عیب‌یابی Down شدن Pool Member در F5؛ از Monitor تا لاگ ltm

Down شدن Pool Member در F5 BIG-IP یکی از خطاهایی است که ظاهر ساده‌ای دارد اما علت‌های زیادی پشت آن می‌تواند باشد. گاهی واقعاً سرویس Backend قطع است، گاهی Health Monitor درست طراحی نشده، گاهی مسیر برگشت ترافیک مشکل دارد، و گاهی هم SSL یا Firewall باعث می‌شود F5 نتواند پاسخ سالم بگیرد.

برای عیب‌یابی درست، نباید از همان ابتدا سراغ حدس‌های پراکنده رفت. مسیر بهتر این است که وضعیت Node، Pool Member، Monitor، شبکه و لاگ‌ها را مرحله‌به‌مرحله بررسی کنیم.

۱. اول دلیل Down بودن را از خود F5 بخوانید

در GUI معمولاً کنار Pool Member توضیح کوتاهی دیده می‌شود، اما برای بررسی دقیق‌تر از tmsh استفاده کنید:

tmsh show ltm pool /Common/example_pool members
tmsh show ltm node /Common/10.10.10.20
tmsh show ltm virtual /Common/example_vs

اگر Pool Member با پیام‌هایی مثل Monitor failed یا No successful responses دیده می‌شود، مسیر بررسی با زمانی که Node disabled یا address unreachable است فرق دارد.

۲. Monitor را با واقعیت سرویس هماهنگ کنید

Health Monitor قرار نیست فقط پورت را چک کند؛ باید سلامت واقعی سرویس را نشان دهد. برای یک سرویس وب، TCP Monitor ممکن است سبز باشد اما اپلیکیشن خطای ۵۰۰ بدهد. برعکس، یک HTTP Monitor بدطراحی‌شده ممکن است سرور سالم را Down کند.

چند مورد مهم در Monitor:

• پورت Monitor با پورت واقعی سرویس هماهنگ باشد.
• Send String و Receive String با پاسخ واقعی اپلیکیشن بخواند.
• Timeout و Interval خیلی تهاجمی تنظیم نشده باشد.
• برای HTTPS، نیاز به Host Header یا SNI بررسی شده باشد.
• اگر صفحه Login یا Redirect دارید، Monitor با آن سازگار باشد.

برای طراحی پایه، مطلب طراحی Health Monitor در F5 BIG-IP توضیح کامل‌تری دارد.

۳. از خود F5 به Backend تست بگیرید

اگر از لپ‌تاپ خودتان به Backend وصل می‌شوید، الزاماً همان مسیر F5 را تست نکرده‌اید. تست باید از خود F5 یا حداقل از همان Segment شبکه انجام شود.

curl -vk https://10.10.10.20/health
curl -v http://10.10.10.20:8080/
ping 10.10.10.20
traceroute 10.10.10.20

اگر اتصال از F5 به سرور برقرار نیست، باید Route، VLAN، Self IP، Firewall و ACL را بررسی کنید.

۴. SNAT و مسیر برگشت را فراموش نکنید

یکی از علت‌های پنهان خطا در F5، مسیر برگشت ترافیک است. اگر سرور Backend پاسخ را به جای برگشت از مسیر F5 از Gateway دیگری بفرستد، ارتباط کاربر خراب می‌شود. در این حالت ممکن است Monitor سالم باشد اما ترافیک واقعی مشکل داشته باشد، یا برعکس.

در طراحی‌هایی که سرورها Default Gateway متفاوت دارند، SNAT Automap یا SNAT Pool ممکن است لازم باشد. البته SNAT هم باید آگاهانه استفاده شود، چون دیدن IP واقعی کاربر در Backend را تغییر می‌دهد.

۵. لاگ ltm را بخوانید

فایل /var/log/ltm برای بسیاری از خطاهای Monitor، SSL، ارتباط Pool و تغییر وضعیت آبجکت‌ها سرنخ می‌دهد.

tail -f /var/log/ltm
grep -i "example_pool" /var/log/ltm
grep -i "monitor" /var/log/ltm

اگر خطاهای SSL Handshake، Timeout، Connection refused یا No route می‌بینید، مسیر عیب‌یابی روشن‌تر می‌شود.

۶. تفاوت مشکل Monitor و مشکل ترافیک واقعی

گاهی Monitor Down است اما ترافیک واقعی اگر ارسال شود کار می‌کند. این معمولاً یعنی Monitor بد طراحی شده است. گاهی هم Monitor Up است اما کاربران خطا می‌گیرند؛ این یعنی Monitor فقط زنده بودن سطحی سرویس را می‌بیند و سلامت واقعی اپلیکیشن را نمی‌سنجد.

برای سرویس‌های حساس، Monitor باید چیزی را بررسی کند که به تجربه کاربر نزدیک‌تر است، نه فقط باز بودن پورت.

۷. SSL سمت Backend را جداگانه بررسی کنید

اگر Pool Member روی HTTPS کار می‌کند، Server SSL Profile و نیازهای TLS سرور را بررسی کنید. ممکن است سرور به SNI نیاز داشته باشد، Certificate داخلی داشته باشد، یا Cipherهای قدیمی/جدید با تنظیمات F5 سازگار نباشد.

جزئیات این موضوع را در مطلب طراحی SSL Profile در F5 BIG-IP توضیح داده‌ام.

جمع‌بندی

وقتی Pool Member در F5 Down می‌شود، بهترین کار این است که از خود F5 شروع کنید: دلیل وضعیت را بخوانید، Monitor را با واقعیت سرویس مقایسه کنید، مسیر شبکه و SNAT را بررسی کنید، لاگ ltm را ببینید و SSL سمت Backend را جداگانه تست کنید. این مسیر جلوی حدس‌زدن‌های طولانی و تغییرهای پرریسک را می‌گیرد.

اگر F5 شما در مسیر سرویس‌های سازمانی است و Down شدن Pool، خطای Monitor یا رفتار ناپایدار Load Balancing تکرار می‌شود، صفحه طراحی و پیاده‌سازی F5 BIG-IP Load Balancer برای بررسی عملی معماری و تنظیمات مرتبط است.