Итак, у компании возникла потребность в ЦОД. Работать с коммерческим или создавать свой? Свой – в уже имеющемся здании или модульный, с нуля? Чем руководствоваться? Ответы на эти вопросы читайте в данной статье.
В настоящее время данные, получаемые самым различным образом, приобретают всё бóльшую ценность для организаций и ведомств, и конечно же, встает вопрос их хранения и обработки. В мире, и в том числе в России, уже имеется много центров обработки данных (далее – ЦОД) как коммерческих, так и созданных различными компаниями и ведомствами для собственных нужд. Какой путь выбрать организации, решившей обрабатывать свои данные в ЦОД? Обратиться в уже функционирующий центр, с репутацией, или же создавать с нуля корпоративный, то есть свой?
Давайте прежде всего разберемся, чем они различаются, а далее поговорим о нюансах создания собственного ЦОД.
Корпоративный центр обработки данных, конечно же, отличается от коммерческого, хотя и сходства тоже предостаточно. Три основные отличия корпоративного ЦОД от коммерческого.
Есть и другие различия, можно список продолжить, но сказанного выше достаточно для понимания того, что коммерческий и корпоративный ЦОД – это разные объекты. Обычно надежность корпоративного ЦОД выше, а обслуживание инженерной инфраструктуры (ИИ) коммерческого ЦОД лучше и реализуется быстрее.
У организации возникает потребность в создании корпоративного ЦОД по ряду причин, назовем основные.
Рассмотрим возможные варианты.
Построить свой собственный ЦОД. Риски, которые возникают в случае такого решения и которые надо попытаться сразу нивелировать:
Основные возможности, которые предоставляет собственный ЦОД:
Арендовать себе ЦОД у коммерческого оператора в виде стойко-мест, или даже в виде выделенного машинного зала, или в виде необходимых сервисов в облаке. Риски, которые могут возникнуть:
Возможности, возникающие при размещении ЦОД у оператора:
Можно пойти по любому пути или выбрать гибридный вариант.
При принятии решений хорошая практика – опираться на требования и рекомендации нормативных документов в профильной или в смежных областях, причем не только российских, но и международных, американских или других национальных стандартов.
Стандарты – это правила, рекомендованные для применения в случае решения той или иной задачи, подготовленные профессионалами, которые уже сталкивались с такой же или похожей проблемой. Основаны стандарты на лучших практиках, в результате применения которых задача решалась успешно.
Стандарты в РФ – условно бесплатные, вы можете их получить в свободном доступе. Стандарты ISO, TIA и BICSI платные, но обычно предыдущую версию стандарта можно легко найти в свободном доступе, чтобы ознакомиться и понять, есть ли смысл покупать текущую версию.
В основном стандарты отвечают нам на вопросы, как спроектировать и сделать ЦОД, чтобы все было правильно, на какой уровень инженерной инфраструктуры мы бы хотели сориентироваться, чтобы получить соответствующий уровень безопасности.
Если поднять российскую нормативную базу стандартов ЦОД, то мы увидим следующие документы.
Стандарты, разработанные техническим комитетом ТК 120 "Центры обработки данных":
Стандарты, разработанные техническим комитетом ТК22 "Информационные технологии":
В этом году начал действовать свод правил (СП), разработанный АО "ЦНИИПромзданий" и ТК 465, – СП 541.1325800.2024 "Здания и сооружения центров обработки данных. Правила проектирования".
Свод правил распространяется на проектирование зданий и сооружений центров обработки данных, а также помещений центров обработки данных в составе зданий, в том числе описаны требования пожарной безопасности.
В частности, приводятся противопожарные требования к инженерным системам и оборудованию зданий и помещений центров обработки данных.
Например, в этом СП наконец-то решен вопрос с тем, нужно ли отключать систему кондиционирования при срабатывании системы автоматического газового пожаротушения (допускается не отключать, при выполнении ряда условий, см. п.8.3.3 СП).
Если мы говорим про международные стандарты, то это стандарты ISO. Комитет ISO/IEC JTC 1/SC 39 Sustainability, IT and data centres разработал следующие нормативные документы:
Обычно данные для разработки международных стандартов берутся из хорошо проработанных и обкатанных национальных стандартов, какими, например, являются американские стандарты.
Основной стандарт относительно инженерной инфраструктуры ЦОД – Telecommunications Infrastructure Standard for Data Centers TIA-942-С, новая версия которого вышла в 2024 г. Он интересен своей классификацией ЦОД от объектов уровня Rated-1 до объектов уровня Rated-4, приведенной в приложении. Требования приведены по каждой инженерной подсистеме из состава ИИ ЦОД в удобной табличной форме. Приложение ANNEX F (INFORMATIVE) DATA CENTER INFRASTRUCTURE RATING – Architecture, Electrical, Mechanical, Telecommunications.
Существует стандарт ANSI/BICSI 002-2024 – The Standard for Data Center Design, в котором, опять же в приложении Appendix B Reliability and Availability (Informative), ЦОД разделяются на классы от Class 0 до Class 4. Стандарт очень полный, основан на реальных практических кейсах, которые могут быть применены для достижения хорошего результата при проектировании и строительстве ЦОД.
Еще одна широко известная группа стандартов – это требования консалтинговой компании Uptime Institute, которая разделяет ЦОД по уровням от Tier I до Tier IV, а также оказывает услуги по сертификации ЦОД по этим уровням. Uptime Institute сертифицирует ЦОД по следующим направлениям:
Сертификации Uptime Institute платные и проводятся только специалистами Uptime Institute. Очень часто можно увидеть утверждение что, например, ЦОД соответствует уровню Tier III Uptime Institute, без сертификата; скорее всего, если реальная сертификация не проводилась, это утверждение будет ошибочным.
Для начала следует получить ответ на вопрос, какой ЦОД нужен, и первая задача, которую требуется решить, – определить масштаб будущего корпоративного ЦОД и, при необходимости, количество таких центров.
Основной инициатор создания и потребитель услуг корпоративного ЦОД – это ИТ-отдел или ИТ-департамент предприятия. Обычно именно они инициируют работу над проектом ЦОД.
Для того чтобы определить масштаб будущего ЦОД, проще всего оттолкнуться от текущих потребностей в размещении ИТ-оборудования, которые ИТ-отдел прекрасно знает, и определить будущие потребности в размещении этого оборудования на перспективу срока службы ЦОД.
Для начала, собственно, нужно определить сам срок службы ЦОД, обычно он составляет от 7 до 15 лет. Далее необходимо совместно с коллегами из бизнес-департамента понять перспективы роста вашей организации на этот срок: предполагаемый рост масштабов бизнеса, темпы роста, планы открытия новых филиалов, увеличения сотрудников (показатели бизнеса, которые связаны или могут быть связаны с увеличением ИТ-нагрузки).
Компании развиваются по-разному, у кого-то линия роста может быть экспонентой, у кого-то прямой, а кто-то уже вышел на плато и практически не растет. Так как срок службы ЦОД достаточно велик, а риски того, что за это время экспонента роста бизнеса сменится прямой или прямая сменится плато, существуют, то ориентироваться лучше на максимально реальный сценарий, согласованный с бизнес-потребностями. Допустим, вы заложите 20%-ный рост бизнеса и такой же рост ИТ-нагрузки, тогда ваш ЦОД за 15 лет своего существования должен будет масштабироваться от одной стойки с ИТ-оборудованием до двенадцати.
У ЦОД есть одно прекрасное свойство: они тоже умеют масштабироваться как по количеству стоек, так и по количеству машзалов, и даже по количеству ЦОД, так что и в случае экспоненциального роста есть вероятность справиться, к тому же коммерческие ЦОД с этим с удовольствием помогут.
С масштабом нашего ЦОД мы определились, а теперь попробуем определиться с количеством ЦОД, или, скажем так, локаций для размещения оборудования.
Коллеги из одного крупного банка привели простой, понятный пример –организацию резервирования базы данных на Oracle (таких баз на практике подавляющее большинство), аналогичная схема будет на PostgreSQL, который оказался в существующей реальности прекрасной альтернативой.
Две базы данных с резервированием не могут гарантировать того, что ваши данные будут в целости и сохранности. Если нарушится связь между ними (они перестанут видеть друг друга) и при этом обе базы останутся рабочими, то в этих базах возникнут разные записи, что приведет к тому, что при восстановлении связи между узлами база данных перестанет работать, понадобится достаточно много времени, чтобы восстановить ее целостность. Чтобы избежать такой ситуации, вводят третий узел – арбитр, который поддерживает связь с базами данных, и в случае, если база данных теряет связь и с арбитром, и с другой базой данных, она просто отключается и не создает записи.
Важно, чтобы эти узлы находились в разных локациях, например в трех разных шкафах или, что гораздо лучше, в трех разных ЦОД. Причем узел-арбитр не требует большой вычислительной мощности и вполне может быть вынесен просто в отдельный микро-ЦОД или в коммерческий ЦОД. То есть в идеальной ситуации нам нужно минимум три географически разнесенные локации, или ЦОД.
Вернемся к стандартам и посмотрим на ГОСТ Р 58811–2020 "ЦОД ИИ. Стадии создания", где описаны последовательные этапы создания ЦОД. Тут приведен общий случай, на практике некоторые этапы исключают или объединяют. Например, есть стадии "проектная и рабочая документация", но в случае, если у нас не капитальное строительство, стадия П нам не понадобится, можно обойтись одностадийным проектированием, допустим если мы предполагаем установку модульного ЦОД.
Крайне не рекомендуется пропускать этап разработки технической концепции. Правильно разработанная техническая концепция позволит в дальнейшем сократить время на проектирование и добавит уверенности и реальных обоснований того, что решение выбрано правильно.
Этап разработки технической концепции описан в ГОСТ Р 70627–2023 "Инженерная инфраструктура. Документация. Техническая концепция. Требования к составу и содержанию".
Чем хороша техническая концепция? Техническая концепция (ТК) – комплект документов, предназначенных для описания вариантов реализации ИИ ЦОД и обоснования выбора варианта, удовлетворяющего требованиям заказчика.
Стоимость разработки этого документа не очень большая, но при этом вы получите подробный план реализации нескольких вариантов ЦОД, например, сможете рассмотреть все плюсы и минусы покупки и установки модульного ЦОД или строительства ЦОД в существующем капитальном здании.
В концепции будет проведена оценка преимуществ и недостатков каждого варианта, сопоставление требований заказчика и характеристик предлагаемой ИИ ЦОД и выбор оптимального варианта, а также будет посчитана стоимость реализации и дальнейшей эксплуатации разных вариантов ЦОД. Имея этот документ, можно предметно общаться с руководством/владельцами предприятия на тему создания корпоративного ЦОД на понятном им языке цифр бюджетов: капитальные затраты/CAPEX будут такими, операционные затраты/OPEX будут вот такие, а совокупная стоимость владения будет вот такая.
Отдельно хотелось бы остановиться на выборе варианта технической реализации корпоративного ЦОД в разрезе, что делать – ЦОД модульный или в капитальном строении.
Могут быть ситуации, когда варианты отсутствуют: например, у заказчика нет территории предприятия, чтобы поставить модульный ЦОД (далее – МЦОД) или, наоборот, территории много, но это, допустим, карьер с небольшим АБК, в котором еле-еле помещается персонал, – тут без вариантов придется делать МЦОД.
А если можно сделать и так, и так, то придется рассмотреть, как минимум основные плюсы и минусы разных решений. Попробуем исключить то, что в этих ЦОД будет равноценно, и понять, в чем будут заключаться базовые различия.
Количество и мощность стоек в обоих ЦОД примем одинаковые. Тогда:
А где же различия?
Основное различие – это конструктив.
В модульном ЦОД производитель путем расчетов и экспериментов подобрал оптимальные параметры для того, чтобы обеспечить оптимальные условия для работы и оборудования и персонала.
В ЦОД внутри капитального здания вы всегда заложник существующего ограничения конфигурации помещения – размеров, высоты, несущей способности перекрытия, защиты от протечек, транзитных коммуникаций и т.д. То есть в уже имеющемся здании вы приспосабливаетесь под существующие ограничения, за счет чего снижается надежность и очень часто – функциональность инженерных систем.
Второй немаловажный момент: МЦОД собирается и тестируется на заводе, надежность решения значительно выше, но есть и минус: гибкость такого решения ниже, производитель не пойдет на установку "любого" оборудования, там будут только проверенные решения.
Как раз установка "любого хорошего" (разрекламированного) оборудования в ЦОД внутри капитального здания несет основные риски того, что система "не полетит" (не будет работать как планировалось), так как обычно интегратора и проектировщика уговорить что-то поменять гораздо проще, чем производителя модульного ЦОД.
ИИ ЦОД консервативна, любит проверенные решения, и новым производителям оборудования доверие надо заслужить как минимум путем заводского тестирования различных конфигураций и режимов работы.
Стоимость реализации МЦОД обычно выше на 20–50% стоимости реализации ЦОД в существующем капитальном здании, но надежность и эффективность МЦОД, как правило, лучше (тут тоже вопрос выбора производителя немаловажен).
И есть еще один момент: выбрав МЦОД, можно получить экономию времени за счет сокращения сроков проектирования и экономию на сроках проведения строительно-монтажных (СМР) и пусконаладочных (ПНР) работ за счет высокой заводской готовности МЦОД.
В качестве резюме хотелось бы отметить следующее:
Многое зависит от масштаба создаваемого ЦОД и времени, которое заказчик готов потратить на реализацию проекта.
Строительство ЦОД – достаточно затратная статья расходов в бюджете организации, и если нет времени, лучше рассмотреть установку ИТ-оборудования в коммерческом ЦОД сейчас с тем, чтобы найти время на тщательную проработку решения и реализацию собственного корпоративного ЦОД.
Опубликовано в журнале "Системы безопасности" № 2/2025
Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>
Изображение сгенерировано нейросетью Kandinsky