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

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

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

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

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

  • Для этой статьи требуется Azure CLI версии 2.30.0 или более поздней. Если вы используете Azure Cloud Shell, последняя версия уже установлена.
  • Используйте виртуальную сеть Azure с подключением к вашей локальной или оборудованной среде. Дополнительные сведения о подключении локальных сред к Azure см. в статье "Подключение локальной сети к Azure".

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

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

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

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

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

    • Хранилище Azure
    • Azure Key Vault
    • Масштабируемые наборы виртуальных машин Azure
    • Azure Monitor
    • Microsoft Entra ID
    • Microsoft Defender для облака

  3. Примените некоторые специальные разрешения к виртуальной сети и подсети, для которой требуется Управляемый экземпляр Azure для Apache Cassandra, с помощью Azure CLI. Используйте команду 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 переменных в следующем скрипте.

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

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

    При необходимости, если вы хотите реализовать проверку подлинности сертификата типа "клиент — узел" или взаимную безопасность транспортного уровня (TLS), укажите сертификаты в том же формате, что и при создании гибридного кластера. См. пример Azure CLI далее в этой статье. Сертификаты предоставляются в параметре --client-certificates .

    Этот подход отправляет и применяет сертификаты клиента к хранилищу доверия для кластера Apache Cassandra для Управляемого экземпляра Azure. Вам не нужно изменять 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 isn't 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

    Если в кластере уже есть шифрование типа "узел—узел" и "клиент—узел", необходимо знать, где хранятся существующие TLS/SSL-сертификаты клиента или для обмена информацией между узлами. Если вы не уверены, запустите команду 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. Приведенная выше команда возвращает сведения о среде для управляемого экземпляра. Вам нужны сертификаты для распределенных систем, чтобы их можно было установить в доверенное хранилище для узлов в существующем центре обработки данных. На следующем снимках экрана показаны выходные данные предыдущей команды и формат сертификатов.

    Снимок экрана: результат получения сведений о сертификате из кластера.

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

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

    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 для следующих доступных уровней продуктов:

    • 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. Зоны доступности повышают уровень доступности в рамках соглашения об уровне обслуживания (SLA) службы. Дополнительные сведения см. в разделе об уровне обслуживания для веб-служб.

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

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

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

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

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

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

    Снимок экрана: получение сведений о центре обработки данных.

  9. Добавьте начальные узлы нового центра обработки данных в конфигурацию начального узла существующего центра обработки данных в файле 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.

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

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

    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) и планируете напрямую подключиться к Управляемому экземпляру Azure для Apache Cassandra, необходимо также включить TLS/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. Одновременно можно запускать rebuild на одном или нескольких узлах. Запустите на одном узле одновременно, чтобы уменьшить влияние на существующий кластер. Запустите на нескольких узлах, когда кластер может обрабатывать дополнительные нагрузки на операции ввода-вывода и сети. Для большинства установок можно запускать только один или два параллельно, чтобы не перегружать кластер.

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

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

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

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

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

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

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

  7. При необходимости или если предпочтительно, переключите код приложения обратно на QUORUM.

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

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

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

При возникновении ошибки при применении разрешений к виртуальной сети с помощью Azure CLI можно применить то же разрешение вручную на портале Azure. Пример такой ошибки: "Не удается найти пользователя или служебного принципала в графовой базе данных e5007d2c-4b13-4a74-9b6a-605d99f03501." Дополнительные сведения см. на портале Azure, чтобы добавить служебный принципал Azure Cosmos DB.

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

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

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

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

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

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

  • Last updated on