Compartir a través de


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, 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

  1. Inicie sesión en Azure Portal.

  2. En la barra de búsqueda, escriba Managed Instance for Apache Cassandra y seleccione el resultado.

    Captura de pantalla de la búsqueda de Azure SQL Managed Instance en Apache Cassandra.

  3. Seleccione Create Managed Instance for Apache Cassandra cluster (Crear instancia administrada para el clúster de Apache Cassandra).

    Captura de pantalla que muestra el botón usado para crear el clúster.

  4. 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 la 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.
    • Nombre del clúster: escriba un nombre para el clúster.
    • Ubicación : ubicación para implementar el clúster.
    • Versión de Cassandra : versión de Apache Cassandra que se va a implementar.
    • Extensión : extensiones que se van a agregar, incluido Índice de Lucene de Cassandra.
    • 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.
    • Red virtual: seleccione una red virtual y una subred que salgan o cree una nueva.
    • Asignación de 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 implementó previamente clústeres de Cassandra de Azure SQL Managed Instance, anule la selección de esta opción.

    Captura de pantalla que muestra la pestaña Aspectos básicos de la página Crear.

    Sugerencia

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

    Nota:

    La implementación de una instancia administrada de Azure 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 KeyVault
    • Conjuntos de escalado de máquinas virtuales de Azure
    • Supervisión de Azure
    • Microsoft Entra ID
    • Seguridad de Azure
    • Replicación automática. Elija el formato de la replicación automática que se va a usar. Para obtener más información, consulte Replicación de llave en mano.
    • Programar estrategia de eventos. La estrategia que usa el clúster para eventos programados.

    Sugerencia

    • StopANY significa detener cualquier nodo cuando hay un evento programado para el nodo.
    • StopByRack significa solo detener el nodo en un bastidor determinado para un evento programado determinado. Por ejemplo, si hay varios eventos programados para nodos en bastidores diferentes al mismo tiempo, solo los nodos de un bastidor se detienen. Otros nodos de otros bastidores se retrasan.
  5. A continuación, seleccione la pestaña Data center (Centro de datos).

  6. 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 la SKU. Elija entre los tamaños de SKU de máquina virtual disponibles.

    Captura de pantalla de la selección de un tamaño de SKU.

    Nota:

    Hemos introducido el almacenamiento en caché de escritura directa (versión preliminar pública) mediante 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 enorme de IOPS para las operaciones de lectura y una latencia de cola reducida.

    Importante

    El almacenamiento en caché de escritura directa está en versión preliminar pública. Esta característica se proporciona sin un Acuerdo de Nivel de Servicio. 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.

    Captura de pantalla de la página del centro de datos donde puede revisar los valores.

    Advertencia

    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 Lista de regiones de Azure.

    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. Es posible que se produzca un error en las implementaciones si la SKU seleccionada o la capacidad no están disponibles en todas las zonas.

  7. A continuación, seleccione Revisar y crear>Crear.

    Nota:

    Puede tardar hasta 15 minutos en crear un clúster.

    Captura de pantalla que muestra la página Revisar y crear del clúster.

  8. Una vez finalizada la implementación, compruebe el grupo de recursos para ver el clúster de instancia administrada recién creado:

    Captura de pantalla que muestra la página Información general después de crear el clúster.

  9. Para examinar los nodos del clúster, vaya al recurso de clúster y abra el panel Centro de datos :

    Captura de pantalla de nodos de centro de datos.

Escalado de un centro de datos

Ahora que ha implementado un clúster con un único centro de datos, puede escalar horizontal o verticalmente resaltando el centro de datos y seleccionando el botón Escalar :

Captura de pantalla del escalado de nodos de centro de datos.

Escalado horizontal

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

Captura de pantalla de la selección del número de nodos de centro de datos.

Escalado vertical

Para aumentar o disminuir el tamaño de la SKU de sus nodos, seleccione entre Tamaño de SKU. Cuando termine, seleccione Escalar.

Captura de pantalla de la selección de tamaño de SKU

Nota:

El tiempo que tarda una operación de escalado depende de varios factores. Podría tardar varios minutos. Cuando Azure le notifica que la operación de escalado se ha completado, no significa que todos los nodos se unan al anillo de Cassandra. Los nodos están completamente operativos cuando todos muestran un estado saludable y el estado del centro de datos indica exitoso.

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

  1. Para agregar otro centro de datos, seleccione el botón Agregar en el panel Centro de datos :

    Captura de pantalla de la agregación de centro de datos.

    Advertencia

    Si va a agregar un centro de datos en otra región, debe seleccionar otra red virtual. También debe asegurarse de que esta red virtual tiene conectividad con la red virtual de la región primaria creada anteriormente. Además, asegúrese de que cualquier otra red virtual que hospede centros de datos dentro del clúster de instancia administrada esté configurada correctamente. Para más información, consulte Conexión de redes virtuales con emparejamiento de redes virtuales.

    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>
    
  2. 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 que las zonas de disponibilidad estén habilitadas en este centro de datos.
    • Ubicación. Ubicación donde se implementa el centro de datos.
    • Tamaño de la 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 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 que salgan.

    Captura de pantalla de la página Agregar centro de datos.

    Advertencia

    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.

  3. Al implementar el centro de datos, debería poder ver toda la información de este en el panel Centro de datos:

    Captura de pantalla que muestra los recursos del clúster.

  4. Para garantizar la replicación entre centros de datos, conéctese a 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};
    
  5. Si va a agregar un centro de datos a un clúster en el que ya hay datos, ejecute rebuild para replicar los datos históricos. En la CLI de Azure, use el siguiente comando 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 <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 debe permitir 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 debe crear una solicitud de soporte para que nuestro equipo pueda ejecutarlo repair en su nombre.

Actualización de la configuración de Cassandra

El servicio permite las actualizaciones de la configuración de YAML de Cassandra en un centro de datos mediante Azure Portal o mediante comandos de la CLI. Para actualizar la configuración en el portal:

  1. Busque Cassandra Configuration en Configuración. Resalte el centro de datos cuya configuración desea cambiar y seleccione Actualizar:

    Captura de pantalla de la selección de centro de datos para actualizar la configuración.

  2. En la ventana que se abre, escriba los nombres de campo en formato YAML, como se muestra aquí. A continuación, seleccione Actualizar.

    Captura de pantalla de la actualización del centro de datos con la configuración de Cassandra.

  3. Una vez completada la actualización, los valores invalidados aparecen en el Cassandra Configuration panel:

    Captura de pantalla de la configuración de Cassandra actualizada.

    Nota:

    En Azure 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 implementó. Consulte la configuración de Cassandra v3.11 para la versión 3.11 y la de Cassandra v4.0 para la versión 4.0. No puede actualizar la siguiente configuración de YAML:

    • nombre_del_cluster
    • proveedor_de_semillas
    • initial_token
    • autobootstrap
    • opciones_de_encriptación_del_cliente
    • opciones_de_encriptación_del_servidor
    • opciones_de_cifrado_de_datos_transparente
    • audit_logging_options
    • autenticador
    • authorizer
    • gestor_de_roles
    • puerto_de_almacenamiento
    • ssl_storage_port
    • puerto de transporte nativo
    • native_transport_port_ssl
    • listen_address
    • interfaz_de_escucha
    • dirección de difusión
    • hints_directory
    • directorios_de_archivos_de_datos
    • commitlog_directory
    • cdc_raw_directory
    • directorio_de_cachés_guardados
    • 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 proporcionan sin un contrato 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.

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.

  1. Busque el Update panel en la pestaña Información general.

    Captura de pantalla de la actualización de la versión de Cassandra.

  2. Seleccione la versión de Cassandra en la lista desplegable.

    Advertencia

    No omita las versiones. Se recomienda actualizar solo de una versión a otra de ejemplo 3.11 a 4.0, 4.0 a 4.1.

    Captura de pantalla de la selección de la versión de Cassandra.

  3. Seleccione Actualizar para guardar.

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. Si usa la funcionalidad de replicación llave en mano, la configuración y administración de clústeres de varias regiones es 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 a la implementación y el mantenimiento de varias configuraciones de región, lo que permite a los usuarios usar las funcionalidades de Cassandra con mayor facilidad y eficacia.

Seleccione la opción a la que se hace referencia en la lista desplegable.

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 nuevos 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 se ejecuta nodetool rebuild sin problemas para garantizar la replicación correcta de 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. Este enfoque 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, se cambia la replicación de los espacios de claves para incluir:

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

Si no es la topología que quiere, use SystemKeyspaces, ajústelos personalmente y ejecute 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 desasignar recursos en el clúster para evitar que se les cobre. Se le 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 "No Producción" solo para ahorrar costos de desarrollo. Pueden tener 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 "No producción" no tiene garantías de Acuerdo de Nivel de Servicio aplicadas.
  • No ejecute ninguna operación de esquema o escritura durante la desasignación. Esta acción puede provocar la pérdida de datos y, en raras ocasiones, daños en el esquema que requieren intervención manual del equipo de soporte técnico.

Captura de pantalla de un clúster en pausa.

Solución de problemas

Si se produce un error al aplicar permisos a la red virtual mediante la CLI de Azure, puede aplicar el mismo permiso manualmente desde Azure Portal. Un ejemplo de este error es No se encuentra 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.

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 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.

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 para Apache Cassandra mediante Java, .NET, Node.jsy Python.

Se recomienda deshabilitar la comprobación de certificados porque la comprobación de certificados no funciona a menos que asigne direcciones IP de los nodos del 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 facilitar esta configuración 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 debe agregar nuevas entradas siempre que amplíe 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. Para obtener una demostración que muestre cómo funciona este enfoque, consulte y cómo habilitar la directiva demostración: implementación de la ejecución especulativa.

Nota:

En la mayoría de los casos, no debe ser necesario configurar o instalar certificados (como rootCA, node o client, truststores) 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 entorno de ejecución que usa el cliente, ya que los certificados de Azure Managed Instance para Apache Cassandra son 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. 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 siempre que se completen los pasos anteriores. Sin embargo, 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. Certificado privado y público (sin CA) para cada nodo. En este caso, necesita todos los certificados públicos.
  • Certificados firmados por una CA. Este certificado puede ser una entidad de certificación autofirmada o incluso una pública. En este caso, necesita el certificado de entidad de certificación raíz y todos los intermediarios (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), proporcione los certificados mediante la CLI de Azure. 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. 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, elimínelo mediante los siguientes pasos:

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

Paso siguiente