فناوری اطلاعات و زیرساخت
زیرساختی که عدد پشتش باشد
شبکه، مرکز داده، ابر، پشتیبانگیری و پایش را طوری طراحی میکنیم که بتوان دربارهشان تعهد داد: چند دقیقه قطعی در ماه، چند دقیقه داده از دسترفته و چند ساعت تا بازگشت سرویس.
درخواست جلسه فنی
بیشتر قطعیهایی که به ما ارجاع میشود ریشه در یک قطعه خراب ندارد؛ ریشه در نقطه اتکای واحدی دارد که کسی روی نقشه ندیده بود — یک سوییچ، یک منبع تغذیه، یا فایل پیکربندیای که فقط روی یک ماشین بود. کار ما حذف همین نقطههاست، پیش از آنکه خودشان را نشان بدهند.
طراحی لایهای با هسته، توزیع و دسترسی؛ هر سوییچ دسترسی با دو آپلینک به دو دستگاه توزیع مجزا و دو مسیر فیزیکی متفاوت. در هسته از MLAG یا پشتهسازی استفاده میکنیم تا هر دو مسیر همزمان بار ببرند و بازگشت از خطا به جای درخت پوشا (STP) بر عهده مسیریابی باشد.
- تفکیک ترافیک با VRF و VLAN، و سیاست عبور روشن بین ناحیهها
- مسیریابی داخلی با OSPF و اتصال به ارائهدهندگان با BGP روی دو خط از دو اپراتور
- طراحی QoS برای ترافیک حساس به تأخیر مانند صوت و تراکنش
از مسیر برق تا بار حرارتی رک را با هم میبینیم: دو مسیر تغذیه مستقل (A و B)، هر تجهیز با دو منبع روی دو مسیر، یوپیاس با آرایش N+۱ و ژنراتور با آزمون بارگذاری ماهانه. خنککاری با تفکیک راهروی سرد و گرم طراحی میشود، چون بدون آن افزودن ظرفیت بازدهی خطی ندارد.
- بودجه توان و حرارت در سطح هر رک، معمولاً در بازه ۴ تا ۸ کیلووات
- چیدمان رک بر اساس جریان هوا، نه بر اساس جای خالی
- پایش محیطی: دما، رطوبت، نشت آب و باز شدن درِ رک
ابر خصوصی روی خوشه مجازیسازی با ذخیرهساز مشترک، یا سکوی کانتینری برای سرویسهایی که معماریشان اجازه میدهد. در هر دو حالت خوشه را با گره مازاد میبندیم: خوشه ششگرهای باید با پنج گره همان بار را ببرد، وگرنه اولین خرابی سختافزاری به کندی سراسری بدل میشود.
- لایه کنترل با سه گره برای حفظ حد نصاب در خرابی یک گره
- پیکربندی بهصورت کد، تا ساخت دوباره محیط تکرارپذیر باشد
- الگوی ترکیبی: نگهداشتن داده حساس در داخل و بردن بار متغیر به ابر
طرح پشتیبانگیری با دو عدد شروع میشود که کارفرما باید بپذیرد: RPO یعنی چند دقیقه داده را حاضریم از دست بدهیم و RTO یعنی چند ساعت تا بازگشت سرویس قابل تحمل است. باقی طراحی از دل این دو عدد بیرون میآید، نه از فهرست محصولات.
- قاعده ۳-۲-۱: سه نسخه، روی دو رسانه، یکی خارج از سایت
- نسخه تغییرناپذیر برای مقابله با باجافزار؛ نسخهای که خود مدیر هم نتواند پاک کند
- RPO حدود ۱۵ دقیقه برای پایگاه داده با تکرار پیوسته، و ۲۴ ساعت برای داده کمتغییر
- آزمون بازیابی واقعی هر سه ماه، با ثبت زمان و مقایسه با RTO تعهدشده
پایش را روی سه لایه میبندیم: سنجههای زیرساخت، گزارشهای سامانه و پایش تجربه کاربر از بیرون. هر هشدار یک مالک، یک آستانه مستند و یک دستورالعمل کوتاه دارد؛ هشداری که کسی بابتش کاری نمیکند حذف میشود.
- نگهداشتن سربار ظرفیت حدود ۳۰ درصد روی پردازنده، حافظه و فضای ذخیرهسازی
- گزارش ماهانه دسترسپذیری با تفکیک قطعی برنامهریزیشده و ناخواسته
- کشیک شبانهروزی و مسیر ارجاع مشخص در قرارداد پشتیبانی
دسترسپذیری چقدر میارزد؟
درصد دسترسپذیری بدون ترجمه به دقیقه بیمعناست. این جدول همان ترجمه است: هر سطح چقدر قطعی در ماه اجازه میدهد، چه معماریای لازم دارد و چه باری روی بهرهبرداری میگذارد. عددها بر پایه ماه ۳۰ روزهاند.
| سطح تعهد | قطعی مجاز در ماه | معماری لازم | بار بهرهبرداری |
|---|---|---|---|
| ۹۹٪ | حدود ۷ ساعت و ۲۰ دقیقه | یک مسیر اصلی با قطعات یدکی در انبار؛ تکرار در سطح سختافزار (منبع تغذیه و دیسک) و بازیابی از نسخه پشتیبان. | پشتیبانی در ساعت اداری کافی است؛ بهروزرسانی در پنجره تعمیرات انجام میشود و کاربر آن را میبیند. |
| ۹۹٫۵٪ | حدود ۳ ساعت و ۴۰ دقیقه | خوشه فعال-غیرفعال با جابهجایی دستی یا نیمهخودکار، ذخیرهساز مشترک، دو مسیر شبکه و دو مسیر برق. | کشیک خارج از ساعت اداری لازم میشود و هر تغییر به محیط آزمون و برنامه بازگشت نیاز دارد. |
| ۹۹٫۹٪ | حدود ۴۳ دقیقه | خوشه فعال-فعال پشت توزیع بار، بدون نقطه اتکای واحد در هیچ لایه، تکرار همزمان داده و سربار ظرفیت برای از دست دادن یک گره. | کشیک ۲۴/۷ با زمان پاسخ تعهدشده، انتشار تدریجی نسخهها و آزمون دورهای سناریوی خرابی؛ هزینه بهرهبرداری بهروشنی بالاتر است. |
چرا ۹۹٫۹٪ با یک سرور دوم به دست نمیآید
در ۴۳ دقیقه بودجه قطعی ماهانه، هر مداخله انسانی گران است: اگر تشخیص خرابی ده دقیقه و جابهجایی دستی بیست دقیقه طول بکشد، یک حادثه تمام بودجه ماه را میبلعد. پس تشخیص و جابهجایی باید خودکار و آزموده باشد.
سرور دوم هم فقط یکی از چند نقطه اتکاست: اگر هر دو سرور به یک سوییچ، یک ذخیرهساز یا یک پایگاه داده مشترک وصل باشند، دسترسپذیری کل از ضعیفترین حلقه بالاتر نمیرود. پنجره تغییرات را هم بیفزایید؛ در بیشتر سازمانها سهم عمده قطعی از بهروزرسانیهای بدون برنامه بازگشت میآید، نه از خرابی سختافزار.
پرسشهای پرتکرار
تفاوت پشتیبانگیری با تکرار داده چیست؟
تکرار (Replication) داده را در لحظه به نسخه دوم میبرد و در برابر خرابی سختافزار خوب عمل میکند، اما خطا را هم تکرار میکند: اگر جدولی اشتباه پاک شود یا باجافزاری فایلها را رمز کند، نسخه دوم هم چند ثانیه بعد خراب است.
پشتیبانگیری نقطهای از گذشته را نگه میدارد و باید تغییرناپذیر و از شبکه اصلی جدا باشد. هر طرح جدی هر دو را دارد.
چقدر ظرفیت سربار باید نگه داریم؟
قاعده کاری ما حدود ۳۰ درصد سربار روی پردازنده و حافظه در ساعت اوج است، و در خوشهها اندازه یک گره کامل. اگر خوشه در اوج ۹۰ درصد پر باشد، خرابی یک گره بار را به بالای صد درصد میبرد و نتیجه قطعی سراسری است، نه کندی موضعی.
روی فضای ذخیرهسازی هشدار را روی ۷۰ درصد میگذاریم، چون تهیه فضای تازه چند هفته زمان میبرد.
مهاجرت به ابر بهتر است یا نگهداشتن مرکز داده داخلی؟
به الگوی بار بستگی دارد: بار یکنواخت معمولاً در مرکز داده داخلی ارزانتر تمام میشود و بار فصلی در ابر بهتر جواب میدهد. بیشتر مشتریان ما به الگوی ترکیبی میرسند؛ پیش از هر تصمیم، مصرف واقعی سه ماه گذشته را اندازه میگیریم.
آزمون بازیابی را چطور انجام میدهید؟
هر سه ماه یک سرویس را در محیط ایزوله از نسخه پشتیبان بالا میآوریم و زمان واقعی بازیابی را ثبت میکنیم. اگر این زمان از RTO توافقشده بیشتر شد، یا طرح اصلاح میشود یا عدد تعهد. پشتیبان آزمایشنشده پشتیبان نیست.
پروژه زیرساخت چقدر طول میکشد؟
ارزیابی و طراحی معمولاً ۳ تا ۵ هفته است؛ خروجی آن نقشه معماری، فهرست تجهیزات و برنامه اجرا با پنجرههای تغییر است. بازطراحی شبکه یک ساختمان ۶ تا ۱۰ هفته و راهاندازی خوشه مجازیسازی با مهاجرت سرویسها ۸ تا ۱۶ هفته طول میکشد؛ مهاجرتها سرویسبهسرویس انجام میشود تا امکان بازگشت بماند.
آیا زیرساخت موجود را هم تحویل میگیرید؟
بله. کار با دوره انتقال ۴ تا ۶ هفتهای شروع میشود: مستندسازی وضعیت موجود، نقشه وابستگی سرویسها، بستن پایش و تحویل کشیک. تا پایان این دوره تعهد سطح خدمت نمیدهیم، چون هنوز عدد قابل اتکایی از رفتار سامانه نداریم.
پس از آن بهرهبرداری با گزارش ماهانه دسترسپذیری و ظرفیت ادامه پیدا میکند؛ جزئیات در صفحه پشتیبانی آمده است.
از وضعیت فعلی شروع کنیم
ارزیابی کوتاه زیرساخت، نقاط اتکای واحد و سربار ظرفیت فعلی را روشن میکند. خروجی آن یک گزارش اولویتبندیشده است، نه پیشفاکتور تجهیزات.