В предыдущей статье мы подробно описывали причины, почему собственный ДГУ должен быть надежным источником электроснабжения ЦОД, постоянно готовым к работе любой длительности. Более того, отключение городской сети и переключение на ДГУ должны восприниматься дежурным персоналом ЦОД как рутинный, многократно отработанный переход на работу от другого источника энергии, а не экстремальная ситуация. В пункте 2.5 Uptime Institute Tier Standard: Topology это описано так: «Перебои в электрической сети (внешней – примечание автора) считаются не аварийной ситуацией, а ожидаемым рабочим условием, к которому площадка полностью подготовлена». Только если в процессе перехода какая-то система сработает «нештатно», ситуацию следует признать аварийной и требующей своевременного устранения.
Добиться такого отношения к этой для многих «волнительной» процедуре можно только регулярными плановыми переключениями всей нагрузки ЦОД с основного источника электроснабжения на ДГУ. В результате будет проверено влияние переключения на всю технологическую цепочку критического оборудования ЦОД, выявлены и улучшены технические уязвимости. Персонал, в свою очередь, отработает действия при этих переключениях в реальных условиях, а не на бумаге, что позволит дежурным не растеряться при реальном отключении городского ввода.
К сожалению, в некоторых ЦОДах придерживаются принципа «а как бы чего не случилось» и либо тестируют ДГУ исключительно на нагрузочные модули (так называемые индивидуальные испытания), либо вообще запускают ДГУ только на холостом ходу. В результате при первом реальном отключении выясняется, что либо ДГУ не готовы к полноценной работе на полную нагрузку ЦОД, либо другие критические системы (например холодоснабжение) не работают корректно во время и после перехода на ДГУ, либо персонал растерялся и не способен устранить даже элементарные сбои в процессе переключения.
Тестовые переключения ЦОД с основного источника на ДГУ должны выполняться регулярно на основании заранее утвержденного графика. Каких-либо нормативов на этот счет нет, мы выбрали для себя такой график – запуск ДГУ без нагрузки (так называемый «прогрев») один раз в неделю, полное переключение ЦОД на работу от ДГУ – раз в квартал.
Поделимся нашим лайфхаком по организации таких переключений. Как при наличии напряжения на основном вводе перейти на ДГУ, не переводя автоматику ГРЩ в «ручной режим» и тем самым сильно увеличивая вероятность человеческой ошибки? Для этого достаточно предусмотреть в ГРЩ режим под условным названием «принудительное отключение основного ввода». При повороте соответствующего тумблера со входа контроллера АВР ГРЩ будет отключаться сигнал наличия напряжения на основном вводе, что в свою очередь приведет к активации автоматического режима перехода на ДГУ. Данная функция также будет вам полезна, если напряжение (или частота) на основном вводе нестабильны, в результате чего ЦОД циклично переходит на ДГУ и обратно. Она позволит вам, оставаясь в автоматическом режиме, игнорировать появление и пропадание напряжения на основном вводе и получать стабильное электроснабжение от вашего ДГУ, пока внешний поставщик не исправит ситуацию с параметрами напряжения на основном вводе.
Что такое парные нагрузки и к чему приводит превышение их лимита, мы подробно описывали тут. Для сохранения требуемого уровня резервирования служба эксплуатации должна вести контроль парных нагрузок между всеми резервирующими друг друга компонентами критических систем ЦОД, в частности:
Также нужно контролировать соблюдение лимита N для систем с резервированием N+1, чаще всего это:
Процесс контроля парных нагрузок должен быть совмещен с процессом управления ресурсами, выделенными для ЦОД (например, сколько энергии куплено у города), и ресурсами, доступными для клиентов (например, сколько установлено ИБП и ДГУ). Так как ЦОД заполняется постепенно, на основании данных, полученных от отдела продаж, служба эксплуатации должна заранее заказывать у поставщиков и вводить в работу новые мощности технологического оборудования ЦОД, чтобы избежать ситуации, когда оборудование новых клиентов устанавливается за счет резервной мощности. Напомним еще раз — любая избыточность, заложенная для резервирования, позволяет потреблять больше ресурсов, но как только это случается, уровень резервирования превращается в N (то есть резерва нет).
Если технологическое оборудование подвержено износу и ЦОДы вынуждены постепенно модернизировать его и заменять на более современное, как это сделали мы с ИБП, то датчики и софт системы мониторинга могут работать очень долго даже без обновлений и поддержки, при этом катастрофически устаревая морально на фоне новых программных продуктов.
Основные черты систем мониторинга ЦОД были заложены в самом начале формирования индустрии ЦОД. Традиционно развитие шло по двум направлениям, с одной стороны стандартные «коробочные» версии от больших вендоров, с ограниченным функционалом не предполагающим кастомизации под ваши задачи, и с другой стороны, так как многие провайдеры ЦОДов вышли из телеком-операторов, применялись системы на базе инструментов мониторинга ИТ/телеком-инфраструктуры Zabbix и Prometheus+Grafana. Реже применялись «самописные» решения на базе открытых SCADA систем, а иногда встречались и такие примитивные решения, как на фото 😊.
Не все службы эксплуатации понимают, что за более чем 10 лет архитектура и функционал доступного программного обеспечения ушли далеко вперед и от системы мониторинга можно добиться много большей эффективности, мобильности, информативности и надежности. Возможно, это происходит в том числе из-за того, что на рынке до сих пор очень мало достойных систем мониторинга, действительно отличающихся от классических устаревших продуктов, а создание решений “с нуля” под свои требования сопряжено с большими сложностями и трудозатратами.
Обратим внимание, что система мониторинга, хоть и не является критической системой ЦОД, в случае сбоя радикально снижает способность команды эксплуатации реагировать на аварийные ситуации, поэтому отдельное внимание следует уделить отказоустойчивости ее основных компонентов.
В зоне ответственности клиентов находится много вопросов, напрямую влияющих на надежность их инфраструктуры, расположенной в ЦОД. Не стоит ожидать, что клиенты заранее будут понимать все особенности и правила правильного размещения оборудования в ЦОД. Поэтому службе эксплуатации ЦОД следует вести превентивную работу по информированию клиентов, которая может быть реализована следующими способами:
Например, в нашем ЦОД реализован онлайн вводный инструктаж, доступный для клиентов по внешней ссылке.
В конце инструктажа необходимо пройти тест, после выполнения которого на службу охраны ЦОД автоматически поступает сообщение об успешном прохождении вводного инструктажа.
Многие ЦОДы всячески стараются избегать прохождения аудитов, так как либо не уверены в своих силах, либо не видят в них пользы. Обычно для таких служб эксплуатации важным является выполнение только требований обязательных норм и правил (электробезопасность, охрана труда, пожарная безопасность и т.п.). Дополнительно они вынуждены проходить аудиты со стороны клиентов, каждый из которых является серьезным стрессоми требует специальной подготовки. Команда эксплуатации ЦОД Linx Datacenter прошла большое число различных аудитов, и мы абсолютно точно можем утверждать, что:
Но как перестать бояться аудитов и начать говорить с аудиторами на одном языке? В одной статье это невозможно описать, поэтому наша команда готовит к изданию книгу, в которой подробно, с примерами и ссылками, описан процесс эксплуатации ЦОД с учетом требований обязательных норм и правил, отраслевых «best practice», философии MOP, SOP, EOP и опыта прохождения всевозможных аудитов, в том числе многократной аттестации Uptime Institute Management & Operations Stamp of Approval.
Закажите консультацию специалиста
