Хостинг переехал на новый сервер за ночь: что мы сделали 7–8 ноября, что пошло не так и что проверить на своём сайте

В ночь с 7 на 8 ноября мы переустановили сервер, на котором живут сайты и почта клиентов нашего хостинга. Старая система, CloudLinux 8, уступила место CloudLinux 9 с новой версией панели. Клиентов предупредили письмом за сутки с лишним и назвали окно с 22:00 до 08:00 по Москве.

Сайты не работали с 22:00 до 00:32, когда загрузился новый сервер. К 01:00 все 247 активных сайтов отвечали так же, как на старом. Но ночь прошла не по плану: отказал диск, около 90 сайтов ещё 20 минут после загрузки отдавали ошибку 503, а с 01:38 примерно 45 минут у большинства доменов на наших DNS-серверах не работали адреса. Последнее целиком наша ошибка. Ниже по порядку, а во второй половине чек-лист: что проверить на своём сайте после любых ночных работ хостинга, не только наших.

Как мы готовились

Переустановить сервер с сотнями сайтов «вживую» нельзя: пока ставится система, сайтов нет. Поэтому новую систему мы собрали заранее на отдельном тестовом сервере. Туда перенесли копии всех аккаунтов, настроили панель, почту и PHP так же, как на рабочем сервере, и несколько раз прогнали переезд целиком. После каждой репетиции сверяли ответы всех сайтов со старым сервером: код ответа и размер страницы.

Ночью оставалось немного. В 22:00 мы остановили сайты, почту и вход по FTP и SSH на старом сервере, чтобы данные перестали меняться. Догнали на тестовый сервер то, что изменилось за последние дни: файлы, почту, базы данных. Перенесли эту систему на диски рабочего сервера и загрузили его. IP-адрес не менялся, поэтому в DNS клиентам ничего править не нужно.

Что пошло не так

Второй диск не ответил

В сервере два диска, данные на них зеркалируются. Когда мы перезагрузили сервер в режим переноса, один из них не ответил, не помогло и полное выключение питания. Мы решили не откладывать и переносить систему на один исправный диск: подготовленная копия на тестовом сервере оставалась второй копией данных. Дата-центр заменил диск той же ночью, сразу после копирования, а в 01:54 зеркало на двух дисках снова было собрано.

Последние аккаунты не попали в копию

Задания копирования мы разбили по размеру аккаунтов заранее, а несколько аккаунтов появились на тестовом сервере позже. Проверка после копирования нашла расхождение, и исправляющий проход дописал недостающее. Повторная проверка показала, что данные совпадают.

Около 90 сайтов отдавали 503

После загрузки часть сайтов отвечала ошибкой. Каждый аккаунт на хостинге работает в своей изолированной среде (CageFS), и её общий каркас при переносе не скопировался. Без него PHP сайтов не запускался. Каркас пересоздали, к 00:52 сайты открылись, первый запрос у некоторых шёл 25–35 секунд, пока PHP прогревался. Для следующих переносов записали: каркас не копировать, а создавать заново.

45 минут без DNS: наша ошибка

Это главное, что могли заметить клиенты. Зоны доменов, которые смотрят на наши ns1.siteko.net и ns2.siteko.net, хранятся на сервере хостинга. ns1 и ns2 берут их оттуда и узнают, какие зоны обслуживать, по служебному списку. При переносе наш скрипт перенёс сами зоны, но в этот список попали только 5 из 405. В 01:38 ns1 и ns2 увидели новый сервер, послушно удалили зоны, которых нет в списке, и начали отвечать ошибкой.

Публичные DNS-серверы (Google, Яндекс, провайдеры) отдавали SERVFAIL, то есть «не могу получить ответ». Сайт по имени не открывался у тех, у кого адрес не был закэширован. Письма на такие домены отправители откладывали и повторяли позже. У одного нового клиента в это время не выпустился сертификат Let's Encrypt: проверка записи CAA получила ту же ошибку, и сертификат выпустили повторно уже после восстановления.

Список исправили к 02:16, к 02:25 ns1 и ns2 снова отдавали все зоны. Теперь в процедуре переноса есть отдельная проверка: пока список зон на новом сервере не совпадёт со старым, ns1 и ns2 его не увидят.

Мелочи в панели

Около двух часов ночи нашлись две ошибки в панели: пустая форма настроек сайта (виноват наш собственный модуль) и страница «не найдено» сразу после входа (из-за старой настройки часовых поясов). Обе исправили за несколько минут. А до 02:46 новые сайты без файлов и приостановленные сайты показывали заводские заглушки панели вместо наших. Их тоже вернули той же ночью.

Как это устроено на Siteko. Перед работами, которые останавливают сайты, мы пишем клиентам на почту, указанную в кабинете, и называем окно с запасом. Резервные копии хранятся вне сервера, а перенос мы сначала репетируем на отдельном сервере. Если после работ что-то ведёт себя не так, как раньше, напишите в поддержку в личном кабинете: такие обращения мы разбираем первыми.

Что проверить на сайте утром после работ хостинга

Хостинг проверяет, что сайты отвечают. Но он не знает, что у вас в корзине должен оформиться заказ, а форма заявки должна дойти до менеджера. Эту часть быстрее проверить самим. На всё уходит минут пятнадцать.

Сайт и админка. Откройте главную и пару внутренних страниц, лучше в приватном окне браузера, чтобы не смотреть на кэш. Зайдите в админку и сохраните что-нибудь безобидное: черновик, настройку. Ошибка при сохранении часто означает, что сайт не может писать в свою папку или в базу.

Формы и письма. Отправьте заявку с формы на сайте и убедитесь, что письмо пришло. Затем напишите на свой ящик на домене с внешней почты и ответьте с него. Письма, которые пришли во время работ, не теряются: почтовые серверы отправителей повторяют доставку. Но приходят они с задержкой, иногда в несколько часов.

DNS с публичных серверов. Ваш компьютер мог запомнить адрес, и сайт откроется у вас, но не у покупателей. Спросите напрямую у Google и Яндекса:

dig @8.8.8.8 example.ru +short
dig @77.88.8.8 example.ru +short
dig @8.8.8.8 example.ru MX +short

На Windows то же делает nslookup example.ru 8.8.8.8. В ответе должен быть IP вашего хостинга и ваши почтовые серверы. Пустой ответ или SERVFAIL - повод сразу написать в поддержку. Как устроены эти записи, мы разбирали в статье Домен подключён, а сайт не открывается: DNS без мистики.

Сертификат. Откройте сайт по https:// и посмотрите в браузере, до какой даты действует сертификат. Из консоли так:

echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -enddate

Если срок кончается в ближайшие недели, проверьте через несколько дней, что сертификат продлился. Продление идёт автоматически, но после переезда за ним стоит проследить.

Задачи по расписанию. Пока сервер стоял, cron не работал, и задачи с запуском в эти часы пропущены. Сами они не догонятся. Если ночью у вас выгружается прайс, собирается карта сайта или делается копия базы, запустите задачу вручную или дождитесь следующего запуска и проверьте результат.

SSH и SFTP. При переустановке у сервера меняются ключи, по которым его узнаёт ваша программа. FileZilla и WinSCP при первом подключении покажут предупреждение о новом ключе, консольный ssh откажется подключаться с сообщением REMOTE HOST IDENTIFICATION HAS CHANGED. Если хостинг предупреждал о смене ключа, это ожидаемо. Старый ключ удаляется командой:

ssh-keygen -R имя-сервера

После этого подключитесь снова и примите новый ключ. Если хостинг о работах не писал, а ключ сменился, сначала спросите поддержку: так же выглядит подмена сервера.

Если сайт открывается не везде. У провайдера может остаться старый ответ DNS, особенно после сбоя: некоторые серверы помнят даже ошибку несколько минут. Проверьте с мобильного интернета и с компьютера. Если с одного открывается, а с другого нет, подождите полчаса. Если не открывается нигде, пишите в поддержку.

Что мы будем делать иначе

Каждую находку этой ночи мы внесли в процедуру переноса, чтобы на следующем сервере она не повторилась: проверка списка DNS-зон до того, как его увидят ns1 и ns2, пересчёт заданий копирования в момент остановки и создание каркаса CageFS заново. Ошибка с DNS обидная, потому что на репетициях мы её не увидели: ns1 и ns2 к тестовому серверу не подключались, и заметить её было не на чем.

Если вы собираетесь переезжать сами, на другой хостинг или свой сервер, порядок действий и проверки в статье Переезд на другой хостинг без потери сайта, писем и заказов. Как этот же переезд готовили на старых сайтах, мы рассказывали в статье Старый сайт на PHP 5.4 после переезда на MySQL 8. А что стоит проверять на сайте регулярно, без всяких переездов, собрано в статье Что проверять на сайте: раз в неделю, раз в месяц и раз в год.