• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Дата-центры для облаков

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

По прогнозам компании MarketsandMarkets, рынок услуг облачного хранения к 2021 г. вырастет втрое по сравнению с 2016 г. и достигнет $74,94 млрд. Основной движущей силой в формировании спроса на облачные услуги будет растущая потребность в гибридных облачных хранилищах и мобильных корпоративных решениях, а также стремление к простоте хранения данных в облаке.

Популярность концепций интернета вещей и BYOD продолжит расти, и накапливаемый объем данных будет увеличиваться все быстрее. Чем больше объем данных, тем более критичным становится время отклика. Как следствие, чем ближе облачное хранилище расположено к конечному пользователю, тем более оно востребовано. В результате дата-центры физически размещают в буквальном смысле «на переднем крае» (Edge Data Centres), уменьшая расстояние до пользователей.

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

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

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

Отказоустойчивость

Представления о надежности и устойчивости ЦОДа к отказам тоже нельзя назвать окончательно устоявшимися.

Провайдер, оказывающий услуги colocation (в том числе тот, у которого размещает свое оборудование ваш облачный провайдер), говоря о надежности ЦОДа, оперирует классами Tier (или Rating от ANSI/TIA, или ClassF от BICSI. Подробнее см. Е. Ершова. Как и чем обнадежить клиента ЦОДа? Подходы к классификации и сертификации. «ИКС» № 1-2'2016, с. 78. – Прим. ред.), которые вполне четко описывают уровни резервирования оборудования и физической инфраструктуры. Заказчику нужно определиться, какой уровень резервирования критических систем (в первую очередь электропитания и охлаждения) ему требуется, и выбирать дата-центр на этой основе. Фактически ЦОД строится для предоставления услуг определенного уровня надежности, однако необходимо проверить, что параметры, заложенные в проект, поддерживаются на практике. Если для достижения соответствующей надежности в проекте дата-центра предусматривалась установка того или иного оборудования, но в действительности оно установлено не было, то обещанный уровень устойчивости к отказам площадка обеспечить не сможет. В США, например, параметры проекта ЦОДа теперь вообще не считаются основанием для сравнения и выбора, поскольку маркетологи слишком часто манипулировали этими цифрами, стараясь представить свои объекты в наиболее выгодном свете.

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

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

Проверять, проверять и еще раз проверять

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

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

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

Гиперконвергентные системы

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

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

Планирование на будущее

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

В идеале после установки аппаратных шкафов и прокладки связывающей их структурированной кабельной системы инфраструктура в ЦОДе меняться не должна. В этом нет нужды, если система спланирована правильно. Однако если первоначальное планирование выполнено плохо, то последствия будут печальными. Отрицательным примером может служить злоупотребление подходом ToR (Top of Rack), который популярен в малонаполненных ЦОДах просто потому, что там многое делается на скорую руку и решения принимаются в последний момент. Сетевые коммутаторы при таком подходе заказываются исходя из количества шкафов, а не в зависимости от количества серверов, требующих подключения. В результате на практике используется только часть коммутаторных портов – остальные простаивают, хотя деньги за них заплачены. Если же вы все-таки захотите задействовать свободные порты, к ним придется прокидывать дополнительные кабельные сегменты. Это не только увеличивает расходы, но и приводит к постоянной неразберихе на объекте. По этой причине многие дата-центры, применявшие такой подход ранее, отказываются от него в пользу топологий EoR/MoR (End of Row и Middle of Row), которые предусматривают вынесение коммутаторов соответственно в конец или середину ряда шкафов. Коммутаторы собираются вместе в центре соответствующей зоны, каждый из них обслуживает несколько шкафов, а не один, как в топологии ToR.

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

* * *

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