Entender o OpenShift Data Foundation
Nuvem privada virtual Infraestrutura clássica Satellite
OpenShift O Data Foundation é uma solução de armazenamento altamente disponível que você pode usar para gerenciar o armazenamento persistente para seus aplicativos em contêineres.
- O que é OpenShift Data Foundation?
- OpenShift O Data Foundation é uma solução de armazenamento altamente disponível que consiste em vários operadores e tecnologias de código aberto, como Ceph, NooBaa e Rook. Com estes operadores, você provisiona e gerencia o armazenamento de Arquivos, Blocos e Objetos para suas cargas de trabalho conteinerizadas em clusters do Red Hat® OpenShift® on IBM Cloud®. Ao contrário de outras soluções de armazenamento em que é necessário configurar drivers e operadores separados para cada tipo de armazenamento, o ODF é uma solução unificada capaz de adaptar ou ajustar a escala às suas necessidades de armazenamento. Também é possível implementar o ODF em qualquer cluster OCP.
- Como funciona o OpenShift Data Foundation?
- O ODF usa esses dispositivos para criar uma camada de armazenamento virtualizada, onde seus dados do app são replicados para alta disponibilidade. Como o ODF abstrai seu armazenamento subjacente, é possível usar o ODF para criar solicitações de armazenamento de arquivo, de bloco ou de objeto por meio do mesmo armazenamento de bloco bruto subjacente.
- O ODF usa volumes de armazenamento em múltiplos de 3 e replica os dados do aplicativo entre esses volumes. Os volumes de armazenamento subjacentes que você usa para o ODF dependem do tipo do seu cluster.
- Para clusters de VPC que usam máquinas virtuais, os volumes de armazenamento são volumes de armazenamento Block Storage for VPC.
- Para clusters Classic ou VPC que usam bare metal workers, os volumes de armazenamento são discos locais em seus nós de bare metal worker.
- Para clusters Satellite, os volumes de armazenamento são discos locais em seus nós de trabalho ou você pode provisionar discos dinamicamente usando um driver de armazenamento em bloco compatível.
- Posso instalar o OpenShift Data Foundation em clusters VPC somente privados?
- Sim, você pode instalar o ODF em clusters de VPC somente privados, começando com a versão do cluster
4.16.23_1546_openshiftpara funcionários CoreOS e4.16.21_1544_openshiftpara funcionários RHEL. - É possível instalar o complemento do OpenShift Data Foundation em clusters do Satellite ?
- Nº O complemento de cluster está disponível apenas para clusters Classic e VPC..
- Como instalar o OpenShift Data Foundation no Satellite?
- É possível instalar o ODF em Satellite usando um dos modelos de armazenamento do Satellite. Para obter mais informações, consulte os docs de armazenamento doSatellite.
odf-local: escolha esse modelo quando tiver armazenamento local disponível para seus nós do trabalhador. Se seus volumes de armazenamento estiverem visíveis ao executar olsblk, será possível usar esses discos ao implementar o ODF se eles forem brutos e não formatadosodf-remote: Escolha esse modelo se você tiver um driver CSI instalado em seu cluster. Por exemplo, o driverazuredisk-csi-driver.. É possível usar o driver CSI para fornecer volumes de armazenamento dinamicamente ao implementar o ODF.
Para obter uma visão geral completa dos recursos e benefícios, consulte OpenShift Data Foundation.
Visão geral da arquitetura
Revise o diagrama e a tabela a seguir para saber mais sobre o OpenShift Data Foundation.
| Número | Componente do ODF | Descrição |
|---|---|---|
| 1 | Classes de armazenamento do OpenShift Data Foundation | Ao implementar o ODF, o operador do ODF cria classes de armazenamento File, Block e Object no cluster. Faça referência a estas classes de armazenamento em seus PVCs e para reclamar o armazenamento para os aplicativos. |
| 2 | Armazenamento de bloco OSD | Estes dispositivos fornecem o armazenamento do aplicativo no cluster. Cada OSD é um dispositivo de armazenamento de blocos brutos que pode ser um disco local em seu nó do trabalhador ou provisionado dinamicamente durante a implementação
do ODF. Nos clusters VPC, seus dispositivos de armazenamento de blocos OSD são provisionados dinamicamente usando o driver do Block Storage for VPC. Nos clusters do Satellite é possível usar volumes locais em seus nós do trabalhador
ou dispositivos de armazenamento em bloco de provisionamento dinâmico usando um driver de armazenamento de bloco compatível com o provisionamento dinâmico. Em clusters clássicos, os dispositivos de blocos OSD são discos locais nos nós
do trabalhador. Ao implementar o ODF, cada dispositivo é montado por um pod de OSD. O armazenamento total disponível para seus aplicativos é igual ao osdSize multiplicado pelo numOfOsd. |
| 3 | Pods do Object Storage Daemon (OSD) | Ospods do OSD gerenciam o posicionamento e replicação de dados entre os dispositivos de armazenamento. |
| 4 | Pods de Monitor (Mon) | Os pods do Monitor mantém um mapa do cluster de armazenamento OpenShift Data Foundation e monitoram o funcionamento do cluster de armazenamento. |
| 5 | Dispositivo de armazenamento de bloco do Monitor (Mon) | Os dispositivos de armazenamento do monitor são os dispositivos de armazenamento subjacentes para os pods do monitor. Cada dispositivo de monitor é um dispositivo de armazenamento de bloco bruto que pode ser um disco local em seu nó do trabalhador ou provisionado dinamicamente durante a implementação do ODF. Cada dispositivo fornece armazenamento a um pod do monitor. |
Visão geral do Multicloud Object Gateway
O Multicloud Object Gateway consiste na ferramenta de código aberto NooBaa e é um componente do OpenShift Data Foundation. Com o Multicloud Object Gateway, você gerencia objetos e depósitos entre os provedores de nuvem.
| Número | Componente do Multicloud Object Gateway | Descrição |
|---|---|---|
| 1 | Armazenamento auxiliar | Armazenamentos auxiliares são depósitos de armazenamento de objetos compatíveis com s3. No Multicloud Object Gateway, seus armazenamentos auxiliares podem estar em qualquer ambiente de nuvem, não importando o provedor. É possível conectar diversos armazenamentos auxiliares ao Multicloud Object Gateway. Ao implementar o ODF, o armazenamento auxiliar padrão usa os dispositivos de armazenamento de bloco brutos que você especifica para o cluster de armazenamento do ODF. No entanto, você pode como opção configurar o IBM Cloud Object Storage como seu armazenamento auxiliar padrão. |
| 2 | Classe de depósito | Uma classe de depósito consiste em um ou mais armazenamentos auxiliares (depósitos) e uma política de localização. Configure armazenamentos auxiliares e políticas de localização para gerenciar seus objetos entre locais e nuvens. |
| 3 | Classe de armazenamento | Uma classe de armazenamento no Multicloud Object Gateway é semelhante a qualquer outra classe de armazenamento Kuberenetes, na medida em que define parâmetros de recursos de armazenamento. Entretanto, no Multicloud Object Gateway, ao criar uma classe de armazenamento, você especifica a classe do depósito que deseja usar. Com a criação de uma classe de armazenamento a partir de sua classe de depósito, é possível disponibilizar seus recursos do Multicloud Object Gateway entre os namespaces. |
| 4 | Object Bucket Claim (OBC) | Uma OBC (object bucket claim) é semelhante a uma solicitação de volume persistente (PVC) do Kubernetes, em que os desenvolvedores ou administradores de armazenamento criam OBCs para solicitar recursos de armazenamento. Ao criar uma OBC, você especifica a classe de armazenamento que deseja usar e opcionalmente fornece um nome para o intervalo de objetos criado dinamicamente. |
| 5 | Segredo | Ao criar uma solicitação de depósito de objeto, um segredo do Kubernetes também é criado em seu cluster. |
| 6 | ConfigMap | Ao criar uma solicitação de depósito de objeto, um ConfigMap também é criado em seu cluster. |
| 7 | Depósito de objetos | Um depósito de objetos é provisionado dinamicamente quando você cria uma solicitação de depósito de objetos. O depósito de objetos abstrai um ou mais armazenamentos auxiliares para um único recurso. |
| 8 | s3 app | Um aplicativo que usa armazenamento de objetos. |
| 9 | Referência de segredo | Uma referência de segredo é uma referência a um segredo de Kubernetes em seu cluster. Ao criar um Object Bucket Claim, o NooBaa cria um segredo e um mapa de configuração correspondente. Em seguida, você fazer referência ao segredo e ao mapa de configuração nos aplicativos sem precisar incluir diretamente as credenciais nesses aplicativos. |
| 10 | ConfigMap ref | Uma referência de mapa de configuração é uma referência a um mapa de configuração do Kuberentes em seu cluster. Ao criar um Object Bucket Claim, o NooBaa cria dinamicamente um segredo e um mapa de configuração correspondente. Você pode referenciar o segredo e o mapa de configuração nos aplicativos sem precisar incluir neles essas credenciais. |
| 11 | Recurso namespace | Um recurso namespace é um depósito compatível com s3. Depois de incluir o recursos do namespace (depósitos) no Multicloud Object Gateway, faça referência a esses depósitos criando um depósito Namespace a ser usado para ler e gravar a partir de um ou mais recursos do namespace. |
| 12 | Depósito do namespace | Um depósito do namespace abstrai um ou mais recursos no namespace NooBaa. Ao criar um depósito do namespace, especifique políticas de leitura ou gravação para os recursos de namespace configurados em seu Multicloud Object Gateway. Por exemplo, é possível ler a partir de dois depósitos entre diferentes provedores de nuvem e gravar em um terceiro depósito em outro ambiente de nuvem separado. |
| 13 | Chave de acesso ao depósito do namespace | A chave de acesso é usada para acessar seu depósito do namespace. Os depósitos de namespace incluem múltiplos recursos de namespace de diferentes provedores de nuvem ou depósitos locais. A chave de acesso ao depósito do namespace e a chave secreta são usadas em seus aplicativos s3 para configurar o acesso ao seu depósito de namespace, que então define as políticas de leitura e gravação dos recursos do namespace que você configurar. |
| 14 | Chave secreta de depósito do namespace | A chave secreta é usada para acessar seu depósito do namespace. Os depósitos de namespace incluem múltiplos recursos de namespace de diferentes provedores de nuvem ou depósitos locais. A chave de acesso ao depósito do namespace e a chave secreta são usadas em seus aplicativos s3 para configurar o acesso ao seu depósito de namespace, que então define as políticas de leitura e gravação dos recursos do namespace que você configurar. |
| 15 | Política de localização | Ao criar uma classe de depósito, especifique uma política de localização. As políticas de localização definem como os dados são gravados em seus armazenamentos auxiliares. Uma política de localização de Espelho executa o espelhamento de objetos entre os armazenamentos auxiliares em sua classe de depósito e uma política de localização de Distribuição distribui os objetos entre os armazenamentos auxiliares em sua classe de depósito. |
Suporte de recurso por tipo de faturamento
| Recursos | Itens básicos | Avançado |
|---|---|---|
| Armazenamento de bloco | True | True |
| Armazenamento de arquivos | True | True |
| Armazenamento de objeto | True | True |
| Node e resiliência do disco | True | True |
| Automação baseada em operadora | True | True |
| Compactação | True | True |
| Snapshots locais e clonagem | True | True |
| Criptografia básica de Cluster-wide | True | True |
| Criptografia avançada com KMS | Não | True |
| Recuperação de desastres regionais com replicação | Não | True |
| Clusters Alongados-Metro de alta disponibilidade e recuperação de desastres | Não | True |
| Multi-cluster-Metro de alta disponibilidade e recuperação de desastres | Não | True |
| Custo por vCPU hora | $0.022 | $0.029 |
Melhores práticas
Revise as seções a seguir para melhores práticas ao instalar e gerenciar o ODF.
Planejamento
- Planeje a distribuição dos nós de trabalho
- Para assegurar alta disponibilidade, difunda o cluster ODF em domínios de falha. Esta distribuição ajuda a minimizar o impacto de falhas do nó e a manter a estabilidade geral do cluster
- Atender às especificações mínimas do nó do trabalhador
- Os nós do trabalhador que usam ODF devem ter 16 vCPUs e 64GB de RAM ou superior. Para clusters clássicos do IBM, o tipo recomendado é
mb4c.32x384.3.8tb.ssdou superior - Mantenha um host de espera para alta disponibilidade..
- Para garantir a alta disponibilidade e minimizar o tempo de inatividade em caso de falha de um host, é recomendável manter sempre um host em espera.
- Atender a contagem de dispositivos de armazenamento por recomendações de nó
- Planeje ter menos de nove dispositivos de armazenamento por nó Isso ajuda a evitar possíveis gargalos e melhora a eficiência de acesso e recuperação de dados.
- Use os tamanhos e as contagem de dispositivos de armazenamento recomendados
- Ao implementar armazenamento local, use tamanhos de disco de 4 TiB ou menores. É importante assegurar que todos os discos no cluster, em todos os nós de armazenamento, sejam do mesmo tamanho e tipo para o uso ideal de armazenamento Use OSDs de pelo menos 512Gi.
- Aumente a capacidade usando o fator de replicação padrão e a configuração do nó de armazenamento
- No OpenShift Data Foundation (ODF), o fator de replicação é configurado como 3 por padrão. Ao incluir capacidade, planeje incluir nós de armazenamento em múltiplos de 3.
- Escolha a configuração certa para suas necessidades: armazenamento remoto vs armazenamento local
- Se você tiver necessidades de armazenamento mais baixas ou estiver usando instâncias do Virtual Server, o armazenamento remoto poderá ser uma opção conveniente e econômica No entanto, se você tiver grandes requisitos de armazenamento, um cluster bare metal ou um armazenamento de alto desempenho com baixa latência de rede, seria mais adequado usar o armazenamento local.
- Simplifique sua implementação usando o recurso de descoberta automática
- Em {: tag-classic-inf} [clássicos] ou ambientes com armazenamento local, aproveite o recurso de descoberta automática para identificar e configurar automaticamente os discos de armazenamento disponíveis em seu cluster para ODF. Esta opção elimina a necessidade de seleção de disco manual A menos que haja requisitos de disco específicos para o fornecimento do ODF, a utilização do recurso de autodescoberta aperfeiçoa o processo de implementação e reduz o potencial para erros de configuração
- Usar classes de armazenamento metropolitanas para instalações do ODF em armazenamento remoto
- Ao executar uma instalação do ODF que usa armazenamento remoto, certifique-se de usar uma classe de armazenamento que tenha
VolumeBindingModedeWaitForFirstConsumer, o que atrasa a criação do Block Storage até que o primeiro pod que usa esse armazenamento esteja pronto para ser agendado. - Dimensionar sua implementação
- Para uma análise detalhada dos requisitos de armazenamento, a Ferramenta de Dimensionamento para determinar a sua capacidade de armazenamento necessária Também é possível usar a ferramenta de dimensionamento oficial Red Hat
- Configurar backups periódicos
- Fazer backups periódicos do cluster do ODF é essencial para garantir a proteção dos dados e facilitar a recuperação dos dados em caso de desastre. Sem backups regulares, recuperar dados de um evento catastrófico se torna significativamente mais desafiador e pode levar à perda permanente de dados.
Implementação
- Planeje usar nós de armazenamento dedicados
- Em cenários com cargas de trabalho pesadas, use nós de armazenamento dedicados para o ODF Ao separar as operações de nós de armazenamento, é possível alcançar um melhor desempenho e escalabilidade para sua infraestrutura de armazenamento
- Configure o monitoramento regular do Red Hat console
- O console Red Hat fornece informações valiosas sobre a integridade e o desempenho do seu ambiente ODF. Recomenda-se monitorar regularmente o console para ficar informado sobre quaisquer problemas em potencial. O console aciona os alertas sempre que há problemas detectados com o ODF, permitindo que você tome medidas proativas.
- Avisos de capacidade de endereço imediatamente
- Quando os avisos de capacidade são emitidos, é importante abordá-los prontamente Ignorar ou atrasar a ação sobre esses avisos pode levar a restrições de capacidade de armazenamento e possíveis interrupções em suas cargas de trabalho Trate os avisos de capacidade como uma oportunidade para avaliar suas necessidades de armazenamento e tomar medidas apropriadas para mitigar quaisquer problemas potenciais.
Expansão de capacidade
- Entenda suas opções para expansão de capacidade
- Há duas opções disponíveis para a expansão da capacidade no ODF A primeira opção envolve aumentar a capacidade incluindo mais OSDs (Daemons doObject Storage ) em nós existentes no cluster. Isso permite utilizar os recursos disponíveis para expandir a capacidade de armazenamento. A segunda opção é expandir a capacidade incluindo novos nós no cluster.. Quando o número de OSDs for aumentado, os OSDs serão provisionados automaticamente nos nós recém-incluídos.
Atualizar
- Executar verificações de funcionamento substituindo nós
- Evite substituir um nó de armazenamento se o ODF não estiver em um estado funcional. Antes de continuar com a substituição do nó, verifique sempre o status de funcionamento do ODF Tente resolver quaisquer problemas antes de substituir o nó não funcional.
- Mantenha seu ambiente atualizado
- Mantenha a sua versão do cluster atualizada para a versão padrão ou mais recente disponível Manter-se atualizado com a versão do cluster assegura que você possa aproveitar os recursos mais recentes e manter a compatibilidade com outros componentes em seu ambiente.
- Executar atualizações do ODF após upgrades de cluster..
- Sempre faça upgrade do cluster principal e do nó do trabalhador primeiro e, em seguida, vá para o upgrade do ODF Após concluir um upgrade do cluster, é essencial atualizar o ODF também. Embora o ODF suporte a versão do cluster atual (n) e a próxima versão do cluster (n+1), mantenha a versão do ODF igual à versão do cluster. Este alinhamento assegura a compatibilidade ideal..
- Atualizar nós de armazenamento sequencialmente
- Ao fazer upgrade dos nós de armazenamento, é melhor prática executar os upgrades um por um. Essa abordagem sequencial permite verificar o status do ODF após cada upgrade do nó e assegurar que sua infraestrutura de armazenamento permaneça funcional durante todo o processo. Ao atualizar nós individualmente, é possível monitorar de perto o impacto de cada upgrade no ODF e identificar e resolver rapidamente quaisquer problemas que possam surgir.
Recuperação
- Substituir hosts não funcionais
- Se houver um desastre local, recomenda-se que um host de cluster não íntegro seja substituído por um íntegro.
- Siga a documentação para recuperar OSDs
- Quando um OSD (Daemon doObject Storage ) fica inativo no OpenShift Data Foundation (ODF), é importante seguir as etapas recomendadas para a recuperação. A documentação fornecida do IBM Cloud Platform fornece instruções detalhadas sobre como recuperar um OSD em tais situações.
Desinstalação e remoção
- Excluindo pods e volumes persistentes (PVs)
- Ao excluir recursos que usam classes de armazenamento ODF, é importante seguir o procedimento recomendado. Sempre exclua os pods e PVs associados criados usando as classes de armazenamento OF antes de continuar com a exclusão de outros recursos
- Siga a ordem de limpeza correta
- Ao desativar ou remover o ODF do seu cluster, certifique-se de seguir a documentação ao limpar os recursos. Comece excluindo o recurso do
ocscluster, que é responsável por gerenciar o ODF Depois que o recursoocsclusterfor removido, continue para remover o complemento ODF do console da IBM. Seguir essa sequência assegura uma remoção suave e adequada do ODF de seu cluster, evitando possíveis problemas ou conflitos.
Resolução de problemas
- Revise os alertas e limites de capacidade
- O ODF gera alertas de capacidade quando a capacidade de armazenamento do cluster atinge determinados limites Estes limiares são fixados em 75% (quase total) e 85% (total) da capacidade total. Esses alertas indicam que a capacidade de armazenamento está se aproximando de seus limites, e requer atenção.
- Revise os problemas comuns
- Ao encontrar problemas com o OpenShift Data Foundation (ODF), é útil consultar os runbooks disponíveis que fornecem orientação sobre a resolução de problemas comuns. Os runbooks contêm uma lista abrangente de problemas conhecidos e suas soluções correspondentes para o ODF
Implementação do OpenShift Data Foundation
Revise as opções de implementação para seu provedor de infraeestrutura.
- Clusters de Virtual Private Cloud (VPC)
- Você pode implementar o ODF usando o provisionamento dinâmico com Block Storage for VPC ou usando discos locais em trabalhadores bare metal. Para mais informações, consulte Implementação do OpenShift Data Foundation em clusters VPC.
- Clusters Satellite
- Se você quiser implantar o ODF em clusters Satellite, poderá usar o modelo de armazenamento Satellite. Para obter mais informações, veja os links a seguir.
- Implementação do modelo do OpenShift Data Foundation em discos remotos e dinamicamente provisionados.
- Implementação do modelo do OpenShift Data Foundation em discos locais.
- Classic clusters
- É possível implementar o ODF mediante uso de discos em nós do trabalhador bare metal. Para mais informações, consulte Implementação do OpenShift Data Foundation em clusters clássicos.