Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4340 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Вышел VMware vCenter Server 6.5 Update 1b

Системы хранения данных NetApp в 2017 году.


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

Системы хранения данных, являясь основой стабильного функционирования любого предприятия, должны соответствовать параметрам доступности, надежности, безопасности и удовлетворять потребности бизнеса компании. Благодаря таким важным характеристикам СХД, как унифицированность, производительность и масштабируемость, затраты на них сегодня занимают одно из центральных мест в бюджете и составляют в среднем 20–25 % всех расходов. В этой статье мы рассмотрим решения NetApp как наилучшей системы хранения данных для современной компании.

NetApp: более 20 лет инноваций

Для начала предлагаем вспомнить, как развивалась NetApp в исторической перспективе, уделив внимание наиболее значимым моментам.

1992 г. Компания вводит в индустрию систем хранения данных абсолютно новые технологии, представляющие в совокупности законченное решение по хранению данных Network Appliance. На тот момент это была всего лишь файловая шара для Linux, куда позже добавили RAID 4, оптимизацию записи, организацию хранения данных WAFL, поддержку технологии Redirect on Wright (ROW), которая позволяет создавать снимки, не влияя на производительность. С тех пор линейка развивается эволюционно.

1995–1996 гг. Компания выпускает первый мультипротокольный сторадж, представляя технологию файлового доступа для Linux- и Windows-серверов с использованием протоколов SMB и NFS. А после реализует репликацию и поддержку файлового доступа поверх блочного, представляя унифицированную систему хранения данных. С тех пор NetApp пропагандирует консолидацию различных нагрузок на одну СХД и инвестирует в разработку технологий, повышающих эффективность хранения данных.

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


Таги: IT-Grad, NetApp, Hardware, Enterprise

Как выбрать дисковый контроллер для VMware vSAN?


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

Дункан Эппинг дает простую рекомендацию - надо брать один из самых недорогих поддерживаемых контроллеров, который имеет большую глубину очереди (Queue Depth). Например, часто в рекомендациях для vSAN можно встретить контроллер Dell H730, который является весьма дорогим устройством, если брать его на каждый сервер.

Но его не обязательно покупать, достаточно будет дискового контроллера Dell HBA 330, который и стоит дешевле, и глубину очереди имеет в 10 раз больше, чем H730 (хотя оба они соответствуют требованиям vSAN). Да, у H730 есть кэш на контроллере, но он в данном случае не требуется. Лучше использовать интерфейс NVMe для подключения отдельного SSD-кэша, не затрагивающего RAID-контроллеры (его нужно размещать как можно ближе к CPU).

Поэтому итоговая рекомендация по выбору дискового контроллера для кластеров vSAN проста - берите любое недорогое устройство из списка совместимости vSAN Compatibility Guide, но с хорошей глубиной очереди (например, HP H240), а на сэкономленные деньги отдельно организуйте кэш на базе NVMe.


Таги: VMware, SSD, Hardware, vSAN, NVMe, Storage

Каких продуктов больше не будет в следующих (через одну) версиях VMware vSphere?


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

1. VMware vCenter Server for Windows.

Да, нетленная классика, продукт, являвшийся основным решением для управления платформой VMware vSphere, уходит в прошлое. На смену ему придет полнофункциональный виртуальный модуль VMware vCenter Server Appliance (vCSA) - готовая виртуальная машина на базе Linux, предоставляющая все необходимые сервисы vCenter. vCSA был анонсирован еще в версии vSphere 5.0 (а это было аж 6 лет назад) и с тех пор показал себя как надежное средство управления виртуальной инфраструктурой.

Мы уже писали о том, что vCSA позиционируется как главный инструмент управления vSphere, а сама VMware выпускает рекомендации по миграции на vCSA с обычного vCenter. К эксклюзивным преимуществам vCSA относятся такие возможности, как бэкап и восстановление на уровне файлов, унифицированная процедура обновления, нативные функции vCenter High Availability и существенное опережение обычного vCenter в плане производительности.

Напомним, что vCSA построен на базе операционной системы Photon OS и базы данных vPostgres, что позволит VMware поддерживать весь стек решения (а не только отдельные сервисы, как для Windows). Пользователи любят vCSA за простоту развертывания и обновлений.

Более подробно о снятии с производства vCenter Server for Windows написано здесь. Следующий релиз vSphere еще будет содержать vCenter Server for Windows, но это будет последний его мажорный релиз.

2. VMware vSphere Web Client.

О том, что Web Client скоро прикажет долго жить мы пишем по нескольку раз в месяц, да что-то он никак не умрет. На данный момент версия vSphere Client 3.19, построенная на базе технологии HTML 5, имеет около 90% всего функционала Web Client, но все еще не дотягивает до полноценной версии (вот таблица отличий функционала).

Web Client уходит по понятным причинам - технология Flash, на которой он построен, уходит в небытие (об этом объявила и сама Adobe). В vSphere 6.5 Update 1, который вышел недавно, уже присутствует свежая версия vSphere Client, а в следующем мажорном релизе vSphere будет поставляться его полноценная релизная версия. А вот Web Client в следующем релизе появится уже в последний раз, а через один релиз его уже исключат из дистрибутива платформы, поэтому нужно осваивать vSphere Client уже сейчас.

Более подробно о снятии с производства Web Client написано здесь.

3. Интерфейс vmkLinux APIs.

Помимо списания vCenter и Web Client, компания VMware также убирает интерфейс vmkLinux API, который уже устарел, и вместо которого используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5.

vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов уходит в прошлое.

В следующем релизе vSphere модель vmkLinux API еще будет присутствовать, но это будет последнее большое обновление, которое будет ее поддерживать. Нативные драйвера вполне справляются со всеми задачами для большинства брендового оборудования, однако некоторое количество непопулярного железа перестанет работать. Надо быть к этому готовым.

Более подробно об отказе от vmkLinux API написано здесь.


Таги: VMware, vSphere, vCenter, vCSA, Web Client, Client, Linux, Hardware

VMware vSAN Sizer - утилита для подбора оборудования и расчета объема хранилищ под кластеры vSAN.


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

VMware vSAN Sizer доступен по адресу: https://vsansizer.vmware.com/

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

На первом этапе нам показывают, сколько нужно серверов и неразмеченного хранилища (Raw Storage):

Ниже мы видим технические характеристики каждого из хостов ESXi:

Ну а в рамках дополнительной информации можно вывести параметры дисковых групп (кэш и емкость хранения). В моем случае это 2 дисковых группы:

В утилите VMware vSAN Sizer расположена ссылка на расширенную версию, которая доступна для партнеров, но когда я зашел под партнерским аккаунтом, то увидел там только пустую белую страницу с шапкой меню.


Таги: VMware, vSAN, Sizing, VMachines, Storage, Hardware

Использование кластеров VMware HA/DRS с разными версиями ESXi.


Спустя 8 лет, опять поднимем тему использования кластеров VMware HA/DRS, в которых, по каким-либо причинам, оказались разные версии хост-серверов VMware ESXi. Такой режим работы кластеров допускается со стороны VMware, но при определенных условиях.

Первая и самая важная вещь - совместимость виртуального аппаратного обеспечения виртуальных машин (Virtual Hardware Version), которое увеличивает свою версию с каждым мажорным релизом ESXi. Правило тут простое - более новые версии ESXi могут запускать и исполнять виртуальные машины более старых версий, а вот старые хосты ESXi более новое для себя "виртуальное железо" не запустят.

Данный момент проясняет табличка из KB 2007240:

Обратите внимание, что, например, ВМ с версией HW 11 вы не запустите на ESXi 5.5. Поэтому выход такой - не обновлять старое виртуальное аппаратное обеспечение виртуальных машин, даже если они переехали за счет vMotion на хосты с более новой версией HW.

Второй момент - VMware Tools. Тут уже проще - старую версию тулзов можно эксплуатировать на новых хостах, как и новую на старых - обратная совместимость тоже есть. Убедиться в этом можно с помощью онлайн-утилиты VMware Product Interoperability Matrices, где в поле "Select a Solution" надо выбрать VMware Tools, а в поле "Add Platform/Solution" - платформу VMware vSphere Hypervisor (ESXi):

Но обратная совместимость тоже не бесконечная - VMware Tools версии 10.1.5, как мы видим, не получится использовать на VMware vSphere 5.1 Update 3.

Кстати, чтобы обновить VMware Tools, можно переместить ВМ с помощью vMotion на хост ESXi с более высокой версией и выбрать пункт "Install/Upgrade VMware Tools" в vSphere Web Client.

Второй способ обновления VMware Tools - это просто скачать их по ссылке с официального репозитория для вашей гостевой ОС:

https://packages.vmware.com/tools/esx/index.html

Ну и третий, заключительный, но самый важный момент при использовании смешанных кластеров (VMware их называет mixed clusters) - это возможности VMware HA, DRS, FT и прочих функций, которые предоставляет соответствующая версия ПО от VMware.

Например, в версии vSphere 6.5 появилось много нового с точки зрения технологии HA (к примеру, механизм Admission Control стал рассчитывать параметры для несбалансированных кластеров автоматически).

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


Таги: VMware, Cluster, vSphere, ESXi, VMachines, Tools, Hardware, Compatibility

Обновления кастомных OEM-образов VMware ESXi (Cisco, Dell, HPE) и визуализация полученных различий.


Многие пользователи виртуальной инфраструктуры VMware vSphere часто используют кастомизированные образы гипервизора VMware ESXi, который распространяется OEM-производителями оборудования, например, HP. Эти образы включают в себя специфические драйвера устройств, которые, зачастую, отсутствуют в стандартном комплекте поставки ESXi (это и понятно, так как нельзя поддерживать все устройства всех производителей в одном образе).

Между тем, многие администраторы обновляют такие образы достаточно редко - иногда по полгода ждут пока OEM-вендор выпустит очередную версию образа и накатывают его. Но ведь бывают критические обновления безопасности ESXi, которые нужно установить как можно скорее. Для этого нужно знать, как выглядит процедура обновления кастомного образа vSphere.

Во-первых, нужно понимать, что основные номера билдов и даты релиза гипервизора указаны в статье KB 2143832. А патчи в виде VIB-пакетов можно скачать с портала MyVMware здесь.

Во-вторых, есть утилита PowerCLI Image Builder (о ней мы писали вот тут), которая позволяет поддерживать актуальное состояние образа ESXi с точки зрения последних обновлений, но в то же время сохранять специфический контент кастомных образов.

Ну и, в-третьих, для тех, кто умеет пользоваться утилитой, есть простая команда, которая позволяет склонировать существующий профиль образа и обновить его пакеты, накатив последние патчи ESXi:

Set-ESXImageProfile $ClonedProfile -SoftwarePackage (Get-ESXSoftwarePackage -Newest)

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

Итак, первый скрипт - esxi-image-creator.ps1 - представляет собой обертку к Image Builder и дает некоторые дополнительные возможности, которые часто требуются для кастомных образов ESXi. Например, он позволяет монтировать depot-файлы и включать или исключать VIB-пакеты из состава образов. Также там есть такие расширенные настройки, как указание билдов по датам выпуска, а не по номерам и т.п. Итоговый образ можно собрать в формате ISO или ZIP.

Второй скрипт - esxi-image-comparator.ps1 - показывает различия между двумя профилями образов ESXi. Эти различия можно показать в консоли или графическом интерфейсе, а также экспортировать в CSV-файл для последующего анализа.

Как видно из картинки, в процессе работы скрипта можно в интерактивном режиме включать или исключать профили для сравнения.

Вот пример использования утилиты при обновлении кастомного образа Cisco для ESXi 5.5 (обновление U3b от декабря 2015) с последними патчами VMware и обновленными драйверами Cisco для устройств enic и fnic. При этом исключается VIB-пакет tools-light для оптимизации использования с Auto Deploy:

esxi-image-creator.ps1 -NewProfileName Cisco_5.5_OEM_with_express_patch_11 -WriteZip -Files Vmware-ESXi-5.5.0-3248547-Custom-Cisco-5.5.3.2-Bundle.zip,ESXi550-201703001.zip,enic-2.3.0.13-offline_bundle-5367272.zip,fnic_driver_1.6.0.28_ESX55-offline_bundle-4179470.zip

Ну а вот так выглядит результат сравнения обновленного профиля с исходным:

Еще один пример - включение в образ Dell ESXi 6.0U3, который уже был обновлен Dell, патча patch 7a (5224934) с пакетами VIB для NSX и удаление VMware Tools для использования с Auto Deploy.

esxi-image-creator.ps1 -NewProfileName Dell_6.0_OEM_5224934_with_NSX -Files VMware-VMvisor-Installer-6.0.0.update03-5224934.x86_64-Dell_Customized-A01.zip,vxlan.zip,vShield-Endpoint-Mux-6.5.0esx60-4885300.zip -Acceptance PartnerSupported

Результат:

А вот пример генерации образа для HPE Proliant, содержащего последние обновления из репозитория HP, а также последние обновления оффлайн-бандла ESXi 6.5:

Add-EsxSoftwareDepot http://vibsdepot.hpe.com/index-ecli-650.xml
esxi-image-creator.ps1 -LeaveCurrentDepotsMounted -NewProfileName ESXi_6.5.0d_with_HPE_drivers -Files ESXi650-201704001.zip -Acceptance PartnerSupported

Вот полученный результат:

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

Но зато вот такая команда позволит сформировать таблицу с отличиями каждого из релизов VMware ESXi:

Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxi-image-comparator.ps1 | Export-Csv all_profiles.csv

Мораль поста такова - нужно пользоваться, по-возможности, кастомными образами ESXi от OEM-производителей, но не забывать накатывать обновления (особенно security patches) от обычных образов VMware ESXi, создаваемых VMware.


Таги: VMware, ESXi, Update, HP, Cisco, Dell, Hardware, PowerCLI

Вышел кастомизированный образ HPE Customized ESXi May 2017.


Оказывается, еще в начале мая компания HP совместно с VMware выпустила кастомизированный образ гипервизора vSphere - HPE Customized ESXi May 2017, предназначенного для установки на серверы HP.

Этот релиз для многих администраторов является важным событием, так как прошлый кастомизированный образ HPE Custom ESXi от ноября 2016 года содержал в себе некоторые проблемы, касающиеся драйверов и работы с хранилищами (в частности, наблюдалась низкая скорость записи на локальные диски). Возможно, в этом релизе данные проблемы решены, по крайней мере новый набор драйверов должен улучшить некоторые вещи.

HPE Customized ESXi May 2017 доступен для скачивания по этой ссылке. Предыдущие образы (для более ранних версий гипервизора) можно также скачать с сайта VMware по этим ссылкам:

Номера билдов и их содержимое приведены вот в этом документе HPE (там же есть ссылки на соответствующие драйвера и офлайн бандлы ESXi). Ну а руководство по кастомизированным билдам HPE Custom ESXi находится вот тут.


Таги: HP, ESXi, Update, VMware, vSphere, Hardware, Storage, Bugs

Кейс от ИТ-ГРАД. Yota Devices: как облака в моделях IaaS и SaaS помогают разработчику YotaPhone.


Yota Devices — разработчик YotaPhone, первого в мире смартфона с двумя сенсорными экранами, один из которых всегда включен. Yota Devices — молодая быстрорастущая российская компания, которая за три года сумела не только с нуля разработать, запатентовать и довести до серийного производства принципиально новый тип смартфона, но и организовать его продажу более чем в 20 странах.

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

Рисунок 1. Офисы Yota Devices

Офисы Yota Devices расположены в Европе, Азии, США и на Ближнем Востоке. Штаб-квартира находится в Москве. В компании работают ведущие разработчики элементной базы и программного обеспечения из России, Финляндии и Китая. Читать статью далее->>

<>
Таги: IT-Grad, IaaS, Case, Hardware

Бесплатный вебинар: Производительность All-Flash конфигураций на дисках Intel SSD средствами решения StarWind HyperConverged Appliance.


Интересный вебинар проведет компания StarWind о производительности конфигураций серверов All-Flash на платформе решения для обеспечения отказоустойчивости хранилищ StarWind Virtual SAN: Get All-Flash Performance using Intel SSD and StarWind HyperConverged Appliance.

Вебинар пройдет 5 апреля в 20-00 по московскому времени.

Напомним, что у StarWind есть собственное решение для создания гиперконвергентной инфраструктуры на базе серверов Dell, гипервизора Microsoft Hyper-V, ПО для хранилищ StarWind Virtual SAN, резервного копирования Veeam Backup and Replication, а также средств управления 5nine Hyper-V Manager. Поставляется оно в виде готового к использованию программно-аппаратного комплекса.

Бонусом мероприятия является комплект для сборки минималистичного компа CanaKit Raspberry Pi 3 Ultimate Starter Kit - 32 GB Edition. Его получат два участника вебинара. Может быть, повезет именно вам - регистрируйтесь!


Таги: StarWind, Webinar, Hardware, Performance

Как узнать, поддерживает ли ваш I/O Adapter технологию VMware VVols.


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

Начнем с того, почему адаптер и хранилище вообще должны ее поддерживать. Все просто - для доступа к томам VVols используется специальный служебный LUN, реализуемый в виде Protocol Endpoint (PE). Когда обычный FC-адаптер соединяется с хранилищем VMFS, он использует путь к LUN на базе адресов WWN, который состоит из номера HBA-адаптера, номера контроллера и, конечно же, LUN ID. Это все выглядит как vmhbaAdapter:CChannel:TTarget:LLUN (например, vmhba1:C0:T3:L1).

В случае с VVols и луном PE это уже работает несколько по-другому: появляются так называемые  Secondary LUN IDs, которые адресуются как саблуны девайсом PE (secondary level IDs, SLLID). Этот Administrative LUN на устройстве PE не имеет емкости, но адресует тома VVols, которые находятся уже непосредственно на хранилище.

Сервер vCenter получает эти Secondary LUN IDs через механизм VASA Provider, реализованный через одноименный API. Далее уже хост ESXi (а точнее его I/O-адаптер, например, HBA-адаптер) работает в виртуальными машинами (а вернее с томами VVols) через Secondary LUN IDs (их, кстати, может быть не 255 как у LUN ID, а намного больше).

Надо отметить, что средства резервного копирования на уровне LUN не могут напрямую обратиться к этим Secondary LUN IDs, так как работа с ними идет только через хост VMware ESXi.

Так вот стандартная SCSI-команда REPORT_LUNS не подходит для обнаружения административных LUN, которые в отличие от LUN с данными, не имеют емкости. Поэтому VMware подала предложения в комитет T-10, отвечающий за SCSI-протокол, чтобы внести в его спецификацию некоторые изменения:

Самый простой способ узнать, поддерживает ли ваш FC/NFS-адаптер адресацию Secondary LUN IDs - это пойти в список совместимости VMware HCL:

В списке Features вы должны увидеть пункт Secondary LUNID (Enables VVols). Выберите его и посмотрите результат:

Тут уже видна подробная информация о драйвере и фича SLLID.

Далее можно заглянуть в ваш vmkernel.log и посмотреть нет ли там следующих строчек:

Sanity check failed for path vmhbaX:Y:Z. The path is to a VVol PE, but it goes out of adapter vmhbaX which is not PE capable. Path dropped.

Если есть - понятное дело, VVols не поддерживаются. Ну а в консоли сервера VMware ESXi параметры HBA-адаптера можно проверить следующей командой:

esxcli storage core adapter list

В колонке Capabilities будет видна строчка Second Level Lun ID, если поддержка VVols у вашего адаптера есть:

На стороне хранилища вам нужно убедиться, что VASA Provider включен и поддержка фич PE для VVols функционирует. Далее выполните следующую команду, чтобы убедиться, что хост ESXi видит девайс PE (обратите внимание, что он видится как диск):

esxcli storage core device list –pe-only

Если вы видите в строчке Is VVOL PE значение true, то значит все ок, и вы можете развертывать виртуальные машины на базе томов VVols.


Таги: VMware, VVols, Hardware, Storage, SAN, SCSI

Интересный вебинар StarWind: "How to Get All-Flash Performance with Intel SSD and StarWind HyperConverged Appliance".


Весьма интересный вебинар скоро проведет компания StarWind, выпускающая лучший на рынке продукт Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V. На бесплатном онлайн-мероприятии "How to Get All-Flash Performance with Intel SSD and StarWind HyperConverged Appliance" сотрудники StarWind расскажут о том, как с помощью программно-аппаратного модуля StarWind HyperConverged Appliance построить надежную архитектуру хранения небольшого предприятия или филиала с наибольшей производительностью и максимальным уровнем отказоустойчивости.

Вебинар пройдет 10 февраля в 22-00 по московскому времени. Макс Коломейцев ответит на все ваши вопросы на русском языке. Регистрируйтесь!


Таги: StarWind, Webinar, Hardware

Обеспечение отказоустойчивости компонента VASA Vendor Provider (VP) для томов VVols в VMware vSphere.


Интересная статья от Дункана Эппинга была опубликована в его блоге пару недель назад. Если вы хотите использовать виртуальные тома VVols, которые обладают некоторыми преимуществами по сравнению с традиционной файловой системой VMware VMFS, то для некоторых систем, поддерживающих механизм VASA (vSphere API for Storage Awareness), потребуется использовать внешний виртуальный модуль VASA Vendor Provider (VP). То есть, некоторые аппаратные хранилища уже содержат в себе готовые модули и прошитые в них модули VP, а вот для некоторых нужно запускать и поддерживать специальную виртуальную машину, выполняющую сервисные функции при работе виртуальных машин с хранилищами VVols.

Прежде всего VP используется для выполнения операции Bind (привязка машины к VVol), которая инициируется при запуске виртуальной машины. В этом случае VP создает точку доступа ввода-вывода (IO access point) для виртуального тома VVol на выбранном Protocol Endpoint (PE). Без этой операции машина не запустится, из чего следует, что критически важно поддерживать виртуальную машину с VP непрерывно доступной. У разных вендоров используются разные уровни доступности:

  • Кто-то выпускает модуль с возможностью active/standby или active/active-конфигурации виртуальных машин на разных хостах.
  • Ну а кто-то надеется на встроенные механизмы обеспечения отказоустойчивости VMware HA и VMware Fault Tolerance (FT).

Очевидно, что если вы выбираете хранилище с внешним VP, то очень желательно, чтобы там был реализован первый вариант обеспечения доступности. Ну и нельзя помещать виртуальную машину с VASA VP на том VVol, чтобы не оказаться в ловушке невозможности запуска этой виртуальной машины.

Со временем VMware планирует включить операции bind/unbind в стандарт T10 SCSI, и сервисная виртуальная машина будет не нужна, но эти вещи, как вы понимаете, делаются не быстро, поэтому пока обеспечивайте отказоустойчивость виртуальных модулей VP, по крайней мере, с помощью технологий VMware HA и VMware Fault Tolerance.

И да, в комментарии пишут, что у одного админа получилось так, что машина с VP просто перестала выполнять команды, хотя сама ВМ работала. В результате продуктивные ВМ было не запустить. Поэтому имеет смысл задуматься и об обеспечении отказоустойчивости на уровне компонентов VP (может, как-нибудь проверять скриптами его работоспособность?).


Таги: VMware, VVOls, HA, FT, Storage, vSphere, Hardware

Облачный ЦОД для IaaS-провайдера: как облако «ИТ-ГРАД» размещается в дата-центре DataSpace.


Корпоративный IaaS-провайдер «ИТ-ГРАД» в качестве облачной площадки выбрал один из крупнейших московских дата-центров DataSpace. В чем его основные преимущества и чем выбранный ЦОД отличается от всех остальных? И правда, чем же DataSpace так приглянулся компании «ИТ-ГРАД», ведь сегодня на рынке ЦОД немало игроков?


Таги: IT-Grad, IaaS, Hardware

Как узнать версию BIOS/Firmware ESXi сервера при помощи PowerCLI


Очередная функция Get-VMHostFirmwareVersion моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам узнать версию и дату выпуска Firmware ваших серверов ESXi. Для большей гибкости и удобства в использовании, функция написана в виде PowerShell-фильтра.


Таги: VMware, ESXi, PowerCLI, Hardware, PowerShell, Blogs

Интеграция NetApp и VMware: клоны для разработчиков


Гостевая статья нашего спонсора - компании ИТ-ГРАД, предоставляющей услуги виртуальных машин VMware в аренду. В этой статье речь пойдет о плюсах интеграции среды виртуализации VMware и систем хранения NetApp. В частности, продолжим разбираться с VAAI и посмотрим, как использование такой связки может помочь в проектах по разработке ПО.


Таги: VMware, NetApp, Hardware, VAAI, Storage, IT-Grad

Приглашаем на бесплатный вебинар о StarWind HyperConverged Appliance.


Компания StarWind Software приглашает на бесплатный вебинар "StarWind HyperConverged Appliance: All-Flash Configuration, When Performance is Crucial", который пройдет 27 октября 2015 года в 22-00 по московскому времени. Мероприятие проводит Анатолий Вильчинский, поэтому вы смело можете задавать вопросы на русском языке (самое интересное - это, конечно же, про производительность):

На мероприятии будет рассказано о комплексном решении для хранения данных StarWind HyperConverged Appliance (HA), которе теперь включает в себя конфигурацию All-Flash, то есть все хранилища виртуальных машин размещаются на высокопроизводительных SSD-дисках.

Напомним, что StarWind HyperConverged Appliance строится все это на базе следующих аппаратных платформ (спецификации - тут):

Регистрируйтесь на вебинар, чтобы узнать больше об этом замечательном и недорогом решении для среднего и малого бизнеса.


Таги: StarWind, Webinar, Hardware

VMware EVO SDDC - обновление блочной архитектуры EVO:RACK.


На прошедшей конференции VMworld 2015 компания VMware анонсировала программно-аппаратную архитектуру VMware EVO SDDC, которая пришла на смену архитектуре EVO:RACK, которая, в свою очередь, была продолжателем подхода EVO:RAIL, о котором мы уже писали вот тут. SDDC - это концепция Software-Defined Data Center, то есть программно определяемый датацентр, где все физические ресурсы виртуализованы, абстрагированы от оборудования (то есть администратор оперирует логическими сущностями) и управляются из одной точки с помощью специализированного программного обеспечения.

Эта архитектура позволяет вендорам аппаратного обеспечения и OEM-партнерам VMware поставлять интегрированные законченные решения для создания виртуальной инфраструктуры в виде готовых к эксплуатации стоек с оборудованием и развернутым на нем программным обеспечением. На данный момент договоры уже подписаны с Dell, VCE и Quanta (они начнут поставки в первой половине 2016 года), другие вендоры также вскоре объявят о сотрудничестве с VMware.

Такой подход позволяет создать новую инфраструктуру или включить дополнительные ресурсы в уже существующую буквально за несколько часов. Ключевым компонентом такой инфраструктуры является средство управления EVO SDDC Manager. Инфраструктура под управлением EVO SDDC Manager является гиперконвергентной (hyper-converged infrastructure, HCI), то есть все ресурсы виртуализованы (серверы, хранилища и сети), находятся под управлением единого средства и управляются из одной точки.

С точки зрения аппаратного обеспечения, типовой базовый блок VMware EVO SDDC включает в себя 8 серверов, пару коммутаторов 10 Gbit Ethernet, один коммутатор управления и пару 40 Gbit spine-коммутаторов с 32 портами для связи между стойками. Все это уже полностью собрано, скоммутировано и настроено.

Полностью настроенный блок EVO SDDC из 24 серверов в максимальной конфигурации позволяет запустить в облаке предприятия или сервис-провайдера IaaS более 1000 виртуальных серверов или более 2000 виртуальных ПК:

А где же система хранения? - спросит вы. А ее тут нет, все хранение виртуальных машин осуществляется на базе локальных дисков серверов, объединенных в единое пространство хранения с помощью решения VMware Virtual SAN.

С точки зрения программного обеспечения, EVO SDDC включает в себя следующие компоненты:

  • VMware vSphere
  • VMware NSX
  • VMware Virtual SAN
  • VMware vRealize Operations
  • VMware vRealize Log Insight
  • VMware vRealize Automation (опционально)
  • VMware Horizon Suite (если стойка используется для виртуальных ПК)

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

Вот так выглядит рабочий процесс путешествия стойки от партнера к клиенту и ее ввод в эксплуатацию:

Более подробно об архитектуре VMware EVO SDDC можно узнать из этого документа.


Таги: VMware, EVO, SDDC, Update, Hardware, IaaS, Cloud, Cloud Computing

Подробная информация о StarWind Hyper-Converged Platform (H-CP).


Не так давно мы писали о гиперконвергентной платформе StarWind Hyper-Converged Platform (H-CP), которая позволяет построить полноценную ИТ-инфраструктуру небольшого предприятия на базе продуктов компаний StarWind, Veeam, VMware и Microsoft. H-CP поставляется в виде уже готовых к использованию серверов с предустановленными компонентами от соответствующих вендоров.

Теперь у StarWind появилась специальная страница, посвященная Hyper-Converged Platform. Ну и, кроме этого, об H-CP можно узнать из вот этого видео:

Строится все это на базе следующих аппаратных платформ:

Подробно об аппаратных характеристиках платформы H-CP от StarWind можно узнать из этого документа.


Таги: StarWind, Hardware, H-CP, HA

Встречайте! Новые массивы AFF от NetApp - мероприятие ИТ-ГРАД 15 октября в Санкт-Петербурге.


15 октября в 15:00 ИТ-ГРАД проводит презентацию новых высокопроизводительных флеш-массивов AFF от NetApp. На мероприятии вы узнаете о новой расширенной линейке флеш-массивов СХД, разработанной для корпоративных клиентов. Спикерами мероприятия выступят инженеры NetApp и ИТ-ГРАД.

ИТ-ГРАД приглашает вас посетить мероприятие-презентацию новых флеш-массивов All Flash FAS (AFF) 8000 от NetApp. Серия AFF на NetApp Data ONTAP призвана повысить производительность и эффективность флеш-данных.

Узнать подробнее о новинках можно от первых лиц компании NetApp, которые выступят спикерами мероприятия.

Участие в мероприятие бесплатное. Регистрируйтесь и присоединяйтесь!


Таги: IT-Grad, NetApp, Hardware, Flash, Event

PowerShell скрипт для автоматической установки ESXi хостов на серверах IBM/Lenovo


Автоматическая установка сама по себе несложный процесс, хотя и требует некоторых базовых знаний. Сложно здесь другое – развернуть вспомогательную инфраструктуру для загрузки по сети, включающую в себя PXE, TFTP и DHCP сервера и настроить её должным образом. А для этого, во-первых, нужно обладать глубокими техническими знаниями во многих областях и, во-вторых, это требует длительных временных затрат, ну и, в-третьих, это не всегда возможно в связи с внутриорганизационной политикой.
Таги: VMware, ESXi, Kickstart, Automation, Hardware, vSphere, PowerShell

Как понизить версию виртуального "железа" (Downgrade Hardware Version) в VMware vSphere.


У многих администраторов VMware vSphere зачастую возникает необходимость понизить версию виртуального аппаратного обеспечения (hardware version) виртуальной машины. Это может понадобиться в следующих случаях (и не только):

  • когда толстый клиент vSphere Client не поддерживает всех функций новой версии Virtual Hardware
  • новая версия железа не поддерживается старыми хостами VMware ESXi, которые вы еще не успели обновить
  • если вы пользуетесь услугами внешнего провайдера IaaS (аренда виртуальных машин), то у провайдера может оказаться не самая последняя версия платформы, и при миграции в его облако обновленное Virtual Hardware не будет поддерживаться

Так или иначе, сделать даунгрейд виртуального железа можно, и это достаточно просто. Если апгрейд делается из контекстного меню виртуальной машины в vSphere Client:

То даунгрейд можно сделать одним из трех способов:

  1. Перед апгрейдом виртуального обеспечения нужно сделать снапшот виртуальной машины. При откате к нему произойдет и откат к предыдущей версии виртуального железа.
  2. Можно использовать VMware Converter Standalone для V2V-миграции, при которой можно выбрать нужную версию Virtual Hardware.
  3. Можно создать новую виртуальную машину с нужной версией железа (например, на старом хосте ESXi), к которой прицепить диск от исходной ВМ.

Таги: VMware, Hardware, vSphere, ESXi, vCenter, VMachines

Citrix X1 Mouse - почти лэптоп Windows на вашем iPad или iPhone.


Не так давно компания Citrix выпустила интересный продукт, про который, наверняка, слышали далеко не все - это Citrix X1 Mouse. Да, да - это мышь для iOS-устройств, с которых весьма часто пользователи гаджетов Apple заходят в свои виртуальные ПК Citrix XenDesktop или опубликованные приложения XenApp. Сам знаю одного продажника стройматериалов, который ездит к клиенту с айпадом и показывает ему на нем прайсы из экселек через Citrix.

Так вот, эта мышь позволяет работать с вашим iPad или iPhone как с компом (особенно, если еще есть сворачивающаяся в трубочку Bluetooth-клавиатура):

Просто запускаете Citrix Receiver, и мышь появляется на экране вашего рабочего стола или в нужном приложении. Мышь посылает данные перемещения курсора непосредственно в Receiver по каналу Bluetooth, так как Apple в устройствах на iOS не поддерживает мышь как устройство ввода через Bluetooth. В принципе, эта штука, конечно, не для всех - не каждый с собой таскает iPad по работе, а для iPhone полезность мышки весьма сомнительна.

Кстати, посредством Citrix Receiver, мыши Citrix X1 Mouse и с помощью механизма ThinPrint можно редактировать документ и послать его на печать в своем или чужом офисе (на любой принтер с поддержкой AirPrint по Wi-Fi):

При работе с этой мышкой потребуется iPad 3.0 или более поздней версии, а также iPhone 5 или 6 (мышь к айфону, Карл!).

Купить мышь Citrix X1 Mouse в Штатах (стоит она $60), а также посмотреть информацию о покупке в других регионах, можно вот тут. Техническая информация о мышке доступна по этой ссылке.


Таги: Citrix, Hardware, Update, XenApp, XenDesktop, VDI

Прямой доступ к хранилищам NFS - вторая возможность Veeam Availability Suite v9.


Многие из вас знают, что в скором времени компания Veeam выпустит обновленный пакет продуктов Veeam Availability Suite v9, который представляет собой лучшее средство для резервного копирования, репликации и управления виртуальной средой. В прошлой заметке мы писали о двух новых возможностях этого решения: интеграции с технологией EMC Storage Snapshots и Veeam Cloud Connect с функциями репликации.

Сегодня мы посмотрим, что еще нового будет в новой версии. Вторая запись в блоге Veeam рассказывает нам о том, что Veeam Availability Suite v9 будет поддерживать прямой доступ к хранилищам NAS/NFS при резервном копировании. Раньше пользователи NFS-массивов чувствовали себя несколько "обделенными" в возможностях, так как Veeam не поддерживал режим прямой интеграции с таким типом дисковым массивов, как это было для блочных хранилищ.

Теперь же появилась штука, называемая Direct NFS, позволяющая сделать резервную копию ВМ по протоколам NFS v3 и новому NFS 4.1 (его поддержка появилась только в vSphere 6.0), не задействуя хост-сервер для копирования данных:

Специальный клиент NFS (который появился еще в 8-й версии) при включении Direct NFS получает доступ к файлам виртуальных машин на томах, для которых можно делать резервное копирование и репликацию без участия VMware ESXi, что заметно повышает скорость операций.

Кроме этого, была улучшена поддержка дисковых массивов NetApp. В версии 9 к интеграции с NetApp добавилась поддержка резервного копирования из хранилищ SnapMirror и SnapVault. Теперь можно будет создавать аппаратные снимки (с учетом состояния приложений) с минимальным воздействием на виртуальную среду, реплицировать точки восстановления на резервный дисковый массив NetApp с применением техник SnapMirror или SnapVault, а уже оттуда выполнять бэкап виртуальных машин.

При этом процесс резервного копирования не отбирает производительность у основной СХД, ведь операции ввода-вывода происходят на резервном хранилище:

 

 

Ну и еще одна полезная штука в плане поддержки аппаратных снимков хранилищ от Veeam. Теперь появится фича Sandbox On-Demand, которая позволяет создать виртуальную лабораторию, запустив виртуальные машины напрямую из снапшотов томов уровня хранилищ. Такая лаборатория может быть использована как для проверки резервных копий на восстановляемость (сразу запускаем ВМ и смотрим, все ли в ней работает, после этого выключаем лабораторию, оставляя резервные копии неизменными), так и для быстрого клонирования наборов сервисов (создали несколько ВМ, после чего создали снапшот и запустили машины из него). То есть, можно сделать как бы снимок состояния многомашинного сервиса (например, БД-сервер приложений-клиент) и запустить его в изолированном окружении для тестов, ну или много чего еще можно придумать.

Veeam Availability Suite v9 ожидается к выпуску, скорее всего, в третьем квартале 2015 года. Следить за новостями по этому решению можно вот тут.


Таги: Veeam, Backup, Suite, Update, Hardware, NFS, NetApp, Storage

StarWind и полная сертификация со стороны производителей платформ виртуализации.


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

На днях пришла отличная новость - StarWind завершила сертификацию своего ПО в рамках программы Citrix XenServer 6.5 Certification, и, таким образом, работоспособность решения Virtual SAN подтверждена официально со стороны основной тройки вендоров платформ:

Поздравляем наших коллег, а всем вам предлагаем бесплатно попробовать продукт StarWind Virtual SAN.


Таги: StarWind, Hardware, Virtual SAN, Storage

Новые возможности Veeam Availability Suite v9 - еще больше средств для резервного копирования, репликации и управления виртуальной инфраструктурой.


Один из лидеров на рынке резервного копирования и управления виртуальной инфраструктурой, компания Veeam Software, официально объявила о запуске во втором квартале 2015 года новой версии лучшего решения для резервного копирования, репликации и управления виртуальной средой - Veeam Availability Suite v9. Напомним, что о возможностях пакета Veeam Availability Suite v8 мы писали вот тут.

Пока стало известно о двух новых возможностях продукта. А именно:

1. Интеграция с технологией EMC Storage Snapshots в Veeam Availability Suite v9.

Многие пользователи Veeam Backup and Replication задавали вопрос, когда же будет сделана интеграция с дисковыми массивами EMC. Теперь она будет добавлена для СХД линеек EMC VNX и EMC VNXe.

Интеграция с хранилищами EMC означает поддержку обеих техник - Veeam Explorer for Storage Snapshots recovery и Backup from Storage snapshots, то есть можно смотреть содержимое снапшотов уровня хранилища и восстанавливать оттуда виртуальные машины (и другие сущности - файлы или объекты приложений), а также делать бэкап из таких снапшотов.

Иллюстрация восстановления из снапшота на хранилище EMC:

Иллюстрация процесса резервного копирования (Veeam Backup Proxy читает данные напрямую со снапшота всего тома, сделанного на хранилище EMC):

Более подробно об этих возможностях можно почитать в блоге Veeam.

2. Veeam Cloud Connect - теперь с возможностью репликации.

Как вы помните, в прошлом году компания Veeam выпустила средство Veeam Cloud Connect, которое позволяет осуществлять резервное копирование в облако практически любого сервис-провайдера. Теперь к этой возможности прибавится еще и возможность репликации ВМ в облако, что невероятно удобно для быстрого восстановления работоспособности сервисов в случае большой или маленькой беды:

Кстати, Veeam Cloud Connect инкапуслирует весь передаваемый трафик в один-единственный порт, что позволяет не открывать диапазоны портов при соединении с инфраструктурой сервис-провайдера. Очень удобно.

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

Ну а сервис-провайдеры с появлением репликации от Veeam получают в свои руки полный спектр средств для организации DR-площадки в аренду для своих клиентов:

Более подробно о репликации Veeam Cloud Connect рассказано в блоге Veeam. Сам продукт ожидается к выпуску, скорее всего (как сказал Антон Гостев), в третьем квартале 2015 года. Следить за новостями по Veeam Availability Suite v9 можно вот тут.


Таги: Veeam, Backup, Update, VMware, Storage, EMC, Hardware, Replication

Репликация в VMware Site Recovery Manager - чем отличаются Array Based Replication и vSphere Replication.


Многие из вас знакомы с продуктом 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).


Таги: VMware, SRM, Replication, Hardware, vSphere, ESXi, Сравнение

Citrix XenServer v6.5 SP1 доступен для скачивания.


На прошедшей совсем недавно конференции Citrix Synergy 2015 компания Citrix сделала массу интересных анонсов. Среди них - объявление о выходе серверной платформы виртуализации Citrix XenServer v6.5 SP1, которая уже сейчас доступна для загрузки.

Напомним, что прошлая версия XenServer 6.5 вышла в начале этого года. Ну а в пакете обновления SP1 мы получили следующие новые возможности:

  • Увеличено число виртуальных машин на хост - до 1000.
  • Полностью доделана поддержка технологий Intel GVT-d (проброс GPU в ВМ) для Windows-машин.
  • Поддержка проброса GPU nVIDIA в виртуальные машины с гостевой ОС Linux. Здесь была проделана действительно большая работа совместно с nVIDIA, теперь в виртуальной машине можно комфортно работать с приложениями, задействующими GPU напрямую. Кроме того, драйверы vGPU теперь ставятся через GUI, безо всяких команд CLI.

  • Добавлена поддержка контейнеров Docker - теперь можно запускать контейнеры в ВМ и управлять их жизненным циклом через XenCenter.

  • Поддержка новых гостевых ОС и их обновлений: Windows 10 (пока неофициальная) и CoreOS.
  • Улучшения XenCenter: возможность просмотра использования кэша на чтение на уровне отдельной ВМ.

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


Таги: Citrix, XenServer, Update, NVIDIA, vGPU, Hardware

Обновления микрокода Intel и AMD в VMware ESXi - как это работает.


Компания VMware в своем блоге затронула интересную тему - обновление микрокода для процессоров платформ Intel и AMD в гипервизоре VMware ESXi, входящем в состав vSphere. Суть проблемы тут такова - современные процессоры предоставляют возможность обновления своего микрокода при загрузке, что позволяет исправлять сделанные вендором ошибки или устранять проблемные места. Как правило, обновления микрокода идут вместе с апдейтом BIOS, за которые отвечает вендор процессоров (Intel или AMD), а также вендор платформы (HP, Dell и другие).

Между тем, не все производители платформ делают обновления BIOS своевременно, поэтому чтобы получить апдейт микрокода приходится весьма долго ждать, что может быть критичным если ошибка в текущей версии микрокода весьма серьезная. ESXi имеет свой механизм microcode loader, который позволяет накатить обновления микрокода при загрузке в том случае, если вы получили эти обновления от вендора и знаете, что делаете.

Надо сказать, что в VMware vSphere 6.0 обновления микрокода накатываются только при загрузке и только на очень ранней стадии, так как более поздняя загрузка может поменять данные, уже инициализированные загрузившимся VMkernel.

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

Есть два способа обновить микрокод процессоров в ESXi - через установку VIB-пакета и через обновление файлов-пакетов микрокода на хранилище ESXi. Если вы заглянете в папку /bootbank, то увидите там такие файлы:

  • uc_amd.b00
  • uc_intel.b00

Эти файлы и содержат обновления микрокода и идут в VIB-пакете cpu-microcode гипервизора ESXi. Ниже опишем процедуру обновления микрокода для ESXi с помощью обоих методов. Предпочтительный метод - это делать апдейт через VIB-пакет, так как это наиболее безопасно. Также вам потребуется Lunix-машина для манипуляций с микрокодом. Все описанное ниже вы делаете только на свой страх и риск.

1. Скачиваем обновления микрокода.

Можно воспользоваться вот этими ссылками:

Для Intel выполните команду:

tar -zxf microcode-*.tgz

После распаковки вы получите файл microcode.dat. Это файл в ASCII-формате, его надо будет преобразовать в бинарный. У AMD в репозитории есть сразу бинарные файлы (3 штуки, все нужные).

2. Делаем бинарный пакет микрокода.

Создаем следующий python-скрипт и называем его intelBlob.py:

#! /usr/bin/python
# Make a raw binary blob from Intel microcode format.
# Requires Python 2.6 or later (including Python 3)
# Usage: intelBlob.py < microcode.dat microcode.bin

import sys

outf = open(sys.argv[1], "wb")

for line in sys.stdin:
if line[0] == '/':
continue
hvals = line.split(',')
for hval in hvals:
if hval == '\n' or hval == '\r\n':
continue
val = int(hval, 16)
for shift in (0, 8, 16, 24):
outf.write(bytearray([(val >> shift) & 0xff]))

Далее создаем бинарники микрокода. Для Intel:

cat intel/*.dat | ./intelBlob.py uc_intel
gzip uc_intel

Для AMD:

cat amd/*.bin > uc_amd
gzip uc_amd

3. Метод замены файлов с апдейтом микрокода.

Тут все просто. Выполним одну из следующих команд для полученных файлов:

  • cp uc_intel.gz /bootbank/uc_intel.b00
  • cp uc_amd.gz /bootbank/uc_amd.b00

Далее можно переходить к шагу 5.

4. Метод создания VIB-пакета и его установки.

Тут нужно использовать утилиту VIB Author, которую можно поставить на Linux-машину (на данный момент утилита идет в RPM-формате, оптимизирована под SuSE Enterprise Linux 11 SP2, который и предлагается использовать). Скачайте файл cpu-microcode.xml и самостоятельно внесите в него изменения касающиеся версии микрокода.

Затем делаем VIB-пакет с помощью следующей команды:

vibauthor -c -d cpu-microcode.xml \
-p uc_intel.gz,boot,uc_intel,200 \
-p uc_amd.gz,boot,uc_amd,201

Если в VIB-файл не нужно включать микрокод от одного из вендоров CPU - просто уберите часть команды с "-p".

Далее устанавливаем VIB через esxcli:

esxcli software acceptance set --level=CommunitySupported
esxcli software vib install \
-v file:/vmfs/volumes/datastore1/cpu-microcode-6.0.0-0.test.0.vib

Затем проверьте наличие файлов uc_*.b00, которые вы сделали на шаге 2, в директории /altbootbank.

5. Тестирование.

После перезагрузки хоста ESXi посмотрите в лог /var/log/vmkernel.log на наличие сообщений MicrocodeUpdate. Также можно посмотреть через vish в файлы /hardware/cpu/cpuList/*, в которых где-то в конце будут следующие строчки:

Number of microcode updates:1
Original Revision:0x00000011
Current Revision:0x00000017

Это и означает, что микрокод процессоров у вас обновлен. ESXi обновляет микрокод всех процессоров последовательно. Вы можете проверит это, посмотрев параметр Current Revision.

Также вы можете запретить на хосте любые обновления микрокода, установив опцию microcodeUpdate=FALSE в разделе VMkernel boot. Также по умолчанию запрещено обновление микрокода на более ранние версии (даунгрейд) и на экспериментальные версии. Это можно отключить, используя опцию microcodeUpdateForce=TRUE (однако микрокод большинства процессоров может быть обновлен только при наличии цифровой подписи вендора). Кроме того, чтобы поставить экспериментальный апдейт микрокода, нужно включить опции "debug mode" или "debug interface" в BIOS сервера, после чего полностью перезагрузить его.


Таги: VMware, ESXi, vSphere, Обучение, Hardware

Не пропустите бесплатный вебинар от StarWind: Make Your Storage Work For You.


Компания StarWind Software, производитель решения #1 в сфере программных хранилищ под виртуализацию, проводит бесплатный вебинар "Make Your Storage Work For You: VAAI and ODX offload up to 30% of disk operations to the SAN".

Этот вебинар продолжает серию технических мероприятий StarWind, в рамках которых подробно рассматриваются довольно интересные глубокие темы. На этот раз речь пойдет об использовании технологий Offloaded Data Transfer (ODX) и APIs for Array Integration (VAAI), которые позволяют передать исполнение до 30% дисковых операций на сторону SAN (дисковый массив или серверы-хранилища), не затрагивая подсистему ввода-вывода хост-серверов Microsoft Hyper-V или VMware ESXi.

Мероприятие пройдет послезавтра, 21 апреля в 21-00 по московскому времени.

РЕГИСТРАЦИЯ.


Таги: StarWind, Hardware, VAAI, VMware, Microsoft, Storage

Почему Virtual Volumes (VVols) в VMware vSphere 6 - это круто?


Не так давно мы писали про технологию Virtual Volumes (VVols), которая полноценно была запущена в новой версии платформы виртуализации VMware vSphere 6. VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее.

VVols - это один из типов хранилищ (Datastore) в vSphere:

Тома vVOLs создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы сейчас видите в папке с ВМ, создается отдельный vVOL.

Многие администраторы задаются вопросом: а почему VVols - это крутая штука, нужны ли они вообще? VMware в своем блоге отвечает на этот вопрос. Попробуем изложить их позицию здесь вкратце.

Ну, во-первых, VVols дают возможность создавать аппаратные снапшоты, клоны и снапклоны на уровне одной виртуальной машины, а не целых LUN, но это неконцептуально. Вопрос следует понимать глубже.

Все идет из концепции SDDC (Software Defined Datacenter), которая подразумевает абстракцию всех уровней аппаратных компонентов (вычислительные ресурсы, сети, хранилища) на программный уровень таким образом, чтобы администратор виртуальных ресурсов не ломал себе голову насчет физического устройства датацентра при развертывании новых систем. Иными словами, при создании виртуальной машины администратор должен определить требования к виртуальной машине в виде политики (например система Tier 1), а программно-определяемый датацентр сам решит где и как эту машину разместить (хост+хранилище) и подключить ее к сети (тут вспомним про продукт VMware NSX).

С точки зрения хранилищ (SDS - software defined storage) эта концепция реализуется через подход Storage Policy Based Management (SPBM), предполагающий развертывание новых систем на хранилищах, которые описаны политиками. Этого мы уже касались в статье "VMware vSphere Storage DRS и Profile Driven Storage - что это такое и как работает".

Если раньше дисковый массив определял возможности хранилища, на котором размещалась ВМ (через LUN для Datastore), и машина довольствовалась тем, что есть, то теперь подход изменился: с Virtual Volumes, к которым привязаны политики виртуальных машин, сама машина "рассказывает" о своих требованиях дисковому массиву, который уже ищет, где он может ее "поселить". Этот подход является более правильным с точки зрения автоматизации и человеческого фактора (ниже расскажем почему).

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

  • Тип избыточности и размещения данных (например, RAID - Stripe/Mirror)
  • Наличие дедупликации (да/нет)
  • Тип носителя (Flash/SAS/SATA)

Это нам даст 12 возможных комбинаций типов LUN, которые мы можем создать на дисковом массиве:

Соответственно, чтобы учесть все такие комбинации требований при создании виртуальных хранилищ (Datastores), мы должны были бы создать 12 LUN. Но на этом проблемы только начинаются, так как администратор всегда стремится выбрать лучшее с его точки зрения доступное хранилище, что может привести к тому, что LUN1 у нас будет заполнен под завязку системами разной критичности, а новые критичные системы придется размещать на LUN более низкого качества.

На помощь тут приходят политики хранилищ (VM Storage Policies). Например, мы создаем политики Platinum, Silver и Gold, для которых определяем необходимые поддерживаемые хранилищами функции, которые обоснованы, например, критичностью систем:

Если говорить о примере выше, то Platinum - это, например, хранилище с характеристиками LUN типов 1 и 3.

Интерфейс vSphere Web Client нам сразу показывает совместимые и несовместимые с этими политиками хранилища:

Так вот при развертывании новой ВМ администратору должно быть более-менее неважно, на каком именно массиве или LUN будет расположена машина, он должен будет просто выбрать политику, которая отражает его требования к хранилищу. Удобно же!

При создании политики администратор просто выбирает провайдера сервисов хранения (в данном случае массив NetApp с поддержкой VVols) и определяет необходимые поддерживаемые фичи для набора правил в политике:

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


Таги: VMware, vSphere, VVOls, Virtual Volumes, Hardware, SDDC, SDS, Storage

1 | 2 | 3 | 4 | 5    >   >>
Реклама





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

02/12/2017:  AZURE DAY 2017 (Минск)
06/03/2018:  ИТ-стратегия 2018
24/05/2018:  IT&SECURITY FORUM (Казань)

Быстрый переход:
VMware StarWind Veeam IT-Grad vGate Microsoft Cloud SDRS Parallels IaaS Citrix 5nine HP VeeamON VMFS RVTools PowerCLI VM Guru Oracle Red Hat Azure KVM VeeamOn Security Code 1cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V VVols HA Tools Backup vSAN Book Photon vCloud VMworld Horizon vROPs Labs Fusion Cloud Computing vCSA SSD Client DRS OpenStack Comparison Workstation Blast SRM App Volumes Performance Manager Nested AWS Log Insight XenDesktop VSA vNetwork SSO LSFS Workspace Host Client VMDK VTL Update iSCSI SDDC NSX Agent Virtual Appliance Whitepaper PowerShell Appliance VUM V2V Cache Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance DR Vanguard SaaS Connector Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Networking Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Director Diagram Bug Troubleshooting Air API CLI Plugin DPM Memory Upgrade SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2017, Александр Самойленко. Правила перепечатки материалов.