Архив за месяц: Март 2016

Синхронизация времени в кластере Nutanix с помощью ntp

Синхронизация времени на нодах кластера Nutanix без работающего в сети сервера ntp может представлять некоторые затруднения. Кода у вас есть работающий ntp, у вас в сети, или доступный кластеру в интернете, то все просто. Однако если в нодах кластера «разъехалось» время, то тут начинаются многие неприятные эффекты, например у вас могут не отображаться графики производительности в дашборде кластера Nutanix. Если вы видите такое — первым делом проверяйте и синхронизируйте время на CVM.

Сделать это можно так:
Залогиньтесь на CVM, и дайте команду:

allssh ssh root@192.168.5.1 date

Если вы еще не знакомы, то allssh позволяет выполнить приведенные далее команды на ВСЕХ хостах кластера разом, что очень удобно.
Адрес 192.168.5.1 это специальный внутренний адрес всех CVM в кластере Nutanix.

Вы получите что-то вроде:

nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$ allssh ssh root@192.168.5.1 date
Executing ssh root@192.168.5.1 date on the cluster
================== 10.4.91.56 =================
FIPS mode initialized
Tue Dec 15 02:46:57 PST 2015
================== 10.4.91.57 =================
FIPS mode initialized
Tue Dec 15 02:48:20 PST 2015
================== 10.4.91.58 =================
FIPS mode initialized
Tue Dec 15 02:49:04 PST 2015
nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$

Здесь мы видим проблему: «разбежалось» время в OS нодов кластера.

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

nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$ allssh ssh root@192.168.5.1 ntpq -p
Executing ssh root@192.168.5.1 ntpq -p on the cluster
================== 10.4.91.56 =================
FIPS mode initialized
remote refid st t when poll reach delay offset jitter
==============================================================================
us.pool.ntp.org 16 u 90 1024 0 0.000 0.000 0.000
================== 10.4.91.57 =================
FIPS mode initialized
remote refid st t when poll reach delay offset jitter
==============================================================================
us.pool.ntp.org 16 u 26 1024 0 0.000 0.000 0.000
================== 10.4.91.58 =================
FIPS mode initialized
remote refid st t when poll reach delay offset jitter
==============================================================================
us.pool.ntp.org 16 u 625 1024 0 0.000 0.000 0.000
nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$

Допустим, с ntp что-то не то, давайте переставим их на другую группу, например на пул российских серверов ntp.

Остановите сервис ntpd:

nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$ allssh ssh root@192.168.5.1 service ntpd stop
Executing ssh root@192.168.5.1 service ntpd stop on the cluster
================== 10.4.91.56 =================
FIPS mode initialized
Shutting down ntpd: [ OK ]
================== 10.4.91.57 =================
FIPS mode initialized
Shutting down ntpd: [ OK ]
================== 10.4.91.58 =================
FIPS mode initialized
Shutting down ntpd: [ OK ]
nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$

Обновите записи для серверов ntp:

nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$ allssh ssh root@192.168.5.1 ntpdate -u ru.pool.ntp.org
Executing ssh root@192.168.5.1 ntpdate -u ru.pool.ntp.org on the cluster
================== 10.4.91.56 =================
FIPS mode initialized
15 Dec 03:28:10 ntpdate[16907]: adjust time server 208.75.88.4 offset -0.014000 sec
================== 10.4.91.57 =================
FIPS mode initialized
15 Dec 03:28:20 ntpdate[14812]: adjust time server 208.75.88.4 offset -0.001235 sec
================== 10.4.91.58 =================
FIPS mode initialized
15 Dec 03:28:30 ntpdate[12209]: adjust time server 208.75.88.4 offset -0.019629 sec
nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$

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

Запустите демон ntpd

allssh ssh root@192.168.5.1 service ntpd start

Теперь время синхронизировано:

nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$ allssh ssh root@192.168.5.1 date
Executing ssh root@192.168.5.1 date on the cluster
================== 10.4.91.56 =================
FIPS mode initialized
Tue Dec 15 03:30:39 PST 2015
================== 10.4.91.57 =================
FIPS mode initialized
Tue Dec 15 03:30:40 PST 2015
================== 10.4.91.58 =================
FIPS mode initialized
Tue Dec 15 03:30:41 PST 2015
nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$

Ну а лучший способ проверить, что все работает отлично, запустить в CVM наш скрипт NCC — Nutanix Cluster Check:

nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$ ncc
+---------------------------------------------------------------------------------------+
| Type | Name | Impact | Short help |
+---------------------------------------------------------------------------------------+
| M | cassandra_tools | N/A | Plugins to help with Cassandra ring analysis |
| M | config_based | N/A | All config based plugin |
| M | file_utils | N/A | Utilities for manipulating files on the cluster |
| M | fix_failures | N/A | Fix failures |
| M | health_checks | N/A | All health checks |
| M | help_opts | N/A | Show various options for ncc. |
| M | insights_collectors | N/A | Plugin to start the insights collectors |
| M | log_collector | N/A | Collect logs on all CVMs. |
+---------------------------------------------------------------------------------------+
nutanix@NTNX-15SM65300246-A-CVM:10.4.91.56:~$ ncc health_checks run_all

Поведение SSD в большой популяции, новое исследование

Я давно слежу за публикациями про поведение жестких дисков, и исследованиями о надежности хранения.
Один из виднейших исследователей этого направления, доктор Bianca Schroeder из университета Торонто, которая многие годы проводит исследования ситуации с поведением и надежностью жестких дисков. Ее группа недавно опубликовала на конференции FAST, материалы которой всегда являются mustread для всех, интересующихся темой хранения данных, работу о том, как ведут себя диски SSD в большой популяции крупного enterprise датацентра (на примере датацентров Google, с которыми у доктора Шредер давние и тесные связи, и которые предоставляют огромное поле для исследований).
Возможно раньше вы встречали ее же исследование, также проведенное совместно с Google, по надежности обычных жестких дисков (http://research.google.com/archive/disk_failures.pdf). Теперь пришла пора посмотреть и на SSD.

Результаты исследования крайне интересны, и, как и в случае исследования HDD, не всегда подтверждают «устоявшиеся убеждения».
Например, стало понятно, что на надежность SSD крайне мало влияет степень их использования (это та самая конечность ресурсов записи у flash, которой все так боятся), но влияет их возраст, впрочем, тот же самый вывод был сделан в 2007-м об обычных HDD, там также вероятность отказов не коррелировала с нагрузкой, но только с их возрастом.
Raw Bit Error Rate (RBER, исправимых в firmware ошибок) на SSD растет медленнее ожидаемого и не коррелирует с Uncorrectable Bit Error Rate (неисправимых диском, видимых пользователю).
В целом можно утверждать, что надежность SSD сравнялась с надежностью HDD. Отказы SSD происходят даже реже, чем у HDD, однако величина UBER несколько выше.

После анализа миллионов «драйво-часов» работы множества экземпляров 10 эксплуатируемых в датацентрах Google моделей SSD, трех разных типов SSD: SLC, MLC и eMLC разных лет выпуска (от 24 до 50nm техпроцесса) стало ясно, что, в подавляющем большинстве случаев, SSD даже в условиях нагруженного датацентра не превышают свой ресурс записи, и их отказы практически не связаны с этим параметром. Ни один из исследованных дисков (самым старшим было около 6 лет) не достиг своего лимита по ресурсу записи.

Также стало очевидно, что (значительно) более дорогие enterprise SLC не имеют более высокого уровня надежности (хотя бы эквивалентного их более высокой стоимости). Уровень надежности оказался сравним для всех участвующих в анализе SSD, вне зависимости от их типа и технологии.

Существование bad blocks — нормальная ситуация для SSD. На от 30 до 80% исследованных SSD (разброс величины для 10 исследованных моделей) возникал хотя бы один bad block за первые 4 года эксплуатации, и на от 2 до 7 процентов — целиком битый чип памяти. Однако возникновение сразу большой группы bad blocks — плохой признак, свидетельствующий о высокой вероятности дальнейшего выхода из строя чипа, или SSD целиком.

Подробнее и со всеми результатами, которые я выпустил за неимением места — в самой работе, ссылка на которую в сборнике материалов FAST’16 приведена выше.
Там же есть и другие интересные работы, например исследование, ясно показывающее (в первый раз это утверждалось в вышепроцитированной работе Шредер и Google о HDD, 2007 года), что высокая температура, вопреки распространенному мнению, сравнительно мало влияет на частоту отказов жестких дисков. А влияет, что интересно — влажность. То есть горячий и «сухой» датацентр по частоте отказов почти не отличался от «классического», холодного и сухого, а вот горячий и «влажный» DC, охлаждающийся с использованием freecooling, обычного уличного воздуха, показывал существенный рост отказов. Впрочем, тоже не катастрофический (AFR, Average Failure Rate дисков вырос в нем до 5,1% с обычных 1,5%).

Еще одно исследование на тему отказов и особенностей работы SSD и Flash, сделанное инженерами Facebook и специалистами Carnegie-Mellon University, и опубликованное в прошлом году, можно найти тут: http://users.ece.cmu.edu/~omutlu/pub/flash-memory-failures-in-the-field-at-facebook_sigmetrics15.pdf

«Чистый» тест производительности при обновлении NOS 4.5 -> 4.6

Еще один тест производительности на одной и той же системе, до и после обновления на 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
*******************************************************************************

Что бы вы хотели знать о VSAN и EMC VxRail (но не догадывались спросить;)

9cff0216a1cc4461ab6f6de87b15af37[1]

В связи с выходом новых продуктов на VSAN — EMC VxRail, маркетинговая машина EMC запустилась, и начала свою работу по продвижению нового продукта семейства EVO:Rail. Новостей о «новом революционном продукте от изобретателей гиперконвергенции» будет много по всем каналам, как у EMC и заведено. Тем не менее для нас, технарей, важно сохранять трезвый взгляд, и знать не только о достоинствах, но и недостатках продукта, в конце концов CIO отрапортуют на chairman’s board о внедрении и пойдут пить свои коктейли, а нам с этим всем жить.
Поэтому я бы хотел остановиться на некоторых моментах VSAN/VxRail, о которых как-то не слишком говорят в презентации продукта.
Поэтому я и написал нижеследующий пост.

Я уже упоминал это, но обратил внимание, что часто этот факт как-то минует сознание многих.
Есть VSAN 1.0, который работает на vSphere 5.5. Он имеет кучу недостатков, о которых я писал раньше в этом блоге. VMware провела большую работу над ошибками, и выпустила следующую версию, которая стала сразу называться «VSAN 6.0». Однако так как VSAN это модуль ядра, то VSAN 6.0 нельзя поставить на vSphere 5.5. Вам придется обновиться на vSphere 6.0. Все бы ничего, но, к сожалению, качество релиза vSphere 6 «оставляет желать». Многие компании продолжают сидеть на 5.5 + Updates, в ожидании, пока 6.0 стабилизируется. Но если вы не готовы мириться с многочисленными проблемами vSphere 6.0, и при этом нуждаетесь в VSAN, то единственный выход для вас — VSAN 1.0, со всеми ее проблемами.

Если в вашей системе VSAN выходит из строя SSD, то это ведет к прекращению работы всей дисковой группы, в которую входит этот SSD.

Добавить еще SSD в систему можно только в создаваемую новую disk group.

Если disk latency для HDD вырастает, по каким-то причинам, до 50ms, то этот диск выводится из дисковой группы, так как считается неисправным. Если по каким-то причинам для операций ввода-вывода на SSD также вырастает latency до 50ms, то он также выводится из дисковой группы, но при этом, см. выше, прекращает работу вся дисковая группа! Это поправлено в VSAN 6.2, но, например, EMC VxRail — это сейчас VSAN 6.1!

В VSAN отсутствует поддержка VCAI (View Composer API for Array Integration), что может стать проблемой с производительностью при развертывании большого числа VDI-десктопов разом.

Соотношение 70/30 для Read/Write операций в VSAN Cache не изменяемо. Это также может быть проблемой для ряда нагрузок, отличающихся от типичных (пример — VDI, где в типичной среде записей происходит больше, чем чтений).

Максимальный размер Write buffer — 600GB. Остальное место, если оно есть на SSD (сегодня есть SSD уже и 1,2TB), как я понимаю, просто не используется?

По-прежнему используется крайне спорное решение, когда при выходе из строя ноды кластера VSAN система ожидает его возвращения в строй 60 минут (целый час!), и только потом начинает процедуры ребилда информации и состояния системы. Если в течение этого часа для системы с FTT=1 происходит отказ в еще одной ноде, то, как я понимаю, все становится очень плохо.

Дедупликация, компрессия, а также Erasure coding доступно ТОЛЬКО на All-Flash системах, и недоступны на Hybrid-конфигурациях (SSD+HDD).

Официально поддержка SAP Core появилась только в VSAN 6.2, см выше про VxRail, а Oracle RAC и Windows Clustering — только с VSAN 6.1.

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

UPD: Заходите в комментарии, там тоже есть много интересного. Я рад, что мое замечание о намерении избежать FUD-а и оперировать фактами было замечено, очень часто комментарии к подобным статьям не менее важны и содержательны, чем сам пост. Как только я разберусь с приведенными контраргументами, я обновлю пост там, где это он заслуживает.

Производительность NX-3460-G4 с NOS v4.6

Вывод 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.