Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube

Last reviewed 2024-05-10 UTC

Este artículo forma parte de una serie en la que se analiza la recuperación ante desastres (DR) en Google Cloud. En esta parte, se analiza el proceso para diseñar cargas de trabajo con Google Cloud y bloques de construcción que sean resilientes a las interrupciones de la infraestructura de la nube.

La serie consta de estas partes:

Introducción

A medida que las empresas trasladan las cargas de trabajo a la nube pública, deben trasladar su conocimiento sobre la compilación de sistemas resilientes en las instalaciones a la infraestructura de hiperescala de los proveedores de servicios en la nube, como Google Cloud. En este artículo, se asignan los conceptos estándar de la industria sobre la recuperación ante desastres, como el RTO (objetivo de tiempo de recuperación) y el RPO (objetivo de punto de recuperación), a la infraestructura de Google Cloud.

La orientación de este documento sigue uno de los principios clave de Google para lograr una disponibilidad de servicio muy alta: planificar la falla. Si bienGoogle Cloud ofrece un servicio muy confiable, ocurrirán desastres naturales, cortes de fibra y errores complejos de infraestructura; estos pueden causar interrupciones. La planificación de interrupciones permite a los clientes deGoogle Cloud compilar aplicaciones que funcionen de manera predecible durante estos eventos inevitables, ya que usan productos de Google Cloud con mecanismos de DR “integrados”.

La recuperación ante desastres es un tema amplio que cubre mucho más que las fallas de infraestructura, como los errores de software o la corrupción de datos, y debes tener un plan integral de extremo a extremo. Sin embargo, este artículo se centra en una parte de un plan de DR general: cómo diseñar aplicaciones que sean resilientes a las interrupciones de la infraestructura de nube. En concreto, se explica lo siguiente:

  1. La infraestructura de Google Cloud , cómo los eventos de desastre se manifiestan como fallas deGoogle Cloud y cómo Google Cloud está diseñado para minimizar la frecuencia y el alcance de las interrupciones.
  2. Una guía de planificación de la arquitectura que proporciona un framework para categorizar y diseñar aplicaciones según los resultados de confiabilidad deseados
  3. Una lista detallada de productos seleccionados de Google Cloud que ofrecen capacidades de DR integradas que podrías usar en tu aplicación.

Para obtener más detalles sobre la planificación general de DR y el uso de Google Cloud como un componente en tu estrategia de DR en las instalaciones, consulta la guía de planificación de recuperación ante desastres. Además, si bien la alta disponibilidad es un concepto muy relacionado con la recuperación ante desastres, no se aborda en este artículo. Para obtener más detalles sobre la arquitectura para la alta disponibilidad, consulta el marco de trabajo de arquitectura deGoogle Cloud .

Nota sobre la terminología: Este artículo hace referencia a la disponibilidad cuando se describe la capacidad de un producto de que se acceda a él de manera significativa y se use a lo largo del tiempo, mientras que la confiabilidad se refiere a un conjunto de atributos que incluye la disponibilidad, además de funciones como la durabilidad y la corrección.

Cómo Google Cloud está diseñado para la resiliencia

Centros de datos de Google

Los centros de datos tradicionales se basan en maximizar la disponibilidad de componentes individuales. En la nube, la escala permite a operadores como Google distribuir servicios en muchos componentes mediante tecnologías de virtualización y, por lo tanto, superar la confiabilidad tradicional de los componentes. Esto significa que puedes dejar de enfocar la mentalidad de la arquitectura de confiabilidad en los innumerables detalles que te preocupaban en las instalaciones locales. En lugar de preocuparte por los distintos modos de falla de los componentes, como el enfriamiento y la entrega de energía, puedes planificar en torno a los productos de Google Cloud y sus métricas de confiabilidad indicadas. Estas métricas reflejan el riesgo de interrupción agregado de toda la infraestructura subyacente. De esta manera, puedes enfocarte mucho más en el diseño, la implementación y las operaciones de la aplicación en lugar de la administración de infraestructura.

Google diseña su infraestructura para cumplir con los objetivos de disponibilidad agresivos en función de nuestra vasta experiencia en el desarrollo y la ejecución de centros de datos modernos. Google es uno de los líderes mundiales en el diseño de centros de datos. Desde la energía hasta el enfriamiento y las redes, cada tecnología de los centros de datos tiene sus propias redundancias y mitigaciones, incluidos los planes de FMEA. Los centros de datos de Google se crean de una manera que equilibra estos muchos riesgos diferentes y les presenta a los clientes un nivel de disponibilidad esperado y coherente para los productos de Google Cloud . Google usa su experiencia para modelar la disponibilidad de la arquitectura general del sistema físico y lógico a fin de garantizar que el diseño del centro de datos cumpla con las expectativas. Los ingenieros de Google hacen grandes esfuerzos operativos para garantizar que se cumplan esas expectativas. Es normal que la disponibilidad real exceda nuestros objetivos de diseño por un margen amplio.

Cuando se destilan todos estos riesgos y mitigaciones del centro de datos en productos para usuarios, Google Cloud te libera de esas responsabilidades de diseño y operativas. En cambio, puedes enfocarte en la confiabilidad integrada en el diseño de las regiones y las zonas deGoogle Cloud .

Regiones y zonas

Las regiones son áreas geográficas independientes que constan de zonas. Las zonas y las regiones son abstracciones lógicas de los recursos físicos subyacentes. Para obtener más información sobre las consideraciones específicas de cada región, consulta Geografía y regiones.

Los productos deGoogle Cloud se dividen en recursos zonales, regionales o multirregionales.

Los recursos zonales se alojan en una sola zona. Una interrupción del servicio en esa zona puede afectar a todos los recursos de esa zona. Por ejemplo, una instancia de Compute Engine se ejecuta en una zona única y especificada. Si una falla de hardware interrumpe el servicio en esa zona, esa instancia de Compute Engine no estará disponible mientras dure la interrupción.

Los recursos regionales se implementan de forma redundante en varias zonas dentro de una región. Esto les brinda mayor confiabilidad en comparación con los recursos zonales.

Los recursos multirregionales se distribuyen dentro de las regiones y entre ellas. En general, los recursos multirregionales son más confiables que los regionales. Sin embargo, a este nivel, los productos deben optimizar la disponibilidad, el rendimiento y la eficiencia de los recursos. Como resultado, es importante comprender las compensaciones de cada producto multirregional que decidas usar. Estas compensaciones se documentan de forma específica para cada producto más adelante en este documento.

Ejemplos de productos de Google Cloud zonales, regionales y multirregionales

Cómo aprovechar las zonas y las regiones para lograr la confiabilidad

Las SRE de Google administran y escalan productos para usuarios globales de alta confiabilidad, como Gmail y Búsqueda, mediante una variedad de técnicas y tecnologías que aprovechan sin problemas la infraestructura de procesamiento en todo el mundo. Esto incluye el redireccionamiento del tráfico desde ubicaciones no disponibles mediante el balanceo de cargas global, la ejecución de varias réplicas en varias ubicaciones en todo el planeta y la replicación de datos en distintos lugares. Estas mismas funciones están disponibles para los clientes de Google Cloud a través de productos como Cloud Load Balancing, Google Kubernetes Engine (GKE) y Spanner.

Google Cloud , por lo general, diseña productos para ofrecer los siguientes niveles de disponibilidad para zonas y regiones:

Recurso Ejemplos Objetivo del diseño de disponibilidad Tiempo de inactividad implícito
Zonal Compute Engine, Persistent Disk 99.9% 8.75 horas al año
Regional Cloud Storage regional, Persistent Disk replicado, GKE regional 99.99% 52 minutos al año

Compara los objetivos del diseño de disponibilidad de Google Cloud con el nivel aceptable de tiempo de inactividad para identificar los recursos apropiados de Google Cloud . Si bien los diseños tradicionales se enfocan en mejorar la disponibilidad a nivel del componente para mejorar la disponibilidad resultante de la aplicación, los modelos de la nube se enfocan en la composición de los componentes a fin de lograr este objetivo. Muchos productos deGoogle Cloud usan esta técnica. Por ejemplo, Spanner ofrece una base de datos multirregional que compone varias regiones para entregar una disponibilidad del 99.999%.

La composición es importante porque, sin ella, la disponibilidad de tu aplicación no puede superar la de los productos de Google Cloud que usas. De hecho, a menos que tu aplicación nunca falle, tendrá una disponibilidad más baja que los productos subyacentes de Google Cloud . En el resto de esta sección, se muestra cómo puedes usar una composición de productos zonales y regionales para lograr una mayor disponibilidad de la aplicación que la que proporcionan una sola zona o región. En la próxima sección, se proporciona una guía práctica para aplicar estos principios a tus aplicaciones.

Planifica los alcances de interrupción de zonas

Las fallas de infraestructura suelen causar interrupciones del servicio en una sola zona. Dentro de una región, las zonas están diseñadas para minimizar el riesgo de fallas correlacionadas con otras zonas, y una interrupción del servicio en una zona no suele afectar el servicio desde otra zona en la misma región. Una interrupción con alcance a una zona no siempre implica que toda la zona no esté disponible; solo define el límite del incidente. Es posible que una interrupción zonal no tenga ningún efecto tangible en los recursos específicos de esa zona.

Es un caso menos frecuente, pero también es importante tener en cuenta que varias zonas, en algún momento, experimentarán una interrupción correlacionada en una sola región. Cuando dos o más zonas experimentan una interrupción, se aplica la estrategia de alcance de la interrupción regional que aparece a continuación.

Los recursos regionales están diseñados para ser resistentes a las interrupciones zonales mediante la entrega del servicio desde una composición de varias zonas. Si se interrumpe una de las zonas que respaldan un recurso regional, el recurso queda disponible de manera automática desde otra zona. Revisa con cuidado la descripción de la capacidad del producto en el apéndice para obtener más detalles.

Google Cloud solo ofrece algunos recursos zonales, como las máquinas virtuales (VM) de Compute Engine y Persistent Disk. Si planeas usar recursos zonales, deberás realizar tu propia composición de recursos mediante el diseño, la compilación y la prueba de la conmutación por error y la recuperación entre recursos zonales ubicados en varias zonas. Estas son algunas de las estrategias:

  • Enrutar con rapidez el tráfico a máquinas virtuales en otra zona mediante Cloud Load Balancing cuando una verificación de estado determina que una zona tiene problemas
  • Usar plantillas de instancias o grupos de instancias administrados de Compute Engine para ejecutar y escalar instancias de VM idénticas en varias zonas
  • Usar Persistent Disk regional para replicar de forma síncrona los datos en otra zona de una región. Consulta Opciones de alta disponibilidad con PD regionales para obtener más detalles.

Planifica los alcances de interrupción regional

Una interrupción regional es una interrupción del servicio que afecta a más de una zona en una sola región. Estas son interrupciones más grandes y menos frecuentes, y pueden ser consecuencia de desastres naturales o fallas en la infraestructura a gran escala.

Si un producto regional está diseñado para proporcionar una disponibilidad del 99.99%, una interrupción puede traducirse a casi una hora de inactividad para un producto específico cada año. Por lo tanto, es posible que tus aplicaciones esenciales necesiten contar con un plan de DR multirregional si no esta duración de interrupción es inaceptable.

Los recursos multirregionales están diseñados para ser resistentes a las interrupciones regionales mediante la entrega del servicio en varias regiones. Como se describió antes, los productos multirregionales compensan la latencia, la coherencia y el costo. La compensación más común se da entre la replicación de datos síncrona y la replicación asíncrona. La replicación asíncrona ofrece menos latencia al costo de riesgo de pérdida de datos durante una interrupción. Por lo tanto, es importante verificar la descripción de la capacidad del producto en el apéndice para obtener más detalles.

Si quieres usar recursos regionales y seguir siendo resiliente ante las interrupciones regionales, debes diseñar tu propia composición de recursos. Para ello, diseña, compila y prueba la conmutación por error y la recuperación entre los recursos regionales ubicados en varias regiones. Además de las estrategias zonales anteriores, que también puedes aplicar a otras regiones, ten en cuenta lo siguiente:

  • Los recursos regionales deben replicar los datos en una región secundaria, en una opción de almacenamiento multirregional, como Cloud Storage, o en una opción de nube híbrida, como GKE Enterprise.
  • Una vez que tengas una mitigación regional ante interrupciones, pruébala con frecuencia. Si hay algo peor que pensar que eres resistente a una interrupción de una sola región, es descubrir que ese no es el caso cuando ocurre de verdad.

Enfoque de resiliencia y disponibilidad deGoogle Cloud

Google Cloud supera con frecuencia sus objetivos de diseño de disponibilidad, pero no debes asumir que este sólido rendimiento anterior es la disponibilidad mínima para la que puedes diseñar. En su lugar, debes seleccionar dependencias de Google Cloud cuyos objetivos de diseño superen la confiabilidad prevista de tu aplicación, de modo que el tiempo de inactividad de tu aplicación más el tiempo de inactividad de Google Cloud proporcione el resultado que buscas.

Un sistema bien diseñado puede responder la pregunta “¿Qué sucede cuando una zona o región tiene una interrupción de 1, 5, 10 o 30 minutos?” Esto se debe tener en cuenta en muchas capas, incluidas las siguientes:

  • ¿Qué experimentarán mis clientes durante una interrupción?
  • ¿Cómo detecto que hay una interrupción en curso?
  • ¿Qué sucede con mi solicitud durante una interrupción?
  • ¿Qué sucede con mis datos durante una interrupción?
  • ¿Qué le sucede a mis otras aplicaciones como consecuencia de una interrupción (debido a las dependencias cruzadas)?
  • ¿Qué debo hacer para recuperarme después de que se resuelve una interrupción? ¿Quién lo hace?
  • ¿A quién debo notificar sobre una interrupción? ¿En qué período?

Guía paso a paso para diseñar la recuperación ante desastres de aplicaciones en Google Cloud

En las secciones anteriores, se explicó cómo Google compila la infraestructura de nube y algunos enfoques para abordar las interrupciones zonales y regionales.

En esta sección, te ayudamos a desarrollar un framework para aplicar el principio de composición a tus aplicaciones en función de los resultados de confiabilidad deseados.

Las aplicaciones de los clientes en Google Cloud que se orientan a objetivos de recuperación ante desastres, como el RTO y el RPO, deben tener una arquitectura de modo que las operaciones fundamentales para el negocio, sujetas al RTO o al RPO, solo tengan dependencias en los componentes del plano de datos que son responsables del procesamiento continuo de las operaciones del servicio. En otras palabras, estas operaciones fundamentales para el cliente no deben depender de las operaciones del plano de administración, que administran el estado de configuración y la configuración de envío al plano de control y al plano de datos.

Por ejemplo,los clientes de Google Cloud que deseen lograr el RTO para operaciones fundamentales no deben depender de una API de creación de VM o de la actualización de un permiso de IAM.

Paso 1: Reúne los requisitos existentes

El primer paso es definir los requisitos de disponibilidad para tus aplicaciones. La mayoría de las empresas ya tienen algún nivel de orientación de diseño en este espacio, que se puede desarrollar de forma interna o derivar de leyes u otros requisitos legales. En general, esta guía de diseño se codifica en dos métricas clave: el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). En términos comerciales, el RTO se traduce como “cuánto tiempo transcurre después de un desastre hasta que vuelvo a estar activo y listo para ejecutar”. El RPO se traduce como “cuántos datos puedo perder si ocurre un desastre”.

Una escala que muestra el tiempo El evento está en el medio. En el extremo izquierdo, aparece el RPO con las palabras “Se pierden estas escrituras” (These writes are lost). En el extremo derecho, aparece el RTO con las palabras “Se reanuda el servicio normal” (Normal service resumes).

A lo largo de la historia, las empresas definieron los requisitos de RTO y RPO para un rango amplio de eventos de desastres, desde fallas de componentes hasta terremotos. Esto tenía sentido en el mundo local en el que los planificadores debían asignar los requisitos de RTO y RPO a través de toda la pila de software y hardware. En la nube, ya no necesitas definir tus requisitos con tanto detalles porque el proveedor se encarga de eso. En cambio, puedes definir tus requisitos de RTO y RPO en términos del alcance de la pérdida (zonas o regiones completas) sin especificar los motivos subyacentes. En el caso de Google Cloud , esto simplifica la recopilación de requisitos a 3 situaciones: una interrupción zonal, una interrupción regional o una interrupción extremadamente improbable de varias regiones.

Ya que se reconoce que no todas las aplicaciones tienen la misma importancia, la mayoría de los clientes clasifican sus aplicaciones en niveles de importancia, en los que se puede aplicar un requisito específico de RTO y RPO. Cuando se combinan, el RTO, el RPO y la importancia de la aplicación optimizan el proceso de diseñar la arquitectura de una aplicación determinada y dan respuesta a las siguientes preguntas:

  1. ¿La aplicación debe ejecutarse en varias zonas en la misma región o en varias zonas en varias regiones?
  2. ¿De qué productos de Google Cloud puede depender la aplicación?

Este es un ejemplo del resultado del ejercicio de recopilación de requisitos:

El RTO y el RPO por importancia de la aplicación para la organización de ejemplo:

Importancia de la aplicación % de apps Apps de ejemplo Interrupción zonal Interrupción regional
Nivel 1

(más importante)

5% Por lo general, aplicaciones globales y externas orientadas al cliente, como los pagos en tiempo real y las vidrieras de comercio electrónico. RTO de cero

RPO de cero

RTO de cero

RPO de cero

Nivel 2 35% Por lo general, aplicaciones regionales o las aplicaciones internas importantes como CRM o ERP. RTO de 15 min

RPO de 15 min

RTO de 1 h

RPO de 1 h

Nivel 3

(menos importante)

60% Por lo general, las aplicaciones de equipos o departamentos, como la oficina administrativa, las reservas, los viajes internos, la contabilidad y el departamento de RR.HH. RTO de 1 h

RPO de 1 h

RTO de 12 horas

RPO de 12 h

Paso 2: Asignación de capacidades a los productos disponibles

El segundo paso es comprender las capacidades de resiliencia de los productos de Google Cloudque usarán tus aplicaciones. La mayoría de las empresas revisan la información relevante de los productos y, luego, agregan orientación sobre cómo modificar las arquitecturas a fin de adaptarse a las brechas entre las capacidades de los productos y los requisitos de resiliencia. En esta sección, se abarcan algunas áreas comunes y recomendaciones sobre las limitaciones de datos y aplicaciones en este espacio.

Como se mencionó antes, los productos habilitados para DR de Google están pensados, a grandes rasgos, para dos tipos de alcances de interrupción: regional y zonal. Cuando se trata de DR, se debe planificar de la misma manera para las interrupciones parciales y las interrupciones totales. Esto brinda una matriz inicial de alto nivel de qué productos son adecuados para cada situación de forma predeterminada:

Google Cloud Funciones generales del producto
(consulta el Apéndice para ver las funciones específicas del producto)

Todos los productos de Google Cloud Productos regionales de Google Cloud con replicación automática entre zonas Productos de Google Cloud multirregionales o globales con replicación automática en todas las regiones
Error de un componente dentro de una zona Cubierto* Cubierto Cubierto
Interrupción zonal No cubierto Cubierto Cubierto
Interrupción regional No cubierto No cubierto Cubierto

* Todos los productos de Google Cloud son resistentes a fallas de componentes, excepto en casos específicos que se indican en la documentación del producto. Por lo general, son situaciones en las que el producto ofrece acceso directo o asignación estática a un hardware de especialidad, como la memoria o los discos de estado sólido (SSD).

Cómo el RPO limita las opciones de producto

En la mayoría de las implementaciones de nube, la integridad de los datos es el aspecto más significativo desde el punto de vista arquitectónico para un servicio. Al menos algunas aplicaciones tienen un requisito de RPO de cero, lo que significa que no se deberían perder datos en caso de que ocurra una interrupción. Por lo general, esto requiere que los datos se repliquen de forma síncrona en otra zona o región. La replicación síncrona tiene compensaciones de costo y latencia, por lo que, si bien muchos productos de Google Cloud proporcionan replicación síncrona en todas las zonas, solo unos pocos lo hacen en todas las regiones. Esta compensación entre el costo y la complejidad significa que no es inusual que diferentes tipos de datos dentro de una aplicación tengan diferentes valores de RPO.

En los datos con un RPO mayor que cero, las aplicaciones pueden aprovechar la replicación asíncrona. La replicación asíncrona es aceptable cuando los datos perdidos se pueden volver a crear con facilidad o se pueden recuperar de una fuente de datos dorada si es necesario. También puede ser una opción razonable cuando una pequeña pérdida de datos es una compensación aceptable en el contexto de las duraciones previstas para las interrupciones zonales y regionales. También es relevante que, durante una interrupción transitoria, los datos escritos en la ubicación afectada, pero que aún no se replicaron en otra ubicación, por lo general estén disponibles después de que se resuelva la interrupción. Esto significa que el riesgo de pérdida permanente de los datos es menor que el riesgo de perder el acceso a los datos durante una interrupción.

Acciones clave: Determina si realmente necesitas un RPO de cero y, si es así, si puedes hacerlo para un subconjunto de datos; esto aumenta de forma notable el rango de servicios habilitados para DR disponibles. En Google Cloud, lograr un RPO cero significa usar principalmente productos regionales para tu aplicación, que de forma predeterminada son resilientes a las interrupciones a escala de zona, pero no a escala de región.

Cómo el RTO limita las opciones del producto

Uno de los principales beneficios de la computación en la nube es la capacidad de implementar la infraestructura a pedido. Sin embargo, no es lo mismo que la implementación instantánea. El valor de RTO de tu aplicación debe adaptarse al RTO combinado de los productos de Google Cloud que utiliza tu aplicación y a cualquier acción que tus ingenieros o SRE deban realizar para reiniciar tus VMs o componentes de la aplicación. Un RTO medido en minutos significa diseñar una aplicación que se recupere de forma automática de un desastre sin intervención humana o con pasos mínimos, como presionar un botón para una conmutación por error. Históricamente, el costo y la complejidad de este tipo de sistema han sido muy altos, pero los productos de Google Cloud , como los equilibradores de carga y los grupos de instancias, hacen que este diseño sea mucho más asequible y sencillo. Por lo tanto, debes tener en cuenta la conmutación por error y la recuperación automatizadas para la mayoría de las aplicaciones. Ten en cuenta que diseñar un sistema para este tipo de conmutación por error en caliente en todas las regiones es complicado y costoso; solo una fracción muy pequeña de los servicios importantes justifican esta capacidad.

La mayoría de las aplicaciones tendrá un RTO de entre una hora y un día, lo que permite una conmutación por error cálida en una situación de desastre, con algunos componentes de la aplicación que se ejecutan todo el tiempo en modo de espera, como las bases de datos, mientras que otros se escalan horizontalmente durante un desastre real, como los servidores web. En el caso de estas aplicaciones, debes considerar la automatización para los eventos de escalamiento horizontal. Los servicios con un RTO de más de un día son los de menor importancia y a menudo se pueden recuperarse desde una copia de seguridad o volver a crearse desde cero.

Acciones clave: Determina si en verdad necesitas un RTO de (alrededor de) cero para la conmutación por error regional y, de ser así, si puedes hacerlo para un subconjunto de los servicios. Esto cambia el costo de ejecutar y mantener tu servicio.

Paso 3: Desarrolla tus propias arquitecturas y guías de referencia

El último paso recomendado es compilar tus propios patrones de arquitectura específicos de la empresa para ayudar a tus equipos a estandarizar su enfoque sobre la recuperación ante desastres. La mayoría de los clientes de Google Cloud producen una guía para sus equipos de desarrollo que hace coincidir sus expectativas individuales de resiliencia empresarial con las dos categorías principales de interrupciones en Google Cloud. Esto permite que los equipos clasifiquen con facilidad qué productos habilitados para DR son adecuados en cada nivel de importancia.

Crea lineamientos para productos

La tabla de RTO y RPO de ejemplo anterior es una guía hipotética que detalla qué productos se permitirían de forma predeterminada para cada nivel de importancia. Ten en cuenta que, de forma predeterminada, ciertos productos se identificaron como no adecuados. Siempre puedes agregar tus propios mecanismos de replicación y conmutación por error para habilitar la sincronización entre zonas o regiones, pero este ejercicio está más allá del alcance de este artículo. En las tablas, también encontrarás vínculos a más información sobre cada producto para ayudarte a comprender sus capacidades en relación con la administración de las interrupciones zonales y regionales.

Patrones de arquitectura de muestra para la organización de ejemplo: Resiliencia para las interrupciones zonales:

Producto deGoogle Cloud ¿El producto cumple con los requisitos de interrupción zonal para la organización de ejemplo (con la configuración adecuada del producto)?
Nivel 1 Nivel 2 Nivel 3
Compute Engine No No No
Dataflow No No No
BigQuery No No
GKE
Cloud Storage
Cloud SQL No
Spanner
Cloud Load Balancing

Esta tabla es un ejemplo basado solo en los niveles hipotéticos descritos con anterioridad.

Patrones de arquitectura de muestra para la organización de ejemplo: Resiliencia para las interrupciones regionales:

Producto deGoogle Cloud ¿El producto cumple con los requisitos de interrupción regional para la organización de ejemplo (con la configuración adecuada del producto)?
Nivel 1 Nivel 2 Nivel 3
Compute Engine
Dataflow No No No
BigQuery No No
GKE
Cloud Storage No No No
Cloud SQL No
Spanner
Cloud Load Balancing

Esta tabla es un ejemplo basado solo en los niveles hipotéticos descritos con anterioridad.

A fin de mostrar cómo se usarían estos productos, en las siguientes secciones, se explican algunas arquitecturas de referencia para cada uno de los niveles hipotéticos de importancia de la aplicación. Estas son descripciones de alto nivel hechas de manera deliberada para explicar las decisiones clave de la arquitectura y no representan un diseño de solución completo.

Arquitectura de ejemplo de nivel 3

Importancia de la aplicación Interrupción zonal Interrupción regional
Nivel 3
(menos importante)
RTO de 12 horas
RPO de 24 horas
RTO de 28 días
RPO de 24 horas

Una arquitectura de ejemplo de nivel 3 que usa productos de Google Cloud

(Los íconos en gris muestran la infraestructura que se habilitará para permitir la recuperación)

En esta arquitectura, se describe una aplicación tradicional de cliente y servidor: los usuarios internos se conectan a una aplicación que se ejecuta en una instancia de procesamiento respaldada por una base de datos para el almacenamiento continuo.

Es importante tener en cuenta que esta arquitectura admite valores de RTO y RPO superiores a los necesarios. Sin embargo, también debes considerar quitar pasos manuales adicionales cuando podrían resultar costosos o poco confiables. Por ejemplo, recuperar una base de datos a partir de una copia de seguridad nocturna podría admitir el RPO de 24 horas, pero esto suele requerir una persona capacitada, como un administrador de la base de datos que podría no estar disponible, en especial si varios servicios se vieron afectados al mismo tiempo. Con la infraestructura a pedido de Google Cloud, puedes compilar esta función sin realizar una compensación de costos importante, por lo que esta arquitectura usa la HA de Cloud SQL en lugar de una copia de seguridad o un restablecimiento manual para las interrupciones zonales.

Decisiones clave de arquitectura para la interrupción zonal: RTO de 12 horas y RPO de 24 horas:

  • Se usa un balanceador de cargas interno para proporcionar un punto de acceso escalable para los usuarios, lo que permite la conmutación por error automática a otra zona. Aunque el RTO es de 12 horas, los cambios manuales en las direcciones IP o incluso las actualizaciones del DNS pueden tardar más tiempo del esperado.
  • Un grupo de instancias administrado regional se configura con varias zonas, pero con recursos mínimos. Esto optimiza el costo, pero permite que las máquinas virtuales se escalen horizontalmente con rapidez en la zona de la copia de seguridad.
  • Una configuración de Cloud SQL de alta disponibilidad proporciona una conmutación por error automática a otra zona. Las bases de datos son mucho más difíciles de volver a crear y restablecer en comparación con las máquinas virtuales de Compute Engine.

Decisiones clave de arquitectura para la interrupción regional: RTO de 28 días y RPO de 24 horas:

  • Se construiría un balanceador de cargas en la región 2 solo en caso de una interrupción regional. Se usa Cloud DNS para proporcionar una capacidad de conmutación por error regional, organizada y manual, ya que la infraestructura en la región 2 solo estará disponible en caso de que se produzca una interrupción regional.
  • Se creará un nuevo grupo de instancias administrado solo en caso de una interrupción de la región. Esto optimiza el costo y es poco probable que se invoque debido a la corta duración de la mayoría de las interrupciones regionales. Ten en cuenta que, a fin de simplificar el diagrama, no se muestran ni las herramientas asociadas necesarias para volver a implementar ni la copia de las imágenes de Compute Engine necesarias.
  • Se volvería a crear una instancia nueva de Cloud SQL y se restablecerían los datos desde una copia de seguridad. Una vez más, el riesgo de una interrupción prolongada en una región es muy baja, por lo que esta es otra compensación de optimización de costos.
  • Se usa Cloud Storage multirregional para almacenar estas copias de seguridad. Esto brinda resiliencia zonal y regional automática dentro de RTO y RPO.

Arquitectura de ejemplo de nivel 2

Importancia de la aplicación Interrupción zonal Interrupción regional
Nivel 2 RTO de 4 horas
RPO de cero
RTO de 24 horas
RPO de 4 horas

Ejemplo de arquitectura de nivel 2 que usa productos de Google Cloud

En esta arquitectura, se describe un almacén de datos con usuarios internos que se conectan a una capa de visualización de instancias de procesamiento, y una capa de transformación y transferencia de datos que propaga el almacén de datos de backend.

Algunos componentes individuales de esta arquitectura directamente no admiten el RPO requerido para su nivel. Sin embargo, debido a cómo se usan en conjunto, el servicio general cumple con el RPO. En este caso, como Dataflow es un producto zonal, sigue las recomendaciones para el diseño de alta disponibilidad a fin de evitar la pérdida de datos durante una interrupción. Sin embargo, la capa de Cloud Storage es la fuente dorada de estos datos y admite un RPO de cero. Como resultado, puedes volver a transferir cualquier dato perdido a BigQuery mediante la zona B en caso de una interrupción en la zona A.

Decisiones clave de arquitectura para la interrupción zonal: RTO de 4 horas y RPO de cero:

  • Se usa un balanceador de cargas a fin de proporcionar un punto de acceso escalable para los usuarios, lo que permite la conmutación por error automática a otra zona. Aunque el RTO es de 4 horas, los cambios manuales en las direcciones IP o incluso las actualizaciones del DNS pueden tardar más tiempo del esperado.
  • Se configura un grupo de instancias administrado regional para la capa de procesamiento de visualización de datos con varias zonas, pero con recursos mínimos. Esto optimiza el costo, pero permite que las máquinas virtuales se escalen horizontalmente con rapidez.
  • Se usa Cloud Storage regional como capa de etapa de pruebas para la transferencia inicial de datos, lo que proporciona resiliencia automática de la zona.
  • Dataflow se usa para extraer datos de Cloud Storage y transformarlos antes de cargarlos en BigQuery. En caso de que ocurra una interrupción zonal, este es un proceso sin estado que se puede reiniciar en otra zona.
  • BigQuery proporciona el backend del almacén de datos para el frontend de visualización de datos. Si se produce una interrupción zonal, se volverán a transferir los datos que se hayan perdido desde Cloud Storage.

Decisiones clave de arquitectura para la interrupción regional: RTO de 24 horas y RPO de 4 horas:

  • Se usa un balanceador de cargas en cada región para proporcionar un punto de acceso escalable para los usuarios. Se usa Cloud DNS para proporcionar capacidad de conmutación por error regional, organizada y manual, ya que la infraestructura en la región 2 solo estará disponible en caso de que se produzca una interrupción regional.
  • Se configura un grupo de instancias administrado regional para la capa de procesamiento de visualización de datos con varias zonas, pero con recursos mínimos. No será accesible hasta que se vuelva a configurar el balanceador de cargas. Sin embargo, no se requiere una intervención manual.
  • Se usa Cloud Storage regional como capa de etapa de pruebas para la transferencia inicial de datos. Se carga al mismo tiempo en ambas regiones para cumplir con los requisitos de RPO.
  • Dataflow se usa para extraer datos de Cloud Storage y transformarlos antes de cargarlos en BigQuery. Si se produce una interrupción regional, BigQuery se propagaría con los datos más recientes de Cloud Storage.
  • BigQuery proporciona el backend del almacén de datos. En las operaciones normales, esto se actualiza de manera intermitente. Si se produce una interrupción regional, se vuelven a transferir los datos más recientes desde Cloud Storage mediante Dataflow.

Arquitectura de ejemplo de nivel 1

Importancia de la aplicación Interrupción zonal Interrupción regional
Nivel 1
(más importante)
RTO de cero
RPO de cero
RTO de 4 horas
RPO de 1 hora

Un ejemplo de arquitectura de nivel 1 que usa productos de Google Cloud

En esta arquitectura, se describe una infraestructura de backend de apps para dispositivos móviles con usuarios externos que se conectan a un conjunto de microservicios que se ejecutan en GKE. Spanner proporciona la capa de almacenamiento de datos de backend para los datos en tiempo real, y los datos históricos se transmiten a un data lake de BigQuery en cada región.

Otra vez, algunos componentes individuales de esta arquitectura no admiten directamente el RPO requerido para su nivel. Sin embargo, debido a cómo se usan en conjunto, el servicio general sí lo admite. En este caso, BigQuery se usa para consultas analíticas. Cada región recibe datos de forma simultánea desde Spanner.

Decisiones clave de arquitectura para la interrupción zonal: RTO de cero y RPO de cero:

  • Se usa un balanceador de cargas a fin de proporcionar un punto de acceso escalable para los usuarios, lo que permite la conmutación por error automática a otra zona.
  • Se usa un clúster regional de GKE para la capa de aplicación que se configura con varias zonas. Esto logra el RTO de cero dentro de cada región.
  • Spanner multirregional se usa como capa de persistencia de datos y proporciona resiliencia automática de los datos de la zona y coherencia en la transacción.
  • BigQuery proporciona la capacidad de crear estadísticas para la aplicación. Cada región recibe datos provenientes de Spanner de manera independiente y la aplicación accede a ellos de la misma forma.

Decisiones clave de arquitectura para la interrupción regional: RTO de 4 horas y RPO de 1 hora:

  • Se usa un balanceador de cargas para proporcionar un punto de acceso escalable para los usuarios, lo que permite la conmutación por error automática a otra región.
  • Se usa un clúster regional de GKE para la capa de aplicación que se configura con varias zonas. Si se produce una interrupción regional, el clúster en la región alternativa se escala de manera automática para tomar la carga de procesamiento adicional.
  • Spanner multirregional se usa como capa de persistencia de datos y proporciona resiliencia automática de los datos regionales y coherencia en la transacción. Este es el componente clave para lograr la RPO de 1 hora.
  • BigQuery proporciona la capacidad de crear estadísticas para la aplicación. Cada región recibe datos provenientes de Spanner de manera independiente y la aplicación accede a ellos de la misma forma. Esta arquitectura compensa el componente de BigQuery, lo que le permite cumplir con los requisitos generales de la aplicación.

Apéndice: Referencia del producto

En esta sección, se describen la arquitectura y las capacidades de DR de los productos de Google Cloudque se usan con mayor frecuencia en las aplicaciones de los clientes y que se pueden aprovechar fácilmente para cumplir con tus requisitos de DR.

Temas comunes

Muchos productos de Google Cloud ofrecen configuraciones regionales o multirregionales. Los productos regionales son resilientes a las interrupciones zonales, mientras que los productos globales y multirregionales son resilientes a las interrupciones regionales. En general, esto significa que, durante una interrupción, la aplicación experimenta interrupciones mínimas. Google logra estos resultados a través de algunos enfoques arquitectónicos comunes, que reflejan la guía de arquitectura anterior.

  • Implementación redundante: Los backends de la aplicación y el almacenamiento de datos se implementan en varias zonas dentro de una región y en varias regiones dentro de una ubicación multirregional. Para obtener más información sobre las consideraciones específicas de cada región, consulta Geografía y regiones.

  • Replicación de datos: Los productos usan la replicación síncrona o asíncrona en las ubicaciones redundantes.

    • La replicación síncrona significa que, cuando tu aplicación realiza una llamada a la API para crear o modificar los datos que almacenó el producto, recibe una respuesta correcta solo una vez que el producto escribió los datos en varias ubicaciones. La replicación síncrona garantiza que no pierdas el acceso a ninguno de tus datos durante una interrupción en la infraestructura de Google Cloud porque todos están disponibles en una de las ubicaciones de backend disponibles.

      Aunque esta técnica proporciona la máxima protección de los datos, puede tener compensaciones en términos de latencia y rendimiento. Los productos multirregionales que usan la replicación síncrona experimentan esta compensación de manera más significativa, por lo general, en décimas o centésimas de milisegundos de latencia adicional.

    • La replicación asíncrona significa que, cuando tu aplicación realiza una llamada a la API para crear o modificar los datos que almacenó el producto, recibe una respuesta correcta una vez que el producto escribió los datos en una sola ubicación. Luego de la solicitud de escritura, el producto replica los datos en ubicaciones adicionales.

      Esta técnica proporciona una latencia menor y una capacidad de procesamiento más alta en la API que la replicación síncrona, pero a expensas de la protección de los datos. Si la ubicación en la que escribiste los datos sufre una interrupción antes de que se complete la replicación, perderás el acceso a esos datos hasta que la interrupción en la ubicación se resuelva.

  • Controla las interrupciones con el balanceo de cargas: Google Cloud usa el balanceo de cargas de software para enrutar las solicitudes a los backends de aplicaciones adecuados. En comparación con otros enfoques como el balanceo de cargas de DNS, este enfoque reduce el tiempo de respuesta del sistema a una interrupción. Cuando se produce una interrupción en una ubicación de Google Cloud , el balanceador de cargas detecta con rapidez que el backend implementado en esa ubicación se encuentra “en mal estado” y dirige todas las solicitudes a un backend en una ubicación alternativa. Esto permite que el producto siga entregando las solicitudes de tu aplicación durante una interrupción en la ubicación. Cuando se resuelve la interrupción en la ubicación, el balanceador de cargas detecta la disponibilidad de los backends del producto en esa ubicación y reanuda el envío de tráfico hacia allí.

Access Context Manager

Access Context Manager permite a las empresas configurar niveles de acceso que se asignan a una política que se define en los atributos de la solicitud. Las políticas se duplican de forma regional.

En el caso de una interrupción zonal, las solicitudes a zonas no disponibles se entregan de forma automática y transparente desde otras zonas disponibles en la región.

En el caso de una interrupción regional, los cálculos de políticas de la región afectada no estarán disponibles hasta que la región vuelva a estar disponible.

Transparencia de acceso

La transparencia de acceso permite a los administradores de la organización de Google Cloud definir un control de acceso detallado y basado en atributos para los proyectos y los recursos en Google Cloud. En ocasiones, Google debe acceder a los datos de los clientes con fines administrativos. Cuando accedemos a los datos del cliente, la Transparencia de acceso proporciona registros de acceso a los clientes afectados de Google Cloud. Estos registros de Transparencia de acceso ayudan a garantizar el compromiso de Google con la seguridad y la transparencia de los datos en el control de datos.

La Transparencia de acceso es resistente a las interrupciones zonales y regionales. Si ocurre una interrupción zonal o regional, la Transparencia de acceso continúa procesando registros de acceso administrativos en otra zona o región.

AlloyDB para PostgreSQL

AlloyDB para PostgreSQL es un servicio de base de datos completamente administrado y compatible con PostgreSQL. AlloyDB para PostgreSQL ofrece alta disponibilidad en una región a través de los nodos redundantes de su instancia principal que se encuentran en dos zonas diferentes de la región. La instancia principal mantiene la disponibilidad regional mediante la activación de una conmutación por error automática a la zona en espera si la zona activa encuentra un problema. Regional Storage garantiza la durabilidad de los datos en caso de pérdida de una zona.

Como otro método de recuperación ante desastres, AlloyDB para PostgreSQL usa la replicación entre regiones para proporcionar capacidades de recuperación ante desastres replicando de forma asíncrona los datos de tu clúster principal en clústeres secundarios que se encuentran en regiones Google Cloud separadas.

Interrupción zonal: Durante el funcionamiento normal, solo uno de los dos nodos de una instancia principal de alta disponibilidad está activo y entrega todas las escrituras de datos. Este nodo activo almacena los datos en la capa de almacenamiento regional independiente del clúster.

AlloyDB para PostgreSQL detecta de forma automática las fallas a nivel de zona y activa una conmutación por error para restablecer la disponibilidad de la base de datos. Durante la conmutación por error, AlloyDB para PostgreSQL inicia la base de datos en el nodo en espera, que ya está aprovisionada en una zona diferente. Las conexiones de bases de datos nuevas se enrutan de forma automática a esta zona.

Desde la perspectiva de una aplicación cliente, una interrupción zonal se parece a una interrupción temporal de la conectividad de red. Una vez que se completa la conmutación por error, un cliente puede volver a conectarse a la instancia en la misma dirección mediante las mismas credenciales, sin pérdida de datos.

Interrupción regional: La replicación entre regiones usa la replicación asíncrona, que permite que la instancia principal confirme las transacciones antes de que se confirmen en las réplicas. La diferencia de tiempo entre el momento en que una transacción se confirma en la instancia principal y en que se confirma en la réplica se conoce como demora de replicación. La diferencia de tiempo entre el momento en que la instancia principal genera el registro de escritura anticipada (WAL) y el momento en que este llega a la réplica se conoce como demora de vaciado. El retraso de replicación y el retraso de vaciado dependen de la configuración de la instancia de la base de datos y de la carga de trabajo generada por el usuario.

Si se produce una interrupción regional, puedes ascender clústeres secundarios en una región diferente a un clúster principal independiente que admite escritura. Este clúster promocionado ya no replica los datos del clúster principal original con el que estaba asociado antes. Debido al retraso de vaciado, puede que se pierdan datos, ya que podría haber transacciones en la instancia principal original que no se propagaron al clúster secundario.

El RPO de replicación entre regiones se ve afectado por el uso de CPU del clúster principal y la distancia física entre la región del clúster principal y la región del clúster secundario. A fin de optimizar el RPO, recomendamos probar la carga de trabajo con una configuración que incluya una réplica para establecer un límite seguro de transacciones por segundo (TPS), que es el TPS continuo más alto que no acumula demora de vaciado. Si la carga de trabajo excede el límite seguro de TPS, la demora de vaciado se acumula, lo que puede afectar el RPO. Para limitar el retraso de la red, elige pares de regiones dentro del mismo continente.

Para obtener más información sobre la supervisión del retraso de la red y otras métricas de AlloyDB para PostgreSQL, consulta Supervisa instancias.

IA para prevención del lavado de dinero

La IA para la prevención del lavado de dinero (AML AI) proporciona una API para ayudar a las instituciones financieras globales a detectar de manera más eficaz y eficiente el lavado de dinero. La IA para la prevención del lavado de dinero es una oferta regional, lo que significa que los clientes pueden elegir la región, pero no las zonas que la conforman. Las cargas de los datos y el tráfico se balancean de forma automática entre zonas de una región. Las operaciones (por ejemplo, para crear una canalización o ejecutar una predicción) se escalan de forma automática en segundo plano y se balancean las cargas entre las zonas según sea necesario.

Interrupción zonal: AML AI almacena los datos para sus recursos de forma regional, replicados de forma síncrona. Cuando una operación de larga duración finaliza de forma correcta, se puede confiar en los recursos, sin importar las fallas zonales. El procesamiento también se replica entre zonas, pero el objetivo es la replicación en un balanceo de cargas y no una alta disponibilidad, por lo que una falla zonal durante una operación puede provocar un error en la operación. Si eso sucede, reintentar la operación puede solucionar el problema. Durante una interrupción zonal, los tiempos de procesamiento pueden verse afectados.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean crear sus recursos de AML AI. Los datos nunca se replican en otras regiones. AML AI nunca enruta el tráfico del cliente a una región diferente. En el caso de una falla regional, Cloud Run volverá a estar disponible en cuanto se resuelva la interrupción.

Claves de API

Las claves de API proporcionan una administración de recursos escalable para las claves de API de un proyecto. Las claves de API son un servicio global, lo que significa que las claves son visibles y se puede acceder a ellas desde cualquier ubicación de Google Cloud . Sus datos y metadatos se almacenan de manera redundante en varias zonas y regiones.

Las claves de API son resilientes a las interrupciones zonales y regionales. En el caso de una interrupción zonal o regional, las claves de API continúan entregando solicitudes desde otra zona en la misma región o en región diferente.

Para obtener más información sobre las claves de API, consulta Descripción general de las claves de API.

Apigee

Apigee proporciona una plataforma segura, escalable y confiable para desarrollar y administrar APIs. Apigee ofrece implementaciones regionales y multirregionales.

Interrupción zonal: Los datos del entorno de ejecución del cliente se replican en varias zonas de disponibilidad. Por lo tanto, una interrupción de una sola zona no afecta a Apigee.

Interrupción regional: En el caso de las instancias de Apigee de una sola región, si una región deja de estar disponible, las instancias de Apigee no estarán disponibles en esa región y no se podrán restablecer en diferentes regiones. En el caso de las instancias de Apigee multirregión, los datos se replican de forma asíncrona en todas las regiones. Por lo tanto, la falla de una región no reduce el tráfico por completo. Sin embargo, es posible que no puedas acceder a los datos no confirmados en la región con errores. Puedes desviar el tráfico de las regiones no saludables. Para lograr la conmutación por error automática del tráfico, puedes configurar el enrutamiento de red con grupos de instancias administrados (MIG).

AutoML Translation

AutoML Translation es un servicio de traducción automática que te permite importar tus propios datos (pares de oraciones) a fin de entrenar modelos personalizados para tus necesidades específicas del dominio.

Interrupción zonal: AutoML Translation tiene servidores de procesamiento activos en varias zonas y regiones. También admite la replicación de datos síncrona entre zonas dentro de las regiones. Estas características ayudan a AutoML Translation a lograr una conmutación por error instantánea sin perder datos para las fallas zonales y sin la necesidad de entradas o ajustes de los clientes.

Interrupción regional: En el caso de una falla regional, AutoML Translation no está disponible.

AutoML Vision

AutoML Vision forma parte de Vertex AI. Ofrece un framework unificado para crear conjuntos de datos, importar datos, entrenar modelos y entregar modelos para la predicción en línea y por lotes.

AutoML Vision es una oferta regional. Los clientes pueden elegir desde qué región desean iniciar un trabajo, pero no pueden elegir las zonas específicas dentro de esa región. El servicio balancea automáticamente las cargas de trabajo en diferentes zonas dentro de la región.

Interrupción zonal: AutoML Vision almacena los metadatos de las tareas regionalmente y los escribe de forma síncrona en todas las zonas de la región. Las tareas se inician en una zona específica, según lo que seleccione Cloud Load Balancing.

  • Trabajos de entrenamiento de AutoML Vision: Una interrupción zonal hace que falle cualquier trabajo en ejecución, y el estado del trabajo se actualiza a "Falló". Si una tarea falla, reinténtalo de inmediato. El trabajo nuevo se enruta a una zona disponible.

  • Trabajos de predicción por lotes de AutoML Vision: La predicción por lotes se compila en función de la predicción por lotes de Vertex AI. Cuando se produce una interrupción zonal, el servicio vuelve a intentar el trabajo automáticamente enviándolo a las zonas disponibles. Si fallan varios reintentos, el estado del trabajo se actualiza a "Falló". Las solicitudes posteriores del usuario para ejecutar la tarea se enrutan a una zona disponible.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean ejecutar sus trabajos. Los datos nunca se replican en otras regiones. En caso de falla regional, el servicio de AutoML Vision no estará disponible en esa región. Sin embargo, volverá a estar disponible cuando se resuelva la interrupción. Para ejecutar sus trabajos, recomendamos que los clientes usen varias regiones. En caso de que se produzca una interrupción regional, dirige las tareas a una región disponible diferente.

Batch

Por lotes es un servicio completamente administrado para poner en cola, programar y ejecutar trabajos por lotes en Google Cloud. La configuración de los lotes se define a nivel de la región. Los clientes deben elegir una región para enviar sus trabajos por lotes, no una zona en una región. Cuando se envía un trabajo, Batch escribe datos de clientes de forma síncrona en múltiples zonas. Sin embargo, los clientes pueden especificar las zonas en las que las VMs de Batch ejecutan trabajos.

Falla zonal: Cuando una sola zona falla, las tareas que se ejecutan en esa zona también fallan. Si las tareas tienen una configuración de reintento, Batch realiza la conmutación por error automáticamente en otras zonas activas de la misma región. La conmutación por error automática está sujeta a la disponibilidad de recursos en zonas activas de la misma región. Los trabajos que requieren recursos zonales (como VMs, GPU o discos persistentes zonales) y que solo están disponibles en la zona con errores, se ponen en cola hasta que la zona con errores se recupera o hasta que se alcanza el tiempo de espera de la cola de los trabajos. Cuando sea posible, recomendamos que los clientes permitan que Batch elija recursos zonales para ejecutar sus trabajos. Esto ayuda a garantizar que los trabajos sean resistentes a una interrupción zonal.

Falla regional: En caso de una falla regional, el plano de control del servicio no está disponible en la región. El servicio no replica datos ni redirecciona solicitudes en todas las regiones. Recomendamos que los clientes usen varias regiones para ejecutar sus trabajos y redireccionar los trabajos a una región diferente si una región falla.

Protección contra amenazas y datos de Chrome Enterprise Premium

La protección de datos y contra amenazas de Chrome Enterprise Premium forma parte de la solución Chrome Enterprise Premium. Extiende Chrome con una variedad de funciones de seguridad, como protección contra software malicioso y phishing, Prevención de pérdida de datos (DLP), informes de seguridad y reglas de filtrado de URL.

Los administradores de Chrome Enterprise Premium pueden habilitar el almacenamiento de contenido principal del cliente que incumpla las políticas de DLP o de software malicioso en los eventos de registro de reglas de Google Workspace o en Cloud Storage para futuras investigaciones. Los eventos de registro de reglas de Google Workspace se basan en una base de datos de Spanner multirregional. Chrome Enterprise Premium puede tardar hasta varias horas en detectar incumplimientos de políticas. Durante este tiempo, los datos sin procesar están sujetos a la pérdida de datos debido a una interrupción zonal o regional. Una vez que se detecta un incumplimiento, el contenido que incumple tus políticas se escribe en los eventos de registro de reglas de Google Workspace o en Cloud Storage.

Interrupción zonal y regional: Debido a que la protección de datos y amenazas de Chrome Enterprise Premium es multizonal y multirregional, puede sobrevivir a una pérdida completa y no planificada de una zona o una región sin perder disponibilidad. Proporciona este nivel de confiabilidad redireccionando el tráfico a su servicio en otras zonas o regiones activas. Sin embargo, debido a que la protección de datos y amenazas de Chrome Enterprise Premium puede tardar varias horas en detectar violaciones de la DLP y software malicioso, cualquier dato sin procesar en una zona o región específica está sujeto a pérdidas por una interrupción zonal o regional.

BigQuery

BigQuery es un almacén de datos en la nube sin servidores, rentable y altamente escalable, diseñado para lograr agilidad empresarial. BigQuery es compatible con los siguientes tipos de ubicaciones para conjuntos de datos del usuario:

  • Una región: una ubicación geográfica específica, como Iowa (us-central1) o Montreal (northamerica-northeast1).
  • Una multirregión: un área geográfica grande que contiene dos o más lugares geográficos, como los Estados Unidos (US) o Europa (EU).

En cualquier caso, los datos se almacenan de manera redundante en dos zonas dentro de una sola región de la ubicación seleccionada. Los datos escritos en BigQuery se escriben en las zonas principal y secundaria. Esto protege contra la falta de disponibilidad de una zona única dentro de la región, pero no contra una interrupción regional.

Autorización binaria

La autorización binaria es un producto de seguridad de la cadena de suministro de software para GKE y Cloud Run.

Todas las políticas de autorización binaria se replican en varias zonas dentro de cada región. La replicación ayuda a las operaciones de lectura de la política de autorización binaria a recuperarse de fallas de otras regiones. La replicación también hace que las operaciones de lectura sean tolerantes a fallas zonales dentro de cada región.

Las operaciones de aplicación de la autorización binaria son resilientes ante las interrupciones zonales, pero no son resilientes ante las interrupciones regionales. Las operaciones de aplicación se ejecutan en la misma región que el clúster de GKE o el trabajo de Cloud Run que realiza la solicitud. Por lo tanto, en el caso de una interrupción regional, no hay nada en ejecución para realizar solicitudes de aplicación de la autorización binaria.

Administrador de certificados

El Administrador de certificados te permite adquirir y administrar certificados de seguridad de la capa de transporte (TLS) para usarlos con diferentes tipos de Cloud Load Balancing.

En el caso de una interrupción zonal, el Administrador de certificados regional y global es resistente a las fallas zonales porque los trabajos y las bases de datos son redundantes en varias zonas dentro de una región. En el caso de una interrupción regional, el Administrador de certificados global es resistente a las fallas regionales porque los trabajos y las bases de datos son redundantes en varias regiones. El Administrador de certificados regional es un producto regional, por lo que no puede resistir una falla regional.

Sistema de detección de intrusiones de Cloud

El Sistema de detección de intrusiones de Cloud (IDS de Cloud) es un servicio zonal que proporciona extremos de IDS con alcance zonal, que procesan el tráfico de las VMs en una zona específica y, por lo tanto, no tolera las interrupciones zonales o regionales.

Interrupción zonal: Los IDS de Cloud están vinculados a las instancias de VM. Si un cliente planea mitigar las interrupciones zonales mediante la implementación de VMs en varias zonas (de forma manual o a través de grupos de instancias administrados regionales), también deberá implementar extremos de IDS de Cloud en esas zonas.

Interrupción regional: El IDS de Cloud es un producto regional. No proporciona ninguna funcionalidad entre regiones. Una falla regional inhabilitará todas las funciones de IDS de Cloud en todas las zonas de esa región.

Google Security Operations SIEM

Google Security Operations SIEM (que forma parte de Google Security Operations) es un servicio completamente administrado que ayuda a los equipos de seguridad a detectar amenazas, investigarlas y responder a ellas.

El SIEM de Google Security Operations tiene ofertas regionales y multirregionales.

  • En las ofertas regionales, los datos y el tráfico se balancean automáticamente en las zonas de la región elegida, y los datos se almacenan de forma redundante en las zonas de disponibilidad de la región.

  • Las multirregiones tienen redundancia geográfica. Esa redundancia proporciona un conjunto de protecciones más amplio que el almacenamiento regional. También ayuda a garantizar que el servicio siga funcionando incluso si se pierde una región completa.

  • La mayoría de las rutas de transferencia de datos replican los datos del cliente de forma síncrona en varias ubicaciones. Cuando los datos se replican de forma asíncrona, hay un período (un objetivo de punto de recuperación o RPO) durante el cual los datos aún no se replican en varias ubicaciones. Este es el caso cuando se transfieren datos con feeds en implementaciones multirregionales. Después del RPO, los datos están disponibles en varias ubicaciones.

Interrupción zonal:

  • Implementaciones regionales: Las solicitudes se entregan desde cualquier zona de la región. Los datos se replican de forma síncrona en varias zonas. En caso de una interrupción de zona completa, las zonas restantes continúan entregando tráfico y procesando los datos. El aprovisionamiento redundante y el escalamiento automatizado del SIEM de Google Security Operations ayudan a garantizar que el servicio siga funcionando en las zonas restantes durante estos cambios de carga.

  • Implementaciones multirregionales: Las interrupciones zonales equivalen a las interrupciones regionales.

Interrupción regional:

  • Implementaciones regionales: El SIEM de Google Security Operations almacena todos los datos del cliente en una sola región y el tráfico nunca se enruta entre regiones. En caso de una interrupción regional, el SIEM de Google Security Operations no estará disponible en la región hasta que se resuelva la interrupción.

  • Implementaciones multirregionales (sin feeds): Las solicitudes se entregan desde cualquier región de la implementación multirregional. Los datos se replican de forma síncrona en varias regiones. En caso de una interrupción de toda la región, las regiones restantes continúan entregando tráfico y procesando los datos. El aprovisionamiento redundante y el escalamiento automatizado del SIEM de Google Security Operations ayudan a garantizar que el servicio siga funcionando en las regiones restantes durante estos cambios de carga.

  • Implementaciones multirregionales (con feeds): Las solicitudes se entregan desde cualquier región de la implementación multirregional. Los datos se replican de forma asíncrona en varias regiones con el RPO proporcionado. En caso de una interrupción de toda la región, solo los datos almacenados después del RPO estarán disponibles en las regiones restantes. Es posible que no se repliquen los datos dentro del período de RPO.

Cloud Asset Inventory

Cloud Asset Inventory es un servicio global, resiliente y de alto rendimiento que mantiene un repositorio de los recursos y los metadatos de las políticas de Google Cloud . Cloud Asset Inventory proporciona herramientas de búsqueda y análisis que te ayudan a realizar un seguimiento de los elementos implementados en organizaciones, carpetas y proyectos.

En el caso de una interrupción zonal, Cloud Asset Inventory continúa entregando solicitudes desde otra zona en la misma región o en una diferente.

En el caso de una interrupción regional, Cloud Asset Inventory continúa entregando solicitudes desde otras regiones.

Bigtable

Bigtable es un servicio de base de datos NoSQL de alto rendimiento completamente administrado para grandes cargas de trabajo estadísticas y operativas.

Descripción general de la replicación de Bigtable

Bigtable ofrece una función de replicación flexible y completamente configurable que puedes usar para aumentar la disponibilidad y la durabilidad de los datos si los copias en clústeres desde varias regiones o varias zonas dentro de la misma región. Bigtable también puede proporcionar una conmutación por error automática para tus solicitudes cuando usas la replicación.

Cuando se usan configuraciones multizonales o multirregionales con el enrutamiento de varios clústeres, en el caso de una interrupción zonal o regional, Bigtable redirige automáticamente el tráfico y entrega solicitudes desde el clúster disponible más cercano. Debido a que la replicación de Bigtable es asíncrona y tiene coherencia eventual, los cambios muy recientes en los datos en la ubicación de la interrupción podrían no estar disponibles si aún no se replicaron en otras ubicaciones.

Consideraciones de rendimiento

Cuando las demandas de recursos de CPU superan la capacidad del nodo disponible, Bigtable siempre prioriza la entrega de solicitudes entrantes antes que el tráfico de replicación.

Si quieres obtener más información sobre cómo usar la replicación de Bigtable con tu carga de trabajo, consulta la descripción general de la replicación de Cloud Bigtable y los ejemplos de configuración de replicación.

Los nodos de Bigtable se usan para entregar solicitudes entrantes y realizar la replicación de datos de otros clústeres. Además de mantener cantidades suficientes de nodos por clúster, también debes asegurarte de que tus aplicaciones usen un diseño de esquema adecuado para evitar hotspots, que puede causar un uso de CPU excesivo o desequilibrado y mayor latencia de replicación.

Si deseas obtener más información sobre cómo diseñar el esquema de tu aplicación para maximizar el rendimiento y la eficiencia de Bigtable, consulta Prácticas recomendadas para el diseño de esquemas.

Supervisión

Bigtable proporciona varias formas de supervisar visualmente la latencia de replicación de tus instancias y clústeres con los gráficos de replicación disponibles en Google Cloud console.

También puedes supervisar las métricas de replicación de Bigtable de manera programática mediante la API de Cloud Monitoring.

Certificate Authority Service

Certificate Authority Service (servicio de CA) permite que los clientes simplifiquen, automaticen y personalicen la implementación, la administración y la seguridad de las autoridades certificadoras (CA) privadas y que emitan certificados a gran escala de forma resiliente.

Interrupción zonal: El servicio de CA es resistente a las fallas zonales porque su plano de control es redundante en varias zonas dentro de una región. Si hay una interrupción zonal, el servicio de CA continúa entregando solicitudes desde otra zona en la misma región sin interrupción. Debido a que los datos se replican de forma síncrona, no hay pérdida ni corrupción de datos.

Interrupción regional: El servicio de CA es un producto regional, por lo que no puede resistir una falla regional. Si necesitas resiliencia ante fallas regionales, crea CA de emisión en dos regiones diferentes. Crea la CA emisora principal en la región en la que necesitas certificados. Crea una CA de resguardo en una región diferente. Usa el resguardo cuando la región de la CA subordinada principal tenga una interrupción. Si es necesario, ambas CA pueden encadenar hasta la misma CA raíz.

Facturación de Cloud

La API de Facturación de Cloud permite a los desarrolladores administrar la facturación de sus proyectos deGoogle Cloud de forma programática. La API de Cloud Billing está diseñada como un sistema global con actualizaciones escritas de forma síncrona en varias zonas y regiones.

Falla zonal o regional: La API de Cloud Billing conmutará por error de forma automática a otra zona o región. Las solicitudes individuales pueden fallar, pero una política de reintento debe permitir que los intentos posteriores tengan éxito.

Cloud Build

Cloud Build es un servicio que ejecuta tus compilaciones en Google Cloud.

Cloud Build está compuesto por instancias regionalmente aisladas que replican datos de forma síncrona en todas las zonas de la región. Te recomendamos que uses regiones específicas de Google Cloud en lugar de la región global y que te asegures de que los recursos que usa tu compilación (incluidos los buckets de registro, los repositorios de Artifact Registry, etcétera) estén alineados con la región en la que se ejecuta la compilación.

En el caso de una interrupción zonal, las operaciones del plano de control no se ven afectadas. Sin embargo, las compilaciones que se ejecutan actualmente dentro de la zona con errores se retrasarán o se perderán de forma permanente. Las compilaciones activadas recientemente se distribuirán de forma automática a las zonas de funcionamiento restantes.

En el caso de una falla regional, el plano de control estará sin conexión y las compilaciones que se encuentran en ejecución se retrasarán o se perderán de forma permanente. Los activadores, los grupos de trabajadores y los datos de compilación nunca se replican en otras regiones. Te recomendamos que prepares activadores y grupos de trabajadores en varias regiones para facilitar la mitigación de una interrupción.

Cloud CDN

Cloud CDN distribuye y almacena en caché contenido en muchas ubicaciones de la red de Google a fin de reducir la latencia de entrega para los clientes. El contenido almacenado en caché se entrega en función del mejor esfuerzo: cuando la caché de Cloud CDN no puede entregar una solicitud, la solicitud se reenvía a los servidores de origen, como las VM de backend o los buckets de Cloud Storage, donde se almacena el contenido original.

Cuando falla una zona o región, las memorias caché de las ubicaciones afectadas no están disponibles. Las solicitudes entrantes se enrutan a las ubicaciones perimetrales y las cachés de Google disponibles. Si estas memorias caché no pueden entregar la solicitud, reenviarán la solicitud a un servidor de origen disponible. Siempre que el servidor pueda entregar la solicitud con datos actualizados, no habrá pérdida de contenido. Una mayor tasa de errores de caché hará que los servidores de origen experimenten un volumen de tráfico mayor que el normal a medida que se llenan las memorias caché. Las solicitudes posteriores se entregan desde las memorias caché que no se ven afectadas por la interrupción de la zona o la región.

Para obtener más información sobre Cloud CDN y el comportamiento de la caché, consulta la documentación de Cloud CDN.

Cloud Composer

Cloud Composer es un servicio de organización de flujo de trabajo administrado que te permite crear, programar, supervisar y administrar flujos de trabajo que abarcan nubes y centros de datos locales. Los entornos de Cloud Composer se compilan en el proyecto de código abierto de Apache Airflow.

La disponibilidad de la API de Cloud Composer no se ve afectada por la falta de disponibilidad zonal. Durante una interrupción zonal, conservas el acceso a la API de Cloud Composer, incluida la capacidad de crear entornos nuevos de Cloud Composer.

Un entorno de Cloud Composer tiene un clúster de GKE como parte de su arquitectura. Durante una interrupción zonal, se pueden interrumpir los flujos de trabajo en el clúster:

  • En Cloud Composer 1, el clúster del entorno es un recurso zonal, por lo que una interrupción zonal puede hacer que el clúster deje de estar disponible. Es posible que los flujos de trabajo que se ejecutan al momento de la interrupción se detengan antes de completarse.
  • En Cloud Composer 2, el clúster del entorno es un recurso regional. Sin embargo, los flujos de trabajo que se ejecutan en nodos en las zonas que se ven afectadas por una interrupción zonal pueden detenerse antes de completarse.

En ambas versiones de Cloud Composer, una interrupción zonal puede hacer que los flujos de trabajo ejecutados de forma parcial dejen de ejecutarse, incluidas las acciones externas que configuraste para que realice el flujo de trabajo. Según el flujo de trabajo, esto puede causar inconsistencias externas, por ejemplo, si el flujo de trabajo se detiene en la mitad de una ejecución de varios pasos para modificar los almacenes de datos externos. Por lo tanto, debes considerar el proceso de recuperación cuando diseñes tu flujo de trabajo de Airflow, incluido cómo detectar estados de flujos de trabajo ejecutados de manera parcial y reparar cualquier cambio parcial en los datos.

En Cloud Composer 1, durante una interrupción zonal, puedes elegir iniciar un entorno de Cloud Composer nuevo en otra zona. Debido a que Airflow mantiene el estado de los flujos de trabajo en su base de datos de metadatos, la transferencia de esta información a un entorno de Cloud Composer nuevo puede tomar pasos adicionales y preparación.

En Cloud Composer 2, puedes abordar las interrupciones zonales mediante la configuración de la recuperación ante desastres con instantáneas de entorno con anticipación. Durante una interrupción zonal, puedes cambiar a otro entorno si transfieres el estado de tus flujos de trabajo con una instantánea de entorno. Solo Cloud Composer 2 admite la recuperación ante desastres con instantáneas de entorno.

Cloud Data Fusion

Cloud Data Fusion es un servicio de integración de datos empresariales completamente administrado para compilar y administrar canalizaciones de datos con rapidez. Proporciona tres ediciones.

  • Las interrupciones zonales afectan las instancias de la edición Developer.

  • Las interrupciones regionales afectan las instancias de las ediciones Basic y Enterprise.

Para controlar el acceso a los recursos, puedes diseñar y ejecutar canalizaciones en entornos independientes. Esta separación te permite diseñar una canalización una vez y, luego, ejecutarla en varios entornos. Puedes recuperar canalizaciones en ambos entornos. Para obtener más información, consulta Crea una copia de seguridad y restablece los datos de las instancias.

Los siguientes consejos se aplican a las interrupciones regionales y zonales.

Interrupciones en el entorno de diseño de la canalización

En el entorno de diseño, guarda borradores de las canalizaciones en caso de una interrupción. Según los requisitos específicos de RTO y RPO, puedes usar los borradores guardados para restablecer la canalización en una instancia de Cloud Data Fusion diferente durante una interrupción.

Interrupciones en el entorno de ejecución de la canalización

En el entorno de ejecución, inicia la canalización de forma interna con los activadores o los programas de Cloud Data Fusion o de forma externa con herramientas de organización, como Cloud Composer. Para poder recuperar las opciones de configuración del entorno de ejecución de las canalizaciones, crea una copia de seguridad de estas y de los parámetros de configuración, como los complementos y los programas. En una interrupción, puedes usar la copia de seguridad para replicar una instancia en una región o una zona no afectadas.

Otra forma de prepararse para las interrupciones es tener varias instancias en las regiones con la misma configuración y el mismo conjunto de canalizaciones. Si usas una organización externa, se pueden balancear las cargas de las canalizaciones en ejecución de forma automática entre las instancias. Ten especial cuidado para asegurarte de que no hayan recursos (como fuentes de datos o herramientas de organización) vinculados a una sola región y que usen todas las instancias, ya que esto podría convertirse en un punto central de falla en una interrupción. Por ejemplo, puedes tener varias instancias en diferentes regiones y usar Cloud Load Balancing y Cloud DNS para dirigir las solicitudes de ejecución de canalización a una instancia que no se ve afectada por una interrupción (consulta las arquitecturas de nivel uno y de nivel tres de ejemplo).

Interrupciones de los otros servicios de datos de Google Cloud en la canalización

Tu instancia puede usar otros servicios de Google Cloud como fuentes de datos o entornos de ejecución de canalización, como Dataproc, Cloud Storage o BigQuery. Esos servicios pueden estar en diferentes regiones. Cuando se requiere una ejecución interregional, una falla en cualquiera de las regiones genera una interrupción. En esta situación, sigue los pasos estándar de recuperación ante desastres y ten en cuenta que la configuración entre regiones con servicios esenciales en diferentes regiones es menos resiliente.

Cloud Deploy

Cloud Deploy proporciona entrega continua de cargas de trabajo en servicios de entorno de ejecución, como GKE y Cloud Run. El servicio consta de instancias regionales que replican datos de forma síncrona en todas las zonas de la región.

Interrupción zonal: Las operaciones del plano de control no se ven afectadas. Sin embargo, las compilaciones de Cloud Build (por ejemplo, las operaciones de procesamiento o implementación) que se ejecutan cuando una zona falla se retrasan o se pierden de forma permanente. Durante una interrupción, el recurso de Cloud Deploy que activó la compilación (una versión o lanzamiento) muestra un estado de falla que indica que la operación subyacente falló. Puedes volver a crear el recurso para iniciar una compilación nueva en las zonas de funcionamiento restantes. Por ejemplo, crea un lanzamiento nuevo mediante la reimplementación de la versión a un destino.

Interrupción regional: Las operaciones del plano de control no están disponibles, al igual que los datos de Cloud Deploy, hasta que se restablece la región. Para facilitar el restablecimiento del servicio en caso de una interrupción regional, te recomendamos que almacenes tu canalización de entrega y las definiciones de destino en el control de origen. Puedes usar estos archivos de configuración para volver a crear tus canalizaciones de Cloud Deploy en una región en funcionamiento. Durante una interrupción, los datos sobre las versiones existentes se pierden. Crea una versión nueva para seguir implementando software en tus destinos.

Cloud DNS

Cloud DNS es un servicio de sistema de nombres de dominio (DNS) global, resiliente y de alto rendimiento que publica sus nombres de dominio en el DNS global de una manera rentable.

En el caso de una interrupción zonal, Cloud DNS continúa entregando solicitudes desde otra zona en la misma región o en otra sin interrupciones. Las actualizaciones de los registros de Cloud DNS se replican de forma síncrona en todas las zonas de la región en la que se reciben. Por lo tanto, no hay pérdida de datos.

En el caso de una interrupción regional, Cloud DNS continúa entregando solicitudes desde otras regiones. Es posible que las actualizaciones muy recientes de los registros de Cloud DNS no estén disponibles porque las actualizaciones se procesan primero en una sola región antes de replicarse de forma asíncrona en otras regiones.

Funciones de Cloud Run

Las funciones de Cloud Run son un entorno de procesamiento sin estado en el que los clientes pueden ejecutar su código de función en la infraestructura de Google. Las funciones de Cloud Run son una oferta regional, lo que significa que los clientes pueden elegir la región, pero no las zonas que la conforman. Las cargas de los datos y el tráfico se balancean de forma automática entre zonas de una región. Las funciones tienen ajuste de escala automático para cumplir con el tráfico entrante y sus cargas se balancean entre las zonas según sea necesario. Cada zona mantiene un programador que proporciona este ajuste de escala automático por zona. También tiene en cuenta la carga que reciben otras zonas y aprovisionará capacidad adicional en la zona para permitir fallas zonales.

Interrupción zonal: Las funciones de Cloud Run almacenan metadatos y la función implementada. Estos datos se almacenan de forma regional y se escriben de forma síncrona. La API de Admin de funciones de Cloud Run solo muestra la llamada a la API una vez que los datos se hayan confirmado en un quórum dentro de una región. Debido a que los datos se almacenan de forma regional, las operaciones del plano de datos tampoco se ven afectadas por las fallas zonales. El tráfico se enruta automáticamente a otras zonas en caso de una falla zonal.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean crear su función. Los datos nunca se replican en otras regiones. Las funciones de Cloud Run nunca enrutarán el tráfico de los clientes a una región diferente. En el caso de una falla regional, las funciones de Cloud Run volverán a estar disponibles en cuanto se resuelva la interrupción. Se recomienda a los clientes que implementen en varias regiones y que usen Cloud Load Balancing para lograr una mayor disponibilidad, si lo desean.

API de Cloud Healthcare

La API de Cloud Healthcare, un servicio para almacenar y administrar datos de atención médica, está diseñada a fin de proporcionar alta disponibilidad y ofrecer protección contra fallas zonales y regionales, según una configuración elegida.

Configuración regional: En su configuración predeterminada, la API de Cloud Healthcare ofrece protección contra fallas zonales. El servicio se implementa en tres zonas de una región, y los datos también se triplican en diferentes zonas dentro de la región. En caso de una falla zonal que afecte a la capa de servicio o de datos, las zonas restantes toman el control sin interrupciones. En la configuración regional, si una región completa en la que se encuentra el servicio experimenta una interrupción, el servicio no estará disponible hasta que la región vuelva a estar en línea. En el caso imprevisto de una destrucción física de una región completa, los datos almacenados en esa región se perderán.

Configuración multirregional: en su configuración multirregional, la API de Cloud Healthcare se implementa en tres zonas que pertenecen a tres regiones diferentes. Los datos también se replican en tres regiones. Esto protege contra la pérdida del servicio en caso de una interrupción en toda la región, ya que las regiones restantes tomarán el control de forma automática. Los datos estructurados, como FHIR, se replican de forma síncrona en varias regiones, por lo que están protegidos contra la pérdida de datos en caso de una interrupción en toda la región. Los datos que se almacenan en depósitos de Cloud Storage, como DICOM y Dictado o objetos grandes HL7v2/FHIR, se replican de manera asíncrona en varias regiones.

Cloud Identity

Los servicios de Cloud Identity se distribuyen en varias regiones y usan el balanceo de cargas dinámico. Cloud Identity no permite que los usuarios seleccionen un alcance de recurso. Si una zona o una región en particular experimenta una interrupción, el tráfico se distribuye de manera automática a otras zonas o regiones.

En la mayoría de los casos, los datos persistentes se duplican en varias regiones con replicación síncrona. Por motivos de rendimiento, algunos sistemas, como las caché o los cambios que afectan a una gran cantidad de entidades, se replican de manera asíncrona en todas las regiones. Si la región principal en la que se almacenan los datos más recientes experimenta una interrupción, Cloud Identity entrega datos obsoletos desde otra ubicación hasta que la región principal esté disponible.

Cloud Interconnect

Cloud Interconnect ofrece a los clientes acceso RFC 1918 a redes de Google Cloud desde sus centros de datos locales a través de cables físicos conectados al perímetro de intercambio de tráfico de Google.

Cloud Interconnect proporciona a los clientes un ANS del 99.9% si aprovisionan conexiones a dos EAD (dominios de disponibilidad perimetral) en un área metropolitana. Un ANS del 99.99% está disponible si el cliente aprovisiona conexiones en dos EAD en dos áreas metropolitanas y en dos regiones con enrutamiento global. Consulta la descripción general de la topología para aplicaciones no críticas y la descripción general de la topología para aplicaciones de nivel de producción para obtener más información.

Cloud Interconnect es independiente de la zona de procesamiento y proporciona alta disponibilidad en forma de EAD. En caso de una falla de EAD, la sesión de BGP para ese EAD se interrumpe y el tráfico se conmuta por error a otro EAD.

En el caso de una falla regional, las sesiones de BGP en esa región se interrumpen y el tráfico se conmuta por error a los recursos en la región de trabajo. Esto se aplica cuando el enrutamiento global está habilitado.

Cloud Key Management Service

Cloud Key Management Service (Cloud KMS) proporciona la administración de recursos de claves criptográficas escalables y de alta durabilidad. Cloud KMS almacena todos sus datos y metadatos en las bases de datos de Spanner, que proporcionan alta durabilidad y disponibilidad de datos con replicación síncrona.

Los recursos de Cloud KMS pueden crearse en una sola región, en varias regiones o de forma global.

En el caso de una interrupción zonal, Cloud KMS continúa entregando solicitudes desde otra zona en la misma región o en otra sin interrupciones. Debido a que los datos se replican de forma síncrona, no hay pérdida ni corrupción de datos. Cuando se resuelve la interrupción zonal, se restablece la redundancia total.

Si se produce una interrupción regional, los recursos regionales de esa región se encuentran sin conexión hasta que esta vuelve a estar disponible. Ten en cuenta que, incluso dentro de una región, se mantienen al menos 3 réplicas en zonas diferentes. Cuando se requiere una mayor disponibilidad, los recursos deben almacenarse en una configuración multirregional o global. Las configuraciones globales y multirregionales están diseñadas para permanecer disponibles durante una interrupción regional mediante el almacenamiento y la entrega de datos con redundancia geográfica en más de una región.

Cloud External Key Manager (Cloud EKM)

Cloud External Key Manager está integrado en Cloud Key Management Service para que puedas controlar y acceder a claves externas a través de socios externos compatibles. Puedes usar estas claves externas para encriptar los datos en reposo y usarlos en otros servicios de Google Cloud que admitan la integración de claves de encriptación administradas por el cliente (CMEK).

  • Interrupción zonal: Cloud External Key Manager es resistente a las interrupciones zonales debido a la redundancia que proporcionan varias zonas en una región. Si se produce una interrupción zonal, el tráfico se redirige a otras zonas dentro de la región. Mientras el tráfico se redirecciona, es posible que veas un aumento en los errores, pero el servicio aún está disponible.

  • Interrupción regional: Cloud External Key Manager no está disponible durante una interrupción regional en la región afectada. No hay un mecanismo de conmutación por error que redireccione las solicitudes entre regiones. Recomendamos que los clientes usen varias regiones para ejecutar sus trabajos.

Cloud External Key Manager no almacena ningún dato del cliente de forma persistente. Por lo tanto, no hay pérdida de datos durante una interrupción regional dentro del sistema de Cloud External Key Manager. Sin embargo, Cloud External Key Manager depende de la disponibilidad de otros servicios, como Cloud Key Management Service y proveedores externos. Si esos sistemas fallan durante una interrupción regional, podrías perder datos. El RPO/RTO de estos sistemas está fuera del alcance de los compromisos de Cloud External Key Manager.

Cloud Load Balancing

Cloud Load Balancing es un servicio administrado completamente distribuido y definido por software. Con Cloud Load Balancing, una sola dirección IP Anycast puede funcionar como frontend para backends en regiones de todo el mundo. No se basa en hardware, por lo que no es necesario que administres una infraestructura física de balanceo de cargas. Los balanceadores de cargas son un componente crítico de la mayoría de las aplicaciones con alta disponibilidad.

Cloud Load Balancing ofrece balanceadores de cargas regionales y globales. También proporciona un balanceo de cargas entre regiones con conmutación automática por error multirregional, que traslada el tráfico a los backends de conmutación por error si los backends principales están en mal estado.

Los balanceadores de cargas globales son resilientes a las interrupciones zonales y regionales. Los balanceadores de cargas regionales son resilientes a las interrupciones zonales, pero se ven afectados por las interrupciones en su región. Sin embargo, en cualquier caso, es importante comprender que la resiliencia de la aplicación en general depende no solo del tipo de balanceador de cargas que implementes, sino también de la redundancia de los backends.

Para obtener más información sobre Cloud Load Balancing y sus características, consulta Descripción general de Cloud Load Balancing.

Cloud Logging

Cloud Logging consta de dos partes principales: el enrutador de registros y el almacenamiento de Cloud Logging.

El enrutador de registros controla los eventos de registros de transmisión y dirige los registros a Cloud Storage, Pub/Sub, BigQuery o al almacenamiento de Cloud Logging.

El almacenamiento de Cloud Logging es un servicio para almacenar, consultar y administrar el cumplimiento de los registros. Es compatible con muchos usuarios y flujos de trabajo, incluidos el desarrollo, el cumplimiento, la solución de problemas y las alertas proactivas.

Enrutador de registros y registros entrantes: Durante una interrupción zonal, la API de Cloud Logging enruta los registros a otras zonas de la región. Por lo general, los registros que enruta el enrutador de registros a Cloud Logging, BigQuery o Pub/Sub se escriben en su destino final lo antes posible, mientras que los registros enviados a Cloud Storage se almacenan en el búfer y se escriben en lotes por hora.

Entradas de registro: Si se produce una interrupción zonal o regional, las entradas de registro que se almacenaron en el búfer de la zona o la región afectada y que no se escribieron en el destino de exportación se vuelven inaccesibles. Las métricas basadas en registros también se calculan en el enrutador de registros y están sujetas a las mismas restricciones. Una vez que se entregan a la ubicación de exportación de registros seleccionada, los registros se replican según el servicio de destino. Los registros que se exportan al almacenamiento de Cloud Logging se replican de forma síncrona en dos zonas de una región. Para obtener información sobre el comportamiento de replicación de otros tipos de destino, consulta la sección relevante en este artículo. Ten en cuenta que los registros exportados a Cloud Storage se agrupan por lotes y se escriben cada hora. Por lo tanto, recomendamos usar el almacenamiento de Cloud Logging, BigQuery o Pub/Sub para minimizar la cantidad de datos afectados por una interrupción.

Metadatos de registro: Los metadatos como la configuración de receptores y de la exclusión se almacenan a nivel global, pero en caché a nivel regional. Si se produce una interrupción, las instancias regionales del enrutador de registros operarían. Las interrupciones en una sola región no tienen impacto fuera de la región.

Cloud Monitoring

Cloud Monitoring consta de una variedad de funciones interconectadas, como paneles (tanto integrados como definidos por el usuario), alertas y supervisión del tiempo de actividad.

Toda la configuración de Cloud Monitoring, incluidos los paneles, las verificaciones de tiempo de actividad y las políticas de alertas, se definen de forma global. Todos los cambios en ellos se replican de forma síncrona en varias regiones. Por lo tanto, durante las interrupciones zonales y regionales, los cambios de configuración exitosos son duraderos. Además, aunque las fallas transitorias de lectura y escritura pueden ocurrir cuando una zona o región falla al principio, Cloud Monitoring redirige las solicitudes hacia las zonas y regiones disponibles. En esta situación, puedes volver a intentar los cambios de configuración con la retirada exponencial.

Cuando escribes métricas para un recurso específico, Cloud Monitoring primero identifica la región en la que reside el recurso. Luego, escribe tres réplicas independientes de los datos de métricas dentro de la región. La escritura general de las métricas regionales se muestra en cuanto se completa correctamente una de las tres escrituras. No se garantiza que las tres réplicas estén en zonas diferentes dentro de la región.

  • Zonal: Durante una interrupción zonal, las operaciones de escritura y lectura de métricas no están disponibles para los recursos en la zona afectada. Efectivamente, Cloud Monitoring actúa como si la zona afectada no existiera.

  • Regional: durante una interrupción regional, las operaciones de escritura y lectura de métricas no están disponibles para los recursos en la región afectada. Efectivamente, Cloud Monitoring actúa como la región afectada no existe.

Cloud NAT

Cloud NAT (traducción de direcciones de red) es un servicio administrado distribuido y definido por software que permite que ciertos recursos sin direcciones IP externas creen conexiones salientes a Internet. No se basa en los dispositivos o VM del proxy. Cloud NAT configura el software Andromeda que potencia tu red de nube privada virtual (VPC) de manera que proporcione la traducción de direcciones de red (de origen NAT o SNAT) para VM sin direcciones IP externas. Cloud NAT también proporciona la traducción de direcciones de red (de destino NAT o DNAT) para los paquetes de respuesta entrantes establecidos.

Para obtener más información sobre la funcionalidad de Cloud NAT, consulta la documentación.

Interrupción zonal: Cloud NAT es resistente a las fallas zonales porque el plano de control y el plano de datos de red son redundantes en varias zonas dentro de una región.

Interrupción regional: Cloud NAT es un producto regional, por lo que no puede resistir una falla regional.

Cloud Router

Cloud Router es un servicio de Google Cloud totalmente distribuido y administrado que usa el Protocolo de Puerta de Enlace Fronteriza (BGP) para anunciar rangos de direcciones IP. Programa rutas dinámicas personalizadas en función de los anuncios de BGP que recibe de un par. En lugar de un dispositivo o dispositivo físico, cada Cloud Router consta de tareas de software que actúan como interlocutores y respuestas de BGP.

En el caso de una interrupción zonal, Cloud Router con una configuración de alta disponibilidad (HA) es resistente a las fallas zonales. En ese caso, una interfaz podría perder conectividad, pero el tráfico se redirecciona a la otra interfaz a través del enrutamiento dinámico mediante BGP.

En el caso de una interrupción regional, Cloud Router es un producto regional, por lo que no puede resistir una falla regional. Si los clientes habilitaron el modo de enrutamiento global, el enrutamiento entre la región con errores y otras regiones podría verse afectado.

Cloud Run

Cloud Run es un entorno de computación sin estado en el que los clientes pueden ejecutar su código alojado en contenedores en la infraestructura de Google. Cloud Functions es una oferta regional, lo que significa que los clientes pueden elegir la región, pero no las zonas que la conforman. Las cargas de los datos y el tráfico se balancean de forma automática entre zonas de una región. Las instancias de contenedor cuentan con ajuste de escala automático para cumplir con el tráfico entrante y se balancean las cargas entre las zonas según sea necesario. Cada zona mantiene un programador que proporciona este ajuste de escala automático por zona. También tiene en cuenta la carga que reciben otras zonas y aprovisionará capacidad adicional en la zona para permitir fallas zonales.

Interrupción zonal: Cloud Run almacena metadatos, así como el contenedor implementado. Estos datos se almacenan de forma regional y se escriben de forma síncrona. La API de Cloud Run Admin solo muestra la llamada a la API una vez que los datos se confirmaron en un quórum dentro de una región. Debido a que los datos se almacenan de forma regional, las operaciones del plano de datos tampoco se ven afectadas por las fallas zonales. El tráfico se enrutará automáticamente a otras zonas en caso de una falla zonal.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean crear su servicio de Cloud Run. Los datos nunca se replican en otras regiones. Cloud Functions nunca enrutará el tráfico del cliente a una región diferente. En el caso de una falla regional, Cloud Run volverá a estar disponible en cuanto se resuelva la interrupción. Se recomienda a los clientes que implementen en varias regiones y que usen Cloud Load Balancing para lograr una mayor disponibilidad, si lo desean.

Cloud Shell

Cloud Shell proporciona a los usuarios de Google Cloud acceso a instancias de Compute Engine para un solo usuario que están preconfiguradas para tareas de integración, educación, desarrollo y operador.

Cloud Shell no es adecuado para ejecutar cargas de trabajo de aplicaciones y, en su lugar, está diseñado para casos de uso de desarrollo y educativo interactivos. Tiene límites de cuota del entorno de ejecución por usuario, se cierra automáticamente después de un período corto de inactividad y solo el usuario asignado puede acceder a la instancia.

Las instancias de Compute Engine que respaldan el servicio son recursos zonales, por lo que, en caso de una interrupción zonal, Cloud Shell del usuario no está disponible.

Cloud Source Repositories

Cloud Source Repositories permite a los usuarios crear y administrar repositorios de código fuente privados. Este producto está diseñado con un modelo global, por lo que no necesitas configurarlo para la resiliencia regional o zonal.

En cambio, las operaciones git push en Cloud Source Repositories replican de forma síncrona la actualización del repositorio de código fuente en varias zonas en varias regiones. Esto significa que el servicio es resistente a las interrupciones en cualquier región.

Si una zona o una región en particular experimenta una interrupción, el tráfico se distribuye de manera automática a otras zonas o regiones.

La función para duplicar de forma automática los repositorios de GitHub o Bitbucket puede verse afectada por problemas en esos productos. Por ejemplo, la duplicación se ve afectada si GitHub o Bitbucket no pueden alertar a Cloud Source Repositories de confirmaciones nuevas o si Cloud Source Repositories no puede recuperar contenido del repositorio actualizado.

Spanner

Spanner es una base de datos escalable, de alta disponibilidad, de varias versiones, replicada de forma síncrona y de coherencia sólida con semántica relacional.

Las instancias regionales de Spanner replican los datos de manera síncrona en tres zonas de una misma región. Una operación de escritura a una instancia regional de Spanner se envía de forma síncrona a las 3 réplicas y se confirma al cliente después de que al menos 2 réplicas (quórum de mayoría de 2 de 3) confirmen la escritura. Esto hace que Spanner sea resistente a la falla de zona, lo que proporciona acceso a todos los datos, ya que las escrituras más recientes se mantuvieron y se puede obtener un quórum mayor para operaciones de escritura con 2 réplicas.

Las instancias multirregionales de Spanner incluyen un quórum de escritura que replica datos de forma síncrona en 5 zonas ubicadas en tres regiones (dos réplicas de lectura y escritura cada una en la región líder predeterminada y otra región; y una réplica en la región testigo). Una operación de escritura en una instancia multirregional de Spanner se confirma después de que al menos 3 réplicas (quórum de mayoría de 3 de 5) hayan confirmado la escritura. En el caso de una falla de zona o región, Spanner tiene acceso a todos los datos (incluidas las escrituras más recientes) y entrega solicitudes de lectura y escritura, ya que los datos se conservan en al menos 3 zonas en 2 regiones en el momento en que la escritura se confirma al cliente.

Consulta la documentación de instancias de Spanner para obtener más información sobre estas configuraciones y la documentación de replicación para obtener más información sobre cómo funciona la replicación de Spanner.

Cloud SQL

Cloud SQL es un servicio de base de datos relacional completamente administrado para MySQL, PostgreSQL y SQL Server. Cloud SQL usa máquinas virtuales administradas de Compute Engine para ejecutar el software de base de datos. Ofrece una configuración de alta disponibilidad para la redundancia regional, lo que protege la base de datos ante una interrupción zonal. Las réplicas entre regiones pueden aprovisionarse para proteger la base de datos ante una interrupción regional. Debido a que el producto también ofrece una opción zonal, que no es resiliente ante una interrupción zonal o regional, debes tener cuidado cuando seleccionas la configuración de alta disponibilidad, las réplicas entre regiones o ambas.

Interrupción zonal: La opción de alta disponibilidad crea una instancia de VM principal y en espera en dos zonas distintas dentro de una región. Durante el funcionamiento normal, la instancia de VM principal entrega todas las solicitudes y escribe los archivos de la base de datos en un disco persistente regional, que se replica de forma síncrona en las zonas principal y de espera. Si una interrupción zonal afecta a la instancia principal, Cloud SQL inicia una conmutación por error durante la cual el disco persistente se conecta a la VM en espera y el tráfico se redirige.

Durante este proceso, se debe inicializar la base de datos, lo que incluye el procesamiento de cualquier transacción escrita en el registro de transacciones, pero que no está aplicada a la base de datos. La cantidad y el tipo de transacciones sin procesar pueden aumentar el tiempo de RTO. Las operaciones de escritura recientes pueden provocar una acumulación de transacciones sin procesar. El tiempo de RTO se ve muy afectado por (a) la actividad de escritura reciente y (b) los cambios recientes en los esquemas de base de datos.

Por último, cuando se resuelve la interrupción zonal, puedes activar de forma manual una operación de recuperación para reanudar la entrega en la zona principal.

Para obtener más detalles sobre la opción de alta disponibilidad, consulta la documentación de alta disponibilidad de Cloud SQL.

Interrupción regional: La opción de réplica entre regiones protege tu base de datos ante las interrupciones regionales mediante la creación de réplicas de lectura de la instancia principal en otras regiones. La replicación entre regiones usa la replicación asíncrona, que permite que la instancia principal confirme las transacciones antes de que se confirmen en las réplicas. La diferencia de tiempo entre el momento en que una transacción se confirma en la instancia principal y en que se confirma en la réplica se conoce como “demora de replicación” (que se puede supervisar). Esta métrica refleja las transacciones que no se enviaron desde la instancia principal a las réplicas y las que se recibieron, pero que aún la réplica no procesó. Las transacciones que no se envíen a la réplica no estarán disponibles durante una interrupción regional. Las transacciones recibidas que la réplica aún no procesó afectan el tiempo de recuperación, como se describe a continuación.

Cloud SQL recomienda probar la carga de trabajo con una configuración que incluya una réplica para establecer un límite de “seguro de transacciones por segundo(TPS)”, que es el TPS continuo más alto que no acumula demora de replicación. Si la carga de trabajo excede el límite seguro de TPS, la demora de replicación se acumula, lo que afecta de manera negativa los valores de RPO y RTO. Como regla general, evita usar configuraciones de instancias pequeñas (<2 núcleos de CPU virtual, <100 GB de disco o HDD de PD), que son susceptibles a las demoras de replicación.

Si se produce una interrupción regional, debes decidir si promueves una réplica de lectura de forma manual. Esta es una operación manual, ya que la promoción puede causar una situación de cerebro dividido en la que la réplica promocionada acepta transacciones nuevas a pesar de que haber demorado la instancia principal en el momento de la promoción. Esto puede causar problemas cuando se resuelve la interrupción regional y deberás conciliar las transacciones que nunca se propagaron de la instancia principal a las réplicas. Si esto resulta problemático para tus necesidades, puedes considerar usar un producto de base de datos de replicación síncrona entre regiones como Spanner.

Una vez que el usuario lo activa, el proceso de promoción sigue pasos similares a la de una instancia en espera en la configuración de alta disponibilidad. En ese proceso, la réplica de lectura debe procesar el registro de transacciones, lo que genera el tiempo de recuperación total. Debido a que no hay un balanceador de cargas integrado en la promoción de la réplica, redirecciona las aplicaciones de forma manual a la instancia principal ascendida.

Para obtener más detalles sobre la opción de réplica entre regiones, consulta la documentación de réplica entre regiones de Cloud SQL.

Para obtener más información sobre la DR de Cloud SQL, consulta los siguientes vínculos:

Cloud Storage

Cloud Storage proporciona almacenamiento de objetos unificado, escalable y con alta durabilidad a nivel global. Los buckets de Cloud Storage se pueden crear en uno de tres tipos de ubicaciones diferentes: en una sola región, en una región doble o en una multirregión dentro de un continente. Con los buckets regionales, los objetos se almacenan de manera redundante en todas las zonas de disponibilidad de una sola región. Por el contrario, los buckets birregionales y multirregionales tienen redundancia geográfica. Esto significa que después de que los datos recién escritos se repliquen en al menos una región remota, los objetos se almacenan de manera redundante en todas las regiones. Este enfoque les brinda a los datos en buckets birregionales y multirregionales un conjunto de protecciones más amplio de lo que se puede lograr con el almacenamiento regional.

Los buckets regionales están diseñados para ser resilientes en caso de una interrupción en una sola zona de disponibilidad. Si una zona experimenta una interrupción, los datos en la zona no disponible se entregan de forma automática y transparente desde cualquier otro lugar de la región. Los datos y los metadatos se almacenan de manera redundante en todas las zonas, a partir de la escritura inicial. Las escrituras no se pierden si una zona deja de estar disponible. En el caso de una interrupción regional, los buckets regionales de esa región permanecen sin conexión hasta que la región vuelve a estar disponible.

Si necesitas más disponibilidad, puedes almacenar datos en una configuración birregional o multirregional. Los buckets birregionales y multirregionales son buckets individuales (sin ubicaciones principales y secundarias independientes), pero almacenan datos y metadatos de forma redundante en todas las regiones. Si se produce una interrupción regional, la entrega no se interrumpe. Puedes pensar en los buckets birregionales y multirregionales como activos-activos en cuanto a que puedes leer y escribir las cargas de trabajo en más de una región al mismo tiempo que el bucket mantiene una coherencia sólida. Esto puede ser muy atractivo para los clientes que desean dividir su carga de trabajo en las dos regiones como parte de una arquitectura de recuperación ante desastres.

Las regiones dobles y múltiples tienen coherencia sólida porque los metadatos siempre se escriben de forma síncrona en las regiones. Este enfoque permite que el servicio siempre determine cuál es la última versión de un objeto y desde dónde se puede entregar, incluso desde regiones remotas.

Los datos se replican de forma asíncrona. Esto significa que hay un período de RPO en el que los objetos recién escritos comienzan protegidos como objetos regionales, con redundancia en las zonas de disponibilidad dentro de una sola región. Luego, el servicio replica los objetos dentro de esa ventana de RPO en una o más regiones remotas para que tengan redundancia geográfica. Una vez completada esa replicación, los datos se pueden entregar de forma automática y transparente desde otra región en el caso de una interrupción regional. La replicación turbo es una función premium disponible en un bucket birregional para obtener una ventana de RPO más pequeña, que apunta al 100% de los objetos recién escritos que se replican y hace que la ubicación tenga redundancia geográfica en 15 minutos.

El RPO es una consideración importante, ya que, durante una interrupción regional, es posible que los datos escritos recientemente en la región afectada dentro del período de RPO aún no se hayan replicado en otras regiones. Como resultado, es posible que no se pueda acceder a los datos durante la interrupción y que se pierdan en caso de una destrucción física de los datos en la región afectada.

Cloud Translation

Cloud Translation tiene servidores de procesamiento activos en varias zonas y regiones. También admite la replicación de datos síncrona entre zonas dentro de las regiones. Estas funciones ayudan a Translation a lograr una conmutación por error instantánea sin perder datos para las fallas zonales y sin la necesidad de entradas o ajustes de los clientes. En el caso de una falla regional, Cloud Translation no está disponible.

Compute Engine

Compute Engine es una de las opciones de infraestructura como servicio de Google Cloud. Usa la infraestructura mundial de Google para ofrecer máquinas virtuales (y servicios relacionados) a los clientes.

Las instancias de Compute Engine son recursos zonales, por lo que, en caso de que se produzca una interrupción zonal, las instancias no están disponibles de forma predeterminada. Compute Engine ofrece grupos de instancias administrados (MIG) que pueden escalar automáticamente VMs adicionales a partir de plantillas de instancias preconfiguradas, tanto dentro de una sola zona como en varias zonas dentro de una región. Los MIG son ideales para las aplicaciones sin estado y que requieren resiliencia ante la pérdida zonal, pero que necesitan configuración y planificación de recursos. Se pueden usar varios MIG regionales a fin de lograr resiliencia ante interrupciones regionales para las aplicaciones sin estado.

Las aplicaciones que tienen cargas de trabajo con estado aún pueden usar MIG con estado, pero necesitan atención adicional en la planificación de la capacidad, ya que no se escalan horizontalmente. En ambos casos, es importante configurar y probar de manera correcta las plantillas de instancias y los MIG de Compute Engine con anticipación para garantizar que las funciones de conmutación por error funcionen en otras zonas. Consulta la sección anterior Desarrolla tus propias arquitecturas y guías de referencia para obtener más información.

Usuario único

El usuario único te permite tener acceso exclusivo a un nodo de usuario único, que es un servidor físico de Compute Engine dedicado a alojar solo las VMs de tu proyecto.

Los nodos de usuario único, como las instancias de Compute Engine, son recursos zonales. En el caso improbable de una interrupción zonal, no están disponibles. Para mitigar las fallas zonales, puedes crear un nodo de usuario único en otra zona. Dado que ciertas cargas de trabajo pueden beneficiarse de nodos de usuario único para fines de licencia o contabilización de CAPEX, debes planificar una estrategia de conmutación por error con anticipación.

Volver a crear estos recursos en una ubicación diferente puede generar costos adicionales de licencias o infringir los requisitos de contabilización de CAPEX. Para obtener orientación general, consulta Desarrolla tus propias arquitecturas y guías de referencia.

Los nodos de usuario único son recursos zonales y no pueden resistir fallas regionales. Para escalar entre zonas, usa MIG regionales.

Herramientas de redes para Compute Engine

Para obtener información sobre las opciones de configuración de alta disponibilidad para conexiones de interconexión, consulta los siguientes documentos:

Puedes aprovisionar direcciones IP externas en modo global o regional, lo que afecta su disponibilidad en caso de una falla regional.

Resiliencia de Cloud Load Balancing

Los balanceadores de cargas son un componente crítico de la mayoría de las aplicaciones con alta disponibilidad. Es importante comprender que la resiliencia de la aplicación en general depende no solo del alcance del balanceador de cargas que elijas (global o regional), sino también de la redundancia de los servicios de backend.

En la siguiente tabla, se resume la resiliencia del balanceador de cargas según la distribución o el alcance del balanceador de cargas.

Alcance del balanceador de cargas Arquitectura Resiliente a una interrupción zonal Resistente a las interrupciones regionales
Global Cada balanceador de cargas se distribuye por todas las regiones
Interregión Cada balanceador de cargas se distribuye por varias regiones
Regional Cada balanceador de cargas se distribuye en varias zonas de la región Una interrupción en una región determinada afecta a los balanceadores de cargas regionales en esa región.

Si deseas obtener más información para elegir un balanceador de cargas, consulta la documentación de Cloud Load Balancing.

Pruebas de conectividad

Las pruebas de conectividad son una herramienta de diagnóstico que te permite verificar la conectividad entre los extremos de red. Analizan tu configuración y, en algunos casos, realizan un análisis del plano de datos en vivo entre los extremos. Un extremo es una fuente o un destino del tráfico de red, como una VM, un clúster de Google Kubernetes Engine (GKE), una regla de reenvío del balanceador de cargas o una dirección IP. Las pruebas de conectividad son una herramienta de diagnóstico sin componentes del plano de datos. No procesa ni genera tráfico de usuario.

Interrupción zonal: Los recursos de las pruebas de conectividad son globales. Puedes administrarlas y verlas en caso de una interrupción zonal. Los recursos de pruebas de conectividad son los resultados de tus pruebas de configuración. Estos resultados pueden incluir los datos de configuración de los recursos zonales (por ejemplo, las instancias de VM) en una zona afectada. Si hay una interrupción, los resultados del análisis no son precisos porque el análisis se basa en datos obsoletos antes de la interrupción. No dependas de él.

Interrupción regional: En una interrupción regional, aún puedes administrar y ver los recursos de las pruebas de conectividad. Los recursos de las pruebas de conectividad pueden incluir datos de configuración de recursos regionales, como subredes, en una región afectada. Si hay una interrupción, los resultados del análisis no son precisos porque el análisis se basa en datos obsoletos antes de la interrupción. No dependas de él.

Container Registry

Container Registry proporciona una implementación escalable y alojada de Docker Registry que almacena de forma segura y privada las imágenes de contenedor de Docker. Container Registry implementa la API de Docker Registry de HTTP.

Container Registry es un servicio global que almacena de forma síncrona los metadatos de imágenes de manera redundante en varias zonas y regiones según la configuración predeterminada. Las imágenes de contenedor se almacenan en depósitos multirregionales de Cloud Storage. Con esta estrategia de almacenamiento, Container Registry proporciona resiliencia ante interrupciones zonales en todos los casos y ante interrupciones regionales para cualquier dato que Cloud Storage haya replicado de manera asíncrona en varias regiones.

Database Migration Service

Database Migration Service es un servicio de Google Cloud completamente administrado para migrar bases de datos de otros proveedores de servicios en la nube o desde centros de datos locales a Google Cloud.

Database Migration Service está diseñado como un plano de control regional. El plano de control no depende de una zona individual en una región determinada. Durante una interrupción zonal, conservas el acceso a las API de Database Migration Service, incluida la capacidad de crear y administrar trabajos de migración. Durante una interrupción regional, perderás el acceso a los recursos del Database Migration Service que pertenecen a esa región hasta que se resuelva la interrupción.

Database Migration Service depende de la disponibilidad de las bases de datos de origen y de destino que se usan para el proceso de migración. Si una base de datos de origen o de destino de Database Migration Service no está disponible, las migraciones dejan de avanzar, pero no se pierden los datos principales del trabajo ni de los clientes. Los trabajos de migración se reanudan cuando las bases de datos de origen y de destino vuelven a estar disponibles.

Por ejemplo, puedes configurar una base de datos de destino de Cloud SQL con alta disponibilidad (HA) habilitada para obtener una base de datos de destino que sea resistente a las interrupciones por zona.

Las migraciones de Database Migration Service pasan por dos fases:

  • Volcado completo: Realiza una copia de datos completa de la fuente al destino de acuerdo con la especificación del trabajo de migración.
  • Captura de datos modificados (CDC): Replica los cambios incrementales de la fuente al destino.

Interrupción zonal: Si se produce una falla zonal durante cualquiera de estas fases, aún puedes acceder y administrar recursos en Database Migration Service. La migración de datos se ve afectada de la siguiente manera:

  • Volcado completo: La migración de datos falla. Debes reiniciar el trabajo de migración una vez que la base de datos de destino complete la operación de conmutación por error.
  • CDC: La migración de datos está pausada. El trabajo de migración se reanuda de forma automática una vez que la base de datos de destino completa la operación de conmutación por error.

Interrupción regional: Database Migration Service no admite recursos interregionales y, por lo tanto, no es resistente contra fallas regionales.

Dataflow

Dataflow es el servicio de procesamiento de datos sin servidores y completamente administrado de Google Cloudpara canalizaciones de transmisión y por lotes. De forma predeterminada, un extremo regional configura el grupo de trabajadores de Dataflow para que use todas las zonas disponibles dentro de la región. La selección de zona se calcula para cada trabajador en el momento en que se crea, lo que optimiza la adquisición de recursos y el uso de reservations sin usar. En la configuración predeterminada para los trabajos de Dataflow, el servicio de Dataflow almacena los datos intermedios y el estado del trabajo se almacena en el backend. Si una zona falla, los trabajos de Dataflow pueden seguir ejecutándose, ya que los trabajadores se vuelven a crear en otras zonas.

Se aplica la siguiente limitación:

  • La posición regional solo es compatible con trabajos que usan Streaming Engine o Dataflow Shuffle. Los trabajos que inhabilitaron Streaming Engine o Dataflow Shuffle no pueden usar la posición regional.
  • La posición regional solo se aplica a las VMs. No se aplica a los recursos relacionados con Streaming Engine ni Dataflow Shuffle.
  • Las VMs no se replican en varias zonas. Si una VM deja de estar disponible, sus elementos de trabajo se consideran perdidos y otra VM los vuelve a procesar.
  • Si se produce un agotamiento de disponibilidad en toda la región, el servicio de Dataflow no puede crear más VM.

Diseña las canalizaciones de Dataflow para alta disponibilidad

Puedes ejecutar varias canalizaciones de transmisión en paralelo para el procesamiento de datos de alta disponibilidad. Por ejemplo, puedes ejecutar dos trabajos de transmisión paralelos en diferentes regiones. La ejecución de canalizaciones paralelas proporciona redundancia geográfica y tolerancia a errores para el procesamiento de datos. Si consideras la disponibilidad geográfica de las fuentes de datos y los receptores, puedes operar canalizaciones de extremo a extremo en una configuración multirregional con alta disponibilidad. Para obtener más información, consulta Alta disponibilidad y redundancia geográfica en “Diseña flujos de trabajo de canalización de Dataflow”.

En el caso de una interrupción zonal o regional, puedes evitar la pérdida de datos si vuelves a usar la misma suscripción en el tema de Pub/Sub. Para garantizar que los registros no se pierdan durante la redistribución, Dataflow usa la copia de seguridad ascendente, lo que significa que el trabajador que envía los registros reintenta las RPC hasta que recibe una confirmación de recepción positiva del registro y que los efectos secundarios de procesar el registro se confirman en el almacenamiento persistente más adelante. Dataflow también vuelve a intentar las RPC si el trabajador que envía los registros deja de estar disponible. Volver a intentar las RPC garantiza que cada registro se entregue exactamente una vez. Para obtener más información sobre la garantía de Dataflow del tipo “exactamente una vez”, consulta Exactamente una vez en Dataflow.

Si la canalización usa la agrupación o el sistema de ventanas de tiempo, puedes usar la funcionalidad Búsqueda de Pub/Sub o Volver a reproducir de Kafka después de una interrupción zonal o regional para volver a procesar los elementos de datos a fin de llegar al mismo resultado de cálculo. Si la lógica empresarial que usa la canalización no depende de los datos antes de la interrupción, la pérdida de datos de los resultados de la canalización se puede minimizar a 0 elementos. Si la lógica empresarial de la canalización se basa en datos que se procesaron antes de la interrupción (por ejemplo, si se usan ventanas variables de larga duración o si un período global almacena contadores en aumento), usa lo siguiente: Instantáneas de Dataflow para guardar el estado de la canalización de transmisión y, luego, iniciar una versión nueva de tu trabajo sin perder el estado.

Dataproc

Dataproc proporciona capacidades de transmisión y procesamiento de datos por lotes. Dataproc se diseñó como un plano de control regional que permite a los usuarios administrar clústeres de Dataproc. El plano de control no depende de una zona individual en una región determinada. Por lo tanto, durante una interrupción zonal, conservas el acceso a las API de Dataproc, incluida la capacidad de crear clústeres nuevos.

Puedes crear clústeres de Dataproc en los siguientes clústeres:

Clústeres de Dataproc en Compute Engine

Debido a que un clúster de Dataproc en Compute Engine es un recurso zonal, una interrupción zonal hace que el clúster deje de estar disponible o lo destruye. Dataproc no realiza instantáneas del estado del clúster de forma automática, por lo que una interrupción zonal podría provocar la pérdida de datos que se están procesando. Dataproc no conserva datos del usuario dentro del servicio. Los usuarios pueden configurar sus canalizaciones para que escriban resultados en muchos almacenes de datos. Debes considerar la arquitectura del almacén de datos y elegir un producto que ofrezca la resiliencia ante desastres necesaria.

Si una zona sufre una interrupción, puedes volver a crear una instancia nueva del clúster en otra zona, ya sea si seleccionas una zona diferente o usas la función de posición automática en Dataproc para seleccionar de forma automática una zona disponible. Una vez que el clúster está disponible, se puede reanudar el procesamiento de datos. También puedes ejecutar un clúster con el modo de alta disponibilidad habilitado, lo que reduce la probabilidad de que una interrupción zonal parcial afecte un nodo principal y, por lo tanto, a todo el clúster.

Clústeres de Dataproc en GKE

Los clústeres de Dataproc en GKE pueden ser zonales o regionales.

Para obtener más información sobre la arquitectura y las capacidades de DR de los clústeres de GKE zonales y regionales, consulta la sección de Google Kubernetes Engine más adelante en este documento.

DataStream

Datastream es un servicio de captura de datos modificados (CDC) y replicación sin servidores que te permite sincronizar datos de forma confiable y con una latencia mínima. Datastream proporciona la replicación de datos de bases de datos operativas en BigQuery y Cloud Storage. Además, ofrece una integración optimizada con las plantillas de Dataflow para crear flujos de trabajo personalizados para cargar datos en una amplia variedad de destinos, como Cloud SQL y Spanner.

Interrupción zonal: Datastream es un servicio multizonal. Puede soportar una interrupción zonal completa y no planificada sin perder datos ni disponibilidad. Si se produce una falla zonal, podrás acceder a tus recursos y administrarlos en Datastream.

Interrupción regional: En el caso de una interrupción regional, Datastream vuelve a estar disponible en cuanto se resuelve la interrupción.

Document AI

Document AI es una plataforma de comprensión de documentos que toma datos no estructurados de documentos y los transforma en datos estructurados, lo que facilita su análisis, análisis y consumo. Document AI es una oferta regional. Los clientes pueden elegir la región, pero no las zonas dentro de ella. Las cargas de los datos y el tráfico se balancean de forma automática entre zonas de una región. Los servidores tienen ajuste de escala automático para cumplir con el tráfico entrante y sus cargas se balancean entre las zonas según sea necesario. Cada zona mantiene un programador que proporciona este ajuste de escala automático por zona. El programador también está al tanto de la carga que reciben otras zonas y aprovisiona capacidad adicional en la zona para permitir fallas zonales.

Interrupción zonal: Document AI almacena documentos de usuarios y datos de versiones de procesadores. Estos datos se almacenan de forma regional y se escriben de manera síncrona. Debido a que los datos se almacenan de forma regional, las operaciones del plano de datos no se ven afectadas por las fallas zonales. El tráfico se enruta automáticamente a otras zonas en caso de una falla zonal, con un retraso en función del tiempo que tardan los servicios dependientes, como Vertex AI, en recuperarse.

Interrupción regional: Los datos nunca se replican en todas las regiones. Durante una interrupción regional, Document AI no realizará una conmutación por error. Los clientes eligen la región de Google Cloud en la que desean usar Document AI. Sin embargo, ese tráfico de clientes nunca se enruta a otra región.

Verificación de extremos

Endpoint Verification permite que los administradores y los profesionales de operaciones de seguridad compilen un inventario de dispositivos que acceden a los datos de una organización. Endpoint Verification también proporciona confianza en el dispositivo y control de acceso basado en la seguridad como parte de la solución de Chrome Enterprise Premium.

Usa la Endpoint Verification cuando quieras una descripción general de la postura de seguridad de los dispositivos laptop y de escritorio de tu organización. Cuando Endpoint Verification se combina con las ofertas de Chrome Enterprise Premium, ayuda a aplicar un control de acceso detallado en tus recursos de Google Cloud .

La verificación de extremos está disponible para Google Cloud, Cloud Identity, Google Workspace Business y Google Workspace Enterprise.

Eventarc

Eventarc proporciona eventos de forma asíncrona de los proveedores de Google (de origen), las apps de usuario (secundarias) y el software como servicio (de terceros) mediante servicios con acoplamiento bajo que reaccionan a los cambios de estado. Permite que los clientes configuren sus destinos (por ejemplo, una instancia de Cloud Run o una función de Cloud Run de 2ª gen.) para que se activen cuando se produce un evento en un servicio de proveedor de eventos o en el código del cliente.

Interrupción zonal: Eventarc almacena metadatos relacionados con los activadores. Estos datos se almacenan de forma regional y se escriben de manera síncrona. La API de Eventarc que crea y administra activadores y canales solo muestra la llamada a la API cuando los datos se confirmaron en un quórum dentro de una región. Debido a que los datos se almacenan de forma regional, las operaciones del plano de datos no se ven afectadas por las fallas zonales. En caso de una falla zonal, el tráfico se enruta de forma automática a otras zonas. Los servicios de Eventarc para recibir y entregar eventos secundarios y de terceros se replican en todas las zonas. Estos servicios se distribuyen regionalmente. Las solicitudes a zonas no disponibles se entregan de forma automática desde las zonas disponibles en la región.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean crear sus activadores de Eventarc. Los datos nunca se replican en otras regiones. Eventarc nunca enruta el tráfico del cliente a una región diferente. En el caso de una falla regional, Eventarc volverá a estar disponible en cuanto se resuelva la interrupción. Para lograr una mayor disponibilidad, se recomienda a los clientes que implementen activadores en varias regiones si lo desean.

Ten en cuenta lo siguiente:

  • Los servicios de Eventarc para recibir y entregar eventos de origen se proporcionan según el criterio del mejor esfuerzo y no están cubiertos por RTO/RPO.
  • La entrega de eventos de Eventarc para los servicios de Google Kubernetes Engine se proporciona según el criterio del mejor esfuerzo y no está cubierta por RTO/RPO.

Filestore

Los niveles Basic y HighScale son recursos zonales. No toleran las fallas de la zona o región implementada.

Las instancias de Filestore de nivel empresarial son recursos regionales. Filestore adopta la política de coherencia estricta que requiere NFS. Cuando un cliente escribe datos, Filestore no muestra una confirmación hasta que el cambio se conserve y se replique en dos zonas, de modo que las lecturas posteriores muestren los datos correctos.

En caso de una falla en la zona, una instancia de nivel empresarial continúa entregando datos desde otras zonas y, mientras tanto, acepta operaciones de escritura nuevas. Las operaciones de lectura y escritura pueden tener un rendimiento degradado y es posible que la operación de escritura no se replique. La encriptación no se ve comprometida porque la clave se entregará desde otras zonas.

Recomendamos que los clientes creen copias de seguridad externas en caso de más interrupciones en otras zonas de la misma región. La copia de seguridad se puede usar para restablecer la instancia en otras regiones.

Firestore

Firestore es una base de datos flexible y escalable para el desarrollo en servidores, dispositivos móviles y la Web desde Firebase y Google Cloud. Firestore ofrece replicación automática de datos multirregión, garantías de coherencia sólida, operaciones atómicas por lotes y transacciones ACID.

Firestore ofrece a los clientes ubicaciones únicas de región única y multirregionales. Las cargas del tráfico se balancean automáticamente entre las zonas de una región.

Las instancias regionales de Firestore replican los datos en al menos tres zonas de forma síncrona. En el caso de una falla zonal, las dos réplicas (o más) restantes aún pueden confirmar las escrituras, y los datos confirmados se conservan. El tráfico se enruta de forma automática a otras zonas. Una ubicación regional ofrece costos más bajos, una latencia de escritura más baja y la colocalización con otros recursos de Google Cloud.

Las instancias multirregionales de Firestore replican los datos de forma síncrona en cinco zonas de tres regiones (dos regiones de entrega y una región testigo) y tienen solidez ante fallas zonales y regionales. En el caso de una falla zonal o regional, los datos confirmados se conservan. El tráfico se enruta de forma automática a las zonas o regiones de entrega, y las al menos tres zonas de las dos regiones restantes entregan las confirmaciones. Las multirregiones maximizan la disponibilidad y durabilidad de las bases de datos.

Estadísticas de firewall

Estadísticas de firewall te ayuda a comprender y optimizar las reglas de firewall. Proporciona estadísticas, recomendaciones y métricas sobre el uso de las reglas de firewall. Estadísticas de firewall también usa el aprendizaje automático para predecir el uso futuro de las reglas de firewall. Las Estadísticas de firewall te permiten tomar mejores decisiones durante la optimización de las reglas de firewall. Por ejemplo, Estadísticas de firewall identifica las reglas que clasifica como demasiado permisivas. Puedes usar esta información para que la configuración de tu firewall sea más estricta.

Interrupción zonal: Dado que los datos de Firewall Insights se replican en varias zonas, no se ven afectados por una interrupción zonal y el tráfico de los clientes se enruta automáticamente a otras zonas.

Interrupción regional: Dado que los datos de Firewall Insights se replican en todas las regiones, no se ven afectados por una interrupción regional y el tráfico de los clientes se enruta automáticamente a otras regiones.

Flota

Las flotas permiten que los clientes administren varios clústeres de Kubernetes como un grupo y permiten que los administradores de la plataforma usen servicios de varios clústeres. Por ejemplo, las flotas permiten que los administradores apliquen políticas uniformes en todos los clústeres o configuren Ingress de varios clústeres.

Cuando registras un clúster de GKE en una flota, el clúster tiene una membresía regional en la misma región de forma predeterminada. Cuando registras un clúster que no es deGoogle Cloud en una flota, puedes elegir cualquier región o la ubicación global. Se recomienda elegir una región cercana a la ubicación física del clúster. Esto proporciona una latencia óptima cuando se usa la puerta de enlace de conexión para acceder al clúster.

En el caso de una interrupción zonal, las funcionalidades de la flota no se ven afectadas, a menos que el clúster subyacente sea zonal y deje de estar disponible.

En el caso de una interrupción regional, las funciones de la flota fallan de manera estática para los clústeres de membresía dentro de la región. La mitigación de una interrupción regional requiere la implementación en varias regiones, como se sugiere en Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube.

Google Cloud Armor

Google Cloud Armor te ayuda a proteger tus implementaciones y aplicaciones de varios tipos de amenazas, incluidos los ataques DDoS volumétricos y los ataques de aplicaciones, como las secuencias de comandos entre sitios y la inyección de SQL. Google Cloud Armor filtra el tráfico no deseado en los balanceadores de cargas de Google Cloud y evita que ese tráfico ingrese a tu VPC y consuma recursos. Algunas de estas protecciones son automáticas. Algunas requieren que configures políticas de seguridad y las vincules a servicios o regiones de backend. Las políticas de seguridad de Google Cloud Armor con alcance global se aplican a los balanceadores de cargas globales. Las políticas de seguridad con alcance regional se aplican en los balanceadores de cargas regionales.

Interrupción zonal: En caso de una interrupción zonal, los balanceadores de cargas de Google Cloud redireccionan tu tráfico a otras zonas donde hay instancias de backend sanas disponibles. La protección de Google Cloud Armor está disponible de inmediato después de la conmutación por error del tráfico, ya que las políticas de seguridad de Google Cloud Armor se replican de forma síncrona en todas las zonas de una región.

Interrupción regional: En caso de interrupciones regionales, los balanceadores de cargas globales de Google Cloud redireccionan tu tráfico a otras regiones donde haya instancias de backend en buen estado disponibles. La protección de Google Cloud Armor está disponible inmediatamente después de la conmutación por error del tráfico, ya que las políticas de seguridad globales de Google Cloud Armor se replican de forma síncrona en todas las regiones. Para resistir a las fallas regionales, debes configurar las políticas de seguridad regionales de Google Cloud Armor para todas tus regiones.

Google Kubernetes Engine

Google Kubernetes Engine (GKE) ofrece un servicio administrado de Kubernetes, ya que agiliza la implementación de aplicaciones alojadas en contenedores en Google Cloud. Puedes elegir entre topologías de clústeres regionales o zonales.

  • Cuando creas un clúster zonal, GKE aprovisiona una máquina de plano de control en la zona elegida, así como máquinas de trabajador (nodos) dentro de la misma zona.
  • Para los clústeres regionales, GKE aprovisiona tres máquinas de plano de control en tres zonas diferentes dentro de la región elegida. De forma predeterminada, los nodos también están incluidos en tres zonas, aunque puedes elegir crear un clúster regional con nodos que se aprovisionan solo en una zona.
  • Los clústeres multizonales son similares a los clústeres zonales, ya que incluyen una máquina principal y ofrecen la capacidad de incluir nodos de varias zonas.

Interrupción zonal: Para evitar interrupciones zonales, usa clústeres regionales. El plano de control y los nodos se distribuyen en tres zonas diferentes dentro de una región. Una interrupción zonal no afecta al plano de control y los nodos trabajadores que se implementan en las otras dos zonas.

Interrupción regional: La mitigación de una interrupción regional requiere la implementación en varias regiones. Aunque por el momento no se ofrece como una capacidad integrada de los productos, la topología multirregional es un enfoque que hoy en día usan muchos clientes de GKE y que se puede implementar de forma manual. Puedes crear varios clústeres regionales para replicar las cargas de trabajo en varias regiones y controlar el tráfico a estos clústeres mediante la entrada de varios clústeres.

VPN con alta disponibilidad

La VPN con alta disponibilidad (HA) es una oferta de Cloud VPN resiliente que encripta de forma segura tu tráfico desde tu nube privada local, otra nube privada virtual o desde otra red de proveedores de servicios en la nube hacia tu nube privada virtual (VPC) de Google Cloud.

Las puertas de enlace de VPN con alta disponibilidad tienen dos interfaces, cada una con una dirección IP de grupos de direcciones IP diferentes, divididas de forma lógica y física en diferentes PoP y clústeres para garantizar una redundancia óptima.

Interrupción zonal: En el caso de una interrupción zonal, una interfaz puede perder conectividad, pero el tráfico se redirecciona a la otra interfaz a través del enrutamiento dinámico mediante el Protocolo de puerta de enlace fronteriza (BGP).

Interrupción regional: En el caso de una interrupción regional, ambas interfaces pueden perder conectividad durante un período breve.

Identity and Access Management

Identity and Access Management (IAM) es responsable de todas las decisiones de autorización para las acciones en los recursos en la nube. IAM confirma que una política otorga permiso para cada acción (en el plano de datos) y procesa las actualizaciones de esas políticas a través de una llamada SetPolicy (en el plano de control).

Todas las políticas de IAM se replican en varias zonas dentro de cada región, lo que ayuda a las operaciones del plano de datos de IAM a recuperarse de fallas de otras regiones y tolerar fallas de zonas dentro de cada región. La resiliencia del plano de datos de IAM frente a fallas de zona y de región habilita las arquitecturas multirregionales y multizona para la alta disponibilidad.

Las operaciones del plano de control de IAM pueden depender de la replicación entre regiones. Cuando las llamadas SetPolicy se realizan de forma correcta, los datos se escriben en varias regiones, pero la propagación a otras regiones tiene coherencia eventual. El plano de control de IAM es resistente a la falla de una sola región.

Identity-Aware Proxy

Identity-Aware Proxy proporciona acceso a las aplicaciones alojadas en Google Cloud, en otras nubes y de forma local. IAP está distribuido a nivel regional, y las solicitudes a zonas no disponibles se entregan de forma automática desde otras zonas disponibles en la región.

Las interrupciones regionales en IAP afectan el acceso a las aplicaciones alojadas en la región afectada. Te recomendamos que implementes en varias regiones y uses Cloud Load Balancing para lograr una mayor disponibilidad y resiliencia contra interrupciones regionales.

Identity Platform

Identity Platform permite a los clientes agregar a sus apps una administración de identidades y accesos personalizable de nivel de Google. Identity Platform es una oferta global. Los clientes no pueden elegir las regiones o zonas en las que se almacenan sus datos.

Interrupción zonal: Durante una interrupción zonal, Identity Platform falla en las solicitudes a la siguiente celda más cercana. Todos los datos se guardan a escala global, por lo que no se pierden.

Interrupción regional: Durante una interrupción regional, las solicitudes de Identity Platform a la región no disponible fallan temporalmente mientras Identity Platform quita el tráfico de la región afectada. Una vez que no haya más tráfico en la región afectada, un servicio global de balanceo de cargas del servidor enrutará las solicitudes a la región en buen estado más cercana disponible. Todos los datos se guardan de forma global, por lo que no se pierden.

Knative serving

Knative serving es un servicio global que permite a los clientes ejecutar cargas de trabajo sin servidor en clústeres de clientes. Su propósito es garantizar que las cargas de trabajo de Knative serving se implementen correctamente en los clústeres de los clientes y que el estado de instalación de Knative serving se refleje en el recurso de funciones de la API de GKE Fleet. Este servicio solo participa cuando se instalan o actualizan recursos de Knative serving en clústeres de clientes. No forma parte de la ejecución de cargas de trabajo del clúster. Los clústeres de clientes que pertenecen a proyectos que tienen habilitada la entrega de Knative se distribuyen entre réplicas en varias regiones y zonas. Cada clúster está supervisado por una réplica.

Interrupción zonal y regional: Los clústeres supervisados por réplicas que se alojan en una ubicación que experimenta una interrupción se redistribuyen de forma automática entre réplicas en buen estado en otras zonas y regiones. Mientras se realiza esta reasignación, es posible que haya un período breve en el que Knative no supervise algunos clústeres. Si durante ese tiempo el usuario decide habilitar las funciones de entrega de Knative en el clúster, la instalación de los recursos de entrega de Knative en el clúster comenzará después de que el clúster se vuelva a conectar con una réplica del servicio de entrega de Knative en buen estado.

Looker (Google Cloud Core)

Looker (Google Cloud Core) es una plataforma de inteligencia empresarial que proporciona aprovisionamiento, configuración y administración simplificados y optimizados de una instancia de Looker desde la consola de Google Cloud . Looker (Google Cloud Core) permite a los usuarios explorar datos, crear paneles, configurar alertas y compartir informes. Además, Looker (Google Cloud Core) ofrece un IDE para modeladores de datos y funciones de API y de incorporación enriquecidas para desarrolladores.

Looker (Google Cloud Core) está compuesto por instancias aisladas de forma regional que replican los datos de forma síncrona en las zonas de la región. Asegúrate de que los recursos que usa tu instancia, como las fuentes de datos a las que se conecta Looker (Google Cloud Core), estén en la misma región en la que se ejecuta tu instancia.

Interrupción zonal: Las instancias de Looker (Google Cloud Core) almacenan metadatos y sus propios contenedores implementados. Los datos se escriben de forma síncrona en todas las instancias replicadas. En una interrupción zonal, las instancias de Looker (Google Cloud Core) continúan entregando contenido desde otras zonas disponibles en la misma región. Las transacciones o llamadas a la API se muestran después de que los datos se confirman en un quórum dentro de una región. Si la replicación falla, la transacción no se confirma y se le notifica al usuario sobre la falla. Si falla más de una zona, las transacciones también fallan y se notifica al usuario. Looker (Google Cloud Core) detiene cualquier programación o consulta que se esté ejecutando. Debes volver a programarlas o ponerlas en cola después de resolver la falla.

Interrupción regional: Las instancias de Looker (Google Cloud Core) de la región afectada no están disponibles. Looker (Google Cloud Core) detiene cualquier programación o consulta que se esté ejecutando. Debes volver a programar las consultas o ponerlas en cola después de resolver la falla. Puedes crear instancias nuevas de forma manual en una región diferente. También puedes recuperar tus instancias con el proceso que se define en Cómo importar o exportar datos de una instancia de Looker (Google Cloud Core). Te recomendamos que configures un proceso de exportación de datos periódico para copiar los recursos con anticipación, en caso de que se produzca una interrupción regional.

Looker Studio

Looker Studio es un producto de inteligencia empresarial y visualización de datos. Permite a los clientes conectarse a sus datos almacenados en otros sistemas, crear informes y paneles con esos datos, y compartir los informes y paneles en toda su organización. Looker Studio es un servicio global y no permite que los usuarios seleccionen un alcance de recurso.

En el caso de una interrupción zonal, Looker Studio continúa entregando solicitudes desde otra zona en la misma región o en una región diferente sin interrupción. Los recursos de usuario se replican de forma síncrona en todas las regiones. Por lo tanto, no hay pérdida de datos.

En el caso de una interrupción regional, Looker Studio continúa entregando solicitudes desde otra región sin interrupciones. Los recursos de usuario se replican de forma síncrona en todas las regiones. Por lo tanto, no hay pérdida de datos.

Memorystore para Memcached

Memorystore para Memcached es la oferta administrada de Memcached de Google Cloud. Memorystore for Memcached permite a los clientes crear clústeres de Memcached que se puedan usar como bases de datos de clave-valor de alta capacidad de procesamiento para las aplicaciones.

Los clústeres de Memcached son regionales, con nodos distribuidos en todas las zonas especificadas por el cliente. Sin embargo, Memcached no replica ningún dato en los nodos. Por lo tanto, una falla zonal puede provocar la pérdida de datos, también descrito como limpieza de caché parcial. Las instancias de Memcached continuarán funcionando, pero tendrán menos nodos: el servicio no iniciará nodos nuevos durante una falla zonal. Los nodos de Memcached en zonas no afectadas continuarán entregando tráfico, aunque la falla zonal dará como resultado una tasa de aciertos de caché más baja hasta que se recupere la zona.

En el caso de una falla regional, los nodos de Memcached no entregan tráfico. En ese caso, los datos se pierden, lo que da como resultado una limpieza de caché completa. Para mitigar una interrupción regional, puedes implementar una arquitectura que implemente la aplicación y Memorystore para Memcached en varias regiones.

Memorystore for Redis

Memorystore para Redis es un servicio de Redis completamente administrado para Google Cloud que puede reducir la carga de administrar implementaciones complejas de Redis. Actualmente, ofrece 2 niveles: Básico y Estándar. En el caso del nivel Básico, una interrupción zonal o regional causará la pérdida de datos, también conocida como una limpieza completa de la caché. En el nivel Estándar, una interrupción regional causará una pérdida de datos. Una interrupción zonal puede causar una pérdida de datos parcial en la instancia de nivel Estándar debido a su replicación asíncrona.

Interrupción zonal: Las instancias de nivel estándar replican de forma asíncrona las operaciones de conjunto de datos del conjunto de datos en el nodo principal al nodo de réplica. Cuando la interrupción ocurre dentro de la zona del nodo principal, el nodo de réplica asciende para convertirse en el nodo principal. Durante la promoción, se produce una conmutación por error y el cliente de Redis debe volver a conectarse a la instancia. Después de volver a conectar, las operaciones se reanudan. A fin de obtener más información sobre la alta disponibilidad de las instancias de Memorystore para Redis en el nivel Estándar, consulta Alta disponibilidad de Memorystore para Redis.

Si habilitas réplicas de lectura en tu instancia de nivel Estándar y solo tienes una réplica, el extremo de lectura no estará disponible mientras dure una interrupción zonal. Para obtener más información sobre la recuperación ante desastres de las réplicas de lectura, consulta Modos de falla para las réplicas de lectura.

Interrupción regional: Memorystore para Redis es un producto regional, por lo que una sola instancia no puede resistir una falla regional. Puedes programar tareas periódicas para exportar una instancia de Redis a un bucket de Cloud Storage en una región diferente. Cuando se produce una interrupción regional, puedes restablecer la instancia de Redis en una región diferente del conjunto de datos que exportaste.

Descubrimiento de servicios de varios clústeres y, además, Ingress de varios clústeres

Los servicios de varios clústeres (MCS) de GKE consisten en varios componentes. Los componentes incluyen el concentrador de Google Kubernetes Engine (que organiza varios clústeres de Google Kubernetes Engine mediante membresías), los clústeres y los controladores de GKE Hub (Ingress de varios clústeres, descubrimiento de servicios de varios clústeres). Los controladores de Hub organizan la configuración del balanceador de cargas de Compute Engine mediante backends en varios clústeres.

En el caso de una interrupción zonal, el descubrimiento de servicios de varios clústeres continúa entregando solicitudes desde otra zona o región. En el caso de una interrupción regional, el descubrimiento de servicios de varios clústeres no realiza una conmutación por error.

En el caso de una interrupción zonal para Ingress de varios clústeres, si el clúster de configuración es zonal y dentro del alcance de la falla, el usuario debe realizar una conmutación por error de forma manual. El plano de datos es estático y falla y entrega tráfico hasta que el usuario haya conmutado por error. A fin de evitar la necesidad de realizar una conmutación por error manual, usa un clúster regional para el clúster de configuración.

En el caso de una interrupción regional, el Ingress de varios clústeres no conmuta por error. Los usuarios deben tener un plan de DR para realizar una conmutación por error manual del clúster de configuración. Para obtener más información, consulta Configura Ingress de varios clústeres y Configura Service de varios clústeres.

Si deseas obtener más información sobre GKE, consulta la sección “Google Kubernetes Engine” en Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube.

Network Analyzer

Network Analyzer supervisa automáticamente la configuración de la red de VPC y detecta opciones de configuración incorrectas y deficientes. Proporciona estadísticas sobre la topología de la red, las reglas de firewall, las rutas, las dependencias de configuración y la conectividad a servicios y aplicaciones. Identifica fallas de red, proporciona información sobre la causa raíz y sugiere posibles soluciones.

Network Analyzer se ejecuta de forma continua y activa análisis relevantes basados en actualizaciones de configuración casi en tiempo real de tu red. Si Network Analyzer detecta una falla de red, intenta correlacionar la falla con los cambios de configuración recientes para identificar las causas raíz. Siempre que sea posible, se proporcionan recomendaciones para sugerir detalles sobre cómo solucionar los problemas.

Network Analyzer es una herramienta de diagnóstico sin componentes del plano de datos. No procesa ni genera tráfico de usuario.

Interrupción zonal: El servicio de Network Analyzer se replica de forma global y su disponibilidad no se ve afectada por una interrupción zonal.

Si las estadísticas de Network Analyzer contienen opciones de configuración de una zona que sufre una interrupción, afecta la calidad de los datos. Las estadísticas de red que hacen referencia a las configuraciones en esa zona quedan inactivas. No dependas de las estadísticas que proporciona Network Analyzer durante las interrupciones.

Interrupción regional: El servicio de Network Analyzer se replica de forma global y su disponibilidad no se ve afectada por una interrupción regional.

Si las estadísticas de Network Analyzer contienen opciones de configuración de una región que sufre una interrupción, afecta la calidad de los datos. Las estadísticas de red que hacen referencia a las configuraciones en esa región quedan inactivas. No dependas de las estadísticas que proporciona Network Analyzer durante las interrupciones.

Topología de red

Topología de red es una herramienta de visualización que muestra la topología de la infraestructura de red. En la vista de Infraestructura, se muestran las redes de nube privada virtual (VPC), la conectividad híbrida desde y hacia tus redes locales, la conectividad a los servicios administrados por Google y las métricas asociadas.

Interrupción zonal: En caso de una interrupción zonal, los datos de esa zona no aparecerán en la Topología de red. Los datos de otras zonas no se ven afectados.

Interrupción regional: En caso de una interrupción regional, los datos de esa región no aparecerán en la Topología de red. Los datos de otras regiones no se ven afectados.

Panel de rendimiento

El panel de rendimiento te brinda visibilidad del rendimiento de toda la red de Google Cloud , así como del rendimiento de los recursos de tu proyecto.

Con estas capacidades de supervisión del rendimiento, puedes distinguir entre un problema en tu aplicación y un problema en la red subyacente de Google Cloud . También puedes investigar problemas históricos de rendimiento de red. El panel de rendimiento también exporta datos a Cloud Monitoring. Puedes usar Monitoring para consultar los datos y obtener acceso a información adicional.

Interrupción zonal:

En caso de una interrupción zonal, los datos de latencia y pérdida de paquetes para el tráfico de la zona afectada no aparecerán en el Panel de rendimiento. Los datos de latencia y pérdida de paquetes para el tráfico de otras zonas no se ven afectados. Cuando finaliza la interrupción, se reanudan los datos de latencia y pérdida de paquetes.

Interrupción regional:

En caso de una interrupción regional, los datos de latencia y pérdida de paquetes del tráfico de la región afectada no aparecerán en el Panel de rendimiento. Los datos de latencia y pérdida de paquetes para el tráfico de otras regiones no se ven afectados. Cuando finaliza la interrupción, se reanudan los datos de latencia y pérdida de paquetes.

Network Connectivity Center

Network Connectivity Center es un producto de administración de conectividad de red que emplea una arquitectura de concentrador y radio. Con esta arquitectura, un recurso de administración central actúa como un concentrador y cada recurso de conectividad funciona como un radio. En la actualidad, los radios híbridos admiten VPN con alta disponibilidad, interconexiones dedicadas y de socio, y dispositivos de router SD-WAN de los principales proveedores externos. Con los radios híbridos del Network Connectivity Center, las empresas pueden conectar las cargas de trabajo y los servicios de Google Cloud a centros de datos locales, otras nubes y sus oficinas de representación a través del alcance global de la red de Google Cloud .

Interrupción zonal: Un radio híbrido de Network Connectivity Center con configuración de alta disponibilidad es resistente a las fallas zonales porque el plano de control y el plano de datos de red son redundantes en varias zonas dentro de una región.

Interrupción regional: Un radio híbrido de Network Connectivity Center es un recurso regional, por lo que no puede resistir una falla regional.

Niveles de servicio de red

Los niveles de servicio de red te permiten optimizar la conectividad entre los sistemas en Internet y tus instancias de Google Cloud . Ofrece dos niveles de servicio distintos: el nivel Premium y el nivel Estándar. Con el nivel Premium, una dirección IP del nivel Premium anycast anunciada a nivel mundial puede funcionar como frontend para backends regionales o globales. Con el nivel Estándar, una dirección IP anunciada a nivel regional puede funcionar como frontend para backends regionales. La resiliencia general de una aplicación está influenciada por el nivel de servicio de red y la redundancia de los backends con los que se asocia.

Interrupción zonal: El nivel Premium y el nivel Estándar ofrecen resiliencia contra interrupciones zonales cuando se asocian con backends regionalmente redundantes. Cuando se produce una interrupción zonal, los backends asociados determinan el comportamiento de la conmutación por error en los casos que usan backends regionalmente redundantes. Cuando se asocia con backends zonales, el servicio volverá a estar disponible en cuanto se resuelva la interrupción.

Interrupción regional: El nivel Premium ofrece resiliencia contra interrupciones regionales cuando está asociado con backends redundantes a nivel global. En el nivel Estándar, fallará todo el tráfico a la región afectada. El tráfico a todas las demás regiones no se ve afectado. Cuando ocurre una interrupción regional, los backends asociados determinan el comportamiento de la conmutación por error para los casos que usan el nivel Premium con backends redundantes a nivel global. Cuando usas el nivel Premium con backends regionales o el nivel Estándar, el servicio volverá a estar disponible en cuanto se resuelva la interrupción.

Servicio de políticas de la organización

El Servicio de políticas de la organización proporciona un control centralizado y programático sobre los recursos de Google Cloud de tu organización. Como administrador de la política de la organización, puedes configurar restricciones en toda la jerarquía de recursos.

Interrupción zonal: Todas las políticas de la organización creadas por el servicio de políticas de la organización se replican de forma asíncrona en varias zonas de cada región. Los datos de la política de la organización y las operaciones del plano de control son tolerantes a las fallas de zona dentro de cada región.

Interrupción regional: Todas las políticas de la organización creadas por el servicio de políticas de la organización se replican de forma asíncrona en varias regiones. Las operaciones del plano de control de la política de la organización se escriben en varias regiones, y la propagación a otras regiones es coherente en cuestión de minutos. El plano de control de la política de la organización es resistente a fallas de una sola región. Las operaciones del plano de datos de la política de la organización pueden recuperarse de fallas en otras regiones, y la resiliencia del plano de datos de la política de la organización frente a fallas de zona y de región habilita las arquitecturas multirregionales y multizona para la alta disponibilidad.

Duplicación de paquetes

La duplicación de paquetes clona el tráfico de instancias específicas en tu red de nube privada virtual (VPC) y reenvía los datos clonados a instancias detrás de un balanceador de cargas interno regional para su examen. La duplicación de paquetes capta todo el tráfico y los datos de paquetes, incluidas las cargas útiles y los encabezados.

Para obtener más información sobre la funcionalidad de la duplicación de paquetes, consulta la página de descripción general de la duplicación de paquetes.

Interrupción zonal: Configura el balanceador de cargas interno para que haya instancias en varias zonas. Si se produce una interrupción zonal, la duplicación de paquetes desvía los paquetes clonados a una zona en buen estado.

Interrupción regional: La duplicación de paquetes es un producto regional. Si hay una interrupción regional, no se clonan los paquetes de la región afectada.

Persistent Disk

Los discos persistentes están disponibles en las configuraciones zonales y regionales.

Los discos persistentes zonales se alojan en una sola zona. Si la zona del disco no está disponible, Persistent Disk tampoco estará disponible hasta que se resuelva la interrupción zonal.

Los discos persistentes regionales proporcionan replicación síncrona de datos entre dos zonas de una región. Si se produce una interrupción en la zona de la máquina virtual, puedes forzar la conexión de un disco persistente regional a una instancia de VM en la zona secundaria del disco. Para ello, debes iniciar otra instancia de VM o mantener una instancia de VM en espera activa en esa zona.

Para replicar datos de forma asíncrona en un disco persistente entre regiones, puedes usar la replicación asíncrona de discos persistentes (PD Async Replication), que proporciona una replicación de almacenamiento en bloque de RTO y RPO bajos para la DR activa-pasiva entre regiones. En el caso improbable de una interrupción regional, PD Async Replication te permite conmutar por error tus datos a una región secundaria y reiniciar tu carga de trabajo en esa región.

Personalized Service Health

Personalized Service Health comunica las interrupciones del servicio relevantes para tus proyectos de Google Cloud . Proporciona varios canales y procesos para ver o integrar eventos disruptivos (incidentes, mantenimiento planificado) en el proceso de respuesta ante incidentes, incluidos los siguientes:

  • Un panel en la consola de Google Cloud
  • Una API de servicio
  • Alertas configurables
  • Registros generados y enviados a Cloud Logging

Interrupción zonal: Los datos se entregan desde una base de datos global sin dependencia de ubicaciones específicas. Si se produce una interrupción zonal, Service Health puede entregar solicitudes y redirigir el tráfico automáticamente a zonas en la misma región que aún funcionan. Service Health puede mostrar llamadas a la API de forma correcta si puede recuperar datos de eventos de la base de datos de Service Health.

Interrupción regional: Los datos se entregan desde una base de datos global sin dependencia de ubicaciones específicas. Si hay una interrupción regional, Service Health aún puede entregar solicitudes, pero puede funcionar con capacidad reducida. Las fallas regionales en las ubicaciones de Logging pueden afectar a los usuarios de Service Health que consumen registros o notificaciones de alertas en la nube.

Private Service Connect

Private Service Connect es una función de las redes de Google Cloudque permite a los consumidores acceder a los servicios administrados de forma privada desde dentro de su red de VPC. Del mismo modo, permite a los productores de servicios administrados alojar estos servicios en sus propias redes de VPC independientes y ofrecer una conexión privada a sus consumidores.

Extremos de Private Service Connect para servicios publicados

Un extremo de Private Service Connect se conecta a los servicios de la red de VPC de los productores de servicios mediante una regla de reenvío de Private Service Connect. El productor de servicios proporciona un servicio mediante el uso de conectividad privada a un servicio consumidor mediante la exposición de un solo adjunto de servicio. Luego, el servicio consumidor podrá asignar una dirección IP virtual desde su VPC para ese servicio.

Interrupción zonal: El tráfico de Private Service Connect que proviene del tráfico de VMs generado por los extremos de cliente de VPC del consumidor aún puede acceder a los servicios administrados expuestos en la red de VPC interna del productor de servicios. Este acceso es posible porque el tráfico de Private Service Connect conmuta por error a backends de servicio en mejor estado en una zona diferente.

Interrupción regional: Private Service Connect es un producto regional. No es resiliente a las interrupciones regionales. Los servicios administrados multirregionales pueden lograr una alta disponibilidad durante una interrupción regional mediante la configuración de extremos de Private Service Connect en varias regiones.

Extremos de Private Service Connect para las APIs de Google

Un extremo de Private Service Connect se conecta a las APIs de Google mediante una regla de reenvío de Private Service Connect. Esta regla de reenvío permite a los clientes usar nombres de extremos personalizados con sus direcciones IP internas.

Interrupción zonal: El tráfico de Private Service Connect desde los extremos del cliente de VPC de consumidor aún puede acceder a las APIs de Google porque la conectividad entre la VM y el extremo se conmutará por error de forma automática a otra zona funcional en la misma región. Las solicitudes que ya están en tránsito cuando comienza una interrupción dependerán del tiempo de espera de TCP y del comportamiento del reintento para la recuperación del cliente.

Consulta la recuperación de Compute Engine para obtener más detalles.

Interrupción regional: Private Service Connect es un producto regional. No es resiliente a las interrupciones regionales. Los servicios administrados multirregionales pueden lograr una alta disponibilidad durante una interrupción regional mediante la configuración de extremos de Private Service Connect en varias regiones.

Para obtener más información sobre Private Service Connect, consulta la sección “Extremos” en Tipos de Private Service Connect.

Pub/Sub

Pub/Sub es un servicio de mensajería para la integración de aplicaciones y las estadísticas de transmisiones. Los temas de Pub/Sub son globales, lo que significa que son visibles y accesibles desde cualquier ubicación de Google Cloud . Sin embargo, cualquier mensaje se almacena en una sola región de Google Cloud , la más cercana al publicador y que permite la política de ubicación de recursos. Por lo tanto, un tema puede tener mensajes almacenados en diferentes regiones de Google Cloud. La política de almacenamiento de mensajes de Pub/Sub puede restringir las regiones en las que se almacenan los mensajes.

Interrupción zonal: Cuando se publica un mensaje de Pub/Sub, se escribe de forma síncrona en el almacenamiento en al menos dos zonas dentro de la región. Por lo tanto, si una sola zona deja de estar disponible, no se produce un impacto visible para el cliente.

Interrupción regional: Durante una interrupción regional, no se puede acceder a los mensajes almacenados dentro de la región afectada. Los publicadores y suscriptores que se conectarían a la región afectada, ya sea a través de un extremo regional o el global, no pueden conectarse. Los publicadores y suscriptores que se conectan a otras regiones aún pueden conectarse y los mensajes disponibles en otras regiones se entregan a los suscriptores más cercanos a la red que tienen capacidad.

Si tu aplicación depende del orden de los mensajes, revisa las recomendaciones detalladas del equipo de Pub/Sub. Las garantías de ordenamiento de mensajes se proporcionan por región y pueden interrumpirse si usas un extremo global.

reCAPTCHA

reCAPTCHA es un servicio global que detecta actividades fraudulentas, spam y abusos. No requiere ni permite la configuración para la resiliencia regional o zonal. Las actualizaciones de los metadatos de configuración se replican de forma asíncrona en cada región donde se ejecuta reCAPTCHA.

En el caso de una interrupción zonal, reCAPTCHA continúa entregando solicitudes desde otra zona en la misma región o en otra sin interrupciones.

En el caso de una interrupción regional, reCAPTCHA continúa entregando solicitudes desde otra región sin interrupciones.

Secret Manager

Secret Manager es un producto de administración de credenciales y secretos deGoogle Cloud. Con Secret Manager, puedes auditar y restringir con facilidad el acceso a los secretos, encriptar los secretos en reposo y garantizar que la información sensible esté protegida en Google Cloud.

Por lo general, los recursos de Secret Manager se crean con la política de replicación automática (recomendado), lo que provoca que se repliquen a nivel global. Si tu organización tiene políticas que no permiten la replicación global de los datos del secreto, los recursos de Secret Manager se pueden crear con políticas de replicación administradas por el usuario, en las que se eligen una o más regiones para que se detecte un secreto replicado.

Interrupción zonal: En el caso de una interrupción zonal, Secret Manager continúa entregando solicitudes desde otra zona en la misma región o en otra sin interrupciones. Dentro de cada región, Secret Manager siempre mantiene al menos 2 réplicas en zonas diferentes (en la mayoría de las regiones, 3 réplicas). Cuando se resuelve la interrupción zonal, se restablece la redundancia total.

Interrupción regional: En el caso de una interrupción regional, Secret Manager continúa entregando solicitudes de otra región sin interrupciones, siempre y cuando los datos se hayan replicado en más de una región (ya sea a través de la replicación automática o mediante la replicación administrada por el usuario en más de una región). Cuando se resuelve la interrupción regional, se restablece la redundancia total.

Security Command Center

Security Command Center es la plataforma global de administración de riesgos en tiempo real de Google Cloud. Consta de dos componentes principales: detectores y hallazgos.

Los detectores se ven afectados por interrupciones regionales y zonales de diferentes maneras. Durante una interrupción regional, los detectores no pueden generar hallazgos nuevos para los recursos regionales porque los recursos que deberían analizar no están disponibles.

Durante una interrupción zonal, los detectores pueden tardar desde varios minutos hasta horas en reanudar el funcionamiento normal. Security Command Center no perderá datos de resultados. Tampoco se generarán datos de búsqueda nuevos para los recursos no disponibles. En el peor de los casos, es posible que los agentes de Container Threat Detection se queden sin espacio de búfer mientras se conectan a una celda en buen estado, lo que podría provocar que se pierdan las detecciones.

Los resultados son resilientes a las interrupciones regionales y zonales, ya que se replican de forma síncrona en todas las regiones.

Protección de datos sensibles (incluida la API de DLP)

La protección de datos sensibles proporciona servicios de análisis de riesgos de privacidad, clasificación, desidentificación y asignación de tokens sensibles. Funciona de forma síncrona en los datos que se envían en los cuerpos de las solicitudes o de forma asíncrona en los datos que ya están presentes en los sistemas de almacenamiento en la nube. La protección de datos sensibles se puede invocar a través de los extremos globales o específicos de la región.

Extremo global: El servicio está diseñado para ser resistente a fallas regionales y zonales. Si el servicio está sobrecargado mientras se produce una falla, es posible que se pierdan los datos enviados al método hybridInspect del servicio.

Para crear una arquitectura resistente a fallas, incluye la lógica a fin de examinar el resultado más reciente previo a la falla que produjo el método hybridInspect. En el caso de una interrupción, los datos que se enviaron al método podrían perderse, pero no más de los últimos 10 minutos antes del evento de falla. Si hay resultados más recientes que 10 minutos antes de que comenzara la interrupción, indica que los datos que generaron ese resultado no se perdieron. En ese caso, no es necesario volver a reproducir los datos anteriores a la marca de tiempo del resultado, incluso si están dentro del intervalo de 10 minutos.

Extremo regional: Los extremos regionales no son resilientes a las fallas regionales. Si se requiere resiliencia contra una falla regional, considera conmutar por error a otras regiones. Las características de las fallas zonales son las mismas que las anteriores.

Service Usage

La API de Service Usage es un servicio de infraestructura de Google Cloud que te permite enumerar y administrar APIs y servicios en tus proyectos de Google Cloud . Puedes enumerar y administrar las APIs y los servicios que proporciona Google, Google Cloudy productores externos. La API de Service Usage es un servicio global y es resistente a las interrupciones zonales y regionales. En el caso de una interrupción zonal o regional, la API de Service Usage continúa entregando solicitudes desde otra zona en diferentes regiones.

Para obtener más información sobre Service Usage, consulta la Documentación de Service Usage.

Speech‑to‑Text

Speech-to-Text te permite convertir audio de voz en texto a través de técnicas de aprendizaje automático, como los modelos de redes neuronales. El audio se envía en tiempo real desde el micrófono de una aplicación o se procesa como un lote de archivos de audio.

Interrupción zonal:

  • API de Speech-to-Text v1: Durante una interrupción zonal, la versión 1 de la API de Speech-to-Text continúa entregando solicitudes desde otra zona en la misma región sin interrupciones. Sin embargo, se pierden los trabajos que se estén ejecutando en la zona con errores. Los usuarios deben reintentar los trabajos con errores, que se enrutarán automáticamente a una zona disponible.

  • API de Speech-to-Text v2: Durante una interrupción zonal, la versión 2 de la API de Speech-to-Text continúa entregando solicitudes desde otra zona en la misma región. Sin embargo, se pierden los trabajos que se estén ejecutando en la zona con errores. Los usuarios deben reintentar los trabajos con errores, que se enrutarán automáticamente a una zona disponible. La API de Speech-to-Text solo devuelve la llamada a la API una vez que los datos se confirmaron en un quórum dentro de una región. En algunas regiones, los aceleradores de IA (TPU) están disponibles solo en una zona. En ese caso, una interrupción en esa zona provoca que el reconocimiento de voz falle, pero no hay pérdida de datos.

Interrupción regional:

  • API de Speech-to-Text v1: La versión 1 de la API de Speech-to-Text no se ve afectada por una falla regional porque es un servicio multirregional global. El servicio continúa entregando solicitudes desde otra región sin interrupciones. Sin embargo, los trabajos que se están ejecutando actualmente dentro de la región con errores se pierden. Los usuarios deben reintentar esos trabajos con errores, que se enrutarán automáticamente a una región disponible.

  • API de Speech-to-Text v2:

    • En la versión 2 de la API multirregional de Speech-to-Text, el servicio continúa entregando solicitudes desde otra zona en la misma región sin interrupciones.

    • En la versión 2 de la API de Speech-to-Text de una sola región, el servicio define el alcance de la ejecución del trabajo en la región solicitada. La versión 2 de la API de Speech-to-Text no enruta el tráfico a una región diferente y los datos no se replican a otra región. Durante una falla regional, la versión 2 de la API de Speech-to-Text no está disponible en esa región. Sin embargo, volverá a estar disponible cuando se resuelva la interrupción.

Servicio de transferencia de almacenamiento

El Servicio de transferencia de almacenamiento administra las transferencias de datos de varias fuentes en la nube a Cloud Storage, así como a los sistemas de archivos, y desde ellos.

La API del Servicio de transferencia de almacenamiento es un recurso global.

El Servicio de transferencia de almacenamiento depende de la disponibilidad del origen y el destino de una transferencia. Si una fuente o un destino de transferencia no están disponibles, las transferencias dejan de avanzar. Sin embargo, no se pierden los datos principales del cliente ni los datos de los trabajos. Las transferencias se reanudan cuando el origen y el destino vuelven a estar disponibles.

Puedes usar el Servicio de transferencia de almacenamiento con o sin un agente de la siguiente manera:

  • Las transferencias sin agentes usan trabajadores regionales para organizar los trabajos de transferencia.

  • Las transferencias basadas en agentes usan agentes de software instalados en tu infraestructura. Las transferencias basadas en agentes dependen de la disponibilidad de los agentes de transferencia y de la capacidad de los agentes para conectarse al sistema de archivos. Cuando decidas dónde instalar los agentes de transferencia, ten en cuenta la disponibilidad del sistema de archivos. Por ejemplo, si ejecutas agentes de transferencia en varias VMs de Compute Engine para transferir datos a una instancia de Filestore de nivel empresarial (un recurso regional), debes considerar ubicar las VMs en diferentes zonas dentro de la región de la instancia de Filestore.

    Si los agentes no están disponibles o si se interrumpe su conexión con el sistema de archivos, las transferencias dejan de avanzar, pero no se pierde ningún dato. Si se finalizan todos los procesos del agente, el trabajo de transferencia se detiene hasta que se agreguen agentes nuevos al grupo de agentes de la transferencia.

Durante una interrupción, el comportamiento del Servicio de transferencia de almacenamiento es el siguiente:

  • Interrupción zonal: Durante una interrupción zonal, las API del Servicio de transferencia de almacenamiento permanecen disponibles y puedes continuar creando trabajos de transferencia. Los datos se siguen transfiriendo.

  • Interrupción regional: Durante una interrupción regional, las APIs del Servicio de transferencia de almacenamiento permanecen disponibles y puedes continuar creando trabajos de transferencia. Si los trabajadores de tu transferencia se encuentran en la región afectada, la transferencia de datos se detiene hasta que la región vuelva a estar disponible y se reanuda de forma automática.

Vertex ML Metadata

Vertex ML Metadata te permite registrar metadatos y artefactos generados por el sistema de AA y consultar esos metadatos para ayudar a analizar, depurar y auditar el rendimiento del sistema de AA o los artefactos que produce.

Interrupción zonal: En la configuración predeterminada, Vertex ML Metadata ofrece protección contra fallas zonales. El servicio se implementa en varias zonas de cada región, con datos replicados de forma síncrona en diferentes zonas dentro de cada región. En caso de una falla zonal, las zonas restantes se hacen cargo con una interrupción mínima.

Interrupción regional: Vertex ML Metadata es un servicio regionalizado. En el caso de una interrupción regional, Vertex ML Metadata no se conmutará por error a otra región.

Predicción por lotes de Vertex AI

La predicción por lotes permite a los usuarios ejecutar la predicción por lotes en los modelos de IA/AA en la infraestructura de Google. La predicción por lotes es una oferta regional. Los clientes pueden elegir la región en la que ejecutan trabajos, pero no las zonas específicas dentro de esa región. El servicio de predicción por lotes balancea las cargas del trabajo de forma automática en diferentes zonas dentro de la región elegida.

Interrupción zonal: La predicción por lotes almacena metadatos para trabajos de predicción por lotes dentro de una región. Los datos se escriben de forma síncrona en varias zonas dentro de esa región. En una interrupción zonal, la predicción por lotes pierde de forma parcial los trabajadores que realizan trabajos, pero los vuelve a agregar de forma automática en otras zonas disponibles. Si varios reintentos de predicción por lotes fallan, la IU enumera el estado del trabajo como con errores en la IU y en las solicitudes de llamada a la API. Las solicitudes posteriores de los usuarios para ejecutar el trabajo se enrutan a las zonas disponibles.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean ejecutar sus trabajos de predicción por lotes. Los datos nunca se replican en otras regiones. La predicción por lotes define el alcance de la ejecución del trabajo a la región solicitada y nunca enruta las solicitudes de predicción a una región diferente. Cuando ocurre una falla regional, la predicción por lotes no estará disponible en esa región. Volverá a estar disponible cuando se resuelva la interrupción. Recomendamos que los clientes usen varias regiones para ejecutar sus trabajos. En caso de una interrupción regional, dirige los trabajos a una región disponible diferente.

Vertex AI Model Registry

Vertex AI Model Registry permite a los usuarios optimizar la administración de modelos, la administración y la implementación de modelos de AA en un repositorio central. Vertex AI Model Registry es una oferta regional con alta disponibilidad y ofrece protección contra las interrupciones zonales.

Interrupción zonal: Vertex AI Model Registry ofrece protección contra interrupciones zonales. El servicio se implementa en tres zonas de cada región, con datos replicados de forma síncrona en diferentes zonas dentro de la región. Si una zona falla, las zonas restantes se encargarán sin pérdida de datos y sin interrupción de servicios.

Interrupción regional: Vertex AI Model Registry es un servicio regional. Si una región falla, Model Registry no conmutará por error.

Predicción en línea de Vertex AI

La predicción en línea permite a los usuarios implementar modelos de IA/AA en Google Cloud. La predicción en línea es una oferta regional. Los clientes pueden elegir la región en la que implementan sus modelos, pero no las zonas específicas dentro de esa región. El servicio de predicción balanceará automáticamente las cargas de trabajo en diferentes zonas dentro de la región seleccionada.

Interrupción zonal: La predicción en línea no almacena ningún contenido de clientes. Una interrupción zonal genera una falla en la ejecución de la solicitud de predicción actual. La predicción en línea puede reintentar o no de forma automática la solicitud de predicción según el tipo de extremo que se use. En particular, un extremo público volverá a intentarlo de forma automática, mientras que el extremo privado no. Para ayudar a controlar las fallas y mejorar la resiliencia, incorpora una lógica de reintento con retirada exponencial en tu código.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean ejecutar sus modelos de IA/ML y servicios de predicción en línea. Los datos nunca se replican en otras regiones. La predicción en línea define el alcance de la ejecución del modelo de IA/AA a la región solicitada y nunca enruta las solicitudes de predicción a una región diferente. Cuando ocurre una falla regional, el servicio de predicción en línea no está disponible en esa región. Sin embargo, volverá a estar disponible cuando se resuelva la interrupción. Recomendamos que los clientes usen varias regiones para ejecutar sus modelos de IA/AA. En el caso de una interrupción regional, dirige el tráfico a una región diferente que esté disponible.

Vertex AI Pipelines

Vertex AI Pipelines es un servicio de Vertex AI que te permite automatizar, supervisar y administrar tus flujos de trabajo de aprendizaje automático (AA) sin servidores. Vertex AI Pipelines se creó para proporcionar alta disponibilidad y ofrece protección contra fallas zonales.

Interrupción zonal: En la configuración predeterminada, Vertex AI Pipelines ofrece protección contra fallas zonales. El servicio se implementa en varias zonas de cada región, con datos replicados de forma síncrona en diferentes zonas dentro de la región. En caso de una falla zonal, las zonas restantes se hacen cargo con una interrupción mínima.

Interrupción regional: Vertex AI Pipelines es un servicio regionalizado. En el caso de una interrupción regional, Vertex AI Pipelines no se transferirá a otra región. Si se produce una interrupción regional, te recomendamos que ejecutes tus trabajos de canalización en una región de copia de seguridad.

Vertex AI Search es una solución de búsqueda personalizable con funciones de IA generativas y cumplimiento empresarial nativo. Vertex AI Search se implementa y replica automáticamente en varias regiones dentro de Google Cloud. Puedes configurar dónde se almacenan los datos si eliges una multirregión compatible, como la global, US o EU.

Interrupción regional y zonal: Es posible que UserEvents se suba a Vertex AI Search debido a un retraso de replicación asíncrona. Otros datos y servicios que proporciona Vertex AI Search permanecen disponibles debido a la conmutación por error automática y la replicación de datos síncrona.

Vertex AI Training

Vertex AI Training proporciona a los usuarios la capacidad de ejecutar trabajos de entrenamiento personalizados en la infraestructura de Google. Vertex AI Training es una oferta regional, lo que significa que los clientes pueden elegir la región para ejecutar sus trabajos de entrenamiento. Sin embargo, los clientes no pueden elegir las zonas específicas dentro de esa región. El servicio de entrenamiento podría balancear las cargas de la ejecución del trabajo de forma automática en diferentes zonas dentro de la región.

Interrupción zonal: Vertex AI Training almacena metadatos para el trabajo de entrenamiento personalizado. Estos datos se almacenan de forma regional y se escriben de manera síncrona. La llamada a la API de Vertex AI Training solo se muestra una vez que estos metadatos se confirmaron en un quórum dentro de una región. El trabajo de entrenamiento puede ejecutarse en una zona específica. Una interrupción zonal genera una falla en la ejecución del trabajo actual. Si es así, el servicio vuelve a intentar el trabajo de forma automática y lo enruta a otra zona. Si varios reintentos fallan, el estado del trabajo se actualiza a con errores. Las solicitudes posteriores de los usuarios para ejecutar el trabajo se enrutan a una zona disponible.

Interrupción regional: Los clientes eligen la región de Google Cloud en la que desean ejecutar sus trabajos de entrenamiento. Los datos nunca se replican en otras regiones. Vertex AI Training define la ejecución del trabajo a la región solicitada y nunca enruta los trabajos de entrenamiento a una región diferente. En el caso de una falla regional, el servicio de Vertex AI Training no está disponible en esa región y vuelve a estar disponible cuando se resuelva la interrupción. Recomendamos que los clientes usen varias regiones para ejecutar sus trabajos y, en caso de una interrupción regional, poder dirigir los trabajos a una región diferente que esté disponible.

Nube privada virtual (VPC)

VPC es un servicio global que proporciona conectividad de red a los recursos (por ejemplo, las VMs). Sin embargo, las fallas son zonales. En caso de una falla zonal, los recursos en esa zona no están disponibles. Del mismo modo, si una región falla, solo el tráfico desde y hacia la región con errores se ve afectado. La conectividad de las regiones en buen estado no se ve afectada.

Interrupción zonal: Si una red de VPC abarca varias zonas y una zona falla, la red de VPC aún estará en buen estado para zonas en buen estado. El tráfico de red entre recursos en zonas en buen estado seguirá funcionando con normalidad durante la falla. Una falla zonal solo afecta el tráfico de red desde y hacia los recursos en la zona con errores. Para mitigar el impacto de las fallas zonales, te recomendamos que no crees todos los recursos en una sola zona. En su lugar, cuando crees recursos, distribúyelos entre zonas.

Interrupción regional: Si una red de VPC abarca varias regiones y una región falla, la red de VPC aún estará en buen estado para regiones en buen estado. El tráfico de red entre recursos en regiones en buen estado seguirá funcionando con normalidad durante la falla. Una falla regional solo afecta el tráfico de red desde y hacia los recursos en la región con errores. Para mitigar el impacto de las fallas regionales, te recomendamos que distribuyas recursos en varias regiones.

Controles del servicio de VPC

Los Controles del servicio de VPC son un servicio regional. Con los Controles del servicio de VPC, los equipos de seguridad de las empresas pueden definir controles de perímetro detallados y aplicar esa postura de seguridad en varios servicios y proyectos de Google Cloud . Las políticas del cliente se duplican de forma regional.

Interrupción zonal: los Controles del servicio de VPC continúan entregando solicitudes desde otra zona en la misma región sin interrupción.

Interrupción regional: las APIs configuradas para la aplicación de la política de los Controles del servicio de VPC en la región afectada no estarán disponibles hasta que la región vuelva a estar disponible. Se recomienda a los clientes que implementen los servicios aplicados de Controles del servicio de VPC en varias regiones si se desea una mayor disponibilidad.

Workflows

Workflows es un producto de orquestación que permite a los clientes de Google Cloudhacer lo siguiente:

  • Implementar y ejecutar flujos de trabajo que conecten otros servicios existentes mediante HTTP
  • Automatizar los procesos, incluida la espera de respuestas HTTP con reintentos automáticos, hasta por un año
  • Implementar el procesamiento en tiempo real con ejecuciones de latencia baja basadas en eventos

Un cliente de Workflows puede implementar flujos de trabajo que describen la lógica empresarial que desea realizar y, luego, ejecutar los flujos de trabajo directamente con la API o con activadores controlados por eventos (actualmente limitados a Pub/Sub o Eventarc). El flujo de trabajo que se ejecuta puede manipular las variables, realizar llamadas HTTP y almacenar los resultados, o definir las devoluciones de llamada y esperar a que otro servicio los reanude.

Interrupción zonal: El código fuente de flujos de trabajo no se ve afectado por interrupciones zonales. Los flujos de trabajo almacenan el código fuente de los flujos de trabajo, junto con los valores de las variables y las respuestas HTTP que reciben los flujos de trabajo que se ejecutan. El código fuente se almacena de forma regional y se escribe de forma síncrona: la API del plano de control solo se muestra una vez que estos metadatos se confirmaron en un quórum dentro de una región. Las variables y los resultados HTTP también se almacenan de forma regional y se escriben de forma síncrona, al menos cada cinco segundos.

Si una zona falla, los flujos de trabajo se reanudan de forma automática en función de los últimos datos almacenados. Sin embargo, las solicitudes HTTP que aún no recibieron respuestas no se reintentan de forma automática. Usa las políticas de reintento para las solicitudes que se pueden reintentar de forma segura, como se describe en nuestra documentación.

Interrupción regional: Los flujos de trabajo son un servicio regionalizado. En el caso de una interrupción regional, los flujos de trabajo no se conmutarán por error. Se recomienda a los clientes que implementen flujos de trabajo en varias regiones si se desea una mayor disponibilidad.

Cloud Service Mesh

Cloud Service Mesh te permite configurar una malla de servicios administrada que abarca varios clústeres de GKE. Esta documentación solo se refiere a la versión administrada de Cloud Service Mesh. La variante en el clúster se aloja de forma independiente y se deben seguir los lineamientos habituales de la plataforma.

Interrupción zonal: la configuración de la malla, como se almacena en el clúster de GKE, es resistente a las interrupciones zonales siempre que el clúster sea regional. Los datos que usa el producto para la contabilidad interna se almacenan a nivel regional o global y no se ven afectados si una sola zona está fuera de servicio. El plano de control se ejecuta en la misma región que el clúster de GKE que admite (para los clústeres zonales, es la región que lo contiene) y no se ve afectado por las interrupciones dentro de una sola zona.

Interrupción regional: Cloud Service Mesh proporciona servicios a los clústeres de GKE, que son regionales o zonales. En caso de una interrupción regional, Cloud Service Mesh no realizará la conmutación por error. Tampoco lo haría GKE. Se recomienda a los clientes que implementen mallas que constituyen clústeres de GKE que abarcan diferentes regiones.

Directorio de servicios

El Directorio de servicios es una plataforma para descubrir, publicar y conectar servicios. Proporciona información en tiempo real, en un solo lugar, sobre todos tus servicios. El Directorio de servicios te permite realizar la administración del inventario de servicios a gran escala, ya sea que tengas unos pocos extremos de servicio o miles.

Los recursos del Directorio de servicios se crean de forma regional y coinciden con el parámetro de ubicación especificado por el usuario.

Interrupción zonal: Durante una interrupción zonal, el Directorio de servicios continúa entregando solicitudes desde otra zona en la misma región o en otra sin interrupciones. Dentro de cada región, el Directorio de servicios siempre mantiene varias réplicas. Una vez que se resuelve la interrupción zonal, se restablece la redundancia total.

Interrupción regional: El Directorio de servicios no es resistente a las interrupciones regionales.