Pool de servidores: Homoxéneos, Heteroxéneos. XenMotion. Alta dispoñibilidade (HA)

Introdución

Unha das funcionalidades que aporta XenServer/XCP é que se poden agrupar varios hosts XenServer/XenServer nunha única entidade de xestión. Esta entidade denomínase Pool.

Dispor dun Pool favorece:
- Iniciar MVs en calquera host do pool, icluso o Pool pode escoller iniciala no host menos cargado.
- Migrar MVs en quente dun host a outro, este proceso coñecese como XenMotion e débese dispoñer de almacenamento externo compartido.
- Se cae un host, as MVs que estaba executando móvense automaticamente para os outros hosts do Pool. Esta funcionalidade denomínase Alta dispoñibilidade, High Avaialability (HA).
- O pool encárgase de acender as MVs que estaban executándose no host caído nun dos hosts accesos do pool.
- Ademais o proceso de XenMotion pode servir para realizar tarefas de mantemento nun servidor físico, pois podemos mover tódalas MVs que están activas nese host para outro servidor do pool sen apagar as MVs. Deste xeito o servizo non se resente e podemos, por exemplo, ampliarlle a RAM ao primeiro host.

Nun Pool un dos hosts actúa como Mestre (Master). Ese host é o que expón a interface de administración para administrar todo o grupo de servidores.
Se se realiza unha operación no Master, esta reprodúcese nos demais membros.
Se o Master cae, entón cae todo o Pool, salvo que se dispoña da funcionalidade HA.
Cando se engade un host a un Pool, este herda de xeito automático:
- os SRs externos dos que dispoña o Pool, pero para que sexan efectivos ese host debe dispoñer dos mesmos camiños físicos/VLANS có Master para poder chegar aos recursos de almacenamento.
- As redes (Switches Virtuais) que teña o pool.
- Esta é a razón pola que nos escenarios anteriores, xen00 se foi cargando de cousas (Rede, Almacenamento) para cando sexa o Master dun Pool observar que pasa co outro host que se una a ese Pool.

Os Pools pode dividirse en:
- Homoxéneos: As CPUs dos hosts son do mesmo tipo, modelo e funcionalidades.
- Heteroxéneos: Cando as CPUs non son do mesmo tipo. Neste caso hai que engadir os equipos ao Pool a través de xsconsole ou CLI xe.

Para engadir hots a un Pool, que xa ten un Mestre:
- Estes deben estar correndo a mesma versión de XEN, e as mesmas actualizacións.
- Non é membro doutro Pool.
- Non usa almacenamento compartido (remoto).
- Non ten MVs funcionando ou suspendidas.
- Non hai operacións activas no momento da unión.
- Revisar que os reloxos estean sincronizados
- O Management Interface non debe estar en Bonding (Pódese configurar despois de unirse ao Pool)

Os membros dun Pool poden ter:
- Diferente número de NICs.
- Almacenamento propio local e de distintos tamaños.

Pool homexéneo

A continuación vaise crear unha nova MV, xen01 coas mesmas características que xen00.

Instalar xen01: Host que se vai unir ao Pool

Crear unha MV, xen01 do mesmo xeito que se creou e ampliou xen00: Instalación de XenServer
- Neste caso cun so disco é suficiente. Neste exemplo creouse un disco de 100 GB de tamaño.
- 3 tarxetas de rede en modo promiscuo.
  - 1ª e 2ª en modo Ponte.
  - En modo Rede Interna.
- Mesmo número de CPUS e mesmas funcionalidades.
- Memoria RAM non ten porque ser igual. Nesta práctica vaise asignar 1 GB a xen01. Quen o desexe, pode configurar máis cantidade en función das súas posibilidades.

Configuración xen01
Primeiro adaptador de rede (Ponte/Promiscuo)... Cando se instale xen01, usar este adptador (eth0) para o Management Interface do host con IP: X.Y.Z.201.
Segundo (Ponte/Promiscuo) ...
Terceiro en modo Rede Interna
Dende XenCenter conectámonos a xen01, sen metelo en ningún Pool. Vemos que precisa ser actualizado (Lema frecha-amarela na icona do servidor). Tamén van saltar as alertas.
Nesta ocasión imos actualizar facendo uso da consola do host, ben dende XenCenter ou a través dun ssh.
No momento de baixa a actualización da web (Neste caso o SP1), copiamos a ruta á ligazón e dende a consola executamos wget http://Pegamos a ruta do enlace. E así descargamos o ficheiro da actualización ao propio servidor (http://es.wikipedia.org/wiki/GNU_Wget). Tamén se podería ter copiado o ficheiro da actualización dende un repositorio local a través do comando scp (Secure CoPy: http://es.wikipedia.org/wiki/SCP)
Unha vez que temos o ficheiro no host, por calquera dos dous métodos anteriores:
Descomprimímolo (unzip ...). Axudarse da tecla TAB.
Cargámolo no virtualizador: xe patch-upload .... Observar que non se lle pasa nin a IP do servidor nin as credenciais, pois xa estamos no servidor destino. Co uuid que xera ...
Aplicamos o parche co comando xe patch-pool-apply .... Pois cada servidor independente é o mestre do seu Pool (Pool por defecto).
Agora seguimos facendo o mesmo co resto das actualizacións que hai que aplicar e finalmente reiniciamos o servidor dende a consola (init 6).
Servidor xen01 actualizado.
Observar Memoria RAM.
Os tres NICs
As tres redes cos nomes por defecto e o Management Interface configurado coa IP X.Y.Z.201.
Non se precisa configurar nada máis en xen01.

Crear Pool Homoxéneo

O escenario 6.J pode resultar complexo, pero se se analiza con tranquilidade, pódese observar que cando xen01 forme parte do Pool cuxo máster é xen00, xen01 vai herdar as configuracións do Master de:
- SRs.
- Rede

A seguinte imaxe 6.J-BIS amosa o mesmo que á anterior pero representando o efecto do POOL. Observar como agora os SRs pertencen ao Pool e non a un servidor concreto.
Se houbera que engadir máis SRs estes engadiríanse ao Pool non a un servidor concreto.
As MVs execútanse nun host concreto (usan a súa RAM e CPU) pero os seus VDIs poden estar nun SR do Pool.

Crear Pool
Lembrar como está configurado xen00 dos escenarios anteriores: ...
Varias redes:
Interna
Xestión
Tráfico MVs
Almacenamento
Tres NICs.
Seis SRs:
Almacenamento VDIs: contra a NAS (iSCSI e NFS)
Backup: contra a NAS (CIFS e NFS)
Imaxes ISOs: (contra un PC(CIFS) e contra a NAS (NFS)).
Crear un novo Pool
Observar que indica que o HW de xen01 non coincide co de xen00 (quen vai ser o Master). Neste caso fíxose a propósito que tivesen distinto número de CPUs, co cal ...
Unha vez solventadas as diferencias entre os hosts ... Crear un Pool con nome: Pool - Homoxéneo.
Proceso de creación do Pool, xen01 está en modo OFF mentres comeza a iniciarse
Pasa a modo Mantemento mentres herda a configuración de xen00.
xen01 xa está activo. Vemos que os SR externos, os compartidos, pertencen ao Pool e non a ningún host en concreto.
Pero 3 deles, os que van contra a NAS, non están activos, por que será?. Pronto o arranxaremos.
Observar que os SRs Backup está conectados, lembrar que ...
... iso é porque non están conectados á NAS a través da rede de Almacenamento (NIC2) senón pola rede de Xestión (NIC0).
Como xa indicamos, isto non ten senso. Pero é para amosar ao usuario do curso distintas casuísticas, pois o lóxico é que eses SRs tamén estiveran conectados á NAS a través da rede de Almacenamento (172.16.0.0).
Revisemos características do Pool: As MVs que te cada un ...
A Memoria de cada host ...
Os SR
A rede?.
Fantástico!!!. Vemos que o host xen01 herdou a configuración de rede de xen00, incluso a rede interna privada, pero ... Observar que para xen00 hai 2 configuracións IP (xestión e almacenamento), pero para xen01 hai so unha configuración IP (xestión) ...
Se tratamos de reparar un do SR compartidos ...
Non imos ter éxito, pois dende xen01 non hai un camiño para chegar ao almacenamento da NAS.
En xen01 imos engadir unha configuración IP sobre a rede Almacenamento
Premer en Add IP Address.
Poñer un nome á configuración IP.
Indicar que é sobre a rede Almacenamento para poder chegar á NAS
e realizar a configuración IP: 172.16.0.201/24
Interface de Almacenamento creado. Observar que non lle chamamos igual que en xen00. Pero que sí está sobre a rede Almacenamento e esta está sobre a NIC2 que é a que está na mesma rede física que a NAS.
Agora xa podemos reparar os SRs
SR reparado. Observar como hai conexión dende os 2 hosts ao mesmo SR.
Pool totalmente operativo. Observar como os recursos SR que non son locais aparecen asignados ao Pool e non a ningún servidor en concreto, e iso que foron creados dende xen00!!!.

Operacións con MVs nun Pool

Imos ver que cousas se poden realizar coas MVs.
Agora podemos mover discos de MVs entre os almacenamentos locais dos 2 hosts, por exemplo, e incluso en quente.
Pero iso non é o normal. O lóxico é mover MVs entre hosts que teñen os VDIs nun SR externo (NFS ou iSCSI).
- Neste último caso, cando se move unha MV dun host a outro só se vai mover:
  - O que haxa na memoria RAM e
  - O que haxa nos rexistros da CPU,
- O disco da MV (VDI) non se vai mover, pois xa é visible polos dous hosts ao estar creado dentro nun SR do Pool.

Inicio e Migración (XenMotion)

Imos traballar coa MV dnfs, que lembrar tiña o seu VDI nun SR NFS VHD, isto é, na NAS.

Operacións con MVs
Antes de comezar con dnfs imos ver que pasa se tratamos de iniciar unha MV (dMySql, p.e.) que ten o seu disco (VDI) no SR local dun host, neste caso, xen00. Pois, que só deixa iniciar esa MV no host no que está o VDI e non noutro host do Pool.
Á MV dnfs, que ten o seu VDI creado no SR do Pool Almacenamento VDIs (NAS / NFS) asociado ao recurso da NAS NFS_VDIs, podemos indicarlle en que host queremos que se inicie, e aínda que pertence ao host xen00 imos iniciala no xen01.
Pero non podemos iniciala en xen01, porque non hai suficiente espazo no servidor...
Para iso axustamos a memoria de dnfs a 128 MB, ben fixos ou ben dinámicos.
Agora xa podemos indicar que se inicie en xen01 a MV que está en xen00.
Isto é posible xa que os membros do Pool comparten o SR: Almacenamento VDIs (NAS / NFS)
Vemos que a MV está iniciada en xen01.
Observar que está consumindo uns 181 MB, está aproveitando toda a RAM que deixa libre o host xen01 (Lembrar que se creara con 1 GB de RAM).
Arrancamos un ping 8.8.8.8 na consola da MV dnfs ...
... porque imos migrala en quente á xen00. Esta operación tamén se pode realizar arrastrando a MV dun host ao outro.
A MV está migrándose, esta funcionalidade coñécese con nome de XenMotion.
Só se ten que migrar o contido da memoria RAM e os Rexistros da CPU, pois o disco (VDI) da MV xa está nun SR do Pool.
A MV está migrada, cortouse o ping e vese que non se perdeu ningún deles.
A lapela Log da MV onde indica o tempo que levou a migración de xen01 a xen00.

Onde se inicia unha MV?

Unha MV que teña os seus discos (VDIs) nun SR do Pool, pode ser iniciada en:
- Home server: á MV indícaselle que sempre que se inicie que se inicie no mesmo host.
- No pool: á MV indícase que sempre que se inicie que busque no Pool aquel host que está máis liberado de recursos.

Inicio das MVs
Apagar dnfs. Imos ver como configurar en que host se debe iniciar por defecto. Seleccionar a MV dnfs e premer en Propiedades.
Seleccionar a opción Home Server.
A MV dnfs está asignada ao host xen00, para que se inicie nel (Observar que ese host só ten 2 GB de RAM), pero ...
... podemos indicarlle que non a asigne o inicio desa MV a ningún host, senón ao Pool.
Deste xeito a MV é do Pool e non dun host en concreto. Cando se inicie a MV tratará de facelo sempre no mesmo host, se este dispón de recursos libres necesarios. Se ese host non ten os recursos libres necesarios tratará de buscalos noutro host para iniciarse nel.
Nesta ocasión iniciáronse varias MVs en xen00, co cal, xa non admite máis.
Observar a memoria do Pool dos hots xen00 (2GB) e de xen01 (1GB).
Agora cando lle indicamos á MV dnfs que se inicie, esta non ten outra opción que escoller o host xen01 para executarse.
Aquí vemos dnfs executándose en xen01.
Se se desexa pódese indicar que o Home server para unha MV sexa distinto daquel no que foi creada.
Aquí vemos dnfs apagada e no Home Server xen01. Para iso non houbo máis que cambiar en propiedades da MV o seu Home Server.
Observar que se se apaga un host, neste caso xen01, que contén MVs asignadas a el, estas pasan ao Pool, para que poidan ser iniciadas en calquera outro servidor.

Segundo as configuracións dos servidores (RAM, Potencia CPU, Interfaces de rede, etc) ou a organización das MVs por funcións ou Sistemas Operativos, ás veces é aconsellable que cada MV teña o seu Home Server no cando de estar asignadas ao Pool.

Crear MVs

Imos simular que se crea unha MV, pois ao final cancelaremos o proceso.

Crear MVs
Crearemos unha MV chamada discsi. Creada a partir de plantilla dBase ...
Non deixa que a MV sexa creada como do Pool. Isto é porque no template estaba asignada a un host e non ao Pool.
Poderíamos asignar un tamaño de Memoria.
Poderíamos crear o VDI nun SR conectado á NAS como o iSCSI.
Asignarlle un VIF conectado á rede Tráfico MVs... Agora cancelamos o proceso, pois a creación da MV sería igual aos métodos xa vistos antes.
Se creásemos unha MV a partir dunha plantilla do Sistema ou dun template creado por nós que estaba asignado ao Pool, entón si que deixa crear a MV asignándoa ao Pool.

A Rede no Pool

As redes que se creen/borren/modifiquen nun host vanse crear no Pool, isto é, nos outros membros do pool vaise replicar esa configuración.

Crear/Borrar unha rede
P.e. imos crear unha Rede Privada Single-Server en xen01.
Rede creada en xen01.
Observar a rede na lapela Networking do Pool ...
... ou no outro host, xen00. Dende aquí borrala: seleccionar a rede premer en Remove.

Apagar o Pool

Para apagar o Pool, o apagado limpo implica apagar primeiro os membros do Pool e logo o Master

Apagar o Pool
Apagar xen01 e logo xen00.
Pool apagado.

Pool Heteroxéneo

O escenario anterior está moi completo (Distintas Redes, SRs e MVs), como para forzalo a estar nun Pool heteroxéneo.
Para esta ocasión imos crear un novo host xen02 en VirtualBox e tratar de unilo ao Pool no que o host real xenA é o Master.
Vaise usar unha soa NIC para todo tipo de tráfico (Xestión, Almacenamento e MVs).
Nun Pool heteroxéneo, pode ser que a migración de MVs entre os hosts (XenMotion) cause estados de erro na MV a migrar.
Nos Pools heteroxéneos o que se fai é aplicar unhas máscaras á CPU para que os Hosts que forman parte del usen aquelas características mínimas que comparten.
Para iso a CPU debe contemplar a posibilidade de aplicar unha máscara, como se intentará máis adiante.
Cando estamos ante hosts con distintas CPUs pero cuxas CPUs poden ser "enmascaradas" entón Xencenter ou xsconsole, vai advertir desa circunstancia pero vai introducir o host no Pool e XenServer xa aplica as máscaras ás CPUS.
Normalmente as CPUs que permiten ser "enmascaradas" son as destinadas para os servidores: http://hcl.xensource.com/CPUMatrix.aspx

No noso caso, neste curso, é probable que non traballemos con servidores reais, senón con PCs que actúan como servidores, por tanto o que imos facer é forzar que un host forme parte dun Pool heteroxéneo aínda que non poidan configurar as CPUs cunhas características comúns mínimas.
Neste caso, o funcionamento pode ser impredictible, e incluso que non podamos realizar o pool·

O escenario 6.K amosa dun modo sinxelo como vai estar formado o Pool heteroxéneo forzado.

Configuración inicial dos hosts

Para este escenario pódese apagar xen00 e xen01.

Configuración dos hosts
Crear un novo host en VirtualBox: xen02.
Un só NIC en modo Ponte/Promíscuo
Un disco duns 100 GB.
Configuración IP de xenA: X.Y.Z.150
Configuración IP de xen02:X.Y.Z.202.
Lembrar actualizalo.

Crear Pool Heteroxéneo

Lembramos de novo: actualizar xen02 e reinicialo.

Crear Pool
Novo Pool
Indica que o HW de xen02 non coincide co do Master xenA. Creamos o Pool igualmente só con xenA
Vemos o Pool creado con so un host e xen02 está fóra do Pool.
En xsconsole de xen02 ir a Resource Pool Configuration.
Tratamos de unilo ao Pool ...
... de xenA
Pero como no caso anterior, non deixa.
Imos agora Forzar a Unión ao Pool.
Aviso de que pode que haxa incompatibilidades entre hosts.
Metemos os datos de xenA
E houbo éxito.
xen02 forma parte do Pool - Heteroxéneo.
Podemos eliminar a súa referencia de fóra do Pool do XenCenter.

Engadir un host heteroxéneo a un Pool usando CLI xe

Agora imos facer o mesmo pero usando o CLI xe.

Localizar as características da CPU do Máster do Pool: xenA:

xe host-get-cpu-features
#
# O resultado de executar o comando anterior é algo semellante a: 77dafbbf-bfebfbff-00000021-2c100800

No novo servidor(xen02) executar o comando que lle indica ás funcionalidades a usar da CPU en función das dispoñibles no Máster. Copiar o resultado de executar a instrución anterior e pegalo na seguinte:

xe host-set-cpu-features features=<funcionalidades do máster do pool>

Habería que reiniciar o novo servidor (xen02), se se lle aplicara realmente a máscara da CPU, pero non vai ser así.
Por tanto imos pasar directamente á seguinte instrución para meter xen02 no Pool pero forzando: engadir a opción force=true.

Meter o servidor no pool:

xe pool-join master-address=<IP host1> master-username=root master-password=<password>

Se se queren restablecer as funcionalidades da CPU dun servidor:

xe host-reset-cpu-features

No enlace hai máis información sobre os Pools Heteroxéneos: http://support.citrix.com/article/CTX127059

Engadir SRs

No caso anterior (Pool-Homoxéneo) creamos o Pool despois de que o Master xa tiña creados varios SRs.
Nesta ocasión imos crear un SR NFS VHD despois de crear o Pool.

Engadir SR
Engadir un SR NFS VHD, poñerlle un nome, neste caso: Almacenamento VDIs (NAS / NFS)
Engadir o mesmo recurso NFS da NAS que no caso anterior: NFS_VDIs.
Só que neste caso imos conectarnos a través da IP do primeiro interface da NAS: X.Y.Z.100.
Observar como amosa os dous SRs creados en escenarios anteriores.
Poderíamos usalos, pero imos crear un novo.
Recurso SR creado para o Pool e posto xa como por defecto para os VDIs das vindeiras MVs.
Configuración do SR.
Notar que xa hai 1,5 GB ocupados, son dos VDIs dalgunhas MVs do Pool Homoxéneo.

Operacións con MVs

Pódense realizar as mesmas operacións con MVs que non Pool Homoxéneo, salvo a Migración que pode causar problemas á MV Migrada.
Neste exemplo do material si que funcionou, pero ...

Operacións con MVs
Creamos unha MV urouter para o Pool. Podemos facelo de varias formas:
-Clonar a MV ubase e realizar Storage XenMotion para mover o disco (VDI) de urouter para o SR NFS VHD asociado á NAS.
-Clonar ubase e no momento da copia indicar que o VDI se almacene no SR NFS VHD.
-Crear unha MV dende cero.
-En calquera caso, fixarse que a MV ten instaladas as XenServer Tools e está actualizada.
-Poñer o nome adecuado usrouter e non asignala a ningún host.
Acendemos urouter en xen02, abrimos un ping 8.8.8.8
Migrámola a xenA con éxito. Cero pings perdidos.

Alta dispoñibilidade. Hight Availability (HA)

Cando se configura un Pool, a nova versión 6.2 incorpora a función de Alta Dispoñibilidade (HA)
Grazas a HA se falla un host as MVs que se están executando nese host poden apagarse e iniciarse noutro host do Pool en función de:
- Como estean configuradas esas MVs en caso de caída de algún dos hosts do Pool.
- Se esas MVs teñen ou non os VDIs nun SR compartido do Pool.
- Como estean de libres os recursos nos outros hosts do Pool, nos que hai que iniciar MVs que estaban no host que tivo problemas.

HA é usado para asegurarse de que as MVs importantes están sempre funcionando aínda que teña problemas o host no que se están executando.

Se quen falla é o Master do Pool, a función HA elixe automaticamente outro servidor do Pool para que faga de Mestre, co cal podemos seguir administrando o Pool. Se non tivéramos HA e o servidor que falla é o mestre, entón perderíamos o Pool.
- Para iso a BBDD do Pool está continuamente replicándose entre os membros do Pool e ao mesmo tempo gárdase unha copia nun SR externo (iSCISI, NFS, etc), que se coñece como SR heartbeat.

A función HA o primeiro que se ten que asegurar é que se estamos ante un verdadeiro fallo ou que o servidor desapareceu por un instante. Pensar que:
- Hai varios tipos de conexións de rede: Xestión, Tráfico MVs, Almacenamento, e calquera podería fallar.
- Hai SR externos: e poden caer os camiños, o servidor, a NAS, atc.
Por iso, Xenserver recomenda:
- Que se use bonding para o tráfico de Xestión e MVs
- Que se use Multipath (verase no seguinte apartado) para o almacenamento, incluído o SR compartido para que funcione o SR Heartbeat.
A función HA crea no almacenamento compartido SR Heartbeat 2 discos/volumes:
- Volume heartbeating de 4 MB: (Pulso, ou latido do corazón), onde cada host está informando de que está OK e das MVs que está executando, e onde a función HA está comprobando o estado de cada host.
- Volume de metadatos 256 MB: onde se garda información do mestre do Pool, por se este falla.

Cando se detecta que un host (ou un conxunto deles) ten un fallo (de rede ou de almacenamento):
- Reiníciase ese host porque:
  - Se ese host era o Master e volvera a estar operativo teríamos un Pool con un comportamento impredictible ao ter dous masters.
  - Se ese host estaba escribindo en almacenamento compartido e volvera a estar operativo poderíamos ter inconsistencias, por iso se reinicia.
- Apáganse as MVs que contiña ese host
- Reinícianse aquelas MVs que contiña ese host en función de:
  - se tiñan configurada unha política de Reinicio
  - e se hai recursos no resto do Pool para inicialas.
  - Na función HA hai que indicar que MVs se van reiniciar ante un posible fallo e en que orde (Algo como o vApp).

IMPORTANTE
- Débese deshabilitar a función HA cando se vaian realizar operacións no Pool ou nos hosts (salvo crear MVs).
- Porque, se por exemplo, se lle cambia unha IP a un host, a función HA vai detectar que ese host está en problemas e vaino reiniciar.

O Escenario 6.L amosa as probas que imos realizar

Aproveitamos o escenario do Pool-Heteroxéneo por ser moi simple.
Todo tráfico (Xestión, Rede e Almacenamento) vai polo mesmo NIC, cando en realidade non debera ser así.
Non hai bonding nin multipath. Debera habelo, pois por exemplo, se falla un camiño, sempre nos quedan o outro/s e non se lanza a función HA a apagar o host/s afectado e as súas MVs
O almacenamento para o SR heartbeating (onde se van crear os 2 volumes) debera ser un Recurso Compartido usado unicamente para esa misión, a través de iSCSI e usando muiltipath.
- Neste caso, para simplificar, imos aproveitar o almacenamento NFS_VDIs, para almacenar o SR Heartbeating e así dun xeito rápido poder ver os 2 volumes creados.
Imos desconectar o cable de xenA, Master, e veremos que pasa con ese rol e coa MV urouter que estaba executando.

Habilitar e configurar HA

A Continuación vaise habilitar e configurar a función HA no Pool Heteroxéneo.

Habilitar e configurar HA
Na lapela HA do Pool ...
... premer en Configure HA...
A pantalla Prerequisitos ...
... indica que para configurar HA debemos ter
- Un SR compartido (para o HeartBeating)
- e as MVs que van ser protexidas con HA deben ser agiles, isto é, deben ter os seus VDIs nun SR compartido.
Na seguinte pantalla ...
... eliximos o almacenamento compartido para HeartBeating, que se vai usar para crear os dous volumes de disco (heartbeating e metadatos).
Na seguinte pantalla ...
... é onde podemos configurar o Plan de HA.
Vemos as MVs:
- A prioridade de reinicio
- En que orde se debe reiniciar cada MV que participe no Plan.
- Os segundos que deben pasar para que unha MV se inicie tras iniciarse unha outra calquera
- Se a MV usa VDIs agiles (VDIs nun SR compartido). Observar como só urouter ten esa propiedade a Yes.
Dentro das políticas de reinicio que lle podemos asignar a unha MV, están:
Reiniciar: é o nivel máis alto de prioridade e iniciaranse as MVs por orde inicio (primeiro as de orde 0, logo as de orde 1, ...
Reiniciala se é posible: se tras iniciar as MVs configuradas con Reinicio hai recursos no Pool entón inícianse as MVs configuradas con esta prioridade.
Non reiniciala: en caso de que falle o host no que se está executando non sei vai facer nada con esa MV.
Cando configuramos unha MV como Restart é cando se aplican os límites que nos podemos permitir de fallos dos servidores. Neste caso como só temos 2 servidores, se nos falla un xa non temos máis posibilidades de que nos falle o segundo e sigamos co Pool.
Este límite ben marcado polo número de servidores, a súa RAM, as MVs configuradas como restart, a RAM que consumen esas MVs, etc.
Observar como cando configuramos a MV como Restart if possible o ńumero máximo de fallos permitidos pasa a ser 2, pois esa MV non é unha das importantes para nós, aínda que fallen os dous servidores non pasaría nada porque esa MV se perdese, pois non é crítica.
Tamén podemos indicar a orde en que se van iniciar as MVs e cantos segundos deben esperar as MVs do seguinte nivel para ser iniciadas.
A modo de exemplo configurouse o que se amosa no exemplo: wsprinter debería espera 30 seg a acenderse despois de que se inicie urouter.
Volvemos a deixar a configuración como se amosa na imaxe e imos ver que pasa.
Na seguinte pantalla ...
... temos un resumo final da configuración HA. Finalizamos a configuración.
Na lapela Log do Pool, vemos que leva o seu tempo activar a función HA.
Na lapela HA do Pool ...
... podemos ver o estado da rede e dos almacenamentos SR compartidos. Se os hosts teñen Conectividade e ademais se chegan ao Almacenamento.
No recurso NFS_VDIs da NAS, na carpeta correspondente a este SR, podemos ver 3 ficheiros:
O VDI da MV urouter.
O ficheiro raw asociado co volume de metadatos do Pool (256 MB).
O ficheiro raw asociado co volume de heartbeating do Pool (260 KB, menos dos 4 MB estimados).
Nas propiedades do Pool, poderíase configurar unha conta de mail na que recibir as alertas, entre elas as que pode enviar a función HA.

Experimentar con HA

A continuación vaise desconectar o cable de rede de xenA (master) e veremos que pasa.
Finalmente volverase a conectar o cable de rede de xenA, e veremos se segue sendo o Mestre.

Practicar con HA
Inciar urouter en xenA
Na consola de urouter lanzar un un ping 8.8.8.8.
Desconectar o cable de rede de xenA. O Pool cáese inicialmente.
Non pode atopar o master.
O pool comeza a recuperarse, pero ...
... xenA está caído. Observar como urouter está iniciado en xen02.
Pero ... urouter non está realizando o ping que deixáramos facendo antes de caer xenA.
urouter foi apagado e iniciado noutro host do Pool. Por iso, está na pantalla de inicio de sesión.
Na lapela HA do Pool, vemos ...
o estado de accesibilidade aos hosts e aos SRs compartidos.
Nas alertas podemos ver que agora xen02 asumiu o mando, é o Mestre.
Perante este proceso a función HA reiniciou o servidor xenA.
E este é o estado no que se atopa ...
... non temos rede.
Pero se volvemos a conectar o cable de rede de xenA, este recupera a súa configuración IP.
Na lapela HA vemos que todo xa está de novo OK.
Observar que xenA está operativo
Pero agora o mestre é xen02 e ...
... xenA non recuperou o seu rol inicial.