Архив метки: cvm

Nutanix ABS: как у нас работает failover/failback?

Интересное видео, показывающее, как отрабатывает Failover и Failback на нашем ABS — Acropolis Block Storage — сервисе, который отдает внешним серверам хранилище Nutanix как блочные LUNы. Это (по крайней мере изначально) было придумано для возможности подключить к кластеру Nutanix какой-то внешний сервер, например Oracle, который нельзя, или лицензионно дорого перетаскивать под гипервизор.
Но как при этом работает failover? Что произойдет если, например, одна из нод кластера упадет?

Вот на этот вопрос отвечает видео. На нем 4-нодовый кластер Nutanix отдает LUN-ы с тестовой базой внешнему серверу Oracle DB. На Nutanix также запущен в отдельной VM swingbench, эмулирующий нагрузку к этой базе данных и показывающий графики параметров работы теста.

На первом видео мы видим, как все четыре CVM обслуживают внешний сервер, самобалансируя ввод-вывод с него между собой. Обратите внимание, что мы НЕ ИСПОЛЬЗУЕМ MPIO или ALUA, для нашей архитектуры доступа к данным они не нужны на хост-сервере! iSCSI Initiator на физическом хост-сервере обращается на общий «кластерный IP» таргета, который передается какому-то из CVM, и им обслуживается. В версии 4.7 используется равномерная «рассортировка» по CVM, начиная с версии 5.0 для выбора целевого CVM используется сравнительный уровень его загрузки. Добавляемые в кластер ноды автоматически начинают обслуживать операции ввода-вывода, без дополнительного вмешательства и перенастройки админом.

Затем мы физически отключаем одну ноду, используя команду poweroff на IPMI из консоли. (страничка по адресу CVM с портом 2009 это одна из наших служебный вебстраниц интерфейса, в данном случае — iSCSI Target Adapter-а).
Мы видим, что iSCSI target переехал на одну из нод, которая подхватила операции упавшей, с минимальной задержкой операций, в пределах таймаута. Нагрузка на CVM, подхвативший операции вышедшего из строя выросла. Операции swingbench не прерывались.

Затем, мы включаем ноду назад, и, вскоре, видим, как она включилась, и iSCSI Target самостоятельно вернулся на включенную ноду, так что нагрузка снова автоматически сбалансировалась по всем четырем CVM-«контроллерам СХД».

Синхронизация времени в кластере 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

Как изменить параметры CVM с помощью virsh

KVM, который мы используем как один из нащих гипервизоров, имеет удобный инструмент управления — virsh.
На примере Nutanix CE можно посмотреть, что с помощью его можно сделать.

Сперва войдем в консоль CentOS Linux, который используется как платформа для KVM.

Username: root
Password: nutanix/4u

Дадим команду virsh list, чтобы увидеть наши виртуальные машины, и прежде всего, конечно, CVM.

virsh-list[1]

В данном случае, у нас свежепоставленный CE, и мы видим лишь одну виртуалку — CVM.
Посмотрим ее параметры:

virsh dominfo NTNX-72c243e3-A-CVM

Давайте увеличим ей объем оперативной памяти с 12 до 15GB.
Гасим ее, прежде всего:

virsh shutdown NTNX-72c243e3-A-CVM

Устанавливаем нужный размер памяти для виртуалки (обратите внимание, перед config два минуса):

virsh setmaxmem NTNX-72c243e3-A-CVM 15G --config
virsh setmem NTNX-72c243e3-A-CVM 15G --config

Запускаем ее обратно:

virsh start NTNX-72c243e3-A-CVM

Если вы хотите изменить число vCPU, то надо отредактировать xml-файл конфигурации. Это можно делать и на включенной CVM, так как читает она его только при старте.

virsh edit NTNX-72c243e3-A-CVM

cpu-change[1]

Запускается vi, с нужным xml в нем. Исправьте там, в данном случае, значиение vcpu placement на нужное вам, например с 4 до 8.

Перезагрузите CVM, чтобы новое значение было прочитано:
virsh shutdown NTNX-72c243e3-A-CVM
virsh start NTNX-72c243e3-A-CVM

Теперь убедимся, что значения изменены:

virsh dominfo NTNX-72c243e3-A-CVM

virsh-dom-info[1]

Nutanix «под крышкой»: как обеспечивается надежность хранения данных

nutanix-front3

Этим постом я начну серию «Nutanix под крышкой», переводов официальных technotes о внутреннем устройстве системы, который сейчас пишутся и постепенно выкладываются в resources на офсайте продукта.
В этом посте вы узнаете, как обеспечивать надежность хранения и сохранность данных, не используя RAID, каким образом хранятся данные на дисках, и как они оказываются доступны прикладным задачам, что такое «метаданные», и какую роль они играют в работе системы хранения Nutanix, наконец, что за механизмы приводят все это в движение.

Надежность хранения данных

Nutanix Virtual Computing Platform разработан и сконструирован «с нуля», чтобы обеспечить максимальную надежность так, чтобы успешно парировать возможные отказы оборудования и программные ошибки. Распределенная программная архитектура запускает виртуальный контроллер хранения (virtual storage controller, также Controller VM или CVM) на каждом узле кластера, составляющих вместе распределенную систему. Все узлы работают совместно, собирая отдельные, непосредственно-подключенные (DAS) к этим узлам диски в общее «пространство имен» (single global namespace), которое может быть использовано всеми хостами. Все диски кластерной системы управляются специальной структурой, называющейся Nutanix Distributed Filesystem (NDFS), которая обеспечивает целостность хранимых данных, и защищает их от сбоев узла, самих дисков, или программных ошибок.

Читать далее