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

Nutanix OS 4.0: Replication Factor = 3: 5 комментариев

  1. Dmitry Morozovsky

    При RF=2 у нас две комии или две *дополнительные* копии? Аналогично, сколько их при RF=3 — откуда требование 5 узлов?

    1. Sergey

      Все просто.
      RF2. Оригинал + копия блока данных, оригинал + 2 копии метаданных. Необходимо от 3х нод.
      RF3. Оригинал + 2 копии блоков данных, оригинал + 4 копии метаданных. Необходимо от 5 нод.

  2. comotoza

    RF=3, всего 3 копии, оригинал и 2 копии

    требование 5 узлов, на сколько понимаю это требование работы zookeeper/cassandra, чтобы при выходе 2 узлов из строя или сплите сети 3 хоста смогли между собой договориться
    для RF=2 тоже самое 2 хоста живы-могу договориться, может выдержать выход из строя 1 сервера
    это на сколько я понял, что написано тут
    http://www.datastax.com/docs/1.1/dml/data_consistency

  3. comotoza

    для RF=2 3 копии zookeeper/cassandra, для RF=3 5 копий этих компонентов
    потому минимальное требование 3 и 5 соответственно

  4. Уведомление: X vs. Y: VSAN 6.0. Что нового? - Virtualization solution with a nuts

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *