Teoria Geral e Arqueologia da Virtualização x86

1. Introdução

Equipe de autores

Postado por Anton Zhbankov ( AntonVirtual , cloudarchitect.cc )
Co-autores: Grigory Pryalukhin , Evgeny Parfenov

Conceitos gerais de virtualização

Eu tive que ver muitas interpretações do que é a virtualização e ouvir muita controvérsia, nem um pouco mais perto de discutir o resultado prático. E como você sabe, o argumento de duas pessoas inteligentes se resume a um debate sobre definições. Vamos definir o que é virtualização e o que vem dela.

Provavelmente, a definição mais próxima de virtualização será "abstração" da programação orientada a objetos. Ou, se traduzido para o russo normal, isso está ocultando a implementação por trás de uma interface abstrata. O que, é claro, explicava tudo de uma vez. Vamos tentar novamente, mas para aqueles que não estudaram programação.

Virtualização - oculta uma implementação específica por trás de um método universal padronizado de acesso a recursos / dados.

Se você tentar colocar essa definição em prática, ela funcionará em assuntos completamente inesperados. Vamos dizer o relógio. Assim, um relógio de sol foi inventado há vários milhares de anos e, na Idade Média, um mecânico foi inventado. O que há em comum? O sol e algumas engrenagens? Algum tipo de bobagem. E então osciladores de quartzo e tudo mais.
A linha inferior é que temos uma interface padrão - um ponteiro ou ponteiro digital, que em uma forma padrão universal indica a hora atual. Mas importa para nós como especificamente esse mecanismo é implementado dentro da caixa, se o tempo é indicado com precisão suficiente para nós?
“Deixe-me”, você pode dizer, “mas eu pensei que a virtualização fosse sobre máquinas, processadores e assim por diante!
Sim, trata-se de carros e processadores, mas este é apenas um caso especial. Vejamos de maneira mais ampla, uma vez que o artigo afirma corajosamente uma teoria geral.

POZOR!

Uwaga! Achtung! Pozor!

Este artigo tem um objetivo educacional geral de vincular um monte de tecnologias e palavras assustadoras, juntamente com a história, a uma determinada estrutura e, devido a essa circunstância, contém uma quantidade significativa de simplificações intencionais . Obviamente, ele também contém um grande número de omissões irritantes e até mesmo erros brutos com erros de digitação. A crítica construtiva só é bem-vinda, especialmente na forma de "Deixe-me lhe lembrar esta parte".

Tipos de virtualização

Voltemos dos conceitos completamente abstratos aos mais familiares aos nossos computadores amados.

Virtualização de armazenamento

O primeiro, provavelmente, é o tipo de virtualização que um nerd iniciante encontra - virtualização de um sistema de armazenamento de dados. Nesse caso, o sistema de armazenamento é usado não no sentido de uma grande matriz com discos conectados via canal de fibra, mas como um subsistema lógico responsável pelo armazenamento de dados a longo prazo.

FS -> LBA -> CHS

Veja o caso mais simples de um sistema de armazenamento em um único disco magnético rígido. O formato usual para trabalhar com dados são os arquivos que estão na unidade lógica. O arquivo pode ser aberto, lido e fechado. Mas um objeto como um arquivo simplesmente não existe fisicamente - existe apenas uma maneira de acessar determinados blocos de dados usando o método de endereçamento no formato “drive: \ folder1 \ folder2 \ file”. I.e. conhecemos a primeira camada de virtualização - de mnemônico e compreensível a humanos, traduzimos tudo em endereços compreensíveis do sistema. Nas tabelas de metadados, o driver do sistema de arquivos procura por quais tipos de blocos de dados existem e obtemos o endereço no sistema LBA (Logical Block Addressing). No sistema LBA, os blocos têm um tamanho fixo e se seguem linearmente, ou seja, de alguma forma, pode ter a ver com o armazenamento de dados em fita magnética, mas o disco rígido é de alguma forma completamente diferente! E aqui vamos para a segunda camada de virtualização - tradução do endereçamento LBA para CHS (cilindro / cabeçote / setor).



O CHS, por sua vez, já no controlador de disco rígido começa a se traduzir em parâmetros físicos para leitura, mas essa é uma história completamente diferente.
Mesmo em um acesso simples ao arquivo para, digamos, visualizar um vidosik com memasics, encontramos três camadas de virtualização imediatamente.
Tudo seria muito simples se as camadas não começassem a se sobrepor em ordem aleatória e de várias maneiras.

RAID

A próxima camada de virtualização, que muitas pessoas erradamente consideram não ser virtualização, é o RAID (matriz redundante de discos independentes / baratos).

O principal recurso do RAID no contexto dos conceitos discutidos não é sua capacidade de proteger dados contra a falha de um disco físico específico. O RAID fornece um segundo nível de endereçamento LBA sobre vários endereços LBA independentes (às vezes muitos). Como podemos acessar o RAID, independentemente do nível RAID, exatamente da mesma maneira que um único disco sem RAID, podemos dizer com confiança:

RAID é virtualização de disco.

Além disso, o controlador RAID não cria apenas um grande disco virtual a partir de vários discos físicos, mas pode criar um número arbitrário deles adicionando outra camada de virtualização.

Ver virtualização

O próximo tipo de virtualização, que muitos de nós usamos quase todos os dias, mas não consideramos virtualização, é uma conexão remota à área de trabalho.

Servidores de terminal, VDI e até apenas RDP via VPN para o servidor são todos virtualização de sessão. Usando uma interface padrão (monitor, teclado, mouse), trabalhamos com uma máquina real ou com um design incompreensível de uma área de trabalho virtual em um clone vinculado a um aplicativo em contêiner, do qual transferimos dados através de um buffer para um aplicativo com entrega de streaming. Ou não, quem descobrirá, além de quem o projetou?

Introdução à virtualização x86

Histórico e visão geral dos processadores

Execução do programa

Na primeira lição de um curso especial de programação, Vladimir Denisovich Lelyukh (descanse em paz para ele) disse aos alunos: o computador, apesar do nome, não pode contar, pode fingir que pode contar. Mas se algo parece um pato, anda como um pato e grasna como um pato, de um ponto de vista prático, é um pato.

Vamos tentar lembrar disso para uso prático adicional.

O computador, e especificamente o processador, na verdade não faz nada - apenas espera alguns parâmetros de entrada em determinados lugares e, em seguida, através de uma terrível magia negra, fornece alguns resultados em determinados locais.

Um programa nesse caso é um certo fluxo de comandos executados estritamente em sequência, como resultado do qual esperamos ver um determinado resultado.
Mas se o programa estiver em execução, como os dados podem ser inseridos? E, em geral, de alguma forma, interagir em um computador?

Para isso, as interrupções de hardware foram inventadas. O usuário pressiona uma tecla - o controlador do teclado sinaliza isso e há uma interrupção na execução do encadeamento de código atual. Os endereços dos manipuladores de interrupção são registrados em uma área de memória específica e, após salvar o estado atual, o controle é transferido para o manipulador de interrupção. Por sua vez, o manipulador deve, em teoria, processar tudo rapidamente, depois ele e o manipulador, anotam a tecla pressionada no buffer desejado e retornam o controle novamente. Assim, o aplicativo parece estar em execução e podemos interagir com o sistema.

Manipuladores de interrupção (e o principal tipo de manipuladores são drivers de dispositivo) têm a oportunidade de entrar em um modo de processador especial, quando outras interrupções não podem ser implementadas antes de sair desse modo. O que no final muitas vezes levava a um problema de suspensão - um erro no driver não permitia sair da interrupção.

Multitarefa

O que fazer em uma situação se for necessário executar vários programas (fluxos de código com suas estruturas de dados e memória) ao mesmo tempo? Obviamente, se houver mais fluxos de código do que dispositivos capazes de executá-los, isso é um problema.

A pseudo-multitarefa aparece quando uma tarefa é executada ao alternar diretamente para ela.

No futuro, uma cooperativa (multitarefa não-preemptiva) aparece - a própria tarefa executável entende que não precisa mais de recursos do processador e dá controle a outra pessoa. Mas tudo isso não é suficiente.

E aqui novamente interrupções + capacidade de fingir vir em nosso socorro. Realmente não importa para o usuário que eles sejam executados estritamente simultaneamente, basta parecer assim.
Portanto, um manipulador é simplesmente desligado para interromper o cronômetro, que começa a controlar qual fluxo de código deve ser executado a seguir. Se o timer for acionado com bastante frequência (digamos 15ms), então para o usuário tudo parecerá uma operação paralela. E, portanto, há uma multitarefa moderna de exclusão.

Modo real

O modo de processador real neste artigo pode ser descrito de maneira simples - toda a memória está disponível para todos. Qualquer aplicativo, incluindo malware (malware, software malicioso), pode acessar em qualquer lugar, tanto para leitura quanto para gravação.

Esse é o modo inicial de operação da família de processadores Intel x86.

Modo protegido

Em 1982, surgiu uma inovação no processador Intel 80286 (a seguir simplesmente 286) - um modo de operação protegido, que trouxe inovações na organização do trabalho com memória (por exemplo, alocação de tipos de segmentos de memória - código, dados, pilha). Mas a coisa mais importante que o processador 286 trouxe para o mundo x86 é o conceito de anéis de proteção, que ainda usamos.

O conceito de anéis de proteção apareceu originalmente no Multics OS para o mainframe GE645 (1967) com uma implementação parcialmente de software e com hardware completo já em 1970 no sistema Honeywell 6180.



A idéia básica dos anéis de defesa se assemelha a fortalezas medievais de vários níveis; a mais valiosa fica no centro atrás das múltiplas muralhas. Nesse caso, o mais valioso é o acesso direto ilimitado a qualquer área da RAM e o controle sobre todos os processos. Eles são possuídos por processos que operam no anel zero de proteção. Atrás da parede, no primeiro toque, processos menos importantes funcionam, como drivers de dispositivo e, finalmente, aplicativos de usuário. O princípio é simples - de dentro você pode sair, mas de fora para dentro é proibido. I.e. nenhum processo do usuário pode acessar a memória do kernel do SO, como era possível no modo real anteriormente.

Na primeira implementação completa do Honeywell 6180, 8 anéis de proteção foram implementados, mas a Intel decidiu simplificar o circuito para 4, dos quais, na prática, os fabricantes de sistemas operacionais começaram a usar apenas dois - zero e terceiro.

32bit

Em 1985, foi lançado outro processador extremamente importante de arquitetura na linha x86 - 80386 (doravante 386), que implementava o endereçamento de memória de 32 bits e usava instruções de 32 bits. E, claro, virtualização de memória. Como já mencionado, a virtualização é a ocultação da implementação real por meio do fornecimento de recursos "virtuais" artificiais. Nesse caso, estamos falando sobre endereçamento de memória. O segmento de memória tem seu próprio endereçamento, o que não tem nada a ver com a localização real das células de memória.
O processador acabou sendo tão requisitado que foi produzido antes de 2007.
A arquitetura em termos da Intel é chamada IA32.

64bit

Obviamente, mesmo sem virtualização em meados dos anos 2000, o setor já estava atingindo os limites de 32 bits. Havia soluções alternativas parciais na forma de PAE (Extensão de Endereço Físico), mas complicaram e desaceleraram o código. A transição para 64 bits foi uma conclusão precipitada.

A AMD apresentou sua versão da arquitetura, chamada AMD64. Na Intel, eles esperavam a plataforma IA64 (Intel Architecture 64), que também conhecemos com o nome Itanium. No entanto, o mercado atendeu a essa arquitetura sem muito entusiasmo e, como resultado, a Intel foi forçada a implementar seu próprio suporte às instruções AMD64, primeiro denominadas EM64T e depois apenas Intel 64.

Por fim, todos conhecemos essa arquitetura como AMD64, x86-64, x86_64 ou, às vezes, x64.

Como o principal uso de servidores da época era físico, sem virtualização, uma coisa técnica engraçada aconteceu com os primeiros processadores de 64 bits na virtualização. Os hipervisores aninhados eram frequentemente usados ​​como servidores de laboratório; nem todos podiam pagar vários agrupamentos de servidores físicos. E, no final, descobriu-se que a VM de carga no hipervisor incorporado só poderia funcionar no modo de 32 bits.

Nos primeiros processadores x86-64, os desenvolvedores, mantendo total compatibilidade com o modo operacional de 32 bits, descartaram uma parte significativa da funcionalidade no modo de 64 bits. Nesse caso, o problema era simplificar bastante a segmentação da memória. A capacidade de garantir a inviolabilidade de um pequeno pedaço de memória na VM em que o manipulador de exceção do hypervisor funcionava foi removida. Consequentemente, o sistema operacional convidado conseguiu modificá-lo.
Posteriormente, a AMD retornou a possibilidade de limitar segmentos, e a Intel simplesmente esperou pela introdução da virtualização de hardware.

UMA

Os sistemas multiprocessadores X86 começaram a trabalhar no modo UMA (Acesso uniforme à memória), no qual a distância de qualquer processador (atraso no acesso a uma célula de memória) a qualquer barra de memória é a mesma. Nos processadores Intel, esse esquema de trabalho foi preservado mesmo após o surgimento de processadores com vários núcleos até a geração 54xx (Harpertown). Começando com a geração 55xx (Nehalem), os processadores mudaram para a arquitetura NUMA.

Do ponto de vista da lógica de execução, essa é a aparência de encadeamentos de hardware adicionais, nos quais você pode atribuir fluxos de código para execução em paralelo.

NUMA

NUMA (acesso não uniforme à memória) - arquitetura com acesso desigual à memória. Dentro dessa arquitetura, cada processador possui sua própria memória local, que é acessada diretamente com baixa latência. A memória de outros processadores é acessada indiretamente com atrasos mais altos, o que resulta em desempenho reduzido.

Para os processadores Intel Xeon Scalable v2 de 2019, a arquitetura interna ainda permanece UMA no soquete, transformando-se em NUMA para outros soquetes (embora não seja realmente, e apenas finge ser). Os processadores Opteron da AMD tinham arquitetura NUMA mesmo durante o UMA Xeon mais antigo e, em seguida, o NUMA ficou dentro do soquete até a última geração de Roma, na qual retornaram ao NUMA = soquete.

Máquina virtual

Máquina virtual , a plataforma host) ou virtualizar alguma plataforma e criar ambientes que isolem programas e até sistemas operacionais uns dos outros. Wikipedia
Neste artigo, vamos dizer "máquina virtual", significando "máquinas virtuais do sistema", permitindo simular completamente todos os recursos e hardware na forma de construções de software.
Existem dois tipos principais de software para criar máquinas virtuais - com full e resp. virtualização incompleta.

A virtualização completa é uma abordagem na qual todo o hardware, incluindo o processador, é emulado. Permite criar ambientes independentes de hardware e executar, por exemplo, o SO e o software aplicativo para a plataforma x86 nos sistemas SPARC ou os conhecidos emuladores Spectrum com o processador Z80 no familiar x86. O outro lado da total independência é a alta sobrecarga para virtualizar o processador e o baixo desempenho geral.

A virtualização incompleta é uma abordagem na qual nem 100% do hardware é virtualizado. Como a virtualização incompleta é a mais comum no setor, falaremos sobre isso. Sobre plataformas e tecnologias de máquinas virtuais do sistema com virtualização incompleta para a arquitetura x86. Nesse caso, há virtualização incompleta do processador, ou seja, com exceção da substituição parcial ou ocultação de determinadas chamadas do sistema, o código binário da máquina virtual é executado diretamente pelo processador.

Virtualização de software

A conseqüência óbvia da arquitetura do processador e os hábitos dos sistemas operacionais de trabalhar no anel zero foi o problema - o kernel do sistema operacional convidado não pode funcionar no local habitual. O anel zero é ocupado pelo hipervisor, e você só precisa deixar o sistema operacional convidado chegar lá - por um lado, retornamos ao modo real com todas as consequências e, por outro lado, o sistema operacional convidado não espera ninguém lá, destruindo instantaneamente todas as estruturas de dados e largando o carro.

Mas tudo foi decidido com simplicidade: como para o hypervisor, o SO convidado é apenas um conjunto de páginas de memória com acesso direto total e o processador virtual é apenas uma fila de comandos, por que não reescrevê-los? Imediatamente, o hipervisor lança fora da fila de instruções para execução no processador virtual todas as instruções que requerem privilégios de toque zero, substituindo-as por menos privilegiadas. Mas o resultado dessas instruções é apresentado exatamente da mesma maneira como se o sistema operacional convidado estivesse no anel zero. Assim, você pode virtualizar qualquer coisa, até a completa ausência de um sistema operacional convidado.
Essa abordagem foi implementada pela equipe de desenvolvimento em 1999 no produto VMware Workstation e, em 2001, nos hipervisores do servidor GSX (o segundo tipo, como Workstation) e ESX (o primeiro tipo).

Paravirtualização

A paravirtualização é um conceito muito simples, que pressupõe que o SO convidado saiba que está em uma máquina virtual e saiba como acessar o SO host para determinadas funções do sistema.Isso elimina o problema de emulação do anel zero - o sistema operacional convidado sabe que não está no zero e se comporta de acordo.
A para-virtualização em x86 apareceu em 2003 com o projeto Linux Xen.

Certas funções paravirtualizadas também são implementadas em hipervisores com virtualização completa por meio de drivers virtuais especiais em sistemas operacionais convidados que se comunicam com o hipervisor para reduzir a sobrecarga da virtualização. Por exemplo, o VMware ESXi for VMs possui um adaptador SCSI paravirtual PVSCSI, que melhora o desempenho geral de VMs com operações intensivas de disco, como DBMSs carregados. Os drivers para dispositivos paravirtuais vêm em pacotes adicionais (por exemplo, VMware Tools) ou já estão incluídos nas distribuições Linux (open-vm-tools).

Virtualização de hardware

Com o desenvolvimento e o crescimento da popularidade da virtualização, surgiu o desejo de ambos os fabricantes de plataformas reduzirem os custos de suporte e, do ponto de vista da segurança, garantir a proteção no hardware.

O problema foi resolvido de uma maneira muito simples - as tecnologias de virtualização de hardware proprietárias Intel VT-x e AMD-V foram adicionadas, se descartarmos detalhes técnicos profundos, menos o primeiro anel de proteção para o hipervisor. Assim, a situação do trabalho no anel zero familiar ao SO foi finalmente estabelecida.

Tipos de hipervisores

Tipo 2 (hospedado)

Os hipervisores do segundo tipo são aplicativos executados sobre o sistema operacional host. Todas as chamadas de máquinas virtuais são tratadas pelo sistema operacional host upstream. Os hipervisores do segundo tipo são severamente limitados em desempenho, uma vez que a aplicação do hipervisor, não tendo o direito de alocação exclusiva de recursos de computação, é forçada a competir por eles com outros aplicativos do usuário. Em termos de segurança, os hipervisores do tipo 2 dependem diretamente das políticas de segurança do sistema operacional do usuário e de sua vulnerabilidade a ataques. Hoje, existe uma opinião unânime no setor de que essas plataformas de virtualização para o nível corporativo não são adequadas. No entanto, eles são adequados para o desenvolvimento entre plataformas e a implantação de stands diretamente nas máquinas dos desenvolvedores de software, pois são fáceis de gerenciar e implantar.

Exemplos do segundo tipo de hypervisor: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

Tipo 1 (bare-metal)

Os hipervisores do primeiro tipo não requerem um sistema operacional de uso geral, diferentemente dos anteriores. O hipervisor em si é um monólito que controla a alocação de recursos de computação e E / S. No anel de segurança zero, existe um micro-núcleo, sobre o qual todas as estruturas de controle funcionam. Nesta arquitetura, o hypervisor controla a distribuição dos recursos de computação e ele próprio controla todas as chamadas de máquinas virtuais para dispositivos. O VMware ESX foi considerado o primeiro hypervisor do primeiro tipo para x86 por um longo tempo, embora agora o atribuíssemos a 1+. O único representante "honesto" desse tipo hoje é o VMware ESXi - o sucessor do ESX, depois de ter desviado a seção pai do RHEL.

Por exemplo, considere a arquitetura ESXi. Os comandos de gerenciamento do hipervisor são executados por meio da API do agente, que é executada sobre o VMkernel. Isso pode parecer uma conexão direta com o hipervisor, mas não é. Não há acesso direto ao hypervisor, que distingue esse tipo de hypervisor do segundo tipo de hypervisor em termos de segurança.



A desvantagem aqui são os drivers de dispositivo: para garantir a "espessura" da plataforma e eliminar complicações desnecessárias de versão para versão, os drivers de dispositivo são alternados, o que torna a infraestrutura física dependente da HCL (lista de compatibilidade de hardware).

Tipo 1+ (hipervisor híbrido)

Os hipervisores do tipo híbrido (também são do tipo 1+, 1a, 1.5) são caracterizados pelo isolamento do SO básico em uma entidade especial chamada partição pai (partição pai na terminologia Microsoft Hyper-V) ou em um domínio pai (domínio dom0 na terminologia Xen). Portanto, depois de instalar a função do hypervisor, o kernel entra no modo de suporte à virtualização e o hypervisor é responsável pela alocação de recursos no host. Mas a seção pai assume a função de processar chamadas para drivers de dispositivo e operações de E / S.

De fato, a seção pai se torna um tipo de provedor entre todas as entidades da pilha de virtualização. Essa abordagem é conveniente do ponto de vista da compatibilidade com o equipamento: não é necessário incorporar drivers de dispositivo no hipervisor, como é o caso do ESXi, o que significa que a lista de dispositivos é muito expandida e menos dependente da HCL. As vantagens incluem o descarregamento do hypervisor da tarefa de processar chamadas para drivers de dispositivo, pois todas as chamadas são tratadas pela seção pai.

A arquitetura de nível superior dos hipervisores do tipo 1+ é assim:



Os hipervisores desse tipo incluem: os hipervisores VMware ESX, Microsoft Hyper-V e Xen falecidos (implementações Citrix XenServer e Xen em várias distribuições Linux). Lembre-se de que o Citrix XenServer é um SO baseado em RHEL ligeiramente truncado, e sua versão e funcionalidade dependiam diretamente da versão atual do Red-Hat Enterprise Linux. No caso de outras implementações do Xen, a situação não é muito diferente: é o mesmo kernel Linux no modo hipervisor Xen e o SO base no domínio dom0. Isso leva à conclusão inequívoca de que os hipervisores baseados em Xen são do tipo híbrido e não são hipervisores honestos do tipo 1.

Principais tecnologias de plataformas industriais

A base será a terminologia do VMware, como a plataforma de virtualização mais avançada tecnologicamente. Neste artigo, nos restringimos às tecnologias dos próprios hipervisores e ao sistema de controle básico. Todas as funcionalidades avançadas implementadas por produtos adicionais por dinheiro adicional serão deixadas nos bastidores. As tecnologias são agrupadas em grupos condicionais para o objetivo principal, como pareceu ao autor, com quem você tem o direito de discordar.

SLA

Essa é uma coleção de tecnologias que afetam principalmente o desempenho dos SLAs para acessibilidade (RPO / RTO).

HA

Alta disponibilidade - uma tecnologia para garantir alta disponibilidade de VMs em um cluster por um hipervisor. Em caso de morte do host, a VM é reiniciada automaticamente nos hosts sobreviventes. Efeito: minimizar o RTO antes do tempo limite do HA + reiniciar OS / serviços.

FT

Tolerância a falhas - tecnologia para garantir a operação contínua de VMs, mesmo em caso de morte do host. Uma VM sombra é criada no segundo host, que é completamente idêntico ao principal e repete as instruções por trás dele. Assim, a diferença nos estados da VM é medida em dezenas ou centenas de milissegundos, o que é bastante aceitável para muitos serviços. Quando o host morre, a execução muda automaticamente para a sombra da VM. Efeito: minimizando o RTO para zero.

Tco

Esta é uma coleção de tecnologias que influenciam principalmente o custo total de propriedade.

vMotion

O vMotion é uma tecnologia para migração ao vivo de um ponto de execução de VM de um host totalmente funcional para outro. Ao mesmo tempo, o ponto de comutação do ponto de execução é menor que o tempo limite da conexão de rede, o que nos permite considerar a migração como ativa, ou seja, sem interrupção no trabalho dos serviços produtivos. Efeito: reduzir o RTO para zero para interrupções planejadas para manutenção do servidor e, como resultado, eliminação parcial das próprias interrupções.

Storage vMotion

O Storage vMotion é uma tecnologia para migração ao vivo de um ponto de armazenamento da VM de um armazenamento totalmente funcional para outro. Ao mesmo tempo, o trabalho com o sistema de disco não para, o que permite que a migração seja considerada ativa. Efeito: reduzir o RTO para zero para interrupções planejadas para manutenção de armazenamento e, como resultado, eliminação parcial das próprias interrupções.

DPM

Distributed Power Management - tecnologia para controlar o nível de carga do host e ligar / desligar os hosts à medida que a carga no cluster muda. Requer DRS para sua operação. Efeito: redução geral no consumo de energia.

VSwitch distribuído

O vSwitch distribuído é uma tecnologia para gerenciamento centralizado das configurações de rede de switches de host virtual. Efeito: reduzindo o volume e a complexidade do trabalho de reconfiguração do subsistema de rede, reduzindo os riscos de erros.

EVC

A compatibilidade aprimorada do vMotion é uma tecnologia que permite mascarar as instruções disponíveis do processador para VMs no modo automático. É usado para alinhar o trabalho das VMs em um cluster desigual com a família de processadores mais antiga, fornecendo a capacidade de migrar VMs para qualquer host. Efeito: economizando na complexidade da infraestrutura e aumentando gradualmente a capacidade / atualizando parcialmente os clusters.

QoS

Essa é uma coleção de tecnologias que influenciam principalmente o desempenho do SLA em termos de qualidade de serviço.

vNUMA

O vNUMA é uma tecnologia que permite que o sistema operacional convidado se comunique com a topologia NUMA virtual da VM para máquinas amplas (nó vCPU ou vRAM> NUMA). Efeito: A falta de penalidade no desempenho do software aplicativo que suporta NUMA.

Conjunto de recursos

Pools de recursos - a tecnologia de combinar várias VMs em um único pool de recursos para controlar o consumo ou garantir a alocação de recursos. Efeito: simplifique a administração, forneça um nível de serviço.

Limite / reserva

O processador / memória limitador e redundante permite limitar a alocação de recursos, ou vice-versa, para garantir sua alocação em uma situação de escassez e concorrência para garantir a manutenção de VMs / pools de alta prioridade.

DRS

Dynamic Resource Scheduler - balanceamento automático de VMs por hosts, dependendo da carga, para reduzir a fragmentação de recursos no cluster e fornecer um nível de serviço para VMs. Requer suporte ao vMotion.

Controle de E / S de armazenamento

O controle de E / S de armazenamento é uma tecnologia que limita o “vizinho barulhento”, uma máquina de baixa prioridade com alta carga de disco para manter o desempenho de um sistema de armazenamento caro disponível para cargas de trabalho produtivas. Como exemplo, um sistema de indexação / mecanismo de pesquisa interno e um DBMS produtivo.

Controle de E / S de rede

O Network IO Control é uma tecnologia para limitar o “vizinho barulhento”, uma máquina de baixa prioridade com alta carga de rede.

Integração de armazenamento (VAAI etc)

Duas categorias de tecnologias se enquadram na seção de integração:

• A integração do sistema de gerenciamento de virtualização ao sistema de gerenciamento de armazenamento pode simplificar bastante a seleção e a apresentação de volumes / balões de armazenamento para hipervisores, reduzindo o risco de erros e a complexidade do trabalho.
• Integração em nível de protocolo - VAAI, ODX. Essas tecnologias permitem descarregar o subsistema de disco, transferindo parte da carga padrão para o descarte de armazenamento inteligente. Por exemplo, essa categoria inclui operações como zerar blocos, clonar VMs etc. Devido a isso, o canal para o sistema de armazenamento é significativamente descarregado, e o próprio sistema de armazenamento realiza operações de disco de maneira mais otimizada.

Segurança

Microssegmentação

A microssegmentação de uma rede virtual em uso prático é a capacidade de criar um firewall distribuído virtual que controla as redes virtuais dentro do host. Melhora extremamente a segurança da rede virtual.

AV sem agente

Suporte de tecnologia antivírus sem agente. Em vez de ser verificado pelos agentes no SO convidado, o tráfego das operações do disco da VM é direcionado pelo hipervisor à VM do serviço selecionado. Reduz significativamente a carga nos processadores e no sistema de disco, eliminando efetivamente as “tempestades antivírus”.

Sistemas hiperconvergentes

Sistemas convergentes, como o nome sugere, são sistemas com uma combinação de funções. E, neste caso, queremos dizer a combinação do armazenamento e execução da VM. Parece simples, mas o marketing de repente entra em cena.

Pela primeira vez com o termo sistemas convergentes, os profissionais de marketing entram no mercado. Os sistemas convergentes venderam servidores clássicos comuns + armazenamento + comutadores. Pouco menos de um número de parceiro. Ou eles nem estavam vendendo, mas um documento chamado "arquitetura de referência" foi produzido. Sinceramente, condenamos essa abordagem e passamos à consideração da arquitetura.

Arquitetura

Mantendo a convergência como um princípio arquitetural, obtemos uma combinação do ponto de armazenamento e do ponto de execução da VM em um único sistema.

A arquitetura convergente, em outras palavras, implica o uso dos mesmos serviços de hardware para executar VMs e armazená-los em discos locais. Bem, como deve haver tolerância a falhas - em uma arquitetura convergida, há uma camada de SDS distribuído.

Temos:

• O sistema clássico - software, armazenamento, comutação e servidores vêm de diferentes locais, combinados pelas mãos do cliente / integrador. Contratos de suporte separados.
• Sistema convergente - tudo de uma fonte, um suporte, um número de parceiro. Não deve ser confundido com a montagem automática de um fornecedor.

E acontece que o termo para nossa arquitetura convergente já foi adotado. Exatamente a mesma situação que com o supervisor.

Sistema hiperconvergente - Um sistema convergente com arquitetura convergente.
Claro, não foi sem a segunda vinda dos profissionais de marketing. Apareceram sistemas convergentes nos quais não havia combinação de armazenamento, mas existem nós de armazenamento dedicados sob o controle do SDS distribuído. No âmbito das guerras de marketing, até o termo especial desagregou HCI (infraestrutura hipervergênica desagregada). Em particular, por exemplo, a NetApp com um sistema semelhante inicialmente lutou intensamente pelo direito de chamar seu sistema de hiper convergente, mas acabou se rendendo. NetApp HCI hoje (final de 2019) - infraestrutura de nuvem híbrida.

Opções de implementação

Devido ao fato de os sistemas hiperconvergentes funcionarem com a virtualização, na verdade existem duas opções e meia para implementação.

• 1. O módulo do kernel. O SDS funciona como um monólito no núcleo do hipervisor, por exemplo vSAN + ESXi
• 1.5 Módulo da seção pai. O SDS funciona como um serviço como parte da seção pai do hypervisor, por exemplo S2D + Hyper-V
• 2. A máquina virtual. O SDS é implementado como uma máquina virtual dedicada em cada host. Nutanix, Cisco Hyperflex, HPE Simplivity.

Obviamente, além das questões discutidas com o efeito da incorporação no desempenho, há uma questão muito importante de isolamento e suporte de hipervisores de terceiros. No caso 1, é óbvio que esse pode ser apenas um sistema do provedor do hipervisor, enquanto 2 pode potencialmente funcionar em qualquer hipervisor.

Contentores

A virtualização em contêiner, embora tecnicamente muito diferente da virtualização completa, parece bastante simples em sua estrutura. Como no modelo de rede OSI, a questão é nivelada. A virtualização de contêiner é um nível mais alto - no nível do ambiente de aplicativos, e não na física.

A principal tarefa da virtualização de contêiner é dividir o SO em partes independentes, das quais aplicativos isolados não podem interferir entre si. A virtualização completa é compartilhada não pelo sistema operacional, mas por um servidor físico.

VM vs Container

Os prós e contras de ambas as abordagens são bastante simples e diretamente opostos.

A virtualização total (VM) dá total independência ao nível de ferro, incluindo SOs totalmente independentes, pilhas de disco e rede. Por outro lado, cada aplicativo, porque aderimos ao esquema 1 aplicativo = 1 servidor, requer seu próprio sistema operacional, seu próprio disco e pilha de rede. isto é há uma despesa múltipla de recursos.

Os contêineres têm pilhas comuns de disco e rede com o sistema operacional host e, juntos, eles usam um núcleo em todo o servidor físico (bem ou virtual, nos últimos tempos), o que, como um todo, permite economizar recursos significativamente em paisagens homogêneas.

Historicamente, o x86 inicialmente tinha contêineres para tudo, além de servidores físicos. Após o advento da virtualização completa, a importância dos contêineres caiu drasticamente em quase 15 anos e as VMs grossas reinaram no mundo corporativo. Naquela época, os contêineres encontravam-se em hosters que forneciam centenas do mesmo tipo de servidores da Web, onde havia pouca demanda. Mas, nos últimos anos, desde cerca de 2015, os contêineres voltaram à realidade corporativa na forma de aplicativos nativos da nuvem.

Contentores 0.1

chroot

O protótipo de contêineres em 1979 foi chroot.

“Chroot é a operação de alterar o diretório raiz em sistemas operacionais semelhantes ao Unix. Um programa iniciado com um diretório raiz modificado terá acesso apenas aos arquivos contidos nesse diretório. ”

I.e. de fato, o isolamento é apenas no nível do sistema de arquivos; caso contrário, é apenas um processo normal no sistema operacional.

Cadeia Freebsd

Significativamente mais avançado foi a prisão do BSD livre, que apareceu em 1999. O Jail permitiu criar instâncias completas de SO virtual com seus próprios conjuntos de aplicativos e arquivos de configuração com base no FreeBSD base. Certamente há quem diga - e o que a cadeia faz em contêineres, porque isso é paravirtualização! E eles estarão parcialmente certos.

No entanto, antes da virtualização completa (e sua variante na forma de paravirtualização), a cadeia carece da capacidade de executar o kernel de uma versão diferente na VM convidada e de agrupar com a migração da VM para outro sistema host.

Zonas Solaris

O Solaris Zones é uma tecnologia de virtualização de sistema operacional (virtualização de contêiner), introduzida em 2004 no Sun Solaris. O princípio básico é a baixa sobrecarga de virtualização.

Não ganhando muita popularidade, migrou para o OpenSolaris e distribuições baseadas nele, disponíveis em 2019.

Containers 1.0

Na era dos contêineres 1.0, surgiram duas direções principais de contêineres - produtos comerciais para provedores de hospedagem e contêineres de aplicativos.

Virtuozzo / OpenVZ

A SWsoft da Rússia lançou em 2001 sua primeira versão da virtualização de contêineres Virtuozzo, voltada para o mercado de provedores de hospedagem. Devido à determinação e ao público-alvo comercial específico, o produto mostrou-se bastante bem-sucedido e ganhou popularidade. Tecnologicamente, em 2002, foi demonstrada a operação simultânea de 2500 contêineres em um servidor com 8 processadores.

Em 2005, uma versão aberta dos contêineres Virtuozzo para Linux, chamada OpenVZ, apareceu. E quase se tornou o padrão ouro para hospedagem de VPS.

Lxc

O LinuX Containers (LXC) é outra virtualização de contêiner bem conhecida, baseada em namespaces e cgroups, que apareceu em 2008. Ela é subjacente às janelas de encaixe atualmente populares, etc.

Containers 1.1 (Application Virtualization)

Se os contêineres restantes foram projetados para dividir o SO básico em segmentos, por que não separar essa camada do sistema e embalá-la em uma única caixa com o aplicativo e todos os seus arredores. E esse pacote pronto pode ser lançado como um aplicativo comum no nível do usuário.

App-v

Microsoft Application Virtualization (App-V), anteriormente Softricity SoftGrid - tecnologia para contêiner de aplicativos específicos (o contêiner é o contrário) em uma caixa de proteção isolada e, em seguida, na Microsoft. Em 2006, a Microsoft adquiriu a startup Softricity, que realmente mudou o contêiner.

Thinapp

O VMware ThinApp (anteriormente Thinstall) é um produto de conteinerização de aplicativos da Jilt adquirido pela VMware em 2008. A VMware estima que 90-95% de todos os aplicativos empacotados no mundo usam essa tecnologia.

Containers 2.0

O histórico do surgimento de containers 2.0 está muito associado a uma mudança no processo de desenvolvimento de software. O desejo da empresa de reduzir um parâmetro tão importante quanto o tempo de colocação no mercado obrigou os desenvolvedores a reconsiderar abordagens para a criação de produtos de software. A metodologia de desenvolvimento Waterfall (ciclos de liberação longos, todo o aplicativo é atualizado) é substituída pelo Agile (ciclos de liberação curtos e com tempo determinado, os componentes do aplicativo são atualizados independentemente) e força os desenvolvedores a separar aplicativos monolíticos em componentes. Embora os componentes de aplicativos monolíticos ainda sejam bastante grandes e não haja muitos deles que possam ser colocados em máquinas virtuais, mas quando um aplicativo consiste em dezenas ou centenas de componentes, as máquinas virtuais não são mais muito adequadas. Além disso, também surge o problema de versões auxiliares de software, bibliotecas e dependências; geralmente há uma situação em que componentes diferentes requerem versões diferentes ou variáveis ​​de ambiente configuradas de maneira diferente. Esses componentes precisam ser distribuídos para diferentes máquinas virtuais, porque é quase impossível executar simultaneamente várias versões de software no mesmo sistema operacional. O número de VM começa a crescer como uma avalanche. Aqui, os contêineres aparecem no palco, permitindo que, dentro da estrutura de um SO convidado, crie vários ambientes isolados para o lançamento de componentes de aplicativos. A conteinerização de aplicativos permite continuar a segmentação de um aplicativo monolítico em componentes ainda menores e passar para o paradigma de uma tarefa = um componente - um contêiner, isso é chamado de abordagem de microsserviço, e cada componente é um microsserviço.

Recipiente sob o capô

Se você olhar para o contêiner com uma olhada do administrador do sistema, esses são apenas processos Linux que têm seus próprios pids, etc. O que torna possível isolar os processos em execução nos contêineres e consumir os recursos do SO convidado juntos? Dois mecanismos padrão presentes no kernel de qualquer distribuição moderna do Linux. O primeiro, Namespaces do Linux, que garante que cada processo veja sua própria representação do sistema operacional (sistema de arquivos, interfaces de rede, nome do host etc.) e o segundo, Linux Control Groups (cgroups), restringindo o processo ao consumo de recursos do SO convidado (CPU, memória largura de banda da rede etc.).

Namespaces do Linux

Por padrão, todo sistema Linux contém um único espaço para nome. Todos os recursos do sistema, como sistemas de arquivos, identificadores de processo (IDs de processo), identificadores de usuário (IDs de usuário) e interfaces de rede pertencem a esse espaço para nome. Mas ninguém está nos impedindo de criar espaços para nome adicionais e redistribuir recursos do sistema entre eles.

Quando um novo processo é iniciado, ele inicia em um espaço para nome, padrão do sistema ou um dos criados. E esse processo verá apenas os recursos disponíveis no espaço para nome usado para executá-lo.

Mas nem tudo é tão simples, cada processo não pertence a um único espaço para nome, mas a um espaço para nome em cada uma das categorias:

• Montagem (mnt)
• ID do processo (pid)
• Rede (líquida)
• Comunicação entre processos (ipc)
• UTS
• ID do usuário (usuário)

Cada tipo de espaço para nome isola um grupo de recursos correspondente. Por exemplo, o espaço UTS define o nome do host e o nome do domínio visíveis aos processos. Portanto, dois processos no sistema operacional convidado podem assumir que eles estão sendo executados em servidores diferentes.

O espaço para nome da rede determina a visibilidade das interfaces de rede; o processo interno verá apenas as interfaces pertencentes a esse espaço para nome.

Grupos de controle do Linux (cgroups)

O Linux Control Groups (cgroups) é o mecanismo do sistema do kernel (Kernel) dos sistemas Linux que limita o consumo de recursos do sistema pelos processos. Cada processo ou grupo de processos não poderá obter mais recursos (CPU, memória, largura de banda da rede etc.) do que o que está alocado e não poderá capturar os "outros" recursos - os recursos dos processos vizinhos.

Docker

Como mencionado acima, o Docker não inventou contêineres como tal. Os contêineres existem há muitos anos (incluindo aqueles baseados no LXC), mas o Docker os tornou muito populares ao criar o primeiro sistema que tornou fácil e simples a transferência de contêineres entre máquinas diferentes. O Docker criou uma ferramenta para criar contêineres - empacotando o aplicativo e suas dependências e executando contêineres em qualquer sistema Linux com o Docker instalado.

Um recurso importante do Docker é a portabilidade não apenas do próprio aplicativo e suas dependências entre distribuições Linux completamente diferentes, mas também a portabilidade do ambiente e do sistema de arquivos. Por exemplo, um contêiner criado no CentOS pode ser executado em um sistema Ubuntu. Nesse caso, dentro do contêiner lançado, o sistema de arquivos será herdado do CentOS e o aplicativo considerará que ele é executado sobre o CentOS. Isso é um pouco semelhante a uma imagem OVF de uma máquina virtual, mas o conceito de uma imagem do Docker usa camadas. Isso significa que, ao atualizar apenas parte da imagem, não é necessário fazer o download da imagem inteira novamente, basta fazer o download apenas da camada alterada, como se na imagem OVF fosse possível atualizar o sistema operacional sem atualizar a imagem inteira.

O Docker criou um ecossistema para criar, armazenar, transferir e iniciar contêineres. Existem três componentes principais no mundo do Docker:

• Imagens - uma imagem, é a entidade que contém seu aplicativo, o ambiente necessário e outros metadados necessários para iniciar o contêiner;
• Registradores - repositório, local de armazenamento para imagens do Docker. Existem vários repositórios, desde o oficial - hub.docker.com até os privados implantados na infraestrutura da empresa;
• Contêineres - um contêiner, contêiner Linux criado a partir de uma imagem do Docker. Como mencionado acima, esse é um processo Linux em execução em um sistema Linux com o Docker instalado, isolado de outros processos e do próprio sistema operacional.

Considere o ciclo de vida do contêiner. Inicialmente, um desenvolvedor cria uma imagem do Docker com seu aplicativo (o comando docker build), completamente do zero ou usando imagens já criadas como base (lembre-se das camadas). Além disso, essa imagem pode ser lançada pelo desenvolvedor diretamente em sua própria máquina ou pode ser transferida para outra máquina - o servidor. Para portabilidade, os repositórios são frequentemente usados ​​(o comando docker push) - eles carregam a imagem no repositório. Depois disso, a imagem pode ser baixada para qualquer outra máquina ou servidor (docker pull). Por fim, crie um container de trabalho (docker run) a partir desta imagem.

Kubernetes

Como já dissemos, o conceito de microsserviços significa dividir um aplicativo monolítico em muitos serviços pequenos, geralmente executando uma única função. Bem, quando existem dezenas desses serviços, eles ainda podem ser gerenciados manualmente através, por exemplo, do Docker. Mas o que fazer quando existem centenas e milhares desses serviços? Além do ambiente industrial, você precisa de um ambiente de teste e ambientes adicionais para diferentes versões do produto, ou seja, multiplique por 2, por 3 ou mais. O Google também enfrentou os mesmos problemas, seus engenheiros foram um dos primeiros a usar contêineres em escala industrial. Assim nasceu o Kubernetes (K8s), criado sob o nome de Borg nas paredes do produto Google, mais tarde dado ao público em geral e renomeado.

O K8s é um sistema que facilita a implantação, o gerenciamento e o monitoramento de aplicativos em contêiner (microsserviços). Como já sabemos, qualquer máquina Linux é adequada para o lançamento de contêineres e os contêineres são isolados um do outro, respectivamente, e os K8s podem gerenciar servidores diferentes com hardware diferente e sob o controle de diferentes distribuições Linux. Tudo isso nos ajuda a usar o hardware disponível de forma eficaz. Como a virtualização, o K8s fornece um conjunto comum de recursos para iniciar, gerenciar e monitorar nossos microsserviços.

Como este artigo é voltado principalmente para engenheiros de virtualização, para uma compreensão geral dos princípios de operação e dos principais componentes do K8s, recomendamos que você leia o artigo que traça o paralelo entre o K8s e o VMware vSphere: https://medium.com/@pryalukhin/kubernetes-introduction-for-vmware- users-232cc2f69c58

Histórico de virtualização industrial X86

VMware

A VMware apareceu em 1998, começando com o desenvolvimento de um segundo tipo de hypervisor, que mais tarde ficou conhecido como VMware Workstation.

A empresa entrou no mercado de servidores em 2001 com dois hipervisores - GSX (Ground Storm X, segundo tipo) e ESX (Elastic Sky X, primeiro tipo). Com o tempo, as perspectivas do segundo tipo em aplicativos de servidor tornaram-se óbvias, ou seja, Nenhuma. E o GSX pago foi primeiro transformado em um servidor VMware gratuito e depois completamente parado e enterrado.

Em 2003, o sistema de gerenciamento central do Virtual Center, a tecnologia vSMP e a migração ao vivo de máquinas virtuais apareceram.

Em 2004, a VMware foi adquirida pela EMC, uma gigante do armazenamento, mas deixou operacional independente.

Em 2008, tornando-se o padrão de fato do setor, a VMware estimulou o rápido crescimento de ofertas competitivas - Citrix, Microsoft etc. Torna-se clara a necessidade de obter uma versão gratuita do hipervisor, o que era impossível - como uma seção pai no ESX, um RHEL completamente comercial foi usado. O projeto de substituir o RHEL por algo mais fácil e gratuito teve sua implementação em 2008 com o sistema busybox. O resultado é o ESXi, conhecido por todos hoje.

Paralelamente, a empresa está desenvolvendo projetos internos e aquisições de startups. Alguns anos atrás, uma lista de produtos VMware ocupava algumas páginas A4, então vamos dizer. O VMware para 2019 ainda é o padrão de fato no mercado de virtualização corporativa corporativa no local, com uma participação de mercado de mais de 70% e um líder absoluto em tecnologia, e uma revisão detalhada da história merece um artigo muito amplo.

Connectix

Fundada em 1988, a Connectix trabalhou em uma variedade de utilitários de sistema até ocupar a virtualização. Em 1997, foi criado o primeiro produto VirtualPC para Apple Macintosh, permitindo que o Windows fosse executado em uma máquina virtual. A primeira versão do VirtualPC para Windows apareceu em 2001.

Em 2003, a Microsoft comprou o VirtualPC e, de acordo com o Connectix, os desenvolvedores mudaram para a Microsoft. Depois disso, o Connectix fechou.

O formato VHD (disco rígido virtual) foi desenvolvido pelo Connectix para VirtualPC e, como lembrete, os discos virtuais das máquinas Hyper-V contêm "conectix" em sua assinatura.
Virtual PC, como você pode imaginar, é um hypervisor de desktop clássico do segundo tipo.

Microsoft

A jornada da Microsoft para a virtualização industrial começou com a compra do Connectix e a renomeação do Connectix Virtual PC no Microsoft Virtual PC 2004. O PC virtual desenvolvido por um tempo foi incluído com o nome Windows Virtual PC no Windows 7. No Windows 8 e posterior, o Virtual PC foi substituído por versão desktop do Hyper-V.

Baseado no Virtual PC, foi criado o hipervisor do servidor Virtual Server, que existia até o início de 2008. Devido à óbvia perda tecnológica antes do VMware ESX, foi decidido restringir o desenvolvimento do segundo tipo de hypervisor em favor de seu próprio primeiro tipo de hypervisor, que se tornou o Hyper-V. Há uma opinião não oficial no setor de que o Hyper-V é surpreendentemente semelhante ao Xen na arquitetura. Aproximadamente o mesmo que .Net em Java.

"Claro, você pode pensar que a Microsoft roubou a idéia de Java." Mas isso não é verdade, a Microsoft a inspirou! - (de um discurso de um representante da Microsoft na apresentação do Windows 2003 Server)

Dos momentos curiosos, pode-se notar que, dentro da Microsoft, o uso de produtos de virtualização proprietários nos anos zero foi, para dizer o mínimo, opcional. Existem capturas de tela do Technet de artigos sobre virtualização, nas quais o logotipo do VMware Tools está claramente presente na bandeja. Além disso, Mark Russinovich na Plataforma de 2009 em Moscou realizou uma demonstração com a VMware Workstation.

Em um esforço para entrar em novos mercados, a Microsoft criou sua própria nuvem pública, o Azure, usando um Nano Server altamente modificado com suporte para Hyper-V, S2D e SDN como plataforma. Vale ressaltar que, inicialmente, o Azure, em alguns pontos, estava muito atrás dos sistemas locais. Por exemplo, o suporte para máquinas virtuais de segunda geração (com suporte para Inicialização segura, inicialização a partir de partições GPT, inicialização PXE etc.) apareceu no Azure somente em 2018. Enquanto no local, as VMs de segunda geração são conhecidas desde o Windows Server 2012R2. O mesmo vale para soluções de portal: até 2017, o Azure e o Windows Azure Pack (solução de nuvem multilocação com suporte a SDN e VM protegida, que substituiu o System Center App Controller em 2013) usavam o mesmo design de portal. Depois que a Microsoft anunciou um curso sobre nuvens públicas, o Azure avançou no desenvolvimento e implementação de vários conhecimentos. Por volta do ano de 2016, você pode observar uma imagem completamente lógica: agora todas as inovações no Windows Server vêm do Azure, mas não na direção oposta. O fato de copiar partes da documentação do Azure para o local "como está" indica isso (consulte a documentação no Azure SDN e Network Controller), que por um lado indica a atitude em relação às soluções no local e, por outro, indica o relacionamento das soluções em termos de entidades e arquitetura. Quem copiou de quem e como realmente é - uma questão discutível.

Em março de 2018, Satya Nadela (CEO da Microsoft) anunciou oficialmente que a nuvem pública estava se tornando a prioridade da empresa. O que, obviamente, simboliza o desbotamento gradual da linha de servidores para produtos no local (no entanto, a estagnação foi observada em 2016, mas foi confirmada com a primeira versão beta do Windows Server e outras linhas de produtos no local), com exceção do Azure Edge - o servidor mínimo necessário Infraestrutura no escritório do cliente para serviços que não podem ser levados para a nuvem.

Ferro virtual

Fundada em 2003, a Virtual Iron ofereceu uma versão comercial do Xen e foi uma das primeiras a oferecer ao mercado suporte completo à virtualização de hardware.
Em 2009, a Oracle foi contratada para desenvolver sua própria linha de virtualização Oracle VM e expandi-la no x86. Antes disso, o Oracle VM era oferecido apenas na plataforma SPARC.

Innotek

No início de 2007, a Innotek GmbH lançou o segundo tipo de hipervisor proprietário, o VirtualBox, que é gratuito para uso não comercial. No mesmo ano, uma versão de código aberto foi lançada.

Em 2008, foi adquirida pela Sun, que por sua vez foi adquirida pela Oracle. A Oracle manteve o uso gratuito do produto para fins não comerciais.
O VirtualBox suporta três formatos de discos virtuais - VDI (nativo), VMDK (VMware), VHD (Microsoft). Como SO host, Windows, macOS, Linux, Solaris e OpenSolaris são suportados. O fork do VirtualBox for FreeBSD é conhecido.

Ibm

O mainframe é o computador principal do datacenter com uma grande quantidade de memória interna e externa (para referência: nos anos 60, 1 MB de memória era considerado irrealisticamente grande). Na verdade, o mainframe era um centro de computação: os primeiros computadores ocupavam salas de máquinas inteiras e consistiam em enormes racks. Hoje em dia é chamado de data centers. Mas nos datacenters da mesma sala de máquinas pode haver milhares de computadores e, no início da tecnologia da computação, um computador ocupava uma sala inteira. Cada rack vendeu um (!) Dispositivo de computador (racks separados com memória, racks separados com dispositivos de armazenamento e dispositivos periféricos separadamente). O núcleo desta enorme máquina era um rack com um processador - era chamado de principal ou mainframe.Depois de mudar para os circuitos integrados de transistor, o tamanho desse milagre do pensamento científico e de engenharia diminuiu significativamente, e o mainframe da IBM e seus análogos começaram a ser entendidos como o mainframe.

Nos anos 60 do século XX, o aluguel do poder de computação de todo o mainframe, para não mencionar sua compra, custou muito dinheiro. Pouquíssimas empresas e instituições poderiam ter esse luxo. O poder de computação do leasing era de hora em hora (o protótipo do modelo moderno de Pay as you go em nuvens públicas, não é?). O acesso aos inquilinos para a computação foi concedido sequencialmente. A solução lógica foi paralelizar a carga computacional e isolar os cálculos dos inquilinos.

Pela primeira vez, a idéia de isolar várias instâncias de sistemas operacionais em um mainframe foi proposta pelo IBM Cambridge Science Center com base no mainframe IBM System / 360-67. O desenvolvimento foi chamado de CP / CMS e, de fato, foi o primeiro hipervisor e forneceu paravirtualização. CP (Control Program) - o próprio hypervisor, que criou várias "máquinas virtuais" (VM) independentes. O CMS (originalmente o Cambridge Monitor System, mais tarde renomeado como Conversational Monitor System) era um sistema operacional leve e de usuário único. Curiosamente, o CMS ainda está ativo e ainda é usado na última geração de mainframes do z / VM. Vale ressaltar que, na época e até os anos 90, uma máquina virtual significava uma separação lógica de discos físicos (discos ou dispositivos de armazenamento eram compartilhados,o hipervisor não forneceu armazenamento para suas próprias necessidades) com uma parte dedicada de memória virtual e tempo do processador usando a tecnologia Time-Sharing. As VMs não previam interação de rede, porque as VMs da época eram sobre computação e armazenamento de dados, e não sobre transferência. Nesse sentido, as VMs da época eram mais como contêineres do que VMs no sentido moderno.

O primeiro hypervisor comercial baseado no CP / CMS, chamado VM / 370, apareceu nos mainframes da série System / 370 em 2 de agosto de 1972. O nome geral dessa família de sistemas operacionais é VM e, como parte desta seção, VM será entendida como o hypervisor IBM. A capacidade de executar vários sistemas operacionais ao mesmo tempo, garantindo a estabilidade do sistema e isolando os usuários um do outro (um erro no SO de um usuário não poderia afetar os cálculos de outro usuário) - foi revolucionária e se tornou um fator essencial no sucesso comercial da VM / 370. Um fato curioso: naquela época na URSS, os esforços do Instituto de Pesquisa Científica da Ciência da Computação (Minsk) clonaram com muito sucesso a arquitetura System / 370 e criaram sua própria VM / 370 analógica sob o nome de computador da UE (com suporte para virtualização incorporada! - para a possibilidade de desenvolver o sistema operacional mais básico).Tais mainframes foram usados ​​por institutos de pesquisa e empresas de defesa do campo socialista.

Os anos 80 podem ser chamados com segurança de "era do mainframe". A VM foi um sucesso com os desenvolvedores de sistemas operacionais, os aplicativos foram escritos para ela e os cálculos foram feitos. Esta foi a década em que o compartilhamento de bancos de dados dominados pelo VM OS começou a prevalecer nos mainframes. Uma das mudanças mais importantes foi a LPAR (Logical Partition Access Resources), que realmente forneceu dois níveis de virtualização. Agora, os clientes podiam usar o mesmo conjunto de processadores, dispositivos de E / S e modems em sistemas VM executando em diferentes LPARs e permitindo que os recursos fossem migrados de um sistema VM para outro. Isso permitiu às organizações de TI oferecer desempenho consistente ao processar picos de carga de trabalho. Para otimizar a crescente base de clientes, a VM foi dividida em três produtos separados,disponível no final dos anos 80:

VM / SP - o sistema operacional de virtualização multiuso usual para servidores System z
HPO (High Performance Option) - VM / SP de alto desempenho para modelos de servidor System z mais antigos
VM / XA (arquitetura ampliada) - Variante VM com suporte para a arquitetura S / S estendida 370

No início dos anos 90, a simplicidade e a conveniência da arquitetura x86 se tornaram mais atraentes para os clientes, e os mainframes estavam perdendo rapidamente a relevância. Os mainframes foram substituídos por sistemas de cluster, como o grunge, que substituiu o glam metal ao mesmo tempo. No entanto, para uma certa classe de tarefas, por exemplo, ao construir um data warehouse centralizado, os mainframes se justificam tanto em termos de produtividade quanto do ponto de vista econômico. Portanto, algumas empresas ainda usam mainframes em suas infraestruturas e a IBM projeta, libera e suporta novas gerações.

Linux Xen

Xen (pronunciado zen) é um hypervisor desenvolvido no Laboratório de Informática da Universidade de Cambridge, sob a direção de Ian Pratt e distribuído sob a GPL. A primeira versão pública apareceu em 2003. Posteriormente, Ian continuou trabalhando no hipervisor em sua versão comercial, estabelecendo a empresa XenSource.
Em 2013, o Xen ficou sob o controle da Linux Foundation.

XenSource

Tendo existido por vários anos no mercado com os produtos XenServer e XenEnterprise, no final de 2007 foi adquirido pela Citrix.

Citrix XenServer

Tendo absorvido o XenSource por US $ 500 milhões, a Citrix não conseguiu comercializar o problema. Mais precisamente, eu realmente não tentei fazer isso, não considerando o XenServer como o principal produto e confiando no preço baixo das licenças permanentes. Após vendas francamente malsucedidas em meio ao altamente bem-sucedido VMware ESX, foi decidido lançar o XenServer no mundo de graça e com código-fonte aberto completo em 2009. No entanto, o código do sistema de gerenciamento proprietário do XenCenter não foi aberto.
Deve-se notar uma interessante coincidência cronológica das iniciativas da Citrix e da Microsoft no campo da virtualização industrial, apesar de as empresas estarem sempre muito próximas.

Apesar do nome de marketing comum, o Citrix XenApp e o XenDesktop não têm nada a ver com o hipervisor Xen.

Amazônia

A Amazon lançou sua oferta pública de nuvem IaaS chamada EC2 (Elastic Compute) em 2006. Inicialmente, a plataforma EC2 usava o hipervisor Xen e, posteriormente, a Amazon dividiu a plataforma em três partes, cada uma das quais usava uma ramificação e uma versão separadas do hipervisor para minimizar o impacto de erros no código na disponibilidade do serviço.

Em 2017, o KVM para cargas pesadas apareceu como um hipervisor adicional no EC2. Há opiniões de que isso indica a transferência gradual do EC2 para a KVM inteiramente no futuro.

QEMU / KVM do Linux

O QEMU (Quick EMUlator) é um software universal para emular hardware de várias plataformas, distribuído sob a licença GPL v2. Além do x86, também são suportados ARM, MIPS, RISC-V, PowerPC, SPARC e SPARC64. Com a versatilidade de uma plataforma com virtualização completa, o QEMU não teve desempenho comparável a um sistema não virtualizado. Para acelerar o trabalho do QEMU no x86, foram oferecidas duas opções principais, que foram finalmente rejeitadas em favor do desenvolvimento de KVM (máquina virtual baseada em kernel) da Qumranet.

Dizemos KVM - queremos dizer QEMU KVM e, portanto, obtemos o formato de disco virtual qcow2 (QEMU copy-on-write 2) para todas as plataformas baseadas no hypervisor KVM.
Embora o QEMU funcione inicialmente como um segundo tipo de hypervisor, o QEMU / KVM é o primeiro tipo de hypervisor.

Qumranet

Uma empresa israelense, ex-desenvolvedora e principal patrocinadora do hypervisor KVM e do protocolo SPICE. Fundada em 2005, ganhou fama após incorporar o KVM no kernel do Linux. 4 de setembro de 2008, adquirido pela Red Hat.

Chapéu vermelho

Como todos os fabricantes de distribuição GNU / Linux, até 2010, a Red Hat tinha suporte interno para o hipervisor Xen em suas distribuições. No entanto, como um dos principais players do mercado e uma marca séria, pensei na minha própria implementação do hypervisor. A base foi tomada pelo hipervisor KVM normal, mas promissor. A primeira versão do Red Hat Enterprise Virtualization 2.2 (RHEV) foi lançada em 2010 com a pretensão de competir por uma parte do mercado de soluções VDI com a Citrix e a VMware devido ao desenvolvimento do Qumranet, que foi adquirido dois anos antes. Pronto para uso, estavam disponíveis clusters de alta disponibilidade, Live Migration e ferramentas de migração M2M (somente RHEL). Vale ressaltar que, a julgar pela documentação da época, a Red Hat manteve a notação Xen ao descrever a arquitetura da solução.

Em 28 de outubro de 2018, a IBM anunciou a compra da Red Hat.

Openstack

Historicamente, o projeto OpenStack surgiu como uma iniciativa para contrastar algo com o monopólio real da VMware no campo da virtualização de servidores pesados ​​x86. O projeto surgiu em 2010, graças aos esforços conjuntos da Rackspace Hosting (um provedor de nuvem) e da NASA (que abriu o código para sua própria plataforma Nebula). O ponto alto da situação foi dado pelo fato de que em 2012 a VMware ingressou no gerenciamento de projetos do OpenStack e causou uma onda de indignação entre os ativistas fundadores.

Com o tempo, Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP e Oracle se juntaram ao projeto.

No entanto, nem tudo foi tranquilo. Em 2012, a NASA deixou o projeto, optando pela AWS. No início de 2016, a HPE encerrou completamente seu projeto Helion com base no OpenStack.

Como parte do projeto OpenStack, o KVM foi adotado como o hypervisor padrão. No entanto, devido à modularidade da abordagem, um sistema baseado no OpenStack pode ser implementado usando outros hipervisores, deixando, por exemplo, apenas um sistema de controle do OpenStack.

Há uma ampla gama de opiniões sobre o projeto OpenStack, desde adoração entusiasta a ceticismo sério e críticas duras. As críticas não são sem razão - um número significativo de problemas e perdas de dados foram registrados ao usar o OpenStack. O que, no entanto, não impede que os fãs neguem tudo e se refiram à curvatura na implementação e operação dos sistemas.

O projeto OpenStack não se limita apenas à virtualização, mas com o tempo se tornou um número significativo de vários subprojetos e componentes para expansão na área da pilha de serviços de nuvem pública. Além disso, a importância do OpenStack provavelmente deve ser avaliada precisamente nesta parte - esses componentes se tornaram essenciais em muitos produtos e sistemas comerciais, tanto no campo da virtualização quanto além.

Na Rússia, o OpenStack fora das nuvens públicas é amplamente conhecido principalmente por seu papel na substituição de importações. A grande maioria das soluções e produtos de virtualização, incluindo sistemas hiperconvergentes, são empacotados pelo OpenStack com vários graus de refinamento.

Nutanix AHV

Desde a sua criação, a Nutanix é um produto e plataforma exclusivamente para o VMware vSphere. No entanto, em parte devido ao desejo de expandir a oferta de outros hipervisores, em parte devido à crise política nas relações com a VMware, foi decidido desenvolver seu próprio hipervisor que completaria a plataforma in a box e permitiria abandonar produtos de terceiros. A KVM foi escolhida como seu próprio hypervisor, que no âmbito da plataforma foi chamado de AHV (Acropolis HyperVisor).

Parallels

Na versão 7 do Virtuozzo, a empresa mudou de seu próprio hypervisor para a KVM.

Proxmox

O Proxmox VE (Ambiente Virtual) é um projeto de código aberto da empresa austríaca Proxmox Server Solutions GmbH, baseado no Debian Linux. O primeiro lançamento foi em 2008.
O produto suporta virtualização de contêiner LXC (anteriormente OpenVZ) e virtualização completa com o hipervisor KVM.

Paralelos / Virtuozzo / Rosplatform

Fundada em 1999 por Sergey Belousov, a SWsoft adotou o software de gerenciamento de hospedagem. Em 2003, a empresa rival de Novosibirsk, a Plesk, foi adquirida.

Em 2004, a SWsoft adquiriu a empresa russa Parallels Nikolai Dobrovolsky com seu produto Parallels Workstation (hypervisor de desktop do segundo tipo no Windows).
A empresa combinada mantém o nome de Parallels e em breve explodirá o mercado com o Parallels Desktop for Mac (hypervisor de desktop do segundo tipo para MacOS).

Como parte da virtualização de servidores, o foco continua em provedores de hospedagem e data centers, em vez de uso corporativo. Devido às especificidades desse mercado específico, os contêineres Virtuozzo e OpenVZ, em vez das máquinas virtuais do sistema, tornaram-se o principal produto. Posteriormente, a Parallels, sem muito sucesso, está tentando entrar no mercado de virtualização de servidores corporativos com o produto Parallels Bare Metal Server (posteriormente Parallels Hypervisor e Cloud Server e Virtuozzo), acrescenta hiperconvergência com seu Cloud Storage. O trabalho continua na automação e orquestração de provedores de hospedagem.

Em 2015, com base nos produtos de virtualização de servidores, é criado o projeto da plataforma Rosplatform - tecnicamente (omitindo aspectos legais e organizacionais) o mesmo Virtuozzo, apenas com papéis de parede modificados e no registro de software russo. Baseado no software da plataforma Rosplatform e no equipamento Depo, o IBS cria uma oferta hiperconvergente do pacote Scala-R.

Antes da versão 7, o Virtuozzo usava um hipervisor de seu próprio design; na versão 7, era feita uma transição para o KVM. Por conseguinte, a Rosplatform também se baseia na KVM.
Após várias fusões, aquisições e rebrandings, a próxima imagem é formada em 2019.

Parallels Desktop é uma subsidiária da Parallels e vendida para a Corel. Toda a automação foi para Odin e vendida para a IngramMicro. A virtualização de servidores permaneceu sob a marca da plataforma Virtuozzo / Rosplatform.