Руководство по планированию кластера

Руководство по планированию кластера включает в себя следующие главы необходимые для прочтения перед непосредственной установкой кластера:

Рекомендации по аппаратному обеспечению для Apache Hadoop

Рабочие нагрузки Hadoop и HBase, как правило, сильно различаются, и необходим опыт для правильного прогнозирования объемов хранилища, вычислительной мощности и межузловой связи, которые потребуются для выполнения различных видов работ.

В главе содержится информация о выборе соответствующих аппаратных компонентов для оптимального баланса между производительностью и стабильностью работы для различных нагрузок:

Краткое резюме приведено в разделе Заключение.

Hadoop – это программный фреймворк, поддерживающий распределенный анализ данных на стандартных серверах. Arenadata является участником инициатив с открытым исходным кодом (Apache Hadoop, HDFS, Pig, Hive, HBase, ZooKeeper) и имеет большой опыт управления кластерами Hadoop на производственном уровне. Arenadata рекомендует следовать принципам проектирования, которые обеспечивают надежное развертывание на различном оборудовании.

Для кластера Hadoop или HBase крайне важно точно спрогнозировать объем, тип, и количество задач. Начиная с Hadoop или HBase, есть возможность получения метрик, измеряя фактические рабочие нагрузки во время пилотного проекта. Таким образом, можно легко масштабировать пилотную среду, не внося существенных изменений в существующее оборудование, программное обеспечение, стратегии развертывания и сетевое подключение.

Типичный кластер Hadoop

Кластеры Hadoop и HBase имеют два типа машин:

  • Masters – HDFS NameNode, YARN ResourceManager и HBase Master;
  • Slaves – HDFS DataNodes, YARN NodeManagers и HBase RegionServers.

Узлы DataNodes, NodeManagers и HBase RegionServers размещаются и разворачиваются совместно для оптимальной локализации данных. Кроме того, HBase требует использования отдельного компонента (ZooKeeper) для управления кластером.

Arenadata рекомендует разделять master (основные) и slave (подчиненные) узлы, поскольку:

  • Рабочие нагрузки задачи/приложения на подчиненных узлах должны быть изолированы от основных;
  • Подчиненные узлы часто выводятся из эксплуатации для технического обслуживания.

В целях эксперимента или тестирования можно развернуть Hadoop, используя инсталляцию с одним узлом (при условии, что все основные и подчиненные процессы находятся на одной машине). Для небольшого двухузлового кластера можно установить NameNode и ResourceManager на master-узле, а DataNode и NodeManager на slave-узле.

Кластеры из трех или более машин обычно используют один NameNode и ResourceManager со всеми другими узлами в качестве подчиненных. Кластер High-Availability использует первичный и вторичный NameNode, а также может использовать первичный и вторичный ResourceManager.

Как правило, кластер Hadoop среднего и большого размера состоит из двухуровневой или трехуровневой архитектуры, построенной на монтируемых в стойку серверах. Каждая стойка серверов соединена с помощью коммутатора 1 Gigabit Ethernet (GbE). Каждый коммутатор уровня стойки подключен к коммутатору уровня кластера (который, как правило, является коммутатором с большей плотностью портов 10GbE). Коммутаторы кластерного уровня могут также соединяться с другими коммутаторами уровня кластера или даже принадлежать к другому уровню инфраструктуры.

Шаблоны рабочей нагрузки для Hadoop

Дисковое пространство, пропускная способность ввода-вывода (необходимая для Hadoop) и вычислительная мощность (необходимая для процессов MapReduce) являются наиболее важными параметрами для точного определения размера оборудования. Кроме того, при установке HBase также необходимо проанализировать приложение и его требования к памяти, поскольку HBase является компонентом, интенсивно использующим память. Исходя из типичных вариантов использования Hadoop, в рабочих средах наблюдаются следующие шаблоны нагрузки:

  • Balanced Workload – сбалансированная

Если рабочие нагрузки распределены равномерно между различными типами заданий (привязка к процессору, к дисковому вводу/выводу или к сетевому вводу/выводу), кластер имеет сбалансированный шаблон рабочей нагрузки. Это хорошая конфигурация по умолчанию для неизвестных или растущих нагрузок.

  • Compute Intensive – ресурсоемкая

Рабочие нагрузки связаны с ЦП и характеризуются необходимостью большого количества процессоров и большого объема памяти для хранения данных в процессе. Шаблон использования типичен для обработки естественного языка или рабочих нагрузок HPCC.

  • I/O Intensive – интенсивный ввод/вывод

Типичное задание MapReduce (например, сортировка) требует очень мало вычислительной мощности. Вместо этого оно больше зависит от связанной способности ввода/вывода кластера (например, при большом объеме холодных данных). Для такого типа рабочей нагрузки рекомендуется закладывать больше дисков.

  • Unknown or evolving workload patterns – неизвестные или растущие шаблоны рабочей нагрузки

Изначально можно не знать необходимые шаблоны рабочей нагрузки. И, как правило, первые задания, переданные в Hadoop, сильно отличаются от фактических, которые будут выполняться в производственной среде. По этим причинам Arenadata рекомендует либо использовать конфигурацию сбалансированной рабочей нагрузки, либо инвестировать в пилотный кластер Hadoop и планировать развитие его структуры по мере анализа шаблонов рабочей нагрузки в среде.

Early Deployments

При первом знакомстве с Hadoop или HBase рекомендуется начинать с относительно небольшого экспериментального кластера, рассчитанного на Balanced Workload и получать оценку путем измерения фактических рабочих нагрузок во время пилотного проекта.

Для пилотного развертывания можно начать с 1U-машины и использовать следующие рекомендации:

  • Два четырехъядерных процессора;
  • От 12 до 24 ГБ памяти;
  • От четырех до шести дисков емкостью 2 ТБ.

Минимальное требование для сети составляет 1GbE all-to-all и может быть легко достигнуто путем подключения всех узлов к коммутатору Gigabit Ethernet. Чтобы использовать запасной сокет для добавления процессоров в будущем, можно использовать шести или восьми ядерный процессор.

Для небольших и средних кластеров HBase необходимо предоставить каждому серверу ZooKeeper около 1 ГБ RAM и желательно собственный диск.

Jump-start – Hadoop Cluster

Один из способов быстрого развертывания Hadoop – выбрать “cloud trials” или использовать виртуальную инфраструктуру. Arenadata обеспечивает доступность дистрибутива через платформу данных Enterprise Data Platform (EDP), которую можно установить в общедоступных и частных облаках.

Обратиться в службу технической поддержки Arenadata можно по адресу электронной почты info@arenadata.io или через окно консультации на сайте www.arenadata.io.

Однако, облачные сервисы и виртуальные инфраструктуры не предназначены для Hadoop. В этом случае развертывания Hadoop и HBase могут иметь низкую производительность из-за виртуализации и неоптимальной архитектуры ввода/вывода.

Контроль ресурсов при пилотном развертывании

Arenadata рекомендует контролировать пилотный кластер с помощью Ganglia, Nagios или других систем мониторинга производительности. При этом важно:

  • Измерить использование ресурсов для CPU, RAM, операций дискового ввода/вывода в секунду (IOPS) и отправленных и полученных сетевых пакетов. Запустить актуальные виды запросов или аналитических заданий;
  • Убедиться, что подмножество данных масштабируется до размера пилотного кластера;
  • Проанализировать данные мониторинга на предмет насыщения ресурсов. На основе этого анализа можно классифицировать задания как связанные с процессором, с дисковым вводом/выводом или с сетевым вводом/выводом.

Important

Большинство приложений Java допускают использование RAM до максимально заданного значения

  • Проанализировать ZooKeeper (так как в нем часто обнаруживаются проблемы, свзязанные с сетью и памятью для HBase).
  • (Опционально) Настроить параметры работы и конфигурации оборудования или сети, чтобы сбалансировать использование ресурсов. Если задания попадают в разные шаблоны рабочей нагрузки, можно выбрать управление только параметрами задания, а для оборудования оставить “balanced”.

Challenges – настройка job-характеристик на использование ресурсов

Способ разработки приложения или представления данных может оказать большое влияние на баланс ресурсов. Например, затраты ресурсов могут быть смещены между дисковым IOPS и CPU с учетом выбранной схемы сжатия или формата синтаксического анализа. Процессор для каждого узла и активность диска можно обменять на пропускную способность между узлами в зависимости от реализации стратегии Map/Reduce.

Кроме того, Amdahl’s Law показывает, как требования к ресурсам могут меняться в значительной степени нелинейным образом при изменении требований: изменение, которое, как можно ожидать, приведет к снижению затрат на вычисления на 50%, может вместо этого привести к изменению чистой производительности на 10% или на 90%.

Повторное использование пилотных машин

Установив пилотный кластер, можно приступить к анализу шаблонов рабочих нагрузок для выявления узких мест CPU и I/O. Позже эти машины могут быть повторно использованы в производственных кластерах, даже если базовые характеристики изменятся.

Чтобы добиться положительного коэффицента возврата инвестиций (return on investment, ROI), рекомендуется убедиться, что машины в пилотных кластерах составляют менее 10% от конечного производственного кластера.

Аппаратное обеспечение для узлов кластера

В разделе приведены рекомендации по аппаратному обеспечению узла сервера для выбора количества узлов, параметров хранилища на узел (количество дисков и их размер, MTBF и затраты на репликацию при сбоях дисков), вычислительной мощности на узел (сокеты, ядра, тактовая частота), RAM на узел и возможности сети (количество, скорость портов):

Slave узлы

Серверная платформа

Как правило, серверы с двумя сокетами являются оптимальными для развертывания Hadoop. Для средних и больших кластеров их использование является лучшим выбором по сравнению с серверами начального уровня благодаря возможности балансировки нагрузки и распараллеливания. С точки зрения компактности выбирается серверное оборудование, которое подходит для небольшого количества стоек. Обычно серверы 1U или 2U используются в 19” стойках или шкафах.

Возможности хранения

Для приложений общего назначения рекомендуется использовать относительно большое количество жестких дисков, обычно от 8 до 12 дисков SATA LFF на сервер. В настоящее время типичная емкость Hadoop в производственных средах составляет около 2 ТБ на диск. Высокоинтенсивные среды ввода/вывода могут потребовать диски 12x2 TБ SATA. Оптимальный баланс между затратами и производительностью, как правило, достигается с помощью дисков SATA емкостью 7200 об/мин. Если в хранилище прогнозируется значительный рост, следует рассмотреть возможность использования дисков 3 ТБ.

SFF-диски используются в некоторых конфигурациях для лучшей пропускной способности диска. Рекомендуется отслеживать кластер на предмет возможных сбоев дисков, так как увеличение их количества приводит и к повышению частоты сбоев. Если количество дисков на сервере велико, следует использовать два дисковых контроллера, чтобы нагрузка ввода/вывода могла распределяться между несколькими ядрами. Настоятельно рекомендуется использовать только SATA или SAS.

В HDFS, в котором используется недорогая надежная система хранения, данные остаются неограниченное время и потребности в хранилище быстро растут. С 12-дисковыми системами обычно получается 24 или 36 ТБ на узел. Использование такой емкости хранилища в узле целесообразно с версией Hadoop 2.0 и выше.

Hadoop – это интенсивное и эффективное хранилище, не требующее при этом быстрых и дорогих жестких дисков. Если шаблон рабочей нагрузки не является I/O Intensive, можно добавить только четыре или шесть дисков на узел. Важно понимать, что затраты на электроэнергию пропорциональны количеству дисков, а не емкости хранилища.

Important

RAID vs. JBOD: не рекомендуется использовать RAID на slave-машинах Hadoop. Кластер допускает вероятность сбоя диска и обеспечивает избыточность данных на всех подчиненных узлах

Important

Диски должны иметь хорошие значения MTBF, так как подчиненные узлы в Hadoop подвержены сбоям

Подчиненные узлы не нуждаются в дорогостоящей поддержке, предлагающей услуги замены дисков в течение двух часов или меньше. Hadoop адаптирован к отказам slave-узлов, и поэтому следует относиться к работам по обслуживанию подчиненных узлов как к постоянной задаче, а не как к чрезвычайной ситуации.

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

Размер памяти

Крайне важно обеспечить достаточную память, чтобы процессоры были заняты без подкачки и без чрезмерных затрат на нестандартные материнские платы. В зависимости от количества ядер подчиненным узлам обычно требуется от 24 до 48 ГБ оперативной памяти. Для больших кластеров этот объем памяти обеспечивает достаточно дополнительной RAM (приблизительно 4 ГБ) для платформы Hadoop и для процессов запросов и анализа (HBase и/или Map/Reduce).

Для обнаружения и исправления случайных нерегулярных ошибок настоятельно рекомендуется использовать память с error correcting code (ECC). Исправление ошибок RAM позволяет доверять качеству вычислений. Доказано, что некоторые детали (chip-kill/chip spare) обеспечивают лучшую защиту с меньшим повторением битовых ошибок, чем традиционные конструкции.

При желании сохранения возможности добавления дополнительной памяти на серверы в будущем необходимо убедиться, что для этого есть место рядом с начальными модулями памяти.

Подготовка памяти

Память может представлять собой недорогие материнские платы на серверах низкого уровня, что типично для технологии Over-Provisioning. Неиспользуемая RAM в таком случае применяется либо приложениями Hadoop (обычно при параллельном запуске нескольких процессов), либо инфраструктурой (для кэширования данных на диске с целью повышения производительности).

Процессоры

Не смотря на то, что важно понимать шаблон рабочей нагрузки, рекомендуется использовать процессоры со средней тактовой частотой и менее, чем с двумя сокетами. Для большинства рабочих нагрузок дополнительная производительность на узел не является экономически эффективной. Следует использовать как минимум два четырехъядерных процессора для подчиненных машин больших кластеров.

Мощность

Мощность является главной задачей при проектировании кластеров Hadoop. Прежде, чем приобретать самые большие и быстрые узлы, советуется проанализировать расход энергии для имеющегося оборудования. Существует возможность огромной экономии в затратах и энергопотреблении путем избежания покупки самых быстрых процессоров, резервных источников питания и прочего.

Производители создают легковесные машины для облачных центров обработки данных с целью снижения затрат и энергопотребления. Например, Supermicro, Dell и HP имеют такие линейки продуктов для облачных провайдеров. Поэтому при необходимости закупки в большом объеме, рекомендуется оценить эти упрощенные “cloud servers”.

Для подчиненных узлов достаточно одного блока питания (PSU), но для мастер-серверов необходимо использовать резервные блоки. Конструкции серверов, которые совместно используют PSU на смежных серверах, могут обеспечить повышенную надежность без увеличения затрат.

Important

Потребляемая мощность кластера: электричество и охлаждение составляют от 33,33% до 50% общей стоимости жизненного цикла оборудования в современных дата-центрах

Сеть

Сеть – это наиболее сложный параметр для предварительной оценки, поскольку рабочие нагрузки Hadoop сильно различаются. Ключевой позицией является покупка достаточной емкости сети при приемлемых затратах так, чтобы все узлы в кластере могли обмениваться данными с разумной скоростью. В больших кластерах обычно используются двойные каналы по 1 ГБ для всех узлов в каждой 20-node стойке и соединительные каналы 2х10 ГБ, доходящие до пары центральных коммутаторов.

Хороший расчет сети учитывает возможность перегрузки в критических точках при реальных нагрузках. Общепринятые коэффициенты превышения oversubscription составляют примерно 4:1 на уровне доступа к серверу и 2:1 между уровнем доступа и уровнем или ядром агрегации. Более низкие показатели превышения переподписки можно рассматривать, если требуется повышенная производительность. Кроме того, рекомендуется oversubscription 1 ГБ между стойками.

Крайне важно иметь выделенные коммутаторы для кластера, а не пытаться назначать виртуальные каналы в существующих коммутаторах – нагрузка Hadoop воздействует на остальных пользователей коммутатора. Не менее важно работать с сетевой командой, чтобы гарантировать, что коммутаторы подходят как Hadoop, так и инструментам мониторинга.

Сеть необходимо разработать так, чтобы сохранить возможность добавления дополнительных стоек серверов Hadoop/HBase. В ином случае исправления в сети могут быть дорогостоящими. “Глубокая буферизация” (“Deep buffering”) предпочтительнее низкой задержки в коммутаторах. Кроме того, включение Jumbo Frames в кластере совершенствует пропускную способность за счет улучшения контрольных сумм файлов, а также может обеспечить целостность пакета.

Important

Сетевая стратегия Hadoop: важно проанализировать соотношение стоимости network-to-computer и убедиться, что стоимость сети составляет около 20% от общей стоимости. Hadoop разработан с учетом аппаратного обеспечения, и сетевые затраты должны комплексно включать: коммутаторы ядра сети, коммутаторы стойки, любые необходимые сетевые карты и т.д.

Master узлы

Главные узлы, будучи уникальными, предъявляют значительно иные требования к хранению и памяти, чем подчиненные узлы. Далее рассматриваются некоторые из компромиссов между памятью и хранилищем. Ориентир по сайзингу для небольших (5–50 узлов) и средних/больших (100-1000 узлов) кластеров приведены в главе Заключение.

Рекомендуется использовать два сервера NameNode – основной и вторичный. Оба сервера должны иметь высоконадежное хранилище для пространства имен и ведения журнала edit-log. Как правило, аппаратный RAID и/или надежное сетевое хранилище являются оправданными вариантами.

Главные серверы должны иметь как минимум четыре резервных тома хранения, несколько локальных и сетевых, но при этом каждый может быть относительно небольшим (обычно 1 ТБ). RAID-диски на главных узлах являются хорошим местом для контрактов поддержки при этом рекомендуется включить опцию замены диска on-site.

Варианты хранения для ResourceManager

На самом деле сервера ResourceManager не нуждаются в RAID-хранилище, поскольку они сохраняют свое состояние в HDFS. Сервер фактически может быть запущен на slave-узле с небольшим количеством дополнительной RAM. Однако использование тех же аппаратных спецификаций для ResourceManager, что и для NameNode, обеспечивает возможность переноса NameNode на тот же сервер, что и ResourceManager, в случае сбоя NameNode, и копию состояния NameNode может быть сохранена в сетевом хранилище.

Память

Объем памяти, необходимый для мастер-узлов, зависит от количества объектов файловой системы, которые создаются и отслеживаются с помощью NameNode. 64 ГБ оперативной памяти поддерживает около 100 миллионов файлов. Некоторые сайты сейчас экспериментируют с 128 ГБ RAM для еще больших пространств имен.

Процессоры

NameNodes активно взаимодействует с клиентами и компонентами кластера. Поэтому рекомендуется предоставлять 16 или даже 24 ядер CPU для обработки трафика обмена сообщениями для главных узлов.

Сеть

Кластер желательно обеспечение множеством сетевых портов и пропускной способностью 10 ГБ для коммутатора.

Аппаратное обеспечение HBase

HBase использует различные типы кэшей для заполнения памяти, и, как правило, чем больше памяти у HBase, тем лучше он может кэшировать запросы на чтение. Каждый slave-узел в кластере HBase (RegionServer) поддерживает несколько областей (фрагментов данных в памяти). Для больших кластеров важно убедиться, что HBase Master и NameNode работают на отдельных серверах. Так же необходимо обратить внимание, что в крупномасштабных развертываниях узлы ZooKeeper не разворачиваются совместно с подчиненными узлами Hadoop/HBase.

Варианты хранения

При распределенной настройке HBase хранит данные в HDFS. Для получения максимальной локальности чтения/записи HBase RegionServers и DataNodes должны быть совместно развернуты на одних и тех же машинах. Поэтому все рекомендации по настройке оборудования DataNode и NodeManager также применимы к RegionServers. В зависимости от того, ориентированы ли приложения HBase на чтение/запись или на обработку, необходимо сбалансировать количество дисков с количеством доступных ядер процессора. Как правило, должно быть по крайней мере одно ядро на диск.

Память

Главные узлы HBase не так интенсивно используют вычислительные ресурсы, как типичный сервер RegionServer или NameNode. Поэтому для мастера HBase можно выбрать более скромную настройку памяти. Требования к памяти RegionServer сильно зависят от характеристик рабочей нагрузки кластера. Хотя избыточное выделение памяти выгодно для всех шаблонов рабочей нагрузки.

Кроме того, при работе кластера HBase с Hadoop необходимо обеспечить избыточную память для Hadoop MapReduce не менее, чем на 1–2 ГБ для каждой задачи поверх памяти HBase.

Другие аспекты

Вес

Плотность хранения серверов последнего поколения подразумевает, что необходимо учитывать вес стоек. Следует убедиться, что вес стойки не превышает допустимую нагрузку пола центра обработки данных.

Масштабируемость

Hadoop легко масштабировать, добавляя в него новые сервера или целые серверные стойки и увеличивая объем памяти в главных узлах для работы с повышенной нагрузкой. Сначала это создает “перебалансировку трафика”, но в итоге обеспечивает дополнительное место для хранения и вычисления.

Для масштабирования кластера необходимо:

  • Убедиться, что в центре обработки данных рядом с кластером Hadoop имеется потенциальное свободное пространство. Оно должно быть в состоянии вместить бюджет мощности для увеличенного количества стоек;
  • Планировать сеть так, чтобы справиться с ростом количества серверов;
  • Добавить больше дисков и RAM при наличии запасных сокетов в серверах, что позволит расширить существующий кластер без добавления дополнительных стоек или сетевых изменений;
  • Планировать расширение по одному серверу за раз, так как обновление оборудования в работающем кластере может занять значительное время;
  • При планировании дополнительного ЦП следует проконсультироваться с торговым представителем о сроках поставки, которые могут занять до 18 месяцев;
  • Может потребоваться больше памяти на master-серверах.

Support

Концепция, которую следует рассмотреть, – это “заботиться о главных узлах, следить за подчиненными узлами”. Для большинства узлов кластера не нужны традиционные контракты на аппаратную поддержку корпоративного класса, поскольку их сбои являются скорее статистической проблемой, чем кризисом. Сэкономленные средства на поддержке оборудования могут пойти на большее количество подчиненных узлов.

Ввод в эксплуатацию

Важно обратить внимание, что “smoke tests”, которые поставляются с кластером Hadoop, являются хорошим начальным тестом.

Заключение

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

Следующие рекомендации составного системного стека могут помочь на этапах планирования:

Табл. 1. Рекомендации по составному системному стеку
Сервер Нагрузка Хранение [1] Процессор Память Сеть
Slaves Balanced workload Двенадцать дисков по 2-3 ТБ 8 ядер 128-256 ГБ 1 GB onboard, 2x10 GbE mezzanine/external
  Compute-intensive workload Двенадцать дисков по 1-2 ТБ 10 ядер 128-256 ГБ 1 GB onboard, 2x10 GbE mezzanine/external
  Storage-heavy workload Двенадцать дисков по 4+ ТБ 8 ядер 128-256 ГБ 1 GB onboard, 2x10 GbE mezzanine/external
NameNode Balanced workload Четыре или более 2-3 ТБ RAID 10 with spares 8 ядер 128-256 ГБ 1 GB onboard, 2x10 GbE mezzanine/external
Resource Manager Balanced workload Четыре или более 2-3 ТБ RAID 10 with spares 8 ядер 128-256 ГБ 1 GB onboard, 2x10 GbE mezzanine/external
[1]Дополнительно зарезервировать как минимум 2,5 ГБ на жестком диске для каждой устанавливаемой версии Hadoop.

Рекомендации по партиционированию файловой системы

Настройка партиций файловой системы

Базовая конфигурация для всех узлов кластера:

  • Root-партиция: ОС и основные программные файлы;
  • Swap: размер 2x системной памяти.

Партиционирование Slave-узлов:

  • Партиции Hadoop Slave: Hadoop должен иметь свои собственные партиции для файлов и журналов. Диски должны быть разделены с помощью XFS или ext4 (в соответствующем порядке предпочтения). Крайне не рекомендуется использовать LVM – создает задержку и узкие места;
  • На slave-узлах все партиции Hadoop должны устанавливаться индивидуально для дисков как /hdfs/[0-n];
  • Пример конфигурации Hadoop Slave Node Partitioning:
    • /root – 20 ГБ: достаточно для существующих файлов, дальнейшего роста журнала и обновлений ОС;
    • /hdfs/0/ – полный диск ГБ: первая партиция Hadoop для локального хранилища;
    • /hdfs/1/ – вторая партиция Hadoop;
    • /hdfs/2/ – …

Рекомендации по резервированию (RAID):

  • Master узлы – конфигурация на надежность (RAID 10, двойные карты Ethernet, двойные блоки электропитания);
  • Slave узлы – RAID не требуется, сбои на узлах управляется автоматически кластером. Все данные хранятся по крайней мере на трех разных хостах.