Artigo

Os benefícios da modularidade na arquitetura da nuvem privada

Explore os benefícios de custo e desempenho da modularidade em uma arquitetura de nuvem privada.

Índice

A modularidade beneficia a arquitetura de nuvem privada A modularidade beneficia a arquitetura de nuvem privada A modularidade beneficia a arquitetura de nuvem privada

Montar um data center de nuvem privada é como criar um carro esportivo do zero. Você precisa escolher o motor, as peças e os equipamentos certos para atender às demandas de performance da estrada e do motorista. Graças a inovações de hardware e software, os arquitetos de TI podem compor seus data centers para desempenhar mais como uma Lamborghini e menos como uma lata-velha.

As nuvens privadas no local exigem supervisão, gerenciamento e manutenção constantes. Os custos operacionais, como a substituição de discos ou sobreprovisionamento, podem subir rapidamente com o tempo. Isso aumenta o custo total de propriedade (TCO) dos data centers e consome parte do rendimento da empresa, principalmente com o crescimento exponencial da captura, criação e utilização de dados todos os anos.

É exatamente por causa dessas questões que está ocorrendo o que a Seagate chama de megatendência de modularidade. O data center modular moderno possibilita que cada servidor de nuvem privada seja formado por componentes que são desagregados, mas se interconectam com tipos otimizados de fabric e largura de banda. A modularidade fornece uma maneira flexível de gerenciar e acessar dados de vários aplicativos e fluxos de trabalho de dados.

Os arquitetos de TI devem decidir se usarão uma solução de nuvem privada ou uma nuvem pública/privada hospedada por um terceiro. As nuvens públicas compartilham serviços computacionais entre diferentes clientes e são hospedadas em um data center externo. Os provedores de nuvem também oferecem nuvens privadas hospedadas, que também são hospedadas externamente, mas os serviços não são compartilhados.

As nuvens privadas no local são gerenciadas e mantidas por um data center da própria empresa e não compartilham serviços com outras organizações. Os maiores benefícios de usar uma nuvem privada no local incluem uma maior sensação de segurança, flexibilidade e desempenho mais alto. Os usuários podem personalizar seus recursos e serviços para que o hardware coincida especificamente com os requisitos de software, em vez de usar uma abordagem generalizada. Os usuários também têm controle total sobre a segurança, escalabilidade e configurabilidade de seus servidores.

Conforme as demandas dos aplicativos aumentam e diminuem, os componentes e servidores se comunicam entre si para desviar a carga de trabalho. Agora, os arquitetos de TI podem criar data centers com uma variedade maior de hardware e componentes de diversos fabricantes. Na prática, eles estão desmantelando, ou desagregando, a infraestrutura do data center tradicional. Após a desmontagem do chassi, o data center pode ser reconstruído para garantir um uso mais eficiente dos recursos instalados. Os arquitetos de TI podem evitar a compra de hardware desnecessário por custo extra e os componentes podem ser substituídos facilmente sem tempo de inatividade.

A desagregação e modularidade na nuvem privada evoluiu da arquitetura de rede tradicional à infraestrutura dinâmica atual que permite o funcionamento de sistemas poderosos e exigentes. A desagregação modular tem vários benefícios importantes, inclusive a latência reduzida e maior segurança e controle sobre os dados.

Limitações do data center tradicional

A arquitetura de TI tradicional está atingindo seus limites devido ao crescimento exponencial de dados e o aumento da complexidade dos aplicativos de software. As CPUs (unidades centrais de processamento), DRAM (memória dinâmica de acesso aleatório), SCM (unidades de memória de classe de armazenamento), GPU (unidades de processamento gráfico), SSD (unidades de estado sólido) e HDDs (unidades de disco rígido) estão entre os componentes cruciais que formam um data center. Esses componentes costumam ser acomodados juntos em uma caixa ou servidor e são a base sobre a qual o data center é construído. Nessa arquitetura de nuvem corporativa tradicional, cada componente, como um HDD, é diretamente conectado ao resto do servidor.

Originalmente, os data centers operavam segundo um paradigma de “um aplicativo por caixa". Quando os aplicativos superaram os recursos de armazenamento e processamento de dados que os servidores únicos podiam oferecer, os arquitetos de TI começaram a agrupar vários servidores em clusters, que podiam formar um pool de recursos. Soluções proprietárias, como da IBM, EMC, NetApp e a própria equipe Dot Hill da Seagate, lideraram a incursão inicial do setor aos recursos de servidor agrupados em pool.

Os data centers puderam, então, expandir verticalmente e satisfazer as necessidades dos aplicativos de software conforme sua complexidade aumentava desta maneira: se um aplicativo precisava de mais armazenamento, largura de banda ou poder de CPU, servidores adicionais (ou nós) podiam ser adicionados ao cluster. O modelo em cluster de recursos agrupados forma a base daquilo que agora conhecemos como infraestrutura de nuvem corporativa convergida e hiperconvergida, usando aplicativos de hypervisor corporativos, como VMware e outros.

Os clusters de nó serviram ao seu propósito nos primórdios da nuvem, mas são propensos ao sobreprovisionamento. Isso ocorre quando os arquitetos de TI compram mais servidores, que conterão mais recursos de um tipo ou outro do que é necessário — recursos esses que são inutilizados. Embora a abordagem de cluster tenha seus benefícios, como garantir armazenamento e poder de processamento suficientes, os recursos não usados nos servidores são ineficientes. No entanto, os arquitetos de TI tiveram que usar o sobreprovisionamento para alcançar a escala, visto que não havia uma forma para os data centers expandirem dinamicamente apenas recursos ou cargas de trabalho específicos de acordo com as demandas dos aplicativos de software. Custos excessivos são um subproduto natural do sobreprovisionamento.

Os arquitetos de TI também eram limitados em termos de quais componentes de hardware podiam usar para compor um servidor. O hardware para cada servidor ou cluster tinha que ser comprado de um mesmo fabricante para haver compatibilidade. E não havia APIs (interfaces de programação de aplicativo) abertas para ajudar os hardwares de diferentes fabricantes a se comunicarem entre si e coordenarem. Se os arquitetos quisessem substituir uma CPU por outra mais rápida, uma de outro fabricante, por exemplo, geralmente não podiam devido a incompatibilidade. Hardwares de diferentes fabricantes não podiam se comunicar ou coordenar uns com os outros.

Mas as incompatibilidades de hardware não são o único problema da infraestrutura de dados tradicional. Há também a questão das quantidades enormes de dados que precisam que sejam coletados, armazenados e analisados. A explosão do big data não só está ultrapassando os limites de armazenamento dos clusters de nuvem privada tradicional, como está criando um gargalo de processamento de dados. Geralmente, cada CPU está ocupada demais processando dados locais para compartilhar recursos com outros aplicativos, o que resulta em ineficiências gerais no escalonamento de recursos no data center.

Por exemplo, aplicativos complexos de inteligência artificial (IA) dependem da capacidade de processar grandes quantidades de dados em um curto período de tempo. Quando um aplicativo de IA utiliza um data center em cluster, costumam ocorrer gargalos na coleta e no processamento de dados. Se o aplicativo precisar de mais poder de processamento, não existe uma maneira de desviar carga de trabalho adicional para outros clusters. A latência, ou atrasos na transmissão de dados entre dispositivos, é outra consequência negativa.

Por exemplo, pode haver dois clusters de servidor no mesmo data center, um sobrecarregado e o outro subutilizado. O aplicativo que está usando o cluster sobrecarregado pode ficar lento ou apresentar problemas de desempenho — um problema que poderia ser resolvido facilmente com a integração do cluster subutilizado e sobrecarregado. Entretanto, o pool de recursos que o aplicativo pode aproveitar é estritamente limitado ao único cluster dedicado a esse aplicativo. Isso ilustra perfeitamente por que os arquitetos de TI têm buscado maneiras mais eficientes de compor um data center.

A era proprietária está chegando ao fim, se é que já não chegou. Aplicativos de software sofisticados exigem mais poder de processamento e armazenamento do que o data center em cluster tradicional pode oferecer. E os arquitetos de TI estão limitados ao hardware que podem usar devido à falta de APIs abertas que permitem comunicação entre dispositivos. Para que os arquitetos de TI avancem, eles precisam de uma compreensão profunda de como os aplicativos modernos afetam a arquitetura de nuvem privada e como a modularidade pode ajudar a superar os desafios da infraestrutura de TI tradicional.

Como os aplicativos afetam o data center de nuvem privada

Uma das maiores forças motrizes da megatendência de modularidade são as demandas dos aplicativos de software. Softwares, como análise de negócios e IA, exigem um conjunto cada vez mais complexo de requisitos de hardware específicos às necessidades do aplicativo. Isso cria uma concorrência acirrada por pools de recursos de armazenamento e processamento.

Como mencionado, os data centers tradicionais agora alcançaram um ponto de ruptura, no qual o poder de processamento necessário por vários aplicativos frequentemente excede os limites de um modelo em cluster. Os requisitos de aplicativos também aumentam constantemente ao longo do tempo e mudanças podem ocorrer rapidamente. A nova versão de um aplicativo empresarial, por exemplo, pode exigir o dobro do poder de processamento e armazenamento do que a anterior. Se exceder os limites de seu cluster dedicado, mais hardware terá que ser comprado. Avanços em software exigem mais do que um data center em cluster tradicional pode oferecer.

A modularidade garante aos aplicativos acesso a pools de recursos fora de seu próprio cluster dedicado, desbloqueando o poder de processamento (ou outros recursos) disponível dentro de servidores sobreprovisionados. Cada CPU, GPU ou nó de armazenamento pode ser expandido verticalmente de modo independente de acordo com as necessidades de preço de cada aplicativo.

Demandas adicionais de processamento também criam gargalos dentro do fabric do data center tradicional. O fabric do data center é o que conecta diversos nós e clusters. O ideal seria que um fabric modular que atende às necessidades dos aplicativos de software modernos criasse um pool de capacidade de fabric flexível. Esse fabric deve ser configurável instantaneamente para provisionar a infraestrutura e os recursos dinamicamente à medida que as necessidades de processamento de um aplicativo aumentarem. O objetivo é fornecer aos aplicativos avançados não só um processamento mais rápido, mas um processamento em tempo real que facilite para que esses aplicativos sejam executados em velocidades otimizadas.

A modularidade e desagregação são essenciais para atender às demandas dos aplicativos de software avançados. As arquiteturas em cluster tradicionais simplesmente não dão conta do recado e as informações não podem percorrer os fabrics de ethernet rápido o suficiente para permitir que aplicativos avançados, como IA, funcionem adequadamente. Ao desagregar componentes dentro de uma caixa de servidor e dar a eles uma forma de se comunicar com protocolos de API, os data centers podem entregar aplicativos complexos de uma maneira econômica.

Os benefícios da desagregação da nuvem privada

Desagregar um data center de nuvem privada significa eliminar completamente o modelo de caixa de servidor tradicional. Todos os componentes de recursos, como CPUs, GPUs, todas as camadas de memória, SSDs e armazenamento HDD, podem ser desagregados e recompostos à la carte dentro de seus fabrics apropriados. Esses recursos podem, então, ser utilizados com base no que um aplicativo específico precisa, não com base em como os componentes são configurados dentro de um servidor físico específico. Qualquer coisa que possa ser acessada em um fabric de rede pode ser desagregada e depois recomposta.

Por exemplo, o pool de recursos de armazenamento que um aplicativo usa pode consistir em HDDs em 10 racks de servidor diferentes em vários locais em um data center. Se o aplicativo precisar de mais armazenamento do que usa no momento, um HDD pode simplesmente se comunicar com outro HDD que tem espaço e transmitir dados diretamente. A carga de trabalho de processamento também pode ser desviada dinamicamente quando as demandas do aplicativo aumentarem. Por outro lado, quando as demandas do aplicativo diminuírem, o armazenamento e processamento podem ser realocados da maneira mais eficiente possível em termos de consumo de energia para reduzir, ou até eliminar, o sobreprovisionamento caro.

É uma mudança drástica dos JBODs, ou just a bunch of disks, de ficar confinado a um único rack de servidor. Os JBODs evoluíram e se tornaram pools que os aplicativos podem chamar a qualquer hora, deixando a alocação de recursos do data center mais inteligente. Os arquitetos começaram então a se valer de armazenamentos externos padronizados que podiam se comunicar entre si.

A desagregação também introduz monitoramento de interface padronizado e permite que os arquitetos de TI gerenciem um data center modular inteiro. A seleção de hardwares baseados em requisitos, sejam SSDs, HDDs, CPUs ou componentes de fabric, é apenas uma parte da desagregação e da mudança para a criação de um data center modular. Os arquitetos ainda precisam dos protocolos corretos de API aberta, como Redfish ou Swordfish, para integração total e uma interface de usuário única para gerenciar o data center. Uma API aberta permite que hardware e software que falam línguas diferentes se comuniquem e trabalhem juntos.

Deixar o aplicativo definir como o data center é composto, em vez de o contrário, resulta em SDN (rede definida por software) e SDS (armazenamento definido por software). O próximo avanço de SDN e SDS é o data center hipercomposto. Isso poderia colocar a arquitetura de nuvem privada no mesmo nível de alguns dos hyperscalers como Amazon Web Services (AWS) e Microsoft Azure. Hyperscalers são grandes provedores de data center que podem aumentar o processamento e armazenamento em escala massiva. Fabrics de ethernet (a espinha dorsal de rede de um data center) podem até mesmo ser personalizados para executar com dispositivos HDD e SSD de baixa latência. Essa personalização reduz atrasos no tráfego ou processamento de dados, visto que os aplicativos podem usar os pools de recursos desagregados que estão operando nos fabrics de baixa latência.

Protocolos de API aberta, como Redfish e Swordfish, são cruciais para todos os componentes desagregados que estão funcionando em harmonia. A Seagate tem sua própria API REST herdada que mantém para sua classe específica de produtos de data center que promovem a operabilidade entre dispositivos. No passado, a troca de dispositivos podia levar semanas para instalar e integrar. Os protocolos API permitem que os arquitetos de data center assumam uma abordagem à-la-carte plug-and-play à obtenção de hardware. Novos dispositivos de fabricantes diferentes podem ser instalados e começar a funcionar em tempo recorde.

A desagregação de data center é o que torna a modularidade possível. Após os arquitetos escolherem os dispositivos de hardware para suas necessidades de aplicativo de software, podem construir, operar e otimizar o data center modular do futuro.

Eficiência do data center modular moderno para nuvem privada

A modularidade de data center não só conecta todos os componentes desagregados, como ajuda a aprimorar os KPIs (indicadores-chave de desempenho) relacionados à eficiência de custos e ao desempenho de data centers. Em data centers tradicionais, o sobreprovisionamento é um dos maiores escoadouros de dinheiro nos orçamentos. Quando data centers são sobreprovisionados, os servidores e recursos são pagos, mas não são usados. Em linhas gerais, os arquitetos de TI estão pagando por pools de recursos que são subutilizados, fazendo com que esses discos rígidos sejam subprovisionados.

Os recursos subprovisionados resultam naquilo que é chamado de pools órfãos, ou pools de recursos que não têm um lar devido à subutilização. Isso pode incluir CPU, GPU, FPGA (arranjo de portas programáveis em campo), DRAM memória dinâmica de acesso aleatório), SSD, HDD ou SCM (memória de classe de armazenamento). Esses blocos de construção são compostos dinamicamente para criar hardware específico para aplicativos por meio de APIs de software.

Antes da arquitetura modular de data center de código aberto, as nuvens privadas costumavam ser construídas usando hardware de um único fornecedor. Os data centers fisicamente conectados são mais caros de montar e, geralmente, as organizações ficam presas a uma arquitetura de um fornecedor específico que fica cara de manter ao longo do tempo.

A tendência de modularidade começou a ganhar terreno como parte das arquiteturas de nuvem pública. Produtos como AWS e Microsoft Azure são dois exemplos. Uma abordagem semelhante pode ser assumida em termos de implementações de nuvem privada, economizando recursos monetários ao evitar a dependência de fornecedores e compor data centers com dispositivos de vários fornecedores.

Com isso, os gerentes de TI podem alocar mais recursos orçamentários para obter uma capacidade de armazenamento maior que possibilite extrair insights e valor dos dados armazenados.

Agora, as organizações podem usar uma solução de armazenamento de terceiros, colocá-la em seu data center e integrá-la perfeitamente com uma API de código aberto. Se um arquiteto de TI quiser um SSD de um fabricante, mas seu data center for formado por componentes de um fabricante diferente, esse SSD pode ser inserido no data center sem muita dor de cabeça. As APIs garantem que todos os componentes funcionem em conjunto. Os gerentes de data center não precisam se preocupar com a forma como os componentes se comunicarão por telemetria, por exemplo, reduzindo o custo e o estresse associados às peças de fornecedores que não estão instaladas no data center no momento.

Outra grande vantagem da memória em pool ou compartilhada é a chance que os aplicativos agora têm de sobreviver a uma falha de nó sem uma disrupção de estado nas máquinas virtuais ou clusters de contêiner afetados por esse nó. A ideia é que outros nós agora podem copiar o último estado da memória da máquina virtual em seu próprio espaço de memória (no caso de arquiteturas de memória em pool) ou usar um processo de zero-cópia por redirecionamento de ponteiro no fabric de latência ultrabaixa e continuar de onde o nó com falha parou de maneira integrada (no caso de arquiteturas de memória compartilhada). Isso pode ser considerado um avanço significativo nos recursos de tolerância a falha integrada dos data centers para fornecer maior confiabilidade e disponibilidade.

Uma arquitetura modular também permite a coleta e o processamento mais rápidos de dados de várias origens e, no geral, um uso mais eficiente dos recursos instalados. Geralmente, a arquitetura de fonte de dados modular inclui sensores físicos, simulações de dados, informações geradas pelo usuário e comunicações por telemetria. Os gerentes de data center podem, então, ativar recursos em questão de minutos, compartilhando-os entre aplicativos imediatamente.

Uma visão única de todos os recursos

Orquestrar e gerenciar um data center de nuvem privada também é mais fácil com uma arquitetura modular usando um cliente de orquestração conteinerizado. Todos os hardwares podem ser desagregados, compostos e monitorados de uma única interface. Os gerentes de data center podem ter uma visão clara em tempo real de quais pools de recursos estão sendo usados e garantir que não haja sobreprovisionamento. Em muitos casos, o gerenciamento será realizado com um software padrão. Ele pode ser proprietário ou de código aberto.

A implementação de novos aplicativos de software em um ambiente conteinerizado de código aberto também é mais flexível, principalmente devido à flexibilidade com a qual recursos de armazenamento podem ser adquiridos e inseridos. Por exemplo, os arquitetos de data center não precisam mais sobreprovisionar camadas de armazenamento flash caro. Isso ocorre porque qualquer carga de trabalho de aplicativo pode ser desviada instantaneamente para um conjunto existente de recursos de SSD conforme necessário, não importa onde estiver fisicamente. Isso evita o sobreprovisionamento, bem como o espaço físico que pode ser usado para outros fins, como maior capacidade de armazenamento bruto.

Há uma necessidade maior de criar mais capacidade de armazenamento bruto devido ao crescimento e explosão de dados brutos. Além disso, as organizações estão se esforçando para obter ainda mais valor e insights úteis de mais desses dados para criar novas oportunidades que aprimoram os resultados finais. O importante é que os arquitetos de TI possam projetar infraestruturas que coletem, armazenem e transmitam volumes massivos de dados. Layouts de hardware de computação mais eficientes significam mais espaço disponível para o armazenamento em massa bruto necessário para o ambiente de big data atual.

A solução é um data center modular que conecte qualquer CPU e qualquer pool de armazenamento com outros dispositivos conforme necessário. Todos os outros dispositivos usam CSI, Redfish e Swordfish para se conectar à rede de gerenciamento, orquestrada pelos mecanismos de software. Todos os outros blocos de construção do data center podem ser compostos dinamicamente para se tornarem específicos ao aplicativo por meio de APIs de software.

Custo, desempenho, eficiência

A tendência de desagregação e modularidade nos data centers é gerada por custo, desempenho e eficiência. Já se foram os dias em que a CPU era o centro do universo que conhecemos, com todos os outros dispositivos entulhados na mesma caixa com ela. Agora, os arquitetos de nuvem privada podem escolher os dispositivos, hardwares e softwares mais apropriados com base no caso de uso e em necessidades específicas.

O data center em cluster conteinerizado tradicional abriu as portas para aplicativos mais complexos, mas os softwares atuais têm um desempenho tão alto que uma arquitetura mais dinâmica passou a ser uma necessidade. E, no futuro, GPUs, FPGAs e memória modulares serão habilitados por interfaces de latência ultrabaixa.

Modularidade significa que a carga de trabalho de processamento é distribuída em tempo real, compartilhando o peso com dispositivos subutilizados e eliminando pools de dados órfãos. O resultado é uma infraestrutura de nuvem privada totalmente orquestrada que ajuda os data centers a processar cargas de trabalho mais rápido e custa menos para operar. Com a desagregação e a modularidade, os arquitetos de TI podem atender às necessidades dos aplicativos de software mais exigentes. O data center modular é realmente mais do que a soma de suas partes.