28 июля 2021 г.
Продолжая разговор про виртуализацию, рассмотрим ее применение на уровне технологических решений, в сегменте компонентов ее уже на удивление много — одни она заменяет полностью, другие дополняет. О преимуществах и особенностях таких подходов, как в экономическом, так и в политическом плане, мы сейчас и поговорим.
Сначала напомним, что виртуализацией называют предоставление вычислительных ресурсов, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе. Под это определение при минимальных допущениях попадают и «облачные» сервисы, так как обычно заказывающие вычислительные ресурсы в «облаке» и близко не представляют, какие физические ресурсы обеспечивают в данном случае работу приложений, виртуальных ПК, серверов и т. д.
Виртуализация компонентов
Современное состояние тренда рассмотрим на примере виртуализации локальных сетей. В качестве продуктового примера возьмем Cisco Meraki, самой новой линейки «сетевухи», активно использующей элементы виртуализации. Эту линейку будем рассматривать как в этом, так и в следующем подразделе, но там уже она будет иллюстрировать другой тренд. Здесь же отметим, что коммутаторы в этой линейке могут быть только виртуальными. Управление и конфигурирование для них, разумеется, реализовано через web, а физически софт располагают на серверах Cisco. Такой подход выгоден по понятным причинам, но очевидны и его проблемные стороны.
В настоящее время региональные серверы Cisco, обеспечивающие работу коммутаторов Meraki, отсутствуют в России. Это ограничивает применение новинки в компаниях с жесткими требованиями по инфобезопасности. В скором времени соответствующие серверы компании будут развернуты на территории РФ, как отметил Алексей Лукацкий, консультант по безопасности в российском представительстве Cisco, что несколько смягчит проблему, но не решит ее полностью — Meraki не предусматривает установку on-premise на мощностях заказчика. Поэтому для создания инфраструктуры, не имеющей компонентов за пределы периметра компании-заказчика, вендор предлагает ряд других продуктов, линейки которых тоже продолжают развитие.
Часть — физична, часть — в «облаке»
Концентраторы, маршрутизаторы, роутеры и сотовые модемы, разумеется, должны иметь физическое воплощение. Линейка Meraki в данном случае не исключение, но виртуализация проникла и сюда. Вся настройка, все управление и вся аналитика для всего «железа» линейки вынесена в «облако» и доступна только через web-интерфейс, как и вышеупомянутого коммутатора. Это выглядит подчеркнуто модерново, а также обеспечивает ряд преимуществ.
Во-первых, все оборудование линейки работает «из коробки» — девайсы нужно только распаковать, подключить к сети и обеспечить им интернет-доступ, остальное они сделают автоматически, самостоятельно загрузив и установив соответствующие настройки. Zero Touch Deployment — нулевые затраты на включение — как одну из важных особенностей Meraki отмечает Фотис Иосифидис, менеджер по продукту в Orange Business Services. Разумеется, загружаемые настройки и политики возникают не «из воздуха», а должны быть предварительно прописаны для устройств, но «на местах» такой подход позволяет свести затрат действительно к нулю. Настройки могут быть централизованно выполнены специалистами из одного места, а загружены на разворачиваемую сеть — совсем в другом. Таким же способом — через web-интерфейс — выполняют и администрирование, смену политик, отслеживание ИБ-инцидентов и т. д.
Согласитесь, это дальнейшее развитие привычных концепций — plug-and-play, программно-управляемых устройств и т. д.! Причем так сделаны все устройства линейки, а там, как отмечает г-н Иосифидис, есть решения как для малых групп (в данном случае «группа» может состоять и из одного пользователя-«удаленщика»), и для сетей, в которых до 10 тыс. пользователей, которые в терминах вендора называют «штаб-квартирами».
Что будет с виртуализированной инфраструктурой, если «на местах» исчезнет интернет-доступ? Вопрос важный и требует предварительной проработки! В случае с сетью, построенной на оборудовании Meraki, ничего не будет: девайсы продолжат работу с ранее загруженными настройками и политиками, а коммутатору для работы нужен канал с шириной, которую может обеспечить даже GPRS.
Такие решения с Zero Touch Deployment будут актуальны для многих компаний, но особенно — для обладающих развитой филиальной структурой — ритейлеров, банков с сетью филиалов и банкоматов, сетевых кафе и т. д. К каждому элементу такой инфраструктуры накладно направлять сетевого специалиста для развертывания и настройки решения, что будет нужно при использовании традиционных решений. Кроме того, в таком случае спец будет требоваться «по месту» каждый раз, когда надо изменить локальную сеть. В случае с виртуализированным управлением все настройки можно выполнить дистанционно, а чтобы подключить обратно отсоединившийся кабель, высокая квалификация не нужна, с этим справится и персонал на месте.
Разумеется, такой набор «killer features» имеет и свою обратную сторону. В данный момент Meraki не поддерживает ряд технологий (например, SLI), а также имеет несколько ограниченные возможности по конфигурированию, как отмечает г-н Лукацкий, но это естественная «плата» за простоту. Кроме того, фрагменты сети, построенные на Meraki, прекрасно сочетаются с фрагментами на другом оборудовании, выбор есть и делать его нужно в зависимости от особенностей решения «по месту».
Виртуализация: плюсы и минусы
Выделить базовые особенности виртуализации позволяет рассмотренный выше пример. Он не единственный (хотя и сейчас наиболее выразительный), аналогов у него есть много, например, в сегменте SD-WAN-решений. Итак:
[ + ] Простота развертывания и, как следствие, дешевизна процесса установки, вплоть до Zero Touch Deployment.
[ + ] Легкость администрирования — технические моменты максимально автоматизированы, админы могут быть удалены хоть на другой континент.
[ + ] Минимизация затрат на обслуживание в локациях, для которых эксплуатация устройств идет по принципу «установил и забыл», хотя админам, проводящим централизованное обслуживание, конечно, не получится «забыть».
[ + ] Перевод части затрат из CAPEX в OPEX, что хорошо для финансово-экономической деятельности компании.
[ — ] Ограничения по тонким возможностями кастомизации решений как плата за простоту настройки.
[ — ] Ограничения по применению из-за политических вопросов — вынос инструментов в «облака» не во всех компаниях приветствуют по причинам политик безопасности, особенно если ЦОДы с соответствующими «облаками» находятся за пределами юрисдикции РФ.
[ * ] Возможность минимизации рисков — работа системы при пропаже широкополосного канала для связи с «облаком» — должна быть предусмотрена заранее.
[ * ] В реальных условиях с высокой вероятностью придется сочетать виртуализированные решения с традиционными, соответствующие вопросы лучше предусмотреть заранее, например, выбирая решения разных типов от одного вендора.
Рассмотрим некоторые другие примеры, на которых перечисленные преимущества-недостатки-особенности системы также видны.
Виртуальный файерволл
Решения для обеспечения инфобезопасности пользуются повышенным спросом и стоят довольно дорого, поэтому их активно виртуализируют. «Облачный» файерволл — удобное решение для компаний из сегмента SMB, а также для ряда ситуаций, которые встречаются у корпоративных пользователей. Например, для рассмотренной выше филиальной сети устанавливать на каждую точку программно-аппаратный комплекс для обеспечения работы файерволла будет довольно затратно.
«Облачный» файерволл принимает весь трафик компании/филиала, фильтрует его и перенаправляет адресату. Это удобно, технично, позволяет минимизировать затраты, попутно переводя их из CAPEX в OPEX, но имеет и понятные ограничения. «Облако», на котором работает файерволл, должно быть «приземлено», по возможности, не очень далеко от локации корпоративного пользователя — увеличение пути трафика до файерволла может снизить время отклика до значений, способных вызвать нестабильную работу прикладных программ и неудобства пользователей (например, при применении сервисов видеоконференцсвязи).
Заметим, что виртуальный файерволл не обязательно должен находиться во внешнем «облаке», есть и другие варианты решений. Например, файерволл можно запускать на виртуальной машине. Конечно, файерволл можно ставить аппаратный, можно запускать на физической машине, однако напомним, что смысл виртуализации состоит в наиболее полном использовании вычислительных ресурсов, поэтому виртуальная машина будет предпочтительней. Распределение аппаратных ресурсов между запущенными виртуальными машинами, как обычно, обеспечивает гипервизор, только в данном случае важно удостовериться в полной совместимости софта: гипервизора и файерволла. Кроме того, использование виртуальной машины позволяет быстро менять ее вычислительные ресурсы, обеспечивая их оптимальное соответствие текущим задачам — в данном случае, нагрузкам на файерволл, которые могут меняться.
Виртуализируют даже ресурсы с вычислительными мощностями суперкомпьютерного класса. Решения для этого технически сложны и требуют комплексного подхода, поэтому доступны только немногим компаниям на рынке. Например, HPE представляет GreenLake for High Performance Computing — это комплексное решение для локальной среды, которое упрощает доступ широкого круга заказчиков к суперкомпьютерным мощностям для развертывания HPC- и AI-приложений, рабочих нагрузок и моделей с оплатой «по факту использования».
Виртуальный ЦОД
Общая парадигма перехода на сервисную модель предоставления всевозможных услуг (X-as-a-Service), которые реализуют исключительно «силами» виртуализации в ЦОДах, определяет положительные перспективы развития ИТ-рынка, отмечает Валерий Андреев, заместитель директора по науке и развитию ИВК. Но в ЦОДах виртуализируют даже ЦОДы!
Промышленный виртуальный центр обработки данных (вЦОД) включает вычислительные ресурсы, дисковое пространство, средства управления и мониторинга, сервисы информационной безопасности и доступа к инфраструктуре. Эта ИТ-инфраструктура, полностью аналогичная решениям на физическом оборудовании, может быть любой сложности. Заказчик получает всю эту инфраструктуру «как сервис» — классический случай IaaS! — с возможностью самостоятельного управления и мониторинга через специализированный портал.
В сегменте ЦОДов расклад прост и ясен. Коммерческие ЦОДы в большинстве случаев выступают площадками для приземления «облаков», разворачивания ресурсов сервис-провайдеров, коллокации оборудования и прочих понятных задач, находясь в собственности провайдера. Ведомственные ЦОДы и дата-центры предприятий, по сути, крупные серверные с продвинутой инфраструктурной «обвязкой», которые служат для тех же задач, находясь в собственности корпоративного заказчика. Картина получается вполне цельная, но возникает вопрос: где тут место виртуальным ЦОДам и зачем они нужны?
Принято считать, что есть два наиболее распространенных варианта применения вЦОДов. Во-первых, такая инфраструктура нужна для компаний, которые не хотят создавать свой физический ЦОД, но при этом управление разрозненными виртуализированными ресурсами оказывается слишком ресурсоемким, а поэтому хорошо бы их объединить в единую структуру. В данном случае преимущества в таком варианте виртуализации оказываются ровно такими же, как и в любом другом, только более выразительными — для любой компании будет крайне приятно отсутствие необходимости собственных вложений в создание защищенного помещения с гарантированным энергопитанием, мощной системой вентиляции и теплоотвода, но при этом обеспечение для своей инфраструктуры «цодовских» параметров надежности. Во-вторых, вЦОД хорош как резервная площадка, ведь создавать два физических ЦОДа для любой компании будет весьма накладно.
Виртуальные ЦОДы также хороши для ряда технических задач. Например, для моделирования различных ситуаций с физическим ЦОДом — от работы под пиковыми нагрузками и поведения при выходе из строя части оборудования до виртуального апгрейда и проведения пентестов — в этом случае вЦОД выступает своеобразным «цифровым двойником» физического ЦОДа. Виртуальный ЦОД также полезен, например, для проведения обучения и тренингов, при миграции и для ряда других задач, проведение которых на физическом ЦОДе по понятным причинам крайне проблематично.
Проникновение виртуализированных решений в инфраструктуру компании зависит от особенностей не вертикального рынка, а конкретной компании, считает Светлана Гацакова, директор департамента КИС ALP Group. Но в любом случаеу корпоративных заказчиков вопрос стоит о том, какие именно технологии подлежат виртуализации в первую очередь, а виртуализацию каких можно пока отложить.
«Облака» для «облаков»
В рассматриваем нами сегменте происходят и совсем постмодернистические события: создают «облачные» решения для управления «облачными» сервисами.
Например, HPE представляет «облачную» службу управления Compute Cloud Console, которая автоматизирует вычислительные операции для всей ИТ-системы организации. Основанная, как легко предположить, на HPE GreenLake Cloud Platform, Compute Cloud Console упрощает управление инфраструктурой и доступна по модели «как услуга» независимо от того, где выполняются рабочие нагрузки — от границы сети до «облака». Кроме того, консоль автоматизирует задачи, выполняемые вручную, к примеру, выделение ресурсов или управление жизненным циклом.
Аналогичные решения создают и российские компании. Например, систему под названием CloudMaster представила корпорация Softline в середине лета. Решение тоже «облачное», но более сфокусированное на управление именно «облачными» ресурсами: оно позволяет заказчикам производить самостоятельное управление произвольным набором подписок и аккаунтов в режиме «одного окна», консолидировать биллинг, повышать прозрачность контроля за бюджетом и автоматизировать многие другие функции. «Благодаря нашему взаимовыгодному сотрудничеству с Microsoft и за счет использования нашей платформы клиенты получат также дополнительные преимущества — будут пользоваться упрощенным интерфейсом, смогут дополнительно отслеживать свои затраты, применять готовые процессы согласований, а также подключать управление ресурсами и биллингом», — говорит Павел Токарев, директор по продукту CloudMaster в Softline. В настоящее время cloud-сервис Softline работает с «облаками», развернутыми в Microsoft Azure, но в дальнейшем, возможно, список поддерживаемых «облачных» платформ будет расширен.
Вместо заключения
В новом мире, где происходит бум виртуализации, традиционные компании канала остаются актуальными, только профиль их деятельности несколько меняется. «Box moving» остается, так как «облака» и виртуализированные решения должны быть приземлены на физическую инфраструктуру, к которой предъявляют все более высокие требования. Но на первый план выходит экспертиза и возможность предложить новые финансовые схемы.
Например, Orange Business Services, выступая в качестве интегратора и создавая решение на рассмотренной выше платформе Meraki не просто перепродает аппаратные компоненты от Cisco — хотя их поставки тоже должны быть выполнены — но и выполняет более важные задачи. Прежде всего это проведение аудита и планирование новой сети, как отмечает Алексей Карташов, технический архитектор Orange Business Service. Также интегратор может предложить бесшовную замену сетевого оборудования, пусконаладочные работы и предоставление новой сети «под ключ» с миграцией, незаметной для сотрудников заказчика. По желанию клиента, Orange Business Services также может вести эксплуатацию сети на новом оборудовании.
Отметим, что мы рассмотрели далеко не все варианты виртуализации в инфраструктуре — их много как для отдельных компонент и функциональных модулей, так и для целых кластеров. Кроме того, виртуализация имеет непосредственное отношение к интереснейшей теме «цифровых двойников», которая позволяет компаниям экономить огромные ресурсы, например, с использованием этих моделей повышая надежность работы физического оборудования. Мы коснулись этой темы на примере виртуальных центров обработки данных, но решения такого типа есть для разных промышленных и инфраструктурных объектов — от железнодорожных вагонов до целых городов. Об особенностях создания «цифровых двойников» и разных аспектов их применения мы поговорим в следующий раз.
Источник: Александр Маляревский, внештатный обозреватель CRN/RE