طراحی Health Monitor درست در F5 BIG-IP؛ فقط TCP کافی نیست

پاسخ کوتاه: Health Monitor در F5 BIG-IP نباید فقط باز بودن یک پورت را چک کند. مانیتور خوب باید همان رفتاری را بسنجد که برای کاربر مهم است: پاسخ درست HTTP، سلامت سرویس پشت Pool، وضعیت SSL، زمان پاسخ و تفاوت بین خطای واقعی و کندی موقت.

در طراحی لودبالانسر، خیلی وقت‌ها همه توجه روی Virtual Server و Pool می‌رود، اما تصمیم نهایی برای خارج کردن یک سرور از مسیر ترافیک را Health Monitor می‌گیرد. اگر این بخش ساده یا اشتباه طراحی شود، F5 می‌تواند ترافیک را به سروری بفرستد که از بیرون «زنده» دیده می‌شود اما برنامه واقعی روی آن درست کار نمی‌کند.

Health Monitor در F5 دقیقاً چه کاری انجام می‌دهد؟

Health Monitor وضعیت Pool Memberها را بررسی می‌کند و به F5 می‌گوید کدام عضو آماده دریافت ترافیک است. این بررسی می‌تواند ساده باشد، مثل TCP Monitor، یا دقیق‌تر باشد، مثل HTTP/HTTPS Monitor با send string و receive string. تفاوت این دو در محیط production مهم است؛ چون باز بودن پورت 443 الزاماً به معنی سالم بودن سرویس نیست.

چه زمانی TCP Monitor کافی نیست؟

TCP Monitor فقط می‌فهمد اتصال شبکه برقرار می‌شود یا نه. اگر وب‌سرور پاسخ 500 بدهد، صفحه login خراب باشد، backend به دیتابیس وصل نشود یا اپلیکیشن فقط یک صفحه خطا برگرداند، TCP Monitor ممکن است همچنان سرور را up نشان دهد. برای سرویس‌های وب، معمولاً باید HTTP یا HTTPS Monitor با مسیر مشخص و پاسخ قابل انتظار تعریف شود.

چک‌لیست طراحی Monitor برای سرویس‌های وب

• مسیر health check را از مسیرهای سنگین و وابسته به کاربر جدا کنید.
• در HTTP Monitor فقط status code را نبینید؛ یک متن کوتاه و ثابت در پاسخ هم بررسی کنید.
• اگر SSL روی backend فعال است، تفاوت SSL profile و certificate chain را در تست‌ها ببینید.
• Interval و Timeout را طوری تنظیم کنید که قطعی واقعی را سریع تشخیص دهد، اما با یک کندی کوتاه سرور را بی‌دلیل down نکند.
• برای سرویس‌هایی که چند Node مشابه دارند، پاسخ health check باید بین همه آن‌ها یکسان و قابل مقایسه باشد.
• بعد از هر تغییر، رفتار Monitor را در حالت سالم، کند و خراب جداگانه تست کنید.

نمونه خطاهای رایج در F5 Health Monitor

• استفاده همیشگی از TCP: برای وب‌اپلیکیشن‌ها معمولاً کافی نیست و خطای برنامه را پنهان می‌کند.
• چک کردن صفحه اصلی سایت: صفحه اصلی ممکن است کش شود یا به سرویس‌های جانبی وابسته باشد؛ بهتر است مسیر سبک و مشخص داشته باشید.
• Timeout خیلی کوتاه: در زمان load بالا، عضو سالم به اشتباه down می‌شود و ترافیک بین Nodeها نوسان می‌کند.
• یکسان نبودن پاسخ backendها: اگر یک Node متن یا کد متفاوت برگرداند، مانیتور رفتار ناپایدار پیدا می‌کند.
• نداشتن برنامه rollback: تغییر Monitor روی Pool فعال می‌تواند مستقیم روی کاربران اثر بگذارد.

ارتباط Health Monitor با Persistence چیست؟

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

روش عملی بررسی قبل از تغییر production

قبل از تغییر Monitor روی Pool فعال، یک Pool تست یا یک بازه کم‌ریسک انتخاب کنید. اول پاسخ health endpoint را مستقیم از خود F5 یا از مسیر مشابه تست کنید. سپس Monitor را با interval محافظه‌کارانه فعال کنید و لاگ وضعیت عضوها را چند دقیقه زیر نظر بگیرید. اگر تغییر باعث flapping شد، یعنی یکی از شرط‌ها یا زمان‌بندی‌ها بیش از حد سخت‌گیرانه است.

جمع‌بندی عملی

Health Monitor خوب در F5 BIG-IP باید به زبان همان سرویس حرف بزند. برای وب‌اپلیکیشن، صرفاً باز بودن پورت کافی نیست؛ باید پاسخ درست برنامه دیده شود. اگر قصد طراحی یا بازبینی ساختار لودبالانسر را دارید، صفحه F5 Load Balancer و BIG-IP و راهنمای Persistence در F5 را هم کنار این مطلب بخوانید. برای اجرای پروژه‌ای و تغییرات حساس، صفحه پیاده‌سازی F5 BIG-IP Load Balancer مسیر خدماتی مرتبط است.

نویسنده: علیرضا عربیان، فعال در حوزه شبکه، امنیت شبکه و طراحی سرویس‌های عملیاتی روی F5 BIG-IP، FortiGate، FortiWeb، Juniper و Cisco.