| Рубрикатор |  |
 |
| Статьи |  |
ИКС № 11 2011 | |
|
| Александр ГУЛЯЕВ | 09 ноября 2011 |
Механизмы резервирования ЦОДов: разделяй и… спи спокойно
Остановка дата-центра даже на несколько часов означает для компании серьезные убытки? Тогда ничего не остается, как принять все меры для снижения вероятности такого события. Эффективным решением станет создание резервного ЦОДа на площадке в существенном удалении от основной.
Только такое географическое резервирование центра обработки данных может дать более или менее твердую уверенность в том, что в результате очередной техногенной катастрофы или банальной ошибки персонала ЦОДа системы, обслуживающие бизнес компании, внезапно не остановятся.
Итак, решение о необходимости создания второго ЦОДа с целью резервирования критичных бизнес-систем принято. Сразу же появляется ряд специфических требований к сетевой инфраструктуре компании и нового ЦОДа. В частности, нужно построить отказо-устойчивую инфраструктуру сети, которая позволит обеспечить работу приложений и кластеров, разнесенных на разные площадки, а также автоматически отрабатывать возможные нестандартные ситуации, вплоть до полной потери одной из площадок. При этом с точки зрения пользователей или клиентов перерыв в предоставлении сервиса должен быть минимальным и практически незаметным, а процедура его восстановления до исходного состояния – по возможности автоматической.
С точки зрения сетевого архитектора требуется решить как минимум две задачи:
-
организовать бесперебойный доступ пользователя к приложениям, размещенным на разных площадках, как в нормальном, так и в аварийном режиме работы одного из ЦОДов;
-
гарантировать бесперебойное функционирование приложений, разнесенных на разные площадки.
Отказоустойчивость для клиентов
Когда площадка одна, способ предоставления сервиса очевиден: клиентское приложение обращается к конкретному серверу. Если серверов несколько и ПО системы не предлагает собственных средств обеспечения отказоустойчивости или распределения нагрузки, на помощь приходят балансировщики нагрузки. В настоящее время они являются неотъемлемым компонентом любого ЦОДа. Но когда площадок две и на каждой из них есть собственный набор серверов, а размещаться они могут даже на разных континентах, средства локальной балансировки уже не всегда подходят, особенно когда площадки расположены на большом расстоянии друг от друга и нельзя организовать между ними каналы Ethernet. Ведь локальный балансировщик – это часть оборудования одной из площадок, и в случае аварии он также становится недоступным и не может перенаправить входящий запрос на другую площадку.
 |
 |
Благодаря такой двухуровневой схеме, а также постоянной связи между локальными и глобальными балансировщиками достигается и масштабируемость решения, и его высокая отказоустойчивость. Глобальных балансировщиков, как и ЦОДов, может быть несколько, что дает возможность построения различных конфигураций ИТ-инфраструктуры.
Кроме решения задачи резервирования, применение балансировщиков позволяет минимизировать время отклика приложений, экономить пропускную способность каналов связи, обеспечить равномерную утилизацию ресурсов в ЦОДах за счет мониторинга загрузки серверов и динамического распределения запросов.
Отказоустойчивость для приложений
С сетевыми решениями, поддерживающими функционирование разнесенных в разные ЦОДы приложений, тоже не все просто. В большинстве случаев требуется единый Ethernet-сегмент, объединяющий Ethernet-сети, расположенные на двух и более относительно близких друг к другу площадках. Это обусловлено особенностью работы многих вычислительных систем, в частности – кластеров. Самый простой способ решения этой задачи – создать транковые Ethernet-соединения между коммутаторами ядра ЦОДов и направить в них трафик нужных нам подсетей. Такая схема применяется очень часто, но ее практическая реализация всегда вызывала ряд вопросов. Начнем с того, что подобная конструкция усложняет логическую структуру сети и сдерживает возможности ее масштабирования. В результате увеличиваются размеры сетевых сегментов и появляется большой объем широковещательного трафика, который занимает часть полосы пропускания в каналах и мешает полезному трафику.
Вторая задача продиктована необходимостью резервировать соединения и сетевое оборудование в ЦОДах. Она требует применения специальных протоколов для предотвращения образующихся в таком случае петель. Наилучшим вариантом преодоления этих трудностей является кластеризация сетевых коммутаторов уровня ядра/агрегации. Подобные решения предлагают сейчас несколько производителей, например, Cisco – технологии VSS и vPC в различных линейках оборудования, Brocade – технологию MCT, Juniper – Virtual Chassis и т.д.
Организация резервирования требует наличия как минимум двух Ethernet-каналов, проложенных по различным трассам, что не всегда возможно, так как для этого необходимо иметь собственное оптическое волокно либо соответствующую услугу, предоставляемую оператором. Через дешевый IP-канал такое соединение работать не будет.
Но выход все же есть. На выделенных IP-каналах можно применить достаточно надежные и хорошо себя зарекомендовавшие технологии MPLS L2VPN. Современные маршрутизаторы отлично справляются с созданием высокоскоростных MPLS-туннелей, а само решение не ограничено какой-либо одной топологией или определенным числом ЦОДов, хорошо масштабируется и обладает надежностью операторского класса. Кроме решения на базе MPLS стоит упомянуть фирменную технологию Cisco OTV (Overlay Transport Virtualization), реализованную в коммутаторах серии Nexus, которая позволяет использовать между ЦОДами каналы IP для передачи Ethernet-трафика.
Безопасность – еще один насущный вопрос, о котором не стоит забывать в современных условиях. Для шифрования трафика, передаваемого через Ethernet-каналы между ЦОДами, можно применить решение на базе стандарта MAC Security. Это позволит обезопасить сетевой трафик от возможных атак или перехвата злоумышленником, не прибегать к дополнительным устройствам шифрования и сэкономить средства при внедрении.
Построив резервный ЦОД, следует помнить о необходимости синхронизации данных приложений и организации резервного копирования. И снова на помощь приходят сетевые технологии. Работающие поверх TCP/IP протоколы, используемые для синхронизации и резервного копирования, хорошо поддаются оптимизации. Сетевая индустрия предлагает специализированные устройства оптимизации трафика для ЦОДов. Их отличительные особенности – возможность эффективно работать на каналах с высокой пропускной способностью, а также большой объем встроенного хранилища данных. В результате применения таких решений становится возможным сократить время резервного копирования, например, с десяти часов до одного часа, ведь эти устройства задействуют весь арсенал доступных средств оптимизации: оптимизацию TCP и других протоколов, дедупликацию данных, кэширование и т.д.
Очевидно, что системы резервного копирования могут взаимодействовать с серверами по каналам Fibre Channel и нагружать только инфраструктуру СХД. С другой стороны, отдельные оптические каналы для Fibre Channel также обойдутся недешево. В случае, когда для резервного копирования или сети хранения данных требуется транспорт Fibre Channel, а возможность организации каналов через оптическую линию связи отсутствует, как правило, применяются решения на базе протокола FCIP (Fibre Channel по IP).
Но по-настоящему революционным решением для объединения ЦОДов представляется универсальный конвергентный транспорт, в частности, протокол FCoE (Fibre Chanel over Ethernet), позволяющий использовать единый Ethernet-транспорт для передачи сетевого трафика и трафика Fibre Channel. До недавнего времени дистанция для конвергентного соединения не могла превышать 300 м, что ограничивало его применение одним ЦОДом. Однако уже сегодня производителями заявлена поддержка multihop FCoE и возможность увеличения дальности конвергентного соединения до 10 км, что позволяет говорить о применимости этой технологии для объединения ЦОДов.
Через призму виртуализации
Выше мы рассмотрели типичные стандартные сценарии, которые остаются актуальными в большинстве случаев при резервировании ЦОДов. Теперь посмотрим на резервирование ЦОДов через призму виртуализации, ставящей перед сетью новые нетривиальные задачи.
Одна из серьезных сетевых проблем в эпоху виртуализации – необходимость обеспечения мобильности виртуальных машин. Настройки сетевых коммутаторов всем хороши, за исключением того, что они, как правило, статичны. Если вы переключаете сервер на другой порт коммутатора, администратор должен добавлять команды на одном или нескольких сетевых устройствах, что значительно повышает риск ошибок и соответственно нарушения работоспособности сети. Да и сами трудозатраты на осуществление нужных настроек влияют на операционные издержки компании.
Виртуализация с ее возможностями адаптироваться под задачи клиентов или растущую нагрузку требует от сети готовности приспосабливаться к динамично меняющемуся ландшафту ЦОДа. Ведь по-настоящему эффективная виртуальная инфраструктура не должна иметь архитектурных ограничений в части развития или привязки тех или иных серверов к строго определенным сетевым сегментам – в идеале сеть должна автоматически принимать нужную конфигурацию для поддержки работы сервисов, а не наоборот.
По сути, большинство производителей оборудования смирились с тем, что стандартными способами выполнить эти требования не получится, и стали предлагать собственные решения, зачастую несовместимые друг с другом. Но прослеживается одна общая тенденция: сеть все плотнее интегрируется с вычислительной инфраструктурой и средствами виртуализации. Причем интеграция идет с двух сторон: как путем организации взаимодействия между ПО сетевого управления и системами управления виртуальными ресурсами, так и за счет интеграции сетевого оборудования с серверными компонентами и драйверами. Современные сетевые решения для ЦОДов уже сейчас позволяют поддерживать миграцию виртуальных машин в пределах ЦОДа и снять нагрузку по обработке сетевого трафика с процессоров виртуализованных серверов, перенеся ее на сетевые коммутаторы. Это повышает отдачу от вычислительных ресурсов, дает возможность более эффективно внедрять сетевые политики и обеспечивать безопасность.
Несмотря на очевидное усложнение логической структуры сети, сопровождающее организацию географического резервирования ЦОДов, решения, которые позволяют эффективно построить такую архитектуру, существуют и продолжают совершенствоваться. Дополнительный импульс развитию таких решений сообщает растущая популярность облачных технологий, в особенности – публичных облаков, для которых потеря одного дата-центра наиболее критична, так как чревата простоем бизнеса не одной, а сотен или даже тысяч компаний. икс
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3