Системный интегратор ProNET наработал значительный опыт в построении различных катастрофоустойчивых решений для украинских заказчиков. По мнению специалистов компании Ярослава Басия и Сергея Вакуленко, интерес к таким решениям на украинском рынке быстро растет. Но от теории к практике предприятия переходят, как правило, только когда сталкиваются с проблемой утраты данных и недоступности ИТ-сервисов.

PCWeek/UE: В каких индустриях более всего ощущается спрос на катастрофоустойчивые решения?

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

PCWeek/UE: За последние годы изменился спрос на подобные решения?

Сергей Вакуленко: Если раньше большинство компаний надеялось на «авось», то теперь они начинают понимать – такой метод не работает. Особенно, когда катастрофа уже произошла и данные надо восстановить любой ценой. Исследования свидетельствуют, что 70% организаций, которые потеряли критически важные для бизнеса данные и не восстановили их в течение десяти дней, либо вынуждены уйти с рынка, либо несут тяжелые финансовые потери.

Я. Б.: После техногенных катастроф прошлого года в Японии и других странах повысились общие требования к энергогенерирующим и энергораспределящим компаниям. Поэтому в энергетическом секторе растет интерес к различным отказоустойчивым и катастрофоустойчивым системам. Тем более, что сейчас намного больше развиты технологии построения таких систем.

PCWeek/UE: Обычно заказчики обращаются к вам уже после того, как столкнулись с проблемой потери данных, или когда желают предотвратить подобные ЧС?

Я. Б.: И первое, и второе. Некоторые компании уже успели пострадать от различных сбоев и аварий, которые привели к потере данных. Осмотрительные ИТ-менеджеры предпочитают учиться на чужих ошибках.

PCWeek/UE: Что является наиболее распространенной причиной аварий в ЦОДах?

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

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

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

PCWeek/UE: Каких рекомендаций должна придерживаться компания при выборе расстояния между основным и резервным ЦОДами?

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

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

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

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

PCWeek/UE: Всегда ли используются только две технические площадки?

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

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

PCWeek/UE: Какие еще особенности построения катастрофоустойчивых систем вы можете отметить?

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

Для расчета таких систем применяют два параметра – время восстановления сервисов на первой площадке и допустимое время потери данных. 100% восстановления данных обеспечивают только очень дорогие решения. Как правило, такие системы заказывают лишь крупные банки.

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

PCWeek/UE: Резервный ЦОД, как и основной, также обычно обеспечивают системой бесперебойного питания на базе ИБП и ДГУ?

Я. Б.: Да, но подобную систему необходимо регулярно тестировать. Не исключено, что при пропадании питания в основной электросети и переходе на источник бесперебойного питания дизель-генератор просто не запустится. Обычно таким процедурам уделяют недостаточно внимания даже в основном ЦОДе, что уж говорить про резервный…

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

PCWeek/UE: В последние годы в Украине появилось несколько коммерческих ЦОДов достаточно высокого уровня, которые сдают в аренду площадь своих центров. Насколько целесообразно для крупного и среднего бизнеса размещать резервные ЦОДы на арендованных площадках вместо того, чтобы строить свои собственные?

Я. Б.: Далеко не все компании морально готовы отдать оборудование с корпоративными данными в ЦОД, куда теоретически могут иметь доступ чужие сотрудники. И не всегда провайдер в состоянии гарантировать конфиденциальность хранения этой информации. Представьте ситуацию, когда приходит представитель правоохранительных органов и просит предоставить ему доступ к определенному оборудованию...

PCWeek/UE: Но ведь некоторые украинские компании вообще переносят свои ИТ-сервисы в облако, причем нередко — к заокеанским провайдерам?

Я. Б.: Да, такая тенденция все более заметна в последнее время. Однако этот вариант не гарантирует полной бесперебойности. Например, в прошлом году в одном из ЦОДов компании Amazon произошла серьезная авария с сетевым оборудованием и в течение нескольких дней многие из предоставляемых компанией ИТ-сервисов были недоступны. Еще один минус облачных решений – использование Интернета в качестве канала связи. И если у вас отсутствует доступ к Интернету, то не будет и доступа к приложениям.

PCWeek/UE: Сегодня многие компании строят свою ИТ-инфраструктуру на базе технологий виртуализации. Как эволюционировал процесс построения катастрофоустойчивых решений после перехода на виртуальные машины?

С.В.: В целом применение виртуализации заметно упростило задачу построения отказоустойчивых решений. Например, компания VMware, продукты которой чаще всего применяются для создания виртуальной ИТ-инфраструктуры, специально для таких задач выпустила приложение VMware vCenter Site Recovery Manager. Это ПО в случае сигнала об опасности автоматически переносит все защищаемые ИТ-сервисы на резервную площадку.

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