Отказоустойчивая инфраструктура ЦОДа, соответствующая требованиям и нормативам международных стандартов и рекомендаций, отечественным СНИПам и ГОСТам, обслуживаемая квалифицированным и опытным инженерным персоналом, позволяет свести к минимуму количество инцидентов и минимизировать потери от нештатных ситуаций. Открытый в 2009 году ЦОД оператора связи e-Style Telecom был оснащен всем необходимым, и все же один неприятный инцидент произошел.
Источники бесперебойного электроснабжения в ЦОДе — это самый критичный компонент в инфраструктуре, а отключение даже на полсекунды не заметить просто невозможно. Инцидент произошел в 2011 году, через полтора года после запуска: один из трех ИБП в штатной ситуации отключил нагрузку почти на секунду. Казалось бы, обычный рабочий цикл, который исправный ИБП должен был легко отработать (ИБП онлайновые, с постоянным выпрямлением и генерацией синуса). В логах ИБП появилась страшная и ничего не объясняющая строчка «Инвертор выключен», через секунду — «Инвертор включен».
В проекте нашего ЦОДа заложено, что все критичные нагрузки подключены к нескольким ИБП разными блоками питания или через PDU с функцией ATS. Это позволило оборудованию, отнесенному к данному классу, продолжить работу. Но часть серверов, где избыточность сделана структурной и которые запитаны от разных ИБП без дублирования, разумеется, перезагрузились. Дальше система внутреннего мониторинга ИБП показывала, что источник работает в штатном режиме, вся штатная диагностика сообщала о полной работоспособности. Ситуация удивительна тем, что произошло это с устройством, работающим полтора года, т. е. в период минимальной теоретической вероятности выхода из строя.
Есть кривая вероятности по выходу из строя оборудования. В соответствии с ней в первые два года вероятность каких-либо сбоев резко падает («обкатка», выявление производственного брака), а дальше — плавное повышение из-за износа. Так вот, описанный выше инцидент произошел в самой нижней точке этого графика — вероятность сбоев в данный момент была наименьшей за все время эксплуатации этих блоков ИБП.
Любой инцидент, произошедший в ЦОДе, подвергается расследованию, чтобы понять причину, выявить класс этой причины и устранить ее именно как класс. Таким образом, если проблема появляется там, где ее быть не должно, нужно докопаться до причины и сделать так, чтобы в будущем не появлялась ни данная, ни аналогичная ей проблема. Для этого мы обратились в официальное представительство производителя ИБП в Москве — собственно, к тем, кто проектировал, поставлял, монтировал систему и осуществлял ввод в эксплуатацию. Прибывший от вендора специалист лишь подтвердил полную исправность ИБП и системы в целом, правда, отметил, что таких строчек в логах «быть не должно». Такой ответ нашу компанию не удовлетворил, т. к. для нас означал возможность повторения ситуации и требовал замены всех ИБП этого вендора.
Мы не единственные эксплуатируем эти модели ИБП, и такая «аномальная» ситуация может случиться в критически важных для жизни человека местах: больницах, аэропортах, банках и т. д. ИБП этой серии достаточно распространены и на момент поставок уже работали порядка трех лет в самых разных отраслях, имея наилучшие рекомендации.
Как я уже упомянул, в местном отделении производителя нам помочь сразу не смогли — пришлось вести переписку со штаб-квартирой, расположенной в Италии, а также найти разработчиков ПО. Все это непростое занятие заняло у нас примерно пару недель. В результате выяснилось, что, да, был аналогичный случай с этой серией ИБП. И вендор дорабатывал ПО ИБП. Как единственный вариант решения проблемы нам предложили заменить версию управляющей программы в ИБП, которая разрабатывалась в расчете на электросети с возможными аномалиями. Но главное во всей этой истории то, что версия такой прошивки существовала, однако московское представительство о ней не знало. Сама замена ПО во всех наших ИБП заняла не более двух часов: приехал инженер с ноутбуком, который в ЦОДе подключился к работающей системе и произвел перешивку. Прошло уже более четырех лет — никаких замечаний к работе ИБП больше зафиксировано не было.
Предвосхищая вопрос по эксплуатации ЦОДа, в рамках процедур, выработанных опытным путем, мы нашли очень эффективное решение. Два раза в неделю производится обход с тепловизором всего дата-центра, во время которого выявляются возможные проблемные моменты на самой ранней стадии. Обследование показывает температурную картину всех кабелей, соединений, узлов и устройств. На тепловизоре отлично видно: холодный коридор — это холодный коридор; горячий — это горячий коридор. Был случай, когда клиент, арендуя телекоммуникационный шкаф целиком, смонтировал часть своих серверов так, что забор воздуха осуществлялся из горячего коридора.
Таким же образом, с использованием тепловизора, обслуживаются кондиционеры, просматривается состояние магистралей. На радиаторах ИБП хорошо виден штатный температурный градиент. И если в одном из блоков температура компонента на 3–5 градусов больше соседнего — это повод задуматься о причинах и последствиях.
Конечно, во всех используемых блоках есть самодиагностика и SNMP-модули, устройства диагностируются и мониторятся, но это только дополняет нашу диагностику. Осматриваются все соединения, все провода, оценивается состояние аккумуляторов (при разрядке/зарядке по температурной картине можно определить состояние всех ячеек и элементов). Конечно же, проводится плановая работа по измерению напряжения в батареях, проверяется изоляция и сопротивление по всем линиям. Все это необходимо для того, чтобы знать: система работает, и работает надежно. Что и подтверждают наши клиенты, которые уже на протяжении многих лет работают с нашей компанией и размещают свое оборудование в нашем центре обработки данных.
Источник: Журнал «ЦОДы.РФ» № 13
Чтобы оставить свой отзыв, вам необходимо авторизоваться или зарегистрироваться
Комментариев: 0