HA و Chassis Cluster در Juniper SRX؛ قبل از Failover چه چیزهایی را چک کنیم؟

در خیلی از پروژه‌ها Juniper SRX به صورت HA نصب می‌شود، اما HA واقعی فقط این نیست که دو دستگاه کنار هم باشند و Chassis Cluster روشن شده باشد. باید بدانید در زمان failover چه اتفاقی می‌افتد، کدام interfaceها مانیتور می‌شوند، sessionها sync می‌شوند یا نه، و اگر لینک کنترل یا fabric مشکل پیدا کند چه اثری روی سرویس‌ها دارد.

این چک‌لیست برای قبل از تحویل، قبل از تغییر حساس و قبل از تست دوره‌ای failover نوشته شده است. هدف این است که HA در زمان حادثه غافلگیرتان نکند.

اول سلامت Cluster را ببینید

قبل از هر تست، وضعیت کلی cluster باید شفاف باشد. اگر یکی از nodeها از قبل warning دارد یا redundancy group در وضعیت ناپایدار است، تست failover می‌تواند مشکل موجود را بدتر کند.

show chassis cluster status
show chassis cluster interfaces
show chassis cluster control-plane statistics
show chassis cluster data-plane statistics

در خروجی‌ها به وضعیت nodeها، redundancy groupها، priority، preempt و خطاهای control/fabric دقت کنید. اگر counters خطا زیاد شده‌اند، قبل از تست failover علت را پیدا کنید.

Control Link و Fabric Link را ساده فرض نکنید

Control link برای هماهنگی cluster حیاتی است و fabric link برای عبور ترافیک و sync بین nodeها نقش مهمی دارد. خرابی یا ناپایداری این لینک‌ها ممکن است خودش را فقط در زمان فشار یا failover نشان بدهد. کابل، transceiver، VLAN، MTU و خطاهای interface را جدا بررسی کنید.

• Control link باید پایدار و بدون error قابل توجه باشد.
• Fabric link را از مسیرهای معمول data جدا و قابل پیش‌بینی نگه دارید.
• اگر چند لینک استفاده می‌شود، وضعیت همه memberها را ببینید.
• تغییرات فیزیکی رک یا سوئیچ را بدون تست cluster تمام‌شده فرض نکنید.

Redundancy Groupها را بر اساس سرویس طراحی کنید

همه چیز نباید کورکورانه در یک redundancy group بماند. بسته به طراحی، ممکن است دیتاپلین‌ها، لینک‌های WAN، DMZ یا بخش‌های داخلی نیاز به مانیتورینگ متفاوت داشته باشند. نکته مهم این است که failover باید با از دست رفتن مسیرهای واقعاً حیاتی اتفاق بیفتد، نه با هر نوسان کم‌اهمیت.

Interface monitoring را با دقت تنظیم کنید. اگر weightها بد انتخاب شوند، یک لینک غیرحیاتی می‌تواند باعث failover بی‌مورد شود یا برعکس، قطعی مهم failover ایجاد نکند.

Session Sync را برای سرویس‌های حساس بررسی کنید

در بعضی سرویس‌ها، failover بدون حفظ session قابل قبول نیست. در بعضی دیگر، قطع شدن چند session کوتاه قابل تحمل است. این تصمیم باید قبل از incident روشن باشد. اگر سازمان از VPN، سرویس‌های مالی، APIهای حساس یا ارتباطات طولانی‌مدت استفاده می‌کند، تست واقعی با ترافیک مشابه production لازم است.

Failover را فقط با خاموش کردن دستگاه تست نکنید

خاموش کردن node یکی از تست‌هاست، اما کافی نیست. باید سناریوهای دقیق‌تری هم بررسی شوند: قطع لینک WAN، قطع لینک DMZ، مشکل سمت سوئیچ، خطای fabric، و تغییر کنترل‌شده priority. هر سناریو اثر متفاوتی دارد و ممکن است همه آنها یک رفتار یکسان ایجاد نکنند.

request chassis cluster failover redundancy-group 1 node 1
show chassis cluster status
show security flow session summary

بعد از تست، فقط up بودن interfaceها کافی نیست. سرویس واقعی را از مسیر کاربر تست کنید، لاگ‌ها را ببینید و مطمئن شوید مسیر برگشت هم درست است. اگر فایروال در مسیر NAT یا VPN است، این بررسی مهم‌تر می‌شود.

Rollback و زمان‌بندی تست

تست HA باید پنجره زمانی و rollback داشته باشد. حتی اگر انتظار قطعی ندارید، باید بدانید اگر node اصلی برنگشت یا sessionها رفتار غیرمنتظره داشتند چه می‌کنید. برای محیط production، قبل از تست خروجی تنظیمات، وضعیت cluster و مسیرهای مهم را ذخیره کنید.

اگر HA بخشی از پروژه بزرگ‌تر امن‌سازی فایروال است، بهتر است کنار Rule Review و NAT Review بررسی شود. صفحه مشاور امنیت شبکه مسیر ارزیابی عملیاتی این نوع زیرساخت‌ها را توضیح می‌دهد.

جمع‌بندی

HA در Juniper SRX وقتی قابل اعتماد است که سلامت cluster، control link، fabric link، redundancy groupها، session sync و سناریوهای failover واقعاً تست شده باشند. Chassis Cluster بدون تست دوره‌ای فقط یک فرض خوش‌بینانه است؛ در شبکه سازمانی باید با خروجی، لاگ و تست سرویس واقعی تأیید شود.