ИТ-портал компании «Инфосистемы Джет»

Курс на облако с минимальным PUE

Курс на облако с минимальным PUE

Если сравнивать современные принципы ЦОДостроения с теми, что были на коне лет 5 назад, можно проследить принципиальные отличия. Еще в середине 2000 годов масштабирование дата-центра обеспечивалось за счет изначального закладывания избыточности решений – предоставления максимально возможных мощностей и ресурсов. Одним словом, решение о строительстве принимали, ориентируясь в первую очередь на размер CAPEX. OPEX на тот момент в расчет не брали, а если и рассматривали, то как что-то, отдаленное от ЦОД. В то же время дата-центр при строительстве ориентировали на определенную архитектуру серверного оборудования: его зоны жестко сегментировались на Hi-End`ы, сетевую часть (LAN, SAN и т.п.), серверы х86, СРК и т.п. Такая карта местонахождения диктовала раз и навсегда закладываемые маршруты прокладки коммуникаций. Другими словами, дата-центры были «неповоротливыми» относительно потенциальной модернизации размещаемого в них серверного оборудования.

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

При этом существенно изменилась и концепция построения серверной ИТ-инфраструктуры: «вектор силы» направлен на повышение энергоемкости. Доля Hi-End-оборудования пошла на убыль, тогда как количество серверов х86, напротив, увеличилось в разы. Один физический сервер теперь, благодаря виртуализации, может скрывать в себе несколько логических. Фермы виртуализации объединяют их в единое целое, и в случае выхода из строя того или иного сервера виртуальные машины (ВМ) поднимаются на другом, без прерывания работы и совершенно незаметно для пользователей.

В результате в ЦОД 5–7-летней выдержки возникли зоны, где базовые показатели инженерной инфраструктуры (энергетика, холод, юниты) вышли за проектные значения. Этот процесс напоминает фрагментацию дискового пространства при работе с файловой системой. Заполнение ЦОД перестало быть равномерным, что привело к дисбалансу и с точки зрения инженерной инфраструктуры. На отдельных участках ЦОД появились перекосы – перегрев, превышение лимитов по электричеству или, наоборот, его дефицит. Подобные точки отказа грозят остановкой серверного оборудования. Это не могло не отразиться на степени утилизации дата-центров: если на 2008 год ее среднее значение для большинства ЦОД составляло 70–80%, то сейчас едва ли достигает 50%.

Сегодняшнюю ситуацию с дата-центрами в России я бы обозначил как «демографическое старение в стране отечественных ЦОД». Пик их строительства пришелся на первую половину 2000-х. Грянувший кризис 2008 года заморозил или заставил вовсе свернуть большинство строек. Потепление наступило лишь в 2010–2011 годах – некоторые из них были извлечены из долгого ящика. В результате на 4–6 докризисных дата-центра в среднем приходится всего 1 ЦОД-новичок, который может похвастаться использованием зеленых технологий и «низкокалорийным» PUE. ЦОДы «с судьбой» не так энергоэффективны, но снимать их со счетов пока преждевременно: они надежны, масштабны (далеко не все новые дата-центры занимают такие площади) и, как уже было сказано, гораздо более многочисленны. Поэтому целесообразнее будет провести их модернизацию с учетом новых тенденций.

Если говорить об оптимизации OPEX’ов, то не последнюю скрипку здесь на данный момент играет Power Usage Effectiveness – PUE. Энергоэффективность ЦОД по факту уже стала одним из ключевых параметров для их владельцев, соответственно, ускоренными темпами растет спрос на «зеленые» решения.

Синергия серверного и инженерного оборудования

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

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

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

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

Гораздо легче при использовании технологий виртуализации переместить в ту или иную физическую зону дата-центра нагрузку на процессорные мощности. Если их расположить более или менее равномерно, можно обеспечить и распределение нагрузки путем миграции ВМ между физическими серверами в соответствии со статистическими показателями, накапливаемыми DCIM. Тогда вы сможете доставлять высоконагруженные процессорные ресурсы ближе к подходящим элементам инженерной инфраструктуры. И наиболее холодно будет в зонах «накала серверных страстей». Проблема карты фиксированного местонахождения, рассчитанной на Hi-End-ориентированное зонирование дата-центров, снимется с повестки дня.

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

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su