Directrices operacionales de Spanner

En esta página se describen algunas de las configuraciones controladas por el usuario que pueden provocar que una interrupción de una instancia de Spanner quede excluida del acuerdo de nivel de servicio (SLA) de Spanner, que excluye las interrupciones "causadas por factores que escapan al control razonable de Google". También se ofrecen directrices sobre cómo evitar estas configuraciones.

Spanner gestiona muchos aspectos de las operaciones de la base de datos, como la división y el reequilibrio de los datos, la replicación, la conmutación por error y todas las actualizaciones de hardware y software. Puedes configurar muchos de estos comportamientos con ajustes integrados y APIs administrativas. Tus cargas de trabajo también dependen de otros componentes, además de Spanner, como tus aplicaciones y tu red. Estas configuraciones controladas por el cliente pueden aumentar el riesgo de tiempo de inactividad de la instancia, en función de la carga de la base de datos y otros parámetros de configuración.

Si tu instancia deja de estar en buen estado y Google determina que no cumple los límites operativos descritos en esta página, es posible que el tiempo de inactividad resultante no esté cubierto por el ANS de Spanner (o que no se tenga en cuenta para dicho ANS).

Configuraciones excluidas del SLA de Spanner

Las siguientes configuraciones no están incluidas en el SLA de Spanner:

  • Si tu instancia está configurada y se usa de forma que la carga de trabajo sobrecarga la instancia, no estará cubierta por el SLA.
  • El tiempo de inactividad de las instancias que se deba a acciones u omisiones voluntarias por tu parte no está cubierto por el SLA.
  • Si inhabilitas la API de Spanner u otras APIs Google Cloud que se necesitan para crear y conectarse a Spanner, no se aplicará el SLA.
  • La falta de disponibilidad de la API de Spanner como resultado de la configuración de tu red, como las reglas de proxy y de cortafuegos, no está cubierta por el SLA.
  • El SLA no cubre la falta de disponibilidad de la aplicación debido a que los clientes no están actualizados o están mal configurados. En particular, comprueba que estés usando versiones recientes del cliente con dependencias compatibles. Por ejemplo, las aplicaciones Java deben usar la lista de materiales de Google con un gestor de paquetes, como Gradle o Maven.

Te recomendamos que configures alertas y monitorización con Cloud Monitoring.

Configuraciones que deben evitarse

Para mantener la cobertura del SLA de Spanner, debes evitar las siguientes configuraciones:

  • Sobrecarga de la CPU: si la utilización de la CPU es constantemente alta, significa que la instancia no tiene el tamaño adecuado para tu carga de trabajo y es posible que no esté cubierta por el SLA. Las recomendaciones de uso de CPU de Spanner proporcionan una sobrecarga para un evento de failover, en el que los recursos de computación restantes ayudan a dar cabida al tráfico de las partes no disponibles de la instancia. Puede usar las métricas de uso de CPU de Spanner para monitorizar el uso de CPU.
  • Almacenamiento completo: Spanner solo te cobra por el almacenamiento que utilizas. Sin embargo, cada nodo o unidad de computación tiene un límite en la cantidad de almacenamiento que puede gestionar. Si tu instancia no tiene el tamaño adecuado para el almacenamiento direccionable por nodo, es posible que no esté cubierta por el SLA. Puedes usar las métricas de uso del almacenamiento de Spanner para monitorizar el uso del almacenamiento.
  • Límite de cuota: los recursos de los nodos están limitados por las cuotas por usuario. Si no solicitas aumentos de cuota con antelación, puede que se produzca una sobrecarga de recursos de computación, que no estaría cubierta por el SLA. Las solicitudes de aumento de cuota que requieren la aprobación de Google se suelen completar en un día.
  • Sesiones con aprovisionamiento insuficiente: los clientes de Spanner usan canales gRPC para comunicarse con Google Cloud endpoints para consultas y administración. Si tus entornos de cliente no proporcionan suficientes canales para admitir el volumen de solicitudes de una carga de trabajo, es posible que tus aplicaciones experimenten una latencia alta y un bajo rendimiento de solicitudes que no estén cubiertos por el SLA.
  • Sobrecarga de conexiones: muchas APIs de Spanner se pueden reintentar de forma segura en caso de que se produzca un error transitorio, como un interbloqueo de transacciones en una consulta, un problema de red o límites de frecuencia para las APIs administrativas. Si se reintenta la conexión de forma demasiado agresiva, se pueden sobrecargar las conexiones existentes, lo que puede provocar que se agoten los recursos o que se aplique un límite adicional. Es posible que el acuerdo de nivel de servicio no cubra el aumento de la latencia o la reducción del rendimiento. Para obtener más información, consulta Gestión de tiempos de espera y reintentos de clientes.
  • Sobrecarga de la unidad de disco duro (HDD): almacenamiento por niveles te permite almacenar tus datos de Spanner en una combinación de unidades de estado sólido (SSD) y unidades de disco duro (HDD). Si la carga del disco en el almacenamiento HDD alcanza el 100%, la latencia de tu instancia de Spanner aumentará significativamente y es posible que no esté cubierta por el SLA. Puedes usar las métricas de almacenamiento por niveles de Spanner para monitorizar la carga del disco.

Siguientes pasos