Аварии на серверах h4 и h5 modhost.pro

Давно не писал интересных заметок, жаль, что повод не очень.

Итак, за последние пару месяцев у нас было 3 проблемы с сервером h4 и 1 с сервером h5. Все аварии по ночам, когда поддержка спит и видит сладкие сны о бесперебойной работе всех сервисов. Последний инцидент был сегодня.

Проблема, как многие уже догадались — в отсутствии свободного места при резервном копировании. Заканчивается место и…
— Отваливается MySQL
— Пользователи видят проблему, не могут войти в админку (пароль-то не проверить, БД не работает)
— Думают, что их взломали (логи сервера с ошибками MySQL смотреть неинтересно) и начинают восстанавливать резервные копии
— А при этом сайт сначала удаляется, но места свободного обычно всё равно не хватает, так что ничего и не восстанавливается
— Дальше отваливается Nginx, когда замечает, что у него пропали конфиги этого удалённого сайта
— Ну и PHP, по той же причине

В общем: паника, разруха, десятки тикетов в поддержке — просыпаешься моментально.

Как же устроено резервное копирование на modhost.pro?



Мы используем Duplicity, который делает 2 полные резервные копии и 6 инкрементальных к ним.

Полная копия — это понятно, взяли всё и запаковали. Инкремент же, это архив только тех файлов, которые изменились с момента предыдущего бэкапа. При распаковке инкремента идёт распаковка полного архива, потом всех инкрементов до нужного — и уже он сам. Выходит дольше, но позволяет сэкономить свободное место, потому что делать даже 3 полных копии каждого сайта очень накладно.

Внимание, для конечного пользователя тип резервной копии значения не имеет! При восстановлении или скачивании любой копии себе — он всегда получит её полную, голый инкремент на 3 мегабайта в изменениями за пятницу ему никто не отдаст. Подробнее про принципы резервного копирования можно почитать тут.

Итого, мы храним максимально 14 бэкапов. Когда подходит очередь делать очередной, 3й полный бэкап, самый первый полный со всеми инкрементами удаляется, и получается 8 бэкапов: 1 полный с 6 инкрементами, и 2-й полный без ничего. Дальше к нему набивается 6 инкрементов и становится 14 копий.

Вот такой круговорот бэкапов в природе. Как нетрудно догадаться, при такой системе свободное место на серверах «плавает».
Например, есть сайт на 10 Гб, который давно работает и всё у него хорошо. Резервные копии, предположим, занимают около 20 Гб (пусть будут 2 полные + 11 инкрементов) в архиве. И тут, внезапно, на сайте решили сделать редизайн и поменять половину картинок товаров, например.
Следующая инкрементальная копия будет гораздо больше обычной, потому что она содержит все новые картинки за этот день. Наш сайт всё еще занимает те же 10 ГБ, но резервные копии весят уже 25 Гб, потому что 7-й инкремент занимает не 100 мб, как обычно, а 5 Гб с новыми картинками.

И вот, когда сервера уже хорошо так заполнены, и на них идёт активная работа, несколько таких совпадений приводит к нехватке свободного места. Как вы теперь видите, предсказать это довольно сложно, и долгое время я пытался как-то вручную развести бэкапы больших сайтов. К сожалению — не получилось.

Тогда я сократил количество бэкапов для сервера h4, где собрались сразу 4 тяжелых сайта, весом больше 10Гб до 1 полного + 6 инкрементов. Предсказуемо пошли жалобы, «а куда делись мои бэкапы?».

Так что, хорошенько подумав, была изобретена

Новая система



— Количество бэкапов возвращается к исходному, формула 2 + (2 * 6)
При создании любой новой резервной копии теперь проверяется процент свободного места на SSD
— Если он меньше 15%, то вместо создания новой копии, у сайта удаляется предыдущий полный бэкап с инкрементами
— Место освобождается, и пользователь может попробовать снова
— При создании бэкапов массово ночью, юзеры теперь обрабатываются в случайном порядке. То есть, не будет несправедливой ситуации, когда пользователи до середины списка с 2 полными бэкапами, а для остальных места всегда не хватает.

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

По мере удаления старых бэкапов и естественного движения пользователей (переезд на другой сервер, удаление сайта по каким-то причинам), места станет больше, и у всех всегда будет от 8 до 14 резервных копий.

Заключение



Эта проблема касается только двух серверов: h4 и h5, так что, если вам нужно гарантированно 14 бэкапов — переезжайте на более свободные сервера в РФ, там в 2 раза больше SSD.

Сделать это можно в любое время, совершенно бесплатно, смотрите раздел «Смена тарифа или сервера».

Если вы не делегировали свой домен нам — то вам нужно будет еще поменять IP для записи A в настройках своего DNS.

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


Если у вас остались какие-то вопросы, не стесняйтесь, задавайте их в комментариях.
Василий Наумкин
27 февраля 2018, 08:29
modx.pro
1
3 776
+11

Комментарии: 9

Роман Воропаев (Volk)
27 февраля 2018, 12:41
0
К слову, я на своём веб-сервере реализовал такого же типа резервное копирование, только бекапы хранятся за 2 месяца, за последние две недели это 2 полных копии и по 6 инкрементальных к ним, и 6 еще полных копий (по одной за каждую еще более давнюю неделю), в целом получилось, что есть бекапы за 2 месяца. Но не это главное.

Что бы не забивало место на диске самого сервера хостинга я сделал в качестве типа хранилища яндекс диск на первое время, но потом заказал у того же хостинг провайдера, у которого арендую vds, отдельный диск (предоставляется фтп доступ к их серверу, на котором выделено нужное мне количество дискового пространства, которое к слову можно при необходимости увеличить), он находится в той же сети, что и мой vds, этим самым минимальный пинг и максимальная скорость передачи.
Конечно при резервном копировании теневая копия хранится на том же сервере, где и установлен веб-сервер, но после копирования её в другое хранилище эта копия удаляется. В итоге имеем на веб сервере только сами сайты и их файлы, а ночью необходимо немного места для создания теневой копии, а все бекапы на другом сервере.

Так же в этом случае можно еще найти вдс с минимум озу и 1 ядром, но с большим диском и поднять там ftp, либо пользоваться dropbox и прочими сервисами, но это обходится дороже, чем свой слабый вдс с большим диском и поднятым на нем фтп.
    Василий Наумкин
    27 февраля 2018, 12:51
    +2
    У нас 10 серверов в разных частях света, плюс возможность переезжать с одного сервера на другой в любой момент, со всеми бэкапами.

    Если их вынести на внешнее хранилище, то работа с ними будет занимать оочень много времени, возможно даже за ночь просто не получится их все выгрузить. Просто потому, что хранилище в одном ЦОД, а большинство серверов — в другом.

    Есть вариант работать с Selectel Cloud Storage, там CDN и типа должно быть всё быстро в любой точке планеты — но цены за хранение 2 ТБ бэкапов такие, что хостинг выйдет нерентабельным (и это я еще не уверен, что CDN поможет при upload).

    Так что, нынешний вариант мне видится пока самым лучшим.
    Alexander V
    28 февраля 2018, 00:44
    +1
    Как такое может быть в принципе? Неужели не допускали того, что может закончиться диск? Я понимаю, что избыточные мощности стоят денег. Но можно ведь было это как-то предвидеть?
      Василий Наумкин
      28 февраля 2018, 04:52
      +4
      Такого вообще не может быть, ведь люди не ошибаются, а все хостинги в мире работают безупречно. Потому что все всё предвидят и вовремя предотвращают.

      Зачем я эту заметку писал?
      Волков Николай
      01 марта 2018, 20:12
      +3
      Неожиданно интересно оказалось почитать про работу с бэкапами. Ранее об этом как-то не задумался и все на хостера в этом вопросе поломался. Надо будет на досуге поподробнее эту тему почитать.
        Alex Box
        08 марта 2018, 15:38
        0
        Интересно, а вот теоретически возможно бекапить в разные аккаунты, динамически распределяя пространство? Я думаю, большинство пользователей модхост — разработчики, с некоторым пулом своих клиентов. Что если юзер объединит несколько своих клиентов в пул?




          Василий Наумкин
          08 марта 2018, 15:41
          +1
          Бэкапы клиентам вообще не считаются. То, что ты видишь в занятом месте — это только твои файлы и БД, бэкапов там нет.

          Если мы начнём вам считать бэкапы — вы офигеете, потому что для сайта на 2 гига хранится 5 гигов бэкапов.
            Alex Box
            08 марта 2018, 15:47
            +3
            ясно ))) не подумал
            на timeweb свыше трех бекапов платно за каждый )). сбежал от них… но, даже больше из-за стабильности.

            у вас лучшее соотношение цена/стабильность/скорость работы. пожалуй, лучшее за последние 4 года.
              Василий Наумкин
              08 марта 2018, 15:48
              +2
              на timeweb свыше трех бекапов платно за каждый
              А что, так можно было?!

              Атас.
          Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
          9