Гостевой пост: как Linux.Org.Ru переезжал в "Селектел" - Академия Selectel
В панель

Гостевой пост: как Linux.Org.Ru переезжал в «Селектел»

Тирекс Тирекс Самый зубастый автор 27 мая 2016

Сегодня мы публикуем в нашем блоге гостевой пост, написанный создателем Linux.Org.Ru Максимом Валянским. Максим подробно рассказывает, почему для размещения сервера был выбран именно “Селектел”, а также делится техническими деталями переезда.

Изображение записи

Российские пользователи OC Linux прекрасно знают сайт Linux.Org.Ru, в обиходе называемый просто LOR. Созданный в 1998 году группой энтузиастов, он быстро завоевал популярность как среди любителей, так и в профессиональном сообществе. В течение долгого времени LOR был чуть ли не единственным ресурсом, где публиковались самые свежие новости из мира Linux и свободного ПО. Даже сегодня, в эпоху Хабрахабра и социальных сетей, проект не сдаёт позиции, успешно развивается и растёт. Совсем недавно сайт был перенесён на новый сервер, и встал вопрос о поиске площадки для его размещения. Узнав об этом, мы предложили Linux.Org.Ru свои услуги — и вскоре сервер был установлен в нашем московском дата-центре.

Сегодня мы публикуем в нашем блоге гостевой пост, написанный создателем Linux.Org.Ru Максимом Валянским. Максим подробно рассказывает, почему для размещения сервера был выбран именно «Селектел», а также делится техническими деталями переезда.

Этой весной мы поменяли сервер, на котором крутится Linux.org.ru. Прошлое «железо» проработало у нас с 2007-го года, почти 9 лет. После этого мы воспользовались предложением компании Selectel, и разместили сервер в их московском дата-центре. Colocation компании Selectel нам понравился отсутствием ограничений на трафик, наличием IP-KVM и возможностью доступа к оборудованию в любой момент. Linux.org.ru — хобби-проект, который развивается в свободное время, так что для нас важна возможность доступа к оборудованию в выходные и нерабочие часы.

Смена дистрибутива

Одно из основных изменений, которое мы сделали на новом сервере — переход с Fedora на CentOS 7. Fedora — замечательный дистрибутив с высокой скоростью развития. Его нужно обновлять раз в полгода, и далеко не все обновления проходили гладко. В условиях, когда весь сайт крутится на одном сервере, это не самый лучший вариант.

CentOS 7 содержит почти все, что нам нужно для запуска, но в комплекте с ним идет очень старая версия PostgreSQL и нет nginx. Пакеты PostgreSQL мы взяли с официального репозитория PostgreSQL (yum.postgresql.org), и пакет nginx — c nginx.org.

Репозиторий с пакетами PostgreSQL хорош тем, что версия СУБД не привязана к версии дистрибутива и ее обновление не требует обновления ОС. Сейчас мы работаем на версии 9.4, но в будущем планируем перейти на 9.5.

Настройка RAID и SSD

На новый сервер мы установили два одинаковых жестких диска Seagate Constellation, и два «desktop-grade» SSD-диска OCZ, которые удачно купил на распродаже один из участников форума Олег Дрокин (green).

HDD мы соединили в RAID1 с использованием mdadm. SSD-диски потребовали более хитрой конфигурации. На каждом из дисков мы создали резерв в треть их объема, а оставшееся место объединили в RAID1 с HDD. Для таких конфигураций в mdadm есть специальный режим — write mostly, при котором второй диск в зеркале используется только для записи, а чтение осуществляется с только с основного. Для уменьшения влияния HDD на скорость записи мы увеличили значение write behind, позволяющее HDD-диску немного отставать от SSD при интенсивной записи. Подобная конструкция позволит нам использовать скорость SSD-диска и не бояться того, что он внезапно выйдет из строя.

На SSD-дисках пока что мы разместили две части нашего сайта — изображения галереи и индексы Elasticsearch. Каталог с изображениями работает в основном только на чтение, и его данные сохраняются системой резервного копирования на облачное хранилище. Индексы Elasticsearch не содержат уникальной информации, и в случае проблем их легко перестроить. Основную БД сайта и ОС мы оставили на HDD.

Переключение сайта со старого сервера на новый

Перенос сайта хотелось осуществить с минимальным даунтаймом. Статические данные сайта и изображения галереи мы перенесли с использованием rsync. Основная сложность — перенос данных PostgreSQL. Объем нашей базы таков, что перенос и развертывание БД из дампа базы заняли бы почти час.

Чтобы избежать простоя мы настроили новый сервер в качестве readonly slave. В PostgreSQL для этого есть два механизма: через архивирование журналов и режим поточной репликации. Метод с передачей журналов проще в настройке, но механизм архивирования у нас уже был задействован системой резервного копирования.

В итоге мы настроили поточную репликацию, дополнительно это потребовало еще настроить TLS для безопасной передачи данных между разными дата-центрами. С настройкой репликации есть два момента, на которые стоит обратить внимание. Во-первых, для slave узла нужно зарегистрировать replication slot. При использовании этого механизма master-узел будет хранить журналы для slave узла до тех пор, пока slave их не прочитает. Это отличается от режима «по умолчанию», при котором временная недоступность slave может привести к тому, что процесс репликации прервется и для его восстановления потребуется снова делать полную копию данных.

Второй интересный момент мы обнаружили, когда попробовали сделать дамп БД со slave узла. Запрос создания дампа работает настолько долго, что за время его выполнения на master-узле успевает отработать autovacuum, который удаляет данные, видимые из транзакции на slave-узле. Это прерывает выполнение запроса. Аналогичные проблемы могут случиться, если использовать slave-узел для выполнения долгих аналитических запросов. Для решения этой проблемы есть параметр hot_standby_feedback, при его использовании master-узел будет обеспечивать наличие данных для транзакций, которые выполняются на slave-узлах.

Само переключение проходило довольно просто: трафик сайта идет через серверы DDoS-защиты, и смена физического адреса сервера проходит почти мгновенно, не требуя смены DNS. После смены мы погасили Tomcat и PostgreSQL на старом сервере, а на новом перевели реплику в режим мастера. Таким образом даунтайм при переходе составил не более двух минут.

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

Послесловие

Все работы по переносу сервера Linux.Org.Ru в наш дата-центр прошли быстро и безболезненно. Мы очень рады, что нам удалось внести свою лепту в развитие одного из самых интересных информационно-просветительских проектов Рунета. От всей души желаем команде LOR творческих успехов и надеемся, что в ближайшем будущем сайт станет ещё интереснее, а его аудитория будет расти.

Читайте также: