Persistence در F5 چیست و چه زمانی Source Address یا Cookie بهتر است؟

پاسخ کوتاه: Persistence در F5 BIG-IP برای نگه داشتن کاربر روی همان عضو Pool استفاده می‌شود. اگر برنامه به session سمت سرور وابسته باشد، نبودن Persistence می‌تواند باعث logout، خطای سبد خرید، خطای فرم یا رفتار ناپایدار کاربر شود.

Load Balancing فقط تقسیم ترافیک نیست. در خیلی از سرویس‌های واقعی، باید بدانیم آیا هر درخواست می‌تواند به هر سروری برود یا کاربر بعد از اتصال اول باید به همان backend برگردد. اینجاست که Persistence در F5 مهم می‌شود.

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

وقتی یک کاربر به Virtual Server وصل می‌شود، F5 بر اساس روش load balancing یک عضو از Pool را انتخاب می‌کند. Persistence باعث می‌شود درخواست‌های بعدی همان کاربر، تا زمان اعتبار رکورد persistence، دوباره به همان عضو Pool هدایت شود.

چه زمانی به Persistence نیاز داریم؟

• برنامه session را روی خود application server نگه می‌دارد.
• کاربر بعد از ورود، در درخواست‌های بعدی logout می‌شود یا خطای session می‌گیرد.
• سبد خرید، فرم چندمرحله‌ای یا پنل کاربری رفتار ناپایدار دارد.
• backendها از نظر داده session کاملاً یکسان یا sync نیستند.
• در زمان تست، Refresh یا درخواست بعدی به سرور دیگری می‌رود و نتیجه فرق می‌کند.

Source Address Persistence چیست؟

در Source Address Persistence، F5 آدرس IP کلاینت را مبنا قرار می‌دهد. اگر همان IP دوباره وصل شود، به همان عضو Pool فرستاده می‌شود. این روش ساده و سریع است، اما همیشه دقیق نیست.

مشکل اصلی زمانی دیده می‌شود که کاربران پشت NAT، Proxy، اینترنت سازمانی یا اپراتور موبایل باشند. در این حالت ممکن است کاربران زیادی با یک IP دیده شوند و همه به یک سرور بچسبند. نتیجه می‌تواند توزیع نامتوازن بار و فشار غیرعادی روی یک backend باشد.

Cookie Persistence چیست؟

در Cookie Persistence، F5 برای سرویس‌های HTTP/HTTPS از cookie استفاده می‌کند تا کاربر را در درخواست‌های بعدی تشخیص دهد. برای وب‌اپلیکیشن‌ها این روش معمولاً دقیق‌تر از Source Address است، چون به جای IP مشترک، مرورگر کاربر مبنا قرار می‌گیرد.

کدام روش بهتر است؟

جواب قطعی بدون شناخت برنامه وجود ندارد، اما یک قاعده عملی داریم: برای سرویس وب، اول Cookie Persistence را بررسی کنید. برای سرویس‌هایی که HTTP نیستند یا cookie معنی ندارد، Source Address یا روش‌های دیگر می‌توانند گزینه باشند. اگر کاربران زیادی پشت NAT هستند، Source Address را با احتیاط انتخاب کنید.

چک‌لیست سریع قبل از فعال کردن Persistence

• مشخص کنید برنامه واقعاً به session affinity نیاز دارد یا نه.
• نوع ترافیک را بررسی کنید: HTTP/HTTPS است یا پروتکل دیگر؟
• وضعیت NAT یا Proxy کاربران را در نظر بگیرید.
• Timeout رکورد persistence را متناسب با رفتار برنامه تنظیم کنید.
• بعد از تغییر، توزیع اتصال‌ها روی اعضای Pool را بررسی کنید.
• با تیم برنامه هماهنگ کنید که session سمت سرور ذخیره می‌شود یا در لایه مشترک.

روش بررسی بعد از تغییر

بعد از فعال کردن Persistence، فقط باز شدن صفحه کافی نیست. باید چند کاربر تستی را وارد برنامه کنید، چند مرحله واقعی مثل login، ثبت فرم یا حرکت بین صفحات را انجام دهید و همزمان روی F5 ببینید ترافیک هر کاربر به کدام Pool Member می‌رود. اگر همه کاربران به یک عضو چسبیده‌اند، Source Address یا Timeout را دوباره بررسی کنید.

اشتباهات رایج در Persistence

• فعال کردن Persistence برای همه سرویس‌ها: بعضی برنامه‌ها stateless هستند و نیازی به چسبندگی ندارند.
• انتخاب Source Address پشت NAT: این کار می‌تواند load balancing را عملاً بی‌اثر کند.
• Timeout خیلی طولانی: کاربرها مدت زیادی روی یک backend می‌مانند و توزیع بار کند اصلاح می‌شود.
• نادیده گرفتن Health Monitor: Persistence جای monitor درست را نمی‌گیرد. اگر backend سالم نیست، باید از Pool خارج شود.

ارتباط Persistence با Health Monitor

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

مطالب و خدمات مرتبط

• آموزش و مفاهیم F5 Load Balancer
• طراحی و پیاده‌سازی F5 BIG-IP Load Balancer
• طراحی Health Monitor درست در F5 BIG-IP
• چرا به امنیت شبکه نیاز داریم؟
• درباره علیرضا عربیان

Glossary کوتاه

• Virtual Server: نقطه ورود سرویس در F5 که کاربران به آن وصل می‌شوند.
• Pool Member: سرور یا سرویس backend که ترافیک به آن ارسال می‌شود.
• Persistence Record: رکوردی که نگه می‌دارد یک کاربر باید به کدام backend برگردد.
• Session Affinity: وابسته ماندن درخواست‌های یک کاربر به یک backend مشخص.

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

برای سرویس‌های وب، Persistence را فقط وقتی فعال کنید که رفتار برنامه واقعاً به آن نیاز دارد. اگر نیاز وجود دارد، Cookie Persistence معمولاً انتخاب تمیزتری است. Source Address ساده است، اما پشت NAT و Proxy می‌تواند بار را نامتعادل کند. بعد از هر تغییر، هم تجربه کاربر و هم توزیع ترافیک روی Pool را بررسی کنید.

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