Visão geral do armazenamento do Red Hat OpenShift on IBM Cloud

Nuvem privada virtual Infraestrutura clássica Satellite

Revise as seguintes seções para obter uma visão geral das opções de armazenamento disponíveis para seu cluster.

Antes de decidir qual tipo de armazenamento é a solução adequada para seus clusters do Red Hat® OpenShift® on IBM Cloud®, é preciso entender o provedor de infraestrutura IBM Cloud, os requisitos do seu aplicativo, o tipo de dados que você deseja armazenar e com que frequência pretende acessar esses dados.

Decida se os seus dados devem ser armazenados permanentemente

Armazenamento persistente: os dados armazenados no armazenamento persistente persistem mesmo quando o contêiner, o nó do trabalhador ou o cluster é removido. Utilize armazenamento persistente em aplicativos com estado, dados essenciais ao negócio ou dados que devam estar disponíveis devido a exigências legais, como um período de retenção definido. Armazenamento persistente também é uma boa opção para auditoria.

Armazenamento não persistente: seus dados podem ser removidos quando o contêiner, o nó do trabalhador ou o cluster é removido. O armazenamento não persistente é geralmente usado para registrar informações, como logs do sistema ou logs de contêiner, teste de desenvolvimento ou quando você deseja acessar dados do sistema de arquivos do host.

Se seus dados devem ser persistidos, analise se o app requer um tipo específico de armazenamento. Ao usar um aplicativo já existente, é possível que ele tenha sido projetado para armazenar dados de uma das seguintes maneiras.

Em um sistema de arquivos: os dados podem ser armazenados como um arquivo em um diretório. Por exemplo, você poderia armazenar esse arquivo em seu disco rígido local. Alguns apps requerem que os dados sejam armazenados em um sistema de arquivos específico, como nfs ou ext4, para otimizar o armazenamento de dados e atingir os objetivos de desempenho.

Em um banco de dados: os dados devem ser armazenados em um banco de dados que segue um esquema específico. Alguns apps vêm com uma interface de banco de dados que pode ser usada para armazenar dados. Por exemplo, o WordPress é otimizado para armazenar dados em um banco de dados MySQL. Nesses casos, o tipo de armazenamento é selecionado para você.

Determine o tipo de dados que você deseja armazenar

Dados estruturados: dados que podem ser armazenados em um banco de dados relacional no qual você tem uma tabela com colunas e linhas. Os dados em tabelas podem ser conectados usando chaves e geralmente são fáceis de acessar devido ao modelo de dados predefinido. Exemplos são números de telefone, números de conta, números de seguridade social ou códigos de endereçamento postal.

Dados semiestruturados: dados que não se ajustam a um banco de dados relacional, mas que vêm com algumas propriedades organizacionais que podem ser usadas para ler e analisar esses dados mais facilmente. Exemplos são arquivos de linguagem de marcações, como CSV, XML ou JSON.

Dados não estruturados: dados que não seguem um padrão organizacional e que são tão complexos que não é possível armazená-los em um banco de dados relacional com modelos de dados predefinidos. Para acessar esses dados, você precisa de ferramentas e software avançados. Exemplos incluem mensagens de e-mail, vídeos, fotos, arquivos de áudio, apresentações, dados de redes sociais ou páginas da web.

Se você tiver dados estruturados e não estruturados, tente armazenar cada tipo de dados separadamente em uma solução de armazenamento que seja projetada para esse tipo de dados. Usar uma solução de armazenamento apropriada para o seu tipo de dados facilita o acesso aos seus dados e fornece os benefícios de desempenho, escalabilidade, durabilidade e consistência.

Analise como você deseja acessar os seus dados. As soluções de armazenamento são geralmente projetadas e otimizadas para suportar operações de leitura ou gravação.

Somente leitura: você não deseja gravar ou mudar os dados. Seus dados são somente leitura.

Leitura e gravação: você deseja ler, gravar e mudar seus dados. Para dados que são lidos e gravados, é importante entender se as operações são de leitura pesada, de gravação pesada ou balanceada.

Determine a frequência em que seus dados são acessados.

Dados quentes: dados que são acessados frequentemente. Casos de uso comuns são apps da web ou móveis.

Dados frescos ou mornos: dados que são acessados infrequentemente, como uma vez por mês ou menos. Os casos de uso comuns são archives, retenção de dados de curto prazo ou recuperação de desastre.

Dados frios: dados que são raramente acessados, se forem. Os casos de uso comuns são archives, backups de longo prazo, dados históricos.

Dados congelados: dados que não são acessados e que você precisa manter devido a motivos jurídicos.

Se não for possível prever a frequência ou se a frequência não seguir um padrão estrito, determine se as cargas de trabalho têm leitura pesada, gravação pesada ou são balanceadas. Em seguida, consulte a opção de armazenamento que se ajusta à sua carga de trabalho e investigue qual camada de armazenamento fornece a flexibilidade necessária. Por exemplo, o IBM Cloud Object Storage fornece uma classe de armazenamento flex que considera como os dados frequentes são acessados em um mês e leva em conta essa medida para otimizar seu faturamento mensal.

Investigue se seus dados devem ser compartilhados entre diversas instâncias de app, zonas ou regiões.

Acessar entre pods: ao usar volumes persistentes do Kubernetes para acessar seu armazenamento, é possível determinar o número de pods que podem montar o volume ao mesmo tempo. Algumas soluções de armazenamento podem ser acessadas por apenas um pod de cada vez. Com outras soluções de armazenamento, é possível compartilhar o volume entre diversos pods.

Acessar entre zonas e regiões: você pode requerer que os seus dados estejam acessíveis entre zonas ou regiões. Algumas soluções de armazenamento, como File Storage and Block Storage, são específicas de data center e não podem ser compartilhadas entre zonas em uma configuração de cluster multizona.

Para tornar seus dados acessíveis entre zonas ou regiões, certifique-se de consultar seu departamento jurídico para verificar se os dados podem ser armazenados em diversas zonas ou em um país diferente.

Entenda outras características de armazenamento que impactam sua opção.

Consistência: a garantia de que uma operação de leitura retorna a versão mais recente de um arquivo. As soluções de armazenamento podem fornecer strong consistency quando você tem garantia de sempre receber a versão mais recente de um arquivo ou eventual consistency quando a operação de leitura pode não retornar a versão mais recente. Frequentemente, você localiza uma consistência eventual em sistemas distribuídos geograficamente nos quais uma operação de gravação deve primeiro ser replicada em todas as instâncias.

Desempenho: o tempo que leva para concluir uma operação de leitura ou gravação.

Durabilidade: a garantia de que uma operação de gravação que está confirmada em seu armazenamento mantenha-se permanentemente e não seja corrompida ou perdida, mesmo se gigabytes ou terabytes de dados forem gravados em seu armazenamento ao mesmo tempo.

Resiliência: a capacidade de se recuperar de uma indisponibilidade e continuar as operações, mesmo se um componente de hardware ou software falhou. Por exemplo, seu armazenamento físico experimenta uma indisponibilidade de energia, uma indisponibilidade de rede ou é destruído durante um desastre natural.

Disponibilidade: a capacidade de fornecer acesso a seus dados, mesmo que um data center ou uma região esteja indisponível. A disponibilidade para seus dados é geralmente obtida pela inclusão de redundância e configuração de mecanismos de failover.

Escalabilidade: a capacidade de ampliar a capacidade e customizar o desempenho com base em suas necessidades.

Criptografia: o mascaramento de dados para evitar visibilidade quando os dados são acessados por um usuário não autorizado.

O armazenamento local secundário deve ser adicionado no momento da criação do pool de trabalho. A adição manual de armazenamento a partir do nível da infraestrutura após a criação de um pool de trabalho não é suportada e não resulta em armazenamento efêmero adicional no cluster.