মাইগ্রেশনের প্রতিটি ভয়ের গল্পের মাঝের অংশ একই: কেউ আগে DNS বদলেছে, তারপর কপি শুরু করেছে। সরানোর সময় ডাউনটাইম প্রায় কখনোই কপি ধীর হওয়ার কারণে হয় না। হয় ধাপগুলো ভুল ক্রমে করার কারণে।
এই সেই ক্রম যা কাজ করে, আপনি অন্য প্রদানকারী ছেড়ে আসুন বা আমাদের দুটি প্ল্যানের মধ্যে সরুন।
১. দুই দিন আগে: TTL কমান
যেসব DNS রেকর্ড বদলাবেন সেগুলো খুঁজে বের করুন (সাধারণত A, AAAA আর সেগুলোর দিকে নির্দেশ করা যেকোনো CNAME), আর সেগুলোর TTL 300 সেকেন্ডে নামান। তারপর অন্তত পুরোনো TTL যতটা ছিল ততক্ষণ অপেক্ষা করুন। এক দিনের TTL-এর রেকর্ড মানে কিছু রিজলভার বদলের পরও এক দিন পুরোনো ঠিকানা দিতে থাকবে, আর সার্ভারে আপনি যাই করুন, তা দ্রুত হবে না।
এই ধাপটাই মানুষ বাদ দেয়, আর এটাই পাঁচ মিনিটের বদলকে এমন একটা দিনে পরিণত করে যখন অর্ধেক ব্যবহারকারী পুরোনো সার্ভার দেখেন।
২. পুরোনো সার্ভারের তালিকা করুন
আপনি এই মেশিন অন্য জায়গায় নতুন করে বানাবেন, তাই লিখে রাখুন এটা আসলে কী করে। যা মনে আছে তা নয়। যা করে তা:
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 ঠিকানা দিয়ে সার্ভারের সঙ্গে কথা বলে। শেষ দলটাই ধূর্ত: কোনো পার্টনারের allowlist, পেমেন্ট প্রদানকারীর ওয়েবহুক সেটিং, কোনো মনিটরিং চেক।
৩. নতুন সার্ভার পুরোনোটার পাশে দাঁড় করান
নতুন সার্ভার অর্ডার করুন, পুরোনোটায় হাত দেবেন না। VPS তালিকা থেকে এমন প্ল্যান বেছে নিন যার ডিস্ক আপনার আসল ব্যবহারের সমান বা বেশি, যা আপনাকে বিক্রি করা হয়েছিল তার নয়। পুরোনো মেশিনে কোনো ইনবাউন্ড ট্রাফিক এলে (ওয়েবসাইট, ওয়েবহুক, API), নতুনটার নিজস্ব IPv4 লাগবে। NAT প্ল্যান শুধু নিজের SSH পোর্টে ইনবাউন্ড সংযোগ নেয়, আর কেন সেটা গুরুত্বপূর্ণ তা ব্যাখ্যা করে একটি ফরওয়ার্ড করা পোর্ট কী পারে আর কী পারে না।
সংযোগ করুন, একই প্যাকেজ ইনস্টল করুন, ব্যবহারকারী আর ফায়ারওয়াল আবার তৈরি করুন। কী আর প্রথম লগইন আছে সংযোগ গাইডে।
৪. ফাইল দুবার সিঙ্ক করুন
প্রথম সিঙ্ক সব কিছু কপি করে যখন পুরোনো সার্ভার কাজ চালিয়ে যায়। কয়েক ঘণ্টা লাগতে পারে; অসুবিধা নেই।
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids ফাইলের মালিকানা নম্বর ধরে রাখে, ফলে দুটি সিস্টেম ভিন্ন ক্রমে ব্যবহারকারী তৈরি করলে যে চিরচেনা চমক ঘটে, "সব কিছু ভুল ব্যবহারকারীর", সেটা এড়ানো যায়। SSH দিয়ে rsync কখনো না চালিয়ে থাকলে, VPS-এ ফাইল কীভাবে পাঠাবেন ধাপে ধাপে দেখায়।
দ্বিতীয় সিঙ্ক, বদলানোর ঠিক আগে, শুধু প্রথমটার পর যা বদলেছে তা কপি করে। সাধারণত কয়েক সেকেন্ড লাগে।
৫. ডেটাবেস ভেবেচিন্তে সরান
ফাইল সহজ। লেখা গ্রহণ করা ডেটাবেসই একমাত্র অংশ যেখানে "ডাউনটাইম ছাড়া" মানে হয় ছোট একটা আপস, নয়তো বাড়তি খাটুনি।
সহজ পথ: পরীক্ষার জন্য একবার ডাম্প নিয়ে রিস্টোর করুন, তারপর বদলানোর সময় এক মিনিটের জন্য লেখা থামান (অ্যাপকে শুধু-পড়া মোডে নিন বা বন্ধ করুন), নতুন ডাম্প নিন, নতুন সার্ভারে রিস্টোর করুন আর অ্যাপ সেখানে চালু করুন। বেশিরভাগ ছোট প্রজেক্টের জন্য এটা এক-দুই মিনিটের বিরতি, আগে থেকে জানিয়ে রাখা যায়।
বিরতি ছাড়া পথ: পুরোনো ডেটাবেস থেকে নতুনটায় রেপ্লিকেশন সেট করুন, সেটাকে ধরে ফেলতে দিন, আর বদলানোর সময় নতুনটাকে প্রধান করুন। প্রস্তুতি বেশি, আর এক মিনিটের হারানো লেখাও যখন অগ্রহণযোগ্য, তখন এটা মূল্যবান।
৬. অন্য কেউ দেখার আগে নতুন সার্ভার পরীক্ষা করুন
DNS এখনও পুরোনো সার্ভারের দিকে, তাই নতুনটা নিভৃতে পরীক্ষা করতে পারেন। আপনার আসল ডোমেইনের অনুরোধ নতুন ঠিকানায় পাঠান:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
সার্টিফিকেট এখনও না থাকলে একইভাবে HTTP দিয়ে পরীক্ষা করুন, অথবা hosts ফাইলে অস্থায়ী লাইন যোগ করে ব্রাউজারে সাইটটা ঘুরে দেখুন। লগইন, আপলোড, ব্যাকগ্রাউন্ড কাজ আর বহির্গামী মেইল যাচাই করুন। হারানো PHP এক্সটেনশন খুঁজে পাওয়ার সবচেয়ে সস্তা মুহূর্ত এটাই।
৭. বদলান, আর পুরোনো সার্ভার চালু রাখুন
শেষ ফাইল সিঙ্ক আর ডেটাবেসের ধাপ সারুন, তারপর DNS রেকর্ড বদলান। 300 সেকেন্ডের TTL-এ বেশিরভাগ ট্রাফিক কয়েক মিনিটে সরে যায়। পুরোনো সার্ভারের অ্যাক্সেস লগে নজর রাখুন: TTL উপেক্ষা করা রিজলভার আর ক্লায়েন্ট থেকে সেখানে এখনও অল্প অল্প অনুরোধ আসবে। কয়েক দিন অপরিবর্তিত অবস্থায় চালু রাখুন। তারপর পুরোনো IP-র দিকে নির্দেশ করা সব কিছু হালনাগাদ করুন: পার্টনারের allowlist, ওয়েবহুক URL, আর মেইলের জন্য নতুন ঠিকানার রিভার্স DNS (আমাদের ডেডিকেটেড IP প্ল্যানে আপনি নিজেই সেট করেন, দেখুন রিভার্স DNS) ও আপনার SPF রেকর্ড।
যা সবচেয়ে বেশি ভাঙে
মোটামুটি যত ঘন ঘন আমরা দেখি সেই ক্রমে: একটা systemd টাইমার যা কেউ তালিকায় রাখেনি, পুরোনো IP সরাসরি লেখা কনফিগ ফাইল, ভুল ব্যবহারকারীর মালিকানার ফাইল, অ্যাপের নিজের পোর্ট আটকে দেওয়া ফায়ারওয়াল, পুরোনো সার্ভারে নবায়ন হওয়া কিন্তু নতুনটায় না হওয়া সার্টিফিকেট, আর স্প্যামে যাওয়া মেইল, কারণ নতুন ঠিকানার এখনও রিভার্স DNS নেই।
যেখানে এই চেকলিস্ট খাটে না
অবিরাম লেখা আর বিরতির প্রতি শূন্য সহনশীলতার ব্যস্ত ডেটাবেসের দরকার আসল রেপ্লিকেশন আর একটা মহড়া, ব্লগের চেকলিস্ট নয়। Windows সার্ভার rsync-এর বদলে অন্য টুলে সরানো হয়। আর সরানোর আসল কারণ যদি আকার হয়, তাহলে আগে এটা পড়ুন: এখানে প্ল্যান সেখানেই বাড়ে। একই নেটওয়ার্ক ধরনের বড় প্ল্যানে গেলে কোনো সরানো ছাড়াই একবার রিবুটে vCPU, RAM আর ডিস্ক বাড়ে। নতুন সার্ভার লাগে শুধু ছোট করতে। মেশিন যথেষ্ট কি না নিশ্চিত না হয়ে সরতে চাইলে, কখন সত্যিই 64 GB RAM লাগে আপনার এই যাত্রা বাঁচাতে পারে, আর VPS আদৌ সঠিক ঠিকানা কি না নিশ্চিত না হলে VPS বনাম শেয়ার্ড হোস্টিং বনাম ডেডিকেটেড বনাম ক্লাউড সাহায্য করবে।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।