Ovos Virtuais e Cestas

Ao conversar com profissionais de TI de pequenas empresas, um dos principais fatores de hesitação em torno da implantação da virtualização surge daquilo que é descrito como “não coloque todos os ovos na mesma cesta”.

Consigo entender de onde vem essa preocupação. A virtualização permite que muitos sistemas operacionais convidados estejam contidos em um único sistema físico que, no caso de uma falha de hardware, faz com que todos os sistemas convidados nele hospedados falhem juntos, todos de uma vez. Isso parece ruim, mas talvez não seja tão ruim quanto presumiríamos à primeira vista.

A ideia do ditado dos ovos e das cestas é que não devemos colocar todos os nossos recursos em risco ao mesmo tempo. Isso geralmente é aplicado a investimentos, incentivando os investidores a diversificar e a investir em muitas empresas e tipos de títulos diferentes, como obrigações, ações, fundos e commodities. No caso dos ovos (ou do dinheiro), estamos falando de uma commodity intercambiável. Um ovo é tão bom quanto outro. Um conjunto de ovos é naturalmente redundante.

Se tivermos uma dúzia de ovos e quebrarmos seis, ainda podemos fazer uma omelete, talvez menor, mas ainda podemos comer. Comer uma omelete menor provavelmente será quase tão satisfatório quanto uma maior – de qualquer forma, não vamos passar fome. Colocar nossos ovos, já redundantes, em várias cestas nos permite distribuir o risco. Sim, carregar duas cestas significa que temos menos tempo para prestar atenção a cada uma delas, o que aumenta o risco de perder alguns dos ovos, mas reduz a probabilidade de perder todos os ovos. No caso dos ovos, uma proposta sábia, de fato. Da mesma forma, uma maneira inteligente de se preparar para a aposentadoria.

Essa teoria, por ser repetida como um ditado sem uma análise cuidadosa ou uma compreensão adequada, acaba sendo aplicada a áreas não relacionadas, como a virtualização de servidores. Os servidores, no entanto, não são como ovos. Os servidores, especialmente em empresas menores, raramente são commodities intercambiáveis em que ter seis funcionando, em vez dos doze habituais, seja suficiente. Normalmente, cada servidor desempenha um papel único e todos são relativamente críticos para o funcionamento do negócio. Se um servidor não for crítico, é improvável que consiga justificar o custo de sua aquisição e manutenção em primeiro lugar e, portanto, provavelmente não existiria. Quando os servidores são intercambiáveis, como em um grande web farm sem estado ou cluster de computação, eles são configurados dessa forma como um meio de expandir a capacidade para além dos limites de uma única caixa física e, portanto, ficam fora do escopo desta discussão.

Os serviços de TI em uma empresa geralmente são, ao menos até certo ponto, uma “dependência em cadeia”. Ou seja, eles são interdependentes e a perda de um único serviço pode afetar outros serviços, seja porque são tecnicamente interdependentes (como uma aplicação de linha de negócio que depende de um banco de dados) ou porque são interdependentes no fluxo de trabalho (como um funcionário de escritório que precisa que o servidor de arquivos esteja funcionando para disponibilizar um arquivo que ele precisa editar com informações de um e-mail, enquanto discute as alterações por telefone ou mensagem instantânea). Nesses casos, a perda de um único serviço fundamental, como e-mail, autenticação de rede ou serviços de arquivo, pode criar uma perda desproporcional da capacidade de trabalho. Se houver dez serviços fundamentais e um deles cair, a produtividade da empresa, do ponto de vista dos serviços de TI, provavelmente cai muito mais do que dez por cento, possivelmente chegando perto de cem por cento em casos extremos. Isso nem sempre é verdade; em alguns casos específicos, os trabalhadores conseguem “contornar” um serviço perdido de forma eficaz, mas isso é muito incomum. Mesmo que as pessoas consigam continuar trabalhando, é provável que sejam bem menos produtivas do que o habitual.

Ao lidar com servidores físicos, cada servidor representa seu próprio ponto de falha. Então, se tivermos dez servidores, teremos dez vezes mais probabilidade de interrupção do que se tivéssemos apenas um desses mesmos servidores. Cada servidor que adicionamos traz consigo seu próprio risco. Se cada falha tiver um fator de interrupção de 2,5 – ou seja, impactando financeiramente o negócio em vinte e cinco por cento da receita durante, digamos, um dia, então nosso impacto médio total ao longo de uma década equivale a duas interrupções e meia totais do site. Uso aqui o conceito de fatores e médias para facilitar; determinar a duração de uma interrupção média ou o impacto de uma interrupção média não é necessário, pois só precisamos determinar o impacto relativo neste caso para comparar os cenários. É apenas uma forma de comparar o impacto financeiro cumulativo das interrupções de um tipo de evento em relação a outro, sem precisar de números específicos – isso não ajuda você a determinar qual deveria ser seu investimento, apenas a confiabilidade relativa.

Com a virtualização, temos a óbvia capacidade de consolidar. Neste exemplo, vamos supor que possamos reduzir todos esses dez servidores existentes a um único servidor. Quando fazemos isso, muitas vezes desencadeamos a reação de “todos os ovos na mesma cesta”. Mas, se fizermos uma análise de risco, veremos que isso geralmente é apenas medo e incerteza, e não um risco matematicamente fundamentado. Se assumirmos os mesmos riscos do exemplo acima, nosso único servidor, em média, sofrerá apenas uma única interrupção total do site, uma vez por década.

Compare isso com o primeiro exemplo, que causou um dano equivalente a duas interrupções e meia totais do site – o risco da solução virtualizada e consolidada é de apenas quarenta por cento do risco da solução tradicional.

Agora, tenha em mente que isso se baseia na suposição de que perder alguns serviços significa uma perda financeira maior do que o valor estrito do serviço que foi perdido, o que quase sempre é o caso. Mesmo que o serviço perdido não represente mais do que a perda de um serviço individual, estamos apenas no ponto de equilíbrio e não precisamos nos preocupar. Em casos raros, o impacto de perder um único sistema pode ser menor do que sua “fatia do bolo”, normalmente porque as pessoas são flexíveis e conseguem contornar o sistema que falhou – como quando as mensagens instantâneas falham e as pessoas simplesmente passam a usar o e-mail até que as mensagens instantâneas sejam restauradas, mas esses casos são raros e normalmente se restringem a alguns poucos sistemas entre muitos, sendo que a maioria dos sistemas, digamos ERP, CRM e e-mail, têm impactos desproporcionalmente grandes no caso de uma interrupção.

Então, o que vemos aqui é que, em circunstâncias normais, migrar dez serviços de dez servidores para dez serviços em um único servidor geralmente reduzirá nosso risco, em vez de aumentá-lo – em contraste direto com a teoria dos “ovos na cesta”. E isso é puramente do ponto de vista da falha de hardware. A consolidação oferece, no entanto, vários outros importantes fatores de confiabilidade que podem ter um impacto significativo em nosso estudo de caso.

Com a consolidação, reduzimos a quantidade de hardware que precisa ser monitorada e gerenciada pelo departamento de TI. Menos servidores significa que mais tempo e atenção podem ser dedicados aos que permanecem. Mais atenção significa uma melhor chance de detectar problemas precocemente e mais oportunidade de manter peças à disposição. Melhor monitoramento e manutenção levam a uma melhor confiabilidade.

Possivelmente o fator mais importante, no entanto, da consolidação é que há uma economia de custos significativa e isso, se abordado corretamente, pode oferecer oportunidades para uma confiabilidade aprimorada. Com a redução drástica do custo total dos servidores, pode ser tentador continuar mantendo os orçamentos apertados e tentar aproveitar puramente a economia de custos de forma direta. Compreensível e, para algumas empresas, essa pode ser a abordagem correta. Mas não é a abordagem que eu recomendaria ao lutar contra a noção dos ovos e das cestas.

Em vez disso, ao aplicar uma abordagem mais moderada, mantendo uma economia de custos significativa, mas ainda gastando mais, relativamente falando, em um único servidor, você pode adquirir um servidor de gama mais alta (leia-se: mais confiável), usar peças melhores, ter peças sobressalentes no local, etc. A economia de custos da virtualização muitas vezes pode ser convertida diretamente em maior confiabilidade, deslocando ainda mais a equação a favor da abordagem de servidor único.

Como afirmei em outro artigo, uma casa de tijolos tem mais probabilidade de sobreviver a uma tempestade de vento do que uma ou duas casas de palha. Ter mais de algo não necessariamente o torna a escolha mais confiável.

Esses benefícios vêm puramente do aspecto da consolidação da virtualização, e não da virtualização em si. A virtualização oferece recursos adicionais de mitigação de risco de forma independente também. A criação de imagens do sistema e restaurações rápidas, bem como restaurações para hardware diferente, são grandes vantagens de praticamente qualquer plataforma de virtualização. Isso pode desempenhar um papel importante em uma estratégia de recuperação de desastres.

Claro, todos esses conceitos servem puramente para demonstrar que a virtualização e a consolidação em uma única caixa podem superar a abordagem legada de “uma aplicação por servidor” e ainda economizar dinheiro – mostrando que o exemplo dos ovos e das cestas é enganoso e não se aplica neste cenário. Deveria haver pouca apreensão em migrar de um ambiente tradicional diretamente para um ambiente virtualizado com base nesses fatores.

Vale observar que a virtualização pode, então, estender a confiabilidade do hardware comum tradicional, oferecendo recursos de failover semelhantes aos de mainframe, que vão além do que as plataformas não virtualizadas conseguem proporcionar. Isso coloca o hardware comum mais firmemente em linha com as plataformas RISC maiores e mais caras. Esses recursos podem trazer um nível extremo de proteção, mas muitas vezes vão além do que é apropriado para departamentos de TI que estão inicialmente migrando de um ambiente de servidores com hardware legado, sem failover. A alta disponibilidade é um ótimo recurso, mas costuma ser dispendiosa e, muito frequentemente, desnecessária, especialmente à medida que as empresas migram, como vimos, de ambientes relativamente pouco confiáveis no passado para ambientes mais confiáveis hoje. Dado que já aumentamos a confiabilidade para além do que era considerado necessário no passado, há uma boa chance de que um salto extremo de confiabilidade não seja necessário agora, mas, devido à grande queda no custo da alta disponibilidade, é bastante possível que ela se justifique em termos de custo onde antes isso não acontecia.

Na mesma linha, a virtualização é frequentemente temida por ser vista como uma tecnologia nova e não comprovada. Isso certamente não é verdade, mas existe essa impressão no espaço das pequenas empresas e dos servidores comuns. Na realidade, porém, a virtualização foi introduzida pela primeira vez pela IBM na década de 1960 e, desde então, tem sido um pilar dos mainframes e servidores RISC de gama alta – aqueles sistemas que exigem a melhor confiabilidade. No espaço dos servidores comuns, a virtualização foi um desafio técnico maior e levou muito tempo até que pudesse ser implementada de forma suficientemente eficiente para torná-la eficaz para uso no mundo real. Mas, mesmo no espaço dos servidores comuns, a virtualização está disponível desde o final da década de 1990 e, portanto, tem aproximadamente quinze anos hoje, o que está muito além do ponto de ser uma tecnologia nascente – no mundo da TI, ela é positivamente venerável. A virtualização em plataformas comuns é um campo maduro, com vários fornecedores e produtos altamente respeitados e extremamente avançados. O uso da virtualização como padrão para todas ou quase todas as aplicações de servidor é um “padrão corporativo” há muito estabelecido e aceito, e que agora pode ser facilmente adotado por empresas de todo e qualquer tamanho.

A virtualização, talvez de forma contraintuitiva, é na verdade um componente muito crítico de uma estratégia de confiabilidade. Em vez de adicionar risco, a virtualização pode quase ser abordada como uma plataforma de mitigação de risco – um conjunto de ferramentas para aumentar a confiabilidade de suas plataformas de computação por meio de diversos caminhos.