fev 17, 2016
marllus

Backup no XenServer 6.5

E aí, tudo certinho?

Bem, hoje o tutorial será sobre backup!

Tão falado, mas tão pouco usado, o backup no XenServer parece ser complicado, mas é mais simples do que se imagina.

Primeiro, existem três níveis de backup no XenServer:

Pool: Esse backup guarda informações a respeito do pool, ou seja, o arquivo gerado por esse backup geralmente é bem pequeno e contém informações a respeito de quais Vms estão em cada host do pool, quantas NICs e quais os Ips dessas NICs, se tem VLAN configurada e quais os storages conectados a ele. Se você “crashar” um pool e ele se perder, esse aquivo permite você criar outro pool idêntico novamente.

Host: Esse backup geralmente é bem grande e contém os dados escritos no disco local do host xen. Não é recomendado você guardar este backup dentro do próprio host, pois o mesmo é bem grande (dependendo da quantidade de dados escritos no disco local do próprio host). Esse backup é interessante quanto se quer ter a instalação do XenServer com todos os patches, updates e alterações em arquivos em diretórios do SO Dom0, ou seja, quando se quer ter o mesmo host xen idêntico ao que era antes, sem maiores trabalhos. A desvantagem disso é que o arquivo gerado será bem maior que um backup de pool.

VM: Esse é o backup quando se quer tirar uma cópia/clone de uma VM. Geralmente se utiliza esse backup quando se quer guardar uma VM completa para ser importada em outro ambiente xenserver ou guardá-la para futuros backups. A vantagem desse procedimento é que, se você quiser uma VM consistente, terá que realizar um backup em um intervalo bem pequeno de tempo. Muitos administradores realizam esse tipo de backup uma vez no ciclo de vida de uma VM e, ao longo do tempo, vai realizando backup do SO (Bacula, por exemplo).

O ideal é se planejar um backup utilizando todos esses níveis, para compor uma solução onde eu tenho tanto a agilidade de recuperação de uma VM, de um host e de um pool. Porém, muitas vezes por falta de recursos disponíveis (lê-se: espaço de armazenamento), elaboramos abordagens que se focam mais em backups de pool e Vms, pois a partir desses dois, pode se construir novamente um pool falhado. A janela de recuperação, nesse caso, será um pouco menor, mas, dependendo do nível de criticidade do ambiente, tende a ser aceitável.

As possibilidades são inúmeras e se diferenciam para cada ambiente. O “know-how” do backup é definir o planejamento dele. Após isso, só passo-a-passo.
Para compor sua solução open source de backup, sugiro pesquisar sobre o software Bacula: http://blog.bacula.org/about-bacula/what-is-bacula/

Os procedimentos para realização dos diversos tipos de backup no Xenserver está disponível na documentação oficial, a qual se encontra aqui:
http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html#backups

Abraços e espero que tenham gostado da explicação sobre os níveis de backup existentes no Xenserver!

Referências:
http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html#backups
http://blog.bacula.org/about-bacula/what-is-bacula/

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

P2V / V2V – Conversão de ambientes – XenServer 6.5

Olá, tudo bem?

Hoje falarei sobre P2V e V2V de sistemas operacionais.

Bem, P2V e V2V são termos que remetem à migração de sistemas. E migração (desde antes de cristo – 40 anos de migração dos hebreus a Canaã rs) é um processo doloroso e às vezes dispendioso (de tempo e recursos físicos).

P2V (Physical to Virtual): É usado quando você quer transformar uma máquina física para virtual (Migração de um PC ou notebook para um virtualizador – ex. Xenserver);

V2V (Virtual to Virtual): É usada quando você quer transformar uma máquina virtual em outra virtual (geralmente quando se vai migrar Vms entre Virtualizadores distintos – ex.Vmware->Xenserver)

Bem, em meus tutoriais gosto sempre de explicar o “estado da arte” ou o “alicerce” para construção de seu próprio conhecimento através de informações precisas e minuciosas do ponto estudado. Na minha cabeça, somente um how-to passo-a-passo, sem os porquês, torna-se meramente um “cale a boca e siga-me”.
É por isso que, em quase todos os tutoriais que fiz, quando chego na parte da “mão na massa” posto links com os procedimentos. Se você consegue levantar questões a respeito do que queres fazer e planejar as soluções para tal, até um robô fará o passo a passo.

Te garanto que se sempre seguir este princípio, sua vida mudará, pois os porquês se tornarão cada vez mais frequentes. Lembre-se disso.

Bem, voltando, sem mais delongas, irei apresentar (em passos) como ocorre o processo de migração de uma máquina física ou virtual para uma VM no Xenserver 6.5. Estes procedimentos são genéricos. Os softwares utilizados para realizar as operações podem ser vários. No final, colocarei tutoriais para você seguir que citam ferramentas úteis para a realização dos procedimentos.

1. Criar uma imagem do disco rígido da máquina;
1.1. Neste passo, geralmente se inicia um cd/usb de boot de algum programa de backup (clonezilla, G4L, etc) na máquina e é copiado o disco rígido inteiro, gerando uma imagem no final do processo. Essa imagem deverá ser guardada.

2. Criar uma VM com as mesmas características de CPU, memória RAM, disco rígido e SO (caso tenha template para ela na lista de templates do XenServer – caso contrário utilizar o template other media install).
2.1. Esse passo é bem simples, só não instale nenhum SO na VM. Somente crie-a e deixe lá desligada.

3. Iniciar a VM por cd/usb de boot a partir do mesmo programa que fez backup da máquina de origem e restaurar essa imagem no novo disco que você acabou de criar para a VM.
3.1. Quando o processo de restauração concluir, geralmente ocorre de a VM não conseguir iniciar ainda, pois as informações do initrd/grub (caso a máquina seja GNU/Linux) ainda estão apontando para o kernel antigo.

Se a VM em questão não for GNU/Linux, então pule para o passo 5.

4. Atualizar imagem initrd, grub e caminhos dos discos no /etc/fstab
4.1. Nesta etapa, basicamente, você terá que montar todos os diretórios da VM em chroot a partir de um livecd/usb Linux e então criar uma nova imagem para o initrd.

5. Após isso, você terá uma VM funcional dentro do seu ambiente de virtualização Xenserver.

Somente esses 5 passos são necessários para a migração V2V ou P2V Windows/GNU/Linux onde o destino é o Xenserver 6.5

Passos adicionais são necessários para a otimização da VM, como a conversão da mesma de HVM para PV (modos de virtualização – se não sabe o que é isto clique aqui) e a instalação do xentools (drivers xen para Network/disco – se não sabe o que é clique aqui)

Bem, como falei, esses são os passos genéricos para se subir uma VM em um ambiente de virtualização Xenserver onde a origem era uma VM advinda de um outro sistema de virtualização ou de uma máquina física.

O PDF a seguir, originado de um colega (Germano Dias) da instituição onde trabalho (Universidade Federal do Ceará) irá embasar a parte prática de todas as informações que repassei neste fluxo. Nele é usado o software Clonezilla (GPL) para realizar o backup e restore dos discos.

Baixe aqui o PDF.

Outros tutoriais podem servir como complemento ou até alternativa para esse procedimento:

Tutorial usando o comando dd: http://www.lewan.com/blog/2011/04/14/p2v-conversion-of-linux-virtual-machine-for-xenserver
Outro tutorial usando o clonezilla: http://www.ibm.com/developerworks/br/library/l-clonezilla/
Você pode usar também o programa G4L Ghost 4 Linux para backup do disco (em alternativa ao clonezilla) e que vem no pacote Hiren’s bootCD 15.2: http://www.hiren.info/pages/bootcd

Bom, espero que tenham gostado e até a próxima!
Dúvidas e sugestões serão bem vindas!
Abraços!

 

Referências:
http://www.ibm.com/developerworks/br/library/l-clonezilla/
http://www.lewan.com/blog/2011/04/14/p2v-conversion-of-linux-virtual-machine-for-xenserver
http://www.ppgia.pucpr.br/~jamhour/RSS/TCCRSS08A/Diego%20Lima%20Santos%20-%20Artigo.pdf
http://www.hiren.info/pages/bootcd
http://clonezilla.org/lecture-materials/015_OSC_Tokyo_Spring_2014/slides/OSC2014-Tokyo-Spring.pdf
http://ports.marllus.com/wp-content/uploads/2016/02/GNU-Linux-P2V-e-V2V-para-XenServer-6.5.pdf
http://ports.marllus.com/2016/02/12/o-xenserver-tools-xenserver-6-5
http://ports.marllus.com/2016/02/12/pv-hvm-hvm-com-drivers-pv-pvhvm-pvh-no-xenserver-a-sopa-de-letrinhas-da-virtualizacao
http://www.webartigos.com/artigos/quarenta-anos-da-caminhada-do-povo-de-deus-no-deserto/77137/

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

 

fev 17, 2016
marllus

Upgrade/Update no XenServer 6.5

Olá amigo(a), tudo bem?

Hoje falarei sobre update e upgrade de hosts XenServer.
Bem, para conceituar os termos:

Update: Atualização (hotfixes) de procedimentos críticos e não críticos de segurança, adição de drivers ou correção de bugs em pacotes → Trivial;

Upgrade: Atualização de versão do sistema de virtualização XenServer, o que pode aglomerar melhorias nos drivers de dispositivos, adicionar funcionalidades, alterar versões de SO usado (neste caso, o GNU/Linux CentOS) e aumento na capacidade de processamento do próprio sistema operacional → (Geralmente crítica e menos trivial [lê-se: trabalhosa]);

O que ocorre?

Muito sysadmin deixa o seu ambiente funcional, perfeitinho e redondinho e enquanto ele estiver funcionando não meche nele porque “não se meche com quem tá queto”.

Nos meus tempos usando XenServer e GNU/Linux aprendi uma coisa: Sempre tente deixar seus sistemas com as últimas versões de atualização. Updates são lançados para serem usados, eles contém novos drivers, patches de segurança, novas versões de softwares com bugs, otimização de código, enfim, não ache que porque seu sistema está no ar que ele não pode cair amanhã por um erro que você já devia tê-lo imunizado.
Te garanto que é doloroso você ter que atualizar o seu ambiente com vários hotfixes na fila de espera, pois cada update vai gerar um mini ataque cardíaco em você.

Para realizar procedimento de update até a versão 6.2 do xenserver open source você teria que ir para a CLI (Linha de comando) e aplicar os passos mostrados neste tutorial:
http://support.citrix.com/article/CTX132791

Curiosidade: Na época em que tínhamos que ir para a linha de comando na versão sem licença paga, vários usuários da comunidade elaboraram suas próprias soluções para realização de update do ambiente. E é disso que estou sempre falando: Compartilhamento de conhecimento!!
Olhem os links:
http://discussions.citrix.com/topic/310573-script-to-update-xenserver-with-powershell/
https://www.citrix.com/blogs/2014/09/10/scripting-automating-vm-operations-on-xenserver-using-powershell/
https://www.virtualexperience.no/2012/11/30/ctxupdate-a-powershell-script-to-download-any-citrix-updates/

Felizmente hoje, a partir da versão 6.5 (versão atual até a última atualização deste tutorial), como o código do XenCenter foi liberado (assim como o código de quase todas as partes do XenServer), foi inevitável liberar a opção no GUI do próprio XenCenter para realizar operações de update.
Isso te dá a possibilidade de deixar a cargo do XenCenter baixar as atualizações e automaticamente aplicar e reiniciar (quando for o caso) o host, sem que se precise fazer de forma manual (apesar de ele também disponibilizar a opção de reiniciar o servidor manualmente).

Por padrão, o XenCenter já vem configurado para sempre checar se existem atualizações disponíveis para hosts xen nele conectados.

Quando for tornada disponível a update, ela vai aparecer na aba de notificações do seu XenCenter, e clicando com o botão direito do mouse em cima dela você pode baixar ou obter informações sobre ela. Antes de atualizar, leia o máximo possível sobre a mesma afim de reconhecer os impactos esperados na pré e pós atualização do ambiente.

Antes disso, realize backup de suas informações como metadados do pool, hosts, e VM. Saiba como realizar backup disso tudo neste aqui:

Eu criei um desenho do fluxo processual que me baseio sempre na hora de realizar procedimentos de update em ambientes XenServer, o qual disponibilizo abaixo:

 

update

 

Nele, mostro que devemos sempre checar a criticidade e impactos institucionais e técnicos antes do procedimento de update, após isso será agendada a atualização (se tiver paradas no servidor, deverão ser previamente relatadas), realizar backups do pool, Vms e xen host (quando houver recurso para o último), desabilitar o HA (requisito técnico) e só depois iniciar a atualização.

Alguns procedimentos minuciosos, bem como todo o passo a passo e pré requisitos de configuração necessários para a realização de um processo de update podem ser conferidos neste link da documentação oficial:
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-updates/xs-xc-updates-applying.html

Com relação à Upgrades (atualização de versão) no Xenserver, existe a possibilidade de realização do procedimento de maneira live, sem que as Vms parem, claro, se você tiver storage compartilhado. As Vms podem ser migradas de um Xenserver para outro com uma versão igual ou superior da de origem, por exemplo de um xenserver 6.2 para um 6.5. Isso é vantajoso neste tipo de atualização, onde a troca das versões é crucial.

Procedimentos e detalhes técnicos de realização de upgrade em um pool (Rolling Pool Upgrade) você pode continuar a leitura do link que passei anteriormente, até chegar nessa parte:
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-updates/xs-xc-upgrade.html

E a mesma imagem para guiar você no processo de update (colocada acima) pode ser usada no processo de upgrade, claro, alterando os detalhes de ordem técnica (na fase de “install update”), mas, o fluxo geral é o mesmo.

Espero que tenha ficado claro para vocês a importância e os procedimentos da documentação oficial que disponibilizei para você.

Grande abraço.

Referências:
http://support.citrix.com/article/CTX132791
http://discussions.citrix.com/topic/310573-script-to-update-xenserver-with-powershell/
https://www.citrix.com/blogs/2014/09/10/scripting-automating-vm-operations-on-xenserver-using-powershell/
https://www.virtualexperience.no/2012/11/30/ctxupdate-a-powershell-script-to-download-any-citrix-updates/
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-updates/xs-xc-updates-applying.html
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-updates/xs-xc-upgrade.html

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

DMC – Dynamic Memory Control – XenServer 6.5

E aí, tb bem?

Você já deve ter visto esse intervalo mínimo e máximo de memória que é mostrado no XenCenter (nas configurações de memória RAM de uma VM). Talvez, possa até ter imaginado que o XenServer vai disponibilizar memória para uma VM de acordo com este intervalo, não é verdade?

É isso mesmo que acontece. Isso é o controle dinâmico de memória (DMC – Dynamic Memory Control). As vezes chamado de “dynamic memory optimization”, “memory overcommit” ou “memory ballooning”.

Quando o DMC é habilitado nas VMs, acontece o seguinte: Se tiver muita memória RAM sobrando no host xen físico, ele libera mémoria máxima para cada VM, ou seja, o valor máximo de memória que você definiu no intervalo é dado a ela (e as VMs ficam bem felizes com isso). Caso falte memória no servidor, o SenServer neste caso faz um cálculo e distribui uma fatia de memória (dentro do intervalo de memória definido em cada VM) para cada VM, não deixando nenhuma delas desamparada e também abrindo oportunidades de novas VMs serem criadas, pois sempre o XenServer irá fazer essas otimizações com o objetivo de todas serem alimentadas com memória suficiente para dar o boot (pelo menos).

Bacana, não é? Show.
Mas, como nem tudo são flores, ter este recurso habilitado requer o dobro de atenção na hora do planejamento de distribuição de memória entre as VMs de seu ambiente.

Imagine a seguinte situação:
Você tem 10 VMs com 1GB de ram funcionando no seu host xen (que tem 12GB de ram). Ou seja, até então você tem pouca memória disponível no seu Dom0 (Xen Hypervisor). Daí você vai criar mais duas VMs de 1GB de ram, então, por causa do DMC ativado em cada VM, o XenServer vai reduzir a memória de cada uma delas afim de ter memória disponível para essas duas VMs novas. Mas, esse ambiente pode entrar em colapso (elas travarem) se as VMs ficarem sem memória suficiente para funcionar, além da memória reservada para o Dom0. Então, tenha bastante cuidado no limite mínimo que você vai colocar para sempre sobrar memória disponível no servidor físico, e assim poder utilizar esse recurso tão bacana sem efeitos colaterais.

Os passos para habilitar/desabilitar o DMC em uma VM, bem como definir um tamanho fixo de memória para ela, está disponível neste link (http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms-configuring/xs-xc-vms-memory/xs-xc-dmc-edit.html)

Referências:
http://www.thegenerationv.com/2010/04/xenserver-56-preview-part-1-dynamic.html
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms-configuring/xs-xc-vms-memory/xs-xc-dmc-edit.html

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

Troubleshooting – Resolução de problemas – XenServer 6.5

Olá, tudo bem?

Hoje, o assunto é sobre troubleshooting, ou, para os menos familiarizados (adeptos do “se está funcionando, está bom” rs) sobre resolução de PROBLEMAS!! Até porque só tem problemas aqueles que fuçam na coisa!

De acordo com a wikipedia:

“Troubleshooting é uma forma de resolver problemas, muitas vezes aplicada na reparação de produtos ou processos falhados. É uma busca sistemática e lógica pela raiz de um problema, de modo a que possa ser resolvido e o produto ou processo possa ficar novamente operacional.”

Portanto, partindo do princípio da busca sistemática e lógica, utilizarei sempre diagramas sistêmicos e fluxogramas para descrever processos de troubleshooting.

Mas, porque trabalhar com fluxogramas em troubleshooting?
Bem, a literatura educacional já tem uma muita pesquisa sobre isso ([1], [2], [3], por exemplo), mas em resumo e tomando como questões também pessoais: Entendeu ou quer que eu desenhe?
Sim, esta frase, muitas vezes tratada de professor para uma sala de aula ou de um amigo que é o “sabichãozão” para com os outros, é lembrada com um tom arrogante. O que quero é tirar este rótulo.
No sentido literal, acredito que tudo deveria ser “desenhado”. A simples forma de uma desenho e a capacidade que ele tem de armazenar várias informações em uma única imagem torna a imersão no conhecimento mais divertida e muito menos enfadonha. Para mim, este é o verdadeiro papel do professor. Aquele que guia e consegue tornar trivial um conteúdo complexo.
Ler slides e livros até o google voice faz.

Você pode perceber que na maioria dos meus tutoriais eu encaixo um desenho que tenta generalizar um processo ou a arquitetura de um sistema que estou explicando. Sempre com uma única imagem.
Acredito neste tipo de imersão educacional. Só não esqueçamos que as referências escritas, mesmo que muitas vezes chatas, tem de ser levadas em suma consideração. Desenhos são generalizações que quase sempre não são perfeitas. A ideia dele é fazer com que o leitor desperte um interesse ou que o processo de melhoria/releitura de um conteúdo ocorra de forma mais eficiente (em menos tempo).

Bem, em processos de resolução de problemas não seria diferente. Na comunidade do xenserver temos muito pouca (ou nenhuma) documentação de troubleshooting através de fluxogramas. Claro que usuários do fórum oficial (Discussion Citrix) e comunidades (xen-br, gc-br, Telegram Xenserver) ajudam bastante, mas, é como se o conhecimento estivesse espalhado e disperso em fóruns e dúvidas de usuários. Não há algo conciso, neste caso.

Bem, uma vez fui aplicar 5 hotfixes em um xenserver 6.2 (desculpe, me atrasei). Seguindo a documentação oficial era como roubar doce de criança (mil maravilhas), mas, na prática não é bem esse carnaval não. É como você recompilar um kernel Linux achando que ele não vai dar pelo menos um bug. Inocência.
Caí em várias armadilhas e situações adversas neste processo e sempre resolvia tentando encontrar soluções naquele momento. Resultado: Sanei os problemas, atualizei meu ambiente e o trabalhão que deu não foi documentado. POOFF na cara da comunidade (e na minha)!

A partir daí, resolvi documentar, no estilo de fluxogramas, os processos de troubleshooting do xenserver em determinadas fases de manutenção.
Atualmente, realizei a criação de um fluxograma do processo referente ao troubleshooting de erros na aplicação de updates no XenServer 6.5. Disponibilizo este documento logo abaixo:

Troubleshooting update – XenServer 6.5:

Para muitos que sofrem com bugs quando vão atualizar seu ambiente, creio que este processo irá ser de grande ajuda.

Meu objetivo é fazer com que usuários contribuam com processos que podem ser melhorados/otimizados no fluxograma. Remodelando o documento através do perfil da comunidade, por meio de críticas e sugestões de usuários, poderemos compilar uma documentação ainda mais concisa do que disponibilizo aqui para você.

Com o passar do tempo creio que este post vai crescer bastante, pois novos fluxogramas irão sendo disponibilizados por mim e pela comunidade. É o que quero.

Um abraço! Até mais.

Referências:
https://pt.wikipedia.org/wiki/Troubleshooting
https://discussions.citrix.com/
https://groups.google.com/forum/#!forum/xen-br
https://groups.google.com/forum/#!forum/gc-br

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

Resizing vDisks (VDIs) – XenServer 6.5

Olá, tudo bem?

Bem, o tema discutido de hoje será redimensionamento de disco virtual no XenServer.
Muitas vezes, por falta de planejamento ou fatos inesperados, o tamanho do disco de uma VM precisa ser aumentado. Por conta deste problema, alguns administradores, com a visão estática de sistemas não virtualizados, não conseguem compreender com clareza como redimensionar um disco virtual.

Se você prestar atenção, o XenServer deixa você alterar o tamanho de um disco de uma VM. Para isso, é só ir na aba configurações do storage da VM e alterar o valor do tamanho dele. Mas, calma que o tamanho da partição la ná VM não vai alterar automaticamente! rs. (assim você quer demais).
Primeiro vamos entender o que é um disco de uma VM. A partir das imagens abaixo, explicarei sucintamente.

O conjunto do relacionamento de objetos de storage do XenServer:

Desenhado pela Citrix:

 objects_storage_Vdi.png

Desenhado por Gohar Ahmed:

 objects_storage_Vdi.png

 

Desenhado por Martez Reed:

 objects_storage_Vdi.png

 

As três imagens demonstram os mesmos relacionamentos, só que com representações diferentes (para uma melhor didática).

Todo dispositivo relacionado com armazenamento (um disco rídigo, por exemplo) que é conectado ao XenServer será reconhecido como um PBD (dispositivo de bloco físico). Então, quando você cria um SR (repositório de storage – storage repository) dentro do XenServer, está justamente configurando este(s) PBD(s) para ser(em) o armazenamento deste SR.
Dentro deste SR eu posso ter vários VDI (imagem de disco virtual – virtual disk image), que é um objeto criado pelo XenServer que fornece uma abstração de um HDD (Disco Físico) e contém informações sobre a mídia física no qual se encontra (tipo de SR, se é compartilhável, se a mídia física é somente leitura, etc.).
O VBD (Dispositivo de Bloco Virtual), por sua vez, é uma abstração necessária para fazer a ponte entre a VM e o VDI. Ele representa o conteúdo do VDI. Caso não existisse o VBD, a VM não conseguiria utilizar o espaço que o VDI oferece dentro do SR. O VBD dá a possibilidade de a VM enxergá-lo como um dispositivo de bloco (neste caso um disco rígido) que pode ser formatado em um tipo de sistemas de arquivos. Por fim, o VBD contém atributos que ligam o VDI a VM, como QoS, atributos de leitura/escrita, se o disco é bootável, etc.
Ainda não entendeu?

Deixa eu explicar melhor:
Imagine um PC físico com um disco rígido e você instalando um debian 8 nele. Blz né? Pois bem, analogicamente, temos uma VM sendo criada no XenServer com um disco virtual. Esse disco virtual é o nosso VBD. Por trás dele teremos o VDI correspondente, que por sua vez está dentro de um SR e este SR é composto por um ou vários PBDs.

Agora, continuando o objetivo do tutorial, segue a pergunta: Como faço pra aumentar o tamanho de um disco de uma VM?

Bem, como sabemos agora, um disco de uma VM é um VBD, que por sua vez tem um correspondente VDI. Até agora beleza!

Os procedimentos genéricos padrão para aumentar (expandir) um vDisk são:
1- Ir no xencenter, configurações do storage da VM e aumentar o tamanho do disco especificado (neste ponto, você aumentou o tamanho do VDI);
2 – A partir deste ponto, o VBD irá ter um espaço adicional (não alocado) dentro dele, referente a esse aumento do VDI. Com qualquer “fdisk -l” ou “parted” você poderá ver esse espaço adicional;
3 – Agora, você terá que fazer a expansão em nível de SO (sistema de arquivo) na VM, para fazer com que a partição que você quer aumentar (ou adicionar) tenha um novo tamanho, utilizando para isso do espaço que foi inserido.
4 – Após os comandos de expansão, que podem variar se o disco tiver uma estrutura LVM (mais simples) ou sem LVM (um pouco mais de trabalho), você deve realizar um comando, em nível de SO, que vai redimensionar a partição para utilizar a nova quantidade de blocos. Geralmente em GNU/Linux o comando final é o “resize2fs /dev/particao”;

OBS1:Caso a estrutura de partições esteja organizada na forma de LVM, você poderá expandir um disco também criando um novo disco para a VM (com o espaço que quer utilizar). Quando a VM reconhecer esse novo VBD, você o formata e o transforma em PV (Volume físico – estrutura LVM) e junta o mesmo ao PV existente na VM. O LVM trás a grande vantagem (além de simular um RAID 0) de tornar mais fácil e dar novas possibilidades à manipulação dos LVs (Volumes lógicos – pontos de montagem do SO – /home, /usr, etc..) e o redimensionamento do tamanho deles.

Bem, partindo destes passos listo abaixo uma série de tutoriais que poderão ser seguidos por você para redimensionar vDisks de Vms.

Aumentando o espaço de um vDisk com uma partição nativa Linux (sem LVM):
https://www.rootusers.com/use-gparted-to-increase-disk-size-of-a-linux-native-partition/

Aumentando o espaço de um vDisk com uma estrutura LVM através da expansão do VDI:
https://www.rootusers.com/how-to-increase-the-size-of-a-linux-lvm-by-expanding-the-virtual-machine-disk/

Aumentando o espaço de um vDisk com uma estrutura LVM através da adição de um outro VDI (como exemplificado no OBS1):
https://www.rootusers.com/how-to-increase-the-size-of-a-linux-lvm-by-adding-a-new-disk/

Para expandir o tamanho de vDisks com SO MS Windows:
http://support.citrix.com/article/CTX117630

Outros tutoriais e formas de expansão de vDisk:
https://maanasroyy.wordpress.com/2012/06/03/resize-a-linux-vm-lvm-disk-in-xenserver/
https://codesilence.wordpress.com/2013/03/14/live-resizing-of-an-ext4-filesytem-on-linux/

OBS2 : Ainda não é possível diminuir (shrink) o tamanho de um VDI dentro do Xenserver. O motivo eu creio que deva ser porque na redução de um VDI, a probabilidade de afetar uma área com dados do sistema do usuário seria bem alta. Mesmo com LVM, um algoritmo que analisasse as áreas não alocadas para serem liberadas do disco, além de muito minucioso, poderia vir a corromper o sistema em uma exclusão errada, além do que o usuário teria que desalocar aquela região que seria liberada.
Considero um problema tanto trabalhoso para resolver, mas não impossível.

Há um meio de realizar esse processo (não muito “ortodoxo” – pra não dizer gambiarra).
Os passos são listados abaixo:

– Anexar um novo VDI na VM em questão e criar uma partição em toda sua extensão (o tamanho do VDI deve ser de pelo menos do tamanho dos dados do disco);
– Utilizar algum programa de clone de disco e dar o boot via ISO (exceto o clonezilla, pois ele tem uma limitação que jájá explicarei);
ex: HD clone, fsarchiver, FOG project, etc.
– Clonar o disco da VM jogando a imagem no VDI anexado na mesma;
– Criar uma nova VM no Xenserver com um disco menor do tamanho que você quer diminuir;
– Iniciar o programa de clonagem e anexar na VM o VDI que contém a imagem exportada e restaurar a imagem do disco antigo para o novo disco;

OBS3: O clonezilla têm a limitação que na restauração de um disco, o tamanho do disco de origem têm de ser maior ou igual ao do disco de destino, o que é é inviável na hora de um shrink.
OBS4: Alguns usuários na internet disseram que conseguiram shrink de discos como Clonezilla (mas somente quando o disco de destino era um pouco menor de tamanho que a origem). Você pode conferir os relatos aqui.

Perceba que vários tutorias utilizam o hypervisor Vmware, mas, não se preocupe. O entendimento que você tem que ter é de como funcionam as relações de PBDs, VDIs e VBDs com Vms.
O processo de criação de disco ou aumento do tamanho usando Xenserver (Xencenter) ou Vmware (vCenter) é só interface. Os passos genéricos padrão (citados acima) são os mesmos para qualquer hypervisor.

Espero que tenha gostado!
Grande abraço.

 

Referências:

https://www.schirmacher.de/display/INFO/How+to+increase+XenServer+virtual+machine+root+or+swap+
partition

https://thewiringcloset.wordpress.com/2013/01/09/extending-a-root-filesystem-in-linux-without-lvm/
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007907
http://discussions.citrix.com/topic/237812-extend-vm-disk-size-debian-guest/
https://www.rootusers.com/use-gparted-to-increase-disk-size-of-a-linux-native-partition/
https://www.rootusers.com/how-to-increase-the-size-of-a-linux-lvm-by-expanding-the-virtual-machine-disk/
https://www.rootusers.com/how-to-increase-the-size-of-a-linux-lvm-by-adding-a-new-disk/
https://www.rootusers.com/lvm-resize-how-to-decrease-an-lvm-partition/
http://support.citrix.com/article/CTX117630
https://maanasroyy.wordpress.com/2012/06/03/resize-a-linux-vm-lvm-disk-in-xenserver/
https://codesilence.wordpress.com/2013/03/14/live-resizing-of-an-ext4-filesytem-on-linux/
http://cleriston.com.br/post/110578666928/identificando-vdi-no-xenserver-via-command-line
https://discussions.citrix.com/topic/361767-convert-vm-from-hyper-v-2012-to-xenserver-62/
https://www.miray.de/products/sat.hdclone.html
http://www.fsarchiver.org/Fsarchiver_vs_partimage
https://fogproject.org/
http://clonezilla.org/
https://community.spiceworks.com/topic/225979-clonezilla-restore-to-smaller-hard-drive
http://clonezilla.org/clonezilla-live/doc/02_Restore_disk_image/advanced/09-advanced-param.php
http://docs.vmd.citrix.com/XenServer/5.5.0/1.0/en_gb/images/sr-diagram.png
http://www.amazon.com/Implementing-Citrix-XenServer-Quickstarter-Gohar/dp/1849689822
http://www.amazon.com.br/Mastering-Citrix-Xenserver-Martez-Reed/dp/178328739X

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

Alta disponibilidade (HA – High Availability) no XenServer 6.5

E aí, leitor! Td bem?

Bem, HA (High Availability – Alta disponibilidade) é um assunto bem procurado por administradores de infraestrutura, pois muitos o querem em seu ambiente (lê-se: seu pescoço), afim de deixá-lo o mais seguro e resiliente possível. Aliado a isto, o fato de esse recurso ser completamente open source (aêêêêê) no XenServer 6.5, contribui bastante para sua adoção.
A facilidade de configuração de HA coloca este recurso na lista dos top 10 mais utilizados no XenServer.

Mas, em quê consiste o HA? Simples, este sistema tenta proteger seu ambiente (suas Vms) em caso de falhas físicas ou lógicas no host xen.
E o que ele faz para tentar garantir isso? Ele tentará migrar as VMs do host xen falhado para algum host vivo (e de bem com a vida). Para isso, o HA faz uso do recurso XenMotion (falo sobre XenMotion aqui).

Explicando o HA de forma mais completa:

Os alicerces para o funcionamento do HA em um pool de recursos são: Planejamento da disponibilidade dos recursos, detecção da falha e execução da recuperação.

Planejamento da disponibilidade dos recursos:

Neste etapa, o HA irá planejar qual a tolerância de falha nos servidores (quantos servidores podem falhar) dentro do pool. Basicamente, baseado em quantas Vms você quer proteger dentro de cada host, o próprio HA emitirá um aviso informando qual o limite de servidores que podem falhar no pool para que essas Vms sejam ligadas em outros servidores ativos.
Portanto, se você quiser ter resiliência total do seu ambiente, deixe sempre uma reserva de recurso (RAM e CPU) em cada host. Essa reserva será utilizada para alocar Vms de hosts que podem vir a falhar. Claro, o tamanho desta reserva vai depender de quantos hosts e quanto de recurso (RAM e CPU) você terá e quantas Vms você vai querer “salvar”.
O HA sempre calculará, automaticamente, a quantidade de recursos disponíveis no pool para lhe dizer qual tolerância de falhas você tem naquele momento.

Detecção da falha:

Quando você for configurar o HA em um pool, o Xenserver vai pedir para escolher um SR onde ele irá gravar o keep alive dos servidores. Este será um SR compartilhado (no pool) chamado Heartbeat SR (que armazena o “batimento cardíaco” dos servidores – 356Mb tamanho). Ele nada mais armazena do que informações de status (vida [response] ou morte [timeout]) de cada servidor no pool. Em um intervalo de tempo, cada servidor fornece a informação que está vivo para este SR (keep alive). Se esta informação não chegar, o HA reconhecerá que o servidor morreu e tentará seguir o plano de recuperação das Vms (de acordo com o que você planejou).
Pode acontecer de um host perder as configurações de rede, ou um bug no toolstack, ou um administrador descuidado retirar ou alterar o ip de gerência do host para uma faixa desconhecida. Nestes casos, a comunicação do host para o storage não foi perdida (ou seja, as Vms continuarão rodando normalmente), porém o host xen ficará inacessível. Para nossa alegria, o HA consegue detectar que houve falha na rede (sim, ele também checa de tempos em tempos a rede do host). Quando ocorre isso, entra em cena um recurso chamado host fencing, que vai desligar o host, e tentar recuperar as Vms protegidas associadas a ele, migrando-as para outro host com recurso disponível.

Execução da recuperação:

Acontece o que expliquei em tópicos anteriores. Se o host deixar de mandar um keep-alive para o storage ou se a rede de gerência do host for perdida (por algum motivo) iniciará o processo de recuperação das Vms, realizado pelo sistema de HA do XenServer. Nestes dois casos, o servidor estará indisponível e as Vms serão migradas para outro host disponível no pool de recursos.

Resumindo (mais do que foi resumido):

Na criação do HA, você seleciona quais Vms vão ser reiniciadas em caso de falhas (indicando qual a ordem de inicialização). Dinamicamente, o HA vai mostrando se ele tem condições de recuperar todas as Vms. É perguntado também qual a tolerância que você quer para falhas em servidores (configured failed capacity) e, automaticamente, o Xenserver vai te dizer se é possível ele garantir essa recuperação (current failed capacity).
Lembrando que o valor do “current failed capacity” vai alterando dinamicamente de acordo com o provisionamento ou alteração de novas Vms no pool, pois, ao longo do tempo os recursos de RAM e CPU entram em escassez, podendo chegar no ponto em que os recursos de “sobra” nos hosts não sejam suficientes para garantir o plano de recuperação configurado pelo administrador (esse ponto é conhecido como overcomitted). Não se preocupe, o Xenserver enviará alertas automaticamente pelo Xencenter ou por e-mail (se configurado) quando o recurso físico disponível não suportar recuperar todas as Vms protegidas pelo HA. Então, fique atento!

Resumindo (com imagens) com duas situações, uma com sucesso e outra sem sucesso no plano de recuperação (por causa de overcommitting):

 

 photo HA_funcionamento1.png

 

 photo HA_funcionamento2.png

Ciclo de vida do HA no Xenserver:

 

 photo HA_lifecycle.png

 

Requisitos e recomendações:

  • – Um pool de recursos, logicamente;
  • – Recomenda-se pelo menos 3 hosts nesse pool;
    – Um SR compartilhado, sendo este do tipo NFS, iSCSI ou FC de pelo menos 356MB ou superior. Destes 356MB serão: 4MB para dados do heartbeating e 256MB para metadados do membro master do pool, para os casos onde ele falhará.
    A citrix recomenda que você utilize um SR dedicado para conter estes dados.
    – IP estático para todos os hosts no pool;
    Se o endereço de IP de um host mudar, provavelmente o HA considerará que a sua rede falhou e irá ativar o host fencing. Para remediar isto, basta desabilitar o HA (comando # host-emergency-ha-disable) e resetar o membro master do pool (comando # pool-emergency-reset-master) e só então reabilitar o HA.
    – vDisks (discos virtuais) de VMs deverão estar em storages compartilhados;
    – Vms não devem ter conexão ativas para unidades de DVD local do host xen;
    – Vms devem ter interfaces de rede virtuais disponíveis em todo o pool;

Algumas considerações:

– Update/Upgrade de Xenserver: Antes de qualquer procedimento deste tipo, desabilite o HA, pois, muito provavelmente seu servidor precisará ter seu XAPI ou kernel reinicializado. Você não quer que o HA entenda isso como uma falha, né?
– Vms configuradas no plano de HA pela opção de best-effort não estão protegidas através do plano de recuperação de Vms do HA. Como o próprio nome já sugere (melhor esforço), o sistema do HA tentará alocar uma VM em um servidor onde haja espaço em recursos. Por isso, as VM com prioridades de reinicialização 0, 1, 2 e 3 são as únicas que estarão no plano de recuperação do HA. Então, fique de olho no que é serviço crítico em seu ambiente.
– No planejamento de reinicialização, sempre é bom estabelecer tanto a prioridade quanto o delay das reinicializações. A primeira serve para definir quem irá rebootar primeiro (DHCP, AD, SAMBA, DNS, por exemplo) e o atraso entre estes reboots. Por exemplo, você não vai querer que o serviço de DHCP de sua rede entre depois de um serviço SAMBA, ou que uma aplicação que usa um compartilhamento do SAMBA ligue após o próprio SAMBA, não é? Fora isso, ainda tem o problema da “chuva de boots” que consiste no overhead do Dom0 para gerenciar o boot de muitas Vms ligando de uma vez. A “chuva de boots” pode comprometer o desempenho de seu ambiente de virtualização.
– Considere utilizar multipathing na comunicação para seu(s) storages e configurar bond nas interfaces de rede de gerência de cada host no pool protegido por HA. Ter duplicação de caminhos para rede e armazenamento melhora, consideravelmente, a capacidade que o(s) host(s) têm de ficarem ativos em caso de falha em uma NIC (placa de rede). Isso reduz a probabilidade de ativação do HA (pois é isso que queremos, certo?).
Bem, para finalizar, deixo aqui os passos (através de documentação oficial) necessários para habilitar o HA em um pool de Xenservers.
http://support.citrix.com/article/CTX121708

Espero que tenha gostado do tutorial!
Até mais!

Referências:
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-protection/xs-xc-pools-ha/xs-xc-pools-ha-enable.html
http://support.citrix.com/article/CTX121708
https://xen-orchestra.com/blog/xenserver-and-vm-high-availability/
https://www.citrix.com/blogs/2011/05/18/so-what-is-xenserver-xapi/
http://wiki.xen.org/wiki/Choice_of_Toolstacks#XAPI_.2F_XE

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

Storage XenMotion no XenServer 6.5

Olá, td bem?

Falei, anteriormente aqui sobre “XenMotion”. Hoje irei falar sobre “Storage XenMotion”.
Storage XenMotion nos remete a ideia de “XenMotion entre storages”, e é exatamente isso que este recurso (fascinante) faz. A partir dele, a VM pode ser transferida entre storages distintos, ou seja, os discos da VM (VDIs) podem ser migrados entre pools diferentes (entre dois sites XenServer). Tudo isso com o mínimo de downtime possível, pois geralmente se perde alguns pings quando se é re-setado a placa de rede virtual e a rota é alterada.
E não é propaganda Tekpix, o recurso existe e é disponível com código fonte liberado (aêêêêêê)!!!
OBS: Convido você a ir no site da VMware e ver a bagatela que é a licença com o recurso equivalente (VMware Storage vMotion) habilitado.

Muitos dos requisitos necessários para utilizar Storage XenMotion são do próprio XenMotion.
A lista com todos é essa:

– O XenServer tools deve estar instalado na VM;
– O host xen destino têm de ter a mesma ou versão superior do XenServer do host de origem;
– O host xen destino têm que ter memória suficiente para provisionar a VM, caso contrário a VM não completará o processo de migração (isso é meio lógico, rs);
– O drive de DVD deve estar setado como empty (não deve ter nenhuma .iso anexada ou nenhum cd/dvd dentro do drive do host);
– Se as CPUs dos hosts de origem e destino forem diferentes, então a CPU do servidor de destino deve suportar todos os recursos da do servidor de origem, o que, por consequência, é muito improvável que as CPUs sejam de fabricantes diferentes, ou seja, é muito recomendável você trabalhar mesmo com o mesmo fabricante de processador (por exemplo, Intel ou AMD).
– Não é possível migrar VMs que tenham mais de um snapshot (leia aqui meu outro tutorial sobre snapshots e saiba o porquê disso);
OBS: Se a VM conter um snapshot, planeje a alocação de seu espaço no storage do host destino. Caso não entenda, o link acima sobre snapshots explica tudo isso.
– Não é possível migrar VMs que tenham mais que 6 VDIs anexados (como somente um VDI é transferido por vez, creio que 7 VDIs iria comprometer bastante a VM em caso de um possível falha na migração).

Limitações do Storage XenMotion:

– Não deve ser usado em ambientes com XenDesktop (Virtual Desktop Infrastructure);
– VMs que usam PCI pass-thru não podem ser migradas;
– A perfomance da VM irá ser reduzida no processo de migração, então, cuidado com o horário de rush;
– Deve ser desabilitado qualquer HA ou WLB configurado no pool de origem ou destino;

Storage XenMotion é bastante utilizado em casos de Upgrade de Xenserver Standalone (hosts xen sem pool).

Para saber como migrar uma VM através do XenCenter, acesse esse tutorial (http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms-manage/xs-xc-vms-relocate.html).

Vídeo demonstração do Storage XenMotion:
https://www.youtube.com/watch?v=YWGu3tT6Z18

Até breve!
Abraço!

 

Referências:
http://www.amazon.com.br/Mastering-Citrix-Xenserver-Martez-Reed/dp/178328739X
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms-manage/xs-xc-vms-relocate.html
https://msinhore.wordpress.com/2012/09/20/storage-xenmotion/
https://www.youtube.com/watch?v=YWGu3tT6Z18
https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/storage-xenmotion-live-storage-migration-with-citrix-xenserver.pdf?accessmode=direct
http://ports.marllus.com/2016/02/15/xenmotion-no-xenserver-6-5
http://store.vmware.com/store/vmware/en_US/pd/productID.284281000?src=WWW_eBIZ_productpage_vSphere_EnterprisePlus_Buy_US
https://en.wikipedia.org/wiki/Desktop_virtualization

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

XenMotion no XenServer 6.5

Olá, td bem?

XenMotion é um recurso bem interessante e muito importante dentro de ambiente de virtualização do XenServer. É com ele que o HA (High Availability), WLB (Work Load Balancing – Versão paga do XenServer – :(  ) e Rolling Pool Upgrade funcionam direitinho, habilitando a possibilidade de mover as VMs entre hosts do mesmo pool sem (ou quase sem) downtime (geralmente 1 ou 2 pings perdidos).

O XenMotion já vem habilitado no XenServer na versão gratuita. E ele serve, basicamente (e como falei acima), para você poder movimentar VMs “à quente” entre hosts xen em um mesmo pool, ou seja, o storage (SR) têm de ser compartilhado entre as VMs (Geralmente um storage, adicionado em um pool, do tipo iscsi, fc, nfs).

Mas, quais os requisitos mais específicos para utilizar o XenMotion?

– O XenServer tools deve estar instalado na VM;
– O host xen destino têm de ter a mesma ou versão superior do XenServer do host de origem;
– O host xen destino têm que ter memória suficiente para o provisionamento da VM, caso contrário a VM não completará o processo de migração (isso é meio lógico, rs);
– O drive de DVD deve estar setado como empty (não deve ter nenhuma .iso anexada ou nenhum cd/dvd dentro do drive do host físico);
– Ter um SR compartilhado no pool (NFS, iSCSI/FC SAN);

Mas, e em quais situações você vai usar o XenMotion (fora ficar brincando de jogar uma VM de um host pra outro só pra ver como é lindo isso funcionando, rs)?
Você pode usar isso, por exemplo, quando for atualizar um host xen, migrando as VMs nele contidas para um outro host xen. Além disso, você pode usar pra migrar VMs enquanto faz manutenção em um host ou até planejar um script balanceador de carga entre hosts físicos (o que o Work Loading Balancig faz – na versão do Xenserver com linceça). Enfim, as possibilidades são muitas. Só a produção e o dia a dia que vai te desafiar com situações como estas. É só pensar sobre os benefícios e planejá-los bem!

Para saber como migrar uma VM através do XenCenter, acesse esse tutorial (http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms-manage/xs-xc-vms-relocate.html).

Tutoriais/ explicações em vídeo:
https://www.youtube.com/watch?v=hTlwlNjc86M
https://www.youtube.com/watch?v=05Zc0ze5CpQ
https://www.youtube.com/watch?v=vcPzrnrnYCU

Até breve!
Abraço!

 

Referências:
http://support.citrix.com/article/CTX115813
http://www.amazon.com.br/Mastering-Citrix-Xenserver-Martez-Reed/dp/178328739X
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms-manage/xs-xc-vms-relocate.html
https://msinhore.wordpress.com/2012/09/20/storage-xenmotion/
https://www.youtube.com/watch?v=hTlwlNjc86M
https://www.youtube.com/watch?v=05Zc0ze5CpQ
https://www.youtube.com/watch?v=vcPzrnrnYCU
https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/storage-xenmotion-live-storage-migration-with-citrix-xenserver.pdf?accessmode=direct

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

fev 17, 2016
marllus

Fast clone e full copy de VMs no XenServer 6.5

Opa, e aí, td certo?

Hoje explicarei sobre Fast Clone e Full Copy de VMs e templates. Meu papo será focado no entendimento destes dois pontos.

Se você nunca copiou uma VM ou template, a qualquer hora irá precisar fazer isto. VMs e templates são copiados a fim de vários motivos: Para realizar testes a partir de uma VM que está em produção, provisionar (subir) novas VMs rapidamente, criar templates a partir delas, etc.
Mas, quando você vai copiar uma VM pelo XenCenter, sempre abre uma tela que te pergunta dois modos de cópia para você escolher: O fast clone ou o full copy.

Bem, quando você olha o nome fast clone dá uma ideia de mais agilidade (rapidez). Creio que muitos administradores escolhem essa opção por isso, sem saber que podem pagar caro no futuro…

Explicando mais detalhadamente:

Quando uma VM ou template é copiado pelo modo fast clone, o novo VDI da VM/template acessa os blocos antigos do VDI de origem. Por exemplo, se eu tenho uma VM com o GNU/Linux Ubuntu recém instalado e copiar esta VM como fast clone, a nova VM criada vai usar os blocos antigos (neste caso a partição do sistema completo) do disco da VM original, todo arquivo criado ou alterado a partir desse momento será gravado no novo disco. Em outras palavras, toda região do VDI da nova VM referente ao que foi gravado na VM original é um ponteiro para o disco desta VM (não há duplicação de conteúdo, em nível de bloco).

Quando uma VM ou template é copiado como full copy, o novo VDI da VM/template é totalmente independente do VDI original (que foi copiado). Todo o conteúdo é copiado (literalmente) para o novo disco. Dá pra imaginar que essa cópia é um pouco mais demorada, por esse fato.

Mas o preço a se pagar pela rapidez do fast clone, é a questão do encadeamento (acorrentamento) dos VDIs. Por padrão, o limite máximo desta cadeia (chain) é de 30 VDIs. Na prática, se você chegar em mais da metade desse limite, o acesso aos dados será bastante degradado. Essa cadeia vai aumentado a partir do momento que você vai provisionando cada vez mais VMs e copiando templates como fast clone.
Por contrapartida, isso não ocorre com o método full copy, pois não existirá ponteiros entre VDIs novos e antigos nem encadeamento entre eles (chain=0).

Vou explicar com imagens:

O que acontece no fast clone:

 

 photo FastClone_fullcopy_zpssg0t9fut.png

O que acontece no modo full copy:

 photo FastClone_fullcopy_zpssg0t9fut.png

Para você analisar essas árvores que são criadas e que crescem a partir do provisionamento de cada vez mais cópias fast, entre no host xen em questão e digite o comando:
# vhd-util scan -f -m “VHD-*” -l VG_XenStorage- -p
O resultado deste comando será algo do tipo:

 photo Cli_fast_parent

Perceba que a seta indica que o VHD (VDI) mostrado na linha tem um parent (nó de origem).
Quando o parâmetro “parent” está como “none” quer dizer que o VHD não tem um pai relacionado, ou seja, ele não foi criado com fast clone.

Assim como os snapshots, quando um VDI na cadeia é excluído, um evento de aglutinação (chamado coalescing) entre VDIs é feito (em qualquer tempo – assíncrono). Após isso, algum espaço em disco no SR deverá ser liberado.
Mas, se você não quer excluir VMs encadeadas, existem três formas de resolver o problema do “encadeamento infeliz”:
– Migrar a VM encadeada para outro SR no pool. Após isso o parâmetro parent será resetado (=none).
– Setar a prioridade de IO de disco (QoS) da VM encadeada como nível alto (use isto como um paleativo). Mais detalhes aqui.
– Copiar a VM encadeada novamente (Xencenter ou “vm-copy” na linha de comando), mas, desta vez como full copy (o parent também irá resetar).

Bem, creio que você agora deve entender mais sobre esses dois tipos de cópias e seus prós e contras.

Para saber como realizar os procedimenos de cópia, clique neste link (http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms/xs-xc-vms-copy.html)

 

Referências:
http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html#disk_qos
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms/xs-xc-vms-copy.html
http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html#id541790
https://www.citrix.com/blogs/wp-content/uploads/2012/05/vhd-util-sample-1024×404.png

 

Licença Creative Commons
Este trabalho de Marllus, está licenciado com uma Licença Creative Commons – Atribuição-CompartilhaIgual 4.0 Internacional.

Páginas:«123»