Настройка репликации кластера Apache HBase в виртуальных сетях Azure

Статья
04/29/2024

Настройка репликации Apache HBase в пределах одной или двух виртуальных сетей в Azure.

Репликация кластера использует методологию source-push. Кластер HBase может быть исходным, кластером назначения или выполнять обе роли одновременно. Репликация выполняется асинхронно. Целью репликации в конечном итоге является согласованность. При получении источником изменения в семействе столбцов с включенной репликацией такое изменение распространяется на все кластеры назначения. При репликации данных из одного кластера в другой исходный кластер и все кластеры, которые уже используют отслеживаемые данные, чтобы предотвратить циклы репликации.

В этой статье показано, как настроить репликацию «источник — назначение». Другие топологии кластеров см. в справочном руководстве по Apache HBase.

Примеры использования репликации HBase для одной виртуальной сети:

Балансировка нагрузки. Например, выполнения проверки или заданий MapReduce в целевом кластере и приема данных на исходном кластере.
Добавление высокого уровня доступности.
Перенос данных из одного кластера HBase в другой.
Обновление кластера Azure HDInsight до другой версии.

Примеры использования репликации HBase для двух виртуальных сетей:

Настройка аварийного восстановления.
Балансировка нагрузки и секционирование приложения.
Добавление высокого уровня доступности.

Кластеры можно реплицировать с помощью скриптов действий сценария, которые можно найти на GitHub.

Необходимые компоненты

Прежде чем приступать к изучению этой статьи, необходимо оформить подписку Azure. См. страницу о получении бесплатной пробной версии Azure.

Настройка сред

Доступны три варианта конфигурации:

два кластера Apache HBase в одной виртуальной сети Azure;
два кластера Apache HBase в двух виртуальных сетях в одном регионе;
два кластера Apache HBase в двух виртуальных сетях в двух регионах (георепликация).

В этой статье описан сценарий георепликации.

Чтобы помочь вам в настройке сред мы создали некоторые шаблоны Azure Resource Manager. Если вы предпочитаете настраивать среды с помощью других методов, см. следующие статьи:

Настройка двух виртуальных сетей в двух разных регионах

Для использования шаблона, который создает две виртуальные сети в двух разных регионах и соединяет их с помощью VPN-подключения, нажмите кнопку Развернуть в Azure.

Ниже приведены некоторые жестко заданные значения в шаблоне.

VNet 1

Свойство	Значение
Расположение	западная часть США
Имя виртуальной сети	<префикс_имени_кластера>-vnet1
Address space prefix	10.1.0.0/16
Имя подсети	subnet 1
Subnet prefix	10.1.0.0/24
Subnet (gateway) name	GatewaySubnet (не может быть изменено)
Префикс подсети (шлюза).	10.1.255.0/27
Имя шлюза.	vnet1gw
Тип шлюза	VPN
Тип VPN шлюза.	RouteBased.
Gateway SKU	Базовая
Gateway IP	vnet1gwip

VNet 2

Свойство	Значение
Расположение	Восточная часть США
Имя виртуальной сети	<префикс_имени_кластера>-vnet2
Address space prefix	10.2.0.0/16
Имя подсети	subnet 1
Subnet prefix	10.2.0.0/24
Subnet (gateway) name	GatewaySubnet (не может быть изменено)
Префикс подсети (шлюза).	10.2.255.0/27
Имя шлюза.	vnet2gw
Тип шлюза	VPN
Тип VPN шлюза.	RouteBased.
Gateway SKU	Базовая
Gateway IP	vnet1gwip

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

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

Настройка службы доменных имен (DNS)

В последнем разделе шаблон создает виртуальную машину Ubuntu в каждой виртуальной сети. В этом разделе вы установите Bind на две виртуальные машины DNS, а затем настроите на них переадресацию DNS.

Чтобы установить Bind, найдите общедоступные IP-адреса двух виртуальных машин DNS.

Откройте портал Azure.
Откройте виртуальную машину DNS, выбрав Группы ресурсов > [имя группы ресурсов] > [vnet1DNS]. Используйте имя группы ресурсов, созданной в последней процедуре. По умолчанию виртуальные машины DNS называются vnet1DNS и vnet2NDS.
Выберите Панель свойств. Откроется страница свойств виртуальной сети.
Запишите общедоступный IP-адрес, а также проверьте частный IP-адрес. Для vnet1DNS должен быть указан IP-адрес 10.1.0.4, а для vnet2DNS — 10.2.0.4.
Настройте использование в обеих виртуальных сетях DNS-серверов по умолчанию (предоставленных Azure). Это позволит разрешить входящий и исходящий доступ к пакетам, используемым при установке Bind на следующих шагах.

Чтобы установить Bind, выполните следующую процедуру.

Используйте SSH для подключения к общедоступному IP-адресу виртуальной машины. В следующем примере устанавливается подключение к виртуальной машине по адресу 40.68.254.142:
```
ssh sshuser@40.68.254.142
```
Замените sshuser учетной записью пользователя SSH, указанной при создании виртуальной машины DNS.
Примечание.

Есть несколько способов получить служебную программу ssh. В Linux, Unix и macOS она предоставляется в составе операционной системы. Если вы используете Windows, рассмотрите один из следующих вариантов:
Чтобы установить Bind, используйте следующие команды из сеанса SSH:
```
 sudo apt-get update -y
 sudo apt-get install bind9 -y
```
Настройте Bind на переадресацию запросов разрешения имен на локальный DNS-сервер. Чтобы сделать это, в качестве содержимого файла /etc/bind/named.conf.options добавьте следующий текст:
```
acl goodclients {
    10.1.0.0/16; # Replace with the IP address range of the virtual network 1
    10.2.0.0/16; # Replace with the IP address range of the virtual network 2
    localhost;
    localhost;
};

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-query { goodclients; };

    forwarders {
        168.63.129.16; #This is the Azure DNS server
    };

    dnssec-validation auto;

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
};
```
Внимание

Замените значения в разделе goodclients следующим диапазоном IP-адресов двух виртуальных сетей. Этот раздел определяет адреса, по которым этот DNS-сервер принимает запросы.

Чтобы изменить этот файл, используйте следующую команду:
```
sudo nano /etc/bind/named.conf.options
```
Чтобы сохранить файл, нажмите клавиши CTRL+X, затем — Y и ВВОД.
В сеансе SSH используйте следующую команду:
```
hostname -f
```
Эта команда возвращает значение следующего вида:
```
vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
```
Текст icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net — это DNS-суффикс для виртуальной сети. Сохраните это значение для последующего использования.

Кроме того, необходимо найти на DNS-сервере DNS-суффикс. Он понадобится нам на следующем шаге.
Чтобы настроить Bind для разрешения DNS-имен ресурсов в виртуальной сети, в качестве содержимого файла /etc/bind/named.conf.local добавьте следующий текст:
```
// Replace the following with the DNS suffix for your virtual network
zone "v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net" {
        type forward;
        forwarders {10.2.0.4;}; # The Azure recursive resolver
};
```
Внимание

Замените значение v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net DNS-суффиксом другой виртуальной сети. IP-адрес сервера пересылки представляет собой частный IP-адрес DNS-сервера в другой виртуальной сети.

Чтобы изменить этот файл, используйте следующую команду:
```
sudo nano /etc/bind/named.conf.local
```
Чтобы сохранить файл, нажмите клавиши CTRL+X, затем — Y и ВВОД.
Чтобы запустить Bind, используйте следующую команду:
```
sudo service bind9 restart
```
Чтобы убедиться, что привязка может разрешать имена ресурсов в другой виртуальной сети, используйте следующие команды:
```
sudo apt install dnsutils
nslookup vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
```
Внимание

Замените значение vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net полным доменным именем (FQDN) виртуальной машины DNS в другой сети.

Замените 10.2.0.4внутренним IP-адресом пользовательского DNS-сервера в другой виртуальной сети.

Ответ будет выглядеть следующим образом:
```
Server:         10.2.0.4
Address:        10.2.0.4#53

Non-authoritative answer:
Name:   vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
Address: 10.2.0.4
```
До сих пор не удается найти IP-адрес из другой сети без указанного IP-адреса DNS-сервера.

Настройка виртуальной сети для использования с пользовательским DNS-сервером

Чтобы настроить виртуальную сеть для использования с пользовательским DNS-сервером вместо рекурсивного сопоставителя Azure, сделайте следующее:

На портале Azure выберите виртуальную сеть, а затем — DNS-серверы.
Выберите Custom (Пользовательский) и введите внутренний IP-адрес пользовательского DNS-сервера. Наконец, щелкните Сохранить.
Откройте виртуальную машину DNS-сервера в виртуальной сети 1 и щелкните Перезагрузить. Чтобы конфигурация DNS вступила в силу, необходимо перезагрузить все виртуальные машины в виртуальной сети.
Повторите шаги настройки пользовательского DNS-сервера для виртуальной сети 2.

Чтобы проверить конфигурацию DNS, подключитесь к двум виртуальным машинам DNS с помощью SSH и проверьте связь с DNS-сервером другой виртуальной сети с помощью имени узла. Если это не сработает, используйте следующую команду для проверки состояния DNS:

sudo service bind9 status

Создание кластеров Apache HBase

В каждой виртуальной сети создайте кластер Apache HBase со следующей конфигурацией:

Имя группы ресурсов. Используйте те же имена групп ресурсов, как при создании виртуальных сетей.
Тип кластера. HBase.
Версия. HBase 1.1.2 (HDI 3.6).
Расположение. Используйте то же расположение, что и у виртуальной сети. По умолчанию для виртуальной сети 1 указано расположение западная часть США, а для виртуальной сети 2 — восточная часть США.
Хранилище. Создайте учетную запись хранения для кластера.
Виртуальная сеть (из дополнительных параметров на портале). Выберите виртуальную сеть 1, созданную в предыдущей процедуре.
Подсеть. Имя по умолчанию, используемое в шаблоне, — subnet1.

Чтобы убедиться, что среда правильно настроена, проверьте связь FQDN головного узла между двумя кластерами.

Загрузка тестовых данных

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

Чтобы создать таблицу Contacts и вставить в нее некоторые данные, следуйте инструкциям по началу работы с примером Apache HBase в HDInsight.

Примечание.

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

Включение репликации

Ниже описано, как вызвать скрипт действия сценария на портале Azure. Дополнительные сведения о том, как выполнить действие сценария с помощью Azure PowerShell и классической версии Azure CLI, см. в статье Настройка кластеров HDInsight под управлением Linux с помощью действий сценариев.

Включение репликации HBase на портале Azure

Войдите на портал Azure.
Откройте исходный кластер HBase.
В меню кластера выберите Действия скрипта.
В верхней части страницы выберите Отправить новое.
Выберите или введите следующие сведения.
1. Имя: введите Включение репликации.
2. URI bash-скрипта. Введите https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh.
3. Голова. Убедитесь, что этот параметр выбран. Отмените выбор других типов узлов.
4. Параметры: Параметры в следующем примере позволяют включить репликацию для всех существующих таблиц, а затем копировать все данные из исходного кластера в целевой.
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -copydata

Примечание.

Используйте имя узла вместо полного доменного имени (FQDN) для DNS-имени как исходного, так и целевого кластера.

В этом пошаговом руководстве предполагается, что hn1 является активным головным узлом. Проверьте кластер, чтобы определить активный головной узел.
Нажмите кнопку создания. Выполнение скрипта может занять некоторое время, особенно при использовании аргумента -copydata.

Ниже приведены обязательные аргументы.

Имя	Описание
-s, --src-cluster	Указывает DNS-имя исходного кластера HBase. например -s hbsrccluster, --src-cluster=hbsrccluster.
-d, --dst-cluster	Указывает DNS-имя кластера назначения (реплики) HBase. например -s dsthbcluster, --src-cluster=dsthbcluster.
-sp, --src-ambari-password	Указывает пароль администратора для Ambari в исходном кластере HBase.
-dp, --dst-ambari-password	Указывает пароль администратора для Ambari в целевом кластере HBase.

Необязательные аргументы для этой команды.

Имя	Описание
-su, --src-ambari-user	Указывает имя пользователя-администратора для Ambari в исходном кластере HBase. Значение по умолчанию — admin.
-du, --dst-ambari-user	Указывает имя пользователя-администратора для Ambari в целевом кластере HBase. Значение по умолчанию — admin.
-t, --table-list	Указывает таблицы для репликации. например --table-list="table1;table2;table3". Если не указать таблицы, будут реплицированы все существующие таблицы HBase.
-m, --machine	Указывает головной узел, на котором будет выполняться действие сценария. Значение должно быть выбрано в зависимости от активного головного узла. Используйте этот параметр при запуске скрипта $0 как действия сценария из портала HDInsight или Azure PowerShell.
-cp, -copydata	Включает перенос существующих данных для таблиц, где включена репликация.
-rpm, -replicate-phoenix-meta	Включает репликацию для системных таблиц Phoenix. Используйте этот параметр с осторожностью. Рекомендуется повторно создать таблицы Phoenix в реплицированных кластерах перед использованием этого скрипта.
-h, --help	Отображает сведения об использовании.

Раздел print_usage()скрипта содержит подробное описание параметров.

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

Сценарии репликации

Ниже перечислены некоторые общие способы применения и используемые параметры.

Включение репликации для всех таблиц между двумя кластерами. В этом сценарии не требуется копирование или перенос существующих данных в таблицах, и они не используют таблицы Phoenix. Используйте следующие параметры:

-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password>
Включение репликации для отдельных таблиц. Чтобы включить репликацию для table1, table2 и table3, используйте следующие параметры:

-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3"
Включение репликации для отдельных таблиц и копирование существующих данных. Чтобы включить репликацию для table1, table2 и table3, используйте следующие параметры:

-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3" -copydata
Включение репликации для всех таблиц с репликацией метаданных Phoenix из источника в место назначения. Репликация метаданных Phoenix не является идеальной. Ее следует использовать с осторожностью. Используйте следующие параметры:

-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3" -replicate-phoenix-meta

Настройка репликации между кластерами ESP

Необходимые условия

Оба кластера ESP должны находиться в одной области (домене). Проверьте /etc/krb5.conf свойство области по умолчанию для файла, чтобы подтвердить.
Общий пользователь должен иметь доступ на чтение и запись в обоих кластерах.
1. Например, если оба кластера имеют одного пользователя администратора кластера (например, admin@abc.example.com), этот пользователь может использоваться для запуска скрипта репликации.
2. Если оба кластера используют одну и ту же группу пользователей, можно добавить нового пользователя или использовать существующего пользователя из группы.
3. Если оба кластера используют другую группу пользователей, можно добавить нового пользователя для использования существующего пользователя из групп.

Действия по выполнению скрипта репликации

Примечание.

Выполните следующие действия, только если DNS не удается правильно разрешить имя узла целевого кластера.

Копирование сопоставления IP-адресов и имен узла кластера приемника в файлах исходного кластера /etc/hosts.
Скопируйте головной узел, рабочий узел и узлы ZooKeeper, а также сопоставление IP-адресов из файла назначения (приемника) из файла /etc/hosts.
Добавьте файл исходного кластера /etc/hosts скопированных записей. Эти записи следует добавить к головным узлам, рабочим узлам и узлам ZooKeeper.

Шаг 1. Создание файла keytab для пользователя с помощью ktutil. $ ktutil

addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
Запрос пароля для проверки подлинности, укажите пароль пользователя
wkt /etc/security/keytabs/admin.keytab

Примечание.

Убедитесь, что файл keytab хранится в /etc/security/keytabs/ папке <username>.keytab в формате.

Шаг 2. Выполнение действия скрипта с параметром -ku

Предоставляется -ku <username> в кластерах ESP.

Имя	Описание
`-ku, --krb-user`	Для кластеров ESP— общий пользователь Kerberos, который может проходить проверку подлинности как исходных, так и целевых кластеров.

Копирование и перенос данных

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

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

Выполните ту же процедуру, описанную в разделе Включение репликации для вызова действия сценария. Используйте следующие параметры:

-m hn1 -t <table1:start_timestamp:end_timestamp;table2:start_timestamp:end_timestamp;...> -p <replication_peer> [-everythingTillNow]

Раздел print_usage()скрипта содержит подробное описание параметров.

Сценарии

Копирование определенных таблиц (test1, test2 и test3) для всех строк, измененных до настоящего момента (текущая отметка времени):

-m hn1 -t "test1::;test2::;test3::" -p "<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure" -everythingTillNow

Или сделайте так:

-m hn1 -t "test1::;test2::;test3::" --replication-peer="<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure" -everythingTillNow
Копирование определенных таблиц с указанным интервалом времени:

-m hn1 -t "table1:0:452256397;table2:14141444:452256397" -p "<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure"

Отключение репликации

Чтобы отключить репликацию, используйте другой пример действия сценария из GitHub. Выполните ту же процедуру, описанную в разделе Включение репликации для вызова действия сценария. Используйте следующие параметры:

-m hn1 -s <source hbase cluster name> -sp <source cluster Ambari password> <-all|-t "table1;table2;...">

Раздел print_usage()скрипта содержит подробное описание параметров.

Сценарии

Отключение репликации для всех таблиц:

-m hn1 -s <source hbase cluster name> -sp Mypassword\!789 -all

or

--src-cluster=<source hbase cluster name> --dst-cluster=<destination hbase cluster name> --src-ambari-user=<source cluster Ambari user name> --src-ambari-password=<source cluster Ambari password>
Отключение репликации для определенных таблиц (table1, table2 и table3):

-m hn1 -s <source hbase cluster name> -sp <source cluster Ambari password> -t "table1;table2;table3"

Примечание.

Если планируется удалить целевой кластер, убедитесь, что он удален из однорангового списка исходного кластера. Это можно сделать, выполнив команду remove_peer '1' в оболочке hbase в исходном кластере. В случае возникновения сбоя исходный кластер может работать неправильно.

Следующие шаги

В этой статье описано, как настраивать репликацию Apache HBase в пределах одной или двух виртуальных сетей. Дополнительные сведения об HDInsight и Apache HBase см.в следующих статьях:

Поделиться через

Настройка репликации кластера Apache HBase в виртуальных сетях Azure

Необходимые компоненты

Настройка сред

Настройка двух виртуальных сетей в двух разных регионах

Настройка службы доменных имен (DNS)

Настройка виртуальной сети для использования с пользовательским DNS-сервером

Создание кластеров Apache HBase

Загрузка тестовых данных

Включение репликации

Сценарии репликации

Настройка репликации между кластерами ESP

Копирование и перенос данных

Сценарии

Отключение репликации

Сценарии

Следующие шаги

Обратная связь

Дополнительные ресурсы