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

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

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

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

Руслан Верчинов: Я бы выделил две категории. Первая — ключевые системы тех отраслей, где от актуальности данных зависят жизнь, здоровье и безопасность людей: медицина, управление воздушным и морским транспортом, другие объекты критической инфраструктуры. Здесь необходимо сохранять доступ к актуальным данным даже при потере целого ЦОДа. Во вторую категорию попадает крупный бизнес, для которого остановка информационных систем или потеря актуальных данных фактически означает остановку деятельности. Например, банки, телеком-операторы, биржевые площадки, крупные маркетплейсы.

Для других игроков оценка целесообразности внедрения геораспределенного кластера требует оценки с точек зрения стоимости решения и критичности простоя ИТ-сервисов бизнеса.

Руслан Верчинов: В большинстве геораспределенных кластеров используется асинхронная репликация: данные передаются из основного ЦОДа в резервный с определенной периодичностью — например, раз в десять минут, час или сутки. Если основной ЦОД выходит из строя, часть последних изменений, еще не переданных на резервную площадку, может быть потеряна.

Метрокластер DEPO Atlas предполагает синхронную репликацию. Данные на обеих площадках постоянно поддерживаются в согласованном состоянии. Поэтому при выходе из строя одного ЦОДа на втором остается актуальная копия данных. Также очень важной особенностью нашего метрокластера является не только функция репликации самих данных, но и обеспечение непрерывного предоставления ИТ-сервисов. То есть, при потере одной из площадок мы сохраняем не только данные, но и функциональность ИТ-инфраструктуры.

В основе нашего решения лежит одна из моделей программно-аппаратных комплексов DEPO Atlas. Мы организуем необходимую сетевую связность между модулями метрокластера, которые затем разносим на географически удаленные площадки. Далее, объединенные таким образом ЦОДы воспринимаются кластером виртуализации как единая инфраструктура.

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

Арбитр (или третья площадка ЦОД) обеспечивает возможность кворума при принятии решения в случае отказов площадок или каналов связи. При обрыве связи между основными площадками каждый ЦОД может решить, что второй вышел из строя, и самостоятельно продолжить работу. Данные разойдутся — возникнет так называемый «split-brain»: разница в данных, записываемых на разных площадках. Чтобы этого избежать, как раз и нужен арбитр.

Арбитр помогает правильно выбрать площадку, которая должна продолжить работать. Если ЦОД перестает «видеть» и партнера, и арбитра, он останавливается, а второй, сохранивший связь с арбитром, работает. Если оба ЦОДа «видят» только арбитра (но не друг друга), то по заранее заданному правилу один из них продолжает работу, а второй останавливает сервисы. Арбитр формирует кворум и не допускает независимой работы двух ЦОД.

Руслан Верчинов: Дело в задержках при передаче данных. Чем больше расстояние, тем выше задержка, а при синхронной репликации она непосредственно влияет на скорость записи. На расстоянии 40 км скорость записи на быстрые флеш-накопители снижается примерно вдвое, а на 100 км — в несколько раз. Это примерные оценки, но они хорошо иллюстрируют характер ограничений. На больших расстояниях синхронная репликация нецелесообразна.

Заказчики регулярно нас спрашивают, можно ли объединить в метрокластер ЦОДы в разных городах и даже регионах, например, в Москве и Нижнем Новгороде. К сожалению, на таком расстоянии задержки окажутся слишком большими. Если у компании нет возможности использовать более близко расположеные площадки, мы рекомендуем решения с асинхронной репликацией.

Руслан Верчинов: Мы последовательно отключаем серверы и сетевые устройства, проверяя реакцию кластера на отказ каждого компонента. Такие испытания проводят и для локальных кластеров.

Специфика метрокластера — проверка сетевой связности между площадками. Мы по очереди отключаем каналы между ЦОДами, между каждым ЦОДом и арбитром, а затем моделируем комбинации отказов. Например, изолируем одну площадку или оставляем обоим ЦОДам связь с арбитром, разорвав соединение между ними. Важно убедиться, что кластер правильно выбирает сценарии для обеспечения работы площадок кластера.

Руслан Верчинов: В качестве узлов вычисления и хранения в составе метрокластера мы используем серверы DEPO Storm 3500 на процессорах четвертого и пятого поколений. Унифицированная платформа основных узлов упрощает модернизацию и техническую поддержку метрокластера.

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

При этом само решение не привязано к конкретным моделям серверов: мы можем строить метрокластеры и на другом оборудовании, поскольку владеем самой технологией их реализации. DEPO Storm 3500 — основа нашей типовой конфигурации, а не единственно возможный вариант.

Руслан Верчинов: Есть три блока. Первый — подготовка площадок ЦОД, которые обычно находятся в зоне ответственности заказчика. Второй — организация связи между ними. Предпочтителен выделенный оптоволоконный канал, однако для небольших метрокластеров подойдет и провайдерский канал с пропускной способностью от 10 Гбит/с. Третий блок — производство и внедрение непосредственно ПАК DEPO Atlas, за который отвечаем мы.

Обычно наиболее сложным становится организация совместной работы специалистов из каждого блока задач. Со своей стороны мы, помимо производства и поставки ПАК, готовы помогать в вопросах проектирования площадок и организации каналов связи.

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

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

Наши специалисты подключаются к поиску причины, а после ее установления либо устраняют самостоятельно, либо консультируют специалистов, обеспечивающих поддержку инфраструктуры заказчика и каналов связи. Мы проводим диагностику комплекса в целом даже когда источник инцидента находится за рамками ПАК DEPO Atlas.

Руслан Верчинов: Технология метрокластеров давно известна. Теоретически, хорошему интегратору вполне по силам ее реализовать, но дьявол, как обычно, кроется в деталях. Недостаточно соединить площадки и развернуть ПО: нужно добиться высокой скорости передачи данных и небольших задержек, отладить сетевое взаимодействие. У нас только НИОКР заняли около девяти месяцев. Затем мы разрабатывали типовые конфигурации, технологические и производственные карты, программы испытаний и шаблоны документов.

Проектированием и внедрением ЦОД, ПАК и метрокластеров мы занимаемся около двадцати лет. Последние пять лет развиваем типовые ПАК. Над собственным метрокластером работали около двух лет и вывели его на рынок примерно полгода назад. Если требования заказчика понятны, сроки производства и внедрения могут составлять считанные недели. При этом основное время занимает закупка компонентов. По факту поставки ПАК внедрение может производиться как самим заказчиком, так и интегратором. Мы со своей стороны предоставляем консультации, проводим шефмонтаж, после чего принимаем на гарантию. Мы не утверждаем, что DEPO Computers — единственная компания, способная построить метрокластер. Но у нас есть собственная отработанная технология, проверенная аппаратная конфигурация и накопленный опыт. Заказчику не придется проходить весь путь для поиска оптимального решения, который когда-то прошли мы.

Пользуясь случаем, хочу пригласить читателей TAdviser на наш вебинар 29 октября «МетроПАК DEPO — новое слово в эволюции катастрофоустойчивости».
Зарегистрироваться.