راه‌اندازی Failover
اینترنت

تفاوت Failover با تجمیع و افزونگی کامل

در تجمیع چند خط، چند اتصال می‌توانند هم‌زمان بار بگیرند. در سناریوی اصلی/پشتیبان، مسیر دوم برای نیاز تعریف‌شده هنگام خرابی استفاده می‌شود. این دو هدف قابل ترکیب‌اند، اما باید جدا آزموده شوند.

افزونگی اینترنت، خرابی برق، روتر، سوئیچ یا برنامه را خودبه‌خود پوشش نمی‌دهد. دامنهٔ خرابی مورد انتظار را مشخص کنید تا تعهد طراحی از واقعیت بیشتر نشود. یک خط دوم، همهٔ نقاط شکست شبکه را حذف نمی‌کند.

استقلال خط پشتیبان و ظرفیت اضطراری

دو سرویس ممکن است مسیر فیزیکی یا تجهیزات مشترک داشته باشند. دربارهٔ تنوع واقعی مسیر از ارائه‌دهنده اطلاعات قابل اتکا بگیرید و وابستگی‌های محل را ثبت کنید. حتی تنوع فناوری، مصونیت از همهٔ اختلالات را تضمین نمی‌کند.

در زمان خرابی، کدام برنامه‌ها باید کار کنند؟ ظرفیت آپلود و دانلود خط دوم و بار حداقلی را بسنجید. اگر ظرفیت کمتر است، سیاست مصرف و اولویت مشخص شود؛ انتقال تمام ترافیک سنگین بدون کنترل می‌تواند مسیر جایگزین را اشباع کند.

تشخیص خرابی واقعی، نه فقط قطع کابل

خرابی می‌تواند با روشن‌بودن رابط رخ دهد؛ برای مثال، مودم پاسخ می‌دهد اما سرویس بیرونی از آن مسیر در دسترس نیست. مقصدهای بررسی باید هدف مشخص داشته باشند و خرابی یک مقصد، بی‌دلیل خرابی همهٔ اینترنت تلقی نشود.

راهنمای Failover در RouterOS نمونه‌ای از بررسی دسترس‌پذیری با مسیر بازگشتی ارائه می‌کند. آزمون سلامت هر خط باید به همان مسیر مقید باشد؛ این مثال، نسخهٔ آمادهٔ تنظیم برای همهٔ شبکه‌ها نیست.

آستانه تشخیص، تأخیر انتقال و برگشت خط

حساسیت زیاد به خطای لحظه‌ای می‌تواند تغییر مکرر مسیر ایجاد کند و حساسیت کم، خرابی را دیر اعلام کند. روش و بازهٔ بررسی با نیاز سرویس و کیفیت خط تنظیم شوند؛ عدد ثابت برای همهٔ محیط‌ها منطقی نیست.

پس از بازگشت، ثبات خط پیش از انتقال گسترده بررسی شود. بازگشت خودکار یا با تأیید، باید از قبل تعریف شود. زمان تشخیص، انتقال و بازیابی نشست‌ها را جدا ثبت کنید؛ یک عدد مبهم برای همهٔ این مراحل قابل استفاده نیست.

تغییر IP و اثر بر تماس، VPN و نشست‌های فعال

انتقال به ISP دیگر می‌تواند IP خروجی را تغییر دهد؛ بعضی نشست‌ها نیاز به اتصال یا ورود مجدد خواهند داشت. تماس فعال، انتقال فایل یا برنامهٔ حساس باید در آزمون واقعی دیده شوند. موفقیت بازکردن یک صفحه، بقای همان تماس را ثابت نمی‌کند.

VPN، سرویس ورودی و فهرست مجاز IP مقصد نیز ممکن است شرایط جدا داشته باشند. برای VPN امن و ارتباط شعب، طراحی مسیر و مقصد باید با خط پشتیبان هماهنگ شود. از وعدهٔ حفظ همهٔ نشست‌ها بدون معماری و شاهد مشخص پرهیز کنید.

راه‌اندازی Failover با بکاپ و مسیر بازگشت

ابتدا خطوط، IP/NAT، قواعد، سرویس حیاتی و معیار پذیرش ثبت شوند. تغییر با بکاپ تنظیمات و مجوز مالک انجام شود و راه دسترسی بازگشت آماده باشد. آزمون قطع ارتباط هنگام کار حساس، بدون هماهنگی مجاز نیست.

پس از پایلوت، سیاست اضطراری و اعلان فعال شوند. مدیریت پهنای باند می‌تواند مصرف مسیر محدودتر را سامان دهد، اما ظرفیت اضافه ایجاد نمی‌کند. رفتار پس از تغییر خطوط و تجهیزات دوباره بررسی شود.

آزمون خرابی و بازگشت؛ چک‌لیست تحویل

قطع کابل تنها سناریو نیست؛ در محیط و زمان مجاز، خرابی رابط و دسترس‌پذیری مسیر و برگشت ناپایدار نیز متناسب با دامنه بررسی شوند. نتیجه و محدودیت هر آزمون با شاهد ثبت شود، نه فقط عبارت «Failover کار می‌کند».

• روش تشخیص هر خط و مقصد آزمون ثبت شده
• ترافیک ضروری روی خط جایگزین درست کار می‌کند
• ظرفیت اضطراری و سیاست مصرف بررسی شده
• رفتار تماس، VPN، نشست و سرویس ورودی گزارش شده
• زمان‌های تشخیص و بازیابی و برگشت ثبت شده
• هشدار، مستندات و بکاپ تحویل شده

نگهداری و هزینه Failover اینترنت

خط دومِ استفاده‌نشده هم ممکن است دچار مشکل شود. سلامت، اعتبار سرویس و ظرفیت آن باید در برنامهٔ نگهداری دیده شوند. پس از تغییر ISP، IP یا روتر، تست قدیمی به‌تنهایی وضعیت جدید را تأیید نمی‌کند.

تعداد خطوط، روتر، روش پایش، ساعات بررسی و دامنهٔ آزمون بر هزینه اثر دارند. ارتباط، اجرای اولیه و نگهداری جدا مشخص شوند. این مقاله زمان انتقال ثابت، قطعی صفر یا قیمت عمومی برای همهٔ شبکه‌ها وعده نمی‌دهد.

طراحی Failover سازمانی در ویوان نت

خطوط فعلی و سرویس‌های ضروری را مشخص کنید تا تشخیص خرابی، ظرفیت اضطراری و رفتار بازیابی قابل تعریف شوند. تعداد کاربران و هدف بررسی را در بخش پشتیبانی ویوان نت توضیح دهید؛ رمز، کلید یا تنظیمات محرمانه را در درخواست معمولی نفرستید.