Despliegue de una base de datos de hardware dedicado de alta disponibilidad
Oracle Data Guard garantiza una alta disponibilidad, protección de datos y recuperación ante desastres para los datos empresariales. Con Data Guard, el failover de la base de datos primaria en la base de datos en espera se puede realizar manualmente mediante la interfaz de línea de comandos de Data Guard Broker (CLI DGMGRL) o Oracle Enterprise Manager o configurando automáticamente un nodo Compute para que actúe como observador de failover de inicio rápido (FSFO). El observador puede iniciar automáticamente el failover y volver a instanciar automáticamente una base de datos primaria fallida como base de datos en espera. Tener observadores FSFO en el despliegue elimina la necesidad de intervención manual cuando es necesario realizar un failover de base de datos.
Arquitectura
Esta arquitectura de referencia muestra cómo desplegar dos sistemas de base de datos con hardware dedicado y los componentes de infraestructura necesarios para configurar FSFO para una base de datos Oracle 12c Versión 2 (12.2) desplegada en Oracle Cloud Infrastructure en dos regiones.
Esta arquitectura de base de datos en la nube se puede utilizar como nivel de base de datos resistente para muchas aplicaciones, incluidas Oracle E-Business Suite, JD Edwards y PeopleSoft.
El siguiente diagrama ilustra esta arquitectura de referencia.
Descripción de la ilustración ha-db.png
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y grandes distancias pueden separarlas (entre países o incluso continentes).
- Dominio de disponibilidad
Los dominios de disponibilidad son centros de datos independientes e independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía o refrigeración, o la red de dominio de disponibilidad interna. Por lo tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de disponibilidad de la región.
Los dominios de disponibilidad no se muestran en el diagrama de arquitectura.
- Dominios de Fallos
Un dominio de fallo es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad tiene tres dominios de fallos con energía y hardware independientes. Cuando distribuye recursos en varios dominios de fallos, las aplicaciones pueden tolerar fallos físicos del servidor, mantenimiento del sistema y fallos de energía dentro de un dominio de fallos.
Los dominios de fallos no se muestran en el diagrama de arquitectura.
- Red virtual en la nube (VCN) y subredes
VCN es una red personalizable definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes tradicionales de centros de datos, las VCN le proporcionan un control completo sobre su entorno de red. VCN puede tener varios bloques CIDR no superpuestos que puede cambiar después de crear VCN. Puede segmentar VCN en subredes, que se pueden asignar a una región o a un dominio de disponibilidad. Cada subred consta de un rango contiguo de direcciones que no se superponen con las otras subredes de VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- Listas de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, destino y tipo de tráfico que se debe permitir dentro y fuera de la subred.
- Observadores
Los observadores son nodos de cálculo que tienen instalado y configurado el software de Oracle Database necesario para iniciar FSFO de Oracle Database que se ejecuta en el sistema de base de datos con hardware dedicado. Una mejor práctica de FSFO es ejecutar el proceso de observación en un host que se encuentra en un centro de datos diferente de la base de datos primaria o en espera. Para cumplir con esa mejor práctica, esta arquitectura de referencia despliega tres nodos de observador. Se necesita la versión 12.2 o superior de Oracle Database para esta configuración.
- Sistemas de base de datos primaria y en espera
Estos sistemas de base de datos con hardware dedicado tienen una base de datos Oracle 12c versión 2 (12.2) configurada para la replicación de Data Guard.
Recomendaciones
Sus requisitos pueden diferir de la arquitectura descrita aquí. Utilice las siguientes recomendaciones como punto de partida.
- Formas del sistema de base de datos
Esta arquitectura de referencia utiliza la forma de hardware dedicado de BM.Standard2.52 para los sistemas de base de datos. Esta forma tiene 51.2 TB de SSD NVMe conectados localmente con baja latencia. Seleccionamos la forma de hardware dedicado porque nos permite crear varios directorios raíz y bases de datos.
- Formas informáticas
Esta arquitectura de referencia utiliza una forma de máquina virtual (VM) principal de VM.Standard2.1 para los nodos observadores. El nodo observador es un cliente Oracle Call Interface de baja huella integrado en la CLI de DGMGRL. Una forma de VM de un núcleo es suficiente para esta arquitectura.
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que tiene previsto asociar a subredes en VCN. Utilice bloques CIDR que estén dentro del espacio de direcciones IP privadas estándar.
Seleccione bloques CIDR que no se superpongan con ninguna otra red (en Oracle Cloud Infrastructure, el centro de datos local u otro proveedor de nube) a la que desee configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Cuando diseñe las subredes, tenga en cuenta sus requisitos de flujo de tráfico y seguridad. Conecte todos los recursos dentro de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
Utilice subredes regionales.
- Listas de seguridad
Utilice listas de seguridad para definir reglas de entrada y salida que se aplican a toda la subred. Por ejemplo, esta arquitectura de referencia permite ICMP internamente para toda la subred privada.
- Cloud Guard
Clonar y personalizar las recetas por defecto proporcionadas por Oracle para crear recetas personalizadas de detectores y respuestas. Estas recetas permiten especificar qué tipo de violaciones de seguridad generan una advertencia y qué acciones se pueden realizar en ellas. Por ejemplo, puede que desee detectar cubos de almacenamiento de objetos que tengan visibilidad definida en público.
Aplique Cloud Guard en el nivel de arrendamiento para cubrir el ámbito más amplio y reducir la carga administrativa de mantener varias configuraciones.
También puede utilizar la función Lista gestionada para aplicar determinadas configuraciones a los detectores.
- Zonas de seguridad
Para los recursos que requieren la máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta definida por Oracle de políticas de seguridad que se basan en las mejores prácticas. Por ejemplo, los recursos de una zona de seguridad no deben ser accesibles desde Internet público y deben cifrarse mediante claves gestionadas por el cliente. Al crear y actualizar recursos en una zona de seguridad, Oracle Cloud Infrastructure valida las operaciones con las políticas de la receta de zona de seguridad y niega las operaciones que violan cualquiera de las políticas.
Consideraciones
Tenga en cuenta estos puntos al desplegar esta arquitectura de referencia.
- Rendimiento
Para obtener el mejor rendimiento para las cargas de trabajo de la aplicación, asegúrese de que el sistema de base de datos de hardware dedicado principal tenga suficientes núcleos para soportar la aplicación y la configuración de Data Guard.
- Disponibilidad
Los nodos de observador se despliegan en varias regiones de disponibilidad para asegurarse de que FSFO puede ocurrir automáticamente incluso si uno de los nodos de observador está fuera de línea. Una vez que se produce un failover, la base de datos en espera se convierte en la base de datos primaria.
- Costo
Tamaño de las CPU en los sistemas de base de datos de hardware dedicado en función de sus necesidades. Puede empezar por dos o más núcleos y escalar hasta 52 núcleos en una forma BM.DenseIO2.52. También puede escalar los núcleos dinámicamente sin tiempo de inactividad.