вторник, 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 сетей для сохранения сетевой доступности при переносе ВМ из одной площадки на другую.