Couchbase Operador autónomo versión 1.1.0 fue publicado el 15 de noviembre de 2018. Para el equipo de Kubernetes es una versión pequeña pero importante para mejorar la experiencia del usuario final. En este post vamos a hacer doble clic en los detalles de lo que se ha cambiado y por qué.
Servicios con estado y volúmenes persistentes
La versión 1.0.0 de Operador Autónomo permitía que los servidores de un grupo específico de escalado de servidores estuvieran respaldados por almacenamiento persistente. La compatibilidad con el almacenamiento persistente es esencial por muchas razones.
Los datos son la savia de una base de datos, y nosotros nos los tomamos en serio. Registran quiénes son sus clientes, sus preferencias para promociones específicas, sus transacciones y multitud de otras informaciones críticas para el negocio. Si se pierden esos datos, la empresa puede sufrir consecuencias negativas, desde sanciones económicas hasta la pérdida de confianza de los consumidores.
La plataforma Kubernetes que gestiona el Operador se basa, por diseño, en recursos efímeros que solo están disponibles mientras se ejecuta el proceso que los requiere. Sin embargo, Kubernetes proporciona volúmenes de almacenamiento persistentes que permiten a las aplicaciones con estado, como la plataforma de datos Couchbase, restaurar los datos en caso de que un proceso del servidor se bloquee o se elimine accidentalmente.
Buenas prácticas
Recomendamos encarecidamente que todos los grupos de escalado que contengan datos de documentos o servicios de índice utilicen almacenamiento persistente. Al hacerlo, los datos no se pierden debido a un fallo y están disponibles para una instancia de servidor de reemplazo. Todo el clúster se puede restaurar desde una pérdida total de energía, lo que no es posible sin un almacenamiento persistente para registrar el estado del clúster. La recuperación tras un fallo es mucho más rápida, ya que el servidor de sustitución puede reutilizar los datos e índices de documentos existentes, recuperando de las réplicas el pequeño subconjunto de datos que se ha modificado en el ínterin. Como efecto secundario, los registros se conservan en el mismo volumen persistente que permite la recuperación, lo que permite diagnosticar y solucionar la causa raíz del fallo.
Algunos grupos de escalado de servidores, como los que sólo ejecutan el servicio de consulta, no dependen del almacenamiento persistente para un funcionamiento fiable. Estos servicios utilizan el estado proporcionado por los servicios de datos e índices servidos por otros nodos. Como resultado, no es necesario que los servidores sin estado utilicen almacenamiento persistente. Sin persistencia, los registros del servidor no pueden recuperarse si un servidor sin estado se bloquea.
La versión 1.1.0 de Autonomous Operator resuelve este problema permitiendo adjuntar un volumen de registro ligero a los servidores.
Mejoras en la recogida de registros
En caso de caída de un servidor, el volumen de registro es detectado como huérfano por el Operador y retenido para la recogida de registros. La dirección cbopinfo ha sido mejorada para detectar estos volúmenes de registro y presentarlos en el momento de la recogida de registros. La herramienta de soporte recopila de forma selectiva los registros del servidor Couchbase de los volúmenes de registro persistentes y los descarga automáticamente en la máquina local que ejecuta el comando.
La herramienta de asistencia ahora redacta los registros del servidor de información potencialmente sensible. El usuario tiene a su disposición tanto los registros redactados como los sin redactar. El usuario final puede elegir qué versión desea enviar a nuestro equipo de asistencia.
Mejoras en la conservación de registros
Operator incorpora una nueva política de retención de registros que el administrador del clúster puede controlar suficientemente para limitar el uso de recursos. Operator admite la retención de registros en función del número máximo de volúmenes de registro permitidos (los volúmenes más antiguos se eliminan primero si el número existente supera este valor) o en función del valor duración del volumen huérfano. Las políticas de retención de registros evitan el uso excesivo de recursos y también ayudan al administrador a cumplir la legislación sobre retención de datos.
Mejoras en la gestión de clústeres
La herramienta de gestión de clusters, cbopctl también se ha actualizado para ayudar a los usuarios finales a desplegar clústeres compatibles. La presencia del por defecto o Registros montajes de volumen en cualquier grupo de escalado de servidores señala la intención de que el usuario final desea que el clúster sea compatible. Estos montajes de volumen no pueden especificarse al mismo tiempo. Además, cbopctl impone que todos los grupos de escalado de servidores sean compatibles si se pretende, y los registros siempre estarán disponibles para su recopilación por parte de cbopinfo. Por último, el Registros no se puede utilizar en grupos de escalado que contengan el archivo datos, índice o análisis servicios. Esto ayuda a prevenir escenarios de pérdida de datos forzando el uso de por defecto montajes de volumen que el Operador puede recuperar.
La herramienta de gestión de clústeres aún permite al usuario crear clústeres sin ningún tipo de respaldo de volumen persistente para su evaluación. Como se ha descrito, en esta configuración el clúster no puede sobrevivir a un corte de energía, puede resultar en la pérdida de datos y los problemas pueden ser insostenibles debido a la ausencia de registros del servidor Couchbase.
Enlaces útiles
- Documentación actualizada sobre buenas prácticas
- Documentación de la herramienta de soporte Couchbase Autonomous Operator
- Documentación de la herramienta de gestión Couchbase Autonomous Operator
