Центры обработки данных

Центр обработки данных проектируют вокруг непрерывной работы вычислительного оборудования, поэтому его нельзя оценивать как обычное здание с набором инженерных систем. Здесь ИТ-нагрузка одновременно формирует потребность в электроснабжении и тепловую нагрузку, компоновка оборудования влияет на распределение этих нагрузок, резервирование связывает несколько проектных систем, а мониторинг должен соответствовать фактической конфигурации оборудования и инженерных решений. Проверка строится по этим зависимостям: от стойки и серверного зала — к питанию и охлаждению, затем к резервным связям и точкам, от которых зависит работа нескольких систем одновременно.

Для предметной проверки нужны схемы электроснабжения, расчёты тепловыделений и охлаждения, планы серверных залов и схемы мониторинга. Важно не только наличие каждого документа. Они должны относиться к одной актуальной конфигурации ЦОД и использовать согласованные исходные параметры: ИТ-нагрузку, принятую схему резервирования, тепловые нагрузки и фактическую проектную компоновку оборудования.

ИТ-нагрузка и схема электроснабжения

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

Проверку начинают с планов серверных залов. По ним устанавливают актуальную компоновку оборудования, после чего сопоставляют её с исходными данными, использованными в схеме электроснабжения. Если оборудование перемещено, добавлено или заменено, выясняют, изменилась ли ИТ-нагрузка и какие элементы электротехнического решения использовали прежнее значение.

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

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

Нагрузка от стойки до питания

Одна из основных проверочных цепочек для ЦОД — прослеживание нагрузки от стойки до питания. Каждый последующий уровень проектного решения должен опираться на актуальные исходные данные предыдущего. Если связь нельзя восстановить, итоговое решение невозможно уверенно соотнести с фактической проектной конфигурацией серверного зала.

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

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

Тепловая нагрузка и охлаждение

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

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

Изменение электрической и тепловой части при этом необязательно происходит одинаково. Замена оборудования может изменить один параметр сильнее другого либо затронуть только часть исходных данных. Поэтому нельзя автоматически считать, что любая правка серверного плана требует полной переработки обеих систем. Объём проверки устанавливают по фактическим зависимостям.

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

Резервирование проектных систем

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

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

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

Общие точки отказа

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

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

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

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

Компоновка серверных залов

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

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

Компоновка также служит контрольной основой для сопоставления документов между собой. Если план серверного зала показывает одну конфигурацию, расчёты построены на другой, а схема мониторинга — на третьей, невозможно уверенно подтвердить их согласованность до определения актуального варианта.

Схемы мониторинга

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

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

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

Изменения исходных параметров

Повторную проверку ЦОД следует строить от параметра, который фактически изменился. Это позволяет не ограничиваться исправленным листом и одновременно не расширять проверку на решения, которые от изменения не зависят.

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

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

Достаточность исходных данных

Комплект можно использовать для полноценной объектной проверки, когда по нему удаётся восстановить ключевые связи ЦОД. Планы серверных залов должны давать актуальную компоновку оборудования; схемы электроснабжения — соответствовать ИТ-нагрузке; расчёты тепловыделений и охлаждения — относиться к той же конфигурации; схемы мониторинга — быть согласованы с фактической проектной структурой.

Практически перед проверкой необходимо установить:

какая конфигурация вычислительного оборудования является актуальной;
какая ИТ-нагрузка относится к этой конфигурации;
какие тепловые нагрузки приняты в расчётах;
какая схема резервирования предусмотрена проектом;
как компоновка оборудования отражена в электрической и тепловой части;
соответствует ли схема мониторинга актуальному расположению и взаимосвязям систем;
относятся ли все сравниваемые документы к одной редакции проекта.

Если функция объекта не установлена, отсутствуют ключевые параметры или невозможно определить актуальную редакцию, индивидуальный вывод по соответствующей зависимости будет ограниченным. В такой ситуации фиксируют конкретно недостающий параметр: например, актуальную ИТ-нагрузку, тепловые исходные данные, схему резервирования или действующую компоновку.

Результат проектной проверки

Результат объектно-специфической проверки ЦОД показывает не только отдельные несоответствия, но и состояние критических связей. Можно зафиксировать, прослеживается ли ИТ-нагрузка от оборудования до электроснабжения, согласован ли тепловой баланс с охлаждением, соответствует ли резервирование взаимосвязанным схемам, существуют ли общие точки зависимости и относится ли мониторинг к актуальной компоновке серверных залов.

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

Такой результат относится к проектной модели объекта. Он не подтверждает фактический уровень доступности ЦОД, реальные эксплуатационные показатели или поведение смонтированных систем в рабочих и отказных режимах. Для подтверждения фактических эксплуатационных метрик нужны соответствующие испытания и данные существующего объекта.

Если определяющей функцией являются хранение и перемещение грузов, применяется модель складских и логистических комплексов. Для объектов с аэродромной и аэропортовой функцией предусмотрена категория аэропортов и аэродромных объектов. Другие объектные категории доступны в разделе «Объекты».