Inicio rápido: Configuración de un clúster híbrido con Azure Managed Instance for Apache Cassandra

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 esta guía de inicio rápido se muestra cómo usar los comandos de la CLI de Azure para configurar un clúster híbrido. Si tiene centros de datos existentes en un entorno local o autohospedado, puede usar Azure Managed Instance para Apache Cassandra para agregar otros centros de datos a esos clústeres y mantenerlos.

Requisitos previos

Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte Introducción a Azure Cloud Shell.
Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de Azure. Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de Azure en un contenedor Docker. Para obtener más información, consulte Ejecución de la CLI de Azure en un contenedor de Docker.
- Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az login. Siga los pasos que se muestran en el terminal para completar el proceso de autenticación. Para ver otras opciones de inicio de sesión, consulte Autenticación en Azure mediante la CLI de Azure.
- En caso de que se le solicite, instale las extensiones de la CLI de Azure la primera vez que la use. Para obtener más información sobre las extensiones, consulte Uso y administración de extensiones con la CLI de Azure.
- Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están instaladas. Para realizar la actualización a la versión más reciente, ejecute az upgrade.

En este artículo se requiere la versión 2.30.0 o posterior de la CLI de Azure. Si usa Azure Cloud Shell, ya está instalada la versión más reciente.
Use una red virtual de Azure con conectividad con el entorno autohospedado o local. Para más información sobre cómo conectar entornos locales a Azure, consulte Conexión de una red local a Azure.

Configuración de clústeres híbridos

Inicie sesión en Azure Portal y vaya al recurso de red virtual.
Seleccione la pestaña Subredes y cree una nueva subred. Para obtener más información sobre los campos del formulario Agregar subred , consulte Agregar una subred.

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 dentro de la red virtual a los siguientes servicios vitales de Azure necesarios para que Azure Managed Instance for Apache Cassandra funcione correctamente. Para obtener una lista de las dependencias de puerto y dirección IP, 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
Aplique algunos permisos especiales a la red virtual y a la subred, que azure Managed Instance para Apache Cassandra requiere mediante la CLI de Azure. Use el comando az role assignment create. Reemplace <subscriptionID>, <resourceGroupName>, y <vnetName> con los valores adecuados.
```
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>
```
Los valores assignee y role en el comando anterior son identificadores fijos de principal de servicio y de rol, respectivamente.
Configure los recursos para el clúster híbrido. Dado que ya tiene un clúster, el nombre del clúster es un recurso lógico para identificar el nombre del clúster existente. Usa el nombre del clúster existente al definir las variables clusterName y clusterNameOverride en el siguiente script.

También necesita, como mínimo, los nodos de inicialización del centro de datos existente y los certificados de intercambio necesarios para el cifrado de nodo a nodo. Azure Managed Instance for Apache Cassandra requiere cifrado de nodo a nodo para la comunicación entre centros de datos. Si no tiene el cifrado de nodo a nodo implementado en el clúster existente, debe implementarlo. Para obtener más información, consulte Cifrado de nodo a nodo. Proporcione la ruta de acceso a la ubicación de los certificados. Cada certificado debe estar en formato correo mejorado de privacidad (PEM), por ejemplo, -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. En general, hay dos maneras de implementar 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 intermediarios (si procede). Para más información, consulte Preparación de certificados de Capa de sockets seguros (SSL) para producción.
Opcionalmente, si desea implementar la autenticación de certificados de cliente a nodo o la seguridad mutua de la capa de transporte (TLS), proporcione los certificados con el mismo formato que al crear el clúster híbrido. Consulte el ejemplo de la CLI de Azure más adelante en este artículo. Los certificados se proporcionan en el --client-certificates parámetro .

Este enfoque carga y aplica los certificados de cliente al almacén de confianza para el clúster de Azure Managed Instance for Apache Cassandra. No es necesario editar cassandra.yaml la configuración. Una vez aplicados los certificados, 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.

El valor de la delegatedManagementSubnetId variable que proporcione en este código es el mismo que el valor de --scope que proporcionó en un comando anterior:
```
resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster-legal-name'
clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'

# You can override the cluster name if the original name isn't legal for an Azure resource:
# overrideClusterName='ClusterNameIllegalForAzureResource'
# the default cassandra version will be v3.11

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
  --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
  # optional - add your existing datacenter's client-to-node certificates (if implemented):
  # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed
```
Si el clúster ya tiene cifrado de nodo a nodo y cliente a nodo, debe saber dónde se conservan los certificados TLS/SSL existentes. Si no está seguro, ejecute keytool -list -keystore <keystore-path> -rfc -storepass <password> para imprimir los certificados.

Una vez creado el recurso del clúster, ejecute el siguiente comando para obtener los detalles de configuración del clúster:

resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'

az managed-cassandra cluster show \
   --cluster-name $clusterName \
   --resource-group $resourceGroupName \

El comando anterior devuelve información sobre el entorno de la instancia administrada. Necesitará los certificados de intercambio para poder instalarlos en el almacén de confianza para los nodos del centro de datos existente. En la captura de pantalla siguiente se muestra la salida del comando anterior y el formato de los certificados.

Los certificados devueltos por el comando anterior contienen saltos de línea que se representan como texto. Un ejemplo es \r\n. Copie cada certificado en un archivo y dé formato antes de intentar importarlo en el almacén de confianza existente.

Copiar el valor de matriz gossipCertificates que se muestra en la captura de pantalla en un archivo. Use el siguiente script de Bash para dar formato a los certificados y crear archivos PEM independientes para cada uno. Para descargar el script de Bash, consulte Descarga de jq para su plataforma.
```
readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
# iterate through the certs array, format each cert, write to a numbered file.
num=0
filename=""
for item in "${cert_array[@]}"; do
let num=num+1
filename="cert$num.pem"
cert=$(jq '.pem' <<< $item)
echo -e $cert >> $filename
sed -e 's/^"//' -e 's/"$//' -i $filename
done
```
A continuación, cree un nuevo centro de datos en el clúster híbrido. Reemplace los valores de variable por los detalles del clúster:
```
resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'
dataCenterLocation='eastus2'
virtualMachineSKU='Standard_D8s_v4'
noOfDisksPerNode=4

az managed-cassandra datacenter create \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --data-center-location $dataCenterLocation \
  --delegated-subnet-id $delegatedManagementSubnetId \
  --node-count 9
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false
```
Elija el valor de --sku en los siguientes niveles de producto disponibles:
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
El valor para --availability-zone se establece en false. Para activar zonas de disponibilidad, establezca este valor en true. Las zonas de disponibilidad aumentan el acuerdo de nivel de servicio (SLA) de disponibilidad del servicio. Para más información, consulte Acuerdo de Nivel de Servicio para servicios en línea.

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 ver las regiones admitidas, 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.

Ahora que se crea el nuevo centro de datos, ejecute el datacenter show comando para ver sus detalles:

resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'

az managed-cassandra datacenter show \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName

El comando anterior muestra los nodos de inicialización del nuevo centro de datos.

Agregue los nodos de inicialización del nuevo centro de datos a la configuración del nodo de inicialización del centro de datos existente en el archivo cassandra.yaml . Además, instale los certificados de intercambio de instancia administrada que recopiló anteriormente en el almacén de confianza para cada nodo del clúster existente. Use el keytool comando para cada certificado:
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Si desea agregar más centros de datos, repita los pasos anteriores, pero solo necesita los nodos de inicialización.

Importante

Si el clúster existente de Apache Cassandra tiene solo un centro de datos, y este centro de datos es el primero agregado, asegúrese de que el parámetro endpoint_snitch en cassandra.yaml esté establecido en GossipingPropertyFileSnitch.

Si el código de aplicación existente usa QUORUM para la coherencia, asegúrese de que antes de cambiar la configuración de replicación en el paso siguiente, el código de aplicación existente usaLOCAL_QUORUM para conectarse al clúster existente. De lo contrario, se produce un error en las actualizaciones dinámicas después de cambiar la configuración de replicación en el paso siguiente. Después de cambiar la estrategia de replicación, puede revertir a QUORUM si lo prefiere.
Por último, use la siguiente consulta del lenguaje de consulta de Cassandra para actualizar la estrategia de replicación en cada espacio de claves para incluir todos los centros de datos en el clúster:
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};
```
También tiene que actualizar varias tablas del sistema:
```
ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
```
Si los centros de datos del clúster existente no aplican el cifrado de cliente a nodo (SSL) y piensa que el código de la aplicación se conecte directamente a Azure Managed Instance para Apache Cassandra, también debe habilitar TLS/SSL en el código de la aplicación.

Uso de un clúster híbrido para la migración en tiempo real

Las instrucciones anteriores proporcionan instrucciones sobre cómo configurar un clúster híbrido. Este enfoque también es una excelente manera de lograr una migración sin problemas de tiempo de inactividad cero. En el procedimiento siguiente se muestra cómo migrar un entorno local u otro entorno de Cassandra que quiera retirar, sin tiempo de inactividad, a Azure Managed Instance para Apache Cassandra.

Configure un clúster híbrido. Siga las instrucciones anteriores.

Deshabilite temporalmente las reparaciones automáticas en Azure Managed Instance para Apache Cassandra durante la migración:

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled false

En la CLI de Azure, use el siguiente comando para ejecutar nodetool rebuild en cada nodo del nuevo centro de datos de Azure Managed Instance for Apache Cassandra. Reemplace por <ip address> la dirección IP del nodo. Reemplace <sourcedc> por el nombre del centro de datos existente, el del que va a migrar:
```
az managed-cassandra cluster invoke-command \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --host <ip address> \
  --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
```
Ejecute este comando solo después de realizar todos los pasos anteriores. Este enfoque debe asegurarse de que todos los datos históricos se replican en los nuevos centros de datos de Azure Managed Instance para Apache Cassandra. Puede ejecutarse rebuild en uno o varios nodos al mismo tiempo. Ejecute en un nodo a la vez para reducir el efecto en el clúster existente. Ejecútela en varios nodos cuando el clúster pueda controlar la presión adicional de red y E/S. Para la mayoría de las instalaciones, solo puede ejecutar una o dos en paralelo para que no sobrecargue el clúster.
Advertencia

Debe especificar el origen data center al ejecutar nodetool rebuild. Si proporciona el centro de datos incorrectamente en el primer intento, los intervalos de tokens se copian sin copiar los datos de las tablas que no pertenecen al sistema. Se produce un error en los intentos posteriores incluso si proporciona el centro de datos correctamente. Para resolver este problema, elimine las entradas de cada espacio de claves que no sea del sistema en system.available_ranges usando la herramienta de consulta cqlsh en el centro de datos de Azure Managed Instance for Apache Cassandra de destino:
```
delete from system.available_ranges where keyspace_name = 'myKeyspace';
```
Corte el código de la aplicación para que apunte a los nodos de inicialización de los nuevos centros de datos de Azure Managed Instance for Apache Cassandra.

Como también se mencionó en las instrucciones de configuración híbrida, si los centros de datos del clúster existente no aplican el cifrado de cliente a nodo (SSL), habilite esta característica en el código de la aplicación. Azure Managed Instance para Apache Cassandra aplica este requisito.
Ejecute ALTER KEYSPACE para cada keyspace de la misma manera como se hizo anteriormente. Ahora puede quitar los centros de datos antiguos.
Ejecute node tool decommission en cada nodo antiguo del centro de datos.
Vuelva a cambiar el código de la aplicación a QUORUM, si es necesario o preferido.

Volver a habilitar reparaciones automáticas

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled true

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

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

Administración de recursos de Azure Managed Instance for Apache Cassandra mediante la CLI de Azure

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-07-23