Armazenamento de dados: quando capacidade deixa de ser a pergunta principal

Sua infraestrutura de dados acompanha a operação?

Por muito tempo, falar sobre armazenamento de dados significava responder a uma pergunta relativamente objetiva: quanto espaço a empresa precisa?

A pergunta continua relevante. Mas, diante da forma como as empresas operam hoje, ela já não é suficiente.

Aplicações se multiplicaram, workloads ficaram mais diversos, ambientes passaram a combinar infraestrutura local e nuvem, e os dados deixaram de estar concentrados em poucos sistemas. Eles circulam entre endpoints, aplicações, servidores, ambientes virtualizados e diferentes plataformas de armazenamento.

Nesse cenário, ampliar capacidade pode resolver uma necessidade pontual. Mas não necessariamente responde à questão mais importante:

Que arquitetura de dados a operação realmente precisa?

Essa mudança de perspectiva é importante para qualquer equipe de TI que esteja revisando sua infraestrutura. Porque armazenamento não é apenas o lugar onde os dados ficam. Ele faz parte da arquitetura que sustenta aplicações, workloads e processos que dependem desses dados para funcionar.

O dado não termina no endpoint.

Para quem trabalha diariamente com infraestrutura, é natural começar pelo que está mais próximo do usuário.

Um colaborador utiliza um notebook. Acessa uma aplicação. Produz um documento. Consulta um banco de dados. Atualiza uma informação. Participa de um processo.

O dispositivo é uma parte essencial dessa operação. Mas o dado que sustenta aquela atividade não necessariamente está no dispositivo.

Ele pode estar em um banco de dados, em um servidor de arquivos, em uma aplicação corporativa, em um ambiente virtualizado ou em uma infraestrutura de nuvem.

Isso significa que existe uma cadeia muito maior por trás daquilo que o usuário enxerga.

O endpoint participa da operação. Os dados sustentam a operação.

Essa distinção ajuda a ampliar a discussão sobre infraestrutura.

Uma organização pode investir continuamente na renovação de seus dispositivos e, ao mesmo tempo, deixar de revisar se a arquitetura que sustenta seus dados acompanha a evolução das aplicações e dos workloads.

Não é uma questão de escolher entre uma coisa ou outra. É entender que elas fazem parte da mesma operação.

Mais dados não significam apenas mais capacidade

Quando o volume de dados cresce, a primeira reação costuma ser pensar em expansão.

• Mais capacidade.
• Mais espaço.
• Mais armazenamento.

Mas volume é apenas uma das variáveis que precisam ser consideradas.

Uma aplicação transacional possui necessidades diferentes de um repositório de documentos. Um banco de dados pode exigir características de desempenho e acesso diferentes de um grande conjunto de dados não estruturados. Um workload virtualizado pode ter requisitos distintos de uma aplicação em contêiner.

Por isso, diferentes arquiteturas de armazenamento existem para atender diferentes características de dados e workloads.

A discussão pode envolver armazenamento em bloco, arquivo ou objeto. Pode envolver desempenho, latência, capacidade, escalabilidade, protocolos de acesso, localização dos dados e integração com os ambientes em que as aplicações estão sendo executadas.

O ponto central não é escolher uma arquitetura porque ela é mais moderna. É entender qual arquitetura faz sentido para o workload que a empresa precisa sustentar.

Por isso, antes de perguntar:  “Quanto espaço precisamos?”

Vale perguntar:

“Que tipos de dados temos?”

“Quais aplicações dependem deles?”

“Como esses dados são acessados?”

“Quais workloads são mais críticos para a operação?”

“Como esse ambiente deve crescer nos próximos anos?”

Essas perguntas mudam a qualidade da decisão.

Onde estão os dados?

Essa talvez seja uma das perguntas mais simples e, ao mesmo tempo, mais difíceis de responder em ambientes que cresceram de forma incremental.

Parte dos dados pode estar em infraestrutura local. Outra parte pode estar em nuvem.

Aplicações podem estar distribuídas entre ambientes físicos e virtuais. Arquivos podem estar em diferentes repositórios. Bancos de dados podem atender aplicações distintas. Novos workloads podem surgir sem que a arquitetura original tenha sido redesenhada para acomodá-los.

O resultado é uma infraestrutura cada vez mais distribuída.

E, quanto mais distribuídos os dados estão, mais importante se torna compreender onde eles estão, quais aplicações dependem deles e como essas diferentes camadas se relacionam. Esse conhecimento deveria preceder a decisão sobre expansão.

Porque não existe uma arquitetura de dados adequada sem uma compreensão mínima do próprio ambiente.

É preciso saber o que existe antes de decidir como sustentar esse ambiente.

Armazenamento, redundância e backup não são a mesma coisa 

Existe outro ponto que merece atenção porque costuma gerar uma simplificação na discussão sobre dados.

Armazenamento não é backup.

E backup não é sinônimo de redundância.

O armazenamento primário sustenta os dados utilizados pelas aplicações no funcionamento cotidiano.

A redundância pode criar cópias adicionais dentro de uma arquitetura de armazenamento para lidar com determinados tipos de falha e atender requisitos de disponibilidade e durabilidade.

O backup tem outra função: manter cópias destinadas à recuperação dos dados quando aquilo que está no ambiente principal não pode ser utilizado como antes.

São camadas diferentes.

Essa distinção é importante porque evita uma conclusão equivocada: ter uma cópia dos dados não significa, por si só, que toda a arquitetura esteja preparada para as necessidades da operação.

Uma organização pode possuir rotinas de backup e ainda precisar avaliar a capacidade, o desempenho, a distribuição e a disponibilidade do armazenamento primário.

Da mesma forma, pode possuir mecanismos de redundância e ainda precisar de uma estratégia específica de backup.

Cada camada responde a uma necessidade.

O trabalho da arquitetura é fazer com que essas necessidades sejam consideradas de forma integrada.

O que o workload tem a ver com isso? 

Tudo. Uma decisão de armazenamento não deveria começar pelo equipamento. Deveria começar pelo workload.

Imagine uma empresa que utiliza uma aplicação crítica para processar transações durante todo o dia.

Agora imagine outra que precisa armazenar grandes volumes de arquivos e dados não estruturados.

As duas têm “dados”. Mas não necessariamente precisam da mesma arquitetura.

A primeira pode depender fortemente de desempenho e baixa latência.

A segunda pode ter como prioridade escala, capacidade e acesso a grandes volumes de informação.

É por isso que a arquitetura precisa acompanhar a natureza dos workloads.

Essa lógica também se aplica quando a infraestrutura começa a incorporar novas tecnologias.

Virtualização, containers, nuvem híbrida, aplicações modernas e inteligência artificial podem introduzir novos padrões de utilização dos dados.

O desafio deixa de ser simplesmente armazenar mais. Passa a ser acompanhar a transformação da própria operação.

A infraestrutura cresce. A arquitetura precisa acompanhar. 

Esse é um ponto que frequentemente passa despercebido.

Uma infraestrutura pode crescer durante anos sem que ninguém faça uma revisão completa da arquitetura.

Um novo servidor é adicionado.

Uma aplicação é implantada.

Um novo ambiente de virtualização é criado.

Mais usuários chegam.

Mais dados são produzidos.

Uma parte da operação vai para a nuvem.

Cada decisão pode fazer sentido individualmente.

O problema aparece quando olhamos para todas elas juntas.

• A arquitetura ainda faz sentido?
• Os diferentes workloads estão sendo atendidos de acordo com suas necessidades?
• Os dados estão onde precisam estar?
• A capacidade acompanha o crescimento?
• A infraestrutura consegue acompanhar novas aplicações?
• Existem dependências que ninguém mais conhece?

Essas perguntas são importantes porque crescimento de capacidade e evolução de arquitetura não são necessariamente a mesma coisa.

É possível aumentar o espaço disponível e, ainda assim, manter uma arquitetura que já não acompanha a complexidade da operação.

Dados como ativo operacional

Quando os dados são tratados apenas como informação armazenada, a conversa tende a ficar restrita à infraestrutura.

Quando são tratados como um ativo operacional, a discussão muda.

Passamos a considerar quais processos dependem deles, quais aplicações os utilizam, quais workloads precisam de maior disponibilidade e como a infraestrutura deve acompanhar a evolução do negócio. Isso aproxima a conversa técnica da realidade da operação.

O colaborador utiliza o dispositivo.

A aplicação processa a informação.

O workload determina determinados requisitos de infraestrutura.

O armazenamento mantém os dados necessários para aquela operação.

As estratégias de redundância, backup e recuperação acrescentam outras camadas.

E o negócio depende da relação entre todas essas peças.

Essa visão é especialmente importante quando diferentes áreas da TI participam de partes diferentes da arquitetura.

Quem administra os endpoints pode não ser a mesma pessoa que administra servidores.

Quem administra servidores pode não ser quem define a estratégia de armazenamento.

Quem cuida do backup pode estar olhando para outra camada.

O desafio está em conectar essas perspectivas.

Porque, para o negócio, o dado continua sendo o mesmo, independentemente de qual equipe administra cada parte da infraestrutura.

E onde entra a tecnologia?

Depois das perguntas certas. Essa ordem importa.

É comum iniciar uma conversa de infraestrutura pelo produto: qual equipamento, qual capacidade, qual plataforma, qual configuração.

Uma abordagem mais madura começa pelo cenário:

Quais são os workloads?

Quais dados eles utilizam?

Quais requisitos precisam ser atendidos?

Como o ambiente está distribuído?

Qual é a perspectiva de crescimento?

Quais camadas já existem?

E quais precisam evoluir?

Somente então a tecnologia passa a ser avaliada como resposta ao problema. 

É nesse contexto que diferentes arquiteturas de armazenamento podem ser consideradas, e entra a solução da nossa parceira Dell.

A Dell Technologies reúne plataformas destinadas a diferentes workloads e necessidades de infraestrutura, incluindo soluções para ambientes de máquinas virtuais, bancos de dados, contêineres, arquivos, dados não estruturados, aplicações essenciais e ambientes de nuvem. O portfólio também contempla diferentes abordagens de armazenamento em bloco, arquivo e objeto.

A questão, portanto, não é simplesmente escolher uma solução de armazenamento.

É avaliar qual arquitetura é coerente com o ambiente que a empresa precisa sustentar. 

Esse é o papel de uma decisão técnica bem estruturada.

A pergunta muda. E a próxima decisão também.

Se os dados são parte da operação, a discussão sobre armazenamento não deveria terminar quando encontramos capacidade suficiente. Ela deveria continuar.

Como esses dados estão distribuídos?

Como são mantidos disponíveis?

Como diferentes camadas da infraestrutura se relacionam?

O que acontece quando um dado deixa de estar disponível no ambiente principal?

Como as cópias são mantidas?

Como a organização consegue recuperar aquilo de que depende?

Essas perguntas conduzem naturalmente para outras camadas da arquitetura.

Proteção.

Backup.

Replicação.

Recuperação.

Mas cada uma delas merece uma discussão própria.

Por isso, antes de falar sobre a próxima solução ou sobre a expansão da capacidade, talvez valha fazer uma pergunta mais básica:

sua equipe conhece suficientemente a arquitetura de dados que sustenta a operação hoje?

Se a resposta não for clara, talvez a próxima decisão de infraestrutura não deva começar pela capacidade.

Talvez deva começar pela arquitetura.

E esse é o ponto de partida para discutir como proteger os dados que a operação não pode deixar de utilizar.

Fale com a Netcenter 

Se sua empresa está revisando a infraestrutura de armazenamento, ampliando workloads ou avaliando como preparar o ambiente para o crescimento dos dados, fale com um de nossos especialistas. 

Nossa equipe pode ajudar a analisar o cenário, os workloads e as necessidades de infraestrutura para identificar os caminhos mais coerentes para a evolução do ambiente.