[an error occurred while processing this directive]

16+

[an error occurred while processing this directive]

Обозрение подготовлено

версия для печати
Катастрофоустойчивый ЦОД должен быть устойчив к выходу из строя любого компонента

Катастрофоустойчивый ЦОД должен быть устойчив к выходу из строя любого компонента

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

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

Термин, вроде бы, понятен интуитивно: под катастрофоустойчивым ЦОД подразумевается вычислительный центр, который не прекратит функционировать ни при каких условиях. Хоть бомбу на него сбрось. На самом деле инженеры толкуют это понятие более узко — устойчивость к выходу из строя любого компонента системы. «При этом необходимо обеспечить резервирование всех значимых элементов и сделать так, чтобы в случае отказа главного устройства моментально осуществлялся переход исполнения его функций на запасное, — разъясняет Ярослав Городецкий, вице-президент, начальник управления технической поддержки продаж компании CPM. — Это предполагает установку и настройку ряда специальных приспособлений». Грубо говоря, под резервированием здесь понимается дублирования самого элемента или создание другого устройства, способного выполнять функции первого.

Как резервировать

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

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

Применять подобные схемы оказывается целесообразным, когда речь идет о построении достаточно совершенной системы с точки зрения стрессоустойчивости, но при этом существуют ограничения по площади для резервных копий или по финансированию проекта.
Чтобы не загружать помещение ЦОД новой вычислительной техникой и средствами ее связи и несколько сократить расходы, необходимо интегрировать устройства с высокой степенью «наработки на отказ», т.е. среднего времени выхода прибора из строя. Например, уже указанный распределитель Juniper, начиная с позиции M10, обладает хорошими характеристиками времени безотказной деятельности, потому что для соединения сигналов в ней встроена железная шина. Получается, что вместо маршрутизатора на каждый сервер устанавливается одно устройство на всех.

И, наконец, самый серьезный уровень «протекционизма» — использование метода географического резервирования вычислительных мощностей. На деле, это означает создание еще одного самодостаточного ЦОД в другом здании. Безусловно, между параллельно функционирующими системами происходит синхроницаия данных.

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

Этапы построения ЦОД

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

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

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

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

Сергей Ильин

Техноблог | Форумы | ТВ | Архив
Toolbar | КПК-версия | Подписка на новости  | RSS