تصویر کلی
Keepalived از VRRP برای مدیریت virtual router و انتقال Virtual IP میان چند node استفاده می‌کند.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
Priority و advertisement interval روی election اثر دارند و health tracking می‌تواند priority موثر را تغییر دهد.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
داشتن VIP به‌تنهایی HA کامل نیست؛ state برنامه، session، upstream route و failure detection باید جداگانه طراحی شوند.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی Keepalived نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
Virtual IP چه چیزی را جابه‌جا می‌کند؟
یک نشانی مجازی به کلاینت امکان می‌دهد مقصد ثابتی داشته باشد در حالی که مالک فعال آن میان گره‌ها تغییر می‌کند. این جابه‌جایی به خودی خود حافظه برنامه، فایل‌های باز یا نشست‌های TCP را منتقل نمی‌کند. اگر سرویس وضعیت‌دار است، طراحی داده و همگام‌سازی آن مسئله‌ای جداست. برای مثال دو وب‌سرور بدون داده محلی مشترک ساده‌تر از دو پایگاه داده مستقل‌اند. قبل از استقرار، مشخص کنید VIP فقط مسیر ورود است یا تیم به اشتباه از آن انتظار تکثیر داده دارد.
در آزمایش دو گره، روی هرکدام سرویس ساده‌ای اجرا کنید که نام گره پاسخ‌دهنده را نشان دهد. کلاینت فقط VIP را درخواست کند. سپس مالک فعال را در شرایط کنترل‌شده از دسترس خارج کنید و تغییر پاسخ را ثبت کنید. این آزمایش اصل جابه‌جایی مسیر را روشن می‌کند، اما هنوز درباره دوام نشست یا صحت داده چیزی نمی‌گوید. برای سرویس واقعی باید آزمون‌های مرتبط با همان قرارداد اضافه شوند.
نقش اعلان‌ها و انتخاب مالک
VRRP با اعلان‌های دوره‌ای به گره‌ها درباره حضور مالک فعال اطلاع می‌دهد. اولویت و وضعیت اعضا در انتخاب نقش اثر دارند. تنظیمات دو طرف باید از نظر شناسه نمونه، رابط و پارامترهای لازم سازگار باشند. یک نام مشابه در فایل‌ها کافی نیست؛ دامنه شبکه‌ای که اعلان‌ها در آن عبور می‌کنند باید درست باشد. اگر اعضا پیام یکدیگر را نمی‌بینند، هرکدام ممکن است نتیجه متفاوتی درباره مالکیت بگیرند.
برای عیب‌یابی، دریافت و ارسال اعلان را در همان رابط شبکه بررسی کنید. فایروال و محدودیت زیرساخت ممکن است ترافیک VRRP را متوقف کنند، حتی وقتی ping و اتصال TCP میان گره‌ها موفق‌اند. موفقیت یک پروتکل، عبور پروتکل دیگر را ثابت نمی‌کند. اگر از حالت unicast استفاده می‌کنید، فهرست peerها و نشانی مبدأ باید دقیق باشد. انتخاب multicast یا unicast باید با قابلیت شبکه و مستندات محیط هماهنگ شود.
Split brain و حد مشاهده هر گره
قطع ارتباط میان دو عضو با خاموش شدن یکی از آن‌ها یکسان نیست. در قطع ارتباط، هر دو ممکن است همچنان برای کلاینت‌ها قابل دسترس باشند و درباره مالکیت VIP تصمیم ناسازگار بگیرند. این وضعیت می‌تواند به پاسخ متناوب، اختلال ARP یا دو نویسنده فعال منجر شود. برای سرویس دارای داده، خطر فقط قطع کوتاه خدمت نیست؛ ناسازگاری داده نیز مطرح است. Keepalived به تنهایی جای سازوکار fencing و هماهنگی نویسنده برنامه را نمی‌گیرد.
آزمایش partition را از آزمایش خاموشی جدا کنید. در محیط غیرتولیدی، ارتباط اعلان میان اعضا را محدود کنید ولی مسیر کلاینت را نگه دارید و رفتار را مشاهده کنید. نتیجه باید نشان دهد طراحی شما در نبود دید مشترک چه می‌کند. اگر هر دو فعال می‌شوند، باید پیامد آن در لایه برنامه مهار شود یا معماری تغییر کند. نام HA روی طرح نباید این حالت را از بررسی حذف کند.
بررسی سلامت سرویس و اثر وزن
وجود رابط شبکه یا زنده بودن فرایند Keepalived به معنی آماده بودن برنامه نیست. track_script و سازوکارهای پیگیری می‌توانند سلامت وابستگی را در تصمیم نقش دخیل کنند، ولی معنای وزن و وضعیت خطا باید دقیق خوانده شود. یک تنظیم ظاهراً منطقی ممکن است فقط اولویت را کم کند و هنوز گره معیوب را برنده نگه دارد. نتیجه را با وضعیت واقعی نقش آزمایش کنید، نه فقط با خروج موفق اسکریپت.
اسکریپت سلامت باید کوتاه، محدود و قابل اعتماد باشد. اگر خودش مدت طولانی منتظر بماند یا منابع زیادی مصرف کند، تشخیص خرابی نامطمئن می‌شود. بررسی مناسب باید توان خدمت‌رسانی مورد نیاز را بسنجد، بدون آنکه هر بار عملیات سنگین یا نویسنده انجام دهد. با پاسخ ساختگی سالم و ناسالم، منطق خروج و اثر آن بر اولویت را بررسی کنید. مالکیت و مجوز فایل اسکریپت نیز مهم است؛ کاربری نامرتبط نباید بتواند کد اجراشده با اختیار سرویس را تغییر دهد.
ARP، همسایه‌ها و زمان دیده‌شدن تغییر
پس از تغییر مالک VIP، شبکه و کلاینت‌ها باید نگاشت نشانی را به مقصد تازه بشناسند. در IPv4، رفتار ARP و اعلان‌های مربوط و در IPv6، سازوکار همسایگی اهمیت دارند. ممکن است گره جدید VIP را داشته باشد ولی بعضی کلاینت‌ها هنوز نگاشت قبلی را نگه دارند. بنابراین زمان تغییر نقش در log با زمان بازگشت خدمت از دید همه کاربران یکی نیست. از چند نقطه نماینده شبکه آزمون بگیرید.
اگر بخشی از کلاینت‌ها دیرتر بازیابی می‌شوند، مسیر سوئیچ، تجهیزات امنیتی و سیاست نگه‌داری همسایه‌ها را بررسی کنید. افزایش تصادفی تعداد اعلان‌ها بدون شناخت محدودیت تجهیزات می‌تواند بی‌اثر باشد. در محیط ابری نیز داشتن IP روی رابط لزوماً مجوز استفاده از آن در شبکه ارائه‌دهنده را ایجاد نمی‌کند. طراحی VIP باید با مدل شبکه همان محیط سازگار باشد؛ برخی محیط‌ها به سازوکار اختصاصی مسیریابی یا جابه‌جایی نشانی نیاز دارند.
Preemption و بازگشت گره قبلی
وقتی گره با اولویت بالاتر پس از خرابی برمی‌گردد، باید تصمیم بگیرید آیا فوراً نقش فعال را پس بگیرد یا مالک فعلی باقی بماند. بازگشت فوری می‌تواند یک جابه‌جایی اضافی ایجاد کند، در حالی که باقی ماندن روی گره فعلی ممکن است با سیاست ظرفیت شما ناسازگار باشد. گزینه‌های preemption و شرایط لازم آن‌ها را مطابق مستندات بررسی کنید و رفتار واقعی را با restart آزمایش کنید. نام گزینه به تنهایی همه شرط‌های آن را توضیح نمی‌دهد.
برای سرویس حساس، زمان گرم‌شدن برنامه و همگام‌شدن داده را پیش از پذیرش نقش لحاظ کنید. بالا آمدن سیستم‌عامل به معنی آماده بودن سرویس نیست. health check باید مانع پذیرش زودهنگام ترافیک شود. در آزمون، گره قبلی را برگردانید و تا پایان آماده‌شدن برنامه مسیر کلاینت را مشاهده کنید. اگر درخواست‌ها پیش از آمادگی به آن هدایت می‌شوند، مشکل در قرارداد readiness و انتخاب نقش است.
نشست‌های موجود و داده برنامه
یک درخواست کوتاه ممکن است پس از جابه‌جایی با retry موفق شود، اما اتصال طولانی رفتار متفاوتی دارد. WebSocket، انتقال فایل یا نشست پایگاه داده را جدا آزمایش کنید. کلاینت باید بتواند قطع اتصال را تشخیص دهد و طبق قرارداد دوباره وصل شود. اگر عملیات نویسنده در لحظه قطع انجام شده باشد، retry ممکن است اثر تکراری بسازد. شناسه یکتای عملیات و منطق idempotency در برنامه برای این مسئله اهمیت دارد.
اگر دو گره به داده محلی متفاوت متصل‌اند، جابه‌جایی VIP ممکن است کاربر را به نسخه قدیمی اطلاعات ببرد. قبل از اعلام HA، راه تکثیر، سازگاری و انتخاب نویسنده داده را مشخص کنید. VIP فقط نقطه ورود ثابت می‌دهد. در گزارش تمرین، علاوه بر زمان اتصال، صحت پاسخ و نسخه داده را ثبت کنید. این روش تفاوت «شبکه برگشت» و «خدمت درست برگشت» را آشکار می‌کند.
دستورالعمل نگه‌داری و مشاهده‌پذیری
برای خارج کردن برنامه‌ریزی‌شده یک گره، روش کاهش نقش یا انتقال را از پیش تمرین کنید. خاموش کردن ناگهانی همیشه بهترین روش نگه‌داری نیست. پس از انتقال، مالکیت VIP، سلامت سرویس و وضعیت عضو باقی‌مانده را تأیید کنید. تغییر هم‌زمان هر دو عضو خطر از دست رفتن مسیر بازگشت را بالا می‌برد. نسخه پیکربندی هر گره باید مشخص باشد تا اختلاف ناخواسته دیده شود.
هشدارها باید تغییر نقش غیرمنتظره، نوسان مکرر و نبود مالک قابل استفاده را پوشش دهند. صرف زنده بودن daemon کافی نیست. زمان تغییر نقش را با رخدادهای شبکه و سلامت برنامه مرتبط کنید تا علت failover مشخص شود. گزارش خوب توضیح می‌دهد چه چیزی شکست خورده، کدام عضو تصمیم گرفته و کلاینت چه زمانی خدمت درست گرفته است. همین سه لایه پایه یک دستورالعمل قابل استفاده در حادثه واقعی‌اند.
شناسه نمونه و همسایگی شبکه
وقتی چند جفت Keepalived در یک بخش شبکه دارید، شناسه نمونه‌ها را با طرح کلی هماهنگ کنید تا گروه‌های مستقل ناخواسته اعلان یکدیگر را تفسیر نکنند. فهرست VIPها، اعضا و شناسه‌ها باید در یک مرجع عملیاتی قابل جست‌وجو باشد. افزودن جفت تازه با کپی مستقیم فایل قدیمی بدون اصلاح این مشخصات می‌تواند اختلالی بسازد که در آزمایش تک‌گرهی دیده نمی‌شود. پیش از اتصال به شبکه مشترک، تنظیمات را با inventory مقایسه کنید و سپس وجود تنها مالک مورد انتظار را از دید شبکه بررسی کنید. این کنترل ساده برای جلوگیری از تداخل میان سرویس‌های مستقل اهمیت زیادی دارد.
