Облачный ЦОД: как проверить надежность дата-центра при выборе IaaS-провайдера 13/12/2015 Поддержите VM Guru! USDT / TRC20, адрес: TCDP7d9hBM4dhU2mBt5oX2x5REPtq9QdU1 Пост:

Почему все нужно проверять

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

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

Не стоит забывать и о национальных особенностях ИТ-бизнеса. Далеко не все коммерческие дата-центры имеют официальную сертификацию по классу надежности, и еще меньшее их число подтверждено реальным независимым аудитом. Увы, но все еще встречаются разнообразные «внутренние сертификации», «нам это не нужно, мы уверены» и «заявленный уровень надежности — TIER III+» (с этими плюсами ситуация вообще забавная, но об этом позже).

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

Чем отличается надежность со стороны клиента и владельца дата-центра

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

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

Что же обычно хочет видеть заказчик при оценке надежности дата-центра:

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

Между тем порой упускаются важные и неочевидные моменты, которые могут вылиться в серьезные неприятности:

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

Разумеется, список неполный. Но даже этот перечень заставляет задуматься о существовании множества особенностей и нюансов, которые при проектировании объекта балансируют между стоимостью и возможностями. Дабы упорядочить ситуацию и внести какое-то подобие структуры, в 1993 году в США был основан The Uptime Institute (UTI), который является лидером в области оценки надежности и доступности дата-центров. Uptime Institute признан мировым ИТ-сообществом как независимый аудитор соответствия ЦОД требованиям отказоустойчивости.

UTI

Организация Uptime Institute за время своего существования собрала информацию о тысячах происшествий в дата-центрах по всему миру. Эти данные использовались для создания классификации по уровням готовности Tier Classification. Этот классификатор через некоторое время стал стандартом де-факто и был включен в состав американского стандарта построения центров обработки данных TIA/EIA-942.

Классификатор состоит из четырех уровней (Tier1 — 4), где большее число означает более высокий уровень надежности:

• Tier 1 предполагает отсутствие резервирования систем электропитания и охлаждения машинного зала, отсутствие резервирования серверных систем. Фактически инженерная инфраструктура просто должна быть собственной и иметь подстраховку на случай перебоев с электропитанием (генератор). Уровень доступности — 99,671 %, что соответствует примерно 28,8 часам простоев ежегодно.
• Tier 2 основывается на Tier 1, но предполагает резервирование всех активных систем. Это уже более надежный класс, который все же допускает около 22 часов простоев в год (99,75 %).
• Tier 3 уже может считаться работающим без остановок. На этом уровне обязательно должны быть зарезервированы все инженерные системы (включая пассивные), должны обеспечиваться возможности ремонта и модернизации без остановки сервисов. Tier 3 фактически предполагает постройку второго ЦОД внутри того же здания — дублирующая СКС, подводы электричества, отдельная система охлаждения, у всего серверного оборудования независимые подключения к нескольким источникам питания. Допускается не более 1,6 часа простоев в год (99,98 %);
• Tier 4 является дальнейшим развитием третьего уровня и, помимо резервирования всех систем, предполагает сохранение уровня отказоустойчивости даже при аварии. Схема позволяет гарантировать непрерывность работы при любых умышленных или случайных поломках, допуская простой продолжительностью лишь 0,8 часа ежегодно (99,99 %).

Для вашего удобства я собрал отличия уровней надежности в табличку:

Что делать, если у ЦОД нет сертификата?

Процесс сертификации ЦОД — дело хлопотное и очень дорогое. Поэтому велик искус оставить все «как есть», ведь клиент же не бумажку покупает, а часть реальной инфраструктуры! Встречается еще одна вариация на тему: «сертификата UTI у нас нет, но мы провели внутреннюю сертификацию и оценили надежность на уровне Tier 3» (слова представителя одной крупной петербургской компании-интегратора, чей коммерческий ЦОД пустует до сих пор). Звучит странно, но чего только не встретишь на просторах нашей необъятной родины.

Когда стоит задача спроектировать и построить ЦОД, который должен пройти довольно жесткую проверку UTI, сертификация начинается еще на этапе чертежей. То есть сначала владелец показывает проектные документы специалистам UTI для сертификации самого проекта (Design Documents), а после постройки и запуска дата-центра проводится выездная проверка специалистами Uptime Institute с целью понять, насколько результат соответствует проекту (Constructed Facility). Затем следует еще более сложный этап, предполагающий оценку реальной работоспособности систем ЦОД и ее соответствие заявленным значениям (Operational Sustainability). Методика оценки у них своя и включает проверку всех подсистем нового ЦОД. При положительном результате новый объект получает соответствующий своему Tier сертификат и размещается в каталоге UTI.

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

Закономерно возникает вопрос: а можно ли как-то самостоятельно оценить положение ЦОД в иерархии Tier-ов? Это может быть интересно заказчикам, которые рассчитывают сэкономить на приобретении услуг у тех провайдеров, кто изначально вложил меньше денег в постройку дата-центра (помним, что правильная сертификация стоит дорого). Конечно, для технически грамотного человека нет ничего невозможного, но вам потребуется детальная информация об объекте — со всеми инженерными коммуникациями, картами СКС и прочими нюансами. Логично предположить, что мало кто захочет делиться такой информацией с клиентом, тем более при небольшой стоимости проекта (ведь мы стараемся сэкономить).

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

Подводные камни сертификации и российские реалии

На отечественном рынке исторически сложилось так, что владельцы дата-центров разделяют надежность подсистем, заявляя для каждой свой уровень готовности. Так, система кондиционирования может формально соответствовать Tier-3, а электроснабжение «застрять» на Tier-2. Разумеется, из двух цифр для презентации берется наибольшая. К слову, о электроснабжении. Существует и еще одна популярная схема: система электроснабжения резервируется по схеме 2(N+1), как того требует Tier-3, а вот резервный генератор остается один. Получается два компонента электроснабжения, один из которых (генератор) не предполагает вообще никакого резервирования. И похожая на Tier-3 схема таковой не является.

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

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

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

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

Про плюсы

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

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

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

Итого

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

• Четко определите для себя требования к доступности тех или иных приложений. Не следует впадать в крайности и организовывать 99,99 % для любых корпоративных систем — вряд ли это целесообразно. Может быть и обратная ситуация, когда есть некий сервис с крайне жесткими требованиями к надежности и производительности, — может оказаться более выгодным оставить его в собственном ЦОД.
• При выборе провайдера лучше отдавать предпочтение ЦОД, имеющим официальный сертификат UTI Operational Sustainability для заявленного уровня надежности. Такой сертификат подтверждает не только надежность дата-центра, но и серьезность его владельца в части развития бизнеса.
• Не стесняйтесь самостоятельно оценивать надежность и качество систем и сервисов коммерческого или облачного ЦОД. Если вам отказывают в экскурсии по машинному залу и инженерным помещениям или ограничиваются формальными ответами, это повод усомниться в достоверности заявленных характеристик. С таким поставщиком вас могут ожидать трудности в самый неподходящий момент.
• Если рассматриваемый вами ЦОД оценен владельцем как Tier 2/3+, то плюсом можно смело пренебречь. Это не более чем маркетинговый ход.

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

Ссылка на статью в блоге ИТ-ГРАД.