Rambler's Top100
Статьи ИКС № 09-10 2015
Сергей АНДРОНОВ  10 ноября 2015

Как ЦОДом обзавестись и бюджет не растерять

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

Сергей АНДРОНОВ, директор Центра сетевых решений, «Инфосистемы Джет»

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

Технология рубль бережет

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

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

Не менее интересна (особенно при наличии географически распределенных серверных площадей) с точки зрения оптимизации занимаемого места, энергопотребления и пр. концепция макровиртуализации, которая базируется на сращивании функционала систем DCIМ и управления виртуальными машинами. DCIM аккумулирует информацию о состоянии инженерной инфраструктуры распределенных серверных площадей, о наличии свободного места в них в целом (и в отдельных стойках в частности), сводит ее в единую картину. На основании полученных данных и информации из системы управления виртуальными машинами определяются причины возникновения в том или ином ЦОДе (или его сегменте) дефицита ресурса охлаждения и/или электропитания, рассчитывается оптимальная модель. Затем виртуальные машины переносятся туда, где необходимый инженерный ресурс есть. При этом данные фрагменты ЦОДа будут работать с максимальной эффективностью, в то время как оставшаяся часть дата-центра, в том числе и инженерная инфраструктура, может функционировать в режиме stand-by. Это гарантирует большую эффективность дефрагментации и утилизации основных ресурсов ЦОДа (энергоснабжения и охлаждения), а также значительное уменьшение эксплуатационных затрат и затрат на обслуживание инженерных систем. По нашему опыту, такая дефрагментация может высвободить от 30 до 40% ресурсов в дата-центре, функционирующем более восьми лет. Это значит, что ровно столько же оборудования можно будет добавить. Кроме оптимизации использования инженерного ресурса эта технология решает вопрос надежности: даже если инженерная инфраструктура ЦОДов имеет невысокую надежность, все они взаимно резервируют друг друга.

Импровизация по ходу стройки

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

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

Во-вторых, можно построить новый дата-центр нужной мощности, повысив утилизацию мощностей существующих ЦОДов. Этот вариант, конечно, актуален только для тех, кто уже обладает одной-двумя серверными площадками, имеющими запас мощности. Принцип прост и основан на «растягивании» линейных систем (СКС, холодоснабжения и т.п.) имеющегося дата-центра на новые площади с подключением к центральным узлам. По статистике, утилизация мощностей дата-центров оставляет 60–70% (а при неправильном планировании серверного хозяйства этот показатель может падать и до 40%), поэтому простое наращивание лучей от основных систем позволит обеспечить мощностями новые серверные площади. Кстати, проектирование в этом случае можно назвать «мелкозернистым», так как оно рассчитано на взаимоувязку слишком мелких (в масштабах ЦОДа) элементов. А это требует повышенной точности, обеспечить которую может 3D-проектирование, практически полностью исключающее риск возникновения внеплановых работ по ходу проекта.

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

Присесть на облако

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

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

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

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

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

Поделиться:
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!