Shared Disk Secondary

Shared Disk Secondary — это архитектурный подход к организации высокопроизводительных вычислительных систем, при котором вторичное хранилище данных (диски, массивы) является общим для нескольких вычислительных узлов (серверов), а первичная обработка данных выполняется на одном из них, называемом первичным (Primary). В случае отказа первичного узла его функции автоматически или вручную передаются вторичному узлу (Secondary), который подключается к тому же общему дисковому массиву. Данная схема является одной из классических реализаций отказоустойчивых кластеров (high-availability clusters) и часто противопоставляется архитектурам с репликацией данных (Shared Nothing) или распределённым хранилищем.

История

Концепция Shared Disk Secondary возникла в 1980-х годах, когда для корпоративных приложений (баз данных, ERP-систем) потребовалось обеспечить непрерывность работы при сбоях оборудования. Первые коммерческие реализации появились в системах кластеризации для операционных систем Unix (например, Veritas Cluster Server, Sun Cluster). В 1990-х годах Microsoft внедрила аналогичный подход в Windows NT с технологией Microsoft Cluster Service (MSCS), позднее эволюционировавшей в Failover Clustering. В 2000-х годах архитектура стала стандартом для критически важных систем в банковской сфере, телекоммуникациях и государственных учреждениях, где время простоя измерялось минутами в год.

Принцип работы

В архитектуре Shared Disk Secondary все узлы кластера имеют физический или логический доступ к одному и тому же дисковому массиву (SAN, NAS, DAS). Однако в нормальном режиме только один узел — первичный (Primary) — монтирует файловую систему или базу данных и выполняет операции записи/чтения. Вторичный узел (Secondary) находится в режиме ожидания (standby), не имея активного доступа к данным, но постоянно мониторя состояние первичного узла через сеть «пульса» (heartbeat).

При обнаружении сбоя первичного узла (например, отказ питания, сбой ОС, потеря сетевой связности) вторичный узел:

1. Перехватывает управление общим диском.
2. Выполняет проверку целостности файловой системы (fsck, chkdsk).
3. Монтирует раздел и запускает приложение (базу данных, веб-сервер).
4. Перенаправляет сетевые запросы на свой IP-адрес (обычно используется плавающий IP).

Время переключения (failover) составляет от нескольких секунд до нескольких минут, в зависимости от объёма данных и сложности проверки.

Классификация

По способу доступа к дискам

• Активный/пассивный (Active/Passive) — самый распространённый вариант. Первичный узел активен, вторичный простаивает. Ресурсы вторичного узла (CPU, память) не используются для обработки запросов, что снижает эффективность, но упрощает отказоустойчивость.
• Активный/активный (Active/Active) — оба узла одновременно обрабатывают запросы, но каждый работает с собственным набором данных на общем диске (например, разные базы данных). При отказе одного узла его нагрузка перераспределяется на другой. Требует более сложного управления блокировками и разделения ресурсов.

По типу хранилища

• С использованием SAN (Storage Area Network) — диски подключаются через Fibre Channel или iSCSI. Обеспечивает высокую производительность и централизованное управление.
• С использованием NAS (Network Attached Storage) — общий доступ через NFS или SMB. Менее производительно, но проще в настройке.
• С использованием DAS (Direct Attached Storage) — диски физически подключены к одному узлу, а второй узел подключается через специальный кабель (например, SCSI-кабель). Устаревший вариант, применяется в небольших системах.

Устройство и компоненты

Типовая реализация Shared Disk Secondary включает следующие элементы:

• Два или более вычислительных узла — серверы с одинаковой конфигурацией (CPU, RAM, ОС). Для исключения единой точки отказа они часто подключаются к разным источникам питания и сетевым коммутаторам.
• Общий дисковый массив — RAID-массив (уровни 1, 5, 6, 10) или система хранения данных (СХД) с резервированием контроллеров. Диски форматируются в файловую систему, поддерживающую кластеризацию (например, NTFS, ext4, XFS, или специализированные кластерные ФС — GFS2, OCFS2).
• Сеть пульса (heartbeat) — выделенная сеть (обычно Ethernet 1 Гбит/с или выше) для обмена служебными сообщениями между узлами. Используется для обнаружения сбоев.
• Программное обеспечение кластеризации — управляет переключением, мониторингом, блокировками. Примеры: Microsoft Failover Clustering, Pacemaker (Linux), Veritas Cluster Server, IBM PowerHA.
• Плавающий IP-адрес — виртуальный IP, который при переключении переходит на активный узел, обеспечивая прозрачность для клиентов.

Применение

Архитектура Shared Disk Secondary широко используется в системах, где критически важна непрерывность работы, а потеря данных недопустима:

• Корпоративные базы данных — Microsoft SQL Server, Oracle Database, IBM DB2. При отказе сервера база данных перезапускается на вторичном узле с минимальной потерей транзакций.
• Файловые серверы — Windows File Server, Samba. Обеспечивает доступ к общим папкам без простоев.
• Почтовые системы — Microsoft Exchange Server, IBM Lotus Domino. Позволяет сохранить доступ к почтовым ящикам при сбое.
• Виртуализация — Hyper-V, VMware vSphere. Виртуальные машины могут быть настроены на отказоустойчивый кластер с общим хранилищем.
• Промышленные системы управления — SCADA, системы управления технологическими процессами, где простой может привести к авариям.

Преимущества и недостатки

Преимущества

• Простота реализации — не требует сложной репликации данных между узлами. Все данные хранятся в одном месте.
• Минимальная задержка при переключении — при отказе первичного узла вторичный сразу получает доступ к актуальным данным, если не требуется длительная проверка целостности.
• Совместимость — поддерживается большинством операционных систем и СУБД без модификации приложений.
• Экономия на хранении — не требуется дублирование дискового пространства (как в репликации), так как данные хранятся в единственном экземпляре.

Недостатки

• Единая точка отказа для хранилища — если общий дисковый массив выходит из строя, кластер становится недоступен. Требуется резервирование на уровне СХД (дублирование контроллеров, дисков, каналов).
• Ограниченная масштабируемость — добавление новых узлов усложняет управление блокировками и может привести к конфликтам доступа.
• Простой вторичного узла — в режиме Active/Passive ресурсы вторичного узла не используются для полезной работы, что снижает общую эффективность.
• Зависимость от сети пульса — при сбое сети пульса возможна ситуация «split-brain», когда оба узла считают себя первичными и пытаются монтировать диск, что может привести к повреждению данных. Для предотвращения используются механизмы fencing (STONITH — Shoot The Other Node In The Head).

Критика и альтернативы

Архитектура Shared Disk Secondary критикуется за недостаточную гибкость в современных распределённых средах. В облачных и контейнерных платформах (Kubernetes, OpenStack) чаще применяется подход Shared Nothing, где каждый узел хранит собственную копию данных, а синхронизация осуществляется через репликацию (например, в базах данных PostgreSQL с потоковой репликацией или в распределённых файловых системах Ceph, GlusterFS). Это позволяет избежать единой точки отказа в виде общего дискового массива и обеспечивает географическую распределённость.

Тем не менее, Shared Disk Secondary остаётся востребованным в legacy-системах и в сценариях, где требуется максимальная производительность при минимальной задержке (например, в высоконагруженных базах данных с OLTP-нагрузкой). В России данная архитектура применяется в государственных информационных системах (например, в системах электронного документооборота, реестрах) и в банковском секторе, где требования к отказоустойчивости регулируются стандартами Центрального банка РФ.

Интересные факты

• Термин «Shared Disk Secondary» часто путают с «Shared Disk Cluster», но последний подразумевает возможность одновременного доступа нескольких узлов к данным (Active/Active), что требует кластерной файловой системы.
• В системах с Shared Disk Secondary время переключения (RTO — Recovery Time Objective) обычно составляет от 30 секунд до 5 минут, а потери данных (RPO — Recovery Point Objective) — от нескольких секунд до нескольких минут, в зависимости от режима кэширования.
• Для защиты от «split-brain» в кластерах на базе Linux Pacemaker используется механизм STONITH, который принудительно отключает питание сбойного узла через удалённый блок питания (IPMI) или сетевой коммутатор.

Источники

• Microsoft Docs. «Failover Clustering Overview». 2023.
• Red Hat. «Pacemaker: A High-Availability Cluster Resource Manager». 2022.
• Veritas Technologies. «Veritas Cluster Server Administrator’s Guide». 2021.
• ГОСТ Р ИСО/МЭК 25010-2015. «Информационные технологии. Качество программных продуктов».
• Техническая документация по кластеризации Oracle Real Application Clusters (RAC).