Como a maioria já viu, o vSAN 6.7 acaba de ser lançado junto com o vSphere 6.7. Assim, percebi que era hora de escrever um artigo sobre "o que há de novo". Há um monte de aprimoramentos interessantes e novos recursos, então vamos criar uma lista dos novos recursos primeiro e, em seguida, examiná-los individualmente com mais detalhes.

• Suporte à interface do usuário do HTML-5
• Painéis nativos do vRealize Operations no cliente HTML-5
• Suporte para o WSFC da Microsoft usando vSAN iSCSI
• Failovers de rede rápida
• Otimização: Ressincronização Adaptativa
• Otimização: Testemunhar a Separação de Tráfego para Clusters Esticados
• Otimização: substituição de site preferencial para clusters esticados
• Otimização: Resync eficiente para clusters esticados
• Novas verificações de saúde
• Otimização: Partição de Diagnóstico Aprimorada
• Otimização: Decomissionamento eficiente
• Otimização: políticas de armazenamento eficientes e consistentes
• Suporte nativo a dispositivos 4K
• Validação FIPS 140-2 Nível 1

Sim, essa é uma lista relativamente longa. Vamos dar uma olhada em cada um dos recursos. Primeiro de tudo, suporte a HTML-5. Eu acho que isso é algo que todo mundo está esperando. O Web Client não foi a interface de usuário mais amada que a VMware produziu, e esperamos que a interface HTML-5 seja vista como um enorme passo à frente. Eu tenho jogado com ele extensivamente nos últimos 6 meses e devo dizer que é muito mal-humorado. Eu gosto de como nós não apenas portamos sobre todas as funcionalidades, mas também olhamos se os fluxos de trabalho poderiam ser melhorados e se as informações / dados apresentados fizessem sentido em cada tela. Isso também significa que, a partir de agora, a nova funcionalidade só estará disponível no cliente HTML-5, portanto, use isso daqui para frente. A menos que a funcionalidade que você está tentando acessar ainda não esteja disponível, mas a maioria deve ser! Para quem ainda não viu, aqui estão alguns screenshots… não é bonito?

Para aqueles que não perceberam, mas na captura de tela acima você realmente pode ver o arquivo de troca e a política associada ao arquivo de troca, o que é uma boa melhoria!

O próximo recurso são painéis nativos de vROPS para vSAN no cliente H5 . Eu achei isso muito útil em particular. Eu não gosto de troca de contexto e esse recurso me permite ver todos os dados que eu preciso para fazer o meu trabalho em uma única interface de usuário. Não é necessário alternar para a interface do usuário do VROps, mas, em vez disso, os painéis do vSphere e do vSAN agora são disponibilizados no cliente do H5. Observe que ele precisa do plug-in VROps Client para a interface do usuário do vCenter H5, mas isso é bastante simples.

O próximo passo é o suporte ao Microsoft Windows Server Failover Clustering para o serviço vSAN iSCSI . Isso é muito útil para aqueles que estão executando um cluster da Microsoft. Crie e iSCSI Target e exponha-o às máquinas virtuais do WSFC. (Normalmente, as pessoas usavam RDMs para isso.) É claro que isso também é suportado por máquinas físicas. Um aprimoramento tão pequeno, mas para os clientes que usam o agrupamento da Microsoft uma grande coisa, já que agora ele permite que você execute esses clusters no vSAN sem nenhum problema.

A seguir, um monte de aprimoramentos que foram adicionados com base nos comentários dos clientes dos últimos 6 a 12 meses. Failovers de rede rápidafoi um desses. A maioria dos nossos clientes tem uma única interface vmkernel com várias NICs associadas a eles, alguns de nossos clientes têm uma configuração onde criam duas interfaces vmkernel em diferentes sub-redes, cada uma com uma única NIC. O que esse último grupo de clientes notou é que na versão anterior esperamos 90 segundos antes de fazer o failover para a outra interface vmkernel (tcp time out) quando uma rede / interface falhava. Na versão 6.7, apresentamos um mecanismo que nos permite fazer failover rápido, literalmente em segundos. Portanto, uma grande melhoria para os clientes que possuem esse tipo de configuração de rede (que é muito semelhante ao design tradicional de A / B Storage Fabric).

Ressincronização adaptativaé uma otimização para a função de ressincronização atual que faz parte do vSAN. Se ocorrer uma falha (host, disco, falha de flash), os dados precisarão ser ressincronizados para garantir que os objetos afetados (VMs, discos, etc.) sejam trazidos para conformidade novamente com a política configurada. Nos últimos 12 meses, a equipe de engenharia trabalhou muito para otimizar o mecanismo de ressincronização o máximo possível. No vSAN 6.6.1, um grande salto já foi feito ao considerar a latência da VM quando se tratava de alocação de largura de banda de ressincronização, e isso foi aprimorado ainda mais em 6.7. Em 6.7, o vSAN pode calcular a largura de banda total disponível e garante que a Qualidade de Serviço das VMs convidadas predomine alocando essas VMs a 80% da largura de banda disponível e limitando o tráfego de ressincronização a 20%. Claro, isso só se aplica quando o congestionamento é detectado.

Um par de lançamento atrás, introduzimos o Witness Traffic Separation para configurações de 2 Nodes, e em 6.7 apresentamos o suporte para esse recurso também para Stretched Clusters. Isso é algo que muitos clientes do Strainched vSAN pediram. Ele pode ser configurado através do CLI apenas neste ponto (esxcli), mas isso não deve ser um grande problema. Como mencionado anteriormente, o que você acaba fazendo é marcar um vmknic apenas para “tráfego de testemunhas”. Bem direto, mas muito útil:

conjunto de ip de rede esxcli vsan -i vmk <X> -T = testemunha

Outro aprimoramento para clusters esticados é a substituição de site preferencial . É um pequeno aprimoramento, mas no passado, quando o site preferido falhava e retornava para o serviço, mas só seria conectado à testemunha, poderia acontecer que a testemunha se ligasse diretamente ao site preferido. Isso por si só resultaria em VMs se tornando indisponíveis. Esta funcionalidade de substituição de sites preferidos impediria que isso acontecesse. Isso garantirá que as VMs (e todos os dados) permaneçam disponíveis no site secundário. Eu acho que alguém poderia argumentar que isso não é um aprimoramento, mas muito mais uma correção de bug. E depois há o Resync eficiente para clusters esticadoscaracterística. Isso está ficando um pouco demais para as ervas daninhas, mas essencialmente é uma maneira mais inteligente de trazer os componentes até o mesmo nível dentro de um site depois que a rede entre os locais falhar. Como você pode imaginar, 1 localização pode progredir, o que significa que o outro local precisa recuperar o atraso quando a rede retornar. Com esse aprimoramento, limitamos o tráfego de largura de banda / resync.

E como em todos os novos lançamentos, a versão 6.7 também possui um novo conjunto de Health Checks . Eu acho que o Health Check tornou-se rapidamente o recurso favorito de todos os vSAN Admins, e por um bom motivo. Isso torna a vida muito mais fácil se você me perguntar. Na versão 6.7, por exemplo, validaremos a consistência em termos de configurações de host e, se for encontrada uma inconsistência, informe isso. Nós também, ao baixar os detalhes da HCL, só faremos o download das diferenças entre a versão atual e a anterior. (Onde antigamente simplesmente puxávamos o arquivo json completo.) Há muitas outras pequenas melhorias em torno do desempenho, etc. Basta dar uma olhada e você verá.

Algo pelo qual minha equipe tem pressionado (obrigado Paudie) é a  Enhanced Diagnostic Partition . Como a maioria de vocês sabe quando você instala / executa o ESXi, há uma partição de diagnóstico. Esta partição de diagnóstico infelizmente era de tamanho fixo, com a versão atual ao atualizar (ou instalar campo verde). O ESXi redimensionará automaticamente a partição de diagnóstico. Isso é especialmente útil para configurações de host de memória grande, realmente úteis para vSAN em geral. Você não precisa mais executar um script para redimensionar a partição, isso acontecerá automaticamente para você!

Outra otimização lançada no vSAN 6.7 é chamada de " Descomissionamento eficiente ". E isso é tudo sobre ser mais inteligente em termos de consolidação de réplicas entre hosts / domínios de falha para liberar um host / domínio de falha para permitir que o modo de manutenção ocorra. Isso significa que, se um componente for distribuído, por outras razões, ele poderá ser consolidado. E a última otimização é o que eles chamam de políticas de armazenamento eficientes e consistentes. Não tenho certeza se entendi o nome, já que isso é tudo sobre o objeto de troca. Por vSAN 6.7, ele será thin provisioned por padrão (em vez de 100% reservado), e o objeto swap agora herdará a política atribuída à VM. Portanto, se você tiver o FTT = 2 atribuído à VM, não terá dois, mas três componentes para o objeto de troca, ainda finamente provisionado, para que não seja realmente necessário alterar o espaço consumido na maioria dos casos.

Depois, há os dois últimos itens da lista: 4 K Native Device Support e FIPS 140-2 Level 1 validation . Eu acho que eles falam por si. O suporte nativo a dispositivos 4K foi solicitado por muitos clientes, mas tivemos que esperar que o vSphere os apoiasse. O vSphere oferece suporte a ele a partir do 6.7, de modo que significa que o vSAN também suportará o dia 0. O VMware VMKernel Cryptographic Module v1.0 atingiu o FIPS 140-2, o vSAN utiliza o mesmo módulo para o vSAN Encryption. Boa colaboração pelas equipes, que agora está mostrando o grande benefício.

Fonte: http://www.yellow-bricks.com/2018/04/17/whats-new-vsan-6-7/