Persistence در F5 BIG-IP؛ چه زمانی Cookie، Source Address یا روش دیگر لازم است؟

در F5 BIG-IP، Persistence یعنی لودبالانسر بعد از اولین انتخاب backend، درخواست‌های بعدی همان کاربر یا همان نشست را تا مدتی به همان Pool Member هدایت کند. این قابلیت برای بعضی سامانه‌ها حیاتی است؛ مثلا وقتی session در خود application server نگهداری می‌شود و جابه‌جایی کاربر بین سرورها باعث logout، خطای سبد خرید، خطای پرداخت یا رفتار نامنظم پنل می‌شود.

اما Persistence راه‌حل پیش‌فرض همه سرویس‌ها نیست. اگر بدون دلیل فعال شود، توزیع بار را خراب می‌کند، یک سرور را شلوغ‌تر از بقیه نگه می‌دارد و عیب‌یابی را سخت‌تر می‌کند. تصمیم درست این است که اول رفتار application روشن شود، بعد نوع persistence انتخاب شود.

چه زمانی Persistence لازم است؟

وقتی برنامه stateful است و session بین سرورها share نشده، Cookie Persistence یا روش مشابه می‌تواند منطقی باشد. اگر برنامه پشت NAT سنگین کاربران قرار دارد، Source Address Persistence ممکن است تعداد زیادی کاربر را به یک member بچسباند و توازن بار را به هم بزند. در سرویس‌های stateless یا جایی که session در Redis، database یا لایه مشترک نگهداری می‌شود، گاهی اصلا Persistence لازم نیست.

انتخاب بین Cookie و Source Address

Cookie Persistence برای وب‌اپلیکیشن‌ها معمولا دقیق‌تر است، چون تصمیم را به نشست مرورگر نزدیک‌تر می‌کند. Source Address ساده‌تر است، اما در شبکه‌هایی که کاربران پشت یک IP عمومی یا پراکسی مشترک می‌آیند، نتیجه آن همیشه قابل اعتماد نیست. برای سرویس‌های غیر HTTP هم باید روش متناسب با پروتکل و رفتار client بررسی شود.

قبل از فعال‌سازی چه چیزهایی را چک کنیم؟

• نوع session برنامه: session روی سرور محلی است یا shared شده؟
• مسیر NAT کاربران: آیا کاربران زیادی با یک IP دیده می‌شوند؟
• مدت timeout: timeout طولانی می‌تواند یک member را بی‌دلیل شلوغ نگه دارد.
• اثر روی failover: اگر member از دسترس خارج شود، رفتار کاربر باید قابل پیش‌بینی باشد.
• هماهنگی با OneConnect و HTTP profile: در بعضی سناریوها ترکیب پروفایل‌ها روی نتیجه اثر دارد.

چند دستور برای بررسی

tmsh list ltm persistence cookie /Common/app_cookie_persist
tmsh list ltm persistence source-addr /Common/app_srcaddr_persist
tmsh list ltm virtual /Common/app_vs persist

این دستورها فقط برای مشاهده وضعیت هستند. قبل از تغییر، خروجی فعلی Virtual Server و Profileها را نگه دارید و تغییر را در پنجره قابل برگشت انجام دهید.

خطاهای رایج

رایج‌ترین خطا این است که برای حل یک مشکل application، Persistence را زیاد و طولانی کنیم. اگر backend کند است، session طراحی نشده یا health check سطحی است، Persistence فقط نشانه‌ها را پنهان می‌کند. خطای دوم استفاده از Source Address در محیطی است که کاربرها پشت NAT مشترک هستند؛ در این حالت ممکن است بخش بزرگی از ترافیک روی یک member جمع شود.

منابع رسمی

برای جزئیات فنی، مستندات رسمی F5 درباره Session Persistence Profiles مرجع اصلی است.