Настольная книга эксплуататора. Всё, что вы хотели знать о повседневной жизни датацентров, но боялись спросить - Алексей Жумыкин

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

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

Дальнейшим развитием этой идеи является создание общего центра мониторинга (или ситуативного центра) – единой точки наблюдения за состоянием всех площадок. Понятно, что требования к коммуникации и эскалации тут еще выше. Также ситуационный центр будет эффективно работать внутри региона, когда все объекты находятся не более чем в нескольких часах езды для общей команды техобслуживания. Если площадки расположены в разных регионах – задача тоже решаема. Повышением уровня резервирования при проектировании и привлечением локальных команд технического обслуживания. В идеале вопрос «Будет ли это работать, если на площадке никого не будет два (три, пять, десять) дней?» нужно задавать еще на этапах проектирования и строительства.

Мы уже рассматривали варианты сокращения времени обходов в главе про техническое обслуживание. Если поставить задачу отказаться от обходов совсем, кажется, что она решается только внедрением достаточного количества датчиков на основные факторы, ведущие к выходу датацентра из строя. Более экзотические способы вроде запуска роботизированных собак (или других роботварей) с ИК-сенсором для контроля перегрева и датчиком для контроля протечек на лапах выглядят как чересчур усложненный вариант установки локальных датчиков. Даже если в дальнейшем таких собак будут продавать «три на десяточку» и удастся справиться с задачей их программирования, нужно будет существенным образом переосмыслить архитектуру датацентров для беспрепятственного перемещения роботов с учетом требования пожарной и физической безопасности зданий.

Перечисленные выше способы улучшения мониторинга дóроги. Возможно, более выгодным будет увеличение пропускной способности инженерного оборудования. Например, если через 630-амперный шинопровод идет ток 500 А, за его состояние мы будем волноваться гораздо больше, чем если бы номинал шинопровода был 1000 А. Такая перестраховка дает нам большее спокойствие, но платить за это приходится нерациональным использованием оборудования. Тут уж придется решать – что важнее.

Еще одно направление – дробление количества единиц оборудования. Например, если нам нужно установить ИБП для расчетной нагрузки в 600 кВт с резервированием, мы можем сделать это установкой четырех блоков по 200 кВт, пяти по 150 кВт или семи по 100 кВт. Понятно, что наименьший реальный эффект окажет отключение в последнем случае. Также, если сравнивать первый и последний варианты, для той же установленной мощности можно будет реализовать резервирование N+2 вместо N+1, что существенно увеличит выживаемость датацентра в случае долгого прибытия команды ТО на площадку. И снова такое решение недешево. Стоит семь раз подумать, может быть проще все же нанять больше дежурных. Скажем, с трехкратным запасом?

Иногда на собеседованиях, да и просто в разговорах с коллегами по отрасли я задаю вопрос: «С каким отказом в датацентрах приходится сталкиваться чаще всего?» Принимая во внимание то, что я занимаюсь обслуживанием инженерного оборудования, большинство старается угадать и более-менее верно называет ИБП. Другие называют те системы, с которыми они нахлебались на своих площадках, не принимая во внимание, что это их собственный частный случай, а не общая ситуация. К сожалению, только единицы сразу отвечают, что подавляющее большинство отказов в датацентрах приходится на HDD-диски. В по-настоящему больших датацентрах их такое количество, что ежедневно может потребоваться несколько человек, которые будут заниматься только заменой этих компонентов (а заодно и планок памяти). Переход с HDD[39] на SSD[40] немного улучшает картину, но не меняет ее. Все равно, диски нужно менять значительно чаще, чем выполнять какие-то другие задачи.

Процедура эта довольно бесхитростная и требует только сноровки и внимательности – никакой специальной компетенции. К тому же алгоритм замены и контрольные точки очень хорошо описываются в инструкциях. Поэтому именно здесь можно уверенно заменить человека роботом, заодно уменьшив количество человеческих ошибок. На первый взгляд идея выглядит неподъемной: необходимо дорабатывать серверы и стойки для доступа «механической руки», обеспечивать контролируемое выдвижение сервера без повреждения подключенных кабелей, придумать способ передвижения робота вдоль стоек с оборудованием, заложить необходимые подключения по электричеству, разработать программу замены диска и т. д. Да, с наскоку эту задачу не решить. Но можно решать ее небольшими шагами, например начать с доработки серверов. Или, наоборот, реализовать робота, просто доставляющего нужный диск к нужной стойке, а остальное по-прежнему оставить за человеком. В любом случае стоит начать двигаться в этом направлении, и результат будет не за горами.

После того как неисправный диск извлекается из сервера, необходимо провести его полноценное тестирование, чтобы принять окончательное решение о его дальнейшей судьбе. В самом простом случае это делается на специально подготовленной станции, в которой сотрудник устанавливает тестируемый диск в гнездо, запускает процедуру теста, которая продлится несколько часов, а по ее окончании диск вытаскивается из гнезда, и его судьба определяется в соответствии с результатами тестирования. Эти процедуры совершенно бесхитростны и могут выполняться простыми промышленными роботами, единственное – нужно разработать программу тестирования, задать процесс движений для манипулятора и организовать загрузку и разгрузку приемных и выходных кассет с дисками. Если объединить функционал этого робота с функционалом описанного ранее, то мы получаем полностью автоматизированный процесс замены дисков в датацентре. Уже очевидным продолжением может стать оснащение робота – сменщика дисков тестирующим модулем, чтобы уменьшить количество используемых манипуляторов.

Подход «а что, если это будет делать робот?» может принести интересные результаты, в том числе в изменении конструктива оборудования, что повлечет за собой перемены не только в конкретном датацентре, но и в индустрии в целом. Быстросменные запчасти, модульное исполнение, вынесение требуемого обслуживания болтовых соединений к передней панели – вот только несколько примеров.

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

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

Самое главное – не бояться пробовать подобные решения, выйти за рамки предлагаемых вендорами продуктов. Ну и, естественно, найти вариант финансирования подобных экспериментов. К сожалению для нас, это весьма немаловажный фактор.

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

Такая гонка за «зеленостью» была не более чем модой, и не похоже, чтобы кто-нибудь из отрасли получил от нее какие-либо дивиденды. Для этого заказчики должны были быть