Estamos adquirindo a seguinte estrutura 2 Storages HP EVA e 2
servidores Blade HP, os storages estão numa distancia de 400 metros
serão interligado com fibra, gostaria de utilizar o xen para garantir
alta disponibilidade e tambem redundancia nesse ambiente, hoje estou
utilizando o SLES 10 mais tambem estamos estudando o RHEL 4, gostaria
de montar uma estrutura de cluster de HA e tambem de replicação do
storage, é possivel montar essa estrutura com XEN, alguem já
implementou algo semelhante?
> Estamos adquirindo a seguinte estrutura 2 Storages HP EVA e 2 > servidores Blade HP, os storages estão numa distancia de 400 metros > serão interligado com fibra, gostaria de utilizar o xen para garantir > alta disponibilidade e tambem redundancia nesse ambiente, hoje estou > utilizando o SLES 10 mais tambem estamos estudando o RHEL 4, gostaria > de montar uma estrutura de cluster de HA e tambem de replicação do > storage, é possivel montar essa estrutura com XEN, alguem já > implementou algo semelhante?
> Abraços, > Danilo
Sim, mas utilizo Debian com storage EMC.
O Xen não é especificamente para HA, pois é arriscado subir Guests em outro Host sem ter 100% de certeza que o Host de origem esta desativado. Mesmo utilizando GFS, muitas aplicações podem quebrar como OpenLDAP, MySQL, PostgresSQL, Cyrus (no caso do Cyrus, ainda pode-se utiliza databases skiplist para contornar isso), etc, no caso de uma ativação de Guest indevida.
Então na prática, o setor de monitoramento (Nagios, etc) deve confirmar o problema do Host e então solicitar ou realizar a ativação das máquinas em outro Host. Se o negócio em questão é importante, então certamente possuirá monitoramento 24x7.
Este nível de disponibilidade é suficiente para a maioria dos casos (exceções seriam Guest críticos da bovespa, ou bancos, etc). Veja que HA significa disponibilidade maior que 99,99% e não que deva haver um chavemento/ativação automática dos Guest em outro Host.
A replicação entre storages é uma tecnologia do storage e independe do SO ou hypervisor/virtualização em uso.
Entendi o seu ponto de vista, também concordo com você o mais
complicado
é definir quando subir o guest no outro server, especificamente
gostaria de replicar um servidor samba, utilizando duas storages eva,
pensei em criar o lvm do xen em cima de um volume software raid 1,
e deixar o processo de startup do servidores de backup manual.
Abraços,
Danilo
On 29 out, 11:03, Reinaldo de Carvalho <reinal...@gmail.com> wrote:
> > Estamos adquirindo a seguinte estrutura 2 Storages HP EVA e 2
> > servidores Blade HP, os storages estão numa distancia de 400 metros
> > serão interligado com fibra, gostaria de utilizar o xen para garantir
> > alta disponibilidade e tambem redundancia nesse ambiente, hoje estou
> > utilizando o SLES 10 mais tambem estamos estudando o RHEL 4, gostaria
> > de montar uma estrutura de cluster de HA e tambem de replicação do
> > storage, é possivel montar essa estrutura com XEN, alguem já
> > implementou algo semelhante?
> > Abraços,
> > Danilo
> Sim, mas utilizo Debian com storage EMC.
> O Xen não é especificamente para HA, pois é arriscado subir Guests em
> outro Host sem ter 100% de certeza que o Host de origem esta
> desativado. Mesmo utilizando GFS, muitas aplicações podem quebrar como
> OpenLDAP, MySQL, PostgresSQL, Cyrus (no caso do Cyrus, ainda pode-se
> utiliza databases skiplist para contornar isso), etc, no caso de uma
> ativação de Guest indevida.
> Então na prática, o setor de monitoramento (Nagios, etc) deve
> confirmar o problema do Host e então solicitar ou realizar a ativação
> das máquinas em outro Host. Se o negócio em questão é importante,
> então certamente possuirá monitoramento 24x7.
> Este nível de disponibilidade é suficiente para a maioria dos casos
> (exceções seriam Guest críticos da bovespa, ou bancos, etc). Veja que
> HA significa disponibilidade maior que 99,99% e não que deva haver um
> chavemento/ativação automática dos Guest em outro Host.
> A replicação entre storages é uma tecnologia do storage e independe do
> SO ou hypervisor/virtualização em uso.
> Estamos adquirindo a seguinte estrutura 2 Storages HP EVA e 2 > servidores Blade HP, os storages estão numa distancia de 400 metros > serão interligado com fibra, gostaria de utilizar o xen para garantir > alta disponibilidade e tambem redundancia nesse ambiente, hoje estou > utilizando o SLES 10 mais tambem estamos estudando o RHEL 4, gostaria > de montar uma estrutura de cluster de HA e tambem de replicação do > storage, é possivel montar essa estrutura com XEN, alguem já > implementou algo semelhante?
> Abraços, > Danilo
Eu tenho algo em pequena escala aqui, com apenas um storage simples, e dois servidores HP DL380 G5. Nada comparado ao seu setup aí. Uso a suite de cluster da Red Hat (RHCS). Com ela é possível implementar alta disponibilidade de máquinas virtuais sem grandes dificuldades.
Inicialmente eu estava utilizando uma configuração mais braçal, definindo cada máquina virtual como se fosse um serviço convencional, para usar ativação exclusiva dos volumes lógicos LVM, prevenindo que um mesmo LV fosse acessado em mais de um nó simultaneamente, mesmo que por algum descuido. Porém, vou abrir mão disso, para poder ter live-migration, o que com certeza é uma das grandes vantagens de se ter servidores virtualizados. (No momento da migração, o "disco virtual", no caso um LV, precisa estar acessível nos dois nós, ao mesmo tempo.)
Inicialmente eu escolhi fazer assim mais por precaução, mas parando pra pensar, cheguei à conclusão de que esse tipo de precaução é excessivo. Desde que os administradores do cluster estejam cientes dos cuidados que devem ser tomados, e desde que as máquinas sejam controladas __somente__ pela infra-estrutura do cluster, e nunca diretamente, não há grandes riscos.
Alías, justamente para que esse risco seja eliminado é que são obrigatórios os métodos de fencing. Se um nó do cluster sai do ar, o segundo só assume as máquinas/serviços depois quem um método de fencing tenha sido executado com sucesso, ou seja, depois do acesso ao storage ter sido cortado ou o servidor derrubado, garantindo que não haverá nenhum acesso compartilhado não controlado.
Embora pareça complicado, digo por experiência própria que a configuração é bem simples. O mais difícil pra mim foi entender os conceitos mesmo. (Lembrando que não uso GFS. As VMs tem seus discos todos com EXT3 mesmo, já que eu não monto nada em dois nós ao mesmo tempo.)
Aqui eu uso os VGs em modo clustered com CLVM, pra poder compartilhar um VG entre dois nós, e CMAN + RGManager pra controlar as máquinas virtuais, que são configuradas como recursos vm, que são próprios para máquinas virtuais (Xen ou KVM). E passei a configuração das máquinas pro formato XML da Libvirt também, porque o recurso vm trabalha melhor usando o comando virsh, do que xm. (Ou ao menos é o que tem se dito por aí.) É claro que sempre existirão mais alguns pequenos detalhes de configuração, mas no geral é isso.
Live-migration funciona corretamente, e failover também.
Na lista linux-cluster, da Red Hat, tem um pessoal muito bom pra ajudar. Eu mesmo já me beneficiei bastante da ajuda vinda de lá.
Obs: só cabe ressaltar que o failover de uma máquina virtual não vai ser imperceptível. Quando um nó do cluster parar e outro assumir, equivalerá a um reboot na máquinas virtuais, afinal não há replicação delas em nível de contexto de execução nos dois nós, e elas serão lançadas de novo.
Minha experiência ainda é bastante limitada, mas isso é o que eu posso dizer do meu caso prático.
> Entendi o seu ponto de vista, também concordo com você o mais > complicado > é definir quando subir o guest no outro server, especificamente
Ora, mas é justamente pra isso que servem os gerenciadores de cluster! Desde que se faça direitinho, dá teoricamente pra garantir que isso nunca vá acontecer por si só, sem ninguém pra fazer alguma coisa errada. =)
Agora, contra root que não sabe desavisado e/ou que não sabe direito o que tá fazendo, não tem santo que dê jeito. =P
> gostaria de replicar um servidor samba, utilizando duas storages eva, > pensei em criar o lvm do xen em cima de um volume software raid 1, > e deixar o processo de startup do servidores de backup manual.
Eu não tenho experiência com replicação de storage, mas a alta-disponibilidade em nível de serviço ou máquina virtual é independente da replicação no nível do storage. Tem apenas que projetar direito a estrutura, as conexões e tal.
Você vai deixar apenas um dos storages distante, um terá um conjunto lâmina Blade + storage, um em cada site? Em geral, o storage espelho entra apenas como mais um path de I/O na história, até onde eu sei.
Obrigado pela explanação do tema, no site backup eu tambem vou ter um
storage+blade,
por isso eu perguntei da possibilidade de fazer um raid 1 entre os
storages, eu preciso
utilizar o CLVM ? Existem alguma alternativa para utilização com o
SLES10.
Abraços,
Danilo
On 29 out, 15:52, Edson Marquezani Filho <edsonmarquez...@gmail.com>
wrote:
> > Entendi o seu ponto de vista, também concordo com você o mais
> > complicado
> > é definir quando subir o guest no outro server, especificamente
> Ora, mas é justamente pra isso que servem os gerenciadores de cluster!
> Desde que se faça direitinho, dá teoricamente pra garantir que isso
> nunca vá acontecer por si só, sem ninguém pra fazer alguma coisa
> errada. =)
> Agora, contra root que não sabe desavisado e/ou que não sabe direito o
> que tá fazendo, não tem santo que dê jeito. =P
> > gostaria de replicar um servidor samba, utilizando duas storages eva,
> > pensei em criar o lvm do xen em cima de um volume software raid 1,
> > e deixar o processo de startup do servidores de backup manual.
> Eu não tenho experiência com replicação de storage, mas a
> alta-disponibilidade em nível de serviço ou máquina virtual é
> independente da replicação no nível do storage. Tem apenas que
> projetar direito a estrutura, as conexões e tal.
> Você vai deixar apenas um dos storages distante, um terá um conjunto
> lâmina Blade + storage, um em cada site? Em geral, o storage espelho
> entra apenas como mais um path de I/O na história, até onde eu sei.
> Obrigado pela explanação do tema, no site backup eu tambem vou ter um > storage+blade, > por isso eu perguntei da possibilidade de fazer um raid 1 entre os > storages, eu preciso
Bom, isso depende da tecnologia específica do Storage em questão, e como eu disse, disso eu não conheço quase nada.
> utilizar o CLVM ? Existem alguma alternativa para utilização com o > SLES10.
O CLVM é pra que você possa "compartilhar" VGs entre os nós do cluster. Por exemplo, no meu caso aqui, cada disco virtual principal das VMs é um LV, todos dentro do mesmo VG. Numa situação comum, eu só acesso os LVs em um dos nós. Porém, eu posso, por exemplo, migrar uma máquina virtual para outro nó. Nessa situação, um LV passa a ser acessado no segundo nó, enquanto os outros continuam a ser acessados no primeiro. Para que uma situação dessas seja possível, é necessário sim que o VG seja do tipo clustered, e gerenciado pelo CLVMD, para que os metadados LVM não sejam corrompidos.
Rolou uma discussão sobre isso aqui[1] uns tempos atrás, e foi a partir dela que eu pude entender algumas coisas.
Já sobre a disponibilidade desses softwares pra Suse Enterprise, eu dei uma pesquisada mas achei nada conclusive. Porém, parece que o conjunto de softwares pra cluster é um pouco diferente, usando Pacemaker ao invés do CMAN/Rgmanager da Red Hat, mas tem CLVM também. Veja aqui[2].
2009/11/3 Edson Marquezani Filho <edsonmarquez...@gmail.com>:
> O CLVM é pra que você possa "compartilhar" VGs entre os nós do > cluster. Por exemplo, no meu caso aqui, cada disco virtual principal > das VMs é um LV, todos dentro do mesmo VG. Numa situação comum, eu só > acesso os LVs em um dos nós. Porém, eu posso, por exemplo, migrar uma > máquina virtual para outro nó. Nessa situação, um LV passa a ser > acessado no segundo nó, enquanto os outros continuam a ser acessados > no primeiro. Para que uma situação dessas seja possível, é necessário > sim que o VG seja do tipo clustered, e gerenciado pelo CLVMD, para que > os metadados LVM não sejam corrompidos.
Acredito que o problema principal esta nas aplicações e não em baixo nível LVM/sistema de arquivos.
> 2009/11/3 Edson Marquezani Filho <edsonmarquez...@gmail.com>:
> > O CLVM é pra que você possa "compartilhar" VGs entre os nós do
> > cluster. Por exemplo, no meu caso aqui, cada disco virtual principal
> > das VMs é um LV, todos dentro do mesmo VG. Numa situação comum, eu só
> > acesso os LVs em um dos nós. Porém, eu posso, por exemplo, migrar uma
> > máquina virtual para outro nó. Nessa situação, um LV passa a ser
> > acessado no segundo nó, enquanto os outros continuam a ser acessados
> > no primeiro. Para que uma situação dessas seja possível, é necessário
> > sim que o VG seja do tipo clustered, e gerenciado pelo CLVMD, para que
> > os metadados LVM não sejam corrompidos.
> Acredito que o problema principal esta nas aplicações e não em baixo
> nível LVM/sistema de arquivos.
|
