В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик | К списку авторов | К списку публикаций
С одной стороны, мы (Россия) в начале нулевых с головой окунулись в ЦОДостроение. Можно сказать, имел место самый настоящий бум строительства дата-центров. С другой стороны, в тот период никто не задумывался о том, что срок жизни ЦОДа должен намного превышать таковой у размещаемого в нем серверного оборудования. Изменения инженерной инфраструктуры ЦОДа происходят менее динамично по сравнению с изменениями архитектуры серверного оборудования. В результате на сегодняшний день в России размещено большое количество ЦОДов, построенных с учетом прогноза наполняемости серверным оборудованием, продолжительность жизни которого в среднем составляет не более 5 лет.
Прежде, например, ЦОДы при проектировании рассчитывались на установку в них моноблочных серверных систем класса Hi-End, таких как SUN Fire 25K и им подобных. На сегодняшний день все эти громоздкие моноблоки на базе процессоров RISC-архитектуры практически исчезли с рынка – все перешли на архитектуру х86. Возникло изобилие серверного оборудования в компактном исполнении: блейд-серверы, серверы высотой 1–2U. И, если по сравнению с моноблоком, суммарное потребление электроэнергии в расчете на одну стойку не изменилось, то охлаждение устанавливаемого в стойку оборудования должно производиться иначе. В сопроводительной документация к RISC-серверам SUN Microsystems отдельно оговаривалось требование обеспечить подачу вентиляционного воздуха в необходимом объеме через отверстия в фальшполе. Новый форм-фактор серверного оборудования, как минимум, требует иной конфигурации вентилирования и вывода тепла из стойки. Данное обстоятельство наряду со многими другими приводит к недоиспользованию серверных площадей и инженерной инфраструктуры ЦОДа. Исправить сложившуюся ситуацию, к сожалению, не представляется возможным.
Первое, что приходит на ум, – необходимо построить новые ЦОДы, оптимально приспособленные к новейшей серверной архитектуре. Построив современный ЦОД, его владелец фактически оказывается на "рынке продавца", т.е. у него нет проблем со сбытом серверных площадей. Владельцы нового серверного оборудования хотят разместить его наиболее эффективно, а в унаследованных ЦОДах это сделать невозможно. Результат: серверное оборудование переезжает на новое место, покидая унаследованные ЦОДы, таким образом, утилизация последних снижается еще сильнее. Однако из-за экономической стагнации новых ЦОДов пока построено совсем немного, и они уже на 100% заполнены.
Тем самым владельцы унаследованных ЦОДов оказались в весьма плачевной ситуации – от них уходят клиенты, и в то время как вложенные в ЦОД инвестиции, по-хорошему, должны бы еще работать, со снижением утилизации доходы от эксплуатации унаследованного дата-центра падают.
Дело в том, что такие ЦОДы оснащены инженерным оборудованием, не приспособленным для обслуживания современных серверов. В принципе, они могут быть размещены и в ЦОДе "старого образца", но это неизбежно вызовет деградацию эффективности их использования, равно как и использования инженерного оборудования. Если в унаследованном ЦОДе на площади в 4 м2, к примеру, размещался один сервер класса High-End высотой 42 дюйма, потреблявший 20 кВт электроэнергии и требующий соответствующего теплоотведения, то на его место ставится стойка с тремя корзинами блейд-серверов х86, каждая из которых выделяет до 15 кВт тепла. На самом деле это означает, что на этой площади в стандартной стойке можно разместить только две блейд-корзины, работающие с неполной нагрузкой. Треть же стоечного "блейд-пространства" останется незаполненным. Возникает, с одной стороны, так называемая "фрагментация юнитов", с другой – серверы приходится недогружать, чтобы выдерживать проектные параметры эксплуатации систем электроснабжения и вентиляции. В масштабах ЦОДа это приводит к падению утилизации со всеми вытекающими последствиями.
В то время как серверное оборудование меняется очень быстро, инженерное – имеет тенденцию к более медленному изменению, оно более консервативно. Как таковых, этапов модернизации систем инженерного обеспечения немного. Возьмем, например, охлаждающее оборудование, модернизация которого направлена на снижение коэффициента PUE – встроенные в фальшпол или внутрирядные кондиционеры, изолированные холодные и горячие коридоры, фрикулинг – вот, пожалуй, и все варианты.
Переход на новое серверное оборудование неизбежно влечет за собой массу проблем с изменением инженерной инфраструктуры для повышения степени ее утилизации – свобода действий здесь чрезвычайно ограничена. Можно попытаться поменять кондиционеры, внедрить какие-то энергоэффективные решения, но это приведет к значительным простоям. Если ЦОД обслуживает нескольких заказчиков или даже несколько бизнес-приложений, какие-либо изменения его инженерной инфраструктуры, связанные с простоями, попросту неприемлемы. Необходим комплексный подход, охватывающий не только серверную, но и инженерную инфраструктуру ЦОДа.
До сих пор, однако, производители инженерного оборудования традиционно не ориентируются на производителей серверов, и наоборот. Вообще среди представителей "хайтековского мейнстрима" конкуренция чрезвычайно высока, о каком-то взаимодействии и сотрудничестве говорить здесь не приходится. В результате возникает та самая фрагментация.
Для дефрагментации можно попытаться применить известные технологические решения. Одним из таких решений является ПО DCIM (Data Center Infrastructure Management – управление инфраструктурой ЦОДа). С помощью DCIM можно, например, выяснить, где в ЦОДе имеются области свободных ресурсов, и, наоборот, выявить очаги перегрузки, вызывающие перегрев оборудования.
Другим решением может служить виртуализация. Она позволяет использовать полученную с помощью DCIM информацию для формирования управляющих сигналов с целью перераспределения виртуализированных ресурсов (виртуальных машин). Таким образом, можно попытаться выровнять нагрузку на физическую инфраструктуру ЦОДа.
Благодаря виртуализации постепенно сами ЦОДы, с точки зрения их операторов, перестанут являть собой физические сущности. Так, несколько территориально распределенных физических ЦОДов можно объединить в единый виртуальный ЦОД с виртуальной средой. При этом в качестве дополнительного бонуса появится возможность повысить общий уровень надежности дата-центра программным способом, выстраиваемого на базе ЦОДов с более низкими TIER.
И операторы, и пользователи ЦОДов стремятся минимизировать свои операционные затраты (эксплуатационные расходы). Для чего нужно стремиться делать самим как можно меньше, т.е. заставить работать пользователя, добиться того, чтобы он сам управлял своими ресурсами. Это означает, что необходимо создать набор неких стандартных типизированных решений и уйти от регулярного "изобретения велосипеда", иначе говоря – построения каждый раз новой особой виртуальной среды для заказчика.
Предположим, заказчик услуг ЦОД хочет получить в свое распоряжение некое виртуальное пространство для своих приложений. Оператор ЦОДа, со своей стороны, предоставляет заказчику набор элементов (своего рода виртуальный конструктор), позволяющий тому самостоятельно создать такое пространство. Допустим, заказчику нужны выделенная сеть, собственные маршрутизатор, межсетевой экран, коммутатор и т.д. Прежде это все предоставлялось ему (за довольно большие деньги) оператором в виде физических линий связи и сетевых устройств.
Виртуализация привела к тому, что сегодня практически все составляющие корпоративной сети можно заменить соответствующими виртуальными устройствами: физический сервер – виртуальным сервером, физический маршрутизатор – виртуальным маршрутизатором и т.д. Все это существует в виртуальной среде, развернутой поверх однотипных стандартизированных экономичных серверов. Каждое виртуальное устройство можно резервировать методом простого копирования, а затем при необходимости восстанавливать из резервной копии. Тиражировать виртуальные устройства методом копирования также чрезвычайно легко. Это относится ко всем виртуальным устройствам. Пользователю виртуальные устройства обходятся дешевле аппаратных, а оператору нет необходимости ни приобретать и эксплуатировать специализированное оборудование, ни выделять для этого квалифицированный персонал и обеспечивать дополнительную отказоустойчивость, тем самым операционные затраты оператора ЦОДа сокращаются.
Такие виртуальные сущности можно представить в виде дружественного пользователю интерфейса (в том числе и Web-), в котором все операции и объемы потребления виртуальных ресурсов могут быть прозрачно тарифицированы. Пользуясь этим интерфейсом, заказчик сам собирает нужное ему решение, не приобретая при этом ни в аренду, ни в собственность никакого физического оборудования. Свои бизнес-приложения он развернет в виртуальной среде, которую сам же для себя создал. Оператор ЦОДа, со своей стороны, не затрачивает на это ни одного человеко-часа, поскольку все необходимые действия выполняет сам заказчик – создает виртуальную сеть, хранилище, серверы приложений и т.д.
Пользователи не склонны к тому, чтобы платить вперед, если на текущий момент не испытывают потребности в том или ином ресурсе. Например, на начальной стадии работы можно ограничиться минимальным количеством портов на маршрутизаторе и лишь при необходимости впоследствии приобрести дополнительные порты (разумеется, виртуальные). Масштабирование решения может быть и со знаком минус: ставшие ненужными порты можно исключить из решения и перестать платить за них. В прежние времена последнее представляло большую проблему, ведь физические порты удалить не так просто, как виртуальные.
Сегодня ЦОДы становятся гибче, и оплату их услуг заказчики могут оптимизировать по своему усмотрению, не "замораживая" свои деньги. Такова общая тенденция, и она набирает обороты.
Если до 2010 г. операторы ЦОДов учились управлять виртуальными машинами, то начиная с 2011–2012 гг. актуальность приобрела виртуализация сетей посредством технологий SDN (программно-определяемые сети), NFV и им подобных. Дело в том, что каждой созданной в рамках виртуалирированного ЦОДа корпоративной сети некоего заказчика присуща уникальная схема распределения IP-адресов, к которым жестко привязаны функционирующие в такой сети приложения. Виртуализация сети, будучи стандартизированной, позволяет переносить ее из одного ЦОДа в другой, не меняя при этом IP-адресацию, так же легко, как отдельно взятую виртуальную машину.
Важным аспектом для возможного использования виртуальных ЦОДов, облачных услуг для корпоративных пользователей является доверие. К сожалению, в России в данном отношении культура бизнеса находится на весьма низком уровне. Все словно ждут какого-нибудь подвоха с чьей-либо стороны. Поэтому, в частности, крупнейшие российские предприятия не спешат переводить свои бизнес-критические системы в чье-либо облако, не имея возможности контролировать его финансовыми, административными или иными методами.
Тем не менее, движение в сторону виртуализации ЦОДов набирает скорость. Одна из важных причин тому заключается, в возможности – снова, казалось бы, парадоксальной – построить высоконадежный виртуальный ЦОД на основе физических ЦОДов сравнительно более низкой степени надежности. Здесь была бы уместна аналогия с Интернетом, в котором любой физический узел или канал связи по определению ненадежен.
Литература
Опубликовано: Журнал "Технологии и средства связи" #2, 2015
Посещений: 7207
Автор
| |||
В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик | К списку авторов | К списку публикаций
