В круглом столе принимают участие

Владимир АЛЕКСЕЕВ, системный архитектор, IBM в России и СНГ

Сергей АНДРОНОВ, директор Центра сетевых решений, «Инфосистемы Джет»

Алексей АРХИПОВ, заместитель генерального директора по ИТ, QIWI

Дмитрий ЖУКОВ, начальник технического отдела, ГВЦ ОАО «РЖД»

Антон ЗАХАРЧЕНКО, руководитель центра вычислительной инфраструктуры, «Энвижн Груп»

Андрей ИВАЩЕНКО, начальник управления вычислительных комплексов ДБИТ ВТБ24

Евгений КАЛАШНИКОВ, директор департамента комплексного пресейла, группа «Астерос»

Андрей КУВАЛДИН, архитектор, Сбербанк России

Александр ТРОШИН, технический директор, «Манго Телеком»

Артем ШАХВЕРДЯН, начальник управления системной экспертизы центральных банковских и интеграционных систем, Альфа-Банк

Леонид ШИШЛОВ, консультант, руководитель направления сервисов ЦОД, Schneider Electric

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

Владимир АЛЕКСЕЕВ

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

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

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

Помимо рисков при выборе решений и технологий для катастрофоустойчивых решений чрезвычайно важно определить параметры RPO (Recovery Point Objective) и RTO (Recovery Time Objective). Они показывают, сколько данных можно потерять и сколько времени потребуется на возобновление работы систем.

Сергей АНДРОНОВ

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

На наш взгляд, 90% заказчиков уже имеют ЦОД и далеко не всегда изначально построенные в русле концепции катастрофоустойчивости. Поэтому в современных условиях нужно учитывать и идею непрерывности бизнеса. Здесь приобретает важность концепция распределенных дата-центров, когда между несколькими ЦОД создается высокоскоростная инфраструктура для передачи информации, и приложения «живут» во всех ЦОД одновременно. В таком контексте задача построения катастрофоустойчивого ЦОД заключается в создании эффективной системы управления инженерной инфраструктурой и увязывании ее с системой управления виртуальными машинами, чтобы иметь возможность использовать всю сумму имеющихся свободных ресурсов более эластично (то, что мы называем макровиртуализацией). Этот уровень надежности можно назвать логическим.

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

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

Алексей АРХИПОВ

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

Дмитрий ЖУКОВ

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

Антон ЗАХАРЧЕНКО

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

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

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

Андрей ИВАЩЕНКО

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

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

Сейчас у нас ведется проект по созданию резервной площадки для обеспечения катастрофоустойчивости. Целевой срок восстановления работоспособности основных бизнес-процессов согласно Disaster Recovery Plan – не более суток.

Евгений КАЛАШНИКОВ

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

Андрей КУВАЛДИН

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

Для защиты от катастроф (аварий на уровне всей площадки) предназначено катастрофоустойчивое решение, которое включает в себя два или более ЦОД. Задача – активация приложения в ручном или автоматическом режиме с актуальными данными на «запасном аэродроме».

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

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

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

Крупные банки в силу особенностей отрасли прорабатывают стратегию защиты в масштабах страны. Лучшие практики описываются формулой 2C3C: 2 cities, 3 centers. Это означает, что в городе основного базирования находятся два ЦОД «на расстоянии синхронной репликации» (т. е. нескольких десятков километров), дублирующих друг друга в «горячем» режиме, а в другом городе, на расстоянии не менее нескольких сотен километров, располагается третий ЦОД на случай региональной катастрофы в городе основного базирования.

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

Если у вас есть резервная площадка, может возникнуть соблазн использовать ее ресурсы в целях экономии. Существуют технические возможности задействовать эти ресурсы для резервного копирования, генерации отчетов и т. д. Однако важно понимать: основная цель резервной площадки – поддержка работы предприятия в случае недоступности основной. Поэтому критерий при принятии решения об использовании ресурсов резервной площадки в «мирное время» прост: ресурсов одной площадки должно быть достаточно для полноценной работы. Это означает, что «экономии» здесь быть не может. А вот задействование резервной площадки для процедур сопровождения, прохождения «пиковых» нагрузок – разумно. Конечно, где-то могут быть применимы и «компромиссные» схемы, когда резервная площадка обеспечивает работу в «аварийном» режиме со сниженной производительностью – здесь все зависит от баланса стоимости решения и цены простоя.

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

Александр ТРОШИН

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

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

Артем ШАХВЕРДЯН

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

В первую очередь речь идет о защите ключевых данных за счет построения отказоустойчивых территориально распределенных систем с созданием копий ключевых систем на резервной площадке и организацией возможности переключения между площадками. Класс резервирования выбирается в зависимости от критичности процессов. Построение катастрофоустойчивых систем – мероприятие сложное и довольно затратное, поэтому обычно такие системы строятся для процессов класса core или mission-critical. Здесь есть два направления работы: построение ЦОД, соответствующего требованиям Uptime Institute, желательно не ниже Tier III, и обеспечение отказоустойчивости самой корпоративной системы. Если система должна работать в непрерывном режиме, для ее развертывания выбираются системы класса hi-end. Основная цель – максимальная автоматизация процессов резервирования и мониторинга, исключающая по возможности участие персонала.

Заказчик обычно сам выбирает архитектуру и реализацию катастрофоустойчивого решения, поскольку в каждом виде деятельности есть свои нюансы. Для банка это, например, особенности взаимодействия с МЦИ Банка России, которое нужно обеспечить на расстояниях в несколько тысяч километров. Не во всех случая даже опытный вендор может подсказать лучшую практику. Все-таки ИТ-вендоры не выпускают готовых решений для тех же банков. Поэтому катастрофоустойчивое решение – это результат трехстороннего сотрудничества заказчика, вендора и подрядчика. И это не одноразовое мероприятие: ИТ-система – живой организм, который требует постоянного развития, совершенствования, адаптации.

Леонид ШИШЛОВ

Для начала нужно определиться, к каким катастрофам ЦОД должен быть устойчивым. При выборе площадки для нового объекта, как правило, проводится анализ рисков (как реальных, так и потенциальных), которые могут оказывать негативное влияние на объект во время его эксплуатации. Перечень таких рисков обширный. Это и риски, связанные с природными катаклизмами: землетрясениями, наводнениями, цунами, ураганами и т. д. Есть риски, связанные с близостью к источникам повышенной опасности – аэропортам, заводам и др. Кроме того, важно учитывать риски, которые связаны с доступностью основных ресурсов, необходимых для работы ЦОД: электроснабжения, водных ресурсов, доставкой топлива и др. Это и многое другое полностью раскрыто в индустриальных стандартах и регламентах, таких как Uptime Institute, TIA, BISCI, ASHRAE и др. Именно на них и надо ориентироваться при построении ЦОД.

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

Владимир АЛЕКСЕЕВ

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

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

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

Сергей АНДРОНОВ

Оценка рисков в каждом конкретном случае индивидуальна, так как они зависят от многих факторов – начиная от сферы деятельности компании, специфики бизнеса, размера и распределенности организации и заканчивая вероятными природными, техногенными, а в некоторых случаях и политическими рисками. Методика как раз и предусматривает оценку причин выхода ЦОД из строя, критичности для бизнеса выхода из строя дата-центра в целом или какой-то его части, уровня потерь, который признается катастрофическим – так называемый Disaster Recovery Planning и Business Impact Analysis. В результате мы понимаем, от каких катастроф страховаться и что в принципе считать катастрофой, имеет ли смысл создавать распределенный ЦОД или стоит сконцентрироваться на физической безопасности и т. д. В случае разнесенных ЦОД для каждого из них оценка рисков осуществляется отдельно.

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

Алексей АРХИПОВ

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

Дмитрий ЖУКОВ

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

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

Андрей ИВАЩЕНКО

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

Евгений КАЛАШНИКОВ

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

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

Еще одно из перспективных направлений развития ЦОД – построение для особо важных сервисов независимых площадок, входящих в один конгломерат.

Александр ТРОШИН

Главным риском является потеря работоспособности одного из серверов в ЦОД. Для компенсации этого риска используется резервирование, которое может быть «холодным», «теплым» или «горячим». В зависимости от ценности информации для компании заказчик выбирает один из типов резерва.

Артем ШАХВЕРДЯН

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

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

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

Леонид ШИШЛОВ

Рисков в работе ЦОД огромное количество. Но, по статистике, от 50 до 70% угроз бесперебойной работе ЦОД связано с человеческим фактором. Поэтому одной из ключевых задач при проектировании и строительстве катастрофоустойчивого ЦОД должна быть минимизация влияния человеческого фактора на работу такого объекта. Это особенно важно при планировании и реализации программы эксплуатации и технического обслуживания.

Каковы особенности основных этапов жизненного цикла катастрофоустойчивого ЦОД (проектирование – строительство –эксплуатация – расширение – модернизация) и почему? В чем их отличие от традиционных ЦОД?

Антон ЗАХАРЧЕНКО

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

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

Андрей ИВАЩЕНКО

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

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

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

Евгений КАЛАШНИКОВ

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

Артем ШАХВЕРДЯН

И проектирование, и расширение, и модернизация – это постоянные процессы, которые идут параллельно с эксплуатацией. Растет количество систем, сами системы наращиваются по мере развития бизнеса.

При проектировании ЦОД мы всегда смотрим в будущее: закладываем запас и прогнозируем объем расширения. В ЦОД должна быть возможность с минимальными затратами нарастить эксплуатационные мощности. Для этого служит процесс Capacity Management, в рамках которого ИТ-департамент совместно с бизнесом прогнозирует динамику роста, на основании чего планируется и реализуется сайзинг всех систем. В Альфа-Банке процесс управления мощностями охватывает все core-, mission-critical- и business-critical-системы, которые обусловливают основное развитие ИТ-ландшафта.

Леонид ШИШЛОВ

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

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

Владимир АЛЕКСЕЕВ

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

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

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

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

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

Сергей АНДРОНОВ

Если не рассматривать такую опорную технологию, как высокопроизводительная LAN (10–100G), без которой никакое «волшебство» было бы просто невозможно, то наибольшее влияние на механизмы обеспечения надежности и защищенности оказали следующие технологии:

• серверная виртуализация. Сегодня восстановление «упавшего» сервера сводится к копированию файла с его образом из одного места в другое вместо восстановления физического сервера путем замены его сбойных компонентов или полной замены. Это уменьшает время восстановления в разы, а в случае плановых манипуляций с сервером − до нуля за счет Live Migration, позволяющей переносить продуктивную нагрузку с одного виртуального сервера на другой вообще без прерывания сервиса;
• виртуализация систем хранения данных – обеспечение с помощью аппаратных или программных виртуализаторов СХД одинаковой (параллельной) видимости дисковых ресурсов и файлов для серверов, расположенных как в главном, так и в резервном вычислительных центрах. С учетом того, что виртуальный продуктивный сервер обычно представляет собой файл, применение виртуализатора позволяет существенно упростить общую конструкцию системы, повышает надежность и упрощает взаимодействие продуктивной и резервной систем;
• дедупликация – значительное уменьшение объема трафика при передаче данных между главным и резервным центрами, что повышает надежность и снижает требования к каналам связи.

На этих «трех китах» и стоят надежность и защищенность современных продуктивных систем.

Дмитрий ЖУКОВ

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

Антон ЗАХАРЧЕНКО

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

Андрей ИВАЩЕНКО

У нас используется или будет использоваться весь спектр существующих решений – и на уровне оборудования, и на уровне операционных систем, и средства самих приложений (например, встроенные средства СУБД Oracle, которые позволяют решению создавать резервную копию и работать в геокластере). В части виртуализации используются встроенные средства VMware – Site Recovery Manager. Каждое приложение анализируется, и для него выбирается наиболее подходящий способ резервирования самого приложения и его данных.

Андрей КУВАЛДИН

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

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

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

На уровне архитектуры традиционные банковские приложения значительно отличаются от интернет-приложений. Как правило, в банковской сфере ключевыми являются требования транзакционности и согласованности данных. По этой причине обычно применяются классические монолитные реляционные базы данных. В банковской сфере наиболее распространено решение проблем отказо- и катастрофоустойчивости при помощи кластерных решений. Некоторые дополнительные возможности в части локальной отказоустойчивости привносит СУБД Oracle RAC, позволяющая обслуживать одну базу данных несколькими серверами одновременно, однако вопрос адаптации приложений к RAC является весьма непростым.

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

Александр ТРОШИН

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

Артем ШАХВЕРДЯН

В части аппаратного обеспечения это избыточность и класс самого оборудования – hi-end. В части защиты данных и ПО применяется защита на уровне аппаратных средств и защита логическая. Специализированные программные продукты, направленные на защиту данных информационных систем, выполняют функции синхронизации (репликации) данных между площадками, мониторинга и контроля качества данных, дают возможность автоматизации переключения между площадками в случае сбоя. Для разных категорий заказчиков на рынке предлагаются разные функциональные наборы таких продуктов и различной стоимости.

Важная оставляющая обеспечения защищенности – планы аварийного восстановления как со стороны ИТ (Disaster Recovery Plan), так и со стороны бизнеса (Business Continuity Plan). Последний предполагает наличие плана действий в случае утраты бизнесом основного инструмента. Оба плана должны периодически тестироваться согласно разработанному в организации регламенту.

В Альфа-Банке используется весь комплекс инструментов защиты – на уровне оборудования, ПО и планов аварийного восстановления.

В каких сегментах и для решения каких задач наиболее востребованы подобные решения? Насколько здесь различаются отечественный и зарубежный опыт? Как вы оцениваете уровень экспертизы отечественной ИТ-индустрии в этой области?

Владимир АЛЕКСЕЕВ

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

Россия – уникальная страна, охватывающая девять часовых поясов. Это означает постоянную нагрузку на ЦОД и практически полное отсутствие «окон» для сервисных работ. Логичной выглядит конфигурация active-active, когда нагрузка в рамках одной системы в катастрофоустойчивом решении разделена между дата-центрами. Однако реализация такого решения довольно сложна, поэтому на практике встречается редко. Зачастую резервные мощности выделяются под разработку и тестирование и переводятся в продуктив в случае аварии. Как правило, используется комбинация active-passive, когда имеются основной ЦОД и резервный. В России уже есть ряд успешно выполненных проектов для телекоммуникационных компаний, а также транспортного и нефтегазового сектора.

Сергей АНДРОНОВ

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

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

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

Алексей АРХИПОВ

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

Антон ЗАХАРЧЕНКО

Пока мы можем ориентироваться на опыт развитых рынков, таких как США или Западная Европа. В России катастрофоустойчивых решений значительно меньше. Интерес есть, например, со стороны представителей финансового сектора, для которых сбой в работе систем и приложений чреват значительными потерями и репутационными рисками.

Андрей ИВАЩЕНКО

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

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

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

Евгений КАЛАШНИКОВ

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

Артем ШАХВЕРДЯН

Решения востребованы в первую очередь в core- и mission-critical-системах, которые должны постоянно работать в режиме 24×7. В банке это автоматизированные банковские системы, процессинговые системы. Для коммерческих банков важны также интернет-каналы. Они классифицируются как business-critical, потому что нарушение работы интернет-банка не влечет отзыва лицензии, однако с точки зрения взаимодействия с клиентами банк может «потерять лицо». Поэтому интернет-каналы мы тоже стараемся поддерживать в режиме mission-critical.

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

Леонид ШИШЛОВ

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

Как новые технологии управления инфраструктурой влияют на надежность ЦОД? В частности, что можно сказать о технологии программно-определяемых ЦОД (SDDC)?

Владимир АЛЕКСЕЕВ

Концепция Software Defined Datacenter (SDDC) означает создание полностью виртуализированного ЦОД. Такой подход дает преимущества в части управляемости, уровня использования ресурсов и масштабируемости систем. SDDC является следующим логическим шагом развития ИТ-инфраструктуры после виртуализации каждого из компонентов: серверов, сети и систем хранения данных. За счет большей гибкости и управляемости настроить репликацию между дата-центрами будет проще, нежели в обычной невиртуализированной инфраструктуре.

Алексей АРХИПОВ

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

Дмитрий ЖУКОВ

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

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

Андрей ИВАЩЕНКО

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

Евгений КАЛАШНИКОВ

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

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

Артем ШАХВЕРДЯН

SDDC – тема популярная, вендоры активно пропагандируют это направление, однако на рынке крайне мало комплексных решений для ЦОД. Рыночный спрос на такие решения не слишком велик, а их качество пока не соответствует тем требованиям, которые предъявляет крупный заказчик.

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