К началу работы сайты клиента были распределены между несколькими хостингами и панелями управления. На одном из серверов находилось более 40 сайтов. Они использовали разные версии PHP, отдельные конфигурации веб-серверов, собственные сертификаты и многочисленные доменные псевдонимы.

Часть инфраструктуры работала на устаревшем программном стеке. На одном из серверов использовались старые версии операционной системы, PHP и СУБД, а основной диск был заполнен примерно на 85%. Полного административного доступа к некоторым площадкам не было.

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

Какие проблемы мы обнаружили

Инфраструктура состояла из нескольких технологических поколений

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

Из-за этого запуск каждого нового сайта превращался в отдельный инфраструктурный выбор. Проект нельзя было просто разместить рядом с существующими: приходилось учитывать совместимость кода, версию PHP, доступный объём диска и влияние изменений на остальные сайты.

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

Резервное копирование не покрывало инфраструктуру целиком

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

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

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

Дисковое пространство стало общим ограничением

На основном SSD хранились рабочие окружения нескольких проектов. По мере роста сайтов и появления новых контейнеров свободное место сокращалось.

Размещать все новые проекты на быстром диске было невозможно. Но переносить целиком на более медленные SATA-диски также было нежелательно: это могло ухудшить скорость работы приложений и баз данных.

Инфраструктура требовала разделения компонентов по характеру нагрузки. Код и статические данные можно было размещать на ёмких дисках, а базы данных и чувствительные к задержкам операции — оставлять на SSD.

Изменения приложений зависели от конфигурации инфраструктуры

Разработчикам регулярно требовались новые версии PHP, дополнительные модули, правила Nginx, редиректы, изменения лимитов памяти, поддержка WebP, WebSocket, Node. js и серверного рендеринга.

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

После переноса одного из проектов в новое окружение Node. js-приложение стало вести себя иначе. Первоначально причиной считались заголовки прокси-сервера или версии пакетов, но дальнейшая диагностика показала, что сбой возникал при обращении серверного рендеринга к внутреннему API. Это требовало совместной проверки приложения, сетевого взаимодействия и серверной конфигурации.

Большое число сайтов увеличивало эксплуатационную связанность

На инфраструктуре работали основные сайты, поддомены, региональные и дилерские площадки. Изменение одного контейнера или веб-сервера могло затронуть сразу несколько проектов.

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

Что было сделано

Спроектирована новая схема размещения проектов

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

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

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

Выполнен перенос действующих сайтов

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

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

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

Разделены окружения для разных версий программного стека

Для проектов, которым требовались новые версии PHP, создавались отдельные контейнеры. Это позволило не обновлять общий runtime для всех сайтов и не подвергать старые приложения дополнительному риску.

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

Для Node. js-проектов настраивались запуск сервисов, проксирование запросов, передача заголовков, серверный рендеринг и взаимодействие с внутренними API.

Построена многоуровневая схема резервного копирования

Для файлов и баз данных разных виртуальных серверов были настроены отдельные расписания копирования. Архивы сохранялись локально и передавались во внешнее хранилище. Для каждого типа данных определялись частота создания копий и глубина хранения.

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

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

Внедрён мониторинг эксплуатационных рисков

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

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

Создан процесс безопасных изменений

Запросы разработчиков стали проходить инженерную проверку перед применением. Изменения Nginx, PHP, Node. js и фоновых заданий оценивались с учётом влияния на весь сервер.

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

Так были реализованы правила редиректов, обработка современных форматов изображений, изменения параметров кэширования, подключение новых поддоменов, обновление runtime и настройка новых приложений.

Результат

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

сайты были перенесены на инфраструктуру с единым инженерным сопровождением

проекты с несовместимыми версиями PHP были разделены по окружениям

появилась возможность запускать новые сайты без обновления общего стека

резервное копирование охватило файлы, базы данных и дисковые образы

копии стали проверяться на фактическое создание и передачу

критичные компоненты были распределены между SSD и ёмкими дисками с учётом характера нагрузки

мониторинг позволил обнаруживать недоступность сайтов, нехватку места, высокую нагрузку и истечение сертификатов

изменения инфраструктуры стали выполняться с оценкой влияния на соседние проекты

диагностика инцидентов стала учитывать одновременно приложение, веб-сервер, runtime, сеть и внутренние API

Вывод

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

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

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

Смотрите другие
кейсы по Bitrix

Error get alias

Хотите передать
свою инфраструктуру в надежные руки?

Будем рады проконсультировать вас и обсудить проект.

Развитие инфраструктуры сети корпоративных и дилерских сайтов

О клиенте

Исходная ситуация