Подробный гайд: Катастрофоустойчивая СХД на оптических каналах (FC/iSCSI/FCoE)

Гайд по проектированию катастрофоустойчивой СХД на оптических каналах: синхронная/асинхронная репликация, FC/iSCSI/FCoE, RPO/RTO, пошаговая настройка и тестирование.

Подробный гайд: катастрофоустойчивая СХД на оптических каналах (FC/iSCSI/FCoE) Данный гайд описывает принципы проектирования, развертывания и эксплуатации системы хранения данных (СХД), построенной на оптических каналах связи (Fibre Channel, iSCSI, FCoE), с обеспечением защиты от катастроф (Disaster Recovery, DR). Основная цель — гарантировать доступность данных и быстрое восстановление бизнес-процессов после аварий, стихийных бедствий или человеческих ошибок.

1. Базовые понятия

1.1. СХД и оптические технологии

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

Основные протоколы:

Fibre Channel (FC) — классический протокол SAN, работает поверх выделенных оптоволоконных сетей. Скорости: 8/16/32/64 Гбит/с. Низкая задержка, высокая надежность.
iSCSI — передача SCSI-команд по TCP/IP, обычно поверх Ethernet (медные или оптические линии). Более дешевый, но с более высокими накладными расходами.
FCoE (Fibre Channel over Ethernet) — инкапсуляция FC-кадров в Ethernet, требует поддержки DCB (Data Center Bridging) и обычно используется внутри ЦОД.
NVMe-oF — современный протокол для твердотельных накопителей, работает поверх RDMA (RoCE, InfiniBand) или FC.

Для междугородних соединений (между ЦОДами) часто применяют FC over DWDM/CWDM или iSCSI через выделенные каналы IP/MPLS.

1.2. Катастрофоустойчивость и ключевые метрики

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

Основные показатели:

RPO (Recovery Point Objective) — допустимая потеря данных во времени. Определяет, как часто выполняется репликация/резервное копирование.
RTO (Recovery Time Objective) — время, за которое сервис должен быть восстановлен после аварии.

Чем меньше RPO и RTO, тем дороже и сложнее решение.

2. Архитектуры защиты от катастроф

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

2.1. Синхронная репликация

Принцип: каждая запись подтверждается приложению только после сохранения на обеих площадках.
RPO = 0 (данные не теряются), RTO — минуты (при автоматическом переключении).
Требования: расстояние обычно до 50–100 км (из-за задержек), высокая пропускная способность, низкая латентность (< 5 мс). Требует выделенных оптических линий.
Сценарий: Active-Standby — основная СХД обслуживает нагрузку, резервная находится в режиме ожидания; либо Active-Active с синхронным зеркалированием на уровне приложений.

2.2. Асинхронная репликация

Принцип: запись подтверждается сразу на основной площадке, затем изменения периодически или непрерывно передаются на резервную.
RPO — от нескольких секунд до часов (зависит от расписания и загрузки).
RTO — от минут до часов.
Требования: допустимы большие расстояния (сотни и тысячи км), меньше требований к латентности.
Сценарий: основной ЦОД работает, резервный получает данные с задержкой; при аварии возможна потеря последних транзакций.

2.3. Географически распределенные кластеры

Если необходимо обеспечить непрерывность работы приложений (Active-Active), применяются растянутые кластеры (stretched cluster) на базе синхронной репликации и виртуализации (VMware vSAN, Microsoft Storage Spaces Direct, Oracle RAC и др.). Требуют специализированного оборудования для синхронизации кэша и обеспечения консистентности.

3. Проектирование оптической инфраструктуры

3.1. Выбор транспорта между площадками

Критерий	Fibre Channel (FC)	iSCSI (Ethernet)	FCoE (Ethernet)
Оборудование	FC-коммутаторы, HBA, оптика	Стандартные Ethernet-коммутаторы, сетевые карты	DCB-коммутаторы, CNA (Converged Network Adapter)
Стоимость	Высокая	Низкая–средняя	Средняя–высокая
Латентность	Очень низкая	Выше (TCP/IP overhead)	Низкая (при правильной настройке)
Расстояние	До 100 км (с DWDM больше)	Практически не ограничено (IP-сети)	Внутри ЦОД (до 10 км)
Сложность	Требует экспертизы в FC	Проще в управлении	Требует настройки DCB, QoS

Для связи между ЦОДами чаще всего выбирают:

FC через DWDM/CWDM — если нужна синхронная репликация и минимальная задержка.
iSCSI через выделенные каналы Ethernet/IP/MPLS — для асинхронной репликации на большие расстояния.
Гибрид: внутри ЦОД FC, между площадками — FCIP (FC over IP) или iSCSI.

3.2. Компоненты оптической сети

Оптические трансиверы (SFP, SFP+, QSFP) — подбираются под тип волокна (одномод/многомод) и требуемую дальность.
Патч-корды и магистральные кабели — одномодовое волокно (SMF) для дальних расстояний, многомодовое (MMF) — для внутристоечных соединений.
FC-коммутаторы / директоры — для построения SAN-фабрики, поддержка зонирования, ISL-транков.
Мультиплексоры DWDM/CWDM — позволяют передавать несколько независимых каналов (FC, Ethernet) по одной паре волокон, экономя оптику.
Оптические усилители (EDFA) — для сверхдальних линий (> 80 км).

3.3. Требования к каналу для синхронной репликации

Задержка (RTT) — не более 5 мс (идеально < 2 мс).
Пропускная способность — должна покрывать пиковую нагрузку записи + 20–30% запас.
Джиттер — минимальный, стабильное соединение.
Надежность — дублирование линий, резервные маршруты.

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

4. Выбор СХД и лицензий для репликации

Большинство корпоративных СХД (Dell EMC PowerStore, NetApp AFF, HPE Primera/Alletra, Huawei OceanStor, IBM FlashSystem, Pure Storage) поддерживают встроенные механизмы репликации.

Примеры:

Dell EMC: SRDF (Symmetrix), RecoverPoint, PowerStore Native Replication.
NetApp: SnapMirror (асинхронная), SnapMirror Synchronous, MetroCluster (синхронный кластер).
HPE: Peer Persistence, Remote Copy.
Huawei: HyperReplication (синхронная/асинхронная), HyperMetro (Active-Active).

При выборе учитывайте:

Поддержку нужного типа репликации (синхронная/асинхронная).
Возможность создания Consistency Groups (групп консистентности) для нескольких LUN/томов, чтобы сохранить целостность данных приложений.
Наличие средств автоматического переключения (failover) и возврата (failback).
Лицензионные требования (часто репликация — платная опция).

5. Пошаговая настройка катастрофоустойчивой репликации

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

Шаг 1. Планирование

Определите RPO/RTO для каждого приложения.
Выберите тип репликации (синхронная/асинхронная).
Рассчитайте требуемую пропускную способность канала и убедитесь, что задержка соответствует требованиям.
Подготовьте IP-адресацию или FC-зонирование для репликационных портов.
Создайте документацию с описанием топологии и процедур.

Шаг 2. Настройка сети

Для FC:

Настройте zoning: разрешите связь между портами репликации основной и резервной СХД.
Если используется FCIP, настройте туннели между FCIP-шлюзами.
Проверьте связность командой switchshow и fabriclog.

Для iSCSI:

Выделите отдельные VLAN для репликационного трафика.
Настройте Jumbo Frames (MTU 9000) для снижения накладных расходов.
Обеспечьте QoS на маршрутизаторах для приоритизации трафика репликации.

Шаг 3. Настройка репликации на СХД

Общий порядок (на примере абстрактной системы):

Создайте пулы/агрегаты и тома (LUN) на обеих СХД.
Определите репликационные пары (source volume → target volume). Резервный том обычно создается автоматически с теми же параметрами.
Настройте параметры репликации:
- Режим: synchronous / asynchronous.
- Для асинхронной — интервал обновления или непрерывная передача.
- Создание Consistency Group, если необходимо.
Инициализируйте репликацию: выполните первичную синхронизацию (initial sync) — обычно по сети или с помощью внешнего носителя (seed).
Настройте политики автоматического переключения (failover/failback) и оповещения.

Пример для NetApp SnapMirror (CLI):

# Создание отношения SnapMirror
snapmirror create -source-path SVM:volume -destination-path SVM:volume -type XDP -schedule hourly
# Инициализация
snapmirror initialize -destination-path SVM:volume
# Проверка состояния
snapmirror show

Для Dell EMC PowerStore (GUI): раздел Protection → Replication → Remote Systems → Create Remote System, затем Add Replication Session.

Шаг 4. Интеграция с приложениями

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

VMware vSphere: Site Recovery Manager (SRM) с адаптерами хранилища (SRA) для оркестрации переключения.
Microsoft: Hyper-V Replica, Storage Replica.
Oracle: Data Guard, ASM.
SAP HANA: HANA System Replication.

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

Шаг 5. Тестирование

Регулярно (раз в квартал/полгода) проводите учения по восстановлению:

Полный тест отработки отказа (failover) на резервную площадку.
Проверка целостности данных и работоспособности приложений.
Обратное переключение (failback).
Документирование времени и выявленных проблем.

6. Безопасность и шифрование

Шифрование каналов: для FC используйте FC-SP (Fibre Channel Security Protocol), для iSCSI/FCoE — IPSec или MACsec. При передаче через общие сети (WAN) шифрование обязательно.
Шифрование данных на СХД: самошифрующиеся диски (SED) или программное шифрование томов, чтобы защитить данные в случае кражи носителей.
Аутентификация и контроль доступа: используйте CHAP для iSCSI, zoning и LUN masking для FC, RBAC для управления СХД.

7. Типичные ошибки и рекомендации

Недооценка требований к каналу: синхронная репликация при задержке > 5 мс приведет к таймаутам и падению производительности. Проводите нагрузочное тестирование до внедрения.
Отсутствие Consistency Groups: при репликации нескольких томов без группы консистентности при аварии данные могут быть несовместимы (например, база данных и журналы).
Нет плана обратного переключения: важно не только переключиться на резерв, но и уметь вернуться обратно без потери данных.
Игнорирование регулярного тестирования: план DR, который не проверяется, не работает.
Неправильная настройка сети: смешивание репликационного и пользовательского трафика в одном VLAN может вызвать задержки и потерю пакетов.

Важно

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

Ключевые факторы успеха:

Четкое понимание RPO/RTO для каждого сервиса.
Правильный выбор транспорта (FC/iSCSI/FCoE) и топологии.
Использование проверенных механизмов репликации СХД с поддержкой консистентности.
Интеграция с системами виртуализации и приложениями для автоматизации аварийного переключения.
Регулярные учения и актуализация документации.

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

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

Статью подготовил: Аверко Денис Сергеевич @Nymexis г. Омск (специалист по ЗИ)