К книге
Настольная книга эксплуататора. Всё, что вы хотели знать о повседневной жизни датацентров, но боялись спроситьГлава 21 Перспективы. Взгляд номер один
87%
Глава 21 Перспективы. Взгляд номер один
26

В прошлых главах, как говорится, я рассказал все, что знал. Теперь хочу поделиться несколькими идеями, которые, как мне кажется, недостаточно обсуждаются сегодня в отрасли, а между тем они не только актуальны, но и могут быть реализованы прямо сейчас. Я буду говорить не о конкретных решениях, а о некоторых направлениях мысли. Правильных ответов, как и что именно нужно сделать сейчас, – нет, но уже настало время, чтобы задуматься о том, какие решения, сделанные сегодня, смогут выжить в нашей отрасли завтра.

Пандемия 2020 года показала, насколько все-таки критичным может быть человеческий фактор для датацентров. Решения о защите здоровья сотрудников, принятые на государственном уровне, были способны обезоружить команду эксплуатации. Не будем описывать тут, какие меры и ухищрения принимались для обеспечения продолжения беспрерывной работы. Суть в том, что очевидным стало преимущество тех датацентров, в которых постоянное присутствие команды не обязательно. Эта идея развилась в направление «бесчеловечного» датацентра – размышления о том, как поменять процессы таким образом, чтобы человеческий фактор на них не влиял. Идея, конечно, не нова. В одной зарубежной компании я видел сеть из более чем 50 (!) маленьких датацентров, большинство из которых не имеет постоянного персонала. Некоторые российские компании – владельцы контейнерных датацентров уже имеют неплохой опыт такой работы. Я уже не говорю об огромной сети базовых станций возле вышек операторов мобильной связи. Но нас будет интересовать то, как «обезлюдить» большой многомегаваттный датацентр. Перечислим несколько идей.

Прежде всего это отказ от физического присутствия дежурных на мониторинге. Это реализуется достаточно просто. При обеспечении канала VPN дежурные могут работать из дома. Конечно, в условиях пандемии это, может быть, еще более тяжелый фактор для психики, чем опасность заразиться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому нужно посмотреть на ситуацию с другой стороны. Заказчик хочет получать услуги дешевле, и вряд ли мы что-то с этим можем сделать. Тогда давайте попробуем наоборот – сделаем датацентр более экологичным, заработав на этом. С инженерной точки зрения датацентр – это огромный нагреватель. К нему подводится электричество, которое в итоге превращается в тепло и рассеивается в атмосферу. Побочный эффект этого нагрева в виде хранения фотографий котиков и просчета кратчайших маршрутов на дачу мы рассматривать не будем. Давайте представим себе, что мы производим тепло, огромное количество тепла – и просто выкидываем его. Соответственно, наша задача провести мозговой штурм и найти все возможные варианты использования этого тепла. Пусть это не будет суперприбыльный бизнес, но все-таки один рубль лучше, чем ноль рублей. Главное, чтобы срок окупаемости капитальных затрат по этому проекту удовлетворял бизнес-требованиям компании.

Среди вариантов использования тепла могут быть:

• отопление собственных помещений, например складских или офисных;

• продажа тепловой энергии соседним предприятиям как для промышленного использования, так и для обогрева ближайших жилых комплексов;

• организация тепличных хозяйств на прилегающей территории;

• организация рыбохозяйств в непосредственной близости от датацентра.

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

Еще одним потенциальным применением датацентров, на этот раз на энергетической карте нашей родины, может стать участие в компенсирующих рынках электрической мощности. Говоря совсем простым языком, генерирующие предприятия должны обеспечивать поставку на рынок некоторого гарантированного объема мощности, включая какой-то запас – аналогично понятию резерва N+1 в датацентрах. Когда сетевые операторы видят, что не справляются с обеспечением резерва или стоимость такого резерва становится слишком высокой, они приходят к потребителям, обладающим значительной собственной генерацией (а датацентры с дизельными установками как раз такие потребители), и предлагают платить некоторую премию за возможность в случае необходимости экстренного переключения потребителя на собственную генерацию, тем самым высвобождая для рынка несколько мегаватт. Вероятность такого переключения достаточно мала, а вот страховая премия может быть заметной в бюджете датацентра. Поэтому стоит внимательно взвесить риски, ознакомиться с конкретными условиями договора и, если все устроит, начать сотрудничество на благо страны.

Глава получилась не совсем про светлое будущее, каким изображают его футурологи, фантасты, евангелисты и др., простите за грубое слово, инфлюенсеры. Скорее речь о совсем близких следующих шагах, сделать которые можно уже сейчас, и, наоборот, шагах, делать которые не нужно.

Предыдущая главаГлава 26 из 30Следующая глава