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

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, para lograr la máxima flexibilidad y control.

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

Prerrequisito

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, busque Instancia administrada para Apache Cassandra y seleccione el resultado.
Seleccione Create Managed Instance for Apache Cassandra cluster (Crear instancia administrada para el clúster de Apache Cassandra).
En el panel Crear instancia administrada para Apache Cassandra , escriba la siguiente información:
- Suscripción: en la lista desplegable, seleccione la suscripción de Azure.
- Grupo de recursos: especifique si desea crear un grupo de recursos o usar uno existente. Un grupo de recursos es un contenedor que almacena los recursos relacionados con una solución de Azure.
- Nombre del clúster: escriba un nombre para el clúster.
- Ubicación: seleccione la ubicación para implementar el clúster.
- Versión de Cassandra: seleccione la versión de Apache Cassandra que se va a implementar.
- Extensión: seleccione extensiones para agregar, incluido Cassandra Lucene Index. Esto solo es relevante para Cassandra v3.11.
- Contraseña de administrador inicial de Cassandra: escriba la contraseña usada para crear el clúster.
- Confirme la contraseña de administrador de Cassandra: vuelva a escribir la contraseña.
- Red virtual: seleccione una red virtual y una subred existentes o cree una nueva. Tome nota de las reglas de red o puede usar la configuración basada en VPN.
- Asignación de roles: las redes virtuales requieren permisos especiales para permitir la implementación de clústeres de Cassandra administrados. Mantenga esta casilla seleccionada si crea una nueva red virtual o usa una red virtual existente sin permisos aplicados. Si usa una red virtual en la que implementó previamente clústeres de Cassandra de Azure SQL Managed Instance, desactive esta opción.
Si usa una red privada virtual, no es necesario abrir otra conexión.

La implementación de Azure Managed Instance para Apache Cassandra requiere acceso a Internet. En entornos con acceso limitado a Internet se produce un error de implementación. Asegúrese de que no está bloqueando el acceso en la red virtual a los siguientes servicios vitales de Azure necesarios para que Cassandra administrado funcione correctamente. Para obtener más información, consulte Reglas de red de salida requeridas.
- Azure Storage
- Azure Key Vault
- Conjuntos de escalado de máquinas virtuales de Azure
- Azure Monitor
- Microsoft Entra ID
- Microsoft Defender for Cloud
- Replicación automática: elija la forma de autorplicación que se va a usar. Para obtener más información, consulte Replicación de llave en mano.
- Estrategia de eventos programados: la estrategia que usa el clúster para los eventos programados.
Sugerencia
- StopANY significa detener cualquier nodo cuando hay un evento programado para el nodo.
- StopByRack significa detener nodos solo en un bastidor específico para un evento programado específico. Por ejemplo, si se programan varios eventos para nodos de distintas estanterías a la vez, solo se detienen los nodos de un estantería. Otros nodos de otros bastidores se retrasan.
Seleccione la pestaña 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.
- Zona de disponibilidad: active esta casilla si desea habilitar zonas de disponibilidad.
- Tamaño de SKU: elija entre los tamaños de nivel de producto de máquina virtual (VM) disponibles.
Se introdujo el almacenamiento en caché de escritura a través (versión preliminar pública) mediante los niveles de producto de máquina virtual de la serie L. Esta implementación tiene como objetivo minimizar las latencias de cola y mejorar el rendimiento de lectura, especialmente para cargas de trabajo de lectura intensiva. Estos niveles de producto específicos están equipados con discos conectados localmente, lo que garantiza un mayor número de IOPS para las operaciones de lectura y una latencia de cola reducida.

El almacenamiento en caché de escritura directa se proporciona sin un contrato de nivel de servicio (SLA). No es aconsejable 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 van a conectar a cada nodo de Cassandra.
- No. de nodos: elija el número de nodos de Cassandra que se van a implementar en este centro de datos.
Las Availability zones no se admiten en todas las regiones. Se produce un error en las implementaciones si selecciona una región en la que no se admiten las zonas de disponibilidad. Para más información, consulte la lista de regiones de Azure.

La implementación correcta de zonas de disponibilidad también está sujeta a la disponibilidad de los recursos de proceso en todas las zonas de la región específica. Es posible que se produzca un error en las implementaciones si el nivel de producto seleccionado o la capacidad no está disponible en todas las zonas.
Seleccione Revisar y crear>Crear.

Puede tardar hasta 15 minutos en crear un clúster.
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 .

Escalado de un centro de datos

Después de implementar un clúster con un único centro de datos, puede escalar horizontal o verticalmente. Resalte el centro de datos y, a continuación, seleccione Escalar.

Escalado horizontal

Para escalar horizontalmente o escalar horizontalmente en nodos, mueva el control deslizante al número que desee. También puede editar el valor. Cuando haya terminado, seleccione Escalar.

Escalado vertical

Para aumentar o disminuir el tamaño del nivel de producto para sus nodos, seleccione opciones de la lista desplegable Tamaño de SKU. Cuando haya terminado, seleccione Escalar.

El período de tiempo que tarda una operación de escalado depende de varios factores. La operación puede tardar varios minutos. Cuando Azure le notifica que la operación de escalado ha finalizado, no significa que todos los nodos se unan al anillo de Cassandra. Los nodos se encargan por completo cuando todos muestran un estado correcto y el estado del centro de datos lee Correcto.

El escalado es una operación en línea y funciona de la misma manera que se describe para aplicación de revisión. Para obtener más información, consulte Aplicación de revisión

Incorporación de un centro de datos

Para agregar otro centro de datos, en el panel Centro de datos , seleccione Agregar.

Si agrega un centro de datos en otra región, debe seleccionar otra red virtual. Asegúrese de que esta red virtual tenga conectividad con la red virtual de la región primaria que se creó anteriormente. Además, asegúrese de que cualquier otra red virtual que hospede centros de datos esté dentro del clúster de instancia administrada. Para más información, consulte Conexión de redes virtuales con emparejamiento de redes virtuales.

Asegúrese de aplicar el rol adecuado a la red virtual antes de intentar implementar un clúster de instancia administrada. Use el siguiente comando de la CLI de Azure:
```
   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:
- Nombre del centro de datos: en la lista desplegable, seleccione la suscripción de Azure.
- Zona de disponibilidad: seleccione si desea habilitar zonas de disponibilidad en este centro de datos.
- Ubicación: ubicación donde se implementa el centro de datos.
- Tamaño de SKU: elija entre los tamaños de nivel de producto de máquina virtual disponibles.
- No. de discos: elija el número de discos p30 que se van a conectar a cada nodo de Cassandra.
- No. de nodos: elija el número de nodos de Cassandra que se van a implementar en este centro de datos.
- Red virtual: seleccione una red virtual y una subred existentes.
Azure Portal no permite la creación de una nueva red virtual al agregar un centro de datos. Debe elegir una red virtual existente y debe asegurarse de que hay conectividad entre las subredes de destino en las que se implementan los centros de datos. También debe aplicar el rol adecuado a la red virtual para permitir la implementación, como se ha descrito anteriormente.
Cuando se implementa el centro de datos, debería poder ver toda la información del centro de datos en el panel Centro de datos .
Para garantizar la replicación entre centros de datos, conéctese a Cassandra Query Language Shell (CQLSH) y use la siguiente consulta CQL para actualizar la estrategia de replicación en cada espacio de claves para incluir todos los centros de datos en el clúster. Las tablas del sistema se actualizan automáticamente.
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
```
Si agrega un centro de datos a un clúster que ya tiene datos, ejecute rebuild para replicar los datos históricos. En la CLI de Azure, use el siguiente comando y ejecute nodetool rebuild en cada nodo del nuevo centro de datos. Esta acción reemplaza <new dc ip address> por la dirección IP del nodo y reemplaza <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>"=""
```

No permita que los clientes de aplicaciones escriban en el nuevo centro de datos hasta que aplique los cambios de replicación del espacio de claves. De lo contrario, la recompilación no funciona y necesita crear una solicitud de soporte para que nuestro equipo pueda ejecutar repair por usted.

Actualización de la configuración de Cassandra

Puede usar los comandos de Azure Portal o la CLI para actualizar la configuración de Cassandra YAML en un centro de datos. Para actualizar la configuración en el portal:

En Configuración, seleccione Configuración de Cassandra. Resalte el centro de datos cuya configuración desea cambiar y, a continuación, seleccione Actualizar.
En la ventana que se abre, escriba los nombres de campo en formato YAML, como se muestra aquí. Después, seleccione Actualizar.
Una vez finalizada la actualización, los valores invalidados aparecen en el panel Configuración de Cassandra .

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

Asegúrese de que la configuración de Cassandra YAML que proporcione sea adecuada para la versión de Cassandra que implementó. Para obtener más información, consulte [Cassandra v5.0] (https://github.com/apache/cassandra/blob/cassandra-5.0/conf/cassandra.yaml) y Cassandra v4.0 para la configuración de v4.0 y Cassandra v3.11 para la configuración de Cassandra v3.11. No puede 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
- authenticator
- 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

Las actualizaciones de la versión de Cassandra 5.0 y Turnkey están en versión preliminar pública. Estas características se proporcionan sin un Acuerdo de Nivel de Servicio. No se recomiendan estas características 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.

Puede realizar actualizaciones de versión principal directamente en su lugar desde el portal o a través de la CLI de Azure, Terraform o plantillas de Azure Resource Manager.

En la pestaña Información general , seleccione Actualizar.
Seleccione la versión de Cassandra en la lista desplegable.

No omita las versiones. Se recomienda actualizar solo de una versión a otra. Por ejemplo, actualice de 3.11 a 4.0 o de 4.0 a 4.1 o de 4.1 a 5.0.
Seleccione Actualizar para guardar.

Replicación inmediata

Cassandra 5.0 presenta un enfoque simplificado para implementar clústeres de varias regiones, que ofrecen mayor comodidad y eficacia. Si usa la funcionalidad de replicación llave en mano, es más accesible configurar y administrar clústeres de varias regiones. Obtiene una integración y operación más fluidas en entornos distribuidos.

Esta actualización reduce las complejidades asociadas a la implementación y el mantenimiento de varias configuraciones de región. Los usuarios pueden usar las funcionalidades de Cassandra con mayor facilidad y eficacia.

Ninguno: la opción Replicar automáticamente se establece en Ninguno.
Espacios de claves del sistema: replica automáticamente todos los espacios de claves del sistema (system_auth, system_tracesy system_auth).
Todos los Keyspaces: Autoreplicar todos los keyspaces, supervisar si se crean nuevos keyspaces y luego aplicar automáticamente la configuración de replicación.

Escenarios de replicación automática

Al agregar un nuevo centro de datos, la característica de replicación automática en Cassandra se ejecuta nodetool rebuild sin problemas para garantizar la replicación correcta de datos en el centro de datos agregado. Al quitar un datacenter, se elimina automáticamente el datacenter específico de los keyspaces.

En el caso de los centros de datos externos, como los hospedados en el entorno local, use la propiedad del centro de datos externo para incluirlos en los espacios de claves. Este enfoque permite a Cassandra incorporar estos centros de datos externos como orígenes para el proceso de regeneración.

Si configura Replicación automática para Todos los espacios de claves, los cambios en la replicación de los espacios de claves incluyen:

WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 }

Si esta topología no es lo que desea, use SystemKeyspaces, ajuste usted mismo y ejecútelos nodetool rebuild manualmente en el clúster de Azure Managed Instance para Apache Cassandra.

Desasignar un clúster

En el caso de entornos que no son de producción, puede pausar o desasignar recursos en el clúster para evitar que se les cobre. Se le seguirá cobrando por el almacenamiento. En primer lugar, cambie Tipo de clúster a Noproducción y, a continuación, seleccione Desasignar.

Use el tipo de clúster NonProduction solo para ahorrar costos de desarrollo. Este tipo de clúster puede tener niveles de producto más pequeños. No lo use para ejecutar cargas de trabajo de producción.

Los tipos de clúster definidos como NonProduction no tienen garantías de Acuerdo de Nivel de Servicio aplicadas a ellos.
No ejecute ninguna operación de esquema o escritura durante la desasignación. Esta acción puede provocar la pérdida de datos. En raras ocasiones, puede experimentar daños en el esquema, lo que requiere 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 al usar la CLI de Azure, puede aplicar manualmente el mismo permiso desde Azure Portal. Un ejemplo de este error es "No se puede encontrar el usuario o la entidad de servicio en la base de datos de grafos para e5007d2c-4b13-4a74-9b6a-605d99f03501". Para obtener más información, consulte Uso de Azure Portal para agregar una entidad de servicio de Azure Cosmos DB.

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

Conexión al clúster

Azure Managed Instance para Apache Cassandra no crea nodos con direcciones IP públicas. Para conectarse al clúster de Cassandra recién creado, cree otro recurso dentro de la red virtual. Este recurso podría 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 Ubuntu.

Conéctese desde CQLSH

Una vez implementada la máquina virtual, use Secure Shell para conectarse a la máquina. Para instalar CQLSH, use 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, cuando se usa uno de los controladores cliente de Apache Cassandra compatibles para conectarse desde una aplicación, el cifrado de capa de sockets seguros y seguridad de la capa de transporte (TLS/SSL) debe estar habilitado y la comprobación de certificados debe estar deshabilitada. Para obtener ejemplos que se usan para conectarse a Azure Managed Instance para Apache Cassandra, consulte Java, .NET, Node.jsy Python.

Se recomienda deshabilitar la comprobación de certificados porque no funciona a menos que asigne direcciones IP de los nodos del clúster al dominio adecuado. Si una directiva interna exige que realice la comprobación de certificados TLS/SSL para cualquier aplicación, agregue entradas como 10.0.1.5 host1.managedcassandra.cosmos.azure.com en el archivo de hosts para cada nodo para facilitar esta configuración. Si adopta este enfoque, también debe agregar nuevas entradas cada vez que escale verticalmente los nodos.

Para Java, se recomienda habilitar la directiva de ejecución especulativa en la que las aplicaciones son sensibles a la latencia final. Para obtener una demostración que muestre cómo funciona este enfoque y cómo habilitar la directiva, consulte Demostración: Implementación de la ejecución especulativa.

En la mayoría de los casos, no debe ser necesario configurar o instalar certificados (como rootCA, node, cliento truststore) para conectarse a Azure Managed Instance para Apache Cassandra. Para habilitar el cifrado TLS/SSL, use el almacén de confianza predeterminado y la contraseña del tiempo de ejecución que usa el cliente. Ese entorno confía en los certificados de Azure Managed Instance para Apache Cassandra. En raras ocasiones, si el certificado no es de confianza, es posible que tenga que agregarlo al almacén de confianza. Para obtener código de ejemplo, consulte Java, .NET, Node.jsy Python.

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 para Apache Cassandra si finalizan los pasos anteriores. Si lo prefiere, también puede crear y configurar certificados de cliente para la autenticación. En general, hay dos maneras de crear certificados:

Certificados autofirmados: Certificados privados y públicos sin entidad de certificación (CA) para cada nodo. En este caso, necesita todos los certificados públicos.
Certificados firmados por una ENTIDAD de certificación: Certificados emitidos por una ENTIDAD de certificación autofirmada o una CA pública. En este caso, necesita el certificado de entidad de certificación raíz y todos los certificados intermedios, si procede. Para obtener más información, consulte Preparación de certificados SSL para producción.

Si desea implementar la autenticación de certificados de cliente a nodo o la seguridad mutua de la capa de transporte (mTLS), use la CLI de Azure para proporcionar los certificados. El comando siguiente carga y aplica los certificados de cliente al almacén de confianza para el clúster de instancia administrada. No es necesario editar cassandra.yaml la configuración. Después de aplicar el comando, el clúster requiere Cassandra para comprobar los certificados cuando se conecta un cliente. Para obtener más información, consulte require_client_auth: true en Cassandra 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, siga estos pasos para eliminarlo:

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 el panel siguiente, escriba el nombre del grupo de recursos que desea eliminar y, a continuación, seleccione Eliminar.

Paso siguiente

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

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-08-21