Fala galera, 100%?!

Antes de escrever esse artigo estava revisando o material que uso em sala para disciplina de Sistemas Operacionais (sim, sou professor a alguns anos…do tipo carrasco xD) e quando cheguei na parte em que falava sobre Kernel pensei: Por que não escrever um pouco sobre o kernel do Hyper-V!? Dei uma revisada também nos conceitos, juntei alguns livros e artigos que já havia estudado e pronto começou a digitação \,,/.

Para fala sobre esse tema é importante definir o que é o bendito Kernel. Se formos consultar lá com o mestre dos magos tanembaum veremos que ele define Kernel como sendo o coração do sistema, onde todas as funções triviais para uma máquina, mas complexas para nós, acontecem. O mundo abstrato da computação começa no Kernel (ou núcleo, se assim preferir). Ele é responsável por manter funções de mais baixo nível em um sistema computacional tipo instruções e CPU, memória e por ai vai. Se curtiu e quer saber um pouco mais sobre Sistemas Operacionais de fato, me avisa deixando um comentário aqui ou em qualquer rede social. Se preferir também pode me enviar um e-mail: [email protected]. Eu tenho um material bacana sobre o assunto.

Ok…agora já sabemos o que o tal Kernel faz e por que existe. Hypervisors do tipo 1 (você vai entender melhor lendo este artigo e depois esse) podem trabalhar com dois tipos de arquitetura. Essa arquitetura é definida pelo tipo de kernel que cada uma usa. Hoje temos duas opções: Kernel Monolítico ou Microkernel. Tratarei sobre a diferença de ambas apontando vantagens e desvantagens a nível de performance e segurança, que, ao meu ver, são os principais fatores independente da solução.

Começando pelo Kernel Monolítico. Esse cara tem por característica maior complexidade, alguns autores destacam que é um mini-sistema operacional. Os drivers necessários para comunicação com o hardware são armazenados no próprio Hypervisor onde as VMS, por sua vez, fazem uso acessando-os (os drivers) diretamente pelo Hypervisor. Essa abordagem garante uma performance superior por conta da “proximidade” e “facilidade” de acesso VM > Drivers. Como nem tudo são flores, com esse tipo de arquitetura a compatibilidade passa a ser mais restrita visto que os drivers devem ser escritos para o hypervisor especificamente. Um lance que muitos apontam é o fator segurança. Pense comigo: Todos os drivers ficam alocados no próprio hypervisor e são compartilhados entre as VMs. Se eu, por engano, realizar uma atualização de driver e esta atualização contiver um erro, quem será afetado?! TODAS AS VMS!!! Lembra que os drivers fazem parte do hypervisor, logo, todas as VMs fazem uso. Esse é um grande ponto a ser considerado. Qualquer modificação incorreta, erro de código e/ou até mesmo um vírus inserido no código do driver podem e provavelmente vão afetar drasticamente seu ambiente como um todo.

Já o tal do microkernel, diferente das soluções monolíticas que mantem os drivers junto ao Hypervisor, mantem uma partição de gerenciamento onde o controle de acesso e drivers é realizado. Esse tipo de abordagem garante um range maior de hardwares compatíveis, visto que nenhum deles é feito exclusivamente para o hypervisor. Como você já deve ter pegado no ar, o Hyper-V utiliza esse tipo de arquitetura. Repare que a quantidade de hardware compatível com o Hyper-v é enorme, tão grande quanto os compatíveis com o Windows Server. A ideia é que, quem já fez drivers para o Windows Server, não precise reescrever ele especificamente para o Hyper-V.

Outra característica interessante está voltado a segurança. O fato de se utilizar uma partição de gerenciamento cria uma camada de isolamento. Nas plataformas monolíticas o erro ou código malicioso injetado no driver poderia impactar todas as maquinas virtuais por conta do compartilhamento total existente, em arquitetura microkernalizadas o erro de um driver não necessariamente afetará todas as VMs, visto que nada é mantido junto ao Hypervisor e sim na partição de gerenciamento.

Obviamente, nem tudo são flores, a questão performance perde um pouco com isso (pouco mesmo). Existe um processo para que as vms acessem recursos e drivers necessários que exige um processamento a mais (falaremos mais sobre esse processo em um artigo futuro). Neste tipo de arquitetura o hypervisor meio que é responsável pela gestão de CPU e memória apenas.

E ai, entendido? Espero que tenha te ajudado a entender um pouco mais sobre a arquitetura de nosso querido Hyper-V!

Aproveite e se inscreva no site para receber os artigos por e-mail….Grande abraço \o