В начале эпохи организации датацентров в России, как правило, приобретали или арендовали пустующие промышленные площади подходящей конфигурации. Часто такие помещения имели ряды колонн, что мешало рационально расставить стойки, да и в целом чаще всего хотелось нашпиговать помещение IT-оборудованием по максимуму, ведь именно оно приносит выручку.
При такой постановке вопроса каждое свободное место на полу серверной и каждый незанятый юнит в стойке казался непростительной тратой ресурсов. Ежедневная забота IT-специалистов была в том, чтобы «оптимизировать» выделенное пространство. В некоммерческих датацентрах пытались разместить стойки даже в коридорах, предназначенных для прохода. Считалось, что идеальный серверный зал должен быть заполнен серверами от пола до потолка.
Понятно, что увеличение количества серверов вело к увеличению энергопотребления, нагрузке на пол и локальным перегревам. Но это были уже проблемы не айтишников, а команды эксплуатации. К сожалению, физические ограничения отменить не так просто, поэтому, когда полы начали прогибаться и трескаться под весом стоек, а автоматы отстреливали из-за превышения тока, проблема из сугубо эксплуатационной переросла в первоочередную для бизнеса.
Самым критичным, конечно, было увеличение нагрузки на пол. В случае если измерения не были проведены на момент строительства, немедленно вызываются эксперты, выдающие допустимый вес аппаратуры, и руководство компании строго-настрого запрещает превышать эти цифры, понимая, что речь может идти не только о финансовых потерях, но и о более серьезных последствиях, особенно если датацентр расположен не на первом этаже здания.
Разобравшись с нагрузкой на пол, команда датацентра обращает свои взоры на электричество. После завершения строительства лучшее, что можно сделать для питания самых «прожорливых» стоек, – это перекидывать временными линиями необходимую мощность с соседних рядов или серверных.
Еще один аспект, существующий как в коммерческих, так и в корпоративных датацентрах, – это переподписка по электричеству. Если коротко, то датацентр продает (или передает, если он корпоративный) заказчикам подключение к большей электрической мощности, чем у него есть, уповая на то, что заказчики никогда одновременно не будут потреблять электроэнергию по максимуму. С одной стороны, желание дважды продать одну и ту же мощность выглядит как жадный оскал капитализма, с другой – если заказчики осведомлены о коэффициенте переподписки и готовы идти на риск, компенсированный комфортными финансовыми условиями, – это вполне разумный компромисс. Какой бы ни была причина, критически важно следить за ситуацией и заранее знать, как повести себя в случае каких-либо ограничений.
При наличии постоянной серверной нагрузки рано или поздно достигается сравнительно стабильное состояние, при котором датацентр можно считать надежно работающим. Самое главное – не забыть записать на бумажке, какая стойка от чего запитана, и передавать это знание из поколения в поколение дежурных, сверяясь с этой записью перед важными отключениями.
После того как с лимитами по электричеству разобрались, наступает очередь самого мистического и загадочного фактора – воздуха, а точнее охлаждения. В подавляющем большинстве случаев инженеры датацентра не знают принципов работы системы охлаждения на их площадке. Если они отчетливо понимают, что она работает в данный момент, – это уже большое достижение. Но любое изменение, при котором система выходит за пределы нормальной работы, открывает огромное поле для знаменитых танцев с бубнами.
Большинство проблем решаются эмпирически: подкладыванием фанерок для изменения потоков воздуха, установкой переносных кондиционеров, заклеиванием или переносом датчиков температуры, открытием настежь дверей серверных и т. д. То есть борьба ведется с последствиями локальных перегревов, а не с их причиной. Моим любимым примером остается случай, когда дежурный инженер, чтобы избавиться от назойливого сигнала, предупреждающего о повышенной температуре в горячем коридоре, просто отвел датчик от струи воздуха. Датчик немедленно «позеленел», и дежурный удовлетворенно вернулся на свое место.
Самым авторитетным специалистом по эксплуатации становится инженер, который ликвидировал больше других аварий. Он «видел все» и точно знает, в каком случае какую заплатку нужно применить. К сожалению, такой метод плохо работает на будущее, то есть практически невозможно рассчитать ограничение, при котором наступит авария. Единственным действенным способом борьбы с критическим перегревом является заметное переразмеривание системы, то есть установка избыточного количества оборудования про запас, что позволяет тем или иным способом направлять излишек холода на критичный участок. Надо признать, что такой подход весьма далек от оптимального, так как большую часть времени запасное оборудование не будет использоваться.
Итак, какую же задачу мы хотим решить, когда говорим об управлении мощностями?
На самом деле, довольно простую: нам нужно разобраться, каким количеством ресурсов мы на самом деле обладаем, сколько из этого количества используется на данный момент, сколько зарезервировано и, соответственно, сколько ресурсов остались свободными.
В дальнейшем изложении я упущу из рассмотрения сетевые подключения. Как правило, анализ доступности канала для ДЦ выполняется отдельным подразделением, а распределением между стоек ведает сам заказчик. В любом случае проблемы нехватки сетевого канала никогда не решаются службой эксплуатации. Однако, принцип анализа, сформулированный в предыдущем абзаце, полностью применим и к сетевым подключениям, поэтому подход к планированию и контролю останется точно таким же.
Для того чтобы решить задачу планирования мощностей обдуманно и основательно, нужно выделить следующие важные шаги.
1. Определить ограничивающие факторы.
2. Выяснить причины ограничений и определить максимально доступные значения каждого фактора.
3. Выяснить реальные значения потреблений.
4. Разработать схемы нормальной работы всего датацентра в целом.
5. Установить пристальное наблюдение.
6. Договориться о частоте и глубине пересмотра выбранных значений и планов.
7. Разработать план действий для каждой нестандартной ситуации.
Ограничивающие факторы для большинства датацентров будут одними и теми же. Прежде всего это уже упомянутые количество доступных стойко-мест, доступная электрическая мощность, доступное количество холода. Именно эти факторы и рассмотрим ниже. Далее для каждого датацентра может быть и что-то специфическое. Например, допустимая нагрузка на перекрытия или количество доступных сетевых портов.
Для того чтобы выяснить причины ограничений, внимательно рассмотрим каждый из факторов.
Количество стойко-мест может быть самым простым для анализа, однако не стоит забывать об особенностях каждой стойки. Стойки могут быть шириной 80 или 60 см, и поэтому на одной и той же площади можно поставить как 30, так и 40 стоек (и даже любое промежуточное число). Для такого случая нужно делать расчет доступной площади в узких, 60-сантиметровых стойках, а одну широкую считать как 1⅓ от базовой. Такая абстракция дает хорошее приближение, единственное, стоит помнить о наличии соответствующего количества блоков на шинопроводе.
Для определения ограничений по электрической мощности необходимо будет рассмотреть однолинейную схему и понять совокупность всех ее ограничений. Например, рассмотрим схему, состоящую из одного трансформатора, трех ИБП, включенных по схеме N+1, распределительного щита, от которого отходит четыре шинопровода, на каждый из них можно установить 25 отводных блоков с допустимым током 32 А на каждый.
Если смотреть на схему с точки зрения отводных блоков, то кажется, что можно подключить суммарную нагрузку током 32 х 25 = 800 А, что дает нам 3200 А на серверную. Однако, посмотрев на номинал автоматов ГРЩ, мы увидим, что ток через каждый шинопровод ограничен величиной 600 А (например, потому, что мы выбрали стандартные шинопроводы номиналом в 630 А). Таким образом, мы уже уменьшаем доступный ток до 2400 А. Наш трансформатор может быть выбран с небольшим запасом и спокойно держать нагрузку только в 2000 А, так что это станет следующей итерацией ограничений. Но окончательный лимит мы узнаем, поняв, что каждый из ИБП способен держать только 600 А, что дает нам ограничение по максимально доступной мощности в 1800 А. Эта величина и будет для нас определяющим фактором при расчете допустимого электрического тока на серверную.
Ситуация с охлаждением немного сложнее и зависит от того, какую философию исповедуют проектировщики датацентра. Старая и менее эффективная схема, при которой охлаждение стоек происходит в замкнутом воздушном контуре машинного зала, может быть посчитана предельно просто. Ведь количество холода, выработанного системой охлаждения (холодопроизводительность), должно быть равно количеству тепла, выделенного стойками плюс теплопритоки в серверную через наружные стены. Таким образом, если выразить холодопроизводительность в ваттах, то можно очень просто рассчитать доступную для серверной холодопроизводительность суммированием всех единиц оборудования.
В случае более продвинутой системы охлаждения (прямого воздушного фрикулинга), когда тепло уносится из серверной поступающим снаружи воздухом, важно определить необходимую производительность (расход) вентиляционной системы, которая измеряется в кубометрах в час. Это значение также берется либо из проектных значений для вентиляторов, либо, что намного более правильно, измеряется во время пусконаладки. Для того чтобы быть уверенным в качестве используемых данных, принимая во внимание естественное старение оборудования, желательно регулярно проводить калибровку систем и соответствующим образом корректировать значения максимально доступной мощности или холодопроизводительности.
Мы ответили на вопрос «сколько есть?», давайте посмотрим, как понять «сколько нужно?». В нашем примере потребление всех перечисленных ресурсов будет определяться стойкой. Можно принять за минимальный квант и сервер, например величиной в юнит или даже в половину, но принцип анализа это не меняет.
Как отмечалось выше, стойка шириной 60 см будет занимать одно стойко-место шириной 60 см, а стойка шириной 80 см – 1⅓ такого места. Выдумывать что-либо хитрее, наверное, бессмысленно. Давайте представим выдуманный график, на котором совместим планы строительства датацентра и план его заполнения с точки зрения стойко-мест.
Видно, что в начале года у нас есть серверные помещения, способные вместить 500 стоек (красная линия на рисунке). В феврале мы увеличиваем количество фактически установленных стоек (зеленая линия) до 250, а затем до 500, таким образом достигая максимального заполнения по стойко-местам. К счастью, в апреле мы увеличиваем доступные к заполнению площади и запускаем в эксплуатацию еще 200 стойко-мест (скачок красной линии), и, несмотря на то что по ряду причин в мае количество стоек было уменьшено, мы способны продолжить заполнение зала стойками.
В августе в эксплуатацию вводится еще 300 стойко-мест (следующий скачок красной линии – теперь доступна 1000) и продолжается заполнение серверной стойками заказчиков. К концу года все доступные серверные площади датацентра заполнены на 90 %.
На таком графике можно провести воображаемую линию, например в июле, и будет очевидно, что показатели слева от этой линии будут историческими значениями, а справа – планами по заполнению.
Таким образом, этот график поможет всем отделам получить необходимую информацию и правильно взаимодействовать. Отдел продаж поймет, когда и сколько стойко-мест еще доступно, и сможет сформулировать новые потребности. Это даст возможность отделу строительства определить срочность и гибкость работ по введению новых площадей на основании планов продаж. Отдел эксплуатации на основании имеющихся площадей и загрузки сможет заблаговременно получить и подготовить необходимые ресурсы.
Чтобы построить такой же баланс по электрической мощности, прежде всего необходимо понять, сколько на самом деле потребляет сервер или стойка, в зависимости от того, что является минимальным квантом. Допустим, что над стойками проложен трехфазный шинопровод, на котором установлены отводные блоки с автоматами на 32 А. Это дает нам 22 кВт мощности на стойку, если все фазы сбалансированы. Если стойка высотой в 52 юнита, то на каждый из них получается около 424 Вт.
Самый простой способ определить потребление сервера – посмотреть спецификации от производителя. В большинстве случаев этого уже достаточно. Более точным способом является создание простых, аналогичных реальным задачам сервера синтетических программных тестов, нагружающих процессор, модули памяти и диски. Затем эти тесты запускаются на сервере и производится лабораторный замер потребляемой мощности. Так как в большинстве серверов есть собственные вентиляторы, то необходимо сделать замеры тока (мощности) во всех температурных режимах и, как минимум, на специфицированных производителем границах, так как это может существенно влиять на общее энергопотребление сервера.
Есть еще один способ, более выгодный экономически, но несущий в себе дополнительные риски. Он заключается в том, что за конкретным типом стойки или сервера устанавливается пристальное наблюдение и его энергопотребление постоянно фиксируется. Затем мы фиксируем пиковое значение энергопотребления, скажем за месяц или за полугодие, и принимаем его за максимальное потребление сервера в реальных условиях. Понятно, что сервер может полгода находиться в режиме stand-by, а затем внезапно включиться в режиме высокой загрузки ЦПУ, тем самым превысив статистический максимум. Поэтому принятие решения о применении такого способа расчета должно быть несколько раз обдумано и, по возможности, согласовано с заказчиком. Такой расчет крайне не рекомендуется в гомогенной среде, где, например, весь машинный зал заполнен одинаковыми серверами одного заказчика.
В коммерческих датацентрах, конечно, никаких измерений можно не делать, а просто определить все резервы стойки на заказчика, подразумевая под этим, что когда-нибудь его оборудование сможет выйти на пиковую мощность. Это будет самым простым, но самым неэффективным решением. С одной стороны, если заказчик оплачивает такое резервирование, то почему бы и нет? С другой, если заказчик сам понимает, что он перестраховывается, то можно договориться с ним о взаимовыгодных условиях переподписки на мощность, когда, например, он платит за базовую мощность ниже максимальной, а в случае пиковой нагрузки может получать и большее количество энергии, но только при ее наличии, то есть без гарантии.
Для датацентров с устаревшим классическим охлаждением количество требуемого ресурса по охлаждению можно определить, приняв его равным энергопотреблению серверов. Но снова это решение больше не про эффективность, а про простоту.
Более грамотный подход состоит в том, чтобы понять, какой расход воздуха нужен серверу в момент его пиковой нагрузки. Измерить это можно в условиях лаборатории с использованием специальных приборов во время описанного выше тестирования на энергопотребление. Такие измерения имеет смысл сделать во всем температурном диапазоне, получив массив данных по расходу воздуха при различной его температуре и при различной загрузке процессора. Результаты измерений имеет смысл сохранить: они могут понадобиться в дальнейшем. Подобные тесты следует проводить регулярно, скажем раз в два-три года, для контроля деградации характеристик серверного оборудования.
Теперь мы знаем, какое количество ресурсов у нас есть и какую часть из них мы можем потребить текущим количеством стоек. Попробуем собрать это все в единый график и посмотреть, какую информацию мы можем получить и как понять, когда у нас нормальная работа всего датацентра в целом, а когда – нет.
На таком графике имеет смысл выделить следующие линии:
Максимальное значение ресурса показывает, сколько всего мощностей доступно для данного объекта. В качестве объекта может выступать отдельная стойка, машзал, здание или весь датацентр в целом. На данном графике эта линия представлена красным цветом.
Значение ресурса с резервированием. Линия оранжевого цвета показывает, сколько у нас есть электричества, обеспечивающего проектный уровень резервирования. В этом месте стоит упомянуть о двусмысленности термина «резерв», что часто приводит к путанице в обсуждении. Нужно четко понимать, что выключение всех резервных единиц инженерного оборудования фактически превратит эту линию в «максимальное значение ресурса». Таким образом, линию можно равноценно назвать как работой с резервированием, так и работой без резервирования – смотря с какой стороны подойти. Чтобы избежать этой двусмысленности, лучше назвать эту линию целевой, так как приближение к ней показывает наиболее эффективное использование ресурсов при сохранении требуемой надежности. Или использовать английский термин warning, так как пересечение этой линии не сразу сказывается на работе IT-оборудования, но повышает риск при любом отказе инженерии.
Аллоцированное значение ресурса – это расчетная величина, показывающая, сколько стойка может потребить в пике. Другими словами, сколько стойка «имеет право» потребить, хотя совершенно не факт, что она сможет приблизиться к этому значению. Именно это значение должно учитываться для понимания загрузки мощностей. На нашем графике эта линия обозначена зеленым цветом.
Реальное потребление ресурса – это текущее значение, получаемое из системы мониторинга постоянно или в регулярные промежутки времени. С помощью этого показателя можно сразу оценить эффективность использования ресурсов нашего датацентра и его устойчивость в данный момент. Наблюдение за этим показателем желательно добавить и дежурной смене.
Если мы рассматриваем данные текущего года, то слева от сегодняшней даты реальное потребление ресурса будет отображаться, показывая фактические данные в прошлом, а справа таких данных не будет, так как потребление в будущие периоды нам пока неизвестно.
Теперь пора понять, как определить уровень резервирования (или целевую линию). Для примера вернемся к уже рассмотренной схеме распределения электроэнергии.
Как мы описали выше, максимальный ток для расчета допустимой мощности определяется током через сборку ИБП и составляет 1800 А или примерно 1,25 МВт. На графике это значение будет обозначено красной линией. В случае если мы захотим вывести из эксплуатации один блок сборки ИБП для ремонта или технического обслуживания, то мы будем способны поддерживать ток в 1200 А или примерно 830 кВт – это и будет оранжевая линия на графике.
Но не все датацентры строятся по такой философии. Если по условиям работы допустимо, чтобы какую-то часть времени серверное оборудование отключалось для ремонта обслуживания, то существенное занижение доступной мощности за счет резервирования одной единицы оборудования неэффективно. В этом случае нам необходимо просто определить, какую величину максимальной мощности мы готовы пожертвовать про запас. Для этого следует разобраться в том, что может быть причиной необходимости такого запаса. Приведем несколько примеров.
1. Погрешность установки автоматов.
2. Погрешность расчета или определения максимальной потребляемой мощности сервера, что особенно актуально при статистическом методе.
3. По сути, та же погрешность, но вызванная незапланированным ростом вычислительной нагрузки, например при переносе вычислений с одной площадки на другую.
Достаточная величина такого резервирования может находиться уже в пределах 95 % от максимального значения, что гораздо лучше, чем 33 %, определенные по предыдущему методу.
Кстати, из сравнения этих графиков видно, что при выборе варианта работы по резервированию к концу рассматриваемого периода аллокация превышает возможности датацентра по обеспечению надежной работы (целевое значение), а для площадки с допустимыми отключениями даже остается ресурс для дополнительной установки IT-оборудования.
Описанный выше способ определения целевого значения, учитывающий резервное оборудование, применим и к системе охлаждения. Единственное, уместно добавить, что производительность системы охлаждения может меняться в зависимости от сезона, например переходом с фрикулинга на работу на чиллерах. Такое изменение может влиять на максимальное и целевое значения и давать дополнительную гибкость, например для кратковременного сезонного повышения доступной емкости площадки, что может увеличить маневренность в запуске новых проектов.
Теперь, когда в руках у нас такой мощный инструмент, посмотрим, как его можно эффективно использовать. Приведем примеры вопросов, ответы на которые содержатся среди линий графика.
Когда строить новый датацентр? Если отдел продаж датацентра предоставит свои планы на один-три года вперед, то, наложив их на существующие мощности, можно получить хорошее понимание того, когда и сколько серверов нужно вводить в эксплуатацию. Это позволит существенно точнее прогнозировать капитальные затраты на предстоящие периоды. Если же превышение мощностей небольшое, то можно либо переарендовать нужные площади у другого датацентра, либо начать переговоры о возможной переподписке.
Можно ли добавить еще нагрузки? Строго говоря, для ответа на этот вопрос достаточно посмотреть на построенные нами три графика (аллокацию по месту, по электричеству и по воздуху) и, если на всех трех графиках есть свободные ресурсы, то, конечно, можно. Очевидно, что допустимая величина люфта будет определяться минимальным запасом из всех доступных.
Как задействовать неиспользуемую мощность? Допустим, мы использовали все доступные стойкоместа, а у нас все еще остается значительное количество электрической мощности. Как одно из некрасивых, но вполне действенных решений можно предложить переброс электрической мощности из одной серверной в другую. Аналогично, если в одной серверной есть избыток холода, а в соседней – недостаток, можно рассмотреть объединение серверных по воздуху путем демонтажа перегородки. Ну и т. д.
Можно ли сейчас выключить часть инженерного оборудования для обслуживания? Даже если в данный момент мы работаем с выключенным резервным оборудованием, но реальная нагрузка существенно ниже, можно оценить, как изменится положение целевой и максимальной линии при отключении еще одной единицы, и принять осознанное решение.
Последний пример, кстати, подтверждает желательность постоянного наблюдения за текущей загрузкой датацентра дежурными, так как в случае инцидента они смогут быстро оценить, насколько критично то или иное происшествие для выполнения датацентром своего предназначения, иными словами соблюдения SLA[33].
По-настоящему эффективное использование нашего замечательного инструмента возможно, когда его силу и ценность понимают все вовлеченные в работу датацентра отделы. Я говорю об отделе продаж (или его аналоге, предоставляющем планы внутренних заказчиков), отделе строительства, эксплуатации и верхнеуровневом руководстве. Для синхронизации общей картины необходимо проводить регулярные встречи отделов, где должна обсуждаться текущая ситуация, текущие и стратегические планы и возможные варианты действий для реализации планов, например корректировки бюджета компании.
В заключение этой главы мы разберем несколько примеров ситуаций, когда «что-то пошло не так» с планированием ресурсов, и то, какие выводы можно сделать в каждом случае.
1. В первом примере голубая линия на некоторое время становится выше зеленой (реальное потребление выше аллокации). Такая ситуация вполне возможна и является результатом ошибки. Либо ошибки мониторинга, когда измеренное значение не соответствует реальному положению дел, либо неправильно определенной линии аллокации.
Если с первой причиной можно справиться достаточно быстро, проверив корректность данных мониторинга и при необходимости восстановив работоспособность системы, то во втором случае требуется внимательный анализ причины. Ситуация осложняется, если линия аллокации действительно определена неверно, и это может привести к пересмотру данных не только для одного конкретного сервера, но и всего датацентра, что существенно изменит картину по всем остальным машзалам, где применяется этот тип серверов.
Вероятность того, что данные искажены ошибкой в измерениях или расчетах, есть всегда, но мы разберем вероятные проблемы, обусловленные неправильным планированием или техническими причинами.
2. Зеленая линия выше оранжевой (аллокация мощностей выше целевого значения). Такая ситуация может случаться сплошь и рядом и на самом деле не является по-настоящему критической.
Прежде всего по своему определению линия аллокации является только резервированием под возможное использование мощности, но вполне вероятно, что оборудование никогда не начнет использовать такое количество мощности.
Кроме того, если такое пересечение находится в отдаленном будущем, то оно может выступать индикатором того, что мощности кончились и необходимо каким-то образом их наращивать или перераспределять.
Если же такая ситуация наблюдается сейчас или в ближайшее время, когда никаких действий по перераспределению мощностей предпринять нельзя, то и тогда паниковать не стоит. В конце концов, оборудование работает и все в норме. Нужно рассмотреть возможность отказа от проведения работ, связанных с отключением инженерного оборудования, понижающего степень резервирования, и установить пристальное наблюдение за состоянием всех систем до того момента, когда мощности будут разгружены.
3. Голубая линия выше оранжевой (реальное потребление выше целевого значения). Ситуация, очень похожая на предыдущую, с одним отличием: в прошлый раз работа без резервирования могла произойти, а теперь точно произошла. В таком случае обязателен запрет на проведение любых манипуляций с оборудованием, которые могут привести к снижению резервирования, а также незамедлительное информирование IT-специалистов для срочного планирования разгрузки мощностей.
4. На следующем примере зеленая линия находится выше красной (планируемое потребление выше максимальной возможности датацентра).
Если такая ситуация предстоит где-то далеко в будущем, то это всего лишь громкий звоночек о том, что необходимо срочно запланировать действия по разгрузке существующих мощностей или по запуску в эксплуатацию новых. Это обсуждение будет вестись на регулярных встречах отделов компании. Если же такая ситуация происходит здесь и сейчас, это еще не катастрофа, но повод немедленно эскалировать ситуацию до руководителей компании и организовать немедленную разгрузку страдающей части датацентра.
5. Голубая линия выше красной (реальное потребление выше максимальной возможности датацентра). Из всех представленных случаев этот – самый катастрофический.
Фактически мы имеем случай, когда реальное потребление датацентра превышает максимально допустимое. «Как такое возможно?!» – спросит внимательный инженер. На самом деле, такая ситуация возможна, потому что линия на графике не является физическим предохранителем, который срабатывает при достижении какого-то значения. В каждой ситуации нужно разбираться отдельно. Как пример, можно назвать превышение расхода электропотребления системами вентиляции, которое не привело к отключению нагрузки, потому что в этот момент электропотребление других систем было не максимально. Тем не менее это уже аварийная ситуация, реагировать на которую дежурная смена должна незамедлительно.
6. Голубая линия намного ниже зеленой (реальное потребление заметно ниже аллокации). Практически это совсем не аварийная ситуация, однако сигнал о том, что датацентр используется неэффективно. Причины, скорее всего, таятся в значительном снижении задач, выполняемых серверами в датацентре, поэтому стоит связаться с администраторами заказчиков и уточнить, временное ли это явление или долгосрочное.
Еще одной причиной существенного снижения реального потребления может быть замена серверов на новые, для которых неправильно посчитано максимальное потребление. Пересмотр методики тестирования и обновление значений в такой ситуации могут высвободить дополнительные ресурсы для установки большего количества серверов и, соответственно, более эффективного использования площадки.
Эффект от изменения реальной нагрузки автоматически нивелируется через некоторое время при статистическом методе расчета мощности, потребляемой сервером.
Разумеется, это только несколько примеров анализа ресурсов в датацентре. Но нашей задачей было продемонстрировать методику анализа, и, надеюсь, приведенных примеров было достаточно.
На этом можно было бы закончить рассмотрение темы управления ресурсами. Но в ее основе лежит несколько интересных идей по дальнейшей оптимизации работы датацентров, в том числе и автоматизированному расчету имеющихся мощностей. Этим идеям имеет смысл посвятить отдельную главу.