новости
статьи
.технологии

распределенные центры обработки данных

Резервный вычислительный центр (РВЦ) — это одно из решений, направленных на обеспечение доступности данных и информационных служб в целом. РВЦ гарантирует непрерывность работы IT-инфраструктуры в случае выхода из строя основного вычислительного центра, когда время его восстановления превышает допустимое время недоступности информационной системы.

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

Все резервные центры организованы похожим образом — выбирается площадка, расположенная на безопасном расстоянии от основного центра, и на ней устанавливается оборудование, необходимое для работы основных приложений и IT-сервисов. Основной и резервный центры соединяются каналом связи для передачи данных приложений.

Схема миграции данных представляет собой репликацию данных приложений из основного центра в резервный или выполнение резервного копирования из основного центра в резервный. Такие схемы выбирались из-за ограничения пропускной способности каналов связи (в том числе и по причине высокой стоимости последних).

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

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

Концепция резервных центров была разработана в конце 80-х — начале 90-х годов прошлого века и с тех пор значительно не изменялась. Но если строить IT-инфраструктуру предприятия сейчас, нужно ли следовать концепции, разработанной более пятнадцати лет назад и базирующейся на тогдашнем уровне технологий?

В предлагаемой статье автор представляет свой взгляд на то, какими должны быть современные решения по обеспечению отказоустойчивости IT- инфраструктуры, а также дает прогноз достижений в этой области на ближайшие годы.

резервные центры как устаревший метод

Современные резервные центры, как метод обеспечения непрерывности производственных и других процессов, не являются продуктом IT. Они известны довольно давно, еще со времени холодной войны, и являются в определенной степени копией армейских центров управления операциями на случай войны "горячей" (к счастью, подобные сооружения так и не пригодились военным). Армейские резервные центры необходимо было поддерживать в постоянной готовности, оборудование должно было полностью соответствовать основным центрам. Узнать наверняка, насколько они были готовы к выполнению своих задач, можно было бы только в случае глобальной войны, вполне возможно, что заявленные функции не выполнялись полностью.

Резервные центры IT-cистем включаются в работу в случае менее серьезных происшествий, но вопросы готовности и соответствия заявленным функциям также имеют ключевое значение.

При оценке применимости РЦ, кроме прочего, следует учитывать конкретные политические и экономические особенности страны. Резервные центры IT- систем — дорогие конструкции, и применялись они изначально транснациональными корпорациями, которые ведут свой бизнес на нескольких континентах. В случае возникновения проблем в Европе такие компании могут руководить своими операциями из Азии или Америки. В Соединенных Штатах Америки управление компанией может быть перенесено с западного побережья на восточное или наоборот.

В России же стране государственное управление традиционно централизовано, и в последние годы наблюдается усиление этой централизации. Трудно представить, каким образом можно было бы перенести управление компанией в Санкт-Петербург в случае какой-либо катастрофы в Москве. Нам пришлось бы решать более серьезные задачи, чем восстановление IT-структур. Сейчас Москва — не только столица, это еще и крупнейший транспортный узел, и узел связи. В 1812 году М. И. Кутузов, оставляя город Наполеону, мог говорить: "С потерей Москвы не потеряна Россия", — поскольку в ту пору она (Москва) была провинциальным городом. Но спустя более столетия, во время другой Отечественной войны, в 1941 году Москву упорно защищали. И это было необходимо не только потому, что столица государства — символ, и необходимость отстоять этот город от вражеской оккупации имела огромное политическое и даже психологическое значение. Дело в том еще, что при потере Москвы как транспортного узла, фронт разваливался на две не связанные между собой части, а это грозило катастрофическими последствиями. С тех пор значение Москвы как крупнейшего узла транспорта, связи и управления (сравните: в Москве четыре аэропорта, в Санкт-Петербурге — один) только возросло.



Рис. 1. Битва за Москву. Сентябрь — декабрь 1941

Подобная же централизация управления, транспорта и связи наблюдается и в российских регионах. Ни один город областного, республиканского или краевого подчинения не сравнится по возможностям со своим административным центром. В таких условиях резервный центр, построенный в другом городе, не гарантирует непрерывность процессов, так как в чрезвычайной ситуации, прежде чем восстанавливать IT-систему, придется решать проблемы восстановления страны или региона. Эффективнее и дешевле разместить площадки в разных районах города и подключить их к разным подстанциям, городским узлам связи.

Кроме того, при размещении площадок внутри города потребуются оптоволоконные коммуникации протяженностью максимум 35-40 км, поэтому гораздо эффективнее было бы использовать сами площадки, чем создавать на одной из них резервный центр.

Со времени появления идеи схемы резервных центров с технологиями связи произошли серьезные метаморфозы, которые существенно расширили возможности связи. (Табл. 1). Теперь каналы связи намного более производительны, а если нет необходимости разносить площадки на значительные расстояния, когда задержка распространения света в оптоволоконном кабеле (~ 5 с/км) оказывает влияние на время выполнения операции ввода-вывода (~ 5-10 мс), то разумно ли организовывать связь площадок по схеме резервного центра.

Таблица 1. Изменение технологий связи.


Технология1990-е годы2006 год
СетьOC-3 (155 Mbit)OC-12 (622 Mbit)10 Gigabit Ethernet
Ввод-выводSCSI, ESCON (200 Mbit)4 Gigabit Fibre Channel10 Gigabit Fibre Channel
Линии связи1 пара оптоволокна — 1 линия связиDWDM — до 32 линий связи в одной паре оптоволокнаCWDM — 8 линий связи в одной паре оптоволокна


Эксплуатация резервного центра создает дополнительные проблемы, которые нужно решать. Так, еще на стадии его построения необходимо обеспечивать подходящее резервирование инфраструктуры для работы приложений. На каждый установленный в основном центре сервер надо отвечать сервером, который сможет обеспечить работу определенного приложения, в резервном центре. Каждому гигабайту полезной емкости в основном центре должен соответствовать гигабайт в резервном. Можно устанавливать в РЦ менее производительные и более дешевые дисковые массивы, но все необходимые ресурсы для запуска приложений должны присутствовать. Все это оборудование не используется и стоит в резерве.

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

Сопровождение резервного центра предполагает решение следующих задач.

1. Обеспечение резервирования новых приложений — установка нового оборудования и программного обеспечения в резервном центре.

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

3. Поддержание одинаковых версий программного обеспечения в основном и резервном центре — после изменения версии приложения или СУБД либо операционной системы следует провести изменения и в резервном центре также. Обновление версий происходит относительно редко, а установка программных коррекций (patches) и изменение конфигурации производятся часто; если не произвести изменение в резервном центре, то приложение, возможно, не сможет быть там запущено.

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

5. Обязательное тестирование всех изменений, чтобы быть уверенным в работоспособности резервирования. Тестирование — это перевод приложений в резервный центр и проверка его работоспособности — процедура трудоемкая и, может быть, даже опасная, в случае сбоя во время этой операции восстановление штатного режима может занять много времени.

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

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

современные технологии изменяют схемы резервирования

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

Площадки соединяются производительными каналами связи с пропускной способностью в десятки гигабит (см. табл. 1). Если площадки находятся в одном городе, и расстояние между ними не превышает 50 км, то из нескольких площадок можно создать единый вычислительный центр, рассматривая их просто как разные комнаты в одном здании.

На рис. 2 представлена примерная схема распределенного вычислительного центра. Локальные сети (LAN) и сети хранения данных (SAN) всех площадок связаны между собой. Сегменты локальных сетей, к которым подключены серверы, объединены в домены второго уровня модели OSI, и это позволяет прозрачно для приложений перемещать IP-адреса серверов с площадки на площадку. Благодаря объединению SAN всех площадок, серверы могут использовать ресурсы хранения данных на любой из них.



Рис. 2. Распределенный вычислительный центр.

Площадки объединены при помощи технологии DWDM. Для надежности соединения используется схема "кольцо" (DWDM Ring). Оборудование DWDM обеспечивает защиту каналов связи на физическом уровне — импульсы света могут передаваться между двумя точками на кольце по двум разным маршрутам (условно назовем их "короткий", когда расстояние между точками на кольце минимально, и "длинный"). В случае разрыва кольца между двумя площадками "короткий" маршрут становится недоступным, но световые импульсы продолжают передаваться по "длинному" маршруту и связь между площадками не теряется.

При правильной конфигурации оборудования локальной сети и сети передачи данных разрыв кольца и изменение маршрута передачи световых импульсов между площадками не приводят к потере информации и происходят прозрачно для оборудования SAN и LAN.

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

Локальные схемы резервирования предусматривают гораздо больше вариантов, чем схема резервного центра, такие как:

- параллельные кластеры для самых критичных приложений (например, Oracle Real Application Cluster для экземпляров СУБД с наивысшими требованиями к готовности);

- кластеры приложений для программного обеспечения, имеющего собственные механизмы резервирования. В качестве примера назовем кластеры таких приложений, как монитор транзакций Tuxedo, сервер приложений Websphere AS, сервис передачи сообщений Websphere MQ;

- кластеры высокой готовности (HA-cluster) для критичных приложений (сейчас многие производители серверов и поставщики программных систем предлагают кластерные решения для популярных приложений). Для приложений собственной разработки можно разработать самому или заказать специализированный модуль для выбранного варианта кластера;

- "теплый" или "холодный" резерв для остальных систем.

Очевидные преимущества предложенного подхода — гибкость и упрощение процедуры резервирования. Снижается время готовности приложений, поскольку перевод приложения между узлами кластера или переключение на другой узел Oracle RAC занимает гораздо меньше времени, чем переход на приложения резервного центра. Не только упрощается процедура перехода на резервный узел, но и уменьшается объем документации, которую нужно поддерживать в актуальном состоянии.

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

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

Объединение площадок при помощи DWDM — это достаточно дорогое решение, строить распределенные центры обработки данных таким образом могут только большие компании с соответствующими IT-бюджетами. Использование более дешевого оборудования CWDM позволяет организовать распределенные центры и менее крупным компаниям.

На рис. 3 представлен вариант модернизации соединения трех площадок с использованием CWDM. Между каждой парой площадок при помощи двух пар оптоволокна и мультиплексоров/демультиплексоров CWDM проводятся 16 каналов связи. Это могут быть каналы Gigabit Ethernet и 2 Gigabit Fibre Channel. Такого количества каналов должно хватить для создания распределенного вычислительного центра в компании среднего размера.



Рис. 3. Объединение трех площадок при помощи оборудования CWDM.

Для соединения площадок потребуется 12 мультиплексоров/демультиплексоров CWDM и 96 приемопередатчиков CWDM с 8-ю разными длинами волны. Но все равно цена решения получается значительно ниже, чем в случае DWDM. Соединение четырех площадок указанным образом будет выглядеть уже сложно, а вот для соединения двух площадок CWDM — почти идеальный вариант (см. рис. 4).



Рис. 4. Соединение двух площадок при помощи оборудования CWDM.

Следует отметить, что при использовании CWDM отсутствует защита от обрыва соединения на физическом уровне. Резервирование линий связи в этом случае производится на уровне оборудования локальной сети или сети хранения данных. Если разрыв соединения произойдет, то будет потеряно несколько фреймов данных, которые передавались в момент аварии. Однако потери данных не случится, если нарушатся не все связи между площадками. Контроль целостности данных на уровне протоколов Fibre Channel (или FCP) и TCP/IP приведет к тому, что пропавшие команды и данные будут повторены.

заглянуть в будущее

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

По мнению автора статьи, значительное влияние на концепции резервирования окажут следующие новинки:

- появление Infiniband для объединения серверов;

- 4 Gigabit Fibre Channel на серверах и устройствах хранения данных (и это уже реальность);

- 8 Gigabit Fibre Channel для соединения коммутаторов — построения ISL;

- приемопередатчики 4 Gigabit для работы на больших расстояниях — ELWL и CWDM;

- приемопередатчики 10 Gigabit для работы на больших расстояниях.

Благодаря Infiniband можно будет объединять серверы, расположенные на разных площадках, в сильносвязанные конфигурации: не только параллельные кластеры, но и комплексы, работающие под управлением одной операционной системы, смогут быть разнесены на значительные расстояния.

Остальные усовершенствования позволят увеличить пропускную способность каналов, соединяющих площадки распределенного вычислительного центра. Площадки распределенного вычислительного центра, удаленные на 45-50 км (длина по оптоволоконному кабелю) можно будет соединить каналами связи с пропускной способностью десятки и сотни гигабит. Использовать полученную мощь для репликации или резервного копирования будет совершенно неразумно.



Дениc Голубев, руководитель экспертной группы отдела вычислительных комплексов, Jet Infosystems
обсудить статью
© сетевые решения
.
.