Корпоративные заказчики чаще всего используют целый ряд критичных информационных систем, обслуживающих большое количество пользователей. Чтобы избежать нарушений работоспособности такого решения, организации используют проверенные способы в виде аренды виртуальной инфраструктуры у облачного провайдера, предоставляющего услуги PaaS, или виртуального дата-центра, в основе которого лежит IaaS корпоративного уровня.

В последние годы на рынке облачных вычислений наблюдается бум использования технологии Docker, но корпоративные заказчики не спешат переходить на новинку. В этой статье мы рассмотрим причины такого поведения заказчиков.

Виды виртуализации

Контейнеры и виртуальные машины схожи по своей цели: изолировать приложение и его зависимости в самостоятельный блок, который можно запускать где угодно.

Более того: и контейнеры, и виртуальные машины избавляют от привязки к конкретному физическому оборудованию, что позволяет более эффективно использовать вычислительные ресурсы с точки зрения потребления энергии и экономической эффективности.

Основное различие между контейнерами и виртуальными машинами – в их архитектурном подходе.

Виртуальная машина – программная и/или аппаратная система, эмулирующая аппаратное обеспечение некоторой целевой и исполняющая программы для гостевой платформы на платформе-хозяине (хосте) или виртуализирующая некоторую платформу и создающая на ней среды, изолирующие друг от друга программы и даже операционные системы. Виртуальные машины запускают на физических машинах, используя гипервизор.

Гипервизор представляет собой часть программного или аппаратного обеспечения, позволяющую одновременное, параллельное выполнение нескольких операционных систем на одном и том же физическом компьютере – хосте. Хост предоставляет виртуальным машинам вычислительные ресурсы, легко распределяемые между ними. Так что если одна виртуальная машина выполняет запуск более ресурсоемких приложений, вы можете выделить ей больше вычислительных возможностей, чем другим машинам, работающим на том же хосте.

Виртуальную машину, запускаемую на том же хосте, часто называют гостевой машиной. Гостевая машина содержит приложение и все, что нужно для его запуска (например, системные исполняемые файлы и библиотеки). Она также несет в себе весь аппаратный стек, включая виртуальные сетевые адаптеры, файловое хранилище и центральный процессор, и полноценную гостевую операционную систему. Виртуальная машина ведет себя как отдельный блок со своими собственными выделенными ресурсами. Если смотреть снаружи, мы знаем, что это виртуальная машина, использующая общие ресурсы, предоставленные хостом.

Контейнеры

В отличие от виртуальной машины, обеспечивающей аппаратную виртуализацию, контейнер обеспечивает виртуализацию на уровне операционной системы с помощью абстрагирования пользовательского пространства...Читать статью далее->>

Недавно мы писали о выпуске обновленной платформы для виртуализации настольных ПК предприятия VMware Horizon 7.7. Частью этого релиза стал апдейт продукта для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам или хостам RDSH - VMware App Volumes 2.15.

Напомним, что о прошлом релизе App Volumes 2.14 мы писали вот тут в рамках анонса позапрошлой версии платформы VMware Horizon 7.5.

Давайте посмотрим, что нового появилось в App Volumes 2.15:

1. Функция Profile-Only Writable Volumes.

Ранее администратор мог создавать один из двух типов шаблонов для writable volume:

• Только для пользовательских приложений
• Для пользовательских приложений и данных профиля

Теперь же появилась третья опция - возможность создать шаблон только для сохранения данных профиля ("Profile Only"). Это позволяет, например, сохранять файлы Outlook OST, которые кэшируются и не требуют их пересоздания при каждом логине пользователя. Это же относится и к остальным приложениям пакета Office 365 - Outlook, Word, Excel, PowerPoint, Skype for Business и OneDrive for Business - при логине пользователя не нужно заново тянуть их данные с серверов датацентра компании.

2. Поддержка облачных приложений для Writable Volumes.

Теперь загруженный контент приложений OneDrive for Business и Box Drive (версии старше 2.1.105) сохраняется между логинами пользователя. Это позволяет создавать неперсистентные десктопы, но сохранять кэш скачанного контента пользователя, чтобы после его логина данные сервисов хранения сразу оказывались ему доступны.

3. Возможность использовать переменные окружения Writable Volume Exclusions.

Администратор может добавить исключения, например, для папки C:\Users\%Username%\Downloads, чтобы скачанные любым пользователем файлы не сохранялись между его входами в десктоп:

exclude_uwv_file=\users\%USERNAME%\downloads

Также, помимо %Username%, можно использовать переменную окружения %UserProfile%, например, чтобы не загружать временные файлы прошлых сессий пользователей:

exclude_uwv_file=%USERPROFILE%\desktop\temp

4. Поддержка решения Horizon 7 on VMware Cloud on AWS.

Теперь App Volumes поддерживают облачную инфраструктуру десктопов Horizon 7 on VMware Cloud on AWS (SDDC версии 1.5). Механизм App Volumes версии 2.15 может быть использован совместно с облачной платформой Horizon, чтобы развертывать приложения при включении виртуальных машин в облачной инфраструктуре Amazon-VMware.

Более подробно о новых возможностях VMware App Volumes 2.15 смотрите в Release Notes, скачать компоненты App Volumes как часть решения VMware Horizon 7.7 можно по этой ссылке.

Недавно компания VMware опубликовала очередной набор практических упражнений Feature Walkthroughs по апгрейду VMware vCenter 6.7 с прошлых версий управляющего сервера. Они рассказывают об обновлении с помощью интерфейса командной строки vCenter Server Appliance (vCSA) CLI, а также средствами графического интерфейса мастера установки.

Напомним, что Feature Walkthroughs позволяют администратору пройти в интерфейсе тот или иной рабочий процесс виртуальной инфраструктуры без необходимости развертывания у себя тестовой среды.

1. Апгрейд vCenter через через vCSA CLI.

В рамках демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 администратор может узнать, каким образом выглядит консольное обновление Embedded vCenter на последнюю версию. Вам покажут как создать и редактировать настроечный JSON-файл, а также правильно использовать параметры консольной утилиты vcsa-deploy.exe.

Кстати, обратите внимание, что обновление vSphere 6.5 Update 2d на vSphere 6.7 все еще не поддерживается.

2. Апгрейд через графический инсталлятор VMware vCSA.

С помощью демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 using the GUI вы можете пройти по шагам процесса обновления vCenter на последнюю версию в рамках vCSA Installer и его рабочего процесса Upgrade:

Также советуем почитать наши посты о миграции с vCenter for Windows на виртуальный модуль vCSA:

• Миграция сервера VMware vCenter для Windows на виртуальный модуль vCenter Server Appliance 6.7 Update 1
• Функции VMware vCenter Server Appliance для миграции сервера vCenter под Windows

Мы много пишем о публичном облаке VMware vCloud on AWS, появившемся в результате совместных усилий Amazon и VMware. Например, недавно рассказывали, что vCloud on AWS будет не только облачным сервисом, но и появится возможность разместить его на собственной площадке (on-premises).

Один из главных вопросов для пользователей (помимо географии и функциональности) - это ценообразование.

Основная страница прайсинга на VMware vCloud on AWS находится вот тут:

https://cloud.vmware.com/vmc-aws/pricing

Здесь мы можем увидеть вот такие цены за хост ESXi с сервисами vSphere/vSAN/NSX в час (на самом деле, это от $7 в час, а цены ниже указаны для новых клиентов в течение 3 первых месяцев):

Если вы подпишете контракт на год, скидка будет 30%, если на 3 года - 50%.

На этой же странице ниже расположен калькулятор стоимости аренды IaaS-инфраструктуры vCloud on AWS, где можно посчитать примерную цену аренды хостов SDDC (2 CPU, 36 ядер, 512 ГБ оперативной памяти, флэш-хранилище NVMe: 3.6 ТБ кэш, плюс 10.7 ТБ сырой емкости для ВМ).

Для четырех хостов ESXi на месяц у меня получилась стоимость 30 тысяч долларов, что как-то слишком дорого:

На данный момент также существует 2 онлайн-сервиса, которые позволяют оценить затраты на IaaS-инфраструктуру VMConAWS с точки зрения стоимости владения за 3 года:

1. Базовый калькулятор стоимости владения: VMware Cloud on AWS and Microsoft Azure: A Hybrid Cloud TCO Comparison.

https://cloud.vmware.com/vmc-aws-tco-pricing/

В левой панели вводите число виртуальных машин (как в облаке, так и на собственной площадке под управлением VMC) и длительность контракта (год, 3 года или по мере использования) и получаете оценку затрат за 3 года в виде совокупной стоимости владения TCO (total cost of ownership), а также стоимость машиночаса. Это все подается еще и в сравнении со стоимостью владения ресурсами публичного облака Microsoft Azure (насчет точности конкурентных расчетов есть определенные сомнения):

2. Расширенный калькулятор стоимости владения: VMware Cloud on AWS Sizer and TCO.

https://vmcsizer.vmware.com/

В этом средстве расчета вы уже задаете профили рабочей нагрузки с их назначением, указываете число виртуальных машин с их параметрами (диск/профиль операций ввода-вывода, память, процессор) и получаете расчет совокупной стоимости владения с детальной разбивкой по статьям затрат, а также детальным описанием планируемой IaaS-инфраструктуры:

Согласно калькулятору, 100 виртуальных машин с дефолтными настройками профиля нагрузки за 3 года обойдутся в 400 тысяч долларов.

Кстати, для тех, кому интересно - вот детальный FAQ про сервис VMware vCloud on AWS от Amazon на русском языке: https://aws.amazon.com/ru/vmware/faqs/. Ну а вот подобный FAQ со стороны VMware, но уже на английском: https://cloud.vmware.com/vmc-aws/faq.

Кстати, пользователи продукта VMware vRealize Business for Cloud могут в нем провести обследование своей инфраструктуры для оценки затрат на содержание такой же облачной среды, но на стороне vCloud on AWS:

Недавно мы писали о политиках хранилищ Storage Policy Based Management (SPBM) на базе тэгов, которые помогают использовать возможности платформы VMware vSphere для назначения виртуальным машинам хранилищ на томах VMFS/NFS с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Сегодня мы поговорим о политиках SPBM для виртуальных томов VVols на хранилищах, которые предоставляют различные возможности через интерфейс VASA (vSphere APIs for Storage Awareness). Механизм VASA реализуется производителем дисковой системы (storage provider) на программно-аппаратном уровне, при этом дисковый массив полностью отвечает за использование его возможностей, а со стороны vSphere возможно только управление ими средствами механизма SPBM.

Через интерфейс VASA Provider устройство хранения сообщает платформе vSphere, какие сервисы оно предоставляет, а через административный том на хранилище Protocol Endpoint (PE) происходит процессинг операций ESXi с массивом:

К таким возможностям в общем случае относятся:

• Шифрование
• Дедупликация данных на массиве
• Репликация данных внутри массива и на другие массивы
• Функции уровня обслуживания QoS (ограничения по IOPS и Latency)
• Выбор яруса хранения / типа дисков (регулирование уровня производительности)

Также возможна реализация в массиве и других сервисов, таких как защита с помощью снапшотов, использование различных размеров блока для разных приложений и т.п.

Самое приятное в использовании механизма SPBM для хранилищ на основе VVols в том, что вам не требуется заботиться о томах LUN, дисковых группах и настройке их параметров - массив сам распорядится размещением данных по ярусам (Tiers) и датасторам, а также обеспечением уровня их производительности (Service levels).

Например, вот так просто выглядят правила (Rules) для первичного размещения виртуальных машин на массиве EMC Unity при выборе уровня обслуживания и производительности для новой политики SPBM:

В массивах может быть также реализован QoS в зависимости от критичности приложения (Mission Critical приложения всегда первыми получат ресурсы ввода-вывода):

Некоторые хранилища, например, HPE Nimble, могут предоставлять сразу большое число сервисов, для каждого из которых можно настроить свои правила:

Хранилище может предоставлять не только правила размещения виртуальных машин и обеспечения их функционирования, но и сервисы репликации, как например у Pure Storage (они позволяют, в том числе, настроить репликацию на уровне отдельных VMDK дисков машин):

Также создание политик SPBM для томов VVols можно посмотреть на видео ниже:

А вот так применяются политики SPBM, включая сервисы репликации:

Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.

Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.

В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.

Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":

Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":

В процессе обновления вам предложат выбрать версию VDS, если кликнуть на иконку <i>, то можно узнать какие фичи предоставляют соответствующие версии:

Обратите внимание, что соответствие версий VDS версиям vSphere следующее:

• vSphere 6.0 = VDS 6.0
• vSphere 6.5 = VDS 6.5
• vSphere 6.7 = VDS 6.6 (да, вот так странно)

После обновления убедитесь, что виртуальный коммутатор имеет ту версию, которую вы выбрали:

И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.

На сайте проекта VMware Labs появилась очередная полезность, на этот раз для пользователей инфраструктуры Workspace ONE. С помощью утилиты Android Device Pre-Verification Suite пользователи и партнеры VMware могут проверить Android-устройство (телефон/планшет/rugged device) на предмет предварительного соответствия условиям device verification program.

Проведение такой предварительной проверки уменьшает время включения устройств в инфраструктуру Workspace One Intelligent Hub (device verification program).

Для работы теста на телефоне должен быть установлен агент Workspace One Intelligent Hub (ранее он назывался Android Agent), который можно поставить из Google Play или с компьютера.

Более подробно об утилите Android Device Pre-Verification Suite можно почитать в документации. Скачать ее можно по этой ссылке.

Спустя всего 3 с небольшим месяца с момента анонса на конференции VMworld 2018 платформы для создания инфраструктуры виртуальных десктопов VMware Horizon 7.6, компания VMware выпустила обновление этого продукта - Horizon 7.7, включая обновленные клиенты Horizon Client 4.10.

Давайте посмотрим, что нового появилось в различных компонентах этого решения:

Улучшения совместимости и поддержка новых ОС

• Поддержка Windows Server 2019 для серверов виртуальных десктопов и RDSH.
• Поддержка последних версий VMware vSphere 6.7 U1 и VMware vSAN 6.7 Update 1.
• Поддержка облачного решения Horizon 7 on VMware Cloud on AWS (SDDC версии 1.5), включая все его новые возможности.
• Теперь апгрейды можно запускать через виртуальный модуль Horizon 7 Cloud Connector. Этот appliance используется для интеграции служб Horizon Cloud Service с компонентами Horizon 7 на площадках заказчиков и VMware Cloud on AWS.
• Пакет VMware Virtualization Pack for Skype for Business теперь может быть использован в окружении IPv6.
• Клиенты Horizon Clients теперь включают поддержку последних операционных систем, таких как macOS 10.14 (Mojave) и Android 9.1.

Улучшения консоли Management Console

Новая Horizon Console (на базе HTML5) получила несколько улучшений:

• Теперь можно добавлять пулы Manual и View Composer linked-clone, а также добавлять, отключать, изменять и удалять персистентные диски для связанных клонов.
• На вкладке Machines можно быстро понять, когда кто-либо, кроме назначенного пользователя, заходил в виртуальную машину. Теперь есть 2 колонки: Connected User и Assigned User (фича также доступна в Horizon Administrator).

• Старый Horizon Administrator в дэшборде System Health отображает детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:

• Имя узла Connection Server pod теперь есть в верхней панели, рядом с заголовком:

• Улучшение Help Desk Tool - администраторы теперь могут завершить процесс приложения для выбранного пользователя. База данных событий записывает это действие, включая такие детали, как дата и время, имя десктопа и название приложения, название пула и имя администратора.

Улучшения масштабируемости

• Можно использовать один экземпляр vCenter Server для нескольких POD в архитектуре CPA (Cloud Pod Architecture).
• Максимальное число серверов одной фермы RDSH было увеличено с 200 до 500.
• Была введена поддержка vMotion для пулов linked-clone и automated, которые содержат также и полные виртуальные машины.
• Поддержка vMotion была также добавлена для полных клонов с поддержкой vGPU, мгновенных клонов и связанных клонов.

Улучшения безопасности и надежности

• Новая возможность аудита буфера обмена позволяет агентам Horizon Agent записывать информацию об активностях операций copy и paste между клиентом и агентом в журнал событий на машине агента.
• Можно добавить устройство Virtual Trusted Platform Module (vTPM) к пулу десктопов instant-clone и удалить vTPM уже после операции по созданию образа.
• Протокол TLS 1.0 теперь отключен по умолчанию на всех клиентах.

Улучшения User Experience

• Улучшения протокола Blast Extreme:
  • Теперь можно использовать протокол Blast Extreme для доступа к физическим компьютерам и рабочим станциям.
  • Для Windows-клиентов протокол кодирования видео Blast Extreme HEVC (H.265) позволяет ужимать почти в два раза эффективнее чем раньше (при том же качестве), либо улучшать качество на той же самой полосе, как и H.264. Также добавлена поддержка режима 8K. Это требует окружения NVIDIA GRID с аппаратными кодировщиками NVIDIA и клиентов, железо которых поддерживает декодирование HEVC.
    
• Улучшения Windows-клиентов:
  • Если включена возможность client-drive redirection, пользователи могут перетаскивать файлы и папки между клиентской системой и удаленными десктопами или опубликованными приложениями. Например, можно перетащить несколько графических файлов в опубликованное приложение (например, закинуть аттач в почтовый клиент).
  • Новая возможность VMware Virtual Print позволяет пользователю печатать на любом Windows-компьютере (она делает то же самое, что и ThinPrint ранее). Но, помимо этого, VMware Virtual Print поддерживает перенаправление принтеров клиента, а также location-based printing. Настройки сохраняются на уровне пользователей.
• Улучшение опубликованных приложений и десктопов RDSH:
  • Режим multi-session mode, который позволяет администратору задать правило - можно ли пользователю открывать несколько сессий к одному приложению с различных устройств. Требует Horizon Client 4.10.
  • На Windows-клиентах пользователю можно назначить приложение RDSH для отображения на одном мониторе или на наборе из нескольких экранов.
  • Новая возможность hybrid logon может быть использована с функцией доступа для неавторизованных пользователей. Она позволяет неаутентифицированным пользователям, но с доступом к домену, получить доступ к сетевым ресурсам (файловые шары, принтеры), без ввода данных учетной записи домена. Требует Horizon Client 4.10.

Улучшения работы публичного облака VMware Cloud on AWS (SDDC версии 1.5)

• Минимально требуемый размер кластера vSphere был уменьшен до 3 узлов. Также поддерживаются "растянутые" кластеры (stretched clusters).
• Поддержка технологий VMware NSX-T network virtualization и VMware vSAN datastore encryption.
• Поддержка технологий Horizon 7 издания Enterprise Edition: VMware User Environment Manager, VMware App Volumes и техники VMware Instant Clone.

Улучшения и новые возможности VMware Horizon 7 for Linux

• Десктопы Linux теперь поддерживаются в инфраструктуре Horizon 7 on VMware Cloud on AWS.
• Режим Single sign-on (SSO) теперь поддерживается для десктопов SLED/SLES 12.x.
• Аудиовход теперь поддерживается для десктопов SLED/SLES.
• Плавающий пул десктопов Instant clone теперь доступен при использовании SLED/SLES .
• Функция session collaboration доступна при использовании Linux-десктопа. Теперь можно приглашать других пользователей присоединиться к удаленной сессии.
• Десктопы Instant clone на базе Linux теперь позволяют офлайновое присоединение к домену Active Directory через Samba.

Более подробная информация о VMware Horizon 7.7 приведена по этой ссылке. Также здесь можно почитать документацию о VMware Horizon Clients, а вот тут написано про новые возможности Unified Access Gateway 3.4.

Компоненты VMware Horizon 7.7 доступны для загрузки уже сейчас по этой ссылке.

Сейчас трудно представить себе сферу деятельности, в которой доступность IT-инфраструктуры стояла бы на последнем месте. С ростом критических для бизнеса сервисов данный вопрос встает все острее, и сегодня мы хотим рассмотреть варианты резервирования инфраструктуры на удаленной DR-площадке IaaS-провайдера и кейсы, в контексте которых они подходят в качестве стратегии business continuity.

Давайте для начала определимся с базовыми понятиями, которыми оперируют IT-специалисты при разработке плана повышения доступности и без которых невозможно принять взвешенное и объективное решение по его реализации. Подготовка подобного плана всегда включает в себя обязательный диалог между IT и бизнесом, от чьих интересов и особенностей мы всегда должны отталкиваться. И первый вопрос в данном диалоге должен звучать так: Какое время простоя сервисов компании в случае отказа информационных систем не окажет ощутимого воздействие на бизнес? Можно сразу ответить: никакое, ведь любая нештатная ситуация, приводящая к прекращению предоставления услуг, неприятна. Но следует понимать, что организация нулевого даунтайма может обойтись бизнесу дороже, чем потенциальные потери, которые может понести компания, выстроив план так, что время восстановления после сбоя займет, к примеру, 4 часа.

Данное понятие называется RTO (recovery time objective) и его суть сводится к определению времени, за которое работоспособность того или иного сервиса должна быть восстановлена. Мы говорим про сервисы, а не про инфраструктуру в целом, потому что у каждого сервиса есть свой cost и RTO должен рассчитываться применительно именно к сервисам, а не к инфраструктуре в целом. Ведь, к примеру, без сервера печати можно прожить чуть дольше, чем без CRM или сайта компании, если он располагается на вашей площадке.

Следующим в данном диалоге будет вопрос о критичности потери наработанной информации. К примеру, в компании резервное копирование данных происходит ежедневно в 6:00 утра. Люди приходят на работу, вносят изменения в базы, получают новую почту, модернизируют приложение… А вечером происходит критический сбой всех наших систем, и все, что у нас есть, – это резервные копии на момент начала рабочего дня. Если изменений немного и они не критичны, то ничего страшного – восстанавливаемся и работаем дальше. Но если это не так и откат до существующей точки восстановления по тем или иным причинам невозможен без существенных потерь для бизнеса?

Подобный вопрос описывается параметром RPO (recovery point objective) – то есть точка состояния критичных данных, к которой допустимо вернуться в случае сбоя. К примеру, для сервера баз данных мы определяем этот параметр равный 1 часу. Это значит, что актуальная резервная копия данных...Читать статью далее->>

Сценарии отказов компонентов дисковой подсистемы кластера VMware vSAN - APD и PDL.

Как знают многие пользователи кластеров отказоустойчивых хранилищ VMware vSAN, это решение очень хорошо обрабатывает различные сценарии отказа дисковой подсистемы кластера, чтобы обеспечить бесперебойное функционирование виртуальных машин. Недавно мы писали о том, как vSAN обеспечивает переход в режим обслуживания хостов, а сегодня поговорим о сценариях отказов дисковых компонентов.

Как известно, дублирование дисковых компонентов и объектов в кластере vSAN зависит от политики Failures to tolerate (FTT) и уровня RAID, заданного для политики, которой подчиняется виртуальная машина:

Если для машин хоста задана политика с FTT=1 и RAID-1, то в общем случае, при отказе хоста ESXi, через 60 минут начинается ресинхронизация его дисковых объектов на других хостах, чтобы обеспечить выполнение политики FTT.

В случае сбоя какого-либо из компонентов дисковой подсистемы хранения кластера (от диска до хоста) механизм vSAN делит характер сбоя на 2 состояния: APD (All Paths Down) и PDL (Physical Device Loss). Об этих состояниях мы подробно писали вот тут.

• APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. Это состояние считается временным и также называется "absent". Иными словами, мы не знаем, что случилось с устройством, может быть оно будет доступно в будущем. В этом случае vSAN не начинает сразу восстановление дисковых компонентов и объектов, а ждет 60 минут, чтобы не тратить напрасно ресурсы в случае, если устройство снова станет доступно. Время до начала восстановления можно регулировать настройкой Object Repair Timer, о которой мы детально писали вот тут. 
• PDL (Physical Device Loss) - состояние, когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет. Этот статус считается постоянным и также называется "degraded". В этом случае кластер vSAN сразу начинает восстановление дисковых объектов, несмотря на значение Object Repair Timer. Примером таких состояний является выход из строя дискового массива или его части, поломка HBA/RAID-контроллера и т.п.

Давайте посмотрим, как именно реагирует кластер vSAN на различные варианты отказов и поломок дисковой подсистемы в кластере:

А вот графическая иллюстрация того, что происходит через 60 минут в кластере при отказе хоста ESXi. Обратите внимание, что если хост появится снова онлайн после сбоя и начала ресинхронизации (>60 минут) - его дисковые компоненты будут признаны "stale" и удалены механизмом vSAN, чтобы использовать его дисковое пространство в полном объеме.

Недавно компания Gartner выпустила Magic Quadrant for Hyperconverged Infrastructure (HCI) за 2018 год, посвященный средствам создания гиперконвергентной инфраструктуры. Это такая среда, которая позволяет объединить вычислительные ресурсы, системы хранения и сети с помощью технологий виртуализации и собрать все компоненты в единую интегрированную сущность, которая управляется из одной точки.

Напомним, что об этом квадранте мы уже писали в начале года, и с тех пор кое-что изменилось:

Вот как было в январе этого года:

Главным лидером рейтинга, как и прежде, сейчас признана компания Nutainx - производитель продуктов для создания гиперконвергентной среды. Сейчас Nutanix поставляет как чисто программные решения (в виде виртуальных модулей), так и программно-аппаратные комплексы (партнерские решения Lenovo, Dell EMC, Fujitsu и IBM). Помимо этого, Nutanix в рамках раннего доступа запустила и облачный сервис для своих HCI-решений.

Несмотря на то, что VMware - это производитель только программных решений, она попала в сегмент лидеров вполне заслуженно. У VMware в последние годы было выпущено очень много того, что относится к HCI - например, сейчас компания поддерживает более 500 моделей серверов в рамках программы ReadyNode для построения кластеров vSAN.

Также VMware поддерживает инициативу VMware Cloud Foundation (VCF), о которой мы много писали в последнее время. Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить.

Ну и, конечно же, в последнее время VMware делает очень много усилий по продвижению гибридной среды VMware Cloud on AWS, которая будет доступна не только из облака, но и в частной инфраструктуре предприятий (Amazon Outposts).

Родительская компания VMware - Dell EMC - в этом квадранте занимает высокое место благодаря решениям VxRail и VxRack, в состав которых, кстати, входит продукт для создания кластеров отказоустойчивых хранилищ vSAN.

Обратите внимание, что существенный прогресс наблюдается у Cisco - из сегмента челенджеров она переместилась в лидеры. Прежде всего, это случилось благодаря доработке платформы Cisco HyperFlex, котора интегрирует в себе архитектуру Cisco Unified Computing System (UCS), сочетающую в себе продукты Network Fabric, управляющую облачную консоль Intersight, сторонний гипервизор (например, ESXi), а также платформу для управления хранилищами и данными HX Data Platform (разработанную компанией Springpath, которую Cisco купила в сентябре 2017 года).

О магических квадрантах Gartner

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Политики SPBM разделяются на 3 основных области:

• Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
• Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
• Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.

В этой статье мы рассмотрим использование таких объектов, как тэги (Tags) и категории (Categories). Они могут оказаться полезными, когда вы хотите высокоуровнево определить параметры размещения и конфигурации виртуальных машин и их дисков на хранилищах, хостах, кластерах или в других объектах виртуальной инфраструктуры.

Поддержка правил на базе тэгов определяется при создании политики:

С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:

Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.

Так, например, может выглядеть конфигурация тэгов и категорий в вашей инфраструктуре:

В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.

Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).

После создания тэга его нужно добавить к соответствующим датасторам и создать политику, которая использует соответствующие тэги. Это позволит определить размещение виртуальных машин при их создании, миграции или клонированию.

Весь этот процесс показан на видео ниже:

Еще одно преимущество такой механики заключается в том, что вы можете изменить хранилище, которое располагается под политикой, без изменения самой политики. То есть вы добавляете тэг какому-нибудь хранилищу, и оно автоматически попадает в политику с этим тэгом для размещения ВМ. Политику также можно ассоциировать с кластерами хранилищ (datastore clusters), что добавляет еще гибкости этому механизму.

Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.

Вот как это работает при создании политики:

С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:

Get-VM -Tag Windows

Name PowerState Num CPUs MemoryGB

---- ------- -------- --------

Windows-VMFS-VM PoweredOff 1 4.000

Win10-3 PoweredOn 2 4.000

jm-ws2016 PoweredOn 2 4.000

Win10-2 PoweredOn 2 4.000

И для хранилища:

Get-Datastore -Tag California

Name FreeSpaceGB CapacityGB

---- --------- ----------

N-VVol-Cali 2,048.000 2,048.000

При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.

Несколько полезных ресурсов про политики SPBM:

• Storage Policy Based Management
• Populating the VM Storage Policies Interface
• Assign Tags to Datastores
• Storage DRS Integration with Storage Profiles

Нил Андерсон (Neil Anderson) прислал нам ссылку на интересный список "List of VSA Virtual Storage Appliances and SAN Storage Simulators", в котором представлены основные виртуальные модули (Virtual Storage Appliances, VSA) и симуляторы для создания программных общих SAN-хранилищ.

Вот список VSA-модулей и SAN-симуляторов, представленный по ссылке:

• FreeNAS VSA
• StarWind Virtual SAN VSA
• Open Media Vault VSA
• OpenFiler Unified Storage VSA
• NetApp ONTAP Simulator
• NetApp ONTAP Select VSA
• HPE 3PAR StoreServ Simulator
• HPE StoreVirtual VSA
• Dell EMC UnityVSA
• Dell EMC ViPR Software Defined Storage
• Dell EMC Isilon Simulator
• Dell EMC Data Domain Virtual Edition – Community Edition
• Oracle ZFS Storage Simulator
• IBM Spectrum Scale Virtual Machine
• HDS HCS Simulator
• Nimble Virtual Array VSA
• Nutanix Community Edition
• Synology DSM XPEnology Simulator
• NexentaStor Community Edition VSA
• Datacore Hyperconverged Virtual SAN
• StorMagic SvSAN Trial

Бонусом идет список программных и аппаратных продуктов, для которых можно посмотреть на их управляющий интерфейс в рамках демо:

• IBM StorWize V-Series Demo
• Dell EMC Unity All Flash Simulator Demo
• Dell EMC VNXe Demo
• Synology DSM NAS Demo
• QNAP QTS NAS Demo
• Thecus NAS Demo
• NetGear ReadyNAS NAS Demo

К каждому продукту автор приложил описание системных требований, а также ссылки на туториалы (в том числе видео) и документацию. Довольно полезная штука, скажу я вам!

Многие из вас используют фреймворк VMware PowerCLI для автоматизации операций в виртуальной инфраструктуре (см. статьи нашего автора Романа Гельмана). Между тем, не все знают, что PowerCLI - это точно такой же поддерживаемый продукт VMware, как и все остальные, с точки зрения обращений в техническую поддержку. То есть, если вы обнаружили некорректное поведение скрипта PowerCLI и не можете выяснить причину - то имеет смысл открыть Support Ticket.

Но чтобы инженеры VMware получили всю необходимую диагностическую информацию, часто оказывается недостаточно сгенерировать support-бандлы для хоста ESXi или сервера vCenter. Иногда нужно залезть глубже, чтобы получить информацию об API-вызовах, например, с помощью инструментов Fiddler или Wireshare.

Но можно сделать все гораздо проще - есть командлет Get-ErrorReport, который соберет для вас всю необходимую диагностическую информацию об ошибке и добавит ее в zip-пакет для отправки как вложения support-тикета. Давайте вызовем ошибку, к примеру, известную проблему PowerCLI, которая возникает при попытке переместить виртуальную машину с помощью Move-VM в виртуальный сервис vApp:

$appsvr = Get-VM -Name appsvr02

$vapp = Get-VApp -Name DemovApp

Move-VM -VM $appsvr -Destination $vapp

Ошибка будет такой:

Move-VM : 11/14/2018 1:12:31 PM Move-VM         A specified parameter was not correct:

PlacementSpec.relocateSpec.pool

Чтобы получить support бандл для этой ошибки, нужно использовать командлет, у которого есть следующие параметры:

• Destination - директория назначения результирующего бандла.
• IncludeServerLogs - нужно ли вытягивать логи с сервера, к которому мы подключены.
• ProblemDescription - описание проблемы для технической поддержки.
• ProblemScript - участок скрипта, который вызывает ошибку.

Таким образом, давайте попробуем вызвать командлет Get-ErrorReport:

$errorCode = {

$appsvr = Get-VM -Name appsvr02

$vapp = Get-VApp -Name DemovApp

Move-VM -VM $appsvr -Destination $vapp

}

Get-ErrorReport -ProblemScript $errorCode -Destination .\Documents\ -ProblemDescription "Using Move-VM to place a VM into a vApp"

Результатом работы сценария будет саппорт-бандл PowerCLI, лежащий в заданной папке:

Если заглянуть внутрь этого zip-пакета, то можно увидеть там следующие файлы:

• PowerCLI-Main-Log.svclog
• Powershell-Debug-Stream.txt
• Powershell-Error-Stream.txt
• Powershell-Info-Stream.txt
• Powershell-Verbose-Stream.txt
• Powershell-Warning-Stream.txt

Это все диагностические файлы, полный комплект которых позволит техподдержке VMware помочь решить вам вашу проблему с PowerCLI.

Кстати, файл с расширением *.svclog можно открыть с помощью инструмента Microsoft Service Stack Trace Viewer. В данном случае мы там увидим, что API-сервис вернул ошибку internal server error с кодом 500:

Для более детального исследования надо уже смотреть внутрь остальных файлов - это работа технической поддержки VMware, куда вы можете оформить запрос, используя материалы вот по этой ссылке.

В начале года мы рассказывали о книге Upgrading to VMware vSphere 6.5, которая описывала процедуры апгрейда платформы виртуализации на версию 6.5. С тех пор были выпущены обновления vSphere 6.7 и 6.7 Update 1, поэтому документ потерял актуальность.

В связи с этим VMware выпустила обновленную книгу Дэвида Стамена (David Stamen) Upgrading to VMware vSphere 6.7, которая стала доступна для скачивания на днях:

В обновленную версию также включены все нововведения последних версий продуктов Site Recovery Manager и Horizon, которые работают в инфраструктуре vSphere. С точки зрения основной платформы, рассматриваются сценарии апгрейда с vSphere 6.0 и 6.5.

В книге процесс обновления разбит на три фазы:

• Фаза 1: Pre-upgrade – обозначает фронт работ и требований, которые должны быть выполнены перед началом процедуры апгрейда.
• Фаза 2: Upgrade – описание шагов процесса обновления и иллюстрация их исполнения.
• Фаза 3: Post-Upgrade – валидация результата в соответствии с изначально поставленными целями.

Скачать книгу Upgrading to VMware vSphere 6.7 можно по этой ссылке.

Летом этого года мы писали о новых возможностях платформы виртуализации Citrix XenServer 7.5. С тех пор мы особо ничего не писали про него, а, оказывается, еще в в начале осени вышло обновление продукта - XenServer 7.6.

Давайте посмотрим, что там появилось нового:

1. Функции виртуализации устройств Networking SR-IOV: Passthrough of Virtual Functions (только в Enterprise Edition).

Теперь в среде XenSever с использованием технологии Single Root I/O Virtualization (SR-IOV) можно организовать проброс одного физического PCI-устройства так, чтобы оно предстало в виде нескольких виртуальных устройств, каждое из которых доступно виртуальной машине. Например, таким образом вы можете организовать прямое подключение сетевых адаптеров ВМ, минуя виртуальный коммутатор (это дает небольшой прирост к быстродействию). Подробнее об этом здесь.

2. Возможность развертывания тонких дисков (Thin provisioning) для общих блочных хранилищ - GFS2 (только в Enterprise Edition).

С помощью возможностей файловой системы GFS2 можно проводить развертывание виртуальных машин на блочных хранилищах через HBA-адаптеры и iSCSI-инициаторы. Это полезно для различных задач, включая использование нескольких машин на базе одного образа, а также машин с большим числом снапшотов. Также GFS2 поддерживает кэширование на чтение на стороне массива (storage read caching).

Кстати, обратите внимание, что нельзя прицепить репозиторий GFS2 из XenServer 7.5 (там это было в экспериментальном режиме) в пул XenServer 7.6 - нужно будет пересоздать его заново.

3. Изменения в поддержке гостевых ОС.

Теперь XenServer 7.6 поддерживает следующие гостевые ОС:

• Red Hat Enterprise Linux 7.5
• CentOS 7.5
• Oracle Linux 7.5
• Scientific Linux 7.5
• Ubuntu 18.04

4. Автоматическое применение хотфиксов во время обновления или апгрейда на следующую версию.

Теперь при обновлении XenServer через мастеры Rolling Pool Upgrade или Install Update на него автоматически накатываются хотфиксы, чтобы избежать большого числа перезагрузок в процессе приведения хостов в соответствие должному уровню безопасности. Во время обновления нужен доступ с хоста в интернет.

5. Новая структура документации по продукту.

Теперь документация по платформе XenServer доступна только онлайн как HTML-структурированный документ, но есть возможность выгрузить его в PDF с помощью функции экспорта (кнопка View PDF).

6. Остальное.

Заявлена поддержка процессоров семейства Intel Processor E-21xxG/21xx (Coffee Lake S).

Для установки XenServer 7.6 и его обновления с прошлых версий нужно использовать разные ISO-образы в соответствии с таблицей:

Скачать Citrix XenServer 7.6 можно по этой ссылке.

Как знают многие пользователи решения для создания отказоустойчивых кластеров VMware vSAN, в данном продукте есть возможность перевода хоста в режим обслуживания (Enter Maintenance Mode, EMM), который позволяет вывести его на время из эксплуатации с сохранением работоспособности кластера в целом. При этом происходит взаимодействие vSAN и механизма балансировки нагрузки VMware vSphere Distributed Resource Scheduler (DRS), который эвакуирует виртуальные машины с хоста ESXi.

Давайте посмотрим, как работает EMM для кластера vSAN, и какие есть опции для данной процедуры. Чтобы перевести хост ESXi в режим обслуживания, надо нажать на него правой кнопкой в vSphere Client и выбрать пункт Maintenance Mode > Enter Maintenance Mode.

Далее мы увидим окно перевода хоста в режим обслуживания, где можно выбрать одну из трех опций:

• Full Data Migration – это миграция всех компонентов дисковых объектов на другие хосты кластера.
• Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов в этом случае не будет соблюдена политика Failures to tolerate (FTT).
• No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).

С первым пунктом (Full Data Migration) все ясно - он вызывает долговременную процедуру миграции всех дисковых объектов и не всегда оправдан, когда хост ESXi нужно погасить лишь ненадолго. Но если вы выводите хост ESXi из эксплуатации производственного кластера (либо останавливаете, например, на несколько дней), то нужно выбирать именно Full Data Migration.

Давайте подробнее рассмотрим вариант Ensure Accessibility, который как раз подходит для кратковременного обслуживания хоста и последующего его повторного ввода в эксплуатацию. Если у вас достаточно запаса дисковых ресурсов, и виртуальные диски машин работают в RAID-1, то копии дисковых объектов переводимого в режим обслуживания хоста должны быть на других серверах. На картинке ниже реплика объекта C1 есть на другом хосте, поэтому в режиме Ensure Accessibility никаких миграций данных производиться не будет, кластер продолжит работать в режиме полной производительности:

Если же у вас, например, задана политика кластера FTT=1 на четырех хостах, и компоненты дисковых объектов хранятся в соответствии с политикой RAID-5, то картина будет следующей:

В этом случае EMM также не будет перемещать никаких компонентов, так как данные дискового объекта в целом продолжают оставаться доступными. Более подробно о различных вариантах перехода в режим EMM вы можете почитать вот в этой статье.

Между тем, если vSAN object manager будет наблюдать ситуацию несоответствия политики надежности более чем 60 минут (см. параметр Object repair timer в конце статьи), то он, все-таки, запустит синхронизацию дисковых объектов, чтобы их конфигурация в итоге соответствовала действующим политикам.

Кстати, обратите внимание, что такое поведение кластера vSAN - это одна из причин, почему VMware Update Manager не делает обновление хостов ESXi кластера vSAN в параллельном режиме, а проводит это последовательно. Ведь если бы это происходило параллельно, не факт, что можно было бы выполнить требования опции Ensure Accessibility, а также происходило бы много миграций дисковых компонентов.

Кроме того, перед переходом в режим обслуживания хоста, EMM делает полную симуляцию перемещений данных, которые будут проведены в процессе выключения хоста. Например, у нас есть 3 виртуальные машины: vm01 с политикой RAID-0 (без избыточных копий данных), а также машины vm02 и vm03 в режиме RAID-1 (зеркало).

Обратите внимание на картинку ниже:

Здесь показано, что в соответствии с вариантом No data migration 3 дисковых объекта виртуальной машины vm01 окажутся недоступными, а 30, относящихся к vm02 и vm03, не будут соответствовать действующей политике по обеспечению надежности.

Если мы нажмем на ссылку See detailed report, то увидим подробную картину симуляции EMM:

То есть, vm01 окажется недоступной, а vm02 и vm03 будут Non-compliant, пока хост находится в режиме обслуживания.

Если же вы выберете вариант Ensure Accessibility, то прогноз будет следующим:

440 МБ дисковых объектов, относящихся к vm01 будут перемещены, а 30 объектов не будут соответствовать политике, при этом все ВМ останутся доступными. Также в VMware vSAN 6.7 Update 1 появились новые предупреждения о том, что в кластере есть активные процессы синхронизации, а также переходящие или уже перешедшие в режим обслуживания хосты ESXi.

Ну и напомним о настройке Object Repair Timer, которую мы детально рассматривали вот тут. Она то, как раз, и позволяет вам расширить окно обслуживания хоста ESXi в Maintenance Mode, если вам это требуется для проведения какой-то долгой операции. По умолчанию синхронизация не соответствующих политике дисковых объектов начнется через 60 минут:

Удобно, что эта настройка задается на уровне всего кластера vSAN, поэтому не нужно как раньше ходить на каждый хост ESXi и задавать ее.

Как многие из вас знают, в последней версии платформы виртуализации VMware vSphere 6.7 Update 1 компания VMware сделала поддержку горячей миграции vMotion для виртуальных машин, которые имеют на борту технологию vGPU в целях прямого использования ресурсов видеокарт NVIDIA.

Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS.

Между тем, по умолчанию эта поддержка для виртуальных машин отключена, и чтобы начать пользоваться этой функцией нужно внести изменения в настройки vCenter. Если вы попробуете сделать vMotion машины с vGPU, то получите вот такую ошибку:

Migration was temporarily disabled due to another migration activity. vGPU hot migration is not enabled.

Вильям Лам написал о том, как включить поддержку vMotion в этой ситуации. Вам надо пойти в Advanced Settings на сервере vCenter и поставить там значение true на настройки vgpu.hotmigrate.enabled:

Эта настройка также рассматривается в документации вот тут. Надо отметить, что вступает в действие она сразу же, и вы можете делать не только vMotion, но и Storage vMotion любой машины (одновременно с vMotion, кстати). Помните, что для успешной работы vMotion на всех хостах ESXi должны быть карточки NVIDIA GRID и установлен соответствующий VIB-пакет.

Также установить эту настройку можно и с помощью командлета PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vgpu.hotmigrate.enabled | Set-AdvancedSetting -Value $true -Confirm:$false

Не все из вас знают, что в начале этого года компания VMware запустила облачный DR-сервис по обеспечению катастрофоустойчивости виртуальной инфраструктуры в облаке - VMware Site Recovery. Это так называемое DRaaS для публичного облака VMware Cloud on AWS (VMC), которое позволяет организовать disaster recovery (DR) инфраструктуру без капитальных затрат на организацию резервной площадки, покупку оборудования и т.п. для бизнес-критичных приложений - можно просто взять ее в аренду и платить по времени использования.

Это Disaster Recovery as-a-Service (DRaaS) решение на базе публичного облака дает следующие преимущества:

• Возможность быстро развернуть резервное окружение для онпремизной инфраструктуры vSphere в облаке.
• Функции vSphere Replication, обеспечивающие, в случае массового сбоя в датацентре, потерю данных в объеме всего RPO=5 минут.
• Единую консоль Site Recovery Manager (SRM), которая позволяет оркестрировать весь процесс восстановления после аварии.

Учитывая возможности решения Site Recovery, можно выделить 4 основных сценария использования данной технологии:

• Замена существующего DR-решения (оптимизация затрат, перераспределение ресурсов).
• Дополнение существующего DR-решения (частичное освобождение мощностей удаленной площадки).
• Обеспечение DR-инфраструктуры для приложений, которые ранее не были защищены.
• Возможность репликации данных из облака в другой регион AWS или другую онпремизную инфраструктуру.

Сервис Site Recovery работает с любым решением для организации хранилищ, особенно эффективен он будет вкупе с решением vSAN, которое, в свою очередь, может быть построено на различных аппаратных платформах, например, Dell-EMC VxRail.

Перед тем, как развертывать компоненты решения Site Recovery, вы можете пощупать их в реальной обстановке в рамках бесплатной лабораторной работы HOL-1905-01-SDC - VMware Site Recovery Manager - Data Center Migration and Disaster Recovery.

Кстати, на VMworld 2018 компания VMware объявила, что теперь в рамках одного кластера SDDC на площадке можно защищать до 1000 виртуальных машин, что в 2 раза больше, чем раньше:

Кроме того, теперь добавлена возможность (пока в режиме превью) реплицировать несколько онпремизных площадок в одну облачную VMware Cloud on AWS DR.

Узнать больше информации о VMware Site Recovery можно в специальном блоге, а также посмотрев следующие видео:

Это гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин из облака по модели IaaS.

С приходом GDPR многие компании поменяли свои политики конфиденциальности и реализовали дополнительные механизмы работы с персональными данными пользователей. Но ряду организаций сделать это не удалось, и им пришлось свернуть бизнес. Посмотрим, почему так получилось.

Первая реакция бизнесов на GDPR

Одним из самых серьезных требований нового регламента стал запрет использовать персональные данные (ПД) в рекламных целях без согласия пользователей. Поэтому многие ИТ-компании изменили политики работы с ПД.

Например, в Facebook добавили новое диалоговое окно с просьбой дать согласие на обработку той или иной информации (в том числе в маркетинговых целях). Однако интерфейс этого окна подвергся критике общественности – о нем писали даже такие крупные издания, как TechCrunch и The Guardian. Журналисты отметили, что дизайн окна намеренно подталкивает пользователей предоставить социальной сети максимум данных: кнопка для изменения настроек крайне неприметна, а ограничить использование тех или иных данных не так-то просто.

Facebook также предоставили возможность выгружать историю поиска в социальной сети и другие данные: историю обновления статусов и звонков, а также теги местоположений и др. Это еще одно требование GDPR.

Такую же функцию предоставила «дочка» Facebook – Instagram. Пользователь получает архив с фотографиями, информацией профиля, комментариями и др.

Однако не всем бизнесам удалось подружиться с новыми требованиями регламента. К 25 мая, когда начал действовать GDPR, больше половины европейских IT-компаний не внедрили необходимые механизмы для работы с ПД. И таких компаний все еще большинство. Поговорим о том, с чем это связано.

Почему сложно выполнять требования GDPR

Это дорого. По данным исследований, только компании из Fortune 500 и FTSE 100 потратят почти миллиард евро на пересмотр своих контрактов и приведение их в соответствие с требованиями GDPR. У малого и среднего бизнеса на проработку нового регламента ресурсов зачастую просто нет.

Регламент не учитывает законы отдельных стран. У разных стран разные определения персональных данных. Поэтому многие формулировки в GDPR сделаны максимально обтекаемыми.

В законе плохо прописана работа с машинным обучением. GDPR начали разрабатывать в 2016 году и многие заложенные в него концепции уже успели устареть. В частности, в нем плохо описаны принципы работы с большими данными (полученными на основе ПД) и системами искусственного интеллекта.

По закону разработчик должен понимать, почему интеллектуальная система приняла то или иное решение. Требование регламента – объяснить пользователю, как именно обрабатываются его персональные данные. Однако «заглянуть» внутрь алгоритма не всегда возможно, так как в большинстве случаев система ИИ представляет собой черный ящик: на вход подаются данные, они как-то обрабатываются, а на выходе получается результат. Даже создатель системы может не знать, почему она выдала такое решение.

Кто не справился и закрылся

Из-за сложности (и дороговизны) реализации всех требований GDPR компании, которые не располагали достаточными ресурсами, были вынуждена прекратить деятельность. О закрытии объявил ряд онлайн-игр: Super Monday Night Combat и Loadout. В обоих случаях стоимость внедрения всех систем для соответствия регламенту (обновление клиента, БД и покупка новых серверов) оказалась неподъемной для небольших студий. В случае с Super Monday Night Combat стоимость обновления вообще была...Читать статью далее->>

Компания Amazon, в рамках конференции AWS re:Invent 2018, объявила о запуске инициативы AWS Outposts, которая будет предоставлять облачные сервисы AWS на площадке и оборудовании заказчика, в том числе сервисы VMware Cloud on AWS.

По-сути, механизм AWS Outposts позволит вам использовать стандартные сервисы AWS, как будто они работают в облаке, но реально исполнять их на своем оборудовании. Это позволит получить все сервисы AWS SDDC, такие как vSphere, NSX и vSAN в своем датацентре, при этом платить по модели повременного использования ресурсов AWS.

Такое может пригодиться в отраслях, где существуют высокие требования к задержкам проведения операций (latency), что требует локального исполнения вычислительных ресурсов, например, в телекоме, высокочастотной биржевой торговле, промышленной автоматизации, финансовых сервисах, ИТ-системах здравоохранения и других приложениях.

Здесь логично напрашивается вопрос - а зачем нужно локально исполнять VMware Cloud on AWS, если можно просто развернуть на своем оборудовании VMware vSphere и остальные компоненты? Использовать VMware Cloud on AWS в таком режиме будет целесообразно, когда у вас есть гибридная среда из локальных и облачных датацентров, а вы хотите получать виртуальные ресурсы от единого поставщика - Amazon, а сервисы по управлению и апдейту всех компонентов SDDC - от VMware.

Также можно будет использовать единую консоль VMConAWS для управления всеми виртуальными инфраструктурами в распределенных датацентрах с возможностью соблюдения единых требований к оборудованию и ПО, политик и рабочих процессов.

Надо отметить, что AWS Outposts предполагает развертывание как в варианте с VMware Cloud on AWS, так и без него - с нативными службами Amazon и их API.

Сервис AWS Outposts будет доступен для пользователей, начиная со второй половины 2019 года. Изменения можно отслеживать на этой странице.

Как знают администраторы больших инфраструктур VMware, для среды управления vSphere есть компонент Platform Services Controller, который может быть внешним (External PSC) и внедренным (Embedded PSC). Недавно мы писали о том, как провести миграцию на внедренный PSC с внешнего PSC с помощью утилиты vCenter Server Converge Tool.

VMware везде рассказывает об этом неспроста - недавно было заявлено, что в следующей версии VMware vSphere внешний сервис PSC будет отсутствовать в принципе. А в данный момент Embedded PSC является рекомендуемым способом развертывания инфраструктуры vCenter (как и виртуальный модуль vCSA).

Возможность создания внешнего PSC появилась в версии vSphere 6.0, а еще в vSphere 5.1 компания VMware предоставила возможность размещать отдельные компоненты, такие как VMware Update Manager (VUM) или vCenter Server Database (VCDB) на отдельных серверах. Это привело к тому, что средства управления виртуальной инфраструктурой можно было развернуть аж на 6 серверах, что рождало проблемы интеграции, обновления и сложности обслуживания.

Когда VMware предложила модель с внешним PSC инфраструктура свелась всего к двум узлам сервисов vCenter. PSC обслуживает инфраструктуру SSO (Single Sign-On), а также службы лицензирования, тэгов и категорий, глобальных прав доступа и кастомных ролей. Помимо этого PSC отвечает за сертификаты данного SSO-домена.

В то время, как службы PSC принесли гибкость развертывания, они же принесли и сложность обслуживания, так как для них нужно было обеспечивать отдельную от vCenter процедуру отказоустойчивости в инфраструктуре распределенных компонентов vCenter Enhanced Linked Mode (ELM).

Еще в vSphere 6.7 и vSphere 6.5 Update 2 была введена поддержка режима ELM для Embedded PSC, поэтому с внедренным PSC уже не требуется обеспечивать отказоустойчивость дополнительных узлов, балансировку нагрузки, а также их обновление. Теперь можно обеспечивать доступность узлов vCenter посредством технологии vCenter High Availability.

Поэтому уже сейчас можете использовать vCenter Server Converge Tool для миграции внешних PSC на Embedded PSC виртуального модуля vCenter Server Appliance. А возможности развернуть внешние PSC в следующих версиях vSphere уже не будет.

Многие администраторы VMware vSphere весьма консервативны и подолгу не обновляют версию платформы виртуализации, даже когда есть деньги на продление поддержки. Отчасти это верная стратегия - VMware так часто пропускает серьезные баги в мажорных релизах, что многие ждут пока обновление "настоится".

Но долго ждать тоже не стоит, так как можно недополучить преимущества новых версий. Например, всегда от релиза к релизу у платформы vSphere растет производительность в различных аспектах. В частности, давайте посмотрим, как выросла производительность технологии миграции хранилищ Storage DRS в VMware vSphere 6.7 по сравнению с версией 6.5.

VMware провела тестирование двух версий платформы и посмотрела, как быстро происходит генерация рекомендаций DRS в разрезе следующих операций в кластере:

• CreateVM
• CloneVM
• ReconfigureVM (добавление дополнительного диска)
• RelocateVM (перемещение на другой датастор)
• Datastore Enter Maintenance (перевод датастора в режим обслуживания)

При одновременном исполнении в кластере множества данных задач одновременно имеет значение своевременное формирование рекомендаций (куда поместить ВМ, куда ее клонировать и т.п.). По итогам тестирования были получены следующие результаты (столбики показывают процент улучшения по времени для 5 одновременных исполняемых операций):

Для 16 одновременных операций:

Отдельно представлен график для операций Datastore Enter Maintenance:

Все это приводит к увеличению скорости развертывания и миграции виртуальных машин и их VMDK-дисков в больших инфраструктурах, где в этом участвует механизм SDRS (генерация рекомендаций по размещению виртуальных машин).

Как почти все знают, компания VMware в рамках конференции VMworld 2018 анонсировала доступность новой версии решения для создания отказоустойчивых хранилищ VMware vSAN 6.7 Update 1. В обновленном vSAN появилась масса новых возможностей, но сегодня мы расскажем о трех новых расширенных настройках (Advanced Options), про которые написал Cormac Hogan, и которые стали доступны для редактирования в графическом интерфейсе.

Ранее Кормак рассказывал про следующие расширенные настройки кластера vSAN:

• VSAN.ClomRepairDelay - задержка перед началом ребилда отсутствующих компонентов.
• VSAN.DomOwnerForceWarmCache - определяет, должны ли операции чтения производится со всех реплик дисковых объектов, либо с определенных сайтов растянутого (stretched) кластера vSAN.
• VSAN.SwapThickProvisionDisabled - возможность сделать swap-файлы виртуальных машин тонкими, то есть растущими по мере наполнения данными.

Теперь эти три настройки в новой инкарнации можно найти в разделе:

Cluster > Configure > vSAN > Services > Advanced Options

При нажатии на ссылку EDIT можно открыть интерфейс их изменения:

1. Настройка Object Repair Timer.

Как было сказано выше, она определяет задержку, после которой начинается ребилд отсутствующих дисковых объектов в кластере после произошедшего сбоя. По умолчанию она установлена в 60 минут (время, которое нужно VMware Update Manager для обновления хоста ESXi). Также тут нужно достаточное время, чтобы не происходило ненужных срабатываний при временных проблемах в сети. Если вы просто тестируете продукт vSAN, то можете поставить ее, например, в 15 минут, чтобы посмотреть, как начнется процесс ребилда.

Если же надо вывести часть кластера в режим обслуживания дольше чем на час, то можно увеличить этот параметр. Ранее подобную настройку нужно было делать на каждом хосте ESXi, а теперь она едина для всего кластера.

2. Настройка Site Read Locality.

Эта настройка определяет, будут ли данные растянутого (stretched) кластера читаться из реплик дисковых объектов на уровне одного сайта (домена отказа), либо будут читаться из всех реплик дисковых объектов ВМ. Второй вариант подходит, когда между площадками у вас налажено высокоскоростное соединение (inter-site link), не отличающееся по скорости от внутреннего. Если же это совсем не так, то Read Locality можно отключить.

Также эта настройка работает и для кластеров vSAN состоящих только из двух узлов - и вот тут иногда бывает смысл ее менять, чтобы данные ВМ читались, например, только с одного хоста ESXi.

3. Настройка Thin Swap.

Она определяет, будут ли файлы подкачки виртуальных машин "тонкими", то есть растущими по мере наполнения данными. Тонкие swap-файлы экономят дисковое пространство, но создают совсем маленькую нагрузку по IO при аллоцировании блоков. По умолчанию тонкий своп включен.

И тут тоже надо отметить, что теперь эта настройка централизованно задается для всего кластера vSAN, а раньше нужно было ходить на каждый хост ESXi и выставлять ее там.

Уважаемые читатели! Некоторые из вас знают, что у нас на сайте есть цикл статей от Романа Гельмана, который разрабатывает различные функции своего PowerCLI-модуля Vi-Module. Они позволяют управлять многими аспектами виртуальной инфраструктуры VMware vSphere с помощью механизмов, недоступных в рамках стандартных средств управления.

Недавно Роман подал свой англоязычный блог ps1code.com на голосование по выбору лучшего блога о виртуализации Top vBlog 2018. И мы от лица всей редакции очень просим проголосовать за Романа - ведь его блог этого действительно достоин!

Спасибо вам заранее.

И вот статьи Романа на нашем ресурсе, чтобы вам удобнее было найти нужную функцию:

• PowerShell скрипт для автоматической установки ESXi хостов на серверах IBM/Lenovo
• Как получить расширенную информацию об RDM-дисках с помощью PowerCLI
• Как конвертировать «тонкие» VMDK-диски в Eager Zeroed Thick с помощью VMware PowerCLI
• Как найти хост ESXi с виртуальными машинами VMware vCenter и SQL Server, когда они выключены?
• Команда Connect-VIServer в PowerCLI: глубокое погружение или «куда же я подключен?»
• Как скопировать VMware ВМ Notes в Computer/AD Computer Account description
• Как узнать версию BIOS/Firmware ESXi сервера при помощи PowerCLI
• Как узнать дату и время установки хоста ESXi
• Как сравнить установленные VIB packages между двумя и более хостами ESXi
• Как включить/отключить SSH на всех хостах ESXi в кластере при помощи PowerCLI
• Как задать/изменить NTP-серверы для хостов ESXi с помощью PowerCLI
• Как узнать версию любого объекта VMware? Используйте Get-Version!
• Azure Automation: как включить/выключить ВМ в облаке Microsoft Azure по расписанию
• Автоматизация работы с тегами Azure VM
• Как найти потерянные VHD файлы в облаке Azure IaaS?
• Как просматривать датасторы VMware с помощью PowerCLI
• Как сравнить 2 или более хостов VMware ESXi с помощью PowerCLI
• Как мигрировать VMware VM Templates на другой Datastore с помощью PowerCLI
• PowerShell и putty – лучше вместе
• Как получить информацию о графическом процессоре ESXi с помощью PowerCLI
• Как проверить наличие хотфикса в VMware ВМ с помощью PowerCLI
• Как конфигурировать Storage DRS кластеры с PowerCLI – Часть 1
• Как создавать и удалять SDRS Anti-Affinity правила с PowerCLI – Часть 2
• Как конфигурировать SDRS Anti-Affinity правила с PowerCLI – Часть 3
• Как увеличить VM Guest Partition с помощью PowerCLI
• Сохранять и извлекать учетные данные с помощью PowerCLI
• Как узнать срок годности резервных копий vCSA с помощью PowerCLI?
• Как получить данные CDP протокола с помощью PowerCLI
• Как мониторить задачи Nutanix с PowerShell

Голосуйте за Романа и его ps1code.com!

Некоторое время назад мы писали о продуктах и технологиях, анонсированных на конференции VMworld Europe 2018 (часть 1 и часть 2), а сегодня поговорим о еще одной технологии, объявленной в рамках мероприятия - VMware vSAN Native Data Protection. О ней в своей статье рассказал Viktor van den Berg.

Данная технология будет представлять собой репликацию данных виртуальных машин на уровне хранилищ на базе снапшотов (а также будет доступна локально в рамках хранилища) в целях создания резервных копий ВМ. Работать этот механизм будет в соответствии с текущей механикой политик Storage Policy Based Management (SPBM).

Использовать технологию vSAN Native Data Protection можно для трех сценариев:

• Защита локальных виртуальных машин без использования снапшотов vSphere.
• Репликация данных машин на стороннее хранилище NFS.
• Репликация данных машин на другую площадку (другой кластер vSAN) под управлением того же (или другого) сервера vCenter.

Технология vSAN Local Data Protection будет использовать механизм native vSAN snapshots, который почти не оказывает влияние на производительность ВМ (поскольку работает на уровне хранилища). Также будут поддерживаться консистентные с точки зрения приложений снапшоты, которые будут использовать скрипты Microsoft VSS / VMware Tools для "подморозки" приложений.

Вот так эта настройка будет выглядеть в мастере конфигурации политики хранилищ для ВМ:

Как мы видим, можно установить частоту создания снапшотов (по сути, требования RPO). Далее идет настройка про то, с какой периодичностью делать application consistent снапшоты. Ну и в конце - число хранимых снапшотов.

Некоторые снапшотоы можно будет хранить в течение долгого периода времени в архивных целях:

Также расписание снапшотирования и откидывания на NFS-хранилище будет представлено в таблице:

Сточки зрения восстановления машин из локальных снапшотов, будет использоваться технология Linked Clone, с помощью которой процесс поднятия ВМ будет занимать около одной минуты. Восстановление полностью независимой ВМ займет существенно больше времени (в зависимости от объема хранилища). При восстановлении ВМ можно выбрать кластер, куда восстанавливать, а также VM Network.

Также в процессе работы vSAN Native Data Protection можно просматривать информацию о ее состоянии в целом:

И для виртуальных машин:

Также будет несколько интересных моментов:

• Пока не будет интеграции vSAN Native Data Protection и SRM.
• В будущем планируется создание резервных копий с помощью снапшотов для групп ВМ (consistency groups), если они, например, располагаются на разных хранилищах.
• Минимально RPO можно указать как 5 минут.
• Для обеспечения консистентности бэкапов на уровне приложений можно будет использовать собственные скрипты подготовки и возобновления приложения, а также Microsoft VSS.
• Технология будет интегрирована со сторонними решениями для резервного копирования и фреймворком VADP.
• Репликация на удаленное хранилище также будет использовать снапшоты в своей основе.
• Без application consistent снапшотов (только crash consistent) хранилище будет снапшотиться мгновенно.
• Будет поддерживаться репликация как между разными кластерами, так и между разными vCenter.
• В качестве архивного хранилища будет поддерживаться пока только NFS, но потом можно будет использовать и облачный сторадж Amazon S3.
• Нативные снапшоты будут дедуплицироваться и сжиматься при передаче.

Доступность технологии vSAN Native Data Protection ожидается в первом квартале 2019 года, а пока вы можете запросить доступ к vSAN Beta, где эта технология уже имеется.

Также полистайте вот эту презентацию и посмотрите вот эту запись с сессии VMworld Europe 2018.

Несколько недель назад компания Login VSI, известная своими бенчмарками для виртуальных сред, выпустила обновленную версию своего средства для генерации и тестирования нагрузки приложений в виртуальных ПК - Login PI Release 3. Напомним, что о прошлой версии этого продукта мы писали вот тут.

На наш взгляд, это наиболее продвинутое средство тестирования производительности приложений в виртуальных десктопах на сегодняшний день.

Давайте посмотрим, что нового появилось в Login PI Release 3:

Она позволяет строить расширенные рабочие процессы с помощью логических условных выражений, что позволяет настроить нагрузку в соответствии с требованиями реальных производственных окружений. Сами приложения могут быть добавлены без использования скриптов.

• Воркфлоу можно создавать с помощью функций автодополнения (intellisense) и подсветки синтаксиса. Их можно редактировать без соединения с бэкендом Login PI, то есть на клиенте без задержек.
• Более гранулярные действия в рабочих процессах и возможность более детального планирования событий, что позволяет точнее настраивать симулированных пользователей и удобнее оркестрировать их поведение.
• Расширенная поддержка сторонних приложений (EPIC, Cerner, AllScripts и т.п.), приложений пользователей (Microsoft Office), а также тесно интегрированных сторонних плагинов, рабочих процессов и скриптов.

2. Новая архитектура Login PI Release 3.

Здесь появились следующие улучшения:

• Теперь поставляется как виртуальный модуль (virtual appliance) и развертывается за несколько минут.
• За счет использования REST API теперь можно интегрировать Login PI с традиционными решениями для мониторинга, такими как SCOM, или системами управления инцидентами, например, ServiceNow, а также big-data анализаторами (например, Splunk).
• Login PI R3 поддерживает соединения через RDP, PCoIP, Blast Extreme, Citrix ICA/HDX, NetScaler и любые другие.
• Повышенная безопасность продукта.

3. Новый интерфейс.

В продукте были улучшены все дэшборды, которые теперь предоставляют более детальную информацию, дают ее более удобном для понимания виде для технического и бизнес-ориентированного персонала.

• Новый интерфейс для конфигурации, репортинга и быстрых выводов (quick insights) в плане производительности.
• Более детальная информация и умная агрегация данных на высокоуровневых дэшбордах для проверки и анализа нескольких серверных ферм в разных локациях, а также для нескольких клиентов (удобно для сервис-провайдеров).

4. Проактивный мониторинг.

С помощью функций проактивного мониторинга можно наблюдать за производительностью VDI-инфраструктуры и выявлять потенциальные проблемы еще до их возникновения. Это делается за счет определения метрик производительности на симулированных пользователях при условиях, которые возникнут в будущем.

Некоторое время назад мы рассказывали об анонсах конференции VMworld Europe 2018, одним из которых была покупка компании Heptio, предоставляющая решения для управления контейнерами платформы Kubernetes в облаке. Ну а на днях на сайте проекта VMware Labs появился плагин к vSphere Client, который позволяет видеть кластеры и узлы Kubernetes, которые находятся под управлением Pivotal Container Service - vSphere PKS Plugin.

Возможности плагина PKS:

• Визуализация, настройка и управление кластерами Kubernetes, развернутыми и управлеяемыми с помощью PKS.
• Средства просмотра нижележащей инфраструктуры для контейнеров, включая виртуальные машины, сетевые ресурсы и объекты хранилищ, которые созданы в кластере Kubernetes, развернутом в окружении VMware vSphere.
• Единая точка просмотра компонентов кластера Kubernetes, включая узлы и сетевые объекты, такие как роутеры, логические коммутаторы и балансировщики.
• Простой интерфейс для доступа к кластеру через kubectl и дэшборд.

Для работы плагина вам понадобятся следующие компоненты:

• PKS v1.2.x
• NSX-T v2.3
• vSphere v6.7.x, v6.5 U1, U2

Загрузить vSphere PKS Plugin можно по этой ссылке (там же вы найдете и документацию).

Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.

1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.

Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).

Ну а суть бага заключается в том, что блоки данных могут оказаться поврежденными, что приводит к неконсистентности файлов для приложений (например, баз данных), а также иногда к невозможности загрузки виртуальной машины!

Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:

• vSphere 6.5 Patch - VMware ESXi 6.5, Patch Release ESXi650-201810002.
• vSphere 6.0 Patch - VMware ESXi 6.0, Patch Release ESXi600-201810001.

Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:

esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing

2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.

Аналогично багу из прошлого пункта, здесь может произойти неприятность с целостностью данных виртуальных машин, которые работают в кластере хранилищ VMware vSAN 6.6. Это может случиться в следующих обстоятельствах:

• vSAN начинает процесс ресинхронизации
• В этот момент вы расширяете диск VMDK виртуальной машины
• vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины

Проблема описана в KB 58715. В этом случае вы сможете только восстановить консистентность виртуальных машин, но сами данные приложений вы уже не вернете.

Для устранения бага накатите патчи на vSAN:

• vSAN 6.7 - Express Patch 4 Release: http://kb.vmware.com/kb/58848
• vSAN 6.6 - Express Patch 9 Release: http://kb.vmware.com/kb/58852

Также вы можете временно избежать проблемы, выполнив такую команду на каждом хосте ESXi:

esxcfg-advcfg -s 0 /VSAN/ClomEnableInplaceExpansion

3. Получение доступа root к хосту ESXi из виртуальной машины.

Если вы используете виртуальные машины с драйвером сетевого адаптера vmxnet3 (у него был еще один отдельный баг), то для непропатченных хостов есть возможность получения доступа root к шеллу ESXi из виртуальной машины.

Кстати, это было публично показано впервые:

#GeekPwn2018 Chaitin Tech security researcher f1yyy has escaped VMware EXSi and got root shell on the host for the first time in the world. After demonstrating it at GeekPwn 2018, f1yyy received the Best of Tech Award and was selected to the GeekPwn Hall of Fame.@GeekPwn pic.twitter.com/2Y2kYKaw4d

— Chaitin Tech (@ChaitinTech) October 31, 2018

Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).

Компания VMware выпустила документ, касающийся работы баз данных Oracle Database 12c на платформе VMware vSAN - Oracle Database on VMware vSAN 6.7. Основная тема дока - тестирование числа операций ввода-вывода (IOPS) и latency операций СУБД на хостах в All-Flash конфигурации, когда и ярус кэширования, и ярус хранения реализован на SSD-дисках:

В документе рассматривается 4 ключевых аспекта для реализации тяжелых баз данных:

• Производительность OLTP-нагрузок в кластере all-flash vSAN.
• Политики Storage Policy Based Management (SPBM) для управления хранилищами.
• Построение платформы для бизнес-критичных задач уровня Tier-1.
• Валидация архитектуры для уменьшения времени развертывания и операционных рисков.

Для тестирования использовались хосты ESXi в следующей конфигурации:

В тестах использовалось два типа рабочих нагрузок (R1 и R15), отличающихся конфигурацией ВМ, а также включенными или выключенными технологиями дедупликации и компрессии на стороне vSAN:

Описание рабочей нагрузки:

Базовые результаты по IOPS и latency для операций чтения и записи:

После результатов тестирования в документе есть секция с рекомендациями по исполнению Oracle на хранилищах vSAN, которые будет полезно почитать администратору БД и vSphere (большая их часть приведена в vSAN Design and Sizing Guide).