Share via

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

  • Artículo

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 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 for Apache Cassandra para agregar otros centros de datos a ese clúster y mantenerlos.

Requisitos previos

  • Este artículo requiere la CLI de Azure 2.30.0 o una versión posterior. Si usa Azure Cloud Shell, la versión más reciente ya está instalada.

  • Azure Virtual Network con conectividad a su entorno autohospedado o local. Para más información sobre cómo conectar entornos locales a Azure, consulte el artículo Conexión de una red local a Azure.

Configuración de clústeres híbridos

  1. Inicie sesión en Azure Portal y vaya al recurso de Virtual Network.

  2. Abra la pestaña Subredes y cree una nueva subred. Para más información sobre los campos del formulario Agregar subred, consulte el artículo Incorporación, cambio o eliminación de una subred de red virtual:

    Add a new subnet to your Virtual Network.

    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. También puede encontrar una amplia lista de dependencias de puertos y direcciones IP aquí.

    • Azure Storage
    • Azure KeyVault
    • Conjuntos de escalado de máquinas virtuales de Azure
    • Supervisión de Azure
    • Microsoft Entra ID
    • Azure Security

  3. Ahora aplicaremos algunos permisos especiales a la red virtual y a la subred que requiere Managed Instance for Apache Cassandra mediante la CLI de Azure. Utilice el comando az role assignment create y 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>

    Nota

    Los valores assignee y role del comando anterior son los identificadores de rol y principio de servicio fijos, respectivamente.

  4. A continuación, vamos a configurar los recursos para nuestro clúster híbrido. Puesto que ya tiene un clúster, el nombre del clúster solo será un recurso lógico para identificar el nombre del clúster existente. Asegúrese de usar el nombre del clúster existente al definir las variables clusterName y clusterNameOverride en el script siguiente.

    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 implementado el cifrado de nodo a nodo en el clúster existente, deberá implementarlo. Consulte la documentación aquí. Debe proporcionar la ruta de acceso a la ubicación de los certificados. Todos los certificados deben estar en formato PEM; p. ej., -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. En general, hay dos maneras de implementar certificados:

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

    2. 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 entidad de certificación raíz (consulte las instrucciones sobre cómo preparar certificados SSL para producción) y todos los intermediarios (si procede).

    Opcionalmente, si también quisiera implementar la autenticación de certificados de cliente a nodo o la seguridad de la capa de transporte (mTLS), deberá proporcionar los certificados en el mismo formato que al crear el clúster híbrido. Consulte el ejemplo de la CLI de Azure a continuación: los certificados se proporcionan en el parámetro --client-certificates. Esto 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 será 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).

    Nota

    El valor de la variable delegatedManagementSubnetId que proporcionará a continuación es exactamente el mismo que el valor de --scope proporcionado en el 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 is not 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

    Nota

    Si el clúster ya tiene cifrado de nodo a nodo y de cliente a nodo, debe saber dónde se guardan los certificados SSL de cliente o intercambio existentes. Si no está seguro, debería poder ejecutar keytool -list -keystore <keystore-path> -rfc -storepass <password> para imprimir los certificados.

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

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

    Get the certificate details from the cluster.

    Nota:

    Los certificados devueltos por el comando anterior contienen saltos de línea representados como texto; por ejemplo, \r\n. Debe copiar cada certificado en un archivo y formatearlo antes de intentar importarlo en el almacén de confianza del centro de datos existente.

    Sugerencia

    Copie el valor de matriz gossipCertificates que se muestra en la captura de pantalla anterior en un archivo y use el siguiente script de Bash (tendrá que descargar e instalar jq para la plataforma) para dar formato a los certificados y crear archivos pem independientes para cada uno.

    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

  7. A continuación, cree un nuevo centro de datos en el clúster híbrido. Asegúrese de reemplazar los valores de las variables 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

    Nota

    El valor de --sku se puede elegir entre las siguientes SKU 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

    Tenga en cuenta también que --availability-zone está establecido en false. Para habilitar las zonas de disponibilidad, establezca esta opción en true. Las zonas de disponibilidad aumentan el Acuerdo de Nivel de Servicio de disponibilidad del servicio. Para más información, revise los detalles completos del Acuerdo de Nivel de Servicio aquí.

    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.

  8. Ahora que se ha creado el nuevo centro de datos, ejecute el comando datacenter show 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

  9. El comando anterior incluye en la salida los nodos de inicialización del nuevo centro de datos:

    Screenshot of how to get datacenter details.

  10. Ahora agregue los nodos de inicialización del nuevo centro de datos a la configuración de nodos de inicialización del centro 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 mediante el comando keytool para cada certificado:

    keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass

    Nota

    Si desea agregar más centros de datos, puede repetir los pasos anteriores, pero solo necesita los nodos de inicialización.

    Importante

    Si el clúster de Apache Cassandra existente solo tiene un único centro de datos y es la primera vez que se agrega un centro de datos, asegúrese de que el parámetro endpoint_snitch en cassandra.yaml está establecido en GossipingPropertyFileSnitch.

    Importante

    Si el código de aplicación existente usa QUORUM para la coherencia, debe asegurarse de que antes de cambiar la configuración de replicación en el paso siguiente, el código de aplicación existente usa LOCAL_QUORUM para conectarse al clúster existente (de lo contrario, se producirá un error en las actualizaciones dinámicas después de cambiar la configuración de replicación en el paso siguiente). Una vez que se haya cambiado la estrategia de replicación, puede revertir a QUORUM si lo prefiere.

  11. Por último, use la siguiente consulta CQL para actualizar la estrategia de replicación de cada espacio de claves para incluir todos los centros de datos del 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}

    Importante

    Si los centros de datos del clúster existente no aplican el cifrado de cliente a nodo (SSL) y tiene previsto que el código de la aplicación se conecte directamente a Cassandra Managed Instance, también deberá habilitar 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 para configurar un clúster híbrido. Sin embargo, esta es también una excelente manera de lograr una migración sin interrupciones de tiempo de inactividad. Si tiene un entorno local u otro entorno de Cassandra que quiera retirar sin tiempo de inactividad, a favor de ejecutar la carga de trabajo en Azure Managed Instance for Apache Cassandra, debe completar los pasos siguientes en este orden:

  1. Configuración del clúster híbrido: siga las instrucciones anteriores.

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

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

  3. En la CLI de Azure, ejecute el comando siguiente para ejecutar nodetool rebuild en cada nodo del nuevo centro de datos de Azure Managed Instance for Apache Cassandra, reemplazando <ip address> por la dirección IP del nodo y <sourcedc> por el nombre del centro de datos existente (desde el 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>"=""

    Debe ejecutar esto solo después de que se hayan realizado todos los pasos anteriores. Esto debe garantizar que todos los datos históricos se repliquen en los nuevos centros de datos de Azure Managed Instance for Apache Cassandra. Puede ejecutar la recompilación en uno o varios nodos al mismo tiempo. Ejecútela en un nodo de cada vez para reducir el impacto 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 no sobrecargar el clúster.

    Advertencia

    Debe especificar el centro de datos de origen al ejecutar nodetool rebuild. Si proporciona el centro de datos incorrectamente en el primer intento, esto hará que se copien los intervalos de tokens, sin que se copien datos para las tablas que no son del sistema. Se producirá un error en los intentos posteriores incluso si proporciona correctamente el centro de datos. Para resolverlo, elimine las entradas de cada espacio de claves que no sea del sistema en system.available_ranges con la herramienta de consulta cqlsh del centro de datos de Managed Instance for Apache Cassandra de destino:

    delete from system.available_ranges where keyspace_name = 'myKeyspace';

  4. Corte el código de la aplicación para que apunte a los nodos de inicialización del nuevo centro de datos de Azure Managed Instance for Apache Cassandra.

    Importante

    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), deberá habilitarlo en el código de la aplicación, ya que Cassandra Managed Instance exige esto.

  5. Ejecute ALTER KEYSPACE para cada espacio de claves, de la misma manera que hizo anteriormente, pero ahora quitando los centros de datos antiguos.

  6. Ejecute nodetool decommision para cada nodo del centro de datos antiguo.

  7. Vuelva a cambiar el código de la aplicación al cuórum (si es necesario o preferido).

  8. Vuelva 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, 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.

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.

Pasos siguientes

En esta guía de inicio rápido, ha aprendido a crear un clúster híbrido con la CLI de Azure y Azure Managed Instance for Apache Cassandra. Ahora puede empezar a trabajar con el clúster.

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