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

Настройка репликации 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. Если вы предпочитаете настраивать среды с помощью других методов, см. следующие статьи:

• Создание кластеров Apache Hadoop в HDInsight
• Создание кластеров Apache HBase в виртуальной сети Azure

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

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

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

VNet 1

VNet 2

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

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

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

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

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

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

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

1. Используйте SSH для подключения к общедоступному IP-адресу виртуальной машины. В следующем примере устанавливается подключение к виртуальной машине по адресу 40.68.254.142:

   ssh sshuser@40.68.254.142
   

   Замените sshuser учетной записью пользователя SSH, указанной при создании виртуальной машины DNS.

   Примечание.

   Есть несколько способов получить служебную программу ssh. В Linux, Unix и macOS она предоставляется в составе операционной системы. Если вы используете Windows, рассмотрите один из следующих вариантов:

   • Azure Cloud Shell
   • Bash на платформе Ubuntu в Windows 10;
   • Git (https://git-scm.com/);
   • OpenSSH (https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH).

2. Чтобы установить Bind, используйте следующие команды из сеанса SSH:

    sudo apt-get update -y
    sudo apt-get install bind9 -y
   

3. Настройте 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 и ВВОД.

4. В сеансе SSH используйте следующую команду:

   hostname -f
   

   Эта команда возвращает значение следующего вида:

   vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
   

   Текст icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net — это DNS-суффикс для виртуальной сети. Сохраните это значение для последующего использования.

   Кроме того, необходимо найти на DNS-сервере DNS-суффикс. Он понадобится нам на следующем шаге.

5. Чтобы настроить 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 и ВВОД.

6. Чтобы запустить Bind, используйте следующую команду:

   sudo service bind9 restart
   

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

   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, сделайте следующее:

1. На портале Azure выберите виртуальную сеть, а затем — DNS-серверы.

2. Выберите Custom (Пользовательский) и введите внутренний IP-адрес пользовательского DNS-сервера. Наконец, щелкните Сохранить.

3. Откройте виртуальную машину DNS-сервера в виртуальной сети 1 и щелкните Перезагрузить. Чтобы конфигурация DNS вступила в силу, необходимо перезагрузить все виртуальные машины в виртуальной сети.

4. Повторите шаги настройки пользовательского 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

1. Войдите на портал Azure.

2. Откройте исходный кластер HBase.

3. В меню кластера выберите Действия скрипта.

4. В верхней части страницы выберите Отправить новое.

5. Выберите или введите следующие сведения.

   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 является активным головным узлом. Проверьте кластер, чтобы определить активный головной узел.

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

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

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

Раздел 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

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

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

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

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

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

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

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

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

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

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

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

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

-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"

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

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

• Начало работы с примером Apache HBase в HDInsight
• Общие сведения об HDInsight Apache HBase
• Создание кластеров Apache HBase в виртуальной сети Azure