Preguntas frecuentes sobre la resiliencia y la disponibilidad continua de la plataforma y los servicios de Oracle Cloud Infrastructure

¿Oracle distingue entre diferentes clases de servicio? Por ejemplo, ¿se distinguen los servicios esenciales, los servicios disponibles de forma continua o los servicios de ubicación única?

No se hacen distinciones. Sin embargo, sí se categorizan nuestros servicios en función del nivel de dependencia, el ámbito de disponibilidad y el plano de datos frente al plano de control. Estas categorías están diseñadas para ofrecer diversos equilibrios útiles entre disponibilidad, durabilidad, rendimiento y comodidad.

Niveles de dependencia

Estos niveles pueden equipararse a las capas o niveles de un diagrama de bloques arquitectural. Es posible que una capa dependa únicamente de otras inferiores.

De inferior a superior:

• Servicios básicos: representan la base de Oracle Cloud Infrastructure. Entre otros, incluyen gestión de identidad y acceso (IAM), gestión de claves, redes, recursos informáticos, volúmenes en bloque, almacenamiento de objetos y servicios internos compartidos. Se han diseñado para que sus dependencias sean mínimas, incluso entre servicios. (Consulta más adelante en este documento para obtener detalles sobre las dependencias).
• IaaS: esta capa proporciona más funcionalidades a nivel de infraestructura, basadas en el núcleo. Esta capa contiene File Storage, Database y Container Engine for Kubernetes.
• SaaS: esta capa es de software enriquecido como servicio que se crea en capas inferiores.

Alcance de disponibilidad

Para cumplir los objetivos de disponibilidad y durabilidad de un servicio, en cada uno de ellos se adopta uno de los siguientes ámbitos de disponibilidad:

• Dominio de disponibilidad local: cada dominio de disponibilidad consta de una instancia del servicio independiente. Dichos servicios ofrecen un alto nivel de durabilidad de los datos almacenados mediante la replicación síncrona de las réplicas de un mismo dominio de disponibilidad. Para obtener más información, consulta la sección sobre dominios de errores que aparece más adelante en este documento. En función de la naturaleza del servicio, los servicios pueden tolerar la interrupción de una tercera parte de la infraestructura en el dominio de disponibilidad, o más. En el dominio de disponibilidad, los servicios locales del dominio de disponibilidad logran este nivel de tolerancia a errores mediante el uso de dos tipos de centros de datos lógicos (grupos de datos lógicos de aislamiento de errores y rendimiento). Para obtener más detalles, consulta las secciones de este documento sobre los dominios de errores y celdas de servicio más adelante. Por último, estos servicios siguen funcionando de forma normal, incluso si el dominio de disponibilidad no se puede comunicar con ningún otro dominio de disponibilidad. En consecuencia, toleran la desaparición de otros dominios de disponibilidad y el fallo total de la red de área amplia en la región.
• Varios dominios de disponibilidad regional: cada una de las regiones con varios dominios de disponibilidad consta de una instancia independiente del servicio, con componentes ubicados en cada dominio de disponibilidad de la región. Estos servicios ofrecen un alto nivel de durabilidad de los datos almacenados. Para ello, aprovechan la replicación síncrona en varios dominios de disponibilidad dentro de la misma región. Estos servicios son tolerantes a la interrupción de cualquier dominio de disponibilidad en la región o a la imposibilidad de comunicarse con él.
• Un solo dominio de disponibilidad regional: si una región consta de un solo dominio de disponibilidad, las características observables de un servicio regional coinciden con las de un servicio local de un dominio de disponibilidad, que se han descrito anteriormente. La diferencia entre un servicio local de un dominio de disponibilidad y un servicio regional de un solo dominio de disponibilidad solo es relevante cuando, para ampliar una región de este tipo de dominio, se agregan uno o más dominios de disponibilidad. En ese caso, todos los servicios regionales se amplían de forma automática para utilizar adecuadamente los nuevos dominios de disponibilidad, pero no dejan de ser una única instancia del servicio. Por ejemplo, el plano de datos de almacenamiento de objetos se ampliaría para aprovechar los nuevos dominios de disponibilidad con el fin de aumentar la durabilidad de los datos existentes. Mientras que para los servicios locales de los dominios de disponibilidad, cada uno de los nuevos dominios de disponibilidad recibe su propia instancia nueva e independiente de cada servicio local de un dominio de disponibilidad.
• Distribuidos en varias regiones: una de las piedras angulares de Oracle Cloud Infrastructure es el principio de que cada región debe tener el mayor independencia operativa frente a otras regiones que sea posible. La calificación de posible refleja el hecho de que, necesariamente, las regiones deben compartir un número mínimo de infraestructuras. Por ejemplo, la red de eje entre regiones. No obstante, no establecemos mecanismos de alta vinculación entre regiones, como alta disponibilidad transparente o failover, ya que podrían causar problemas que afectaran a varias regiones al mismo tiempo. En su lugar, se ofrecen dos mecanismos para la distribución de servicios en varias regiones mediante acoplamiento débil:
  • La recuperación ante desastres (DR): nuestros clientes pueden desarrollar sistemas con características de recuperación ante desastres, que es una piedra angular de nuestro enfoque e inversión en la nube. Ya existen varios servicios básicos que ofrecen mecanismos de recuperación ante desastres: Block Volumes incluye copias de seguridad entre regiones y Object Storage, copias entre regiones. Todos nuestros servicios incorporan la funcionalidad de DR como elementos de máxima prioridad en su hoja de ruta.
  • Suscripciones entre regiones: por ahora, las suscripciones entre regiones solo están disponibles para los datos de IAM. Conceptualmente, el ámbito de los datos de IAM es global. Los clientes pueden suscribirse (mediante un proceso de inclusión) a un conjunto de regiones. A continuación, los datos de IAM y las actualizaciones correspondientes se replican de forma automática en las regiones especificadas. Para evitar una alta vinculación, la replicación es asíncrona y, en última instancia, consistente. Los clientes pueden modificar sus datos de IAM en una región "base". Si, por cualquier motivo, la región base actual deja de estar disponible o ya no es la más adecuada, se puede designar otra diferente.

Plano de control frente a plano de datos

El plano de datos de un servicio es la recopilación de interfaces y componentes de procesamiento de datos que implantan la funcionalidad del servicio que las aplicaciones deben utilizar. Por ejemplo, el plano de datos de la red virtual en la nube (VCN) incluye el sistema de procesamiento de paquetes de red, enrutadores virtualizados y puertas de enlace, mientras que el plano de datos de los volúmenes en bloque incluye la implantación del protocolo iSCSI y el sistema de almacenamiento replicado tolerante a errores para datos de volumen.

El plano de control de un servicio es el conjunto de las API y los componentes que son responsables de las siguientes tareas:

• Gestión de las solicitudes de cliente para aprovisionar, volver a configurar, escalar o reducir verticalmente o finalizar recursos
• Aplicación automática de parches a grandes conjuntos de soluciones, de forma segura y rápida
• Detección de recursos con fallos, degradados o configurados incorrectamente
• Realización de reparaciones automáticas o búsqueda de operadores humanos para obtener ayuda
• Colaboración con otros planos de control (p. ej., Compute, VCN y Block Storage están vinculados a LaunchInstance).
• Gestión de la capacidad no utilizada
• Coordinación con personas, por ejemplo, con motivo de la llegada de equipo nuevo o para llevar a cabo tareas físicas de mantenimiento y reparación
• Provisión de visibilidad y control operativos

¿Cómo garantiza Oracle que sus servicios son resilientes y están disponibles continuamente?

Para todos los tipos de servicios, utilizamos el mismo conjunto de principios de ingeniería para lograr resiliencia y disponibilidad, porque los desafíos de ingeniería fundamentales para la creación de sistemas distribuidos, ampliables y tolerantes a errores son los mismos.

Para lograr resiliencia y disponibilidad continua, es necesario comprender y, a continuación, resolver todas las causas de no disponibilidad (rendimiento degradado y fallos no controlados) de los sistemas a escala en la nube Hay un gran número de tales causas, por lo que las agrupamos en categorías según su naturaleza básica

Normalmente, los análisis de disponibilidad de los sistemas de TI empresarial se centraban en la categoría de fallos de hardware. Sin embargo, para los sistemas en la nube, el fallo de hardware es un problema relativamente pequeño y bien comprendido. En la actualidad, es relativamente sencillo evitar o mitigar la mayoría de los tipos de fallos de hardware. Por ejemplo, los racks pueden tener fuentes de alimentación dobles y unidades de distribución de energía asociadas y muchos componentes se pueden sustituir en caliente. Por supuesto, los fallos de hardware a gran escala y las pérdidas que conllevan se pueden producir, por ejemplo, debido a desastres naturales. Sin embargo, nuestra experiencia y los informes post-mortem públicos de otros proveedores de servicios en la nube demuestran que el fallo o la pérdida total de un centro de datos no se produce casi nunca en comparación con el resto de las causas de no disponibilidad. Si bien es cierto que todavía se deben subsanar fallos de hardware a gran escala (por ejemplo, con mecanismos de recuperación ante desastres, entre otros), no se trata ni de lejos del problema más frecuente

A nivel de la nube, las causas principales de no disponibilidad son las siguientes:

• Bugs de software
• Error de configuración
• Errores de los operadores humanos
  Nota: La principal lección del sector es que estas tres formas de error humano son, por mucho, las principales causas de no disponibilidad. Aunque las herramientas, la automatización y la formación pueden reducir la frecuencia, no se pueden eliminar. Por tanto, deben abordarse como principales preocupaciones en la arquitectura, el diseño y la implementación del sistema.
• Desviación inaceptable en el rendimiento (incluida la latencia) por los siguientes motivos:
  • "Vecinos ruidosos" en los sistemas multiinquilino (fallo de los mecanismos de calidad de servicio)
  • Incapacidad para rechazar eficazmente la sobrecarga (accidental o malintencionada) sin dejar de realizar un trabajo útil.
  • Hiperpaginación distribuida, tormentas de mensajes, tormentas de reintentos y otras interacciones "emergentes" costosas
  • Choque frío (cachés vacías) tras los ciclos de energía, sobre todo en el caso de ciclos de energía simultáneos de múltiples sistemas
  • Sobrecarga al ampliar el sistema (por ejemplo, al volver a realizar particiones)
• Fallo al limitar el "radio de influencia" (la cantidad de clientes y sistemas afectados) de cualquiera de las incidencias anteriores

Estos desafíos son universales. Se podría decir que forman parte de las "leyes de la física" de los sistemas distribuidos al nivel de la nube.

Para cada una de las categorías anteriores, se utilizan estrategias de ingeniería de eficacia probada para abordar el problema. Las más importantes son:

• Principios de diseño de sistemas y estructuras
• Nuevos conceptos arquitectónicos (que, en general, resultan de la aplicación de principios)
• Procedimientos de ingeniería de servicios

Principios de Diseño de Sistemas y Arquitectura

Existe un gran número de estos principios. Sin embargo, nos centraremos en aquellos relativos a la resiliencia y la disponibilidad.

Computación orientada a la recuperación

Para manejar los bugs de software y los errores de los operadores que tienen efectos relativamente localizados, se siguen los principios de la informática orientada a la recuperación¹. A grandes rasgos, esto significa que, en lugar de intentar garantizar que nunca se produzca un problema (algo imposible de probar), nos centramos en la resolución discreta de los problemas, de una forma que se puede probar. En particular, nos centramos en minimizar el tiempo medio de reparación (MTTR), que es una combinación del tiempo medio para detectar, diagnosticar y mitigar.

Nuestro objetivo es que la reparación sea tan rápida que los usuarios humanos no se vean afectados por el problema. Para alcanzar este objetivo, se deben cumplir los siguientes criterios:

• Detecta de forma rápida y automática los síntomas de bugs y errores cometidos por operadores, mediante el uso excesivo de afirmaciones en el código, y mediante el control y la detección activos en todos los niveles.
• Separación de las funcionalidades en muchas unidades de aislamiento independientes y granulares (subprocesos, procesos, fibras, máquinas de estados, etc.) poco vinculadas, es decir, que no comparten directamente una memoria que podría dañarse.
• Al detectar los síntomas de un bug o de un error cometido por un operador, la unidad de aislamiento delimitada se reinicia automáticamente y tan rápidamente como sea posible. Reiniciar es una forma práctica de intentar recuperarse de un fallo arbitrario, porque intenta restablecer un estado que ha sido bien probado, y así restaura invariables.
• Si la recuperación en el nivel de aislamiento detallado no funciona (por ejemplo, las afirmaciones siguen activándose en ese nivel con una alta frecuencia, lo que provoca una serie de bloqueos), es necesario pasar a la siguiente unidad de mayor tamaño (proceso, tiempo de ejecución, host, centro de datos lógicos, búsqueda de un operador humano).
• Creación de mecanismos mediante los que se lleva a cabo una acción de deshacer en todo el sistema, incluido el control de versiones de cualquier estado y configuración persistentes, con el fin de identificar las confirmaciones incorrectas y deshacerlas con rapidez.

Minimización de los efectos de las incidencias

Para tratar los bugs y errores que pueden entrañar efectos más amplios, se crean mecanismos para minimizar el "radio de influencia" de cualquier incidencia. Es decir, trabajamos para reducir al mínimo el número de clientes, sistemas o recursos que pueden verse afectados por cualquier problema, sobre todo por aquellos especialmente peliagudos, como los "vecinos ruidosos" en los sistemas multiinquilino, la sobrecarga ofertada, la capacidad degradada y el bloqueo distribuido. Para lograrlo, se utilizan una variedad de límites de aislamiento y prácticas de gestión de cambios (consulta las secciones posteriores).

Conceptos arquitectónicos de los principios de diseño

Aunque existen muchos de estos conceptos, nos centraremos en aquellos que sirven para limitar el radio de influencia.

Conceptos de colocación recogidos en nuestras API públicas: regiones, dominios de disponibilidad y dominios de errores

Puesto que los dominios de errores son relativamente recientes, los describiremos con mayor detalle.

Los dominios de errores sirven para limitar el radio de influencia de los problemas que ocurren cuando se realizan cambios activos en un sistema, por ejemplo, despliegues, aplicación de parches, reinicios del hipervisor y actividades de mantenimiento físico.

Es decir, se tiene la certeza de que, en un dominio de disponibilidad cualquiera y en un momento determinado, se están modificando los recursos en un dominio de errores (como máximo). Es posible que, si surgen complicaciones durante el proceso de cambio en el dominio de errores en cuestión, todos sus recursos o parte de ellos no estén disponibles temporalmente. Sin embargo, esto no afecta a los demás dominios de errores en el dominio de disponibilidad. Cada dominio de disponibilidad consta de un mínimo de tres dominios de errores, lo que hace que sea posible alojar con un alto nivel de disponibilidad los sistemas de replicación basados en quórum (como Oracle Data Guard) en un solo dominio de disponibilidad.

Por tanto, cada una de las principales categorías de problemas que afectan a la disponibilidad (bugs de software, errores de configuración o cometidos por operadores, así como problemas que afectan al rendimiento que ocurren durante procesos de cambio), es un centro de datos lógico independiente dentro de un dominio de disponibilidad.

Los dominios de errores también protegen contra ciertos fallos de hardware localizados. Las propiedades de los dominios de errores garantizan, en la mayor medida práctica, que los recursos situados en dominios de errores no comparten ningún detonante potencial de un fallo de hardware dentro del dominio de disponibilidad. Por ejemplo, los recursos en distintos dominios de errores no comparten el mismo conmutador de red para parte superior del rack, porque su diseño estándar no ofrece redundancia.

Sin embargo, la capacidad de los dominios de errores de proteger contra problemas en el hardware o el entorno físico se detiene en ese nivel local. A diferencia de los dominios de disponibilidad y las regiones, los dominios de errores no proporcionan aislamiento físico de la infraestructura a gran escala. En el caso poco probable de que se produzca un desastre natural o un fallo de toda la infraestructura del dominio de disponibilidad, este afectaría posiblemente a múltiples dominios de errores de forma simultánea.

Nuestros servicios internos utilizan dominios de errores de la misma manera que los clientes. Por ejemplo, los servicios de volúmenes en bloque, almacenamiento de objetos y almacenamiento de archivos protegen las replicas de los datos en tres dominios de errores independientes. Todos los componentes de la totalidad de planos de control y planos de datos se alojan en dichos dominios de errores (o, en uno de ellos, en varios dominios de disponibilidad).

Celdas de servicio

Las celdas de servicio sirven para limitar el radio de influencia de las incidencias que tienen lugar aunque no se realicen cambios en un sistema activamente. Estos problemas pueden deberse a que la carga de trabajo de un sistema multiinquilino en la nube puede cambiar de forma extrema en cualquier momento y a que, en un sistema distribuido de gran tamaño, pueden producirse fallos parciales complejos en cualquier momento. En estos escenarios, puede que se produzcan errores ocultos o problemas emergentes que afectan al rendimiento.

Además, las celdas de servicio también limitan el radio de influencia en aquellos escenarios en los que se realiza un cambio activo en el sistema. Un ejemplo clásico es cuando un despliegue en un dominio de errores parece haberse realizado correctamente (sin errores ni cambios en el rendimiento), pero tan pronto como se actualizan el segundo o el último dominio de errores, las nuevas interacciones en el sistema (a plena escala en la nube y con cargas de trabajo de producción) causan problemas de rendimiento.

Ten en cuenta que las celdas de servicio son patrones arquitectónicos, no conceptos que se nombran explícitamente en el SDK o la API de Oracle Cloud. Cualquier sistema multiinquilino puede seguir este patrón arquitectónico, no se requiere ninguna característica especial de la plataforma en la nube.

Las celdas de servicio funcionan de la siguiente manera:

• Cada instancia del servicio (por ejemplo, en una región particular o un dominio de disponibilidad concreto, si se trata de servicios locales de un dominio de disponibilidad), consta de varios despliegues independientes de la pila de software del servicio. Cada uno de ellos se denomina celda. En la práctica, cada celda se aloja en su propia infraestructura. Como mínimo, no deben compartir ningún host ni máquina virtual.
• Es posible que un servicio se inicie con algunas celdas en cada región o dominio de disponibilidad. A medida que se amplíe el servicio para satisfacer el aumento de la demanda, se agregarán más celdas para mantener el límite impuesto al radio de influencia en caso de que se produzcan incidencias. Es posible que un servicio popular y de gran tamaño tenga muchas celdas. Dicho de otro modo, las celdas ofrecen una multiplexación de n-a-m de las cargas de trabajo de cliente a distintos entornos de alojamiento, una isla de aislamiento de recursos. Por ejemplo, las celdas no tienen una cardinalidad evidente. (Como ya se ha señalado, una opción obvia para la cardinalidad de los dominios de errores es tres por dominio de disponibilidad, con el fin de permitir que los sistemas de replicación basados en cuórum se alojen con alta disponibilidad en un solo dominio de disponibilidad.)
• Cada "unidad natural" de una carga de trabajo de cliente se asigna a una celda individual. La definición de "unidad natural" depende de la naturaleza de cada servicio concreto. Por ejemplo, en el caso de nuestro servicio de flujos de trabajo compartidos internos (que se describe más adelante), la unidad natural es "todos los flujos de trabajo en este dominio de disponibilidad o región para un plano de control específico".
• En frente de cada grupo de celdas habrá una capa de enrutamiento minimalista o una API para detectar puntos finales de celda. Por ejemplo, el sistema de transmisión y mensajería tiene una API para detectar el punto final del plano de datos actual de un tema concreto, y el almacén interno de metadatos tiene un punto final independiente por celda. Sin embargo, otros servicios basados en celdas tienen un único punto final para el plano de datos y una capa de enrutamiento compartido. La capa de enrutamiento es una causa potencial de fallos correlacionados en múltiples celdas, pero se puede mitigar. Para ello, conviene que la capa de enrutamiento sea lo más sencilla, predecible y con el mayor rendimiento posible (sin operaciones de alto costo). Asimismo, se debe aprovisionar con una gran cantidad de capacidad para disponer de margen de maniobra, altas cuotas de calidad de servicio y mecanismos de limitación.
• Los propietarios del servicio pueden migrar una carga de trabajo de una celda a otra, según sea necesario. Estos son algunos escenarios de ejemplo:
  • Para evitar incidencias producidas por "vecinos ruidosos" en los sistemas multiinquilino, se puede trasladar una carga de trabajo de gran volumen, de modo que otros usuarios de una celda no se vean afectados.
  • Para favorecer la recuperación tras una sobrecarga o un bloqueo parcial, que puede deberse a un ataque distribuido de denegación de servicio. Disponemos de cuota y mecanismos de limitación para defender contra esos ataques, pero a veces se producen casos extremos en los que un caso de uso específico (API, patrón de acceso) es más exigente para el servicio de lo que abarca el sistema de cuotas o limitaciones. Las celdas ofrecen mecanismos de mitigación a corto plazo.
  • Para separar cargas de trabajo esenciales en celdas independientes y reducir drásticamente la probabilidad de que fallen. Por ejemplo, en nuestro flujo de trabajo interno compartido para los planos de control, se asignan celdas distintas a aquellos planos considerados como básicos y esenciales (como Platform, Compute, Networking y Block Volumes), por lo que su correlación de fallos es mucho menor que si no se utilizaran celdas, o si les se asignara la misma celda.
    Nota: El uso de celdas reduce la necesidad de que los clientes consideren las dependencias internas de los servicios para desarrollar aplicaciones resilientes. Si bien se recomienda consultar el gráfico de dependencias (más información sobre esto en secciones posteriores de la documentación), no es tan necesario si se ha activado el mecanismo de anulación de correlación.

El resultado es que cada celda de servicio es otro tipo de "centro de datos lógicos", una agrupación lógica de aislamiento de rendimiento y fallos, en un solo dominio de disponibilidad o región.

En resumen, las celdas de servicio y los dominios de errores se complementan mutuamente, tal como se aprecia a continuación:

• Los dominios de errores hacen frente a las incidencias cuando se realizan cambios activos en un sistema.
• Las celdas de servicio limitan el radio de influencia cuando un sistema se enfrenta a incidencias potencialmente graves, tanto si se realizan cambios activos como si no.

Nuestra estrategia unifica las características de los dominios de errores y de las celdas de servicio cuando es necesario desplegar y aplicar parches.

Procedimientos de ingeniería de servicios

Contamos con un amplio espectro de procedimientos de ingeniería, porque tanto las pruebas como la excelencia operativa son fundamentales para la fiabilidad de los sistemas en la nube. A continuación, algunas de las más importantes que aprovechan los conceptos mencionados en la sección anterior:

• Los servicios de despliegue se despliegan de forma incremental, con una cuidadosa validación entre los pasos y un rollback reflexivo, en caso de que ocurra algún imprevisto. En términos concretos, el proceso es el siguiente:
  • En cada dominio de disponibilidad se despliega en una celda de servicio a la vez. En cada una de ellas, se despliega en un dominio de errores a la vez, hasta que no se hayan completado todos los dominios de errores para esa celda. A continuación, se pasa a la siguiente celda en el dominio de disponibilidad.
  • Tras cada uno de los pasos del despliegue (después de haber desplegado los correspondientes dominios de errores en las celdas), se realiza una validación, para verificar si el cambio tiene los efectos deseados. Se comprueba si se ha degradado el rendimiento o se han introducido errores, tanto internos como externos. En caso de que algo no se ajuste a las expectativas o sea incorrecto, se anula de forma reflexiva el cambio. Destacamos en gran medida la preparación y las pruebas, incluidas las pruebas automatizadas, de los procedimientos de rollback, incluidos los cambios que afectan a los esquemas o estados persistentes.
  • Así pues, en cada región se despliegan los cambios de uno en uno de los dominios de disponibilidad. Los desplegamos en todas las regiones de un dominio de tal forma que no modificamos al mismo tiempo ningún par de regiones que un cliente pueda utilizar para sitios de recuperación principal o ante desastres.
• Verificamos con regularidad que los mecanismos de manejo de errores y otras herramientas de mitigación funcionen de la manera prevista y no empeoren el problema a escala. Si estas pruebas, es habitual que los mecanismos de manejo de errores (como reintentos, algoritmos de recuperación tras bloqueos y algoritmos de reconfiguración de máquinas de estados) contengan errores, sean demasiado caros o interactúen de forma sorprendente y, por lo tanto, causen hiperpaginación distribuida u otros problemas graves de rendimiento.
• Tal como se ha indicado anteriormente, verificamos nuestra capacidad para realizar un rollback de forma rápida y segura, mediante un software y una configuración correctos, incluidos el estado y el esquema persistentes.

En las regiones de Oracle que constan de varios dominios de disponibilidad, ¿los dominios de disponibilidad son todos servicios esenciales?

Sí. En cada una de las regiones, los dominios de disponibilidad ofrecen los mismos conjuntos de servicios.

¿De qué modo evitan Oracle y sus clientes que un servicio esencial dependa de un solo centro de datos lógico?

En las regiones de dominios de disponibilidad única, los clientes pueden recurrir a los dominios de errores (grupos lógicos con modos de error sin correlación entre grupos) para beneficiarse de la mayoría de las propiedades de los "centros de datos lógicos" independientes. Los clientes también pueden utilizar varias regiones para la recuperación ante desastres (DR).

En las regiones con varios dominios de disponibilidad, los clientes pueden utilizar los dominios de errores del mismo modo. Asimismo, los clientes pueden combinar los servicios locales de los dominios de disponibilidad, las funciones de failover entre dominios de disponibilidad (como DBaaS con Data Guard) y servicios regionales (Object Storage, Streaming) para lograr alta disponibilidad completa en todos los centros de datos lógicos de nivel superior (dominios de disponibilidad). Por último, los clientes pueden utilizar varias regiones para la recuperación ante desastres.

En todos los casos, los clientes pueden utilizar el concepto de las celdas de servicio para aislar más si cabe hasta las incidencias más graves, como la hiperpaginación distribuida.

¿Cómo realiza Oracle las actividades de mantenimiento sin que ningún servicio crítico esté disponible temporalmente para ningún cliente?

Las interrupciones temporales se evitan de la mano de los dominios de errores, las celdas de servicio y nuestros procedimientos operativos para el despliegue y la validación incrementales, como señalamos anteriormente en este documento.

¿Se despliegan los servicios de la plataforma sin servidor en varios centros de datos lógicos para una mayor disponibilidad?

Sí. Todas las categorías de servicios se despliegan en varios centros de datos lógicos, que son agrupaciones lógicas independientes de aislamiento de errores y de rendimiento, para ofrecer resiliencia y disponibilidad continua.

Si la resiliencia no es la configuración por defecto, ¿se ofrece a los clientes la oportunidad de realizar despliegues a través de varios centros de datos lógicos? Por ejemplo, mediante una configuración entre regiones o que tenga varios dominios de disponibilidad.

Como se ha indicado en otra parte de este documento, cuando se trata de regiones de dominios de disponibilidad única, los dominios de errores se ofrecen como el mecanismo que reemplaza a "varios centros de datos lógicos".

En las regiones con dominios de disponibilidad múltiple, ofrecemos servicios y funciones que proporcionan un nivel todavía mayor de durabilidad física de los datos replicados de forma síncrona (con una relación rendimiento-costo limitada a causa de la distancia entre los dominios de disponibilidad de la región y la velocidad de la luz).

No ofrecemos alta disponibilidad automática ni mecanismos de failover entre regiones, ya que podría crearse una relación de alta dependencia entre ellas que incrementaría el riesgo de que varias presentaran problemas de forma simultánea. En su lugar, activamos varias formas de replicación asíncrona entre regiones, y ofrecemos una lista de características en expansión, como copia y copia de seguridad asíncronas, lo que permite la recuperación de fallos entre regiones.

Oracle ayuda a los clientes a evitar el fallo correlacionado de aplicaciones provocado por dependencias internas entre su gama de servicios de infraestructura y plataforma.

Como se trata de una pregunta compleja, nos parece necesario reformularla para que sea más fácil de comprender:

• Si un cliente desea utilizar dos servicios de Oracle (los servicios A y B) y pretende desarrollar una aplicación que sea resiliente en caso de que cualquiera de ellos falle, ¿es necesario que el cliente sepa si el servicio A depende internamente del servicio B? ¿Es cierto que las dependencias internas se traducen en un fallo correlacionado? Si es así, es posible que el cliente tenga que conocer dichas dependencias internas. Si lo desea, al desarrollar sus propios mecanismos de resiliencia en el nivel de la aplicación, puede que el cliente tenga que utilizar los servicios A y B para otros fines o, incluso, podría recurrir al servicio independiente C para esos casos.
• ¿Cómo defiende mejor al cliente en caso de que se produzca un fallo correlacionado de los servicios de Oracle?

La respuesta consta de dos partes.

Principios arquitectónicos

Utilizamos principios arquitectónicos que permiten reducir notablemente la frecuencia de fallos relacionados entre servicios dependientes. En algunos casos, esta técnica reduce la probabilidad de fallo correlacionado hasta tal punto que se puede ignorar desde la perspectiva de cumplir un acuerdo de nivel de servicio de disponibilidad (SLA).

En concreto, utilizamos celdas de servicio, a las que se hace referencia en más detalle en este documento. Las células ayudan con este problema porque, si el servicio interno A se ve afectado por un fallo en una de sus dependencias, el servicio B, es muy probable que este se limite a una sola celda. Es probable que otros servicios de nivel superior y las aplicaciones del cliente que utilizan el servicio B utilicen otras celdas que no se vean afectadas. Argumento probabilístico que varía en función del número de celdas, un parámetro interno oculto que sufre modificaciones (aumentos), por lo que no se puede proporcionar garantía ni cuantificación. Por lo tanto, será necesario atenerse a los SLA independientes de los servicios A y B. Sin embargo, en la práctica, esto puede disminuir la correlación de los fallos entre servicios.

Muchos de nuestros servicios internos compartidos, como los servicios de flujo de trabajo y metadatos para los planos de control, así como el de transmisión y envío de mensajes, utilizan celdas de servicio para reducir la correlación de las interrupciones para los servicios ascendentes que las utilizan.

Dependencias

La siguiente orientación es a grandes rasgos y puede diferir (y lo hará) de la implementación real y de los detalles de cada servicio. No obstante, en el caso de las dimensiones clave de recursos informáticos, almacenamiento, redes y autenticación/autorización, destacaremos las siguientes dependencias:

En planos de control, las dependencias comunes son las siguientes:

• Plano de datos de identidad o plataforma para autenticación o autorización
• Servicio de seguimiento de auditorías
• Servicios internos que ofrecen, entre otros, flujo de datos, almacenamiento de metadatos y registro
• Equilibradores de carga de varios tipos

Obviamente, algunos planos de control tienen dependencias específicas. Por ejemplo, al iniciar una instancia de VM o hardware dedicado, el plano de control de recursos informáticos depende de:

• Object Storage (para recuperar la imagen del sistema operativo especificada)
• Plano de control de Block Volumes (para aprovisionar y asociar el volumen de inicio)
• Plano de Networking (para aprovisionar y asociar VNIC)

El principio general aplicado a los planos de datos de servicios esenciales es que cada plano de datos está diseñado de forma intencional para tener las mínimas dependencias, con el fin de lograr una alta disponibilidad, un tiempo de diagnóstico y un tiempo de recuperación rápidos. Los resultados de este principio son los siguientes:

• El plano de datos de Networking es independiente.
• El plano de datos de Block Volumes es independiente.
• Las instancias informáticas de hardware dedicado y máquinas virtuales dependen del plano de datos de Block Volumes (para los volúmenes de inicio) y del plano de datos de Networking.
• El plano de datos de Object Storage depende del plano de datos de identidad y plataforma para las acciones de autenticación y autorización (debido a las expectativas del sector). El plano de datos de Object Storage no depende de Block Volumes ni de File Storage.
• Todos los servicios que permiten las funciones de copia de seguridad y restauración dependen del plano de datos de Object Storage.

Como principio general en cuanto a los planos de datos IaaS, solo se depende de los planos de datos básicos o de bajo nivel (con el fin de evitar dependencias cíclicas).

• La base de datos RAC de varios nodos depende de los planos de datos de Networking y Block Storage.
• Como no cabe duda de que Container Engine for Kubernetes depende de Kubernetes y de sus dependencias transitivas (como etcd) y del plano de Networking.
• La copia de seguridad y la restauración dependen por completo del plano de datos de Object Storage.

¿Seguirán funcionando los servicios de Oracle Cloud Infrastructure en una región, incluidos los puntos finales de API regionales, si están aislados de las funciones del plano de control global?

Sí, los servicios de Oracle Cloud Infrastructure están diseñados para ser independientes de las regiones, de forma que los servicios de una región de Oracle Cloud Infrastructure puedan seguir funcionando incluso cuando la región esté aislada de otras regiones de Oracle Cloud Infrastructure o plano de control global. Tanto la funcionalidad de plano de datos como la de plano de control, incluidos los puntos finales de API de servicio, siguen estando disponibles aunque la región esté aislada.

Muchos servicios de Oracle Cloud Infrastructure ofrecen funciones en varias regiones, como la función de copia de objetos entre regiones que ofrece Oracle Cloud Infrastructure Object Storage. La funcionalidad entre regiones de Oracle Cloud Infrastructure está siempre diseñada como una capa sobre el servicio principal, de forma que el aislamiento de regiones no perjudique el servicio principal, aunque afecte la funcionalidad entre regiones. Por ejemplo, la funcionalidad de copia entre regiones del almacén de objetos de Oracle Cloud Infrastructure está diseñada como una capa sobre el servicio de almacén de objetos y, por lo tanto, el aislamiento de una región puede afectar a la función de copia entre regiones relevante, pero no afectará al servicio de almacenamiento de objetos principales de la región.

¿Seguirán funcionando los servicios de Oracle Cloud Infrastructure en un centro de datos lógico si están aislados de las funciones del plano de control regional?

Sí, los servicios de Oracle Cloud Infrastructure están diseñados para que la funcionalidad de plano de datos en cada centro de datos lógico siga funcionando, incluso aunque esté aislada del plano de control regional correspondiente. Por ejemplo, las instancias informáticas de Oracle Cloud Infrastructure en un centro de datos lógico seguirán funcionando junto con los volúmenes en bloque asociados y la funcionalidad de red virtual asociada, incluso cuando el centro de datos esté aislado de las funciones de plano de control de recursos informáticos, almacenamiento de bloques, VCN y/o gestión de identidad y acceso.

¿Las regiones de Oracle Cloud Infrastructure tienen conexiones de Internet redundantes para una alta disponibilidad?

Sí. Oracle Cloud Infrastructure está conectado a Internet a través de varios proveedores redundantes en todas las regiones comerciales. Estas conexiones utilizan el protocolo BGP (Border Gateway Protocol).