Consiguiendo Alta Disponibilidad Y Contingencia 4x2k2q

Consiguiendo Alta Disponibilidad y Contingencia con Oracle® | MUGPERU Blog

Página 1 de 2

Consiguiendo Alta Disponibilidad y Contingencia con Oracle® Escrito en 11/02/2013 por Francisco Riccio

11 Recommend

Actualmente las empresas requieren el a sus bases de datos en todo momento, además de necesitarlas acceder lo más rápido posible. Como es de Base de Datos & Aplicaciones siempre ha sido un desafío poder cumplir con este requerimiento de las empresas cuyo rubro no permite nunca detener el sistema productivo. Frente a este problema, tenemos varias soluciones tales como tener instalado un cluster y un ambiente de contingencia. El objetivo de este artículo es comentar las bondades de tener un cluster y un ambiente de contingencia en nuestra empresa y asimismo entregar un panorama general de los mismos. Primero debemos definir ¿Qué es un cluster?, y en términos sencillos significa agrupar 2 o más servidores unidos mediante una red de alta velocidad, de tal modo que esta agrupación forma un gran servidor potente ubicado en un centro de cómputo. Al estar varios servidores en cluster, nos entrega muchos beneficios que se pueden resumir para nuestro final en un más rápido de la información (porque cada servidor balanceará la carga de trabajo), además de permitirle una mayor posibilidad de siempre tener un a la información (porque si falla un servidor, otro servidor del conjunto puede atender el requerimiento) y permitirle tener soluciones escalables (podemos aumentar más servidores al cluster para soportar más s y mantener la performance). Existen muchos proveedores que ofrecen varias tecnologías para implementar un cluster, por ejemplo: Microsoft, Oracle, IBM, Red Hat, etc. Todas las tecnologías se basan en el siguiente esquema: Un conjunto de servidores que comparten un storage externo común, con la finalidad de que si un servidor se malogra, los demás servidores puedan seguir accediendo a la información ya que la información se ubica en un storage externo y compartido para todos los servidores. Para el storage externo tenemos también diferentes soluciones, precios y beneficios, por ejemplo IBM ofrece sus Storage DS en la serie 8000 como última generación, HP ofrece su Storage XP1000 y así otros fabricantes. Los storage modernos tienen como características que su conexión hacia los servidores es por fibra y la velocidad de transmisión es de 4 Gigabits por segundo, mantienen un caché con la finalidad de colocar ahí la información y luego escribirlo en los discos, soportan varios discos, el storage cuenta con procesadores para su procesamiento y en algunos casos estos procesadores se encuentran en un ambiente alta disponibilidad por hardware como el DS 8300 de IBM. Volviendo al escenario de la implementación de un cluster, este storage externo se presenta a cada servidor como discos duros, donde por ejemplo, el servidor 1 ve el disco duro con serial A, ese mismo disco duro con serial A es también visto por el servidor 2. Hasta este paso tenemos un storage externo y común para los servidores, pero deben ser formateados y particionados los discos (en el caso de Windows/Linux con fdisk). Una vez particionados los discos el gran problema que se presenta para implementar nuestro cluster es el formato que tendrán las particiones de los discos. Aquí existen varias respuestas: Si estamos en Windows podemos formatear los discos con un sistema de archivos FAT32, NTFS; o si estamos en Linux podemos hacerlo con EXT3 etc. Pero ninguno de estos sistema de archivos permiten que 2 o más servidores puedan escribir y leer al mismo tiempo sobre el mismo disco duro externo, por lo tanto necesitamos un sistema de archivos que permita esto, de tal modo que los servidores del cluster puedan escribir y leer lo que ingresa cada servidor en tiempo real. Algunos de estos son GPFS y JFS2 los cuales corresponden al sistema operativo UNIX AIX de IBM. Así mismo HP presenta también sus soluciones para UNIX HP-UX. En Linux y Windows contamos felizmente con una solución gratuita de ORACLE llamada OCFS (Oracle Cluster Filesystem).

http://blog.mugperu.com/index.php/2013/02/consiguiendo-alta-disponibilidad-y-conti... 03/11/2015

Consiguiendo Alta Disponibilidad y Contingencia con Oracle® | MUGPERU Blog

Página 2 de 2

Entonces hasta el momento, hemos aprendido que para armar un ambiente cluster necesitaríamos: 1. Una conexión de red súper rápida para que los servidores puedan coordinar. 2. Un storage externo y compartido para los servidores del cluster. 3. El sistema de archivos (con el que se les formateará a los discos del storage compartido) debe permitir la I/O a todos los servidores del cluster en tiempo real. 4. Un software de cluster que haga el balanceo de carga, la alta disponibilidad y permita la istración del cluster. Continuará ….

http://blog.mugperu.com/index.php/2013/02/consiguiendo-alta-disponibilidad-y-conti... 03/11/2015

Consiguiendo Alta Disponibilidad y Contingencia con Oracle® (parte 2) | MUGPE...

Página 1 de 3

Consiguiendo Alta Disponibilidad y Contingencia con Oracle® (parte 2) Escrito en 16/02/2013 por Francisco Riccio

6 Recommend

Continuando con la temática de un artículo anterior Entonces hasta el momento, hemos aprendido que para armar un ambiente cluster necesitaríamos: 1. Una conexión de red súper rápida para que los servidores puedan coordinar. 2. Un storage externo y compartido para los servidores del cluster. 3. El sistema de archivos (con el que se les formateará a los discos del storage compartido) debe permitir la I/O a todos los servidores del cluster en tiempo real. 4. Un software de cluster que haga el balanceo de carga, la alta disponibilidad y permita la istración del cluster. El punto 1 y 2 son temas de hardware. Para el punto 3 tenemos una solución gratuita de Oracle llamada OCFS. Sobre el punto 4, Oracle también ofrece una solución gratuita llamada el Oracle Clusterware, su última versión es la 11g. El Oracle Clusterware está disponible en diferentes plataformas. La idea ahora como es de Base de Datos & Aplicaciones es implementar el esquema mostrado en la figura 1. Figura 1

Podemos apreciar por la figura 1, que nuestra base de datos estará ubicada en el storage compartido (con un sistema de archivo que soporte un ambiente cluster) y el software de cluster hará el trabajo ya mencionado anteriormente. La gran ventaja que nos ofrece Oracle con el clusterware si lo utilizamos sobre base de datos Oracle sobre otro software de cluster de otros proveedores, es que el Oracle Clusterware realiza un balanceo de carga a nivel de carga de procesamiento a nivel de Base de Datos y no a nivel de carga de U como hace el resto. Además tiene una característica llamada Transparent Application Failover (TAF), el cual nos da la bondad de que si estamos nosotros realizando un reporte en un servidor determinado y si el servidor presenta un problema de hardware y cae, Oracle Clusterware será el responsable de llevar nuestra sesión del servidor caído hacia otro servidor que este operativo y continuar con el reporte sin comenzar de cero y para el final será transparente porque tendrá su reporte sin conseguir un mensaje de error. El clusterware tiene otras virtudes, por ejemplo: el mismo puede levantar automáticamente un servicio cierta cantidad de veces en caso el servicio este caído, además permite trabajar en diferentes modos como activo/activo, activo/pasivo, etc. Desde la versión 10g, Oracle nos ofrece un nuevo sistema de archivos llamado ASM (Automatic Storage Management), que también nos permite el I/O sobre los discos a tiempo real entre todos los servidores que conforman el cluster, además de ofrecer la característica de stripping (significa que cada disco duro balanceará la carga de trabajo porque su información estará distribuida uniformemente entre todos los discos duros).

http://blog.mugperu.com/index.php/2013/02/consiguiendo-alta-disponibilidad-y-conti... 03/11/2015

Consiguiendo Alta Disponibilidad y Contingencia con Oracle® (parte 2) | MUGPE...

Página 2 de 3

Este sistema de archivo solo permite almacenar archivos de base de datos tales como datafiles, redo logs, archivers, etc. Mientras OCFS permite almacenar cualquier tipo de archivo. Tengamos presente que si nosotros tenemos un disco duro con un sistema de archivo OCFS ó ASM, Oracle será el responsable de leer y grabar en crudo el disco. De este modo hace un by al sistema operativo, teniendo un 30% de mejora de performance sobre sistema de archivos convencionales tales como NTFS. Por experiencia personal, lo recomendable sería que los archivos de configuración y uso del Oracle Clusterware tales como el OCR y el Voting, deberían alojarse en un sistema de archivo OCFS y nuestra base de datos en ASM. Nuestra base de datos corriendo con el software de cluster de Oracle es la solución llamada: Oracle RAC (Oracle Real Application Cluster) y tiene un costo adicional. Hasta este momento tenemos la noción general de cómo se compone nuestro cluster y qué soluciones nos ofrece Oracle para implementarlo. Frente a esta solución, se han preguntado ¿Qué sucedería si tenemos una solución Oracle RAC o cualquier otra solución de cluster de otro fabricante en nuestro centro de cómputo; y ocurre un accidente tal como un incendio, terremoto, un atentado terrorista como la del 11 de setiembre o simplemente nuestro storage externo murió? Frente a esto, nuestro cluster dejaría de funcionar y nuestro storage externo también. En estos escenarios donde los procesos de negocio deben continuar, es donde se piensa en implementar un ambiente de contingencia, con la finalidad si algo sucede con todos nuestros servidores de producción exista un servidor extra que pueda funcionar para seguir brindando la información a la empresa y la disponibilidad del negocio continúe. Nuestro ambiente de contingencia debe estar ubicado en otro lugar físico de la empresa y no menos de 10 Km. de distancia de nuestro centro de cómputo. Oracle nos ofrece una solución llamada Oracle Dataguard, la cual nos permite tener una base de datos en estado pasivo que estará recepcionando las transacciones del ambiente productivo, en caso de un desastre, esta base de datos se convertirá en servidor productivo y atenderá las peticiones de los s porque siempre estuvo sincronizando la base de datos con el ambiente productivo. Oracle indica que si tenemos una solución Oracle RAC con Oracle Dataguard, tendremos una disponibilidad de la información al 99.99999% durante los 365 días del año. “Conocido como los cinco nueves”. Además como buena práctica, Oracle recomienda tener este ambiente de contingencia en cluster. Por lo tanto, en nuestro centro de cómputo tendríamos un Oracle RAC enlazado a un Oracle Dataguard que se conforma por otro Oracle RAC en estado pasivo. El esquema quedaría de este modo: Figura 2

Si optamos por una solución con Oracle Dataguard, yo recomiendo por experiencia que la comunicación de nuestro centro de cómputo hacia el ambiente de contingencia debe realizarse por medio de fibra oscura, para no presentar problemas de performance más adelante. Hoy en día Oracle nos ofrece mecanismos para que nuestros s siempre puedan obtener la información que necesiten de modo eficiente. Como DBAs debemos considerar el uso de algunas de estas tecnologías presentadas tales como OCFS, ASM, Oracle RAC y Oracle Dataguard para conseguir el desafío presentado al inicio del artículo. Existe mucha documentación sobre todas estas tecnologías, pero me gustaría compartir el link de la página principal de OCFS, donde podemos encontrar las librerías que necesitaríamos si deseáramos implementarlo lo más antes posible.

http://blog.mugperu.com/index.php/2013/02/consiguiendo-alta-disponibilidad-y-conti... 03/11/2015

Consiguiendo Alta Disponibilidad y Contingencia con Oracle® (parte 2) | MUGPE...

Página 3 de 3

El url es: http://oss.oracle.com/projects/ocfs2

http://blog.mugperu.com/index.php/2013/02/consiguiendo-alta-disponibilidad-y-conti... 03/11/2015