infraestrutura de replicação
Danilo
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
Reinaldo de Carvalho
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.
--
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net
"Don't try to adapt the software to the way you work, but rather
yourself to the way the software works" (myself)
Danilo
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:
> 2009/10/29 Danilo <daniloh2...@yahoo.com.br>:
Edson Marquezani Filho
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.
Edson Marquezani Filho
>
> Olá Reinaldo,
>
> 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.
> Abraços,
> Danilo
>
Danilo
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:
> 2009/10/29 Danilo <daniloh2...@yahoo.com.br>:
>
> - Mostrar texto das mensagens anteriores -
Edson Marquezani Filho
>
> Bom dia Edson,
>
> 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].
[1] http://groups.google.com/group/xen-br/browse_thread/thread/8fae9746d481b88f/9990e7f378a5ea06
[2] http://linux.derkeiler.com/Mailing-Lists/SuSE/2008-10/msg00884.html
Reinaldo de Carvalho
>
> 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.
--
Reinaldo de Carvalho
http://korreio.sf.net
Pedro Rodrigues
Saudações portuguesas.
Penso que o que vocês estão a precisar é deste documento: http://wiki.novell.com/images/3/37/Exploring_HASF.pdf
Depois de le-lo talvez fiquem esclarecidos.
cumprimentos,
Pedro Rodrigues
--
Cumprimentos Cordiais,
Pedro Rodrigues
--- Gnu. It's not about taking. It's about giving. ---