تخممرغها و سبدهای مجازی
در گفتگو با متخصصان IT کسبوکارهای کوچک، یکی از عوامل اصلی تردید در استقرار مجازیسازی از آنچه بهعنوان “همه تخممرغهایت را در یک سبد نگذار” توصیف میشود ناشی میشود.
میتوانم ببینم این نگرانی از کجا میآید. مجازیسازی به بسیاری از سیستمهای عامل مهمان اجازه میدهد در یک سیستم فیزیکی واحد قرار گیرند که در صورت خرابی سختافزاری، همه سیستمهای مهمان روی آن با هم، همه به یکباره خراب میشوند. این بد به نظر میرسد، اما شاید به اندازهای که ابتدا فرض میکنیم بد نباشد.
ایده اصطلاح تخممرغها و سبدها این است که نباید همه منابع خود را بهطور همزمان در معرض خطر قرار دهیم. این اصطلاح معمولاً در سرمایهگذاری بهکار میرود و سرمایهگذاران را به تنوعبخشی و سرمایهگذاری در شرکتهای مختلف و انواع اوراق بهادار مانند اوراق قرضه، سهام، صندوقها و کالاها تشویق میکند. در مورد تخممرغها (یا پول) از یک کالای قابل تعویض صحبت میکنیم. یک تخممرغ به اندازه تخممرغ دیگری خوب است. مجموعهای از تخممرغها بهطور طبیعی افزونه هستند.
اگر دوازده تخممرغ داریم و ششتا را میشکنیم، هنوز میتوانیم املت درست کنیم، شاید کوچکتر، اما هنوز میتوانیم بخوریم. خوردن یک املت کوچکتر احتمالاً تقریباً به اندازه یک بزرگتر رضایتبخش است - در هر صورت گرسنه نمیمانیم. قرار دادن تخممرغهای از قبل افزونهمان در چند سبد به ما امکان میدهد شرطبندیهایمان را پوشش دهیم. بله، حمل دو سبد به این معناست که زمان کمتری برای توجه به هر کدام داریم، بنابراین خطر از دست دادن برخی تخممرغها را افزایش میدهد اما احتمال از دست دادن همه تخممرغها را کاهش میدهد. در مورد تخممرغها، پیشنهادی خردمندانه است. به همین ترتیب، روشی هوشمند برای آماده شدن برای بازنشستگی.
این نظریه، چون بهعنوان یک اصطلاح بدون تجزیهوتحلیل دقیق یا درک مناسب تکرار میشود، سپس به حوزههای نامرتبط مانند مجازیسازی سرور اعمال میشود. اما سرورها مانند تخممرغ نیستند. سرورها، بهخصوص در کسبوکارهای کوچکتر، بهندرت کالاهای قابل تعویض هستند که داشتن شش عدد کارآمد، بهجای معمول دوازده عدد، کافی باشد. معمولاً هر سرور نقش منحصر به فردی دارد و همهشان نسبتاً برای عملکرد کسبوکار حیاتی هستند. اگر یک سرور حیاتی نباشد، بعید است بتواند هزینه خرید و نگهداری خود را توجیه کند و بنابراین احتمالاً وجود نخواهد داشت. وقتی سرورها قابل تعویض هستند، مانند یک مزرعه وب بزرگ و بیحالت یا کلاستر محاسباتی، بهعنوان یک وسیله برای گسترش ظرفیت فراتر از محدودیتهای یک جعبه فیزیکی واحد پیکربندی میشوند و بنابراین خارج از حوزه این بحث هستند.
خدمات IT در یک کسبوکار معمولاً، حداقل تا حدی، یک «وابستگی زنجیرهای» هستند. یعنی بههم وابسته هستند و از دست دادن یک سرویس ممکن است سایر سرویسها را تحت تأثیر قرار دهد زیرا آنها بهطور فنی به هم وابسته هستند (مانند یک برنامه کاری که به یک پایگاه داده وابسته است) یا بهطور گردشی کاری به هم وابسته هستند (مانند یک کارمند اداری که برای ارائه فایلی نیاز دارد فایلسرور کار کند تا بتواند با اطلاعات یک ایمیل ویرایش کند در حین بحث درباره تغییرات از طریق تلفن یا پیامرسان فوری.) در این موارد، از دست دادن یک سرویس کلیدی واحد مانند ایمیل، احراز هویت شبکه یا خدمات فایل ممکن است به از دست رفتن نامتناسب توانایی کار منجر شود. اگر ده سرویس کلیدی وجود داشته باشد و یکی خراب شود، بهرهوری شرکت از دیدگاه خدمات IT احتمالاً بسیار بیشتر از ده درصد کاهش مییابد، شاید در موارد شدید به نزدیک صد درصد برسد. این همیشه صادق نیست؛ در برخی موارد منحصر به فرد کارمندان میتوانند یک سرویس از دست رفته را بهطور مؤثر «دور بزنند»، اما این بسیار غیررایج است. حتی اگر مردم بتوانند به کار ادامه دهند، احتمالاً بسیار کمتر از حالت معمول بهرهور هستند.
هنگام کار با سرورهای فیزیکی، هر سرور نقطه خرابی خود را نشان میدهد. بنابراین اگر ده سرور داشته باشیم، ده برابر احتمال قطعی نسبت به داشتن تنها یکی از همان سرورها داریم. هر سرور که اضافه میکنیم خطر خود را با خود میآورد. اگر هر خرابی ضریب قطعی ۲.۵ داشته باشد - یعنی تأثیر مالی روی کسبوکار برای بیستوپنج درصد از درآمد برای، مثلاً یک روز - پس تأثیر متوسط کل ما در طول یک دهه معادل دو و نیم قطعی کل سایت است. از مفهوم ضرایب و میانگینها در اینجا برای آسان کردن کار استفاده میکنم؛ تعیین طول یک قطعی متوسط یا تأثیر یک قطعی متوسط لازم نیست زیرا فقط نیاز داریم تأثیر نسبی را برای مقایسه سناریوها تعیین کنیم. این فقط روشی برای مقایسه تأثیر مالی تجمعی قطعی یک نوع رویداد در مقابل رویداد دیگر است بدون نیاز به ارقام خاص - این به شما کمک نمیکند هزینه مصرف را تعیین کنید، فقط قابلیت اطمینان نسبی.
با مجازیسازی توانایی آشکار تجمیع را داریم. در این مثال فرض میکنیم که میتوانیم همه ده سرور موجود را در یک سرور واحد جمع کنیم. وقتی این کار را میکنیم اغلب واکنش «همه تخممرغهایمان در یک سبد» را برمیانگیزیم. اما اگر تجزیهوتحلیل ریسک انجام دهیم خواهیم دید که این معمولاً فقط ترس و عدم اطمینان است و یک خطر ریاضی پشتیبانیشده نیست. اگر همان خطرات مثال بالا را فرض کنیم، سرور واحد ما بهطور متوسط فقط یک قطعی کل سایت، یک بار در دهه، را متحمل خواهد شد.
این را با مثال اول مقایسه کنید که خسارتی معادل دو و نیم قطعی کل سایت داشت - خطر راهحل مجازیشده و تجمیعشده فقط چهل درصد راهحل سنتی است.
حالا به یاد داشته باشید که این بر اساس این فرض است که از دست دادن برخی سرویسها به معنای ضرر مالی بیشتر از ارزش دقیق سرویسی است که از دست رفته، که تقریباً همیشه چنین است. حتی اگر سرویس از دست رفته بیشتر از از دست دادن یک سرویس فردی نباشد، فقط به تساوی میرسیم و نیازی به نگرانی نداریم. در موارد نادر تأثیر از دست دادن یک سیستم واحد میتواند کمتر از «سهمش از کل» باشد، معمولاً به این دلیل که مردم انعطافپذیر هستند و میتوانند سیستم خراب را دور بزنند - مانند اینکه اگر پیامرسان فوری خراب شود و مردم بهسادگی تا بازیابی پیامرسان از ایمیل استفاده کنند، اما این موارد نادر هستند و معمولاً محدود به چند سیستم از میان بسیاری هستند در حالی که اکثر سیستمها، مانند ERP، CRM و ایمیل، در صورت قطعی تأثیر نامتناسب بزرگی دارند.
پس آنچه میبینیم این است که در شرایط عادی انتقال ده سرویس از ده سرور به ده سرویس روی یک سرور بهطور کلی خطر ما را کاهش میدهد نه افزایش میدهد - در تضاد مستقیم با نظریه «تخممرغها در یک سبد». و این صرفاً از دیدگاه خرابی سختافزاری است. تجمیع چند عامل قابلیت اطمینان مهم دیگری نیز دارد که میتواند تأثیر قابلتوجهی بر مطالعه موردی ما داشته باشد.
با تجمیع میزان سختافزاری که باید توسط بخش IT نظارت و مدیریت شود را کاهش میدهیم. سرورهای کمتر به این معناست که زمان و توجه بیشتری میتواند به آنهایی که باقی ماندهاند اختصاص یابد. توجه بیشتر به معنای احتمال بهتر گرفتن مشکلات زودرس و فرصت بیشتر برای نگهداری قطعات یدکی است. نظارت و نگهداری بهتر منجر به قابلیت اطمینان بهتر میشود.
احتمالاً مهمترین عامل با تجمیع این است که صرفهجویی هزینه قابلتوجهی وجود دارد و این، اگر بهدرستی رویکرد گرفته شود، میتواند فرصتهایی برای بهبود قابلیت اطمینان فراهم کند. با کاهش چشمگیر کل هزینه سرورها ممکن است وسوسهانگیز باشد که بودجهها را کم نگه داریم و تلاش کنیم صرفاً از صرفهجویی هزینه مستقیم استفاده کنیم. قابلدرک است و برای برخی کسبوکارها این ممکن است رویکرد صحیح باشد. اما رویکردی که من در مبارزه با مفهوم تخممرغها و سبدها توصیه میکنم نیست.
در عوض با اتخاذ رویکرد متعادلتر که صرفهجویی هزینه قابلتوجهی حفظ میکند اما هنوز هم نسبتاً بیشتر روی یک سرور واحد هزینه میکند، میتوانید یک سرور سطح بالاتر (خواندنی: قابلاطمینانتر) به دست آورید، از قطعات بهتر استفاده کنید، قطعات یدکی در محل داشته باشید و غیره. صرفهجویی هزینه مجازیسازی اغلب میتواند مستقیماً به افزایش قابلیت اطمینان تبدیل شود که معادله را بیشتر به نفع رویکرد سرور واحد تغییر میدهد.
همانطور که در مقاله دیگری ذکر کردم، یک خانه آجری بیشتر از یک یا دو خانه کاهی احتمال بقا در یک طوفان باد را دارد. داشتن چیزهای بیشتر لزوماً آن را انتخاب قابلاطمینانتر نمیکند.
این مزایا صرفاً از جنبه تجمیع مجازیسازی هستند و نه از خود مجازیسازی. مجازیسازی ویژگیهای کاهش خطر گسترشیافته را نیز بهطور جداگانه فراهم میکند. تصویربرداری سیستم و بازیابی سریع، همچنین بازیابی به سختافزار متفاوت، مزایای اصلی بیشتر هر پلتفرم مجازیسازی هستند. این میتواند نقش مهمی در استراتژی بازیابی فاجعه داشته باشد.
البته، همه این مفاهیم صرفاً برای نشان دادن این است که مجازیسازی و تجمیع یک جعبه واحد میتواند رویکرد قدیمی «یک برنامه برای یک سرور» را شکست دهد و در عین حال پول صرفهجویی کند - نشان میدهد که مثال تخممرغها و سبدها گمراهکننده است و در این سناریو اعمال نمیشود. باید تردید کمی در انتقال از یک محیط سنتی مستقیماً به یک محیط مجازیشده بر اساس این عوامل وجود داشته باشد.
باید توجه داشت که مجازیسازی میتواند سپس قابلیت اطمینان سختافزار کالایی سنتی را با ارائه ویژگیهای failover شبیه مینفریم که فراتر از آنچه پلتفرمهای غیرمجازی میتوانند ارائه دهند است، گسترش دهد. این سختافزار کالایی را بیشتر به خط پلتفرمهای بزرگتر و گرانقیمتتر RISC نزدیک میکند. این ویژگیها میتوانند سطح حفاظتی فوقالعادهای فراهم کنند اما اغلب فراتر از آنچه برای فروشگاههای IT که ابتدا از یک محیط سرور قدیمی و بدون failover مهاجرت میکنند مناسب است. دسترسیپذیری بالا یک ویژگی عالی است اما اغلب پرهزینه و معمولاً غیرضروری است، بهخصوص وقتی شرکتها از محیطهای نسبتاً غیرقابلاطمینان گذشته به محیطهای قابلاطمینانتر امروزی منتقل میشوند. با توجه به اینکه قبلاً قابلیت اطمینان را بیشتر از آنچه در گذشته لازم بود افزایش دادهایم، احتمال خوبی وجود دارد که جهش شدید در قابلیت اطمینان الان لازم نباشد، اما با توجه به کاهش بزرگ هزینه دسترسیپذیری بالا، بسیار محتمل است که از نظر هزینه توجیهپذیر باشد در جایی که قبلاً نمیتوانست.
در همین راستا، مجازیسازی اغلب ترسناک است زیرا بهعنوان یک فناوری جدید و اثباتنشده دیده میشود. این مطمئناً نادرست است اما در فضای کسبوکار کوچک و سرور کالایی این تصوری وجود دارد. در واقعیت، مجازیسازی اول بار توسط IBM در دهه ۱۹۶۰ معرفی شد و از آن زمان به این طرف رکن اصلی سرورهای مینفریم و RISC سطح بالا بوده - همان سیستمهایی که بهترین قابلیت اطمینان را میطلبند. در فضای سرور کالایی مجازیسازی یک چالش فنی بزرگتر بود و مدت بسیار طولانی طول کشید تا به اندازه کافی کارآمد پیادهسازی شود تا استفاده از آن در دنیای واقعی مؤثر باشد. اما حتی در فضای سرور کالایی مجازیسازی از اواخر دهه ۱۹۹۰ در دسترس بوده و بنابراین تقریباً پانزده سال قدمت دارد که بسیار فراتر از نقطه یک فناوری نوپا است - در دنیای IT این یک فناوری کاملاً بالغ است. مجازیسازی پلتفرم کالایی یک حوزه بالغ با چندین فروشنده و محصول بسیار معتبر و فوقالعاده پیشرفته است. استفاده از مجازیسازی بهعنوان یک استاندارد برای همه یا تقریباً همه کاربردهای سرور یک «الگوی سازمانی» مدتهاست تثبیتشده و پذیرفتهشده است و الگویی است که اکنون بهراحتی توسط شرکتهای هر اندازهای میتواند پذیرفته شود.
مجازیسازی، شاید برخلاف انتظار، در واقع یک مؤلفه بسیار حیاتی از یک استراتژی قابلیت اطمینان است. بهجای افزودن خطر، مجازیسازی تقریباً میتواند بهعنوان یک پلتفرم کاهش ریسک مورد استفاده قرار گیرد - مجموعهای از ابزارها برای افزایش قابلیت اطمینان پلتفرمهای محاسباتی شما از طرق مختلف.
آگهی
