جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
مدیر فروش می‌پرسد: اگر یک مشتری از داخل و یکی از خارج، همزمان آخرین کالای انبار را بخرند، کدام سفارش ثبت می‌شود؟ معماری هیبرید سرور پیش از انتخاب هر ابزاری باید به این سؤال جواب بدهد. سایتی با یک سرور در ایران و یکی در خارج، اول از همه دو نسخه از داده به دست می‌آورد.
- اگر کد و فایل ثابت است ← یک نسخه روی هر دو.
- اگر آپلود کاربر است ← یک پذیرنده، یک کپی.
- اگر دیتابیس است ← یک source و یک replica خواندنی.
- اگر نشست کاربر است ← ماندن روی همان لوکیشن.
- اگر مانیتورینگ است ← ناظری روی شبکه سوم با هشدار.
💡 دو لوکیشن، یک صاحب برای هر داده
طرح هیبرید: یک سرور داخل ایران، یک سرور خارج، و هر بازدیدکننده روی یکی.
✅ پیش از خرید سرور دوم، صاحب هر داده را بنویسید.
✅ هر دو نشانی را از دو سوی مرز بیازمایید.
تصمیم دشوار این است که کدام داده حق دارد چند دقیقه کهنه بماند. CSS دیروزی آسیبی ندارد؛ موجودی انبار کهنه یعنی فروش کالایی که دیگر نیست. هر روش همگام‌سازی را باید با همین معیار سنجید.
📌 داده‌ای که در دو جا زندگی می‌کند
◀️ کدام بخش سایت باید در دو لوکیشن باشد؟
◀️ تقسیم سرویس‌ها بر اساس جهت نوشتن
◀️ ابزار همگام‌سازی را از روی جهت داده انتخاب کنید
◀️ مسیریابی با GeoDNS و هزینه TTL
کدام بخش سایت باید در دو لوکیشن باشد؟
کد و فایل‌های ثابت را هر دو سرور از یک مخزن برمی‌دارند؛ سرور اصلی برنامه (origin) در هر لوکیشن کل سایت را اجرا می‌کند. دیتابیس و آپلود کاربر صاحب مشخص می‌خواهند. طراحی معماری هیبرید سرور با این فهرست شروع می‌شود: کنار هر جزء بنویسید چه کسی آن را تغییر می‌دهد.
طرح روی کاغذ تا وقتی آزمون‌های تست دسترسی سایت از ایران را از هر دو طرف پس نداده فقط یک فرض است.
جزءهایی که فقط یک صاحب دارند
دیتابیس سفارش‌ها و پوشه آپلود فهرست کمبودهای یخچال‌اند، وقتی خانواده در خانه شهری و ییلاقی دو فهرست جدا بنویسد: آخر هفته معلوم نیست کدام درست است، تا یکی از دو یخچال مرجع شود. در سایت، مرجع لوکیشنی است که تنها نویسنده آن داده است.
نشست کاربر (session) معمولاً روی سروری می‌ماند که کاربر به آن رسیده. یا کاربر را تا پایان نشست روی یک لوکیشن نگه دارید؛ یا نشست را در دیتابیس نویسنده بگذارید و تأخیر بین دو کشور را بپذیرید.
💡 قانون تک‌نویسنده
هر داده فقط در یک لوکیشن تغییر می‌کند. با یک نویسنده جواب سؤال مدیر فروش روشن است: تراکنش روی source تصمیم می‌گیرد و آخرین کالا دو بار فروخته نمی‌شود.
سرویس‌ها بر اساس جهت نوشتن داده بین داخل و خارج تقسیم می‌شوند
جهت بیشتر نوشتن‌ها جای نویسنده را در معماری هیبرید سرور تعیین می‌کند. اگر سفارش‌ها بیشتر از داخل ایران می‌آید، دیتابیس source در ایران می‌نشیند و سرور خارج فقط نسخه خواندنی دارد. با مشتریان بیشتر در خارج جهت برعکس می‌شود و سرور ایران نسخه نزدیک خواننده داخلی است.
نویسنده در ایران، خواننده در دو طرف
جریان replication و آپلودها یک‌طرفه از ایران به خارج است. برنامه سرور خارج خواندن را از replica محلی و نوشتن را از source ایران می‌گیرد. برنامه‌ای که هنگام نمایش صفحه هم می‌نویسد، روی replica خطا می‌دهد؛ این تفکیک را پیش از راه‌اندازی بیازمایید.
هر نوشتن خارجی منتظر یک رفت‌وبرگشت بین دو کشور می‌ماند. پورت دیتابیس را در فایروال فقط برای IP سرور مقابل باز کنید و اتصال رمزنگاری‌شده بخواهید؛ در MySQL کاربر replication با REQUIRE SSL ساخته می‌شود و replica با SOURCE_SSL=1 وصل می‌شود. حساب برنامه روی replica هم فقط مجوز خواندن بگیرد.
جای ایمیل و بکاپ
صندوق‌های ایمیل یک‌جا می‌مانند و رکورد MX بیرون از GeoDNS. بکاپ نسخه‌دار هر لوکیشن روی لوکیشن مقابل می‌نشیند. سرور خارج و ناظر بیرونی باید بی‌واسطه به سرور داخل وصل شوند. روی سرور داخلی وب‌داده، این اتصال به IP مستقیم خود سرور می‌رسد که با IPv4 و IPv6 از بیرون ایران هم در دسترس است.
ابزار همگام‌سازی را از روی جهت داده انتخاب کنید
داده یک‌طرفه با rsync یا replication جابه‌جا می‌شود؛ داده با دو نویسنده به مخزن مرکزی یا ابزاری می‌رود که تعارض را علامت می‌زند. پیامد آپلود هم‌نام در چهار روش:
| روش | جهت داده | آپلود هم‌نام از دو طرف | عقب‌ماندگی | پیچیدگی |
|---|---|---|---|---|
| ارسال با rsync | یک‌طرفه از نویسنده | پیش نمی‌آید، اگر مقصد ننویسد | تا اجرای بعدی | کم |
| پوشه Syncthing | دوطرفه یا Send Only | هر دو می‌مانند؛ یکی با نام sync-conflict | وابسته به اتصال دو دستگاه | متوسط |
| مخزن ذخیره‌سازی شیء | هر دو در یک مخزن | آخرین نوشتن می‌ماند و دیگری بی‌صدا حذف می‌شود | فاصله هر سرور تا مخزن | متوسط |
| تکثیر دیتابیس | یک‌طرفه از source | ربطی ندارد | ناهمزمان در پیش‌فرض | زیاد |
مستند S3 در AWS می‌گوید از دو PUT همزمان روی یک کلید، درخواست دیرتر می‌ماند. پس مخزن مرکزی فقط با نام یکتا برای هر آپلود برتری دارد، و دست‌کم یکی از دو سرور برای رسیدن به آن از مرز می‌گذرد.
ابزار rsync برای آپلودهای یک‌طرفه
طبق صفحه راهنمای rsync گزینه -a معادل -rlptgoD است و ACLها و هاردلینک‌ها را شامل نمی‌شود. انتقال راه دور معمولاً روی ssh است و --partial فایل نیمه‌کاره را نگه می‌دارد. با کاربر غیر root در مقصد، مالک فایل‌ها همان کاربر می‌شود؛ وب‌سرور باید بتواند آن‌ها را بخواند.
rsync -ai --delete --partial --dry-run SRC_DIR/ deploy@FOREIGN_HOST:DEST_DIR/راهنما --delete را خطرناک می‌داند و اول --dry-run را پیشنهاد می‌کند؛ -i فهرست تغییرات را نشان می‌دهد. بعد --dry-run را بردارید و اجرا را به زمان‌بند سیستم بسپارید. اگر مقصد روزی خودش آپلود بپذیرد، --delete فایل‌های تازه آن طرف را پاک می‌کند.
ابزار Syncthing و پوشه‌ای با دو نویسنده
مستند Syncthing می‌گوید وقتی فایلی همزمان روی دو دستگاه تغییر کند، نسخه با زمان تغییر قدیمی‌تر به <filename>.sync-conflict-<date>-<time>-<modifiedBy>.<ext> تغییر نام می‌دهد و مثل فایل معمولی پخش می‌شود. پوشه Send Only روی نویسنده و Receive Only روی سرور دیگر، Syncthing را یک‌طرفه می‌کند.
سرویس relay در پیش‌فرض Syncthing روشن است و بدون اتصال مستقیم، داده رمزنگاری‌شده از سرور سوم می‌گذرد. برای دو سرور نشانی ایستای دستگاه مقابل را با پیشوند tcp:// وارد کنید و گزینه‌های relaysEnabled و globalAnnounceEnabled را خاموش کنید.
⚠️ فایل‌های sync-conflict در پوشه آپلود
دو آپلود هم‌نام همزمان در دو لوکیشن یعنی یک فایل sync-conflict که سایت به آن لینک نمی‌دهد؛ آن آپلود از دید کاربر گم می‌شود.
تکثیر دیتابیس در MySQL و PostgreSQL
مستند replication در MySQL 8.4 تکثیر از source به replica را در پیش‌فرض ناهمزمان می‌داند. در PostgreSQL 18 هم streaming replication در پیش‌فرض ناهمزمان است و standby فقط خواندن می‌پذیرد.
تصمیم اصلی هر معماری هیبرید سرور همین‌جاست: replica کمی عقب بماند یا هر commit منتظر ارتباط بین‌المللی بماند. در حالت نیمه‌همزمان MySQL هر commit تا تأیید دریافت دست‌کم یک replica صبر می‌کند و اگر مهلت بدون تأیید تمام شود، source به حالت ناهمزمان برمی‌گردد.
⚠️ نوشتن دوطرفه در دیتابیس
نوشتن روی هر دو دیتابیس به سفارش تکراری یا موجودی دو بار کم‌شده می‌رسد. مستند MySQL در سناریوی پخش بار همه نوشتن‌ها را روی source می‌خواهد.
مسیریابی کاربر با GeoDNS و هزینه پنهان TTL
مستند بک‌اند GeoIP در PowerDNS کار GeoDNS را فرستادن بازدیدکننده به سرور نزدیک‌تر می‌داند. هر تغییر پاسخ تا پایان TTL ذخیره‌شده در resolver به کاربر نمی‌رسد.
موقعیت چه کسی سنجیده می‌شود
سرور DNS معمولاً نشانی resolver را می‌بیند؛ بک‌اند GeoIP فقط با EDNS Client Subnet در پرس‌وجو و edns-subnet-processing روشن، زیرشبکه کاربر را به کار می‌برد. کاربر داخلی با resolver خارجی ممکن است به سرور خارج برسد، پس هر دو سرور کل سایت را تحویل می‌دهند. برای گواهی TLS، مستند Let’s Encrypt روش DNS-01 را برای چند وب‌سرور مناسب می‌داند.
بررسی سلامت و سرعت جابه‌جایی
صفحه بک‌اند GeoIP بررسی سلامتی توصیف نمی‌کند و برای کنار گذاشتن خوشه به رکوردهای Lua ارجاع می‌دهد. پس معماری هیبرید سرور با GeoDNS تنها، سرور خراب را دور نمی‌زند. تابع‌های ifportup و ifurlup در رکوردهای Lua فقط نشانی‌های پاسخ‌گو به آزمون پورت یا HTTP را برمی‌گردانند.
در RFC 1035، TTL مدت مجاز ذخیره رکورد است؛ با 3600 ثانیه، جابه‌جایی تا یک ساعت طول می‌کشد. اگر سرور DNS نام‌دار در دسترس نباشد، RFC 8767 به resolverها اجازه می‌دهد داده کهنه را تحویل دهند و سقف پیشنهادی آن را ۱ تا ۳ روز می‌گذارد. ترکیب آماده دو هاست و GeoDNS را صفحه سرویس GeoHost بررسی می‌کند.
نام میزبان جدا برای بخش‌های نوشتنی
بخش خرید روی نامی که فقط به سرور نویسنده اشاره می‌کند و صفحه‌های خواندنی با GeoDNS. این نام گواهی TLS خودش را لازم دارد و دامنه کوکی ورود باید هر دو نام را بپوشاند. «سفارش‌های من» هم از source خوانده می‌شود.
اگر سایت شما بیشتر خواننده دارد و چند دقیقه قطعی را تحمل می‌کند، یک سرور با بکاپ در لوکیشن دوم شاید کافی باشد. سرور دوم یعنی استقرار دوباره و پایش replication؛ وقتی می‌ارزد که کندی یک سوی مرز برایتان مشتری از دست‌رفته باشد.
سرور هیبرید در سایت‌های میزبانی خارجی همان طرح ایران و خارج است؟
همیشه نه. میزبانی مثل M5 Hosting این نام را برای سرور فیزیکی مجازی‌شده بین چند مشتری به کار می‌برد.
پوشه آپلود وردپرس را با rsync همگام کنم یا Syncthing؟
با یک پذیرنده، هر دو کار می‌کنند. با دو پذیرنده، Syncthing هر دو فایل هم‌نام را نگه می‌دارد، ولی مخزن مرکزی بدون نام یکتا یکی را بی‌صدا رونویسی می‌کند.
می‌شود روی هر دو دیتابیس همزمان نوشت؟
در replication معمولی نوشتن روی source است؛ در MySQL این قاعده را با مجوزها خودتان اعمال می‌کنید. برای تکثیر همزمان، MySQL سراغ NDB Cluster را می‌دهد.
مقدار TTL رکوردهای سایت را چند بگذارم؟
عدد جهانی ندارد. TTL کوتاه‌تر را دست‌کم به اندازه TTL قبلی زودتر از تغییر منتشر کنید؛ برای قطعی ناگهانی این فرصت نیست.
کاربری که DNS عمومی خارجی دارد به کدام سرور می‌رسد؟
بدون EDNS Client Subnet موقعیت resolver ملاک است و ممکن است به سرور خارج برسد.
ایمیل سایت را هم روی هر دو سرور بگذارم؟
بهتر است نه. صندوق‌ها را یک‌جا نگه دارید و رکورد MX را از GeoDNS جدا کنید.
نسخه replica در لوکیشن دوم بکاپ هم حساب می‌شود؟
نه. replica حذف اشتباه را هم تکرار می‌کند و --delete حذف فایل را به مقصد می‌برد.
جمع‌بندی؛ معماری هیبرید سرور را از روی جهت داده بچینید برای هر نوع داده یک صاحب تعیین کنید. دیتابیس یک source و یک replica خواندنی دارد، با ارتباط رمزنگاری‌شده میان IP دو سرور. آپلودها با rsync یک‌طرفه کپی می‌شوند یا با نام یکتا به مخزن مرکزی می‌روند. replication ناهمزمان کمی عقب می‌ماند و نیمه‌همزمان هر نوشتن را منتظر ارتباط بین‌المللی می‌گذارد. GeoDNS بدون بررسی سلامت سرور خراب را دور نمی‌زند و هر تغییرش تا پایان TTL طول می‌کشد. بکاپ نسخه‌دار را در لوکیشن مقابل بگذارید و هر دو نشانی را از شبکه‌های دو طرف بیازمایید.
🚀 یکی از دو سرور فقط از یک اپراتور باز نمی‌شود؟
پیش از تغییر رکوردهای GeoDNS، جای خرابی را پیدا کنید.
در سایت خودتان، چه چیزی را فقط در یک لوکیشن نگه می‌دارید؟
منبع گزینه‌ها و پیش‌فرض‌ها
- راهنمای rsync: rsync(1)
- مستند Syncthing: Understanding Synchronization
- مستند MySQL 8.4: Replication
- مستند PowerDNS: GeoIP backend
- استاندارد DNS: RFC 1035 و RFC 8767
- مستندهای PostgreSQL 18 و S3 و Let’s Encrypt
