Exención de responsabilidad

En la siguiente documentación se describe la dirección general de nuestros productos. Puesto que se ha redactado con fines meramente informativos, no es susceptible de incorporarse a ningún contrato. No supone compromiso alguno de entrega de ningún material, código o funcionalidad, ni debe utilizarse como base para la adopción de decisiones de compra. El desarrollo, la publicación, el plazo de puesta a disposición y el precio de cualesquiera funciones o funcionalidades descritas de los productos de Oracle pueden cambiar y quedarán a la sola discreción de Oracle Corporation.

A continuación, se ofrecen respuestas a preguntas frecuentes con respecto a los métodos que utiliza Oracle para garantizar la resiliencia y la disponibilidad continua de los servicios de la infraestructura base y de la plataforma de alojamiento. Hay diversos motivos por los que dichas respuestas resultarán de utilidad para los clientes de Oracle Cloud:

  • Sirven de orientación para actuar con la diligencia debida al evaluar tanto los servicios como la plataforma de alojamiento de Oracle.
  • En varias de las respuestas se exponen tanto desafíos como soluciones inherentes a todos los sistemas al nivel de la nube. Por tanto, los clientes que deseen desarrollar uno pueden utilizarlas como referencia en términos de arquitectura y diseño.

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, ¿distingue entre servicios esenciales, servicios disponibles de forma continua o servicios de ubicación única?

No se hacen distinciones. Sin embargo, sí se clasifican los servicios según nivel de dependencia, ámbito de disponibilidad y se distingue entre el plano de datos y el plano de control. Dichas categorías permiten seleccionar niveles de disponibilidad, durabilidad, rendimiento y comodidad idóneos.

Niveles de dependencia

Se pueden contemplar como capas o niveles de un diagrama de bloques de arquitectura. Es posible que una capa dependa únicamente de otras inferiores.

De abajo a arriba:

  • 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, telemetría y muchos más servicios internos compartidos. Se han desarrollado para reducir la cantidad de dependencias tanto como sea posible, incluso aunque sean mutuas. (Encontrará más información sobre las dependencias en secciones posteriores de esta documentación.)
  • IaaS: esta capa ofrece más funcionalidades a nivel de infraestructura, basadas en los servicios básicos. Esta capa contiene los servicios de base de datos, almacenamiento de archivos y Container Engine for Kubernetes.
  • SaaS: esta capa ofrece software como servicio integral, que se ha desarrollado sobre las capas precedentes.
Ámbito 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. Para ello, aprovechan la replicación síncrona entre réplicas dentro del mismo dominio de disponibilidad (para obtener más información al respecto, consulte la sección de esta documentación relativa a los dominios de errores, que se encuentra más adelante). En función de su naturaleza, los servicios locales de los dominios de disponibilidad son capaces de tolerar la interrupción de una tercera parte de la infraestructura en el dominio de disponibilidad, o incluso de más. Su nivel de tolerancia a errores se debe a que, dentro del dominio de disponibilidad, se utilizan dos tipos de centros de datos lógicos, que son grupos lógicos de aislamiento de errores y rendimiento. Para obtener más información al respecto, consulte las secciones de esta documentación relativas a los dominios de errores y celdas de servicio, que se encuentran más adelante. Por último, estos servicios son capaces de funcionar con normalidad incluso si se interrumpe la comunicación entre dominios de disponibilidad. En consecuencia, toleran la desaparición de otros dominios de disponibilidad e incluso 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. Dichos 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 capaces de tolerar la interrupción de cualquier dominio de disponibilidad en la región y funcionan incluso aunque no puedan comunicarse con ellos.
  • 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 ya se han descrito. La diferencia entre un servicio local de un dominio de disponibilidad y un servicio regional de un solo dominio de disponibilidad únicamente es relevante cuando, para expandir la región de este último tipo de dominio, se agregan uno o más dominios de disponibilidad. Llegado el 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. En cuanto a los servicios locales de los dominios de disponibilidad, ocurre a la inversa. Todos los dominios de disponibilidad que se generan reciben una nueva instancia, propia 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 grado de independencia operativa frente a otras regiones que sea posible. Este criterio de posibilidad refleja el hecho de que, obligatoriamente, las regiones deben compartir un número mínimo de infraestructuras. Por ejemplo, la red de eje central entre regiones. Al margen de lo indicado, no se desarrollan mecanismos de acoplamiento fuerte entre regiones, tales como alta disponibilidad transparente o failover, ya que podrían provocar problemas que perjudicaran 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:
    • Recuperación ante desastres (DR): nuestros clientes pueden desarrollar sistemas con características de DR. Se trata de un pilar de nuestro enfoque e implicación en la nube. Ya existen varios servicios básicos que ofrecen mecanismos de DR. Como ejemplo, se pueden citar la copia de seguridad entre regiones de los volúmenes en bloque y la copia entre regiones del almacenamiento de objetos. Todos nuestros servicios incorporan funcionalidades 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. En términos conceptuales, 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 sus actualizaciones correspondientes se replican de forma automática en las regiones especificadas, siempre que sean relevantes. Para prescindir del acoplamiento fuerte, se opta por la replicación asíncrona y consistente en última instancia. Los clientes pueden designar una región "inicial" en la que pueden modificar sus datos de IAM. Si, por cualquier motivo, la región inicial actual deja de estar disponible o no resulta apropiada, se puede designar otra nueva.
Diferencias entre el plano de control y el 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 gateways. Por su parte, 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 se encargan de las siguientes tareas:

  • Gestión de las solicitudes de cliente relacionadas con las acciones de aprovisionamiento, nueva configuración, escala o reducción vertical o finalización de recursos
  • Aplicación automática de parches de flotas de gran tamaño, de forma segura y rápida
  • Detección de recursos fallidos, 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.: los servicios de recursos informáticos, redes virtuales en la nube y almacenamiento de bloques se vinculan durante 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?

En materia de ingeniería, los desafíos prioritarios a la hora de desarrollar sistemas tolerantes a errores, ampliables y distribuidos son los mismos. Por tanto, con independencia del tipo de servicio, se utiliza un mismo conjunto de principios de ingeniería, mediante los que se garantizan tanto la resiliencia como la disponibilidad.

En primer lugar, es fundamental comprender las causas que provocan que un sistema al nivel de la nube no esté disponible, como el rendimiento degradado o los fallos no identificados. Solo entonces se podrá contrarrestar dichos problemas y, por tanto, garantizar resiliencia y disponibilidad continua. Dado que abundan dichas causas, es necesario clasificarlas por categorías según su naturaleza básica.

Hasta no hace mucho, los análisis de disponibilidad para sistemas de TI empresarial se concentraban en la categoría de fallos de hardware. Sin embargo, no es un problema que afecte con frecuencia a los sistemas en la nube y, aunque se diera el caso, contamos con los conocimientos para resolverlo. Hoy en día, los puntos de fallo específicos que desencadenan un fallo de hardware se pueden prevenir o mitigar con relativa facilidad. Por ejemplo, los racks pueden tener fuentes de alimentación duales y unidades de alimentación asociadas y muchos componentes se pueden sustituir en caliente. Esto no significa, por supuesto, que los fallos de hardware a gran escala y las pérdidas que conllevan no se produzcan. Los desastres naturales pueden provocarlos. A pesar de ello, se puede asegurar, tanto a partir de nuestra experiencia como de los informes finales públicos de otros proveedores de servicios en la nube, que el fallo general de un centro de datos o su pérdida son fenómenos extremadamente inusuales, en comparación con el resto de las causas de no disponibilidad. Si bien es cierto que se deben gestionar los fallos de hardware a gran escala (mediante mecanismos de recuperación ante desastres, entre otros), otros problemas que afectan a la disponibilidad son mucho más acuciantes.

A continuación, se presentan las causas principales de indisponibilidad en los sistemas al nivel de la nube:

  1. Bugs de software
  2. Errores de configuración
  3. Errores cometidos por operadores humanos
    Nota: Si algo ha quedado patente en el sector es que las tres formas de error humano indicadas son las principales razones por las que un sistema deja de estar disponible. Aunque existen herramientas con las que reducir su frecuencia y se pueden utilizar tanto la formación como la automatización para tal fin, no es posible eliminarlos. Por tanto, el planteamiento de las fases de arquitectura, diseño e implantación del sistema debe centrarse en dichos problemas.
  4. Varianza inaceptable en el rendimiento (incluida la latencia) por los motivos que sean, entre los que se incluyen los siguientes:
    • "Vecinos molestos" multi-inquilino (fallo de los mecanismos de QoS)
    • Incapacidad para rechazar sobrecargas (tanto accidentales como maliciosas) de forma eficiente, al mismo tiempo que se prosigue con las tareas.
    • Hiperpaginación distribuida, tormentas de mensajes, tormentas de reintentos y otras interacciones "emergentes" costosas
    • Choque frío (cachés vacías) después de apagar y volver a encender, sobre todo si esta acción se lleva a cabo al mismo tiempo en varios sistemas
    • Sobrecarga al ampliar el sistema (por ejemplo, si se vuelven a realizar particiones)
  5. 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 contrarrestar cualquiera de los problemas en las categorías anteriores, se utilizan estrategias de ingeniería de eficacia probada. Los más importantes son las siguientes:

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

Existen muchos principios que encajan en esta categoría, pero nos centraremos en los que son clave en términos de resiliencia y disponibilidad.

Informática orientada a la recuperación

Para identificar bugs de software y errores cometidos por operadores, con una repercusión relativamente local, se siguen los principios de la informática orientada a la recuperación1. En un nivel superior, esto significa que, en lugar de esforzarse para que jamás se produzca un problema (algo imposible de probar), el énfasis se coloca en la resolución discreta de los problemas, de una forma que se puede probar. Sobre todo, nos centramos en minimizar el tiempo medio para la recuperación (MTTR), que es la suma de los tiempos medios dedicados a la detección, diagnóstico y mitigación.

Nuestro objetivo es la recuperación rápida. De este modo, nuestros usuarios no sufrirán perjuicios a raíz de la incidencia. Para alcanzar este objetivo, se cumplen los siguientes puntos:

  • Detección rápida y automática de los indicios de bugs y errores cometidos por operadores o debidos al uso excesivo de afirmaciones en el código, para lo que se aplican el control y la detección activos en todos los niveles.
  • Separación de funcionalidades como muchas unidades de aislamiento independientes y detalladas (threads, procesos, fibras, máquinas de estados, etc.) acopladas de forma débil, es decir, no comparten directamente una memoria que podría dañarse.
  • Cuando se detectan indicios de que se ha producido un bug o un operador ha cometido un error, la unidad de aislamiento delimitada se reinicia automáticamente y tan rápido como sea posible. Esta medida es una forma práctica de recuperarse frente a un fallo arbitrario, puesto que trata de restablecer un estado que se ha probado a fondo, para lo que restaura las invariables.
  • Si la recuperación en el nivel de aislamiento detallado no es eficaz (por ejemplo, porque las afirmaciones siguen activándose en dicho nivel con una alta frecuencia y esto provoca una serie de bloqueos), será 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).
  • Desarrollo de mecanismos mediante los que se lleva a cabo una acción de "deshacer" que abarca todo el sistema. Esto incluye el control de versiones de cualquier estado y configuración persistentes, lo que permite identificar las confirmaciones incorrectas y deshacerlas con rapidez.

Minimizar los efectos de las incidencias

Para hacer frente a los bugs y errores que pueden entrañar una repercusión generalizada, se desarrollan mecanismos concebidos para minimizar el "radio de influencia" de cualquier incidencia. Es decir, trabajamos para minimizar el número de clientes, sistemas o recursos que pueden verse afectados por dichas incidencias, incluso aquellas de carácter especialmente problemático, como "vecinos molestos" multi-inquilino, sobrecarga ofertada, capacidad degradada e hiperpaginación distribuida. Para lograrlo, se utilizan una variedad de límites de aislamiento y prácticas de gestión de cambios (consulte las secciones posteriores).

Conceptos arquitectónicos derivados de los principios de diseño

Si bien hay un gran número de estos conceptos, vamos a centrarnos 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 lujo de detalles.

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 afectará 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 cuórum (como Oracle Data Guard) dentro de 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 incidencias relacionadas con el rendimiento que ocurren durante procesos de cambio), cuenta con dominios de errores que funcionan como centros de datos lógicos independientes dentro de los dominios de disponibilidad correspondientes.

Asimismo, los dominios de errores resguardan frente a ciertos fallos de hardware localizados. Las propiedades de los dominios de errores garantizan, en la medida de lo posible, que los recursos situados en dominios de errores independientes 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, puesto que su diseño estándar no ofrece redundancia.

No obstante, los dominios de errores solo sirven de escudo contra los problemas que afectan al hardware o al entorno físico en el nivel local. Los dominios de errores no ofrecen aislamiento físico de la infraestructura a gran escala, al contrario que las regiones y los dominios de disponibilidad. Por improbable que sea, si un desastre natural azotara la infraestructura o si se produjese un fallo que afectara al conjunto de la infraestructura del dominio de disponibilidad, cabe pensar que afectaría también a los recursos en varios dominios de errores.

Nuestros servicios internos utilizan dominios de errores tal como deberían hacer los clientes. Por ejemplo, los servicios de volúmenes en bloque, almacenamiento de objetos y almacenamiento de archivos protegen las réplicas de los datos en tres dominios de errores independientes. Del mismo modo, todos los componentes de la totalidad de planos de control y planos de datos se alojan en dichos dominios de errores (o en varios dominios de disponibilidad, si se trata de una región con esas características).

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. Este tipo de problemas pueden ser consecuencia de cambios extremos en la carga de trabajo de un sistema en la nube multi-inquilino o de fallos parciales complejos en un sistema distribuido de gran tamaño. Ambas incidencias pueden ocurrir en cualquier momento. Estos escenarios pueden activar bugs ocultos e inadvertidos 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 cambia activamente el sistema, que, a pesar de no ser frecuentes, revisten dificultades. Por ejemplo, puede que a primera vista no se aprecien errores o cambios en el rendimiento cuando se realiza un despliegue en un dominio de errores individual, pero tan pronto como se actualiza el segundo o el último dominio de errores, las nuevas interacciones en el sistema (al nivel de la nube completa y con cargas de trabajo de producción) provocarán incidencias que afecten al rendimiento.

Tenga en cuenta que "celdas de servicio" es un patrón arquitectónico, no un concepto que aparezca por dicho nombre ni en el SDK ni en la API de Oracle Cloud. Se trata de un patrón arquitectónico que se puede utilizar en cualquier sistema multi-inquilino y que no requiere compatibilidad especial con la plataforma en la nube.

El funcionamiento de las celdas de servicio es el siguiente:

  • 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 estos despliegues individuales se denomina celda. En la medida de lo posible, cada celda se aloja en su propia infraestructura. Como mínimo, no deben compartir ni hosts ni máquinas virtuales.
  • 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. Por ejemplo, un servicio popular y de gran tamaño tendrá un gran número de 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, un archipiélago de aislamiento de recursos. Al contrario que los dominios de errores, las celdas carecen de cardinalidad evidente. (Como ya se ha mencionado, lo idóneo es que la cardinalidad de los dominios de errores sea de tres por cada dominio de disponibilidad. Así, los sistemas de replicación basados en cuórum se pueden alojar con altos niveles de 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 detallará más adelante), la unidad natural sería "todos los flujos de trabajo en este dominio de disponibilidad o región para un plano de control específico".
  • Enfrente de cada grupo de celdas habrá una capa de enrutamiento minimalista o una API para detectar puntos finales de celda. Por ejemplo, la API del sistema de transmisión y envío de mensajes permite detectar el punto final del plano de datos actual de un tema concreto, y el almacén interno de metadatos cuenta con un punto final independiente para cada celda. Esto no quiere decir, sin embargo, que otros servicios basados en celdas no tengan un único punto final para el plano de datos ni que no compartan capa de enrutamiento. La capa de enrutamiento es una causa posible detrás del fallo correlacionado de varias celdas, aunque se puede mitigar. Para ello, conviene que la capa de enrutamiento sea lo más previsible y sencilla posible y que tenga un gran rendimiento (sin operaciones de alto costo). Asimismo, se debe aprovisionar con margen de maniobra de gran capacidad, cuota de QoS sofisticada y mecanismos de limitación.
  • Los propietarios del servicio pueden trasladar cargas de trabajo entre celdas, en función de sus necesidades. A continuación, se presentan algunos escenarios de ejemplo:
    • Para evitar incidencias producidas por "vecinos molestos" multi-inquilino, se puede trasladar una carga de trabajo de gran volumen, con lo que el resto de los usuarios de la celda no se verán afectados.
    • Para favorecer la recuperación tras una sobrecarga o un bloqueo parcial, que puede haber sido provocado por un ataque distribuido de denegación de servicio. Contamos tanto con una cuota como con mecanismos de limitación para defendernos de este tipo de ataques. En ocasiones marginales, cierto caso de uso concreto (API, patrón de acceso) provoca un mayor agotamiento del sistema que el que se puede contrarrestar con sistemas de cuota o limitación. 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 se produzcan fallos correlacionados. Por ejemplo, en lo que respecta a nuestros flujos de trabajo compartidos internos para planos de control, los que entran en la categoría "base esencial" (como plataforma, recursos informáticos, redes y volúmenes en bloque) se asignan a celdas diferentes, con lo que el riesgo de que se produzca un fallo correlacionado es mucho menor que si no se utilizaran dichas celdas o se asignaran a la misma.
      Nota: Cuando las celdas se utilizan de este modo, no es necesario que los clientes presten tanta atención a las dependencias internas de los servicios para desarrollar aplicaciones resilientes. Si bien se recomienda consultar el gráfico de dependencias (encontrará más información al respecto en secciones posteriores de la documentación), no es tan necesario si se ha activado el mecanismo de anulación de correlación.

En consecuencia, todas las celdas de servicio pasan a ser una agrupación lógica de aislamiento de errores y de rendimiento, es decir, otro tipo de "centro de datos lógicos" dentro de un solo dominio de disponibilidad o una 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 realizar despliegues y aplicar parches.

Procedimientos de ingeniería de servicio

Contamos con un amplio espectro de procedimientos de ingeniería, debido a la fiabilidad de los sistemas en la nube que depende de dos pilares fundamentales: las pruebas y la excelencia operativa. A continuación, se enumeran los de mayor importancia, que hacen uso de los conceptos mencionados en la sección anterior:

  • Los servicios de despliegan de forma incremental. Por una parte, entre paso y paso se lleva a cabo una validación exhaustiva y, por otra, en caso de que ocurra algún imprevisto, se realiza un rollback reflexivo. Si entramos en detalles, el proceso es el siguiente:
    • En cada dominio de disponibilidad se realiza un despliegue por celdas de servicio, de una en una. A su vez, en cada una de ellas se despliega en un dominio de errores individual. Este proceso continúa hasta que se no quedan dominios de errores para la celda en cuestión. A continuación, se avanza hasta la siguiente celda en dicho 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 realiza un rollback reflexivo del cambio. Cuando se realiza un rollback, la prioridad reside en la preparación y las pruebas correspondientes, también las automáticas; lo que engloba los cambios que puedan afectar a los esquemas o estados persistentes.
    • Así pues, los cambios se despliegan en cada región en todos los dominios de disponibilidad, uno a uno. Los despliegues se ponen en marcha en todas las regiones de un dominio de tal forma que, si un cliente dedica un par determinado de regiones para sitios de recuperación principal o ante desastres, no se modifiquen al mismo tiempo.
  • Verificamos con regularidad que los mecanismos de manejo de errores y otras herramientas de mitigación funcionan de la manera prevista y no empeoran el problema en su nivel respectivo. Si se prescinde de estas pruebas, es habitual que los mecanismos de manejo de errores (como reintentos, algoritmos de recuperación tras bloqueos y algoritmos de nueva configuración de máquinas de estados) contengan bugs, tengan un precio prohibitivo o interactúen de formas imprevistas. Como resultado, pueden provocar graves problemas que afectan al rendimiento, como la hiperpaginación distribuida.
  • Tal como se ha indicado anteriormente, verificamos nuestra capacidad para realizar un rollback de forma rápida y segura, mediante el que se regresa a la última versión correcta del software y de la configuración, lo que incluye tanto el estado como el esquema persistentes.
 
 

En las regiones de Oracle que constan de varios dominios de disponibilidad, ¿los servicios esenciales se distribuyen entre los dominios de disponibilidad?

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ógicos?

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. Asimismo, los clientes pueden poner varias regiones al servicio de 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 (almacenamiento de objetos, transmisión) para alcanzar altos niveles de disponibilidad total en todos los "centros de datos lógicos" de niveles superiores (dominios de disponibilidad). Por último, los clientes pueden dedicar varias regiones a la recuperación ante desastres.

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

 
 

¿Cómo es posible que los servicios esenciales sigan disponibles para los clientes cuando Oracle lleva a cabo sus actividades de mantenimiento?

Las interrupciones temporales se evitan mediante el uso de dominios de errores, celdas de servicio y procedimientos operativos para despliegues y validación incrementales. Consulte los párrafos correspondientes en secciones previas de la documentación.

 
 

Para que los servicios de plataforma sin servidor dispongan de niveles más altos de disponibilidad, ¿se despliegan en varios centros de datos lógicos?

Sí. Con independencia de su clase, todos los servicios se despliegan en varios centros de datos lógicos, que son agrupaciones lógicas independientes de aislamiento de errores y de rendimiento. De este modo, se ofrece 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 englobe varios dominios de disponibilidad.

Tal como se ha indicado en otras secciones de la presente documentación, cuando se trata de regiones de dominios de disponibilidad única, los dominios de errores se ofrecen como un mecanismo que reemplaza a "varios centros de datos lógicos".

En cuanto a las regiones con varios dominios de disponibilidad, los servicios y funciones que se ofrecen proporcionan un nivel aún mayor de durabilidad física de los datos replicados de forma síncrona (si el rendimiento no es demasiado alto, el costo se explica según la distancia entre dominios de disponibilidad en la región y la velocidad de la luz).

No ofrecemos alta disponibilidad de forma automática ni mecanismos de failover entre regiones. Esto se debe a que podría crearse una relación de acoplamiento cerrado entre las mismas, lo que acarrearía el riesgo de que varias regiones presentaran problemas de forma simultánea. Sin embargo, sí ofrecemos toda una gama de formas de replicación asíncrona entre regiones, así como una lista de características en expansión, como copia y copia de seguridad asíncronas, lo que permite la recuperación ante desastres entre regiones.

 
 

¿De qué manera facilita Oracle que los clientes eviten 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 (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 conllevan cierto grado de fallo correlacionado? En tal caso, el cliente debería tener constancia de dichas dependencias internas. De ese modo, al desarrollar sus propios mecanismos de resiliencia en el nivel de la aplicación, podría utilizar los servicios A y B para otros fines o, incluso, podría recurrir al servicio independiente C, en los casos indicados.
  • ¿Cuál es la mejor defensa al alcance del cliente en caso de que se produzca un fallo correlacionado de los servicios de Oracle?

Vamos a dividir la respuesta en dos partes.

Principios arquitectónicos

Utilizamos principios arquitectónicos que permiten reducir notablemente la frecuencia de fallos correlacionados entre servicios dependientes. En algunas ocasiones, esta técnica reduce la probabilidad de que se produzca un fallo correlacionado hasta tal punto que, en términos de cumplimiento de un acuerdo de nivel de servicio o SLA, pierde toda relevancia.

En concreto, utilizamos celdas de servicio, a las que se hace referencia en secciones previas de esta documentación. Las celdas resultan muy útiles para contrarrestar este problema porque, si el servicio interno A se ve afectado por un problema en una de sus dependencias, servicio B, casi con toda certeza el problema en dicho servicio quedará restringido a una sola celda. Además, es probable que ni otros servicios de nivel superior ni las aplicaciones del cliente que recurran al servicio B se vean afectadas. Puesto que se trata de un argumento de probabilidad que cambia en función del número de celdas, un parámetro interno oculto que sufre modificaciones (aumentos), no se puede proporcionar una garantía ni aportar una cuantificación. Por tanto, será necesario atenerse a los SLA independientes de los servicios A y B. Pese a ello, en la práctica este sistema reduce en gran medida la correlación de los fallos entre servicios.

Gran parte 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, emplean celdas de servicio para reducir la correlación de las interrupciones para los servicios ascendentes que las utilizan.

Dependencias

La orientación que se detalla a continuación es de alto nivel. Tanto la implantación como los detalles de los servicios de bajo nivel pueden cambiar y, de hecho, lo hacen. Con excepción de las dimensiones clave de recursos informáticos, almacenamiento, redes y autenticación o autorización, se enumeran las siguientes dependencias:

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

  1. Plano de datos de identidad o plataforma para autenticación o autorización
  2. Servicio de seguimiento de auditorías
  3. Servicios internos que ofrecen, entre otros, flujo de datos, almacenamiento de metadatos e inicio de sesión
  4. Equilibradores de carga de varios tipos

Ciertos planos de control cuentan con dependencias específicas de algunos servicios, como cabría esperar. Por ejemplo, al iniciar una instancia de máquina virtual o hardware dedicado, el plano de control de recursos informáticos depende de:

  • Almacenamiento de objetos (para recuperar la imagen del sistema operativo especificada)
  • Plano de control de volúmenes en bloque (para aprovisionar y asociar el volumen de inicio)
  • Plano de control de redes (para aprovisionar y asociar VNIC)

Como principio general en lo referente a los planos de datos de servicios básicos, cada plano de datos se diseña con la intención de incluir la cantidad mínima de dependencias. De este modo, se garantizan altos niveles de disponibilidad y se reducen tanto los tiempos de diagnóstico como de recuperación. Cuando se cumple este principio, se obtienen los siguientes resultados:

  • El plano de datos de redes es independiente.
  • El plano de datos de volúmenes en bloque es independiente.
  • Las instancias de máquina virtual y con hardware dedicado de los recursos informáticos dependen del plano de datos de volúmenes en bloque (para los volúmenes de inicio) y del plano de datos de redes.
  • El plano de datos de almacenamiento de objetos 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 almacenamiento de objetos no depende de volúmenes en bloque ni de almacenamiento de archivos.
  • Todos los servicios compatibles con las funciones de copia de seguridad y restauración dependen de plano de datos de almacenamiento de objetos para utilizar dicha función.

Como principio general en cuanto a los planos de datos IaaS, solo se depende de los planos de datos de bajo nivel o que sean básicos. De este modo, se previenen las dependencias cíclicas.

  • La base de datos RAC de varios nodos depende de los planos de datos de redes y de volúmenes en bloque.
  • Como no puede ser de otro modo, Container Engine for Kubernetes depende de Kubernetes y de sus dependencias transitivas (como etcd) y del plano de datos de redes.
  • La compatibilidad con las funciones de copia de seguridad y restauración dependen por completo del plano de datos de almacenamiento de objetos.

1Programa de investigación pública surgido en las universidades de Stanford y Berkeley, encabezado por Armando Fox y Dave Patterson

 
×
Llámenos ahora
1-800-633-0738 (Estados Unidos)

Contacto
×
Llámenos ahora
1-800-633-0738 (Estados Unidos)


Foros de discusión de Oracle Cloud