Как убрать единую точку отказа PowerEdge

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

Задача — не купить «второй сервер на всякий случай». Нужно разделить сервисы так, чтобы остановка одного PowerEdge не оставила компанию без всех рабочих систем сразу. При этом нельзя честно обещать переключение за пять минут или доступность 99,9%: для такого расчёта нужны схема инфраструктуры, замеры восстановления и стоимость простоя.

Составьте карту зависимостей до выбора железа #

Начните не с моделей PowerEdge, а с цепочки, которая приводит пользователя к сервису:

Подготовка второго узла к восстановлению

PowerEdge → гипервизор или ОС → сервер приложений → СУБД → данные → лицензии

Такая карта показывает, что именно исчезнет при остановке каждого компонента. Если на одном узле находятся сервер 1С, PostgreSQL и каталог резервных копий, перенос только службы 1С на другую машину не устраняет общий отказ. База и копии всё ещё зависят от первого сервера.

Для 1С на Linux отметьте конкретные точки восстановления. Методическая поддержка 1С называет службу srv1cv83, файл настроек /etc/sysconfig/srv1cv83, параметр каталога данных SRV1CV8_DATA и каталог журналов /var/log/1c/logs. Одного установленного пакета мало: после аварии потребуются настройки, данные и доступ к лицензиям.

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

Второй сервер должен восстанавливать сервис, а не повторять первый #

Для компании с одним PowerEdge разумная исходная схема выглядит так:

узел A обслуживает рабочую нагрузку;
узел B принимает выбранные критичные службы либо восстановленную копию после отказа;
резервные данные лежат за пределами обоих узлов.

Роль узла B нужно записать одним предложением. Например: «На нём запускаем СУБД и сервер 1С из резервной копии» или «Он постоянно обслуживает файловые ресурсы, а при аварии принимает 1С». Формулировка «резервный сервер» ничего не говорит администратору во время сбоя.

Не переносите весь набор служб на один новый, более крупный PowerEdge. Так Вы обновите железо, но сохраните прежнюю архитектуру: одна остановка по-прежнему отключит 1С, файлы и базу.

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

Для Oracle берите совместимость из матриц Dell #

Сочетание PowerEdge, ОС, СХД и сетевых компонентов под Oracle не стоит собирать по памяти. Dell публикует Oracle Validated Configurations — проверенные конфигурации для Oracle Linux и Oracle VM, куда входят программное обеспечение, серверы, хранилище и сеть.

Для проверки конкретных компонентов Dell указывает ещё три вида документов:

Hardware Certification List для серверов и массивов под Oracle Linux или Oracle VM;
SDL или Interoperability Matrix с перечнем проверенных компонентов;
Reference Architecture Whitepapers с готовыми архитектурами Oracle Database на оборудовании Dell.

Если требуемой модели, ОС или СХД нет в соответствующем документе, это не доказывает несовместимость. Но риск проверки и устранения проблем переходит на Вашу команду.

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

Модель, ОС и поддержку проверяют отдельно #

Перед закупкой откройте официальный индекс технических характеристик PowerEdge. В нём есть документация для поколений от R240, R640 и R740 до R660, R760 и R770. Для моделей с отдельной отметкой Dell размещает характеристики в разделе Technical Specifications руководства Installation and Service Manual.

Затем проверьте поддержку нужной ОС на странице Dell Server Operating Systems. Совпадения процессорного сокета и объёма памяти недостаточно: второй узел должен запускать ту ОС, на которой Вы собираетесь восстанавливать сервис.

Состояние поддержки проверяют по Service Tag каждого имеющегося сервера. Dell Support показывает доступный уровень сервиса и дату его окончания рядом с карточкой устройства.

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

Время восстановления узнают на испытании #

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

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

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

До переноса проверьте накопители и журнал iDRAC. Если Lifecycle Log уже сообщает о проблемах диска, сначала разберите их по процедуре диагностики SSD0001 и PDR16 в iDRAC. Перенос с повреждённого массива добавит к архитектурной работе риск потери данных.

Что сделать до закупки второго PowerEdge #

Запишите все службы, данные, лицензии и сетевые зависимости первого узла.
Проверьте Service Tag и дату окончания поддержки каждого сервера.
Сверьте модели PowerEdge и нужную ОС с документацией Dell.
Назначьте второму узлу конкретные рабочую и аварийную роли.
Разместите резервные копии вне обоих серверов.
Восстановите один сервис из копии и запишите фактическое время.
Повторите проверку для каждой системы, остановка которой блокирует работу компании.

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