По сравнению с 2012 годом на форуме «МИР ЦОД – 2013» было представлено значительно большее число коммерческих ЦОД, причем не только отечественных, но и европейских, проявляющих интерес к перспективному российскому рынку. Если несколько лет назад КЦОД делали ставку почти исключительно на предложение услуг по размещению оборудования, то теперь они активно развивают облачные сервисы, благодаря которым удается значительно повысить доход с одного квадратного метра дорогостоящей площади.
Еще год-два назад внедрение облачных платформ для предоставления инфраструктурных сервисов вроде IaaS было прерогативой крупных ИТ-интеграторов, таких, например, как «Крок» и «Ай-Теко». Однако предлагаемые производителями платформы «зрели» стремительно, и сегодня для их развертывания уже не требуется «искусства» интеграции. Компании, для которых основным бизнесом является предоставление услуг на базе своих ЦОД, тоже активно «пошли в облака».
«ОБЛАКА» ВОКРУГ РОССИИ
Те, кто переносит ИТ-сервисы во внешнее инфраструктурное облако, особенно находящееся за границей, обычно не слишком заинтересованы в раскрытии этой информации. Тем примечательнее, что компания Linxdatacenter, только осенью прошлого года начавшая предоставлять услуги IaaS из своего варшавского ЦОД (подробнее см. экскурсию в этот ЦОД в ноябрьском номере «Журнала сетевых решений/LAN» за 2012 год), представила на форуме «МИР ЦОД – 2013» сразу трех российских заказчиков. Это производитель и дистрибьютор товаров для спорта и отдыха Atemi, разработчик ПО для нефтегазового сектора Intari, а также один из крупнейших дистрибьюторов ИТ-оборудования и программного обеспечения OCS. В самое ближайшее время Linxdatacenter планирует развернуть платформу IaaS и на своих российских площадках.
7 шагов в облако
При переходе в облако LinxCloud заказчики совместно со специалистами Linxdatacenter обычно проходят следующие этапы:
- Оценка требуемой вычислительной мощности. Обычно определяются четыре параметра: мощность процессора, объем оперативной памяти, емкость СХД и скорость сетевого соединения.
- Выбор площадки для размещения данных. Определяющий фактор — метод подключения конечных пользователей к облачной инфраструктуре. Если предполагается терминальный доступ, то местоположение ЦОД не так важно (достаточно не слишком скоростного соединения). Если требуется скоростное подключение, то желательно, чтобы ЦОД располагался ближе к офису заказчика. Благодаря наличию у Linx собственных каналов 10G от Москвы до Варшавы с задержкой 30 мс, использование заказчиками облака, находящегося в Европе, не составляет проблем. Необходимо учесть также требования регулятора: ряд систем, приложений и данных нельзя выносить за пределы РФ. Это одна из причин, по которым Linxdatacenter решил развернуть облачную платформу и в РФ.
- Анализ совместимости программного обеспечения. Следует учесть, что часть приложений вообще не виртуализируется и не может быть вынесена в облако. Возможность и целесообразность их перемещения в облако можно проверить путем получения демодоступа — на 10 дней без оплаты.
- Получение демодоступа. Работоспособность приложений, которые вызывают наибольшие сомнения, в новой среде лучше проверить заранее. В случае проблем возможен гибридный вариант — вынос приложения на отдельном сервере в тот же ЦОД, где и облако.
- Согласование заказа на услугу. Определение коммерческих условий, сроков и пр. В зависимости от задачи можно приобрести услугу с гарантированной мощностью (выделенные ресурсы) либо использовать разделяемые ресурсы. Заказ сопровождается заключением соглашения SLA.
- Миграция сервисов в облачную среду. В зависимости от объема и сложности проекта миграция занимает от нескольких дней до нескольких месяцев.
- Администрирование и поддержка. Техническая поддержка включается в стоимость услуги.
Рисунок 1. Платформа для предоставления сервисов IaaS в ЦОД компании Linxdatacenter в Варшаве. |
На форуме «МИР ЦОД» технический консультант группы компаний Linx Андрей Захаров представил основные шаги по переводу ИТ в облако (см. врезку «7 шагов в облако»). Используемая Linxdatacenter платформа создана на основе программно-аппаратного комплекса FlexPod (совместное решение Cisco и NetApp) и ПО VMware (см. Рисунок 1). Вычислительная система представляет собой массив блейд-серверов с резервированием N+1, а в системе хранения реализована поддержка RAID 6-DP и предусмотрена избыточность контроллеров 2N. Вторичная система хранения размещена на отдельной площадке в одном километре от основного ЦОД. Гипервизоры VMware работают в режиме отказоустойчивости High-Availability. Linxdatacenter гарантирует доступность услуги LinxCloud IaaS на уровне 99,9%.
Группа компаний Atemi — один из пользователей этой услуги — полностью отказалась от собственных серверов, оставив у себя только тонкие клиенты и принтеры. Atemi располагает сетью спортивных магазинов во Владимире, Рязани, Тамбове, Туле, Ульяновске и Ярославле, а также занимается оптовыми поставками спортивных и рыболовных товаров. Переход на облачную инфраструктуру был обусловлен рядом причин, включая необходимость замены устаревшего парка серверов, возрастающие потребности в вычислительной мощности при сложности ее прогнозирования, потребность в постоянной поддержке новых офисов и магазинов. Среди сложностей перехода на виртуальную инфраструктуру специалисты Atemi называют проблемы с получением качественных каналов связи и настройкой периферии на работу с удаленной инфраструктурой (на принтерах для печати потребовалось увеличить скорость каналов). Но в целом компания довольна работой в облаке.
Рисунок 2. Центр обработки данных «Парковый»
в Киеве должен стать первым сертифицированным ЦОД Tier III в Украине. |
Большие планы по предоставлению облачных сервисов имеет и центр обработки данных «Парковый» в Киеве (см. Рисунок 2), который должен стать — если запланированная сертификация пройдет успешно — первым ЦОД Tier III в Украине. Как рассказал на форуме «МИР ЦОД – 2013» Александр Кариченский, директор по развитию бизнеса компании «Дата-центр «Парковый»», уже закуплен начальный набор оборудования (несколько сотен серверов Cisco UCS и СХД EMC на 100 Тбайт) для создания двух независимых облачных инфраструктур: для государственных органов (частное облако) и для коммерческих компаний (публичное облако). Для доступа к публичному облаку будут использоваться открытые сети связи общего пользования, а для частного — специальная сеть связи для решения государственных задач. В планах предложение услуг IaaS — предоставление виртуальных серверов, виртуальных ЦОД и облачных хранилищ, а также сервисов PaaS и SaaS. К числу последних относятся электронная почта, решения для совместной работы и унифицированные коммуникации.
Мощность ИТ-нагрузки ЦОД «Парковый» составит 2,4 МВт, а его емкость — 400 стойко-мест. В ЦОД имеется 14 машинных залов различной площади для размещения оборудования заказчика — как обычные неэкранированные, так и экранированные, согласно требованиям украинского законодательства к размещению серверного оборудования банков. Электроснабжение ЦОД осуществляется по первой категории надежности от двух (в перспективе от трех) независимых подстанций. Для обеспечения бесперебойного электропитания на объекте установлено три модульных ИБП APC Symmetra MW мощностью 1600 кВА каждый, что позволяет обеспечить как внутреннее резервирование ИБП по схеме N+1 по силовым модулям, так и резервирование N+1 на уровне отдельных устройств. Распределительная сеть электропитания выполнена на основе шинопроводов серии Canalis.
В ЦОД реализована двухконтурная чиллерная система с применением моноблочных охлаждающих машин Uniflair, межрядных блоков APC InRow в машзалах и шкафных блоков Uniflair в технических помещениях. Чиллеры имеют функцию фрикулинга, что вместе с электронным регулированием мощности насосов и вентиляторов, применением систем контейнеризации «горячих» коридоров позволяет добиться высоких показателей среднегодового PUE — расчетные значения 1,3–1,35. При этом, как надеется Александр Кариченский, при выходе на полную мощность реальный показатель энергоэффективности окажется даже лучше. «В других коммерческих ЦОД Украины в лучшем случае PUE составляет 1,65–1,7. В корпоративных ЦОД этот коэффициент, как правило, не измеряется и часто переваливает за 2,0», — рассказывает он.
ИНТЕГРАТОР ИЛИ ПРОВАЙДЕР
Павел Колмычек, руководитель сети центров обработки данных «Крок», рекомендует при выборе ЦОД, в том числе для облачных сервисов, учитывать «специализацию» его владельца, то есть какой бизнес является для него основным — проектный (интегратор) или развитие услуг ЦОД (провайдер). Провайдер может предложить более дешевые базовые услуги (аренда), а интегратор лучше обеспечит дополнительные услуги, например в части соблюдения требований регулятора или выполнения особых пожеланий службы безопасности. Нередко для удовлетворения «продвинутых» запросов заказчиков, скажем по организации резервного ЦОД, провайдер обращается за помощью к интегратору. По мнению специалиста «Крок», интеграторы ориентированы на выполнение крупных проектов, тогда как провайдеры умеют хорошо работать с небольшими клиентами.
Опираясь на богатый опыт компании «Крок» по предоставлению облачных сервисов, Павел Колмычек советует обязательно запрашивать тестовый доступ к облаку для проверки того, что оно «умеет». «Порой возникают ситуации, когда после переноса ИТ-системы в облако часть ресурсов по тем или иным причинам приходится перемещать обратно. Все это весьма дорогостоящие операции, — продолжает он. — Есть решения, которые позволяют подключать к облаку обычные физические серверы, например с базами данных». По его мнению, реализацию подобных гибридных схем лучше поручить интегратору.
Специалист «Крок» предлагает простую блок-схему выбора типа ЦОД (см. Рисунок 3). Обратите внимание на его рекомендацию использовать собственный ЦОД в случае, если требуется уникальная услуга, то есть когда на рынке нет хотя бы двух предложений на сформулированный запрос. «Если вам нужна уникальная услуга, то и цена на нее будет уникальной», — констатирует он.
Рисунок 3. Как выбрать правильный ЦОД. |
О СЕРТИФИКАЦИИ
В фокусе внимания участников форума «МИР ЦОД – 2013» оказались вопросы сертификации ЦОД. Свой опыт прохождения сертификации на соответствие уровню надежности Tier III (по классификации Uptime Institute) представили российская компания «Крок» и латвийский оператор Lattelecom. Пожалуй, квинтэссенция целей сертификации была отражена в названии доклада Руслана Заединова, заместителя генерального директора «Крок»: «Спокойствие заказчиков ЦОД — бесценно, для всего остального существует сертификация».
«Tier III — это не про девятки, а про параллельное обслуживание, — считает Руслан Заединов. — Предположим, дизели зарезервированы, но подключены к одной шине или к одному АВР. В этом случае неважно, по какой схеме зарезервированы дизели — это может быть N+1, 2N или даже 5N. Если что-то случится с этой шиной или с этим переключателем, вы окажетесь без резервного электропитания».
Как рассказал Марис Сперга, директор по развитию международного бизнеса компании Lattelecom, которая развивает услуги КЦОД под маркой Dattum, еще на стадии проектирования компания получила от организации Uptime Institute 28 замечаний. В частности, расчет системы охлаждения был выполнен исходя из статистики местного гидрометцентра, при этом за максимальную была принята температура +27°С. Uptime Institute потребовал руководствоваться рекомендациями ASHRAE, в которых для расчетов предписывается использовать максимальную температуру +35°С. Кроме того, замечания касались вопросов установки перфорированных плит фальшпола (дабы устранить вероятность завихрений воздуха, снижающих эффективность системы охлаждения), резервирования ДГУ и пр. Все замечания были учтены, благодаря чему проверку уже построенный ЦОД прошел с первого раза, что удается лишь немногим — претензии у экспертов Uptime Institute не возникают лишь к 20% объектов.
Как уже отмечал «Журнал сетевых решений/LAN» (см. статью автора «Не Uptime’ом одним» в майском номере «Журнала сетевых решений/LAN» за 2013 год), доля ЦОД, сертифицированных Uptime Institute, пока еще мала. Например, ЦОД «Компрессор» компании «Крок» стал только третьей российской площадкой с сертификатом Tier III (такие сертификаты также имеются у ЦОД Сбербанка РФ и DataSpace) и пока единственным коммерческим ЦОД с таким уровнем надежности, предоставляющим облачные сервисы. А вот ЦОД Lattelecom — вообще первый ЦОД Tier III в Северной Европе. Однако, как указывает Алексей Солодовников, управляющий директор Uptime Institute Russia, процесс сертификации ЦОД начался всего несколько лет назад и динамика роста числа сертифицированных объектов впечатляет (см. Рисунок 4).
Рисунок 4. Рост числа выданных организацией Uptime Institute сертификатов на проект ЦОД (TCDD)
и на уже построенный объект (TCCF). |
ПРЕСЛОВУТЫЙ ЧЕЛОВЕЧЕСКИЙ ФАКТОР
Наряду с уровнем готовности (по сути, SLA) не меньшее значение операторы коммерческих ЦОД придают задачам обеспечения безопасности. К слову, эти вопросы уже выходят за рамки рекомендаций Uptime и рассматриваются в других документах, например в ISO/IEC 27001. Некоторые российские ЦОД считают важным наличие такого сертификата — в частности, он уже имеется у компании DataLine, а Linxdatacenter находится в процессе его получения (подробнее см. статью «Не Uptime’ом одним»).
Как полагает Руслан Заединов, самое важное в безопасности — это то, как организован доступ людей к установленному в ЦОД оборудованию. Желательно иметь несколько периметров безопасности. В качестве примера он приводит ЦОД «Компрессор», который размещен в закрытой промышленной зоне, образующей первый периметр безопасности. Второй периметр — собственно территория ЦОД, куда имеют доступ только авторизованные сотрудники ЦОД и заказчики. Следующие три периметра безопасности проходят на уровне самого здания ЦОД, его отдельных холлов и машзала (см. Рисунок 5). Наконец, шестой периметр может реализовать заказчик: один из них — финансовая организация — установил даже лазерную систему обнаружения вторжений.
Рисунок 5. Вложенные периметры безопасности на примере ЦОД «Компрессор» компании «Крок». |
Эксперты компании «Крок» также рекомендуют делать раздельные периметры безопасности для ИТ и инженерного оборудования. «Представьте ЦОД, где установлены все мыслимые системы контроля доступа: сканирование сетчатки глаза и отпечатков пальцев, ультразвуковой снимок скелета руки, взвешивание при входе через шлюз, распознавание голоса и т. д. Но если все инженерные системы — и охлаждения, и газового пожаротушения, и бесперебойного электропитания — будут размещены в машзале ЦОД, то список тех, кому разрешен доступ, придется существенно расширить, что снизит уровень безопасности, — продолжает Руслан Заединов. — Крайне желательно системы охлаждения установить в коридоре или отдельном помещении, а электропитания — в другом помещении. Тогда в машзал будут заходить только специалисты по ИТ, в помещения с системами кондиционирования — только инженеры-теплотехники, в комнату с электрооборудованием — только электрики».
Практически все эксперты отмечают важность человеческого фактора и в вопросе эксплуатации ЦОД. Как бы хорошо ни был построен ЦОД и сколь бы высокая степень отказоустойчивости ни была в него заложена, безграмотная эксплуатация может загубить все дело, так что за год уровень надежности может снизиться с Tier III до Tier II, и даже ниже. Не случайно Uptime Institute в дополнение к двум имевшимся типам сертификатов (на проект (Design) и на уже построенный объект (Constructed Facility)) ввел третий — на эксплуатацию ЦОД (Operational Sustainability). Сертификация процессов эксплуатации начала проводиться относительно недавно, более того, она возможна только после того, как ЦОД проработает хотя бы год. Понимая важность процессов эксплуатации, многие владельцы сертифицированных ЦОД намереваются получить и сертификат Operational Sustainability. Например, на форуме «МИР ЦОД» об этом заявили представители «Крок» и Lattelecom.
Не меньшее внимание вопросам грамотной эксплуатации уделяют и компании, которые считают неоправданным тратить деньги на сертификацию в Uptime Institute. На форуме «МИР ЦОД» компания DataLine, один из крупнейших российских поставщиков услуг ЦОД и облачных сервисов, поделилась своим опытом организации процессов эксплуатации. Как отметил Кирилл Шадский, начальник отдела эксплуатации DataLine, 60–70% сбоев в работе ЦОД связаны с человеческим фактором. Он выделяет несколько ключевых вопросов — в частности, ведение документации, обучение, плановое техобслуживание и ремонтные работы, мониторинг и нагрузочное тестирование ЦОД. По его мнению, недостаточно разместить документацию «где-то на сервере» — важно, чтобы возле каждой единицы инженерного оборудования (например, ИБП, кондиционер, ДГУ) находилась краткая выдержка из инструкций, что в случае аварии позволит оперативно выполнить необходимые действия, не тратя время на поиск информации.
Специалист DataLine рекомендует в каждом ЦОД иметь запас топлива минимум на 4–6 часов работы при полной нагрузке (например, по московским пробкам машина с соляркой может добираться до объекта несколько часов), а также запас расходников с большим сроком поставки (на доставку которых из Европы уходит 6–12 недель). Кроме того, желательно иметь в ЦОД «мелочовку»: фреон, предохранители, автоматы и пр. Все это, конечно, есть на складах в Москве, но удобнее, чтобы было «под рукой». Кроме того, российская специфика — например, продолжительные январские и майские праздники — такова, что какую-нибудь простенькую запчасть можно ждать целую неделю, даже если она находится на соседнем складе. Ясно, что обслуживание сложных инженерных систем всегда разумно поручать специализированным организациям, но специалисты DataLine считают необходимым часть работ уметь делать самостоятельно. Это срочные аварийные работы и простые каждодневные операции (запайка фреоновых труб, чистка и замена фильтров).
Скорость и адекватность реакции персонала на то или иное событие зависят от своевременной информированности и полноты данных. Кирилл Шадский рекомендует четко продумать задание приоритетов для сигналов, получаемых от средств мониторинга. Например, по его словам, порой важнее быстро отреагировать на сигнал о проблеме в работе вентилируемой двери шкафа, а не чиллера: последний обычно зарезервирован, тогда как дверь — нет. Если параметры функционирования системы электропитания в ЦОД DataLine запрашиваются ежесекундно — всплески и скачки напряжения могут возникнуть мгновенно, то для систем охлаждения частота опроса составляет раз в минуту. «Температура не может возрасти мгновенно. Если же все параметры отслеживать каждую секунду, то это может привести, во-первых, к перегрузке системы управления, а во-вторых, к появлению массы ненужных предупреждающих сигналов, которые будут только мешать работе операторов», — поясняет он.
Согласно практике, принятой в DataLine, тестирование ДГУ с полной нагрузкой осуществляется не реже двух раз в месяц, причем сама проверка длится не менее часа, поскольку многие проблемы проявляются только после определенного времени работы. Тестирование ИБП с переходом на батареи проводится не реже одного раза в квартал, переключения между элементами системы технологического кондиционирования — раз в две недели, а проверка автоматической установки газового пожаротушения — ежемесячно, каждый месяц для разного направления. В последнем случае тестируется только автоматика без выпуска дорогостоящего газа. Очень важно, что во время тестирования проверяется не только оборудование, но и действия сотрудников, для которых это служит лучшим экзаменом по усвоению теоретических знаний.
Что тормозит развитие облачных сервисов в России
Чтобы в полной мере понять проблематику развития облачного рынка в России, необходимо подходить к ее рассмотрению с двух сторон: со стороны операторов, которые хотят предоставлять облачные услуги, и со стороны заказчиков, которым эти услуги предназначаются.
Для операторов внедрение облачных сервисов означает существенные вложения в аппаратно-программную составляющую в случае с IaaS, не говоря уже об услугах PaaS и SaaS. При этом важно учитывать, что платформы для облачных вычислений состоят как из программного обеспечения, необходимого для работы платформы, так и из вычислительных компонентов, которые довольно быстро амортизируются. Расчет делается на то, что платформа для облачного вычисления будет активно востребована потенциальными клиентами и в короткие сроки выйдет на свою расчетную мощность и окупаемость. На российском рынке такой сценарий пока невозможен, что делает внедрение облачных платформ экономически нецелесообразным для операторов. Данный фактор тормозит развитие облачных сервисов в России.
Со стороны заказчиков облачных услуг можно выделить спрос на два вида ресурсов — на виртуальные облачные машины и на рабочие места в облаке. Причем потребность в таких услугах возникает, как правило, у территориально распределенных компаний, офисы которых разбросаны по всей стране, а концентрация рабочих мест очень мала. Именно таким компаниям выгоднее выносить рабочие места в облако, поскольку это дает положительный экономический эффект за счет консолидации квалифицированного труда по обслуживанию всей инфраструктуры в одном месте. Однако, если говорить об IaaS, при использовании виртуального сервера, размещенного в облаке, подобного эффекта добиться не удается, поскольку в этом случае потребность в квалифицированном персонале такая же, как и в случае с физическим сервером. Именно поэтому большей популярностью среди облачных решений пользуются услуги SaaS.
Главным же сдерживающим фактором развития частных облаков является прежде всего стоимость аппаратной составляющей платформы, которая значительно превышает для заказчика стоимость организации обычного ИТ-комплекса. Именно поэтому большинство компаний пока отдают предпочтение более традиционным и доступным по стоимости решениям.
Подводя итог, можно сказать, что в целом рынок облачных технологий в России еще слабо развит. Стоит также отметить, что на сегодняшний момент облачные сервисы ближе интеграторам, нежели операторам ЦОД. Пока еще сервисные облачные услуги и услуги предоставления инфраструктуры ЦОД в аренду представляют разные направления бизнеса, которые требуют от компаний разных компетенций. Коммерческие ЦОД, безусловно, проявляют интерес к облачным технологиям, поскольку изначально заинтересованы в диверсификации своего бизнеса. Однако большинство из них все же пока не рассматривает данное направление как приоритетное для своего развития.
Андрей Касьяненко — заместитель генерального директора телекоммуникационной компании Caravan.
ДАННЫЕ — САМОЛЕТОМ
Критерии выбора коммерческого ЦОД могут различаться. При этом границы между странами все реже становятся преградой для «переезда» ИТ-систем и/или сервисов. Например, как рассказал Марис Сперга, один из крупных клиентов нового ЦОД Dattum — российская компания, решившая перенести в Ригу свои серверы из Лондона. Причинами принятия такого решения стали более низкая цена, наличие русскоязычной поддержки, а также существенно более низкая задержка при передаче данных. При доступе к серверам в Лондоне последняя величина составляет 60 мс, а при их размещении в Риге — 19 мс. Наконец, из Москвы до столицы Латвии можно долететь всего за полтора часа, что оказалось дополнительным фактором в пользу ЦОД Dattum.
Предположим, коммерческий ЦОД выбран. Далее необходимо перенести туда определенные ИТ-сервисы. Задача эта может оказаться очень непростой. Своим опытом в части переноса из одного ЦОД в другой системы SAP поделился на форуме Робертас Балкис, руководитель отдела поддержки продаж компании Hostex BDC. Заказчиком проекта выступила компания Rimi Baltic Group — крупнейший в Прибалтике оператор розничной торговли с 234 магазинами в Эстонии, Латвии и Литве. Система SAP обслуживает примерно 2800 пользователей, причем она имеет критически важное значение для бизнеса: при ее недоступности останавливаются вся логистика и движение товаров, а в конечном счете — и обслуживание покупателей. Допустимо лишь несколько часов простоя такой системы в год.
Изначально система, развернутая на платформе HP Integrity rx8640, Itanium2, находилась в ЦОД в Германии. «Переехать» она должна была в один из ЦОД Hostex BDC в Вильнюсе на классические серверы HP C7000 / bl460c G8 с процессорами Intel x86. В процессе переноса не должно было возникнуть перебоев в функционировании сети магазинов и логистических центров во всех странах Балтии. Длительность проекта по миграции должна была составить 3 месяца, а продолжительность технического простоя системы — максимум 12 ч. За невыполнение или несвоевременное выполнение проекта был предусмотрен денежный штраф в 1 млн евро.
На какое-то время система оказалась разделенной между Германией и Литвой — одна часть ресурсов находилась в одном ЦОД, другая — в другом, что потребовало серьезных усилий по управлению и обеспечению согласованного функционирования. В процессе миграции нагрузка на серверы и СХД становится значительно больше, чем во время штатной работы, поэтому для поддержания необходимой производительности потребовалось создать временную систему, ставшую буфером между исходной и конечной. Наконец, пропускная способность сетей между Литвой и Германией оказалось недостаточной — «трудно получить гигабитный канал, реально доступны только мегабитные», сетует Робертас Балкис. Поэтому большую часть данных (всего порядка 10 Тбайт) перевозили самолетом — в чемодане со специальной системой, включающей сервер и СХД. Через сеть передавались только изменения данных.
Российские компании и организации начинают не только теоретически понимать преимущества коммерческих ЦОД, но и извлекать их на практике. Все большее число историй успеха облачной модели потребления ИТ, в том числе и модели «инфраструктура как сервис» (IaaS), способствуют дальнейшему увеличению числа заказчиков, заинтересованных в таких услугах.
Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.