Avançar para o conteúdo principal
BlogCálculoComo Linode passou de Hardware para GPUs ao Vivo em Seis Semanas

Como Linode passou de Hardware para GPUs ao Vivo em Seis Semanas

GPUs Linode Cloud

Em 2019, três departamentos diferentes estabeleceram um objetivo para o lançamento das novas Instâncias GPU LInode para os clientes pelo aniversário da LInode. Entre as equipas de harware, marketing e gestão, não tínhamos a certeza se tal era possível, sobretudo devido aos outros produtos nos quais estávamos a trabalhar nessa altura.

Por isso escolhemos uma equipa que conseguiu que tal acontecesse, uma equipa escolhida a dedo, de empregados incansáveis, de vários departamentos para formar a Equipa Missão GPU. Agora, dois anos depois e com muitas e muitas implementações de GPU, fazemos uma viagem pela nossa memória para dar uma visão mais em detalhe sobre como fizemos que isso acontecesse e como tornámos uma ideia num produto de sucesso que estamos a expandir ativamente.

Um Breve Regresso à História da Virtualização na LInode

Antes de começarmos sobre a forma como alcançámos as instâncias GPU, deixamos aqui alguns detalhes técnicos simples, e a história sobre como a virtualização começou na Linode antes de nos tornarmos num fornecedor cloud como somos conhecidos presentemente.

A Linode começou como uma pequena empresa em 2003 para o fornecimento de máquinas virtuais executadas emUML (Modo de Utilização Linux), um paradigma de virtualização antecipada semelhante ao Qemu (Quick EMUlator). A UML fornecia hardware totalmente virtualizado. Quando um cliente acedia ao seu Linode, os dispositivos que o cliente via, tais como discos, rede, motherboard, RAM etc. todos se pareciam e comportavam como dispositivos de hardware reais, mas os dispositivos estavam realmente suportados por software em vez de hardware real.

Vários anos mais tarde, Linode mudou-se para Xen como a sua camada de virtualização para fornecer as mais recentes melhorias de desempenho aos nossos clientes. Xen é um hipervisor de tipo 1, o que significa que o hipervisor corre directamente no hardware, e os convidados correm no topo do kernel Xen . O kernel Xen fornece paravirtualização aos seus convidados, ou as interfaces de hardware que o Linode vê são traduzidas para chamadas de máquina reais através do kernel Xen e devolvidas ao utilizador. A razão pela qual esta camada de tradução existe é fornecer segurança e outras características de segurança para que a instrução certa vá para o Linode correcto.

Vários anos depois disso, estava a ser desenvolvida uma nova tecnologia chamada KVM (Kernel Virtual Machine). KVM consiste em partes do kernel Linux que fornecem interfaces paravirtuais às instruções do CPU. Qemu é uma das tecnologias de virtualização que pode tirar partido de KVM. Linode decidiu mudar novamente para benefício dos nossos clientes. Quando os clientes levaram a actualização gratuita para KVM a maioria das cargas de trabalho viu um aumento instantâneo no desempenho. Este tipo de paravirtualização é diferente de Xen: as instruções do CPU passam do hóspede (Qemu) para o núcleo hospedeiro e directamente para o CPU utilizando as instruções ao nível do processador, permitindo velocidades de execução quase nativas. Os resultados dessas instruções são devolvidos ao Linode que as emitiu, sem a sobrecarga que Xen exige.

Então o que é que isto tudo tem a ver com as instâncias GPU Linode?

A Linode fez uma prospeção de mercado e tentou determinar o que era mais conveniente para os clientes interessados em executar cargas de trabalho de GPU. Decidimos fornecer GPUs diretamente aos clientes utilizando uma tecnologia chamada "host passthrough". Dissemos à Qemu que dispositivo de hardware gostaríamos de passar ao convidado, neste caso a placa GPU, e a Qemu trabalha em conjunto com Linux para isolar a placa GPU para que nenhum outro processo no sistema a possa usar. A máquina anfitriã Linux não a pode usar, os outros Linodes na máquina também não o podem fazer. Apenas o cliente que o solicitou pode utilizar a placa GPU e recebe a placa completa. O dispositivo de hardware real é suportado, inalterado e não paravirtualizado, o que significa que não há camada de tradução.

Semana 1 : Hardware Chega à Linode

Com a investigação terminada, toda a equipa decidiu seguir em frente com o projeto. Para que o plano resultasse, o sistema necessitou de algumas alterações em toda a pilha de baixo nível. O hardware chegou numa segunda-feira e tínhamos cinco dias para decidir se queríamos seguir em frente com uma grande encomenda de um centro de dados e para cumprirmos os prazos.

Todos estavam envolvidos na mesma teoria, se não conseguíssemos que funcionasse numa semana normal de trabalho de 40 horas, não seguiríamos em frente. Isto significava que não havia pressão para trabalhar fora de horas, mas tínhamos apenas cinco dias para determinar o futuro de um novo produto Linode.

Então, o que acabou por acontecer? Isto resultou que toda a nossa investigação valeu a pena. Tentámos seguir alguma documentação já existente, e funcionou exatamente como esperávamos. No espaço de dias, fomos capazes de agregar de uma forma fiável GPUs a Linodes num ambiente de teste. Na sexta-feira, estávamos confiantes que o conseguíamos fazer. O teste foi bem sucedido! Agora estava na altura de colocar uma grande encomenda para os clientes e seguir em frente.

Semana 2: Fazer com que a Camada de Interface trabalhe com as GPUs

Depois de um teste inicial bem sucedido, voltámos ao escritório na segunda-feira com as pilhas carregadas e prontos para integrar o processo de agregação da GPU com a nossa criação dos fluxos de trabalho Linode existentes. Tentámos fazer a nossa interface o mais simples possível, apenas alguns cliques para implementar um LInode, e muito vai para aquelas poucas ações que tivemos de justificar.

Para que as GPUs fossem possíveis, tiveram de ser escritas e implementadas várias peças de nível baixo, tais como isolar a RAM para a GPU e para o Linode, bem como dar ao LInode núcleos CPU dedicados que foram emparelhados com a RAM isolada e a GPU. Investigámos a arquitetura NUMA (Non Uniform Memory Access) da motherboard e fomos capazes de isolar o grupo NUMA de RAM ao CPU que estava associado e o grupo NUMA que estava agregado à pista PCIe (PCI [Peripheral Computer Interface] express) em que a GPU estava ligada. Isto permitiu-nos implementar um Linode com 1, 2, 3, ou 4 GPUs agregadas e aproveitar a RAM e os núcleos CPU que estavam diretamente associados com a placa GPU com base na estrutura da motherboard.

Após a camada de hardware ter sido feita, trabalhámos na interface com os mecanismos de fila de trabalho de Linode, para que pudéssemos arrancar Linodes através do nosso Cloud Manager e API. Nesta fase, pudemos começar a testar a fiabilidade. A última coisa que queríamos era que um engenheiro de plantão fosse chamado a meio da noite por causa de um sistema que falhou, ou que um sistema fosse desligado a meio do dia de trabalho para um cliente num fuso horário diferente. Tendo em mente tanto os horários de sono dos clientes como dos engenheiros, começámos a testar cedo, e continuámos a assegurar que os clientes acabassem com um produto sólido e fiável.

Semana 3: Fazer alterações na Interface de Administrador e no Controlo

Na semana três, tivemos alguns problemas administrativos para enfrentar: Como vamos seguir os clientes que estão atribuídos e a que LInodes? De que forma enviamos clientes para uma instância Linode com uma GPU e não para um Linode sem uma GPU?

Todo o sistema de seguimento e controlo tinha de ser implementado. Fizemo-lo para que soubéssemos controlar quantas placas de GPU tínhamos, quantas foram ocupadas, quantas estavam vazias e quantas ainda podiam ser vendidas a novos clientes. Também tivemos de implementar este seguimento de GPU nas nossas interfaces de administrador internas. Isto pode parecer um trabalho de controlo aborrecido, mas foi necessário muito talento de toda a nossa equipa e de membros externos à equipa, para fazer a interface deste novo produto com todos os nossos produtos já existentes, sem serem necessárias etapas manuais.

Felizmente, juntámos todos e fomos capazes de escrever o código e testá-lo para nos assegurarmos que funcionava bem, que trabalhava de forma fiável e que não necessitava de intervenção manual para obter uma instância GPU Linode a funcionar. Outro benefício de fazer este trabalho foi que nesta fase de trabalho o teste foi mais fácil. Tivemos apenas de carregar num botão da nossa interface de administrador para criar uma instância GPU Linode.

Semana 4: Tornar público API Alterações para que os clientes possam rodar Linodes

Depois de fazer o botão de interface do administrador para trazer à tona uma instância de GPU Linode, estávamos a sentir-nos bastante bem. Agora, precisávamos de trabalhar no sentido de expor esta mesma funcionalidade aos clientes. O público API é apoiado por Python, o que tornou o código extremamente intuitivo. Fomos capazes de lançar as alterações e testá-las muito rapidamente. A parte complicada foi tornar esta funcionalidade disponível dentro da empresa para testes, mas não disponível fora da empresa até termos feito os testes necessários para fins de fiabilidade.

Semana 5: Implementar! Ou, Como Implementar uma Funcionalidade Pública através de um comando de ativação

Implementar cedo e implementar frequentemente.

Estávamos literalmente no arame, por isso colocou-se a questão, de que forma podemos lançar isto ao público e finalmente ter clientes a usarem este novo serviço?

A resposta foi lidar com tudo o que era desconhecido mais cedo e controlar ao implementar cedo e frequentemente. Enquanto ainda estávamos a fazer testes aos casos de utilização, implementámos as instâncias GPU Linode no público, mas escondidas por um botão de ativação. Fomos capazes de testar as GPUs em contas de empregados e isso permitiu-nos assegurar que as coisas se comportavam exatamente como esperado se um cliente tivesse de as utilizar. Sempre que encontrámos algo que não esperávamos, solucionávamos o problema e fizemos uma implementação pública.

Devagar, mas seguros, e implementando o código quase todos os dias, resolvemos tudo na nossa lista. Esgotámos as alterações e sentimo-nos confiantes em disponibilizar isto aos clientes.

Semana 6: Teste! Disponibilizar GPUs aos empregados Linode

Uma das grandes vantagens em trabalhar na Linode é a de que lidamos com tecnologia de ponta antes de qualquer outra pessoa. (P.S. estamos a recrutar!) Qualquer empregado tem a possibilidade de colocar um novo produto a trabalhar ao seu ritmo para que qualquer peça de tecnologia que lançamos seja testada até à exaustão. Qualquer empregado pode registar-se para testar uma instância GPU Linode durante as horas de trabalho, mesmo depois do trabalho se assim o quiserem fazer, para utilizarem uma instância GPU Linode como se fossem um cliente. Tudo o que tiveram de fazer foi etiquetar a sua conta de empregado e girar uma GPU.

Aqui ficam algumas formas como os Linodeanos experimentaram as novas GPUs:

  • Jogar na cloud - Onde o jogo é executado na instância GPU Linode, o vídeo e os controlos são enviados via Steam Link™
  • Renderização 3D
  • Transcodificação de vídeo
  • Teste de robustez da password
  • Execução de TensorFlow

Após esta fase, recolhemos métricas de desempenho e decidimos que estávamos prontos para ir para a produção e lançamento aos clientes.

Lançamento!

Lançámos! Celebrámos! Houve gelado e swag! Os clientes começaram a experimentar o produto que esteve em desenvolvimento há apenas umas semanas. A melhor parte foi que tudo funcionou no dia do lançamento. Não tivemos de fazer alterações de última hora, não houve fogos para apagar, os clientes estavam satisfeitos e tudo trabalhou de forma fiável.

O lançamento efectivo do código não foi difícil. Da perspectiva do código e da configuração do sistema, tudo o que foi preciso para lançar GPUs para a produção foi a remoção de uma bandeira de funcionalidade. Mas há também toneladas de outras coisas que vão para o lançamento de um produto em Linode: documentação técnica, fazer as alterações de IU no Linode Cloud Manager, e todo o material de marketing divertido para ajudar a celebrar o nosso novo produto.

Após o Lançamento: Nenhuma alteração de código durante seis meses

Algumas perguntas ficam sempre nas nossas cabeças, fizemos suficientes testes? As seis semanas passaram muito depressa?

No nosso caso foi apenas a velocidade certa: não tive de tocar no código desde o lançamento. E, as GPUs Linode têm visto a utilização por parte dos clientes todos os dias. É óptimo quando se pode construir um produto e tê-lo a funcionar, e depois continuar e construir outros grandes produtos, e aquela coisa que se construiu há dois anos ainda está a funcionar, tudo por si só, com o mínimo de interacção necessária

Em retrospetiva aqui ficam alguns apontamentos que nos permitiram que fossemos tão bem sucedidos:

  1. Fazer investigação antecipada - Isto ajudou-nos muito a tratar de tudo o que era desconhecido que não poderíamos ter feito se tivéssemos o hardware connosco.
  2. Fazer um plano - Tínhamos um plano muito detalhado e cada etapa tinha de ser executada no tempo devido caso contrário não teríamos conseguido o lançamento.
  3. Respeitar o plano: Mantendo o foco na tarefa em mãos e ter em mente as restantes tarefas que tinham de ser executadas.
  4. Ter uma boa equipa de gestão - Assegurar que todos os níveis de gestão têm o entendimento que, se um projeto tem um prazo muito apertado, se perde uma etapa o prazo de lançamento não será atingido. Isto pode ter sido o mais importante que nos permitiu sermos bem sucedidos. Alguma pressão é bom, como foi o nosso caso, demasiada pressão conduz ao burn out e ao erro. Depois de discutido o tempo de execução com a gestão ficaram totalmente ao corrente de tudo.
  5. Ajudar-nos uns aos outros - A equipa que teve a oportunidade não a teria tido sem toda uma estrutura de apoio da restante organização. Quando todos os colaboradores querem ser bem sucedidos todos se irão juntar se necessitarmos deles.
  6. Testar, testar, testar, testar, se eu pudesse escrever mais uma vez, seria testar. Ambos os testes o automático e o manual. Isto foi de longe a razão principal pela qual ninguém da minha equipa teve de tocar no código em mais de 6 meses.

Saiba mais sobre as instâncias GPU LInode consultando a nossa documentação sobre GPU , e acabámos de expandir a nossa disponibilidade em GPU nos nossos centros de dados de Newark, Mumbai e Singapura.

Interessado em experimentar as GPUs Linode para as suas cargas de trabalho atuais? Pode obter um teste gratuito durante uma semana para saber como funcionam as GPUs. Saiba mais aqui.

(E novamente, se quer ajudar-nos a desenvolver e a testar produtos como as GPUs Linode, nós estamos a recrutar!)

Comentários (1)

  1. Author Photo

    how to make windows os in linode

Deixe uma resposta

O seu endereço de correio electrónico não será publicado. Os campos obrigatórios estão marcados com *