F5 BIG-IP معمولا وقتی دردسرساز میشود که چند سال تغییر روی آن جمع شده باشد: Virtual Serverهایی که مالک مشخص ندارند، Poolهایی که Monitor دقیق ندارند، SSL Profileهایی که با استاندارد امروز نمیخوانند، Persistenceهایی که از قبل ماندهاند و SNATهایی که مسیر واقعی کاربر را در لاگ پنهان میکنند. بازبینی کانفیگ یعنی قبل از تغییر بعدی، این وضعیت را قابل فهم و قابل دفاع کنیم.
در بازبینی F5 BIG-IP چه چیزهایی باید دیده شود؟
بازبینی درست فقط نگاه کردن به لیست Virtual Serverها نیست. باید ارتباط Virtual Server، Pool، Node، Health Monitor، Persistence، SNAT، Client SSL، Server SSL، iRule، Profileها، Route، VLAN، Self IP، HA و لاگ کنار هم بررسی شود. گاهی مشکل از یک Monitor ساده شروع میشود، اما اثرش در Session کاربر، خطای TLS یا Down شدن یک سرویس حساس دیده میشود.
در محیط عملیاتی، هر پیشنهاد تغییر باید دلیل، اثر احتمالی، روش تست و مسیر Rollback داشته باشد. F5 روی مسیر سرویسهای مهم قرار میگیرد و تغییر بدون نقشه میتواند از یک خطای کوچک، قطعی جدی بسازد.
نشانههایی که میگویند کانفیگ F5 نیاز به بازبینی دارد
- Virtual Serverهایی که نامگذاری یا توضیح روشن ندارند.
- Pool Memberهایی که گاهی Down میشوند ولی دلیل دقیق ثبت نشده است.
- Health Monitorهایی که فقط TCP هستند و سلامت واقعی اپلیکیشن را نمیسنجند.
- Persistenceهایی که بدون دلیل روشن فعال ماندهاند.
- SNAT یا Auto Map که باعث گم شدن IP واقعی کاربر در لاگ شده است.
- SSL Profileهایی که Certificate، Cipher، SNI یا Re-encryption آنها قدیمی یا مبهم است.
- iRuleهایی که کسی نمیداند دقیقا چه تغییری در مسیر درخواست ایجاد میکنند.
ترتیب امن برای بررسی و اصلاح
اول باید سرویسهای حساس و مسیر واقعی ترافیک مشخص شود. بعد برای هر Virtual Server، وابستگیها ثبت میشود: Pool، Node، Monitor، Profileها، Persistence، SNAT، SSL، iRule و مسیر برگشت. بعد از این مرحله میتوان موارد پرریسک را جدا کرد: سرویسهای بدون Monitor مناسب، Profileهای ناسازگار، تنظیمات قدیمی TLS، Persistence اشتباه یا SNATهای غیرضروری.
اصلاح باید مرحلهای باشد. برای بعضی موارد، اول فقط لاگ و مشاهده کافی است. برای بعضیها باید در پنجره تغییر، تست قبل و بعد انجام شود. در سرویسهای حساس، بهتر است قبل از تغییر UCS Backup، خروجی tmsh و برنامه برگشت آماده باشد.
ارتباط این بازبینی با مقالات دیگر F5
اگر مسئله شما سلامت سرویس است، از طراحی Health Monitor در F5 BIG-IP شروع کنید. اگر مشکل قطع شدن Session یا پخش نامناسب ترافیک دارید، طراحی Persistence در F5 BIG-IP مسیر دقیقتری میدهد. اگر IP واقعی کاربر در لاگ گم میشود یا مسیر برگشت ترافیک مشکل دارد، مطلب SNAT و Auto Map در F5 BIG-IP مرتبطتر است.
برای تغییرات عملیاتی، چکلیست تغییر روی F5 BIG-IP در Production باید کنار این بازبینی دیده شود. اگر هدف شما اجرای کامل یا بازطراحی است، صفحه طراحی و پیادهسازی F5 BIG-IP Load Balancer مسیر خدماتی را توضیح میدهد.
خروجی قابل استفاده برای تیم فنی
خروجی خوب باید فهرست قابل اجرا بدهد: سرویسهای حساس، Virtual Serverهای پرریسک، Poolهای نیازمند Monitor بهتر، Profileهای قدیمی، Persistenceهای قابل حذف یا اصلاح، SNATهای مبهم، iRuleهای نیازمند مستندسازی، ریسکهای TLS و پیشنهاد تغییر مرحلهای. کنار هر مورد باید اثر احتمالی روی سرویس و روش تست نوشته شود.
هدف از بازبینی این نیست که کانفیگ فقط تمیزتر دیده شود. هدف این است که F5 بعد از چند ماه دوباره به یک جعبه مبهم تبدیل نشود و تیم فنی بداند هر سرویس چرا اینطور طراحی شده، چه چیزی باید مانیتور شود و تغییر بعدی از کجا شروع شود.
