بسیاری از کسب‌وکارها هم مشتری داخلی دارند و هم به سرویس‌های بین‌المللی نیاز دارند: درگاه‌های ارزی، APIهای خارجی، ارسال ایمیل به سراسر دنیا یا کاربران خارج از کشور. سرور داخلی به‌تنهایی برای این نیازها کافی نیست و سرور خارجی هم در زمان محدودیت برای کاربران ایرانی از دسترس خارج می‌شود. راه‌حل، استفاده هم‌زمان از سرور ایران و خارج با معماری‌ای است که با قطع ارتباط بین دو طرف، هیچ‌کدام از کار نیفتد.
فهرست مطالب
اصل اول: هر طرف مستقل کار کند
خطای رایج این است که سایت روی سرور داخلی اجرا شود اما دیتابیس، فضای فایل یا سرویس احراز هویت روی سرور خارج باشد (یا برعکس). چنین معماری‌ای در زمان قطعی بدترین حالت ممکن است، چون هر دو سرور سالم‌اند اما سرویس کار نمی‌کند. قاعده ساده است: مسیر کامل سرویس‌دهی به کاربر ایرانی باید داخل کشور بسته شود و ارتباط با سرور خارج فقط برای همگام‌سازی و کارهای غیرفوری باشد.
کدام سرویس کجا اجرا شود؟
| سرویس | محل پیشنهادی | دلیل |
|---|---|---|
| سایت و API برای کاربران ایرانی | ایران | پینگ پایین و دسترس‌پذیری در محدودیت |
| دیتابیس اصلی سرویس داخلی | ایران | کنار برنامه، بدون وابستگی به مرز |
| DNS دامنه | ایران (و در صورت نیاز، نسخه ثانویه خارج) | resolve شدن دامنه برای کاربران داخلی |
| اتصال به APIها و درگاه‌های خارجی | خارج | به اینترنت بین‌الملل نیاز دارد |
| ارسال ایمیل انبوه بین‌المللی | خارج | تحویل بهتر به سرویس‌های ایمیل جهانی |
| سرویس برای کاربران خارج از کشور | خارج | پینگ پایین‌تر برای آن کاربران |
| بکاپ | هر دو طرف | در قطعی، نسخه در دسترس داشته باشید |
| مانیتورینگ | هر دو طرف | هر طرف دید درستی از دسترس‌پذیری خودش داشته باشد |
سه الگوی رایج
۱. داخلی اصلی، خارجی کمکی
همه سرویس‌دهی به کاربران روی سرور داخلی است. سرور خارج فقط کارهایی را انجام می‌دهد که به اینترنت بین‌الملل نیاز دارند؛ مثلاً دریافت نرخ ارز از API خارجی، ارسال ایمیل یا اتصال به سرویس‌های ابری. ارتباط بین دو طرف با صف پیام (Queue) و به‌صورت ناهمگام است، تا اگر ارتباط قطع شد، کارها در صف بمانند و پس از برقراری دوباره انجام شوند. ساده‌ترین و پایدارترین الگو برای بیشتر کسب‌وکارهای ایرانی همین است.
۲. دو نسخه موازی (Active/Active جغرافیایی)
یک نسخه از سرویس در ایران برای کاربران داخلی و یک نسخه در خارج برای کاربران خارجی اجرا می‌شود. هر نسخه دیتابیس مخصوص خودش را دارد و داده‌های مشترک به‌صورت ناهمگام همگام‌سازی می‌شوند. این الگو بیشترین پایداری را دارد، اما مدیریت تعارض داده‌ها پیچیده است و فقط برای سرویس‌هایی مناسب است که داده‌های هر کاربر عمدتاً در یک طرف ایجاد می‌شود.
۳. نسخه آماده به کار (Standby)
سرویس اصلی در یک طرف اجرا می‌شود و طرف دیگر یک نسخه تکثیرشده و آماده دارد. اگر سرویس اصلی خارج است، در زمان قطعی DNS به نسخه داخلی تغییر می‌کند. این الگو برای مهاجرت تدریجی به سرور داخلی هم مناسب است. تعریف اهداف زمانی بازیابی (RTO و RPO) در برنامه بازیابی از حادثه.
DNS و هدایت کاربران
- Nameserverهای دامنه را داخل کشور میزبانی کنید یا دست‌کم یک Nameserver داخلی داشته باشید؛ در غیر این صورت در قطعی، دامنه برای کاربران داخلی resolve نمی‌شود.
- TTL رکوردهایی که ممکن است در زمان بحران تغییر کنند را کوتاه نگه دارید (مثلاً ۳۰۰ ثانیه) تا تغییر مسیر سریع اعمال شود.
- اگر به هدایت جغرافیایی نیاز دارید (کاربر ایرانی به سرور داخلی، کاربر خارجی به سرور خارج)، از DNS با قابلیت GeoDNS استفاده کنید. ساده‌تر از آن، تعریف زیردامنه‌های جدا برای هر نسخه است.
مفاهیم پایه در DNS چیست.
تکثیر دیتابیس و فایل‌ها
- دیتابیس: تکثیر Synchronous بین ایران و خارج را به‌کار نبرید. تاخیر رفت‌وبرگشت هر نوشتن را کند می‌کند و با قطع ارتباط، نوشتن روی سرور اصلی هم متوقف می‌شود. تکثیر Asynchronous (مثل Replication در MySQL یا Streaming Replication در PostgreSQL) را انتخاب کنید و تاخیر تکثیر (Replication Lag) را پایش کنید.
- فایل‌ها و آپلودها: با
rsyncزمان‌بندی‌شده یا تکثیر Object Storage همگام‌سازی کنید. در قطعی، همگام‌سازی متوقف می‌شود و پس از برقراری از همان نقطه ادامه می‌یابد. - بکاپ: بکاپ هر طرف را در همان طرف هم نگه دارید. بکاپی که فقط در خارج است، در قطعی قابل بازیابی نیست. روش‌ها در بکاپ و انتقال دیتابیس.
وقتی ارتباط دو طرف قطع می‌شود
مهم‌ترین بخش طراحی، تصمیم‌گیری از پیش برای این لحظه است. اگر هر دو طرف به نوشتن روی یک داده ادامه دهند، پس از برقراری ارتباط با تعارض داده‌ها (Split-brain) روبه‌رو می‌شوید. پیش از بحران مشخص کنید:
- کدام طرف «مرجع» هر دسته از داده‌هاست (مثلاً سفارش‌های کاربران ایرانی: سرور داخلی).
- طرف غیرمرجع در زمان قطعی چه رفتاری دارد: فقط خواندنی، صف کردن تغییرات یا توقف موقت آن بخش.
- پس از برقراری ارتباط، تغییرات صف‌شده چطور اعمال و تعارض‌ها چطور حل می‌شوند.
- چه کسی تصمیم تغییر DNS یا جابه‌جایی نقش‌ها را می‌گیرد و با چه دستورالعملی.
Failover خودکار بین ایران و خارج معمولاً خطرناک است، چون از دید هر طرف «طرف دیگر از کار افتاده» به نظر می‌رسد. تغییر نقش‌ها را دستی و طبق دستورالعمل مکتوب انجام دهید.
ارتباط امن بین سرورها
ترافیک همگام‌سازی بین دو طرف (دیتابیس، فایل، صف) را روی اینترنت عمومی بدون رمزنگاری ارسال نکنید. یک تونل Site-to-Site رمزنگاری‌شده مثل WireGuard یا IPsec بین سرورهای خودتان بسازید و پورت‌های دیتابیس را فقط روی آن تونل باز کنید. در داخل هر طرف هم سرورها را با شبکه خصوصی به هم وصل کنید؛ راهنما در شبکه خصوصی سرور مجازی. توجه کنید که در زمان قطع ارتباط بین‌الملل، این تونل هم قطع می‌شود؛ معماری باید این حالت را تحمل کند.
آزمایش سناریوی قطعی
- در یک زمان کم‌ترافیک، با فایروال ارتباط سرور داخلی با سرور خارج را موقتاً قطع کنید.
- بررسی کنید سایت برای کاربر داخلی کامل کار می‌کند: ورود، جست‌وجو، ثبت سفارش و پرداخت.
- بررسی کنید صف‌ها پر می‌شوند و پس از برقراری ارتباط، بدون از دست رفتن داده تخلیه می‌شوند.
- زمان بازگشت همگام‌سازی و تاخیر تکثیر دیتابیس را اندازه بگیرید.
برای آماده‌سازی خود سرور داخلی هم چک‌لیست سرور مجازی در قطعی اینترنت را ببینید.
سوالات متداول
برای یک سایت فروشگاهی ایرانی، سرور خارج لازم است؟
اگر مشتریان داخلی‌اند و از درگاه پرداخت داخلی استفاده می‌کنید، معمولاً سرور داخلی کافی است. سرور خارج فقط برای کارهایی لازم است که به اینترنت بین‌الملل نیاز دارند.
می‌توان دیتابیس را بین ایران و خارج Master-Master کرد؟
از نظر فنی بله، اما با تاخیر بالا و احتمال قطع ارتباط، خطر تعارض داده زیاد است. الگوی یک مرجع برای هر دسته داده و تکثیر ناهمگام امن‌تر است.
کدام کشور برای سرور خارج مناسب‌تر است؟
بسته به مخاطب و سرویس‌های مورد نیاز دارد. برای اتصال به سرور داخلی، لوکیشن‌های اروپایی معمولاً پینگ کمتری تا ایران دارند.
هزینه این معماری خیلی بیشتر است؟
در الگوی «داخلی اصلی، خارجی کمکی»، سرور خارج می‌تواند کوچک باشد؛ پس هزینه اضافه معمولاً محدود است.
سرور ایران و ۱۱ لوکیشن خارج
سرور مجازی در دیتاسنتر تهران و لوکیشن‌های اروپا و آمریکا را از سرور مجازی تراست هاست تهیه کنید. برای طراحی و پیاده‌سازی معماری ترکیبی، خدمات پشتیبانی سرور را ببینید.
