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


Краткое руководство: создание управляемого экземпляра Azure для кластера Apache Cassandra на портале Microsoft Azure

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

В этом кратком руководстве описывается, как создать управляемый экземпляр Azure для кластера Apache Cassandra на портале Microsoft Azure.

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

Если у вас нет подписки Azure, создайте бесплатную учетную запись, прежде чем приступить к работе.

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

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

  2. В строке поиска введите Управляемый экземпляр для Apache Cassandra и выберите результат.

    Снимок экрана поиска по экземпляру Azure SQL с управлением для Apache Cassandra.

  3. Нажмите кнопку Создать управляемый экземпляр для кластера Apache Cassandra.

    Создание кластера.

  4. В области Создать управляемый экземпляр базы данных SQL Azure для Apache Cassandra укажите следующие сведения:

    • Для параметра Подписка выберите подписку Azure в раскрывающемся списке.
    • Для параметра Группа ресурсов укажите, нужно ли создать новую группу ресурсов или использовать существующую. Группа ресурсов — это контейнер, содержащий связанные ресурсы для решения Azure. Дополнительные сведения см. в обзорной статье Группа ресурсов Azure.
    • Имя кластера: введите имя кластера.
    • Расположение: расположение, в котором будет развернут кластер.
    • Версия Cassandra — версия Apache Cassandra, которая будет развернута.
    • Расширение — расширения, которые будут добавлены, включая Cassandra Lucene Index.
    • Начальный пароль администратора Cassandra: пароль, используемый для создания кластера.
    • Подтвердите пароль администратора Cassandra: введите пароль повторно.
    • Виртуальная сеть — выберите имеющуюся виртуальную сеть и подсеть или создайте их.
    • Назначение ролей — виртуальным сетям требуются специальные разрешения для развертывания управляемых кластеров Cassandra. Установите этот флажок, если вы создаете новую виртуальную сеть или используете существующую виртуальную сеть без применения разрешений. При использовании виртуальной сети, где уже развернуты кластеры Cassandra для Управляемого экземпляра SQL Azure, снимите этот флажок.

    Заполнение формы для создания кластера.

    Совет

    Если вы используете VPN , то вам не нужно открывать другое подключение.

    Примечание.

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

    • Хранилище Azure
    • Azure Key Vault
    • Масштабируемые наборы виртуальных машин Azure
    • Мониторинг Azure
    • Microsoft Entra ID
    • Безопасность в Azure
    • Автоматическая репликация — выберите форму автоматической репликации, используемую. Подробнее
    • Стратегия планирования событий — метод, который будет использоваться кластером для запланированных мероприятий.

    Совет

    • StopANY означает остановку любого узла при наличии запланированного события для этого узла.
    • StopByRack означает только остановку узла в заданной стойке для заданного запланированного события, например, если два или более событий запланированы для узлов в разных стойких одновременно, будут остановлены только узлы в одной стойке, а другие узлы в других стойких задерживаются.
  5. Выберите вкладку Центр обработки данных.

  6. Введите следующие сведения:

    • Имя центра обработки данных — введите имя центра обработки данных в текстовое поле.
    • Зона доступности — установите этот флажок, если необходимо включить зоны доступности.
    • Размер SKU — выберите доступные размеры SKU виртуальных машин.

    Снимок экрана: выбор размера SKU.

    Примечание.

    Мы внедрили кэширование с записью (публичная предварительная версия) через использование SKU виртуальных машин серии L. Эта реализация направлена на минимизацию конечных задержек и улучшение производительности при чтении, особенно для нагрузок, интенсивно использующих чтение. Эти конкретные артикулы SKU оснащены локально подключенными дисками, обеспечивая значительное увеличение операций ввода-вывода в секунду для операций чтения и снижение конечной задержки.

    Внимание

    Кэширование с помощью записи доступно в общедоступной предварительной версии. Эта функция предоставляется без соглашения об уровне обслуживания и не рекомендуется для использования в рабочей среде. Дополнительные сведения см. в статье Дополнительные условия использования Предварительных версий Microsoft Azure.

    • № дисков — выберите количество дисков p30, которые необходимо подключить к каждому узлу Cassandra.
    • № узлов — выберите количество узлов Cassandra, которые будут развернуты в этом центре обработки данных.

    Просмотр сводки для создания дата-центра.

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

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

  7. Затем нажмите кнопку "Рецензирование" и "Создать">

    Примечание.

    Создание кластера может занять до 15 минут.

    Просмотрите сводку для создания кластера.

  8. После завершения развертывания проверьте группу ресурсов. В ней должен отображаться созданный кластер с управляемым экземпляром:

    Обзорная страница после создания кластера.

  9. Для просмотра узлов кластера перейдите к кластерному ресурсу и откройте область Центр обработки данных.

    Снимок экрана: узлы центра обработки данных.

Масштабирование центра обработки данных

Теперь, когда вы развернули кластер с одним центром обработки данных, можно масштабировать по горизонтали или по вертикали, выделите центр обработки данных и нажмите Scale кнопку:

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

Горизонтальное масштабирование

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

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

Вертикальное масштабирование

Чтобы увеличить или уменьшить размер SKU для ваших узлов, выберите из раскрывающегося списка Sku Size. По завершении нажмите Scale.

Снимок экрана: выбор размера SKU.

Примечание.

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

Добавление центра обработки данных

  1. Чтобы добавить еще один центр обработки данных, нажмите кнопку "Добавить" в панели Центра обработки данных:

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

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

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

        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>
    
  2. Заполните соответствующие поля:

    • Имя центра обработки данных — выберите свою подписку Azure из раскрывающегося списка.
    • Зона доступности. Установите этот флажок, если необходимо включить зоны доступности в этом центре обработки данных.
    • Расположение — расположение, в котором будет развернут центр обработки данных.
    • Размер SKU — выберите доступный размер SKU для виртуальной машины.
    • Нет дисков — выберите количество дисков p30, которые необходимо подключить к каждому узлу Cassandra.
    • № узлов — выберите количество узлов Cassandra, которые будут развернуты в этом центре обработки данных.
    • Виртуальная сеть — выберите существующую виртуальную сеть и подсеть.

    Добавьте центр обработки данных.

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

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

  3. После развертывания центра обработки данных вы сможете просмотреть всю информацию о центре обработки данных в панели Центра обработки данных.

    Просмотр ресурсов кластера.

  4. Чтобы обеспечить репликацию между центрами обработки данных, подключитесь к cqlsh и используйте следующий запрос CQL, чтобы обновить стратегию репликации в каждом пространстве ключей, чтобы включить все центры обработки данных в кластере (системные таблицы будут обновляться автоматически):

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
    
  5. Если вы добавляете центр обработки данных в кластер, где уже есть данные, необходимо выполнить репликацию rebuild исторических данных. В Azure CLI выполните следующую команду, чтобы выполнить nodetool rebuild на каждом узле нового центра обработки данных, заменив <new dc ip address> IP-адрес узла и <olddc> именем существующего центра обработки данных:

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

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

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

Обновление конфигурации Cassandra

Служба позволяет обновлять конфигурацию YAML Cassandra в центре обработки данных через портал или с помощью команд CLI. Чтобы обновить параметры на портале, выполните следующие действия.

  1. Найдите Cassandra Configuration в разделе параметров. Выделите центр обработки данных, конфигурация которого требуется изменить, и нажмите кнопку "Обновить":

    Снимок экрана: выбор центра обработки данных для обновления конфигурации.

  2. В открывавшемся окне введите имена полей в формате YAML, как показано ниже. Затем нажмите кнопку "Обновить".

    Снимок экрана: обновление конфигурации Центра обработки данных Cassandra.

  3. После завершения обновления переопределенные значения будут отображаться в Cassandra Configuration области:

    Снимок экрана: обновленная конфигурация Cassandra.

    Примечание.

    На портале отображаются только переопределенные значения конфигурации Cassandra.

    Внимание

    Убедитесь, что предоставленные настройки Yaml для Cassandra соответствуют версии Cassandra, которую вы установили. См. здесь настройки Cassandra версии 3.11 и здесь для версии 4.0. Обновление следующих параметров YAML запрещено:

    • cluster_name
    • seed_provider
    • initial_token
    • autobootstrap
    • client_encryption_options
    • параметры шифрования сервера
    • transparent_data_encryption_options
    • audit_logging_options
    • аутентификатор
    • авторизатор
    • role_manager
    • storage_port
    • ssl_storage_port
    • native_transport_port
    • порт нативного транспорта SSL
    • адрес для прослушивания
    • listen_interface
    • broadcast_address
    • hints_directory
    • каталоги_файлов_данных
    • commitlog_directory
    • cdc_raw_directory
    • директория_сохраненных_кэшей
    • endpoint_snitch
    • Партиционер
    • адрес RPC
    • интерфейс RPC

Обновление версии Cassandra

Внимание

Обновления версий Cassandra 5.0 и Turnkey доступны в общедоступной предварительной версии. Эти функции предоставляются без соглашения об уровне обслуживания и не рекомендуется для использования в производственной среде. Дополнительные сведения см. в статье Дополнительные условия использования Предварительных версий Microsoft Azure.

Вы можете выполнять обновления основной версии на месте непосредственно с портала или с помощью Az CLI, Terraform или шаблонов ARM.

  1. Update Найдите панель на вкладке "Обзор"

    Снимок экрана: обновление версии Cassandra.

  2. Выберите версию Cassandra из раскрывающегося списка.

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

    Не пропускайте версии. Рекомендуется обновить только одну версию до другой версии 3.11 до версии 4.0, 4.0 до версии 4.1.

    Снимок экрана: выбор версии Cassandra.

  3. Нажмите кнопку "Обновить", чтобы сохранить.

Репликация под ключ

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

Выберите ссылку из раскрывающегося списка.

Совет

  • Нет. Для автоматической репликации задано значение none.
  • SystemKeyspaces: автоматическая репликация всех системных пространств ключей (system_auth, system_traces, system_auth)
  • AllKeyspaces: автоматическая репликация всех пространств ключей и мониторинг при создании новых пространств ключей, а затем автоматическое применение параметров автоматической репликации.

Сценарии автоматической репликации

  • При добавлении нового центра обработки данных функция автоматической репликации в Cassandra беспрепятственно выполнит nodetool rebuild, обеспечивая успешную репликацию данных в новом центре обработки данных.
  • Удаление центра обработки данных приводит к автоматическому удалению определенного центра обработки данных из пространств хранения ключей.

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

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

Установка автоматической репликации в значение AllKeyspaces изменит репликацию пространства ключей, включая WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 }Если это не та топология, которая вам нужна, вам потребуется использовать SystemKeyspaces, настроить их самостоятельно и запустить nodetool rebuild вручную в управляемом экземпляре Azure для Apache Cassandra.

Деаллокация кластера

  1. Для непроизводственных сред можно приостановить или отключить выделение ресурсов в кластере, чтобы избежать их оплаты (плата будет взиматься за хранение). Сначала измените тип NonProductionкластера на , а затем deallocate.

Совет

Тип кластера следует использовать как "NonProduction" только чтобы сэкономить на разработке. Они могут поставляться с меньшими SKU и не должны использоваться для выполнения рабочих нагрузок в производственной среде.

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

  • Тип кластера, определенный как "Непроизводственный", не будет иметь гарантии по соглашению об уровне обслуживания, применяться к нему.
  • Не выполняйте никаких операций со схемой или записью во время освобождения ресурсов. Это может привести к потере данных и в редких случаях к повреждению схемы, требующего ручного вмешательства со стороны команды поддержки.

Снимок экрана: приостановка кластера.

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

Если при применении разрешений к виртуальной сети с помощью 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.

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

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

Подключение через CQLSH

После развертывания виртуальной машины используйте SSH для подключения к компьютеру и установите CQLSH с помощью приведенных ниже команд:

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

# Install the Cassandra libraries in order to get CQLSH:
echo "deb http://archive.apache.org/dist/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
sudo apt-get update
sudo apt-get install cassandra

# Export the SSL variables:
export SSL_VERSION=TLSv1_2
export SSL_VALIDATE=false

# Connect to CQLSH (replace <IP> with the private IP addresses of a node in your Datacenter):
host=("<IP>")
initial_admin_password="Password provided when creating the cluster"
cqlsh $host 9042 -u cassandra -p $initial_admin_password --ssl

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

Как и в CQLSH, подключение из приложения с использованием одного из поддерживаемых клиентских драйверов Apache Cassandra требует включения ssl-шифрования и отключения проверки сертификации. Примеры подключения к управляемому экземпляру Azure для Apache Cassandra с помощью Java, .NET, Node.js и Python.

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

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

Примечание.

В подавляющем большинстве случаев не нужно настраивать или устанавливать сертификаты (rootCA, узел или клиент, truststores и т. д.) для подключения к Azure Managed Instance для Apache Cassandra. Шифрование SSL можно включить, используя хранилище доверия по умолчанию и пароль среды выполнения, которая используется клиентом (см. примеры Java, .NET, Node.js и Python), так как службы Azure Managed Instance для сертификатов Apache Cassandra будут доверять этой среде. В редких случаях, если сертификат не является доверенным, может потребоваться добавить его в хранилище доверия.

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

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

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

Если вы хотите реализовать проверку подлинности сертификата между клиентами или взаимную проверку подлинности на уровне транспорта (mTLS), необходимо предоставить сертификаты через Azure CLI. Следующая команда отправит и применит сертификаты клиента к хранилищу доверия для кластера 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

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

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

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

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

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