понедельник, января 25, 2016 |
1 комментарий
|
ESX, ESXi, vCenter, vCenter Server Heartbeat, VMware, VMware Server, VMware Workstation
Сегодня я хотел бы рассказать вам о продуктах, которые раньше выпускались компанией VMware, но по тем или иным причинам были сняты с продаж и перестали развиваться. Список далеко не полный и содержит, по большей части, мое мнение о продуктах по результатам работы с ними.
VMware ESX Server - первый гипервизор типа 1 для процессоров Intel x86. ESX не был первым серверным гипервизором, и даже не был первым продуктом VMware. Однако в нем впервые были реализованы такие функции, как живая миграция ВМ (vMotion), высокая доступность ВМ (High Availability), автоматическая балансировка (Distributed Resource Scheduler), управление питанием (Distributed Power Management) и многое другое.
Кстати, вы никогда не задавались вопросом, что значить аббревиатура ESX? Так вот, ESX - это Elastic Sky X. Что лишний раз доказывает, что еще в далеком 2002 VMware разрабатывала свои продукты с оглядкой на облачные вычисления...
ESX строился на базе монолитной архитектуры, все драйверы, сеть и подсистема ввода-вывода работали на уровне гипервизора. Однако для управления гиперзовиром на каждом хосте устанавливалась небольшая служебная ВМ - Service Console на базе модифицированного дистрибутива Red Hat Linux. С одной стороны, это накладывало ряд ограничений - служебная ВМ отъедала часть вычислительных ресурсов хоста, ее диски, как и любой другой ВМ требовалось размещать на VMFS хранилище, а каждый хост нуждался, по меньшей мере, в двух IP адресах, один - для VMKernel интерфейса, второй - для Service Console. С другой стороны, Service Console предоставляла возможность установки стороннего ПО (агентов, плагинов), которые расширяли возможности по мониторингу и управлению гипервизором. Наличие Service Console породило распространенное заблуждение, что гипервизор ESX является модифицированным Linux'ом.
Стоит упомянуть, что первые версии ESX устанавливались и управлялись по отдельности, однако, начиная ESX 2.0, для централизованного управления несколькими хостами появился VMware VirtualCenter (ныне хорошо известный под именем vCenter Server). Тогда, собственно, и появился Virtual Infrastructure, который представлял собой набор продуктов для виртуализации, состоящий из гипервизора ESX и ПО управления VirtualCenter. К версии 4.0 Virtual Infrastructure был переименован в vSphere.
В 2008 году появился альтернативный гипервизор - ESXi, который не нуждался в Service Console, был гораздо меньше в размере, но не поддерживал многое из того, что умел ESX (у ESXi отсутствовал WEB интерфейс, встроенный брандмауэр, возможность загрузки по SAN, интеграция с Active Directory и пр.). С каждой новой версией VMware постепенно наращивала функционал ESXi. VMware vSphere 4.1 стал последним релизом, включающим гипервизор ESX. Начиная с 5.0 VMware оставила только ESXi.
Как и старший собрат GSX поддерживал централизованное управление через VirtualCenter.
Позже GSX был переименован в VMware Server, получил при этом возможность запускать 64-битные ВМ, а также выделять ВМ несколько виртуальных процессоров. Вышедший в конце 2008 года VMware Server 2.0 стал бесплатным, обзавелся полноценным веб-интерфейсом и возможностью проброса USB устройств внутрь ВМ, однако потерял поддержку VMware VirtualCenter.
К этому времени гипервизоры ESX и ESXi заняли большую часть рынка серверной виртуализации. Выход бесплатных версий VMware ESXi Free и Microsoft Hyper-V Server стали последним гвоздем в крышку гроба VMware Server. VMware и Microsoft забросили свои гипервизоры для серверных ОС.
В основе механизма защиты лежала идея организации двухузлового кластера, работающего в режиме active-passive. Пассивный узел следил за состоянием основного узла, и в случае его недоступности, запускал кластеризованные сервисы. Для работы кластера не требовалось общее хранилище, т.к. изменения, выполненые на активном узле периодически реплицировались на пассивный узел. vCenter Heartbeat обеспечивал защиту как физических, так и виртуальных, и даже смешанных конфигураций vCenter, когда один узел был физическим, а второй - виртуальным.
Хотя какое-то время vCenter Heartbeat и был единственным способом обеспечить защиту vCenter не только от аппаратных, но и от программных сбоев, реализация откровенно хромала. Сложная процедура установки и обслуживания кластера, а также масса багов сделали свое черное дело. В итоге, начиная с vSphere 5.5 U3 / vSphere 6.0 компания VMware отказалась от vCenter Heartbeat и вернулась к более привычному способу кластеризации средствами Microsoft Failover Cluster.
Помимо обновления гостевых ОС, vCenter Protect позволял выполнять инвентаризацию программного и аппаратного обеспечения, запускать различные сценарии по расписанию, выполнять проверку на наличие уязвимостей.
Но, по всей вимости, продажи шли не очень хорошо, кроме того в портфеле VMware был vRealize Configuration Manager, приобретенный в 2010 у EMC, и выполнявший функции патч-менеджмента, инвентаризации и многого другого. Поэтому в 2013 vCenter Protect был продан компании LANDesk.
На каждом хосте ESXi развертывался специальный апплайнс VSA. Виртуальные диски VSA размещались на VMFS хранилище, созданном на томах локального RAID контроллера. Половина дискового пространства предназначалась для зеркалирования данных с другого VSA (этакий сетевой аналог RAID 1), расположенного на соседнем хосте, половина оставалась под полезные данные. Затем каждый апплайнс презентовал свое зеркалируемое хранилище по протоколу NFS обратно всем хостам виртуализации. Одна инсталляция поддерживала 2 или 3 хоста виртуализации, при использовании 2 хостов vCenter Server выполнял роль арбитра и должен был разворачиваться на отдельном физическом сервере или хосте ESXi, не входящем в VSA.
Функционал VSA был весьма ограниченным. Так, например, первая версия VSA поддерживала размещение только на VMFS томах с RAID 1 или 10, что приводило к высоким накладным расходам на хранение данных (фактически, полезное пространство составляло менее 1/4 от объема локальных дисков), отсутствовала поддержка VAAI, не было поддержки кэширования или тиринга.
Все это в совокупности с не слишком низкой ценой и невысокой производительностью не позволили VSA вытеснить привычные СХД из SMB сегмента. Поэтому вскоре после выхода первой версии Virtual SAN в 2014, продукт был снят с продаж.
Перпективная разработка в области программно-определяемых хранилищ данных, Virsto представлял собой виртуальный апплайнс, выполняющий роль виртуализатора СХД, т.е. ресурсы СХД презентовались аплайнсу, а аплайнс, в свою очередь, отдавал дисковое пространство хостам по протоколу NFS. Сердцем Virsto была VirstoFS - специализированная файловая система, позволяющая оптимизировать операции записи и чтения за счет использования механизмов, схожих с теми, что можно видеть в СХД NetApp FAS. Virsto мог аккумулировать случайные операции записи в специальном журнале и затем последовательно записывать данные на СХД, что положительно сказывалось на IOPS и задержках. Кроме того, Virsto поддерживал многоуровневое хранение данных (тиринг) и оптимизировал работу со снапшотами за счет хранения в оперативной памяти метаданных о том, какой блок с данными в каком из снимков находится.
Несмотря на то, что продукт так и не вышел, старания разработчиков не прошли даром - в Virtual SAN 6.0 вместо VMFS-L появился новый формат разметки дисков на базе VirstoFS и поддержка "продвинутых" снапшотов.
По сути Lab Manager являлся менеджером менеджеров, разворачивался поверх существующей инсталляции VMware ESX/ESXi и vCenter и позволял организовывать многопользовательский (многоарендный) доступ к общей виртуальной инфраструктуре, выделять пользователям необходимый набор вычислительных ресурсов, автоматически выдавать IP адреса ВМ из пулов, создавать изолированные сети для ВМ, указывать срок аренды для ВМ.
С ростом популярности темы облачных вычислений VMware переключилась на другой продукт - vCloud Director, постепенно перенеся из Lab Manager все наработанные фишки и закрыв его.
ACE работал в связке с клиентскими гипервизорами VMware Workstation и Player и позволял управлять ВМ на основании заданных политик. С помощью политик администраторы могли ограничить функционал ВМ (например, отключить проброс USB устройств или контролировать доступ в сеть), принудительно шифровать виртуальные диски, разрешать доступ к ВМ только для авторизованных пользователей, настраивать срок жизни ВМ, по истечении которого ВМ переставала запускаться и т.д. ВМ вместе с политиками и гипервизором VMware Player могли быть экспортированы в виде готово пакета Pocket ACE и переданы пользователю любым удобным способом (на CD-диске, flash-накопителе или по сети). При необходимости, администратор мог развернуть в сети сервер ACE Management Server, к которому подключались клиентские гипервизоры и запрашивали актуальные настройки политик для ВМ.
Не смотря на интересный функционал, продукт не получил широкого распространения, и по словам VMware не отвечал всем требованиям тех немногих заказчиков, что его использовали, поэтому в 2011 он был снят с продажи. Спустя несколько лет на смену ACE пришел VMware Horizon FLEX, имеющий собственный механизм доставки ВМ на компьютеры пользователей, а также поддерживающий гипервизор VMware Fusion Pro для ОС Apple MAC OS X.
VMware ESX Server
Начну, пожалуй, с самого значимого продукта, благодаря которому VMware стала лидером на рынке серверной виртуализации.VMware ESX Server - первый гипервизор типа 1 для процессоров Intel x86. ESX не был первым серверным гипервизором, и даже не был первым продуктом VMware. Однако в нем впервые были реализованы такие функции, как живая миграция ВМ (vMotion), высокая доступность ВМ (High Availability), автоматическая балансировка (Distributed Resource Scheduler), управление питанием (Distributed Power Management) и многое другое.
Кстати, вы никогда не задавались вопросом, что значить аббревиатура ESX? Так вот, ESX - это Elastic Sky X. Что лишний раз доказывает, что еще в далеком 2002 VMware разрабатывала свои продукты с оглядкой на облачные вычисления...
ESX строился на базе монолитной архитектуры, все драйверы, сеть и подсистема ввода-вывода работали на уровне гипервизора. Однако для управления гиперзовиром на каждом хосте устанавливалась небольшая служебная ВМ - Service Console на базе модифицированного дистрибутива Red Hat Linux. С одной стороны, это накладывало ряд ограничений - служебная ВМ отъедала часть вычислительных ресурсов хоста, ее диски, как и любой другой ВМ требовалось размещать на VMFS хранилище, а каждый хост нуждался, по меньшей мере, в двух IP адресах, один - для VMKernel интерфейса, второй - для Service Console. С другой стороны, Service Console предоставляла возможность установки стороннего ПО (агентов, плагинов), которые расширяли возможности по мониторингу и управлению гипервизором. Наличие Service Console породило распространенное заблуждение, что гипервизор ESX является модифицированным Linux'ом.
Стоит упомянуть, что первые версии ESX устанавливались и управлялись по отдельности, однако, начиная ESX 2.0, для централизованного управления несколькими хостами появился VMware VirtualCenter (ныне хорошо известный под именем vCenter Server). Тогда, собственно, и появился Virtual Infrastructure, который представлял собой набор продуктов для виртуализации, состоящий из гипервизора ESX и ПО управления VirtualCenter. К версии 4.0 Virtual Infrastructure был переименован в vSphere.
В 2008 году появился альтернативный гипервизор - ESXi, который не нуждался в Service Console, был гораздо меньше в размере, но не поддерживал многое из того, что умел ESX (у ESXi отсутствовал WEB интерфейс, встроенный брандмауэр, возможность загрузки по SAN, интеграция с Active Directory и пр.). С каждой новой версией VMware постепенно наращивала функционал ESXi. VMware vSphere 4.1 стал последним релизом, включающим гипервизор ESX. Начиная с 5.0 VMware оставила только ESXi.
VMware GSX Server / Server
Долгие годы VMware GSX Server выпускался параллельно с VMware ESX. Ground Storm X (так расшифровывается аббревиатура GSX) представлял собой гипервизор второго типа и устанавливался поверх серверных ОС Microsoft Windows, RedHat или SUSE Linux. Использование гипервизора тип 2 имело свои плюсы. Во-первых, GSX поддерживал гораздо более широкий перечень оборудования и мог работать даже на десктопном железе в отличие от "капризного" ESX. Во-вторых, VMware GSX был крайне прост в установке и настройке, любой, кто работал с VMware Workstation, был способен управиться и с GSX. В-третьих, GSX имел встроенный NAT и DHCP сервер, что позволяло легко настраивать сеть для ВМ.Как и старший собрат GSX поддерживал централизованное управление через VirtualCenter.
Позже GSX был переименован в VMware Server, получил при этом возможность запускать 64-битные ВМ, а также выделять ВМ несколько виртуальных процессоров. Вышедший в конце 2008 года VMware Server 2.0 стал бесплатным, обзавелся полноценным веб-интерфейсом и возможностью проброса USB устройств внутрь ВМ, однако потерял поддержку VMware VirtualCenter.
К этому времени гипервизоры ESX и ESXi заняли большую часть рынка серверной виртуализации. Выход бесплатных версий VMware ESXi Free и Microsoft Hyper-V Server стали последним гвоздем в крышку гроба VMware Server. VMware и Microsoft забросили свои гипервизоры для серверных ОС.
VMware vCenter Server Heartbeat
Продукт, предназначенный для обеспечения высокой доступности служб vCenter и смежных сервисов (СУБД, SSO, Update Manager), разрабатывался не самой VMware, а сторонней компанией - Neverfail Group.
В основе механизма защиты лежала идея организации двухузлового кластера, работающего в режиме active-passive. Пассивный узел следил за состоянием основного узла, и в случае его недоступности, запускал кластеризованные сервисы. Для работы кластера не требовалось общее хранилище, т.к. изменения, выполненые на активном узле периодически реплицировались на пассивный узел. vCenter Heartbeat обеспечивал защиту как физических, так и виртуальных, и даже смешанных конфигураций vCenter, когда один узел был физическим, а второй - виртуальным.
Хотя какое-то время vCenter Heartbeat и был единственным способом обеспечить защиту vCenter не только от аппаратных, но и от программных сбоев, реализация откровенно хромала. Сложная процедура установки и обслуживания кластера, а также масса багов сделали свое черное дело. В итоге, начиная с vSphere 5.5 U3 / vSphere 6.0 компания VMware отказалась от vCenter Heartbeat и вернулась к более привычному способу кластеризации средствами Microsoft Failover Cluster.
VMware vCenter Protect
Для тех из вас, кто работал с vSphere хотя бы с 4-й версии, должно быть известно, что в то время vCenter Update Manager поддерживал установку обновлений не только для гипервизоров ESX/ESXi, но также гостевых операционных систем и различного ПО. Однако начиная с 5.0 данный функционал был исключен из Update Manager, вместо этого VMware стала предлагать отдельный продукт - VMware vCenter Protect, который был приобретен вместе с компанией Shavlik.
Помимо обновления гостевых ОС, vCenter Protect позволял выполнять инвентаризацию программного и аппаратного обеспечения, запускать различные сценарии по расписанию, выполнять проверку на наличие уязвимостей.
Но, по всей вимости, продажи шли не очень хорошо, кроме того в портфеле VMware был vRealize Configuration Manager, приобретенный в 2010 у EMC, и выполнявший функции патч-менеджмента, инвентаризации и многого другого. Поэтому в 2013 vCenter Protect был продан компании LANDesk.
VMware Virtual Storage Appliance
Virtual Storage Appliance - первая попытка VMware играть на рынке программно-определяемых СХД. VSA предназначался для SMB и позволял создавать общую отказоустойчивую СХД на базе локальных дисков, устанавленных в сервер.На каждом хосте ESXi развертывался специальный апплайнс VSA. Виртуальные диски VSA размещались на VMFS хранилище, созданном на томах локального RAID контроллера. Половина дискового пространства предназначалась для зеркалирования данных с другого VSA (этакий сетевой аналог RAID 1), расположенного на соседнем хосте, половина оставалась под полезные данные. Затем каждый апплайнс презентовал свое зеркалируемое хранилище по протоколу NFS обратно всем хостам виртуализации. Одна инсталляция поддерживала 2 или 3 хоста виртуализации, при использовании 2 хостов vCenter Server выполнял роль арбитра и должен был разворачиваться на отдельном физическом сервере или хосте ESXi, не входящем в VSA.
Функционал VSA был весьма ограниченным. Так, например, первая версия VSA поддерживала размещение только на VMFS томах с RAID 1 или 10, что приводило к высоким накладным расходам на хранение данных (фактически, полезное пространство составляло менее 1/4 от объема локальных дисков), отсутствовала поддержка VAAI, не было поддержки кэширования или тиринга.
Все это в совокупности с не слишком низкой ценой и невысокой производительностью не позволили VSA вытеснить привычные СХД из SMB сегмента. Поэтому вскоре после выхода первой версии Virtual SAN в 2014, продукт был снят с продаж.
VMware Virsto
Еще одна жертва Virtual SAN, продукт одноименной компании, которую VMware приобрела в 2013 году. Насколько мне известно, после покупки Virsto так и не появился в прайс-листах, а был практически сразу же помножен на ноль.Перпективная разработка в области программно-определяемых хранилищ данных, Virsto представлял собой виртуальный апплайнс, выполняющий роль виртуализатора СХД, т.е. ресурсы СХД презентовались аплайнсу, а аплайнс, в свою очередь, отдавал дисковое пространство хостам по протоколу NFS. Сердцем Virsto была VirstoFS - специализированная файловая система, позволяющая оптимизировать операции записи и чтения за счет использования механизмов, схожих с теми, что можно видеть в СХД NetApp FAS. Virsto мог аккумулировать случайные операции записи в специальном журнале и затем последовательно записывать данные на СХД, что положительно сказывалось на IOPS и задержках. Кроме того, Virsto поддерживал многоуровневое хранение данных (тиринг) и оптимизировал работу со снапшотами за счет хранения в оперативной памяти метаданных о том, какой блок с данными в каком из снимков находится.
Несмотря на то, что продукт так и не вышел, старания разработчиков не прошли даром - в Virtual SAN 6.0 вместо VMFS-L появился новый формат разметки дисков на базе VirstoFS и поддержка "продвинутых" снапшотов.
VMware Lab Manager
Продукт для автоматизации развертывания и управления жизненным циклом ВМ в тестовых окружениях.По сути Lab Manager являлся менеджером менеджеров, разворачивался поверх существующей инсталляции VMware ESX/ESXi и vCenter и позволял организовывать многопользовательский (многоарендный) доступ к общей виртуальной инфраструктуре, выделять пользователям необходимый набор вычислительных ресурсов, автоматически выдавать IP адреса ВМ из пулов, создавать изолированные сети для ВМ, указывать срок аренды для ВМ.
С ростом популярности темы облачных вычислений VMware переключилась на другой продукт - vCloud Director, постепенно перенеся из Lab Manager все наработанные фишки и закрыв его.
VMware ACE
Закончить обзор я хочу на достаточно редком звере - VMware ACE. Еще до появления VDI в своем классическом виде и широкого распространения BYOD компания VMware предлагала клиентам ПО для централизованного управления виртуальными рабочими станциями, которые могли запускаться на персональных компьютерах пользователей - VMware ACE.
ACE работал в связке с клиентскими гипервизорами VMware Workstation и Player и позволял управлять ВМ на основании заданных политик. С помощью политик администраторы могли ограничить функционал ВМ (например, отключить проброс USB устройств или контролировать доступ в сеть), принудительно шифровать виртуальные диски, разрешать доступ к ВМ только для авторизованных пользователей, настраивать срок жизни ВМ, по истечении которого ВМ переставала запускаться и т.д. ВМ вместе с политиками и гипервизором VMware Player могли быть экспортированы в виде готово пакета Pocket ACE и переданы пользователю любым удобным способом (на CD-диске, flash-накопителе или по сети). При необходимости, администратор мог развернуть в сети сервер ACE Management Server, к которому подключались клиентские гипервизоры и запрашивали актуальные настройки политик для ВМ.
Не смотря на интересный функционал, продукт не получил широкого распространения, и по словам VMware не отвечал всем требованиям тех немногих заказчиков, что его использовали, поэтому в 2011 он был снят с продажи. Спустя несколько лет на смену ACE пришел VMware Horizon FLEX, имеющий собственный механизм доставки ВМ на компьютеры пользователей, а также поддерживающий гипервизор VMware Fusion Pro для ОС Apple MAC OS X.
