Tudo bem, quero começar a aproveitar minha SAN um pouco mais do que tenho feito e, ao mesmo tempo, aproveitar as vantagens do ESXi.
Atualmente, tenho uma matriz de blades Dell PowerEdge 1955 conectados a uma matriz de armazenamento EMC AX4-5 FC de gabinete único. Estou essencialmente usando o SAN como DAS. Eu tenho LUNs na SAN que apontam para máquinas físicas específicas, e essas máquinas utilizam os LUNs para qualquer coisa (principalmente bancos de dados e compartilhamentos Samba/NFS, dependendo do servidor de destino).
Eu tenho vários servidores de arquivos físicos e cada um deles tem uma configuração de samba para servir os compartilhamentos apropriados. Como nunca fiz o RHCS funcionar, apenas um dos servidores de arquivos tem os LUNs montados por vez. No caso de um servidor de arquivos morrer, eu o cerco manualmente (desmontando e removendo a apresentação da unidade, usando o utilitário navisphere ou desligando a energia via DRAC) e depois uso o utilitário navisphere para exibir os LUNs apresentados no próximo concorrente ( depois disso, inicie o Apache e os outros daemons). Tudo à mão, agora mesmo.
Eu me sinto como Ferris Bueller tocando clarinete. Nunca tive uma aula!
De qualquer forma, estou tentando melhorar. O que eu quero fazer é instalar o ESXi nos hosts físicos e, em seguida, criar LUNs para armazenar duas imagens de servidor de arquivos (caso uma seja corrompida/fubar), uma das quais será a ativa e a outra será a de espera. Pelo menos dessa forma, não melhoro a automação (embora irei escrever um script para mudar o servidor "ativo" em algum momento em breve), mas sinto que estou adicionando flexibilidade, além de poder usar os hosts ESXi para armazenar outras VMs, e o hardware não será desperdiçado, como é agora.
Minhas perguntas são:
1) Quão estúpido é meu plano?
2) Quando se trata da implementação real, devo criar uma imagem vmdk normal no LUN ou devo fornecer uma partição "bruta" (se isso for possível com o ESXi?)
3) Existe uma maneira "boa" de usar servidores de arquivos não agrupados?
Responder1
Seu plano não é maluco. Como sempre, existem várias maneiras de atacar isso com base no que você está tentando alcançar e em como proteger seus dados.
Primeiro, você pode apresentar um LUN bruto a uma VM usando um "Mapeamento de dispositivo bruto". Para fazer isso:
- Apresente o LUN ao host ESXi (ou grupo de hosts, se você for usar clustering/HA)
- Adicione um disco à sua VM, selecione Raw Device Mapping, aponte para o LUN
- Verifique novamente o barramento SCSI dentro da VM
- fdisk, monte e adicione ao fstab, como um disco normal.
Vantagens: rápido de configurar, rápido de usar, fácil, pode representar o disco para o host físico se você precisar de V2P no futuro
Desvantagem: você pode perder algumas opções de snapshot/reversão baseadas em VMware, dependendo se você usa o modo de compatibilidade físico ou virtual
Uma opção alternativa é criar VMFS no LUN para criar um armazenamento de dados e, em seguida, adicionar um disco VMDK à VM que reside nesse armazenamento de dados.
- Vantagem: é compatível com Storage vMotion se você comprar uma licença para usá-lo. Isso permite a migração a quente de discos VMDK entre LUNs e até mesmo SANs.
Em ambos os casos, você estará em uma posição de risco semelhante caso o VMware ou sua VM coma o sistema de arquivos durante uma falha; um não é drasticamente melhor que o outro, embora as opções de recuperação disponíveis sejam bem diferentes.
Eu não implanto RDMs a menos que seja necessário; Descobri que eles não me dão muita flexibilidade como VMDK (e fui mordido porinsetosisso os tornou impraticáveis ao realizar outras operações de armazenamento (desde que corrigido - consulte a seção RDM nesse link))
Quanto à sua VM, sua melhor aposta em termos de flexibilidade é armazenar o disco de inicialização do seu servidor de arquivos como um VMDK na SAN para que você possa fazer com que outros hosts o inicializem no caso de falha do host. Usando a funcionalidade HA do VMware, a inicialização de sua VM em outro host é automática (a VM inicializará no segundo host como se a energia tivesse sido desligada; espere executar os fscks e mágicas usuais para ativá-la, como no caso de um servidor normal ). Observe que HA é um recurso licenciado.
Para mitigar uma falha de VM, você pode construir um clone leve do seu servidor de arquivos, contendo o mínimo necessário para inicializar e iniciar o SAMBA em um estado configurado e armazená-lo no disco local de cada host, aguardando que você adicione a unidade de dados do VM com falha e ligue-a.
Isso pode ou não oferecer opções extras no caso de falha da SAN; Na melhor das hipóteses, seu armazenamento de dados exigirá um fsck ou outro reparo, mas pelo menos você não precisa consertar, reconstruir ou configurar a VM na parte superior. Na pior das hipóteses, você perdeu os dados e precisa voltar para a fita... mas você já estava nesse estado de qualquer maneira.
Responder2
Eu ficaria com as imagens vmdk, caso você passe a usar o vmotion no futuro, você nunca sabe que poderá conseguir um orçamento para isso.
Se suas máquinas não estiverem agrupadas, no que me diz respeito, a melhor maneira de gerenciá-las é tentar distribuir a carga da maneira mais uniforme possível. Eu tenho 3 2950 não clusterizados, onde a carga das VMs mais críticas é de no máximo 1/3 em cada uma. A teoria é que é improvável que eu perca mais de uma caixa ao mesmo tempo, então pelo menos 2/3 poderão continuar operando sem serem afetados.
Do ponto de vista da energia, provavelmente seria mais eficiente carregar as máquinas o mais próximo possível de 100% e desligar as outras máquinas, mas para mim parece como colocar todos os ovos na mesma cesta.
Eu não me consideraria um especialista nisso, é apenas o que eu faço.
Responder3
Olá, Matt. Há muitas maneiras de dividir uma solução quando você usa uma solução de virtualização. Em primeiro lugar, houve muitos benchmarks mostrando o desempenho do Raw LUN (RDM) versus VMDK e a diferença normalmente é insignificante. Algumas coisas a serem observadas com RDMs: Apenas certas situações de clustering exigem o uso de RDMs (clustering MS). Os RDMs têm um limite de 2 TB, mas o LVM pode ser usado para contornar esse limite. Os RDMs são mais difíceis de controlar do que fornecer um LUN ao ESXi para usar no VMFS e colocar vmdk nele. VMDKs (como mencionado) têm alguns benefícios interessantes: svMotion, Snapshots (não é possível capturar instantâneos de um pRDM).
Se estiver executando o Free ESXi, veja como posso resolver sua situação. Primeiro, todos os dados estão em arquivos vmdk no VMFS LUNS. Configure 2 VM's e use Heartbeat para failover de IP e Serviços. O Heartbeat mudará o IP do serviço e poderá manipular scripts para desmontar/montar o LUN de dados quando apropriado. Você pode até criar scripts para algum VMware Remote CLI para garantir que a VM 'inativa' seja desligada para proteção. Com a coordenação direta do batimento cardíaco entre os sistemas, o risco de acessar os dados / executar os mesmos serviços deve ser extremamente baixo. A chave aqui é garantir que a montagem/desmontagem do LUN de dados e a inicialização/desligamento dos serviços sejam feitas pelo Heartbeat, e não pelos mecanismos normais de inicialização.
Um failover alternativo pode ser realizado através do sistema de monitoramento. Ao detectar o host inativo, ele pode usar o VMware Remote CLI para desligar (por segurança) e, em seguida, ligar a VM de backup. Nesta situação, o failback é bastante manual.
No meu ambiente "minúsculo", não vi um VMDK ser corrompido. O que também percebi é que se você tiver mais de dois hosts ESX(i) ou uma dúzia de VMs, você precisará do vCenter para ajudar a controlar tudo. Alguns dos pacotes Essential/Plus não são muito caros considerando os benefícios.
Responder4
Acho que você deveria se perguntar "Alguma vez pretendo voltar para servidores físicos"
Se a resposta for talvez, talvez você deva seguir o RDM. O ESXi com RDM exigiria (eu acho) que você comprasse algo para que sua fibra funcionasse (novamente, não tenho 100% de certeza sobre o esxi).
Tínhamos várias máquinas que migrei rapidamente de servidores físicos para ESX (4.0) usando RDM. Eu tinha uma mistura de máquinas Linux e Windows (super fácil para ambas as plataformas). Ainda temos alguns FreeBSD legados em execução (6.0 e anteriores) em servidores físicos para os quais não podemos usar RDM porque o antigo kernel FBSD não suporta isso. Foi rápido e exigiu que eu não fizesse nada além de apontar meu LUN e instalar as ferramentas VMWare. Morte cerebral fácil .. sem conversor, sem complicações ...
Outra coisa que você deve se perguntar é “Quais recursos do VMWare eu quero usar?”
Dependendo da sua resposta, você pode não ter outra escolha senão o VMDK. Se você usa sua SAN para snapshots e não se importa em usar VMware para isso, por exemplo.
Vou compartilhar algumas notas com você sobre o que encontramos até agora. O Vmotion funciona igualmente bem com RDM e VMDK, o Storage Vmotion, por outro lado, só funciona corretamente com não RDM, e tentar usar o armazenamento Vmotion para ir de RDM para VMDK é uma merda basta usar o conversor. A maioria das distribuições Linux possui um pacote de ferramentas VMware de código aberto, o que torna a instalação de ferramentas um problema. O aplicativo de backup funciona muito bem e é livre de VMware, mas não faz tantas coisas quanto gostaríamos. Eu recomendo fortemente fazer uma aula de vmware. O que eu peguei durou uma semana e valeu cada centavo. O suporte VMWare é incrível. Se você conseguir um contrato de suporte e precisar ligar, eles são excelentes. ), mas assim que os consigo, eles SEMPRE vêm com suporte rápido e confiável.