Diferencia entre revisiones de «Pool de servidores: Homoxéneos, Heteroxéneos. XenMotion. Alta dispoñibilidade (HA)»

De Manuais Informática - IES San Clemente.
Ir a la navegación Ir a la búsqueda
(Alta dispoñibilidade. Hight Availability (HA))
 
(Sin diferencias)

Revisión actual del 23:14 4 dic 2016

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.

Sv 2013 network 107.jpg

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


Sv 2013 network 119.jpg

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.

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

00 Servizos Virtualizacion Escenarios Semana 06 J.jpg

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

00 Servizos Virtualizacion Escenarios Semana 06 J BIS.jpg


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.


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.



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

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.

Apagar o Pool

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

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.

00 Servizos Virtualizacion Escenarios Semana 06 K.jpg

Configuración inicial dos hosts

  • Para este escenario pódese apagar xen00 e xen01.

Crear Pool Heteroxéneo

  • Lembramos de novo: actualizar xen02 e reinicialo.

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

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.

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

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

00 Servizos Virtualizacion Escenarios Semana 06 L.jpg

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


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.

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.




-- Antonio de Andrés Lema e Carlos Carrión Álvarez (Maio-2013, Rev1: Feb 2014 - Rev2: Nov 2014)