Как стать автором
Обновить
107.23
Холдинг Т1
Многопрофильный ИТ-холдинг

Ремонт по фото, летающие серверы и опасная тишина, или Байки из ЦОДа

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров1.4K

Привет, Хабр. Это команда Т1 Облако. Так совпало, что сегодня 1 апреля и мы предлагаем на ваш суд несколько баек. Хотите верьте, хотите нет, но всё это происходило на самом деле. «Что еще за байки?» — спросите вы. Отвечаем.

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

Сниму порчу по фото

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

Первым делом попросили прислать логи ошибок. Взамен получили только фотографии экрана АРМ из их ЦОДа. Мы, конечно, удивились, но это была вся доступная информация. Ок, разбираемся: попросили выполнить команды диагностики, а затем отправить дополнительные фото с выводом команд. Фух, за несколько часов и пару килограммов нервных клеток всё решилось.

«Кто‑то по картам таро судьбу узнает, а мы по фото сервисы чиним», — посмеялся инженер техподдержки L2.

Этот способ экстренного «лечения» пришёлся по душе клиенту, и он стал обращаться чаще. Вы думаете, мы подпрыгивали от его запросов? Да! Но мы ни разу не отказывали в помощи, даже если проблема находилась, скажем так, не в нашей, а в параллельной вселенной.

Кармическая несовместимость

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

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

Наш Герой был в паре с коллегой: они ловко и умело монтировали резервный IP‑шлюз высотой в 4 юнита в верхней части 48-юнитовой стойки. Это примерно 2 м от пола. Шлюз крепился только на «уши», без салазок — обычное дело. История умалчивает, почему, но наш Герой, не закрепив оборудование со своей стороны и не дожидаясь, когда его напарник закрепит оборудование со своей стороны, убрал руки. IP‑шлюз вместе с пальцами коллеги молниеносно и с оглушительным грохотом упал на ниже стоящее оборудование, а именно на балансировщик нагрузки, который был расположен сильно ниже и уже обрабатывал продуктивный трафик. В этот момент с наших уст сорвались, наверное, все слова на букву «П».

«Пальцы как?» К счастью, руки и пальцы коллеги остались целы и невредимы, чего не скажешь про балансировщик нагрузки и IP‑шлюз. Хорошо, что мы всё резервируем. HA (high avaliblity) по балансировке отработал штатно. Однако уже к концу переезда мы заменили клиенту IP‑шлюз и балансировщик, а наш Герой более не работал в этом проекте по причине кармической несовместимости.

Непредвиденные последствия ремонта

Эта суровая история произошла в далёком северном регионе. Шёл комплексный ИТ‑проект, и бригада строителей меняла фальшполы в серверном помещении. На первый взгляд, задача простая, но клиент был, что называется, с выдумкой, и не дал нам никакого даунтайма.

Ок, включаем фантазию. Инженеры вместе с заказчиком решили немного приподнять одну из стоек, а затем поменять под ней напольное покрытие. Стойка оказалась нелегка на подъём: она была под завязку набита оборудованием — серверами, хранилками и прочим «железом». Инженеры героически приподняли стойку, освободив под ней около полуметра пространства, и начали менять фальшпол. Но, как водится, при любом ремонте основным расходным материалом являются нервные клетки. Вот и в ходе этих работ случилось непредвиденное.

Тяжеленная стойка внепланово приземлилась обратно на свое место. Клиент в шоке. Мы тоже не ожидали такого перфоманса. На всякий случай, мы быстро отгрузили жёсткие диски, аналогичные тем, что были в оборудовании той многострадальной стойки, чтобы у клиента был «ЗИП» и он мог поменять накопители, если случится самое страшное. К счастью, всё обошлось, диски остались целы и невредимы, подобно коту, который ловко спрыгнул со стенного шкафа на пол и побежал дальше по своим делам.

PDU против системы хранения, или Проблемы с «хвостом»

Если вы не бывали в ЦОДе, то постарайтесь представить, как он звучит: ритмично гудят серверы, равномерно шуршат жёсткие диски и всё это обволакивает белый шум от мощных вентиляторов охлаждения. Лишь блок распределения питания (PDU) безмолвно выполняет свою работу. Это не просто удлинитель с розетками, а сложное устройство, которое помогает управлять потреблением электроэнергии в ЦОДе. И эта история как раз о нём.

Однажды инженеры проводили в ЦОДе плановую замену PDU‑шек в стойке: меняли старые на более мощные. Делали по классике: у каждой стойки было по два «хвоста» PDU. Сначала меняли первый, затем переключали в него всё оборудование и меняли второй, и так по очереди.

И вот в одной из стоек самую малость недовоткнули этот «хвост». И когда отключили вторую PDU‑шку, то питание у одной из полок системы хранения резко закончилось и загорелась красная лампочка! Она предупреждала о том, что, вероятно, прилегла система хранения.

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


Надеемся, байки из ЦОДа вызвали у вас улыбку. А какие удивительные ситуации были у вас? Делитесь в комментариях.

Теги:
Хабы:
+7
Комментарии2

Публикации

Информация

Сайт
t1.ru
Дата регистрации
Дата основания
Численность
свыше 10 000 человек
Местоположение
Россия
Представитель
ИТ-холдинг Т1