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

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

Каково сегодня положение дел с использованием заказчиками частных облаков и каковы перспективы на будущее? Эти вопросы мы обсудили с рядом экспертов из числа ведущих игроков российского ИТ-рынка.

Есть ли понимание “частного облака” на рынке?

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

“Сегодня частное облако становится собирательным образом того, как должна выглядеть ИТ-инфраструктура современного предприятия, причем образом, понятным не только для ИТ-шников, но и для бизнеса, — развил свою мысль Василий Маланин. — Бизнес может воспринимать облако как некий объект со скрытой внутренней структурой (не важно, как оно устроено), из которого бизнес может получать ИТ-сервисы, причем получать по запросу, оперативно, высококачественно и с предсказуемыми экономическими показателями. Для ИТ-шника облако — это уже описание правильной архитектуры построения ресурсной базы (эластичные пулы, виртуализация, автоматизация и т. д.) и правильных процессов взаимодействия с пользователем (ITSM, каталог сервисов, charge back и т. д.). При этом граница между частным и публичным облаком очень тонкая — в качестве ресурсной базы для предоставления сервисов ИТ-отдел может выбрать как собственные ресурсы, так и арендованные — в зависимости от конкретных задач потребителя”.

Менеджер по развитию бизнеса HP BladeSystem в России Александр Светлаков предложил такую формулировку: частное облако — это такая модель ИТ-инфраструктуры предприятия, при которой приложения и ИТ-ресурсы распространяются внутри предприятия как услуги. “Мы уверены, что в таком общем определении понятие частного облака уже принято большинством участников рынка, а сама модель признана достойной внимания. Об этом говорят сотни случаев ее внедрения по всему миру, — отметил он. — Но иногда еще приходится сталкиваться с недостатком информации на рынке, когда под облаком воспринимают виртуализацию рабочих мест и терминальный доступ к приложениям”.

Директор по работе с ключевыми заказчиками и партнерами компании Tripp Lite Максим Рубаненко считает, что, несмотря на уже довольно длительное обсуждение темы облачных технологий, правильного понимания этого термина у большинства заказчиков нет. “Мы сами понимаем под частным облаком, скорее, принцип организации инфраструктуры заказчика, — заметил эксперт. — Это, по сути, следующий уровень развития корпоративного ЦОДа, когда на базе внедренной технологии виртуализации и переноса на виртуальные серверы корпоративных приложений в виртуальную среду переносят всю или часть пользовательской инфраструктуры. Это и организация в облаке хранения пользовательских данных, и предоставление через облако пользовательских приложений (что обеспечивает гибкость и эффективность использования лицензий на ПО), и полный перенос всей работы пользователей на виртуальные машины в корпоративном ЦОДе (с доступом через сеть как с тонких клиентов, так и с мобильных устройств пользователя). Все это увеличивает нагрузку на оборудование ЦОДа, растет энергопотребление. Результатом является резкий рост требований к инженерной инфраструктуре ЦОДа — надежности и устойчивости энергоснабжения, эффективности системы охлаждения, гибкости системы управления инфраструктуры”.

Преимущества и недостатки частных облаков

Руководитель по стратегическому развитию сервисного бизнеса IBM в России и СНГ Валерий Корниенко уверен, что надежность и безопасность, которые необходимы большому бизнесу, пока могут обеспечить лишь частные, а не публичные облака: “Частное облако — это безопасное и контролируемое решение, стоимость владения которым при этом все равно значительно ниже, чем в случае традиционного ЦОДа, а использование ресурсов — на порядок выше”.

“У нас есть методика расчета ROI проектов по внедрению частного облака, — утверждает Василий Маланин. — Внедрение виртуализации и управления инфраструктурой позволяет достичь быстрых результатов. Экономия на оборудовании, электроэнергии, трудозатратах и избежание рисков позволяет окупить внедрение за несколько месяцев. Сложные сценарии, такие как самообслуживание, charge back и т. д., требуют значительной работы с пользователями и потребителями сервисов облака. Их эффект виден на больших промежутках времени. Но важно, что они позволяют заложить более динамичный стиль работы с ИТ и могут повлиять на основной бизнес компании”.

Говоря о достоинствах частных облаков, Максим Рубаненко отметил: “Во-первых, это безопасность, закрытость конфиденциальной информации от несанкционированного доступа, которые сегодня не могут обеспечить коммерческие ЦОДы. Во-вторых, это управляемость ЦОДа. Собственный дата-центр позволяет настраивать всю инфраструктуру под специфику организации на таком уровне, который в коммерческом центре невозможен либо окажется слишком дорогостоящим дополнительным сервисом. К недостаткам можно отнести необходимость значительных стартовых инвестиций в создание собственного ЦОДа, при том что расходы на его текущее содержание могут быть такими же, как стоимость услуг стороннего оператора. По настоящему безопасная концепция частного облака требует разворачивать его на базе двух-трех территориально распределенных дата-центров. Для малого и среднего бизнеса такие инвестиции, как правило, недоступны”.

Технический директор департамента инфраструктурных решений компании “АйТи” Андрей Синяченко считает, что о преимуществах частного облака уже давно все сказано. Что же касается недостатков, то они нередко являются оборотной стороной достоинств. Например, если сценарии автоматизации предоставления услуг не были достаточно тщательно проработаны на этапе создания облака, то могут возникать ситуации, когда ошибки этих сценариев будут накапливаться, оставаться незамеченными и в итоге приведут к непредсказуемым последствиям. Как любая интеллектуальная автоматизированная система, облако требует тонкой настройки и постоянного внимания администратора.

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

Всем ли заказчикам нужны частные облака?

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

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

А вот Максим Рубаненко считает, что наиболее эффективно применение частных облаков как раз в организациях с большой территориально распределенной структурой. Сотрудники предприятия в удаленном маленьком филиале или мобильные сотрудники подключаются к системе с любого доступного устройства (тонкого клиента или мобильного устройства) и получают доступ к своей виртуальной машине в дата-центре. При этом компании не надо тратиться на обслуживание машин в удаленном офисе, их постоянную модернизацию. Данные изначально централизованы, обеспечена их сохранность и целостность, а также синхронизация. А небольшим компаниям собственное облако не требуется, для них могут быть интересны облачные сервисы от коммерческих операторов.

Менеджер по маркетингу продукции Fujitsu в России и СНГ Павел Борох уверен, что частное облако точно не нужно тем, кто не собирается что-то менять в своей ИТ-инфраструктуре или почему-либо эксплуатирует специфические монолитные неизменяемые решения с предопределенным профилем нагрузки и постоянным кругом пользователей. Либо тем, кто уже готов жить в публичном облаке. Облачные инфраструктуры подразумевают каналы связи с облаком, так что облака также не годятся тем, у кого каналы связи к индивидуальным работникам нестабильны или непостоянны, возможно, в силу специфики деятельности этих работников.

Как сложен переход в частное облако?

Переход в облака очень специфичен для каждой компании, утверждает Валерий Корниенко: “После принятия принципиального решения необходимо исследовать существующую инфраструктуру, протестировать приложения в новом окружении, установить систему управления облаком, провести тестовую миграцию и т. д. Я бы советовал заручиться поддержкой партнера, уже имеющего опыт в этой области, — в этом случае переход не растянется на годы”.

Более оптимистично настроен Андрей Синяченко: “Превратить виртуализованную инфраструктуру ЦОДа в полноценное частное облако технологически не сложно. Для этого остается внедрить только портал самообслуживания, систему биллинга и более детально рассмотреть вопросы информационной безопасности: все-таки конфигурация облака в процессе эксплуатации будет изменяться по заранее определенным правилам, с минимальным вмешательством администраторов, соответственно некоторые нюансы, связанные с безопасностью, могут быть упущены. Сложности могут возникнуть при разработке метрик биллинга, так как многое здесь зависит от специфики организации работы ИТ-службы на предприятии. Например, если операторы мотивированы получать прибыль за счет продажи услуг и им необходимо точно тарифицировать и переложить в стоимость услуги все свои постоянные и переменные затраты, то у промышленного предприятия таких задач нет. Модель биллинга может быть более простой, а назначение такой тарификации — стимулирование внутренних заказчиков к экономии ресурсов (и соответственно ИТ-бюджета)”.

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

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

Павел Борох отметил, что одно из ключевых свойств облачного сервиса — это поддержка самообслуживания по требованию, возможность для пользователя запросить услуги и ресурсы и быстро получить их. Одной виртуализации здесь недостаточно, здесь требуется динамическое создание и выделение ресурсов из имеющегося пула вычислительных средств (серверных), сетевых СХД-ресурсов, конфигурация их под требования пользователя и предоставление их в его распоряжение. Автоматизация таких целей требует довольно интеллектуальной работы, для этого предлагаются специализированные облачные решения, работающие поверх систем виртуализации — оркестраторы, директоры и т. п. Переход к облачной инфраструктуре — это очень индивидуальный и непростой процесс.

Нужно ли переносить в частное облако всю ИТ-инфраструктуру?

“В будущем мы ожидаем, что все больше задач будет выполняться в облачном окружении, — сказал Александр Светлаков. — Но сегодня разумней говорить о гибридной модели, сочетающей в себе как возможности частных и публичных облаков, так и элементы традиционной ИТ-инфраструктуры. К примеру, сегодня публичные облачные сервисы могут предоставить предприятию электронную почту, персональные офисные приложения пользователей, средства управления веб-контентом и дисковую емкость по запросу, а частное облако — вычислительные ресурсы по запросу, бизнес-приложения (CRM, ERP), архив и резервное копирование данных, средства совместной работы, службу поддержи ИТ. В то же время можно оставить в традиционном окружении задачи, связанные с высокой степенью секретности, а также узкоспециализированные приложения”.

Валерий Корниенко также подчеркивает эволюционность процесса: “Традиционные ЦОДы будут постепенно превращаться в частные облака, перемены могут не затронуть лишь не поддающиеся виртуализации унаследованные приложения”.

“Основная проблема, которая может возникнуть сегодня при переносе в облако всей инфраструктуры организации — это перенос персональных данных, — отметил Максим Рубаненко. — Законодательство содержит весьма жесткие требования к безопасности системы, хранящей и обрабатывающей эти данные. Зачастую на порядок дешевле и проще вынести их в отдельную, закрытую подсистему с ограниченным доступом к ней сотрудников. Это позволит упростить сертификацию такой инфраструктуры на соответствие нормативным требованиям”.

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

“Не вижу теоретических причин для “нельзя”, но на практике целесообразность переноса будет зависеть от многих факторов и будет решаться ИТ-менеджерами компаний”, — подвел итог разговора по этому вопросу Павел Борох.

Советы тем, кто собирается и не собирается переходить в частное облако

Валерий Корниенко уверен, что переходить в облако нужно: “Облачные вычисления позволяют использовать ресурсы в несколько раз эффективнее”. А вот Александр Светлаков в своих рекомендациях не столь однозначен: “Задумываться о переходе в облако нужно только тогда, когда имеющиеся ИТ-ресурсы предприятия используются с максимальной эффективностью. Если на предприятии ИТ-ресурсы консолидированы и унифицированы, ИТ-служба работает по стандартным процессам и затрачивает на рутинное обслуживание минимум времени, то такое предприятие может уверенно рассматривать переход на облачную модель для дальнейшего повышения эффективности ИТ. Но, по нашему опыту, большинство предприятий все еще имеют значительный потенциал для роста эффективности ЦОДа в рамках традиционной модели ИТ-инфраструктуры. Мы не советуем задумываться об облаке компаниям, в которых ИТ-служба все еще тратит большую часть времени на рутину и “тушение пожаров” — попытка перехода на облако в таком случае только усугубит неразбериху”.

Что частное облако требует от корпоративного ЦОДа

В принципе, считает Василий Маланин, требования к облачным ЦОДам такие же, как и к обычным: высокая энергоэффективность, высокая плотность размещения нагрузок, низкая эксплуатационная стоимость. Опыт показывает, что для частных облаков требуется баланс различных элементов инфраструктуры (серверы, сеть, СХД), по этому поводу есть рекомендации по подбору компонентов в виде спецификации Fast Track 2.0, проверенной рядом вендоров для оборудования собственного производства.

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

Директор департамента интеграции подразделения IT Business компании “Шнейдер Электрик” Александр Аносов сказал, что его компания, специализирующаяся именно в области создания инженерных систем ЦОДов, выделяет четыре ключевых аспекта внедрения облачной/виртуальной среды, влияющих на архитектуру построения инженерных систем. Первый — увеличение плотности нагрузки в ЦОДе. В результате разница в энергопотреблении между виртуализированной машиной и обычной, как правило, лежит в диапазоне 5—50%. А при условии объединения виртуализированных серверов в кластеры и группы, нагрузка на единичную виртуализированную стойку может отличаться в разы по сравнению с обычной. Второй — изменение ИТ-нагрузки может повлиять на PUE (показатель энергоэффективности системы охлаждения и электроснабжения). Третий — влияние динамической ИТ-нагрузки на энергопотребление, которое “перемещается” за перемещениями виртуальной ИТ-нагрузки. Это может привести к потенциальном проблемам в “узких” местах систем охлаждения и электроснабжения, ухудшению PUE и т. д. Иными словами, необходима интеграция систем управления виртуальными машинами и систем управления инженерной инфраструктурой для гибкого управления ресурсами ЦОДа. Четвертый аспект — снижение требований к отказоустойчивости отдельных компонентов инфраструктуры, поскольку после внедрения хорошо управляемых виртуальных машин существенно возрастает отказоустойчивость на уровне ИТ-оборудования и негативный эффект от выхода из строя отдельного сервера или группы серверов нивелируется автоматическим переносом виртуальных машин на другие серверы. В результате для большинства компаний с требованиями по отказоустойчивости компонентов инженерной инфраструктуры, скажем, 2N+1 теперь становится возможным построить вместо одного ЦОДа с высокими требованиями по резервированию компонентов два со средними. А это, в свою очередь, ведет к снижению капитальных затрат на создание ЦОДа, так как построить два ЦОДа с резервированием N+1 на 35% дешевле, чем строить один ЦОД с резервированием 2N.

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

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

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

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

Как строить ЦОД в условиях ограничения ИТ-бюджета и нестабильности экономики

Сергей Андронов уверен, что к закладыванию бюджетов и строительству ЦОДов правильнее подходить с точки зрения учета общей стоимости затрат (TCO), рассчитывая значение TCO в определенный промежуток времени. Он рекомендует ориентироваться на период в пять-семь лет и подчеркивает, что, формируя требования к ЦОДу, следует стремиться к снижению операционных и капитальных затрат. Необходимо ориентироваться на создание ЦОДов с низким PUE и использовать такие решения, которые оставят ЦОДу максимальный запас для масштабирования.

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

“Строительство ЦОДа — достаточно затратное и не быстрое дело, — констатирует Василий Маланин. — Безусловно, важно четко проанализировать ваши потребности в ресурсах, посчитать, сравнить с альтернативными вариантами (аренда ЦОД, облачные сервисы и т. д.). Если решение о строительстве собственного ЦОДа принято, то в условиях нестабильной экономики я бы рекомендовал обратить внимание на модульный подход к его строительству. Он хорош тем, что первоначальные инвестиции в развертывание начальных мощностей гораздо ниже по сравнению с традиционными ЦОДами, где фактически сначала нужно оплатить “бетон” для всего объема мощностей, который вы предполагаете “снять” с ЦОДа. В модульных ЦОДах можно наращивать мощности последовательно, по мере необходимости. Естественно, рекомендуется использовать энергоэффективные средства охлаждения. Однако специфика зависит от конкретного местоположения ЦОДа”.

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

С ним согласен Максим Рубаненко: “Самое правильное в этой ситуации использовать модульные решения. Это позволит инвестировать средства и вводить проект в эксплуатацию поэтапно, упрощает заказчику и наращивание мощностей ЦОДа в дальнейшем, по мере роста предприятия. Модульный принцип необходимо применять во всех составляющих проекта, включая и инфраструктуру”.