Быстрый старт: Создать экземпляр Azure Управляемый экземпляр для кластера Apache Cassandra, используя Azure CLI

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

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

Предварительные требования

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

Внимание

Для этой статьи требуется 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 Virtual Machine Scale Sets (Масштабируемые наборы виртуальных машин 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
    • Диски данных: четыре диска P30 подключены к каждой развернутой виртуальной машине. При изменении размера хранилища запланируйте максимальное устойчивое использование 50%, чтобы обеспечить достаточное место для сборок и использования дисков системными службами. Кроме того, резервные копии временно занимают локальное дисковое пространство перед сохранением в объектное хранилище Blob.

    После выполнения всех сведений используйте команду 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 рекомендуется включить политику выполнения спекулятивное выполнение, где приложения чувствительны к конечной задержке. Для иллюстрации того, как работает этот подход, и чтобы узнать, как включить данную политику, обратитесь к статье Implement speculative execution policy.

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

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

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

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

Чтобы реализовать проверку подлинности сертификата клиента к узлу или взаимную безопасность транспортного уровня, предоставьте сертификаты с помощью Azure CLI. Следующая команда загружает и применяет клиентские сертификаты к хранилищу сертификатов доверия для кластера Apache Cassandra в Azure Управляемый экземпляр. Вам не нужно изменять 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