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

Для чего нужен ЦОД
Назначение ЦОД состоит в том, чтобы обеспечить контролируемую среду для обработки, передачи и хранения данных. На его ресурсах могут работать корпоративные приложения, сайты, базы данных, виртуальные машины, системы резервного копирования, частные облака, аналитика, обучение нейросетей и инференс.
Центр обработки данных решает несколько задач одновременно:
размещает вычислительные серверы и ускорители;
хранит рабочие данные, архивы и резервные копии;
соединяет ИТ-системы между собой, с операторами связи и пользователями;
подает электропитание нужного качества и сохраняет его при части отказов, если это предусмотрено проектом;
отводит тепло и поддерживает условия, допустимые для установленного оборудования;
ограничивает физический доступ и обнаруживает опасные события;
собирает телеметрию, предупреждает об отклонениях и помогает управлять изменениями.
ЦОД, серверная и облако: в чем разница
Серверная комната тоже может иметь стойки, ИБП, кондиционирование и контроль доступа. Граница между ней и небольшим ЦОД не задается одним числом серверов. Обычно о центре обработки данных говорят, когда площадка имеет формализованную инженерную архитектуру, выделенные зоны, круглосуточный мониторинг, процедуры эксплуатации и измеримые требования к доступности.
Облако находится на другом уровне сравнения. Это модель получения вычислений, хранения и сервисов через программные интерфейсы и сеть. Физически облачная инфраструктура все равно работает в одном или нескольких ЦОД. Поэтому вопросы «собственный ЦОД или облако» и «какое здание выбрать» относятся к разным уровням решения.
Полезно различать три модели:
Модель | Что принадлежит заказчику | За что отвечает площадка или провайдер | Когда подходит |
|---|---|---|---|
Собственный ЦОД | здание или модуль, инженерные системы и ИТ-оборудование | часть внешних коммуникаций и сервисов по договорам | нужны полный контроль, особые требования и предсказуемая длительная нагрузка |
Colocation | серверы, СХД и сеть заказчика | стойка или зал, питание, охлаждение, физическая защита и подключения | оборудование должно оставаться собственным, а строительство площадки нецелесообразно |
Облако | данные и программная конфигурация в пределах договора | физическая платформа, виртуализация и выбранные управляемые сервисы | важны быстрый запуск, эластичность и оплата ресурсов как услуги |
Из чего состоит инфраструктура ЦОД
Устройство ЦОД удобно рассматривать как четыре взаимозависимых слоя. Такое деление помогает не потерять инженерные требования при выборе серверов и не строить дорогую площадку без понятной ИТ-нагрузки.
Здание, помещения и физические зоны
На первом слое находятся участок, оболочка здания, машинные залы, технические помещения, зоны разгрузки, склад, диспетчерская и маршруты перемещения оборудования. Для модульного или контейнерного ЦОД часть этих функций объединена в заводском блоке, но требования к размещению, безопасности и обслуживанию никуда не исчезают.
В машинном зале устанавливают стойки ЦОД. При планировке учитывают их габариты и массу, ширину проходов, кабельные трассы, направление воздушных потоков, точки подключения питания и возможность замены крупных узлов. Фальшпол возможен, но не является обязательным признаком дата-центра. Кабели и воздух можно организовать и другими способами.
ИТ-оборудование
В стойках работают серверы, системы хранения данных, коммутаторы, маршрутизаторы, средства информационной безопасности и устройства управления. Их нельзя выбирать независимо друг от друга.
Например, увеличение числа GPU меняет не только вычислительную мощность. Оно влияет на потребление стойки, тепловыделение, массу, число портов, пропускную способность сети и скорость СХД. Базовый состав и критерии подбора разобраны отдельно в материале про серверное оборудование, а назначение разных узлов можно уточнить в классификации серверов.
Инженерные системы
К инженерному слою относятся вводы электроснабжения, распределительные устройства, ИБП, аккумуляторные системы, резервные генераторы, охлаждение, вентиляция, пожарная автоматика, освещение и заземление. Конкретная схема зависит от проектной мощности, допустимого простоя, местных условий и нормативных требований.
У инженерной системы есть как минимум четыре важных свойства: доступная мощность, резервирование, ремонтопригодность и наблюдаемость. Запас в одном месте не компенсирует узкое место в другом. Два генератора не помогут, если оба питают нагрузку через единственный незарезервированный элемент распределения.
Эксплуатация, мониторинг и безопасность
Четвертый слой объединяет людей, процессы и средства управления. Системы BMS контролируют инженерное оборудование здания. DCIM помогает учитывать стойки, мощность, порты, кабели, температуры и доступную емкость. ИТ-мониторинг следит за серверами, сетью, СХД и приложениями.
Как работает ЦОД: путь одного запроса
Работу центра обработки данных проще понять на примере запроса пользователя к корпоративному приложению.
Запрос приходит по сети оператора связи на пограничное оборудование площадки.
Маршрутизаторы, межсетевые экраны и балансировщики направляют трафик к нужному сервису.
Коммутаторы внутри ЦОД передают пакеты вычислительным узлам.
Сервер выполняет приложение на CPU или GPU и при необходимости обращается к оперативной памяти и СХД.
Система хранения возвращает данные, после чего приложение формирует ответ пользователю.
Телеметрия о задержках, ошибках, потреблении и температуре поступает в системы мониторинга.
Параллельно инженерная инфраструктура питает оборудование и отводит выделяемое им тепло.
Эта цепочка показывает, почему «сервер в ЦОД» не является изолированным устройством. Производительность приложения может ограничить вычислительный узел, сеть, накопители или внешнее подключение. Доступность может нарушить не только отказ сервера, но и ошибка маршрутизации, исчерпание мощности, перегрев либо неверное действие при обслуживании.

Как устроено электроснабжение ЦОД
Система электроснабжения ЦОД должна передать нагрузке мощность нужного качества и отработать предусмотренные проектом аварийные сценарии. Упрощенный путь выглядит так:
Электроэнергия поступает от внешней сети через один или несколько вводов.
Вводные и распределительные устройства формируют секции и защищают линии.
ИБП поддерживает критичную нагрузку во время краткого нарушения и на период запуска резервного источника в пределах расчетной автономии.
Генераторная установка принимает нагрузку при длительном исчезновении внешнего питания, если такой сценарий заложен и успешно отработан.
Шинопроводы или кабельные линии подводят питание к рядам и стойкам.
Стоечные PDU распределяют его между блоками питания серверов, СХД и сетевых устройств.
Что означают N, N+1 и 2N
Nозначает минимальный набор мощности или компонентов, достаточный для расчетной нагрузки.N+1добавляет один резервный компонент к необходимому набору. Если для нагрузки нужны три модуля, устанавливают четыре.2Nозначает два полных набора, каждый из которых способен обеспечить расчетную нагрузку в заданном режиме.
Эти обозначения нужно читать вместе с границами системы. Формулировка «ИБП N+1» ничего не говорит о резервировании кабельных трасс, распределительных щитов, автоматики и вводов. Для двухблочных серверов часто предусматривают независимые ветви A и B, но схема сохраняет смысл только тогда, когда общие точки отказа найдены и учтены.
Мощность ЦОД также нельзя оценивать только по номиналам блоков питания. Для проекта нужны фактические профили нагрузки, коэффициенты одновременности, пусковые режимы, план роста и допустимые режимы после отказа или во время обслуживания.

Системы охлаждения ЦОД
Почти вся электрическая мощность, потребленная ИТ-оборудованием, в итоге превращается в тепло. Задача охлаждения состоит не в том, чтобы сделать зал как можно холоднее, а в том, чтобы удалить это тепло и удержать параметры среды в пределах, допустимых для конкретного класса оборудования и режима работы.
Воздушное охлаждение
В традиционной схеме холодный воздух подают к входам серверов, а нагретый отводят от их выходов. Стойки обычно ориентируют так, чтобы образовать холодные и горячие коридоры. Изоляция коридоров уменьшает смешивание потоков и помогает использовать доступную холодопроизводительность.
Холод может передаваться через кондиционеры точного контроля, теплообменники, чиллеры, сухие охладители и другие элементы. Набор зависит от климата, плотности нагрузки, режима резервирования и выбранной технологии. Сам термин «кондиционирование ЦОД» не описывает полный тепловой контур.
Жидкостное охлаждение
При высокой плотности стойки воздух становится ограничением по переносу тепла и расходу энергии на вентиляторы. Тогда применяют прямое жидкостное охлаждение компонентов, задние дверцы с теплообменниками или другие жидкостные контуры. В схеме direct-to-chip теплоноситель подходит к холодным пластинам на процессорах и ускорителях, а CDU разделяет контуры и управляет параметрами теплообмена.
Жидкостная система не отменяет воздух автоматически. Память, накопители, блоки питания и сетевые устройства могут сохранять воздушное тепловыделение. Проект должен отдельно учитывать долю тепла, которую забирает жидкость, остаточную нагрузку на зал, качество воды или теплоносителя, обнаружение утечек, сервисные соединения и аварийные режимы.
Для приемки плотной стойки недостаточно увидеть среднюю температуру помещения. Нужны данные на входах оборудования, перепад давления, расход, температуры подачи и возврата, мощность во времени и поведение при переключениях. Практический состав проверки приведен в протоколе испытаний охлаждения GPU-сервера.
Сеть, каналы связи и хранение данных
Сетевая инфраструктура ЦОД соединяет пользователей, вычислительные узлы и системы хранения. На крупной площадке могут быть независимые вводы операторов связи, помещения взаимного соединения, пограничный контур и внутренняя фабрика передачи данных.
Архитектуру leaf-spine часто применяют там, где нужен предсказуемый путь между большим числом стоек. Это не обязательная схема для любого дата-центра. Небольшая корпоративная площадка может использовать двухуровневую сеть. Выбор определяется числом портов, направлениями трафика, требованиями к задержке, отказоустойчивостью и планом расширения.
Производственную сеть, доступ к хранению и контур управления нередко разделяют логически или физически. Такое разделение уменьшает взаимное влияние трафика и помогает ограничивать последствия ошибок. Принцип работы оборудования и критерии выбора раскрыты в статье о сетевых коммутаторах. Для готового проекта можно использовать раздел сетевого оборудования для AI, но число и тип портов нужно рассчитывать по топологии.
Данные могут находиться на локальных накопителях серверов, в централизованной СХД, программно определяемом хранилище или объектной системе. Выбор между блочным, файловым и объектным доступом зависит от приложений. Отдельный разбор приведен в материале о видах и архитектуре СХД, а доступные классы решений собраны в разделе систем хранения данных.
Физическая защита и пожарная безопасность
Безопасность ЦОД строится слоями. Периметр ограничивает доступ к территории, пропускной пункт проверяет людей и транспорт, а система контроля доступа определяет, кто может войти в конкретную зону. Видеонаблюдение, охранная сигнализация и журналирование помогают расследовать события. Для особо чувствительных площадок добавляют раздельные зоны доступа и правило сопровождения.
Физическую безопасность нельзя смешивать с кибербезопасностью. Замок на стойке не исправит открытую административную сеть, а межсетевой экран не защитит кабель от физического повреждения. Оба направления входят в модель угроз, но требуют разных мер и ответственных.
Пожарная безопасность включает раннее обнаружение, оповещение, локализацию, безопасное отключение по проектному сценарию и тушение. Конкретный состав датчиков и огнетушащее вещество выбирают по нормативам, типу помещения, рискам для людей и оборудования. Универсальной системы пожаротушения ЦОД, подходящей любой площадке, нет.
Какие бывают виды ЦОД
Классификация ЦОД зависит от того, по какому признаку их сравнивают: владельцу, масштабу, способу исполнения или назначению.
Вид | Особенность | Типичный сценарий |
|---|---|---|
Корпоративный | площадка принадлежит одной организации и работает под ее задачи | банки, промышленность, государственные и крупные корпоративные системы |
Коммерческий colocation | оператор предоставляет стойки, залы, питание, охлаждение и подключения | размещение собственного оборудования без строительства своей площадки |
Облачный или hyperscale | большая стандартизованная инфраструктура обслуживает облачные платформы и массовые сервисы | эластичные вычисления, хранение и управляемые сервисы |
Edge ЦОД | ресурсы размещены ближе к источнику данных или пользователю | низкая задержка, локальная обработка, связь и промышленная автоматизация |
Модульный или контейнерный | системы собраны в типовых заводских модулях | поэтапный ввод мощности, удаленные объекты, ограниченные сроки строительства |
HPC и AI ЦОД | высокая плотность вычислений, быстрые сети и повышенные требования к отводу тепла | моделирование, обучение нейросетей, RAG и массовый инференс |
Классы ЦОД и уровни Tier
Пользователи часто ищут «класс ЦОД», «уровни ЦОД» и «ЦОД Tier» как одно понятие. На практике сначала нужно назвать систему классификации и орган, который подтвердил соответствие. Маркетинговая фраза «уровень Tier III» не равна действующему сертификату объекта.
Система Uptime Institute описывает четыре уровня инфраструктуры площадки:
Уровень | Официальное название | Смысл требования |
|---|---|---|
Tier I | Basic Capacity | базовая инфраструктура для поддержки ИТ-нагрузки |
Tier II | Redundant Capacity Components | к базовой схеме добавлены резервные компоненты мощности |
Tier III | Concurrently Maintainable | каждый компонент и путь, требующий планового обслуживания, можно вывести без остановки ИТ-операций в предусмотренных условиях |
Tier IV | Fault Tolerant | инфраструктура должна сохранять ИТ-операции после отдельного отказа в пределах критериев стандарта |
Tier не следует переводить в обещание определенного числа минут простоя по старым интернет-таблицам. Uptime Institute не использует такие расчетные проценты как часть актуального Tier Standard. Уровень также не оценивает производительность приложения, кибербезопасность, качество кода или готовность резервной копии.
Tier IV нужен не каждому проекту. Более высокий уровень повышает сложность, стоимость строительства и эксплуатации. Обоснованный класс ЦОД выбирают по последствиям остановки, допустимым окнам обслуживания, резервной площадке и экономике сервиса.
Кроме системы Uptime Institute, существует стандарт TIA-942, охватывающий телекоммуникации, электропитание, охлаждение, архитектуру, пожарную и физическую безопасность. Обозначения разных систем не нужно считать взаимозаменяемыми. В техническом задании следует указать точный стандарт, редакцию, границы оценки и необходимость независимой сертификации.
Что такое PUE и что этот показатель не измеряет
PUE, или Power Usage Effectiveness, показывает отношение всей энергии, потребленной центром обработки данных, к энергии ИТ-оборудования за один и тот же период:
PUE = общая энергия ЦОД / энергия ИТ-оборудования
В актуальной ISO/IEC 30134-2 показатель определяется для 12-месячного периода. Чем меньше инфраструктурные потери при той же полезной ИТ-нагрузке, тем ближе результат к единице. Но сравнивать две площадки по одной цифре опасно. На PUE влияют климат, загрузка, границы измерения, резервирование и технология охлаждения.
PUE не показывает:
производительность приложения на ватт;
доступность сервиса;
водопотребление;
углеродную интенсивность электроэнергии;
надежность резервного копирования;
эффективность использования серверов.
Как проектируют, строят и вводят ЦОД
Строительство ЦОД начинается не с выбора ИБП или серверного шкафа. Сначала фиксируют бизнес-сервисы и допустимые последствия отказов. Затем переводят их в технические параметры.
1. Сбор требований
Нужно определить:
какие приложения и данные будут размещены;
требуемые RPO, RTO и окна обслуживания;
текущую ИТ-мощность и прогноз роста;
плотность нагрузки по стойкам;
типы сетевых подключений и требуемую пропускную способность;
ограничения по территории, зданию и коммуникациям;
требования к безопасности, аттестации и сертификации;
этапы ввода и бюджет жизненного цикла.
2. Концепция и проект
На этом этапе выбирают площадку, формируют планировку, однолинейную схему электроснабжения, тепловой контур, сетевую архитектуру, систему пожарной защиты и модель мониторинга. Проект проверяют не только на штатный режим, но и на обслуживание, частичную загрузку, единичные отказы и дальнейшее расширение.
3. Поставка, монтаж и интеграция
Инженерные и ИТ-системы монтируют по согласованным схемам. Для серверов, СХД и сети нужен точный перечень оборудования, версии микропрограмм, кабельный журнал, адресный план и схема размещения. Изменения должны попадать в исполнительную документацию, иначе реальный объект быстро расходится с проектом.
4. Пусконаладка и комплексные испытания
Отдельно исправные компоненты еще не доказывают работоспособность ЦОД. Проверяют совместное поведение: исчезновение внешней сети, запуск генератора, переключение ветвей, отказ модуля охлаждения, потерю канала связи, срабатывание сигнализации и работу персонала по регламенту. Нагрузочные испытания проводят в контролируемых условиях по утвержденной программе.
5. Эксплуатация
После ввода начинаются управление емкостью, профилактика, обновления, резервные копии конфигураций, тренировки аварийных процедур и анализ инцидентов. Любое изменение оценивают по влиянию на питание, охлаждение, сеть, безопасность и общие точки отказа.

Как выбрать между собственным ЦОД, colocation и облаком
Решение нельзя принимать только по цене стойки или стоимости серверов. Сравнивать нужно одинаковый горизонт и один уровень сервиса.
Собственный ЦОД имеет смысл, когда нагрузка крупная и стабильная, нужен полный физический контроль, действуют особые ограничения по данным либо доступна площадка с подходящими энергоресурсами. Заказчик при этом принимает на себя проектирование, капитальные расходы, эксплуатацию и управление запасом мощности.
Colocation подходит, если компания хочет владеть аппаратной платформой, но не строить инженерный объект. При выборе проверяют доступную мощность на стойку, фактическую схему резервирования, тип охлаждения, операторов связи, правила доступа, сроки расширения и границы ответственности.
Облако удобно для быстрого старта, переменной нагрузки и сервисов, которые выгоднее потреблять по запросу. Следует заранее рассчитать стоимость постоянной загрузки, сетевой трафик, переносимость данных, доступные типы ускорителей и зависимость от сервисов провайдера.
Для сравнения полезен единый набор сценариев:
штатная загрузка сегодня и через три года;
отказ компонента или канала;
плановое обслуживание;
резкий рост потребления;
перенос данных на другую площадку;
завершение договора или смена архитектуры.
Чем отличается ЦОД для искусственного интеллекта
ЦОД для ИИ подчиняется тем же базовым принципам, но меняет масштаб отдельных требований. Современные GPU-системы концентрируют высокую электрическую и тепловую нагрузку в стойке. Для распределенного обучения нужна сеть с высокой пропускной способностью и предсказуемой задержкой. Подготовка данных создает интенсивную нагрузку на СХД.
Поэтому проект AI-инфраструктуры начинается с модели или приложения, а заканчивается проверкой всей площадки:
сколько GPU требуется и как они связаны внутри узла;
какой объем данных должен поступать на ускорители;
какой трафик возникает между узлами;
сколько киловатт потребляет стойка в устойчивом и переходном режимах;
какую часть тепла снимает жидкость, а какую воздух;
можно ли доставить, установить и обслужить тяжелую rack-scale систему;
как будет расти кластер без полной перестройки электрики и сети.
Реальный масштаб связи между вычислениями и инженерией показывает проект многостоечного GPU-кластера для обучения собственной LLM. В описании проекта расчетная электрическая мощность комплекса указана на уровне около 350 кВт. Итоговая раскладка по стойкам при такой нагрузке зависит от доступного питания и способа отвода тепла.

Типичные ошибки при создании и выборе ЦОД
Считать резервные устройства вместо путей
Два ИБП или два коммутатора могут зависеть от одной шины, одной трассы или общей системы управления. Анализировать нужно цепочку целиком и явно отмечать общие точки отказа.
Проектировать по паспортному максимуму без профиля нагрузки
Слепое суммирование номиналов завышает часть систем, но может пропустить кратковременный пик или нештатный режим. Нужны измерения, сценарии и прозрачные коэффициенты.
Выбирать охлаждение по средней температуре зала
Среднее значение скрывает горячую точку на входе конкретного сервера. Контроль строят по стойкам, рядам, потокам воздуха или жидкости и режимам отказа.
Путать Tier с доступностью приложения
Инфраструктурная площадка может соответствовать высокому уровню, а сервис останавливаться из-за ошибки приложения, базы данных или сети. Отказоустойчивость программного стека проектируется отдельно.
Оставлять приемку на конец проекта
Если сценарии испытаний не определены в техническом задании, некоторые режимы невозможно безопасно проверить после запуска. Программа приемки должна появиться вместе с архитектурой.
Не планировать расширение
Свободное место в стойках не означает наличие электрической, холодильной и сетевой мощности. Емкость учитывают по всем ресурсам одновременно.
Чек-лист требований к ЦОД
Перед проектированием собственной площадки или запросом услуги colocation соберите следующие данные:
Перечень сервисов, их критичность, RPO и RTO.
Число стоек, масса и габариты оборудования.
Текущая и прогнозная мощность каждой стойки.
Тип охлаждения и параметры на границе ответственности.
Количество сетевых вводов, операторов, портов и требуемая пропускная способность.
Объем рабочих данных, резервных копий и прогноз роста.
Требования к физическому доступу и информационной безопасности.
Требуемый стандарт, редакция и границы сертификации.
Сценарии планового обслуживания и отказов.
Программа комплексных испытаний и критерии приемки.
Регламент мониторинга, эскалации и восстановления.
План расширения по мощности, охлаждению, площади и сети.
Частые вопросы
ЦОД, что это простыми словами?
ЦОД представляет собой специально подготовленную площадку для серверов, хранения и сетевого оборудования. Вместе с ИТ-техникой работают питание, охлаждение, пожарная защита, безопасность и мониторинг.
Как расшифровывается ЦОД?
Аббревиатура ЦОД расшифровывается как «центр обработки данных». Также употребляют слова «дата-центр» и английское data center.
Что относится к ЦОД?
К ЦОД относятся здание или модуль, машинные залы, стойки, серверы, СХД, сеть, электрическая и холодильная инфраструктура, пожарные системы, физическая защита, мониторинг и эксплуатационные процессы. Граница конкретного объекта фиксируется в проекте.
Как устроен ЦОД?
В центре обработки данных есть четыре связанных слоя: физическая площадка, ИТ-оборудование, инженерные системы и эксплуатация. Работоспособность сервиса зависит от каждого слоя.
Как работает ЦОД?
Сеть принимает запрос и передает его серверу. Сервер выполняет приложение и обращается к хранилищу. Инженерные системы непрерывно подают питание и отводят тепло, а мониторинг контролирует состояние компонентов.
Чем ЦОД отличается от серверной?
Разница определяется не числом серверов, а полнотой инженерной архитектуры и процессов. У ЦОД обычно формализованы зоны, резервирование, мониторинг, обслуживание, управление емкостью и требования к доступности. Хорошо спроектированная серверная может обладать частью этих свойств.
Какие бывают виды ЦОД?
Выделяют корпоративные, коммерческие colocation, облачные и hyperscale, периферийные edge, модульные, контейнерные, HPC и AI ЦОД. Классы пересекаются, поэтому один объект может одновременно быть корпоративным, модульным и предназначенным для AI.
Что означает Tier в ЦОД?
Tier является системой классификации инфраструктуры площадки Uptime Institute. Уровни идут от базовой мощности Tier I до отказоустойчивой инфраструктуры Tier IV. Уровень не заменяет оценку приложения, кибербезопасности и резервного копирования.
Что такое облачный ЦОД?
Это физическая инфраструктура, на которой провайдер оказывает облачные услуги. Пользователь управляет выделенными ресурсами и сервисами через программные интерфейсы, не обслуживая здание и большую часть аппаратной платформы.
Что такое PUE в ЦОД?
PUE равен отношению общей энергии дата-центра к энергии ИТ-оборудования за одинаковый период. Он показывает инфраструктурные энергозатраты, но не измеряет доступность или полезную производительность приложений.
Можно ли поставить любой сервер в ЦОД?
Нет. Нужно проверить формат стойки, глубину и массу, разъемы и ветви питания, потребление, воздушный поток или жидкостный контур, сетевые интерфейсы и правила площадки. Для плотных GPU-систем согласование начинают до закупки.
Что передать для расчета инфраструктуры
Если известны только число серверов и их общая мощность, этого мало для надежного проекта. Нужны профиль приложений, схема сети, требования к хранению, режимы нагрузки, габариты, тепловой контур, RPO, RTO и план роста.
Start Server помогает спроектировать и поставить вычислительные узлы, СХД и сеть с учетом площадки. Передайте исходные данные для подготовки архитектуры, точного перечня оборудования, схемы подключений и программы испытаний. Начать можно с каталога серверного оборудования, а затем проверить выбранную конфигурацию по всем ограничениям ЦОД.
Получить консультацию
Оставьте заявку и наш менеджер свяжется с вами для консультации









