Browsing articles in "Sem categoria"
fev 17, 2016
marllus

Criando SRs (Storage Repository) no XenServer 6.5

Olá, pessoa! Tudo bem com você?

Bem, hoje falarei sobre os repositórios de armazenamento (SR – Storage Repository).
Existem três tipos de mapeamentos de armazenamento físico (SR) para um VDI, são eles:

VHD baseado em volume lógico (LVM) em uma LUN: Nesse caso, a LUN é fornecida como um dispositivo de bloco para o XenServer. Nesta LUN serão criados os VHDs que correspondem aos VDIs das VM’s. Os VDIs são representado como volumes e guardados em formato VHD. A conexão para a LUN pode ser através de Fiber Channel (SR do tipo LVMoHBA), iSCSI (SR do tipo LVMoiSCSI), SAS (SR do tipo LVMoHBA) ou ainda criada localmente no host XenServer (SR local do Tipo Local LVM).

VHD baseado em arquivo em um sistema de arquivo: Nesse caso, o SR é criado a partir de algum compartilhamento NFS ou local (do tipo EXT). Neste SR, as VMs são criadas como VHDs, ocupando somente o espaço de escrita “naquele momento”, ou seja, são thin-provisioned.

LUN por VDI: Neste caso, você espeta diretamente a LUN na VM. Então, a LUN será o próprio VDI da VM. Ela escreverá diretamente na LUN, que pode estar guardada em um storage SAN, por exemplo.

Para resumir os três tipos de SR e em que casos são utilizados:

SR Volume-Based: Local LVM, iSCSI/FC/SAS.
SR File-Based: Local EXT, NFS.

VDI é uma abstração de um Hard Disk Drive (Drive de disco rígido). O formato padrão dessa abstração é o VHD (Virtual Hard Disk), que é o mesmo padrão que a Microsoft utiliza para os discos virtuais no Hyper-v (Hypervisor que ela mantém). Nesse VHD contém tudo que um HDD conteria: tabelas de partições, metadados referentes ao tamanho do dispositivo de bloco, cilindros, etc.
Como a Microsoft liberou as especificações desse padrão para a comunidade, o xensource (consequemente o Xenserver – a partir da versão 5.5 update 2) o adotou para compor o formato padrão de VDI.

Portanto, quando você criar um VDI ele será gravado, por padrão, no formato VHD. Além desse formato existe também o RAW (pior performance) que você pode escolher utilizando a linha de comando (apenas) do próprio XenServer. A menos que seja um caso específico, não recomendo utilizar raw.

Com relação ao LVM e File, vai depender do tipo de armazenamento físico que você usará para ser SR no seu ambiente. Como falei anteriormente, se for utilizar iSCSI/FC/SAS ou uma partição local como LVM, você irá utilizar VHD em formato LVM. Porém, se utilizar um compartilhamento NFS como seu SR ou uma partição local formatada como EXT, os VHDs guardados nesses locais serão no formato de arquivo (File).

Agora vem a pergunta: Qual a diferença do LVM para o File? Bem, se você não leu meu artigo sobre snapshots, recomendo que leia aqui.
Mas, a diferença é que VDIs escritos em SR do tipo LVM são thick-provisioned. Já os escritos em SR do tipo File são thin-provisioned.
Para entender como funcionam esses dois “modelos” de escrita em disco, recomendo a leitura sobre isso no blog do Cleriston: http://cleriston.com.br/post/19582513172/thick-or-thin-provisioning

Quando eu estava escrevendo esse artigo, li sobre o lançamento da nova versão do Xenserver (7 – Dundee). Descobri que o mesmo vai vir com a opção de usar thin-provisioning em SR do tipo LVM. É um avanço, sem dúvidas (desde à versão 5.5 a comunidade aguarda essa feature). Porém, muito cuidado ao utilizar thin-provisioning no lado do hypervisor, pois, lembre-se que o espaço consumido no SR sempre é o que está escrito nos discos virtuais do seu ambiente naquele momento, e nunca o tamanho total desses discos. Isso abre a possibilidade de você criar, sem problemas, discos de tamanhos que, se somados, podem passar do total da capacidade física.
Imagine isso acontecendo e todos os discos virtuais atingindo sua capacidade máxima.
Dados vão para o ar! Ou melhor: pro limbo. Cuidado.

A descrição para a criação de vários tipos de SR está disponível na documentação oficial, a qual você pode conferir aqui:
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-storage/xs-xc-storage-pools-add.html

Grande abraço e espero que tenha ensinado de forma satisfatória sobre os pontos inerentes ao SR.

Referências:
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-storage/xs-xc-storage-pools-add.html
http://support.citrix.com/article/CTX125884
https://en.wikipedia.org/wiki/Connectix
http://serverfault.com/questions/277294/what-kvm-disk-type-to-use
http://xenserver.org/discuss-virtualization/virtualization-blog/entry/xenserver-dundee-beta-1-available.html
http://cleriston.com.br/post/19582513172/thick-or-thin-provisioning
http://ports.marllus.com/2016/02/14/snapshots-no-xenserver-6-5
http://support.citrix.com/article/CTX138342

 

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

Entendendo templates – Xenserver 6.5

Olá, td bem?

O assunto agora é sobre templates.
Template => modelo, padrão;

Uma VM é um recipiente de software (muitas vezes chamada de Guest) que contém informações a respeito de CPU, sistema operacional, memória RAM e recursos de rede. Esta VM funciona “em cima” do hypervisor Xen.
Pois bem, um template nada mais é que uma VM encapsulada em um arquivo e que contém todas as informações (metadados) para seu rápido provisionamento. Por exemplo, uma destas informações pode ser o tamanho padrão do disco rígido que irá ser criado para ela, ou o máximo de RAM que poderá ser atribuída a ela ou quantos CPUs a VM terá. com estas informações, a criação de VMs fica muito mais rápida para o administrador.

Outro benefício é que, além dos templates padrão que o XenServer disponibiliza de vários sistemas operacionais, você também pode criar/deletar outros novos templates.

Mas, por que devo criar templates se o XenServer já me disponbiliza vários?

Te respondo com um exemplo: Você criou uma VM e teve o maior trabalho para configurar certinho um LAMP (Linux+Apache+MySQL+PHP). Tempos depis, na empresa que você trabalha você foi solicitado para entregar uma máquina com estas mesmas configurações. Neste caso, não é preciso criar a VM e configurar na unha todos os serviços novamente. Basta gerar um template a partir da VM que você criou (e no momento após a configuração de todos os serviços). Daí, a partir deste template, você criará (replicará) uma VM idêntica à original, depois é só alterar o nome dela, alterar o IP ou outras configurações e entregar ao setor que a solicitou.
Massa né?

A figura abaixo mostra qual as características dos templates e como podem ser usados, com base no exemplo que usei.

 

 photo templates_zpsh12h7izn.png

Existem 4 formas de se criar templates no XenServer, através do XenCenter:
– Fazendo a cópia de um template existente;
– Convertendo uma VM existente em um template (olha o exemplo que citei);
– Salvando uma cópia de um snapshot de uma VM em um template;
– Importando um template de uma VM (em arquivo .xva) que foi exportado de um template existente ou snapshot de uma VM;

Todo o procedimento de cada um dos passos é descrito neste link (http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms/xs-xc-templates-new.html).
Qualquer dúvida, só postar nos comentários ou no fórum xen-br@googlegroups.com.

Existe como também você editar templates existentes no XenServer (como os templates prontos que já vem por padrão no XenServer). Por exemplo, neste artigo da Citrix (http://support.citrix.com/article/CTX126320) é descrito como você pode alterar o limite máximo de memória suportada para uma VM, que no caso do artigo, era de no máximo 16GB.

OBS: Um ponto importante para ser dito é sobre a questão da cópia de um template ou de uma VM existente (primeira opção na lista de ser criar templates que citei acima). Nesta cópia existem dois mecanismos: A cópia completa (full copy) e a clone rápido (fast clone). Muito cuidado ao copiar como fast clone. Eu recomendo antes de o fazer, saber usá-lo e evitar futuras dores de cabeça.
Para complementar, recomendo a leitura deste tutorial, onde explico sobre os tipos de snapshots.

Abraços e até+!

 

Referências:
http://docs.citrix.com/en-us/xencenter/6-5/xs-xc-vms/xs-xc-templates-new.html
http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html
http://support.citrix.com/article/CTX126320
http://blogs.citrix.com/2012/05/03/creating-vms-from-templates-in-xenserver-creates-a-fast-clone/

 

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 16, 2016
marllus

Monitoramento – XenServer 6.5

Olá, hoje o assunto é sobre Monitoramento do ambiente de virtualização XenServer.

O assunto é bem simples, mas pouca gente sabe o quão ampla é a gama de métricas que o XenServer consegue capturar no seu funcionamento.

Por padrão, é mostrado no XenCenter, na aba “performance” do host ou VM, gráficos de utilização de memória RAM, network e CPU.

Porém, você pode querer capturar outras méticas, como a quantidade de IOPS (Entra e saída por segundo) na escrita dos VDIs das VMs, a latência do disco ou rede de um host, dentre vários dados. Essas métricas são mostradas no Xencenter através de RRDs (Base de dados Roud Robin), que são arquivos que guardam diversos dados sobre as métricas de rede, CPU, RAM, Storage, etc.

Caso você queira pegar esses RRDs para utilizar em outras ferramentas, pode também capturá-los via HTTP. Como é mostrado aqui: http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html#analyzing_rrds

Você também pode querer adicionar o monitoramento de seu ambiente de virtualização em um software de monitoramento de ambiente, como o nagios ou cacti. Deixo um link aqui de um script para nagios para monitoramento de diversas informações em um pool de servidores XenServer. Ele é totalmente adaptável, abrindo facilmente a possibilidade de adição de novas métricas.
https://exchange.nagios.org/directory/Plugins/Operating-Systems/*-Virtual-Environments/Others/Check-XenServer/details

O conjunto de métricas disponíveis no Xenserver para serem capturadas tanto no Host quanto nas VMs está disponível na documentação oficial do XenServer, que pode ser vista aqui:
http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html#performance_monitoring

Espero que tenha gostado da breve explicação. Qualquer dúvida, só chamar!
Abraço.

Referências:
https://pt.wikipedia.org/wiki/RRDTool
http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/reference.html#performance_monitoring
http://xenserver.org/partners/20-dev-hints/120-xs-pool-check-nagios.html
https://exchange.nagios.org/directory/Plugins/Operating-Systems/*-Virtual-Environments/Others/Check-XenServer/details

 

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

fev 7, 2016
marllus

HCL Xenserver

Olá, seja bem vindo!

O assunto aqui é sobre compatibilidade de hardware e XenServer.
A Citrix mantém uma site (http://hcl.xenserver.org/) contendo todo o conjunto de hardware homologado por ela junto a diversos fabricantes de equipamentos, como Dell, HP, Supermicro, IBM. Todo equipamento que obteve êxito nesse teste é adicionado à essa lista de compatibilidade (HCL).

Mas, o que é essa tal de compatibilidade? Ela serve para oficializar que o XenServer vai conseguir “enxergar” (instalar os drivers) qualquer hardware que contenha na lista em questão.    

Pois bem, quando você estiver elaborando um projeto de especificação de equipamentos (servidores, storages, placas de rede (NICs), etc.) e quiser utilizar o XenServer neste ambiente, o primeiro passo é entrar no site (http://hcl.xenserver.org/) e procurar o hardware em questão no campo de busca do mesmo. Você poderá também selecionar algum tipo de equipamento e fazer a listagem dos homologados. Observe a imagem  do site abaixo que mostra esses duas opções que mencionei:

 photo xen1_zps6fzsarnf.png

Mas, não se preocupe se o servidor onde você irá instalar o seu XenServer não está aí. Na verdade, necessariamente, isso não é um pré requisito para este fantástico virtualizador funcionar. Neste caso, ele poderá até reconhecer e instalar todos os drivers do equipamento mas não terá suporte oficial pela Citrix, se você tiver em mente de adquirir uma licença.

Recapitulando: Ter um hardware na HCL não é requisito para a total plenitude de funcionamento do XenServer neste ou conectado a este hardware (storages, servidores, NICs, etc.)!  

Abraços e até mais!

Referências:

http://hcl.xenserver.org/

jul 6, 2015
marllus

Sobre este tutorial

Bem, se caiu aqui neste site, você deve compreender um pouco sobre virtualização e o que é o XenServer.

Bem, Xenserver é uma plataforma completa de virtualização mantida pela empresa Citrix. Com ele, você consegue criar e gerenciar máquinas virtuais (VMs), discos virtuais (VDIs), redes virtuais (VIFs), balancear (ativo-passivo) e agregar (ativo-ativo) links de rede, criar templates de instalações ou de determinados pontos da vida de uma VM (e reduzindo o tempo para recriar, por exemplo, seu ambiente LAMP/WAMP ou outro que necessita de configuração inicial), exportar a quente (live) VMs entre hosts (servidores) XenServer, utilizar um dispositivo de armazenamento de rede NFS, iSCSI (Ethernet), FC (Canal de Fibra) para armazenar as VMs criadas, criar um ambiente de altadisponibilidade (HA) entre elas, dentre inúmeras coisinhas bem legais de se fazer que a própria virtualização já inclui.

Agora, volte para o menu inicial do mapa de ideias e clique em alguma caixa que achar interessante ou siga para o “bizu bala” para ver essas caixinhas separadas por tópico (Instalação, configuração, gerenciamento, monitoramento, backup, atualização, linha de comando, troubleshooting). Até mais. Grande Abraço!

Páginas:«123