Ver el código de «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'''.

[[Image:Sv_2013_network_107.jpg|500px]]

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


[[Image:Sv_2013_network_119.jpg|600px]]

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

<gallery caption="Configuración xen01" widths="350" heights="250px" perrow="2">
Sv_2013_pool_01.jpg|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'''.
Sv_2013_pool_02.jpg|Segundo (Ponte/Promiscuo) ...
Sv_2013_pool_03.jpg|Terceiro en modo Rede Interna
Sv_2013_pool_07A.jpg|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.
Sv_2013_pool_07B.jpg|Nesta ocasión imos actualizar facendo uso da consola do host, ben dende XenCenter ou a través dun ssh.<br>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)
Sv_2013_pool_07C.jpg|Unha vez que temos o ficheiro no host, por calquera dos dous métodos anteriores:<br>Descomprimímolo ('''unzip ...'''). Axudarse da tecla TAB.<br>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 ...<br>Aplicamos o parche co comando '''xe patch-pool-apply ...'''. Pois cada servidor independente é o mestre do seu Pool (Pool por defecto).  
Sv_2013_pool_07D.jpg|Agora seguimos facendo o mesmo co resto das actualizacións que hai que aplicar e finalmente reiniciamos o servidor dende a consola (init 6).
Sv_2013_pool_07E.jpg|Servidor xen01 actualizado.
Sv_2013_pool_08.jpg|Observar Memoria RAM.
Sv_2013_pool_09.jpg|Os tres NICs
Sv_2013_pool_10.jpg|As tres redes cos nomes por defecto e o '''Management Interface''' configurado coa IP '''X.Y.Z.201'''.<br>Non se precisa configurar nada máis en xen01.
</gallery>

===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
[[Image:00_Servizos_Virtualizacion_Escenarios_Semana_06_J.jpg|500px]]

*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. 
[[Image:00_Servizos_Virtualizacion_Escenarios_Semana_06_J_BIS.jpg|500px]]



<gallery caption="Crear Pool" widths="350" heights="250px" perrow="2">
Sv_2013_vds_84.jpg|Lembrar como está configurado xen00 dos escenarios anteriores: ...
Sv_2013_network_99.jpg|Varias redes:<br>Interna<br>Xestión<br>Tráfico MVs<br>Almacenamento
Sv_2013_pool_07.jpg|Tres NICs.
Sv_2013_pool_11.jpg|Seis SRs:<br>'''Almacenamento VDIs''': contra a NAS (iSCSI e NFS)<br>'''Backup''': contra a NAS (CIFS e NFS)<br>'''Imaxes ISOs''': (contra un PC(CIFS) e contra a NAS (NFS)).
Sv_2013_pool_12.jpg|Crear un '''novo Pool'''
Sv_2013_pool_13.jpg|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 ...
Sv_2013_pool_16.jpg|Unha vez solventadas as diferencias entre os hosts ... Crear un Pool con nome: '''Pool - Homoxéneo'''. 
Sv_2013_pool_17.jpg|Proceso de creación do Pool, '''xen01''' está en modo OFF mentres comeza a iniciarse
Sv_2013_pool_17B.jpg|Pasa a modo '''Mantemento''' mentres '''herda''' a configuración de '''xen00'''.
Sv_2013_pool_18A.jpg|'''xen01''' xa está activo. Vemos que os SR externos, os compartidos, pertencen ao Pool e non a ningún host en concreto.<br>Pero 3 deles, os que van contra a NAS, non están activos, por que será?. Pronto o arranxaremos.<br>Observar que os SRs '''Backup''' está conectados, lembrar que ...
Sv_2014_network_105A.jpg|... iso é porque non están conectados á NAS a través da rede de '''Almacenamento (NIC2)''' senón pola rede de '''Xestión (NIC0)'''.<br>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).
Sv_2013_pool_20.jpg|Revisemos características do Pool: As MVs que te cada un ...
Sv_2013_pool_21.jpg|A Memoria de cada host ...
Sv_2013_pool_22.jpg|Os SR
Sv_2013_pool_24.jpg|A rede?.<br>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) ...
Sv_2013_pool_25.jpg|Se tratamos de reparar un do SR compartidos ...
Sv_2013_pool_26.jpg|Non imos ter éxito, pois dende xen01 non hai un camiño para chegar ao almacenamento da NAS.
Sv_2013_pool_27.jpg|En '''xen01''' imos engadir unha configuración IP sobre a rede '''Almacenamento'''
Sv_2013_pool_28.jpg|Premer en '''Add IP Address'''.<br>Poñer un nome á configuración IP.<br>Indicar que é sobre a rede '''Almacenamento''' para poder chegar á NAS <br>e realizar a configuración IP: '''172.16.0.201/24''' 
Sv_2013_pool_32.jpg|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.
Sv_2013_pool_25.jpg|Agora xa podemos reparar os SRs
Sv_2013_pool_30.jpg|SR reparado. Observar como hai conexión dende os 2 hosts ao mesmo SR.
Sv_2013_pool_33.jpg|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!!!.
</gallery>

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


<gallery caption="Operacións con MVs" widths="350" heights="250px" perrow="2">
Sv_2013_pool_33A.jpg|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.
Sv_2013_pool_34.jpg|Á 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.<br>'''Pero''' non podemos iniciala en xen01, porque non hai suficiente espazo no servidor... 
Sv_2013_pool_34A.jpg|Para iso axustamos a memoria de '''dnfs''' a 128 MB, ben fixos ou ben dinámicos. 
Sv_2013_pool_35.jpg|Agora xa podemos indicar que se inicie en xen01 a MV que está en xen00. 
Sv_2013_pool_36.jpg|Isto é posible xa que os membros do Pool comparten o SR: '''Almacenamento VDIs (NAS / NFS)'''
Sv_2013_pool_36A.jpg|Vemos que a MV está iniciada en xen01.<br>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). 
Sv_2013_pool_37.jpg|Arrancamos un '''ping 8.8.8.8''' na consola da MV '''dnfs''' ...
Sv_2013_pool_38.jpg|... porque imos migrala en quente á xen00. Esta operación tamén se pode realizar '''arrastrando''' a MV dun host ao outro. 
Sv_2013_pool_39.jpg|A MV está migrándose, esta funcionalidade coñécese con nome de '''XenMotion'''.<br>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.
Sv_2013_pool_40.jpg|A MV está migrada, cortouse o ping e vese que non se perdeu ningún deles.
Sv_2013_pool_40A.jpg|A lapela '''Log''' da MV onde indica o tempo que levou a migración de xen01 a xen00.
</gallery>

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

 
<gallery caption="Inicio das MVs" widths="350" heights="250px" perrow="2">
Sv_2013_pool_41.jpg|Apagar '''dnfs'''. Imos ver como configurar en que host se debe iniciar por defecto. Seleccionar a MV '''dnfs''' e premer en '''Propiedades'''.
Sv_2013_pool_42.jpg|Seleccionar a opción '''Home Server'''.<br>A MV '''dnfs''' está asignada ao host '''xen00''', para que se inicie nel (Observar que ese host só ten 2 GB de RAM), pero ...
Sv_2013_pool_43.jpg|... podemos indicarlle que non a asigne o inicio desa MV a ningún host, senón ao Pool. 
Sv_2013_pool_44.jpg|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.
Sv_2013_pool_45.jpg|Nesta ocasión iniciáronse varias MVs en '''xen00''', co cal, xa non admite máis.
Sv_2013_pool_45A.jpg|Observar a memoria do Pool dos hots xen00 (2GB) e de xen01 (1GB).
Sv_2013_pool_45B.jpg|Agora cando lle indicamos á MV '''dnfs''' que se inicie, esta non ten outra opción que escoller o host xen01 para executarse.
Sv_2013_pool_45C.jpg|Aquí vemos '''dnfs''' executándose en xen01.
Sv_2013_pool_45D.jpg|Se se desexa pódese indicar que o '''Home server''' para unha MV sexa distinto daquel no que foi creada.<br>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.
Sv_2013_pool_45E.jpg|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.
</gallery>


*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.
<gallery caption="Crear MVs" widths="350" heights="250px" perrow="2">
Sv_2013_pool_49.jpg|Crearemos unha MV chamada '''discsi'''. Creada a partir de '''plantilla dBase''' ... 
Sv_2013_pool_50.jpg|Non deixa que a MV sexa creada como do Pool. Isto é porque no template estaba asignada a un host e non ao Pool.
Sv_2013_pool_51.jpg|Poderíamos asignar un tamaño de Memoria.
Sv_2013_pool_52.jpg|Poderíamos crear o VDI nun SR conectado á NAS como o iSCSI.
Sv_2013_pool_53.jpg|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.
Sv_2013_pool_54.jpg|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.
</gallery>

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

<gallery caption="Crear/Borrar unha rede" widths="350" heights="250px" perrow="2">
Sv_2013_pool_46.jpg|P.e. imos crear unha Rede Privada Single-Server en xen01.
Sv_2013_pool_47.jpg|Rede creada en xen01.
Sv_2013_pool_47A.jpg|Observar a rede na lapela '''Networking''' do Pool ...
Sv_2013_pool_48.jpg| ... ou no outro host, xen00. Dende aquí borrala: seleccionar a rede premer en '''Remove'''.
</gallery>

===Apagar o Pool===
*Para apagar o Pool, o apagado limpo implica apagar primeiro os membros do Pool e logo o Master
<gallery caption="Apagar o Pool" widths="350" heights="250px" perrow="2">
Sv_2013_pool_55.jpg|Apagar xen01 e logo xen00.
Sv_2013_pool_56.jpg|Pool apagado.
</gallery>

==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.
[[Image:00_Servizos_Virtualizacion_Escenarios_Semana_06_K.jpg|500px]]

===Configuración inicial dos hosts===
*Para este escenario pódese apagar xen00 e xen01. 
<gallery caption="Configuración dos hosts" widths="350" heights="250px" perrow="2">
Sv_2013_pool_65.jpg|Crear un novo host en VirtualBox: '''xen02'''.<br> Un só NIC en modo Ponte/Promíscuo<br>Un disco duns 100 GB.
Sv_2013_pool_66.jpg|Configuración IP de '''xenA''': X.Y.Z.150
Sv_2013_pool_67.jpg|Configuración IP de '''xen02''':X.Y.Z.202.<br>'''Lembrar actualizalo'''.
</gallery>

===Crear Pool Heteroxéneo===
*Lembramos de novo: actualizar '''xen02''' e reinicialo.

<gallery caption="Crear Pool" widths="350" heights="250px" perrow="2">
Sv_2013_pool_68.jpg|Novo Pool
Sv_2013_pool_69.jpg|Indica que o HW de '''xen02''' non coincide co do Master '''xenA'''. Creamos o Pool igualmente só con xenA
Sv_2013_pool_70.jpg|Vemos o Pool creado con so un host e xen02 está fóra do Pool.
Sv_2013_pool_71.jpg|En '''xsconsole''' de xen02 ir a '''Resource Pool Configuration'''.
Sv_2013_pool_72.jpg|Tratamos de unilo ao Pool ...
Sv_2013_pool_73.jpg|... de xenA
Sv_2013_pool_75.jpg|Pero como no caso anterior, non deixa.
Sv_2013_pool_76.jpg|Imos agora Forzar a Unión ao Pool.
Sv_2013_pool_77.jpg|Aviso de que pode que haxa incompatibilidades entre hosts.
Sv_2013_pool_78.jpg|Metemos os datos de xenA
Sv_2013_pool_80.jpg|E houbo éxito.
Sv_2013_pool_81.jpg|'''xen02''' forma parte do '''Pool - Heteroxéneo'''.
Sv_2013_pool_82.jpg|Podemos eliminar a súa referencia de fóra do Pool do XenCenter.
</gallery>

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

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

===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 ...
<gallery caption="Operacións con MVs" widths="350" heights="250px" perrow="2">
Sv_2013_pool_85.jpg|Creamos unha MV '''urouter''' para o Pool. Podemos facelo de varias formas:<br>-'''Clonar''' a MV '''ubase''' e realizar '''Storage XenMotion''' para mover o disco (VDI) de '''urouter''' para o SR NFS VHD asociado á NAS.<br>-Clonar '''ubase''' e no momento da copia indicar que o VDI se almacene no SR NFS VHD.<br>-Crear unha MV dende cero.<br>-En calquera caso, fixarse que a MV ten instaladas as '''XenServer Tools''' e está actualizada.<br>-Poñer o nome adecuado '''usrouter''' e non asignala a ningún host.
Sv_2013_pool_86.jpg|Acendemos '''urouter''' en '''xen02''', abrimos un '''ping 8.8.8.8'''
Sv_2013_pool_87.jpg|Migrámola a '''xenA''' con éxito. Cero pings perdidos.
</gallery>

==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
[[Image:00_Servizos_Virtualizacion_Escenarios_Semana_06_L.jpg|500px]]
*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.


<gallery caption="Habilitar e configurar HA" widths="350" heights="250px" perrow="2">
Sv_2014_ha_01.jpg|Na lapela '''HA''' do Pool ...
Sv_2014_ha_02.jpg|... premer en '''Configure HA...'''
Sv_2014_ha_03.jpg|A pantalla '''Prerequisitos''' ...
Sv_2014_ha_04.jpg|... indica que para configurar HA debemos ter<br>- Un SR compartido (para o HeartBeating)<br>- e as MVs que van ser protexidas con HA deben ser '''agiles''', isto é, deben ter os seus VDIs nun SR compartido.
Sv_2014_ha_05.jpg| Na seguinte pantalla ...
Sv_2014_ha_06.jpg| ... eliximos o almacenamento compartido para HeartBeating, que se vai usar para crear os dous volumes de disco (heartbeating e metadatos).<br>Na seguinte pantalla ...
Sv_2014_ha_07.jpg|... é onde podemos configurar o '''Plan de HA'''. 
Sv_2014_ha_08.jpg|Vemos as MVs:<br>- A '''prioridade de reinicio'''<br>- En que '''orde''' se debe reiniciar cada MV que participe no Plan.<br>- Os '''segundos''' que deben pasar para que unha MV se inicie tras iniciarse unha outra calquera<br>- Se a MV usa VDIs '''agiles''' (VDIs nun SR compartido). Observar como só '''urouter''' ten esa propiedade a '''Yes'''.
Sv_2014_ha_09.jpg|Dentro das políticas de reinicio que lle podemos asignar a unha MV, están:<br>'''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, ... <br>'''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.<br>'''Non reiniciala''': en caso de que falle o host no que se está executando non sei vai facer nada con esa MV.
Sv_2014_ha_10.jpg|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.<br>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.
Sv_2014_ha_11.jpg|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.
Sv_2014_ha_12.jpg|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.
Sv_2014_ha_13.jpg|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'''.
Sv_2014_ha_14.jpg|Volvemos a deixar a configuración como se amosa na imaxe e imos ver que pasa.<br>Na seguinte pantalla ...
Sv_2014_ha_15.jpg|... temos un resumo final da configuración HA. Finalizamos a configuración.
Sv_2014_ha_16.jpg|Na lapela '''Log''' do Pool, vemos que leva o seu tempo activar a función HA.
Sv_2014_ha_17.jpg|Na lapela '''HA''' do Pool ...
Sv_2014_ha_18.jpg|... podemos ver o estado da rede e dos almacenamentos SR compartidos. Se os hosts teñen Conectividade e ademais se chegan ao Almacenamento.
Sv_2014_ha_39.jpg|No recurso NFS_VDIs da NAS, na carpeta correspondente a este SR, podemos ver 3 ficheiros:<br>O VDI da MV urouter.<br>O ficheiro '''raw''' asociado co volume de metadatos do Pool (256 MB).<br>O ficheiro '''raw''' asociado co volume de '''heartbeating''' do Pool (260 KB, menos dos 4 MB estimados).
Sv_2014_ha_32.jpg|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.
</gallery>

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

<gallery caption="Practicar con HA" widths="350" heights="250px" perrow="2">
Sv_2014_ha_19.jpg|Inciar '''urouter''' en '''xenA'''
Sv_2014_ha_20.jpg|Na consola de '''urouter''' lanzar un un '''ping 8.8.8.8'''.
Sv_2014_ha_22.jpg|Desconectar o cable de rede de xenA. O Pool cáese inicialmente. 
Sv_2014_ha_21.jpg|Non pode atopar o master.
Sv_2014_ha_23.jpg|O pool comeza a recuperarse, pero ...
Sv_2014_ha_25.jpg|... '''xenA''' está caído. Observar como '''urouter''' está iniciado en '''xen02'''.
Sv_2014_ha_26.jpg|Pero ... '''urouter''' non está realizando o ping que deixáramos facendo antes de caer '''xenA'''.<br>'''urouter''' foi apagado e iniciado noutro host do Pool. Por iso, está na pantalla de inicio de sesión.
Sv_2014_ha_28.jpg|Na lapela '''HA''' do Pool, vemos ...
Sv_2014_ha_27.jpg|o estado de accesibilidade aos hosts e aos SRs compartidos.
Sv_2014_ha_29.jpg|Nas alertas podemos ver que agora '''xen02''' asumiu o mando, é o '''Mestre'''.
Sv_2014_ha_36.jpg|Perante este proceso a función HA '''reiniciou''' o servidor '''xenA'''.
Sv_2014_ha_37.jpg|E este é o estado no que se atopa ...
Sv_2014_ha_38.jpg|... non temos rede.
Sv_2014_ha_40.jpg|Pero se volvemos a '''conectar''' o cable de rede de '''xenA''', este recupera a súa configuración IP.
Sv_2014_ha_30.jpg|Na lapela '''HA''' vemos que todo xa está de novo OK.
Sv_2014_ha_31.jpg|Observar que '''xenA''' está operativo 
Sv_2014_ha_33.jpg|Pero agora o '''mestre''' é '''xen02''' e ... 
Sv_2014_ha_34.jpg|... '''xenA''' non recuperou o seu rol inicial.
</gallery>

===Deshabilitar HA===
*Ao deshabilitar HA gárdase a política de reinicios de MVs, por se no futuro desexamos volver activar a función HA poder recuperar esa configuración.
<gallery caption="Deshabilitar HA" widths="350" heights="250px" perrow="2">
Sv_2014_ha_41.jpg| Na lapela '''HA''' do Pool, premer en '''Disable HA...'''
Sv_2014_ha_42.jpg| Premer en '''Yes''' e así imos deixar a función HA para os vindeiros escenarios.
</gallery>





<br> -- [[Usuario:Antonio|Antonio de Andrés Lema]] e [[Usuario:Carrion|Carlos Carrión Álvarez]] (Maio-2013, Rev1: Feb 2014 - Rev2: Nov 2014)