طراحی درست Health Monitor و Persistence در F5 BIG-IP

وقتی F5 BIG-IP را فقط به چشم یک لودبالانسر ساده ببینیم، معمولاً طراحی در همان چند pool و virtual server خلاصه می‌شود. اما در عمل، پایداری سرویس بیشتر از هر چیز به چند تصمیم کوچک بستگی دارد: health monitor درست، انتخاب persistence مناسب، SSL profile تمیز، و اینکه بدانیم در زمان خطا دقیقاً از کجا باید شروع کنیم.

این نوشته قرار نیست آموزش کلیک‌به‌کلیک F5 باشد. بیشتر یک چک‌لیست فنی است برای زمانی که می‌خواهیم یک سرویس وب را پشت F5 BIG-IP LTM قرار بدهیم و بعداً درگیر قطعی‌های مبهم، sessionهای گم‌شده یا pool memberهایی که ظاهراً up هستند ولی سرویس واقعی کار نمی‌کند نشویم.

اشتباه رایج: مانیتور سطح پایین برای سرویس سطح بالا

خیلی وقت‌ها برای یک وب‌سرویس، فقط یک TCP monitor ساده می‌گذارند. نتیجه این می‌شود که F5 پورت ۴۴۳ یا ۸۰ را باز می‌بیند و member را up نگه می‌دارد، در حالی که اپلیکیشن پشت آن ممکن است خطای ۵۰۰ بدهد، صفحه login بالا نیاید، یا backend به دیتابیس وصل نباشد.

برای سرویس‌های HTTP/HTTPS بهتر است health monitor حداقل یک URL واقعی را تست کند؛ نه الزاماً سنگین‌ترین صفحه، ولی چیزی که معنی‌دار باشد. مثلاً:

GET /health HTTP/1.1rnHost: app.example.comrnConnection: Closernrn

اگر اپلیکیشن endpoint مخصوص health ندارد، بهتر است با تیم نرم‌افزار هماهنگ شود و یک endpoint سبک ساخته شود. این endpoint نباید فقط وب‌سرور را چک کند؛ باید حداقل وابستگی‌های اصلی سرویس را هم در حد قابل قبول بررسی کند.

Receive string را جدی بگیرید

در مانیتورهای HTTP/HTTPS، فقط ارسال request کافی نیست. بهتر است response هم بررسی شود. مثلاً اگر صفحه health باید عبارت OK یا status مشخصی برگرداند، همان را در receive string بگذاریم. این کار جلوی خیلی از false positiveها را می‌گیرد.

Send String:    GET /health HTTP/1.1rnHost: app.example.comrnConnection: Closernrn
Receive String: OK

اگر برنامه گاهی redirect می‌دهد، صفحه maintenance دارد، یا خروجی health آن دقیق نیست، باید همان ابتدا مشخص شود. وگرنه روز حادثه F5 را متهم می‌کنیم، در حالی که monitor از اول درست طراحی نشده بوده.

Persistence؛ همیشه راه‌حل نیست

برای بعضی سرویس‌ها persistence لازم است، برای بعضی‌ها نه. مشکل از جایی شروع می‌شود که برای هر سرویس، بدون فکر کردن، source address persistence می‌گذاریم. پشت NAT یا proxy، تعداد زیادی کاربر ممکن است با یک IP دیده شوند و همین باعث می‌شود load balancing عملاً به چند member محدود شود.

برای انتخاب persistence باید اول بفهمیم state برنامه کجاست:

• اگر session در خود اپلیکیشن و روی همان سرور نگه‌داری می‌شود، persistence احتمالاً لازم است.
• اگر session در Redis، دیتابیس یا shared store است، شاید persistence لازم نباشد.
• اگر ترافیک از پشت NAT بزرگ می‌آید، source address affinity می‌تواند توزیع بار را خراب کند.
• برای سرویس‌های HTTPS، cookie persistence یا SSL persistence باید با دقت و بر اساس رفتار اپلیکیشن انتخاب شود.

SSL offload؛ تمیز و قابل نگهداری

یکی از کاربردهای مهم F5، terminate کردن TLS روی خود BIG-IP است. این کار هم performance و هم مدیریت certificate را بهتر می‌کند، ولی فقط وقتی که profileها تمیز طراحی شده باشند.

برای SSL profile بهتر است چند چیز روشن باشد:

• certificate و chain کامل و درست نصب شده باشد.
• نسخه‌های قدیمی TLS و cipherهای ضعیف حذف شده باشند.
• اگر backend هم HTTPS است، server SSL profile جداگانه و درست تنظیم شود.
• SNI، چند دامنه و wildcard certificate بدون مستندات رها نشوند.

در محیط‌هایی که سرویس‌های زیادی پشت F5 هستند، نام‌گذاری profileها خیلی مهم است. اسم‌هایی مثل clientssl_prod_app1_2026 شاید ساده به نظر برسند، ولی چند ماه بعد در زمان troubleshooting واقعاً کمک می‌کنند.

Load balancing method را بر اساس رفتار سرویس انتخاب کنید

روش پیش‌فرض برای همه‌چیز جواب ایده‌آل نیست. Round Robin ساده است، ولی برای memberهایی که ظرفیت متفاوت دارند یا requestها هم‌وزن نیستند، همیشه بهترین انتخاب نیست.

• Round Robin: ساده و قابل پیش‌بینی، مناسب سرویس‌های تقریباً هم‌ظرفیت.
• Least Connections: برای سرویس‌هایی که طول connectionها متفاوت است، معمولاً منطقی‌تر است.
• Ratio: وقتی memberها ظرفیت متفاوت دارند و می‌خواهیم وزن بدهیم.

قبل از تغییر method، بهتر است رفتار واقعی connectionها و response time بررسی شود. تغییر بدون مشاهده، بیشتر شبیه حدس زدن است تا مهندسی.

چک‌لیست قبل از تحویل سرویس روی F5

• Virtual Server با IP/Port درست و route برگشت بررسی شده باشد.
• Pool memberها با monitor مناسب و receive string واقعی چک شوند.
• SSL profileها، certificate chain و TLS policy بررسی شده باشند.
• Persistence فقط در صورت نیاز فعال شده باشد.
• SNAT/Auto Map یا طراحی route برگشت آگاهانه انتخاب شده باشد.
• لاگ و مانیتورینگ برای خطاهای 4xx/5xx و resetها در دسترس باشد.
• سناریوی خارج شدن یک member از سرویس تست شده باشد.
• مستندات شامل virtual server، pool، monitor، profile و owner سرویس نوشته شده باشد.

عیب‌یابی سریع وقتی سرویس پشت F5 مشکل دارد

برای troubleshooting بهتر است از مسیر ساده شروع کنیم:

tmsh show ltm virtual /Common/vs_app
 tmsh show ltm pool /Common/pool_app members
 tmsh show ltm monitor
 tmsh show sys connection cs-server-addr <client-ip>

اگر memberها up هستند ولی کاربر خطا می‌گیرد، مانیتور را دوباره بررسی کنید. اگر فقط بخشی از کاربران مشکل دارند، persistence و NAT مسیر را ببینید. اگر SSL خطا می‌دهد، certificate chain، SNI و client/server SSL profile را جدا بررسی کنید.

F5 فقط Load Balancer نیست

در طراحی درست، F5 نقطه‌ای است که می‌تواند دید خوبی از وضعیت سرویس بدهد: health، ترافیک، session، SSL، خطاها و گاهی حتی رفتار برنامه. برای همین در کنار فایروال‌هایی مثل فورتیگیت، Cisco Firepower و راهکارهای WAF مثل FortiWeb، نقش F5 در پایداری سرویس‌های دیتاسنتری جدی است.

اگر این بخش خوب طراحی شود، هم قطعی کمتر می‌شود، هم زمان عیب‌یابی پایین می‌آید. اگر بد طراحی شود، F5 خودش تبدیل به جایی می‌شود که همه موقع حادثه به آن شک می‌کنند.