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

1
Alta Disponibilidad en UnixCaso HP-UX y
MC/Service Guard
2
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

3
Introducción

• Las necesidades del negocio actual y
• como la actual técnología intenta cubrirlas

4
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
5
Perdidas en media por falta de disponibilidad
Securities
Manufacturing
Telecommunications/Internet
Banking

• Cuanto cuesta una parada a una empresa?
• Cuantas paradas puede soportar una empresa?

Transportation
Retail
Insurance
100,000
200,000
300,000
400,000
500,000
Fuente Qualix Group, Find/SVP Strategic Research
Division, abril/96.
6
Posibles consecuencias de una parada

• Perdida de Clientes
• Perdida de Oportunidades
• Perdida de Capacidad
• Trabajo perdido o improductivo
• 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.
7
Causas de paradas no programadas

• Fallos en aplicaciones (p.e. errores y
  rendimiento)
• Fallos en Sistema Operativo
• Errores humanos
• Fallos de red (comunicaciones)
• Fallos en componentes Hardware
• Desastres naturales

Fuente Gartner Group febrero 2000
8
Soluciones a las paradas no planificadas

• Procesos de IT
• Gestión de parches
• Gestión de Cambios
• Ajustes de configuración
• Consultoría de integración
• ...

• Acuerdos de Soporte
• Proactivo y Reactivo
• Punto único de contacto de Soporte 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
9
Conceptos de Cluster en Unix

• Como Unix permite reiniciar procesos que corren
  en un servidor en otro, en caso de fallo del
  primero.
• Repaso de Conceptos.

Aplicación reiniciada
Aplicación antes fallo
Servidor Principal (sufre un fallo)
Servidor Secundario
10
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)

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, 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.

12
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
• El Sistema de Clustering permite eliminar el caso
  de fallo en CPU y Red.

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
13
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.

14
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.

Aplicación Contabilidad
VG's
names nodes etc
15
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 192.6.3.5
Standby LAN
IP Estática 192.6.3.6
Standby LAN
16
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.

17
Configuración típica de un Cluster II
HUB
HUB
Lan Activa
Lan Secundaria
root
root
Aplicación X
Aplicación Y
18
Proceso de traspaso de paquete
Node 2
Node 2
FAILOVER
Pkg A
Node 1
Node 3
Node 1
Node 3
Pkg F
Pkg A
Pkg A
Pkg F
Pkg B
Pkg B
Pkg B
Node 4
Node 4
Pkg C
Pkg C
Pkg G
Pkg G

• En caso de que se produzca un fallo en un
  servidor se traspasa automáticamente (Failover)
  los paquetes a nodos secundarios.

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

• El software MC/Service Guard de realiza las
  funciones de Cluster sobre HP-UX para servidores
  Unix Hewlett Packard HP9000

Aplicación reiniciada
Aplicación antes fallo
Servidor Principal (sufre un fallo)
Servidor Secundario
21
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

22
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.

23
Hardware Configuración Disco
Nodo A
Nodo B

• VG minor 's
• VG names
• LV names

Package
vgdb1
vgdb2
s0
24
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 A Coordinador del Cluster
Se requiere coordinación
nodo B
nodo B
A
nodo C
nodo D
nodo C
nodo D
25
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

26
Gestión del Cluster Configuración

• Se configura y se propagan los ficheros a todos
  los nodos del Cluster

node A
node B
daemons cmcld cmfork
daemons cmcld cmfork
Node A fichero binario configurado
Node B fichero binario configurado
identicos !!!
/etc/cmcluster/cmclconfig
27
Gestión del Cluster Arranque, control y parada

• Arrancamos todos los nodos cmrumcl v
• Control del Cluster cmviewcl -v
• Estado del Cluster
• Estado del Node
• Estado del Paquete
• Package Switching
• Estado de los servicios
• Paramos todos los nodos cmhaltcl v
• Todos los comandos también desde SAM
• Para más información man ltcomandogt

28
Gestión del paquete Configuración

• Tras configurar el Cluster debemos configurar los
  paquetes que se ejecutarán dentro del mismo
• Crear template de configuración y ficheros de
  control cmmakepkg -p pkg_name.conf cmmakepkg
  -s pkg_name.cntl
• Modificar los templates para que reflejar la
  configuración concreta de cada paquete
• Distribuir los ficheros de control de los
  paquetes a todos los nodos
• Verificar la configuración cmcheckconf -C
  cmclconf.ascii -P pkg_name.conf
• Crear y distribuir el fichero binario de la
  configuración cmapplyconf -C cmclconf.ascii
  -P pkg_name.conf
• Arrancar el Cluster, los paquetes arrancas
  automáticamente cmruncl

29
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
• ...

30
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 ltcomandogt

31
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

32
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

33
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 192.6.3.5
Standby LAN
IP Estática 192.6.3.6
Standby LAN
34
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

35
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
lan0 data heartbeat LAN
Subnet S1
36
Ú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, ...