Compartir vía


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, realizamos una compactación menor a través de la reparación (consulte Mantenimiento). Se realiza una compactación de árbol Merkle, que es un tipo especial de compactación.
  • Según la estrategia de compactación que se ha establecido en la tabla mediante CQL (por ejemplo WITH compaction = { 'class' : 'LeveledCompactionStrategy' }), Cassandra se 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 y no realizar compactaciones manuales fuera de la estrategia.

Aplicación de revisiones

  • Las revisiones de nivel de sistema operativo se realizan automáticamente con una frecuencia de aproximadamente 2 semanas.

  • Las revisiones de nivel de software de Apache Cassandra se realizan cuando se identifican vulnerabilidades de seguridad. Tenga en cuenta que la frecuencia de aplicación de las revisiones puede variar.

  • Durante la aplicación de revisiones, las máquinas se reinician de bastidor en bastidor. No debería experimentar ninguna degradación en el lado de la aplicación, siempre y cuando no se esté utilizando la opció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 la implementación de las versiones principales (X) y secundarias (Y) manualmente a través de las herramientas de servicio. Mientras que las revisiones de Cassandra (Z) que pueden ser necesarias para esa combinación de versión principal y secundaria, estas se realizan automáticamente.

Nota

El servicio admite actualmente las versiones 3.11 y 4.0 de Cassandra. Ambas versiones son de disponibilidad general. Consulte nuestro Inicio rápido de la CLI de Azure (paso 5) para especificar la versión de Cassandra durante la implementación del clúster.

Mantenimiento

  • El servicio ejecuta automáticamente la reparación de Nodetool mediante la herramienta Reaper. Esta herramienta se ejecuta una vez cada semana. Puede deshabilitarla si usa su propio servicio para realizar una implementación híbrida.

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

    • Supervisar activamente la pertenencia de cada nodo en el anillo de Cassandra.
    • Detección y mitigación automáticas de incidencias de infraestructura, como máquinas virtuales, red, almacenamiento, Linux y soporte técnico de errores de software.
    • 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:

  • Un único punto de contacto para las incidencias de infraestructura de Cassandra: no es necesario generar casos de soporte técnico con equipos de IaaS (disco, proceso, redes) por separado.
  • Asesoramiento proactivo por correo electrónico en el caso de cuellos de botella de rendimiento, ajuste de tamaño y otras incidencias 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.
  • Soporte técnico de 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

Investigaremos y diagnosticaremos los problemas notificados mediante casos de soporte técnico, y los resolveremos o mitigaremos siempre que sea posible. Sin embargo, usted es responsable en última instancia 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.

En caso de que investiguemos un caso de soporte técnico y descubramos que la causa principal del problema se encuentra en el nivel de configuración de Apache Cassandra (y no en ningún aspecto de nivel de plataforma subyacente que mantengamos), todavía proporcionaremos 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 los anteriores.

Advertencia

Azure Managed Instance for Apache Cassandra también permite ejecutar nodetoolcomandos sstablepara la administración rutinaria de DBA; consulte el artículo aquí. Algunos de estos comandos pueden desestabilizar el clúster de Cassandra y solo deben ejecutarse cuidadosamente y después de probarse en entornos que no son de producción. Siempre que sea posible, primero --dry-run se debe implementar una opción. Microsoft no puede ofrecer ningún Acuerdo de nivel de servicio ni soporte técnico en los problemas con la ejecución de comandos que modifican la configuración predeterminada de la base de datos y/o las tablas.

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 2 días (48 horas). No hay ningún costo para las 2 copias de seguridad iniciales. Se cobran las copias de seguridad adicionales, consulte los precios. Para cambiar el intervalo de copia de seguridad o el período de retención, puede editar la directiva en el portal:

Screenshot of backup schedule configuration page.

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

  1. Proporcionar el id. de la copia de seguridad que quiere restaurar en el portal. Esto se puede encontrar en el portal:

    Screenshot of backup schedule configuration page highlighting backup ID.

  2. Si no es necesaria la restauración de todo el clúster, proporcione el espacio de claves y la tabla (si procede) que se deben restaurar.

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

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

  5. 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. Tenga en cuenta que nuestro proceso de restauración predeterminado sobrescribe el espacio de claves system_auth.

Nota:

El tiempo necesario para responder a una solicitud de restauración de la copia de seguridad dependerá de la gravedad del caso de soporte técnico que genere (y del tiempo de respuesta correspondiente del Acuerdo de Nivel de Servicio) y de la cantidad de datos que se van a restaurar. Sin embargo, no proporcionamos un Acuerdo de Nivel de Servicio del tiempo en completar la restauración, ya que depende mucho del volumen de datos que se vayan a restaurar.

Advertencia

Las copias de seguridad están pensadas para escenarios de eliminación accidental y no tienen redundancia geográfica. Por lo tanto, no se recomienda su uso como estrategia de recuperación ante desastres (DR) en caso de una interrupción regional total. Para protegerse frente a interrupciones en toda la región, se recomienda una implementación en varias regiones. Eche un vistazo a nuestro inicio rápido para las implementaciones en varias regiones.

Seguridad

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

  • Imágenes de máquinas virtuales 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 nuestro artículo aquí.

Compatibilidad híbrida

Cuando se configura un clúster híbrido, las operaciones de Reaper automatizadas que se ejecutan en el servicio beneficiarán a todo el clúster. Esto incluye los centros de datos que no aprovisione el servicio. A parte de esto, recuerde que es su responsabilidad mantener el centro de datos local u hospedado externamente.

Pasos siguientes

Comience con uno de nuestros inicios rápidos: