clusters.ppt [modo de compatibilidad] - fi.upm.es · planes de continuidad de negocio ... oracle...

1

Una Solución de Alta Disponibilidad de Negocio para un Servicio de Base de Datos

FACULTAD DE INFORMÁTICAUNIVERSIDAD POLITÉCNICA DE MADRID

un Servicio de Base de Datos

Jesús Angulo Arribas

Agenda

IntroducciónSituación InicialRequisitos de la Propuesta

Una Solución de Alta Disponibilidad de Negocio para un Servicio de Base de Datos 24 de Junio de 2008

Planes de Continuidad de NegocioSolución PropuestaResultadosConclusiones y Líneas Futuras de Trabajo

Introducción

El objetivo del proyecto es el diseño de una arquitectura de alta disponibilidad para el entorno de bases de datos. Dentro de un Plan de Continuidad de Negocio


gglobal de los servicios críticos de la organización, consolidados en una arquitectura de tres niveles: Web, Servidor de Aplicaciones y Bases de Datos

Agenda




2

Arquitectura Inicial


Situación Inicial (I)Un Cluster de 2 nodos en el CPD Principal, con 117 instancias de Oracle 8i y 9iSolución de disponibilidad:

Un Cluster Oracle HA (failover). Fallo de un nodo implica la Indisponibilidad del 50% del servicio


Recuperación automática en minutosLos clientes Oracle necesitan reconexión

Recuperación ante Desastres:Replicación asíncrona en CPD Secundario (a 17 Km.)Recuperación manual en 4 horas del 100% de BBDD Necesidad de recursos de reserva

Situación Inicial (II)Se dispone de recursos COD (Capacidad Bajo Demanda) de CPU y Memoria para asumir la carga de trabajo en modo degradado:

Fallo de un nodo del clusterDesastre en CPD Principal


Rendimiento del Cluster en modo degradadoAnte fallo de un nodo: se asume el 75% de la carga de trabajo

Rendimiento en caso de desastreEl servidor de reserva asume el 50% de la carga de trabajo

Agenda




3

Requisitos de la Propuesta (I)Disponibilidad de la arquitectura propuesta: 99,99%Solución de continuidad de negocio:

Tiempo de recuperación inferior a 4 horasP i l t ti ibl l


Proporcionar el mayor automatismo posible a la solución

Funcionalidades de copia y réplica de datos:RAID por HardwareReplicación asíncrona basada en cabina de discos (True Copy)

Requisitos de la Propuesta (II)Escalabilidad de la capacidad de proceso:

Aumentar la capacidad de proceso en un 40%Que se permita crecimientos futuros sin cambio de SistemasSe valora aumentar la capacidad en COD


Flexibilidad y capacidad de gestión de la solución:

Mejorar el mantenimiento de la plataformaSoftware de base:

Sistema operativo Solaris 9Gestor de base de datos Oracle 9i

Agenda




Planes de Continuidad de NegocioFases de un PCN [BCI,05]:

1. Conocimiento de la organización

BIA: RTO y RPORA

2. Estrategia de Continuidad de Negocio

Estrategias de Continuidad de Negocio:

Potenciar la Disponibilidad de los componentesBackup y recuperación de cintaReplicación de Datos


de Negocio3. Implementación del PCN4. Desarrollo cultura de

Continuidad de Negocio5. Pruebas y mantenimiento

del PCN

Replicación de Datos Síncrona o AsíncronaCluster Extendido

Cluster Local Extendido <10KmMetro Cluster <80-100Km

Con mirroring Con replicación

Cluster Geográfico >100Km

4

Días MinsHorasSems Segs

Punto de Recuperación RPO Tiempo de Recuperación RTO

DíasMins Horas SemsSegs

ReplicaciónSpíncrona

Cluster Extendido

Planes de Continuidad de NegocioEstrategia Tecnológica según RPO y RTO


ReplicaciónPeriodica

Spíncrona

Restauracióndesde cinta

Migración ManualReplicación

Asíncrona

Backup en Cinta

RPO Inicial: MinutosRTO Inicial: 4 horas

Planes de Continuidad de NegocioEstrategia Tecnológica según RPO y RTO

Días MinsHorasSems Segs

Punto de Recuperación RPO Tiempo de Recuperación RTO

DíasMins Horas SemsSegs

ReplicaciónSpíncrona

Cluster Extendido


RPO Inicial: MinutosRTO Inicial: 4 horas

RPO Requerido: MinutosRTO Requerido: < 4 horas

ReplicaciónPeriodica

Spíncrona

Restauracióndesde cinta

Migración ManualReplicación

Asíncrona

Backup en Cinta

Componentes HW de un Cluster


Componentes de un Cluster


5





Distribución de Carga en un Cluster


Recuperación Cluster - Oracle HA1. Detección del fallo2. Reorganización de la pertenencia al cluster3. Transferencia de la propiedad de los discos

4. Reinicio de base de datos5. Recuperación de aplicación y base de datos6. Recuperación de clientes


6

Dispositivo de Quorum en Clusters


Dispositivo de Quorum en Clusters


Clusters Extendidos

Cluster Extendido Local <10KmMetro Cluster <50-80Km

Con mirroring C li ió


Con replicaciónCluster Geográfico o Global >100Km

Cluster Extendido LocalCluster Extendido Local (Campus Cluster)Nodos ExtendidosRedes Ethernet y FC Extendidas


Fibra MultimodoDistancia máxima: 500 metros

7

Cluster Extendido Local – SAN Ext.Cluster Extendido Local (Campus Cluster)Redes Ethernet y SAN ExtendidaPuertos Switch configurados en modo ISL ( Inter


(Switch Link)Fibra MultimodoDistancia máxima: 500 metros

Cluster Extendido Local – SAN Ext.Fibra Monomodo 10 km

Cluster Extendido Local (Campus Cluster)Redes Ethernet y SAN ExtendidaPuertos Switch configurados en modo ISL ( Inter


(Switch Link)Fibra MonomodoDistancia máxima: 10 km

Metro ClusterMetro Cluter (Campus Cluster)Redes Ethernete y SAN ExtendidaPuertos Switch configurados en modo ISL ( Inter Switch Link)


DWDM sobre Fibra Oscura (Monomodo)Distancia máxima DWDM: 200 kmDistancia máxima de un cluster: 50-80 km

Metro Cluster con ReplicaciónMetro Cluter Redes Ethernet ExtendidaNo se necesita SAN ExtendidaReplicación SíncronaReplicación:


pSW sobre IPHW sobre FC o IP

Distancia máxima de repclicación Sóncrona: 50-80 km

8

Cluster Geográfico o GlobalCluster GeográficoClusters independientesReplicación Asíncrona (Síncrona)Replicación:


pSW sobre IPHW sobre IP (FC)

Distancia máxima de repclicación Asíncrona: Ilimitada

Agenda




Arquitectura Propuesta Gestor de BBDD Oracle 9i RAC2 cluster de Oracle RAC ExtendidosSe añaden 2 servidores Sun Fire 25KSe aumenta la


Se aumenta la capacidad de proceso de Producción y CODSe extienden redes privadas y de producciónSe reutilizan los componentes de la infraestructura actual

Solución Propuesta (I)2 cluster de Oracle 9i RAC Extendidos Activo-Activo¿Por qué Oracle RAC?

Oracle RAC permite tener múltiples instancias contra una base de datos


En caso de fallo proporciona automatismo y transparencia (clientes OCI) en la recuperación de la BBDDRecuperación del servicio en menos de 1 minuto

¿Por qué Oracle RAC Extendido?Proporciona una solución de recuperación de desastres. El mismo servicio corriendo en 2 CPDs

9

Solución Propuesta (II)

¿Por qué 2 cluster de Oracle RAC de 2 nodos?

Un 25% de perdida de rendimiento con 4 nodos


Se mejora el mantenimiento de la plataformaImpactos en Rendimiento:

Paso de Oracle a Oracle RAC: 10%Paso de Oracle RAC a Oracle RAC Extendido: 10%

Arquitectura Cluster Oracle RAC


Recuperación de Oracle RAC1. Detección del fallo 2. Reorganización pertenencia al cluster3. Recuperación de base de datos


Modelo de DisponibilidadMTBF: Tiempo Medio Entre Fallos del servidor (Nodo)MTTR_1: Tiempo Medio de Reparación de un nodoMTTR_2: Tiempo Medio de Reparación de dos nodosRecovery_Time: Tiempo que lleva la reconfiguración completa


lleva la reconfiguración completa del clusterNode_Rejoin_Time: Tiempo para agregar un nodo al clusterp: Probabilidad de reconfiguración con éxito del clustera: Incremento en porcentaje de la tasa de fallo (MTBF) del nodo superviviente, debido al incremento de la carga de trabajo

36 minutos y 8 segundos


Tiempo Anual de Indisponibilidad

0,999930,99998Disponibilidad del Sistema

0,20,2a

0,980,99p

20 segundos20 segundosNode_Rejoin_Time

60 segundos60 segundosRecovery_Time

4 horas2 horasMTTR_2

1 hora1 horaMTTR_1

3000 horas4000 horasMTBF

SETPARAMETROS_2SETPARAMETROS_1Parámetro



Tiempo Anual de Indisponibilidad

0,999930,99998Disponibilidad del Sistema

0,20,2a

0,980,99p

20 segundos20 segundosNode_Rejoin_Time

60 segundos60 segundosRecovery_Time

4 horas2 horasMTTR_2

1 hora1 horaMTTR_1

3000 horas4000 horasMTBF


10

Modelo de Disponibilidad (II)Análisis Diferencial: decremento del 10% de todos los parámetrosOrden decreciente de importancia:

pMTBFMTTR_2, Recovery_TimeNode_Rejoin_TimeMTTR 1, a 377462p

-0,52-1,29Node_Rejoin_Time

-1.61-3.90Recovery_Time

-7,87-4,82MTTR_2

-0,14-0,13MTTR_1

11,2911,28MTBF


377462p

-0,52-1,29Node_Rejoin_Time

-1.61-3.90Recovery_Time

-7,87-4,82MTTR_2

-0,14-0,13MTTR_1

11,2911,28MTBF



_ ,-0,025-0,023a -0,025-0,023a

ReglasRegla 1: Si hay un fallo en un nodo, reducir al mínimo la probabilidad de que no tenga éxito la reconfiguración del clusterRegla 2: Reducir al mínimo los fallos en un nodoRegla 3: Si hay un fallo de reconfiguración (haciendo que todo el cluster se caiga) reducir al mínimo el tiempo necesario para que el cluster vuelva a su funcionamiento normalRegla 4: En caso de éxito en la reconfiguración del cluster, reducir al mínimo la duración de la reconfiguración

Recuperación ante DesastresComportamiento de la Arquitectura Propuesta

Recuperación de Desastres y Fallos Múltiples:50% automática50% manual en < 4 horas

Posibles casos de desastre o fallo múltiple contemplados:Fallo en una Cabina de discosFallo de las líneas de comunicaciones Desastre en un CPD


Desastre en un CPDSe plantea una distribución las BBDD alternativa para mejorar la disponibilidad en caso de desastre:

Ubicar todas las BBDD de un mismo cluster, en la misma cabina de discosConfigurar el Dispositivo de Quórum del cluster en la misma cabina de discos que las BBDDSe penaliza tiempo de respuesta del 100% de operaciones de un nodoDe media el 66-67% de las BBDD se recuperarían automáticamente

Recuperación ante Desastres (II)Posibles casos de desastre:

Fallo en una Cabina de discos:Recuperación: Automática 50% y Manual 50% < 4 horasAlternativa: Automática 50% y Manual 50% < 4 horas

Fallo de las líneas de comunicaciones (*):


Fallo de las líneas de comunicaciones ( ):Recuperación: Automática 50% y Manual 50% < 4 horasAlternativa: Automática 100%

Desastre en un CPD:Recuperación: Automática 25%, Manual 25% en 30 minutos y Manual 50% < 4 horasAlternativa: Automática 50% y Manual 50% < 4 horas

Fallo en líneas de comunicaciones

SF15K-1 SF15K-2RAC-1 N1 RAC-1 N2

A1 R. Privada A2B1 B2


C1 R. Privada C2D1 D2

9980V 1 DWDM 9980V 2


9980V-1 DWDM 9980V-2BD-A (25%) BD-B (25%)BD-C (25%) BD-D (25%)QD RAC-1 SAN Ext. QD RAC-2

R-B R-AR-D R-C

AAA

Fallo de ComponenteElemento AfectadoVoto de Quorum en RAC-1Voto de Quorum en RAC-2

Funcionamiento NormalFuncionamiento Correcto

11






9980V 1 DWDM 9980V 2





9980V 1 DWDM 9980V 2



R-B R-AR-D R-C

AAA




R-B R-BR-D R-D

Fallo Líneas de Comunicación entre CPDs






9980V 1 DWDM 9980V 2





9980V 1 DWDM 9980V 2





9980V 1 DWDM 9980V 2



R-B R-AR-D R-C

AAA




R-B R-BR-D R-D



R-B R-AR-D R-C

BBDD A: 25% AutomáticoBBDD B: 25% < 4 horasBBDD C: 25% < 4 horasBBDD D: 25% Automático

Recuperación Sevicios de BBDD

Fallo en líneas de comunicaciones. Con Arquitectura Alternativa





9980V 1 DWDM 9980V 2


9980V-1 DWDM 9980V-2BD-A (25%) BD-C (25%)BD-B (25%) BD-D (25%)QD RAC-1 SAN Ext. QD RAC-2

R-C R-AR-D R-B

AAA








9980V 1 DWDM 9980V 2





9980V 1 DWDM 9980V 2



R-C R-AR-D R-B

AAA




R-C R-AR-D R-B


12






9980V 1 DWDM 9980V 2





9980V 1 DWDM 9980V 2





9980V 1 DWDM 9980V 2



R-C R-AR-D R-B

AAA




R-C R-AR-D R-B



R-C R-AR-D R-B

BBDD A: 25% AutomáticoBBDD B: 25% AutomáticoBBDD C: 25% AutomáticoBBDD D: 25% Automático

Recuperación Sevicios de BBDD

Agenda




Resultados (I)Disponibilidad de la arquitectura: 99,99%

52 minutos de parada al añoRecuperación automática en menos de 1 minuto

Solución de Continuidad de Negocio. Recuperación de Desastres y Fallos Múltiples:



Funcionalidades de copia y réplica de datos:RAID Hardware y réplica (True Copy) de cabina de discos

Resultados (II)Escalabilidad de la capacidad de proceso:

112 procesadores USIV . Aumento de la capacidad de proceso en un 40%, incluido impacto por Oracle RAC ExtendidoLa capacidad de recursos COD permite absorber el 100% de la carga de trabajo ante fallos simples o en caso de desastreHasta 80 procesadores adicionales. Y en un futuro actualizarlos por procesadores más potentes


por procesadores más potentesFlexibilidad y capacidad de gestión :

Se mejora el mantenimiento preventivo y reactivo de la plataforma sin parada de servicio

Software de base:Gestor de BBDD Oracle 9i RAC 9.2Sistema Operativo Solaris 9 9/04

13

Agenda




Conclusiones. DisponibilidadComparación con Situación Inicial

Situación Inicial:Disponibilidad: ~99,9% (~8,75 horas/año)Recuperación Cluster:

A t áti

Solución Propuesta:Disponibilidad 99,99% (52 minutos/año)Recuperación Cluster:

A t áti


AutomáticaTiempo: Orden de magnitud en minutos

Recuperación de Desastres:

100% Manual en 4 horas

AutomáticaTiempo: Orden de magnitud en segundos

Recuperación de Desastres:

50% automática50% manual en < 4 horas

Conclusiones

Se mejora significativamente la disponibilidad del servicio de BBDDSe cumplen los requisitos de proyectoLa arquitectura propuesta reutiliza todos los


La arquitectura propuesta reutiliza todos los recursos actuales del cliente, reduciendo el coste de migración a la nueva arquitectura

Líneas Futuras De Trabajo1) Pasar a 2 Clusters de Oracle

HA2) Se creara un tercer Cluster

(particionando los servidores) con Oracle 9i RAC y 4 instancias, para probar la

it t t

Configuración de Oracle RAC en modo activo-activo o activo-latenteEn base a estas pruebas, si es necesario, se aplicarán las correcciones oportunas a la arquitectura propuesta


arquitectura propuesta: Funcionalidades en generalDisponibilidad de la soluciónReconexión de clientes, funcionalidad TAF de OracleRendimiento de Oracle RAC Extendido

3) Migración de las instancias Oracle 8i a Oracle 9i, como paso previo a la migración a Oracle 9i RAC

14

Gracias

Jesús Angulo Arribas

IntroducciónEl objetivo del proyecto es el diseño de una arquitectura de alta disponibilidad para el entorno de bases de datos. Dentro de un Plan de Continuidad de Negocio global de los servicios críticos de la organización, consolidados en una arquitectura de tres niveles: Web, Servidor de A li i B d D t


Aplicaciones y Bases de DatosEn el diseño de la solución participa: El propio cliente, Oracle y SunEl equipo de Sun esta formado por: Un coordinador del proyecto y, especialistas en Clusters y SO, Base de Datos Oracle y Sistemas de Almacenamiento

Recuperación ante Desastres (I)Recuperación de Desastres y Fallos Múltiples:

50% automática50% manual en < 4 horas

Se plantea una distribución las BBDD alternativa para mejorar la disponibilidad en caso de desastre:


Ubicar todas las BBDD de un mismo cluster, en la misma cabina de discosConfigurar el Dispositivo de Quórum del cluster en la misma cabina de discos que las BBDDSe penaliza tiempo de respuesta del 100% de las operaciones en uno de los dos nodos de cada clusterDe media el 66-67% de las BBDD se recuperarían automáticamente

Resultados (I)Disponibilidad de la arquitectura: 99,99%

52 minutos de parada al añoRecuperación automática en menos de 1 minuto

Solución de Continuidad de Negocio. Recuperación de Desastres y Fallos Múltiples:



Funcionalidades de copia y réplica de datos:RAID Hardware y réplica (True Copy) de cabina de discos

15

Resultados (II)Escalabilidad de la capacidad de proceso:

112 procesadores USIV . Aumento de la capacidad de proceso en un 40%, incluido impacto por Oracle RAC ExtendidoLa capacidad de recursos COD permite absorber el 100% de la carga de trabajo ante fallos simples o en


100% de la carga de trabajo ante fallos simples o en caso de desastreHasta 80 procesadores adicionales. Y en un futuro actualizarlos por procesadores más potentes

Flexibilidad y capacidad de gestión :Se mejora el mantenimiento preventivo y reactivo de la plataforma sin parada de servicio

Resultados (III)

Software de base:Gestor de BBDD Oracle 9i RAC 9.2Sistema Operativo Solaris 9 9/04Sun Cluster 3.1 8/05


Software de Veritas Storage Foundation Cluster File System 4.0, que incluye los productos:

Sistema de Ficheros Veritas Cluster File System 4.0Gestor de Volúmenes Veritas Cluster Volume Manager 4.0

Software TrueCopy para la replicación entre las cabinas de disco Hitachi 9980V

Líneas Futuras De Trabajo Recomendaciones y Alternativas

Recomendaciones:Dispositivo de quórum en tercer CPDActualización a Sun Cluster 3.2, permite Dispositivo de Quórum sobre un servidor Solaris con acceso IP

Alternativas:


BBDD de un mismo cluster en una única cabina de discos, junto con DQ: Aumenta la disponibilidad ante desastresConfigurar Oracle RAC en Activo-Latente, para evitar parte de la latencia del RAC extendidoClusters Oracle RAC Locales: Mejora el rendimiento, pero disminuye la disponibilidad ante desastres

Una Solución de Alta Disponibilidad de Negocio para un Servicio de Base de Datos

FACULTAD DE INFORMÁTICAUNIVERSIDAD POLITÉCNICA DE MADRID

un Servicio de Base de Datos

Defensa Proyecto Fin de CarreraAutor: Jesús Angulo ArribasTutora: Pilar Herrero Martín

clusters.ppt [modo de compatibilidad] - fi.upm.es · planes de continuidad de negocio ... oracle...

Documents