.
A substituição de um algoritmo de classificação no kernel do FreeBSD melhorou sua velocidade de inicialização por um fator de 100 ou mais… e embora seja voltado para uma micro-VM, os ganhos devem beneficiar a todos.
MicroVMs são uma área importante de pesquisa e desenvolvimento de tecnologia na última meia década ou mais. A ideia central é uma reinvenção de alguns conceitos e tecnologias que IBM inventou junto com o hipervisor na década de 1960: projetar sistemas operacionais especificamente para rodar como convidados em outro sistema operacional. Isso significa construir o sistema operacional especificamente para rodar dentro de uma VM e se comunicar com recursos fornecidos por um hipervisor específico, em vez de falsificar hardware.
Isso significa que o sistema operacional convidado praticamente não precisa de suporte para hardware real, apenas VirtIO drivers que se comunicam diretamente com os recursos fornecidos pelo hipervisor host. Por sua vez, o hipervisor não precisa fornecer um barramento PCI emulado, gerenciamento de energia emulado, placa gráfica emulada, placas de interface de rede emuladas e assim por diante. O resultado é que o próprio hipervisor pode ser muito menor e mais simples.
O resultado da destruição implacável do hipervisor e do sistema operacional que é executado nele é que ambas as extremidades podem ser muito menores e mais simples. Isso significa que as VMs podem usar muito menos recursos e iniciar muito mais rapidamente.
No momento, o objetivo comercial disso é fornecer poder de computação “sem servidor”. A computação “sem servidor” é, na verdade, um discurso duplo de marketing: é claro que realmente existem servidores, em algum lugar de um datacenter. Mas em vez de fornecer Infraestrutura como Serviço, o famoso modelo IaaS, isso é Em vez disso, funcione como um serviço. A ideia é que você não precise saber nada sobre a infraestrutura: seu programa chama outro programa, e as ferramentas de gerenciamento geram quantas instâncias forem necessárias para executar aquela operação específica, retornar o resultado e, em seguida, excluir as VMs usadas para executar os cálculos. Você nunca precisa saber onde ou como aconteceu.
Para o cliente é bom porque é rápido e fácil. Para os provedores, é bom porque significa que os recursos são liberados novamente com muito mais rapidez, para que possam ser reutilizados imediatamente, o que significa oferecer suporte a mais clientes na mesma quantidade de hardware.
A AWS está oferecendo FaaS por meio de um serviço chamado Lambda, após um pouco de terminologia de programação funcional. Lambda é alimentado por produtos caseiros da Amazon Hipervisor de fogos de artifício que também alimenta seu Oferta sem servidor do Fargate.
O Firecracker é baseado no hipervisor KVM integrado do kernel Linux: por si só, é algo diferente, já que até então, AWS foi baseado no hipervisor Xen. Isso significa que é inerentemente uma oferta Linux-on-Linux. Isso soou como um desafio para Colin Percival, desenvolvedor do kernel do FreeBSD, já que relatado há um ano: ele decidiu fazer o FreeBSD rodar no Firecracker. Porém, como acontece com a maior parte da computação em geral, o processo geral de otimização é: primeiro, fazê-lo funcionar; então, faça com que vá rápido.
De acordo com seu twittar no início desta semana, sua última otimização de desempenho é impressionante: substituindo um algoritmo de classificação que fazia parte do processo de inicialização do kernel do FreeBSD em torno de um centenas de vezes mais rápido, reduzindo o tempo de carregamento do kernel para impressionantes 25 milissegundos. Isso é um quarto de décimo de segundo.
O FreeBSD (HEAD) não perde mais tempo executando um bubblesort em seus SYSINITs. Agora estamos executando um mergesort que é cerca de 100x mais rápido: https://t.co/1F8Yodedh3 https://t.co/AvmVVwz9G5
-Colin Percival (@cperciva) 20 de agosto de 2023
Este ajuste é apenas o mais recente de uma longa série, que ele descreveu com muito mais detalhes. detalhe alguns dias depois. Ele descreve as mudanças preliminares necessárias para inicializá-lo: remover várias etapas de inicialização que presumiam que ele estava inicializando no Xen e, em seguida, consultar a ACPI para o tipo e número de processadores. Isso falhou, pois o Firecracker não fornece ACPI. Então, a inicialização de um dos únicos bits de hardware que ele emula, um console serial, falhou.
Depois que o kernel foi iniciado com sucesso, o uso de memória rapidamente se tornou um problema: o padrão do Firecracker é atribuir ao convidado apenas 128 MB de RAM, devido a uma suposição que teve que ser alterada. O que se segue é uma lista completa de otimizações, cada uma das quais contribuiu com uma pequena economia de tempo.
É uma leitura interessante, mesmo que você não seja super técnico. Algumas das etapas mudam coisas que eram escolhas bastante razoáveis para inicializar em hardware dedicado, o que não faz mais sentido em um ambiente virtual onde uma máquina é gerada, faz algum trabalho e é excluída novamente em questão de segundos.
Percival comentou:
Acredito que o Linux esteja em 75-80 ms para o mesmo ambiente onde tenho o FreeBSD inicializando em 25 ms.
E contínuo:
Quando comecei a trabalhar para acelerar o processo de inicialização, o kernel demorava cerca de 10 segundos para inicializar, então tenho um kernel inicializando cerca de 400x mais rápido agora do que há alguns anos.
Por enquanto, o kernel otimizado é o do FreeBSD 14, em x86-64, mas o trabalho está em andamento para trazê-lo também para o Arm64 — a AWS está o maior usuário de servidores Arm no mundo.
Firecracker é um dos microVMs de maior perfil, mas existem outros, e seu sucesso inspirou os desenvolvedores do QEMU a adicionar um microvm plataforma virtual também. O desenvolvedor canônico Christian Erhardt tem blogado sobre como usar isso no Ubuntu e no fornecedor de ambiente de desenvolvimento de código online Hocus recentemente explicado por que mudou do Firecracker para o equivalente do QEMU.
Podemos ver muitos usos potenciais para microVMs, não apenas em cenários de nuvem. A capacidade de executar um único programa criado para um sistema operacional em cima de um sistema operacional totalmente diferente, sem a sobrecarga de executar um ambiente totalmente emulado o tempo todo, pode ser muito útil em todos os tipos de situações.
Os contêineres são uma ferramenta muito útil, mas em contêineres você só pode executar binários para o mesmo sistema operacional host. Executar qualquer outra coisa – como contêineres Docker Linux no macOS – significa que alguma emulação e um sistema operacional convidado foram escondidos em algum lugar da pilha. Quanto menor for a VM e quanto menos recursos ela usar, melhor será o desempenho geral, não apenas dos contêineres, mas de toda a máquina. ®
.
