Международный магистральный оператор связи

Один из ключевых поставщиков услуг международной передачи данных.
Предоставление услуг IP-транзита и выделенных каналов связи международным и локальным Интернет-провайдерам.
Организация виртуальных частных сетей (VPN), доступа в Интернет и других услуг связи для крупных и средних предприятий из различных отраслей промышленности; банковских структур и финансовых институтов, а также государственных организаций
Обширное покрытие сети — 28 стран, 3 континента — и значимое присутствие в Восточной Европе и России.
Высокая пропускная способность сети, через которую проходят большие объемы международного трафика.
Высокая связность за счет прямых подключений к многочисленным ЦОДам и международным точкам обмена трафиком.

Крупнейший интернет-провайдер Москвы

Широкая зона покрытия — около 70 районов для корпоративных клиентов и 27 районов для физических лиц.
Инновационные технологии — постоянно совершенствует качество своих услуг, увеличивая мощность серверов и пропускных способностей каналов, смело внедряя инновационные технологии, предоставляя своим абонентам пользоваться новыми возможностями для работы, отдыха, общения и развития.
Starlink заботится о своих абонентах, предоставляя им Интернет нового поколения. Компания первой в России стала активно подключать своих пользователей к Сети, используя IPv6 — протокол нового поколения.

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

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

Революция произошла в 90-х годах, после распространения клиент-серверной модели. Те компьютеры, которые стали считать серверами, начали размещать в отдельных помещениях с подготовленной инфраструктурой. Названия этих помещений на английском звучали как Computer room, Server room, Data Center, в то время как в Советском Союзе мы называли их «Машинными залами» или «Вычислительными Центрами». После распада СССР и популяризации английской терминологии наши ВЦ превратились в «серверные» и «Центры Обработки Данных» (ЦОД). Есть ли принципиальные отличия между этими понятиями, или это всего лишь вопрос терминологии?

Первое, что приходит на ум, это масштаб: если маленькая, то серверная, а если большой - то ЦОД. Или: если внутри только свои сервера, то это серверная; а если предоставляются услуги размещения серверов сторонним компаниям - то дата-центр. Так ли это? За ответом обратимся к стандартам.

Стандарты и критерии

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

В самом стандарте TIA 942 написано, что цель его создания - сформулировать требования и руководящие указания по проектированию и монтажу ЦОД или машинного зала. Будем считать, что ЦОД - это то, что соответствует требованиям TIA 942, а серверная - просто некое помещение с серверами.

Итак, стандарт TIA 942 классифицирует 4 уровня (TIERs) ЦОД и называет ряд параметров, по которым можно провести эту классификацию. Для примера я решил проверить, является ли моя серверная, построенная вместе с заводом три года назад, настоящим дата-центром.

В качестве небольшого отступления укажу, что завод занимается изготовлением штампованных деталей для автомобильной промышленности. Мы выпускаем кузовные детали для таких компаний, как Ford и GM. Предприятие само по себе небольшое (общий штат порядка 150 человек), но с очень высоким уровнем автоматизации: число роботов сопоставимо с количеством рабочих в цехе. Основным отличием нашего производства можно назвать ритм работы Just-In-Time, то есть мы не можем себе позволить задержку, в том числе по вине ИТ-систем. ИТ являются критичными для бизнеса.

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

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

Основные параметры классификации ЦОД

Стандарт устанавливает критерии двух категорий - обязательные и рекомендуемые. Обязательные обозначаются словом «должны» (shall), рекомендуемые - словами «следует», «могут», «желательно» (should, may, desirable).
Первый и самый важный критерий - уровень эксплуатационной готовности. Согласно TIA 942, ЦОД высшего - четвертого - уровня должен обладать 99,995% готовности (т.е. не более 15 мин простоя в год). Далее, по нисходящей, 99,982%, 99,749% и 99,671% для первого уровня, что соответствует уже 28 ч простоя в год. Критерии довольно жесткие, однако что из себя представляет эксплуатационная готовность ЦОД? Здесь считается только простой всего ЦОД по вине одной из систем жизнеобеспечения, и простой отдельных серверов на эксплуатационную готовность ЦОД не влияет. А раз так, то самой вероятной причиной отказа справедливо считать перебои в системе энергоснабжения.

В нашей серверной установлен мощный ИБП APC с резервированием N+1 и дополнительным шкафом батарей, который способен поддерживать работоспособность не только серверов, но и всех компьютеров на предприятии до 7 ч (а зачем нам работающие сервера, если к ним некому подключаться). За три года эксплуатации сбоев ни разу не было, так что по этому параметру мы можем претендовать на самый высокий TIER 4.

К слову об энергоснабжении, третий и четвертый классы ЦОД требуют второго энерговвода. У нас его нет, так что максимум - второй класс. Еще стандарт классифицирует потребление мощности на квадратный метр площади. Странный параметр, никогда об этом не задумывался. Померял: у меня 6 кВт на 20 м кв., то есть 300 Вт на квадратный метр (только первый уровень). Хотя возможно, что я неправильно считаю: в стандарте указано, что хороший ЦОД должен иметь свободные площади для масштабирования. То есть получается, чем больше «запас масштабирования», тем ниже уровень ЦОДа, а должно быть наоборот. Здесь у нас самая низкая оценка, но все же стандарту отвечаем.

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

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

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

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

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

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

Нашел я таки параметр, по которому моя серверная на ЦОД не тянет: размер входной двери. По стандарту должно быть минимум 1,0×2,13 м, а лучше 1,2×2,13 м. А у нас дверь обыкновенная: 0,9×2,0 м. Это минус, но считать критерием отличия ЦОДа от серверной размер входной двери - это несерьезно.

Почти настоящий ЦОД!

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

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

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

/ ЦОД: строить или арендовать?

Вконтакте

Одноклассники

Михаил Поляков , заместитель генерального директора «ИНСИСТЕМС» (группа компаний ЛАНИТ)

ЦОД: строить или арендовать?

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

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

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

Направление бизнеса и его масштабы

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

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

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

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

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

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

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

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

Сейчас следует задуматься именно об аренде услуг ЦОД. В связи с развитием виртуализации и облачных технологий аренда серверного оборудования (dedicated server) и размещение собственных серверов в предоставляемых стойках (colocation) – лишь часть услуг, традиционно предоставляемых ЦОД. Кроме перечисленных, ЦОД предоставляют услуги IaaS (Infrastructure as a Service), SaaS (Software as a Service) и PaaS (Platform as a Service).

В последнее время развитие облачных технологий вызвало появление даже такого понятия, как XaaS (Anything as a Service), то есть возможность предоставления любых услуг через Интернет. Все это не только расширяет список потребителей услуг ЦОД, но и создает новые типы провайдеров этих услуг. В свою очередь, провайдеры услуг ЦОД более высокого уровня одновременно являются потребителями услуг более низкого уровня. Например, провайдер SaaS может являться потребителем IaaS, colocation или dedicated server. Важным субъективным моментом, влияющим на выбор решения о собственном ЦОД или аренде, может стать и осведомленность потребителя об услугах, которые ему предлагают.

Сейчас подавляющее большинство уже понимает, что такое аренда сервера или стойки, когда такими же привычными и понятными станут смысл и преимущества и других услуг, количество арендаторов заметно вырастет. БИТ

Рост на фоне нестабильности

В 2014 году российский рынок дата-центров вырос почти на 30% и составил 11,9 млрд руб. (9,3 млрд в 2013 году).

Такие данные приводятся в исследовании компании iKS-Consulting «Российский рынок коммерческих дата-центров 2014-2018», опубликованном в декабре 2014 года. Одним из ключевых факторов роста рынка стал ввод новых мощностей ЦОД в РФ. В 2014-м площадь машинных залов увеличилась на 17,5 тыс. кв.м, а количество стоек – на 3,5 тыс. Таким образом, на конец 2014 года суммарная площадь машинных залов коммерческих ЦОД в РФ достигнет 86 тыс. кв.м (рост 36,5%), стоек – 25,5 тыс. (рост 28%) (см. рис. 1).

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

По данным годового отчет «Российский рынок центров обработки данных 2014» РБК.Research, доходность от услуг ЦОД в 2014-м выросла у 60% компаний, снизилась у 10%, осталась на прежнем уровне у 30% компаний, в то время как в 2013 году увеличение показателя доходности отметили 71% игроков рынка.

Повышение энергоэффективности ЦОД более чем на 5% в 2013 году отметили 71% опрошенных компаний, в 2014-м – уже 78%. У остальных участников исследования этот показатель остался на прежнем уровне.

Граница минимальной стоимости услуги ЦОД в 2014 году увеличилась у 11% участников исследования. При этом у 78% компаний данный показатель остался на уровне прошлого года.

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

Область применения документа и перечень рассматриваемых вопросов

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

В документе рассматриваются:

• Проблемы, появляющиеся на этапах проектирования, строительства и эксплуатации ЦОД, а так же возможные решения этих проблем
• Приводятся рекомендации по использованию современных стандартов, а так же даётся краткая их характеристика
• Приводятся основные ошибки при проектировании, и проблемы, появляющиеся при эксплуатации, показываются их последствия, а так же возможные пути устранения ошибок и решения проблем
• Отдельно приводятся правила создания успешных IT-проектов
• Раскрываются наиболее важные требования к основным элементам ЦОД, и по возможности, объясняется причина этих требований и последствия их несоблюдения
• Перечисляются основные тенденции в создании ЦОД и некоторые статистические данные зарубежных и российских ЦОД

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

Предварительно я попытаюсь уточнить круг специалистов, для которых документ будет ориентирован. Это будут специалисты организаций не имеющие ЦОД, но желающие его построить, специалисты принявшие решение построить ЦОД, но не знающие, на что обратить внимание при написание технического задания (Т)З и как выбрать партнёра, специалисты, построившие ЦОД, но пытающихся при эго эксплуатации обеспечить заявленные характеристики и снизить затраты. А также вероятно документ будет интересен поставщикам оборудования и разработчикам ЦОД, хотя бы в плане понимания проблем их клиентов. Хотя документ и будет рассматривать большинство вопросов возникающих при обосновании выбора ЦОД, его проектировании, построении и эксплуатации, но в документе не будет указаний на выбор того или иного оборудования, и даже на обязательное использование тех или иных технологий. Дело в том, что новая техника, решения и технологии появляются каждый год, часто, по сути, отличаясь внесением некоторых несущественных изменений, или реализацией давно известных решений, но на новом техническом уровне. Помните — «Знание нескольких принципов, освобождает нас от знания множества частностей ». Исходя из этого, я и постараюсь в первую очередь, рассказать о принципах проектирования и эксплуатации сложных вычислительных систем, которые, как нельзя лучше подходит для ЦОД.

Для того, что бы обсуждать проблемы построения и эксплуатации ЦОД надо определиться с некоторыми терминами и понять что же такое ЦОД. Поэтому вначале я попытаюсь определиться с самим термином «ЦОД».

Определение термина «ЦОД»

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

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

Если обратиться к Википедии то ЦОД или центр хранения и обработки данных (ЦОД /ЦХОД ) - это специализированное здание для размещения (хостинга) серверного и коммуникационного оборудования и подключения абонентов к каналам сети Интернет. Другое название ЦОД — Дата-центр (от англ. data center ).

Замечание : Если в документе приводится термин «Дата-центр », то это означается, что цитируется, или пересказывается документ, где используется именно такой термин, а не термин «ЦОД ».

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

Во всяком случае, в определении ЦОД не стоит подчёркивать наличие хостинга и сети Интернет, т.к. они действительно могут быть, но их отсутствие не является критичным для ЦОД. В том виде, как приводится уточнённая формулировка ЦОД, она наиболее полно соответствует концепции ЦОД изложенной в Стандарте TIA-942 . Хотя, на мой взгляд, следовало бы уточнить формулировку «ЦОД — Это здание, его часть, или группа зданий , для которых применены… » далее по тексту. Т.к. вполне может оказаться, что при реализации ЦОД с дублированием подсистем территориально ЦОД окажется разнесён между несколькими зданиями. Иногда вспоминают и о том, что при функционировании ЦОД необходимо разработать комплекс организационных процедур и постоянно заниматься обучением персонала. Но это уже не столь принципиально, т.к. стоит только понимать, что ЦОД это не только здание, но и комплекс инженерных решений, да и не только её, а так же обеспечение необходимых сервисов и наличие квалифицированного персонала.

Исторически дата-центры (название ЦОД появилось позже в России) выросли из больших серверных имеющихся у IT-компаний в 90-х годах. Этому качественному изменению содействовало появление клиент-серверной технологии, появление новых стандартов кабельных сетей, и появление иерархического управления носителями данных. Основные черты ЦОД сложились к 2000 году, когда очень востребованы стали ЦОД для развёртывания интернет серверов организаций, не имеющих возможностей по их поддержке, а так же обеспечения работы в своих вычислительных центрах разросшихся баз данных различных организаций.

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

Относительно Стандарта TIA-942 необходимо заметить, что в документе подробно проработаны вопросы построения (в основном в форме изложений требований) инженерных подсистем, но если попытаться задаться вопросом выбора конкретного проекта для построения ЦОД, с целью выполнения конкретных задач, сразу появляются вопросы. В Стандарте TIA-942 вводится понятие уровней TIER . Стандарт рассматривает четыре уровня, связанных с разной степенью готовности (терминология TIA-942 ) инфраструктуры оборудования дата-центра. Более высокие уровни соответствуют не только более высокой готовности, но соответственно вызывают повышенные затраты на создание инфраструктуры. Фактически Стандарт TIA-942 разделяет (классифицирует) ЦОДы только по уровню надёжности (иногда пишут что по уровню доступности, но этот термин хотя и близок, но всё же он уже термина «надёжность »).

Классификация ЦОД

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

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

Можно разделить ЦОДы по:

• Назначению или точнее — разделить их на публичные и не публичные (чаще используется термин «корпоративные») ЦОДы;
• Надёжности хранения данных (если быть более точным, то по совокупности надёжности и доступности).

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

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

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

Если говорить о надёжности, то начинать нужно с рассмотрения термина «Наработка на отказ». Вообще-то не факт, что система после выхода из строя при отказе одного из своих элементов перестанет функционировать. Если при выходе со строя (переходе из работоспособного состояния в не работоспособное) одного из элементов системы, система становится неработоспособной, то говорят, что произошёл отказ . Если всё же система осталась работоспособной, то говорят, что произошёл сбой . Момент и частота появления сбоев и отказов описываются методами теории вероятности и в настоящем документе не рассматривается. Единственно о чём нужно помнить что, только анализируя схему надежности системы и имея данные о наработках на отказ в цифровом выражении каждой его составной части можно говорить уровне доступности или работоспособности всей системы. Доля (%) времени в течение года, когда система находится в рабочем состоянии и/или в состоянии простоя (% Uptime and Down time), напрямую связаны между собой. Период простоя (downtime) – это суммарный показатель простоев за год. Этими терминами часто оперируют при обсуждении различных уровней (Tier ) ЦОД. Но цифровое их выражение для разных уровней не корректно , т.к. разброс показателей отказоустойчивости у ЦОД одного уровня может быть велик. В соответствующем месте документа будет показано, что все цифры характеризующие период простоя у различных уровней ЦОД от лукавого и реально опираться на них нельзя. Если говорить кратко, то перечень наиболее характерных черт различных уровней ЦОД можно свести в простую таблицу.

Класс ЦОД (уровень)
Наиболее характерная черта	Базовый уровеньнизкая отказоустойчивость	С резервированием	С возможностью параллельного проведения профилактических работ	Высокая отказоустойчивость
	Подвержен нарушениям нормального хода работы как от плановых, так и от внеплановых действий. Он имеет системы распределения электропитанияи охлаждения компьютеров, но может иметь или не иметь фальшполов, ИБП или генератора. Если даже есть ИБП или генераторы, то они представляют собой одномодульные системы и имеют много одиночных точек отказа. Ежегодно инфраструктуру приходится полностью выключать для выполнения работ по планово-предупредительномуобслуживанию и профилактическому ремонту. Срочная необходимость может потребовать более частых отключений. Ошибки при эксплуатации или самопроизвольные отказы компонентов инфраструктуры объекта будут вызывать перерывы нормального хода работы дата-центра.	Имеются избыточные компоненты, несколько меньше подверженнарушениям нормального хода работы от плановых и от внеплановых действий, чем базовый дата-центр. В данном случае, имеется фальшпол, ИБП и генераторы, однакопроект имеет оценку N+1 (Need plus One), что означает однопоточный путь распределения по всей площади. Техническое обслуживание и ремонт критического пути электроснабжения и других частей инфраструктуры объекта потребует остановки процесса обработки данных.	Позволяет осуществлять любую плановую деятельность инфраструктуры объекта без какого-либо нарушения нормального хода работы технических средств машинного зала. К плановой деятельности относится профилактическое ипрограммируемое техническое обслуживание, ремонт и замена компонентов, добавление или удаление компонентов, влияющих на производительность, тестирование компонентов и систем и пр. Необходимо иметь в наличии достаточную мощность и распределительные возможности, чтобы одновременно нестинагрузку на одном пути и в то же время выполнять ремонт или тестирование на другом пути. Внеплановые действия, например ошибки при эксплуатации или самопроизвольные отказы компонентов инфраструктуры объекта, всё же будут вызывать перерывы нормального хода работы дата-центра. Объекты Уровня III часто проектируют с перспективой наращивания ресурсов до Уровня IV.	Имеет несколько активных путей распределения электропитания иохлаждения. Обеспечивает повышенную степень отказоустойчивости из-за наличия 2-х путей.Обеспечивает несколько путей подвода электропитания ко всемвидам вычислительного и телекоммуникационного оборудования. Требует, чтобы всё компьютерное и телекоммуникационное оборудование имело несколько силовых входов. Оборудование продолжает функционировать, когда один силовых входов отключён.Предусматривается возможность и способность инфраструктуры объекта позволять любую плановую деятельность без нарушения нормального хода работы критически важной нагрузки. Отказоустойчивая функциональность также обеспечивает способность инфраструктуры дата-центра выдержать по крайней мере один внеплановый отказ (или событие) наихудшего свойства без последствий для критически важной нагрузки. Имеет в наличии двух отдельных систем ИБП, в которых каждая система имеет резервирование N+1.
Тип компании-потребителя ресурсов	Средний и малый бизнес. ЦОД для обслуживания внутренних процессов компании	Средний и малый бизнес. ЦОД функционирует в режиме"5Х8"	Компании, обслуживающие как внутренних, так и внешних заказчиков в режиме «7Х24»	Глобальные компании, предоставляющие свои услуги в режиме «24×365»
Тип здания	C соседями		Отдельно стоящее
Количество энерговводов	1		Один активный, второй резервный	Два активных

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

Доступность, % (% UP TIME)	Время простоя в год, час. (DOWN TIME в год), час	Решения, обеспечивающие надёжность
		Без резервирования, генератора, и резервного ввода
		Без резервирования, генератора, но имеется резервный ввод
		С частичным «холодным» резервированием, без генератора но имеется резервный ввод
		С «горячим» резервированием наиболее важных частей и «холодным» практически всего остального, наличие генератора и резервного ввода
		С «горячим» резервированием наиболее важных частей и «холодным» практически всего остального, с генератором в «горячем» резерве и резервном вводе в «горячем» резерве.
99,999	5,26 мин.	Полное резервирование всего, всегда наличие 2-х путей (связей) часто с дублированием.

Запись вида «Без резервирования» не говорит о том, что в случае выхода со строя будет ожидаться заказ и получение от поставщика отказавшего блока. Наличие просчитанных запасов ЗИП и снижение значения показателя MTTR (среднее время ремонта) так же заметно влияет на время простоя.

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

Пример

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

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

Требования стандартов к составным частям ЦОД

Вначале надо определиться требованиями, каких стандартов необходимо руководствоваться, и главное — что будет, если их несколько «нарушить» соответственно в лучшую или худшую сторону. В самом начале главы, я выскажу несколько крамольную мысль. Стандарты необходимо знать, для того, что бы в случае необходимости их можно было при необходимости нарушать. Точнее обоснованно делать некоторые из требований для вашего конкретного ЦОД выше или ниже, чем требования стандарта к выбранному вами классу ЦОД. Написал я эту строку и понял, теперь точно придётся писать название этого «умного» стандарта, требованиям которого необходимо следовать при разработке ЦОД. Но… нет – не всё так просто. Документы, несущие в своём заголовке гордое имя «Стандарт…» на самом деле чаще всего являются обобщённым опытом группы экспертов создавших этот Стандарт. К доступности (% UP TIME) или времени простоя (DOWN TIME ) рекомендации не имеют прямого отношения. Следование требованиям стандартов действительно позволяет улучшить эти показатели, но на какую величину, то это является тайной покрытой мраком. Дело в том, что практически не возможно учесть все факторы, влияющие на уменьшение или увеличение этих показателей и тем более невозможно получить данные на всю, используемую конкретно вами аппаратуру вашего ЦОД. Что же делать? В первую очередь, выстроив по приоритетам требования к создаваемому вами ЦОД попытаться принять за основу один из стандартов и в дальнейшем следовать его требованиям с возможной точностью.

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

В июне 2010 года корпорация Building Industry Consulting Service International Inc. (BICSI) опубликовала новый стандарт 002-2010 : Data Center Design and Implementation Best Practices. Этот стандарт BSCI 002-2010 отражает рост сложности обустройства вычислительных центров и потребность компаний и организаций в понимании требований к энергетике, механическим нагрузкам и телекоммуникациям при проектировании инфраструктуры ВЦ.

Каким же стандартом лучше пользоваться? В чем их различия? Как же тогда сертифицироваться? Ведь существуют и стандарты от других организаций. Например, главным отличием при сертификации по стандартам Uptime Institute (Институт бесперебойных процессов) является то, что сертифицированные специалисты этой организации должны на месте убедиться в реализации требований, изложенных в своих стандартах. В середине 2010 года Uptime Institute выпустил еще один стандарт “Operational Sustainability (Операционной устойчивости)” регламентирующий и службы эксплуатации. Именно требований к службе эксплуатации не хватало в TIA -942 . И хотя совместно выполняя требования Стандарта TIA -942 и стандарта Operational Sustainability можно уже достаточно точно сформулировать требования к ЦОД, но на практике строители новых вычислительных центров чаще ссылаются на стандарт TIA-942. Дело в том, что каждый из стандартов составлялся различной организацией и во многих деталях отличаются друг от друга. Тем более что, по мнению специалистов Uptime Institute, их порядок разделения на уровни доступности никак функционально не связан с уровнями TIA-942, они оценивают способность вычислительных центров поддерживать работоспособность в условиях отказов и аварий. Чтобы избежать путаницы специалисты Uptime Institute предлагают обозначать уровни доступности в их толковании римскими цифрами I, II, III и IV. Достаточно сложно и сертифицировать ЦОД. Если обратиться к сайту Uptime Institute (сайт http://uptimeinstitute.com) то на конец мая 2012 года реально обеспечивает IV Уровень (т.е. не только документация и созданное здание с техническими средствами в нём, но и уровень эксплуатации) только 1 центр, сертификация построенного объекта на IV Tier проведена для 6 ЦОДов. Сертификация документации для построения ЦОД IV Tier получена для 22 объектов. Российских ЦОД среди Tier IV на настоящий момент нет. ЦОДов уровня III так же не очень много. Обеспечивают полное выполнение требований для III Уровня по «Операционной устойчивости» всего лишь 4 ЦОДа. Российских среди них нет . Документация и помещение соответствует Tier III у 5 российских ЦОД (4- Design Documents и 1 Constructed Facility).

В течение 2012 года будет опубликован Стандарт TIA-942-A включивший в себя изменения и дополнения следующих версий TIA-942-1 и TIA-942-2. К сожалению, новая версия стандарта сильно видоизменилась. Новый стандарт TIA-942-A будет касаться только темы кабельных систем и уже не будет таким всеобъемлющим, какой был стандарт TIA-942. Т.е. в основном он будет регламентировать только построение кабельных систем . Раздел об энергетической эффективности, скорее всего, будет касаться этой темы только с точки зрения кабельной системы и использования «зеленой» среды передачи данных – оптоволокна.

Ниже приведен перечень основных изменений, включенных в текущий проект TIA-942-A (согласно предварительным заявлением разработчика). Эта информация выделена курсивом.

TIA-942-A приведен в соответствие с серией стандартов TIA-568-C в отношении топологии, терминологии и классификаций среды, представленных в стандарте 568-C.0, а также спецификаций компонентов, представленных в TIA-568-C.2 и C.3;

• Приложения, TIA-942-1 и TIA-942-2, включены в стандарт TIA-942-A;
• Информация по заземлению была перемещена из стандарта TIA-942-A в стандарт TIA-607-B;
• Информация по администрированию будет перемещена в стандарт TIA-606-B;
• Большая часть информации, касающаяся телекоммуникационных шкафов и серверных стоек, разделения силовых и телекоммуникационных кабельных систем, будет перемещена в стандарт TIA-569-C;
• Информация по внешней кабельной разводке перемещена в TIA-758-B;
• Отменено ограничение длины горизонтальных оптоволоконных кабельных систем 100 метрами.
• Кабели Category 3 и Category 5e больше не должны применяться в горизонтальных кабельных системах. В рабочей версии стандарта разрешено применение сбалансированных витых пар типа Category 6 и Category 6A в горизонтальных кабельных системах. Category 6 и Category 6A можно будет использовать и в магистральных кабельных системах;
• Одобрено применение в горизонтальных и магистральных кабельных системах многомодовых оптоволоконных кабелей типа OM3 и OM4 (многомодовый оптическое волокно с диаметром сердечника/оболочки 50/125 мкм, оптимизированное для работы с источниками света на основе лазеров на длине волны 850 нм). Кабели типа OM1 и OM2 больше не разрешаются для использования;
• Для соединения одного или двух волоконных кабелей должны использоваться волоконно-оптические разъемы типа LC и для многоволоконных разъемы типа MPO;
• В топологию ЦОД включена промежуточная распределительная зона (IDA) ;
• В стандарт добавлен раздел по энергетической эффективности;
• Добавлены термины «аппаратная розетка» (EO - equipment outlet) и «внешний сетевой интерфейс» (ENI - external network interface), заимствованные из международного стандарта ISO/IEC 24764.

Стандарт “Operational Sustainability (Операционной устойчивости)” всего лишь дополняет TIA-942 особенно в части эксплуатации ЦОД.

Стандарт «Operational Sustainability», описывает требования, позволяющие гарантировать устойчивость центров обработки данных, а также минимизировать связанные с этим риски. Как известно, предшествующий широко распространенный стандарт «Tier Standard: Topology» регламентировал технические параметры ЦОД, необходимые для достижения определенного уровня надежности. Особенность нового стандарта в том, что он учитывает человеческий фактор в устойчивой работе ЦОД. И это имеет большое значение, так как процент ошибок в работе, связанных с этим фактором достигает 70% , из них чуть более 40% связаны с ошибками управляющих службы эксплуатации. Чтобы свести к минимуму эти ошибки необходимо вести целенаправленную работу с персоналом, повышать его квалификацию, проводить мероприятия по удержанию квалифицированных кадров.

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

Система оценки уровней устойчивости и основные разделы стандарта BICSI 002 2010 . Как утверждают в ассоциации, разработчики стандарта ставили перед собой цель обеспечить проектирование и строительство центров обработки данных с учетом долгосрочной перспективы их эксплуатации. Основные разделы документа:

• Планировка ЦОД
• Выбор площадки
• Архитектурные решения
• Строительные конструкции
• Электротехнические системы
• Механические системы
• Пожаротушение
• Безопасность
• Системы автоматизации здания
• Телекоммуникации
• Информационные технологии
• Ввод в действие
• Эксплуатация и техническое обслуживание
• Процесс проектирования
• Надежность

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

Uptime Institute в своё время определил четыре уровня, связанных с разной степенью готовности инфраструктуры оборудования дата-центра (ЦОД). На самом деле хоть они связаны с уровнем доступности, но наверно более правильно говорить об уровнях TIER, хотя сам термин «TIER» и переводится как — «Уровень». Выше я, не зря раскрывая понятие «Уровень», не приводил цифровые характеристики уровня доступности ЦОД. Цифровые выражения были получены только из анализа реализованных проектов. Привожу некоторые данные из документа, разработанного Институтом проблем работоспособности (The Uptime Institute) в изданном ими бюллетене «Классификация уровней по отраслевому стандарту, определяющему качество работы инфраструктуры объекта» (Industry Standard Tier Classifications Define Site Infrastructure Performance).

Параметр / Класс ЦОД (уровень)	1 Низкая отказоустойчивость			4 Высокая отказоустойчивость
Тип здания	C соседями	С соседями	Отдельно стоящее	Отдельно стоящее
Количество энерговводов	1	1	Один активный, второй резервный	Два активных
Первоначальная мощность Вт на м 2	215 - 323	430 - 537	430 — 645	537 - 860
Максимальная мощность Вт на м 2	215 - 323	430 - 537	1075- 1615	1615+
Бесперебойное кондиционирование	Нет	Нет	Возможно	Есть
Высота фальшпола в метрах	0.3	0.45	0.75 - 0.9	0.75 - 0.9
415	488	732	732+ (по страндарту 2005г 1000+)
Общая длительность отказов за год	28,8 ч	22 ч	1,6 ч	0,4 ч
Доступность ЦОД	99,671 %	99,749 %	99,982 %	99,995%
Срок ввода в эксплуатацию (мес.)	3	3 - 6	15 - 20	15 - 20
Типовой проект впервые реализован в	1965 г.	1970 г.	1985 г.	1995 г.

Общий вывод по использованию стандартов:

• Основополагающим стоит считать использование стандарта TIA — 942 с последними дополнениями (например с стандартом“Operational Sustainability (Операционной устойчивости)”;
• Новый стандарт TIA-942-A (одобрен 24 апреля 2012 года) касается только темы кабельных систем и уже не будет таким всеобъемлющим, какой был стандарт TIA-942;
• При построении ЦОД следует пользоваться не только стандартами, но и здравым смыслом, позволяющим существенно сэкономить, не ухудшая наиболее востребованные его качества;
• Сертификация более необходима коммерческому ЦОД, а ЦОД организации может этим не заниматься. Конечно если ЦОД всё, же создавался на основе стандартов, то все отступления от рекомендаций должны быть обоснованными;
• Прочитать, и, главное, понять какой Стандарт взять за основу и на какие требования его необходимо будет сделать упор в будущей разработке, нельзя считать, что работу со стандартами вы закончили. Перед тем, как переходить к следующему этапу, необходимо в обязательном порядке перечитать старые, хорошие, правда, в настоящий момент в основном забытые ГОСТы – серии 34. И ничего, что они уже много лет не обновлялись, но там есть подробное рассмотрение предпроектных стадий. В них нет находящихся на слуху слов «бизнес-процессы», «процессорный подход», но есть понятие «информационная модель» вполне корректно их заменяющее. Поэтому особенно на стадии ТЗ эти документы, вам помогут. Конечно, подходить нужно творчески и не следовать буквально всем рекомендациям, но внимательно прочитать их необходимо.

Порядок построения ЦОД

Как не странно наибольший вклад в успешность или не успешность будущего проекта вносят начальные стадии. Вообще-то по мировой статистике в IT индустрии успешным становится только -один проект из 3-х . Если подойти более жестко, и оценивать успешность проекта как:

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

Всё будет ещё хуже. Наверно под определение «успешный» попадёт не более 20% проектов.

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

Если практически над каждым проектом довлеет вероятность провала, то, как быть с бодрыми заявлениями о десятках успешных проектов у множества фирм? Для начала нужно сразу поставить всё на свои места, определив термин «Проект ».

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

Дело в том, что существуют 2 подхода к выполнению работ и их оценке. Это подход Разработчика и подход Заказчика.

Разработчик, старается при реализации задания от Заказчика:

1. Постараться применить уже реализованное ранее Разработчиком решение;
2. В случае невозможности этого, пытается применить апробированное другими фирмами решение (чаще всего решение рекомендованное производителем оборудования или ПО);
3. Попытаться понизить требования Заказчика и по возможности свести их к тем же типовым решениям;
4. В случае неудачи предыдущего пункта Разработчик пытается увеличить время выполнения работ или сделать более мягкими требования по приёмке своей работы;
5. Попытаться на этапе приёмки сконцентрироваться на сильных сторонах выполненного проекта и скрыть свои ошибки и не доработки;
6. Попытаться побыстрее сдать проект и начать новый, или, в крайнем случае, обеспечить себе аутсорсинг.

Подход Заказчика в первую очередь характеризуется:

1. Попыткой получить, как можно больше от Разработчика и за меньшие деньги;
2. Попытками в процессе разработки проекта изменить или уточнить пункты первоначального ТЗ;
3. Во время приёмки попытаться получить как можно больше документации, и найти ошибки разработчика;
4. Постараться за счёт Заказчика не только исправить выявленные в процессе приёмки ошибки, но и внести очередные изменения в проект.

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

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

Поэтому одной из основных ошибок у Заказчика является устранение от работы специалистов участвующих написании ТЗ и эпизодическое участие в эскизном и рабочем проекте только узких специалистов при решении частных вопросов . Специалисты, участвующие в работе по реализации крупных проектов должны у Заказчика находиться в отделе комплексных работ . И именно они должны привлекать в случае необходимости всех специалистов по отдельным направлениям. В этом случае, специалисты комплексного отдела будут в курсе всех «тонких» мест проекта и сам проект получит большие шансы на успешное завершение. Так же специалисты комплексного отдела должны участвовать в приёмке работы Заказчика, т.к. постоянно следя за ходом работ, они будут в курсе всех его проблем.

Замечание по поводу работ относимых к компетенции комплексного отдела .

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

Если мы обратимся к опыту реализации больших проектов, то заметим, что большие организации (например, банки), или те, специализация которых связана с IT, сами руководят проектами по созданию своих ЦОД.

Подведение итогов по этапам обоснования и составления ТЗ

Из изложенного выше можно сделать вывод:

1. Говоря о создании ЦОД нужно в первую очередь расставить приоритет требований которым он должен будет удовлетворять.
2. После расстановки приоритетов необходимо взять за основу один из стандартов, требованиям которого вы будете следовать. (Я бы советовал использовать TIA-942 , но нельзя забывать, что он не рассматривает вопросов эксплуатации.)
3. Все отступления от стандарта в лучшую или худшую сторону должны быть обоснованны.
4. Для составления ТЗ необходимо задействовать свой отдел комплексных работ (или создать его), т.к. с вашей стороны нужны люди персонально заинтересованные в успешной реализации проекта и которые будут курировать все работы с Исполнителем.

Если вы заметили, что в этой части я рассмотрел вопросы до начала написания ТЗ, подчеркнул, что писать ТЗ нужно обязательно с Исполнителем, а о выборе исполнителя ничего не написал. Дело в том, что выбор Исполнителя отдельная и ответственная задача. И если очень кратко об этом упомянуть, то обычно выбор разбивается на 2 этапа:

1. Определение круга претендентов для решения задачи построения вашего конкретного ЦОД.
2. Анализ представленного фирмами материала и уточнение вопросов при личных встречах.

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

»

- У вас есть ЦОД?
- Да, строим на 100 стоек.
- А мы строим на 200.
- А мы на 400 с независимой газовой электростанцией.
- А мы на 500 с водяным охлаждением и возможностью отводить до 10 кВт тепла с одной стойки.
- А мы наблюдаем за рынком и удивляемся.

Ситуация на московском (да и российском в целом) рынке ЦОД еще два года назад выглядела плачевно. Тотальная нехватка дата-центров как таковых и мест в уже существовавших центрах привела к тому, что стойка на 3-4 кВт, стоившая в 2004-2005 гг. около 700 у.е., в 2007-м стала стоить 1500-2000 у.е. Стараясь удовлетворить растущий спрос, многие операторы и системные интеграторы организовали «стройки века» с целью создания самых лучших и самых больших ЦОД. Эти прекрасные стремления привели к тому, что на текущий момент в Москве есть около 10 дата-центров в стадии открытия и первичного заполнения, и еще несколько находится в проекте. Компании «Теленет», i-Teco, Dataline, «Хостеров», «Агава», «Мастерхост», Oversun, «Синтерра» и целый ряд других открыли собственные дата-центры на рубеже 2008 и 2009 гг.

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

Инвестиционные проекты, запущенные в разгар кризиса, тоже не могут похвастаться стабильным притоком клиентов. Сплошь и рядом стоимость за стойку, заложенная в бизнес-плане на уровне 2000 у.е., в нынешних экономических условиях снижается до 1500-1400 у.е., на годы откладывая выход проекта на самоокупаемость.

Остались нереализованными несколько грандиозных проектов строительства дата-центров на тысячи стоек с газовыми электростанциями за МКАД. Один из таких проектов, в частности, был «похоронен» оператором фиксированной связи (в связи с поглощением компании более крупным игроком).

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

Однако не все так плохо: даже в условиях кризиса, при соблюдении определенных условий, можно и нужно создавать собственный ЦОД. Главное - понять ряд нюансов.

Что заставляет компанию создавать собственный ЦОД

Мотив один - безопасность бизнеса и минимизация рисков. Риски же таковы. Во-первых, класс коммерческих ЦОД в Москве соответствует 1-2 уровню, что означает перманентные проблемы с электропитанием и охлаждением. Во-вторых, коммерческие ЦОД категорически не согласны покрывать убытки от простоя и недополученную выгоду. Уточните максимальный размер штрафа или неустойки, на который вы можете рассчитывать в случае простоя, - он, как правило, не превышает 1/30 от арендной платы за день простоя.

И в третьих, вы не в состоянии контролировать реальное положение дел в коммерческом ЦОД:

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

Экономика ЦОД

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

Уровень 1	От 620 т.р.
Уровень 2	От 810 т.р.
Уровень 3	От 1300 т.р
Уровень 4	От 1800 т.р.

Стоимость эксплуатации ЦОД зависит от множества факторов. Перечислим основные.

1. Стоимость электричества = количество потребляемой электроэнергии + 30% на отвод тепла + потери при передаче и преобразовании (от 2 до 8%). И это при условии выполнения всех мер по снижению затрат - таких, как сокращение потерь и пропорциональное охлаждение (что в некоторых случаях, увы, невозможно).
2. Стоимость аренды помещения - от 10 тыс. рублей за кв. м.
3. Стоимость обслуживания систем кондиционирования - приблизительно 15-20% от стоимости системы кондиционирования в год.
4. Стоимость обслуживания энергосистем (ИБП, ДГУ) - от 5 до 9% от стоимости.
5. Аренда каналов связи.
6. ФОТ службы эксплуатации.

Из чего состоит ЦОД

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

В настоящий момент широко используется международная классификация уровней (от 1 до 4) готовности (надежности) ЦОД ()см. таблицу). Каждый уровень предполагает определенную степень доступности сервисов ЦОД, которая обеспечивается различными подходами к резервированию питания, охлаждения и канальной инфраструктуры. Самый низкий (первый) уровень предполагает доступность 99,671% времени в год (или возможность 28 ч простоя), а самый высокий (четвертый) уровень - доступность 99,995%, т.е. не более 25 мин простоя в год.

Параметры уровней надежности ЦОД

	Уровень 1	Уровень 2	Уровень 3	Уровень 4
Пути охлаждения и ввода электричества	Один	Один	Один активный и один резервный	Два активных
Резервирование компонентов	N	N+1	N+1	2*(N+1)
Деление на несколько автономных блоков	Нет	Нет	Нет	Да
Возможность горячей замены	Нет	Нет	Да	Да
Здание	Часть или этаж	Часть или этаж	Отдельно стоящее	Отдельно стоящее
Персонал	Нет	Не менее одного инженера в смене	Не менее двух инженеров в смене	Более двух инженеров, 24-часовое дежурство
100	100	90	90
Вспомогательные площади, %	20	30	80-90	100+
Высота фальш- пола, см	40	60	100-120	600	800	1200	1200
Электричество	208-480 В	208-480 В	12-15 кВ	12-15 кВ
Число точек отказа	Много + ошибки оператора	Много + ошибки оператора	Мало + ошибки оператора	Нет + ошибки оператора
Допустимое время простоя в год, ч	28,8	22	1,6	0,4
Время на создание инфраструктуры, мес.	3	3-6	15-20	15-20
Год создания первого ЦОД подобного класса	1965	1975	1980	1995

Данная классификация по уровням была предложена Кеном Бриллом (Ken Brill) еще в 1990-х гг. Считается, что первый ЦОД самого высокого уровня готовности был построен в 1995 г. компанией IBM для UPS в рамках проекта Windward.

В США и Европе существует определенный набор требований и стандартов, регламентирующих постройку ЦОД. Например, американский стандарт TIA-942 и его европейский аналог -EN 50173−5 фиксируют следующие требования:

• к месту расположения дата-центра и его структуре;
• к кабельной инфраструктуре;
• к надежности, специфицированные по уровням инфраструктуры;
• к внешней среде.

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

Итак, остановимся на трех «китах» строительства ЦОД, которые являются наиболее значимыми.

Питание

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

Основные ошибки обычно допускают еще на этапе проектирования систем электропитания ЦОД. Они (в перспективе) могут вызвать отказ системы электроснабжения по следующим причинам:

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

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

• Уровень 1 — достаточно обеспечить защиту от скачков тока и стабилизацию напряжения, это решается установкой фильтров (без установки ИБП);
• Уровень 2 — требует установки ИБП с байпасом с резервированием N+1;
• Уровень 3 — необходимы параллельно работающие ИБП, с резервированием N+1;
• Уровень 4 — системы ИБП, с резервированием 2 (N+1).

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

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

Очень важно также проследить, как будет вестись учет потребления электричества.

Охлаждение

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

На качество отвода тепла влияют следующие моменты.

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

Высота потолков и фальшпола. Здесь все очень просто: если высотой фальшпола дело не испортишь, то слишком высокие потолки ведут к застою горячего воздуха (следовательно, его надо отводить дополнительными средствами), а слишком низкие потолки затрудняют движение горячего воздуха к кондиционеру. В случае же низкого фальшпола (> 500 мм) резко падает эффективность охлаждения.

Показатели температуры и влажности воздуха в ЦОД. Как правило, для нормальной работы оборудования требуется соблюдать температурный режим в диапазоне 18-25 градусов Цельсия и относительную влажность воздуха от 45 до 60%. В этом случае вы обезопасите свое оборудование от остановки по причине переохлаждения, выхода из строя в случае выпадения конденсата при высокой влажности, статического электричества (в случае с низкой влажностью) или из-за перегрева.

Каналы связи

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

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

Собственный ЦОД на «раз-два-три»

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

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

Стоимость собственно BlackBox — около полумиллиона долларов. И тут надо отметить, что BlackBox - это полностью сконфигурированный (однако с возможностью кастомизации) виртуализационный центр обработки данных, размещенный в стандартном транспортном контейнере.

Две компании уже получили этот контейнер для предварительного тестирования. Это Linear Accelerator Center (Стэнфорд, США) и... российская компания «Мобильные ТелеСистемы». Самое интересное, что МТС запустила BlackBox быстрее, чем американцы.

В целом BlackBox производит впечатление очень хорошо продуманной и надежной конструкции, хотя, конечно, стоит упомянуть и ее недостатки.

Необходим внешний источник энергии минимум в 300 Вт. Здесь мы упираемся в строительство или реконструкцию ТП, монтаж ГРЩ, прокладку кабельной трассы. Это не так просто - проектные работы, согласование и утверждение проекта во всех инстанциях, монтаж оборудования…

ИБП в комплект поставки не входят. Опять упираемся в проектные работы, выбор поставщика, оборудование помещения под монтаж ИБП с климатической установкой (батареи очень капризны к температурному режиму).

Потребуется также покупка и монтаж ДГУ. Без него не решить проблему с резервированием, а это еще один круг согласований и разрешений (средний срок поставки таких агрегатов - от 6 до 8 месяцев).

Охлаждение - необходим внешний источник холодной воды. Придется спроектировать, заказать, дождаться, смонтировать и запустить систему чиллеров с резервированием.

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

Чем больше ЦОД, тем..?

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

Строительство в Дублине конструкции общей площадью 51,09 тыс. кв. м, на территории которой разместятся десятки тысяч серверов, началось в августе 2007 г. и должно завершиться (по прогнозам самой компании) в середине 2009 г.

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

• «Домашний ЦОД» - ЦОД уровня предприятия, которому требуются серьезные вычислительные мощности. Мощность - до 100 кВт, что позволяет разместить в нем до 400 серверов.
• «Коммерческий ЦОД». К этому классу относятся операторские ЦОД, стойки в которых сдаются в аренду. Мощность - до 1500 кВт. Вмещает до 6500 серверов.
• «Интернет-ЦОД» - ЦОД для Интернет-компании. Мощность - от 1,5 МВт, вмещает 6500 серверов и более.

Возьму на себя смелость предположить, что при строительстве ЦОД мощностью более 15 МВт неотвратимо возникнет «эффект масштаба». Ошибка на 1,5-2 кВт в «семейном» ЦОД на 40 кВт, скорее всего, останется незамеченной. Ошибка размером в мегаватт будет фатальной для бизнеса.

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

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

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

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

Где строить?

Считается, что ЦОД должен размещаться в отдельно стоящем здании, как правило, без окон, оснащенном самыми современными системами видеонаблюдения и контроля доступа. К зданию должно быть подведено два независимых электрических ввода (от двух разных подстанций). Если ЦОД имеет несколько этажей, то перекрытия должны выдерживать высокие нагрузки (от 1000 кг на кв. м). Внутренняя часть должна быть разделена на герметичные отсеки с собственным микроклиматом (температурой 18-25 градусов Цельсия и влажностью 45-60%). Охлаждение серверного оборудования должно обеспечиваться с помощью прецизионных систем кондиционирования, а резервирование питания - как устройствами бесперебойного питания, так и дизель-генераторными установками, которые обычно находятся рядом со зданием и обеспечивают в случае аварии функционирование всех электрических систем ЦОД.

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

Сетевая инфраструктура также должна предусматривать максимальное резервирование всех критически важных узлов.

Как экономить?

Можно начать экономить с качества питания в ЦОД и закончить экономией на отделочных материалах. Но если вы строите такой «бюджетный» ЦОД, это выглядит по крайней мере странно. Какой смысл инвестировать в рискованный проект и ставить под угрозу ядро своего бизнеса?! Одним словом, экономия требует очень взвешенного подхода.

Тем не менее есть несколько весьма затратных статей бюджета, которые оптимизировать не только можно, но и нужно.

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

• стоимость может отличаться на порядок;
• нагрузка на перекрытия выше в среднем на 25-30%;
• охлаждающая способность ниже (даже с учетом установки перфорированных дверей).

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

Ни в коем случае не стройте «медный» кросс в одном месте - разоритесь на кабеле. Намного дешевле и грамотней ставить рядом с каждым рядом телекоммуникационную стойку и разводить от нее на каждую стойку по 1-2 патч-панели медью. Если необходимо будет подключить стойку, то пробросить оптический патч-корд до нужного ряда - минутное дело. При этом еще и не понадобятся серьезные инвестиции на начальном этапе; наконец, попутно будет обеспечена необходимая маштабируемость.

3. Питание. Да, не поверите, но в питании ЦОД самое важное - КПД. Тщательно выбирайте электрооборудование и системы бесперебойного питания! От 5 до 12% стоимости владения ЦОД можно сэкономить на минимизации потерь, таких как потери на преобразовании (2-8%) в ИБП (у старых поколений ИБП КПД ниже) и потери при сглаживании гармонических искажений фильтром гармоник (4–8%). Уменьшить потери можно за счет установки «компенсаторов реактивной мощности» и за счет сокращения длины силовой кабельной трассы.

Заключение

Какие же выводы можно сделать? Как выбрать из всего многообразия то решение, которое подходит именно вам? Это, безусловно, сложный и нетривиальный вопрос. Повторимся: в каждом конкретном случае необходимо тщательно взвешивать все «за» и «против», избегая бессмысленных компромиссов, - учитесь правильно оценивать собственные риски.

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

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

Одним словом, если вы планировали строить свой собственный дата-центр, то сейчас, на наш взгляд, самое время.