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

Краткое руководство. Создание управляемого экземпляра Azure для кластера Apache Cassandra с помощью Azure CLI

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

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

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

Внимание

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

Создание кластера с управляемым экземпляром

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

  2. Задайте идентификатор подписки в Azure CLI:

    az account set --subscription <Subscription_ID>

  3. Создайте виртуальную сеть с выделенной подсетью в группе ресурсов:

    az network vnet create --name <VNet_Name> --location eastus2 \
  --resource-group <Resource_Group_Name> --subnet-name <Subnet Name>

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

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

  4. Примените эти определенные разрешения к виртуальной сети. Управляемому экземпляру они необходимы. Используйте команду 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 являются фиксированными. Введите эти значения точно так же, как упоминалось в команде. Если это не сделать, возникают ошибки при создании кластера. Если при выполнении этой команды возникают какие-либо ошибки, возможно, у вас нет разрешений на его запуск. Обратитесь к администратору Azure за разрешениями.

  5. Создайте кластер в созданной виртуальной сети с помощью команды az managed-cassandra cluster create . Выполните следующую команду со значением переменной delegatedManagementSubnetId . (Значение delegatedManagementSubnetId является тем же самым именем виртуальной сети, для которого были применены разрешения.)

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster_Name>'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualNetworks/<VNet name>/subnets/<subnet name>'
initialCassandraAdminPassword='myPassword'
cassandraVersion='5.0' # set to 4.0 for a Cassandra 4.0 cluster

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --initial-cassandra-admin-password $initialCassandraAdminPassword \
  --cassandra-version $cassandraVersion \
  --debug

  6. Создайте датацентр для кластера с тремя виртуальными машинами. Используйте следующую конфигурацию:

    • Размер виртуальной машины: стандартный E8s версии 5
    • Диски данных: 4 диска P30, подключенные к каждой развернутой виртуальной машине

    После выполнения всех сведений используйте команду az managed-cassandra datacenter create :

    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 3 \
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false

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

    • Standard_E8s_v5
    • Standard_E16s_v5
    • Standard_E20s_v5
    • Standard_E32s_v5

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

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

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

  7. После создания центра обработки данных можно запустить команду az managed-cassandra datacenter update , чтобы уменьшить или увеличить масштаб кластера. Измените значение параметра на нужное значение node-count :

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'
dataCenterName='dc1'
dataCenterLocation='eastus2'

az managed-cassandra datacenter update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --node-count 9

Подключение к кластеру

Управляемый экземпляр Azure для Apache Cassandra не создает узлы с общедоступными IP-адресами. Чтобы подключиться к новому кластеру Cassandra, необходимо создать другой ресурс в одной виртуальной сети. Этот ресурс может быть приложением или виртуальной машиной с установленной оболочкой языка запросов Cassandra (CQLSH). CQLSH — это средство запросов с открытым кодом Apache.

Для развертывания виртуальной машины Ubuntu можно использовать шаблон Azure Resource Manager .

Из-за некоторых известных проблем с версиями Python рекомендуется использовать образ Ubuntu 22.04, который поставляется с Python3.10.12 или виртуальной средой Python для запуска CQLSH.

Подключитесь из CQLSH

После развертывания виртуальной машины используйте Secure Shell для подключения к компьютеру и установки CQLSH. Используйте следующие команды:

# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre

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

Установите библиотеки Cassandra, чтобы получить CQLSH. Выполните официальные шаги из документации Cassandra.

Подключение из приложения

Как и в CQLSH, при использовании одного из поддерживаемых клиентских драйверов Apache Cassandra для подключения из приложения необходимо включить шифрование протокола TLS/SSL, а проверка сертификата должна быть отключена. Примеры см. в разделе Java, .NET, Node.jsи Python.

Рекомендуется отключить проверку сертификата, так как она не работает, если вы не сопоставляете IP-адреса узлов кластера с соответствующим доменом. Если внутренняя политика требует проверки TLS/SSL-сертификата для любого приложения, добавьте записи, как 10.0.1.5 host1.managedcassandra.cosmos.azure.com в файле узлов для каждого узла, чтобы упростить эту настройку. При таком подходе также необходимо добавить новые записи при каждом масштабировании узлов.

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

Обычно не требуется настраивать сертификаты (напримерrootCA, , nodeclientилиtruststore) для подключения к Управляемому экземпляру Azure для Apache Cassandra. Шифрование TLS/SSL использует хранилище доверия по умолчанию и выбранный клиентом пароль среды выполнения. Пример кода см. в разделе Java, .NET, Node.jsи Python). Сертификаты по умолчанию являются доверенными. Если нет, добавьте их в хранилище доверенных сертификатов.

Настройка сертификатов клиента (необязательно)

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

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

Чтобы реализовать проверку подлинности сертификата клиента к узлу или взаимную безопасность транспортного уровня, предоставьте сертификаты с помощью Azure CLI. Следующая команда загружает и применяет клиентские сертификаты в хранилище сертификатов для управляемого экземпляра Azure в кластере Apache Cassandra. Вам не нужно изменять cassandra.yaml параметры. После применения сертификатов кластеру требуется Cassandra для проверки сертификатов во время клиентских подключений. См. дополнительные сведения в require_client_auth: true в client_encryption_options Cassandra.

resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --client-certificates /usr/csuser/clouddrive/rootCert.pem /usr/csuser/clouddrive/intermediateCert.pem

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

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

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

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

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

az group delete --name <Resource_Group_Name>

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

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

Развертывание управляемого кластера Apache Spark с помощью Azure Databricks

  • Last updated on