Всяка страшна история за преместване има една и съща среда: някой първо сменил 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 запазва собствениците на файловете по номер, което предпазва от класическата изненада „всичко принадлежи на грешния потребител“, когато двете системи са създавали потребители в различен ред. Ако никога не сте ползвали 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. Оставете го включен и непроменен няколко дни. След това обновете всичко, което сочи към стария IP: allowlist на партньори, адреси на уебхуци, а за пощата — обратния DNS на новия адрес (при нашите тарифи със специален IP го задавате сами, вижте обратен DNS) и SPF записа.
Какво се чупи най-често
Горе-долу по реда, в който го виждаме: systemd таймер, който никой не е вписал, конфигурационен файл със стария IP, вписан на твърдо, файлове, принадлежащи на грешния потребител, файъруол, който блокира собствения порт на приложението, сертификат, който се подновява на стария сървър, но не и на новия, и поща, която отива в спам, защото новият адрес още няма обратен DNS.
Къде този чеклист не пасва
Натоварена база с постоянни записи и нулева търпимост към пауза има нужда от истинска репликация и репетиция, а не от чеклист от блог. Windows сървърите се местят с други инструменти, а не с rsync. И ако преместването всъщност е заради размера, прочетете първо това: тук тарифите растат на място. Преминаването към по-голяма тарифа от същия мрежов тип добавя vCPU, RAM и диск с един рестарт, без никакво преместване. Нов сървър трябва само за намаляване. Ако се местите, защото не сте сигурни дали машината стига, кога наистина ви трябват 64 GB RAM може да ви спести пътуването, а VPS, споделен хостинг, нает сървър или облак ще помогне, ако не сте сигурни, че VPS изобщо е правилният дом.
Коментари
Още няма коментари. Бъди първият.