Что происходит в облаках

Кэрри Гетц (Хигби)
Директор компании Siemon по решениям для центров обработки данных

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

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

Популярность концепций интернета вещей IoT (Internet of Things) и «принеси собственное устройство» BYOD (Bring Your Own Device) будет только расти. Каждый человек постоянно будет взаимодействовать со все большим количеством гаджетов, и накапливаемый объем данных будет увеличиваться все быстрее. Список устройств постоянно расширяется: телефоны, планшеты, умные браслеты и часы, фитнес-трекеры и системы контроля здоровья, датчики в умных домах и многое другое. Чем больше объем данных, тем более критичным становится время отклика. Как следствие, чем ближе облачное хранилище расположено к конечному пользователю, тем оно популярнее. Инфраструктура стремится объединить в себе все возможные виды приложений, усиливается конвергенция сервисов, растет популярность распределенных вычислений, и центры обработки данных физически размещают в буквальном смысле «на переднем крае» (Edge Data Centres), как можно ближе к пользователям.

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

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

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

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

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

Представления о надежности и устойчивости ЦОД к отказам тоже нельзя назвать окончательно устоявшимися. Провайдер, оказывающий услуги колокации (в том числе тот, у которого размещает свое оборудование ваш облачный провайдер), говоря о надежности, оперирует классами Tier, которые вполне четко описывают уровни резервирования оборудования и физической инфраструктуры. Заказчику необходимо определиться, какой уровень резервирования критических систем (в первую очередь, электропитания и охлаждения) ему необходим, и выбирать центр обработки данных на этой основе. Фактически, ЦОД строится для обеспечения того или иного класса надежности Tier, однако необходимо проверять, что заложенные в проект параметры поддерживаются на практике. Если проект предусматривал для обеспечения соответствующей надежности установку какого-то оборудования, но в действительности оно установлено не было, то обещанный уровень устойчивости к отказам площадка обеспечить не сможет. В США, например, проектные параметры вообще более не считаются основанием для сравнения, поскольку маркетологи слишком часто манипулировали этими цифрами, стараясь представить свои объекты в максимально выгодном свете.

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

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

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

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

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

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

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

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

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

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

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

Что будет дальше

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


Кэрри Гетц (Хигби)
Директор компании Siemon по решениям для центров обработки данных