وقتی عدم افزونگی قابل اعتمادتر است – افسانه افزونگی

ریسک مفهوم دشواری است و برای ارزیابی صحیح سناریوهای داده شده نیاز به آموزش، تفکر و تحلیل زیادی دارد. اغلب، چون ارزیابی‌های ریسک بسیار دشوار هستند، تحلیل ریسک را با افزودن ساده افزونگی پایه و فرض اینکه ریسک را به درستی کاهش داده‌ایم جایگزین می‌کنیم. اما خیلی اوقات اینطور نیست. معرفی پیچیدگی یا حالت‌های خرابی اضافی اغلب با افزودن افزونگی همراه می‌شود و این اشکال جدید خرابی پتانسیل افزودن ریسک بیشتر از آنچه افزونگی افزوده شده حذف می‌کند را دارند. سیستم‌های ذخیره‌سازی به ویژه مستعد این فرآیندهای تصمیم‌گیری هستند که متأسف‌کننده است زیرا کمتر از آنها، در صورت وجود، در برابر خرابی آسیب‌پذیر و برای محافظت مهم‌تر هستند.

RAID مثال خوبی است که چگونه فقدان تفکر جامع درباره ریسک می‌تواند به برخی تصمیم‌گیری‌های عجیب منجر شود. اگر به یک سناریوی نه‌چندان غیرمعمول نگاه کنیم، می‌بینیم که هدف محافظت در برابر خرابی درایو می‌تواند در واقع منجر به افزایش ریسک حتی هنگامی که افزونگی اضافی اعمال می‌شود گردد. در این سناریو یک آرایه دوازده‌درایوه متشکل از دوازده هارد دیسک SATA سه ترابایتی در یک آرایه واحد را مقایسه خواهیم کرد. شنیدن اینکه مردم RAID 5 را برای این سناریو انتخاب می‌کنند تا «حداکثر ظرفیت و عملکرد» داشته باشند در حالی که «حفاظت کافی در برابر خرابی» دارند غیرمعمول نیست.

ایده اینجا این است که RAID 5 در برابر از دست دادن یک درایو محافظت می‌کند که می‌تواند جایگزین شود و آرایه قبل از خراب شدن درایو دوم خودش را بازسازی می‌کند. این در تئوری عالی است اما ریسک‌های واقعی یک آرایه با این اندازه، سی‌وشش ترابایت ظرفیت درایو، نه از خرابی‌های چندگانه درایو آنطور که مردم عموماً تصور می‌کنند بلکه از ناتوانی در بازسازی قابل اعتماد آرایه پس از خرابی یک درایو یا از خرابی خود آرایه بدون اینکه هیچ درایو فردی خراب شود می‌آید. ریسک خرابی درایو دوم پایین است، نه صفر، اما کاملاً پایین. درایوهای امروز بسیار قابل اعتماد هستند. وقتی یک درایو خراب می‌شود، احتمال خرابی درایو دوم را افزایش می‌دهد که خوب مستند شده است، اما نمی‌خواهم این ریسک ما را از نگاه کردن به ریسک‌های واقعی گمراه کند – ریسک یک عملیات resilver ناموفق.

آنچه در طول یک عملیات resilver RAID 5 ما را می‌ترساند این است که یک خطای خواندن غیرقابل بازیابی (URE) می‌تواند رخ دهد. وقتی این اتفاق می‌افتد عملیات resilver متوقف می‌شود و آرایه در حالت بی‌فایده رها می‌شود – تمام داده‌های روی آرایه از دست می‌رود. در درایوهای SATA معمولی نرخ URE برابر 10^14 است، یا یک بار در هر دوازده ترابایت عملیات خواندن. این بدان معناست که یک آرایه شش ترابایتی در حال resilver تقریباً پنجاه درصد شانس برخورد با URE و شکست دارد. پنجاه درصد احتمال شکست دیوانه‌وار بالاست. تصور کنید اگر ماشین شما پنجاه درصد احتمال افتادن چرخ‌هایش هر بار که آن را می‌راندید داشت. پس با یک آرایه RAID 5 شش ترابایتی کوچک (طبق استانداردهای امروز) با استفاده از درایوهای SATA با URE برابر 10^14، اگر یک درایو را از دست می‌دادیم، فقط پنجاه درصد احتمال دارد که آرایه در صورت جایگزینی فوری درایو بازیابی شود. این شامل ریسک خرابی درایو دوم نیست، فقط ریسک خرابی URE است. همچنین فرض می‌کند که درایو کاملاً بیکار است به جز عملیات resilver. اگر درایوها به طور مشغول برای سایر کارها در همان زمان استفاده شوند، احتمال وقوع چیز بدی، چه یک URE چه خرابی درایو دوم، به طور چشمگیری افزایش می‌یابد.

با یک آرایه دوازده ترابایتی احتمال از دست دادن کامل داده در طول یک عملیات resilver به صد درصد نزدیک می‌شود – یعنی RAID 5 در آن حالت هیچ کارکردی ندارد. همیشه احتمال بقا وجود دارد اما بسیار پایین است. در شش ترابایت می‌توانید یک عملیات resilver را با یک بازی روسی رولت با یک گلوله و شش محفظه مقایسه کنید و باید ماشه را سه بار بکشید. با دوازده ترابایت باید شش بار بکشید! اینها شانس‌های خوبی نیستند.

اما ما درباره یک آرایه دوازده ترابایتی صحبت نمی‌کنیم. ما درباره یک آرایه سی‌وشش ترابایتی صحبت می‌کنیم – که بزرگ به نظر می‌رسد اما این اندازه‌ای است که امروز حتی یک فرد می‌تواند در خانه داشته باشد، چه برسد در یک کسب‌وکار. هر سازنده عمده سرور، و همچنین تقریباً تمام فروشندگان ذخیره‌سازی کم‌هزینه، سیستم‌های ذخیره‌سازی زیر ده‌هزار دلار در این محدوده ظرفیت را امروز می‌سازند. Resilver کردن یک آرایه RAID 5 با یک خرابی درایو روی یک آرایه سی‌وشش ترابایتی مانند بازی روسی رولت، یک گلوله، شش محفظه و کشیدن ماشه هجده بار است! داده‌های شما شانس چندانی ندارند. به این اضافه کنید مقدار شگفت‌انگیز زمان لازم برای resilver یک آرایه از این اندازه را و ریسک از دست دادن دیسک دوم در طول پنجره resilver شروع به تبدیل شدن به یک تهدید کاملاً قابل توجه می‌کند. برآوردهایی از زمان‌های resilver دیده‌ام که در برخی سیستم‌ها به هفته‌ها یا ماه‌ها می‌رسد. مدت زمان طولانی‌ای است که بدون توانایی از دست دادن درایو دیگری اجرا شود. وقتی صحبت از ساعت‌ها یا روزها است ریسک‌ها نسبتاً پایین هستند اما همچنان وجود دارند. وقتی صحبت از هفته‌ها یا ماه‌ها آسیب رساندن مداوم است، همانطور که عملیات resilver به شدت درایو-فشرده هستند، نرخ خرابی به شدت بالا می‌رود.

با یک آرایه از این اندازه می‌توانیم به طور مؤثر فرض کنیم که از دست دادن یک درایو به معنای از دست دادن کامل آرایه است و ما را بدون هیچ حفاظتی در برابر خرابی درایو رها می‌کند. حالا اگر به یک درایو با همان یا عملکرد بهتر با همان یا ظرفیت بهتر در RAID 0 نگاه کنیم که هیچ حفاظتی در برابر از دست دادن درایو ندارد، فقط باید از همان درایوهایی که برای آرایه RAID 5 دوازده‌تایی نیاز داشتیم یازده‌تا استفاده کنیم. این بدان معناست که به جای دوازده هارد دیسک، هر کدام با تقریباً سه درصد احتمال خرابی سالانه، فقط یازده داریم. این به تنهایی آرایه RAID 0 ما را قابل اعتمادتر می‌کند زیرا درایوهای کمتری برای از کار افتادن وجود دارد. نه تنها درایوهای کمتری داریم بلکه نیازی به نوشتن بلوک پریتی نیست و نه از رد شدن از بلوک‌های پریتی هنگام خواندن که کمی، هر چند ناچیز، سایش مکانیکی روی آرایه RAID 0 برای همان استفاده را کاهش می‌دهد و یک مزیت قابلیت اطمینان اضافی بسیار جزئی می‌دهد. آرایه RAID 0 یازده‌درایوه از نظر ظرفیت با آرایه دوازده‌درایوه RAID 5 یکسان اما توان عملیاتی و تأخیر اندکی بهتر خواهد داشت. یک برد همه‌جانبه. به علاوه صرفه‌جویی در هزینه عدم نیاز به درایو اضافی.

پس آنچه اینجا می‌بینیم این است که در آرایه‌های بزرگ (بزرگ از نظر ظرفیت نه از نظر تعداد اسپیندل) RAID 0 در واقع در برخی سناریوها از RAID 5 پیشی می‌گیرد. هنگام استفاده از درایوهای SATA معمولی این در ظرفیت‌هایی اتفاق می‌افتد که حتی کاربران حرفه‌ای در خانه و بسیاری از کسب‌وکارهای کوچک تجربه می‌کنند. اگر به درایوهای SATA سازمانی یا SAS برویم، عدد ظرفیتی که این اتفاق می‌افتد بسیار بالا می‌رود و امروز نگرانی نیست اما در چند سال آینده که ظرفیت‌های درایو بیشتر هم افزایش یابند خواهد بود. اما این برجسته می‌کند که RAID 5 در اندازه‌هایی که امروز می‌بینیم چقدر خطرناک است. همه مخاطرات شگفت‌انگیز RAID 0 را می‌فهمند اما درک اینکه مشکلات RAID 5 آنقدر شدید است که ممکن است در واقع کمتر از RAID 0 قابل اعتماد باشد دشوار است.

اینکه RAID 5 ممکن است فقط بر اساس عملیات resilver در یک آرایه از این اندازه از RAID 0 کمتر قابل اعتماد باشد تنها آغاز است. در یک آرایه عظیم مثل این، زمان resilver می‌تواند آنقدر طولانی شود و فشار چنین سنگینی بر درایوها وارد کند که خرابی درایو دوم هم شروع به تبدیل شدن به یک ریسک قابل اندازه‌گیری کند. و سپس ریسک‌های اضافی ناشی از خطاهای کنترلر آرایه هستند که می‌توانند از الگوریتم‌های resilver برای نابود کردن یک آرایه کامل حتی بدون اینکه خرابی درایوی رخ داده باشد استفاده کنند. از آنجا که RAID 0 (یا RAID 1 یا RAID 10) الگوریتم‌های resilver ندارند، از این ریسک اضافی رنج نمی‌برند. اینها ریسک‌های دشوار برای کمیت‌سنجی هستند اما آنچه مهم است این است که آنها ریسک‌های اضافی هستند که هنگام استفاده از یک سیستم پیچیده‌تر در صورتی که یک سیستم ساده‌تر، بدون افزونگی، از ابتدا قابل اعتمادتر بود انباشته می‌شوند.

حالا که ثابت کردیم RAID 5 می‌تواند از RAID 0 کمتر قابل اعتماد باشد، به خطرات واضح RAID 0 اشاره می‌کنم. RAID به طور کلی برای کاهش ریسک خرابی یک هارد دیسک تنها و منفرد استفاده می‌شود. همه از شکست خوردن یک درایو تنها و از دست رفتن تمام داده‌ها می‌ترسیم. RAID 0، که یک نوار بزرگ از درایوها بدون هیچ نوع افزونگی است، ریسک از دست دادن داده در اثر خرابی یک درایو را در تعدادی از درایوها تکثیر می‌کند که در آن خرابی هر درایوی باعث از دست رفتن کامل داده در تمام درایوها می‌شود. پس در مثال یازده‌دیسکی بالا، اگر هر یک از یازده دیسک خراب شود همه چیز از دست می‌رود. کاملاً واضح است که این چقدر خطرناک‌تر از استفاده از یک درایو تنها است.

آنچه اینجا می‌خواهم اشاره کنم این است که افزونگی به معنای قابلیت اطمینان نیست. فقط به این دلیل که چیزی افزونه است، مانند RAID 5، هیچ تضمینی ارائه نمی‌دهد که همیشه از چیزی که افزونه نیست قابل اعتمادتر باشد.

مشابه‌سازی مورد علاقه‌ام اینجا نگاه کردن به خانه‌ها در یک تورنادو است. در یک سناریو یک خانه از آجر و ملات می‌سازیم. در سناریوی دوم دو خانه افزونه، هر کدام از کاه می‌سازیم (سازندگان ما ظاهراً خوک هستند). وقتی تورنادو (یا گرگ بد بزرگ) می‌آید کدام احتمال بیشتری دارد که یک خانه سرپا رها کند؟ روشن است که یک خانه آجری و ملاتی مزایای قابلیت اطمینان قابل توجهی نسبت به خانه‌های کاهی افزونه دارد. افزونگی اهمیتی نداشت؛ قابلیت اطمینان در نهایت اهمیت داشت.

افزونگی اغلب گمراه‌کننده است چون کمیت‌سنجی آن آسان اما کیفیت‌سنجی آن دشوار است. افزونگی یک سؤال سیاه یا سفید است: آیا افزونه است؟ بله یا نه. ساده. قابلیت اطمینان اینقدر ساده نیست. قابلیت اطمینان درباره نرخ‌های خرابی و احتمالات است. درباره آمار و تحلیل است. از آنجا که کمیت‌سنجی قابلیت اطمینان به شکلی معنادار دشوار است، به ویژه هنگام فروش یک پروژه به افراد تجاری، افزونگی اغلب به جایگزین ساده‌ای برای این مفهوم پیچیده تبدیل می‌شود.

مفهوم استفاده از افزونگی برای انحراف سؤالات قابلیت اطمینان در نهایت به زیرسیستم‌ها نیز به شیوه‌های بسیار پیچیده اعمال می‌شود. به جای اینکه یک «سیستم» افزونه شود، رایج شده که یک زیرسیستم بسیار قابل اعتماد و کم‌هزینه افزونه شود و افزونگی زیرسیستم به عنوان اعمال‌شدن به کل سیستم برخورد شود. رایج‌ترین مثال این کنترلرهای RAID در محصولات SAN است. به جای داشتن یک SAN افزونه (یعنی دو SAN)، سازندگان اغلب آن یک جزء که معمولاً در سرورهای عادی افزونه نیست را افزونه می‌کنند و سپس SAN را افزونه می‌نامند – یعنی یک SAN که حاوی افزونگی است، که اصلاً یک چیز نیست.

یک مشابه‌سازی خوب اینجا مقایسه داشتن ماشین‌های افزونه یعنی دو ماشین کامل و کارآمد با داشتن یک ماشین با یک پمپ آب یدکی در صندوق عقب در صورت خرابی پمپ اصلی است. روشن است که یک پمپ آب یدکی چیز بدی نیست. اما همچنین مقدار ناچیزی از محافظت در برابر خرابی ماشین در مقایسه با داشتن یک ماشین دوم آماده به حرکت است. در یک مورد کل سیستم افزونه است، از جمله شاسی. در مورد دیگر فقط یک جزء بسیار قابل اعتماد را درون شاسی افزونه می‌کنیم. حتی به پای داشتن یک لاستیک یدکی هم نمی‌رسد که حداقل یک قطعه ماشین با احتمال بالاتر خرابی است.

درست مثل افسانه قابلیت اطمینان RAID 5 و قابلیت اطمینان سیستم/زیرسیستم، فناوری‌های ذخیره‌سازی اشتراکی مانند SAN و NAS اغلب به همین شکل برخورد می‌شوند، به ویژه در مورد مجازی‌سازی. یک سناریوی رایج وجود دارد که در آن یک پروژه مجازی‌سازی انجام می‌شود و مردم غریزتاً وحشت می‌کنند چون یک هاست مجازی‌سازی واحد نقطه شکست واحدی را نشان می‌دهد که اگر خراب شود بسیاری از سیستم‌ها همگی با هم خراب خواهند شد.

استفاده از اصطلاح «نقطه شکست واحد» احساس وحشت ایجاد می‌کند و وسیله‌ی عالی برای هدایت یک مکالمه است. اما یک SPOF، همانطور که آن را می‌نامیم، در حالی که چیزی است که دوست داریم در صورت امکان حذف کنیم ممکن است پایان دنیا نباشد. به خانه آجری ما فکر کنید. یک SPOF است. دو خانه از کاه ما نیستند. با این حال یک نسیم کوچک راه‌حل‌های افزونه ما را سریع‌تر از SPOF قابل اعتماد ما از بین می‌برد. جستجوی SPOFها روش خوبی برای یافتن نقاط شکنندگی در یک سیستم است اما احساس نکنید که هر SPOF باید در هر سناریویی افزونه شود. اکثر کسب‌وکارها بهترین ارزش را با داشتن بسیاری از SPOFها پیدا خواهند کرد. هدف واقعی ما قابلیت اطمینان با هزینه مناسب است؛ افزونگی، همانطور که دیده‌ایم، جایگزین قابلیت اطمینان نیست، صرفاً ابزاری است که می‌توانیم برای دستیابی به قابلیت اطمینان استفاده کنیم.

تئوری که بسیاری از مردم هنگام مجازی‌سازی دنبال می‌کنند این است که هاست مجازی‌سازی را گرفته و می‌گویند «این هاست یک SPOF است پس باید دو تا از آنها داشته باشم و از ویژگی‌های High Availability برای failover شفاف استفاده کنم!» این توسط پیشرو فروشنده مجازی‌سازی که درآمدش اول از فروش محصولات افزودنی گران‌قیمت HA و دوم از مالکیت یک فروشنده ذخیره‌سازی بزرگ تأمین می‌شود تحریک می‌شود – پس فروش ذخیره‌سازی اشتراکی غیرضروری یا حتی خطرناک اضافی یک برد بزرگ پولی برای آنهاست و به راحتی می‌تواند دلیلی باشد که آنها از ابتدا فضای مجازی‌سازی را حمایت کرده‌اند. هاست‌های مجازی‌سازی افزونه با ذخیره‌سازی اشتراکی عالی به نظر می‌رسد اما می‌تواند به دلایل متعددی کاملاً اشتباه باشد.

دلیل اول اینکه حذف SPOF اولیه، هاست مجازی‌سازی، با یک SPOF جدید، ذخیره‌سازی اشتراکی، جایگزین می‌شود. این هیچ کاری انجام نمی‌دهد. با فرض اینکه از سرورها و ذخیره‌سازی اشتراکی با کیفیت قابل مقایسه استفاده می‌کنیم، تنها چیزی که کرده‌ایم این است که محل ریسک را جابجا کرده‌ایم نه اینکه اندازه آن را تغییر داده باشیم. احتمال شکست سیستم ذخیره‌سازی تقریباً برابر با احتمال شکست سرور اصلی است. اما علاوه بر جابجا کردن SPOF مثل یک بازی پوسته‌بازی، کاری بسیار بدتر هم انجام داده‌ایم – وابستگی‌های خرابی زنجیری یا آبشاری معرفی کرده‌ایم.

در سناریوی اصلی ما یک سرور داشتیم. اگر سرور کار می‌کرد خوب بودیم، اگر خراب می‌شد نبودیم. ساده. حالا دو هاست مجازی‌سازی، یک سرور ذخیره‌سازی واحد (SAN، NAS، هر چه) و یک شبکه که آنها را به هم وصل می‌کند داریم. قبلاً تعیین کردیم که ریسک شکست ذخیره‌سازی اشتراکی تقریباً برابر با کل ریسک سیستم در سناریوی اصلی است. اما حالا وابستگی‌های اضافی شبکه و دو نود مجازی‌سازی جلویی داریم. هر یک از این اجزا از ذخیره‌سازی اشتراکی شکننده (هر چیزی با درایوهای مکانیکی شکننده خواهد بود) قابل اعتمادتر است اما اینکه ریسک پایین‌تری دارند مسئله نیست؛ مسئله این است که ریسک‌ها ترکیبی هستند.

اگر هر یک از این سه جزء (ذخیره‌سازی، شبکه یا نودهای جلویی) خراب شود همه چیز خراب می‌شود. راه‌حل این است که ذخیره‌سازی اشتراکی را به تنهایی افزونه کنیم و شبکه را به تنهایی افزونه کنیم. با تلاش کافی می‌توانیم بر شکنندگی و ریسکی که با افزودن ذخیره‌سازی اشتراکی معرفی کردیم غلبه کنیم اما ذخیره‌سازی اشتراکی به تنهایی نوعی کاهش ریسک نیست بلکه خودش یک ریسک است که باید کاهش یابد. مارپیچ پیچیدگی شروع می‌شود و هزینه مرتبط با آوردن این سیستم جدید به سطح قابلیت اطمینان سیستم تک‌سرور اصلی می‌تواند نجومی باشد.

حالا که همه این افزونگی را داریم یک ریسک دیگر هم برای نگرانی داریم. مدیریت تمام این افزونگی، تمام این قطعات متحرک، دانش، مهارت و آمادگی بسیار بیشتری نسبت به مدیریت یک سرور واحد ساده می‌طلبد. از یک راه‌حل ساده به یک راه‌حل بسیار پیچیده رفته‌ایم. در تجربه شخصی خودم، خطرات واقعی راه‌حل‌هایی مثل این نه از شکست سخت‌افزار بلکه از خطای انسانی می‌آیند. نه تنها کار زیادی برای جلوگیری از ایجاد خرابی این سیستم جدید توسط خطای انسانی انجام نشده بلکه نقاط بی‌شماری اضافه کرده‌ایم که یک انسان ممکن است تصادفاً کل سیستم، افزونگی و همه را پایین بیاورد. خودم دیده‌ام؛ داستان‌های ترسناک شنیده‌ام. هرچه سیستم پیچیده‌تر باشد احتمال اینکه یک انسان تصادفاً همه چیز را خراب کند بیشتر است.

این امر حیاتی است که به عنوان متخصصان IT یک قدم به عقب برداریم و به سیستم‌های کامل نگاه کنیم و قابلیت اطمینان و ریسک را در نظر بگیریم و افزونگی را صرفاً به عنوان ابزاری برای استفاده در پیگیری قابلیت اطمینان در نظر بگیریم. افزونگی به خودی خود یک دارویی همه‌کاره نیست. سادگی هم نیست. قابلیت اطمینان یک مسئله پیچیده برای حل است. اجتناب از جایگزینی‌های ساده‌انگارانه اولین قدم مهم در انتقال از پوشاندن مشکلات قابلیت اطمینان به مواجهه و حل آنها است.