É o Bill Vass de volta com outra carta. Antes que os meus fiéis leitores se questionem sobre o que estou fazer, devo explicar que nas minhas cartas estou a criar um conjunto de tecnologias que podem ajudar as empresas a reduzir as despesas dos centros de dados, melhorara a utilização de hardware e aumentar a disponibilidade e desempenho das aplicações.

Nas últimas cartas, discutimos como o Processador CMT da Sun pode reduzir as exigências dos centros de dados, como a fonte aberta e OpenSolaris podem melhorar a segurança e desempenho das aplicações e como o middleware de fonte aberta pode ajudar as empresas a tirara o máximo partido dos investimentos de legado. Nesta edição, vou recuar um ou dois passos para discutir um tema escaldante para as empresas actuais - a virtualização.

Nos termos mais básicos, a virtualização trata-se de abstrair os recursos informáticos do hardware subjacente. Como tal, as tecnologias de máquinas virtuais emergiram como um fenómeno recente que se tornou quase sinónimo da própria virtualização. Mas as máquinas virtuais não são de todo o “mais que tudo” da virtualização. Os esquemas de virtualização de sistemas operativos como os Contentores Solaris têm um importante papel a desempenhar. De uma perspectiva mais alargada, as grelhas oferecem o potencial para arquitecturas virtualizadas e partilhadas de forma generalizada que podem transformar drasticamente a forma como as aplicações são desenvolvidas e fornecidas.

A razão de negócios para a virtualização

Não é segredo que a manutenção do hardware no centro de dados pode significar custos elevados. Consumo de energia, refrigeração e custos de espaço físico constituem uma tripla ameaça aos orçamentos de TI. A maior parte das empresas constrói tendo em conta os picos de cargas, mas as alturas de pico tendem a chegar em massa no último trimestre do ano, e no tempo restante as taxas de utilização de hardware andam à volta dos 10 a 15 porcento. Como consequência, muitos recursos são subaproveitados – o que representa um enorme desperdício de capital, energia e espaço.

A gestão de vastas áreas de servidores cria outra despesa crescente. À medida que o preço do hardware desce, os custos de administração continuam a aumentar. Por isso, se não contarmos com os custos directos dos grandes centros de dados, reduzir o número de máquinas físicas a supervisionar e manter é outra motivação para utilizar tecnologias de virtualização – partindo de princípio que uma empresa não muda simplesmente da gestão física para a gestão de máquinas virtuais.

Menos discutido, mas não menos importante, é o facto de as empresas dependerem do hardware para disponibilidade de aplicação. Muitas organizações implementam hardware redundante para ajudar a garantir uma aplicação contínua e operações de negócio e evitar comprometer o tempo de não funcionamento. A redundância do hardware é não só um meio pouco eficaz de garantir a disponibilidade das aplicações, como também serve para multiplicar as despesas dos centros de dados.

A virtualização apareceu como uma forma de solucionar tanto a utilização como a redundância. Ao permitir que várias aplicações e instâncias de sistemas operativos partilhem recursos de hardware, a virtualização promove maiores taxas de utilização e um melhor retorno do investimento. Ao abstrair o software do hardware subjacente, a virtualização oferece maior disponibilidade porque as aplicações podem tornar-se redundantes sem depender do hardware temperamental. Em resumo, a virtualização ajuda as organizações a:

• Melhorar as TI e a flexibilidade de negócios
• Aumentar e reduzir rapidamente a infra-estrutura
• Aumentar a disponibilidade e desempenho das aplicações
• Simplificar a gestão de aplicações e aumentar o desempenho das aplicações por dólar gasto

O renascimento das máquinas virtuais

As tecnologias de máquinas virtuais tornaram-se numa forma bem aceite de virtualização. Essencialmente, estas tecnologias permitem à máquina física hospedar múltiplas instâncias de sistemas operativos virtuais, e estas permitem que sistemas operativos diferentes como Solaris, Linux e Windows coexistam de forma pacífica no mesmo hardware.

Nos últimos anos, a tecnologia VMware evidenciou-se como a provável líder no mercado das máquinas virtuais. A tecnologia de virtualização VMware funciona criando um hipervisor, que funciona como um mini-sistema operativo que é executado em primeiro lugar e essencialmente virtualiza o hardware subjacente em pequenos pedaços, para que os diferentes sistemas operativos possam correr no mesmo servidor físico. Esta abordagem provou ser particularmente atractiva para as organizações com aplicações de legado, que exigem um ambiente de sistemas operativos misto.

Embora apelativa, a abordagem de máquina virtual VMware pode ser relativamente dispendiosa do ponto de vista do desempenho. Tipicamente, o hipervisor consome entre 5 a 15 porcento da energia total da CPU, enquanto cada sistema operativo adiciona uma sobrecarga adicional. No fim, as empresas podem consumir grandes quantidades de recursos da CPU somente para suportar a infra-estrutura da máquina virtual. As máquinas virtuais podem ainda afectar negativamente a capacidade de observação pois se uma aplicação falhar, torna-se mais difícil saber se o responsável é a aplicação, o sistema operativo ou a própria máquina virtual.

Recentemente, o software de fonte aberta Xen apareceu como uma alternativa ao VMware. Tal como com o VMware, o Xen suporta a execução de múltiplos sistemas operativos externos no mesmo hardware. Xen é uma forma muito mais reduzida de virtualização que permite aos administradores virtualizar várias partes de um sistema, incluindo a memória e a CPU. E, porque reside a nível tão reduzido, oferece um isolamento significativo de recursos e falhas.

Existem muitas razões convincentes para considerar o Xen. Primeira, é de fonte aberta. Segunda, é de processamento relativamente leve, por isso não consome uma quantidade excessiva de recursos da CPU. Terceira, atinge um elevado nível de isolamento no âmbito das tecnologias de máquinas virtuais. Finalmente, como em outras tecnologias de máquinas virtuais, suporta versões e sistemas operativos mistos e permite aos administradores fundamentar e executar de forma dinâmica uma instância de sistema operativo sem interferir com o serviço.

Usar Contentores Solaris com máquinas virtuais

Está disponível gratuitamente outra forma de virtualização para todos os utilizadores do SO Solaris 10, nomeadamente os Contentores Solaris. Dentro do Solaris, é possível virtualizar ambientes de aplicações usando Contentores Solaris – dando a cada aplicação o seu próprio endereço IP, sistema de ficheiros, utilizadores e recursos atribuídos. Para além disso, os Contentores Solaris são de processamento extremamente leve porque a virtualização acontece a nível do núcleo. Por não existir a sobrecarga acrescida de múltiplos núcleos, é possível correr centenas, se não milhares, de Contentores Solaris num único servidor. Mais, com os Contentores Solaris para aplicações Linux, é agora possível correr aplicações Linux completamente inalteradas em Contentores Solaris.

Embora os contentores Solaris não permitam a utilização de múltiplas instâncias de sistemas operativos, a tecnologia oferece ainda assim inúmeras vantagens.

Maiores taxas de utilização: Os Contentores Solaris promovem taxas de utilização mais altas porque os contentores consomem apenas os recursos exigidos pelo volume de trabalho sem sobrecarga acrescida.

Custos de gestão mais reduzidos: Os Contentores Solaris reduzem os custos de gestão porque os administradores não têm de manter uma instância de sistema operativo separada para cada volume de trabalho.

Excelente capacidade de observação: Os Contentores Solaris fornecem visibilidade para o ambiente virtualizado, particularmente em conjunto com outras funcionalidades Solaris como o DTrace para resolução de problemas em tempo real.

Provisionamento rápido: Os Contentores Solaris disponibilizam um provisionamento rápido e disponibilidade de anfitriões a curto prazo, tal como num ambiente QA que realiza testes de regressão de diferentes sistemas e configurações de serviço. Custos de licenciamento reduzidos: Os Contentores Solaris podem reduzir potencialmente os custos de licenciamento pois uma licença de SO pode suportar centenas de Contentores Solaris.

Ainda assim, os elevados níveis de recursos e isolamento de falhas oferecidos pelas máquinas virtuais não devem ser subestimados. Existem alturas em que as aplicações simplesmente exigem isolamento superior à capacidade dos Contentores Solaris. Nessas circunstâncias, é possível usar máquinas virtuais em conjunto com Contentores Solaris par alcançar os níveis óptimos de isolamento, utilização e administrabilidade.

Misturar Contentores Solaris e máquinas virtuais

Vamos considerar o exemplo de quando a mistura de máquinas virtuais e Contentores Solaris pode fazer sentido. Assumimos que existe uma aplicação que exige actualização por razões de segurança e desempenho, e uma segunda aplicação com um nível de actualização incompatível. Mais, existe uma terceira aplicação de legado que está ligada ao sistema operativo Windows. Estas três aplicações têm de correr em máquina virtual em três instâncias de sistemas operativos. Agora vamos partir do princípio que o mesmo ambiente tem mais quarto aplicações que são compatíveis em termos de actualizações.

Neste exemplo, as três aplicações que requerem instâncias de sistema operativo próprio podem ser virtualizadas usando máquinas virtuais, e uma quarta instância de sistema operativo em máquina virtual pode alojar os quatro Contentores Solaris par as aplicações que requerem apenas uma instância de Solaris. As vantagens incluem:

• Os contentores Solaris permitem às aplicações partilhar o mesmo conjunto de actualizações
• Os administradores apenas têm de manter uma instância de sistema operativo
• Os administradores não têm de guardar registos de várias máquinas virtuais
• A organização reduz as suas despesas administrativas

Grelhas: A virtualização de ontem, hoje e amanhã

Até agora esta carta tem sido muito aberta em termos de expandir os horizontes do discurso sobre virtualização. Mas isso está prestes a mudar. Existe uma área onde a virtualização há muito tem sido empregue mas pouco divulgada em termos de virtualização - falamos das grelhas. Embora as grelhas possam não se parecer com virtualização, se nos lembrarmos da definição dada no início desta carta – abstrair os recursos informáticos do hardware subjacente – não existe exemplo mais promissor de virtualização.

À medida que as empresas vão percorrendo o caminho para um ambiente virtualizado, vão descobrir que a virtualização se deve na sua essência ao ambiente em grelha. Isso acontece porque uma vez que existem instâncias virtuais de Solaris de múltiplos Contentores Solaris, os recursos nestes contentores podem ser consumidos por múltiplas grelhas. As grelhas de aplicação podem ser formadas e controladas por estruturas de grelha para fornecer software como serviços, e as grelhas de motores podem equilibrar os ciclos em excesso nas grelhas de computação. Mas, como habitual, estou a adiantar-me.

As grelhas, claro, não são novidade. São há muito empregues como forma de abordar em conjunto as tarefas de cálculo intensivo. Por exemplo, as grelhas foram utilizadas para criar simulações complexas de meteorologia, traçar mapas de campos de petróleo subterrâneos, modelar os efeitos da explosão de uma bomba atómica, simular o desempenho financeiro de derivados complexos e adicionar texturas multi-camadas aos frames individuais de um filme. Praticamente todas as indústrias que têm grandes exigências de processamento – e a maior parte delas fá-lo – dependem das grelhas.

Grelhas sem manutenção de estado vs. grelhas com manutenção de estado

A forma como as grelhas tradicionais funcionam é muito simples. Se um estúdio cinematográfico precisar de adicionar texturas a 1000 frames de um filme, o controlador de grelha estabelece 1000 processos paralelos, e estes processos são distribuídos pelo mesmo número de servidores. (Claro que, num ambiente virtualizado, pode facilmente tratar-se de 1000 Contentores Solaris em vez de 1000 servidores físicos ou CPUs).

De qualquer forma, se um dos servidores falhar, o controlador de grelha reúne as outras 999 volumes de trabalho, apercebe-se que falta uma e envia o volume restante para um servidor em funcionamento. Este tipo de grelha mais básico é conhecido como uma grelha sem manutenção de estado pois não faz qualquer diferença se alguém desligar um servidor; o controlador de grelha volta simplesmente a atribuir o volume de trabalho que desapareceu a outro servidor – sem qualquer consequência.

Recentemente, apareceram as chamadas grelhas de manutenção de estado. Em vez de instalar montanhas de ambientes de trabalho com enormes quantidades de energia de processamento desperdiçado, a Sun utiliza uma grelha de visualização em conjunto com clientes finos Sun Ray para enviar os ambientes de trabalho aos utilizadores onde e quando eles necessitam. Na Sun, o controlador de grelha atribui a cada pessoa o poder de processamento que ela necessita dos 700 servidores dedicados à grelha de visualização.

Por exemplo, quando um funcionário chega ao local de trabalho e inicia o StarOffice, o utilizador poderá necessitar de 60% do poder de processamento de uma CPU típica, e é exactamente essa quantidade que o controlador de grelha atribui ao utilizador. A grelha de visualização da Sun é chamada de manutenção de estado porque o utilizador tem uma ligação que mantém o estado da infra-estrutura subjacente – se alguém desligasse o ambiente de trabalho, o utilizador iria certamente notar.

Agora vamos considerar uma forma mais avançada de uma grelha com manutenção de estado — uma grelha de aplicação. Suponhamos que uma empresa pretende movimentar o seu sistema ERP Oracle não RAC para um ambiente de grelha, e que o sistema é composto por uma camada de apresentação de três níveis típica, camada de aplicação, e arquitectura de camada de base de dados. É possível atribuir 20 contentores da grelha para serem servidores Web e designar quatro desses contentores para actuar como equilibradores do volume.

Então, para o servidor da aplicação, a empresa poderia criar um conjunto com manutenção de estado entre dois conjuntos de contentores actuando como servidores de aplicação, de modo que se alguém desligar um dos servidores de aplicação, o controlador da grelha pode reiniciar as suas tarefas num servidor de aplicação em funcionamento. Agora, quando a empresa adiciona a camada da base de dados à grelha, a grelha atribui contentores como componentes com manutenção de estado, e pode tornar os contentores num conjunto de disponibilidade elevada ao longo da grelha, de modo que os contentores assumem diferentes localizações físicas.

No passado, para criar uma tal arquitectura, o sistema Oracle ERP iria normalmente necessitar de algo como 20 CPUs dedicados a cada camada — apesar do facto de um sistema ERP típico ter a tendência a ser fustigado de manhã, depois existe uma estagnação, e a procura de processamento tem outro pico da parte da tarde. Novamente, existe simplesmente demasiado hardware dedicado a utilização de pico, e demasiados recursos subaproveitados.

Num ambiente em grelha, é possível criar a mesma arquitectura utilizando contentores de grelha, de modo a que a camada do servidor Web é composta por 20 contentores, a camada da aplicação tem 10 contentores primários e 10 contentores para redundância, e a camada da base de dados tem 10 contentores adicionais e novamente mais 10 para redundância. E, todas as camadas partilham os mesmos recursos de hardware virtualizado.

Avançar em direcção a taxas de utilização de 100% do hardware

A verdadeira revolução é que se está a tornar possível misturar e fazer corresponder volumes — quer sejam com ou sem manutenção de estado — na mesma grelha. E é possível atribuir prioridade dada tendo em consideração a manutenção de estado ou vitalidade dos volumes. Por exemplo, um funcionário que execute o StarOffice retira potência de CPU dos grandes volumes dispensáveis de fundo. De igual modo, quando uma aplicação ou servidor de base de dados Oracle solicita potência de processamento o funcionário do StarOffice recebe os ciclos de CPU restantes, e os volumes dispensáveis recebem qualquer potência de processamento restante.

No final, através da possibilidade de permitir que todas as aplicações partilhem a mesma infra-estrutura virtualizada, e através do aproveitamento da gestão de recursos apropriados, as empresas podem ser capazes de atingir taxas de utilização de hardware próximas dos 100 por cento em vez dos 15 por cento da realidade actual — e melhorar a redundância e a disponibilidade ao mesmo tempo.

Virtualização, grelhas e a reunião de todos os elementos

Os cenários delineados neste artigo não são nenhum castelo no ar. São realidades actuais. É verdade que as empresas já estão a fazer bom uso de tecnologias de máquinas virtuais como, por exemplo, as oferecidas pelo VMware e Xen. Muitas organizações implementaram o Solaris Containers para melhorar a utilização.

E várias empresas líderes — como, por exemplo, alguns gigantes automóveis e instituições financeiras de classe mundial — estão a avançar para ambientes completamente virtualizados, incluindo sistemas operativos virtualizados, aplicações virtualizadas, infra-estruturas de ambiente de trabalho partilhadas, e grelhas para gerir volumes com e sem manutenção de estado.

A tendência é inegável, e é apenas uma questão de tempo até instituições de todos os tamanhos começarem a pensar em tratar as suas infra-estruturas de hardware subjacente como um recurso partilhado para todas as aplicações. Faz simplesmente mais sentido e dinheiro do que ignorar.

Bill Vass
CIO
Sun Microsystems, Inc.
cio@sun.com