вторник, 22 мая 2018 г.

Немного о дизайне VDI. Часть 8. Подсистема хранения

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI

8.1 Масштабирование СХД

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

При использовании классических систем хранения существует два основных варианта планирования архитектуры.

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

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

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

8.2 Типы хранилищ

vSphere поддерживает следующие типы хранилищ:
  • Блочные с файловой системой VMFS версии 3, 5 или 6 (локальные диски, тома, подключаемые по SAS, iSCSI, FC, FCoE).
  • Файловые (NFS v3, NFS v4.1).
  • Объектные (хранилище VMware VSAN, Dell EMC ScaleIO).
  • Блочные или файловые с поддержкой Virtual Volumes (VVOL).

В таблице приведено сравнение типов хранилищ по ряду параметров. Некоторые модели СХД могут накладывать дополнительные ограничения, например, на максимальный размер LUN под хранилища, наличие или отсутствие поддержки VAAI, возможностям по репликации и т.д.

Функции
Блочное хранилище (VMFS)
Сетевой каталог (NFS)
Объектное хранилище (VSAN)
Среда передачи данных SAS, Ethernet, Fibre Channel Ethernet Ethernet
Максимальный размер хранилища 64 ТБ 64 ТБ 64 ТБ
Максимальный размер VMDK 62 ТБ 62 ТБ 62 ТБ
Максимальное число хостов, которым может быть презентовано хранилище 64 n/a 64
Кол-во хранилищ на один хост 512 256 1
Кол-во ВМ на один хост 1024 1024 200
Включенных ВМ на одном хранилище 2048 n/a 6000
Поддержка составных хранилищ (extent) Да Нет Нет
Поддержка многопутевого ввода-вывода (multipathing) Да, для балансирования нагрузки и отказоустойчивости Поддерживается в NFS v4 для обеспечения отказоустойчивости Не применимо*
Поддержка SIOC Да Нет Да
Поддержка Raw Device Mapping Да Нет Да**
Поддержка VAAI Да, зависит от массива Да, зависит от массива Не применимо
Поддержка VASA Да, зависит от массива Да, зависит от массива Да
Поддержка VVOLS Да Да, кроме NFS v4.1 Нет
Поддержка шифрования VM Encryption Да Да Да, также поддерживается VSAN Data at Rest Encryption
Поддержка Virtual Flash Read Cache (vFlash) Да Да Нет
Поддержка Storage DRS Да Да, кроме NFS v4.1 Нет
Поддержка vSphere Replication Да Да Да
Поддержка аппаратной репликации Да Да Нет

* VSAN является распределенной системой хранения. Передача данных между узлами выполняется через VMKernel интерфейсы. Агрегация каналов средствами виртуального коммутатора и/или несколько VMKernel интерфейсов на одном хосте поддерживаются, но только для обеспечения отказоустойчивости.

** В VSAN 6.5 появилась функция Software iSCSI Target, позволяющая презентовать LUN, хранящиеся на VSAN клиентским устройствам по протоколу iSCSI, данные LUN могут быть презентованы как RDM диски виртуальным машинам. В vSAN 6.7 такие LUN могут использоваться в качестве общих дисков для кластеров Windows Server Failover Cluster.
При планировании хранения для VDI следует учитывать, что далеко не все технологии хранения, поддерживаемые в vSphere, поддерживаются и для Horizon. Так среди известных ограничений:
  • Отсутствие поддержки vFlash для Automated Pool десктопов.
  • Отсутствие поддержки Storage vMotion для Linked-Clone десктопов.
  • Storage DRS кластеры поддерживаются только для пулов с Full-clone десктопами.
  • Отсутствие поддержки vSphere Replication.
Пара слов о VVOLs. Как и в случае с VCAI, хранилище должно находится в списке совместимости для поддержки со стороны VMware. На текущий момент VVOLs поддерживаются только на хранилищах NetApp: https://www.vmware.com/resources/compatibility/pdf/vi_vvolh_guide.pdf

8.3 Сайзинг размера хранилищ

Несмотря на ограничение в максимальный размер хранилища VMFS в 64 ТБ на практике вы вряд ли будет использовать такие большие хранилища. Причин так делать может быть много:
  • Ограничение на максимальные размер LUN со стороны СХД.
  • Решение проблем с производительностью. На производительность блочного доступа большое влияние может оказывать глубина очереди команд (Queue Depth). Глубина очереди есть у накопителей, адаптеров ввода-вывода, портов массива, есть она и у LUN. При размещении большого количества ВМ на одном LUN, подключенного к большому числу хостов, вы можете упереться в размер очереди к логическому тому. Еще одна проблема с производительностью касается старых массивов, а также некоторых конфигураций на современных массивах. До появления VAAI ATS в vSphere 4.0 запуск ВМ, расширение thin диска, создание снапшота требовали временной блокировки всего LUN. При большом количестве ВМ подобные операции происходят достаточно часто, что может приводить к уменьшению производительности. Практически все современные массивы поддерживают VAAI, однако в некоторых случаях он может отключаться (например, при настройке репликации LUN на удаленный массив).
  • Балансирование нагрузки на сеть хранения. При блочном доступе в один момент времени доступ к LUN со одного хоста осуществляется через один путь. Увеличив числов LUN, вы можете настроить доступ к ним, используя разные пути до массива.
  • Использование разных LUN под хранение разных типов данных. Помимо очевидного преимущества в виде тиринга средствами Horizon, например, размещение linked-clone реплик на LUN на Flash накопителях, дельта дисков на LUN на SAS дисках, а persistent дисков на SATA, это также может пригодиться в случаях, когда вы планируете использовать репликацию средствами СХД для катастрофоустойчивых сценариев, чтобы, например, чтобы вынести файлы подкачки ВМ на отдельный LUN и не реплицировать его вместе с дисками виртуальных машин.
  • Ограничения и рекомендации со стороны VMware. Согласно VMware Horizon 7 Sizing Limits and Recommendations на одном логическом томе рекомендуется размещать не более 500 ВМ.
С другой стороны - создание большого количества маленьких хранилищ приведет к усложнению администрирования, кроме того при просчетах в сайзинге повышается риск того, что на одном из хранилищ закончится место, в то время, как другие будут не нагружены. Нужно найти некий баланс между удобством управления небольшим кол-во хранилищ и вышеуказанными ограничениям.

В этом плане NAS хранилища гораздо площе, т.к. не имеют многих ограничений блочного доступа.

8.4 VMware vSAN

Одним из вариантов организации хранения ВМ для VDI является использование SDS на базе VMware vSAN.

К преимуществам vSAN можно отнести простоту развертывания, высокую производительности и экономию на внедрении за счет использования лицензий vSAN for Horizon Advanced, входящих в бандлы Horizon Advanced или Enterprise.
При выборе конфигурации сервера для vSAN можно приобрести предопределенные и протестированные вендорами конфигурации – vSAN Ready Nodes от различных производителей (HPE, Dell, Cisco, Huawei, Lenovo и другие), либо самостоятельно собирать серверы из совместимых компонентов (https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan).

К преимуществам vSAN (как и многих других программно-конфигурируемых хранилищ) относится возможность горизонтального масштабирования. vSAN поддерживает создание кластеров до 64 узлов для локального кластера или до 31 узла – для территориально распределенного (stretched) кластера.

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

Минимальная поддерживая конфигурация - два хоста. Двухузловой кластер может использоваться в небольших инсталляциях в филиалах (Branch office). Важным требованием для развертывания двухузловой конфигурации является наличие узла-свидетеля на третьей площадке. Узел свидетель представляет собой виртуальную машину с установленным гипервизором ESXi, которые хранит witness компоненты и выступает арбитром для предотвращения возникновения split brain.

Если говорить о варианте развертывания без использования специализированных компонентов, то минимальное кол-во хостов – 3. В данной конфигурации каждый хост хранит данные ВМ и witness компоненты, которые автоматически распределяются по хостам. Для трехузлового кластера возможна настройка режима избыточного хранения – Fault to Tolerate = 1, при котором vSAN создает и поддерживает в синхронном состоянии две копии данных, так, что отказ одного любого компонента (жесткого диска, SSD, контроллера, либо хоста целиком) не приведет к потере данных.

Часто в официальных руководствах можно встретить рекомендацию по использованию в кластере vSAN не менее 4-х узлов. Откуда взялась данная рекомендация?

Это сделано для того, чтобы в случае отказа одного хоста, или переводе его в режим обслуживания, в кластере осталось 3 узла и была возможность восстановить избыточность данных. В случае 3-узлового кластера отказ одного хоста позволит сохранить доступ к данным (при FTT=1) однако двух оставшихся хостов будет недостаточно, чтобы хранить две копии данных и witness компоненты, такой кластер будет работать в деградировавшем режиме, пока третий хост не вернется в строй. По этой же причине VMware рекомендует резервировать в кластере часть дискового пространства (порядка 30%), которое будет использоваться для восстановления избыточности хранения в случае отказа хоста.

Еще одна причина для резервирования дискового пространства, когда на накопителе, хранящем данные (capacity device) остается менее 20% свободного пространства, vSAN запускает процедуру балансировки компонентов по другим хостам, что может создать дополнительную нагрузку на дисковую подсистему. Для этих целей VMware и рекомендует оставлять резерв порядка 30% для восстановления избыточности при отказе или переводе в режим обслуживания хоста в кластере.

Для того, чтобы vSAN мог хранить данные на хосте, на нем должна быть создана, по крайней мере, одна дисковая группа. Дисковая группа включает в себя накопители двух типов:
  • Накопитель для Performance Tier, который используется для кэширования операций ввода/вывода – это Flash накопитель с SATA, SAS или PCI-E (включая NVMe) интерфейсом. Для создания дисковой группы в ней обязательно должен присутствовать один (не более и не менее) Flash накопитель для Performance Tier.
  • Накопители для Capacity Tier, которые используются для хранения данных ВМ. В качестве накопителя могут использоваться жесткие диски с интерфейсом SATA/SAS – такие конфигурации носят название гибридные (Hybrid), или Flash накопители – такие конфигурации называются All-Flash. В одной дисковой группе может присутствовать от 1 до 7 накопителей Capacity Tier. Смешивание hybrid и all-flash накопителей в рамках дисковой группы, хоста, или всего кластера не поддерживается. Единственное исключение – миграция с hybrid на all-flash конфигурации.
При необходимости использования большего количества дисков на хосте может быть создано до 5 дисковых групп, что теоритически позволяет установить в сервер до 35 Capacity накопителей.

Следует помнить, что в vSAN отличается подход к работе с flash кэшем для гибридных и all-flash конфигураций.

Для гибридных конфигураций flash кэш делится в соотношении 70/30 на кэш для операций чтения и кэш для операций записи.

В all flash конфигурациях вся емкость Performance tier выделяется под кэш на запись. Чтение же выполняется напрямую с flash накопителей, относящихся к capacity tier.

При планировании конфигурации накопителей VSAN следует помнить, что максимальный размер кэша на запись для одной дисковой группы составляет 600 Гигабайт. Это не слишком критично для гибридных конфигураций, поскольку будет являться ограничением только при использовании SSD накопителей объемом более 2 ТБ под кэш. В all-flash конфигурациях накопители объемом более 600 ГБ на дисковую группу не будут полностью утилизироваться. С другой стороны, использование накопителей большей емкости позволит уменьшить износ и повысить ресурс SSD за счет использования технологий типа TRIM, обеспечивающих равномерную перезапись данных по всем ячейкам.

Управление настройками VSAN осуществляется гранулярно при помощи политик хранения (Storage Policies) для каждого объекта.
VSAN позволяет хранить следующие типы объектов
  • Виртуальные диски (vmdk).
  • Снапшоты виртуальных дисков (-delta.vmdk).
  • Файл подкачки ВМ (vswp).
  • Конфигурационный раздел, где хранится файл настроек (.vmx), файлы журналов (.log), файл настроек биоса (.nvram) и т.д.
Администратор может использовать политику по умолчанию или создать свою, чтобы задать уровень доступности данных, задать настройки резервирования дискового пространства и кэша, включить или отключить erasure coding или hardware checksum.
Перечень настроек VSAN:

Number of Failures To Tolerate - определяет кол-во копий объектов, которые размещаются на хранилище VSAN. Фактически, данная настройка определяет, какое число одновременных отказов в кластере объект может перенести с гарантированным сохранением доступа к данным. Копии объектов размещаются на разных хостах кластера, что позволяет переживать отказ любого аппаратного компонента сервера - жёсткого диска, flash накопителя, HBA адаптера, сервера целиком, а при использовании совместно с механизмом Fault Domain - стойки или всей площадки (при реализации распределенного кластера VSAN). Параметр может принимать значение от 0 до 3.

Минимальное значение FTT=0, означает, что на VSAN размещается всего одна копия данных без резервирования, что, эквивалентно JBOD или RAID-0 конфигурации дисковой подсистемы.
При FTT=1 в кластере хранятся две копии данных - аналог raid 10, что позволяет обеспечивать доступность при отказе любого одного компонента VSAN. Для данного режима также поддерживается режим erasure coding.

При FTT=2 в кластере хранятся три копии данных, что позволяет гарантированно пережить отказ одновременно любых двух компонентов. Для FTT=2 Vmware заявляет о доступности данных на уровне 99.9999%. Для данного режима такжеподдерживается erasure coding, о котором ниже.

Наконец, FTT=3 обеспечивает хранение четырёх копий данных и позволяет пережить отказ любых трёх компонентов.

В VSAN 6.6 данная политика были изменена из-за появления механизма Local Protection for Stretched Clusters. До этого при настройке Stretched VSAN Cluster поддерживался лишь режим FTT=1, при котором одна копия объекта хранилась на хостах на одной площадке, а вторая копия - на второй. Это означало, что при отказе площадки, доступной оставалась только одна копия данных для которой VSAN не восстанавливал избыточность и любой последующий отказ на второй площадке мог привести к потере данных.

В VSAN 6.6 появилась возможность дополнительно защищать данные на каждой из площадок.
Параметр Primary level of failures to tolerate определяет уровень защиты данных между площадками (хранить 1 или 2 копии).

Параметр Secondary level of failures to tolerate определяет уровень защиты данных внутри площадки и может принимать значение от 0 до 3.

В таблице приведена информация о требованиях к минимальному числу хостов в кластере и накладных расходах на хранения при разных уровнях PFTT и SFTT.

Режим
Мин. Кол-во хостов (локальный кластер PFTT=0)
Требование к дисковому пространству % (локальный кластер)
Мин. кол-во хостов (stretched кластер)
Требование к дисковому пространству % (stretched кластер PFTT=1)
SFTT=0 1 100% 2 200%
SFTT=1 (Mirroring) 2 + witness или 3 200% 4 400%
SFTT=1 + Erasure Coding 4 133% 8 266%
SFTT=2 (Mirroring) 5 300% 10 600%
SFTT=2 + Erasure Coding 6 150% 12 300%
SFTT=3 (Mirroring) 7 400% 14 800%

Number of Disk Stripes Per Object – управляет настройками страйпинга (размазыванием) копии объекта по накопителям Capacity Tier.

Параметр может принимать значение от 1 до 12. Параметр определяет – на каком минимальном числе накопителей Capacity Tier будет размещаться объект.
Каждая копия объекта состоит из одного или более компонентов, которые, в свою очередь, хранится на одном из накопителей capacity tier. Все компоненты, которые хранят данные объекта, объединяются в страйп (аналог RAID-0). Данные распределяеются по компонентам равномерно, блоками (chunk) размером по 1 МБ.

В каких случаях может происходить разделение копии объекта на несколько компонентов? Во-первых, размер компонента не может превышать 255 ГБ, поэтому если размер (копии) объекта больше 255 ГБ, то он разбивается на пропорциональное число компонентов. Например, виртуальный диск размером 1 ТБ, имеющий одну копию на VSAN, будет состоять минимум из 5 компонентов (без учета политики FTT).

Во-вторых, объект может разбиваться на компоненты, если на физическом накопителей capacity tier недостаточно свободного места. Например, если надо сохранить объект размером 100 ГБ, а на дисках осталось по чуть более 50 ГБ свободного пространства, то объект будет разделен на два компонента по 50 ГБ.

В-третьих, если для объекта задана настройка Number of Disk Stripes Per Object больше 1, то для соответствия требованиям политики VSAN разделит объект на нужное число компонентов. Следует помнить, что данная политика определяет только минимальное число дисков для размещения компонентов, поэтому вполне возможна ситуация, когда реальное число компонентов больше того, что указано в политике.

Object Space Reservation, по умолчанию все объекты на VSAN, кроме файла подкачки ВМ создаются тонкими, т.е. без резервирования дискового пространства (Space Reservation = 0) и растут по мере заполнения данными.

Данная политика позволяет регулировать какой объем дискового пространства будет резервироваться для объекта. В случае 100% резервации вы получите обычные thick диски, при 0% - тонкие, при любых значения между - что-то среднее.

Flash Read Cache Reservation - политика определяет какой объем кэш памяти на чтение резервируется для данного объекта. По умолчанию резко для объектов равен 0%, однако для обеспечения гарантированного уровня производительности вы можете зарезервировать часть пространства. Для вм horizon по умолчанию используется настройка которая для replica дисков резервирует 10% дискового пространства на чтение. Эта политика не применяется для all flash конфигураций.

Force Provisioning - политика, которая определяет - возможно ли создать объект на VSAN, в случае, когда не могут быть выполнены остальные политики, например, если недостаточно хостов или дискового пространства для создания нужного количества копий. Если политика не включена то объект не создастся, если не сможет удовлетворять всем требованиям политики.

Failure Tolerance Method - включает или отключает режим erasure coding для объекта для экономии дискового пространства. При отключенном EC VSAN хранит несколько полных копий объектов для обеспечения избыточности сетевой аналог raid1/10, при включенном ec для обеспечения избыточности используются хэш суммы, аналог raid5 для FTT=1 и raid6 - для FTT=2.

Использование EC позволяет существенно снизить требования к дисковому пространства. Цена за экономию - большая нагрузка на дисковую подсистему. Данная политика работает только для all-flash конфигураций VSAN.

Disable Object Checksum включает или отключает использование контрольных сумм для выявления и исправления одиночных ошибок при записи или чтении данных. Создает большую нагрузку на процессор.

IOPS limit for object – доступна только в редакции vSAN Enterprise. Ограничивает кол-во IOPS для объекта. В качестве размера блока для IO операции берется 32 КБ, таким образом, чтение или запись блока размером 64 КБ будет считаться уже за 2 IO операции.

Еще одна политика, которая не имеет прямого отношения к VSAN, но может использоваться совместно - это политики Storage I/O Control, позволяющие гарантировать определнный уровень производительности ввода вывода для виртуалтных машин, начиная с vSphere 6.6 настройки SIOC также задаются через механизм Storage Policies и позволяют задавать лимиты и резервирование IOPS.

SIOC может пригодиться как для решения проблем с boot или antivirus storm, когда несколько ВМ могут репетировать большое кол-во запросов вода вывода к дисковой подсистеме, так и для приоритизации операций ввода-вывода для ВМ в целях обеспечения лучшего уровня производительности для привилегированных пользователей.

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

Дополнительные материалы:
  1. VMware vSAN Design and Sizing Guide: https://storagehub.vmware.com/export_to_pdf/vmware-r-virtual-san-tm-design-and-sizing-guide
  2. VMware Horizon 6 Storage Considerations (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-view-mirage-workspace-portal-app-volumes-storage.pdf).
  3. VMware vSphere Storage DRS Interoperability (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vsphere-storage-drs-interoperability-white-paper.pdf).

понедельник, 16 апреля 2018 г.

Обновление NVIDIA GRID

В августе прошлого года я писал о NVIDIA GRID - решении по работе с графикой в виртуальных машинах с использованием ускорителей NVIDIA Tesla.

В марте NVIDIA представила новую версию GRID (6.0), а также обновила документацию по продуктам:

понедельник, 9 апреля 2018 г.

Настройка ОС с использованием механизма PowerShell DSC

Одним из нововведений, появившихся в PowerShell 4.0, стал механизм настройки требуемого состояния (DSC - Desired State Configuration), позволяющий задавать настройки ОС и приложений в виде конфигурационного файла с использованием синтаксиса PowerShell и затем применить их к компьютеру. Как и в других системах управления конфигурациями вроде Puppet или Ansible администратор описывает требуемую конфигурацию (целевое состояние) вместо указания конкретных команд или скриптов, которые должны быть выполнены.

воскресенье, 1 апреля 2018 г.

vSphereum - новая виртуальная крипто-валюта

В последние годы технологии Blockchain обрели огромную популярность. Рост курса отдельных криптовалют привел к тому, что миллионы людей втянулись в процесс добычи и торговли "виртуальным золотом". Неудивильно, что многие крупные компании всерьез заинтересовались данным направлением, ведь один только намек на Blockchain сводит с ума акционеров, и заставляет их скупать акции за любые деньги.

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

пятница, 30 марта 2018 г.

Релиз ОС для тонких клиентов ThinOS 8.5

В начале марта вышла новая версия ОС для тонких клиентов - ThinOS 8.5. Данная ОС поддерживается всеми актуальными моделями ТК производства Dell, а именно: Wyse 3010, 3020, 3030 LT, 3040, 5010, 5040, 5060 и 7010.

Из основных нововведений, появившихся в ThinOS.

Мастер первоначальной настройки (First Boot Wizard). Теперь при первом запуске ТК можно выполнить его первоначальную настройку - задать язык интерфейса, раскладку клавиатуры, указать сервер управления, добавить брокер для удаленного подключения, либо импортировать готовый файл с настройками wnos.ini с USB накопителя.

воскресенье, 25 марта 2018 г.

Wyse ThinOS шифрование паролей в wnos.ini

Тем, кто работал с тонкими клиентами Dell Wyse с ОС ThinOS, должно быть известно о возможности настройки ТК через конфигурационный файл wnos.ini, загружаемый по сети с FTP или HTTP сервера.

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

суббота, 10 марта 2018 г.

Номинация на vExpert

Компания VMware опубликовала список участников программы vExpert. vExpert - это почетное звание, которое ежегодно присваивается специалистам по всему Миру за вклад в продвижение технологий виртуализации. Среди награжденных - более полутора тысяч известных евангелистов, блогеров, авторов книг и статей, спикеров, разработчиков, участников форумов и ваш покорный слуга.

В последний раз я удостаивался подобной награды в далеком 2011 году. Статус vExpert не дает каких-либо материальных благ (и девушки на шею штабелями не вешаются), но все-равно приятно.

Также хочу поздравить других активных участников комьюнити из России и соседних государств и пожелать им дальнейший творческих успехов:

пятница, 9 марта 2018 г.

Установка накопителя Intel DC P3700 для работы с VMware ESXi

Недавно взял себе NVME накопитель Intel DC P3700 для тестирования All-Flash vSAN.

После установки накопителя в сервер и загрузки гипервизора, P3700 не появился в списке устройств для хранения (Devices), хотя и отображался на вкладке адаптеров (Adapters).

суббота, 24 февраля 2018 г.

Примеры вопросов и материалы для подготовки к экзамену VCP7-DTM

Недавно я сдал экзамен 2V0-751 на статус VMware Certified Professional 7 - Desktop & Mobility.

С момента сдачи предыдущего экзамена VCP6-DT были добавлены вопросы по таким продуктам, как VMware App Volumes и User Environment Manager. В целом экзамен стал проще в части касающейся Horizon View, зато появилось больше технических вопросов по Identity Manager и Mirage.

На текущий момент по VCP7-DTM присутствует не так много материалов для подготовки, поэтому если вы не готовились и не сдавали экзамен на VCP6-DT, то я рекомендую ознакомиться со следующими ссылками:
Для других экзаменов VMware обычно делает тестовую версию или выкладывает примеры вопросов, однако для VCP7-DTM ничего такого я не нашел. Поэтому я сделал небольшой тест для самопроверки, включающий вопросы по основным темам. Тест можно загрузить по ссылке.

понедельник, 15 января 2018 г.

Немного о дизайне VDI. Часть 3. Верхнеуровневая архитектура

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам:
Часть 1. Введение
Часть 2. Постановка задачи

3.1 Концептуальная схема

После выработки и фиксации основных требований наступает черед разработки верхнеуровневой архитектуры.

Разработка верхнеуровневой архитектуры позволяет сформировать общее понимание назначения и принципов работы системы. Отличие верхнеуровневой архитектуры (HLD – high level design) от низкоуровневой архитектуры (LLD – low level design) заключает в широте охвата и меньшей детализации. На уровне High Level Design нет необходимости спускаться до уровня физических компонентов – указания количества и моделей серверов, процессоров, клиентских устройств, конкретных настроек ПО. HLD должен однозначно отвечать на вопросы – из каких блоков/подсистем состоит система и как они взаимодействуют друг с другом.