آموزش جامع HA و Session Synchronization در FortiWeb

این مقاله برای شاخهFortiWeb 7.6نوشته شده و نسخه مبناFortiWeb 7.6.9است. جزئیات CLI با CLI Reference رسمی 7.6.7 و 7.6.8 تطبیق داده شده‌اند. در FortiWeb 7.4 ساختار اصلی HA مشابه است، اما Health Check Synchronization و بعضی قابلیت‌های Active-Active شاخه 7.6 توسعه یافته‌اند. در FortiWeb 8.0 دستور Manual Failover باexecute ha failoverاضافه شده است؛ این دستور را برای شاخه 7.6 فرض نکنید.

مروری بر این مقاله

1. HA چه مشکلی را حل می‌کند و چه مشکلی را حل نمی‌کند؟
2. مقایسه Modeهای HA
3. مفاهیم State و Synchronization
4. Configuration Synchronization
5. FortiWeb Session و Web Application Session
6. TLS Session در Failover
7. Layer 7 Persistence Synchronization
8. Health Check Synchronization
9. Heartbeat و شبکه HA
10. Primary Election، Priority و Override
11. Virtual MAC، ARP و NS
12. Reserved Management Interface
13. پیش‌نیازها و Pre-check
14. سناریوی کامل Active-Passive
15. پیکربندی Active-Passive در GUI
16. پیکربندی Active-Passive در CLI
17. Active-Active و Session Synchronization
18. Load-balancing Algorithm و Session Management
19. Synchronization دستی و مدیریت Memberها
20. روش تست Configuration Sync
21. روش تست Failover و Session
22. روش تست Network Convergence
23. Upgrade و Maintenance در Cluster
24. Troubleshooting و Split-Brain
25. Best Practice و چک‌لیست اجرایی

1. HA چه مشکلی را حل می‌کند و چه مشکلی را حل نمی‌کند؟

2. مقایسه Modeهای HA

پشتیبانی Operation Mode

3. مفاهیم State و Synchronization

4. Configuration Synchronization

Primary بیشتر تنظیمات Configuration را به Secondaryها منتقل می‌کند. هدف این است که Member جایگزین پس از Failover همان Server Policy، Certificate، Protection Profile و Network Configuration لازم را داشته باشد.

مواردی که معمولاً Sync می‌شوند

• Server Policyها و Server Poolها
• Web Protection Profileها
• Certificateها و بیشتر Objectهای امنیتی
• Interface Configurationهای غیررزروشده
• System Settingهای مشترک
• FortiGuard Packageها وSecurityDatabaseها طبق رفتار نسخه

موارد Node-specific

• Device Priority
• بعضی HA Settingهای محلی
• Reserved Management IP هر Member
• Serial Number و Hardware State
• High Volume Active-Active Interface Addressهای Member-specific

5. FortiWeb Session و Web Application Session

FortiWeb Session با Session خود Web Application یکسان نیست. Login Session برنامه معمولاً با Cookie، Token یا Server-side Session Store نگهداری می‌شود. FortiWeb ممکن است برای Featureهایی مانند Client Management، Authentication یا Persistence State جداگانه داشته باشد.

قانون 30 ثانیه

طبق مستند Fortinet، Sessionهایی که کمتر از 30 ثانیه برقرار بوده‌اند Sync نمی‌شوند. فقط Sessionهای قدیمی‌تر از 30 ثانیه برای Synchronization واجد شرایط‌اند.

اثر روی تست

• تست Session بلافاصله بعد از Login ممکن است Fail شود و نتیجه اشتباه بدهد.
• برای تست، Session را بیش از 30 ثانیه فعال نگه دارید.
• Session کوتاه و طولانی را جداگانه آزمایش کنید.
• Featureهای مبتنی بر Cookie FortiWeb را جدا از Login Application بررسی کنید.

6. TLS Session در Failover

State مربوط به TLS Handshake و Session Keyها Sync نمی‌شود. پس از Failover، Client معمولاً TLS Session را دوباره برقرار می‌کند. این Re-handshake ممکن است وقفه کوتاهی ایجاد کند، اما الزاماً Login Session برنامه را از بین نمی‌برد.

چه چیزی باید اندازه‌گیری شود؟

• مدت TLS Reconnect
• تعداد Requestهای Retryشده توسط Browser
• رفتار Mobile App و API Client
• Certificate و Cipher روی Member جدید
• اثر روی WebSocket یا Long-lived Connection

7. Layer 7 Persistence Synchronization

این قابلیت در Active-Passive استفاده می‌شود تا Mapping Persistence میان Primary و Secondary Sync شود. برای مثال کاربری که بر اساس Cookie Persistence به Backend شماره 2 هدایت شده است، بعد از Failover نیز به همان Backend هدایت شود.

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

• Backendها Shared Session Store ندارند.
• Application به Sticky Session وابسته است.
• Server Pool از Cookie یا Source-based Persistence استفاده می‌کند.
• تغییر Backend باعث Logout یا Transaction Failure می‌شود.

چه چیزی را حل نمی‌کند؟

• خرابی Backend انتخاب‌شده
• Session ذخیره‌شده فقط در Memory Backend
• Database Transaction نیمه‌کاره
• WebSocket Connection بدون Reconnect Logic

8. Health Check Synchronization

Health Check Sync وضعیت Up یا Down بودن Backendها را از Primary به Secondary منتقل می‌کند. بدون این قابلیت، Member جدید بعد از Failover ممکن است برای مدت کوتاهی Health State را از ابتدا محاسبه کند.

Modeهای پشتیبانی‌شده

• Active-Passive
• Active-Active Standard
• Reverse Proxy و True Transparent Proxy

رفتار Sync

• به‌صورت پیش‌فرض هنگام تغییر Health State Sync انجام می‌شود.
• Periodic Sync قابل فعال‌سازی است.
• بازه معتبر Periodic Sync طبق مستند 600 تا 3000 ثانیه است.
• مقدار پیش‌فرض Periodic Interval برابر 3000 ثانیه است.
• دستور Immediate Sync نیز وجود دارد.

config system ha set hlck-sync enable set hlck-period-sync enable set hlck-period-timeout 600 end execute ha synchronize health-check

9. Heartbeat و شبکه HA

Heartbeat برای تشخیص سلامت Member و انتقال Sync Data استفاده می‌شود. Heartbeat Traffic می‌تواند شامل اطلاعات حساس Configuration باشد و پهنای باند قابل توجهی مصرف کند.

Best Practice شبکه Heartbeat

• در Active-Passive دو Link مستقل استفاده کنید.
• ترجیحاً اتصال مستقیم میان Memberها باشد.
• اگر Switch استفاده می‌شود، VLAN اختصاصی و L2 Multicast مجاز باشد.
• Heartbeat Port برای Traffic عادی، Virtual Server یا Bridge استفاده نشود.
• Encryption روی تمام Memberها یکسان تنظیم شود.
• MTU، Duplex، Speed و Error Counter بررسی شوند.
• Heartbeat اصلی و Backup روی یک Switch یا مسیر فیزیکی مشترک نباشند.

Heartbeat Interval و Lost Threshold

کاهش بیش از حد Interval یا Threshold Failover را سریع‌تر می‌کند، اما حساسیت به Jitter، CPU Spike و Packet Loss را افزایش می‌دهد. مقدارهای پیش‌فرض یا مستند باید نقطه شروع باشند و بدون تست تغییر نکنند.

10. Primary Election، Priority و Override

Device Priority عددی است که عدد کوچک‌تر اولویت بالاتری دارد. Override تعیین می‌کند Priority نسبت به Uptime اهمیت بیشتری داشته باشد.

Side Effect Override

Override می‌تواند بعد از Recovery یک Failback دوم ایجاد کند. اگر Application به تغییر Connection حساس است، ممکن است ترجیح دهید Member سالم فعلی Primary بماند تا Maintenance Window.

11. Virtual MAC، ARP و NS

در Active-Passive و Standard Active-Active، Traffic Portها از Virtual MAC استفاده می‌کنند. هنگام Failover، Member جدید Virtual MAC را به‌عهده می‌گیرد و ARP یا Neighbor Solicitation ارسال می‌کند تا Switch و Neighborها Mapping جدید را یاد بگیرند.

پارامترهای مهم

• arpsتعداد ARP/NS Announcement
• arp-intervalفاصله Announcementها
• link-failed-signalسیگنال Link Failure برای تجهیزات مجاور در سناریوهای لازم
• Group ID: بخشی از Virtual MAC؛ تغییر آن Connectivity را تحت تأثیر قرار می‌دهد.

12. Reserved Management Interface

در Active-Passive و Standard Active-Active، بیشتر Interface Configurationها Sync می‌شوند. برای اینکه هر Member IP مدیریتی مستقل داشته باشد، یک Interface را Reserved Management تعریف کنید.

کاربرد

• Login مستقیم به Secondary
• بررسی Log و Status هر Member
• Troubleshooting زمانی که Cluster IP مشکل دارد
• SNMP وMonitoringMember-specific در صورت طراحی صحیح

مسیریابی Management

اگر Management Station در Subnet دیگری است، HA Static Route یا HA Policy Route لازم است. Route مدیریت Memberها Node-specific است و باید روی هر Member بررسی شود.

config system ha set ha-mgmt-status enable set ha-mgmt-interface "port5" end

13. پیش‌نیازها و Pre-check

• مدل و Firmware همه Memberها یکسان است.
• در VM، vCPU، RAM و Interface Count یکسان است.
• License و FortiGuard Contract همه Memberها معتبر است.
• System Time و NTP صحیح است.
• Operation Mode با HA Mode انتخاب‌شده سازگار است.
• Group ID در Broadcast Domain یکتا است.
• Heartbeat Cable و Backup Link آماده‌اند.
• تمام Monitor Interfaceها روی هر دو Member Link Up هستند.
• Switch و Firewall مسیر Redundant دارند.
• Reserved Management IPها و Routeها طراحی شده‌اند.
• Backend از هر دو Member قابل دسترسی است.
• Backup هر دو دستگاه گرفته شده است.

Pre-check CLI

get system status show system interface show system ha diagnose system ha status # بررسی Interface: diagnose netlink interface list # بررسی Route: get router info routing-table all

14. سناریوی کامل Active-Passive

تصمیم درباره Override

در این سناریو Node 1 باید همیشه Preferred Primary باشد، بنابراین Override فعال است. اگر جلوگیری از Failback خودکار مهم‌تر است، Override را غیرفعال کنید.

15. پیکربندی Active-Passive در GUI

مرحله 1: تنظیم Node اول

1. Mode را Active-Passive انتخاب کنید.
2. Group Name راPARTIAN-FWB-HAوارد کنید.
3. Group ID را 10 قرار دهید.
4. Device Priority را 1 تنظیم کنید.
5. Override را مطابق سیاست Failback فعال کنید.
6. Heartbeat Interface راport3انتخاب کنید.
7. Backup Heartbeat راport4انتخاب کنید.
8. Heartbeat Encryption و Key را تنظیم کنید.
9. Monitor Interface راport1وport2انتخاب کنید.
10. Boot Time را متناسب با Switch و Network Convergence تنظیم کنید.
11. Reserved Management Interface را فعال کنید.
12. Layer 7 Persistence Synchronization را فعال کنید.
13. Server Health Check Synchronization را فعال کنید.

مرحله 2: تنظیم Node دوم

تمام مقدارهای مشترک باید یکسان باشند. فقط Hostname، Priority و Reserved Management IP متفاوت است.

مرحله 3: بررسی HA Members

Role، Serial، Priority، Uptime، Sync Status، Interface Status و Health را بررسی کنید.

16. پیکربندی Active-Passive در CLI

Node اول

config system ha set mode active-passive set group-id 10 set group-name "PARTIAN-FWB-HA" set priority 1 set override enable set hbdev "port3" set hbdev-backup "port4" set hb-interval 1 set hb-lost-threshold 3 set arps 5 set arp-interval 1 set monitor "port1" "port2" set boot-time 30 set ha-mgmt-status enable set ha-mgmt-interface "port5" set 17-persistence-sync enable set hlck-sync enable set encryption enable set key "REPLACE-WITH-STRONG-HA-KEY" end

Node دوم

config system ha set mode active-passive set group-id 10 set group-name "PARTIAN-FWB-HA" set priority 5 set override enable set hbdev "port3" set hbdev-backup "port4" set hb-interval 1 set hb-lost-threshold 3 set arps 5 set arp-interval 1 set monitor "port1" "port2" set boot-time 30 set ha-mgmt-status enable set ha-mgmt-interface "port5" set 17-persistence-sync enable set hlck-sync enable set encryption enable set key "REPLACE-WITH-STRONG-HA-KEY" end

17. Active-Active و Session Synchronization

در Active-Active، Primary Traffic را میان Memberها توزیع می‌کند. Session Table به‌صورت پیش‌فرض می‌تواند از Heartbeat Interface منتقل شود. در Cluster پرترافیک، تا چهار Interface جدا برای Session Sync قابل تعریف است.

config system ha set mode active-active-standard set group-id 20 set group-name "PARTIAN-FWB-AAS" set hbdev "port3" set hbdev-backup "port4" set session-pickup enable set session-sync-dev "port5" "port6" set session-sync-broadcast disable set session-warm-up 20 end

قواعد Session Sync Interface

• فقط Primary تنظیم را اعمال می‌کند.
• Configuration به Secondaryها Sync می‌شود.
• Heartbeat Interface نباید درsession-sync-devوارد شود.
• اگر Interface جدا انتخاب شود، Heartbeat دیگر Session Table را حمل نمی‌کند.
• Unicast حالت پیش‌فرض است.
• برای Cluster بزرگ Broadcast ممکن است مفید باشد، اما باید L2 Design بررسی شود.

18. Load-balancing Algorithm و Session Management

طبق CLI Reference، بعضی قابلیت‌های Session Management FortiWeb با Algorithmهای By Connections یا Round-robin محدودیت دارند. قبل از انتخاب Algorithm، Featureهایی مانند Client Management، Authentication و Cookie-based Functionها را آزمایش کنید.

Weight در Algorithm IP

در Cluster دارای Memberهای یکسان معمولاً Weight برابر استفاده می‌شود. اگر ظرفیت واقعی Memberها متفاوت است، اساساً Cluster Design باید بازبینی شود؛ HA Memberها بهتر است هم‌مدل و هم‌ظرفیت باشند.

19. Synchronization دستی و مدیریت Memberها

بررسی وضعیت

get system ha status diagnose system ha status show system ha

Sync دستی

execute ha synchronize cli execute ha synchronize all execute ha synchronize health-check

ورود به Member دیگر

execute ha manage # یا در Buildهایی که Syntax Index می‌خواهد: execute ha manage

Cluster Index با Serial Number تعیین می‌شود. قبل از تغییر Node-specific مطمئن شوید روی Member درست قرار دارید.

20. روش تست Configuration Sync

1. وضعیت Cluster را In-Sync ثبت کنید.
2. یک Object کم‌خطر مانند Comment یا Test Protected Host بسازید.
3. روی Secondary از طریق Reserved Management یاha manageوجود Object را بررسی کنید.
4. Certificate List و Web Protection Profile را مقایسه کنید.
5. Object تست را حذف کنید و Sync حذف را نیز بررسی کنید.

چه چیزی را نباید برای تست تغییر داد؟

• Group ID در Production
• Heartbeat Interface بدون Console
• Virtual Server IP فعال
• Server Policy اصلی
• Firmware یا Operation Mode

21. روش تست Failover و Session

آماده‌سازی

• یک User تست داخل Application
• یک صفحه که Backend ID را نمایش دهد
• Packet Capture روی Client-side و Server-side
• Log Application و FortiWeb
• Session کوتاه و Session بالای 30 ثانیه

مراحل

1. با User تست Login کنید.
2. Backend انتخاب‌شده را ثبت کنید.
3. حداقل 60 ثانیه Session را فعال نگه دارید.
4. یک Transaction غیرحساس در حال Polling ایجاد کنید.
5. Interface Monitorشده Primary را در Change Window قطع کنید.
6. زمان تغییر Role را ثبت کنید.
7. TLS Re-handshake و HTTP Retry را مشاهده کنید.
8. ادامه Login و Backend Persistence را بررسی کنید.
9. Primary قبلی را برگردانید و رفتار Override را ثبت کنید.

جدول نتیجه تست

22. روش تست Network Convergence

• MAC Address Table روی Switch را قبل و بعد ثبت کنید.
• ARP Table یا Neighbor Table روی Router و Client را بررسی کنید.
• Gratuitous ARP یا NS Packetها را Capture کنید.
• Failover را از هر دو مسیر Client-side و Server-side تست کنید.
• درVMwareVirtual Switch Security Setting را بررسی کنید.
• اگر Failover طولانی است، ARP Count، ARP Interval و Boot Time را بررسی کنید.
• Link-failed-signal را فقط با شناخت رفتار Switch فعال کنید.

23. Upgrade و Maintenance در Cluster

Upgrade HA باید بر اساس Upgrade Path و Release Notes انجام شود. قبل از Upgrade موارد زیر را بررسی کنید

• Known Issueهای HA همان Release
• Upgrade ترتیب Memberها
• Config Backup و Certificate Backup
• License و Disk Space
• Compatibility با FortiWeb Manager یا FortiAnalyzer
• زمان Reboot و Failover
• تست Application بعد از هر مرحله

24. Troubleshooting و Split-Brain

Debug کوتاه

diagnose system ha status diagnose debug application hatalk 7 diagnose debug enable # پس از جمع‌آوری: diagnose debug disable

25. Best Practice و چک‌لیست اجرایی

• مدل، Firmware و Resource Memberها یکسان است.
• License و FortiGuard همه Memberها معتبر است.
• Operation Mode با HA Mode سازگار است.
• Group ID یکتا است.
• Priority و Override مستند شده‌اند.
• دو Heartbeat Link مستقل وجود دارد.
• Heartbeat از شبکه User جدا است.
• Heartbeat Encryption یکسان است.
• Monitor Interfaceها روی هر دو Member متصل‌اند.
• VLAN Subinterface به‌عنوان Monitor انتخاب نشده است.
• Reserved Management برای هر Member وجود دارد.
• Management Route هر Member تست شده است.
• تفاوت FortiWeb Session و Application Session مستند است.
• قانون 30 ثانیه در تست لحاظ شده است.
• Layer 7 Persistence Sync در صورت نیاز فعال است.
• Health Check Sync فعال و Immediate Sync تست شده است.
• Session Sync Interface ظرفیت کافی دارد.
• Algorithm Active-Active با Featureهای Session سازگار است.
• ARP/ND Convergence تست شده است.
• Switch، Firewall و Backend نیز Redundant هستند.
• Failover و Failback دوره‌ای تست می‌شوند.
• Backup و Rollback Plan وجود دارد.
• Upgrade Path و Known Issues بررسی می‌شوند.

برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمایپشتیبانی شبکهرا نیز مطالعه کنید.