Пример «живой» системы, результатами на тестовом «прогреве» которой перед сдачей клиенту поделились коллеги.
1300+ VDI десктопов на 24 хостах Lenovo HX3720. Рандомная по чтению-записи нагрузка, 600K+ cluster IOPS, 4.4 GBs трафика, 1 ms latency при 80% загрузке CPU.
Наш тестовый пакет для нагрузочного тестирования гиперконвергентных систем и анализа получившейся производительности, который мы назвали X-Ray, прошел длинный путь. Сначала он был нашим внутренним продуктом для тестирования POC (Proof-of-Concept, тестовых демосистем, которые ставятся у потенциальных клиентов, где мы практически доказываем, что мы можем решить его задачи). Начиная с версии 2.0 мы сделали его общедоступным и открытым. Xray 2.0 и новее можно свободно скачивать и модифицировать настройки его тестовых сценариев, чтобы иметь возможность подстроить их под конкретные требования клиентов. В этом блоге я впервые написал о нем вот здесь.
Но все равно, мы постоянно сталкивались с предубеждением, что, мол, раз его сделал вендор HCI-платформы, то значит он заточен на то, чтобы демонстрировать преимущества только этой платформы, и поэтому необъективен. Тем более, что основной компонент его, ядро интерпретатора сценариев, оставался закрытым.
Поэтому мы сделали следующий шаг. Начиная с вышедшей на прошлой неделе версии 3.0 мы полностью открываем код и переходим в Open Source.
Исходные коды X-Ray Curie, это основной, до сих пор бывший закрытым, компонент X-Ray, ядро, которое интерпретирует и исполняет сценарии на YAML, выложены теперь на GitLab: https://gitlab.com/nutanix/curie
Лицензией выбрана MIT License.
Документация — тут: https://nutanix.gitlab.io/curie/
X-Ray 3.0 VM images
Nutanix AHV binary: QCOW2
VMware ESXi binary: OVA
Виртуальную машину с X-Ray можно развернуть поверх любого гипервизора, например на VirtualBox, зайти на него по IP-адресу VM в веб-интерфейс, указать в качестве таргета нужную систему, и X-Ray Curie передаст на нее сформированный в сценарии тестовый workload, запустит его, а потом покажет достигнутые результаты, и сформирует отчет.
Скачивайте, тестируйте, сравнивайте.
Немного интересного о том, насколько важно для получения хорошего результата правильно и грамотно конфигурировать систему (а не просто поставить ее потыкав Enter и «Далее»), руководствуясь нашими Best Practices.
Нак коллега из Германии поделился своим опытом:
«Доброе утро. Хочу с вами поделиться результатами тестирования, которые хорошо иллюстрируют важность использования наших best practices.
Я запускал бенчмарк на MSSQL с использованием HammerDB. Использовался AOS 5 на AHV на 3x NX-3175-G4. CPU на 2.6 Ghz (2x 10 core) и каждая нода имела 692 GB RAM. Диски: 2x 1.5 TB SSD и 2x 2TB HDDs.
Все VM были созданы из шаблона Windows 2012 R2 x64 со всеми сежими патчами, VM имела 1 сокет и 8 виртуальных ядер, а также 64GB vRAM.
Я создал VM с SQL Server установленным по умолчанию (просто приняты все значения установки по умолчанию, просто жал «next» всегда), и база была поставлена на виртуальный диск, размером 1TB в контейнере по умолчанию.
Я также создал одну VM с SQL установленным и настроенным в соответствии с нашими best practices. Контейнер имел включенную inline compression, для базы созданы несколько виртуальных дисков, настроены параметры SQL Server, установлены trace flags, large pages, database memory allocation, и так далее.
Затем я установил HammerDB и выполнил транзакционный тест (TPC-C) с 40 пользователями и 254 warehouses, что, в общем, довольно невысокое число последних.
Так выглядел запуск теста на неоптимизированном сервере SQL. Мы получили примерно 90K transactions per minute, и уперлись в CPU.
А это тест на оптимизированной VM с SQL. Мы получили тут более миллиона транзакций в минуту, и все еще не уперлись в CPU.
В обоих случаях, OS и базовая конфигурация VM были идентичны, различалась только конфигурация контейнера, были добавлены дополнительные диски в VM, и были сделаны настройки базы данных. Подсистема хранения не была слишком нагружена, она выдавала всего около 4800 IOs или 290 MB/s.
Мне показалось, что вам будет интересно посмотреть на результаты. Возможно это также будет полезно показать пользователям, если заходит разговор о производительности базы данных на Nutanix.»
Итак, просто за счет более правильной настройки VM для работы в Nutanix, получен двенадцатикратный прирост ее производительности.
Помните, я рассказывал про историю, как мы в 4.6 значительно улучшили производительность работы на том же самом железе, просто обновлением софта.
Так вот, «мы снова сделали это». На скриншотах ниже результаты обновления версии AOS 4.7.3 на AOS 5.0 на тестовой системе. Просто запустили diagnostics.py, обновили систему на 5.0, и снова его запустили.
Вот результат с последней сабверсией линейки 4.7 — 4.7.3 на 4-нодовой демосистеме NX-3000, стоявшей в этот момент на тестировании у пользователя.
А это результат того же diagnostics.py сразу после обновления на 5.0.
Вот так работает software defined. То же железо, та же задача, а производительность Random Read IOPS стала выше на ~25%, Random Write IOPS — на ~30%, просто обновлением ПО, которое вы получаете бесплатно, пока система находится на поддержке.
Еще один тест производительности на одной и той же системе, до и после обновления на NOS 4.6
Это топовая NX-3460-G4, с 2x SSD 1,2TB, 4x SATA 2TB, 512GB RAM, 2x E5-2680v3 на каждой из 4 ее нод.
На ней был установлен Acropolis Hypervisor (AHV) и затем NOS 4.5.1.2 обновлена на NOS 4.6, тест diagnostics.py был запущен до и после 1-Click обновления.
Было (AHV NOS 4.5.1.2):
Waiting for the hot cache to flush …………. done.
2016-02-24_05-36-02: Running test «Sequential write bandwidth» …
1653 MBps , latency(msec): min=9, max=1667, median=268
Average CPU: 10.1.16.212: 36% 10.1.16.209: 48% 10.1.16.211: 38% 10.1.16.210: 39%
Duration fio_seq_write : 33 secs
*******************************************************************************
Waiting for the hot cache to flush ……. done.
2016-02-24_05-37-15: Running test «Sequential read bandwidth» …
3954 MBps , latency(msec): min=0, max=474, median=115
Average CPU: 10.1.16.212: 35% 10.1.16.209: 39% 10.1.16.211: 30% 10.1.16.210: 31%
Duration fio_seq_read : 15 secs
*******************************************************************************
Waiting for the hot cache to flush ……… done.
2016-02-24_05-38-22: Running test «Random read IOPS» …
115703 IOPS , latency(msec): min=0, max=456, median=4
Average CPU: 10.1.16.212: 73% 10.1.16.209: 75% 10.1.16.211: 74% 10.1.16.210: 73%
Duration fio_rand_read : 102 secs
*******************************************************************************
Waiting for the hot cache to flush ……. done.
2016-02-24_05-40-44: Running test «Random write IOPS» …
113106 IOPS , latency(msec): min=0, max=3, median=2
Average CPU: 10.1.16.212: 64% 10.1.16.209: 65% 10.1.16.211: 65% 10.1.16.210: 63%
Duration fio_rand_write : 102 secs
*******************************************************************************
Стало после обновления (AHV NOS 4.6):
Waiting for the hot cache to flush …………. done.
2016-03-11_03-50-03: Running test «Sequential write bandwidth» …
1634 MBps , latency(msec): min=11, max=1270, median=281
Average CPU: 10.1.16.212: 39% 10.1.16.209: 46% 10.1.16.211: 42% 10.1.16.210: 47%
Duration fio_seq_write : 33 secs
*******************************************************************************
Waiting for the hot cache to flush …….. done.
2016-03-11_03-51-13: Running test «Sequential read bandwidth» …
3754 MBps , latency(msec): min=0, max=496, median=124
Average CPU: 10.1.16.212: 22% 10.1.16.209: 37% 10.1.16.211: 23% 10.1.16.210: 28%
Duration fio_seq_read : 15 secs
*******************************************************************************
Waiting for the hot cache to flush ……….. done.
2016-03-11_03-52-24: Running test «Random read IOPS» …
218362 IOPS , latency(msec): min=0, max=34, median=2
Average CPU: 10.1.16.212: 80% 10.1.16.209: 91% 10.1.16.211: 80% 10.1.16.210: 82%
Duration fio_rand_read : 102 secs
*******************************************************************************
Waiting for the hot cache to flush …….. done.
2016-03-11_03-54-43: Running test «Random write IOPS» …
156843 IOPS , latency(msec): min=0, max=303, median=2
Average CPU: 10.1.16.212: 69% 10.1.16.209: 72% 10.1.16.211: 64% 10.1.16.210: 74%
Duration fio_rand_write : 102 secs
*******************************************************************************
Вывод diagnostics.py под Acropolis вчерашней инсталляции NX-3460-G4, 4 ноды, 2x480GB SSD, 4x2TB SATA на ноду, 256GB RAM, 2x E5-2660v3 CPU
Результаты — для всех 4 нод суммарно. Для производительности одной VM на одной ноде — делить на 4.
nutanix@NTNX-15SM60210062-A-CVM:10.9.20.160:~$ diagnostics/diagnostics.py --display_latency_stats --run_iperf run
Cleaning up node 10.9.20.156 ... done.
Cleaning up node 10.9.20.157 ... done.
Cleaning up node 10.9.20.158 ... done.
Cleaning up node 10.9.20.159 ... done.
Cleaning up the container and the storage pool ... done.
Running Iperf Test between CVMs
bandwidth between 10.9.20.160 and 10.9.20.161 is: 8.65 Gbits
bandwidth between 10.9.20.160 and 10.9.20.162 is: 8.77 Gbits
bandwidth between 10.9.20.160 and 10.9.20.163 is: 8.51 Gbits
Checking if an existing storage pool can be used ...
Using storage pool default-storage-pool-28308 for the tests.
Checking if the diagnostics container exists ... Container with desired replication factor exists.
Preparing the UVM on host 10.9.20.156 ...
Transferring diagnostics image to NDFS ... done.
Deploying the UVM on host 10.9.20.156 ... done.
Adding disks ... done.
Preparing the UVM on host 10.9.20.157 ...
Deploying the UVM on host 10.9.20.157 ... done.
Adding disks ... done.
Preparing the UVM on host 10.9.20.158 ...
Deploying the UVM on host 10.9.20.158 ... done.
Adding disks ... done.
Preparing the UVM on host 10.9.20.159 ...
Deploying the UVM on host 10.9.20.159 ... done.
Adding disks ... done.
VM on host 10.9.20.156 has booted. 3 remaining.
VM on host 10.9.20.157 has booted. 2 remaining.
VM on host 10.9.20.158 has booted. 1 remaining.
VM on host 10.9.20.159 has booted. 0 remaining.
2016-02-29_05-13-22: Running setup "Prepare disks" ...
done.
Average CPU: 10.9.20.162: 45% 10.9.20.163: 40% 10.9.20.160: 39% 10.9.20.161: 47%
Duration prepare_disks : 44 secs
*******************************************************************************
Waiting for the hot cache to flush ............. done.
2016-02-29_05-15-14: Running test "Sequential write bandwidth" ...
1291 MBps , latency(msec): min=8, max=1758, median=344
Average CPU: 10.9.20.162: 35% 10.9.20.163: 31% 10.9.20.160: 32% 10.9.20.161: 36%
Duration fio_seq_write : 41 secs
*******************************************************************************
Waiting for the hot cache to flush ............. done.
2016-02-29_05-17-00: Running test "Sequential read bandwidth" ...
3884 MBps , latency(msec): min=0, max=564, median=118
Average CPU: 10.9.20.162: 29% 10.9.20.163: 23% 10.9.20.160: 26% 10.9.20.161: 30%
Duration fio_seq_read : 15 secs
*******************************************************************************
Waiting for the hot cache to flush ........... done.
2016-02-29_05-18-11: Running test "Random read IOPS" ...
223506 IOPS , latency(msec): min=0, max=19, median=2
Average CPU: 10.9.20.162: 79% 10.9.20.163: 80% 10.9.20.160: 81% 10.9.20.161: 80%
Duration fio_rand_read : 102 secs
*******************************************************************************
Waiting for the hot cache to flush ........ done.
2016-02-29_05-20-30: Running test "Random write IOPS" ...
149141 IOPS , latency(msec): min=0, max=207, median=2
Average CPU: 10.9.20.162: 69% 10.9.20.163: 63% 10.9.20.160: 67% 10.9.20.161: 63%
Duration fio_rand_write : 102 secs
*******************************************************************************
Tests done.
Results archived in /home/nutanix/diagnostics/results/2016-02-29_05-10-56
nutanix@NTNX-15SM60210062-A-CVM:10.9.20.160:~$
До установки NOS 4.6 там была 4.5.1 и где-то ~120000 IOPS на random read.
Наша долгожданная версия Nutanix OS 4.6, с таким объемом новых фич, которые у кое-кого стали бы поводом назвать ее «5.0», поэтому в этой и нескольких последующих статьях я расскажу, что у нас теперь появилось нового.
Прежде всего, остановимся на очень большой оптимизации кода, работы по которому велись весь прошлый год, в результате чего Nutanix удалось достичь очень существенного прироста в производительности. Причем это происходит и на уже существующих системах. Все что вам нужно — обновиться, причем без остановки работы, с помощью 1-Click Upgrade.
Вот вам картинка для привлечения внимания:
Да, около 2,5 раз прирост на рандомном чтении мелкими блоками, около 1,8 раз на рандомной записи, по сравнению с предыдущей версией! Улучшились также, почти двукратно, показатели по вводу/выводу для одного vDisk.
Основными методами, приведшими к такому резкому приросту разработчики назвали:
Еще больше прирост показывают наши allflash системы, причем в скором времени грядет очень важное изменение в структуре предложений наших линеек продуктов, связанных с allflash.
В общем, если у вас система Nutanix подключена к интернету и получает обновления с наших серверов обновлений — ищите в PrismUI Upgrade Software новую версию. Для остальных — offline update bundle можно будет скачать с portal.nutanix.com, думаю, что в ближайшие сутки новая версия и там и там появится.
Кроме этого, просто как placeholders, перечислю через запятую, и распишу все эти новые фичи в следующих постах:
Встроенный в Nutanix распределеный scale-out файловый сервис SMB 2.1 Project Minerva, опубликован в статусе Technology Preview.
Volume Groups, появившиеся в 4.5 и конфигурировавшиеся в CLI, теперь управляются из PrismUI. Volume Groups — это тома с блочным доступом по iSCSI, доступные VM, в том случае, если вам нужно отдать в VM раздел с блочным доступом. Примеры таких приложений это Microsoft Exchange на ESXi, Windows 2008 Guest Clustering, Microsoft SQL 2008 Clustering и Oracle RAC.
Обновление 1-Click Upgrade теперь работает в том числе и для BMC и BIOS платформы. Без остановки работы вы можете обновить BIOS серверной платформы.
Также обновляется и встроенный теперь в Nutanix наш сервис прошивки и заливки образов гипервизора и CVM — Foundation.
Metro Availability получил долгожданную возможность не перезагружать VM после миграции на DR-сайт. Раньше это требовалось из-за необходимости переключить NFS-дескрипторы на новый сайт и его хранилище (сами данные синхронно реплицировались), теперь VM работают через NFS proxy, и могут мигрировать «наживую».
Еще одна долгожданная функция — Self-Service Restore. Теперь пользователь VM может самостоятельно восстановить данные, сохраненные в снэпшоте. Для этого в VM устанавливается так называемый Nutanix Guest Tool, и с его помощью VM коммуницирует с Nutanix, позволяя смонтировать снэпшот как отдельный диск внутри VM, откуда простым копированием можно извлечь данные снэпшота.
Появилась интеграция с OpenStack, новые драйвера для Nova, Cinder, Glance и Neutron. Интеграция работает через специальную Server VM (SVM), образ которой доступен для скачивания и установки в Nutanix. Таким образом, Nutanix видится из Open Stack как hypervisor.
Репликация между кластерами теперь возможна и между разными гипервизорами. Например, продакшновый кластер под ESXi может реплицировать свои данные на кластер в резервном датацентре, под Acropolis Hypervisor.
В статусе Tech Preview опубликован Project Dial — 1-click in-place hypervisor conversion, миграция всего кластера с ESXi на AHV. Автоматически конвертируются гипервизоры кластера, его CVM, а также VM пользователя. Разумеется, все это будет проделываться без остановки работы системы и приложений в VM. Релиз GA в ближайших версиях NOS.