Журнал "Системы Безопасности" № 2‘2025

К О М П Л Е К С Н А Я Б Е З О П А С Н О С Т Ь , П Е Р И М Е Т Р О В Ы Е С И С Т Е М Ы 115 ального роста есть вероятность справиться, к тому же коммерческие ЦОД с этим с удоволь- ствием помогут. Количество С масштабом нашего ЦОД мы определились, а теперь попробуем определиться с количе- ством ЦОД, или, скажем так, локаций для раз- мещения оборудования. Коллеги из одного крупного банка привели про- стой, понятный пример –организацию резерви- рования базы данных на Oracle (таких баз на практике подавляющее большинство), анало- гичная схема будет на PostgreSQL, который ока- зался в существующей реальности прекрасной альтернативой. Две базы данных с резервированием не могут гарантировать того, что ваши данные будут в целости и сохранности. Если нарушится связь между ними (они перестанут видеть друг друга) и при этом обе базы останутся рабочими, то в этих базах возникнут разные записи, что при- ведет к тому, что при восстановлении связи между узлами база данных перестанет рабо- тать, понадобится достаточно много времени, чтобы восстановить ее целостность. Чтобы избежать такой ситуации, вводят третий узел – арбитр, который поддерживает связь с базами данных, и в случае, если база данных теряет связь и с арбитром, и с другой базой данных, она просто отключается и не создает записи. Важно, чтобы эти узлы находились в разных локациях, например в трех разных шкафах или, что гораздо лучше, в трех разных ЦОД. Причем узел-арбитр не требует большой вычислитель- ной мощности и вполне может быть вынесен просто в отдельный микроЦОД или в коммер- ческий ЦОД. То есть в идеальной ситуации нам нужно минимум три географически разнесен- ные локации, или ЦОД. Вернемся к стандартам и посмотрим на ГОСТ Р 58811–2020 "ЦОД ИИ. Стадии создания", где описаны последовательные этапы создания ЦОД. Тут приведен общий случай, на практике некоторые этапы исключают или объединяют. Например, есть стадии "проектная и рабочая документация", но в случае, если у нас не капи- тальное строительство, стадия П нам не пона- добится, можно обойтись одностадийным про- ектированием, допустим если мы предполагаем установку модульного ЦОД. Разработка технической концепции Крайне не рекомендуется пропускать этап раз- работки технической концепции. Правильно разработанная техническая концепция позволит в дальнейшем сократить время на проектиро- вание и добавит уверенности и реальных обоснований того, что решение выбрано пра- вильно. Этап разработки технической концепции опи- сан в ГОСТ Р 70627–2023 "Инженерная инфра- структура. Документация. Техническая концеп- ция. Требования к составу и содержанию". Чем хороша техническая концепция? Техническая концепция (ТК) – комплект документов, предна- значенных для описания вариантов реализации ИИ ЦОД и обоснования выбора варианта, удов- летворяющего требованиям заказчика. Стоимость разработки этого документа не очень большая, но при этом вы получите подробный план реализации нескольких вариантов ЦОД, например, сможете рассмотреть все плюсы и минусы покупки и установки модульного ЦОД или строительства ЦОД в существующем капи- тальном здании. В концепции будет проведена оценка преиму- ществ и недостатков каждого варианта, сопо- ставление требований заказчика и характери- стик предлагаемой ИИ ЦОД и выбор опти- мального варианта, а также будет посчитана стоимость реализации и дальнейшей эксплуа- тации разных вариантов ЦОД. Имея этот доку- мент, можно предметно общаться с руковод- ством/владельцами предприятия на тему соз- дания корпоративного ЦОД на понятном им языке цифр бюджетов: капитальные затраты/CAPEX будут такими, операционные затраты/OPEX будут вот такие, а совокупная стоимость владения будет вот такая. Технический аспект реализации корпоративного ЦОД Отдельно хотелось бы остановиться на выборе варианта технической реализации корпоратив- ного ЦОД в разрезе, что делать – ЦОД модуль- ный или в капитальном строении. Могут быть ситуации, когда варианты отсут- ствуют: например, у заказчика нет территории предприятия, чтобы поставить модульный ЦОД (далее – МЦОД) или, наоборот, территории много, но это, допустим, карьер с небольшим АБК, в котором еле-еле помещается персонал, – тут без вариантов придется делать МЦОД. А если можно сделать и так, и так, то придется рассмотреть, как минимум основные плюсы и минусы разных решений. Попробуем исключить то, что в этих ЦОД будет равноценно, и понять, в чем будут заключаться базовые различия. Количество и мощность стоек в обоих ЦОД примем одинаковые. Тогда: l для системы основного, гарантированного и бесперебойного электропитания решения будут примерно одинаковые; l для системы охлаждения и вентиляции реше- ния также будут примерно одинаковые; l СКС внутри ЦОД – аналогично, одинаковые решения; l системы физической безопасности – одина- ковые; l системы пожарной безопасности – примерно одинаковые. А где же различия? Основное различие – это конструктив. В модульном ЦОД производитель путем рас- четов и экспериментов подобрал оптимальные параметры для того, чтобы обеспечить опти- мальные условия для работы и оборудования и персонала. В ЦОД внутри капитального здания вы все- гда заложник существующего ограничения конфигурации помещения – размеров, высоты, несущей способности перекрытия, защиты от протечек, транзитных коммуника- ций и т.д. То есть в уже имеющемся здании вы приспосабливаетесь под существующие ограничения, за счет чего снижается надеж- ность и очень часто – функциональность инженерных систем. Второй немаловажный момент: МЦОД собира- ется и тестируется на заводе, надежность реше- ния значительно выше, но есть и минус: гиб- кость такого решения ниже, производитель не пойдет на установку "любого" оборудования, там будут только проверенные решения. Как раз установка "любого хорошего" (разрек- ламированного) оборудования в ЦОД внутри капитального здания несет основные риски того, что система "не полетит" (не будет рабо- тать как планировалось), так как обычно интег- ратора и проектировщика уговорить что-то поменять гораздо проще, чем производителя модульного ЦОД. ИИ ЦОД консервативна, любит проверенные решения, и новым производителям оборудова- ния доверие надо заслужить как минимум путем заводского тестирования различных кон- фигураций и режимов работы. Стоимость реализации МЦОД обычно выше на 20–50% стоимости реализации ЦОД в суще- ствующем капитальном здании, но надежность и эффективность МЦОД, как правило, лучше (тут тоже вопрос выбора производителя нема- ловажен). И есть еще один момент: выбрав МЦОД, можно получить экономию времени за счет сокраще- ния сроков проектирования и экономию на сро- ках проведения строительно-монтажных (СМР) и пусконаладочных (ПНР) работ за счет высо- кой заводской готовности МЦОД. Заключение В качестве резюме хотелось бы отметить сле- дующее: l рассматривать нужно все варианты возмож- ной реализации корпоративного ЦОД, не исключая размещение своего оборудования в коммерческом ЦОД; l резервирование на уровне нескольких ЦОД позволяет снизить требования по отказо- устойчивости инженерной и ИТ-инфраструк- туры отдельного ЦОД; l ЦОД служат годами, при планировании надо учитывать перспективы развития бизнеса; l ЦОД – это очень дорогостоящее вложение средств, ошибки при выборе решения и про- ектировании могут быть очень болезненны- ми, нужно найти время на тщательную про- работку концепции и проекта; l стандарты – это ваши помощники, это своды знаний, разработанные экспертами и профес- сионалами; пользуйтесь ими, чтобы сделать свое решение лучше; - l в ситуации, когда есть выбор, присмотритесь к префаб-решениям (модульным ЦОД). Многое зависит от масштаба создаваемого ЦОД и времени, которое заказчик готов потратить на реализацию проекта. Строительство ЦОД – достаточно затратная статья расходов в бюджете организации, и если нет времени, лучше рассмотреть установку ИТ- оборудования в коммерческом ЦОД сейчас с тем, чтобы найти время на тщательную про- работку решения и реализацию собственного корпоративного ЦОД. n www.secuteck.ru апрель – май 2025 Ваше мнение и вопросы по статье направляйте на ss @groteck.ru