© 1995-2021 Компания «Инфосистемы Джет»
Стандартизация ЦОД
Инженерная инфраструктура

Говоря о стандартизации, мы подразумеваем соответствие продукта либо решения определенным нормам и правилам. Это понятие универсально и может быть применено к любому виду ИТ-деятельности.

28.05.2010

Посетителей: 104

Просмотров: 87

Время просмотра: 0.6 мин.

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

 

 

Там, где «живет» ЦОД...

 

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

 

Все эти факторы, с одной стороны, влияют на развитие рынка, с другой – воздействуют на сами технологические и архитектурные приемы, которые применяются при строительстве ЦОД. Есть еще третья сторона – все перечисленные выше параметры влекут за собой необходимость стандартизации подходов на всех уровнях цодостроения: архитектурном, структурном уровне, на более низких технологических уровнях – протокольных и аппаратных и т.д. И как раз с этим связана основная проблема – сегодня в мире существует только один стандарт по строительству ЦОД – TIA/EIA-942. Он описывает требования к инженерной инфраструктуре на архитектурном уровне без глубокой детализации. Это приводит к возникновению проблем в технологических аспектах, связанных с отсутствием всеобъемлющих норм, пронизывающих все уровни архитектуры Дата-центра. К тому же все это тормозит развитие всей сферы.

Технологические проблемы стандартизации

 

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

 

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

 

  1. The Priority-based Flow Control (PCF)
  2. The Enhanced Transmission Selection (ETS)
  3. The DataCenter Bridging eXchange
  4. IEEE 802.1aq shortest Path Bridging (IEEE 802.1aq)
  5. IETF Trill (Computer Networking) (TRILL)
  6. IEEE 802.1p/Q
  7. IEEE 802.3x

 

К сожалению, некоторые из них утверждены лишь на уровне драфтов, в то время как другие  находятся в стадии разработки, на уровне группы IEEE1.

 

Критерии оценки ЦОД

 

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

 

Во-первых, это оценки с точки зрения отказоустойчивости (отказоустойчивости именно всего комплекса, а не отдельных компонент).

 

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

 

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

 

И последний, но не менее важный параметр – оценка ЦОД с точки зрения его соответствия стандартам. Ему мы уделим особое внимание, поскольку он является ключевым вопросом нашего разговора. До 2000-х годов существовал только один нормативный документ –  «Строительные нормы и правила» ( СНиП 512-78), разработанный в 1978 году. Он содержит строительные рекомендации к помещениям и зданиям для размещения вычислительных машин. Безусловно, в нем заложены правильные азы, но исходя из современных параметров оценки Дата-центров, их нужно кардинально пересмотреть. СНиП не затрагивает архитектурно-технологическую часть инженерных систем и является общим документом с точки зрения ландшафтных решений. Он не удовлетворяет всем запросам  в части реализации таких проектов.

 

Во второй половине 2000-х годов появился новый стандарт –  TIA/EIA-942.  Стоит отметить, что создатели этого документа – первопроходцы в данной области, и  его положения написаны, в первую очередь, исходя из структурно-архитектурных требований к комплексу инженерных систем (и каждой инженерной системе отдельно).

 

В итоге получается, что СНиП – это совсем «высокоуровневый» документ, TIA/EIA-942 – среднее звено, а все что ниже (протоколы, технологические решения) – отдается на усмотрение различным вендорам, которые на основе этих требований разрабатывает свои протокольно-технологические решения для своего оборудования. 

 

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

 

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

 

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

 

Фактически решение подобных вопросов целиком и полностью отдается интегратору. Это означает, что вы доверяетесь специалистам и надеетесь, что благодаря своим высоким компетенциям, о которых они рассказывали на этапах подготовки к проекту, вас не обманут и сделают все правильно.


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

 

К тому же, нет единого стандарта о том, какое количество сертифицированных специалистов должно быть у интегратора и по каким критериям они должны быть сертифицированы, какими квалификациями обладать, какими сертификатами все это должно быть подтверждено. Это касается как узконаправленных специалистов, так и специалистов уровня ГИП. Заказчик выбирает интегратора по маркетинговым соображениям: по количеству реализованных проектов, по опыту работы. Он верит ему на слово, поскольку нет формального механизма, позволяющего определить, что согласно мировым стандартам этот интегратор подходит именно под его задачи.

 

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

 

И если представить, что Россия войдет в ВТО, можно считать, что «кризис жанра» уже наступил. На рынок придут крупные мировые интеграторы, и с точки зрения российского ИТ-бизнеса произойдет коллапс. Когда дело дойдет до аудита, окажется, что 90% всего, что построено отечественными компаниями, не соответствует заявленному. Уже сегодня, например, 99% ЦОД не соответствуют заявленному Tier. А для заказчика это означает повторные инвестиции, переделки и разочарования.

 

Аудит – вопросы соответствия

 

Есть сейчас в мире услуга, которая позволяет вам, привлекая коммерческие организации, провести оценку вашего ЦОД на соответствие стандарту TIA/EIA-942 по параметрам, разговор о которых шел выше. Есть известные мировые аудиторы, которые могут провести такую оценку, но по целому ряду причин они с большой осторожностью относятся к таким работам и не спешат  предлагать данную услугу на российском рынке. Например, одной из таких компаний является Uptime Institute, который занимается сертификаций уже построенных ЦОДов, относя их к определенному классу надежности. Так как сертификация проводится уже готового проектного решения, невозможно в процессе строительства проверить правильность его реализации и исправить недочеты до завершения работ. В итоге – очень часто при прохождении аудита выясняется, что ваш ЦОД не соответствует заявленному классу. А приглашать Uptime Inst. во время строительства довольно дорого, да и сотрудников компании на всех не хватит. На рынке аудиторов, безусловно, есть и более мелкие игроки, которые готовы провести аудит, правда достоверность таких работ не всегда вызывает доверие.

 

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

 

Специфика российского рынка

 

В силу сложившейся ситуации возникает довольно очевидный вопрос: что делать? И какой выход из положения может быть, если он вообще существует?

 

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

 

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

 

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

 

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

 

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

 

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

 

Итого, в сухом остатке...

 

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

 

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

 

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

Уведомления об обновлении тем – в вашей почте

ЦОД сдан в эксплуатацию. Покой нам только снится?

Вот и наступил долгожданный момент, когда владелец дата-центра принял его в эксплуатацию

Модульные ЦОДы

Основой для возникновения этого решения в свое время послужили мобильные ЦОДы

Коммерческий ЦОД в жилом доме — бесперспективная идея?

Почему центры обработки данных решили строить в ЖК? Какие проблемы возникают при строительстве и эксплуатации дата-центра? Где в Москве лучше строить коммерческие ЦОДы?

Миграционный вопрос

Как организовать и провести ИТ-миграцию, обеспечить безболезненный переезд ИТ-систем

Эксплуатация ЦОД. Что лучше: аутсорсинг или своя команда?

Любые сложные инженерные системы, а к таковым, безусловно, относятся системы центров обработки данных (ЦОД), нуждаются в обслуживании

Распределенные центры обработки данных

Резервный вычислительный центр (РВЦ) — это одно из решений, направленных на обеспечение доступности данных и информационных служб в целом.

Виртуализация нового типа

Название статьи предусматривает, что существует или существовала раньше виртуализация «старого типа», на базе которой или, скорее, вопреки которой появилась виртуализация «новая».

Рынок ЦОДов: вчера и сегодня

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

«Бояться новых подходов в ИТ — все равно что бояться дышать»: что такое Инфраструктура 3.0 и почему она неизбежно наступит

Какие технологии характерны для Инфраструктуры 3.0? За счет чего новый подход может быть выгоднее имеющейся инфраструктуры? Как хождение по граблям решает кадровый вопрос?

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня