افزونگی‌ای که واقعا سوییچ می‌کند

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

نخستین و رایج‌ترین عیب وابستگی مشترک است. دو سرور، دو مسیر شبکه، دو منبع تغذیه — و یک سوییچ، یک کلید مدار، یک یو‌پی‌اس، یک رایزر ساختمان، یک منبع زمان، یک دی‌ان‌اس، یک سرور مجوز، یک آرایه ذخیره‌سازی مشترک. جفت افزونه شد؛ چیزی که هر دو به آن نیاز دارند نه. یافتن این ساده است و به‌ندرت دنبالش می‌گردند: معماری را بردارید و برای هر مولفه بپرسید اگر همین یک قلم بایستد چه می‌شود. پاسخ اغلب این است که هر دو نیمه یک جفت افزونه با هم می‌ایستند. دو منبع تغذیه که به یک چندراهی زده شده‌اند مثال کلاسیک است و هنوز بی‌نهایت رایج.

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

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

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

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

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

هدف نقشه‌ای با دو تا از هر چیز نیست. پاسخی مستند، سنجیده و تازه تمرین‌شده به این پرسش است که وقتی یکی‌شان ایستاد چه می‌شود.