Apesar de todo o trabalho que dedicamos ao VMware vSAN em termos de conteúdo e análises para o site, pode ser surpreendente para alguns que não estávamos usando o vSAN em produção. Com a atualização dos nossos servidores de laboratório concluída (12 Dell EMC PowerEdge R740xd ), decidimos resolver esse problema reaproveitando alguns servidores PowerEdge R730 e SSDs extras que tínhamos disponíveis. O resultado é uma configuração modesta do vSAN 6.6 que usaremos para hospedar VMs necessárias para testes, além de servir como plataforma para testar e relatar novos recursos do vSAN. Essa implementação, no entanto, levanta uma questão imediata que os compradores do vSAN costumam ter: como migrar cargas de trabalho existentes para o vSAN?
Como acontece com a maioria das empresas, nosso armazenamento de laboratório primário é uma mistura de compartilhamentos iSCSI e armazenamento Fibre Channel com a maioria de nossos dados residindo em matrizes Dot Hill e um Fusion-io ION. Há várias maneiras diferentes de abordar essa migração, desde a movimentação de VMs entre armazenamentos de dados com um comando SVMotion básico com o armazenamento conectado localmente a um host que pode ver ambos os armazenamentos de dados ou uma migração em duas etapas em que o host e o armazenamento de dados são alterados.
Se você tiver uma matriz de armazenamento com iSCSI LUNs, esse processo é bastante fácil. Adicione o dispositivo de armazenamento iSCSI a um de seus hosts vSAN, se ainda não o fez, adicione o destino iSCSI de sua matriz de armazenamento e tenha acesso rápido a essa VM dentro do cluster vSAN sem precisar migrar o armazenamento de dados ainda. Se você tiver uma matriz de armazenamento que se comunica por FC, poderá aproveitar um FC HBA, caso já exista um dentro do servidor, ou adicionar um ao host. Se o armazenamento FC não for muito usado no futuro, o custo e o tempo de inatividade associados à instalação do HBA podem não valer a pena. Nesse caso, passamos para o processo de duas etapas.
Ao mover VMs entre hosts ESXi onde a computação e o armazenamento serão alterados no mesmo movimento, você pode mover a VM para qualquer lugar em seu ambiente, desde que os dispositivos possam se comunicar entre si dentro de seu vCenter. Esta é uma opção que tem mais compatibilidade, mas pode não ser o caminho de transferência mais rápido se já existir um nativo. Para VMs individuais ou pequenos grupos, isso pode não ser um problema, mas com VMs muito grandes ou grandes lotes, um caminho de transferência mais rápido pode ser garantido.
No nosso caso, podemos ver que a transferência da VM levou apenas alguns minutos, com o link de rede 10G entre os dois hosts ajudando a aumentar a velocidade para cerca de 400 MB/s. No geral, essa é uma das etapas mais fáceis associadas à instalação e funcionamento de sua plataforma vSAN, mas há algumas maneiras de abordá-la, dependendo de quais são suas necessidades ou recursos de hardware.
Neste artigo, falamos bastante sobre como é fácil migrar VMDKs e compartilhamentos iSCSI existentes do VMware para o vSAN. Em qualquer organização que já esteja virtualizada, esse processo é bem simples. A VMware também oferece uma ferramenta para migrações bare metal; nós usamos o VMware vCenter Converter anteriormente para virtualizar cargas de trabalho legadas. Independentemente do método escolhido, o vSAN oferece muitas vantagens em termos de eficiência operacional e redução do custo total de propriedade (TCO) em comparação com as implementações de TI tradicionais. Estamos ansiosos para experimentar esses benefícios em nosso laboratório e esperamos publicar mais conteúdo sobre experiências reais.
Amazon