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

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

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

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

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

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

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

Свободного пространства для такого сценария не оставалось. Это приводило к остановке компонентов портала и ежедневным периодам недоступности.

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

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

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

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

Стандартный логический дамп становился все менее подходящим для такого объема данных. Резервное копирование само создавало дополнительную нагрузку и увеличивало риск недоступности портала.

Состояние сервера нельзя было надежно воспроизвести

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

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

Поэтому полноценное принятие портала на поддержку требовало не последовательного исправления старого сервера, а подготовки нового окружения по контролируемому стандарту.

Система требовала постоянного контроля ресурсов

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

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

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

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

Приняли инфраструктуру под наблюдение

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

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

Параллельно была оценена текущая нагрузка, объем базы и файлов, темпы их роста и требования к новой конфигурации.

Спроектировали новое серверное окружение

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

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

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

Организовали перенос с контролируемым переключением

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

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

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

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

Перестроили резервное копирование

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

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

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

Сопровождали рост портала

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

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

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

Обеспечили эксплуатацию оборудования

Мониторинг состояния накопителей позволил обнаруживать ошибки дисков и деградацию RAID-массивов до полной потери массива. Замена накопителей выполнялась с контролем перестроения RAID и доступности портала.

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

Результат

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

устранена исходная схема, при которой ночной бэкап заполнял системный раздел и останавливал портал

инфраструктура портала собрана в воспроизводимой конфигурации

настроен постоянный контроль доступности, ресурсов, базы данных, служб, RAID и резервных копий

резервное копирование адаптировано к крупной и продолжающей расти базе данных

перенос выполнен с предварительной синхронизацией, пользовательской проверкой и возможностью возврата

изменения параметров и обновления компонентов стали оцениваться с учетом влияния на всю систему

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

снизился риск потери данных при отказе накопителей и деградации RAID

управление доступами внешних подрядчиков стало частью контролируемого процесса эксплуатации

Вывод

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

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

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

Error get alias

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

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

Стабилизация и развитие инфраструктуры корпоративного портала на «1С-Битрикс24»

О клиенте

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