Alta Disponibilidad en Unix Caso HP-UX y MC/Service Guard

CONCEPTES AVANÇATS DE SISTEMES OPERATIUS
Departament d’Arquitectura de Computadors
Alta Disponibilidad en Unix
Caso HP-UX y MC/Service Guard
Antonio Díaz
Pere Munuera
Indice
 Introducción
– Las necesidades del negocio actual y como la actual técnología
intenta cubrirlas.
 Concepto de Cluster en Unix
– Como Unix permite reiniciar procesos que corren en un servidor
en otro, en caso de fallo del primero.
 Solución concreta de Hewlett Packard para HP-UX
– El software MC/Service Guard realiza las funciones de Cluster
sobre HP-UX para servidores Unix Hewlett Packard HP9000

Departament. d’Arquitectura de Computadors - UPC
2
Introducción
Las necesidades del negocio actual y

como la actual técnología intenta cubrirlas

3
La economía actual requiere más disponibilidad
 La sociedad y los negocios se mueven hacía
entornos más dinámicos y continuamente
online.
– Incrementan la presión de la competencia,
– Globalización de los servicios,
– E-comercio,
– Los Clientes demandan accesos continuos a la
información más rápidos y fáciles.
– Los procesos de negocio dependen de la
infraestructura IT. Por ejemplo no se permiten
copias de seguridad manuales: cuando la
infraestructura se para, el negocio se para.
Desafío: Crear infraestructura flexible, escalable y altamente disponible, que permita a los
equipos de IT soportar las necesidades del negocio de hoy y mañana

4
Perdidas en media por falta de disponibilidad
Securities
Manufacturing
Telecommunications/Internet
Banking
Cuanto cuesta una
Transportation parada a una empresa?
Cuantas paradas puede
Retail soportar una empresa?
Insurance
$100,000 $200,000 $300,000 $400,000 $500,000

Fuente: Qualix Group, Find/SVP Strategic Research Division, abril/96.

5
Posibles consecuencias de una parada
 Perdida de Clientes
 Perdida de Oportunidades
 Perdida de Capacidad
 Trabajo perdido o improductivo EWS
N
 Costes de Restauración
 Penalizaciones
 Mala Publicidad Las paradas no programadas son simplemente
inaceptables para una empresa que quiera mantener los
compromisos con sus Clientes.

6
Causas de paradas no programadas
 Fallos en aplicaciones (p.e.
errores y rendimiento)
 Fallos en Sistema
Fallos en aplicaciones
Operativo Hardware
20%
 Errores humanos 40%
 Fallos de red 40%

IT Processes
(comunicaciones)
Errores del Operador / Administrador
 Fallos en componentes
Fuente: Gartner Group
Hardware febrero 2000
 Desastres naturales
7
Soluciones a las paradas no planificadas
Procesos de IT:
Acuerdos de Soporte:
 Gestión de parches
 Proactivo y Reactivo
 Gestión de Cambios
 Punto único de
 Ajustes de configuración
contacto de Soporte
 Consultoría de integración
para toda la
 ...
infraestructura
Tecnología de infraestructura:
 Integración con productos de
alta disponibilidad Este trabajo se centrará
en este área
Solución: Los Sistemas tolerantes a fallos se apoyan en 3 pilares que unidos dan la seguridad
más alta a la instalación

8
Conceptos de Cluster en Unix
Aplicación Aplicación
reiniciada
antes fallo
Servidor Principal Servidor Secundario

(sufre un fallo)
Como Unix permite reiniciar procesos que corren en un

servidor en otro, en caso de fallo del primero.
Repaso de Conceptos.

9
Alta Disponibilidad
 Alta disponibilidad (HA) más allá de la disponibilidad del Hw. Esto

implica asegurar la disponibilidad de acceso a la aplicación, con
sólo una pequeña interrupción, en caso de fallo de alguno de los
componentes del sistema. Sistemas de HA permiten reiniciar
aplicaciones en un Hw redundante en caso de fallos.
 El tiempo de interrupción depende de principalmente de la
recuperabilidad de la aplicación, o sea del tiempo que le cuesta a la
aplicación volver a estar operativa en caso de una parada
brusca. Los requerimientos tiempo máxima de parada se acuerdan
en los Acuerdos de Nivel de Servicio (SLA)

10
Punto único de fallo Hw de un servidor
 El objetivo principal de un Sistema de Alta Disponibilidad es eliminar

los puntos únicos de fallo, en nuestro caso nos centraremos en los de
un servidor y como solucionarlos:
– CPU: MultiCPU + Clustering
– Disco: Duplicación de disco (Raid-x y Discos Espejo)
– Red: Duplicación de placas de red + sw de Clustering
– Electricidad: PDUs y magnetotérmicos duplicadas, SAI.
– Canales de I/O: Duplicación de conexiones.
 El Sistema de Clustering permite eliminar el caso de fallo en CPU y
Red.

11
Punto único de fallo Hw de un servidor
 El objetivo principal de un Sistema de Alta Disponibilidad es eliminar
los puntos únicos de fallo (Single Point of Failure-SPOF), en nuestro
caso nos centraremos en los de un servidor y como solucionarlos:
SPOF Solución
CPU MultiCPU + Clustering
Disco Duplicación de disco (Raid-x y Discos Espejo)
Red Duplicación de placas de red + sw de
Clustering
Electricidad PDUs y magnetotérmicos duplicadas, SAI
Canales de I/O Duplicación de conexiones
 El Sistema de Clustering permite eliminar el caso de fallo en CPU y

Red.
12
Grupos de Volumenes en Cluster
 Grupo de Volumes (VG): Agrupación lógica de discos físicos.
 Para permitir que múltiples servidores compartan aplicaciones, estos
deben tener acceso a los discos donde reside el Software.
 Los VG configurados inicialmente en el servidor principal, son
importados al servidor secundario en caso de fallo en el primero.
 El Sistema Operativo no es compartido. Cada nodo tiene su propio
VG para almacenarlo.

13
Concepto de Paquete
 Las Aplicaciones son agrupadas en ‘Paquetes’. Un paquete contiene
los recursos que necesita para correr una aplicación. Típicamente
VGs.
 Una regla general es que un recurso sólo pertenece a un paquete.
 Un paquete también tiene asociados shell scripts y funciones que
permiten iniciar y parar aplicaciones.
scripts
VG's names
nodes
etc

14
Reasignación de direcciones IP
 Una dirección IP estática nunca cambia.
 Para el Cliente (usuario) el Servidor (aplicación) tiene asociada una
dirección IP que en caso de cambio de servidor debería mantenerse
 Direcciones IP dinámicas.
 Las IP dinámicas se configuran como recursos de un paquete, así
que allí donde este el paquete funcionando estará ‘mapeada’ la IP.
IP Estática: Standby IP Estática: Standby

192.6.3.5 LAN 192.6.3.6 LAN
IP dinámica:
192.6.3.88 CONCEPTES AVANÇATS DE SISTEMES OPERATIUS
Contabilidad Departament. d’Arquitectura de Computadors - UPC
15
Configuración típica de un Cluster I
 Un Cluster Consiste típicamente de:
– 2 o más servidores
– 1 o más paquetes
– 1 o más Grupo de Volúmenes (VG) por paquete.
– 1 o más Aplicaciones por paquete.
– 1 o más direcciones IP dinámicas por paquete.
– 1 conjunto de scripts de configuración por paquete
 Cuando se configura el Cluster se arranca 1 proceso (Hearbeat) en

cada servidor que está continuamente comprobando que el otro esté
‘vivo’, en caso de que el servidor secundario no detecte al primario se
inicia el proceso de traspaso de aplicaciones.
16
Configuración típica de un Cluster II
Lan HUB HUB Lan

Activa Secundaria
root root
Aplicación X
Aplicación Y

17
Proceso de traspaso de paquete
Node 2 Node 2
Pkg D Pkg D
Pkg E Pkg E
Pkg A
Node 1 Node 1 Node 3
Node 3
FAILOVER
Pkg A Pkg F
Pkg A Pkg F
Pkg B Pkg B Pkg B
Node 4 Node 4
Pkg C Pkg C Pkg G
Pkg G
Pkg C
Pkg H Pkg H
Pkg I Pkg I
En caso de que se produzca un fallo en un servidor se traspasa

automáticamente (Failover) los paquetes a nodos secundarios.
18
Proceso de traspaso de paquete II
1 2 3 4 5 6
tiempo
A B C D E
1. Ocurre un Fallo A. Transcurren los 2 segundos de no
2. El fallo es detectado contestación (hearbeat) por defecto
3. Arranque del paquete en el nodo B. Reconfiguración del Cluster y
secundario elección del nodo secundario
4. Recuperación del File Sistem, si aplica. C. Activación los VGs del paquete
5. Inicio Recuperación de la aplicación D. Recuperación del File Sistem, si
6. La aplicación está disponible a los aplica
usuarios E. Proceso de Recuperación de la
aplicación
19
Solución concreta de Hewlett Packard para HP-UX
HP High
Availability
Aplicación
Aplicación
reiniciada
antes fallo
Servidor Principal Servidor Secundario

(sufre un fallo)
El software MC/Service Guard de realiza las funciones de

Cluster sobre HP-UX para servidores Unix Hewlett Packard
HP9000

20
Nomenclatura HP MC/Service Guard
 HP-UX: Sistema Operativo Unix propietario de HP
 Paquete: package
 Servidor: node o nodo
 LVM (Logical Volume Manager): Gestor HP-UX de VGs
 SAM: Utilidad de HP-UX para gestión del Sistema Operativo

21
Hardware: Configuración Disco
 Los servidores comparten un bus (Fiber Channel o SCSI), de donde

están ‘pinchados’ los discos que contienen los VGs de los paquetes.
 Todos los discos deben estar gestionados por LVM (Logical Volumen
Manager). En caso de fallo de disco MC/Service Guard asume que el
sw de LVM y Mirror lo atienden.
 Cada nodo debe tener su propio disco de arranque (boot).
 El disco de arranque debe pertenecer a un VG que no esté en el
Cluster (tipicamente vg00).
 Los VGs se deben llamar igual en cada nodo del Cluster.

22
Hardware: Configuración Disco
Nodo A Nodo B
 VG minor #'s
 VG names
 LV names
/etc/lvmtab /etc/lvmtab
. .
vgdb1 Package vgdb1
. .
vgdb2 vgdb2
vgdb1 vgdb2
s0
23
Hardware: Cluster Lock Disk
 MC/Service Guard para evitar que entre dos nodos pudieran llegar a acceder a los
mismos discos a la vez, se configura un disco (vgchange –c y /dev/vgxx)que el
primer nodo que lo monte es el que hará el papel de principal.  Previene la
activación de un paquete en más de un nodo.
 En caso de caída del nodo A, el ‘Cluster Lock Disk’ es libre y el primero que se lo
asigne será el nuevo Coordinador del Cluster
nodo A nodo B nodo A

Coordinador nodo B
del Cluster
Se requiere
coordinación
A
nodo C nodo D
nodo C nodo D

24
Gestión del Cluster
 MC/Service Guard proporciona comandos para configurar, gestionar
y monitorizar el Cluster:
– Bajo /usr/sbin/ están todos los comandos de gestión: cmquerycl, cmmakepkg,
cmscancl, cmgetconf, cmcheckconf, cmapplycon, cmruncl, cmhaltcl, cmviewcl,
cmrunpkg, cmhaltpkg, cmmodpkg, cmrunnode, cmhaltnode)
– Bajo /etc/cmcluster se encuentran los ficheros de configuración del Cluster (
– Para asegurarse la compatibilidad de los recursos el fichero .rhosts debe estar
configurado
– El fichero cmclnodelist contiene la información de los nodos que forman el
Cluster
– Parámetros más importantes de configuración: CLUSTER_NAME,
MAX_CONFIGURED_PACKAGES, FIRST_CLUSTER_LOCK_VG, HEARTBEAT_IP,
STATIONARY_IP, FIRST_CLUSTER_LOCK_PV, HEARTBEAT_INTERVAL,
NODE_TIMEOUT, NETWORK_POLLING_INTERVAL, AUTO_START_TIMEOUT,
VOLUME_GROUP
25
Gestión del Cluster: Configuración
 Se configura y se propagan los ficheros a todos los nodos del Cluster
node A node B
template
cmquerycl
obtención de editamos el daemons: daemons:

información template cmcld cmcld
cmfork cmfork
fichero ASCII
fichero ASCII configurado Node A Node B
cmcheckconf
fichero binario fichero binario
(verifica el
configurado configurado
fichero ASCII)
fichero binario
cmapplyconf configurado
(convierte a binario) identicos !!!
/etc/cmcluster/cmclconfig
26
Gestión del Cluster: Arranque, control y parada
H 90
00
 Arrancamos todos los nodos: # cmrumcl –v H 9

0
0
0
H 9
0
0
0
H 90
00
 Control del Cluster: cmviewcl -v HP 90

00
– Estado del Cluster

– Estado del Node
– Estado del Paquete
– Package Switching
– Estado de los servicios H 90
00
 Paramos todos los nodos: # cmhaltcl –v H 90

00
H 90
00
Todos los comandos también desde SAM H 90

00
Para más información # man <comando>

27
Gestión del paquete: Configuración
 Tras configurar el Cluster debemos configurar los
paquetes que se ejecutarán dentro del mismo:
1. Crear template de configuración y ficheros de control
cmmakepkg -p pkg_name.conf
cmmakepkg -s pkg_name.cntl
2. Modificar los templates para que reflejar la configuración concreta de
cada paquete
3. Distribuir los ficheros de control de los paquetes a todos los nodos
4. Verificar la configuración
cmcheckconf [-C cmclconf.ascii] -P pkg_name.conf
5. Crear y distribuir el fichero binario de la configuración
cmapplyconf [-C cmclconf.ascii] -P pkg_name.conf
6. Arrancar el Cluster, los paquetes arrancas automáticamente
cmruncl
28
Gestión del paquete: Parámetros significativos
Fichero de Configuración
 PACKAGE_NAME pkg1.accounting
 NODE_NAME original_node
 NODE_NAME adoptive_node
 NODE_NAME adoptive_node
 PKG_SWITCHING_ENABLED YES
 NET_SWITCHING_ENABLED YES
 FAILOVER_POLICY CONFIGURED_NODE
 FAILBACK_POLICY MANUAL
 SUBNET 15.128.152.0
 SUBNET 192.6.20.0
 RUN_SCRIPT /etc/cmcluster/pkg1/pkg_name.cntl RUN_SCRIPT_TIMEOUT NO_TIMEOUT
 HALT_SCRIPT /etc/cmcluster/pkg1/pkg_name.cntl
 HALT_SCRIPT_TIMEOUT NO_TIMEOUT
 ...

29
Gestión del paquete: Arranque, parada y mover
 Arranque de un paquete en un nodo concreto:
# cmrunpkg [-n node1] pkg1
 Paramos un paquete: # cmhaltpkg –v
 Mover un paquete de nodo:

cmhaltpkg pkg1
cmrunpkg -n node2 pkg1
cmmodpkg -e pkg1
Todos los comandos también desde SAM
Para más información # man <comando>
30
Gestión del Cluster y paquete
# cmviewcl –v
PACKAGE STATUS STATE PKG_SWITCH NODE
pkg1 up running enabled ftsys9
Policy_Parameters:
POLICY_NAME CONFIGURED_VALUE
Failover configured_node
Failback manual
Script_Parameters:
ITEM STATUS MAX_RESTARTS RESTARTS NAME
Service up 2 0 pkg1.ser_1
Service up 0 0 pkg1.ser_2
Subnet up 15.13.168.0
Node_Switching_Parameters:
NODE_TYPE STATUS SWITCHING NAME
Primary up enabled ftsys9 (current)
Alternate up disabled ftsys10
31
Red
 MC/Service Guard permite las siguientes funciones sobre los
elementos y configuraciones de red:
– Reasignación de direcciones IP
– Reconfiguración de red local
– Comunicación dentro del Cluster (o heartbeats)
– Conexión del Cliente a los datos
 Redes soportadas:
– Ethernet
– Token Ring
– FDDI
– VG100
– 10Base/ 100Base T

32
Red: Reasignación de direcciones IP
 En caso de caída del nodo principal donde se conectan los
usuarios se habilita el nodo secundario y se reasigna la IP
al nuevo nodo
IP Estática: Standby IP Estática: Standby

192.6.3.5 LAN 192.6.3.6 LAN
IP dinámica:
192.6.3.88
Contabilidad

33
Red: Reconfiguración de red local
 En caso de en placa de red de un servidor se habilita una
placa secundaria dentro del mismo servidor
Stationary and
Relocatable IP's:
192.6.3.5 and
192.6.3.88 192.6.3.5
192.6.3.88
lan1: Standby LAN Subnet S1
Bridge
lan0: data & heartbeat LAN Subnet S1

34
Red: Configuración típica de la red
 La configuración de red típica para asegurar alta
disponibilidad
heartbeat
over RS232
lan1: Standby LAN Subnet S1
Bridge
lan0: data & heartbeat LAN Subnet S1

35
Últimas Consideraciones sobre alta disponibilidad
 Todo sistema de aseguramiento de la alta disponibilidad
entra en funcionamiento sólo en caso de problemas 
Planificar pruebas de funcionalidad periódicamente
 Estos sistemas son complejos de administrar y gestionar 
Utilizarlos en los entornos realmente necesarios
(Productivos)
 No descuidar ningún SPOF  Elementos que no siempre
se consideran: SAIs, redundancia de magnetotérmicos y
fuentes de alimentación, copias de seguridad, ...

36

Alta Disponibilidad en Unix Caso HP-UX y MC/Service Guard

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Alta Disponibilidad en Unix Caso HP-UX y MC/Service Guard

Transféré par

Droits d'auteur :

Formats disponibles

CONCEPTES AVANÇATS DE SISTEMES OPERATIUS

Departament d’Arquitectura de Computadors