Tirando o Melhor Proveito da Sua Pirâmide Invertida da Perdição

A arquitetura 3-2-1, ou Pirâmide Invertida da Perdição, tornou-se um pária da indústria de TI por muitas razões. Infelizmente, para muitas empresas, elas só tomam conhecimento dos perigos associados a este design depois que os componentes já chegaram e o dinheiro já saiu das contas.

Algumas empresas têm sorte e percebem este erro cedo o suficiente para conseguir devolver suas compras e recomeçar com uma fase adequada de design e decisão antes da aquisição de novo hardware e software. Esta, no entanto, é uma situação ideal e muito rara. Na melhor das hipóteses, normalmente podemos esperar taxas de reposição de estoque e, muito mais comumente, ou o equipamento não pode ser devolvido de forma alguma ou as taxas são tão elevadas a ponto de tornar a devolução inútil.

O que a maioria das empresas enfrenta é a necessidade de “tirar o melhor proveito” da situação daqui para frente. Uma das maiores preocupações é que as partes interessadas, sejam elas os responsáveis financeiros que acabaram de gastar muito dinheiro no novo hardware, sejam os responsáveis técnicos que agora ficam mal vistos por terem permitido a compra deste equipamento, sucumbam a uma reação emocional que as leve a ceder à falácia do custo irrecuperável. É vital que esta reação emocional e ilógica não seja autorizada a se instaurar, pois ela minará a tomada de decisões críticas.

É preciso compreender que o dinheiro gasto na pirâmide invertida da perdição já foi gasto e se foi. O fato de o dinheiro ter sido desperdiçado, ou de quanto foi desperdiçado, é irrelevante para a tomada de decisão neste momento. Se o sistema foi um presente ou se custou um bilhão de dólares não importa; esse dinheiro se foi e agora temos que nos virar com o que temos. Um possível “truque” aqui seria trazer um responsável por decisões financeiras, como um CFO, explicar que está prestes a ocorrer uma reação emocional a um dinheiro já gasto e discutir a falácia do custo irrecuperável antes de falar sobre o problema em si, de modo que as pessoas estejam conscientes e lógicas e que a pessoa treinada (esperamos) para lidar da melhor forma com este tipo de situação esteja presente e pronta para conter as emoções ligadas ao custo irrecuperável. O manejo cuidadoso de uma reação potencialmente movida pela emoção é importante. Este não é o momento de tentar encobrir os deslizes financeiros ou técnicos, que é justamente o que a reação emocional está criando. É necessário que todas as partes se comuniquem e permaneçam desapegadas e lógicas a fim de atender às necessidades. Algumas empresas lidam bem com isto, muitas não e acabam presas tentando avançar com decisões ruins que já foram tomadas, provavelmente na esperança de que nada de mau aconteça e de que ninguém se lembre ou perceba. Combata essa reação. Todos a têm; é a resposta emocional natural de “luta ou fuga” da amígdala.

Agora que estamos prontos para combater as reações emocionais ao problema, podemos começar a abordar a questão de “para onde vamos a partir daqui”. A boa notícia é que onde estamos é geralmente uma posição de ter “coisas demais”, em vez de “coisas de menos”. Portanto, temos a oportunidade de sermos um pouco criativos. Felizmente, geralmente há boas opções que podem nos permitir seguir em várias direções.

Algo muito importante a observar é que estamos analisando exclusivamente soluções que são mais confiáveis, e não menos confiáveis, do que a pretendida arquitetura de pirâmide invertida da perdição que estamos substituindo. Uma IPOD é um design muito frágil e perigoso, e poderíamos nos estender bastante demonstrando conceitos como análise de risco, pontos únicos de falha, as falácias da falsa redundância, olhar para a redundância em vez da confiabilidade, cadeias de dependência, etc., mas o que é absolutamente crítico que todas as partes compreendam é que um único servidor, funcionando com armazenamento local, é mais confiável do que toda a infraestrutura IPOD seria. Isto é tão importante que precisa ser dito novamente: se um único servidor é de “disponibilidade padrão”, a IPOD está abaixo disso. Mais arriscada. Se nesta fase alguém temer uma “falta de redundância” ou uma “falta de complexidade” nas soluções resultantes, temos que voltar a este ponto – nada do que vamos discutir é tão arriscado quanto o que já havia sido projetado e comprado. Se houver qualquer temor de risco daqui para frente, o temor deveria ter sido maior antes de melhorarmos a confiabilidade do design. Isto não pode ser exagerado. As IPODs vendem porque confundem facilmente aqueles não treinados em análise de risco e parecem confiáveis quando, na verdade, são tudo menos isso.

Compreendendo o exposto acima e usando uma técnica chamada “leitura reversa” da arquitetura IPOD aceita, percebemos que a empresa em questão aceitava não ter alta disponibilidade (ou mesmo disponibilidade padrão) no momento da compra da IPOD. Talvez acreditassem que estavam obtendo isso, mas a arquitetura não conseguia fornecê-la e, portanto, daqui para frente temos a opção de “nos virarmos” com nada mais do que um único servidor, funcionando em seu próprio armazenamento local. Isto é simples e fácil e representa uma melhoria em quase todos os aspectos do design IPOD pretendido. Custa menos para operar e manter, muitas vezes é mais rápido e é muito menos complexo, sendo, ao mesmo tempo, ligeiramente mais confiável.

Mas é provável que simplesmente reduzir para um único servidor e esperar encontrar usos para o restante do equipamento comprado “em outro lugar” não seja a nossa melhor opção. Em situações em que a IPOD havia sido destinada a ser usada apenas para uma única carga de trabalho ou conjunto de cargas de trabalho, e outras áreas do negócio também têm necessidade de equipamento, pode ser muito benéfico adotar a abordagem de “servidor único” para a carga de trabalho IPOD pretendida e utilizar o equipamento restante em outras partes do negócio.

A abordagem mais comum ao reaproveitar uma pilha IPOD é reconfigurar os dois (ou mais) nós de computação para que sejam nós de pilha completa, contendo seu próprio armazenamento. Esta etapa pode não exigir nenhuma compra, dependendo de qual armazenamento já foi adquirido, uma movimentação de discos entre os sistemas ou, frequentemente, a compra relativamente pequena de discos rígidos adicionais para este fim.

Esses nós podem então ser configurados em um de dois modelos de alta disponibilidade. No passado, uma escolha de design comum, por razões de custo, era usar um modelo de replicação assíncrona (frequentemente conhecido como a abordagem Veeam) que replica máquinas virtuais entre os nós e permite que as VMs sejam ligadas muito rapidamente, permitindo um tempo de inatividade, desde o momento da falha do nó de computação até a recuperação, de apenas alguns minutos.

Hoje, a tolerância a falhas totalmente síncrona está disponível de forma tão comum e gratuita que efetivamente substituiu o modelo assíncrono em quase todos os casos. Neste modelo, o armazenamento é replicado em tempo totalmente real entre os nós de computação, permitindo que o failover ocorra instantaneamente, em vez de com alguns minutos de atraso, e com zero perda de dados, em vez de uma pequena janela de perda de dados (por exemplo, um RPO de zero).

Neste ponto, parece ser comum que as pessoas reajam à replicação com um temor de perda de capacidade de armazenamento causada pela replicação. É claro que isto é verdade. É necessário que se compreenda que é justamente esta replicação, ausente do design IPOD original, que fornece a base sólida para a alta confiabilidade. Se esta replicação for ignorada, a alta disponibilidade torna-se um sonho inatingível, e nós de computação individuais usando armazenamento local em um modo “autônomo” são a opção potencial mais confiável. As soluções de alta disponibilidade dependem de replicação e redundância para construir a confiabilidade necessária para se qualificarem como de alta disponibilidade.

Isto resolve a questão do que fazer com nossos nós de computação, mas nos deixa com a questão do que podemos fazer com nosso dispositivo de armazenamento compartilhado externo, o ponto único de falha ou o “ápice” do design de pirâmide invertida. Para responder a esta pergunta, devemos começar examinando o que esse armazenamento poderia ser.

Existem três tipos comuns de dispositivos de armazenamento que seriam usados em um design de pirâmide invertida: DAS, SAN e NAS. Podemos agrupar DAS e SAN, pois ambos são dois aspectos distintos do armazenamento em blocos e podem ser usados, essencialmente, de forma intercambiável em nossa discussão – eles se diferenciam apenas pela existência de comutação, que pode ser adicionada ou removida conforme necessário em nossos designs. O NAS difere por ser armazenamento de arquivos, em vez de armazenamento em blocos.

Em ambos os casos, armazenamento em blocos (DAS ou SAN) ou de arquivos (NAS), um dos usos mais comuns para este dispositivo agora supérfluo é como destino de backup para nossa nova infraestrutura de virtualização. Em muitos casos, o dispositivo pode ser exagerado para esta tarefa, geralmente com mais desempenho e muito mais recursos do que o necessário para um simples destino de backup, mas um bom armazenamento de backup é importante para qualquer infraestrutura crítica de negócios, e pecar pelo excesso não é necessariamente algo ruim. As empresas frequentemente tentam economizar em suas infraestruturas de backup, e esta é uma oportunidade de investir pesadamente nela sem gastar dinheiro adicional.

Na mesma linha do armazenamento de backup, o dispositivo de armazenamento externo poderia ser reaproveitado como armazenamento de arquivamento ou outro “nível inferior” de armazenamento onde a alta disponibilidade não se justifica. Esta é uma abordagem menos comum, geralmente porque toda empresa precisa de um bom sistema de backup, mas apenas algumas têm como aproveitar um nível de armazenamento de arquivamento.

Além desses dois modelos de armazenamento comuns e universais, um caso de uso frequente para dispositivos de armazenamento externos, especialmente se o dispositivo for um NAS, é aproveitá-lo em sua função nativa como servidor de arquivos separado da infraestrutura de virtualização. Para muitas empresas, o serviço de arquivos não é tão crítico em termos de disponibilidade quanto a infraestrutura central de virtualização, e os backups são muito mais fáceis de manter e gerenciar. Ao transferir o serviço de arquivos para um dispositivo NAS já adquirido, isto pode reduzir os requisitos de serviço de arquivos da infraestrutura de virtualização, tanto por reduzir o número de VMs que precisam ser executadas ali quanto por mover o que normalmente é um dos maiores consumidores de armazenamento para um dispositivo separado, o que pode diminuir os requisitos de desempenho da infraestrutura de virtualização, bem como seus requisitos de capacidade. Ao fazer isto, potencialmente reduzimos o custo de obtenção dos discos rígidos adicionais necessários para o armazenamento local nos nós de computação, conforme afirmamos anteriormente, e por isso este pode ser um método muito popular para que muitas empresas atendam às necessidades de reaproveitamento.

Cada empresa é única e existem potencialmente muitos lugares onde o equipamento de armazenamento sobressalente poderia ser usado de forma eficaz, de laboratórios a arquivos e armazenamento em níveis. Usar um pouco de criatividade e pensar fora da caixa pode ser aproveitado para pegar o seu conjunto único de equipamento disponível e o conjunto único de necessidades e demandas do seu negócio e encontrar o melhor lugar para usar este equipamento, onde ele esteja desacoplado da infraestrutura central e crítica de virtualização, mas ainda possa agregar valor à organização. Ao evitar a pirâmide invertida da perdição, podemos obter o máximo valor do equipamento no qual já investimos, em vez de implementar uma nova dívida técnica que então temos que trabalhar para superar desnecessariamente.