07.08.2023
Константин Нагорный
Главный инженер ЦОД Linx
3 мин

Топ-5 ошибок проектировщиков ЦОД

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

Завышенные требования к системе внешнего электроснабжения ЦОД

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

Uptime Institute (UI) в статье о мифах вокруг системы сертификации Tier четко разъясняет, что: «Согласно стандарту Tier Standard: Topology, единственным надежным источником электропитания для ЦОД является генераторная установка. Это связано с тем, что электроснабжение подвержено незапланированному отключению даже в местах с надежными электросетями. Число внешних фидеров, подстанций и электросетей, к которым подключен ЦОД, не определяет его уровень Tier и никак не влияет на него»*.

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

Из разъяснений UI следует, что для ЦОД любого уровня достаточно подключения даже по третьей категории надежности ЭС, то есть к одному источнику электроснабжения.

К этому выводу можно было прийти и без UI, просто внимательно прочитав определения категорий электроснабжения, приведенные в Правилах устройства электроустановок (ПУЭ).

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

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

В приведенных пунктах из ПУЭ отметим важное:

  1. В обоих случаях источники должны быть «взаиморезервирующие», а это те источники, на которых, согласно ПУЭ п. 1.2.10, «сохраняется напряжение в послеаварийном режиме в регламентированных пределах при исчезновении его на другом или других источниках питания», то есть резерв источников должен быть 2N. Не следует путать это резервирование с двумя линиями от одной подстанции (резерв линий 2N). Наличие резерва 2N по линиям от одного источника, например от ДГУ, вполне логично, так как позволяет обслуживать одну линию без выведения всего комплекса ДГУ из работы. Наличие двух линий от городской подстанции тоже имеет смысл, так как позволит вам не переходить на ДГУ при обслуживании одной из этих линий. Но две линии от одного источника – это все равно третья категория надежности, так как имеется только один источник.
  2. Время пропадания электричества равно времени ручного переключения для второй категории и времени автоматического переключения для первой. При этом в обоих случаях пропадание допустимо и время этого переключения не нормировано, хотя скорее всего предполагается, что время ручного переключения исчисляется в минутах (а, может, и часах), а автоматического в секундах, если другое явно не указано в договоре на электроснабжение. Теперь представьте, что электроснабжающая организация согласится добавить себе в договор дополнительные временные обременения и, естественно, штрафы за их неисполнение, а они равны штрафам, которые клиенты выставят ЦОД. Считаете такое развитие событий вероятным?

В результате мы имеем:

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

Проектировщикам следует объяснять эти риски заказчику и со своей стороны запроектировать для ЦОД надежный комплекс ДГУ с резервом не менее N+1. Это рекомендовано и в процитированной выше статье UI: «В то же время генератор должен быть правильно подобран и сконфигурирован таким образом, чтобы питать критическую нагрузку без ограничений по времени работы. Поэтому необходимо уделять особое внимание номинальной мощности генераторной установки и распределению этой мощности»*.

В результате данного подхода именно совокупность третьей категории ЭС от города, третьей категории от ДГУ, автоматики переключения ГРЩ и ИБП (с АКБ) обеспечит требуемую первую особую категорию электроснабжения ИТ-нагрузки ЦОДкак это описано в п.1.2.19 ПУЭ: «Для электроснабжения особой группы электроприемников первой категории должно предусматриваться дополнительное питание от третьего независимого взаимно резервирующего источника питания. В качестве третьего независимого источника питания для особой группы электроприемников и в качестве второго независимого источника питания для остальных электроприемников первой категории могут быть использованы местные электростанции, электростанции энергосистем (в частности, шины генераторного напряжения), предназначенные для этих целей агрегаты бесперебойного питания, аккумуляторные батареи и т.п.».

*Перевод дан по https://dcforum.ru/news/sistema‑klassifikatsii‑tier‑mify‑i-zabluzhdeniya

Игнорирование этапности заполнения ЦОД оборудованием клиентов

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

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

Стремление снизить сроки окупаемости проекта за счет нестандартных технических решений

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

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

Ошибки при планировании холодных коридоров

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

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

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

Второй частой ошибкой является применение холодных коридоров с так называемыми «падающими» крышами. Вот пример таких крыш:

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

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

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

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

Ошибки при проектировании входной зоны в ЦОД

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

  • мы ни разу не видели ни одного КПП на въезде на территорию ЦОД. Шлагбаумы видели, а вот отдельных «домиков» с постом охраны, турникетом и тесным тамбуром, являющимися у нас неотъемлемой «приставкой» к шлагбауму, там не было;
  • входные зоны (зона ресепшн) всех ЦОД представляли собой открытые пространства, в которые можно попасть сразу с улицы. В них располагаются переговорные, кофейные станции, туалеты и большая зона ожидания/ отдыха. Чтобы попасть оттуда в зону ЦОД, требуется пройти процедуру регистрации и полноростовой турникет, за которым и начинается охраняемый периметр ЦОД. А что охранять на ресепшн? Чайные пакетики?

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

Вот так выглядел ресепшн раньше:

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

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

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

Итоги

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

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

Другие новости и публикации
Новость
14.09.2023
Linx Cloud запускает новую услугу: частное облако на базе российско...
Вас также могут заинтересовать
Linx NGFW
IS-18.png
Межсетевой экран следующего поколения
Nwtwork own PC
Разместите свое оборудование в дата-центрах с высоким уро...
Linx Backup
Backup copy
Автоматизированное управление резервными копиями виртуаль...
Linx Outsourcing
Remote work
Аудит, модернизация и оптимизация ваших серверных мощностей
Linx Network
Remote work
Обеспечьте отказоустойчивость и бесперебойную работу сети
Linx DRaaS
DraaS-023
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-с...
Linx Private Cloud
Linxcloud
Готовая платформа для надежной работы бизнес-приложений
Linx IaaS
Iaas-02 copy
Отказоустойчивая и масштабируемая ИТ-инфраструктура для с...
Linx Kubernetes
Kubernetes
Автомасштабирование приложений с облачным Kubernetes от Linx
Linx DB
DB
Полностью управляемые и масштабируемые СУБД с гарантирова...
Что вас интересует?
Получить демо-доступ

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!