Inicio rápido: Creación de un clúster de Azure Managed Instance for Apache Cassandra desde Azure Portal

Artículo
08/15/2024

Azure Managed Instance for Apache Cassandra es un servicio totalmente administrado para clústeres de Apache Cassandra de código abierto puros. El servicio también permite invalidar las configuraciones, en función de las necesidades específicas de cada carga de trabajo, lo que permite la máxima flexibilidad y control cuando sea necesario

En este inicio rápido se muestra cómo usar Azure Portal para crear un clúster de Azure Managed Instance for Apache Cassandra.

Requisitos previos

Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Creación de un clúster de instancia administrada

Inicie sesión en Azure Portal.
En la barra de búsqueda, escriba Managed Instance for Apache Cassandra y seleccione el resultado.
Seleccione el botón Create Managed Instance for Apache Cassandra cluster (Crear clúster de Managed Instance for Apache Cassandra).
En el panel Create Managed Instance for Apache Cassandra cluster (Crear clúster de Managed Instance for Apache Cassandra), escriba los siguientes detalles:
- Suscripción: en la lista desplegable, seleccione su suscripción de Azure.
- Grupo de recursos: especifique si quiere crear un grupo de recursos o utilizar uno ya existente. Un grupo de recursos es un contenedor que almacena los recursos relacionados con una solución de Azure. Para más información, consulte el artículo de introducción Grupo de recursos de Azure.
- Nombre del clúster: escriba un nombre para el clúster.
- Ubicación: lugar donde se implementará el clúster.
- Versión de Cassandra: versión de Apache Cassandra que se implementará.
- Extensión: Extensiones que se agregarán, incluido el índice de Cassandra Lucene.
- Initial Cassandra admin password (Contraseña inicial de administrador de Cassandra): la contraseña que se usa para crear el clúster.
- Confirm Cassandra admin password (Confirmar contraseña de administrador de Cassandra): vuelva a escribir la contraseña.
- Virtual Network (Red virtual): seleccione una red virtual y una subred existentes o cree una nueva.
- Assign roles (Asignar roles): las redes virtuales requieren permisos especiales para permitir la implementación de clústeres de Cassandra administrados. Mantenga activada esta casilla si va a crear una nueva red virtual o si usa una red virtual existente sin permisos aplicados. Si usa una red virtual en la que ya ha implementado clústeres de Cassandra en Azure SQL Managed Instance, desactive esta opción.
Sugerencia

Si usa VPN, no es necesario abrir ninguna otra conexión.
Nota:

La implementación de Azure Managed Instance for Apache Cassandra requiere acceso a Internet. En entornos con acceso limitado a Internet se produce un error de implementación. Asegúrese de no bloquear el acceso desde la red virtual a los siguientes servicios de Azure que son esenciales para que las instancias administradas de Cassandra funcionen correctamente. Consulte Reglas de red de salida necesarias para obtener información más detallada.
- Azure Storage
- Azure KeyVault
- Conjuntos de escalado de máquinas virtuales de Azure
- Supervisión de Azure
- Microsoft Entra ID
- Azure Security
- Replicación automática: elija la forma de replicación automática que se va a usar. Más información
- Programar estrategia de eventos: la estrategia que usará el clúster para eventos programados.
Sugerencia
- StopANY significa detener cualquier nodo cuando hay una programación incluso para el nodo.
- StopByRack significa que solo se detiene el nodo en un bastidor determinado para un evento programado concreto; por ejemplo, si dos o más eventos están programados para nodos en bastidores diferentes al mismo tiempo, solo se detendrán los nodos de un bastidor, mientras que los demás nodos de otros bastidores se retrasan.
A continuación, seleccione la pestaña Data center (Centro de datos).
Escriba la siguiente información:
- Nombre del centro de datos: escriba un nombre de centro de datos en el campo de texto.
- Availability zone (Zona de disponibilidad): active esta casilla si desea habilitar las zonas de disponibilidad.
- SKU Size (Tamaño de SKU): elija entre los tamaños de SKU de máquina virtual disponibles.
Nota:

Hemos introducido el almacenamiento en caché de escritura continua (versión preliminar pública) mediante el uso de SKU de máquina virtual de la serie L. Esta implementación tiene como objetivo minimizar las latencias finales y mejorar el rendimiento de lectura, especialmente para cargas de trabajo de lectura intensiva. Estas SKU específicas están equipadas con discos conectados localmente, lo que garantiza un aumento considerable de IOPS para las operaciones de lectura y una latencia de cola reducida.

Importante

El almacenamiento en caché de escritura continua está en versión preliminar pública. Esta característica se ofrece sin contrato de nivel de servicio y no se recomienda para cargas de trabajo de producción. Para más información, consulte Términos de uso complementarios de las Versiones Preliminares de Microsoft Azure.
- No. de discos - Elija el número de discos p30 que se adjuntarán a cada nodo de Cassandra.
- No. de nodos - Elija el número de nodos de Cassandra que se implementarán en este centro de datos.
Advertencia

Las zonas de disponibilidad no se admiten en todas las regiones. Se producirá un error en las implementaciones si selecciona una región en la que no se admiten las zonas de disponibilidad. Consulte aquí las regiones admitidas. La implementación correcta de las zonas de disponibilidad también depende de la disponibilidad de los recursos de proceso en todas las zonas de la región dada. Podría producirse un error en las implementaciones si la SKU que ha seleccionado o la capacidad no están disponibles en todas las zonas.
Después, seleccione Revisar y crear>Crear

Nota:

El clúster puede tardar hasta 15 minutos en crearse.
Una vez finalizada la implementación, compruebe el grupo de recursos para ver el clúster de instancia administrada recién creado:
Para examinar los nodos del clúster, vaya al recurso de clúster y abra el panel Centro de datos para verlos:

Escalado de un centro de datos

Ahora que ya ha implementado un clúster con un centro de datos único, puede escalar horizontalmente o verticalmente. Para ello, resalte el centro de datos y seleccione el botón Scale:

Escalado horizontal

Para escalar o reducir horizontalmente los nodos, mueva el control deslizante hasta el valor deseado o simplemente edítelo. Cuando termine, seleccione Scale.

Escalado vertical

Para escalar o reducir verticalmente el tamaño de la SKU de los nodos, seleccione Sku Size en la lista desplegable. Cuando termine, seleccione Scale.

Nota

La duración del proceso de escalado dependerá de varios factores, puede tardar varios minutos. Cuando Azure le notifique que se ha completado la operación de escalado, esto no significará que todos los nodos se hayan unido al anillo de Cassandra. Los nodos se asignarán por completo cuando todos ellos muestren un estado "correcto" y el estado que muestre el centro de datos sea "correcto". El escalado es una operación en línea y funciona de la misma manera que se describe para aplicar revisiones en operaciones de administración

Incorporación de un centro de datos

Para agregar otro centro de datos, haga clic en el botón Agregar en el panel Centro de datos:
Advertencia

Si va a agregar un centro de datos en otra región, deberá seleccionar una red virtual diferente. También deberá asegurarse de que esta red virtual tenga conectividad con la red virtual de la región primaria creada anteriormente (y cualquier otra red virtual que hospede centros de datos dentro del clúster de instancia administrada). Eche un vistazo a este artículo para aprender a emparejar redes virtuales mediante Azure Portal. También debe asegurarse de que ha aplicado el rol adecuado a la red virtual antes de intentar implementar un clúster de instancia administrada mediante el siguiente comando de la 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>
```
Rellene los campos correspondientes:
- Datacenter name (Nombre de centro de datos): en la lista desplegable, seleccione su suscripción de Azure.
- Zona de disponibilidad: active esta casilla si desea habilitar las zonas de disponibilidad en este centro de datos.
- Ubicación: lugar donde se implementará el centro de datos.
- SKU Size (Tamaño de SKU): elija entre los tamaños de SKU de máquina virtual disponibles.
- No. de discos - Elija el número de discos p30 que se adjuntarán a cada nodo de Cassandra.
- No. de nodos - Elija el número de nodos de Cassandra que se implementarán en este centro de datos.
- Red virtual: seleccione una red virtual y una subred existentes.
Advertencia

Tenga en cuenta que no se permite la creación de una red virtual al agregar un centro de datos. Debe elegir una red virtual existente y, como se mencionó anteriormente, debe asegurarse de que hay conectividad entre las subredes de destino donde se implementarán los centros de datos. También debe aplicar el rol adecuado a la red virtual para permitir la implementación (consulte lo anterior).
Al implementar el centro de datos, debería poder ver toda la información de este en el panel Centro de datos:
Para garantizar la replicación entre centros de datos, conéctese a cqlsh y use la siguiente consulta de CQL para actualizar la estrategia de replicación de cada espacio de claves con el fin de incluir todos los centros de datos del clúster (las tablas del sistema se actualizarán automáticamente):
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
```
Si va a agregar un centro de datos a un clúster donde ya hay datos, debe ejecutar rebuild para replicar los datos históricos. En la CLI de Azure, ejecute el siguiente comando para ejecutar nodetool rebuild en cada nodo del nuevo centro de datos, reemplazando <new dc ip address> por la dirección IP del nodo y <olddc> por el nombre del centro de datos existente:
```
 az managed-cassandra cluster invoke-command \
   --resource-group $resourceGroupName \
   --cluster-name $clusterName \
   --host <new dc ip address> \
   --command-name nodetool --arguments rebuild="" "<olddc>"=""
```
Advertencia

No debería permitir que los clientes de la aplicación escriban en el nuevo centro de datos hasta que haya aplicado los cambios de replicación del espacio de claves. De lo contrario, la recompilación no funcionará y deberá crear una solicitud de soporte técnico para que nuestro equipo pueda ejecutar repair en su nombre.

Actualización de la configuración de Cassandra

El servicio permite actualizar a la configuración de YAML de Cassandra en un centro de datos a través del portal o mediante comandos de la CLI. Para actualizar la configuración en el portal:

Busque Cassandra Configuration en Configuración. Resalte el centro de datos cuya configuración desea cambiar y haga clic en Actualizar:
En la ventana que se abre, escriba los nombres de campo en formato YAML, como se muestra a continuación. Después, haga clic en Actualizar.
Una vez completada la actualización, los valores invalidados se mostrarán en el panel Cassandra Configuration:

Nota

En el portal solo se muestran los valores de configuración de Cassandra invalidados.
Importante

Asegúrese de que la configuración de YAML de Cassandra que proporcione sea adecuada para la versión de Cassandra que ha implementado. Consulte aquí la configuración de Cassandra v3.11 y aquí para la v4.0. No se permite actualizar la siguiente configuración de YAML:
- cluster_name
- seed_provider
- initial_token
- autobootstrap
- client_encryption_options
- server_encryption_options
- transparent_data_encryption_options
- audit_logging_options
- autenticador
- authorizer
- role_manager
- storage_port
- ssl_storage_port
- native_transport_port
- native_transport_port_ssl
- listen_address
- listen_interface
- broadcast_address
- hints_directory
- data_file_directories
- commitlog_directory
- cdc_raw_directory
- saved_caches_directory
- endpoint_snitch
- partitioner
- rpc_address
- rpc_interface

Actualización de la versión de Cassandra

Importante

Las actualizaciones de versiones de Cassandra 5.0 y Turnkey están en versión preliminar pública. Estas características se ofrecen sin Acuerdo de Nivel de Servicio y no es aconsejable usarlas en cargas de trabajo de producción. Para más información, consulte Términos de uso complementarios de las Versiones Preliminares de Microsoft Azure.

Tiene la opción de realizar actualizaciones de versiones principales en contexto directamente desde el portal, o bien mediante la CLI de Az, Terraform o plantillas de ARM.

Busque el panel Update en la pestaña Información general
Seleccione la versión de Cassandra en la lista desplegable.

Advertencia

No omita ninguna versión. Se recomienda actualizar solo de una versión a otra; por ejemplo de 3.11 a 4.0, de 4.0 a 4.1.
Seleccione una actualización para guardarla.

Replicación inmediata

En Cassandra 5.0 se presenta un enfoque simplificado para implementar clústeres de varias regiones, lo que ofrece mayor comodidad y eficacia. El uso de la funcionalidad de replicación inmediata, la configuración y administración de clústeres de varias regiones se ha vuelto más accesible, lo que permite una integración y una operación más fluidas en entornos distribuidos. Esta actualización reduce significativamente las complejidades asociadas tradicionalmente con la implementación y el mantenimiento de configuraciones de varias regiones, lo que permite a los usuarios utilizar las funcionalidades de Cassandra con mayor facilidad y eficacia.

Sugerencia

None: la replicación automática está establecida en Ninguna.
SystemKeyspaces: replicación automática de todos los espacios de claves del sistema (system_auth, system_traces, system_auth)
AllKeyspaces: replicación automática de todos los espacios de claves y supervisión de si se crean espacios de claves y, después, aplicación automática de la configuración de replicación automática.

Escenarios de replicación automática

Al agregar un nuevo centro de datos, la característica de replicación automática en Cassandra ejecutará sin problemas nodetool rebuild para garantizar la replicación correcta de los datos en el centro de datos agregado.
Al quitar un centro de datos, se desencadena una eliminación automática del centro de datos específico de los espacios de claves.

En el caso de los centros de datos externos, como los hospedados en el entorno local, se pueden incluir en los espacios de claves mediante el uso de la propiedad del centro de datos externo. Esto permite a Cassandra incorporar estos centros de datos externos como orígenes para el proceso de regeneración.

Advertencia

Al establecer la replicación automática en AllKeyspaces cambiará la replicación de los espacios de claves que se van a incluir WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } Si no es la topología que quiere, tendrá que usar SystemKeyspaces, ajustarlos personalmente y ejecutar nodetool rebuild de forma manual en el clúster de Azure Managed Instance for Apache Cassandra.

Desasignar clúster

En el caso de entornos que no son de producción, puede pausar o cancelar la asignación de recursos en el clúster para evitar que se les cobre por ellos (se seguirá cobrando por el almacenamiento). En primer lugar, cambie el tipo de clúster a NonProduction y, a continuación deallocate.

Sugerencia

El tipo de clúster debe usarse como "NonProduction" solo para ahorrar costos de desarrollo. Pueden venir con SKU más pequeñas y NO deben usarse para ejecutar cargas de trabajo de producción.

Advertencia

El tipo de clúster definido como "NonProduction" no tendrá garantías de Acuerdo de Nivel de Servicio aplicadas.
No ejecute ninguna operación de esquema o escritura durante la desasignación: esto puede provocar la pérdida de datos y, en raras ocasiones, daños en el esquema que requieren la intervención manual del equipo de soporte técnico.

Solución de problemas

Si se produce un error al aplicar permisos a la red virtual mediante la CLI de Azure, por ejemplo, se indica que no se encuentra el usuario o la entidad de servicio en la base de datos de grafos para "e5007d2c-4b13-4a74-9b6a-605d99f03501" , puede aplicar el mismo permiso manualmente desde Azure Portal. Aprenda cómo hacerlo aquí.

Nota

La asignación de roles de Azure Cosmos DB se usa solo con fines de implementación. Azure Managed Instance for Apache Cassandra no tiene dependencias de back-end en Azure Cosmos DB.

Conectarse a los clúster

Azure Managed Instance for Apache Cassandra no crea nodos con direcciones IP públicas, así que para conectarse al clúster de Cassandra recién creado, deberá crear otro recurso dentro de la red virtual. Puede ser una aplicación o una máquina virtual con la herramienta de consulta de código abierto de Apache, CQLSH, instalada. Puede usar una plantilla para implementar una máquina virtual de Ubuntu.

Conexión desde CQLSH

Después de implementar la máquina virtual, use SSH para conectarse a la máquina e instale CQLSH con los siguientes comandos:

# 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

Conexión desde una aplicación

Al igual que con CQLSH, la conexión desde una aplicación mediante uno de los controladores de cliente de Apache Cassandra admitidos requiere que el cifrado de SSL esté habilitado y la verificación de certificación esté deshabilitada. Consulte ejemplos para conectarse a Azure Managed Instance for Apache Cassandra mediante Java, .NET, Node.js y Python.

Se recomienda deshabilitar la comprobación de certificados porque esta comprobación no funcionará a menos que asigne las direcciones IP de los nodos de clúster al dominio adecuado. Si tiene una directiva interna que exige que realice la comprobación de certificados SSL para cualquier aplicación, puede facilitarlo agregando entradas como 10.0.1.5 host1.managedcassandra.cosmos.azure.com en el archivo de hosts para cada nodo. Si adopta este enfoque, también tendrá que agregar nuevas entradas cada vez que escale verticalmente los nodos.

Para Java, también se recomienda habilitar la directiva de ejecución especulativa en la que las aplicaciones son sensibles a la latencia alta. Aquí encontrará una demostración que describe cómo funciona y cómo se habilita la directiva.

Nota:

En la gran mayoría de los casos, no debería ser necesario configurar o instalar certificados (rootCA, nodo o cliente, almacenes de confianza, etc.) para conectarse a Azure Managed Instance for Apache Cassandra. El cifrado SSL se puede habilitar mediante el almacén de confianza predeterminado y la contraseña del runtime que usa el cliente (consulte los ejemplos de Java, .NET, Node.js y Python), ya que los certificados de Azure Managed Instance for Apache Cassandra serán de confianza para ese entorno. En raras ocasiones, si el certificado no es de confianza, es posible que tenga que agregarlo al almacén de confianza.

Configuración de certificados de cliente (opcional)

La configuración de certificados de cliente es opcional. Una aplicación cliente puede conectarse a Azure Managed Instance for Apache Cassandra siempre que se hayan realizado los pasos anteriores. Sin embargo, si lo prefiere, también puede crear y configurar certificados de cliente adicionales para la autenticación. En general, hay dos maneras de crear certificados:

Certificados autofirmados. Esto significa que existe un certificado privado y público (sin CA) para cada nodo. En este caso, necesitamos todos los certificados públicos.
Certificados firmados por una CA. Puede ser una entidad de certificación autofirmada o incluso una pública. En este caso, necesitamos el certificado de CA raíz (consulte las instrucciones sobre cómo preparar certificados SSL para producción) y todos los intermediarios (si procede).

Si desea implementar la autenticación de certificados de cliente a nodo o Seguridad de la capa de transporte (mTLS), debe proporcionar los certificados a través de la CLI de Azure. El siguiente comando cargará y aplicará los certificados de cliente al almacén de confianza para el clúster de la instancia administrada de Cassandra (es decir, no es necesario editar la configuración de cassandra.yaml). Una vez aplicado, el clúster requerirá que Cassandra compruebe los certificados cuando un cliente se conecte (consulte require_client_auth: truecassandra client_encryption_options).

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

Limpieza de recursos

Si no va a seguir usando este clúster de instancia administrada, elimínelo mediante los siguientes pasos:

En el menú de la izquierda de Azure Portal, seleccione Grupos de recursos.
En la lista, seleccione el grupo de recursos que creó para este inicio rápido.
En el panel Información general del grupo de recursos, seleccione Eliminar grupo de recursos.
En la ventana siguiente, escriba el nombre del grupo de recursos que desea eliminar y, después, seleccione Eliminar.

Pasos siguientes

En este inicio rápido, ha aprendido a crear un clúster de Azure Managed Instance for Apache Cassandra mediante Azure Portal. Ahora puede empezar a trabajar con el clúster:

Implementación de un clúster de Apache Spark administrado con Azure Databricks

Compartir a través de