DR для LLM on-prem: резервирование, репликация и запас GPU

Что ломается в on-prem LLM и почему это останавливает работу

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

Причины простоя похожи на обычный ЦОД, но для LLM последствия заметнее: проблемы с питанием и охлаждением (перезагрузка стойки, деградация из-за перегрева), сетевые сбои (теряется связность между API, хранилищем и базой знаний), диски и контроллеры (повреждение томов или резкое падение производительности), неудачные обновления (GPU-драйвер, контейнеры, зависимости), а также шифровальщик или компрометация учетных записей (блокируются файлы и секреты).

Чаще всего теряется не «модель целиком», а свежие изменения вокруг нее. Например, последние документы, которые еще не попали в резервную копию, или векторный индекс, который потом пересобирается часами. Отдельная боль - настройки доступа: секреты, роли, ключи API, правила сетевого доступа. Без них сервис трудно быстро поднять даже на резервной площадке.

LLM на месте зависит не только от весов модели. Ей нужны данные (база знаний, файлы, витрины), индекс для быстрого поиска, пайплайн загрузки и очистки документов, а также слой выдачи: ранжирование, фильтры по правам, логирование. Если падает любой из этих элементов, ответы становятся медленными, пустыми или небезопасными.

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

RTO и RPO простыми словами: задаем цели непрерывности

Чтобы DR для LLM on-prem был не «папкой на полке», сначала договоритесь о двух цифрах: RTO и RPO. Это не про железо, а про то, сколько простоя и потерь бизнес реально выдержит.

RTO (Recovery Time Objective) отвечает на вопрос: сколько времени вы можете быть без сервиса. Если внутренний помощник недоступен 4 часа, работа еще терпима. Если он стоит сутки, встают поддержка, закупки и согласования.

RPO (Recovery Point Objective) отвечает на вопрос: сколько данных допустимо потерять по времени. Для LLM-сервиса это обычно не «модель целиком», а свежие документы, логи диалогов, новые эмбеддинги и обновления индекса. RPO в 24 часа означает, что можно потерять все изменения за день. RPO в 15 минут - что почти все должно быть синхронизировано постоянно.

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

Удобный способ согласовать требования с владельцами процессов - сделать «одну страницу» и утвердить ее как исходные условия. В ней обычно фиксируют: какие функции LLM критичны (поиск по базе знаний, генерация ответов, суммаризация), допустимый простой и допустимую потерю обновлений по каждой функции, критерий «сервис восстановлен» (минимальный набор проверок), а также кто принимает решение о переключении на DR и о возврате назад.

После этого разговор про бэкапы, репликацию и запас ресурсов становится проще: вы выбираете не «самое надежное», а то, что укладывается в согласованные RTO/RPO.

Что именно нужно сохранять: данные, индекс, модели и настройки

Если LLM-сервис работает on-prem, «бэкап LLM» почти никогда не означает одну папку. Система состоит из нескольких слоев. И ломается она часто не там, где ожидают: документы на месте, а индекс потерян; модели есть, но нет токенизатора или правил фильтрации.

Простое правило: сохраняйте не только контент, но и все, что превращает его в ответы пользователям.

Пять наборов, без которых DR будет неполным

1. Исходные данные: документы, версии, метаданные, права доступа. Важно хранить не только файлы, но и информацию о том, кто что может читать. Иначе после восстановления вы либо «откроете всем все», либо получите массовые отказы по доступам.

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

3. Модели и артефакты: веса, токенизаторы, словари, конфиги рантайма, промпт-шаблоны, правила фильтрации и redaction. Эти детали меняют поведение ответов почти так же сильно, как сама модель.

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

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

Короткий пример

Внутренний поиск по базе документов в госорганизации: файлы восстановили из резервной копии, но забыли про права и индекс. В итоге пользователи видят ошибки доступа, а админы вынуждены пересобирать векторную базу с нуля. Если заранее сохранять данные, индекс и весь «обвес» модели, восстановление сводится к запуску сервисов и проверке контрольных запросов, а не к долгой реконструкции.

Резерв индекса: как не потерять скорость восстановления

В on-prem LLM чаще всего «болит» не сама модель, а скорость поиска по базе знаний. Если векторный индекс потерян, сервис может формально подняться, но ответы станут медленными или неполными, пока индекс не пересоберется. Полная пересборка нередко занимает часы и даже дни: нужно заново посчитать эмбеддинги, записать их в хранилище и построить структуры поиска.

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

Какие варианты резервирования индекса работают

Выбор зависит от того, как устроен индексатор и где лежат данные. Чаще всего используют один из трех вариантов: полную копию индекса по расписанию (просто, но требует места), инкрементальные копии (меньше объем, но сложнее восстановление и проверка), либо снапшоты на уровне движка или файловой системы (часто дают хороший баланс скорости и надежности).

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

Как часто делать и как не потерять бэкап

Частоту привязывайте к обновлению базы знаний и к обещанному RPO. Если контент меняется каждый час, а потерять можно максимум 15 минут, нужна частая фиксация состояния (снапшоты или инкремент).

Отдельно продумайте хранение: отдельный контур, контроль целостности, журналирование и защита от удаления. Минимум - раздельные роли и двухэтапное удаление.

Самое важное измерение - не «есть бэкап», а «сколько реально занимает восстановление». Раз в квартал поднимайте тестовый стенд, восстанавливайте индекс и замеряйте время до готовности поиска. Так вы понимаете, выдерживаете ли свой RTO, или план надо менять.

Репликация хранилища и снапшоты: защита от потерь и ошибок

В DR для LLM on-prem чаще всего подводит не «железо», а хранилище: оно может выйти из строя, заполниться, повредиться после сбоя питания или стать жертвой шифровальщика. Поэтому полезно разделять два механизма: репликацию (чтобы быстро подняться) и снапшоты (чтобы откатиться назад, если данные испортили логически).

Что реплицировать и как часто

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

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

Уровень репликации зависит от того, где «истина»: файловая система, SAN/NAS, объектное хранилище или база данных. Репликация на уровне СХД проще, но может переносить и ошибку. Репликация на уровне приложения сложнее, зато дает больше контроля над консистентностью.

Снапшоты и проверка консистентности

Снапшоты помогают, когда проблема логическая: случайно удалили папку, загрузили битые данные, или шифровальщик успел испортить часть томов. Делайте снапшоты часто (например, каждые 15-60 минут), держите несколько «точек» за день и за неделю, и обязательно разводите домены отказа: разные стойки, залы, а лучше разные площадки.

Чтобы убедиться, что копии пригодны, нужны простые проверки, а не вера в «зеленый статус». Полезный минимум: фиксировать контрольные точки (время, версия, список томов) перед репликацией, сверять объемы и число объектов после переноса, выборочно проверять хэши для критичных наборов, а также периодически поднимать тестовый контур и прогонять короткий набор запросов.

Так вы заранее узнаете, восстановится ли сервис реально, а не только «по отчету».

Запас GPU и вычислений: сколько нужно и в каком виде

Даже при идеальных бэкапах DR не сработает, если нет свободных вычислений. Для LLM чаще всего «бутылочное горлышко» - GPU и их память, но проблема обычно шире: важны CPU и RAM (препроцессинг, векторизация, очереди), сеть между хранилищем и GPU-узлами, диски и IOPS (модели, кэши, логи), а также лицензии, ключи и доступы.

Есть три базовых подхода к резерву. Холодный резерв дешевле, но RTO будет большим: железо есть, но оно не готово. Теплый резерв - узлы включены, образы и контейнеры готовы, но трафик на них не идет. Актив-актив имеет смысл, только если простой очень дорог и нагрузка стабильна, иначе это постоянный «двойной» кластер.

Минимальный расчет часто делают по правилу N+1: если для пика нужно N GPU, держите еще 1 на отказ. На практике лучше считать от цели: например, «в аварии держим 70% пропускной способности». Тогда запас - это разница между пиком и тем, что вы готовы потерять.

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

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

Доступы, секреты и роли: без этого DR не запускается

Можно иметь бэкапы, репликацию и запасные GPU, но DR для LLM on-prem часто ломается на самом простом: нужный человек недоступен, пароль хранится в чате, ключи истекли, а у дежурной команды нет прав.

Где держать секреты, чтобы восстановление не уперлось в одного человека

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

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

Роли и права: кто что делает в первые 30 минут

Заранее разделите роли, чтобы не было хаоса и «все ждут всех». Обычно достаточно пяти: дежурный инженер поднимает базовую инфраструктуру и проверяет доступность сервисов; администратор данных восстанавливает хранилище/БД и валидирует целостность; ответственный за сеть и балансировщики переключает трафик и проверяет маршрутизацию; владелец сервиса решает, когда включать пользователей, и подтверждает выполнение RTO/RPO; руководитель инцидента ведет таймлайн и фиксирует решения.

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

Продумайте и коммуникации: отдельный канал для команды, отдельный для руководства и отдельный для пользователей. Короткие статусы по шаблону (что случилось, что делаем, ETA, риски) экономят время. Если поддержку ведет внешняя команда с 24/7 дежурством, заранее согласуйте, кто имеет право переключать трафик, а кто только рекомендует.

План восстановления по шагам: от инцидента до возврата трафика

Рабочий DR для LLM on-prem начинается с дисциплины. В первые минуты важно остановить хаос: зафиксируйте время, симптомы, затронутые сервисы и сразу заморозьте изменения. Никаких «быстрых правок в проде» и ручных перезапусков без записи, иначе вы усложните расследование и восстановление.

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

• Подтвердить инцидент и объявить режим DR: кто руководит, кто выполняет шаги, где ведется журнал действий.
• Переключить пользователей на резервную площадку или временный режим: ограничить функции, отключить тяжелые инструменты, включить более строгие лимиты.
• Восстановить хранилище данных из реплики или снапшотов и проверить консистентность: права доступа, целостность файлов, совпадение версий схем.
• Восстановить индекс (векторный или поисковый) и сделать быстрые проверки качества: 10-20 типовых запросов, подсказки, фильтры, скорость ответа.
• Поднять LLM-сервис и обвязку: авторизация, секреты, лимиты, очереди, журналы и метрики. Важно убедиться, что ошибки не продолжают сыпаться в логах.

После технического восстановления возвращайте трафик постепенно: сначала внутренние пользователи, затем 10%, 50% и только потом 100%. Если есть запас GPU, подключайте его поэтапно, чтобы не упереться в память или питание.

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

Проверки и учения: как убедиться, что план работает

DR для LLM on-prem проверяется только практикой. Если вы ни разу не поднимали сервис из резервов, вы не знаете, сколько это займет и где все застрянет.

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

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

Фиксируйте метрики, иначе тест превратится в «вроде получилось». Достаточный набор: фактические RTO и RPO (по времени и по данным), время восстановления индекса и время прогрева после старта, доля успешных восстановлений с первого раза, время на получение GPU-ресурсов и запуск инференса, количество ручных действий, без которых ничего не работает.

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

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

Частые ошибки: почему DR «на бумаге» не спасает

Главная причина провала DR для LLM on-prem проста: план написан, но не проверен в реальности. В момент аварии выясняется, что критичный кусок не учтен, и RTO превращается из часов в дни.

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

Вторая ловушка - индекс. Данные восстановили быстро, а индекс для поиска и RAG пересобирается сутками. Это не заложено в RTO, и пользователи видят «работает, но ничего не находит». Если у вас есть резервное копирование индекса, проверьте, что оно возвращает прежнюю скорость и качество выдачи.

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

Отдельная история - запасные GPU. Железо может стоять на складе, но несовпадение драйверов, CUDA, версии ядра или контейнерных образов делает его бесполезным. Совместимые версии нужно фиксировать заранее и держать готовый эталонный образ.

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

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

Короткий чеклист перед запуском DR для on-prem LLM

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

• Цели непрерывности зафиксированы письменно: RTO и RPO согласованы с владельцем сервиса и понятны дежурным.
• Есть полный перечень того, что восстанавливается: исходные данные, индекс (например, векторный), модели, конфиги, секреты и ключи, журналы и метрики.
• Резервные копии проверены восстановлением: известна последняя точка, проверена целостность, замерено реальное время восстановления на тестовом стенде. Отдельно подтверждено, что бэкап индекса дает ожидаемую скорость возврата сервиса.
• Репликация и снапшоты работают предсказуемо: известно текущее отставание, отработано переключение на резерв и обратное переключение после устранения причины.
• Вычисления готовы: есть резерв GPU и серверов (или подтвержденная квота), а запуск LLM-сервиса на резерве уже проходили руками по инструкции.

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

Пример сценария: отказ ЦОД и возврат LLM-сервиса в работу

11:20, будний день. Основная площадка пропадает из сети: мониторинг показывает недоступность гипервизоров, затем падают API LLM и векторный поиск. Первое, что ощущают пользователи, - ответы перестают приходить, а новые документы не индексируются.

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

Дальше включается заранее подготовленный DR для LLM on-prem на резервной площадке:

• Поднимают реплицированное хранилище или последний чистый снапшот и проверяют целостность (контрольные суммы, доступность ключевых томов).
• Восстанавливают векторный индекс из бэкапа (или подключают актуальную реплику), не запуская массовую пересборку без необходимости.
• Запускают сервис LLM и очередь задач в «урезанном» режиме: ограничивают параллелизм, включают лимиты, используют запасные GPU или временно меньше моделей.
• Возвращают доступы: секреты, токены, роли, доступ к ключевым API и журналам.
• Переключают трафик на резерв (внутренний DNS или балансировщик) и включают запись только после валидации.

Проверка качества занимает 10-15 минут и важнее, чем «просто поднялось». Достаточно выборочно проверить типовые запросы: несколько вопросов по ключевым регламентам и договорам с ожидаемыми ссылками на документы, поиск по редким терминам (коды, номера приказов), а также один запрос, где важна свежесть, со сверкой времени последнего обновления.

После стабилизации фиксируют причины отказа, обновляют емкость (если работали на уменьшенном количестве GPU) и корректируют лимиты, чтобы RTO и RPO совпадали с реальностью. Если нужна помощь с подбором и внедрением железа под такой план непрерывности, уместно заранее привлекать партнера, который умеет собрать серверный контур, интеграцию и поддержку в один процесс, например на базе стоечных серверов уровня S200 и с опорой на сервисную сеть.