Compartir a través de


Operaciones de administración en 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, lo que permite la máxima flexibilidad y control cuando sea necesario.

En este artículo se definen las operaciones de administración y las características que proporciona el servicio. También se explica la separación de responsabilidades entre el equipo de soporte técnico de Azure y los clientes al mantener clústeres híbridos.

Compactación

  • Hay diferentes tipos de compactación. Actualmente, este servicio realiza una compactación menor mediante la reparación. Para obtener más información, vea Mantenimiento. Esta operación realiza una compactación del árbol Merkle, que es un tipo especial de compactación.

  • En función de la estrategia de compactación que se estableció en la tabla mediante CQL, por ejemplo WITH compaction = { 'class' : 'LeveledCompactionStrategy' }, Cassandra compacta automáticamente cuando la tabla alcanza un tamaño específico. Se recomienda seleccionar cuidadosamente una estrategia de compactación para la carga de trabajo. No realice ninguna compactación manual fuera de la estrategia.

Aplicación de revisiones

  • Las revisiones de nivel de sistema operativo se realizan automáticamente a la cadencia de dos semanas.

  • Las revisiones de nivel de software de Apache Cassandra se realizan cuando se identifican vulnerabilidades de seguridad. La cadencia de aplicación de revisiones puede variar.

  • Durante la aplicación de revisiones, las máquinas se reinician de bastidor en bastidor. No debe experimentar ninguna degradación en el lado de la aplicación siempre que no se use la configuración de cuórum ALL y el factor de replicación sea 3 o superior.

  • La versión de Apache Cassandra tiene el formato X.Y.Z. Puede controlar manualmente la implementación de versiones principales (X) y secundarias (Y) mediante herramientas de servicio. Las revisiones de Cassandra (Z) que podrían ser necesarias para esa combinación de versiones principales/secundarias se realizan automáticamente.

Nota

El servicio admite actualmente las versiones 3.11 y 4.0 de Cassandra. Ambas versiones son de disponibilidad general. Para especificar una versión de Cassandra al implementar un clúster, consulte Inicio rápido de la CLI de Azure.

Mantenimiento

  • El servicio ejecuta la reparación de nodetool mediante reaper. Esta herramienta se ejecuta una vez cada semana. Si usa su propio servicio para una implementación híbrida, puede deshabilitar el reaper.

  • La supervisión del estado del nodo consta de:

    • Supervisar activamente la pertenencia de cada nodo en el anillo de Cassandra.
    • Detección automática y omisión automática de problemas de infraestructura, como máquinas virtuales, red, almacenamiento, Linux y errores de software de soporte técnico.
    • Supervise activamente la CPU, el disco, la pérdida de cuórum y otros problemas de recursos.
    • Se muestran automáticamente los nodos con errores siempre que sea posible y se muestran manualmente los nodos en respuesta a las advertencias generadas automáticamente.

Soporte técnico

Azure Managed Instance for Apache Cassandra proporciona un Acuerdo de Nivel de Servicio para la disponibilidad de los centros de datos de un clúster administrado. Si tiene algún problema con el uso del servicio, abra una solicitud de soporte técnico en Azure Portal.

Nuestras ventajas de soporte técnico incluyen:

  • Punto de contacto único para problemas de infraestructura de Cassandra. No es necesario generar casos de soporte técnico con equipos de IaaS como disco, cómputo y redes por separado.
  • Asesoramiento proactivo por correo electrónico sobre cuellos de botella de rendimiento, dimensionamiento y otros problemas de restricción de recursos.
  • Cobertura de soporte técnico 24 x 7, lo que incluye los incidentes generados automáticamente para cualquier problema grave de interrupción.
  • Compatibilidad con revisiones aprobadas por la comunidad. Consulte Aplicación de revisiones.
  • Soporte técnico del equipo de ingeniería interno de JDK/JVM de Java.
  • Soporte técnico del sistema operativo Linux con la seguridad de la cadena de suministro de software.

Importante

Microsoft investiga y diagnostica los problemas notificados mediante el uso de casos de soporte técnico. El soporte técnico resuelve o mitiga siempre que sea posible. En última instancia, es responsable de cualquier uso de nivel de configuración de Apache Cassandra que cause problemas de CPU, disco o red.

Algunos ejemplos de estos problemas son:

  • Operaciones de consulta ineficaces.
  • Rendimiento que supera la capacidad.
  • Ingesta de datos que superan la capacidad de almacenamiento.
  • Valores de configuración de espacio de claves incorrectos.
  • Modelo de datos deficiente o estrategia de claves de partición.

Microsoft puede investigar un caso de soporte técnico y detectar que la causa del problema está en el nivel de configuración de Apache Cassandra. Este problema no procede de ningún aspecto de nivel de plataforma subyacente que Azure mantenga. El soporte técnico todavía proporciona recomendaciones e instrucciones sobre la corrección, o mitigación cuando sea posible, antes de cerrar el caso.

Se recomienda habilitar las métricas y familiarizarse con la integración de Azure Monitor para evitar problemas comunes de nivel de configuración o aplicación en Apache Cassandra, como se ha descrito anteriormente.

Advertencia

Azure Managed Instance para Apache Cassandra también le permite ejecutar comandos nodetool y sstable para la administración rutinaria de DBA. Para más información, consulte Comandos DBA para Azure Managed Instance para Apache Cassandra.

Algunos de estos comandos pueden desestabilizar el clúster de Cassandra. Debe ejecutar estos comandos cuidadosamente y después de probarlos en entornos que no son de producción. Siempre que sea posible, use primero una --dry-run opción. Microsoft no ofrece ningún Acuerdo de Nivel de Servicio ni compatibilidad con problemas con la ejecución de comandos que modifican la configuración o las tablas predeterminadas de la base de datos.

Copia de seguridad y restauración

Las copias de seguridad de instantáneas están habilitadas de manera predeterminada y se toman cada 24 horas. Las copias de seguridad se almacenan en una cuenta interna de Azure Blob Storage y se conservan durante un máximo de dos días (48 horas). No hay ningún costo para las dos copias de seguridad iniciales. Se cobran copias de seguridad adicionales. Consulte Precios. Para cambiar el intervalo de copia de seguridad o el período de retención, puede editar la directiva en Azure Portal:

Recorte de pantalla de la página de la configuración de programación de copia de seguridad.

Para restaurar desde una copia de seguridad, abra una solicitud de soporte técnico en Azure Portal. Al presentar un caso de soporte técnico, debe hacer lo siguiente:

  1. Proporcionar el id. de la copia de seguridad que quiere restaurar en el portal. Puede encontrar este identificador en Azure Portal:

    Recorte de pantalla de la página de configuración de programación de copia de seguridad que resalta el identificador de copia de seguridad.

  2. Háganos saber si se eliminó el centro de datos de origen. Este hecho es importante para identificar la cuenta de copia de seguridad correcta desde la que se va a restaurar.

  3. Si no necesita restaurar todo el clúster, proporcione el espacio de claves y la tabla, si procede, que debe restaurarse.

  4. Indicar si quiere que la copia de seguridad se restaure en el clúster existente o en uno nuevo.

  5. Si quiere restaurarla en un nuevo clúster, primero debe crearlo. Asegúrese de que el clúster de destino coincide con el clúster de origen en términos del número de centros de datos. Compruebe que el centro de datos correspondiente tiene el mismo número de nodos. También puede decidir si desea conservar las credenciales en el nuevo clúster de destino. También puede permitir la restauración para invalidar el nombre de usuario y la contraseña con lo que se creó originalmente.

  6. Además, puede decidir si quiere mantener el espacio de claves system_auth en el nuevo clúster de destino o permitir que la restauración lo sobrescriba con datos de la copia de seguridad. El espacio de claves system_auth de Cassandra contiene datos de autenticación internos y de autorización, incluidos roles, permisos de rol y contraseñas. El proceso de restauración predeterminado sobrescribe el system_auth keyspace.

Nota

El tiempo necesario para responder a una solicitud de restauración a partir de la copia de seguridad depende de la gravedad del caso de soporte técnico que genere, el Acuerdo de Nivel de Servicio para el tiempo de respuesta y la cantidad de datos que se van a restaurar. No proporcionamos un SLA para el tiempo necesario para completar la restauración. Ese valor depende del tiempo y del volumen de datos que se va a restaurar.

Advertencia

Las copias de seguridad están diseñadas para escenarios de eliminación accidental y no tienen redundancia geográfica. No se recomiendan copias de seguridad para su uso como estrategia de recuperación ante desastres (DR) para la interrupción regional. Para proteger contra interrupciones regionales, se recomienda una implementación en varias regiones. Para más información, consulte inicio rápido para implementaciones de varias regiones.

Seguridad

Azure Managed Instance for Apache Cassandra proporciona muchos controles y características de seguridad explícitos integrados:

  • Imágenes endurecidas de máquina virtual Linux con una cadena de suministro controlada.
  • Supervisión común de vulnerabilidades y exposición (CVE) en el nivel de sistema operativo.
  • Rotación de certificados para el software Apache Cassandra y Prometheus hospedados en la instancia de Virtual Machines administrada.
  • Examen de vulnerabilidades activo.
  • Examen de virus activo.
  • Prácticas de codificación seguras.

Para más información sobre las características de seguridad, consulte Seguridad en Azure Managed Instance para Apache Cassandra.

Compatibilidad híbrida

Cuando se configura un clúster híbrido , las operaciones de reaper automatizadas que se ejecutan en el servicio benefician a todo el clúster. Este aspecto incluye centros de datos que el servicio no aprovisiona. Es responsabilidad suya mantener el centro de datos local o hospedado externamente.