Константин Нагорный
главный инженер ЦОД Linx Datacenter в Санкт-Петербурге
23.08.2023
3 мин

Топ-5 ошибок службы эксплуатации ЦОД

Боязнь тестировать ДГУ на полную нагрузку ЦОД

В предыдущей статье мы подробно описывали причины, почему собственный ДГУ должен быть надежным источником электроснабжения ЦОД, постоянно готовым к работе любой длительности. Более того, отключение городской сети и переключение на ДГУ должны восприниматься дежурным персоналом ЦОД как рутинный, многократно отработанный переход на работу от другого источника энергии, а не экстремальная ситуация. В пункте 2.5 Uptime Institute Tier Standard: Topology это описано так: «Перебои в электрической сети (внешней – примечание автора) считаются не аварийной ситуацией, а ожидаемым рабочим условием, к которому площадка полностью подготовлена». Только если в процессе перехода какая-то система сработает «нештатно», ситуацию следует признать аварийной и требующей своевременного устранения.

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

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

Тестовые переключения ЦОД с основного источника на ДГУ должны выполняться регулярно на основании заранее утвержденного графика. Каких-либо нормативов на этот счет нет, мы выбрали для себя такой график – запуск ДГУ без нагрузки (так называемый «прогрев») один раз в неделю, полное переключение ЦОД на работу от ДГУ – раз в квартал.

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

Отсутствие контроля за парными нагрузками и управления мощностями ЦОД

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

  • комплекс ДГУ и городской ввод,
  • ГРЩ А и B,
  • ИБП А и B,
  • щиты гарантированного питания А и B,
  • шинопроводы А и B,
  • PDU А и В,
  • трассы холодоснабжения А и B (если система охлаждения имеет их).

Также нужно контролировать соблюдение лимита N для систем с резервированием N+1, чаще всего это:

  • агрегаты ДГУ,
  • чиллеры или градирни,
  • фанкойлы или кондиционеры.

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

Использование устаревших систем мониторинга

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

Основные черты систем мониторинга ЦОД были заложены в самом начале формирования индустрии ЦОД. Традиционно развитие шло по двум направлениям, с одной стороны стандартные «коробочные» версии от больших вендоров, с ограниченным функционалом не предполагающим кастомизации под ваши задачи, и с другой стороны, так как многие провайдеры ЦОДов вышли из телеком-операторов, применялись системы на базе инструментов мониторинга ИТ/телеком-инфраструктуры Zabbix и  Prometheus+Grafana. Реже применялись «самописные» решения на базе открытых SCADA систем, а иногда встречались и такие примитивные решения, как на фото 😊.

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

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

Низкий уровень коммуникаций с клиентами

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

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

Например, в нашем ЦОД реализован онлайн вводный инструктаж, доступный для клиентов по внешней ссылке.

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

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

Боязнь аудитов и нежелание проходить их самостоятельно

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

  • Большинство применимых отраслевых аудитов (Uptime Management and Operations, ISO, проверки Ростехнадзора, аудиты со стороны клиентов и т.д.) имеют множество действительно полезных и обоснованных требований, а главное большинство проверяемых вопросов схожи, хотя зачастую и звучат по-разному.
  • Вполне реально создать систему («экосистему», как сейчас модно говорить) процессов и документации, удовлетворяющую всем требованиям различных аудитов, при этом не ведя «двойную» документацию под требования различных аудитов.
  • Созданные процессы, документация и уровень осведомленности персонала службы эксплуатации могут и должны поддерживаться на уровне, позволяющем в любой момент пройти любой применимый аудит без специальной подготовки.
  • Прохождение аудитов гарантированно повышает уровень процессов службы эксплуатации и помогает их совершенствовать, а боязнь аудитов наоборот не дает службе эксплуатации развиваться. Даже самый типовой аудит может поставить перед вами вопрос, который вы упустили в своих процессах. И это замечательно, ведь вам помогли найти уязвимость, и вы получили возможность устранить ее. Если аудитор обладает высокой квалификацией и четко понимает, почему он что-то требует, проходить аудит становится очень интересно и полезно.

Но как перестать бояться аудитов и начать говорить с аудиторами на одном языке? В одной статье это невозможно описать, поэтому наша команда готовит к изданию книгу, в которой подробно, с примерами и ссылками, описан процесс эксплуатации ЦОД с учетом требований обязательных норм и правил, отраслевых «best practice», философии MOP, SOP, EOP и опыта прохождения всевозможных аудитов, в том числе многократной аттестации Uptime Institute Management & Operations Stamp of Approval.

Другие новости и публикации
Новость
20.12.2024
Linx Cloud вошел в топ-3 поставщиков Kubernetes по версии CNews Market
Вас также могут заинтересовать
image 21
Удаленный доступ – легко и безопасно. Сервис MFA подходит...
fbe38929-c3dc-4675-8313-ef3c68d0cde5
Облачный сервис для защиты приложений на этапе разработки...
Linx NGFW
IS-18.png
Виртуальный межсетевой экран следующего поколения для ком...
PrivateCloud
Linxcloud
Готовая платформа для надежной работы бизнес-приложений
Migration
Migration-to-cloud-04-02-1024x576
Перенос ИТ-ресурсов в облако Linx Cloud из других облачны...
Nwtwork own PC
Разместите свое оборудование в дата-центрах с высоким уро...
Backup
Backup copy
Автоматизированное управление резервными копиями виртуаль...
Outsourcing
Remote work
Аудит, модернизация и оптимизация ваших серверных мощностей
Network
Remote work
Обеспечьте отказоустойчивость и бесперебойную работу сети
Linx DRaaS
DraaS-023
Облачный сервис для аварийного восстановления ИТ-инфрастр...
Что вас интересует?
Получить промокод
остались вопросы?

Закажите консультацию специалиста

заказать тест-драйв
Получить демо-доступ

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