Если вы администратор платформы виртуализации VMware vSphere, то, наверное, часто замечали, что в некоторых случаях при операциях с виртуальными машинами и ее дисками происходит "подмораживание" ВМ (или "stun", он же "quiescence"). В этот момент виртуальная машина ничего не может делать - она недоступна для взаимодействия (в консоли и по сети), а также перестает на небольшое время производить операции ввода-вывода. То есть, ее исполнение ставится на паузу на уровне инструкций, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).
Cormac Hogan написал на эту тему интересный пост. Stun виртуальной машины нужен, как правило, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация снапшотов. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше.
Когда может возникать stun виртуальной машины? Есть несколько таких ситуаций.
1. Во время операции "suspend" (постановка ВМ на паузу). Тут происходит такое подмораживание, чтобы скинуть память ВМ на диск, после чего перевести ее в приостановленное состояние.
2. В момент создания снапшота. Об этом написано выше - нужно закрыть старый диск и начать писать в новый. На время этой операции логично, что приостанавливается ввод-вывод.
3. Консолидация снапшотов (удаление всех). Здесь тоже нужно "склеить" все VMDK-диски (предварительно закрыв) и начать работать с основным диском ВМ. А вот удаление снапшота в цепочке stun не вызывает, так как не затрагивает VMDK, в который сейчас непосредственно идет запись.
4. Горячая миграция vMotion. Сначала память передается от одной машины к целевой ВМ без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).
5. Горячая миграция хранилищ Storage vMotion. Здесь stun случается аж дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова переоткрыть диски уже на целевом хранилище.
В современных версиях vSphere работа со снапшотами была оптимизирована, поэтому подмораживания виртуальной машины во время этих операций вы почти не заметите.
Давно мы не публиковали сравнений платформ виртуализации VMware vSphere и Microsoft Hyper-V, которые, как известно, лишены смысла (ибо они либо ангажированы, либо сравнивают мягкое с горячим, либо привязываются к конкретному варианту использования). Всем понятно, что VMware - это дорогая и мощная платформа для тех у кого есть деньги, а Microsoft - бюджетная платформа виртуализации серверов в небольших компаниях. И в ближайшие пару лет это вряд ли изменится.
Так вот, оказывается, одно из последних сравнений VMware vSphere 5.1 и Microsoft Hyper-V третьей версии (примерно то, что есть сейчас) мы публиковали аж в 2012 году. Но ведь не так давно компания VMware обновила свое сравнение, включив туда VMware vSphere 6.0, пытаясь, видимо, широко распространить эту презентацию до того, как Microsoft обновит свой Windows Server до платформы vNext (это будет в следующем году).
Ну а мы, без зазрения совести, публикуем здесь это сравнение.
Итак, основные параметры платформ (гипервизора). VMware действительно выигрывает по Enterprise-фичам, но все довольно спорно для SMB:
Обеспечение доступности и защита данных. Здесь VMware, конечно же, впереди. Но нужен ли такой уровень доступности (например, Fault Tolerance) для небольших компаний? Иногда да, но чаще выгоднее сэкономить.
Автоматизация и управление. Ну вот это все точно про крупную организацию:
Ну и традиционный булшит про стоимость владения (его как бы можно посчитать на калькуляторе VMware вот тут). Когда не могут оправдать высокую входную цену продукта - берутся, как правило, заливать про TCO. Типа автоматизация сэкономит вам кучу денег:
Как, помимо прочего, происходит экономия при виртуализации? Типа, говорят, становится меньше дел, и можно сократить "лишних" системных администраторов. На деле же геморроя становится больше, поэтому администратора приходится нанимать.
Как многие из вас знают, в VMware vSphere 6.0 была добавлена функциональности горячей миграции vMotion виртуальной машины между датацентрами под управлением разных серверов vCenter. Виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed Switch (vDS)в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.
На днях VMware выпустила интересное видео, описывающее данную возможность:
Чтобы машина могла переезжать с одного vCenter на другой в горячем режиме необходимо:
Чтобы оба сервера vCenter были версии 6.0 или более поздней.
Чтобы оба сервера vCenter работали в режиме Enhanced Linked Mode и были в одном домене Single Sign-On, то есть один vCenter (исходный) мог аутентифицироваться на другом (целевом).
Оба сервера vCenter должны быть синхронизированы по времени, чтобы SSO мог корректно производить аутентификацию.
Если вы переносите только ВМ с сервера на сервер (хранилище остается тем же), оба сервера vCenter должны видеть общее хранилище (соответственно, хост-серверы и vCenter должны быть соответствующим образом отзонированы).
Больше подробностей можно узнать из видео выше и KB 2106952.
На сайте проекта VMware Labs появилась очередная полезная утилита - View Auto-Connection Utility, которая может понадобиться администраторам виртуальной инфраструктуры десктопов VMware View. Эта штука позволяет задать параметры соединения с виртуальным ПК, протестировать их и включить возможность автосоединения с конкретным десктопом:
Утилита обнаруживает установленный VMware View Client на компьютере, после чего можно выбрать следующие параметры:
Подключение к виртуальному ПК или отдельному приложению по RDSH
Сервер Connection Server и пул виртуальных ПК
Протокол (PCoIP или RDP)
Логин/пароль
Режим отображения консоли (полный экран или в окне)
Подключить USB-устройства
Отключить Shade (верхняя часть меню в консоли виртуального ПК)
Также можно сгенерировать консольную команду по запуску клиента, настроить выход из приложения по окончанию сессии и отключить предупреждения клиента (Launch Silently).
Протестив соединение с помощью кнопки Test Connection, можно поставить галку "Enable AutoConnection" и добавить программу в автозагрузку. После этого, при старте физического ПК сразу будет запускаться нужное соединение с виртуальным десктопом. Очень просто и полезно, особенно для тонких клиентов (или для превращение компьютеров в "как бы тонкие клиенты").
В качестве хостовых ОС поддерживаются следующие:
Windows XP
Windows 7
Windows Vista
Windows 8
Windows 8.1
Windows Server 2003
Windows Server 2008
Windows Server 2012
Скачать View Auto-Connection Utility можно по этой ссылке. Инструкции по использованию доступны здесь.
Практически все администраторы виртуальных инфраструктур обеспокоены проблемой ее производительности в тех или иных условиях. На днях компания VMware обновила свое основное руководство по производительности платформы виртуализации номер один на рынке - Performance Best Practices for VMware vSphere 6.0.
Это не просто очередной whitepaper - это настоящая книга о производительности, на почти 100 страницах которой можно найти не только теоретические советы, но и вполне практичные настройки и конфигурации среды VMware vSphere. К каждому объясняемому параметру заботливо описаны рекомендуемые значения. В общем, Must Read.
Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:
Во второй части подробно описаны различные сценарии сбоев и их обработка кластером vMSC в вашей распределенной виртуальной инфраструктуре:
В документе описаны следующие виды сбоев:
Отказ одного хоста в основном датацентре
Изоляция одного хоста в основном датацентре
Разделение пула виртуальных хранилищ
Разделение датацентра на сегменты (сети хостов и сети хранилищ)
Отказ дисковой полки в основном ЦОД
Полный отказ всех хранилищ в основном датацентре
Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)
Понятное дело, что документ обязателен к прочтению, если вы планируете строить распределенную инфраструктуру для ваших виртуальных машин на платформе VMware vSphere 6.0.
Цель документа - дать понятие о методике сбора данных об ИТ-окружении, сайзинге, планировании архитектуры и внедрении VMware Mirage в инфраструктуру предприятия. Напомним, что сам Horizon Mirage предназначен для управления образами виртуальных и физических ПК на уровне слоев ОС, приложений и данных (это нужно для обновлений компонентов, бэкапа и восстановления, а также миграции ОС в корпоративной инфраструктуре).
Пояснения к работе схемы:
Каждый конечный ПК (виртуальный или физический) содержит установленный клиент Mirage, которые забирает слои (ОС, приложения, данные) с серверов Mirage (или кластера этих серверов).
Администраторы определяют расписание и проводят обновления этих слоев.
При изменении слоя на конечном ПК происходит синхронизация этих изменений в сторону датацентра, чтобы обе копии окружений были одинаковыми (этот процесс может инициировать как пользователь, так и администратор датацентра).
Если подумываете о внедрении Horizon Mirage, то документ, конечно же, нужно обязательно прочитать.
В самом конце прошлого года мы писали о том, что компания VMware выпустила решение VMware Horizon FLEX, которое представляло собой продолжение продуктов VMware ACE (если его здесь кто-то еще помнит) и VMware View Local Mode. Напомним, что Horizon FLEX представляет собой платформу виртуализации для настольных ПК, позволяющую запускать виртуальные ПК локально (как на Mac во Fusion, так и на Windows в Player), без требования связи с датацентром компании. Кстати, VMware Mirage входит в состав VMware FLEX.
На днях компания VMware анонсировала обновление Horizon FLEX 1.5:
Теперь в продукте появилось много новых функций и возможностей (большинство доработок основано на фидбэке пользователей), а именно:
больше новых политик - больше гибкости в настройке
возможность удаленно стереть виртуальную машину с хоста
более гибкий и гранулярный контроль политик для USB-устройств
управление на базе политик для файловой системы хоста и ВМ
больше возможностей по выделению машине оперативной памяти и CPU
интеграция с Active Directory по зашифровке/расшифровке виртуального образа
возможность задания лимита на запуск только одной копии ВМ
иконка для виртуальной машины пользователя на рабочем столе
Скорее всего, вам будет лень все это ставить, поэтому пройдемся по данному решению в формате видеообзоров. Об основных функциях продукта:
Создание образа для пользователей:
Настройка политик для виртуальной машины, которая уйдет к пользователю для локального запуска:
В блоге Tech Communications Video Blog компании VMware в последние дни появилось три действительно интересных видеоролика. Во-первых, вы знаете, что в последней версии VMware Horizon View 6.1.1 появилась поддержка виртуальных десктопов Linux.
Директор по R&D в видео ниже рассказывает, как они работают, а также показывает весь процесс, включая консольные команды и настройку параметров. То есть, это не маркетинговый булшит, а хороший технический обзор новой функции, в которой заинтересованы сейчас многие:
Во-вторых, весьма интересен ролик про различие параметров настройки vCenter Server Appliance версий 5.5 и 6.0 (в шестой версии больше нет Virtual Appliance Management Interface):
Ну и, в-третьих, полезно посмотреть видео о развертывании продукта VMware vRealize Business Standard, являющегося частью пакета решений VMware vCloud Suite 6.0. Напомним, что vRealize Business нужен для автоматического определения стоимости содержания и развития инфраструктуры, а также измерения потребления ресурсов.
Да и в общем и целом блог весьма интересный для технической аудитории - посмотрите прошлые видео.
В блоге компании VMware появился интересный пост с некоторыми подробностями о работе технологии репликации виртуальных машин vSphere Replication. Приведем здесь основные полезные моменты.
Во-первых, репликация с точки зрения синхронизации данных, бывает двух типов:
Full sync - это когда требуется полная синхронизация виртуальной машины и всех ее дисков в целевое местоположение. Для этого в версии VMware vSphere 5.x использовалось сравнение контрольных сумм дисков на исходном и целевом хранилище. Если они не совпадают, и нужно делать Full sync, исходя из начальных условий - начинается процесс полной репликации ВМ. В первую очередь, основным подвидом этого типа является Initial full sync - первичная синхронизация работающей виртуальной машины, для которой репликация включается впервые.
Кроме того, полная синхронизация включается, когда по какой-либо причине произошла ошибка отслеживания блоков виртуального диска машины при дельта-репликации и передать на целевую ВМ только изменения виртуальных дисков становится невозможным.
Delta sync - после того, как полная синхронизация закончена, начинается процесс передачи целевой ВМ только различий с момента полной репликации. Тут используется технология changed block tracking, чтобы понять, какие блоки надо отреплицировать с последнего Full sync. Периодичность дельта-репликации зависит от установленной политики Recovery Point Objective (RPO).
Чтобы политика RPO соблюдалась нужно, чтобы дельта-синхронизация полностью проходила за половину времени, установленного в RPO, иначе будут нарушения политики, сообщения о которых вы увидите в vSphere Client. Почему половину? Подробно мы писали об этом вот тут (почитайте, очень интересно). Также еще и в документации VMware есть информация о расписании репликации.
Если вы настроите репликацию для виртуальной машины, то автоматически работать она будет для включенной ВМ, а если она выключена, то сама работать не будет, о чем будет выдано соответствующее предупреждение:
Вот так запускается репликация для выключенной ВМ:
Во время offline-репликации виртуальную машину нельзя включить, а ее диски будут залочены. Кроме того, вы не сможете отменить эту операцию. Поэтому при нажатии Sync Now будет выведено вот такое предупреждение:
Обычно offline-репликация используется для создания гарантированной копии ВМ на другой площадке (например, при переезде датацентра или частичном восстановлении инфраструктуры на другом оборудовании). Ну или если у вас была настроена online-репликация, а вы выключили ВМ, то в конце нужно сделать еще ручной Sync Now.
Также в VMware vSphere 6.0 было сделано существенное улучшение в производительности процесса репликации. Если раньше идентичность копий основного диска и реплики сверялась только на базе контрольных сумм (все данные диска надо прочитать - а это затратно по вводу-выводу и CPU), то теперь иногда используются данные о конфигурации виртуального диска на базе регионов. Например, если на исходном диске есть регионы, которые не были аллоцированы на целевом диске, то репликация это отслеживает и передает данные в эти регионы на целевое хранилище. Это работает значительно быстрее вычисления контрольных сумм.
Но такая оптимизация работает не для всех типов виртуальных дисков, а только для Lazy zeroed thick disks, thin disks и vSAN sparse disks и только на томах VMFS. Тома NFS, тома VVols, а также диски типа Eager zeroed thick не предоставляют информации об аллокации регионов, поэтому для них оптимизация работать не будет. Более подробно об этом написано тут.
Дункан опубликовал в своем блоге интересный пост про то, как кластер VMware Virtual SAN размещает данные больших VMDK-дисков на малых физических дисках. Напомним, что Virtual SAN оперирует понятием дисковых страйпов (disk stripes), на которые разбивается дисковый объект (в частности, виртуальный диск VMDK является дисковым объектом). Это как кирпичики Virtual SAN, на уровне которых работает кластер.
Давайте взглянем на картинку:
Здесь мы видим вот что: на уровне политики (VSAN Policy) задан параметр "Number of failures to tolerate" (подробнее об этом мы писали тут) равный 1. Это значит, что инфраструктура Virtual SAN может пережить отказ не более одного хоста.
Но также в рамках политики есть еще и параметр "Stripe Width" (он же "Number of Disk Stripes Per Object"), который позволяет разбить дисковый объект на два страйпа: stripe/a и stripe/b, причем обратите внимание, что реплика дискового объекта может храниться на разных хост-серверах (а может и на одном - это вы никак не сможете отрегулировать, гарантируется лишь, что это будут 2 разных hdd-диска). Так что, если у вас маленькие диски, а виртуальные машины с большими дисками VMDK, то задайте этот параметр вот здесь:
Кстати говоря, объекты разбиваются на страйпы не только при заданном Stripe Width, но и автоматически, когда размер VMDK превышает 256 ГБ.
Как некоторые из вас знают, компания VMware в последний год активно двигает продажи не просто платформы VMware vSphere, а ее "расширенной" версии со средствами мониторинга и управления (есть даже пакеты Acceleration Kit с обязательной добавкой Operations Management). По-сути, vSphere with Operations Management - это vSphere плюс vRealize Operations Standard.
Помните про такой сайт VMware Walkthroughs, где собраны обучающие интерактивные материалы, с помощью которых можно виртуально "пощупать" продукты VMware, в частности vSphere и Virtual SAN? Так вот недавно этот ресурс пополнился материалами про vSphere with Operations Management.
Теперь всем желающим доступны материалы на следующие темы об Operations Management:
Компания Nutanix, производящая программно-аппаратные решения для создания кластеров хранилищ под виртуализацию, опубликовала интересный постер, где приведены основные командлеты PowerShell для управления этими системами:
Ну а вот тут собрано еще несколько интересных документов от Nutanix.
Не так давно мы писали о том, что компания VMware выпустила бета-версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры vSphere 6.0 Hardening Guide. На днях же вышла финальная версия этого документа. Надо отметить, что документ весьма сильно поменялся по структуре и содержанию:
Согласно записи в блоге VMware, в данной версии руководства были сделаны следующие позитивные изменения:
Сделан упор на автоматизацию воплощения рекомендаций через API, чтобы доставить меньше хлопот по ручному конфигурированию настроек. Приводятся конкретные команды PowerCLI и vCLI для исследования конфигураций и задания необходимых параметров.
В качестве рекомендуемого значения добавлен параметр "site-specific", что означает, что конкретная имплементация данной настройки зависит от особенностей инфраструктуры пользователя.
Появилась колонка с разносторонним обсуждением проблемы потенциальной уязвимости (с учетом предыдущего пункта).
Дается больше информации о потенциальных рисках - на что влияет данная настройка в итоге.
Кстати, вот полный список руководящих документов по обеспечению безопасности других продуктов компании VMware и прошлых версий VMware vSphere:
Ну и надо обязательно добавить, что VMware Configuration Manager теперь полностью поддерживает конфигурации из руководства vSphere 6 Hardening Guide. Более подробно об этом написано в блоге VMware Security.
Многие наши читатели интересуются, а есть ли утилиты, предназначенные специально для облачных инфраструктур. Например, которые позволяют оценить качество предоставления услуг сервис-провайдером? Да, есть такое, и одно из подобных средств - AppEnsure - как раз позволяет измерять время отклика для корпоративных приложений и текущую используемую пропускную способность.
Теперь это полноценный продукт, с платным и бесплатным изданиями, который позволяет анализировать качество предоставления услуг облаком (частным или публичным) и искать причину падения производительности приложений.
Вот возможности бесплатной версии AppEnsure:
Обнаружение приложений вашей инфраструктуры и их добавление в окружение мониторинга.
Автоматическое построение топологии зависимости компонентов вашего приложения.
Измерение по шагам (hop-by-hop) и полного (end-to-end) времени отклика, а также пропускной способности канала для каждого приложения.
Возможность предоставления диагностической информации при снижении пропускной способности или увеличении времени отклика.
Продукт AppEnsure (консоль и база данных) поставляется как готовый виртуальный модуль (VMware Virtual Appliance).
Доступны как серверные, так и десктопные агенты для ОС Windows/Linux (до 5 серверов в бесплатной версии).
Поддержка удаленных агентов (в другой сети или облаке по отношению к мастер-инсталляции).
Доступ к веб-порталу технической поддержки.
Сохранение данных в течение 24 часов (в платной версии - сколько угодно).
Вот так выглядит обнаруженная топология:
Так дэшборд приложения:
А вот так - общий дэшборд:
Ну и таблица сравнения изданий:
Загрузить бесплатную версию AppEnsure или попробовать платную версию продукта можно по этой ссылке.
В нескольких заметках мы освещали новости о продукте VMware Log Insight, который предназначен для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска.
Многие администраторы VMware vSphere знают, что такой продукт есть, на мало кто знает, зачем он реально нужен. Ну да, централизованно собирает логи, есть аналитика, но когда он может пригодиться? Поэтому приведем тут пример решения конкретной административной задачи с помощью VMware Log Insight, которую описал у себя в блоге Iwan Rahabok.
Итак, каждый из вас, я надеюсь, знает, что снапшоты виртуальных машин - это плохо (назовем их "snapshits"). Поэтому в большой инфраструктуре часто оказывается необходимым найти тех, кто снапшоты создает, а если он потом их удалил, то когда это было сделано.
Для начала создадим и удалим снапшот виртуальной машины. Это отобразится в списке последних задач vSphere Web Client:
Откроем консоль VMware Log Insight и перейдем в представление "Virtual Machine – Snapshots", как показано ниже:
Видим, что оба события были пойманы. Переключимся в представление Interactive Analytics (в верхнем меню):
Тут мы видим оба события на таймлайне. Расширим диапазон до 7 дней и добавим фильтр по строчкам "vmw_esxi_snapshot_operation". Видим записи лога о снапшотах:
Ну и переключимся на вкладку Field Table, где выберем параметр vc_username в качестве фильтра (если пользователь заходил из vCenter):
Ну и видим тут, что всеми этими делами занимался пользователь obi-wan.
На самом деле, с помощью Log Insight можно вытягивать очень много чего полезного, например, можно было бы составить фильтр так, чтобы показать виртуальные машины только по указанному шаблону именования.
Интересная история произошла тут между компаниями VMware и Nutanix. Инженеры и сейлы из VMware решили провести сравнение производительности программных отказоустойчивых кластеров на базе локальных хранилищ серверов VMware Virtual SAN и Nutanix. Создав тестовую конфигурацию и выбрав профиль нагрузки, компания VMware сделала тест в средах Virtual SAN и Nutanix.
Кстати, вот конфигурация тестового кластера хранилищ:
4 x Dell XC630-10 для Nutanix,
4 x Dell R630 для vSphere с кластером VSAN
2 x Intel E5-2690 v3 на сервер
12 ядер на процессор 2.6GHz, 256 ГБ памяти на сервер
Двухпортовый 10Gb Ethernet
1 x PERC H730 Mini на сервер
2 x 400GB Intel S3700 на сервер
6 дисков x 1TB 7200 RPM NL-SAS (Seagate) на сервер
Но тут спецы из VMware решили заглянуть в EULA Nutanix, а там написано (п. 2.1, подпункт e):
You must not disclose the results of testing, benchmarking or other performance or evaluation information related to the Software or the product to any third party without the prior written consent of Nutanix
То есть, публиковать результаты тестирования нельзя. Вот такой облом. А ведь VMware много раз ругали за то, что она сама запрещает публиковать результаты тестирования производительности с конкурирующими продуктами. Это также зафиксировано в EULA:
You may use the Software to conduct internal performance testing and benchmarking studies. You may only publish or otherwise distribute the results of such studies to third parties as follows: (a) if with respect to VMware’s Workstation or Fusion products, only if You provide a copy of Your study to benchmark@vmware.com prior to distribution; (b) if with respect to any other Software, only if VMware has reviewed and approved of the methodology, assumptions and other parameters of the study (please contact VMware at benchmark@vmware.com to request such review and approval) prior to such publication and distribution.
VMware, конечно, утверждает, что у нее условия мягче, но по-сути у них написано одно и то же. Публиковать результаты тестов без разрешения нельзя. А разрешение, конечно, никто не даст, так как опубликовать конкуренты захотят только, если у них все работает лучше и быстрее.
Поэтому VMware ничего не оставалось, как опубликовать результаты только своих тестов и разбить их по профилям нагрузки, отметив, что желающие сравнить пользователи сами могут убедиться, что Nutanix работает медленнее, проведя тесты самостоятельно.
Надо также отметить, что VMware отправила запрос на публикацию в Nutanix, на что получила ожидаемый ответ - публиковать нельзя.
Ну и, собственно, результаты тестирования для кластера Virtual SAN:
На прошлой неделе компания VMware без особого шума выпустила обновление своей платформы виртуализации настольных ПК Horizon View 6.1.1. Несмотря на то, что обновление номера версии произошло только в третьем разряде, новых возможностей появилось весьма немало.
Посмотрим на новые функции и улучшения продукта:
Client Drive Redirection
Пользователи теперь могут шарить папки и приводы своих локальных клиентских ПК для удаленных десктопов и приложений. Client Drive Redirection поддерживается для VDI-десктопов и для RDS-десктопов и приложений. Данная фича поддерживается для ОС Windows и в экспериментальном режиме для Mac OS X. Будьте внимательны - файлы, передаваемые по сети, не шифруются!
Десктопы с ОС Linux на базе Horizon 6
Наконец-то. Теперь можно развернуть инфраструктуру View Horizon на базе виртуальных ПК с ОС Linux. Можно поставить View Agent for Linux, где при установке можно задать родительские машины или шаблоны с ОС Ubuntu, RHEL, CentOS или NeoKylin и развернуть пулы виртуальных ПК через View Administrator. Для виртуальных машин Linux поддерживается технология vDGA (на данный момент только для адаптеров NVIDIA GRID GPU). Некоторые возможности, такие как SSO, автоматическое развертывание виртуальных ПК, HTML Access и перенаправление локальных дисков не поддерживаются в этой версии. Больше подробностей тут.
Serial Port Redirection
Теперь пользователи могут перенаправить последовательный порт (COM) RS232 или адаптеры типа USB-to-Serial. Через эти порты можно пробросить старые принтеры, сканеры штрих-кодов и другие legacy или промышленные устройства.
Поддержка Windows Media Multimedia Redirection (MMR) для виртуальных ПК на базе RDS
Ранее эта фича поддерживалась только для виртуальных десктопов VDI, на которых мог работать только один пользователь. Больше подробностей можно узнать в разделе System Requirements for Windows Media MMR, в секции Setting Up Desktop and Application Pools документа View guide.
Поддержка HTML Access для приложений Hosted Apps
Теперь пользователи могут получать доступ к виртуализованным приложениям Hosted Apps через веб-клиенты HTML Access. Чтобы использовать эту возможность нужно скачать и установить HTML Access installer. Более подробно об этом рассказано в разделе To use HTML Access with Hosted Apps.
Скачать VMware View Horizon 6.1.1 можно по этой ссылке.
Рано или поздно любой администратор VMware vSphere сталкивается с проблемой разросшихся тонких дисков виртуальных машин, которые увеличиваются неизбежно по своей природе (при удалении файлов в гостевой ОС блоки не обнуляются и не отдаются обратно на хранилище с уменьшением VMDK).
Но, во-первых, SVMotion есть не у всех (так как в начальные издания vSphere эта технология не входит), а, во-вторых, есть более простой способ. Итак:
1. Давайте сначала "раздуем" исходный тонкий диск с помощью утилиты sdelete.
Было (18,74 ГБ):
Запускаем в гостевой ОС Windows утилиту:
sdelete -c
Стало (41,8 ГБ):
2. Очищаем удаленные блоки в гостевой ОС, заполняя их нулями.
Для этого запустим команду:
sdelete -z
3. Уменьшаем размер виртуального диска с помощью утилиты vmkfstools.
Делается это с помощью ключа -K (можно также использовать ключ --punchzero) в консоли сервера ESXi:
vmkfstools -K Test.vmdk
Вот и все, смотрим на получившийся размер:
Надо отметить, что утилита vmkfstools, запущенная с ключом -K, еще и может преобразовать обычный диск (zeroedthick или eagerzeroedthick) в thin disk с вычищением нулевых блоков и, соответственно, уменьшением размера vmdk.
На днях компания VMware запустила публичную бету решения vROps Management Pack for Virtual SAN, которое позволяет отслеживать состояние и параметры кластера VMware Virtual SAN, производить аналитику и траблшутинг, а также Healthcheck инфраструктуры отказоустойчивых хранилищ:
По-сути, это vRealize Operations Manager, прикрученный к VSAN, который позволяет нам следить за кластером хранилищ и своевременно решать проблемы, которые возникают в процессе эксплуатации.
Посмотрим на возможности vROps Management Pack for Virtual SAN:
Возможность контролировать несколько кластеров Virtual SAN
Поддержка дэшбордов для Cluster Insights, Device Insights, Entity usage, heat maps и т.п.
Информация о механизме SMARTS (отчеты и алертинг)
Обнаружение проблем APD (All Path Down) и PDL (Physical Device Loss). Мы писали об этом тут
Обнаружение несовместимости протоколов доступа к хранилищам
Описание сбоев программного и аппаратного обеспечения, а также конкретные рекомендации по их устранению
Мониторинг SSD (в дополнение к CPU, памяти и т.п.)
Мониторинг агрегированных IOPS
Отслеживание обновлений ПО
Решение проблем с некорректной презентацией LUN
Решение проблем со снапшотами, которые разрастаются и заполоняют хранилища
Возможность отключения LUN после ошибки администратора
В документе рассмотрено тестирование производительности 12-узлового кластера Virtual SAN на базе серверов Supermicro в рамках следующей логической архитектуры:
Подробная конфигурация хостов:
В целом инфраструктура тестирования выглядела так:
Для тестов использовалось средство Login VSI (о нем мы уже много писали), которое поставляется вместе с методологией тестирования:
Сводные результаты тестов:
Для получения более подробной информации о результатах по каждому тесту, используемых сценариях и конфигурациях обращайтесь к документу. Все 38 страниц полны картинок, графиков и табличек с цифрами - док составлен очень по делу. Для тех, кто планирует VDI на базе Virtual SAN очень полезный референс, как в плане архитектуры, так и в плане производительности.
На днях компания VMware выпустила интересный открытый документ "Virtualizing Microsoft Applications on VMware Virtual SAN", в котором описываются результаты тестирования бизнес-критичных приложений Microsoft в кластере отказоустойчивых хранилищ VMware VSAN.
В документе рассматривается стрессовое тестирование следующих приложений, работающих в кластере Virtual SAN, состоящем из 8 узлов:
Microsoft Exchange 2013 с поддержкой Database Availability Groups (DAG)
Microsoft SQL Server 2014 с включенными AlwaysOn Availability Groups (AAG)
Microsoft SharePoint 2013 как фронтэнд баз данных
Для теста использовалась такая конфигурация серверов:
ESX host CPU - 2 x Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz 10C (60 GHz)
Результаты тестирования первого узла с ролью Mailbox средствами Jetstress:
Результаты тестирования второго узла с ролью Mailbox:
Результаты теста Load Generator:
Архитектура сервисов Microsoft SQL Server с технологией защиты данных Always On:
Для тестирования SQL Server использовался инструмент DVD Store. Конфигурация виртуальных машин:
Результаты тестов DVD Store.
Ну и в заключение - сводные результаты тестирования:
В итоге утверждается, что приложения Microsoft уровня Tier 1 прекрасно себя чувствуют в кластере VMware Virtual SAN, и их быстродействие мало чем отличается от ситуации, если бы на бэкэнде были аппаратные SAN/NFS-массивы.
Мы много писали про решение для создание отказоустойчивых хранилищ на базе локальных дисков VMware Virtual SAN 6.0 (еще вот тут и тут). Продукт этот достаточно дорогой и подходит, в основном, для средних/больших компаний или очень крутых маленьких компаний. Однако у вас есть возможность протестировать его в течение 6 месяцев абсолютно бесплатно, став как бы членом VMware User Group:
Заполнив форму из трех полей, вы попадете на страницу технической информации о продукте, а через некоторое время получите по почте лицензию VMware Virtual SAN на 6 месяцев на 6 процессоров для трех хост-серверов VMware ESXi, которые будут узлами кластера хранения.
Кстати, все нужные документы про VMware Virtual SAN:
Многие из вас знают, что у VMware есть виртуальный модуль vCenter Server Appliance (vCSA), который можно использовать в качестве виртуального управляющего сервера для инфраструктуры vSphere. Для многих это просто "черный ящик", к которому можно подключиться с помощью vSphere Client или Web Client и рулить хостами и виртуальными машинами.
Давайте немного заглянем внутрь. Если мы откроем консоль vCSA, то увидим нечто подобное консоли VMware ESXi:
Не забывайте, что это не только сервер vCenter, но еще и Linux, в который можно залезть. Сделать это можно в локальной консоли, нажав комбинацию клавиш Alt+F1, но лучше нажать <F2> и включить доступ к vCSA по SSH. Также это можно сделать и в vSphere Web Client в следующем разделе:
System Configuration / Nodes / Manage / Settings / Access
Далее можно будет подключиться к хосту vCSA по SSH под аккаунтом root и смотреть, что там внутри:
Это оболочка виртуального модуля vCSA. Чтобы посмотреть API-функции, которые можно использовать для настройки модуля, введите команду:
help api list
Интерфейс vCSA содержит несколько стандартных плагинов (посмотреть их можно командой help pi list), реализующих стандартные средства, такие как ps, top или vimtop (это своего рода esxtop, но только для vCSA). Запустим, кстати, vimtop:
Здесь наглядно видно, какой сервис vCenter или самой ОС отъедает ресурсы. Более подробно об этом средстве написано вот тут.
Чтобы включить доступ к bash-консоли линукса нужно написать:
shell.set --enabled true
Далее просто запустите ее командой shell.
Кстати, тут есть хинт - по умолчанию для bash-консоли установлен таймаут 1 час, поэтому оттуда вас будет постоянно выбрасывать. Увеличить его можно следующей командой (отключить нельзя, поэтому указываем максимальное время в секундах на 68 лет - только учтите, что оно сохраняется после перезагрузки):
shell.set --enabled true --timeout 2147483647
Чтобы закинуть на vCSA какие-нибудь скрипты или другие файлы, воспользуемся утилитой WinSCP. Но при попытке соединения мы получим вот такой отлуп:
Все логично - WinSCP ожидает стандартный shell линукса, а не то, что показано на первом скрине. Поэтому надо сделать так: в настройках Win SCP выставить протокол SFTP (вместо SCP), а в Advanced Settings ввести "shell /usr/lib64/ssh/sftp-server" (без кавычек) для использования SFTP-сервера.
Также можно временно заменить дефолтный шел модуля на bash с помощью команды:
chsh -s /bin/bash
И потом можно просто соединяться через WinSCP в обычном режиме. Чтобы вернуть шел модуля, напечатайте:
chsh -s /bin/appliancesh
Также обратимся к настройке устаревания и сложности паролей. Многих эта тема волнует и бесит, когда заставляют создавать пароли, не соответствующие чьим-то мудацким правилам. Ну и, конечно же, по дефолту включено устаревание пароля в 90 дней.
Отключить все это можно через Web Client в разделе Administration / Single Sign-On / Configuration / Policies / Password Policy (не забудьте зайти под SSO админом):
Для отключения устаревания установите значение 0. Также это можно сделать командой:
chage -M -1 root
Для изменения политики сложности пароля вам нужно отредактировать следующий файл:
/etc/pam.d/common-password
Кстати, если вы все же решите оставить устаревание пароля, то с помощью следующей команды можно настроить отсылку предупреждения об устаревании пароля на электронную почту:
В новой версии VMware vSphere 6 для хостов ESXi было сделано следующее нововведение в плане безопасности - теперь после 10 неудачных попыток входа наступает блокировка учетной записи (account lockout), которая длится 2 минуты.
Этот эффект наблюдается теперь при логине через SSH, а также при доступе через vSphere Client (ну и в целом через vSphere Web Services SDK). При локальном доступе через DCUI (напрямую из консоли) такого нет.
Сделано это понятно зачем - чтобы никто не перебирал пароли рута брутфорсом.
Отрегулировать настройки блокировки можно в следующих параметрах Advanced Options хоста ESXi:
Security.AccountLockFailures - максимальное число попыток входа, после которого аккаунт блокируется. Если поставить 0, то функция локаута будет отключена.
Security.AccountUnlockTime - число секунд, на которое блокируется аккаунт.
Многие из вас знакомы с продуктом VMware Site Recovery Manager, который позволяет построить катастрофоустойчивую виртуальную инфраструктуру за счет репликации виртуальных машин на хосты резервной площадки, помещения или стойки. Как известно, VMware SRM может использовать два типа репликации:
Array Based Replication - репликация уровня массива, котора требует наличия соответствующего типа дискового массива на основной и резервной площадке, канала репликации, а также, собственно, программного продукта, который реализует эту репликацию. Как правило, данный тип представляет собой синхронную репликацию с возможностью быстрого переключения на резервную инфраструктуру в случае сбоя без потери данных.
vSphere Replication - репликация уровня массива, которая не требует ничего кроме сетевого соединения между площадками, но она происходит в асинхронном режиме, а значит возможна потеря данных в случае сбоя.
Давайте попробуем рассмотреть особенность обоих методов репликации в таблице:
Категория
Репликация уровня массива (Array-Based Replication)
Репликация уровня хоста ESXi (vSphere Replication)
Тип репликации
Репликация на уровне массива по выделенному каналу
Репликация на уровне хостов ESXi по сети
Минимальная и максимальная потеря данных (требования к контрольной точке восстановления - RPO)
От 0 до максимально определенной вендором массива.
От 15 минут до 24 часов
Максимальное число ВМ
До 5 000 защищенных ВМ и до 2 000 машин, одновременно восстанавливаемых с одного vCenter
До 2 000 ВМ (и защищаемых, и одновременно восстанавливаемых) на один vCenter
Порядок записи данных на резервной инфраструктуре (Write order fidelity)
Write order fidelity поддерживается для нескольких ВМ в пределах одной consistency group
Write order fidelity поддерживается для дисков VMDK одной ВМ. Для нескольких ВМ одной consistency group это не гарантируется.
Уровень репликации
Репликация на уровне LUN/VMFS или томов NFS
Репликация на уровне виртуальной машины
Метод настройки репликации
Репликация настраивается на стороне дискового массива средствами продуктов вендора
Репликация настраивается и управляется через vSphere Web Client
Тип дискового массива
Необходим массив с поддержкой репликации на обеих площадках (например, EMC RecoverPoint, NetApp vFiler, IBM SVC и т.п.)
Любое хранилище, включая локальное хранилище (в случае наличия в списке vSphere HCL)
Тип хранилища и протокол
Только для хранилищ с протоколами FC, iSCSI или NFS
Поддержка ВМ на локальном хранилище, VSAN, FC, iSCSI или NFS
Стоимость решения
Относительно высокая. Нужна лицензия на функции Replication и Snapshot.
vSphere Replication включена в издание vSphere Essentials Plus 5.1 и более высокие
Развертывание
Необходимо привлечение администраторов хранилищ и, возможно, сетевых администраторов
Администратор vSphere может настроить самостоятельно
Консистентность данных на уровне приложений
В зависимости от дискового массива и производителя консистентность приложений может поддерживаться средствами агентов в гостевой ОС ВМ
Поддержка VSS и Linux file system application consistency
Возможность репликации ВМ, защищенных технологией Fault Tolerance (FT)
Можно реплицировать FT ВМ, но при восстановлении FT будет выключена. Также не поддерживаются ВМ с несколькими vCPU.
Репликация ВМ с включенной FT не поддерживается
Возможность репликации выключенных ВМ, шаблонов, связанных клонов (Linked clones), ISO-образов
Все эти объекты (как и любые другие файлы на виртуальных хранилищах) можно реплицировать на уровне томов VMFS
Можно реплицировать только запущенные виртуальные машины.
Поддержка томов RDM
Тома RDM в режиме физической и виртуальной совместимости могут быть реплицированы
Только тома RDM в режиме виртуальной совместимости (virtual mode)
Поддержка кластеров MSCS
Да, машины, являющиеся частью кластера MSCS, можно реплицировать
Нет, репликация ВМ в составе MSCS-кластера не поддерживается (нельзя реплицировать диски в режиме записи с нескольких хостов - multi-writer)
Поддержка виртуальных сервисов vApp
Да, полностью поддерживается
Нет, объекты vApp реплицировать нельзя. Можно реплицировать машины виртуальных сервисов по отдельности, а потом вручную собрать из них vApp на резервной площадке.
Поддержка версий хостов vSphere
Поддерживаются версии vSphere 3.5-6.0
Только начиная с vSphere 5.0 и более поздние версии
Несколько точек восстановления (Multiple point in time - MPIT)
Снапшоты Multiple point in time и возможность отката к ним поддерживается только отдельными производителями (например, в продукте EMC RecoverPoint)
До 24 точек восстановления
Снапшоты
Поддержка репликации ВМ со снапшотами в неизменяемом виде
Поддержка репликации ВМ со снапшотами, на на целевой площадке они будут удалены (ВМ будет в последнем состоянии, без снапшотов)
Реакция на сбой хоста
Не влияет, так как репликация идет независимо на уровне дискового массива
При сбое хоста, машина перезапускается на другом ESXi и вызывается полная ресинхронизация ВМ (больше подробностей в vSphere Replication FAQ)
Также при использовании репликации уровня дискового массива рекомендуется прочитать документацию к соответствующему компоненту SRA (storage replication adapter).
Если вкратце, то компоненты vCenter предлагается защищать с помощью следующих решений:
1. Кластер высокой доступности VMware HA и сервис слежения за vCenter - Watchdog.
Сервис HA автоматически перезапускает виртуальную машину с vCenter отказавшего сервера на другом хосте кластера, а сервис Watchdog (он есть как на обычном vCenter, так и на vCenter Server Appliance) следит за тем, чтобы основная служба vCenter работала и отвечала, и запускает/перезапускает ее в случае сбоя.
2. Защита средствами VMware Fault Tolerance.
Теперь технология VMware FT в VMware vSphere 6.0 позволяет защищать ВМ с несколькими vCPU, поэтому данный способ теперь подходит для обеспечения непрерывной доступности сервисов vCenter и мгновенного восстановления в случае сбоя оборудования основного хоста ESXi.
Компания VMware предоставляет специализированный API, который могут использовать партнеры для создания решений, защищающих приложения в гостевой ОС, в частности, сервис vCenter. Одно из таких приложений - Symantec ApplicationHA. Оно полностью поддерживает vCenter, имеет специализированного агента и перезапускает нужные службы в случае сбоя или зависания сервиса.
4. Средства кластеризации на уровне гостевой ОС (с кворумным диском).
Это один из древнейших подходов к защите сервисов vCenter. О нем мы писали еще вот тут.
Для организации данного типа защиты потребуется основная и резервная ВМ, которые лучше разместить на разных хостах vCenter. С помощью кластера Windows Server Failover Clustering (WSFC) организуется кворумный диск, общий для виртуальных машин, на котором размещены данные vCenter. В случае сбоя происходит переключение на резервную ВМ, которая продолжает работу с общим диском. Этот метод полностью поддерживается с vCenter 6.0:
Кстати, в документе есть пошаговое руководство по настройке кластера WSFC для кластеризации vCenter 6.0 (не забудьте потом, где его искать).
Ну и в заключение, сводная таблица по функциям и преимуществам приведенных методов:
Далее идет описание средств высокой доступности в Enterprise-инфраструктуре с несколькими серверами vCenter, где компоненты PSC (Platform Services Controller) и vCenter разнесены по разным серверам. Схема с использованием балансировщика:
Обратите внимание, что для PSC отказоустойчивость уже встроена - они реплицируют данные между собой.
Та же схема, но с кластеризованными серверами vCenter средствами технологии WSFC:
Использование географически распределенных датацентров и сервисов vCenter в них в едином домене доступа SSO (Single Sign-On) за счет технологии Enhanced Linked Mode (каждый сайт независим):
То же самое, но со схемой отказоустойчивости на уровне каждой из площадок:
Ну и напоследок 2 дополнительных совета:
1. Используйте Network Teaming для адаптеров vCenter (физических или виртуальных) в режиме отказоустойчивости, подключенные к дублирующим друг друга сетям.
2. Используйте Anti-affinity rules кластера HA/DRS, чтобы основная и резервная машина с vCenter не оказались на одном хосте VMware ESXi.
Да, и не забывайте о резервном копировании и репликации виртуальной машины с vCenter. Сделать это можно либо средствами Veeam Backup and Replication 8, либо с помощью VMware vSphere Replication/VMware vSphere Data Protection.
RSS
