Архив за месяц: Июль 2014

Обновление Nutanix Cluster «на ходу»

Кластер Nutanix теперь можно обновить «на ходу», non-disruptive, не прерывая его работу по обслуживанию пользовательских данных, и прямо из Nutanix Prism UI. Это называется One-Click Upgrade, и позволяет, с использованием CVM Auto-Pathing 2.0, появившейся в 4.0, прозрачно перебрасывать доступ к данным на время операций обновления CVM на соседние узлы.
Всего за 16 минут автор скринкаста обновил 4 ноды своего кластера.

Nutanix Foundation: видео процесса запуска кластера в работу

Nutanix Foundation — это инструмент, который позволяет быстро запустить в работу кластер Nutanix. С его помощью можно залить на ноды кластера нужный вам гипервизор (про эту процедуру, и зачем она теперь нужна, я писал ранее), установить и настроить Nutanix Controller VM (CVM), настроить IPMI, а также сделать необходимые стартовые установки и настройки.
Администратору остается только создать и сконфигурировать storage pool, создать VM и завести их в vCenter, SCVMM, или тот инструментарий управления, которым вы планируете пользоваться.

видео с пояснениями работы Nutanix Foundation снял блоггер Андре Лебовичи. Смотреть желательно в HD (720 или 1080).

Nutanix POSH: опубликован набор PowerShell командлетов

Библиотека командлетов PowerShell, которую Nutanix пилил на протяжении нескольких месяцев, стала доступна, что называется General Available, GA.
PowerShell, как вы знаете, это «админская консоль», средство администрирования в среде Windows, поставляется сегодня со всеми OS Windows, и позволяет из продвинутой «командной строки» управлять не только Windows, но и другими системами, если их производитель предусмотрел соответствующую библиотеку расширения PowerShell for Windows (пример: VMware PowerCLI).
Вот именно такую библиотеку так называемых «командлетов» и разработал Nutanix. Если вы Windows-админ, и владеете PowerShell, и при этом хотите управлять кластером Nutanix с помощью командной строки, то это — для вас.
Скачать библиотеку можно прямо из Prism Dashboard, как показано на скриншоте.
download_cmdlets_installer[1]

С ее помошью вам становятся доступны множество функций управления, ранее доступные через GUI. Для работы требуется PowerShell 2.0+ и .NET 4.0

Ниже пример того, как в Powershell из командной строки извлекаются параметры контейнера Nutanix

powershell_containers_example[1]

Все доступные командлеты можно посмотреть в выводе команды:
get-module | ForEach-Object {Get-Command -Module $_} | ForEach-Object {$_.Name}

Nutanix OS 4.0: Replication Factor = 3

Долгожданная версия Nutanix OS 4.0 (NOS 4.0), объявленная этой весной, принесла с собой несколько важных и полезных функций.
Сегодня мы рассмотрим возможности улучшенной отказоустойчивости, которую обеспечивает использование Replication Factor (RF) = 3.

Но для начала, вкратце, что это такое — Replication Factor.
Как я уже писал в этом блоге, отказоустойчивость в Nutanix обеспечивается не путем использования RAID, а путем постоянной репликации копий блоков записываемых данных на другие узлы кластера. Каждый узел кластера хранит свою, локальную для его VM копию их данных, а также блоки своих соседей, реплицированные системой на него в определенном порядке и по определенным правилам. В свою очередь его данные также синхронно реплицированы на соседей. В случае отказа дисков узла, или узла целиком, данные остаются доступны с узлов-партнеров кластера, с которых они, в ходе восстановления этого узла, реплицируются на него обратно, в его локальную (для его VM) копию. Replication Factor — это как раз то, сколько копий блоков хранится реплицированными в пределах кластера.
До NOS 4.0 RF был равен 2, и требовал минимум 3 узлов в кластере (оригинал и две копии), начиная с NOS 4.0 появилась возможность, при необходимости повышенной отказоустойчивости, использовать RF = 3, что требует уже пяти нодов в кластере. Соответственно повышается и отказоустойчивость кластера в целом.

Таким образом в NOS 4.0 устраняется уже не «единая точка отказа», а обеспечивается двойная зашита. Любые два отказа в системе не приводят к потере данных и отказу в обслуживании.

Отметьте, что, в ряде случаев, даже использование RF=2 позволяло выдержать ситуацию двух связанных отказов, например это могут быть отказы двух дисков в одном узле кластера, или отказ двух узлов в составе одного блока, если в кластере работало несколько таких блоков («блок» в данном случае это «корпус», «конструктив», в который установлены узлы по 2 или 4 штуки). Опция, под названием «block aware» также появилась в 4.0.
(см. Рис. 1) Первая копия 4MB «чанка» данных (AKA extent group) записывается на node 1, на котором работает сама VM, использующая эти данные.(так называемый «принцип data locality»)
Вторая копия данных сохраняется на другом узле.
Таким образом, если один диск или узел кластера выходит из строя, curator быстрее восстановит потерянные фрагменты данных, так как все оставшиеся доступными узлы и диски будут задействованы в процессе считывания с них нужных данных. VM может быть смигрирована на другие узлы, и curator будет, по возможности, поддерживать локальность для VM используемых данных, перенеся связанные с VM данные на данный узел с других узлов, и перестроив схему репликации.
При создании второй копии, софт действует достаточно разумно, чтобы обеспечить, по возможности, так называемую схему block aware, то есть поддерживая реплики разнесенными, если это возможно, по разным блокам (корпусам) узлов, чтобы этим обеспечить балансировку загрузки и оградиться от ситуации возможного отказа блока узлов целиком.
Это обеспечивает доступность данных в случае отказа диска, или отказа группы дисков в одном узле, или отказа одного узла целиком.
В версии 4.0, Nutanix UI показывает состояние работы кластера и его «здоровье», информацию о статусе репликации и имеет монитор процесса репликации.
RF=2 будет работать даже в случае кластера из трех узлов.

Рис. 1:

rf2-image

Вывод команды, приведенный ниже, показывает конфигурацию контейнера (датастора).

nutanix@NTNX-13SM35300010-B-CVM:10.1.60.98:~$ ncli ctr ls

ID : 1504
Replication Factor : 2
Oplog Replication Factor : 2

Если вам надо убедиться, что система переносит отказ одного из узлов:
nutanix@NTNX-13SM35300010-B-CVM:10.1.60.98:~$ ncli cluster get-domain-fault-tolerance-status type=node (значение 1 означает наличие отказоустойчивости конфигурации)
Component Type : EXTENT_GROUPS
Current Fault Tolerance : 1

Component Type : OPLOG
Current Fault Tolerance : 1

Рис. 2:
Prism UI показывает сходную картину:

rf2-prism

В NOS 4.0 появилось значение Resiliency Factor=3:

  • Это новинка для Nutanix, и появилась она начиная с 4.0
  • Для нее требуется минимум 5 узлов в кластере.
  • RF=3 обеспечивает высокую отказоустойчивость даже в случае двух несвязанных одновременных отказов, например двух отказов дисков на разных узлах, или отказ двух нод целиком в разных корпусах (блоках).
  • Resiliency factor в кластере устанавливается в процессе начальной инициализации кластера (в настоящий момент это возмодно только при начальной установке, но ведутся работы над тем, чтобы уметь делать это динамически)
  • При иницализации конфигурируется пять узлов zookeeper, хранящих пять копий метаданных.
  • В кластере с RF=3 ы можете иметь контейнеры с RF=2 или RF=3, то есть VM, которым требуется более высокая отказоустойчивость, могут использовать контейнер с RF=3.
  • RF для контейнера может быть изменен динамически (возможно выбрать RF равное 2 или 3).
  • Nutanix будет держать три копии одной группы экстентов (extent group) и стараться поддерживать состояние block awareness (разбрасывать копии по разным блокам-корпусам, если их несколько).
  • RF=3 и Block awareness могут быть сконфигурированы на одном кластере (требуется 5 блоков в 4.0 и 3 блока в 4.0.1)
  • RF=3 и дедупликация будет делать так, чтобы к кластере хранилось только три копии данной extent group. Поэтому, в ряде случаев, RF=2 без дедупликации может занимать больше места, чем RF=3 с дедупликацией.

rf3-image

rf3-fail

Шаги инициализации кластера с RF=3
Команды инициализации кластера с RF=3 в CLI:
cluster -f -s --redundancy_factor=3 create
ncli sp create name=sp add-all-free-disks=true
ncli ctr create name=red rf=3 sp-name=sp
ncli cluster get-domain-fault-tolerance-status type=node


Domain Type : NODE
Component Type : STATIC_CONFIGURATION
Current Fault Tolerance : 2
Fault Tolerance Details :
Last Update Time : Wed Jun 04 11:52:11 PDT 2014

Domain Type : NODE
Component Type : ZOOKEEPER
Current Fault Tolerance : 2
Fault Tolerance Details :
Last Update Time : Wed Jun 04 11:49:55 PDT 2014

Domain Type : NODE
Component Type : METADATA
Current Fault Tolerance : 2
Fault Tolerance Details :
Last Update Time : Wed Jun 04 11:46:55 PDT 2014

Domain Type : NODE
Component Type : OPLOG
Current Fault Tolerance : 2
Fault Tolerance Details :
Last Update Time : Wed Jun 04 11:51:18 PDT 2014

Domain Type : NODE
Component Type : EXTENT_GROUPS
Current Fault Tolerance : 2
Fault Tolerance Details :
Last Update Time : Wed Jun 04 11:51:18 PDT 2014

В итоге мы получаем кластер с RF=3, в котором Fault Tolerance разных его компонентов выдерживает отказ двух этих компонентов, в этом смысл «2» на картинке, сравните с аналогичной панелью приведенной выше, у кластера с RF=2.

rf3-prism