Краткое руководство. Настройка гибридного кластера с помощью службы "Управляемый экземпляр Azure для Apache Cassandra"

  • Статья

Azure Управляемый экземпляр для Apache Cassandra — это полностью управляемая служба для чистых кластеров Apache Cassandra с открытым кодом. Служба также позволяет переопределить конфигурации в зависимости от конкретных потребностей каждой рабочей нагрузки, что позволяет обеспечить максимальную гибкость и контроль при необходимости.

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

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

  • Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.

  • Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.

    • Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью Azure CLI.

    • Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.

    • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

  • Для работы с этой статьей потребуется Azure CLI 2.30.0 или более поздней версии. Если вы используете Azure Cloud Shell, последняя версия уже установлена.

  • Azure виртуальная сеть с подключением к локальной или локальной среде. Дополнительные сведения о подключении локальных сред к Azure см. в статье Подключение локальной сети к Azure.

Настройка гибридного кластера

  1. Войдите на портал Azure и найдите нужный ресурс виртуальной сети.

  2. Откройте вкладку Подсети и создайте новую подсеть. Дополнительные сведения о полях в форме Добавление подсети можно найти в статье о виртуальной сети.

    Add a new subnet to your Virtual Network.

    Примечание.

    Для развертывания Управляемого экземпляра Azure для Apache Cassandra требуется доступ к Интернету. Развертывание будет завершаться сбоем в средах с ограниченным доступом к Интернету. Убедитесь, что вы не блокируете в виртуальной сети доступ к следующим жизненно важным службам Azure, которые необходимы для нормальной работы Управляемого экземпляра Cassandra: Кроме того, здесь можно найти обширный список зависимостей IP-адресов и портов.

    • Хранилище Azure
    • Azure Key Vault
    • Масштабируемые наборы виртуальных машин Azure
    • Мониторинг Azure
    • Microsoft Entra ID
    • Безопасность в Azure

  3. Теперь мы с помощью Azure CLI применим к виртуальной сети и подсетям специальные разрешения, которые требует Управляемый экземпляр Cassandra. Выполните команду az role assignment create, заменив <subscriptionID>, <resourceGroupName>, и <vnetName> соответствующими значениями:

    az role assignment create \
  --assignee a232010e-820c-4083-83bb-3ace5fc29d0b \
  --role 4d97b98b-1d4f-4787-a291-c67834d212e7 \
  --scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>

    Примечание.

    Значения assignee и role в предыдущей команде являются фиксированными идентификаторами субъекта-службы и роли соответственно.

  4. Теперь нам предстоит настроить ресурсы для гибридного кластера. Так как кластер у вас уже есть, имя кластера здесь является логическим ресурсом, который позволяет указать имя существующего кластера. Обязательно указывайте имя существующего кластера при определении переменных clusterName и clusterNameOverride в следующем скрипте.

    Также вам нужны, как минимум, начальные узлы из существующего центра обработки данных и сертификаты gossip для шифрования данных при передаче между узлами. Управляемый экземпляр Azure для Apache Cassandra требует использовать шифрование между узлами для обмена данными между центрами обработки данных. Если в существующем кластере еще не реализовано шифрование данных при передаче между узлами, необходимо его реализовать по этим инструкциям. Вам нужно указать путь к расположению сертификатов. Каждый сертификат должен иметь формат PEM, например -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Как правило, существует два способа реализации сертификатов:

    1. Самозаверяющие сертификаты. Они включают закрытый и открытый (без использования центра сертификации) сертификат для каждого узла. В нашем примере все сертификаты должны быть открытыми.

    2. Сертификаты, подписанные центром сертификации. Центр сертификации может быть самозаверяющим или общедоступным. В нашем примере потребуется сертификат корневого центра сертификации (воспользуйтесь инструкциями по подготовке SSL-сертификатов для рабочей среды) и все промежуточные сертификаты, если они есть.

    При необходимости, если требуется реализовать проверку подлинности сертификата типа "клиент — узел" или взаимную проверку подлинности на уровне транспорта (mTLS), необходимо предоставить сертификаты в том же формате, что и при создании гибридного кластера. См. пример Azure CLI ниже. Сертификаты предоставляются в параметре --client-certificates . Это отправит и применит сертификаты клиента к хранилищу доверия для кластера Cassandra Управляемый экземпляр (т. е. не нужно изменять параметры cassandra.yaml). После применения кластеру потребуется Cassandra проверить сертификаты при подключении клиента (смrequire_client_auth: true. в client_encryption_options Cassandra).

    Примечание.

    Значение переменной delegatedManagementSubnetId, которое вы будете указывать ниже, точно совпадает со значением --scope, указанным в команде выше:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster-legal-name'
clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'

# You can override the cluster name if the original name is not legal for an Azure resource:
# overrideClusterName='ClusterNameIllegalForAzureResource'
# the default cassandra version will be v3.11

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
  --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
  # optional - add your existing datacenter's client-to-node certificates (if implemented):
  # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed

    Примечание.

    Если в кластере уже настроено шифрование данных при передаче между узлами и между узлом и клиентом, вам нужно знать, где хранятся SSL-сертификаты gossip и (или) клиента. Если вам это неизвестно, можно выполнить keytool -list -keystore <keystore-path> -rfc -storepass <password> для вывода сертификатов.

  5. После создания ресурса кластера выполните следующую команду, чтобы получить сведения о настройке кластера:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'

az managed-cassandra cluster show \
   --cluster-name $clusterName \
   --resource-group $resourceGroupName \

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

    Get the certificate details from the cluster.

    Примечание.

    Приведенная выше команда возвращает сертификаты с разрывами строк, представленными в текстовом виде, например так: \r\n. Нужно скопировать каждый сертификат в файл и исправить его формат, прежде чем пытаться импортировать его в хранилище доверия в существующем центре обработки данных.

    Совет

    Скопируйте в файл значение массива gossipCertificates, представленное на приведенном выше снимке экрана, и используйте следующий скрипт Bash (для которого потребуется скачать и установить jq для используемой платформы), чтобы отформатировать сертификаты и создать для каждого из них отдельный PEM-файл.

    readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
# iterate through the certs array, format each cert, write to a numbered file.
num=0
filename=""
for item in "${cert_array[@]}"; do
  let num=num+1
  filename="cert$num.pem"
  cert=$(jq '.pem' <<< $item)
  echo -e $cert >> $filename
  sed -e 's/^"//' -e 's/"$//' -i $filename
done

  7. Теперь создайте центр обработки данных в гибридном кластере. Обязательно замените значения переменных данными для реального кластера:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'
dataCenterLocation='eastus2'
virtualMachineSKU='Standard_D8s_v4'
noOfDisksPerNode=4

az managed-cassandra datacenter create \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --data-center-location $dataCenterLocation \
  --delegated-subnet-id $delegatedManagementSubnetId \
  --node-count 9
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false

    Примечание.

    Значение для --sku можно выбрать из следующих доступных номеров SKU:

    • Standard_E8s_v4
    • Standard_E16s_v4
    • Standard_E20s_v4
    • Standard_E32s_v4
    • Standard_DS13_v2
    • Standard_DS14_v2
    • Standard_D8s_v4
    • Standard_D16s_v4
    • Standard_D32s_v4

    Обратите внимание, что для --availability-zone установлено значение false. Чтобы включить зоны доступности, установите для этого параметра значение true. Зоны доступности расширяют действие соглашения об уровне обслуживания относительно доступности, применяемого к службе. Дополнительные сведения см. в полном описании соглашения об уровне обслуживания здесь.

    Предупреждение

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

  8. Итак, новый центр обработки данных создан. Теперь выполните команду show datacenter, чтобы просмотреть сведения о нем.

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'

az managed-cassandra datacenter show \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName

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

    Screenshot of how to get datacenter details.

  10. Теперь добавьте начальные узлы нового центра обработки данных в конфигурацию начальных узлов существующего центра обработки данных в файле cassandra.yaml. Затем установите собранные ранее сертификаты gossip для управляемого экземпляра в хранилище доверия для каждого узла в существующем кластере, используя команду keytool для каждого сертификата:

    keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass

    Примечание.

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

    Важно!

    Если существующий кластер Apache Cassandra имеет только один центр обработки данных, и это первый раз, когда добавляется центр обработки данных, убедитесь, что endpoint_snitch для cassandra.yaml параметра задано значение GossipingPropertyFileSnitch.

    Важно!

    Если существующий код приложения использует КВОРУМ для согласованности, необходимо убедиться, что перед изменением параметров реплика tion на шаге ниже существующий код приложения использует LOCAL_QUORUM для подключения к существующему кластеру (в противном случае динамические обновления завершаются ошибкой после изменения параметров реплика tion на следующем шаге). После изменения стратегии реплика tion можно отменить изменения к кворуму при желании.

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

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};

    Кроме того, необходимо обновить несколько системных таблиц:

    ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}

    Важно!

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

Использование гибридного кластера для миграции в режиме реального времени

Приведенные выше инструкции содержат рекомендации по настройке гибридного кластера. Однако это также отличный способ достижения простоя простоя миграции. Если у вас есть локальная или другая среда Cassandra, которую вы хотите вывести из эксплуатации с нулевым временем простоя, в пользу выполнения рабочей нагрузки в Azure Управляемый экземпляр для Apache Cassandra, в этом порядке необходимо выполнить следующие действия:

  1. Настройте гибридный кластер. Следуйте приведенным выше инструкциям.

  2. Временно отключите автоматическое восстановление в Azure Управляемый экземпляр для Apache Cassandra на время миграции:

    az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled false

  3. В Azure CLI выполните приведенную ниже команду, чтобы выполнить nodetool rebuild на каждом узле в новом центре обработки данных Azure Управляемый экземпляр для центра обработки данных Apache Cassandra, заменив <ip address> IP-адрес узла и <sourcedc> именем существующего центра обработки данных (который вы переносите из):

    az managed-cassandra cluster invoke-command \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --host <ip address> \
  --command-name nodetool --arguments rebuild="" "<sourcedc>"=""

    Это необходимо выполнить только после выполнения всех предыдущих шагов. Это должно гарантировать, что все исторические данные реплика в новые центры обработки данных в Azure Управляемый экземпляр для Apache Cassandra. Одновременно можно выполнить перестроение на одном или нескольких узлах. Запустите на одном узле одновременно, чтобы уменьшить влияние на существующий кластер. Запустите на нескольких узлах, когда кластер может обрабатывать дополнительные нагрузки на операции ввода-вывода и сети. Для большинства установок можно запускать только одну или две параллельно, чтобы не перегружать кластер.

    Предупреждение

    При запуске nodetool rebuildнеобходимо указать исходный центр обработки данных. Если центр обработки данных указан неправильно при первой попытке, это приведет к копированию диапазонов маркеров без копирования данных для таблиц, отличных от системы. Последующие попытки завершаются ошибкой, даже если вы правильно предоставляете центр обработки данных. Это можно устранить, удалив записи для каждого пространства ключей, отличного от системы, с system.available_ranges помощью средства запроса в целевом cqlsh центре обработки данных Cassandra MI:

    delete from system.available_ranges where keyspace_name = 'myKeyspace';

  4. Вырезайте код приложения, чтобы указать начальные узлы в новом Управляемый экземпляр Azure для центров обработки данных Apache Cassandra.

    Важно!

    Как и упоминание в инструкциях гибридной настройки, если центры обработки данных в существующем кластере не применяют шифрование между узлами (SSL), необходимо включить это в коде приложения, так как Cassandra Управляемый экземпляр это принудительно.

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

  6. Запуск вывода из эксплуатации nodetool для каждого старого узла центра обработки данных.

  7. Переключите код приложения обратно в кворум (если требуется или предпочтителен).

  8. Повторно включите автоматическое восстановление:

    az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled true

Устранение неполадок

Если при применении разрешений к виртуальной сети с помощью Azure CLI возникла ошибка, например, информирующая о том, что не удается найти пользователя или субъект-службу в базе данных графа (Cannot find user or service principal in graph database for 'e5007d2c-4b13-4a74-9b6a-605d99f03501'), это же разрешение можно применить вручную на портале Azure. Узнайте, как это сделать, здесь.

Примечание.

Назначение роли Azure Cosmos DB используется только в целях развертывания. В Управляемом экземпляре Azure для Apache Cassandra нет внутренних зависимостей от Azure Cosmos DB.

Очистка ресурсов

Если вы не планируете в дальнейшем использовать кластер с управляемым экземпляром, удалите его, выполнив следующие действия:

  1. В меню слева на портале Azure выберите Группы ресурсов.
  2. Выберите из списка группу ресурсов, созданную для этого краткого руководства.
  3. В области Обзор на странице группы ресурсов выберите Удалить группу ресурсов.
  4. В следующем окне введите имя группы ресурсов, которую требуется удалить, и щелкните Удалить.

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

Из этого краткого руководства вы узнали, как создать гибридный кластер с использованием Azure CLI и службы "Управляемый экземпляр Azure для Apache Cassandra". Теперь можно приступить к работе с кластером.

Управление ресурсами службы "Управляемый экземпляр Azure для ресурсов Apache Cassandra" с помощью Azure CLI