გადასვლის ყველა საშინელ ისტორიას ერთი და იგივე შუა ნაწილი აქვს: ვიღაცამ ჯერ 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 მისამართით მიმართავს. ბოლო ჯგუფი ყველაზე მზაკვრულია: პარტნიორის allowlist, გადახდის პროვაიდერის ვებჰუკების პარამეტრები, მონიტორინგის შემოწმება.
3. ააწყვეთ ახალი სერვერი ძველის გვერდით
შეუკვეთეთ ახალი სერვერი, ძველს კი ნუ შეეხებით. აირჩიეთ ტარიფი VPS-ების სიიდან იმავე ან უფრო დიდი დისკით, ვიდრე რეალურად იყენებთ და არა ვიდრე მოგყიდეს. თუ ძველ მანქანაზე რაიმე შემომავალი ტრაფიკი მოდის (საიტი, ვებჰუკები, API), ახალს საკუთარი IPv4 სჭირდება. NAT ტარიფი შემომავალ კავშირებს მხოლოდ თავის SSH პორტზე იღებს, ხოლო რატომ არის ეს მნიშვნელოვანი, ხსნის სტატია რა შეუძლია და რა არ შეუძლია ერთ გადამისამართებულ პორტს.
დაუკავშირდით, დააყენეთ იგივე პაკეტები, თავიდან შექმენით მომხმარებლები და ფაირვოლი. გასაღებები და პირველი შესვლა აღწერილია დაკავშირების სახელმძღვანელოში.
4. დაასინქრონეთ ფაილები ორჯერ
პირველი სინქრონიზაცია ყველაფერს აკოპირებს, სანამ ძველი სერვერი მუშაობას აგრძელებს. შეიძლება საათობით გაგრძელდეს — ეს ნორმალურია.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids ფაილების მფლობელებს ნომრის მიხედვით ინარჩუნებს, რაც გიცავთ კლასიკური სიურპრიზისგან „ყველაფერი არასწორ მომხმარებელს ეკუთვნის“, როცა ორმა სისტემამ მომხმარებლები სხვადასხვა რიგით შექმნა. თუ SSH-ით rsync ჯერ არ გამოგიყენებიათ, სტატია როგორ გადავიტანოთ ფაილები VPS-ზე ამას ნაბიჯ-ნაბიჯ განიხილავს.
მეორე სინქრონიზაცია, ზუსტად გადართვის წინ, მხოლოდ იმას აკოპირებს, რაც პირველის შემდეგ შეიცვალა. ჩვეულებრივ წამებს გრძელდება.
5. ბაზა შეგნებულად გადაიტანეთ
ფაილებთან ყველაფერი მარტივია. ბაზა, რომელიც ჩანაწერებს იღებს, ერთადერთი ადგილია, სადაც „შეფერხების გარეშე“ ან მცირე კომპრომისს, ან დამატებით შრომას მოითხოვს.
მარტივი გზა: ერთხელ გააკეთეთ დამპი და აღადგინეთ ტესტისთვის, ხოლო გადართვისას ჩაწერა ერთი წუთით შეაჩერეთ (აპლიკაცია მხოლოდ კითხვის რეჟიმში გადაიყვანეთ ან გააჩერეთ), გადაიღეთ ახალი დამპი, აღადგინეთ ახალ სერვერზე და იქ გაუშვით აპლიკაცია. მცირე პროექტების უმეტესობისთვის ეს ერთ-ორწუთიანი პაუზაა, რომლის შესახებაც წინასწარ შეიძლება გააფრთხილოთ.
პაუზის გარეშე გზა: ააწყვეთ რეპლიკაცია ძველი ბაზიდან ახალში, მიეცით დაწევის საშუალება და გადართვისას ახალი ბაზა მთავრად აქციეთ. მეტი გამართვაა, და ეს ღირს, როცა თუნდაც ერთი წუთის დაკარგული ჩანაწერები მიუღებელია.
6. შეამოწმეთ ახალი სერვერი, სანამ სხვა დაინახავს
DNS ისევ ძველ სერვერზე მიუთითებს, ამიტომ ახლის შემოწმება მოწმეების გარეშე შეგიძლიათ. გაგზავნეთ მოთხოვნა თქვენს ნამდვილ დომენზე ახალ მისამართზე:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
თუ სერტიფიკატი ჯერ არ არის, ასევე შეამოწმეთ HTTP-ით ან hosts ფაილში დროებითი სტრიქონი დაამატეთ და საიტი ბრაუზერში დაათვალიერეთ. შეამოწმეთ შესვლა, ფაილების ატვირთვა, ფონური ამოცანები და გამავალი ფოსტა. ეს ყველაზე იაფი მომენტია PHP-ის დაკარგული გაფართოების აღმოსაჩენად.
7. გადართეთ და ძველი სერვერი ნუ გამორთავთ
გააკეთეთ ფაილების ბოლო სინქრონიზაცია და ბაზის ნაბიჯი, მერე შეცვალეთ DNS ჩანაწერები. 300-წამიანი TTL-ით ტრაფიკის უმეტესი ნაწილი წუთებში გადავა. თვალი ადევნეთ ძველი სერვერის წვდომის ლოგს: იქ ისევ შემოვა მცირე ნაკადი იმ რეზოლვერებიდან და კლიენტებიდან, რომლებიც TTL-ს უგულებელყოფენ. დატოვეთ ის ჩართული და უცვლელი რამდენიმე დღით. მერე განაახლეთ ყველაფერი, რაც ძველ IP-ზე მიუთითებს: პარტნიორების allowlist-ები, ვებჰუკების მისამართები, ხოლო ფოსტისთვის — ახალი მისამართის უკუ DNS (ჩვენს გამოყოფილი IP-ის ტარიფებზე მას თავად აყენებთ, იხ. უკუ DNS) და SPF ჩანაწერი.
რა ფუჭდება ყველაზე ხშირად
დაახლოებით იმ სიხშირის მიხედვით, რითაც ამას ვხედავთ: systemd ტაიმერი, რომელიც არავინ შეიტანა სიაში, კონფიგი ხისტად ჩაწერილი ძველი IP-ით, არასწორი მომხმარებლის კუთვნილი ფაილები, ფაირვოლი, რომელიც აპლიკაციის საკუთარ პორტს ბლოკავს, სერტიფიკატი, რომელიც ძველ სერვერზე ნახლდება, ახალზე კი არა, და ფოსტა, რომელიც სპამში ხვდება, რადგან ახალ მისამართს ჯერ უკუ DNS არ აქვს.
სად არ ერგება ეს ჩეკლისტი
დატვირთულ ბაზას მუდმივი ჩანაწერებით და პაუზის მიმართ ნულოვანი შემწყნარებლობით ნამდვილი რეპლიკაცია და რეპეტიცია სჭირდება და არა ჩეკლისტი ბლოგიდან. Windows სერვერები სხვა ინსტრუმენტებით გადადის და არა rsync-ით. და თუ გადასვლა სინამდვილეში ზომას ეხება, ჯერ ეს წაიკითხეთ: აქ ტარიფები ადგილზევე იზრდება. იმავე ქსელური ტიპის უფრო დიდ ტარიფზე გადასვლა vCPU-ს, RAM-ს და დისკს ერთი გადატვირთვით ამატებს, ყოველგვარი გადასვლის გარეშე. ახალი სერვერი მხოლოდ შემცირებისთვის გჭირდებათ. თუ გადადიხართ იმიტომ, რომ დარწმუნებული არ ხართ, ყოფნის თუ არა მანქანა, სტატია როდის გჭირდებათ ნამდვილად 64 GB RAM შესაძლოა ამ მოგზაურობისგან გაგათავისუფლოთ, ხოლო VPS, shared ჰოსტინგი, გამოყოფილი სერვერი თუ ღრუბელი დაგეხმარებათ, თუ არ ხართ დარწმუნებული, რომ VPS საერთოდ სწორი სახლია.
კომენტარები
ჯერ არ არის კომენტარები. იყავით პირველი.