Да, тупые название - чтобы не было индексации, почему? не люблю известность.
Метро-кластер (Metro Cluster) — это высокодоступная архитектура, объединяющая два (или более) географически разнесённых дата-центра в единую отказоустойчивую систему хранения данных. Она использует синхронную репликацию данных между двумя площадками, чтобы обеспечить нулевую потерю данных (RPO = 0) и минимальное время восстановления (RTO ≈ 0).
Компоненты метро-кластера:
- Два активных хранилища на разных площадках.
- Синхронная репликация всех данных в реальном времени.
- Арбитр (witness) — третий узел, выступающий как "судья" при split-brain.
- Клиентская зона доступа, которая "видит" обе системы как одну.
Преимущества метро-кластера:
- Максимальная доступность — система выдерживает отказ одного из дата-центров.
- Нулевая потеря данных — синхронная репликация.
- Быстрое восстановление — нет необходимости "восстанавливать" данные, потому что они уже есть в рабочем виде.
- Прозрачность для приложений — не требуется ручной перевод или конфигурация со стороны клиента.
Недостатки:
- Высокая стоимость — двойное оборудование, высокая пропускная способность каналов, требование к каналу по задержке и надёжности.
- Сложность внедрения — требует сетевых и СХД-экспертов, сертифицированных решений.
- Невозможность масштабирования на большие расстояния (ограничено по latency).
Где применяют метро-кластеры:
- Финансовые организации (банки, биржи)
- Телеком (billing, HLR, user data)
- Госсектор (МФЦ, налоговые, реестры)
- Крупные производственные компании (MES-системы, SCADA)
- Медицинские учреждения (ПАКС, ЭМК, ЛИС)
- Платформы 24/7 (интернет-магазины, маркетплейсы, SaaS)
Как "продавать" метро-кластер:Покажите ценность непрерывности бизнеса: «если упадёт ЦОД — ничего не произойдёт».Обоснуйте финансовые риски простоя: каждая минута = Х тысяч рублей/долларов.Подчеркните соответствие требованиям отраслевых регуляторов (ЦБ, 152-ФЗ, GDPR, и т.д.).Приведите референсные примеры: кто уже использует и какие риски они таким образом нивелировали.
Метро-кластер (metropolitan cluster или metrocluster) — это архитектурный подход, который охватывает всю ИТ-инфраструктуру, включая:СХД (системы хранения данных),серверы,виртуализацию,сети,и сервисные приложения,расположенные в двух географически разнесённых площадках, обычно в пределах одного города (отсюда и «метро»).
Ключевая мысль: Метро-кластер — это не просто технология репликации в СХД, это отказоустойчивый комплекс из СХД + сервисов, обеспечивающий нулевой или минимальный downtime.
Если говорить маркетингово — метро-кластер продаёт не просто хранилище, а "непрерывность бизнеса", то есть возможность компании работать даже при полном отключении одного из дата-центров.
Что означает метка «метрокластер» в СХД:
(или как ты меня достал Аквариум)
Синхронная репликация в реальном времени
- данные одновременно записываются в оба дата-центра.
- подтверждение записи приложению происходит только после того, как обе стороны подтвердили запись.
Автомаическое переключение (failover)
- если одна площадка выходит из строя, вторая автоматически (или полуавтоматически) принимает на себя нагрузку без потери данных.
- особенно критично для систем, где время простоя = деньги (банки, биржи, госпитали, ритейл).
Единое логическое пространство
- две (или более) СХД выглядят как единый массив.
- это важно для кластеров баз данных, виртуализации, SAP, Oracle RAC и других отказоустойчивых решений.
Поддержка split-brain защиты
- встроенные механизмы, чтобы избежать «раздвоения сознания» кластера, например, через третий арбитр(witness) или механизм «quorum».
В классической синхронной репликации СХД (Storage-based synchronous replication) автоматическое переключение чаще всего отсутствует. Основная задача такой репликации — обеспечение полной синхронности данных между двумя хранилищами, но:
Что делает сама синхронная репликация СХД:
- Ждёт подтверждения записи на обоих сайтах (Primary и Secondary).
- Гарантирует консистентность: данные 1:1 одинаковые.
- Используется, например, в банковских системах, платёжках, SAP и т.п.
- Но при отказе одного из сайтов… переход на другую сторону — это ручная работа:
- Либо с помощью сценариев, оркестратора (например, VMware Site Recovery Manager),
- Либо вручную через администратора.
А вот метрокластер (MetroCluster) — это уже надстройка:
Это решение «под ключ», объединяющее:
- синхронную репликацию данных,
- автоматическое переключение сервисов,
- часто — кластеризацию виртуализации, баз данных, приложений и т.п.
- Обычно работает на уровне приложений + СХД, либо в интеграции.
- Например: NetApp MetroCluster, Hitachi GAD + MetroCluster, VMware vSphere Metro Storage Cluster.
Метро-кластер практически всегда требует доработок или специфической настройки виртуальной среды, особенно если вы хотите добиться автоматического переключения (failover) и высокой доступности без вмешательства администратора. Вот почему:
Почему метро-кластер требует доработок виртуальной среды
Общие хранилища на двух площадках:
- Метро-кластер подразумевает, что у виртуальных машин должен быть доступ к хранилищу (LUN/Volume), синхронно реплицируемому между двумя дата-центрами. Это требует:
- поддержки Storage vMotion / VMFS / vSAN stretched clusters;
- настроенного кворума и высоко доступной сетевой связности.
Интеграция с гипервизором:
Например:
VMware vSphere Metro Storage Cluster (vMSC) требует:
- сертифицированное СХД-решение;
- специфическую настройку HA/DRS;
- адаптацию таймаутов SCSI / APD / PDL.
В Microsoft Hyper-V — аналогичная история: требуется настройка Failover Clustering с корректной логикой для работы на двух площадках.
Кворум третьей площадки (witness):
- Чтобы избежать split-brain, нужен арбитр — третий элемент в архитектуре, обычно размещённый в третьем ЦОДе или в облаке.
Если продаёте СХД с возможностью MetroCluster, нужно сразу обсуждать совместимость и сертификацию со стороной виртуализации!!!
Метро кластер ≠ просто синхронная репликация СХД
Метро кластер (в понимании производителей и заказчиков) — это комплексное решение, которое:
- Обеспечивает синхронную репликацию между двумя СХД;
- Поддерживает автоматическое переключение (failover) в случае сбоя одного из узлов;
- Интегрируется с виртуальной/кластерной средой (например, VMware vSphere Metro Storage Cluster, Microsoft Failover Cluster, Red Hat Cluster Suite и т.д.);
- Может быть прозрачным для приложений — без сбоев, перезапусков и потерь данных.
Без внешнего кластера это просто синхронная репликация
- Если у тебя просто синхронная репликация СХД — да, данные зеркалируются блок в блок, но…
- Автоматического переключения не будет. Администратор вручную должен переключить хосты на вторую СХД, вручную изменить маршруты, заново примонтировать диски и т.д.
- Это критично: на уровне приложений может быть потеря доступа или сбой.
Требуется доработка/интеграция с виртуальной/кластерной средой
Метро кластер требует:
- Решений верхнего уровня, которые "поймут", что узел отказал и "переведут" вычисления на вторую сторону;
- Интеграции с гипервизором, оркестратором или кластерным ПО (например, stretched cluster VMware).
Если ты продаёшь СХД, и видишь, что заказчик не готов интегрироваться с виртуализацией, ты предлагаешь:
- Синхронную репликацию с ручным failover (и честно предупреждаешь: без автоматизации).
Если заказчик:
• • Использует VMware или Hyper-V, у него распределённый ЦОД, и нужны RPO=0 + RTO~0 — ты продаёшь полноценный метро кластер, обсуждаешь совместимость и услуги по внедрению (вплоть до VMWare SRM, stretched HA и т.д.).
Что делать с "Закладкой" в 44ФЗ? Требовать разъяснений! С какой конкретной виртуальный средой требуется работа, как ЗАКЗАЧИК видит - работу метрокластера, а ДАЛЬШЕ дело техники)