A virtualização de um servidor significa outra camada do sistema operacional para correção e atualização, mais trabalho e maior risco?

Fiz uma pesquisa e não encontrei nada que resolvesse problemas relacionados a patches e atualizações do sistema. Eu tenho diretrizes que dizem que os servidores precisam ter os patches necessários. Se eu tenho um host de VM, isso é uma camada extra para corrigir e atualizar - mesmo com hipervisores bare metal? Ao contrário de ter um servidor de metal? (ou seja, mais trabalho, testes e documentação, de acordo com minhas diretrizes).

Com que frequência os hipervisores tipo 1 / bare-metal são atualizados? Isso importa? O fato de ser uma camada extra de software introduz mais complexidade e risco (segurança e confiabilidade)? (por exemplo, 99% de software livre de erros x 99% de software livre de erros = 98% sistema livre de erros)?

(Minha experiência prática é com VMWare Workstation and Server e VirtualBox.)

Sim, às vezes, produtos como o VMware devem ser corrigidos ( as atualizações são cumulativas ), mas os patches vêm com menos frequência do que um sistema operacional principal e o potencial vetor de ataque é menor - seu hipervisor não deve estar acessível ao público .

Vou usar o VMware ESXi versão 5.0 (não 5.1) como exemplo ...

O ESXi 5.0 teve o seguinte agendamento de atualização:

Entre 9/2011 e o presente, houve dez atualizações no produto ESXi 5.0. Dessas , SIX foram atualizações com foco em segurança, incluídas nos pacotes de atualizações com descrições como:

"Vulnerabilidade de análise de tráfego do ESXi NFS" - CVE-2012-2448 .

Essas vulnerabilidades de segurança são reais, pois às vezes refletem os bugs gerais de segurança do Linux, mas acho que a maioria das organizações não é muito suscetível aos riscos. Cabe ao engenheiro avaliar esse risco, no entanto. Seus usuários desejam um tempo de inatividade maciço para corrigir a seguinte exploração ?

"A macro encode_name em misc / mntent_r.c na GNU C Library (também conhecida como glibc ou libc6) 2.11.1 e anterior, conforme usada pelo ncpmount e mount.cifs, não manipula corretamente os caracteres de nova linha nos nomes dos pontos de montagem, o que permite aos usuários locais causar uma negação de serviço (corrupção do mtab) ou possivelmente modificar opções de montagem e obter privilégios por meio de uma solicitação de montagem criada ".

Talvez? Talvez não.

Eu executo o Update Manager da VMware , mas só tento atualizar se sou afetado por um bug ou requer um aprimoramento de recurso. Quando executado em uma instalação em cluster, é fácil aplicar patches sem tempo de inatividade nas VMs em execução. Se não houver outros motivos urgentes, tentarei atualizar trimestralmente. Hosts individuais exigirão uma reinicialização completa, pois os patches são entregues como imagens monolíticas.

Como observação lateral, sempre que herdo uma configuração do VMware ESXi ou trabalho em um sistema que normalmente não gerencio, geralmente vejo hosts em execução que nunca tiveram nenhum patch do VMware aplicado. Isso esta errado!! Mas posso ver como os administradores podem cometer esse erro quando os sistemas estiverem em funcionamento.

Essa é uma boa pergunta se você é novo na virtualização com hosts 'bare metal'. Fazer as coisas dessa maneira requer uma mentalidade diferente da abordagem que você pode adotar com os hipervisores que são executados como um serviço / aplicativo em cima de um sistema operacional convencional.

Na minha experiência, provavelmente é justo dizer que o ESX e o HyperV precisam de menos correções em geral do que os sistemas operacionais convencionais. Isso não significa que eles não precisam de nenhum patch ou que a aplicação de alguns patches não seria benéfica, independentemente da "necessidade", mas isso significa que as interrupções em seus serviços para corrigir o host devem ser menos frequentes e mais sob seu controle. Existe um risco potencial de segurança para os SOs do hipervisor, assim como para qualquer outro, e enquanto você pode minimizar a exposição desse risco (por exemplo, expor apenas o gerenciamento do hipervisor em uma VLAN isolada que não pode ser logicamente alcançada a partir de um servidor comprometido) seria tolice fingir que não há risco algum.

Portanto, se você tem 4 servidores não virtuais, por exemplo, e os move para o mesmo host virtualizado individual, sim, você está aumentando a quantidade de interrupções que podem ser causadas pela necessidade de corrigir o sistema host (ou lidar com um problema de hardware etc.).

Enquanto eu sugiro a chance de isso ocorrendo risco é relativamente baixo (estou falando da diferença entre remendar um host virtual e o tipo de patch que requer um reinício que você teria que fazer para um sistema autônomo de qualquer maneira ), não há como fugir do fato de que o impacto é alto.

Então, por que fazemos isso então?

O verdadeiro benefício da virtualização vem de poder configurar mais de um host e configurar os hosts para trabalharem em conjunto, permitindo que os convidados sejam movidos de um host para outro no caso de um host falhar ou no qual você deseja agendar correções. os sistemas host.

Usando essa abordagem, consegui corrigir 5 hosts ESX, por sua vez, sem nenhuma interrupção nos 40 servidores virtuais em execução em cima deles. Isso é simplesmente uma questão de economia de escala - uma vez que você tem máquinas virtuais convidadas em potencial suficientes para compor esse tipo de configuração complexa e gerenciá-la com o tipo de ferramentas que @ewwhite menciona em sua resposta, a recompensa em reduzir os riscos você está preocupado em chegar muito rapidamente.

Um servidor virtual exigirá a mesma manutenção e correções que um servidor físico, os hipervisores bare metal exigirão atualizações, por segurança, mas também para corrigir bugs e melhorar o desempenho. Quanto mais servidores você tiver, mais trabalho será necessário para mantê-los atualizados, não importa se eles são físicos ou virtuais.

Com base nas respostas acima, parece: A virtualização de um servidor introduziu mais complexidade e risco em segurança e confiabilidade, mas elas precisam ser comparadas aos benefícios de poder reduzir o tempo de inatividade ao virtualizar um servidor.

Se o seu ambiente exigir auditoria, testes e documentação, o custo-benefício da carga de trabalho adicional de um ambiente virtualizado deverá ser levado em consideração com o número de servidores e equipe de sistemas que você possui. Em nosso ambiente, não temos tempo para manter a trilha de auditoria de um ambiente virtualizado. Em nossos processos de negócios, podemos ter algum tempo de inatividade, mas não podemos perder uma trilha de auditoria e documentação.