بهترین استفاده از هرم وارونه فاجعه
معماری ۳-۲-۱ یا هرم وارونه فاجعه به دلایل بسیاری به طردشده صنعت IT تبدیل شده است. متأسفانه بسیاری از شرکتها تنها پس از رسیدن قطعات و خروج پول از حسابها با خطرات مرتبط با این طراحی آشنا میشوند.
برخی شرکتها خوششانس هستند و این اشتباه را بهقدری زود مییابند که بتوانند خریدهای خود را بازگردانند و با یک مرحله طراحی و تصمیمگیری مناسب قبل از تهیه سختافزار و نرمافزار جدید از نو شروع کنند. این، اما، یک وضعیت ایدهآل و بسیار نادر است. در بهترین حالت میتوان انتظار هزینههای بازگشت کالا داشت و در موارد بسیار رایجتر، تجهیزات اصلاً قابل بازگشت نیستند یا هزینهها آنقدر بالاست که بیفایده میشود.
آنچه بیشتر شرکتها با آن روبرو هستند نیاز به «بهترین استفاده» از وضعیت موجود است. یکی از بزرگترین نگرانیها این است که طرفهای ذینفع، چه سهامداران مالی که پول زیادی برای سختافزار جدید خرج کردهاند و چه سهامداران فنی که اکنون به خاطر اجازه دادن به خرید این تجهیزات وجهشان به خطر افتاده، تسلیم واکنش احساسی شده و به دام مغالطه هزینه از دست رفته بیفتند. حیاتی است که این واکنش احساسی و غیرمنطقی اجازه بروز نیابد زیرا تصمیمگیریهای حیاتی را تضعیف خواهد کرد.
باید درک شود که پولی که برای هرم وارونه فاجعه خرج شده، رفته و از دست رفته است. اینکه پول هدر رفته یا چقدر هدر رفته در این مرحله برای تصمیمگیری بیربط است. اگر این سیستم یک هدیه بود یا یک میلیارد دلار هزینه داشت، اهمیتی ندارد؛ آن پول رفته و اکنون باید با آنچه داریم کنار بیاییم. یک «ترفند» احتمالی اینجا میتواند این باشد که یک تصمیمگیرنده مالی مانند مدیر ارشد مالی را وارد کنیم، توضیح دهیم که در شرف یک واکنش احساسی به پول از پیش خرج شده هستیم و مغالطه هزینه از دست رفته را قبل از بحث درباره مشکل واقعی مطرح کنیم تا همه آگاه و منطقی باشند و آن شخص آموزشدیده (امیدوارانه) برای بهترین مدیریت این نوع وضعیت حاضر و آماده برای جلوگیری از واکنشهای سنک کاست باشد. مدیریت دقیق یک واکنش بالقوه احساسی مهم است. این زمان مناسبی برای پوشاندن اشتباهات مالی یا فنی نیست، که همان چیزی است که واکنش احساسی ایجاد میکند. لازم است همه طرفها ارتباط برقرار کنند و برای رسیدگی به نیازها بیطرف و منطقی بمانند. برخی شرکتها این کار را به خوبی انجام میدهند، بسیاری نمیدهند و در تلاش برای ادامه تصمیمات بد که قبلاً گرفته شده گیر میکنند، احتمالاً به این امید که اتفاق بدی نیفتد و هیچکس یادش نماند یا متوجه نشود. با این واکنش مبارزه کنید. همه آن را دارند، این واکنش طبیعی عاطفی «جنگ یا گریز» آمیگدال است.
حالا که آماده مبارزه با واکنشهای احساسی به مشکل هستیم، میتوانیم شروع به بررسی «از اینجا کجا برویم» کنیم. خبر خوب این است که جایی که هستیم عموماً موقعیت «بیش از حد داشتن» است نه «کم داشتن». پس فرصت داریم کمی خلاق باشیم. خوشبختانه معمولاً گزینههای خوبی وجود دارد که میتواند ما را در چندین مسیر حرکت دهد.
یک نکته بسیار مهم که باید توجه داشت این است که ما به دنبال راهحلهایی هستیم که منحصراً از معماری هرم وارونه فاجعهای که جایگزین میکنیم قابلاطمینانتر باشند، نه کمتر. یک IPOD یک طراحی بسیار شکننده و خطرناک است و میتوانستیم وقت زیادی صرف نمایش مفاهیمی مانند تحلیل ریسک، نقاط تک خرابی، مغالطههای افزونگی کاذب، بررسی افزونگی به جای قابلیت اطمینان، زنجیرههای وابستگی و غیره کنیم، اما آنچه کاملاً حیاتی است که همه طرفها بفهمند این است که یک سرور منفرد که با ذخیرهسازی محلی کار میکند از کل زیرساخت IPOD قابلاطمینانتر است. این آنقدر مهم است که باید دوباره گفته شود: اگر یک سرور منفرد «دسترسپذیری استاندارد» است، IPOD پایینتر از آن است. پرخطرتر. اگر کسی در این مرحله از «فقدان افزونگی» یا «فقدان پیچیدگی» در راهحلهای حاصل میترسد، باید به این موضوع برگردیم - هیچیک از چیزهایی که بحث خواهیم کرد به اندازه آنچه قبلاً طراحی و خریداری شده پرخطر نیست. اگر هر ترسی از ریسک در آینده وجود دارد، ترس باید قبل از اینکه قابلیت اطمینان طراحی را بهبود دادیم بیشتر بود. این قابل اغراق نیست. IPODها میفروشند زیرا به راحتی آنهایی را که در تحلیل ریسک آموزشندیدهاند گیج میکنند و قابلاطمینان به نظر میرسند در حالی که در واقع چنین نیستند.
درک موارد فوق و استفاده از تکنیکی به نام «خوانش معکوس» معماری پذیرفتهشده IPOD به ما میگوید که شرکت مورد نظر در زمان خرید IPOD قبول داشته که دسترسپذیری بالا (یا حتی دسترسپذیری استاندارد) نداشته باشد. شاید آنها فکر میکردند که آن را دارند، اما معماری نمیتوانست آن را فراهم کند و بنابراین در آینده این گزینه را داریم که «سرپا بمانیم» با چیزی کمتر از یک سرور منفرد که روی ذخیرهسازی محلی خودش کار میکند. این ساده و آسان است و تقریباً در هر جنبهای از طراحی IPOD مورد نظر بهتر است. هزینه کمتری برای اجرا و نگهداری دارد، اغلب سریعتر است و پیچیدگی بسیار کمتری دارد و در عین حال کمی قابلاطمینانتر است.
اما احتمالاً صرفاً کاهش به یک سرور منفرد و امیدوار بودن برای یافتن استفادههایی برای بقیه تجهیزات خریداریشده «در جای دیگر» بهترین گزینه ما نخواهد بود. در وضعیتهایی که IPOD قرار بود فقط برای یک بار کار یا مجموعهای از بارهای کاری استفاده شود و سایر حوزههای کسبوکار نیز به تجهیزات نیاز دارند، میتواند بسیار مفید باشد که برای بار کاری مورد نظر IPOD رویکرد «سرور منفرد» را اتخاذ کنیم و از تجهیزات باقیمانده در جاهای دیگر در کسبوکار استفاده کنیم.
رایجترین رویکرد برای استفاده مجدد از یک پشته IPOD، پیکربندی مجدد دو (یا بیشتر) نود کامپیوت برای تبدیل شدن به نودهای full stack شامل ذخیرهسازی خودشان است. این مرحله ممکن است هیچ خریدی نیاز نداشته باشد، بسته به اینکه چه ذخیرهسازی قبلاً خریداری شده، جابجایی درایوها بین سیستمها یا اغلب خرید نسبتاً کوچک هارددیسکهای اضافی برای این منظور.
سپس این نودها میتوانند به یکی از دو مدل دسترسپذیری بالا پیکربندی شوند. در گذشته یک انتخاب طراحی رایج، به دلایل هزینه، استفاده از مدل رپلیکیشن ناهمگام (اغلب به عنوان رویکرد Veeam شناخته میشود) بود که ماشینهای مجازی را بین نودها رپلیکیت میکند و امکان راهاندازی سریع VMها را میدهد که زمان توقف از لحظه خرابی نود کامپیوت تا بازیابی را به چند دقیقه کاهش میدهد.
امروزه تحملپذیری خطای کاملاً همگام بهقدری به طور رایگان در دسترس است که عملاً مدل ناهمگام را در تقریباً همه موارد جایگزین کرده است. در این مدل ذخیرهسازی بهطور کاملاً بلادرنگ بین نودهای کامپیوت رپلیکیت میشود و امکان فیلاور فوری را به جای تأخیر چند دقیقهای و بدون از دست دادن داده به جای پنجره از دست دادن داده کوچک (مثلاً RPO برابر با صفر) فراهم میکند.
در این مرحله به نظر میرسد رایج باشد که مردم به رپلیکیشن با ترس از کاهش ظرفیت ذخیرهسازی ناشی از رپلیکیشن واکنش نشان دهند. البته این درست است. لازم است که درک شود که این رپلیکیشن، که در طراحی اصلی IPOD گم شده بود، پایه محکمی برای قابلیت اطمینان بالا فراهم میکند. اگر این رپلیکیشن حذف شود، دسترسپذیری بالا یک رویای دستنیافتنی است و نودهای کامپیوت منفرد که از ذخیرهسازی محلی در حالت «مستقل» استفاده میکنند قابلاطمینانترین گزینه بالقوه است. راهحلهای دسترسپذیری بالا به رپلیکیشن و افزونگی متکی هستند تا قابلیت اطمینان لازم برای واجد شرایط بودن برای دسترسپذیری بالا را بسازند.
این سؤال را که با نودهای کامپیوت چه کنیم حل میکند اما این سؤال را باقی میگذارد که با دستگاه ذخیرهسازی اشتراکی خارجی، نقطه تک خرابی یا «نوک» طراحی هرم وارونه چه کنیم. برای پاسخ به این سؤال باید با بررسی اینکه این ذخیرهسازی چه چیزی ممکن است باشد شروع کنیم.
سه نوع رایج دستگاه ذخیرهسازی وجود دارد که در طراحی هرم وارونه استفاده میشود: DAS، SAN و NAS. میتوانیم DAS و SAN را با هم جمع کنیم زیرا هر دو جنبههای مختلف ذخیرهسازی بلوکی هستند و میتوانند در بحث ما اساساً به جای یکدیگر استفاده شوند - آنها تنها با وجود سوئیچینگ که میتواند در صورت نیاز در طراحیهای ما اضافه یا حذف شود از هم متمایز میشوند. NAS با اینکه ذخیرهسازی فایل است نه ذخیرهسازی بلوکی متفاوت است.
در هر دو مورد، ذخیرهسازی بلوکی (DAS یا SAN) یا فایل (NAS)، یکی از رایجترین کاربردها برای این دستگاه اکنون اضافی به عنوان هدف بکاپ برای زیرساخت مجازیسازی جدید ما است. در بسیاری از موارد دستگاه ممکن است برای این کار بیش از حد بزرگ باشد، عموماً با کارایی بیشتر و ویژگیهای بسیار بیشتر از آنچه برای یک هدف بکاپ ساده نیاز است، اما ذخیرهسازی بکاپ خوب برای هر زیرساخت کسبوکاری حیاتی است و خطا کردن به سمت بیش از حد بزرگ بودن لزوماً چیز بدی نیست. کسبوکارها اغلب تلاش میکنند در زیرساختهای بکاپ خود صرفهجویی کنند و این فرصتی است برای سرمایهگذاری سنگین در آن بدون خرج پول اضافی.
در همان راستای ذخیرهسازی بکاپ، دستگاه ذخیرهسازی خارجی میتواند به عنوان ذخیرهسازی آرشیو یا سایر «لایههای پایینتر» ذخیرهسازی که دسترسپذیری بالا در آنها توجیه ندارد، تغییر کاربری دهد. این رویکرد کمتر رایج است، عموماً زیرا هر کسبوکاری به یک سیستم بکاپ خوب نیاز دارد اما فقط برخی راهی برای استفاده از لایه ذخیرهسازی آرشیو دارند.
فراتر از این دو مدل ذخیرهسازی رایج و جهانی، یک مورد استفاده رایج برای دستگاههای ذخیرهسازی خارجی، به خصوص اگر دستگاه یک NAS باشد، استفاده از آن در نقش اصلی خود به عنوان فایلسرور جدا از زیرساخت مجازیسازی است. برای بسیاری از کسبوکارها ارائه فایل از نظر آپتایم به اندازه زیرساخت اصلی مجازیسازی حیاتی نیست و بکاپها نگهداری و مدیریت آسانتری دارند. با برونسپاری ارائه فایل به یک دستگاه NAS که قبلاً خریداری شده، میتوان نیازمندیهای ارائه فایل از زیرساخت مجازیسازی را کاهش داد هم با کاهش تعداد VMهایی که باید در آنجا اجرا شوند و هم با انتقال آنچه معمولاً یکی از بزرگترین مصرفکنندگان ذخیرهسازی است به یک دستگاه جداگانه که میتواند نیازمندیهای کارایی زیرساخت مجازیسازی را کاهش دهد همانطور که نیازمندیهای ظرفیت آن را نیز کاهش میدهد. با انجام این کار به طور بالقوه هزینه تهیه هارددیسکهای اضافی لازم برای ذخیرهسازی محلی روی نودهای کامپیوت را که قبلاً ذکر کردیم کاهش میدهیم و بنابراین این میتواند یک روش بسیار محبوب برای بسیاری از شرکتها برای رفع نیازهای استفاده مجدد باشد.
هر شرکتی منحصر به فرد است و به طور بالقوه جاهای زیادی وجود دارد که تجهیزات ذخیرهسازی اضافی میتواند به طور مؤثر از آزمایشگاهها تا آرشیوها تا ذخیرهسازی لایهبندیشده استفاده شود. استفاده از کمی خلاقیت و تفکر خارج از چارچوب میتواند برای بهرهگیری از مجموعه منحصربهفرد تجهیزات موجود و مجموعه منحصربهفرد نیازها و خواستههای کسبوکار و یافتن بهترین جا برای استفاده از این تجهیزات که از زیرساخت اصلی مجازیسازی حیاتی جدا شده اما هنوز میتواند برای سازمان ارزشآفرینی کند، به کار رود. با اجتناب از هرم وارونه فاجعه میتوانیم بیشترین ارزش را از تجهیزاتی که قبلاً در آنها سرمایهگذاری کردهایم به دست آوریم به جای اینکه بدهی فنی تازهای ایجاد کنیم که باید بعد از آن به طور غیرضروری بر آن غلبه کنیم.
آگهی
