Vmware vds что это
vSphere Distributed Switch
Осуществляйте настройку, мониторинг и администрирование коммутаторов доступа для виртуальных машин во всем ЦОД с помощью централизованного интерфейса, предоставляемого решением vSphere Distributed Switch.
Обзор
Что представляет собой решение vSphere Distributed Switch и как оно повышает эффективность сетей ВМ?
Распределенный коммутатор VMware vSphere Distributed Switch (VDS) предоставляет централизованный интерфейс для настройки, мониторинга и администрирования доступа к виртуальным машинам для всего ЦОД. VDS предоставляет следующие преимущества:
Возможности
Упрощенная настройка сети виртуальных машин
Воспользуйтесь следующими возможностями VDS, чтобы оптимизировать инициализацию, администрирование и мониторинг виртуальных сетей на нескольких узлах:
Расширенные возможности мониторинга сети и устранения неполадок
VDS предоставляет следующие возможности мониторинга и устранения неполадок:
Поддержка передовых сетевых технологий vSphere
VDS предоставляет структурные блоки для многих сетевых возможностей в среде vSphere, в том числе следующие:
Принцип работы
Технические сведения
VDS расширяет функции и возможности виртуальных сетей, а также упрощает процессы инициализации, текущей настройки, мониторинга и управления.
Сетевые коммутаторы vSphere можно разделить на две логические части: плоскость данных и плоскость управления. Плоскость данных предоставляет возможность коммутации пакетов, фильтрации, использования тегов и т. д. Плоскость управления — это структура контроля, используемая оператором для настройки возможностей плоскости данных. Каждый стандартный коммутатор vSphere (VSS) имеет плоскости данных и управления, а администратор настраивает и поддерживает каждый коммутатор отдельно.
VDS упрощает управление, рассматривая сеть как объединенный ресурс. Отдельные виртуальные коммутаторы на уровне узла абстрагируются в один большой коммутатор VDS, охватывающий несколько узлов на уровне ЦОД. В этой архитектуре плоскость данных остается локальной для каждого коммутатора VDS, а плоскость управления — централизованной.
Каждый экземпляр VMware vCenter Server может поддерживать до 128 VDS, а каждый VDS может контролировать до 500 узлов.
Дополнительные сведения
Распределенные виртуальные группы портов (группы DV-портов) позволяют определить параметры конфигурации портов для каждого задействованного порта.
Распределенные виртуальные исходящие подключения (dvUplink) обеспечивают уровень абстрагирования для адаптеров физической сети (vmnics) на каждом узле.
Поддержка частной сети VLAN (PVLAN) предоставляет возможности более широкой совместимости с существующими сетевыми средами, использующими данную технологию.
Сетевая функция vMotion упрощает мониторинг и устранение неполадок путем отслеживания состояния сети (например, с помощью счетчиков и статистики портов) каждой виртуальной машины при перемещении между узлами в VDS.
Функция двунаправленного формирования трафика применяет политики формирования трафика для определений групп DV-портов, которые зависят от максимального объема трафика, а также средней и пиковой пропускной способности.
VMware vDS – логический коммутатор облачной инфраструктуры
Возможности и функции vSS и vDS во многом схожи, но существуют отличия, которые делают vDS более гибким для сетевых администраторов.
Одним из основных компонентов виртуальной инфраструктуры, построенной на решении vSphere от VMware, является виртуальный L2-коммутатор vSwitch. Довольно продолжительное время администраторам vSphere был доступен только стандартный коммутатор vSphere Standard Switches (vSS), способный работать лишь с одним физическим хостом ESXi. Из-за этого ограничения требовалось устанавливать vSS на каждый сервер и индивидуально настраивать, например при создании группы портов для дополнительного VLAN ее необходимо продублировать на каждом хосте.
В версии vSphere 4.0 разработчики добавили новый тип коммутатора — vNetwork Distributed vSwitch (vDS), один экземпляр которого способен работать со всеми серверами ESXiодновременно. Также vDS позволяет осуществлять мониторинг состояния сетевых компонентов инфраструктуры и имеет функции по управлению трафиком.
Возможности и функции vSS и vDS во многом схожи, но существуют отличия, которые делают vDS более гибким для сетевых администраторов.
Еще одной важной особенностью распределенного коммутатора VMware vSphere Distributed Switch является возможность резервного копирования и восстановления сети в случае сбоя. Сетевой администратор может осуществлять перенос vDS в другую виртуальную инфраструктуру, производить миграцию путем сохранения и восстановления настроек.
Плюсы и особенности централизованного управления
Централизованное управление делает настройку сети VMware vSphere быстрой и удобной. Можно сравнить с протоколом VTP от Cisco, когда при настройке на сервере VTP новой сети VLAN она становится доступной всем коммутаторам в домене. При использовании vDS настройка всех хостов производится из одной панели управления vCenter, доступ к которой можно организовать из management сети.
Управление коммутатором через vCenter имеет еще одно важное преимущество: каждый хост сохраняет на себя копию параметров vDS и регулярно ее обновляет. В случае падения vCenter хосты продолжают работать с заданными параметрами. В это время администратор может спокойно восстановить работу без какой-либо деградации ее качества. Дополнительные сложности могут возникнуть только при необходимости внести изменения в настройки сети, пока vCenter недоступен, придется подключить виртуальные машины к стандартному коммутатору на хосте и производить изменения на нем.
Чем меньше ручных настроек производит сетевой администратор vSphere, тем ниже вероятность допустить ошибки. Настройка vSS производится индивидуально для каждого хоста. Когда их два-три, осуществлять контроль и мониторинг параметров не представляет сложности, но если число серверов измеряется десятками, то распространение конфигурации начинает занимать много сил, времени и ответственности.
Не стоит забывать, что программно-определяемый механизм vDS предоставляет целый ряд дополнительных функций для повышения производительности и надежности сети, таких как механизмы фильтрации трафика и контроля сетевых операций ввода-вывода.
Что выбирают облачные провайдеры — vSS или vDS?
Облачные провайдеры, предлагающие услуги IaaS, выбирают vDS, так как он обладает большей гибкостью и содержит в себе такие возможности, как:
— централизованная настройка сети пула хостов ESXi
— расширенные функции для сетевых администраторов
— контроль и мониторинг сетевых элементов инфраструктуры IaaS
— резервное копирование, восстановление и миграция настроек сети
— управление трафиком
По сравнению с vSS, который доступен в любой версии vSphere, даже бесплатной, использовать vDS можно только купив лицензию Enterprise Plus — самую дорогую в линейке VMware. Зрелый облачный провайдер не использует пробные или бесплатные версии платформ виртуализации, так как только старшие лицензии позволяют получить максимум функций для создания надежной, эффективной и производительной виртуальной инфраструктуры.
Лицензированная платформа и техническое сопровождение vSphere позволяют получать регулярные обновление, исправляющие ошибки, добавляющие новые возможности и расширяющие лимиты на те или иные элементы инфраструктуры, в том числе и vDS. Так, например, с версии vSphere 5 администратору доступна возможность зеркалирования портов и добавлен протокол обнаружения канального уровня, а vSphere 6.5 увеличила максимальное число хостов на один виртуальный коммутатор с 1000 до 2000.
Заключение
При создании собственной виртуальной инфраструктуры на компанию ложится бремя покупки дорогих лицензий vSphere Enterprise Plus — только с ними можно реализовать централизованное управление сетями хостов ESXi и использовать дополнительные функции. Другой вариант решения этой задачи — аренда виртуальной инфраструктуры IaaS у облачного провайдера, который берет на себя закупку всех необходимых лицензий и оборудования, а также отвечает за его настройку и эффективную эксплуатацию. Клиент получает готовый к внедрению в собственную инфраструктуру продукт.
vSphere Distributed Switch
Configure, monitor, and administer virtual machine access switches for the entire data center with the centralized interface delivered by vSphere Distributed Switch.
Overview
What is vSphere Distributed Switch and how it helps in Virtual Machine Networking?
VMware vSphere Distributed Switch (VDS) provides a centralized interface from which you can configure, monitor and administer virtual machine access switching for the entire data center. The VDS provides:
Features
Simplified Virtual Machine Network Configuration
Use the following VDS features to streamline provisioning, administration and monitoring of virtual networking across multiple hosts:
Enhanced Network Monitoring and Troubleshooting Capabilities
The VDS provides the following monitoring and troubleshooting capabilities:
Support for Advanced vSphere Networking Features
The VDS supplies the building blocks for many networking capabilities in the vSphere environment, including the following:
How it Works
Technical Details
The VDS extends the features and capabilities of virtual networks while simplifying provisioning and the ongoing configuration, monitoring and management process.
vSphere network switches can be divided into two logical sections: the data plane and the management plane. The data plane implements the packet switching, filtering, tagging and so on. The management plane is the control structure used by the operator to configure data plane functionality. Each vSphere Standard Switch (VSS) contains both data and management planes, and the administrator configures and maintains each switch individually.
The VDS eases this management burden by treating the network as an aggregated resource. Individual host-level virtual switches are abstracted into one large VDS spanning multiple hosts at the data-center level. In this design, the data plane remains local to each VDS but the management plane is centralized.
Each VMware vCenter Server instance can support up to 128 VDSs; each VDS can manage up to 500 hosts.
Additional Details
Distributed Virtual Port Groups (DV Port Groups) — Allows you to specify port configuration options for each member port.
Distributed Virtual Uplinks (dvUplinks) — Provides a level of abstraction for the physical network adaptors (vmnics) on each host.
Private VLAN (PVLAN) Support — Enables broader compatibility with existing networking environments using the technology.
Network vMotion — Simplifies monitoring and troubleshooting by tracking the networking state (such as counters and port statistics) of each virtual machine as it moves from host to host on a VDS.
Bi-directional Traffic Shaping — Applies traffic shaping policies on DV port group definitions, defined by average bandwidth, peak bandwidth and burst size.
Обзор российского рынка VMware-хостинга. Сравнение ведущих провайдеров корпоративного IaaS в России
Облачный рынок в России формируется весьма динамично и уже сейчас можно выделить отдельный сегмент в нише аренды виртуальной инфраструктуры – так называемый «корпоративный» IaaS. Его отличает, в первую очередь, использование коммерческих гипервизоров и управляющего ПО, высокие требования к аппаратной составляющей, при относительно более высокой стоимости облачных ресурсов. При этом, переплачивая за лицензии гипервизора и за использование high-end оборудования, корпоративный заказчик получает необходимые ему функциональные возможности, например, функциональность HA (высокая доступность), поддержку любых гостевых ОС, возможность интеграции с собственной виртуальной инфраструктурой и пр.
Безусловным лидером виртуализации серверных ресурсов для корпоративного сегмента сегодня является VMware. В этом посте я поделюсь информацией из реального проекта по развертыванию виртуального дата-центра, в ходе которого сравнивались все официально существующие и реально действующие на сегодняшний день в России VMware сервис-провайдеры. Ниже будет приведена подробная информация по отличительным особенностям таких компаний и мои соображения по этому поводу.
Отдельно следует подчеркнуть, что всё что вы узнаете ниже не имеет никакого отношения к рынку VPS / VDS хостинга и потребностям компаний, обходящихся одним сервером и двумя айтишниками (Корпоративным называют то, что относится к крупной компании, корпорации. – Толковый словарь русского языка Дмитриева. Д. В. Дмитриев. 2003).
Короткая предыстория. Один крупный корпоративный стартап выбирал площадку для организации виртуального дата-центра. Стартовых критериев отбора поставщиков – всего два:
1. Основная площадка должна находиться в России.
2. Используемая платформа виртуализации должна быть VMware.
Глубоко вдаваться в детали выбора в качестве гипервизора VMware не буду, замечу только, что критичными аргументами в пользу такого решения были: имеющийся положительный опыт работы с гипервизором, функции «High Availability», «vMotion», поддержка требуемых ОС, возможности по сопряжению с собственной виртуальной инфраструктурой, и, на перспективу, возможность использования функциональности SRM. Но речь не об этом, поэтому дополнительную аргументацию приводить не будем и возьмём эти исходные предпосылки как данность.
Основная площадка – в России, для обеспечения минимальных задержек и приемлемого по стоимости выделенного подключения к облаку. На перспективу плюсом для провайдера будем считать наличие второй аналогичной по архитектуре площадки, возможно, зарубежной.
Поехали. Где взять список Российский VMware сервис-провайдеров? Чтобы отсечь всевозможных агентов и реселлеров типа 1cloud, идём на http://partnerlocator.vmware.com/, указываем Country – Russian Federation, Partner Type – «Service Provider». Получаем список партнеров VMware, официально предоставляющих IaaS в России. В списке 12 компаний. Для честности отсортируем их по дате начала предоставления услуг в статусе VMware Service Provider, т.к. порядок выдачи в партнер-локаторе мне совершенно непонятен.
Итак, вот список героев.
Провайдер IaaS | Сайт | С какого года предоставляет IaaS в статусе VMware Service Provider | Партнерский статус VSPP | |
---|---|---|---|---|
1. | IT-GRAD | http://www.it-grad.ru/ | 2008 | Enterprise |
2. | Dataline | http://www.dtln.ru/ | 2009 | Premier |
3. | Cloudone | http://www.cloudone.ru/ | 2010 | Professional |
4. | ONLANTA | http://www.onlanta.ru/ | 2011 | Enterprise |
5. | SafeData | http://www.safedata.ru/ | 2011 | Enterprise |
6. | Cloud4Y | http://www.cloud4y.ru/ | 2011 | Professional |
7. | Croc | http://www.croc.ru/ | 2012 | Enterprise |
8. | I-Teco | http://www.i-teco.ru/ | 2012 | Enterprise |
9. | MegaFon | https://server.megafon.ru/ | 2012 | Enterprise |
10. | RTComm-Sibir | http://www.rtcomm-sibir.ru/ | 2012 | Professional |
11. | SoftLine | http://www.softcloud.ru | 2014 | Enterprise |
12. | DEPO Electronics | http://www.depo.ru/ | 2014 | Professional |
Сразу медали получают ИТ-ГРАД за самый большой опыт и Даталайн за самый высокий партнерский статус.
Следующий шаг – нам нужно понимание ориентировочных цен на облачные ресурсы. У большинства из перечисленных провайдеров на сайтах есть калькуляторы, считающие общую стоимость машины или пула по некоторым нелинейным формулам. Для корпоративного уровня это, разумеется, не годится. Нам нужны будут фиксированные цены на каждый из ресурсов, прописанные в договоре. Более того, даже те цены, которые мы получим в первом коммерческом предложении, являются только отправной точкой для отжимания реальной цифры, например, путём проведения тендера или аукциона. В этом сегменте, уже на объёме от 100 000 р. ежемесячного платежа можно согласовать существенную скидку даже не пугая провайдера более низкими ценами конкурентов и без всякого конкурса.
Другими словами, те цены, которые мы увидим в таблице на основе первых полученных коммерческих предложений, не являются теми ценами, которые в итоге будут в нашем договоре, и представлены исключительно для понимания порядка значений. На текущем этапе нас должна больше интересовать модель и принципы ценообразования. В этом плане, с учетом однородности гипервизора и управляющего программного обеспечения, мы не имеем такого многообразия как на рынке бюджетного облачного хостинга.
Запросив коммерческие предложения, мы получаем понимание, что в этой нише используются две основные модели биллинга:
Статические модели различаются размером биллингуемого периода. Также к ним могут применяться жесткие тарифные сетки с заданным соотношением объёма CPU / RAM, что является неудобным ограничением.
Динамическая модель может включать ресурс жесткого диска, в этом случае гигабайт занятого пространства обойдется несколько дороже, чем гигабайт выделенного дискового пространства. Либо не включать, тогда стоимость HDD будет браться по аналогии со стоимостью статической модели.
Динамическую модель биллинга поддерживают не все провайдеры. Связано это с тем, что подходит она, как правило, в основном для тестовых сред и сред разработки. Для корпоративного продакшна получается дороговато. Тем не менее, для тех, кто занимается разработкой собственного ПО, наличие динамической модели – это весомый плюс к возможности сэкономить.
Запрашивая коммерческие предложения в некоторых компаниях, придется столкнуться с квестом под названием «получить именно VMware». Например, в Айтеко вам по умолчанию предложат бюджетный MakeCloud на платформе OpenStack, в то время как на VMware у них отдельно реализован так называемый «Enterprise Cloud». В КлаудФоУай дефолтом тест вам выдадут на Citrix Xen. А в КРОКе вам скажут, что в их облаке используется виртуализация Red Hat KVM, так что придется отдельно уточнить, какой гипервизор нам необходим.
Пройдя первый квест, в большинстве случаев придется столкнуться со вторым – получить отдельные цены на CPU, RAM и HDD, а не просто стоимость запрошенного пула целиком. Да, и еще, желательно, в рублях. У многих провайдеров цены предлагаются в долларах, евро или у.е., но поскольку мы с вами в корпоративном сегменте, при желании без проблем нам все пересчитают в рубли и даже впишут эти цифры в договор. Курс конвертации, правда, может совсем не порадовать.
Так или иначе, через несколько почтовых итераций, мы получаем отдельные цены в разрезе ресурсов, и при помощи калькулятора приводим всё в формат ежемесячного платежа по статической и динамической модели. Для дисков за эталон сравнения берем HDD SAS 15K или сопоставимые с ними по производительности из перечня предлагаемых провайдером тарифов. Стоимость процессора приводим к стоимости 1 GHz (при необходимости делим стоимость аренды ядра на его тактовую частоту). Еще раз напомню, что цены эти для нашего случая интересны только как ориентировочные, для понимания общей ситуации на рынке. Курс доллара взят на 19.03.2014 г. и равен 36,45 р.
* Минимальные цены при соблюдении соотношения количества ядер процессора к количеству GB оперативной памяти 1:8. Если такое отношение не соблюдается, стоимость будет дороже.
За наличие биллинга по реальному потреблению ресурсов медали получают Даталайн, ИТ-ГРАД и СэйфДата.
Бросающиеся в глаза отдельные заниженные цены на оперативную память наводят на мысль о том, что, возможно, не все провайдеры честно отчитываются перед VMware за лицензии.
Лидеров по самым низким / высоким ценам выделить не получается, общая стоимость будет зависеть от соотношения объёмов отдельных ресурсов (CPU / RAM / HDD), общих объёмов потребления и от результатов переговоров по цене.
Получается, что на рынке IaaS VMware средняя стартовая цена на 1 GHz процессора составляет около 500 р. в месяц, а на 1 GB оперативной памяти – около 600 р. Жесткий диск с производительностью, сравнимой с SAS 15K, обойдется в среднем в 14 рублей за GB.
Если с ресурсом процессоров и оперативной памятью (с учетом использования общей технологии виртуализации) у всех провайдеров все примерно одинаково, и по производительности того и другого вопросов быть не должно, то с дисковой подсистемой все существенно сложнее. Получив в КП позицию «Дисковое пространство HIGH», «HDD FAST» или «HDD SAS 15K», мы не получаем никакого понимания в части того, какая производительность нам будет гарантирована.
Единственное реальное средство оценки потребности в производительности дисковой подсистемы для конкретного приложения – это проведение нагрузочного тестирования с замером текущей нагрузки (в IOPs) и задержки (Latency, в мс) в операционной системе (исключив перед этим паразитную нагрузку других приложений). Практически для любых приложений достаточно latency в 20 мс, более высокие задержки, как правило, начинают сказываться на производительности приложения.
Поэтому, нам следует уточнить этот момент. Предметно интересует – наличие прописанных в договоре (SLA) или хотя бы декларируемых гарантий по количеству операций ввода / вывода в секунду (IOPs) и гарантий по максимальной задержке при обращении к дискам (Latency, мс). А также возможности по управлению производительностью нашей дисковой подсистемы, в разрезе пула или в разрезе отдельных машин (что конечно более предпочтительно).
Немного повозившись с документацией и продавцами, получаем следующую таблицу.
* Согласованные цифры можно вписать в договор по отдельному запросу в зависимости от объема потребления.
В этот раз выдаем медали провайдерам Облако один (за лучшие стартовые показатели производительности, даром, что в типовом SLA у них это не отражено) и ИТ-ГРАД (за технологичность: возможность установить требуемые значения параметров производительности в рамках типового SLA).
Печально, что больше половины провайдеров не в состоянии гарантировать хоть какие-то цифры по производительности дисковой подсистемы. Это значит, что при её деградации нам придется еще очень сильно постараться, чтобы доказать провайдеру, что это действительно инцидент, в то время как наше приложение на это время может полностью потерять работоспособность.
Теперь перейдём, собственно, к гарантиям работоспособности. Обычно у организаций, оказывающих любые ИТ услуги, принято оформлять SLA, в котором фиксируется гарантированная доступность, качественные параметры услуги, уровень сервиса и пр. Удивительно, но не у всех сервис-провайдеров VMware есть SLA, либо под SLA некоторые провайдеры понимают сугубо регламент работы службы технической поддержки.
Поскольку здесь мы приводим сравнение, то обратим внимание на гарантированную доступность и компенсации в случае её нарушения – эти пункты есть если не в SLA, то хотя бы в договоре. Итак, разобрав основные схемы компенсаций, можно выделить следующие:
Как это выглядит в цифрах показано ниже.
* Допускается 1 инцидент со временем решения не более 90 минут
** Доступность за год, 3,3% штрафа за каждые 0,1% снижения доступности. Штраф от суммы платежей за последний квартал.
*** SLA отсутствует.
**** Убытки возмещаются в пределах полученных сумм и должны быть документально подтверждены.
* Компенсация квартального платежа при среднегодовом снижении доступности, приведенная к 1 месяцу. Т.е. если в течение года была недоступность 11 дней, то будет полностью компенсирован последний квартальный платеж.
По результатам приведенного анализа без сомнений вручим медаль компании Софтлайн за самый жесткий SLA в части компенсаций при нарушении доступности.
После доступности, которая есть почти у всех, попробуем оценить насыщенность используемых SLA в части параметров и индикаторов качества. Параметры и индикаторы производительности дисковой подсистемы мы рассмотрели ранее, поэтому сосредоточимся на регламентации качества работы службы поддержки.
После разбора процедурных моментов пришло время посмотреть на такие осязаемые вещи как облачная платформа и площадка её размещения. Начнем с традиционных вопросов относительно железа, которое входит в состав платформы.
Конфигурация типовой серверной ячейки – это, как оказалось, весьма конфиденциальная информация, которой корпоративные IaaS провайдеры делятся крайне неохотно.
За неимением полного объема достоверной информации по этом срезу медали вручать не будем, но стоит выделить важные моменты, такие как используемые поколения процессоров, их частоту и размер серверной ячейки. Очевидно, что более новые процессоры дадут большую производительность на 1 GHz частоты, более высокая тактовая частота на ядро – единственный путь ускорения выполнение приложений, менее эффективно распараллеливающих свою работу, а размер серверной ячейки напрямую ограничивает размер создаваемых виртуальных машин, например, мощных серверов БД. Сокрытие от потенциального клиента подобной информации – явно дурной признак.
Среди систем хранения данных, используемых для построения публичных облаков на VMware, в России лидирует NetApp.
По ряду вопросов без глубоких изысканий различия нам провести не удастся. Например, у всех VMware IaaS провайдеров декларируется наличие двух независимых каналов в интернет с автоматическим переключением средствами сетевого оборудования (проверить можно будет только на практике). У всех по умолчанию декларируется включенная по умолчанию функция HA (High Availability). Все сервис провайдеры формально заявляют о 100% гарантии выделения заявленных ресурсов под клиента.
Ниже состояние ПО виртуализации на первый квартал 2014. Мегафон расстраивает.
Разобравшись с железом и ПО виртуализации, перейдем к обзору площадок, на которых размещаются облачные платформы. Формально все VMware-хостеры заявляют, что их дата-центры соответствуют стандарту TIA-942 Tier 3. Ездить по всем дата-центрам и проверять, так ли это в действительности – не наш вариант. Поэтому наиболее простым и надежным способом будет проверка наличия сертификатов, подтверждённых Uptime Institute:
Подтвержденные UTI сертификаты можно посмотреть здесь: http://uptimeinstitute.com/TierCertification/certMaps.php.
Список подтвержденных VMware площадок можно посмотреть здесь: http://vcloudproviders.vmware.com/vcloud_ecosystem.
Площадки с декларируемой категорией надежности ниже Tier 3 здесь рассматривать не будем, как «некорпоративные». Все перечисленные дата-центры, естественно, при желании можно посетить, договорившись на экскурсию с соответствующим провайдером облака VMware.
По результатам обзора площадок медали получат КРОК и ИТ-ГРАД за полностью сертифицированные по Tier III Uptime Institute площадки.
В итоге мы рассмотрели основные «жесткие» параметры, по которым может сравнить VMware сервис-провайдеров корпоративный клиент. Все данные приведены по состоянию на 1 квартал 2014 года и основаны на данных полученных реальными клиентами в ходе частных закрытых конкурсов на аренду виртуальной инфраструктуры VMware на основе анализа типовых предложений провайдеров.
Приведенные данные могут быть не точными, но хорошая новость в том, что, как говорилось ранее, в корпоративном сегменте имеется возможность подкорректировать многие вещи, грубо говоря, «на ходу», например:
Лидера сравнения в рамках данного обзора VMware сервис провайдеров мы выделять не будем, поскольку для каждого клиента каждый критерий имеет свой собственный вес. Поэтому ограничимся общим впечатлением о сложившемся рынке.
Если посмотреть на развитие рынка Российского VMware хостинга в динамике, то отчетливо можно выделить пионеров: ИТ-ГРАД, Даталайн, Облако один и Сэйфдата. Причем Даталайн и Сэйфдата – это изначально датацентровый бизнес, резвившийся в IaaS. Эти провайдеры размещают свои платформы исключительно на собственных площадках. ИТ-ГРАД и Облако один – изначально облачные компании, размещающие свои мощности в дата-центрах по собственному выбору.
За ними подтягиваются крупные интеграторы и провайдеры связи, такие как КРОК, Айтеко, Ланит, Мегафон и Ростелеком.
И наконец, в первом квартале этого года на рынок VMware хостинга вышли такие интеграторы как Софтлайн и Депо.
Анализ представленных данных показывает, что наиболее проработанные услуги – как с технической, так и с организационной стороны – у компаний, которые первыми стартовали на данном рынке и имеют на текущий момент наибольшее число клиентов, использующих IaaS VMware, благодаря сфокусированной работе по корпоративному сегменту в течение последних пяти лет. По косвенным признакам – это ИТ-ГРАД и Даталайн (реально используемые площадки, уровень оборудования, партнерский статус и прочее). В совершенно зачаточном состоянии IaaS VMware находится у Мегафона и Ростелекома, но для них это, по всей видимости, не критично, так как нацелены они на региональных государственных заказчиков, на спросе со стороны которых это, очевидно, никак не скажется.
Договориться о коррекции услуги и условий её предоставления проще всего будет с компаниями, для которых корпоративный IaaS является основным направлением деятельности (IT-GRAD, Dataline, Cloudone, SafeData, Cloud4Y). Компании-интеграторы (Croc, I-Teco, SoftLine, DEPO, Ланит) более ориентированы на продажу услуги «как есть», притом, что «как есть» значительно отстает по степени проработанности от того, что уже имеется на рынке у специализированных на IaaS провайдерах, либо стараются перевести клиента в привычный для них проектный подход с заряженным ценником за выделенное решение. Федеральные провайдеры связи (Мегафон, Ростелеком) вообще не готовы к диалогу с потенциальным корпоративным коммерческим клиентом при минимальной проработанности своих услуг.
Надеюсь, что приведенный в настоящей статье материал поможет корпоративным заказчикам требовать большего от провайдеров виртуальной инфраструктуры, а провайдерам корпоративного IaaS на VMware – доработать свои предложения.