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

Новогодний ESXi

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

Подключитесь к хосту по ssh под учетной записью root и в командной строке напишите:
cp /etc/motd /etc/motd.backup
echo -e "   *   __       *         *      *    \n*    _|--|_  *     * /\     *         \n  \__ ('') __/ *    /\/\            * \n     (^^^^)        /_/\_\ *    *      \n  * (^^^^^^)      *  ||     *        *\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n~~ Merry Christmas & Happy New Year ~~\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n" > /etc/motd
Теперь каждый раз при подключении к Service Console или по SSH вы сможете наблюдать незамысловатую ASCII картинку.

А для того, чтобы "убрать елку", достаточно будет заменить содержимое /etc/motd из старого файла /etc/motd.backup.

вторник, 6 ноября 2018 г.

Особенности работы Sparse дисков в VMware ESXi

Сегодня я хотел бы рассказать об особенностях архитектуры "разреженных" (Sparse) дисков, использующихся для виртуальных машин на базе гипервизора ESXi.

Знание аспектов работы Sparse дисков позволит лучше понять преимущества и недостатки при использовании для защиты данных виртуальных машин (снапшоты и бекапы) или для клонирования виртуальных машин (Linked Clones).

Начнем с общей теории. ESXi поддерживает множество различных форматов виртуальных дисков: VMFS, vmfsSparse, vmfsSeSparse, RDM, VVOL, vSAN.

Формат VMFS (также известный как FLAT) имеет простую структуру и используется для thick и thin дисков. Каждый виртуальный диск хранится в виде нескольких файлов - файла дескриптора (.vmdk), бинарного файла с данными (-flat.vmdk) и опционального файла, хранящего информацию об измененных блока ( -ctk.vmdk), используемого для резервиного копирования данных.

Пример файла дескриптора.

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=ec393eec
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 4194304 VMFS "vm01-flat.vmdk"

# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "261"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "b67f98419cca278410ca1bd9fffffffe"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 94 5a a7 a8 8e-d6 41 59 5b b0 06 b3 2b"
ddb.virtualHWVersion = "14"

Бинарный файл с данными имеет плоскую структуру, такую же как файл .dd. Секторы хранятся последовательно, нулевой сектор имеет адрес 0x0000, первый - 0x0200, второй - 0x400 и так далее.

Thin диск в отличие от Thick диска не требует выделения всего дискового простанства при создании, а увеличивается по мере заполнения данными. Гранулярность с которой растет thin диск зависит от размера файлового блока, который использует файловая система VMFS. Для VMFS 5 и VMFS 6 размер файлового блока по умолчанию составляет 1 МБ. Thin диск, по мере записи в него новых данных, будет увеличиваться частями (сегментами) по 1 МБ. Это может приводить к большей фрагментации файлов thin дисков по сравнению с thick дисками, особенно в тех случаях, когда на хранилище VMFS располагается много thin дисков, которые постепенно увеличиваются в размере.

Поскольку thick и thin диски имеют одинаковый внутренний формат (FLAT), отсюда следует первый нюанс - возможность хранения тонких дисков - это свойство файловой системы VMFS (или NFS сервера, если его файловая система поддерживает thin provisioning), а не самого формата. Это можно легко проверить на практике, создав пустой тонкий диск размером 1 ГБ, а затем скопировать его на компьютер с ОС Windows на раздел с файловой системой NTFS, используя File browser или scp. После копирования файл будет занимать ровно 1 ГБ.

Второй нюанс заключается в том, что VMFS является кластерной файловой системой с разделяемым доступом. Для координации доступа используются метаданные файловой системы, в которых указывается - в какие файлы/области диска какой из хостов может выполнять запись. Каждый раз при выделении нового сегмента (при создании нового диска или при увеличении размера существующего тонкого диска) один из хостов ESXi выполняет блокировку всего тома, используя SCSI-3 резервацию, для обновления метаданных, что негативно сказывается на производительности операций ввода-вывода, либо только определенных секторов, используя механизм ATS VAAI (если это поддерживается со стороны СХД).

Sparse диски

Sparse диски (они же delta-диски, Redo Log файлы или снапшоты, как их называют в быту) имеют более сложную структуру по сравнению с thick и thin дисками.

Sparse диск создается "поверх" родительского диска (другого Sparse диска или базового VMFS диска), формируя своеобразную цепочку, или дерево, если из одного родительского диска создано несколько Sparse дисков. Sparse диск аккумулирует в себя все изменения (все операции записи), которые выполняются для данной цепочки, выступая т.н. Redo Log файлом, и растет по мере заполнения.

Но Sparse диски могут использоваться и без снапшотов (те же linked clones ВМ) и даже без родительского диска, например, можно создать пустой SE Sparse диск, выполнив команду:

vmkfstools -c 10g -d sesparse disk.vmdk

Sparse диски в отличие от FLAT дисков являются тонкими благодаря внутреннему формату хранения данных. При копировании такого диска с VMFS он сохраняет свой реальный размер, а не раздувается как FLAT диски.

Изначальной целью создания Sparse дисков было обеспечение максимальной экономии дискового пространства при хранении изменений. Гранулярность хранения данных для Sparse дисков составляет 512 байт. Иными словами, если после создания снапшота на диск потребуется записать всего 10 байт данных, то внутри Sparse диска будет выделен блок размером в 512 байт. Чуть позже мы более детально рассмотрим внутренний формат хранения и механизмы работы операций чтения и записи.

Однако, поскольку Sparse диски хранятся на файловой системе VMFS, то минимальный размер файла связан с размером файлового блока (по умолчанию, 1 МБ для VMFS5). Это не всегда верно, так как я намеренно опускаю ряд технических деталей по хранению файлов маленького размера внутри файловых дискрипторов или суб-блоков, чтобы не перегружать читателей. В реальности размер дискового пространства, с которым растет Sparse диск, составляет 16 МБ. Умудренный читатель спросит - почему для Sparse диска единоразово выделяется больше места, чем для Thin диска (16 МБ против 1 МБ)? Я не нашел достоверной информации по этому поводу, но могу предположить, что это сделано для того, чтобы уменьшить количество блокировок VMFS, которые возникают при увеличении размера файла и необходимости выделения новых файловых блоков - Sparse диски растут гораздо быстрее, т.к. в них записываются не только новые блоки данных, но и изменения в блоках родительских дисков.

Для связи родительского (parent) диска с дочерними используется механизм указателей. В каждом файле дескриптора .vmdk присутствуют два поля:

CID=ec393eec
parentCID=ffffffff

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

Поле parentCID позволяет выстроить цепочку зависимостей между виртуальными дисками. При создании Sparse диска в поле parentCID прописывается значение CID-идентификатора родительского диска. У базового VMFS диска значение parentCID всегда равно 'ffffffff'.

На картинке ниже приведен пример многоуровневого дерева снапшотов и значение идентификаторов.

Гипервизор проверяет на соответствие значение CID в родительском диске и parentCID в дочернем. Отличия в значении говорят о том, что родительский диск был изменен после создания дочернего диска, и консистентность данных не может быть гарантирована.

Структура Sparse диска приведена на рисунке.

Заголовок Sparse файла (COW Header) включает в себя следующие поля (это далеко не все поля, присутствующие в заголовке):
  • magicNumber [4 байта] - хранит в себе слово COWD в ASCII формате.
  • version [4 байта] - всегда равна 1.
  • flags [4 байта] - значение равно 3.
  • numSectors [4 байта] - количество секторов базового диска.
  • grainSize [4 байта] - размер блока данных (в секторах), который используется для хранения данных (для Sparse дисков ESXi равен 1 сектору).
  • gdOffset [4 байта] - смещение с которого начинается Granular Directory, равен 4 секторам.
  • numGDEntries - кол-во GDE (равен numSectors / gtCoverage).
  • freeSector - адрес смещения следующего свободного сектора, где может размещаться GT или полезные данные.
Рассмотрим пример заголовка Sparse диска, созданного с базового диска размером 32 МБ.

Более детальная информация по структуре заголовка приведена в документе Virtual Disk Format 5.0.

Sparse файлы используют двухуровневую иерархию метаданных для адресации блоков с данными:
  • L0 - Granular Directory (GD)
  • L1 - Granular Table (GT)
GD идет следом за заголовком COW Header. GD состоит из ячеек Granular Directory Entry (каждая размером 4 байта). Ячейки GDE используются для хранения смещения (в 512 байтный секторах) по которому располагается таблица Granular Table. Ячейки GDE всегда располагаются последовательно. Адрес первой GDE ячейки указан в поле заголовка (gdOffset) и равен 4 секторам = 0x800 = 2048 байтам. Размер/количество ячеек GDE в Granular Directory зависит от максимально возможного размера Sparse диска, а также от размера блока данных, который может адресовать одна запись в таблице (gtcoverage).

Granual Table, на которую ссылается GDE, в свою очередь, состоит из 4096 ячеек Granular Table Entry, каждая из которых хранит смещение, по которому располагается блок данных (Grain Data). Размер блока данных, адресуемого GTE, указывается в заголовке в поле grainsize. Для Sparse дисков, создающихся гипервизором ESXi размер блока данных составляет 1 сектор (512 байт). GT создаются по мере необходимости, при первой операции записи в 2 МБ диапазон данных. Каждая GT адресует свою определенную область данных, первая GT - первые 2 МБ, вторая GT - следующие 2 МБ, и так далее, хотя технически сами GT могут размещаться в любом месте Sparse диска.

Из-за размера ячейки GDE и GTE в 4 байта (32 бита) с учетом использования 512 байт секторов можно легко посчитать максимальный размер Sparse диска = 2^32 * 512 = 2 ТБ.

Максимальное кол-во GDE, которое может быть создано внутри файла, рассчитывается по формуле:

GDE = numSectors * 512 Байт / 2 МБ

Рассмотрим пример с адресацией GDE, GTE и блоков данных внутри Sparse диска. Создадим Sparse диск и с помощью какой-нибудь низкоуровневой утилиты из гостевой ОС запишем в первый сектор диска тестовые данные - 512 байт со значением 0xff. Поскольку мы знаем, что это первый блок на диске, то его адрес будет хранится в первой GTE, в таблице GT, которая адресуется первой GDE. Для того, чтобы найти нужный блок с данными, определим адрес первой GDE по смещению gdOffset (0x800). Далее из GDE определим адрес GT (0x1000). Первая ячейка GTE указывает на расположение первого блок Sparse диска (находится по смещению 0x5000).

Учтите, что сектора, которые в базовом FLAT диске идут последовательно, не обязательно будут последовательно размещаться в Sparse файле. Адрес блока данных зависит от того, когда этот блок был выделен для записи. Таким образом, при случайной записи вполне реальна ситуация, которая изображена на картинке.

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

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

Для примера создадим Thick диск размером 2 ГБ, сделаем снапшот ВМ и перезапишем все блоки в Sparse диске:

2114560 -rw-------    1 root     root     2164269056 Oct 30 18:07 disk-000001-delta.vmdk
2097152 -rw-------    1 root     root     2147483648 Oct 30 17:43 disk-flat.vmdk

Размер Sparse диска больше на ~16 МБ за счет места, которое занимает заголовок, GDE и GTE ячейки.

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

Что касается записи - данные всегда записываются в последний в цепочке файл. Гранулярность записи составляет 512 Байт.

В документации можно встретить упоминание, что снапшоты используют механизм Copy-on-Write (COW) для хранения данных. Это запутывает многих администраторов, которые считают, что использование отдельного файла, хранящего изменения, ближе к механизму Redirect-on-Write (ROW), чем к Copy-on-Write. Sparse диски используют COW, когда выполняют запись данных меньших, чем размер сектора. Например, вам требуется записать в сектор всего 10 изменных байт. Для обеспечения целостности данных, перед тем, как выполнить запись, должен быть инициирован целый сектор - в него будут скопированы данные из родительского диска, и только после этого могут быть записаны измененные блоки данных. Поэтому - Copy-on-Write.

На сегодня это вся информация, которой я хотел поделиться, в следующей части я расскажу о Space Efficient Sparse дисках, которые появились в vSphere 5.1.

При подготовке использовались следующие материалы:
  1. https://kb.vmware.com/s/article/1015180
  2. https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf
  3. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/sesparse-vsphere55-perf-white-paper.pdf
  4. http://sanbarrow.com/vmdk-handbook.html

понедельник, 8 октября 2018 г.

Замена сертификатов в vSphere Integrated Containers

Работа с сертификатами является важной составной частью процедуры настройки платформы для запуска контейнеров VMware vSphere Integrated Containers. Сертификаты используются в VIC для подключения администраторов к веб-консоли VIC, проверки подлинности хранилища образов Harbor, аутентификации пользователей в Virtual Container Host.

VIC Appliance и VCH могут использовать самозаверенные сертификаты, которые автоматически создаются при развертывании данных компонентов, либо импортированные сертификаты от доверенного Удостоверяющего Центра. Использование сертификатов, выданных доверенным УЦ, позволяет обеспечить больший уровень защищенности и упростить эксплуатацию платформы, избавившись от необходимости повсюду добавлять самозаверенные сертификаты в доверенные или отключать проверку подлинности. Ниже я опишу основные шаги по замене сертификатов для новой и уже существующей инфраструктуры VIC.

Выдача сертификатов

Ниже я рассмотрю пример выдачи сертификатов для VIC Appliance и для VCH на базе УЦ Microsoft Windows Server. Во-первых, требуется включить на сервере поддержку Subject Alternative Name сертификатов, т.к. обращение к компонентам VIC будет осуществляться и по DNS именам, и по IP адресам. Во-вторых, будет проще создать отдельный шаблон сертификата из типового шаблона Web Server и разрешить в нем экспорт закрытого ключа.

При запросе сертификата у УЦ, разрешите экспорт закрытого ключа (Mark key as exportable) и укажите несколько дополнительных имен в поле атрибутов (например, короткое имя и IP адрес сервера VIC), например:
SAN:dns=vic02.company.local&dns=vic02&ipaddress=192.168.1.21

После запроса сертификата экспортируйте его вместе с закрытым ключом в формат PFX. Повторите аналогичную процедуру для каждого сервера VCH.

Замена сертификатов для VIC Appliance

Замена сертификатов для VIC выполняется путем редактирования настроек vApp Options виртуального апплайнса. Для развертываемого с нуля апплайнса достаточно скопировать содержимое файлов с сертификатом, закрытым ключем и сертификатом УЦ в соответствующие поля в мастере настройке VIC при импорте шаблона.

Сертификаты сервера VIC и удостоверяющего центра должно быть сохранены в PEM формате в стандарте PKCS#12. Для закрытого ключа поддерживаются стандарты PKCS#1 и PKCS#8, при этом сам закрытый ключ не должен быть зашифрован.

Если у вас уже есть PFX файл с закрытым ключом (cert.pfx), то вы можете воспользоваться утилитой OpenSSL для конвертации и экспорта сертификатов и ключей в требуемый формат.

Для экспорта сертификата из PFX файла в PEM формат используйте команду:
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem

Для экспорта закрытого ключа используйте команду:
openssl pkcs12 -in cert.pfx  -nocerts -out enckey.pem

Затем для конвертации закрытого ключа в формат PKCS#8 используйте команду:
openssl pkcs8 -topk8 -in enckey.pem -out key.pem -nocrypt

Наконец, сохраните сертификат доверенного УЦ в формате Base64 (ca.pem).

После этого откройте файлы cert.pem, key.pem и ca.pem в любом тестовом редакторе и скопируйте содержимое файлов в соответствующие поля в форме (копируемый текст сертификатов должен начинаться с -----BEGIN CERTIFICATE----- и заканчиваться -----END CERTIFICATE-----).

Для уже развернутого VIC Appliance потребуется предварительно выключить ВМ, затем зайти в ее настройки в vSphere Web Client (Edit Settings -> vApp Options -> 1. Appliance Configuration) и скопировать содержимое сертификатов в нужные поля.

После загрузки ВМ, подключитесь к Web-интерфейсу и проверьте, что новый сертификат отображается корректно.

Замена сертификатов для Virtual Container Host

Экспорт файлов сертификата и закрытого ключа для VCH выполняется теми же командами OpenSSL, что и для VIC Appliance.

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

Заменить сертификаты для существующего VCH можно при помощи утилиты командной строки vic-machine, входящей в состав vSphere Integrated Containers Engine bundle (сам бандл можно загрузить с веб-портала VIC Appliance, подключившись по адресу https://<vic_ip>:9443).

Для замены сертификата вам потребуется определить ID виртуальной машины VCH. Сделать это можно при помощи команды:
vic-machine-windows.exe ls --target vc.vm.local -u administrator@vsphere.local --thumbprint 1B:00:FD:5D:6F:C4:1E:0A:E1:0D:4B:64:1E:D2:BC:2F:12:2C:1B:FC --compute-resource test

, где --target указывает на адрес сервера vCenter, где установлен VIC;
-u задает логин учетной записи для подключения к серверу vCenter;
--thumbprint задает отпечаток сертификата vCenter;
--compute-resource задает имя кластера, на котором установлен VCH.

Для замены сертификата используйте команду:
vic-machine-windows.exe configure --target vc.vm.local -u administrator@vsphere.local --thumbprint 1B:00:FD:5D:6F:C4:1E:0A:E1:0D:4B:64:1E:D2:BC:2F:12:2C:1B:FC --compute-resource test --id "vm-2343" --tls-server-cert cert.pem --tls-server-key key.pem --tls-cname vch03.company.local --tls-ca ca.pem

, где --tls-server-cert указывает путь к файлу сертификата;
--tls-server-key указывает путь к закрытому ключу;
--tls-cname задает FQDN имя для сервера VCH;
--tls-ca указывает путь к сертификату УЦ.

Учтите, что при указании сертификата доверенного УЦ, автоматически выключается анонимный доступ и включается режим аутентификации Docker клиентов по сертификатам.

Это значит, что каждому Docker клиенту потребуется выдать по сертификату с закрытым ключом для доступа к VCH. Выдаваемый сертификат должен быть предназначен для аутентификации клиентов (Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2)).

Сохраните выданный сертификат на клиенте Docker (в виде файлов cert.pem и key.pem), а также сертификат УЦ (в файле ca.pem) в каталоге ~/.docker/ , либо настройте переменные окружения, указав путь к каталогу, где хранятся файлы:
export DOCKER_HOST=<IP VCH:2376>
export DOCKER_CERT_PATH=<путь к папке с cert.pem>
export DOCKER_KEY_PATH=<путь к папке с key.pem>
export DOCKER_CA_PATH=<путь к папке ca.pem>

Теперь запросы к VCH будут работать корректно.

вторник, 4 сентября 2018 г.

Установка и настройка DVD Store для нагрузочного тестирования ВМ (часть II)

Продолжаем говорить о настройке бенчмарка DVD Store. Сегодня - подготовка шаблона ВМ для автоматизированного развертывания.

Предыдущая часть доступна по ссылке: http://blog.vmpress.org/2018/08/dvd-store-i.html

Установка DVD Store на один тестовый сервер - не такая уж и сложная задача. Но когда речь заходит о необходимости одновременного запуска и тестирования DVD Store на десятках серверов, было бы неплохо каким-либо образом автоматизировать данную задачу. И тут как нельзя кстати подойдет возможность клонирования заранее созданного эталонного образа или шаблона ВМ в связке с Customization Specification.

Но просто так взять и конвертировать существующую ВМ с установленным SQL Server в шаблон не получится, SQL Server плохо переносит кастомизацию с помощью Sysprep. Выходом будет установка компонентов SQL Server в режиме PrepareImage с последующей автоматической настройкой в момент запуска Sysprep.

Для начала выполните начальные шаги по созданию и настройке эталонной ВМ и гостевой ОС аналогичные тем, что были описаны в первой части, включая установку ActivePerl и копирование файлов DVD Store в каталог C:\ds2\.

Запустите процедуру установки компонентов SQL Server:
Setup.exe /QS /ACTION=PrepareImage l /FEATURES=SQL,FullText /InstanceID="MSSQLSERVER" /IACCEPTSQLSERVERLICENSETERMS

Дождитесь, пока установщик скопирует необходимые файлы.

Чтобы сэкономить время, заранее создайте тестовую базу необходимого размера на тестовом сервере, и затем скопируйте все файлы БД и журналов на эталонную ВМ в папку E:\SQL\dbfiles\.

Создайте файл setup.sql в корне диска E:\ со следующим содержимым:
--Attach database
USE master
GO

sp_attach_db 'DS2', 'E:\SQL\dbfiles\ds.mdf'
GO

--Change password
ALTER LOGIN sa WITH CHECK_POLICY=OFF
ALTER LOGIN sa WITH PASSWORD=N''
GO

Создайте файл setupcomplete.cmd в папке C:\Windows\Setup\Scripts\ со следующим содержимым:
cd "C:\Program Files\Microsoft SQL Server\140\Setup Bootstrap\SQL2017\"

Setup.exe /ACTION="CompleteImage" /QS /IACCEPTSQLSERVERLICENSETERMS /INSTANCENAME="MSSQLSERVER" /INSTANCEID="MSSQLSERVER" /AGTSVCACCOUNT="NT Service\SQLSERVERAGENT" /AGTSVCSTARTUPTYPE="Manual" /SQLSVCSTARTUPTYPE="Automatic" /SQLCOLLATION="Latin1_General_CI_AS" /SQLSVCACCOUNT="NT Service\MSSQLSERVER" /SQLSYSADMINACCOUNTS="Administrator" /SECURITYMODE="SQL" /ADDCURRENTUSERASSQLADMIN="False" /TCPENABLED="1" /NPENABLED="0" /BROWSERSVCSTARTUPTYPE="Disabled" /SAPWD="P@ssw0rd"

icacls E:\SQL /grant "NT Service\MSSQLSERVER":(OI)(CI)F

"C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\SQLCMD.EXE" -S localhost -U sa -P "P@ssw0rd" -i E:\setup.sql

"C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\SQLCMD.EXE" -S localhost -U sa -P "" -i "C:\ds2\sqlserverds2\build\sqlserverds2_create_user.sql"

Данный скрипт будет автоматически запущен на последнем этапе Sysprep и выполнит следующие действия:
  1. Завершит установку SQL Server с нужными настройками.
  2. Выдаст разрешение на папку E:\SQL\ учетной записи MSSQLSERVER, под которой запускаются службы SQL (это нужно для корректного подключения БД).
  3. Запустит скрипт setup.sql, который подключит базу и сбросит пароль для учетной записи sa.
  4. Запустит скрипт sqlserverds2_create_user.sql, который создаст учетную запись ds2user и предоставит ей необходимые права на БД.

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

На этом настройка завершена. Теперь вы можете создавать новые экземпляры тестовых СУБД из эталонной ВМ.

Параметры для запуска теста

Последнее, о чем хотелось бы поговорить - это параметры, которые можно указывать в файле или передавать при запуске утилиты ds2sqlserverdriver.exe для тестирования:
  • target= - имена или IP адреса СУБД, к которым будут выполняться тестовые запросы. Можно указать несколько серверов, разделяя их точкой с запятой, например: 192.168.1.10;192.168.1.11;192.168.1.12;sql01;sql02. Если не задан, то в качестве значения по умолчанию используется localhost.
  • n_threads= - количество одновременных потоков, которые использует утилита для подключения к каждому серверу, чем больше потоков, тем больше нагрузка на СУБД. Значение по умолчанию: 1.
  • ramp_rate= - прирост пользователей в секунду, с которым происходит увеличение кол-ва обращений к СУБД. Значение по умолчанию: 10.
  • run_time=60 - задает время проведения теста в минутах. Значение по умолчанию: 0 - бесконечность.
  • db_size=2GB - размер БД в гигабайтах.
  • warmup_time=10 - время в минутах в начале теста, которое дается на "разогрев". Значение по умолчанию: 0.
  • think_time= - время в секундах, которое тратит тестовый пользователей между операциями (поиск, заказ DVD и пр.). Значение по умолчанию: 0.
  • pct_newcustomers= - процентное соотношение новых пользователей, заходящих в магазин. Значение по умолчанию: 20.
  • n_searches= - среднее количество операций поиска по каталогу товаров, которые приходятся на одного пользователя. Значение по умолчанию: 3.
  • search_batch_size= - среднее количество объектов, которые возвращаются в одном поисковом запросе. Значение по умолчанию: 5.
  • n_line_items= - среднее количество товаров в одном заказе. Значение по умолчанию: 5.
  • windows_perf_host= - перечень серверов Windows, по которым требуется отображать статистику загрузки CPU.
  • linux_perf_host= - перечень серверов Linux, по которым требуется отображать статистику загрузки CPU.
  • detailed_view= - отображать детальную статистику по каждому тестовому СУБД.

вторник, 28 августа 2018 г.

Установка и настройка DVD Store для нагрузочного тестирования ВМ (часть I)

Сегодня я хочу рассказать о DVD Store - популярном средстве тестирования производительности серверов. DVD Store представляет собой набор скриптов и утилит, позволяющих создать базу данных для Интернет магазина по продаже DVD дисков и в условиях приближенных к боевым провести нагрузочное тестирование СУБД. DVD Store поддерживает различные СУБД (Oracle Database, Microsoft SQL Server, MySQL и PostgreSQL) и может быть установлен на физическом сервере или в ВМ под управлением ОС Windows или Linux. DVD Store также используется в качестве одного из тестов известного бенчмарка VMmark, разрабатываемого компанием VMware.

Тест DVD Store имет двухзвенную архитектуру (сервер приложений, выполняющий запросы, и СУБД), оба компонента могут быть установлены локально на одном сервере, либо на разных (для более корректного тестирования производительности или для оценки масштабирования физического сервера). Сервер приложений имитирует действия пользователей, заходящих в Интернет магазин и покупающих DVD диски. Производительность измеряется в opm - orders per minutes / заказах в минуту, которые может обработать СУБД. DVD Store также замеряет утилизацию процессора, среднее и максимальное время обработки одного заказа.

В первой части я опишу процесс установки и подготовки DVD Store на одном сервере под управлением ОС Windows Server 2016 для тестирования СУБД Microsoft SQL Server 2017 для запуска локальных тестов. Процедура установки подходит и для более ранних версий СУБД и ОС. Во второй части я более подробно остановлюсь на процедуре подготовки эталонной ВМ для автоматизированного развертывания и тестирования DVD Store на большом количестве серверов.

На текущий момент доступна уже третья версия DVD Store (ds3), хотя большая часть руководств и замеров производительности, которые можно найти в Интернет, касается второй версии (ds2.1). Из-за различий в механизме тестирования некорректно сравнивать значения opm, полученные в версиях ds3 и ds2.1. Поэтому я детально опишу процедуру установки ds2.1 и кратко опишу отличия в установке для версии ds3.

Настройка ВМ и SQL Server

Загрузите триальные версии Windows Server 2016SQL Server 2017 и актуальную версию SQL Management Studio с сайта Microsoft.

Выполните установку сервера Windows Server 2016 в виртуальной машине. Рекомендуется создать отдельный виртуальный диск и назначить ему букву (например, E:\) под хранение базы и журналов.

Установите на сервер необходимые обновления и дополнительное ПО (антивирусные агенты, ПО мониторинга, средства резервного копирования и т.д.) для того, чтобы сервер был в условиях близких к производственной среде.

Установите .Net Framwork 3.5:
dism /online /enable-feature /featurename:NetFx3 /All

(Опционально) Включите RDP и доступ к файловым ресурсам по сети:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
netsh advfirewall firewall set rule group="remote desktop" new enable=yes
netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=yes

(Опционально) Включите удаленное управление сервером Windows Remote Management:
winrm /quickconfig -force

Установите SQL Server Management Studio:
SSMS-Setup-ENU.exe /install /quiet /norestart /log log.txt

Установите SQL Server 2017. Требуется установить компоненты SQL Database и Full-Text and Semantic Extractions for Search.

Пример параметров для автоматической установки SQL Server из ISO образа (где D:\ - буква CD-привода):
D:\Setup.exe /ACTION=Install /FEATURES=SQL,FullText /QS /IACCEPTSQLSERVERLICENSETERMS /INSTANCENAME="MSSQLSERVER" /INSTANCEID="MSSQLSERVER" /AGTSVCACCOUNT="NT Service\SQLSERVERAGENT" /AGTSVCSTARTUPTYPE="Manual" /SQLSVCSTARTUPTYPE="Automatic" /SQLCOLLATION="Latin1_General_CI_AS" /SQLSVCACCOUNT="NT Service\MSSQLSERVER" /SQLSYSADMINACCOUNTS="Administrator" /SECURITYMODE="SQL" /ADDCURRENTUSERASSQLADMIN="False" /TCPENABLED=1 /NPENABLED=0 /BROWSERSVCSTARTUPTYPE="Disabled" /SAPWD="P@ssw0rd"

Добавьте на брандмауэре Windows правило, разрешающее удаленный доступ к SQL Server:
netsh advfirewall firewall add rule name="SQL Server" dir=in protocol=tcp localport=1433 action=allow

Задайте для учетной записи sa пустой пароль. Учетная запись sa используется для создания и импорта тестовой БД DVD Store:
"C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\SQLCMD.EXE" -S localhost -Q "USE master; ALTER LOGIN sa WITH CHECK_POLICY=OFF; ALTER LOGIN sa WITH PASSWORD=N''"

Последний шаг, создайте на диске E:\ каталог SQL\dbfiles\, в котором будут храниться тестовая база и журналы.

Установка DVD Store version 2.1

Загрузите и установите ActiveState Perl с настройками по умолчанию.

Загрузите DVD Store с сайта: http://linux.dell.com/dvdstore/. Вам потребуются два архива:
  • ds21.tar.gz - содержит основные компоненты DVD Store.
  • ds21_sqlserver.tar.gz - содержит компоненты для трестирования SQL Server.
Разахивируйте ds21.tar.gz и скопируйте папку ds2 в корень диска C:\ на сервере. Разархивируйте ds21_sqlserver.tar.gz и скопируйте папку sqlserverds2 в папку ds2.

Запустите скрипт Install_DVDStore.pl из каталога C:\ds2\.

Укажите размер тестовой базы и тип СУБД (MSSQL).

В DVD Store второй версии есть баг, связанный с созданием CSV файлов, содержащих тестовые данные. Поэтому в поле Please enter system type on which DB Server is installed (WIN / LINUX) требуется указать LINUX, в противном случае файлы CSV будут содержать некорректные символы переноса строк, из-за которых на этапе импорта будет возникать ошибка.

Дождитесь завершения создания тестовых файлов. Учтите, что все сгенерированные файлы будут храниться в папке C:\ds2\data_files, поэтому вам можте потребоваться увеличить размер диска, если вы планируете создавать большую тестовую базу.

В каталоге C:\ds2\sqlserverds2\ будет создан конфигурационный файл sqlserverds2_create_all_<размер_БД>.sql, например sqlserverds2_create_all_2GB.sql, содержащий команды Transact-SQL для создания базы данных, журналов и импорта данных. Запустите команду, указав путь к файлу:
osql -Usa -P -i sqlserverds2_create_all_2GB.sql

Дождитесь, когда команда завершится.

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

На этом настройку DVD Store version 2.1 можно считать завершенной.

Установка DVD Store version 3

Установка ds3 во многом повторяет процедуру установки ds2 за исключением некоторых исправленных багов, а также отличий в именах каталогов и файлов (ds3 вместо ds2). Загрузите ds3 со страницы проекта на GitHub: https://github.com/dvdstore/ds3/archive/master.zip.

Загрузите и установите ActiveState Perl с настройками по умолчанию.

Распакуйте архив в папку C:\ds3, в архиве уже присутствует папка sqlserverds3 со скриптами для настройки и тестирования БД Microsoft SQL Server.

Запустите скрипт Install_DVDStore.pl из каталога C:\ds2\. Укажите размер создаваемой тестовой БД.

В ds3 исправлен баг с некорректными символами переноса строк, потому в скрипте следует указать тип сервера: WIN. 

Дождитесь завершения создания тестовых файлов.

В каталоге C:\ds3\sqlserverds3\ будет создан конфигурационный файл sqlserverds3_create_all_<размер_БД>.sql. Запустите команду, указав путь к файлу:
osql -Usa -P -i sqlserverds3_create_all_2GB.sql

Дождитесь, когда команда завершится.

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

На этом настройку DVD Store version 3 можно считать завершенной.

Запуск теста

Тестирование БД осуществляется при помощи утилиты ds2sqlserverdriver.exe, расположенной в папке C:\ds2\sqlserverds2\. Для третьей версии, соответственно, C:\ds3\sqlserverds3\ds3sqlserverdriver.exe.

Утилита принимает в качестве параметров различные настройки, с которыми будет запускаться тест. Для простоты настройки могут быть описаны в отдельном тестовом файле. Вот пример настроек, которые могут использоваться для тестирования созданной базы:
target=localhost
n_threads=1
ramp_rate=10
run_time=60
db_size=2GB
warmup_time=10
think_time=0
pct_newcustomers=20
n_searches=3
search_batch_size=5
n_line_items=5
virt_dir=ds2
page_type=php
windows_perf_host=localhost
linux_perf_host=
detailed_view=Y

Сохраните их в текстовом файле DriverConfig.txt в папке C:\ds2\sqlserverds2\. Запустите утилиту из командной строки:
ds2sqlserverdriver.exe --config_file=DriverConfig.txt

Если все настройки были выполнены корректно, то в окне появится метрики, полученные от тестов.


понедельник, 13 августа 2018 г.

Немного о дизайне VDI. Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление

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

11.1 Доступность компонентов

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

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

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

В случае отказа клиентского устройства должны быть предусмотрены варианты оперативного восстановления работы, например:
  • Наличие резерва на замену. Для территориально удаленных площадок может потребовать организацию склада на местах для снижения времени доставки устройства до рабочего места.
  • Наличие сервисного контракта с поставщиком для оперативной замены или ремонта устройства.
  • Организация подключения пользователя с другого рабочего места, оборудованного клиентским устройством. Стандартизация моделей и конфигурации клиентских устройств позволит упростить реализацию данного варианта.
Другой пример – отказ WAN канала до удаленной площадки приведет к невозможности подключения к VDI инфраструктуре. Для снижения риска возможно арендовать WAN канал через другого провайдера или на время недоступности канала организовать подключение пользователей к VDI через Интернет (например, разрешить сотрудникам подключаться и работать из дома).

Выход из строя физического сервера из-за отказа аппаратного обеспечения или сбоя гипервизора влечет за собой недоступность виртуальных машин, которые работали на сервере. Аппаратные компоненты сервера (адаптеры ввода-вывода, устройства хранения, блоки питания, вентиляторы системы охлаждения, модули оперативной памяти) могут резервироваться, что снижает вероятность выхода сервера из строя из-за отказа одного из компонентов, а также позволяет производить обслуживание и замену компонентов на горячую. При наличии нескольких блоков питания с возможностью резервирования по схеме N+N рекомендуется подключать их к независимым линиям электропитания. Это же касается подключения сетевых адаптеров к Ethernet коммутаторам и адаптеров ввода-вывода к коммутаторам сети хранения – подключение сервера к нескольким коммутаторам и настройка teaming’а и multipathing’а позволит проводить обслуживание коммутаторов без необходимости выключать сервер.

Для снижения времени простоя ВМ могут использоваться следующие механизмы повышения доступности:
  • Настройка vSphere High Availability для автоматизации запуска ВМ на других физических сервера.
  • Настройка Fault Tolerance для критичных ВМ.
  • Резервирование на уровне приложений, запущенных внутри ВМ. Установка дополнительных экземпляров серверов View Connection Server, создание избыточных виртуальных десктопов в Floating Pool, кластеризация SQL Server и т.п. При резервировании на уровне приложений совместно с DRS следует помнить о необходимости использования правил Anti-Affinity Rules, что поможет избежать ситуации, при которой узлы кластеризованного приложения окажутся на одном физическом сервере и могут стать недоступны одновременно из-за сбоя сервера.
Для большинства приложений в случае сбоя ВМ или гостевой ОС может использоваться один из следующих вариантов восстановления:
  • Восстановление ВМ из актуальной резервной копии. Ряд СРК предоставляют возможность снижения RTO за счет быстрого запуска ВМ непосредственно с хранилища резервных копий, так называемое мгновенное восстановление (например, Veeam VM Instant Recovery).
  • Настройка репликации ВМ (например, средствами vSphere Replication или Veeam Backup & Replication), переключение на реплику.
  • Создание мгновенного снимка перед обновлением или изменением настроек для быстрого отката изменения внутри ВМ.
Для некоторых компонентов высокая доступность и отказоустойчивость могут быть обеспечены на уровне приложений.

Например, в VDI инфраструктуре может быть развернуто несколько экземпляров пограничных серверов (View Security Server или Unified Access Gateway) и настроено балансирование нагрузки между серверами при помощи внешнего балансировщика. Это же касается серверов View Connection Server, в одном Pod может быть развернуто до семи серверов, которые будут реплицировать конфигурацию друг с другом, в случае отказа, вышедший сервер может быть удален из кластера и заменен новым сервером-репликой.

Для серверов vCenter Server и PSC в Embedded режиме можно настроить двухузловой кластер vCenter High Availability (для vCenter Server Appliance 6.5 или выше), обеспечивающий репликацию конфигурации и автоматическое переключение на резервный узел. Для сервера vCenter Server под Windows можно настроить защиту служб средствами Microsoft Failover Cluster (для vCenter 5.5 U3 или выше). Для внешних серверов PSC можно развернуть несколько экземпляров серверов в одном SSO домене с репликацией и балансировкой подключений с использованием внешнего балансировщика.

СУБД SQL Server, обслуживающий базы vCenter Server, View Composer и View Event Log, можно кластеризовать с использованием SQL Failover Cluster в конфигурации с общим диском, либо с использованием групп доступности SQL AlwaysOn.

Из всех основных компонентов Horizon, пожалуй, только View Composer не имеет собственных механизмов защиты на уровне приложений и не поддерживает кластеризацию. Для него могут применяться средства защиты на уровне ВМ или на уровне гипервизора.

11.2 Резервное копирование VDI

Резервное копирование серверов View Connection Server выполняется автоматически встроенными средствами. По умолчанию каждый сервер View выполняет архивирование раз в день. Файл с архивом сохраняется локально, поэтому рекомендуется перенести его на сетевое хранилище. Данный бекап может использоваться для восстановления конфигурации View на свежеустановленный сервер Connection Server.

Помимо архива с конфигурацией ценность представляет также цифровые сертификаты и файл конфигурации locked.properties (если вы вносили в них изменения), однако они редко меняются и не требуют регулярного резервного копирования. В качестве альтернативного вариант можно выполнять резервное копирования сервера View целиком в виде виртуальной машины или через агента СРК, установленного в гостевой ОС. 
При восстановлении сервера В инсталляциях Horizon, включающей несколько серверов View в одном Pod, следует помнить о репликации LDAP базы между несколькими серверами, при восстановлении сервера View из бекапа (https://docs.vmware.com/en/VMware-Horizon-7/7.1/com.vmware.horizon-view.installation.doc/GUID-04ADFC96-5EBA-4561-B02C-B70CBE3B1D6A.html).

Сервер View Security Server в отличие от Connection Server не имеет встроенного механизма резервного копирования, т.к. Security Server не хранит никаких данных на самом сервере (за исключением сертификата и того же файла locked.properties). Бекап сервера View Security Server может выполняться целиком в виде ВМ или через агента, установленного в гостевой ОС. В качестве альтернативного варианта можно рассмотреть установку сервера Security Server с нуля с восстановлением конфигурационных файлов и цифрового сертификата.

Сервер Unified Access Gateway, как правило, не нуждается в регулярном резервном копировании, т.к. повторная установка с нуля в большинстве случаев будет проще и быстрее.

Сервер View Composer. Конфигурация Composer хранится в базе поэтому требуется бекапить СУБД, где размещается БД Composer. В качестве альтернативного варианта можно использовать функцию экспорта конфигурации из БД Composer при помощи утилиты командной строки sviconfig. На самом сервере важно сохраниться сертификат. Сервер может быть забекаплен целиком, либо можно забекапить цифровой сертификат.

Сервер vCenter Server поддерживает полное резервное копирование и восстановление на уровне ВМ. При восстановлении из бекапа следует помнить о том, что конфигурация vCenter, восстанавливаемая из бекапа (распределенного коммутатора, состава и настроек кластеров, пулов ресурсов), и текущая конфигурация виртуальной инфраструктуры могут различаться. Помимо восстановления ВМ целиком, в vCenter Server Appliance, начиная с версии 6.5, появился встроенный бекап (File-Based Backup), который позволяет сохранить архив с настройками vCenter на внешнем хранилище, а затем использовать его при развертывании нового апплайнса с нуля.

Что касается резервного копирования и восстановления виртуальных десктопов, то тут следует учитывать следующие моменты:
  • Не имеет практического смысла выполнять резервное копирование для floating и non-persistent десктопов, т.к. такие ВМ не предназначены для хранения на них постоянных данных. Гораздо более уместным будет периодическое копирование эталонного образа и проработка возможности оперативного создания большого числа ВМ (например, при помощи механизмов Linked Clone или Instant Clone). При необходимости сохранения изменений в таких виртуальных десктопах, могут использоваться Writable Volumes, доступные в ПО App Volumes. Сами Writable Volumes могут бекапиться с использованием вспомогательных утилит (например, https://labs.vmware.com/flings/app-volumes-backup-utility).
  • Если требуется сохранять только данные и настройки пользователей, то более простым вариантом является предварительная настройка перемещаемых профилей и перенаправление рабочих каталогов пользователей с виртуальных десктопов на выделенный файловый сервер, откуда, в свою очередь, они смогут централизованно бекапиться.
  • Если вариант с переносом данных на файловый сервер не подходит, например, из-за необходимости бекапить и восстанавливать данные за пределами пользовательских каталогов, вы можете использовать агент СРК, установленный в гостевой ОС. Большинство современных СРК поддерживают резервное копирование клиентских ОС (например, Veeam Agent for Microsoft Windows, Symantec Backup Exec, Microsoft SCDPM и другие). Данный вариант следует применять с осторожностью для Linked Clones ВМ, т.к. восстановление большого объема данных приведет к разрастанию delta-дисков.

11.3 Аварийное восстановление VDI инфраструктуры

Рассмотрим два основных способа организации аварийного восстановления:
  • Развертывание Horizon в режиме федерации, включающей несколько Cloud Pod.
  • Создание территориально-распределенного кластера vSphere.
Организация федерации из двух и более Pod, размещенных на разных площадках, и использующих разные вычислительные ресурсы для запуска десктопов доступна в VMware Horizon, начиная с 6 версии. Данный вариант позволяет объединить несколько локальных пулов десктопов на нескольких территориально-удаленных площадках в один глобальный пул. При подключении к серверу Connection Server, входящему в федерацию, и выборе глобального пула пользователю будет предоставлена ВМ из одного из локальных пулов, например, из того Pod, к которому подключился пользователь, или с той площадки, которая является для пользователя домашней (Home Site).

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

Развертывание территориально-распределенной виртуальной инфраструктуры с использованием метро-кластеров (vSphere Metro Storage Cluster). Данный вариант подразумевает создание общего распределенного хранилища, доступного серверам виртуализации на обеих площадках, средствами системы хранения данных. Контроллеры СХД хранят копии данных на каждой из площадок и в реальном времени синхронизируют все изменения. В случае отказа СХД на любой из площадок, серверы виртуализации на второй площадке сохраняют доступ к своей копии данных и могут продолжать работу. Создание территориально-распределенных СХД поддерживается многими производителями, среди примеров реализации можно отметить NetApp MetroCluster, VMware vSAN Stretched Cluster, EMC VPLEX Metro, HPE 3PAR Peer Persistence, HDS GAD и многие другие. К плюсам подобного подхода относится прозрачность работы для ВМ и приложений, для компонентов Horizon такая инсталляция не отличается от обычного HA кластера, возможность обеспечивать катастрофоустойчивую защиту для любых типов виртуальных десктопов. К минусам данного варианта относятся высокие требования к полосе пропускания и задержкам каналов передачи данных из-за необходимости постоянной синхронизации данных между площадками. Кроме того, метро-кластеры требуют наличие территориально-распределенных L2 сетей для сохранения сетевой доступности при переносе ВМ из одной площадки на другую.

вторник, 24 июля 2018 г.

Парсер для правил NSX Distributed Firewall

Update 05.08.2018: в новой версии появилась возможность подключения к NSX Manager для экспорта текущих правил.

VMware NSX позволяет экспортировать правила распределенного фаерволла в файл в XML формате. Данный формат не очень удобен для анализа и включения в документацию, поэтому я написал небольшой парсер, конвертирующий правила из XML формата в HTML или CSV.

Скрипт имеет следующий формат:
Parse-NSXRules.ps1 -FilePath <string> -ResultPath <string> [-Property <string>] [-Format <string>]

и использует следующие параметры:
  • -ResultPath <string> - (обязательный) Указывает путь к файлу, в котором будут сохранены результаты.
  • -FilePath <string> - (опциональный) Указывает путь к XML файлу с правилами.
  • -Property <string> - (опциональный) Указывает перечень столбцов для отображения, разделенных запятыми. По умолчанию отображает все столбцы.
  • -Format <string> - (опциональный) Указывает формат итогового файла. Поддерживает CSV, HTML или XML. По умолчанию используется HTML формат.
  • -NSXManager <string> - (опциональный) Указывает IP адрес или DNS имя сервера NSX Manager для подключения.
  • -Username <string> - (опциональный) Указывает имя пользователя для подключения к NSX Manager.
  • -Password <string> - (опциональный) Указывает пароль пользователя для подключения к NSX Manager.
Примеры использования скрипта:

#Сохранить результат в HTML файле
.\Parse-NSXRules.ps1 -FilePath C:\Temp\NSX_rules.xml -Format HTML -ResultPath C:\Temp\parsed_rules.html

#Сохранить результат в CSV, отобразить только столбцы id,name,source и action
.\Parse-NSXRules.ps1 -FilePath C:\Temp\NSX_rules.xml -Format CSV -ResultPath C:\Temp\parsed_rules.csv -Property "id,name,source,action"

#Подключиться к NSX Manager и сохранить результат в формате XML
\parse-nsxrules.ps1 -Format XML -ResultPath C:\Temp\parsed_rules.csv -NSXManager 192.168.1.10 -Username admin -Password VMware1!

Пример получаемого HTML файла:

Загрузить скрипт можно по ссылке: https://github.com/omnimod/NSX-Firewall-Rules-Parser

понедельник, 2 июля 2018 г.

Немного о дизайне VDI. Часть 9. Сетевая подсистема

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

9.1 Требования к производительности сети

При грамотном подходе и планировании сетевая подсистема внутри ЦОД, как правило, не является проблемным местом, чего не скажешь о "последней миле", которая может приводить к изрядным головным болям у архитектора и сотрудников поддержки (и пользователей).

При планировании VDI следует обратить внимание на то, какие требования предъявляют и какую нагрузку создают следующие типы трафика:
  • Трафик, который генерирую виртуальные десктопы при работе с приложениями.
  • Трафик при подключении пользователей к своим виртуальным десктопам.
  • Служебные трафик, необходимый для функционирования VDI инфраструктуры.
В сценариях VDI виртуальные десктопы и серверы приложений находятся достаточно "близко" друг от друга, трафик передается внутри ЦОД по высокоскоростной сети. В этом и заключается одно из главных отличий VDI от физических рабочих станций. Централизация позволяет снизить нагрузку на канал передачи данных от пользовательских рабочих места до ЦОД. Пользователи могут заметить повышение производительности в работе приложений, в качестве примера можно рассмотреть вариант с открытием и сохранением больших документов, которые раньше передавались по сети 100 Мбит/с или 1 Гбит/с на физическую рабочую станцию, а теперь передаются на виртуальный десктоп, подключенный к сети 10 Гбит/с. Однако, несмотря на локализацию внутри ЦОД, трафик приложений все-равно следует учитывать при сайзинге количества и типа сетевых интерфейсов серверов виртуализации.
Трафик протоколов удаленного доступа (PCoIP, Blast или RDP) также следует учитывать при планировании конфигурации серверов и коммутаторов, однако большее влияние он оказывает на WAN-каналы передачи данных при организации подключения пользователей из удаленных филиалов или из Интернет. Каналы с недостаточной пропускной способностью, большими потерями и высокими задержками будут напрямую влиять на качество изображения, скорость отрисовки и время отклика протоколов удаленного доступа, а следовательно, и на удовлетворенность пользователей от работы с виртуальным десктопом.

Нагрузка, создаваемая при подключении к виртуальным десктопам, зависит от используемого протокола, количества и разрешения мониторов, настроек качества изображения и частоты обновления. В среднем, для типового пользователя Knowledge Worker утилизация составляет 150-200 Кбит/с. Просмотр изображений и видео, работа с 3D графикой увеличивает требования к каналу.

При сайзинге требуемой полосы пропускания для протокола PCoIP следует воспользоваться рекомендациями из PCoIP Session Planning Administrators' Guide (https://www.teradici.com/web-help/TER1105004/Sess-Plan_Admn-Gd.pdf) и Horizon 7 Architecture Planning (https://docs.vmware.com/en/VMware-Horizon-7/7.5/horizon-architecture-planning.pdf).
В тестовой среде или пилотной инсталляции основные метрики производительности протокола удаленного доступа и утилизация канала могут быть получены при помощи счетчиков Perfmon, или из журналов PCoIP или Blast. Также можно воспользоваться ПО vRealize Operations for Horizon, позволяющим централизованно собирать статистику о работе протоколов удаленного доступа с виртуальных десктопов.

Служебный трафик может составлять значительную часть от всего сетевого трафика, генерируемого VDI инфраструктурой. К служебному трафику можно отнести трафик vSAN, трафик Fault Tolerance, трафик репликации данных в СУБД Microsoft SQL или файловых серверов DFS-R, vCenter Server, установленном в HA режиме, репликации ВМ средствами vSphere Replication, трафик системы резервного копирования. Fault Tolerance или All-Flash vSAN могут накладывать дополнительные ограничения на минимальную скорость подключения (не менее 10 Гбит/с).

9.2 Планирование адресного пространства

Разделение адресного пространства на несколько подсетей может быть продиктовано желанием уменьшить широковещательный домен или отделить трафик виртуальных десктопов от служебных ВМ из-за требований безопасности.

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

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

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


9.3 Выбор виртуального коммутатора

В зависимости от версии гипервизора для организации сети поддерживаются следующие типы виртуальных коммутаторов:
  • стандартный виртуальный коммутатор (vSS – vNetwork Standard Switch);
  • распределенный виртуальный коммутатор (vDS – vNetwork Distributed Switch);
  • сторонний виртуальных коммутатор (Third-party Switch).
Из-за прекращений поддержки сторонних коммутаторов в ESXi после версии 6.5 U1, на текущий момент имеет смысл рассматривать выбрить только между vSS и vDS. Различия в функциональных возможностях коммутаторов приведены в таблице.
Функции
vSS
vDS
Поддерживаемые редакции vSphereEssentials или вышеEnterprise Plus
Входит в состав лицензий NSX или VSAN
Требует наличие vCenter Server для настройкиНетДа
Шейпинг входящего трафика ВМ (Egress)ДаДа
Шейпинг исходящего трафика ВМ (Ingress)НетДа
Поддержка агрегации канала / NIC TeamingТолько статическая (для IP Hash)Статическая и LACP
Варианты балансирования трафикаPort ID
MAC Hash
IP Hash
Failover
Port ID
MAC Hash
IP Hash
Failover
Based on NIC Load
LACP
Поддержка NetFlowНетДа
Поддержка Port Mirroring (SPAN, RSPAN)НетДа
Встроенный фильтр трафикаНетДа
Тегирование трафика QoSНетДа
Поддержка NIOCНетДа
Создание виртуальных логических сетей NSXНетДа
Интеграция с распределенным брандмауэром NSXДаДа

Несмотря на зависимость vDS коммутатора от vCenter Server, он предоставляет гораздо больше функциональных возможностей по сравнению со стандартным коммутатором и рекомендуется к использованию в большинстве инсталляций VDI. vSS может использоваться для небольших/тестовых инсталляциях, а также в тех случаях, когда используется vSphere Standard, в которой отсутствует vDS.

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

  • Load based on Port ID;
  • Load based on MAC Hash;
  • Load based on IP Hash;
  • Failover;
  • Load based on NIC Load.
Failover – самый примитивный режим, не обеспечивает балансировку трафика и используется только для отказоустойчивости. Все сетевые интерфейсы ВМ подключаются к первому в списке активному физическому интерфейсу (аплинку), в случае его недоступности – ко второму, и т.д.

Port ID – является типовым режимом, работающим по принципу Round Robin. Сетевые интерфейсы ВМ и VMKernel равномерно распределяются между аплинками в режиме чередования, в зависимости от того, к какому порту виртуального коммутатора они подключены. Например, для двух аплинков первая ВМ будет подключена к первому аплинку, вторая – ко второму аплинку, третья – снова к первому, и т.д.

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

MAC Hash также распределяет виртуальные адаптеры по аплинкам, как и Port ID, однако выбор аплинка выполняется на основании хэша MAC адреса виртуального сетевого интерфейса.

IP Hash динамически выбирает аплинки для отправки пакета в зависимости от IP адреса источника и назначения. Данный алгоритм балансировки требует настройки агрегации сетевых интерфейсов со стороны сетевого коммутатора (Static EtherChannel в терминологии Cisco).

Load based on NIC Load распределяет сетевые адаптеры схожим с Port ID образом за исключением того, что гипервизор отслеживает нагрузку на аплинках, и если нагрузка между аплинками различается более, чем на 70%, то автоматически переключает сетевые интерфейсы ВМ с более загруженного на менее загруженный аплинк.

Отдельно следует сказать про балансирование трафика средствами LACP Aggregation Group (LAG). LAG не являются одним из алгоритмов балансировки, доступны только в связке с распределенным коммутатором, позволяют объединить до 8 физических интерфейсов в LAG и настроить на нем способ балансирования трафика. В vSphere доступно 22 алгоритма балансировки.

9.4 VMware NSX

VMware NSX может применяться в сценариях VDI для решения следующих задач:
  • Микросегментация/фильтрация трафика между виртуальными десктопами и служебными ВМ.
  • Обеспечения связности между подсетями/маршрутизация трафика средствами гипервизора.
  • Интеграция с ПО антивирусной защиты.
  • Организация L2 сетей для обеспечения катастрофоустойчивости или для виртуальных инфраструктур, охватывающих несколько площадок (Cross-vCenter NSX).
NSX Distributed Firewall – функция микросегментирования позволяет фильтровать любой трафик отправляемый или получаемый сетевыми интерфейсами ВМ, в том числе, передающийся между ВМ, расположенными в одной подсети и даже запущенные на одном физическом сервере. Данная возможность отличает NSX от классических межсетевых экранов, которые могут фильтровать трафик передаваемые только между разными подсетями. Это позволяет обеспечить передачу трафика, необходимого для работы VDI и приложений, и запретить все остальное сетевое взаимодействие. При создании правил в качестве источника или назначения трафика могут использоваться:
  • MAC адрес.
  • IP адрес.
  • Конкретная ВМ или сетевой адаптер ВМ.
  • Группа безопасности, в которую входят ВМ.
  • Группа безопасности, в которую входит группа пользователей Active Directory.
  • Логическая сеть, группа портов на стандартном или распределенном коммутаторе.
  • Кластер или виртуальный ЦОД целиком.
Про группы безопасности следует упомянуть отдельно. Членство в группах может быть статическим – администратор вручную указывает, какие ВМ входят в группу, либо динамическим. NSX может включать ВМ в группу безопасности на основании операционной системы, установленной в ВМ (например, все ВМ, с ОС Windows, все ВМ с ОС Windows XP и т.д.), на основании тэга безопасности, присвоенной ВМ (можно создать тэг "Connection Servers" и назначить его соответствующим ВМ), на основании имени ВМ (все ВМ, имя которых начинается с vdi-desktop) и другие критерии.

Отдельного упоминания заслуживает возможность включить в группу безопасности доменные группы пользователей из Active Directory. В этом случае появится возможность создавать т.н. Identity Based правила, которые будут применяться к ВМ после того, как в них вошли доменные пользователи, которые являются членами определенной доменной группы.
NSX Distributed Logical Router позволяет перенести задачи по маршрутизации трафика виртуальной инфраструктуры с физических маршрутизаторов на гипервизоры.

Функция NSX Guest Introspection поддерживается многими современными антивирусными решениями, и позволяет полностью отказаться от необходимости установки и периодического обновления антивирусного агента внутрь ВМ, либо использовать облегченные версии антивирусных агентов.

Использование L2 логических сетей (Logical Network) на базе VXLAN позволяет связать две площадки и организовать катастрофоустойчивый территориально-распределенный кластер (stretched cluster), либо выполнить развертывание NSX в режиме Cross-vCenter и объединить несколько инсталляций vCenter на разных площадках и обеспечить L2 связность при помощи универсальных логических сетей и универсальных маршрутизаторов.

VMware NSX не входит в состав Horizon, поэтому его требуется приобретать отдельно. Для сценариев VDI возможно лицензирование NSX по физическим процессорам/сокетам серверов виртуализации, либо по количеству запущенных ВМ (NSX for Desktop, данный вариант лицензирования предназначен для сценариев VDI и имеет те же ограничения, что и vSphere for Desktop или vSAN for Desktop).

Из других функций, которые также могут найти применение в сценариях VDI следует отметить балансировщик нагрузки в NSX Edge Services Gateway, который может использоваться для балансировки нагрузки между View Connection Server или Unified Access Gateway, а также VPN (L2 Site-to-Site VPN для организации связности удаленных площадок и SSL VPN – для подключения пользователей).

VMware NSX доступен в нескольких редакциях, до версии 6.4 – это были Standard, Advanced и Enterprise, начиная с версии 6.4 основные редакции (не считая ROBO): Standard, Professional, Advanced и Enterprise Plus (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmware-nsx-datasheet.pdf).

При выборе редакции следует учесть – какие функции требуются от NSX. Так, например, NSX Distributed Firewall доступен в редакции Professional и выше, Identity Based правила и территориально-распределенные инсталляции Cross-vCenter NSX – в Advanced и выше.

Продолжение доступно по ссылкам: