failover سرور و چند سرور مبدا؛ جلوگیری از قطعی سایت

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

در این مقاله می‌بینید nsin چطور با «origin pool» ترافیک را بین چند سرور پخش می‌کند و هنگام خرابی failover انجام می‌دهد، با «origin route» بخش‌های مختلف سایت را به سرورهای جدا می‌فرستد و با بخش آپتایم از قطعی سرور مبدا خبر می‌دهد. اگر هنوز CDN را راه‌اندازی نکرده‌اید، ابتدا CDN چیست و راه‌اندازی بدون قطعی را ببینید.

مبدا چیست و چرا یکی کافی نیست؟

طبق مستندات مبدا و failover، مبدا (origin) سروری است که nsin سایت شما را از آن می‌گیرد؛ به‌طور پیش‌فرض همان چیزی که رکورد DNS شما به آن اشاره می‌کند. دو نوع قانون سمت لبه این رفتار را تغییر می‌دهند:

• Origin pool: چند سرور با health check و failover.
• Origin route: فرستادن مسیرهای مشخص به یک سرور مشخص.

قبل از تنظیم چیزی، یک سؤال ساده از خودتان بپرسید: کدام یک از این دو مشکل را دارم؟ چند سرور یکسان دارم و می‌خواهم بار بینشان پخش شود و اگر یکی خراب شد بقیه جایش را بگیرند (pool)، یا بخش‌های مختلف سایت روی سرورهای متفاوت‌اند (route)؟ می‌توانید هر دو را با هم به کار ببرید.

یک نکته درباره پلن: اینکه هر نوع قانون در دسترس باشد به پلن دامنه بستگی دارد. اگر پلن دامنه نوعی از قانون را شامل نشود، قانونی از آن نوع ساخته می‌شود ولی خاموش ذخیره می‌شود و تا وقتی پلن آن نوع را شامل نشود روشن نمی‌شود (پلن‌ها).

ساخت origin pool

برای ساخت آن در Rules روی Add Rule و بعد Origin Pool بزنید. هر سرور را با آدرس، پورت و پروتکل http یا https اضافه کنید. بعد یکی از این روش‌های توزیع ترافیک را انتخاب کنید و در پایان Save را بزنید:

روش	رفتار
Round robin	به‌نوبت بین سرورها می‌چرخد. وزن بیشتر به یک سرور سهم بزرگ‌تری می‌دهد.
Least load	سروری را ترجیح می‌دهد که همین الان کمترین کار را دارد.
Geographic	هر موقعیت nsin از سروری استفاده می‌کند که شما برایش تعیین کرده‌اید.

نمونه‌های انتخاب:

• دو سرور هم‌قدرت دارید: Round robin ساده‌ترین و قابل‌پیش‌بینی‌ترین گزینه است.
• یک سرور قوی‌تر و یکی ضعیف‌تر دارید: Round robin با وزن‌های متفاوت.
• بار درخواست‌ها نامتوازن است: Least load.
• سرورهایتان در مکان‌های مختلف‌اند و می‌خواهید هر موقعیت nsin از سرور مشخصی استفاده کند: Geographic (سرور هر موقعیت را خودتان تعیین می‌کنید؛ فهرست موقعیت‌ها در ابزار MCP با list_edge_nodes هم در دسترس است).

Health check؛ قلب failover

بدون health check، pool در عمل فقط توزیع بار است. با روشن کردن آن، nsin هر سرور را بررسی می‌کند (به‌طور پیش‌فرض مسیر /، یا یک مسیر اختصاصی مثل /healthz) و سرورهای ناسالم را از چرخه خارج می‌کند. این پارامترها را می‌توانید تنظیم کنید:

• فاصله بین بررسی‌ها (interval)
• مهلت پاسخ (timeout)
• تعداد شکست لازم برای کنار گذاشتن سرور
• تعداد موفقیت لازم برای برگرداندن آن

همچنین سروری که در درخواست‌های واقعی شکست می‌خورد، می‌تواند برای مدتی کوتاه کنار گذاشته شود.

مسیر health check را طوری انتخاب کنید که واقعاً برنامه را تست کند. مسیری که حتی وقتی دیتابیس از کار افتاده 200 برمی‌گرداند، هیچ‌چیز به شما نمی‌گوید.

یعنی اگر برنامه‌تان به دیتابیس وابسته است، یک endpoint سلامت بنویسید که وضعیت اتصال را هم بسنجد، نه فقط «وب‌سرور بالا است».

وقتی یک سرور از کار می‌افتد بازدیدکننده چه می‌بیند؟

با health check روشن، معمولاً هیچ‌چیز: ترافیک به بقیه سرورها می‌رود. بدون آن، تا وقتی سرور خراب را دستی حذف نکنید، بعضی درخواست‌ها شکست می‌خورند.

origin route؛ جدا کردن بخش‌های سایت

گاهی مشکل تعداد سرور نیست، تفکیک وظیفه است. با Origin Route مسیرهای مشخصی را به سروری مشخص می‌فرستید و بقیه سایت دست‌نخورده می‌ماند. برای ساخت آن در Rules روی Add Rule و بعد Origin Route بزنید، مسیرها (مثلاً /api/*) را بنویسید و آدرس، پورت و پروتکل سرور را مشخص کنید.

نمونه‌ای که در مستندات آمده، جدا کردن API از وب‌سایت است:

• /api/* به 10.0.0.20:8080 روی http
• بقیه مسیرها به مبدا معمول

آدرس بالا فقط نمونه است؛ آدرس واقعی سرور API خودتان را بگذارید. این کار وقتی مفید است که API روی ماشین جدا با منابع متفاوت اجرا می‌شود و نمی‌خواهید مشکل آن روی صفحه‌های وب‌سایت اثر بگذارد.

هدر Host

هر دو نوع قانون اجازه می‌دهند Host header (و TLS SNI) ارسالی به مبدا را تغییر بدهید؛ مثلاً وقتی یک بک‌اند چند سایت را سرو می‌کند و باید مقداری مثل app.internal بفرستید. اگر خالی بگذارید، همان hostname که بازدیدکننده درخواست کرده ارسال می‌شود. برای آدرس سرور می‌توانید به‌جای IP از hostname هم استفاده کنید، ولی آن‌وقت nsin به درست resolve شدن آن نام وابسته است.

مانیتورینگ آپتایم: از قطعی باخبر شوید

failover خرابی را از چشم بازدیدکننده پنهان می‌کند، ولی پنهان بودن خرابی به معنای نبودن آن نیست. اگر یکی از دو سرور خراب شده باشد و شما خبر نداشته باشید، در واقع با یک سرور کار می‌کنید. بخش Uptime پنل (مستندات آپتایم) وقتی سرور شما مدتی به درخواست‌های واقعی درست جواب نمی‌دهد، شما را باخبر می‌کند. چون این بخش درخواست‌های ناموفق را می‌شمارد، خرابی‌ای که failover پنهانش کرده ممکن است در آن دیده نشود؛ پس سلامت تک‌تک سرورها را جداگانه هم زیر نظر داشته باشید.

nsin چطور خرابی را تشخیص می‌دهد؟

nsin سایت شما را از بیرون پینگ نمی‌کند. ترافیک واقعی بازدیدکنندگان را می‌بیند و درخواست‌هایی را می‌شمارد که سرور شما درست جواب نداده است. یک ساب‌دامین وقتی در یک دقیقه «پایین» حساب می‌شود که سهم درخواست‌های ناموفق از آستانه بالاتر باشد و ترافیک آن دقیقه هم برای معنادار بودن عدد کافی باشد. این کف ترافیک مهم است: دو خطا از سه درخواست ساعت ۴ صبح، قطعی نیست.

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

تنظیمات تشخیص

در بخش Settings صفحه Uptime می‌توانید تشخیص را با ترافیک خودتان تنظیم کنید. هر تنظیم بازه مجاز خودش را دارد که کنارش در پنل نشان داده می‌شود.

تنظیم	معنی
Alerts on/off	ارسال اعلان قطعی برای این دامنه
Threshold	درصد درخواست ناموفق در دقیقه که «پایین» حساب می‌شود
Window	مدتی که میزبان باید پایین بماند تا incident باز شود
Minimum requests	کف ترافیک؛ زیر آن incident باز نمی‌شود
Minimum active minutes	حداقل تعداد دقیقه‌هایی از پنجره که باید ترافیک واقعی داشته باشند
Recovery	تعداد دقیقه‌های سالم متوالی برای بستن incident

اگر برای اتفاق‌های کوچک هشدار می‌گیرید، window را بزرگ‌تر یا minimum requests را بیشتر کنید. اگر قطعی‌های واقعی را نمی‌شنوید، اول threshold را پایین بیاورید.

کانال‌های اعلان و webhook

در بخش Notification channels صفحه Uptime مشخص می‌کنید اعلان‌های دامنه از چه کانال‌هایی ارسال شوند. اعلان‌ها به مالک دامنه و اعضایی می‌رسد که اعلان قطعی را روشن دارند. کانال‌ها: ایمیل (پیش‌فرض روشن)، پیامک (پیش‌فرض روشن؛ فقط پلن‌های پولی و شماره موبایل ایرانی تأییدشده) و webhook (پیش‌فرض خاموش؛ روی همه پلن‌ها رایگان؛ یک URL برای هر دامنه). هشدارها در هر حال در پنل هم نمایش داده می‌شوند.

وقتی قطعی شروع می‌شود (outage.opened) و وقتی برطرف می‌شود (outage.resolved)، webhook یک درخواست POST با بدنه JSON به URL شما می‌فرستد؛ برای هر incident یک بار از هر کدام. دکمه Test هم یک رویداد آزمایشی به نام test می‌فرستد. هر درخواست هدرهای X-Nsin-Timestamp و X-Nsin-Signature دارد؛ امضا برابر sha256= به‌علاوه HMAC-SHA256 (به‌صورت hex) رشته <timestamp>.<raw body> است که با signing secret نمایش‌داده‌شده در صفحه محاسبه می‌شود. حتماً امضا را در سمت گیرنده راستی‌آزمایی کنید. پاسخ 2xx را ظرف ۵ ثانیه برگردانید؛ در غیر این صورت دو بار دیگر (بعد از ۵ و ۳۰ ثانیه) تلاش می‌شود. گیرنده می‌تواند سرویس کوچکی باشد که رویداد را برای ربات چت تیم یا ابزار مدیریت رخداد ارسال می‌کند.

توصیه‌های عملی: کش، failover و آپتایم کنار هم

• از کش استفاده کنید. طبق مستندات، در زمان قطعی صفحه‌های کش‌شده همچنان سرو می‌شوند، اما هر چیزی که nsin باید از سرور شما بگیرد شکست می‌خورد. توضیح بیشتر درباره کش در کش CDN آمده است.
• دو سرور یکسان بگذارید و برایشان pool بسازید، با health check روی مسیری که واقعاً سلامت برنامه را نشان می‌دهد.
• بخش‌های مستقل را با route جدا کنید تا خرابی API روی بقیه اثر نگذارد.
• آپتایم را فعال نگه دارید و اعلان ایمیل یا webhook را به جایی بفرستید که کسی واقعاً آن را ببیند.
• آدرس‌های nsin را در فایروال سرور مجاز کنید. وقتی دامنه پروکسی است، درخواست‌ها از آدرس‌های nsin به سرور شما می‌رسند؛ لیست IP را در فایروال مجاز نگه دارید. این یکی از چک‌های بخش Recommendations پنل هم هست.
• آنالیتیکس را بخوانید. صفحه مانیتورینگ نرخ خطا و کدهای وضعیت را نشان می‌دهد. مانیتورینگ ویژگی پرمیوم است و طبق مستندات، تشخیص قطعی در آپتایم هم به پلنی نیاز دارد که مانیتورینگ را شامل شود (پلن‌ها).

پرسش‌های متداول

چند سرور مبدا برای شروع کافی است؟

دو سرور یکسان کمترین حالتی است که failover معنا دارد. مهم این است که سرورها واقعاً یک محتوا را سرو کنند و health check درستی داشته باشند.

تفاوت origin pool و origin route چیست؟

Pool برای چند سرور یکسان است که بار بینشان پخش می‌شود و اگر یکی خراب شد، ترافیک به بقیه می‌رود. Route برای فرستادن بخش‌های مشخص سایت (مثل /api/*) به سرور مشخص است. می‌توانید هر دو را با هم داشته باشید.

اگر health check را خاموش بگذارم چه می‌شود؟

pool همچنان ترافیک را پخش می‌کند، ولی تا وقتی سرور خراب را دستی حذف نکنید، بعضی درخواست‌ها شکست می‌خورند.

آپتایم می‌گوید قطع است ولی سایت برای من باز می‌شود. چرا؟

قطعی‌ها معمولاً جزئی‌اند: یک ساب‌دامین، یک منطقه یا بعضی درخواست‌ها. نمای live و کدهای وضعیت را در بخش مانیتورینگ ببینید.

در زمان قطعی سرور، سایت کاملاً از دسترس می‌رود؟

صفحه‌های کش‌شده همچنان سرو می‌شوند؛ اما هر چیزی که nsin باید از سرور شما بگیرد، تا وقتی سرور خراب است شکست می‌خورد. کش و failover مبدا هر دو برای کم کردن همین اثرند.

شروع کنید

قدم اول ساده است: اگر دو سرور دارید، در بخش Rules پنل دامنه‌تان یک Origin Pool بسازید، health check را روی مسیر سلامت برنامه بگذارید و در Uptime کانال اعلان (ایمیل یا webhook) را بررسی کنید. اگر هنوز دامنه‌تان روی CDN nsin نیست، برای ساخت حساب و افزودن دامنه به panel.nsin.ir بروید.