Há alguns anos, durante o EMC World, tive a oportunidade de me encontrar com Chuck Hollis e vários outros funcionários da VMware para conversar sobre uma ideia que eles tinham. Eles queriam aproveitar os recursos de armazenamento local não utilizados dentro de um host ESX. Em vez de simplesmente armazenar a imagem de inicialização do ESX, eles queriam tornar o recurso utilizável para máquinas virtuais em todo o cluster ESX. Conversamos sobre o que parecia ser um sistema de arquivos clusterizado que poderia proteger os dados em vários hosts ESX. Eu mencionei que os discos rígidos tradicionais são lentos e eles falaram sobre o uso de unidades SSD para acelerar as operações de E/S. Era uma ideia interessante e eu estava curioso para saber se ela se concretizaria. Como você deve imaginar, ela se concretizou: o Virtual SAN. Com o lançamento inicial do VSAN, fiquei interessado, mas, admito, um pouco decepcionado. Aqui estamos, um ano após o lançamento geral, e o VSAN deu um grande salto com a atualização mais recente para o VSAN 6.0.
Claro que o VSAN 6.0 é melhor, mais rápido e maior. Em alinhamento com o vSphere 6.0, os VMDKs podem ter até 62 TB e até 64 hosts no cluster. O número de máquinas virtuais em um nó dobrou de 100 para 200, com um máximo de 6,400 por cluster. Mais nós significam mais capacidade e mais desempenho. O uso de unidades de 4 TB coloca o limite em torno de 9 petabytes de capacidade bruta.
O Virtual SAN 6.0 apresenta um novo modelo de gerenciamento baseado em política de armazenamento, que permite políticas em um nível por VM, em vez de todo o armazenamento de dados. Isso permite que cada VM tenha suas próprias configurações para itens como disponibilidade, desempenho e provisionamento thin. Essas são configurações dinâmicas, portanto, se uma VM precisar repentinamente de proteção extra, o VSAN se adaptará. Em comparação com as versões anteriores, esta nova abordagem é muito mais simples e permite um controle mais granular.
Historicamente, o Virtual SAN tem operado em uma configuração híbrida usando unidades magnéticas tradicionais como armazenamento de capacidade, com flash como cache de leitura para acelerar o desempenho. Para obter o mais alto desempenho, uma configuração totalmente flash foi introduzida. Para manter o custo dessa opção baixo, o papel da capacidade será desempenhado por uma unidade MLC econômica. O Virtual SAN ainda requer um nível de cache, mas não para desempenho. Em vez disso, a ideia é minimizar a carga de trabalho de gravação na camada de capacidade e estender sua vida útil. É importante considerar a natureza de gravação da carga de trabalho.

Em um esforço para melhorar a utilidade em servidores blade, o Virtual SAN 6.0 agora tem uma opção de High Density Direct Attached Storage. Não vejo isso como uma ótima opção, pois a VMware ainda recomenda que todos os servidores em um cluster Virtual SAN tenham a mesma configuração de armazenamento. O uso de tantos gabinetes JBOD externos usa uma quantidade significativa de espaço do chassi do blade, portanto, essa pode ser uma solução muito cara.

O Virtual SAN 6.0 agora reconhece o rack. Ao criar domínios de falha, que representam no mínimo três racks, o Virtual SAN será inteligente o suficiente para distribuir os dados entre esses racks. Isso ajudará a proteger contra falhas de energia, problemas de controlador de armazenamento e falha de rede.
Qual é o próximo título A próxima versão do Virtual SAN pode ser usada em conjunto com uma matriz de armazenamento externo? Na verdade, isso é algo que Chuck Hollis falou há mais de um ano em seu blog. Agora que temos um domínio de falha expandido, a próxima etapa será um cluster Virtual SAN estendido? Posso ver um futuro em que o Virtual SAN seja estendido ao vCloud Air como uma simplificação da recuperação de desastres. O que falta no Virtual SAN 6.0 é qualquer tipo de tecnologia de redução de dados e outros serviços de dados avançados. Com os desenvolvimentos recentes no Virtual SAN 6.0, fica claro que a VMware está investindo pesadamente na tecnologia. Estou ansioso para o que o próximo lançamento pode trazer.
Sobre o autor
Mark May é engenheiro de armazenamento em Cincinnati, Ohio. Ele trabalha com armazenamento e backup corporativo há mais de 15 anos. É um EMC Elect, Cisco Champion e um entusiasta da tecnologia. Em seu tempo livre, gosta de ajudar outras pessoas a entender os meandros do setor de armazenamento, que está em constante evolução. Você pode encontrá-lo online em vários lugares, mas os dois mais prováveis são seu blog pessoal e o Twitter @cincystorage.




Amazon