كل قصة مرعبة عن نقل الخوادم لها الوسط نفسه: شخص غيّر DNS أولًا ثم بدأ النسخ. الانقطاع أثناء النقل لا يحدث تقريبًا أبدًا بسبب بطء النسخ. يحدث بسبب تنفيذ الخطوات بترتيب خاطئ.
هذا هو الترتيب الذي ينجح، سواء كنت تترك مزوّدًا آخر أو تنتقل بين باقتين من باقاتنا.
1. قبل يومين: اخفض TTL
حدّد سجلات DNS التي ستغيّرها (عادةً A وAAAA وأي CNAME يشير إليها) واخفض قيمة TTL لها إلى 300 ثانية. ثم انتظر على الأقل بمقدار TTL القديم. السجل الذي قيمة TTL له يوم واحد يعني أن بعض المحلّلات ستواصل تقديم العنوان القديم يومًا كاملًا بعد التغيير، ولا شيء تفعله على الخادم يسرّع ذلك.
هذه هي الخطوة التي يتخطاها الناس، وهي نفسها التي تحوّل تبديلًا مدته خمس دقائق إلى يوم يرى فيه نصف المستخدمين الخادم القديم.
2. اجرد محتويات الخادم القديم
ستعيد بناء هذا الجهاز في مكان آخر، فاكتب ما يفعله فعلًا. لا ما تتذكره. ما يفعله:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
أضف إلى القائمة: شهادات TLS وطريقة تجديدها، وملفات البيئة التي تحوي أسرارًا، وقواعد الجدار الناري، والمستخدمين ومفاتيح SSH الخاصة بهم، وقاعدة البيانات وحجمها، وكل ما يتواصل مع الخادم عبر عنوان IP. المجموعة الأخيرة هي الماكرة: قائمة السماح لدى شريك، وإعدادات webhook لدى مزوّد دفع، وفحص مراقبة.
3. جهّز الخادم الجديد بجانب القديم
اطلب الخادم الجديد واترك القديم وشأنه. اختر باقة من قائمة VPS بقرص مساوٍ لما تستخدمه فعلًا أو أكبر، لا لما بيع لك. إذا كان الجهاز القديم يستقبل أي حركة واردة (موقع، webhooks، واجهة API)، فالجديد يحتاج إلى IPv4 خاص به. باقة NAT لا تقبل الاتصالات الواردة إلا على منفذ SSH الخاص بها، ومقال ما الذي يستطيعه منفذ واحد محوَّل وما الذي لا يستطيعه يشرح لماذا يهم ذلك.
اتصل، وثبّت الحزم نفسها، وأعد إنشاء المستخدمين والجدار الناري. يغطي دليل الاتصال المفاتيح وأول تسجيل دخول.
4. زامن الملفات مرتين
المزامنة الأولى تنسخ كل شيء بينما يواصل الخادم القديم العمل. قد تستغرق ساعات؛ لا بأس.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
الخيار --numeric-ids يحافظ على ملكية الملفات بالأرقام، فيجنّبك المفاجأة الكلاسيكية «كل شيء يخص المستخدم الخطأ» عندما يكون النظامان قد أنشآ المستخدمين بترتيب مختلف. إن لم تستخدم rsync عبر SSH من قبل، فمقال كيف تنقل الملفات إلى VPS يشرحه خطوة بخطوة.
المزامنة الثانية، قبيل التبديل مباشرة، تنسخ فقط ما تغيّر منذ الأولى. وعادةً تستغرق ثوانيَ.
5. انقل قاعدة البيانات بوعي
الملفات سهلة. قاعدة البيانات التي تستقبل عمليات كتابة هي الجزء الوحيد الذي يتطلب فيه «دون انقطاع» إما تنازلًا صغيرًا وإما جهدًا أكبر.
الطريق البسيط: خذ تفريغًا واستعده مرة للاختبار، ثم عند التبديل أوقف الكتابة دقيقة (ضع التطبيق في وضع القراءة فقط أو أوقفه)، وخذ تفريغًا جديدًا، واستعده على الخادم الجديد، وشغّل التطبيق هناك. لمعظم المشاريع الصغيرة هذا توقف لدقيقة أو اثنتين، يُعلَن عنه مسبقًا.
الطريق بلا توقف: أعدّ نسخًا متماثلًا من قاعدة البيانات القديمة إلى الجديدة، ودعه يلحق، ثم رقِّ الجديدة إلى أساسية عند التبديل. إعداد أكثر، ويستحق ذلك عندما تكون حتى دقيقة من الكتابات المفقودة غير مقبولة.
6. اختبر الخادم الجديد قبل أن يراه غيرك
ما زال DNS يشير إلى الخادم القديم، لذا يمكنك اختبار الجديد بعيدًا عن الأعين. أرسل طلبًا لنطاقك الحقيقي إلى العنوان الجديد:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
إذا لم تكن الشهادة موجودة بعد، فاختبر بالطريقة نفسها عبر HTTP، أو أضف سطرًا مؤقتًا في ملف hosts وتجوّل في الموقع بالمتصفح. تحقّق من تسجيل الدخول والرفع والمهام الخلفية والبريد الصادر. هذه أرخص لحظة لاكتشاف إضافة PHP ناقصة.
7. بدّل، وأبقِ الخادم القديم يعمل
نفّذ المزامنة الأخيرة للملفات وخطوة قاعدة البيانات، ثم غيّر سجلات DNS. مع TTL قدره 300 ثانية تنتقل معظم الحركة خلال دقائق. راقب سجل الوصول في الخادم القديم: سيظل يصله قليل من الطلبات من محلّلات وعملاء يتجاهلون TTL. أبقِه يعمل دون تغيير بضعة أيام. ثم حدّث كل ما يشير إلى العنوان القديم: قوائم السماح لدى الشركاء، وروابط webhook، وللبريد DNS العكسي للعنوان الجديد (في باقاتنا ذات IP المخصّص تضبطه بنفسك، انظر DNS العكسي) وسجل SPF الخاص بك.
ما الذي يتعطل غالبًا
تقريبًا بترتيب تكرار ما نراه: مؤقت systemd لم يضعه أحد في القائمة، وملف إعدادات فيه العنوان القديم مكتوبًا مباشرة، وملفات يملكها المستخدم الخطأ، وجدار ناري يحجب منفذ التطبيق نفسه، وشهادة تتجدد على الخادم القديم لا الجديد، وبريد يذهب إلى الرسائل المزعجة لأن العنوان الجديد لا يملك DNS عكسيًا بعد.
حيث لا تناسب هذه القائمة
قاعدة بيانات مزدحمة بكتابات مستمرة ولا تحتمل أي توقف تحتاج إلى نسخ متماثل حقيقي وبروفة، لا إلى قائمة تحقق من مدوّنة. خوادم Windows تُنقل بأدوات غير rsync. وإن كان النقل في حقيقته يتعلق بالحجم، فاقرأ هذا أولًا: هنا تكبر الباقات في مكانها. الانتقال إلى باقة أكبر من نوع الشبكة نفسه يضيف vCPU والذاكرة والقرص بإعادة تشغيل واحدة، دون أي نقل. الخادم الجديد لازم للتصغير فقط. إن كنت تنتقل لأنك غير متأكد من أن الجهاز يكفي، فقد يوفّر عليك مقال متى تحتاج فعلًا إلى ذاكرة 64 GB هذه الرحلة، ويساعدك مقال VPS أم الاستضافة المشتركة أم الخادم المخصّص أم السحابة إن لم تكن متأكدًا أن VPS هو المكان المناسب أصلًا.
التعليقات
لا تعليقات بعد. كن الأول.