Нормативная документация

Начинаем проектировать ЦОД. 15 основных правил и практические аспекты выбора решений

10 октября 2013 г. | Категория: Проектирование ЦОД

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

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

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

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

Кратко сформулируем данные правила:

1. Делайте технологический раздел.

2. Соблюдайте отечествен­ные стандарты.

3. Сомневайтесь во всем.

4. Решайте от задач.

5. Делайте сбалансированные решения.

6. Избегайте связанных решений.

7. Проектируйте как можно проще.

8. Применяйте унификацию.

9. Создавайте ЦОД добротным.

10. Безопасность людей первична.

11. Не забывайте о мелочах.

12. Рассматривайте худ­­ший случай.

13. Думайте об интересах всех сторон.

14. Озвучивайте риски клиенту.

15. Проектируйте на перспективу.

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

ПРАВИЛО № 1

Делайте технологический раздел

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

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

Приведем аналогию. При разработке проектной документации на специализированные объекты, будь то производственный цех или, например, ресторан, во главу угла ставится бизнес-задача, которая формулируется технологом в составе раздела ТХ. Данная марка, наряду с архитектурными решениями, являет­ся отправной для прочих разделов проектной документации.

Такой же подход целесообразно спроецировать на задачу создания ЦОД.

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

В технологическом разделе должны быть отражены следующие воп­росы:

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

Основой при создании технологического раздела являются планировочные решения ЦОД, или Room Layout (в англоязычной терминологии).

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

• ЦОД представляется как единый объект, конкретные технические решения принимаются в канве единой логики и с учетом интересов всех участников проекта;

• имеется техническое описание для поддержки принятия экономических решений;

• раздел способствует сбалансированности проекта в целом;

• раздел ограничивает максимальные потребности в ресурсах;

• ключевые топологии и схемы утверждаются для дальнейшей разработки;

• раздел отвечает на вопрос, почему те или иные решения были приняты;

• клиент имеет формальное представление о том, что он получит.

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

• эскиз или концепция;

• стадия «Проект» или «Проектная документация» (ранее — технико-экономическое обоснование);

• рабочая документация.

Делать или не делать все шаги, определение полноты каждого раздела или их объединение — все это зависит от особенностей и масштаба проекта, желания клиента, культуры проектирования исполнителя. Как опи­­сывать и формировать раздел, названный здесь «технологическим», личное дело каждого специалиста. Тем не менее при разработке документации должен быть найден формат документа, который отразит все вышеизложенные вопросы.

ПРАВИЛО № 2

Соблюдайте отечест­вен­ные стандарты

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

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

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

• прописывать стандарты или не­об­хо­димые требования в до­го­во­рах и технических заданиях;

• при сравнении требований использовать наиболее жесткие;

• разрабатывать собственные стан­дарты;

• строго следовать обязательным го­су­дарственным стандартам (ар­хи­тектура и конструктив, пожарная безопасность, экология, электроснабжение).

ПРАВИЛО № 3

Сомневайтесь во всем

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

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

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

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

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

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

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

• Учет технических, юридических, экономических и прочих последствий внедрения того или иного решения.

ПРАВИЛО № 4. Решайте от задач

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

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

Для иллюстрации можно сформулировать два тезиса.

Мощнее — не значит лучше. Сораз­мерность задачам.

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

Типичный пример: некритичный к времени простоя ЦОД, задачи которого по уровню надежности вполне соответствуют Tier I или Tier II, на всякий случай позиционируют как Tier III или Tier IV. По результатам проектирования и определения стоимостей бюджет и бизнес-план начинает трещать по швам. Начинается уменьшение требований, например, по части якобы некритичных систем. Проект перекраивается на ходу, становится несбалансированным, упрощается настолько, что уже не соответствует никакому Tier. Такой ЦОД (или это уже ИТ-помойка) нужен клиенту? Может быть, рынку? В данном случае и проектная команда, и заказчики занимались самообманом.

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

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

Решайте от экономики

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

Следует оценивать затраты как капитальные (CAPEX), так и операционные (OPEX). Обычно они имеют полярные зависимости, и нужно решать задачу по поиску оптимума.

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

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

ПРАВИЛО № 5

Делайте сбалан­сированные решения

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

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

• по макропоказателям;
• по техническим решениям;
• по стоимости решений.

Сбалансированность по макропоказателям

Для анализа ЦОД могут быть применены общераспространенные или определенные самостоятельно коэф­фициенты и показатели.

Каждый из таких показателей хорошо известен и, как правило, фигурирует в описании технических характеристик ЦОД. Здесь можно отметить разнообразные удельные показатели: площадь на шкаф, мощность электроэнергии на шкаф и т. д., а также наиболее популярный на настоящий момент макропоказатель — PUE (или DCiE (DCE, DCPE) — величина, обратная PUE), который по популярности в последнее время вне конкуренции.

Рассмотрим пример. Ограничения, накладываемые при планировании/расчете PUE. Для получения «хоро­ших» (близких к единице) значений PUE очевидно нужно повысить потребляемую оборудованием мощность и снизить мощность, которую расходуют остальные потребители. Однако для полноты анализа нельзя оперировать только двумя максимальными цифрами — требуется рассмат­ривать систему в целом, проводить комплексный анализ при разных режимах работы, при неполной загрузке и т. д. Иначе можно получить «виртуаль­ное» приемлемое значение PUE, которое на практике будет далеко от идеа­ла. А практического результата при этом придется ждать целый год.

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

Datacenter Productivity = Useful Work/Total Facility Power

Cбалансированность по техническим решениям

Разные системы оценки надежнос­­ти (Tier I–IV, Tier 1–4, Critically Levels, STARS, прочие клоны и вариа­ции) так или иначе соответствуют друг другу и никаким образом не га­рантируют определенное время простоя.

Тогда почему же они так популярны, особенно Tier, в России?

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

Какой уровень технических реше­ний следует выбирать? Это зависит от уровня и важности задач. Tier III или Tier IV, к которым стремятся «на всякий случай», оправдан, только когда речь идет о жизнях людей и системах жизнеобеспечения, системообразующих государственных и финансовых институтах, объективно критических сервисах.

Сбалансированность по стоимости решений

Стоимость решения является не только экономическим параметром — это и один из важнейших параметров оценки качества решения.

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

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

• выработать решение, опираясь на выбранный уровень;

• применить и воспользоваться идео­­логией оптимизированного по производительности ЦОД (POD), которая продвигается некоторыми организациями;

• максимально использовать решения от одного производителя или от совместных альянсов.

ПРАВИЛО № 6

Избегайте связанных решений

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

Основной смысл Правила № 6 — сделать решения гибкими и масштабируемыми, заложить на этапе проектирования несколько степеней свободы.

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

Избегайте технически связанных решений

При проектировании следует задать запас по вариативным параметрам, но не на развитие, как у нас часто принято обосновывать, а на балансировку ЦОД и адаптацию под конкретные потребности. В практическом плане величины запаса должны лежать в пределах 10–25 %.

В качестве примера можно привести популярную в последнее время идею ЦОД переменной плотности (Density Zone). Здесь формируются три уровня загруженности ЦОД по производительности ИТ-оборудования (например, в рамках модуля):

• зона высокой плотности;
• зона средней плотности;
• зона низкой плотности.

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

Избегайте экономически связанных решений

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

Примером реализации гибкого с экономической точки зрения ЦОД является дата-центр переменного уровня (Multi-Tier DC). В рамках одного объекта формируются модули ЦОД — каждый со своей привязкой к уровню Tier. Происходит диверсификация ЦОД под разные ИТ-задачи и сервисы со своим уровнем ценовой политики.

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

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

ПРАВИЛО № 7

Проектируйте как можно проще

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

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

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

ПРАВИЛО № 8

Применяйте унификацию

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

Унификация ЦОД может быть реализована на любом уровне — от одинаковых болтов для крепления оборудования в шкафах до законченных модульных или контейнерных решений под ключ.

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

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

ПРАВИЛО № 9

Создавайте ЦОД добротным

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

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

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

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

ПРАВИЛО № 10

Безопасность людей первична

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

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

Интересно выделить два случая.

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

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

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

ПРАВИЛО № 11

Не забывайте о мелочах

Как известно, есть достаточное коли­чество пословиц и поговорок о важнос­ти незначительных на первый взгляд вещей. Например, «дьявол кроет­ся в мелочах» или «мал золотник, да дорог».

Что происходит с системами или компонентами ЦОД, польза и нужность которых не совсем очевидна? Исполнитель начинает про них забывать, а клиент — экономить!

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

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

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

ПРАВИЛО № 12

Рассматривайте худший случай

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

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

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

ПРАВИЛО № 13

Думайте об интересах всех сторон

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

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

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

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

В проекте обязательно нужно учитывать ЗИП, формировать его состав.

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

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

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

ПРАВИЛО № 14

Озвучивайте риски клиенту

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

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

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

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

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

ПРАВИЛО № 15

Проектируйте на перспективу

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

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

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

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

Заключение

У читателя может создаться впечатление о консервативном характере приведенных правил. Наверноe, это не совсем так — приме­нять инновационные решения можно и нужно.

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

Игорь Дорофеев, ООО «АйКорд», генеральный директор

Источник: журнал ЦОДы.РФ, февраль 2013, № 02, май 2013, № 03

Теги: проектирование, проект