Bem temperado. Hardware delicado

Transcrição

1 Red Hat para desktops virtuais ANÁLISE Bem temperado A Red Hat confere ânimo ao desempenho de aplicativos multimídia em desktops remotos com o SPICE, protocolo simples para ambientes de computação independentes. por Udo Seidel O Linux oferece muitos protocolos e implementações que permitem o acesso remoto às interfaces gráficas de outros computadores. O recurso de rede do X Window, por exemplo, é fabuloso e transforma cada máquina Linux ou Unix em um potencial terminal de servidor. Ele costumava ser o bastante em solução de desktop remoto para transferência de interface gráfica através da rede, mas os usuários e administradores de hoje têm necessidades muito mais sofisticadas. Cenários modernos exigem o acesso ao hardware, e todas as transferências de dados entre o servidor e o cliente devem ser seguras. Cada vez mais, usuários de celulares desejam interromper sessões para retomá-las posteriormente em um computador ou outro dispositivo. Protocolos e aplicativos, como o protocolo de desktop remoto da Microsoft (RDP, Remote Desktop Protocol ) ou o NoMachine, da NX, dominam todos estes desafios sem problemas; no entanto, quando se trata de multimídia, eles estão muito aquém do desempenho de um desktop instalado localmente. Hardware delicado Feliz é aquele cujas placas de som, impressora ou unidade Flash USB locais funcionam corretamente em rede. No entanto, quando se trata de 3D, efeitos transparentes cativantes, ou reprodução de vídeos HD sem solavancos, o trigo é separado do joio. Apenas dois produtos prometem bom resultado: A Citrix está apostando em seu produto comercial HDX ( High-Definition User Experience ) [1], e a Red Hat aposta no protocolo, servidor e cliente SPICE [2]. O SPICE (protocolo simples para ambientes de computação independentes) promete ao usuário da nuvem acessar diretamente os componentes de hardware instalados no servidor, bem como um transparente repasse de desempenho para o cliente. Era uma vez De acordo com o site do projeto, o SPICE...tem como objetivo fornecer uma solução completa em código aberto para a interação com dispositivos de desktop virtualizados. O SPICE foi desenvolvido pela Qumranet e, como tantos softwares desenvolvidos em Israel, não era inicialmente um produto de código aberto. A Qumranet causou polêmica na comunidade Linux com o desenvolvimento do KVM. O trabalho anterior com virtualização KVM obrigou a empresa a enfrentar problemas como a transmissão de vídeo de elevado desempenho e encaminhamento de USB e, em 2007, publicou a primeira versão do SPICE. A Red Hat assumiu a Qumranet em 2008 e prescreveu a estratégia 68

2 Red Hat para desktops virtuais ANÁLISE de código aberto que continua até hoje. Por sua vez, o protocolo SPICE é distribuído sob a licença BSD, e a maior parte da implementação está sob a GPL. Desde 2010, o projeto SPICE é um membro do projeto Freedesktop. org [3]. Até poucos anos atrás, os usuários só podiam usar o protocolo de acesso para convidados virtuais, mas um aplicativo para o servidor X ( Xspice [4] ) foi disponibilizado em Tijolo por tijolo O SPICE inclui uma miscelânea de componentes que se enquadram em quatro categorias: Protocolo Servidor Cliente Componentes mediadores Dependendo da tarefa, vários intermediários entram em uso por exemplo, placas gráficas virtuais QXL [5] e interfaces VDI (desktop virtual/interface do dispositivo) [6]. A interação entre os vários componentes, com um foco nos convidados virtuais, é mostrada na figura 1. O aplicativo primeiro se comunica com o vídeo da máquina local por exemplo, o servidor X. Este envia a solicitação para o dispositivo QXL com a ajuda do driver. A partir daí, o servidor SPI- CE pega o pedido, processa e envia para o cliente SPICE. Se os agentes SPICE estiverem envolvidos, o sistema operacional convidado Figura 1 A interação dos vários componentes do SPICE. faz a comunicação através de dispositivos de porta VDI ou drivers com o servidor SPICE. A comunicação entre o servidor e o cliente SPICE é dividida em canais que trabalham em paralelo, cada um responsável por uma classe específica de dados. O canal principal é uma espécie de instância de gerenciamento que cria, configura, controla e fecha os outros canais. A tabela 1 mostra os canais do SPICE, sua utilização pretendida, e quais componentes do sistema operacional do convidado estão envolvidos. O protocolo SPICE rege a comunicação entre o servidor e o cliente. Ele define os tipos de mensagens para acessar, controlar e receber a entrada de dispositivos remotos. Não importa se o dispositivo reside localmente no servidor SPICE ou no cliente SPICE. Os canais mostrados na tabela 1 fazem parte das especificações de protocolo SPICE. O ambiente SPICE inclui um mecanismo de autenticação com Canal Responsável por Dispositivo do SO Convidado Aplicativo do SO Convidado Principal Gestão dos outros canais Virtio serial VDI Agent Vídeo Comandos gráfi cos, imagens e vídeo Dispositivos QXL Drivers QXL Entradas Entradas de teclado e mouse Teclado, mouse, tablet Drivers Padrão do SO Cursor (Mouse) posição e forma do ponteiro Dispositivos QXL Drivers QXL Reprodução Gravação Processamento de áudio do servidor para o cliente Processamento de áudio do servidor para o cliente Tabela 1 Canais de comunicação do SPICE. Placa de som Placa de som Drivers Padrão do SO Drivers Padrão do SO Linux Magazine #96 Novembro de

3 base em ingressos no formato X.509 com uma chave RSA de 1024 bits. As implementações atuais do SPICE também suportam a camada de segurança e autenticação simples (da sigla SASL, de Simple Authentication and Security Layer ) para acesso seguro. As mensagens definidas pelo protocolo ou são de natureza geral, específicas para o servidor ou cliente, ou válidas para um determinado canal. Mais detalhes são encontrados nas especificações do protocolo no site do projeto. O SPICE utiliza a segurança da camada de transporte (TLS, Transport Layer Security, RFC 2246) para criptografia de dados e, consequentemente, o servidor precisa de seu próprio certificado. Cada certificado X.509 (RFC 5280) deve ser assinado por uma CA (Unidade Certificadora) raiz. Para o servidor SPICE poder verificar esta assinatura, os usuários devem especificar seu caminho na inicialização tanto no servidor como no cliente. Na prática Para implementar o SPICE, o melhor é começar com o cliente. O cliente spice-gtk [7] já vem integrado com o virt-viewer. O usuário só precisa mudar o tipo de visualização na caixa de diálogo de preferências do virt-manager de VNC para SPICE. Os desenvolvedores implementaram o cliente spice-gtk como bibliotecas nas quais o virt- -viewer está vinculado. Pelo fato de o virt-manager ser programado em Python, ele usa um módulo correspondente para controlar o cliente spice-gtk. O spicy e o spicec ( figura 2 ) são verdadeiros clientes independentes. Como com um cliente VNC, o usuário especifica os detalhes da conexão com o servidor SPICE na inicialização. No entanto, o cliente SPICE HTML5 [8], ainda Figura 2 Os programas clientes spicy (esquerda) e spicec (direita) são semelhantes aos clientes VNC comuns. é muito novo. Além do HTML5, ele também requer JavaScript e um proxy WebSockets [9] ; os desenvolvedores prometem tornar os desktops remotos disponíveis para qualquer navegador em algum momento no futuro. O servidor SPICE também é implementado como uma biblioteca. Desde 2010, o QEMU/KVM é vinculado ao libspice-server.so e pode portanto fornecer o recurso do SPICE. Embora o VNC ainda seja o padrão para acessar a interface gráfica de um convidado, a mudança para o SPICE é bem simples. Porém, se quiser tirar o máximo de seus recursos, o usuário precisará usar uma placa de vídeo diferente e trocar para os drivers QXL. Para os amantes da linha de comando, isto pode ser feito com a opção -vga qxl do KVM. No entanto, o ajuste correspondente no virt-manager está a apenas alguns cliques de distância no menu hardware. Temperos para o X11 O driver SPICE para o servidor X vem com um script chamado Xspice, escrito em Python. No entanto, no momento da publicação deste artigo, o script na melhor das hipóteses só pode ser considerado experimental: o desempenho da rede é pior do que com o VNC, e a sincronização da posição do cursor tem erros. A implementação do servidor SPICE no QEMU/KVM é muito mais avançada e atualmente a mais utilizável. Ela constitui a base para as descrições e testes a seguir. O encaminhamento de vídeo e a segurança através de SSL/TLS não são características realmente notá- Listagem 1: ich9-ehciuhci.cfg 01 # cat /etc/qemu/ ich9-ehci-uhci.cfg 02 [device "ehci"] 03 driver = "ich9-usb-ehci1" 04 addr = "1d.7" 05 multifunction = "on" [device "uhci-1"] 08 driver = "ich9-usb-uhci1" 09 addr = "1d.0" 10 multifunction = "on" 11 masterbus = "ehci.0" 12 firstport = "0" [device "uhci-2"] 15 driver = "ich9-usb-uhci2" 16 addr = "1d.1" 17 multifunction = "on" 18 masterbus = "ehci.0" 19 firstport = "2" [device "uhci-3"] 22 driver = "ich9-usb-uhci3" 23 addr = "1d.2" 24 multifunction = "on" 25 masterbus = "ehci.0" 26 firstport = "4" 27 # 28 # 70

4 Red Hat para desktops virtuais ANÁLISE veis, pois os ancestrais de desktops remotos, como o X e o VNC, já podiam fazer isso. Outros recursos, no entanto, tornam o SPICE realmente interessante. O primeiro seria o seu suporte a áudio. Embora o QEMU (em conjunto com o VNC) já tivesse um complemento que permitia o encaminhamento de som, infelizmente quase nenhum dos clientes VNC suporta isso. O SPICE, por outro lado, já é bem preparado para esta tarefa e inclui uma implementação que funciona para servidor e cliente. Com uma pequena preparação, o usuário pode reproduzir um arquivo de áudio no KVM convidado e ouvi-lo no cliente SPICE. Para que isso aconteça, os recursos correspondentes devem ser primeiro ativadas no servidor QEMU/KVM. O comando qemu -audio-help revela uma grande variedade de opções de configuração mas, no caso mais simples, é suficiente para configurar a variável QEMU_AUDIO_DRV para o backend de áudio desejado ( tabela 2 ). No entanto, isto não é o suficiente, pois o cliente deve possuir uma placa de som virtual também. Os modelos AC97 e ICH6 provaram ser eficientes, mas no teste para este artigo, uma Creative Soundblaster16 e uma ENSONIQ AudioPCI ES1370 emuladas também funcionaram. No lado cliente do SPICE, não importa se usamos o virt-viewer, virt-manager, spicec ou spicy nos Figura 3 O spicy permite que o usuário escolha o dispositivo USB a ser encaminhado. testes, todos reproduziram o som sem problemas. Repasse de dispositivos USB Outro deleite picante do SPICE é o redirecionamento de USB, que permite ao usuário acessar um dispositivo USB local no convidado virtual (no servidor). Assim como acontece com o canal de áudio, tanto o servidor como o cliente dão o suporte necessário. No teste para este artigo, isso só foi verdade no caso do spicy. O QEMU/KVM suporta USB 2.0 através de um controlador EHCI virtual ( Enhanced Host Controller Interface ). Para que isto funcione, o usuário deve primeiro dar ao QEMU uma configuração especial ( listagem 1 ) e induzir que ela seja aplicada quando a instância virtual iniciar ( listagem 2 ). Com o argumento -readconfig /etc/qemu/ich9-ehci-uhci.cfg, o administrador liga o suporte para USB 2.0. As portas USB associadas são definidas pelas opções -chardev e -device do QEMU. Isso prepara o terreno necessário para o servidor SPICE, e o usuário pode iniciar o convidado virtual. O cliente spicy do SPICE for- Backend de audio no QEMU Valor QEMU_AUDIO_DRV Site do Projeto PulseAudio pa SDL sdl ALSA alsa OSS oss Tabela 2 Confi guração de som. Listagem 2: Iniciando o Qemu/KVM 01 qe mu -readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=0 Linux Magazine #96 Novembro de

5 nece agora um menu para selecionar os dispositivos a serem encaminhados ( figura 3 ). Posteriormente, o dispositivo fica disponível no convidado como um hardware local estaria. Se a rede tiver um servidor USB sobre IP [10], este também estará acessível para o usuário. Nesse caso, o dispositivo USB não está integrado ao servidor através do SPICE, mas por encapsulamento USB em TCP. O melhor é apenas colocar todos os parâmetros (muitas vezes numerosos) do QEMU em um único arquivo de configuração XML no convidado com a instrução qemu:commandline. Tempo para poupar É um verdadeiro desafio obter transmissão de alto desempenho de interfaces gráficas modernas com toda sua riqueza de detalhes e grandes fluxos de vídeo via bandas mais estreitas. Como o NX, o SPICE baseia-se em um cache local e procura evitar qualquer tipo de tráfego desnecessário. Ele armazena imagens, paletas de cores e informações de cursor no cache. Mas quando não pode se basear em transferência de uma imagem, o SPICE coloca vários métodos de compressão para funcionar: o QUIC (baseado no SFALIC, Simple Fast and Adaptive Lossless ImageCompression ) [11], o LZ (Lempel-Ziv), ou o GLZ (generalized Lempel-Ziv) [12]. Para transmissão de vídeo, o M-JPEG O autor Udo Seidel já trabalhou como instrutor Linux, administrador de sistemas e engenheiro sênior de soluções. Hoje, ele é chefe da equipe Linux/Unix na empresa alemã Amadeus Data Processing. Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso o site: 71 (Motion JPEG) é utilizado. É possível configurar tanto o algoritmo de compressão como o reconhecimento de transmissão de vídeo com as opções fornecidas pelo QEMU. Perspectivas Embora nem tudo funcione, o SPI- CE parece ter um futuro promissor pela frente. Por um lado, mais e mais clientes estão sendo desenvolvidos e não apenas para o Windows e o Linux [13], mas também para Mac OS X [14], o Android [15] e o N900. Até mesmo os fabricantes de hardware, como a IGEL, especialista em thin client [16], tem demonstrado interesse. Visitantes da CeBIT experimentaram o estado atual do desenvolvimento do SPICE, notando uma enorme Mais informações diferença de desempenho entre os clientes Windows e Linux. Os vídeos em HD foram renderizados aos solavancos no cliente Linux, mas não nas máquinas com Windows. A Red Hat integrou as características que faltam em clientes existentes e está trabalhando em recursos completamente novos. Entre estes novos recursos estão o suporte a gráficos 3D e acesso a diretórios locais da máquina do cliente. As funções disponíveis na área de virtualização já são bastante úteis e, particularmente em convidados baseados em Linux, vale muito à pena a mudança para o SPICE. Mas o Xspice deve ser significativamente melhorado antes de o SPICE tornar-se uma alternativa real para o VNC, RDP e NX. [1] Citrix HDX: [2] Red Hat SPICE: -space.org/ [3] Projeto Freedesktop.org: [4] SPICE para X11: -space.org/page/features/xspice/ [5] Red Hat, Spice para Iniciantes, Capítulo 2.6: spice -space.org/wiki/images/1/17/spice_for_newbies.odt [6] VDI (Virtual Desktop/Device Interface): spice -space.org/vdi.html [7] Cliente GTK para SPICE: freedesktop.org/spice/spice -gtk/ [8] Cliente HTML5: -html5/ [9] WebSockets: -US/docs/WebSockets/ [10] USB sobre IP: [11] Algoritmo SFALIC: pl/~rstaros/sfalic/index.html [12] Algoritmo LZ: [13] Clientes SPICE: -space.org/download.html [14] SPICE para Apple: com.br/2011/06/spicy-apples.html [15] SPICE para Android: com/p/spice -client-android/ [16] Clientes VDI: 45-to-its-linux-thin-clientrange.html 72