Настраиваем Linux сервера
и не даем им падать

Переезд - это всегда хороший повод внести улучшения

После аудита было принято решение поднимать копию сервиса не руками, а вместо этого внедрить автоматизацию, описав всю инфраструктуру сервиса на ansible.

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

Кроме этого были устранены единые точки отказа, а именно задублированы фронтенды с nginx и единственный сервер mysql был заменен на отказоустойчивый percona xtradb cluster из 3 нод. Таким образом, любой из элементов сервиса может быть выведен из строя, но система продолжит функционировать нормально

Был написан набор сценариев, запустив которые можно поднять полную копию сервиса за десятки минут, ввести в строй новые ноды за минуты, изменить конфигурацию и обновить код на всех машинах - за секунды. После проверки сценариев на тестовой инсталляции, боевая инсталляция из 10 машин была подготовлена менее чем за 2 часа (полтора из которых заняло создание пустых виртуальных машин со стороны azure).
Простой при переключении на новую инсталляцию не привысил 10 минут

После переезда был настроен автоматический мониторинг системы по нескольким сотням параметрам с оповещеним по e-mail и sms, чтобы обеспечить непрерывную работу сервиса, и автоматическое резервное копирование на 2 удаленных площадки, чтобы исключить риск потери пользовательских данных

На первом этапе был улучшен процесс развертывания приложения для того, чтобы можно было быстро поднимать его копии.
Следом было настроено резервное копирование и расширенный мониторинг сервиса.

Во втором датацентре была создана копия сервиса. Для синхронизации данных была настроена master-slave репликация базы данных postgres.
В течение недели репликации было дано "отстояться". Все это время мониторинг проверял ее статус. В дополнение к этому периодически эмулировалась потеря связности между датацентрами и проверялось, как восстанавливается репликация,

После успешных тестов был написан регламент переключения площадок.
Далее вместе с клиентом в ночь выбрали время и сэмулировали гибель основной площадки (потеря питания в датацентре), и выполнили переключение на резервную, протестировали и переключили на основную. Процесс прошел штатно и в отведенные для этого сроки.

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

Для решения проблемы с нагрузкой были настроены ElasticSearch для более оптимального поиска по каталогу и redis для кэширования результатов работы с базой.

Нагрузка на сайт значительно упала и главное выровнялась. Это позволило уменьшить число ареднуемых серверов и сократить расходы

Работы проводились в 3 этапа. На первом этапы была настроена база данных, выявлены и оптимизированы самые тяжелые запросы, добавлены недостающие индексы. База перестала быть узким местом

На втором этапе оптимизировалась работа php. На проекте использовался php5.4. На тестовом стенде была опробована версия php5.6. Сайт заработал с минимальными исправлениями в коде и стал значительно быстрее. После тестов был обновлен и основной сайт

На третьем этапе виртуальная машина с сайтом была мигрирована на новое арендованное железо. Цена аренды при этом осталась прежней, но скорость работы увеличилась кратно. Благодаря тщательной подготовке, сам момент переключения и недоступности сайта не превысил 5 минут

Redmine был упакован в Docker контейнеры: для каждого клиента запускается контейнер с Redmine, контейнер с базой данных postgres и конетйнер для хранения пользовательских файлов. Создание и управление контейнерами просиходит из админки, написанной разработчиками клиента.

При обновлении версии продукта происходит сборка нового образа docker. Образ тестируется, после чего происходит редеплой, то есть перезапуск контейнеров с новой версией образа у всех клиентов.

Docker позволил сделать обновление версии очень быстрым и легим, и кроме этого дал впечатляющую плотность размещения: более 50 контейнеров на одном сервере, что позволило сэкономить на хостинге

Был собран и описан список всех физических серверов и виртуальных машин. Для каждой машины было описано ее назначение, была составлена и актуализирована полная таблица с планом ip-адресов

Следом была описана система виртуализации из 16 гипервизоров, проверены и описаны основные сценарии работы с виртуальными машинами

Затем было проверено и задокументировано сетевое взаимодействие: настойка свитчей, назначение vlan'ов, маршрутизация между vlan'ами, настройки внутренней маршутизации и внешней (BGP аплинки и пиринг с партнерами), а так же DNS и VPN

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

Далее проведен аудит баз данных в плане настроек производительности и отказоустойчивости