پروکسماکس دربارهٔ خرابی چه به من آموخت¶
هوملب جای امنی برای فهمیدن این است که میان یک ماشین مجازی روشن و یک سرویس قابلبازیابی، چه تعداد فرض پنهان وجود دارد.
ماشین مجازی همان سرویس نیست¶
درس اول ساده بود: روشنبودن guest به معنی سالمبودن workload نیست. ذخیرهسازی، شبکه، DNS، همگامسازی زمان و وضعیت برنامه هرکدام حالتهای خرابی خودشان را دارند.
خلاصهوضعیت Proxmox ممکن است guest را سبز نشان دهد، درحالیکه برنامهٔ داخل آن قادر به پاسخگویی نیست. فرایندی شاید در حال اجرا اما منتظر دیتابیس باشد؛ دیتابیس ممکن است سالم باشد اما بهدلیل تغییر bridge یا قانون فایروال در دسترس نباشد. وضعیت زیرساخت مفید است، ولی تنها یک لایه از سلامت سرویس را نشان میدهد.
این موضوع آنچه را باید پایش شود تغییر میدهد. CPU و فضای ذخیرهسازی میزبان مهماند، اما resolveشدن DNS، انقضای گواهی، زمان پاسخ برنامه، عمق صف و توانایی انجام یک درخواست واقعی هم مهم هستند. بهترین health check به کاری نزدیک است که کاربر واقعاً از سرویس انتظار دارد.
snapshot نسخهٔ پشتیبان نیست¶
snapshot برای بازگشت کوتاهمدت پیش از تغییری پرخطر عالی است. سریع و راحت است، چون به دیسک مجازی و سامانهٔ ذخیرهسازی اصلی متصل میماند. همین ارتباط محدودیت آن هم هست: اگر storage از بین برود یا خراب شود، snapshotها نیز ممکن است همراه آن ناپدید شوند.
نسخهٔ پشتیبان باید مرز خرابی مستقلی داشته باشد. در یک هوملب میتوان پشتیبانهای زمانبندیشده را روی دستگاهی دیگر نگه داشت و موارد مهم را به مکان سومی کپی کرد. ابزار دقیق از توانایی پاسخدادن به این پرسشها کماهمیتتر است:
- آیا پشتیبان از میزبان و فضای ذخیرهسازی اصلی جداست؟
- چند نسخهٔ تاریخی نگهداری میشود؟
- آیا خطاها جایی گزارش میشوند که متوجهشان شوم؟
- آیا داده در محل مناسب رمزنگاری شده است؟
- آیا اخیراً بازیابی کامل آزمایش شده است؟
اجرای موفق backup فقط ثابت میکند فایلها نوشته شدهاند؛ تنها بازیابی موفق نشان میدهد که آن فایلها به درد میخورند.
پیکربندی بخشی از بازیابی است¶
دیسکهای guest تمام پلتفرم نیستند. بازیابی ممکن است به پیکربندی VM، نقشهٔ شبکه، تعریف storage، سیاست فایروال، رکوردهای DNS و secretهای برنامه هم نیاز داشته باشد.
بهتر است inventory کوچکی بیرون از کلاستر نگه دارید. برای هر guest مهم، کاربرد، مالک، آدرسها، فضای ذخیرهسازی، وابستگیها، سیاست پشتیبانگیری و ترتیب بازگشت سرویسها را ثبت کنید. پیکربندی قابلخروجی و infrastructure as code اینجا ارزشمندند، اما حتی یک فایل متنی بازبینیشده بهتر از تکیه بر حافظه است.
ترتیب بوت هم مهم است. شروع برنامه پیش از آمادهشدن DNS، دیتابیس یا storage شبکه میتواند هنگام بازیابی رخداد گیجکنندهٔ دیگری بسازد. وابستگیها باید retry را تحمل کنند و برنامهٔ بازیابی باید مشخص کند کدام سرویسهای پایه زودتر بالا میآیند.
عمداً خرابش کنید¶
خرابی کنترلشده، اطمینان مبهم را به شواهد تبدیل میکند:
- یک guest را ناگهانی متوقف کنید.
- آن را جای دیگری بازیابی کنید.
- خود برنامه را بیازمایید، نه فقط فرایند را.
- هرجا به حافظهٔ انسانی نیاز بود ثبت کنید.
«جای دیگر» مهم است. بازیابی روی همان میزبان فقط فایل پشتیبان را میآزماید؛ بازیابی روی storage متفاوت یا node جایگزین بخش بزرگتری از مسیر را آزمایش میکند. اگر guest بازیابیشده ممکن است با آدرسهای عملیاتی تداخل کند یا کارهای واقعی را پردازش کند، از شبکهای ایزوله استفاده کنید.
یک مانور مفید زمان را اندازه میگیرد و اصطکاکها را ثبت میکند. پیداکردن backup، بازسازی شبکه، گرفتن اعتبارنامه و اعتبارسنجی برنامه چقدر طول کشید؟ کدام مرحله به دستوری در تاریخچهٔ shell وابسته بود؟ پاسخها برنامهای کلی را به فهرستی مشخص از بهبودها تبدیل میکنند.
دسترسپذیری بالا همان بازیابی نیست¶
HA میتواند پس از خرابی میزبان، guest را روی node دیگری راهاندازی کند؛ اما همهٔ خرابیها را اصلاح نمیکند. دادهٔ خراب برنامه را سالم نمیکند، حذف تصادفی را برنمیگرداند و تضمین نمیکند پیکربندی معیوب پس از restart کار کند. storage مشترک و عضویت در کلاستر نیز وابستگیهای خودشان را اضافه میکنند.
به همین دلیل دسترسپذیری و بازیابیپذیری باید جداگانه طراحی شوند. HA وقفهٔ ناشی از گروهی از خرابیهای زیرساخت را کم میکند. پشتیبان، بازیابی آزموده و مراحل مستند بازسازی گروه دیگری را پوشش میدهند. یک سیستم میتواند یکی را داشته باشد و دیگری را نه.
پیچیدگی در محیطهای کوچک هزینه دارد. شاید بازیابی یک setup تکنودی ساده با پشتیبان مطمئن خارج از میزبان، از کلاستری که quorum، storage و رفتار شبکهاش خوب فهمیده نشده آسانتر باشد. وقتی حالتهای خرابی پذیرفتنی و دلیل روشنی برای قطعات متحرک بیشتر دارید، clustering را اضافه کنید.
موفقیت را پیش از رخداد تعریف کنید¶
بازیابی زمانی تمام شده که سرویس کار کند، نه وقتی VM بوت شود. اعتبارسنجی باید کارهای مهم را دربر بگیرد: ورود، خواندن و نوشتن داده، resolve نامها، دسترسی به وابستگیها و اجرای jobهای زمانبندیشده. لاگها را هم بررسی کنید؛ ممکن است سرویس ظاهراً کار کند اما کارهای پسزمینه پیوسته شکست بخورند.
دو هدف ساده برنامهریزی را دقیقتر میکنند:
- هدف نقطهٔ بازیابی (RPO): بیشترین میزان پذیرفتنی از دسترفتن داده.
- هدف زمان بازیابی (RTO): بیشترین زمان پذیرفتنی برای بازگرداندن سرویس.
لازم نیست این هدفها وعدههایی در اندازهٔ سازمانهای بزرگ باشند. حتی عددهای تقریبی هم تصمیمگیری دربارهٔ فاصلهٔ پشتیبانها، retention، سختافزار یدکی و میزان خودکارسازی بازسازی را جدیتر میکنند.
درس مفید¶
Proxmox ساختن و ادارهٔ ماشین مجازی را آسان میکند، اما درس مهم بالاتر از hypervisor قرار دارد: مجازیکردن سرور، سرویس آن را خودکار قابلبازیابی نمیکند.
اطمینان باید از شواهد بیاید. برنامه را پایش کنید، پشتیبانها را بیرون از مرز خرابی اصلی نگه دارید، پیکربندی لازم برای بازسازی را حفظ کنید و پیش از اضطراری شدن اوضاع بازیابی را تمرین کنید. هوملب جای ایدئالی برای این یادگیری است؛ چون میتوان خرابی را زمانبندی کرد و هر خرابی کنترلشده، سیستم واقعی را کمی قابلپیشبینیتر میکند.