Подборка публикаций о новой платформе VMware vSphere 6.5 и окружении:
Nested ESXi Enhancements in vSphere 6.5 от William Lam
What’s new in vSphere 6.5 Core Storage от Cormac Hogan
Набор статей от Vladan Seget – vSphere 6.5
Набор статей от Brian Graf – vSphere 6.5
Quick summary of What’s New in vSphere 6.5 от Eric Siebert
What’s New in vSphere 6.5 сборная статья от Ivo Beerens
Big Improvements to vSphere HA and DRS in 6.5 Release от Chris Wahl
VMware Gets Serious about RESTful APIs and Expanding PowerCLI от Chris Wahl
A Look at VMware’s vCenter Server Appliance (VCSA) 6.5 Release от Chris Wahl
What’s new in vSphere 6.5: Security
What’s New in vSphere 6.5: vCenter Server
What’s New in vSphere 6.5: Host & Resource Management and Operations
New vRealize Log Insight 4.0 release
vRealize Automation 7.2 – What’s New
What’s New with VMware Virtual SAN 6.5
Изумительные новости =) Меня особенно радуют:
– доработки VCSA: VUM, дублирование, бэкапы, мониторинг…
– Наконец-то будет реализовано шифрование, да не как нибудь, а с любым KMIP сервером – просто чудесно. фтопку танцы с гостевыми шифровальщиками и угрозой утечки ключа из памяти гостя…
– Здорово что DRS теперь учитывает нагрузку сети…
– VSAN на 2 ноды – наконец то вспомнили о мелких филиалах 🙂
В общем, очень крутой список. Просто праздник какой-то 🙂
Мы строили, строили и наконец построили… Чебурашка(с)
На самом деле ничего особенного, просто наконец-то напинали зад разработчикам и они свои Fling воткнули в основные ветки кода.
Не революционно, просто доделали то, что клиенты платили еще много лет назад.
Меня радует то, что Vmware теперь имеет дело с другой реальностью, когда сказать что Hyper-V это фигня уже не очень получиться. Функционально они почти равны. Да, у Hyper-V legacy кода навалом и много разных нюансов, которые смотрятся немного странно, но тем не менее функционально два сопоставимых продукта, теперь. Также на эту поляну начинают выкатываться Nutanix и даже возможно Veeam, конечно они заходят с заднего крыльца с медленным KVM, но тем не менее.
Я также очень надеюсь, что со следующего года я забуду про бесконечные ошибки Flash в браузерах и смогу наконец-то не тратить время на разборки с тем как и куда Flash player ставиться.
Конечно, iSCSI LUN на VSAN это очень, очень странное решение, с припиской, что его нельзя использовать для связи кластеров между собой. Ха-ха, это как 2-Node cluster с direct connection с особым типом трафика – Witness. Оно и так работает! Причина втыкания поддержки этой конфигурации в том, что клиенты ее массово пользуют и чудесно поднимают Witness на этих же 2-ух нодах, просто выкидывая диски Witness VM на отдельные HDD/SSD. А этот тип трафика нужен для уменьшения объемов дебага. На Witness кроме VM-конфигураций ничего и не передается более. Но возникает вопрос – как MS может делать решения с кворумом на 2-х элементах и почему Vmware не может? Почему Witness нельзя сделать частью esxi, чтобы не поднимать лишнюю VM. Почему нормальный HA для vCenter появился только спустя 8 лет!?
И почему решения для Docker в Hyper-V уже есть на уровне кода гипервизора, а Vmware опять бегает с fling?
Где нормальная реализация vVOL??? 4 года прошло!!!
Вообщем, я понимаю, что маркетинг и много надо тестировать, но неужели нельзя было перебросить увольняемых разрабов с Workstation на флагманский продукт и довести его до-ума.
Почему-то у меня нет особой радости от выхода этой версии, наверное я просто так устаю ждать новые и нужные функции, что по выходу их – у меня апатия.
И еще есть вопрос – зачем убили Vsphere client???
Отдали бы его OpenSource, тем более что REST API покрывает теперь все основные функции. Неравнодушные люди бы его допилили бы его под текущие версии.
> как MS может делать решения с кворумом на 2-х элементах и почему Vmware не может?
Даже DAG нужен внешний ресурс в качестве арбитра.
Обновление подсистемы хранения:
http://cormachogan.com/2016/10/18/whats-new-vsphere-6-5-core-storage/
Новые фишки nested ESXi:
http://www.virtuallyghetto.com/2016/10/nested-esxi-enhancements-in-vsphere-6-5.html
Пардон за дубли, список ведь обновляется?
philzy,
“Конечно, iSCSI LUN на VSAN это очень, очень странное решение, с припиской, что его нельзя использовать для связи кластеров между собой.”
А зачем нужно связывать кластера между собой по iSCSI на VSAN’e? iSCSI нужно чтобы делать RDM для MS кластеров + подключить пару физ.хостов, который нечаянно остались в филиале.
“Ха-ха, это как 2-Node cluster с direct connection с особым типом трафика — Witness. Оно и так работает!”
Расскажите, пожалуйста, каким образом можно сделать маршрутизацию между тремя узлами при помощи кросс-кабеля в 6.2?
“клиенты ее массово пользуют и чудесно поднимают Witness на этих же 2-ух нодах, просто выкидывая диски Witness VM на отдельные HDD/SSD.”
Ага, а потом, когда падает хост с одной из копий и witness VM, то второй хост закрывает данные за запись и все падает.
“Почему Witness нельзя сделать частью esxi, чтобы не поднимать лишнюю VM.” потому что при наличии только двух объектов нельзя решить проблему сплит-брейна даже в теории. А если хоста три, то witness VM не нужна.
“Где нормальная реализация vVOL??? 4 года прошло!!!”
Во-первых, VVOL вышел вместе с 6.0, т.е. 1.5 года назад. А во-вторых, какие сейчас проблемы с реализацией VVOL? Оставалась только поддержка репликации на СХД, но в 6.5 её добавили.
Поддержка Docker есть в VIC, Photon Platform, Photon OS. И не на flings, а на GitHub, ибо это opensource и поэтому там они и останутся. Плюс есть еще Admiral и Harbor.
Николай!
Спасибо за комментарии. Но, попробую вам оппонировать с пруфами.
Какая маршрутизация? Нод всего 2, Witness VM крутиться на одной из них. VSAN в своем VLAN прибитом на портгруппу. L2 вульгарис. На каждой ноде имеется либо свое локальное хранилище на HDD/SSD или если совсем хорошо, то общее (Starwind, HP, любое с репликацией) для Witness VM. Не верите, что работает? Напишите мне на мыло – покажу как все устроено.
Как сделать, чтобы конфигурация из двух нод не умирала жестко и насовсем? Репликация (бэкап) Witness VM на другую ноду. Способ – любой (какой нравиться). Если есть общее хранилище, то HA переподнимет Witness VM на живой ноде при его изоляции.
Запись закрывается не сразу, поэтому время есть на подъем Witness VM.
Да, способ не идеальный, но 2-х узловая схема с мертвым Witness VM ведет себя также скверно, а именно прекращает доступ к дисковым группам через 1 час (можно этот параметр менять). А в случае выноса Witness VM на другой esxi такой вариант не исключен, так что если терять Witness VM, то не важно с одной нодой или без нее. В любом случае надо бороться за быстрое восстановление Witness VM.
Погодите, но почему надо делать систему с VM??? Нельзя поднять отдельный сервис на esxi, который будет обеспечивать кворум без отдельной VM? Как-то AD работает на 2-х узлах, если на то пошло. А VSAN это пространство имен на базe Ruby с RabitMQ для бинарной передачи данных мультикастом на все узлы (теперь хоть unicast можно настроить). Тут на форуме есть материалы (добрые люди добыли) о том как VSAN устроен. Я понимаю, что разработчикам было проще допилить 3-х нодовый конфиг, чем менять схему работы всей технологии. Поэтому и Flex в интерфейсе и VM с гипервизором для кворума. Но в этом вся Vmware – они даже свою ржавую вывеску не могут покрасить вовремя (в моей презентации есть фото).
vVol вышел в 2012 году! https://blogs.vmware.com/vsphere/2012/10/virtual-volumes-vvols-tech-preview-with-video.html
Пожалуйста, прежде чем спорить с тем, кто эксплуатирует vSAN с 1-ой бэта-версии изучите соответствующие материалы. Можно даже мою презентацию с VMUG – http://www.vm4.ru/2014/07/vmware.html. И первая реализация vVol “в натуре” это VSAN. Технологию, купленной компании Virsto, просто доработали серьезно, а чтобы стало совсем круто воткнули – VASA. И получили полный vVol 🙂
Проблемы с vVol в том, что производители хранилищ реализуют эту технологию плохо, медленно и не в полном объеме. Причина понятна – производители хранилищ не очень хотят делать продукцию только для Vmware, да еще и по сырой спецификации, которая совсем не отраслевой стандарт и даже не RFC.
Теперь про Docker от Vmware – не рассказывайте мне про это поделие от Vmware. Попробуйте его в реальном проекте. Ух, как вы будете разочарованы. Прикиньте, сколько слоев виртуализации используется. И еще проверьте что там с производительностью, надежностью и управляемостью.
Не удивительно, что его сначала выпустили как fling, потом на GitHub выложили, а не сразу закрыли патентами как новый продукт за 20k USD 🙂
Вообще меня очень радует развитие линейки Vmware продуктов, MS до них еще как до луны
@philzy
Насчет двух годовой конфигурации.
Нельзя размещать Witness там же где и данные. Это unsupported и против здравого смысла. Потому что, как вы верно написали, это приводит к тому, что если эта нода падает – вторая копия будет закрыта на запись. Вариант с тем, что есть задержка на закрытие – достаточно скверный, т.к. witness VM – ESXi и требуется, как минимум, время на его старт. Играть с тем, что раньше произойдет можно только в home lab, но ни как не продуктиве. С вариантом, восстановления из бекапа/реплики все еще хуже, т.к. это требует ручной реакции на подъем, что гарантированно дольше, чем блокирование объектов.
“Да, способ не идеальный, но 2-х узловая схема с мертвым Witness VM ведет себя также скверно, а именно прекращает доступ к дисковым группам через 1 час (можно этот параметр менять).”
Это не так. 2-х узловая схема живет сколько угодно (точнее до второго сбоя), после падения Witness VM. Про 1 час, это вы, видимо, перепутали с vsan.clomrepairdelay, который говорит о том, через сколько начинать ребилд данных. Но в двух годовой конфигурации, данный параметр не играет никакой роли, т.к. ребилдиться просто некуда при падении ноды или witness.
“Нельзя поднять отдельный сервис на esxi, который будет обеспечивать кворум без отдельной VM? Как-то AD работает на 2-х узлах, если на то пошло. ”
Потому что witness – это не сервис, а хранилище данных. Пусть и малого (4MB на компонент) их количества, но это приводит к тому, что нужен datastore на котором эти данные будут лежать. Следовательно нужны локальные диски или общее хранилище, которое будет эти данные держать. Самый просто вариант – развернуть ВМ, но если вам очень хочется, то можно вместо этого использовать полноценный железный ESXi, который будет этим заниматься «как сервис в ESXi», но ни одной здравой причины зачем так делать я пока не знаю. На самом деле, на много большая проблема, что на каждый 2-х кодовый кластер нужно держать по Witness ВМ, что становиться не удобным, если таких кластеров/площадок >20-50. AD – не хранилище данных. И он не борется с коллизиями. Т.е. если у вас произошел splitbrain и на каждом из инстансов произошли изменения одних и тех же учетом, то потом эти коллизии надо исправлять руками. Очевидно, что в случае с СХД это не приемлемо, поэтому любой системе (даже в теории), которая должна отрабатывать сценарий split brain нужен свидетель/орбитр или третий объект для решения этой задачи.
“А VSAN это пространство имен на базe Ruby с RabitMQ для бинарной передачи данных мультикастом на все узлы (теперь хоть unicast можно настроить).”
vSAN не передает данные мультикастом. Мультикаст нужен только для работы CMMDS (сервис высокого уровня отвечающий за работу компонентов кластер, мониторинга их сбоев и т.д.), DOM работает (и всегда работал) уникастом по RDT-протоколу.
От куда информация по Ruby и RabitMQ – мне не понятно. Если Ruby вылез из RVC, то он тут не причем. Так можно сказать проводя аналогии с vCenter, что и ESXi – это Java. RabbitMQ – шина обмена сообщений, работающая по HTTP/STOMP/MQTT проколам, что опять-таки не имеет отношения к работе с данными. Если вы хотите деталей о том, как работает vSAN внутри – есть вот этот неплохой документ для начального ознакомления с основными внутренними компонентами https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vcat/architecting-vmware-virtual-san-62-for-vmware-vcloud-air-network.pdf
snapshots/).
vSAN – это не Virsto, хотя многие так считают. Например, о vSAN было впервые сказано/показано на VMworld 2012 году (а значит разработка началась задолго до этого) – http://www.vmgu.ru/news/vmware-distributed-storage-vsan. Virsto была куплена только в 2013 (http://www.vmware.com/company/acquisitions/virsto.html) и появилась в vSAN только в его второй версии 6.0 в виде VirstoFS (VirstoFS is the first implementation of technology that was acquired when VMware bought a company called Virsto a number of years ago. http://cormachogan.com/2015/03/27/vsan-6-0-part-5-new-vsansparse-snapshots/
vSAN – это не VVOL, хотя они оба используют SPBM для управления и VASA провайдер в качестве прослойки. vSphere использовала VASA 1.0 для получения данных с СХД. vSAN использует VASA Provider 1.5. VVOL – VASA 2.0, которая позволяет говорить массиву, что ему нужно сделать:
The VASA level is identified on vCenter when you are adding the storage provider. You can tell what version you have based on the solution you’re using. VASA 1.0 delivered a one way communication with vSphere where it told vsphere the things that it could do statically. VASA 2.0 (VVol) is a two way communication where the array can fell vSphere what it can do but then vSphere can tell the array what it wants and what it needs to consume from a feature and capacity perspective. VASA 1.5 is a special version that is exclusive to VSAN. Other than that there is nothing else you need
Virtual Volumes does require VASA 2.0. The version 2.0 of the VASA protocol introduces a new set of APIs specifically for Virtual Volumes that are used to manage storage containers and Virtual Volumes. It also provides communication between the vCenter Server, ESXi hosts, and the storage arrays.
http://www.hoonkar.com/main/14-virtual-volumes-faq-includes-exclusive-faq-from-vmware-webinars
К тому же, помимо VASA, есть куча других ключевых компонентов VVOL – T10 OSD (который, кстати, очень даже стандарт) в виде secondary LUN ID, PE, bind/rebind операции на ESXi, команды на offload вместо VAAI. VASA – management layer, но ни разу ни data/control plane.
Поэтому, ни смотря на то, что VVOL и vSAN похожи с точки зрения подходов к управлению, перехода на объектную модель хранения и ряда инструментов, это далеко не одно и тоже.
Насчет вендора реализуют плохо и медленно – все актуальные СХД всех крупнейших вендоров поддерживают VVOL на большинстве массивов (HPE 3par,XP, весь NetApp, EMC Unity,VMAX, Hitachi, Dell Equalogic, весь Fujitsu, IBM, и т.д.). Кое-кто, конечно, со странностями, но это больше зависит от того, как натягивается VVOL на имеющуюся архитектуру СХД. Да и на текущий момент, насколько я знаю, все основные косяки (типа NetApp’овского внешнего statefull VASA провайдера) уже исправлены. Подскажите, какого актуального массива тут нет? http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vvols Ну кроме всякого low-end типа MSA и специализированных СХД типа XtremIO/DSSD?
“vVol вышел в 2012 году”
В 2012 он не вышел. Его в 2012 анонсировали. Иначе можно сказать, что и vSAN вышел в 2012 году. VVOL появился в 2015 в vSphere 6.0, а до этого не было возможности его использовать (даже в качестве techical preview).
А можно подробнее про исправленный VASA провайдер от NetApp?
Да там все достаточно просто. VVOL’y для работы требуется “база данных”, в которой записывается отношение объектов vvol и ВМ, т.е. какой машине какие объекты принадлежат. И крайне желательно не держать эти данные во внешнем VASA провайдере. Все (ну или большинство вендоров) так и сделали – у части из них VASA провайдер живет на контроллерах или сами данные лежат на СХД, которые всегда внешний VASA провайдер может прочитать. Это позволяет защититься от потери этих данных, т.к. если у вас упали (со всем состоянием) все контроллеры, то данных все равно уже нет, что на VVOL, что на VMFS/NFS. NetApp, по какой-то причине, решил эти данные положить во внешнюю ВМ, что может привести к тому, что если у вас эта машина теряется, то вы не можете сопоставить объекты и ВМ, поэтому, считайте, что вы потеряли все данные на vvol с СХД. Когда эта проблема всплыла, то NetApp выпустил VASA Provider 6.2, в которой они поместили VVOL metadata вместе с самими объектами на СХД (с возможностью считывания этих данных), а так же сделали бекап этих данных из VASA провайдера из коробки с возможностью втягивания конфигурации в новый/чистый VASA Provider.
Подробнее об этом можно почитать тут (http://cormachogan.com/2015/12/04/losing-vasa-vcenter-in-vvols), тут (https://kb.netapp.com/support/s/article/how-to-perform-a-vasa-provider-disaster-recovery?language=en_US) или тут (https://library.netapp.com/ecm/ecm_get_file/ECMLP2371577)
To Николай:
Хочу продолжить наш диспут.
Я думаю, что вы доверяете Cormac Hogan:
http://cormachogan.com/2015/09/11/a-closer-look-at-the-vsan-witness-appliance/
Replacing the witness host
If there is an issue with the witness host, then the witness components will go in an “absent” state. This will not impact the virtual machine as they continue to have a full copy of the data available from the data sites as well as greater than 50% of the components available. This means the virtual machine will stay accessible. If the witness host is unrecoverable, and a new witness host is deployed, the stretched cluster configuration can be recreated. Note however that the clomd timeout value still holds in this situation, so the components will be left absent for 60 minuted by default. After that timer has expired, the witness components will be rebuilt on the witness host and the “absent” witness components will return to an active state.
Из моего опыта, когда Witness накрывается, то все запущенное продолжает работать. Ровно через час начинают появляться inaccessible. Если из бэкапа поднять Witness, то буквально через некоторое время все возвращается в нормальный вид и продолжает работать.
Если есть второй общий сторадж, то HA вполне отрабатывает такую ситуацию.
Отвечаю сразу, что второй общий сторадж это Starwind. Для этого он годится.
Поэтому, я уверен, что для не mission critical решений это вполне подходит.
А, главное оно работает и вполне так неплохо.
AD работает по величине номера USN. Кластер MS работает в двух-узловой конфигурации с кворумным ДИСКОМ, а не с кворумной виртуалкой.
Никто вручную сплит-брейны на массивах не разбирает.
Хорошо, что вы поняли мой посыл итерполировав количество 2-Node VSAN до 20. Вот именно в таком случае моя схема и позволит не городить огород, а строить такие кластера. И моя схема не от хорошей жизни.
Хм, а у Starwind тоже нет кворума 🙂
Теперь про внутреннее устройство VSAN:
https://vmind.ru/forum/viewtopic.php?f=1&t=438 – тут гляньте.
Возможно, что TechTalk презентация будет и Вам интересна.
Спорить на эту тему не буду, т.к. без полной документации это бессмысленно.
Про Virsto и VSAN
1. VSAN Beta вышла в октябре 2013 (я был бета тестером) и это была Vsphere 5.5
и именно тогда партиция с метаданными называлась – VirstoFS, а не VSAN
Совпадение? Не думаю.
Возможно, что это была совместная разработка или процесс интеграции начался раньше.
2. VSAN это первая реализация vVOL вот о чем я говорил. Конечно для аппаратного массива vVOL имеет другой состав, но концепцию откатывали и презентовали именно на VSAN.
3. И где я не прав насчет того, что вендоры 2-3 года ждали?
Объявили vVOL в 2012, в 2013 его применили в VSAN, в 2014 (в бете 6.0) начали использовать – http://community.netapp.com/t5/Tech-OnTap-Articles/NetApp-Unlocks-the-Power-of-VMware-VVOLs/ta-p/86939
Насчет падения witness.
Я так и понял, где в тут написано, что через 60 минут должны отказать рабочие компоненты. Более того, прочитайте VMware vSAN 6.2 Stretched Cluster & 2 Node Guide, раздел Single witness host failure – Witness site (стр. 97) This should have no impact on the run state of the virtual machine, but the witness components residing on the witness host should show up as “Absent”. и “Rule for virtual machine object accessibility: at least one full copy of the data must be available, and more than 50% of the components that go to make up the object are available.” Таким образом, падения witness не влияет на доступность данных пока у нас сохраняется кворум (>50%, т.е. обе копии данных доступны). Если ваша система ведет себя иначе – проверяйте конфигурацию и настройки.
По starwind. Я совсем не большой специалист по этому продукту, но, насколько я понимаю, 2-х нодовая конфигурация используют heartbeat сеть или общий файл/диск-кворума ( при кластеризации на базе MS MSCS). Если происходит полная изоляция двух копий, то обе копии выключаются, как изолированные. Поэтому да, для отработки сценария split-brain требуется орбитр (некая третья сущность). И вообще, если уже развернут starwind, то зачем еще и vSAN создавать на площадке для двух хостов. Ровно как и наоборот.
В любом случае, появление в vSAN 6.5 2-node direct connect – не маркетинг. Это следствие появление технической возможности отделения witness сети от Data-сети в vSAN 6.5, что позволяет сделать нормальную маршрутизацию через WAN на witness ВМ с двух хостов, продолжая гонять данные на прямую по 10GbE direct-connect кабелем. До этого cross-connect не поддерживался и нормально (для продуктива) не работал, т.к. вариант с падением обоих копий и попытки успеть перезагрузить до блокировки – так себе решение и никому я это советовать не буду, а главное не понятно зачем. Лучше уж по 1GbE соединить хосты.
Я достаточно хорошо представляю себе внутреннее устройства vSAN. А в рамках этих презентаций и тех публичных материалов, что я отправлял выше, нет ни одного упоминания про «трафик гонится multicast’ом» и «RabbitMQ и Ruby». Более того, есть другие документы откуда можно узнать о внутренностях vSAN, поэтому если у вас есть какие-то вопросы – спрашивайте, я, по возможности, отправлю необходимые документы и дам комментарии.
Насчет beta и Virsto.
Публичная beta на vSAN была объявлена в августе 2013. Кстати, их там было несколько версий vSAN beta до GA и код vSAN достаточно сильно менялся за это время. Virsto приобретена только в феврале 2013. К тому же, вы серьезно думаете, что перед публичной бетой не было множества внутренних и закрытых бета тестирований? А разработка, в свою очередь, началась задолго до появления первой беты и тем более приобретения Virsto. Поэтому еще раз – vSAN – это не Virsto, хотя и использует сейчас некоторые её наработки. И если верить Cormac Hogan, то в виде Virtso FS в vSAN 6.0 (VirstoFS is the first implementation of technology that was acquired when VMware bought a company called Virsto a number of years ago из ссылки выше).
VSAN это первая реализация vVOL вот о чем я говорил. …концепцию откатывали и презентовали именно на VSAN
Почему вы знак равенства между vSAN и VVOL?
Только из-за управления через SPBM через VASA? Так VASA и SPBM (на тот момент Storage Profiles) появился сильно раньше еще в 5.0 в 2011 году, задолго до vSAN/VVOL. Более того, тут надо смотреть с другого конца – VASA/SPBM – интерфейс взаимодействия ESXi c системами хранения, поэтому, очевидно, и vSAN и VVOL, как наиболее актуальные технологии по работе с хранилищами, используют этот интерфейс для своей работы.
Концепцию чего обкатали на vSAN? Управления через политики хранения? Как я уже писал её начали обкатывать еще с 2011, когда появились первые VASA провайдеры + Storage Profiles.
Из-за того, что они оба используют объектную модель работы с данными? Но там даже понятие объектов сильно различается, ни говоря уже про протоколы обмена данными, используемые технологии/решения и реализацию.
Еще один забавный момент в том, что VVOL создавали Dell (iSCSI), HP (FC) и NetApp (NFS) совместно с VMware, которые описывали прокол с точки зрения системы хранения, а анонсировали vvol в 2012 одновременно с vSAN. Поэтому разработка этих двух решений велась разными компаниями/людьми параллельно друг от друга, хотя, очевидно, имеет общие посылы с точки зрения решаемой задачи. Так же VVOL и vSAN развиваются параллельно друг от друга, в VVOL 2.0 и vSAN 6.5 ничего нового общего не появилось, хотя для vSAN это уже 5-ая версия.
Последний момент, который мне не ясен – если вы говорите, что vSAN=Virsto и при этом что vSAN=VVOL, то получается, что VVOL=Virsto?
Напишите, пожалуйста, что заставляет вас думать, будто vSAN это VVOL, если я что-то пропустил.
Вендоры 2-3 года ждали. От момента анонса – да. От момента фиксации протокола/API и получения к нему доступа – не знаю. От момента GA – нет. Почти все решения получили поддержку за 1 год. В любом случае, какая разница для пользователей? Большинство массивов на рынке поддерживают VVOL уже относительно давно, примерно с того времени, как они смогли бы им воспользоваться в продуктиве.
P.S. И вообще, мне кажется нам надо переезжать в другое место для обсуждения этих вопросов. А то они уже имеют мало отношения к анонсу vSphere 6.5 🙂