Dispersão definida por software

Não se iluda, a abstração é algo bom. E a abstração com APIs avançadas é excelente. A abstração do software dá suporte à meta de toda mecanização de reduzir o trabalho humano e estimular a criatividade dos engenheiros. Mas esse mesmo recurso sempre traz consigo um aspecto negativo raramente aparente nos primeiros estágios da administração: a dispersão.

A virtualização eliminou em grande medida as barreiras à geração descontrolada de novos servidores e agora devemos desbastar periodicamente nossos clusters, a menos que queiramos enfrentar alertas de recursos não provisionáveis. Flash e armazenamento híbrido são excelentes ativos em nossa eterna busca por mais IOPS, mas um design de pool indisciplinado não contribui para a eficácia do data center. E por que esperaríamos que sistemas como redes definidas por software (SDN), virtualização de funções de rede (NFV), plataforma como serviço (PaaS) no local, sistemas hiperconvergentes etc. tivessem algum tipo de imunidade? Eles não têm, e dar conta da dispersão definida por software tornou-se mais uma das nossas tarefas.

A era das infinitas redes 

Talvez você tenha monitorado os caminhos do tráfego pelas redes de um provedor de SaaS e notado que alterações na rota do tráfego acontecem a cada dia ou até a cada hora. E isso faz sentido. Essas operadoras têm recursos de desenvolvimento consideráveis e há muito tempo desenvolveram abordagens proprietárias ao SDN. Seus serviços são distribuídos geograficamente entre diferentes fusos horários e se adaptam dinamicamente à demanda usando uma combinação de abstração e atuação por software. Isso permite que elas façam alterações em configurações mais rapidamente e com maior precisão do que qualquer equipe humana poderia.

Mas agora com o SDN e o armazenamento definido por software (SDS), entre outros elementos em seu data center, o roteamento, as políticas de segurança, a otimização da entrega de aplicativos e a arquitetura de armazenamento podem ser igualmente dinâmicos. No passado, você mantinha sua rede racionalizada em função de alguns vínculos avançados que geralmente não apresentavam problemas. Se possível, você pode seguir o exemplo das grandes operadoras e gerenciar as redes intricadas de diversas bases com apenas um clique.

Só tem uma pegadinha. Como isso é algo fácil, é provável que os recursos acabem órfãos, duplicados, excessivamente provisionados ou simplesmente perdidos. Caso você tenha monitorado NetFlow, logs de fluxos VPC do AWS ou perfilagem de agentes OMS do Microsoft Azure no local, talvez já tenha notado uma pequena porcentagem do tráfego “vazando” além das rotas esperadas. No caso de redes configuradas manualmente, com frequência isso é rastreado até vínculos de internet/VPN locais de filiais, rotas de failover ativas quando deveriam ficar em espera, configurações indevidas de BGP CDIR ou políticas de firewall aleatórias.

Se o número de vínculos for relativamente estático e pequeno o suficiente para manter uma imagem mental completa, a correção poderá ser simples. Mas se sua estrutura de SDN está funcionando como deve, o VMware vRealize está invadindo os domínios do NSX ou o SCVMM está embaralhando os contratos de ACI. Os controladores modificam o acesso à rede, bem como permissões, endereços e rotas regularmente sem a sua supervisão. O que também significa que, em sua maior parte, as alterações estão acontecendo fora do alcance da visão.

O SDS costuma estar ainda mais sujeito à dispersão. Idealmente, políticas bem ajustadas remanejam cargas de trabalho de armazenamento para obter máximo desempenho ao mesmo tempo que minimizam a utilização de recursos. Controladores híbridos otimizam arquivos individuais de volumes, atribuindo-os a diferentes mídias físicas com base na análise de uso. Mas, diferentemente de uma interrupção, um pecado ocasionalmente perdoável das redes, uma falha de armazenamento (perda de dados) é algo grave. O resultado é uma tendência a criar políticas conservadoras que, quando em dúvida, optam por deixar os arquivos onde estão para serem limpos posteriormente. A dispersão do armazenamento é um subproduto mais seguro quando se deixa que as políticas sejam executadas de forma autônoma.

Dispersão como serviço 

A dispersão da infraestrutura definida por software piora quando é composta. Na verdade, os orquestradores com controle de redes, armazenamento e outros recursos no local são o menor dos problemas. Um script de controlador de nível superior que, por sua vez, invoca APIs em sistemas de virtualização herdados pode gerar VMs, pools e vMACs sem se preocupar com o consumo de recursos. Pelo menos, os engenheiros no local ainda mantêm o total controle administrativo, ainda sendo possível monitorar manualmente a dispersão com as ferramentas existentes, embora isso seja uma tarefa tediosa.

A TI híbrida e a nuvem, por outro lado, costumam elevar a dispersão a um novo patamar. Qualquer gerente de TI que já tenha sido surpreendido por uma fatura de serviços que poderia potencialmente limitar sua carreira pode prestar testemunho do lado negro da dispersão definida por software. A criação de relatórios ou até mesmo a descoberta para determinar como eliminar instâncias ociosas ou órfãs pode ser uma tarefa difícil. “O processo analítico mensal da equipe de finanças é executado em i-5of78b0zg9vps9fro? Ou seria em i-09eomj1mnex8ex6yi? Ah, espere. Esse é do RH. Finanças está em i-299rjpen9ruwahzuo. Eu acho.”

O problema é quando os administradores se precipitam para aproveitar os incríveis recursos da infraestrutura definida por software, sem ter experiência com rastreamento distribuído/delegado de transações e registro em log de ações de configurações, entre outras habilidades. Se uma organização adota o DevOps com DEV maiúsculo, isso já traz algum alívio. Ferramentas de integração/compilação/entrega contínuas facilitam a garantia da rastreabilidade pelas camadas de abstração, mas o simples uso do Chef ou do Puppet não basta.

O que você pode fazer

• Documentar – Sim, a tarefa tão temida. Primeiro, admita que você não gosta de documentar, reconheça que ninguém gosta e, então, documente ainda assim. Os sistemas que gerenciam pontos de controle individuais realizam um excelente trabalho de organização dos elementos em seu campo de ação. No entanto, são péssimos para a visualização dos relacionamentos de ponta a ponta que passam por várias camadas do sistema. Passe algum tempo no Visio, faça diagramas de sua arquitetura integrada de sistemas SDx e, em seguida, imprima-os em pôsteres. As conversas sobre solução de problemas serão mais eficientes e a gerência sentirá que você tem tudo sob controle.
• Relatórios, não apenas alertas – O gerenciamento responsivo da TI demanda a definição de alertas inteligentes que acelerem a recuperação. O gerenciamento proativo da TI depende de relatórios úteis que mantém você à frente dos problemas.  Leia os manuais de seus sistemas de monitoramento e gerenciamento e crie relatórios que identifiquem a exaustão da capacidade, destaquem áreas operacionais sujeitas a erros etc. Se puder incluir relatórios de custos detalhados regulares, especialmente para TI híbrida e nuvem, melhor ainda.
• Aplicar o DevOps a tudo – Se você não puder afirmar com algum grau de confiança que poderia, neste exato momento, recriar 75% de seus sistemas gerenciados por SDN de maneira programática, pare de ler agora mesmo e descubra como chegar lá. Confira os artefatos de configuração no controle de origem e verifique se todos sabem como gerenciá-los. LeiaThe Phoenix Project. Pelo menos experimente um pouco de Agile. A dificuldade é apenas no começo e você não precisa adotá-lo integralmente. Imagine quantas noites e finais de semana você poderia recuperar se fizesse a maior parte de suas alterações à produção, ou talvez até todas elas, durante o horário de expediente. Isso é realmente possível! E você ainda pode contar com uma estrutura de alterações mais precisa e resistente à dispersão.

Déjà-vu, tudo outra vez

Embora seja importuno quando a dispersão surge em outra área da TI, é possível mantê-la sob controle. Na verdade, podemos ajustar a infraestrutura definida por software utilizando quase a mesma abordagem usada para dispersão de aplicativos ou de virtualização, além de algumas novas ferramentas. Além disso, esse é um problema transicional, já que a TI sai da linha de comando pelo SDx de primeira geração para a infraestrutura PaaS. O PaaS inclui inteligência e uma forte integração que gerencia recursos com ferramentas avançadas a fim de minimizar a dispersão. Logicamente, talvez isso não ajude muito no caso da dispersão de contêineres e tecnologias sem servidores, mas esses são outros quinhentos.