ALTA DISPONIBILIDAD
La gestión de la alta disponibilidad se ha realizado en el plano inter-vm, descartando escalar hasta el hypervisor (VMWare), por motivos economicos, se ha optado por el stack Pacemaker+Corosync, tandem habitual de este tipo de entornos.
1 – COROSYNC LAYER
La configuración de corosync, presente en /etc/corosync.conf se expone a continuación, es la misma en todos los nodos (y debe serlo):
<pre>
totem {
version: 2
transport: udpu # set to ‘udpu’ (udp unicast)
cluster_name: kamailio
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
interface {
ringnumber: 0
bindnetaddr: 10.220.1.0
ttl: 1
}
}
quorum {
provider: corosync_votequorum
expected_votes: 3
}
nodelist {
node {
ring0_addr: 10.220.1.21
}
node {
ring0_addr: 10.220.1.22
}
node {
ring0_addr: 10.220.1.23
}
}
logging {
fileline: off
to_stderr: no
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
</pre>
Sobre esta configuración, pocos comentarios importantes:
• Transporte Unicast, para evitar posibles problemas en el IP Layer en áreas de
multicasting transport.
2 – PACEMAKER LAYER
Como gestor de recursos de clustering se utiliza Pacemaker, que es quien (basándose en la información desde/hacia Corosync) conoce como están todos los nodos y conoce las políticas de cluster configuradas.
Cabe destacar que en Debian 8 los mantenedores no llegaron a tiempo de preparar las versiones finales del software, con lo que se ha desplegado todo desde el repositorio oficial de Jessie Backports.
La configuración se expone a continuación:
crm(live)# configure show
node 182190357: kamailio01
node 182190358: kamailio02
node 182190359: kamailio03 \
attributes standby=on
primitive IP-HA-01 IPaddr2 \
params ip=10.220.1.25 nic=eth0 cidr_netmask=24 \
meta migration-threshold=2 \
op monitor interval=20 timeout=60 on-fail=restart
primitive KAMAILIO01 systemd:kamailio \
op monitor interval=30s timeout=60s on-fail=restart \
op start interval=0 timeout=30s \
op stop interval=0 timeout=30s \
meta is-managed=true
primitive stonithssh stonith:external/ssh \
params hostlist=»kamailio01 kamailio02 kamailio03″
group PROXY01 IP-HA-01 KAMAILIO01 \
meta target-role=Started
clone fencing stonithssh
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.16-94ff4df \
cluster-infrastructure=corosync \
cluster-name=kamailio \
no-quorum-policy=ignore \
stonith-enabled=true \
stonith-action=reboot
rsc_defaults rsc-options: \
resource-stickiness=100
Explicación detallada por sección y área de configuración:
Stonith
En caso de desajuste por caída temporal de comunicación y llegar a la situación poco deseada de “split-brain”, la forma técnica recomendada y standarizada es la de “shoot the other node in the head”, es decir, hacer que muera el nodo que está en rebeldía en lo que a quorum de decisiones se refiere.
Se ha optado por tener el mecanismo vía SSH, al estar virtualizado y no tener regletas IPMI o similaes y no se plantea escalar hasta API’s de Hyperviso.
Agrupar Recursos en grupos
El agrupado es únicamente para hacer que tanto Kamailio como la IP Virtual estén siempre en el mismo servidor.
Y, por otra parte, para que arranquen en dicho orden, primero la IP Virtual, luego Kamailio.
Nodo en Standby
El modelo de replicación de BBDD escogido: M/S cruzado, y el acuerdo técnico del tercer nodo para el quorum, obligan a tenerlo en standby, siendo únicamente necesario para las votaciones de recursos. Es decir, el nodo Kamailio03 nunca ejecutará ningún servicio, salvo intervención puntual manual.
