На прошедшей осенью этого года главной конференции о виртуализации Explore 2022 компания VMware сделала немало интересных анонсов, главным из которых стал выпуск новых версий платформ vSphere 8 и vSAN 8. На американской и европейской конференциях много говорили о будущих новых продуктах и технологиях VMware, но несколько незамеченным остался переход VMware на новую схему релизов платформы vSphere. Сегодня мы поговорим об этом несколько подробнее.
Опытные администраторы виртуальных инфраструктур помнят, что еще много лет назад установка первых мажорных обновлений главных компонентов инфраструктуры vSphere - ESXi и vCenter - сразу после их выхода были довольно рискованным предприятием. Причина была проста - часто релизы мажорной версии или большого пакета обновлений (Update 1/2/3) сопровождались багами, которые могли как немного повлиять на функционирование платформы, так и серьезно нарушить работу инфраструктуры и даже привести к потере критичных данных (а это, как минимум, требует времени на их восстановление).
Один из первых таких случаев - это таймбомба, образовавшаяся в результате бага с лицензиями в VMware Virtual Infrastructure 3.5 (так тогда называлась платформа vSphere). В результате, лицензии пользователей оказались недействительными, что привело к невозможности запускать виртуальные машины и перемещать их средствами VMware VMotion (раньше так писалось слово vMotion). Произошло это в августе далекого 2008 года, тогда все не на шутку перепугались, а VMware пришлось экстренно выпускать критические патчи:
При этом, в моменте, в качестве решения проблемы, пользователям предлагалось отключить NTP и открутить время сервера ESX назад. Такой workaround тогда удивил многих администраторов.
Потом было много самых интересных ситуаций и проблем. Например, была проблема с самопроизвольной перезагрузкой виртуальных машин со включенной возможностью Virtual Machine Failure Monitoring (сейчас это часть VMware HA) в VMware ESX 3.5 Update 3 (тогда вместо ESXi был гипервизор ESX на базе полноценного линукса).
Если вы думаете, что со временем проблем в мажорных обновлениях стало меньше, то это верно лишь отчасти. Например, многие помнят, что после выхода VMware vSphere 5 Update 1 почему-топерестал работать автостарт виртуальных машин.
В принципе, такая ситуация понятна - гипервизор VMware начала делать еще в конце девяностых годов, и с тех пор появилась аппаратная виртуализации, технологии HA, DRS и vMotion, а также много-много всего. Очевидно, что настолько комплексный продукт очень тяжело держать в полностью контролируемом со всех сторон состоянии.
Это подтвердила и критическая ситуация с VMware vSphere 7 Update 3, которая произошла совсем недавно - в прошлом году, но ее решение растянулось на несколько месяцев. И только в начале этого года она была исправлена. Хронология событий была такова:
Проблем у обновления было много, и кое-какие из них были весьма критичными. Это были ситуации с выпадением в розовый экран смерти (PSOD), трудности при апгрейде с прошлых версий, неполадки в плане стабильности vSphere HA и другое:
В конце декабря 2021 года пользователи справедливо заметили, что проблема существует уже больше месяца, а многие до момента отзыва релиза Update 3 уже успели обновиться на него. При этом основная информация о возникшей ситуации с последним пакетом обновлений публиковалась в KB 86398.
Ну и наконец только в январе 2022 года VMware выпускает окончательное исправление в виде релиза VMware vSphere 7 Update 3c. Ситуация разрешилась, но многим пользователям пришлось понервничать, особенно тем, кто уже успел обновиться до Update 3 и не мог позволить себе откатывать инфраструктуру к прошлой версии гипервизора.
Приведенные примеры лишь иллюстрируют то, почему пользователи так скептически относились к обновлению VMware vSphere. Главным правилом апгрейдов было то, что после выхода мажорной версии платформы или очередного пакета обновлений, надо просто подождать выхода следующей версии и обновиться на ту, что стала уже предыдущей. Ведь даже небольшой баг для большой инфраструктуры может повлечь серьезные последствия и головную боль для администраторов.
Очевидно, что это тормозило процесс внедрения новых решений, поэтому в этом году компания VMware решила перейти на новую схему релизов vSphere. Итак, теперь у нас есть модель IA/GA (Initial Availability/General Availability), которая позволяет выровнять схему релизов с продуктами облачной линейки Cloud Services в рамках доступной пользователям подписки vSphere+. Но основная ее цель - это дать пользователям время на обнаружение серьезных проблем, появляющихся на стадии Initial Availability.
IA-релиз это, как и раньше, полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, полностью оттестирован, но доступен он теперь, как правило, на 4-6 недель раньше, чтобы собрать условия его применения от клиентов и партнеров VMware (и, конечно же, выявить критичные для инфраструктуры баги). В этот промежуток времени будут публиковаться все найденные важные проблемы, за чем можно следить в блогах VMware.
Теперь у пользователей достаточно времени, чтобы оценить - произошло ли за эти 1-2 месяца что-то критичное, и можно ли обновлять свои хост-серверы. Такая схема должна работать эффективнее, чем прежний подход, заключавшийся в ожидании очередного апдейта, так как до следующего пакета vSphere Update X проходит в среднем полгода.
Таким образом, общая схема выпусков IA/GA для VMware vSphere теперь выглядит так:
VMware, как и раньше, предлагает использовать один из трех вариантов развертывания гипервизора:
Базовый образ с сайта (base image)
Базовый образ с дополнительными утилитами (base image with vendor add-on)
Образ производителя, полученный по OEM-каналу
Самое интересное тут то, что VMware таким образом как бы признала, что да - при релизах бывают проблемы, и торопиться с обновлением не стоит. Что поделаешь - от всех вызовов не уберечься.
Еще один аспект, о котором стоит сказать - безопасность. В последний пару лет проблема Day-0 уязвимостей вышла на первый план. Мы уже видели, какие серьезные уязвимости были в процессорах Intel (вспомним Spectre), а также в различных вспомогательных сервисах VMware. Вспомним и проблему с решением VMware Carbon Black, в сервисах vCenter, а также шифрование VMDK-дисков программами вымогателями (Ransomware).
Если мы обратимся к уязвимостям Meltdown и Spectre, то тоже увидим, что VMware там наступала на те же грабли - сначала был выпущен патч для них, но его пришлось отозвать. Также на эти уязвимости реагируют и производители оборудования серверов.
Ну и, конечно же, вспомним о нашумевшей уязвимости Log4j, которая появилась в компоненте веб-сервера Apache Software Foundation log4j Java logging, а значит и во многих продуктах VMware. Эта уязвимость описана в CVE-2021-44228 - атакующий, который имел доступ к отсылке логов (к отправке самих сообщений или к настройке их параметров), мог исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена. Это уязвимость типа "zero-day", а значит исправление ее было в процессе, когда ее уже могли использовать в тысячах виртуальных окружений по всему миру.
Вот поэтому, учитывая накопившийся ворох проблем и сложностей, компания VMware решила перейти на схему релизов Initial Availability/General Availability. То есть, теперь у пользователей два выбора - early adopters получают продукт раньше, но рискуют словить баги, а большие среды уже обновляются через 1-2 месяца, если все в порядке, а не через 6, как это было раньше. Ну, по крайней мере, так предлагает делать VMware.
В этот раз релиз General Availability был выпущен (а точнее объявлен), когда число загрузок платформы VMware vSphere достигло более 18000, а "настаивался" он почти 2 месяца:
При этом в статус General Availability был отправлен тот же самый образ, что и для Initial Availability. Это говорит о том, что в этот раз ничего серьезного не произошло. Таким образом, схема IA/GA будет использоваться и в будущем.
RSS
