terça-feira, 1 de agosto de 2017
Reunião Q3 - Brasilia VMUG - 04/08/2017
O
VMUG Brasília (grupo de usuários VMware independente) se reunirá na próxima sexta-feira, dia 4
de agosto de 2017, no Centro Universitário IESB, às 18h30. O encontro - que faz
parte das atividades dos cursos de Análise e Desenvolvimento de
Sistemas, Segurança da Informação e Rede de Computadores da instituição -
terá duas apresentações técnicas sobre temas de interesse da comunidade
VMUG, como por exemplo Composible Infrastruture, Hyperconvergence, Containers and
Docker, PaaS and Cloud Ready Applications.
“As tecnologias que serão
tratadas nas palestras fornecem a sustentação para ambientes
computacionais que exigem alta disponibilidade de aplicações”, explica o coordenador do curso de Segurança da Informação, professor Francisco Marcelo.
O encontro terá as seguintes apresentações:
Como
responder às transformações na era digital com a agilidade exigida
pelos usuários e os requisitos estabelecidos pelo negócio, com Luciano Freitas, HPE Master Accredited Solutions Expert, que trata de Composible Infrastructure and Containers;
Execute aplicativos em contêineres juntamente com aplicativos tradicionais na infraestrutura já existente,
que será oferecida pela VMware, explicando sobre vSphere Integrated
Containers, que oferece aos desenvolvedores infraestrutura em nível
de produção e ajuda a equipe de operações de TI a executar aplicativos
tradicionais e em contêineres simultaneamente, em uma infraestrutura
comum proporcionando velocidade, agilidade, segurança, isolamento e
gerenciamento de VMs.
Durante
o evento, serão sorteados brindes aos participantes e anunciado o
ganhador do Badge Contest. Para se inscrever é necessário entrar no https://goo.gl/7HQn7d
Reunião Q3 VMUG Brasília
Data: 04 de agosto
Hora: 18h30
Local: Sala BB1, Campus Sul
Inscrições: https://goo.gl/7HQ
quinta-feira, 3 de novembro de 2016
VMUG-SP realizará seu primeiro encontro no próximo dia 17/11/2016
A primeira reunião do VMUG SP – Grupo de Usuários de VMware de São Paulo já tem data e local para acontecer
O Grupo de Usuários VMware de São Paulo (VMUG SP) foi criado para incentivar o networking e o compartilhamento de conhecimento entre os profissionais de VMware no Estado de São Paulo e também fortalecer o relacionamento com a VMware Brasil e seus parceiros de negócios.
O VMUG é uma organização mundial presente nas principais capitais e grandes centros do mundo e conta atualmente com mais de 150 mil membros ativos, sendo a maior organização do mundo para usuários de virtualização. Cada grupo local é totalmente independente e gerido pelos próprios membros que escolhem e apresentam temas de interesse geral relacionados a tecnologia.
O evento acontecerá no escritório da VMware São Paulo, localizado na Rua Surubim 504 – 4o Andar, no bairro do Brooklin em São Paulo no próximo dia 17 de novembro com início às 18 horas.
“Já temos confirmado a palestra de Introdução a Software Defined Network e ao VMware NSX com o System Engineer de NSX da VMware, Caio Oliveira e temos muitos outros assuntos interessantes para apresentar” diz Valdecir Carvalho, líder do VMUG SP.
A agenda completa do evento será divulgada em breve no site do VMUG SP – http://vmugsp.com.br
A participação no evento é totalmente gratuita e haverá sorteio e distribuição de brindes.
terça-feira, 25 de outubro de 2016
O que há de novo no vSphere 6.5? - vSphere DRS
Na semana passada, a VMware anunciou oficialmente a nova versão da sua plataforma de virtualização, o vSphere 6.5. O anúncio ocorreu na abertura da edição européia da VMworld 2016, que aconteceu em Barcelona entre os dias 17/10/16 e 20/10/16 , e trouxe muitas novidades.
Nesse post vou falar sobre as novidades do vSphere 6.5 com relação ao DRS.
Depois de um bom tempo, finalmente a VMware anunciou algumas mudanças e/ou novidades relativas aos mecanismos do DRS (Distributed Resource Scheduler).
- DRS – New Policies
O DRS (Distributed Resource Scheduler) é a funcionalidade responsável por balancear a utilização dos recursos de um cluster VMware e também por escolher o melhor host para alocar uma VM no momento em que ela é ligada. Nas versões anteriores foram adicionadas algumas opções avançadas que permitiam ajustar a maneira como o DRS deveria balancear as VMs entre os hosts ESXi. Com o vSphere 6.5 algumas dessas opções foram adicionadas à interface gráfica para facilitar para os usuários que desejam tais alterações possam faze-las com mais segurança. Basicamente foram três novas opções:
Nesse post vou falar sobre as novidades do vSphere 6.5 com relação ao DRS.
Depois de um bom tempo, finalmente a VMware anunciou algumas mudanças e/ou novidades relativas aos mecanismos do DRS (Distributed Resource Scheduler).
- DRS – New Policies
O DRS (Distributed Resource Scheduler) é a funcionalidade responsável por balancear a utilização dos recursos de um cluster VMware e também por escolher o melhor host para alocar uma VM no momento em que ela é ligada. Nas versões anteriores foram adicionadas algumas opções avançadas que permitiam ajustar a maneira como o DRS deveria balancear as VMs entre os hosts ESXi. Com o vSphere 6.5 algumas dessas opções foram adicionadas à interface gráfica para facilitar para os usuários que desejam tais alterações possam faze-las com mais segurança. Basicamente foram três novas opções:
VM Distribution
A primeira opção faz com que o DRS tente balancear as VMs de maneira mais igual entre os hosts ESXi de um cluster. Por padrão o DRS distribui as VMs em um cluster levando em conta mais a utilização dos recursos nos hosts, e tenta manter uma utilização próxima entre os hosts, independente do número de VMs. Essa opção, VM Distribution, corresponde à opção avançada TryBalanceVmsPerHost, que foi adicionada no vSphere 6.5 para tentar balancear o número de VMs nos hosts.
Por exemplo, muitas vezes acontece de existir uma VM muito grande em um cluster, algumas VMs médias e muitas VMs pequenas. Pode acontecer do DRS alocar a VM grande sozinha em um host e alocar outras dezenas de VMs menores em um outro host. Do ponto de vista da utilização dos recursos, esse cenário até poderá estar bem distribuído, porém do ponto de vista da disponibilidade das VMs, não está. Pois, enquanto a queda de um host pode resultar na indisponibilidade de uma única VM, a queda do outro pode resultar na indisponibilidade de dezenas de VMs.
Com a opção VM Distribution habilitada, cada host terá um limite de VMs “maxVMs”, calculado com base numa média de VMs por host. Esse limite será aplicado somente ao algoritmo de balanceamento de carga do DRS, no caso do algoritmo que define o melhor host na hora de ligar uma VM, esse limite poderá esse violado.
Memory Metric for Load Balancing
Por padrão o DRS utiliza a métrica de Active Memory na hora de balancear as VMs entre os hosts. A métrica Active Memory é resultado de um cálculo feito pelo VMkernel que leva em conta apenas as páginas de memória que foram recentemente acessadas pela VM. Alguns administradores preferem trabalhar com uma outra métrica chamada de Consumed Memory. Essa métrica é um pouco mais conservadora e leva em conta todas as páginas de memória que em algum momento já foram alocadas por uma VM. É por isso que geralmente a métrica Active Memory é inferior à Consumed Memory, que por sua vez é inferior, porém mais próxima, ao Configured VM Size.
A primeira opção faz com que o DRS tente balancear as VMs de maneira mais igual entre os hosts ESXi de um cluster. Por padrão o DRS distribui as VMs em um cluster levando em conta mais a utilização dos recursos nos hosts, e tenta manter uma utilização próxima entre os hosts, independente do número de VMs. Essa opção, VM Distribution, corresponde à opção avançada TryBalanceVmsPerHost, que foi adicionada no vSphere 6.5 para tentar balancear o número de VMs nos hosts.
Por exemplo, muitas vezes acontece de existir uma VM muito grande em um cluster, algumas VMs médias e muitas VMs pequenas. Pode acontecer do DRS alocar a VM grande sozinha em um host e alocar outras dezenas de VMs menores em um outro host. Do ponto de vista da utilização dos recursos, esse cenário até poderá estar bem distribuído, porém do ponto de vista da disponibilidade das VMs, não está. Pois, enquanto a queda de um host pode resultar na indisponibilidade de uma única VM, a queda do outro pode resultar na indisponibilidade de dezenas de VMs.
Com a opção VM Distribution habilitada, cada host terá um limite de VMs “maxVMs”, calculado com base numa média de VMs por host. Esse limite será aplicado somente ao algoritmo de balanceamento de carga do DRS, no caso do algoritmo que define o melhor host na hora de ligar uma VM, esse limite poderá esse violado.
Memory Metric for Load Balancing
Por padrão o DRS utiliza a métrica de Active Memory na hora de balancear as VMs entre os hosts. A métrica Active Memory é resultado de um cálculo feito pelo VMkernel que leva em conta apenas as páginas de memória que foram recentemente acessadas pela VM. Alguns administradores preferem trabalhar com uma outra métrica chamada de Consumed Memory. Essa métrica é um pouco mais conservadora e leva em conta todas as páginas de memória que em algum momento já foram alocadas por uma VM. É por isso que geralmente a métrica Active Memory é inferior à Consumed Memory, que por sua vez é inferior, porém mais próxima, ao Configured VM Size.
Como a própria opção descreve, alterar a métrica a ser utilizada pelo DRS para o balanceamento das VMs, de Active Memory para Consumed Memory só é recomendado para clusters onde não há over-committed de memória.
CPU Over-Commitment
Essa opção pode ser utilizada para controlar a taxa de sobre-alocação (over-commitment) de CPU em um cluster. Existem alguns casos em que os administradores precisem garantir uma determinada relação de vCPU:pCPU (num de CPUs virtuais por num de CPUs físicos), por conta de algum requisito de uma aplicação específica. Em ambientes VDI por exemplo, essa é uma questão bastante relevante.
- DRS – Network Aware
Uma outra novidade no vSphere 6.5 com relação ao DRS é a verificação da utilização de rede em um host na hora de alocar ou mover uma VM. Até então o DRS levava em conta somente os recursos de CPU e Memória de um host na hora de definir o melhor host para pôr uma VM quando ela fosse ligada e também na hora de balancear as VMs. Com isso poderia ocorrer de haver um host com baixa utilização de CPU/Mem e uma alta utilização de rede mas mesmo assim o DRS movimentar VMs para este host ou ligar uma VM nele, podendo causar um congestionamento no uplink, e consequentemente impactando no desempenho de todas as VMs em execução no host.
Com a implementação do Network Aware, o DRS passa a considerar a utilização da placa de rede física dos hosts ESXi, e quando estas apresentarem uma utilização superior a 80%, o DRS irá considerar este host como saturado e evitará ligar novas VMs neste host e também tentará resolver este problema de saturação,movimentando algumas VMs deste host para outros na execução do próximo ciclo do DRS.
- Predictive DRS
O Predictive DRS é uma nova funcionalidade do vSphere 6.5 que como o próprio nome sugere “prevê” a utilização de recursos do cluster e faz o balanceamento da carga (se necessário) antes. Para fazer isso, o DRS irá contar com a ajuda do vROPS (vRealize Operations). A versão do vROPS que terá suporte a essa funcionalidade deve sair até a metade do ano de 2017, portanto apesar dessa funcionalidade já estar embutida no código do vSphere 6.5, será necessário aguardar o lançamento da próxima versão do vROPS para utiliza-la.
O vROPS calcula e prevê a utilização dos recursos de CPU e Memória com base no histórico de dados que ele captura do vCenter. A partir daí o vROPS passa a calcular thresholds dinâmicos (Dynamic Thresholds), e quanto mais dados são capturados ao longo do tempo, essas previsões se tornam mais precisas, e com níveis mais elevados de confiança.
Em seguida essas previsões são enviadas para o DRS, que consome esses dados com antecedência (por padrão o DRS trabalha com 60 minutos de antecedência) e balanceia o cluster com base na utilização prevista. O benefício disso é que picos na utilização dos recursos poderão ser previstos e o balanceamento da carga ocorrerá antes que este pico ocorra, possibilitando um melhor desempenho do ambiente como um todo.
CPU Over-Commitment
Essa opção pode ser utilizada para controlar a taxa de sobre-alocação (over-commitment) de CPU em um cluster. Existem alguns casos em que os administradores precisem garantir uma determinada relação de vCPU:pCPU (num de CPUs virtuais por num de CPUs físicos), por conta de algum requisito de uma aplicação específica. Em ambientes VDI por exemplo, essa é uma questão bastante relevante.
- DRS – Network Aware
Uma outra novidade no vSphere 6.5 com relação ao DRS é a verificação da utilização de rede em um host na hora de alocar ou mover uma VM. Até então o DRS levava em conta somente os recursos de CPU e Memória de um host na hora de definir o melhor host para pôr uma VM quando ela fosse ligada e também na hora de balancear as VMs. Com isso poderia ocorrer de haver um host com baixa utilização de CPU/Mem e uma alta utilização de rede mas mesmo assim o DRS movimentar VMs para este host ou ligar uma VM nele, podendo causar um congestionamento no uplink, e consequentemente impactando no desempenho de todas as VMs em execução no host.
Com a implementação do Network Aware, o DRS passa a considerar a utilização da placa de rede física dos hosts ESXi, e quando estas apresentarem uma utilização superior a 80%, o DRS irá considerar este host como saturado e evitará ligar novas VMs neste host e também tentará resolver este problema de saturação,movimentando algumas VMs deste host para outros na execução do próximo ciclo do DRS.
- Predictive DRS
O Predictive DRS é uma nova funcionalidade do vSphere 6.5 que como o próprio nome sugere “prevê” a utilização de recursos do cluster e faz o balanceamento da carga (se necessário) antes. Para fazer isso, o DRS irá contar com a ajuda do vROPS (vRealize Operations). A versão do vROPS que terá suporte a essa funcionalidade deve sair até a metade do ano de 2017, portanto apesar dessa funcionalidade já estar embutida no código do vSphere 6.5, será necessário aguardar o lançamento da próxima versão do vROPS para utiliza-la.
O vROPS calcula e prevê a utilização dos recursos de CPU e Memória com base no histórico de dados que ele captura do vCenter. A partir daí o vROPS passa a calcular thresholds dinâmicos (Dynamic Thresholds), e quanto mais dados são capturados ao longo do tempo, essas previsões se tornam mais precisas, e com níveis mais elevados de confiança.
Em seguida essas previsões são enviadas para o DRS, que consome esses dados com antecedência (por padrão o DRS trabalha com 60 minutos de antecedência) e balanceia o cluster com base na utilização prevista. O benefício disso é que picos na utilização dos recursos poderão ser previstos e o balanceamento da carga ocorrerá antes que este pico ocorra, possibilitando um melhor desempenho do ambiente como um todo.
Outros posts sobre o que há de novo no vSphere 6.5:
O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)
O que há de novo no vSphere 6.5? - vSphere HA
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage
O que há de novo no vSphere 6.5? - Virtual SAN 6.5
O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)
O que há de novo no vSphere 6.5? - vSphere HA
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage
O que há de novo no vSphere 6.5? - Virtual SAN 6.5
O que há de novo no vSphere 6.5? - vSphere HA
Na semana passada, a VMware anunciou oficialmente a nova versão da sua plataforma de virtualização, o vSphere 6.5. O anúncio ocorreu na abertura da edição européia da VMworld 2016, que aconteceu em Barcelona entre os dias 17/10/16 e 20/10/16 , e trouxe muitas novidades.
Nesse post vou falar sobre as novidades do vSphere 6.5 com relação ao HA.
Depois de um bom tempo, finalmente a VMware anunciou algumas mudanças e/ou novidades relativas aos mecanismos do HA (High Availability).
- HA – Admission Control
O Admission Control é uma funcionalidade do HA utilizada para garantir que o cluster terá recursos suficientes para continuar atendendo às VMs no caso de falha em algum(s) hosts. Até então a configuração do Admission Control era de díficil entedimento para muitos, não é atoa que em muitos lugares ela não é nem utilizada, e isso não é nada bom. A maior dificuldade estava na hora de calcular o quanto de recursos seria necessário reservar para continuar atendendo às demandas das VMs sem que as mesmas viessem a sofrer quedas de desempenho.
Com o vSphere 6.5, a interface para configuração foi simplificada, e agora a política padrão passou a ser a “Cluster Resource Percentage”, ao invés da política baseada em slots.
Sobre a política padrão “Cluster Resource Percentage”, agora ela está completamente relacionada à opção “Host failures cluster tolerates”, ou seja, dependendo da quantidade de hosts que você estiver disposto a perder, a porcentagem de recursos reservados será automaticamente calculada. Por exemplo, suponha que o seu cluster possua 4 hosts, ao configurar a opção Host failures cluster tolerates=1, os valores reservados para CPU e Memória serão automaticamente setados em 25%. Se um novo host for adicionado ao cluster, esses valores também serão automaticamente ajustados para 20%.
Nesse post vou falar sobre as novidades do vSphere 6.5 com relação ao HA.
Depois de um bom tempo, finalmente a VMware anunciou algumas mudanças e/ou novidades relativas aos mecanismos do HA (High Availability).
- HA – Admission Control
O Admission Control é uma funcionalidade do HA utilizada para garantir que o cluster terá recursos suficientes para continuar atendendo às VMs no caso de falha em algum(s) hosts. Até então a configuração do Admission Control era de díficil entedimento para muitos, não é atoa que em muitos lugares ela não é nem utilizada, e isso não é nada bom. A maior dificuldade estava na hora de calcular o quanto de recursos seria necessário reservar para continuar atendendo às demandas das VMs sem que as mesmas viessem a sofrer quedas de desempenho.
Com o vSphere 6.5, a interface para configuração foi simplificada, e agora a política padrão passou a ser a “Cluster Resource Percentage”, ao invés da política baseada em slots.
Sobre a política padrão “Cluster Resource Percentage”, agora ela está completamente relacionada à opção “Host failures cluster tolerates”, ou seja, dependendo da quantidade de hosts que você estiver disposto a perder, a porcentagem de recursos reservados será automaticamente calculada. Por exemplo, suponha que o seu cluster possua 4 hosts, ao configurar a opção Host failures cluster tolerates=1, os valores reservados para CPU e Memória serão automaticamente setados em 25%. Se um novo host for adicionado ao cluster, esses valores também serão automaticamente ajustados para 20%.
Se você reparar bem na imagem acima, existe uma nova opção de configuração chamada “Performance degradation VMs tolerate”. Com essa opção é possível setar quantos % de degradação de desempenho será tolerado nas VMs do cluster. Com base no valor configurado, um alerta poderá ser gerado quando, após uma falha, não houver capacidade suficiente para garantir o mesmo nível de desempenho às VMs. Por padrão esse valor é 100%.
- HA Orchestrated Restart
A principal função do HA é garantir que as VMs estejam sempre disponíveis, por isso ao detectar uma falha em um host, o principal objetivo do HA passa a ser religar o quanto antes as VMs, que estavam no host que falhou, nos demais hosts que permaneceram disponíveis. Infelizmente, nem sempre o fato de religar as VMs em outros hosts significava que uma aplicação voltaria funcionar. Esse era o cenário encontrado no caso das aplicações Multi-tier, por exemplo com uma VM para Web-Server, uma para App e uma para BD, se o HA ligasse a VM de App antes da VM do BD, é provável que a aplicação não subiria corretamente e uma intervenção manual seria necessária, aumentando o tempo de recuperação do ambiente.
No vSphere 6.5 foi adicionada uma funcionalidade chamada de HA Orchestrated Restart, que permitirá a criação de grupos de VMs e de regras que irão controlar a ordem com que as VMs nestes grupos serão ligadas.
- HA Orchestrated Restart
A principal função do HA é garantir que as VMs estejam sempre disponíveis, por isso ao detectar uma falha em um host, o principal objetivo do HA passa a ser religar o quanto antes as VMs, que estavam no host que falhou, nos demais hosts que permaneceram disponíveis. Infelizmente, nem sempre o fato de religar as VMs em outros hosts significava que uma aplicação voltaria funcionar. Esse era o cenário encontrado no caso das aplicações Multi-tier, por exemplo com uma VM para Web-Server, uma para App e uma para BD, se o HA ligasse a VM de App antes da VM do BD, é provável que a aplicação não subiria corretamente e uma intervenção manual seria necessária, aumentando o tempo de recuperação do ambiente.
No vSphere 6.5 foi adicionada uma funcionalidade chamada de HA Orchestrated Restart, que permitirá a criação de grupos de VMs e de regras que irão controlar a ordem com que as VMs nestes grupos serão ligadas.
A imagem acima exemplifica bem como o Orchestrated Restart funciona. Neste caso 3 grupos de VMs seriam criados. O grupo 1 com a VM de BD, o grupo 2 com a VM de App e o grupo 3 com a VM de Web. Em seguida duas regras seriam criadas, a primeira configurando a dependência do grupo 2 ao grupo 1, ou seja, a VM do grupo 2 só vai ligar após a VM do grupo 1. A segunda regra configuraria a dependência do grupo 3 ao grupo 2, o que fará com que a VM do grupo 3 só seja ligada após a VM do grupo 2.
O tempo de espera entre o ligamento das VMs dependerá da configuração da opção “VM Dependency Restart Condition”.
- Proactive HA
Uma nova funcionalidade adicionada ao vSphere 6.5 é o Proactive HA. O Proactive HA, apesar de ter HA no nome e aparecer na seção vSphere Availability na interface gráfica, é na verdade uma funcionalidade do DRS. O principal objetivo do Proactive HA é agir quando ocorrer algum evento no host que possa vir a gerar algum tipo de indisponibilidade no host e consequentemente nas VMs.
Para que isso seja possível, o Proactive HA trabalhará em conjunto com o software de monitoramento de hardware dos fabricantes de servidores (Health Provider), através de um plugin para o WebClient, que fornecerá detalhes sobre a saúde e o status do servidor para o DRS, o qual reagirá de acordo com o status do hardware do host.
Dentre os status possíveis que o Health Provider pode informar ao vCenter Server estão: Healthy, Moderate Degradation, Severe Degradation e Unknown. A definição de quais eventos resultarão em quais status caberá ao fabricante de hardware.
Com base no status indicado o DRS poderá alterar o mode de operação do host para “Maintenance Mode” ou “Quarantine Mode”.
O Maintanence Mode já existia anteriormente e o funcionamento é o mesmo, ou seja, todas as VMs serão migradas para fora do host.
No caso do Quarantine Mode, este modo é novo no vSphere 6.5 e só é ativado através do Proactive HA, não é possível habilita-lo/desabilita-lo manualmente como pode ser feito com o Maintenance Mode. Quando o Quarantine Mode é habilitado não necessáriamente todas as VMs serão migradas para fora do host, existem dois casos nos quais as VMs permanecerão no host:
1. Caso não haja recursos suficientes nos demais hosts para migrar as VMs sem que o desempenho das demais máquinas virtuais do cluster sejam impactadas;
2. Caso exista alguma regra de afinidade do DRS (VM/VM ou VM/Host) que impeça a migração da VM;
O tempo de espera entre o ligamento das VMs dependerá da configuração da opção “VM Dependency Restart Condition”.
- Proactive HA
Uma nova funcionalidade adicionada ao vSphere 6.5 é o Proactive HA. O Proactive HA, apesar de ter HA no nome e aparecer na seção vSphere Availability na interface gráfica, é na verdade uma funcionalidade do DRS. O principal objetivo do Proactive HA é agir quando ocorrer algum evento no host que possa vir a gerar algum tipo de indisponibilidade no host e consequentemente nas VMs.
Para que isso seja possível, o Proactive HA trabalhará em conjunto com o software de monitoramento de hardware dos fabricantes de servidores (Health Provider), através de um plugin para o WebClient, que fornecerá detalhes sobre a saúde e o status do servidor para o DRS, o qual reagirá de acordo com o status do hardware do host.
Dentre os status possíveis que o Health Provider pode informar ao vCenter Server estão: Healthy, Moderate Degradation, Severe Degradation e Unknown. A definição de quais eventos resultarão em quais status caberá ao fabricante de hardware.
Com base no status indicado o DRS poderá alterar o mode de operação do host para “Maintenance Mode” ou “Quarantine Mode”.
O Maintanence Mode já existia anteriormente e o funcionamento é o mesmo, ou seja, todas as VMs serão migradas para fora do host.
No caso do Quarantine Mode, este modo é novo no vSphere 6.5 e só é ativado através do Proactive HA, não é possível habilita-lo/desabilita-lo manualmente como pode ser feito com o Maintenance Mode. Quando o Quarantine Mode é habilitado não necessáriamente todas as VMs serão migradas para fora do host, existem dois casos nos quais as VMs permanecerão no host:
1. Caso não haja recursos suficientes nos demais hosts para migrar as VMs sem que o desempenho das demais máquinas virtuais do cluster sejam impactadas;
2. Caso exista alguma regra de afinidade do DRS (VM/VM ou VM/Host) que impeça a migração da VM;
Como pode ser visto na imagem acima, é possível configurar diferentes respostas para diferentes tipos de falhas, por exemplo Quarantine Mode para falhas que resultem em um status Moderate Degradation e Maintanence Mode para falhas que resultem em Severe Degradation.Outros posts sobre o que há de novo no vSphere 6.5:
O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)
O que há de novo no vSphere 6.5? - vSphere DRS
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage
O que há de novo no vSphere 6.5? - Virtual SAN 6.5
Assinar:
Postagens (Atom)