На магистралях интерЦОД

По данным Price Waterhouse Coopers, по всему миру из-за простоя сетевых инфраструктур компании теряют ежегодно 1,6 трлн долларов, то есть каждую минуту потери составляют примерно 3 млн долларов. А исследование Forrester Research, которым было охвачено 250 предприятий из списка Fortune 1000, выявило, что минутное отсутствие доступа к приложениям планирования корпоративных ресурсов (ERP) обходится в 13 тыс. долларов. Не случайно все больше компаний, у которых данные хранятся только в одном ЦОД, всерьез задумываются о подстраховке путем создания их удаленного «образа».

Стратегия обеспечения непрерывности бизнеса в части гарантии работоспособности ИТ-приложений состоит по сути всего из двух мер: во-первых, создание резервной копии данных, а во-вторых, перенаправление запросов пользователя к этой копии в случае проблем. Формирование резервной копии данных может осуществляться в синхронном или асинхронном режиме. В первом случае каждое изменение тут же фиксируется в соответствующей копии, тогда как в последнем резервирование осуществляется через определенные промежутки времени, продолжительность которых зависит как от специфики приложений, так и от требований бизнеса.

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

Типовой ЦОД можно разделить на несколько уровней. Интерфейс с пользователем (front-end), как правило, обеспечивают Web-серверы, предоставляющие запрашиваемую им информацию. Далее следует уровень приложений, реализующих основную бизнес-логику, в соответствии с которой серверы выбирают и обрабатывают информацию. И наконец, «фундаментом» всей структуры служат системы хранения данных (СХД). В случае территориально распределенных ЦОД сетевое взаимодействие может осуществляться на каждом из этих трех уровней (см. Рисунок 1).

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

По мнению Романа Козлова, руководителя направления СХД компании Netwell, традиционный инструментарий резервирования, работающий на уровне файловой системы, несколько устарел. «Функционал современных СХД обеспечивает возможность делать консистентные резервные копии практически мгновенно, время тратится только на подготовку приложения к резервному копированию. При этом обеспечивается согласованность резервных копий данных приложений, в том числе СУБД», — говорит он.

СКОРОСТЬ, ЗАДЕРЖКА, РАССТОЯНИЕ

Очевидно, что необходимая пропускная способность каналов связи между ЦОД определяется тем, какой объем данных требуется передавать. Исследование, проведенное компанией Forrester, показало, что 65% крупных организаций нуждаются в резервном хранении более 50 Тбайт информации. Если предположить, что каждый день изменяется примерно 10% этой информации, то для передачи измененных данных понадобятся каналы 2,5 Гбит/с. Если канал, связывающий систему хранения и ЦОД, способен передавать, скажем, не более 10 Мбит в секунду, то и резервирование можно будет обеспечить только для хранилища емкостью 2 Тбайта. (В расчетах предполагалось, что данные передаются в рабочие часы, а загрузка каналов составляет 0,6.)

В современных ЦОД используются интерфейсы 10 Gigabit Ethernet и Fibre Channel на 4 Гбит/с, которые для современного высокоскоростного оборудования локальных сетей и SAN становятся стандартом де-факто. По оценке Дмитрия Дощаного, ведущего инженера департамента вычислительных систем компании «Крок», количество таких интерфейсов, используемых для связи между площадками, обычно составляет два – четыре, иногда больше, поэтому для передачи соответствующего объема трафика требуется проложить или арендовать многожильный оптический кабель или установить оборудование спектрального мультиплексирования (WDM). В случае использования такого оборудования, полагает он, можно быть уверенным, что сеть не станет узким местом распределенного ЦОД.

Помимо пропускной способности каналов связи, не менее важным фактором для обеспечения надежного взаимодействия территориально разнесенных ЦОД является продолжительность задержки при передаче трафика. Этот параметр наиболее критичен при синхронной репликации данных. В ходе такой репликации приложение на основной площадке будет ждать подтверждения записи от удаленного ЦОД, поэтому большая задержка существенно снижает быстродействие приложений. Упомянутое выше оборудование WDM вносит минимальную задержку (около нескольких микросекунд), поэтому величина задержки определяется в основном длиной оптического тракта. Обычно в расчетах полагают, что круговая задержка составляет примерно 1 мс на 100 км.

По словам Дмитрия Дощаного, производители СХД по умолчанию поддерживают решения синхронной репликации между ЦОД, когда они располагаются на удалении не более чем 200 км. При больших расстояниях задержка будет неприемлема для многих систем, поэтому потребуются консультации с вендором и интегратором. «Крок» предлагает своим заказчикам трехузловые решения. Их суть в том, что с одним ЦОД, расположенным на расстоянии нескольких десятков километров, осуществляется синхронная репликация, а с другим, удаленным на сотни и тысячи километров, — асинхронная.

Михаил Зайд, руководитель производственного сектора управления «Вычислительные системы» компании «АйТи», рассматривает требования к характеристикам «межцодовской» инфраструктуры на примере ПО Mirrorview компании ЕМС, служащего для проведения репликации между дисковыми массивами. Вариант этой системы для синхронной репликации (Mirrorview/S), когда каждый цикл записи основного массива передается на резервный массив с подтверждением записи, предусматривает создание побайтовой копии на основном и резервном массиве, чем обеспечивается нулевая точка восстановления (RPO). По данным специалиста «АйТи», теоретически Mirrorview/S не имеет ограничений по расстоянию, но практически это ограничение в виде максимальной допустимой задержки сигнала между транзакциями ввода/вывода накладывает само приложение. Обычная область применения этого продукта — географически распределенные системы с расстоянием между площадками менее 80 км, однако возможно и увеличение расстояния до 200 км. Исходя из требований низкой задержки и высокой пропускной способности, при использовании Mirrorview/S в качестве основного канала связи между СХД рекомендуется Fibre Channel.

Для минимизации нагрузки на каналы «межцодовского» взаимодействия очень важно грамотно спроектировать систему. Александр Скороходов, системный инженер-консультант по технологиям ЦОД компании Cisco, указывает, что серьезные проблемы могут возникнуть в ситуации, когда активный экземпляр приложения в кластерной системе (или виртуальная машина, ВМ) «переехал» в ЦОД №2, а активный экземпляр СХД остался в ЦОД №1. В этом случае приложение будет записывать данные на удаленную СХД, которая станет выполнять синхронное копирование на диски, расположенные на той же площадке (ЦОД №2), что и приложение. Тогда задержка и требования к пропускной способности удваиваются. Вывод очевиден: желательно, чтобы приложение (или ВМ) всегда работало с локальной СХД.

Приведенные выше рекомендации относительно пропускной способности и задержки при «межцодовском» взаимодействии, безусловно, носят общий характер. В конкретном случае все определяется спецификой приложений, аппаратной платформой, сетевыми устройствами, моделью дискового массива, количеством дисков и т. д. Гигабитные каналы нужны далеко не всегда. Например, по словам Дмитрия Дощаного, если удаленный ЦОД используется только для асинхронного резервирования данных нескольких СУБД, то вполне достаточно и «тонкого» арендованного IP-канала. Как утверждает Михаил Зайд, при использовании решения Mirrorview/A для асинхронной репликации данных, расстояние между тиражируемыми массивами может составлять от десятков до тысяч километров. Mirrorview/A не накладывает жестких ограничений на пропускную способность канала связи и уровень задержек, а минимальное требование к пропускной способности составляет всего 128 Кбит/с.

«РАСТЯГИВАЯ» SAN…

Итак, для построения систем высокой доступности, как правило, требуется «растянуть» сеть хранения (SAN) от основного ЦОД до резервного. Это можно сделать по темной оптике или по спектральным каналам WDM (см. Рисунок 2). Как уже отмечалось, максимальное удаление определяется допустимым временем задержки, которая, в свою очередь, зависит от числа буферов, поддерживаемых на портах коммутаторов FC. Типичная дальность такого «растягивания» составляет десятки километров, но можно достичь и упомянутых представителями интеграторов 200 км.

Ускорить работу систем FC в режиме синхронной репликации можно при помощи специальных алгоритмов. В качестве примера такого механизма Александр Скороходов приводит функцию FC Writе Acceleration, поддерживаемую на коммутаторах Cisco MDS. При ее включении хост получает подтверждение записи не от удаленной системы (как в обычном решении), а от локального коммутатора. Общее подтверждение с другого конца приходит по завершении транзакции. Кроме того, при построении распределенной сети FC важно обеспечить логическую изоляцию фабрик SAN, сохранив их связность, так как при слиянии или разделении фабрик требуется определенное время на перестройку сети SAN, что снижает степень ее доступности. В коммутаторах MDS подобная изоляция обеспечивается при помощи функции Inter-VSAN Routing (IVR).

Решения WDM позволяют несколько оптимизировать расходы на высокоскоростную оптическую сеть благодаря мультиплексированию множества спектральных каналов, «несущих» различные сервисы. Так, посредством решений Adva FSP3000, которые эксперты компании Netwell рекомендуют для организации соединения WDM между ЦОД, по одной паре оптических волокон можно передавать до 80 различных сервисов, в том числе Fibre Channel (4, 8 и 10 Гбит/с), Ethernet (1 и 10 Гбит/с), Infiniband, SDH и ряд других. В своих проектах «Крок» традиционно ориентируется на решения WDM производства Cisco, Nortel и Ciena.

Очевидно, что даже с учетом преимуществ WDM далеко не все заказчики готовы строить высокоскоростную оптическую сеть (или покупать соответствующие сервисы) для «растягивания» сети SAN. На помощь приходит технология FCIP, позволяющая передавать трафик SAN по сети IP. Как говорит Дмитрий Дощаный, при помощи конвертеров FCIP можно построить маршрутизируемую сеть SAN между двумя ЦОД, даже если они соединены не слишком широким и протяженным каналом IP. Разумеется, в данном случае по сети SAN, связывающей ЦОД, следует передавать только трафик асинхронной репликации и резервного копирования.

Александр Скороходов в качестве примера приводит заказчиков, использующих технологию FCIP на каналах с пропускной способностью всего в десятки мегабит в секунду. Для ускорения работы сети SAN и снижения нагрузки на каналы связи он рекомендует задействовать технологии оптимизации трафика не только в самих коммутаторах FC, но и во внешних устройствах, например технологию WAAS (см. ниже).

Заговорив об FCIP, мы, по сути, уже перешли к обсуждению вопроса об обеспечении взаимодействия локальных сетей удаленных площадок.

… И ЛОКАЛЬНУЮ СЕТЬ

Традиционно для кластеров высокой доступности необходимо обеспечить связность между удаленными узлами на втором уровне (L2). Одной из основных причин этого требования является то, что при «переезде» сервер сохраняет свой IP-адрес. Хотя взаимодействие удаленных площадок по L3 — это, по многим соображениям, более правильное и безопасное решение, в большинстве случаев приходится «растягивать» домен L2. Какие варианты возможны в данном случае?

Один из них — использование обычных коммутаторов для локальных сетей, высокоскоростное (10GbE) соединение между которыми организуется по темной оптике или ее аналогу (спектральным каналам WDM). Однако классические протоколы локальных сетей не слишком подходят, поскольку требуется обеспечить нужную степень изоляции удаленных сетей, отказоустойчивость без привязки к медленному протоколу STP и пр. Подобные решения (в виде доработки стандартных протоколов или фирменных алгоритмов) имеются у всех ведущих производителей, включая компании Allied Telesis, Avaya (Nortel), Cisco, Enterasys, Extreme Networks, HP, Juniper Networks и др.

Например, компания HP для соединения двух удаленных ЦОД предлагает решение на базе своих коммутаторов H3C 12508 (см. Рисунок 3). В документах компании используется даже специальный термин, «пара ЦОД» (Data Center Pair, DCP), который служит для обозначения комплекса из двух площадок, удаленных на расстояние не более 100 км и соединенных высокоскоростными каналами L1 (например, WDM) с обеспечением связности L2 (без маршрутизации трафика). Подобный комплекс обеспечивает одновременную доступность ресурсов, расположенных на обеих площадках. В таком решении маршрутизаторы применяются только для предоставления доступа внешним клиентам.

Александр Кудряшов, архитектор сетевых решений HP, обращает внимание на то, что пары коммутаторов H3C 12508 в обоих ЦОД объединяются в кластеры Intelligent Resilient Framework (IRF) — эта технология обеспечивает функционирование пары как логически единого коммутатора. В частности, она позволяет поддерживать все каналы в активном состоянии, при этом не происходит зацикливания трафика на уровне L2. Традиционным решением по предупреждению зацикливания является протокол STP, однако он исключает возможность балансировки нагрузки по нескольким линиям и имеет очень большое время сходимости.

Специалисты компании Allied Telesis при разработке своих решений исходили из требований небольших ЦОД: для их взаимодействия в пределах города или района пары стековых коммутаторов предлагается связывать двумя агрегированными каналами по 10 Гбит/с (расстояние между смежными площадками не должно превышать 80 км). При этом рекомендуется применять топологию «кольцо», в котором для быстрого восстановления (50 мс) в случае обрыва или выхода из строя оборудования используется фирменная технология EPSR (см. Рисунок 4). Представители Allied Telesis отмечают, что технология агрегации каналов и протокол EPSR работают на уровне L2, что позволяет отказаться от использования маршрутизации в кольце между ЦОД и одновременно сохранить должную гибкость и надежность.

Другой вариант «растягивания» домена L2 — использование сервисов L2 VPN операторов связи, например с применением механизмов эмуляции проводов (pseudo-wire) в среде MPLS или технологии VPLS. Это стандартизованные и отлаженные решения, но, по словам Александра Скороходова, требующие сложной настройки. В частности, при подключении ЦОД к сети сервис-провайдера в нескольких точках (multi-homing) с использованием отдельных устройств — а это крайне желательно для повышения отказоустойчивости — требуется задействовать дополнительные механизмы чтобы обеспечить оптимальную загрузку соединений и исключить возникновение «петель коммутации».

Третий вариант — решения, разработанные специально для межсоединения сетей ЦОД на уровне L2. Примером такого решения является технология Overlay Transport Virtualization (OTV), реализованная в коммутаторах Cisco Nexus. Она работает поверх существующих сетей IP, используя все преимущества маршрутизации на уровне L3 (хорошую масштабируемость, высокую отказоустойчивость, подключение в нескольких точках, передачу трафика по множеству путей и пр.). Как утверждает Александр Скороходов, настроить OTV очень просто — для этого требуется выполнить всего шесть команд.

При построении сети передачи данных, охватывающей несколько ЦОД, эксперты рекомендуют использовать технологии оптимизации глобальной сети (WAN Optimization), позволяющие снизить требования к каналам связи. По словам Дмитрия Дощаного, такая оптимизация решает три основные проблемы: нехватку пропускной способности, «болтливость» и задержки транспортного протокола, а также неэффективность прикладного протокола. Соответствующие решения предлагают несколько компаний, но, пожалуй, наиболее известны системы WAAS от Cisco и Steelhead от Riverbed.

Характеризуя подобные оптимизаторы, Дмитрий Дощаный указывает, что недостаточность пропускной способности они компенсируют с помощью механизмов сжатия, дедупликации и кэширования; данные проходят через глобальную сеть только при первом обращении, затем они сохраняются на принимающей стороне, а при последующих обращениях передаются одни лишь ссылки на информацию. Эти продукты позволяют значительно уменьшить число служебных обращений в канале глобальной сети, а также оптимизировать работу протокола TCP для максимально эффективного использования канала.

ЧТО МЕНЯЕТ ВИРТУАЛИЗАЦИЯ?

Хотя в соответствии с логикой изложения данный раздел оказался в конце статьи, он является, пожалуй, наиболее важным. Дело в том, что именно виртуализация стала главным драйвером роста интереса к территориально распределенным ЦОД. Как отмечает Александр Скороходов, если раньше вопросы мобильности ИТ-систем были связаны исключительно с кластерами высокой доступности и касались небольшого числа наиболее критичных приложений, то теперь, благодаря средствам виртуализации (таким, как VMotion), мобильность приложений получила гораздо более широкое применение, в том числе для перераспределения ресурсов, управления ими, оптимизации энергопотребления и т. д.

Снижает ли виртуализация требования к характеристикам сетевой инфраструктуры? Пожалуй, наоборот, такие требования только возрастают. «Конечно, когда мы консолидируем на одном сервере десять серверов, их сетевое взаимодействие будет осуществляться через общую память, а не через сеть, — поясняет Дмитрий Дощаный, — но мы неоднократно наблюдали у заказчиков взрывной рост количества виртуальных машин после внедрения решения по виртуализации. Поэтому требуется тщательный подбор всех компонентов виртуальной фермы, а также сетевых устройств».

«Если, в случае выхода из строя одного сервера приложений с данными на локальных дисках, прекращается обслуживание только одного информационного сервиса, то при сбое сервера со средой виртуализации, канала связи между сервером и СХД или самой СХД прекращается, пусть и временно, обслуживание не одного, а возможно даже нескольких десятков сервисов», — отмечает Роман Козлов из Netwell.

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

Эксперты из компаний-интеграторов утверждают, что для осуществления «живой» (live) миграции ВМ между ЦОД (функция VMotion в терминах VMware, см. Рисунок 5) необходим широкий канал с низкой задержкой, иначе все преимущества этих технологий будут потеряны. В официальных документах VMware приводятся следующие требования к сетевой инфраструктуре, предъявляемые VMotion:

• минимальная пропускная способность — 622 Мбит/с, максимальная задержка — 5 мс;
• нахождение обоих серверов VMware ESX (источника и получателя) в одной подсети IP (в одном широковещательном домене);
• круглосуточное активное состояние СХД, включая устройство, с которого осуществляется загрузка, и доступность с обоих серверов VMware ESX.

Как видим, требования по скорости и задержке довольно высоки, а значит, ни о какой миграции ВМ в режиме live по каналам 10 Мбит/с и речи быть не может.

Особого рассмотрения требуют вопросы обеспечения информационной безопасности территориально распределенных ЦОД. Константин Пичугов, руководитель направления защиты виртуальных инфраструктур компании «Код Безопасности», обращает внимание на то, что в процессе живой миграции ВМ осуществляется передача по сети Ethernet фрагментов оперативной памяти и процессорных инструкций ВМ, причем по умолчанию данный трафик не шифруется. «Открытая передача оперативной памяти представляет собой угрозу даже в условиях локальной сети (оперативная память может содержать не только защищаемые данные, но и — в случае использования средств криптографии внутри ВМ — ключи шифрования), что уж говорить об открытой передаче по каналам за пределами контролируемой зоны», — подчеркивает он.

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

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

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.