Uno de los grandes problemas a la hora de implementar soluciones activo‐activo se encuentra en la capa de base de datos, ya que la pérdida de la cabina de discos supone la caída total delservicio.

Ademas  en algunos casos se superan los 15 minutos de tiempo máximo de parada  por lo que es importante estudiar  que soluciones pueden permitir la estabilidad de una BBDD Oracle en el menor tiempo posible

En principio  existe para  ello   tres soluciones:

• Réplica síncrona basada en cabina(disk array mirroring). Se trata de una solción sencilla de implementar y que no requiere licencias adicionales al mantener  la base de datos de respaldo inactiva. Por el contrario, supone una infrautilización de recursos y un tiempo deparada medio‐alto en caso de contingencia. Además, si la contingencia es brusca, sólo se conservarán aquellos datos que estén consolidados en disco y podrían perderse transacciones.

 

•  Oracle Datagard. Este producto de Oracle requiere tener una infraestructura de base de datos paralela a la de producción,si bien puede ser inferior en recursos.En este caso,cada transacción de la BBDD se va replicando automáticamente mediante el software de Oracle en la base de datos de datagard.En caso de contingencia,esta segunda BBDD podría actuar como base de datosprincipal,si bien requiere al igual que en el caso anterior una serie de procedimientos
 manuales para su puesta en producción.La ventaja frente a la anterior es que,al ser el mismo software de Oracle el que gestiona la réplica, la pérdida de datos no consolidados en caso de contingencia se ve muy disminuida. En contra, sí  requiere licencia adicional y supone, como en el caso anterior, una infrautilización de recursos, si bien es cierto que las últimas versiones de Datagard permiten tener la
 base de datos de respaldo levantada en modo de solo lectura.

 

• RAC extendido con tecnología Oracle RAC   11g.  En este sistema  cada uno de los nodos tiene visibilidad de los dispositivos de almacenamiento que le presentan las dos cabinas. Para evitar el punto de fallo,los nodos tiene tarjetas de fibra redundadas y en ambas cabinas por dos caminos diferentes.

Existe una capa de software,Oracle ASM (Automatic Storage Management),que gestiona el almacenamiento de forma que todos nodos vean los discos que les presentan las cabinas como un único pool de almacenamiento. Los nodos se comunican entre sí mediante una red privada (red de interconnect) a Giga. A través de esta red intercambian información de lo que esta  haciendo cada nodo y realizan una fusión de caches (todos los nodos comparten la caché), que es lo que permite que la ca¡da de uno de ellos sea transparente para la sesión del usuario. Todas la interfaces de red, tanto las del interconnect como las de la red de servicio deben estar redundadas (mediante bonding en Linux, IPMP en Solaris,etc.)para evitar que constituyan un punto de fallo.

Otra capa de software por debajo de ASM, Oracle Clusterware, gestiona todos los recursos del cluster, mantiene al nodo dentro del grupo y proporciona a ASM los recursos necesarios para su funcionamiento.

Toda la información de estado del cluster se ubica en un dispositivo denominado voting disk.Para evitar que este constituya un punto de fallo, Oracle recomienda mantener tres voting disk, uno en cada cabina y un tercero en un servidor ubicado en otro CPD al que accedan los nodos mediante NFS.

Este tipo de cluster extendido muy usado en la actualidad , presenta las siguientes hitos:

• En una configuración activo-activo pura hay aprovechamiento de todos los recursos disponibles.
• Es completamente tolerante a fallos gracias a la redundancia de todos sus elementos.
• Alta disponibilidad total: 24 x 7 garantizado.
• Fácilmente escalable con posibilidad de a¤adir nuevos nodos en caliente.

 

Desde el punto de vista del desarrollador  en una BBDD en RAC activo -activo   necesitaremos  tener en el  tnsanames.ora dos entradas ( o tantas como instancias como haya)  en el que  se alternaran en cada entradas tantos campos  ADDRESS como instancias también haya   ( cada  una con ip’s y  puertos diferentes  )  y ADEMAS  alternos en cada  entrada  pero compartiendo el mismo SERVICE_NAME(SSID)

Por ejemplo    si tenemos dos instancias  , tendríamos en el tnsanames.ora las dos siguientes entradas

INSTANCIA1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)(HOST=maquina1)(PORT=50150))
(ADDRESS=(PROTOCOL=TCP)(HOST=maquina2)(PORT=50046))
)
(CONNECT_DATA =
(SERVICE_NAME = SSID)
(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC))
)
)

INSTANCIA2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)(HOST=maquina2)(PORT=50046))
(ADDRESS=(PROTOCOL=TCP)(HOST=maquina1)(PORT=50150))
)
(CONNECT_DATA =
(SERVICE_NAME = SSID)
(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC))
)
)

 

 

 

SOLUCION STANDALONE

Frente   a la soluciones activo-activo comentadas   Oracle también propone una solución standalone  llamada Oracle Grid Infrastructure para un servidor independiente  también conocido como Oracle Restart, proporcionado soporte del sistema para una base de datos Oracle de instancia única.  Este sistema  incluye administración de volumen, sistema de archivos y capacidades de reinicio automático.

Oracle Restart mejora la disponibilidad de una BBDD Oracle al proporcionar lo siguiente:

• Cuando hay una fallo de hardware o software, Oracle Restart inicia automáticamente todos los componentes de Oracle, incluida la instancia de la base de datos de Oracle, el servicio de escucha de Net de Oracle, los servicios de base de datos y el ASM de Oracle.
• Oracle Restart inicia los componentes en el orden correcto cuando se reinicia el host de la base de datos.
• Oracle Restart ejecuta verificaciones periódicas para monitorear el estado de los componentes de Oracle. Si una operación de verificación falla para un componente, entonces el componente se apaga y se reinicia.

En caso de  que se necesite  usar Oracle Automatic Storage Management (Oracle ASM), se  debera instalar tambien  Oracle Restart antes de instalar la BBDD.

Oracle combinó dos productos de infraestructura (Oracle Grid Infrastructure para un servidor independiente que  incluye Oracle Restart y Oracle Automatic Storage Management.) en un único conjunto de binarios que se instalan desde la  página de inicio de Oracle Restart.

Respecto a Oracle Automatic Storage Management es un administrador de volúmenes y un sistema de archivos para archivos de base de datos Oracle que admite configuraciones de Oracle Database y Oracle Real Application Clusters (Oracle RAC) de instancia única.  También admite un sistema de archivos de propósito general para las necesidades de su aplicación, incluidos los binarios de Oracle Database.

En resumen Oracle Automatic Storage Management es la solución de administración de almacenamiento recomendada de Oracle que ofrece una alternativa a los administradores de volumen convencionales, sistemas de archivos y dispositivos sin formato.

Presenta incompatibilidades

• No puede instalar Oracle Restart en un nodo miembro de clúster de Oracle Grid Infrastructure, ni agregar un servidor de Oracle Restart a un nodo miembro de clúster de Oracle Grid Infrastructure.
• Oracle Restart admite bases de datos de instancia única en un servidor, mientras que Oracle Grid Infrastructure para un clúster admite bases de datos de instancia única o Oracle RAC en un clúster.
• Si desea usar Oracle ASM o Oracle Restart, debe instalar Oracle Grid Infrastructure para un servidor independiente antes de instalar y crear la base de datos. De lo contrario, debe registrar manualmente la base de datos con Oracle Restart. Oracle Restart se utiliza en entornos de instancia única (no agrupados).

 

Desde el punto de vista del desarrollador  en una BBDD en RAC stanalone   necesitaremos  tener en el  tnsanames.ora una única entrada   pues toda la gestion se abastrae  tanto a lso servidores de aplicaciones como al propio desarrolalador