Pools replicados (padrão)

A configuração padrão do ODF utiliza replicação tripla. Cada dado é armazenado em três cópias em nós diferentes, o que oferece proteção contra até duas falhas simultâneas de disco ou de nó.

• Vantagens: arquitetura simples, leituras rápidas, recuperação rápida e latência previsível.
• Aumento no uso: 3x de armazenamento bruto para cada byte de dados utilizáveis.

O que acontece quando as cópias são perdidas ( rep3 ):

O parâmetro min_size controla o número mínimo de cópias que devem estar disponíveis antes que o Ceph permita a E/S. O ODF define, por padrão, o parâmetro “ min_size=2 ” para os pools “ rep3 ” e essa configuração é aplicada por meio de “ requireSafeReplicaSize: true ”, o que significa que, quando houver 2 ou 3 cópias disponíveis, as operações de leitura e gravação ocorrem normalmente. Quando há apenas uma cópia disponível, o Ceph bloqueia as operações de E/S para evitar novas inconsistências nos dados.

Esse comportamento é um mecanismo de segurança deliberado que prioriza a integridade dos dados em detrimento da disponibilidade.

O período entre a perda da segunda cópia e a conclusão da replicação é o mais perigoso. Durante esse período, uma terceira falha causa perda permanente de dados. É por isso que o planejamento de capacidade é importante, pois a velocidade de replicação do Ceph depende da largura de banda disponível do cluster e do espaço livre. Um cluster sobrecarregado ou quase cheio leva mais tempo para ser replicado novamente, o que prolonga o período de vulnerabilidade.

No caso das piscinas “ rep2 ”, a progressão é mais agressiva. Se uma cópia for perdida, apenas uma cópia permanecerá. Com a opção “ min_size=2 ” (padrão), a E/S é imediatamente bloqueada nos PGs afetados até que o OSD ausente retorne ou uma nova cópia seja replicada. Com a opção “ min_size=1 ”, a E/S continua na única cópia restante, mas uma segunda falha resulta em perda permanente de dados.

O complemento ODF do Red Hat OpenShift Kubernetes Service cria automaticamente apenas pools do tipo “ rep3 ” com ocs-storagecluster-cephblockpool. Rep2 Os pools não são criados pelo complemento. Você deve criar manualmente um arquivo CephBlockPool personalizado com o conteúdo replicated.size: 2 e um arquivo StorageClass correspondente. Para obter mais informações, consulte “Criação de um StorageClass personalizado para virtualização ”.

Como o rep2 oferece menos tolerância a falhas do que o rep3, avalie se a economia de espaço de armazenamento justifica o aumento do risco para sua carga de trabalho.

IBM recomenda a replicação em três vias para todas as cargas de trabalho de virtualização em produção, a fim de ajudar a garantir a disponibilidade e a durabilidade dos dados.

Piscinas com código de apagamento

Para ambientes em que a eficiência da capacidade de armazenamento é uma prioridade, o ODF também oferece suporte a pools com códigos de eliminação (EC). O EC divide os dados em blocos de dados k e blocos de paridade m, reduzindo o uso de armazenamento bruto em comparação com a replicação, ao mesmo tempo em que continua a oferecer tolerância a falhas.

Status do suporte: A codificação de apagamento para RBD e CephFS no ODF é um recurso em pré-visualização para desenvolvedores, introduzido pela primeira vez no ODF 4.20. Os recursos da versão de pré-visualização para desenvolvedores não são compatíveis com uso em produção. Além disso, elas não são abrangidas pelo gerenciamento de casos do Portal do Cliente d Red Hat. Antes do ODF 4.20, apenas o EC RGW (armazenamento de objetos) estava disponível como pré-visualização para desenvolvedores (no ODF 4.16 ). Embora o mecanismo de armazenamento Ceph subjacente ofereça suporte a substituições de EC para RBD desde a versão Luminous (2017), o operador ODF e seu modelo de implantação gerenciada ainda não certificam pools de EC para cargas de trabalho de armazenamento em bloco de produção. Planeje utilizar pools replicados ( rep2 ou rep3 ) para todo o armazenamento de produção VM e avalie os pools EC apenas para ambientes que não sejam de produção, nos quais as limitações da versão de pré-visualização para desenvolvedores sejam aceitáveis.

A tabela a seguir compara todos os tipos de pool disponíveis, a título de referência.

As listas a seguir apresentam as principais considerações sobre a codificação de apagamento.

• Os pools EC apresentam maior latência de gravação do que os pools replicados devido ao cálculo de paridade e à necessidade de gravar mais blocos por operação.
• Os pools EC oferecem taxa de transferência de leitura sequencial competitiva, mas podem apresentar IOPS de gravação aleatória reduzido.
• O número de domínios de falha deve ser, no mínimo, k+m. Em um cluster de 3 nós, apenas rep2, rep3 e ec-2-1 são possíveis.
• Para um cluster de 6 nós, todos os tipos de pool listados anteriormente estão disponíveis.

Pool de réplicas único (sem resiliência, apenas para desenvolvimento e testes)

A partir da versão do complemento ODF 4.14, Red Hat OpenShift Kubernetes Service oferece suporte a um pool de réplica única ( rep1 ) por meio do parâmetro addSingleReplicaPool. Este parâmetro cria um pool de blocos não resiliente do Ceph, sem replicação de dados, no qual cada bloco de dados é armazenado uma única vez.

Para habilitar o conjunto de réplicas únicas ao implantar o ODF, use o seguinte comando

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

Este comando cria um StorageClass:

• ocs-storagecluster-ceph-non-resilient-rbd: Armazenamento de bloco de réplica única com vinculação de volume WaitForFirstConsumer.

A pool padrão “ replica-3 ” (ocs-storagecluster-cephblockpool) ainda é criada com ele. O pool não resiliente é uma opção separada e opcional.

Um único pool de réplicas apresenta os seguintes casos de uso.

• Ambientes de desenvolvimento e teste — nos quais a durabilidade dos dados não é essencial e a redução dos custos de armazenamento é priorizada.
• Aplicativos com replicação integrada — esses aplicativos gerenciam sua própria redundância de dados na camada de aplicação. Essas aplicações mantêm várias cópias entre os nós, o que significa que a replicação no nível do armazenamento é redundante.

O pool de réplicas único oferece tolerância zero a falhas. Uma falha em um único OSD ou nó resulta em perda permanente e irrecuperável de todos os dados desse OSD. Nenhuma segunda cópia está disponível para recuperação. A documentação do site IBM Cloud adverte explicitamente que essa opção aumenta o risco de perda de dados, corrupção de dados e possível instabilidade do sistema. Para obter mais informações, consulte a documentação do Ceph.

Limitações:

• Apenas armazenamento em bloco: o armazenamento de arquivos não é compatível com uma única réplica.
• Requer discos adicionais: pelo menos um disco NVMe utilizável adicional por nó, além daqueles utilizados pelo pool “ replica-3 ”. Sem esse disco extra, os OSDs do replica-1 não são iniciados e o cluster de armazenamento permanece em um estado de progresso.
• Um pool por domínio de falha: O ODF cria um CephBlockPool não resiliente por domínio de falha, com volumes que são vinculados usando WaitForFirstConsumer para validar a localidade dos dados.
• Não recomendado para discos raiz de carga de trabalho de máquinas virtuais: Se o OSD que hospeda um disco raiz falhar, a carga de trabalho da máquina virtual será perdida permanentemente. Use o pool não resiliente apenas para discos de dados descartáveis em cargas de trabalho de máquinas virtuais de desenvolvimento ou teste.

Para cargas de trabalho de virtualização em produção, utilize sempre pools do tipo “ replica-3 ” (ou, no mínimo, do tipo “ replica-2 ”).

VMware vSAN comparação de migração

Para as equipes que estão migrando de VMware vSAN™, esses tipos de pool do Ceph correspondem às políticas de armazenamento já conhecidas do vSAN:

Principais diferenças em relação a vSAN:

• Mínimos de host menores: O Ceph separa o quorum do cluster do posicionamento dos dados. Um pool do tipo “ rep3 ” precisa de apenas 3 hosts, pois cada host armazena uma cópia completa. vSAN RAID-1 FTT=2 precisa de 5 hosts.
• rep2 corresponde ao padrão vSAN RAID-1: A maioria das implantações do vSAN utiliza FTT=1, que armazena duas cópias. O rep2 do Ceph é o equivalente direto.
• ec-3-1 corresponde a vSAN RAID-5: Ambos utilizam um layout 3+1 e alcançam uma utilização de 1.33x, a opção mais eficiente em termos de espaço para tolerância a uma única falha.
• ec-4-2 corresponde a vSAN e RAID-6:. Ambos utilizam um layout 4+2 e alcançam uma utilização de 1.5x com tolerância a falhas duplas.
• ec-2-1 e “ ec-2-2 ” não têm um equivalente direto em “ vSAN ”: configurações menores do Ceph EC com menos blocos de dados, o que resulta em maior uso por byte, mas exige menos hosts. Elas sacrificam a eficiência de armazenamento em troca de requisitos menores quanto ao número de hosts.

Capacidade de planejamento

Ao planejar seu cluster ODF, leve em consideração o uso bruto de armazenamento da política de proteção de dados escolhida. A capacidade utilizável é menor do que a capacidade total bruta do NVMe.

A fórmula da capacidade utilizável é Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor.

Veja o exemplo de cálculos a seguir para um cluster de 3 nós com 8 unidades NVMe de 3.2 TB por nó (total bruto de 76.8 TB):

Estimativa da capacidade da carga de trabalho da máquina virtual: Uma carga de trabalho típica de máquina virtual com um disco raiz de 30 GB e um disco de dados de 100 GB usa 130 GB de armazenamento utilizável. Com o rep3, essa carga de trabalho da máquina virtual requer 390 GB de armazenamento bruto. No cluster de 3 nós mencionado anteriormente, seria possível provisionar aproximadamente 196 cargas de trabalho de máquinas virtuais desse tamanho. Na prática, mantenha o uso do Ceph em menos de 75% para manter o desempenho e dar suporte às operações de recuperação.

O desempenho do Ceph diminui à medida que o uso do cluster aumenta. O ODF aciona o alerta “ CephOSDNearFull ” ( Prometheus ) quando qualquer OSD excede 75% de utilização. Aos 85%, o Ceph define o sinalizador OSD nativo “ nearfull ” (mon_osd_nearfull_ratio) e o ODF dispara o alerta “ CephOSDCriticallyFull ”. Quando atinge 90%, o Ceph interrompe as operações de preenchimento e recuperação no OSD afetado (mon_osd_backfillfull_ratio). Quando atinge 95%, o Ceph marca o OSD como “ full ” (mon_osd_full_ratio), bloqueia todas as gravações e emite a mensagem “ HEALTH_ERR ”. Planeje sua capacidade de forma que a utilização permaneça abaixo de 70% durante as operações normais, deixando margem para recuperação de dados e reequilíbrio durante a manutenção dos nós ou em caso de falhas.

Para verificar o uso atual do cluster, execute o seguinte comando:

oc exec -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) -- ceph df

Número de nós de trabalho e topologia

A topologia do domínio de falhas utilizada pelo complemento ODF do IBM Cloud depende da configuração do seu cluster:

• Clusters multizona (3 zonas de disponibilidade): O domínio de falha está definido como zone. Os nós de trabalho estão distribuídos pelas zonas, e o ODF deve crescer em múltiplos de 3 para manter o equilíbrio entre as zonas. Para obter disponibilidade, desempenho e segurança de dados ideais, utilize 3, 6 ou 9 nós no cluster de armazenamento ODF — cada zona recebe o mesmo número de nós.
• Clusters de zona única ou clusters com menos de 3 zonas de disponibilidade: o dimensionamento flexível é ativado automaticamente e o domínio de falha é definido como “ host ”. Você pode começar com 3 nós e adicionar nós, um de cada vez.

Todos os nós que participam do cluster de armazenamento ODF devem ser bare metal. Não há suporte para a combinação de nós virtualizados e bare-metal no mesmo cluster ODF.

Para clusters com várias zonas: adicionar nós em quantidades que não sejam múltiplos de 3 gera um desequilíbrio entre as zonas. Com 4 nós, uma zona recebe 2 nós, enquanto as outras recebem 1 cada, resultando em distribuição desigual do peso dos OSDs, posicionamento de dados abaixo do ideal, uso desigual e OSDs parcialmente ociosos.

Para clusters com várias zonas, sempre faça o dimensionamento em múltiplos de 3 para manter uma topologia de zonas equilibrada.

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

Planos de assinatura do ODF

Escolha o plano que melhor atende às suas necessidades:

• Itens básicos

  • Custo reduzido
  • Apenas implantação no modo interno
  • Não oferece suporte à recuperação de desastres, clusters estendidos ou implantações no modo externo
  • Mais adequado para ambientes de teste e desenvolvimento, provas de conceito ou implantações em pequena escala

• Avançado

  • Conjunto completo de recursos que inclui recuperação de desastres, clusters estendidos, implantação em modo externo, criptografia granular avançada e suporte a múltiplos clusters
  • Recomendado para cargas de trabalho de virtualização em produção com máquinas virtuais

Ambos os planos incluem compressão d BlueStore s em conjuntos de blocos, provisionamento dinâmico, instantâneos e clonagem. As diferenças entre os planos dizem respeito à recuperação de desastres, à granularidade da criptografia e à flexibilidade de implantação, e não aos recursos de eficiência de armazenamento.

O ODF oferece suporte à deduplicação somente para armazenamento de objetos por meio do MCG (Multicloud Object Gateway). O armazenamento em bloco não oferece suporte à deduplicação. Esse suporte se aplica tanto ao plano Essentials quanto ao plano Advanced. A desduplicação upstream do Ceph para RBD permanece experimental e não está certificada para uso no ODF.

Para obter mais informações, consulte “ODF: Noções básicas versus Avançado ”.

Tipo de armazenamento

• Selecione Armazenamento local.
• O armazenamento local usa o armazenamento de instância NVMe local disponível nos nós de trabalho bare metal.
• As unidades NVMe oferecem latência reduzida e alto desempenho em IOPS, características necessárias para os discos que suportam cargas de trabalho de máquinas virtuais.

Perfil do recurso ODF

O ODF fornece três perfis de alocação de recursos que controlam a CPU e a memória reservadas para os daemons do Ceph.

• Lean: alocação mínima de recursos. O perfil Lean é adequado para ambientes com recursos limitados, testes, desenvolvimento e provas de conceito. O Lean não é recomendado para cargas de trabalho de virtualização de produção.
• Equilibrado: O perfil padrão em Red Hat OpenShift Kubernetes Service. O perfil Balanced oferece um equilíbrio entre o consumo de recursos e o desempenho para cargas de trabalho de uso geral.
• Desempenho: Aloca mais CPU e memória aos daemons do Ceph, o que reduz o risco de gargalos no lado dos daemons. Ideal para cargas de trabalho com alto número de IOPS, grande quantidade de servidores virtuais e aplicativos exigentes.

Para implantações em bare metal com unidades NVMe locais, use o perfil de recurso “Desempenho ”. Nós bare-metal com 8 ou mais unidades NVMe por nó geram um número elevado de OSDs por host. Com o perfil “Balanced”, os limites de CPU e memória do daemon do Ceph costumam ser atingidos antes que o hardware NVMe subjacente fique saturado, o que limita o número de IOPS e aumenta a latência. O perfil de desempenho é o perfil mínimo recomendado para cargas de trabalho de virtualização do Red Hat OpenShift em produção em ambiente bare-metal.

Os requisitos de recursos mostrados no console da Web Red Hat OpenShift durante a instalação do ODF são calculados dinamicamente com base na contagem de OSDs do cluster. Portanto, os clusters com mais unidades NVMe exigem proporcionalmente mais recursos. Os valores não são fixos. Sempre verifique os requisitos exibidos no console para sua configuração específica de cluster.

O perfil é selecionado durante a criação do site StorageSystem por meio da tela Configure Performance (Configurar desempenho) no console da Web Red Hat OpenShift. Os daemons do Ceph com recursos insuficientes podem se tornar um gargalo oculto, causando uma redução nas IOPS ou uma latência maior do que a que o hardware de armazenamento subjacente é capaz de oferecer.

Combine seus perfis de servidor bare metal com os requisitos de recursos mostrados para o perfil escolhido: IBM Cloud Perfis de servidor bare metal da VPC.

Uma pequena sobrecarga de recursos geralmente é aceitável em um servidor bare metal. No entanto, nunca aloque recursos significativamente inferiores aos requisitos mínimos exibidos, pois isso prejudica o desempenho e a estabilidade do ODF.

Número de discos OSD por nó

• Determine o número de unidades NVMe locais disponíveis em cada servidor bare metal.
• Certifique-se de que o número de OSDs configurados por nó não exceda o número de unidades NVMe utilizáveis.
• O padrão recomendado é de 1 OSD por unidade NVMe para obter desempenho ideal e isolamento de falhas.
• Certifique-se de que o número de discos OSD corresponda, em geral, ao número de unidades NVMe por nó bare metal. O cálculo da capacidade de armazenamento exibido na interface do usuário não reflete a capacidade útil real para configurações de armazenamento local e pode ser desconsiderado.

Ao selecionar nós durante a criação de um StorageSystem, evite selecionar todos os nós do cluster. A seleção de todos os nós cria um LVS ( LocalVolumeSet ) sem nodeSelector. Qualquer nó de trabalho que for adicionado ao cluster no futuro será automaticamente detectado pelo ODF, mesmo que não seja destinado ao armazenamento. Os nós detectados de forma inesperada devem ser removidos manualmente do LVS. Para evitar isso, selecione apenas os nós do seu pool de workers de armazenamento dedicado ou certifique-se de que esses nós tenham a etiqueta “ cluster.ocs.openshift.io/openshift-storage ” antes da criação d StorageSystem.

Padrão StorageClass para o cluster

Após a implantação do ODF, geralmente são criados os arquivos de configuração do ODF ( followingStorageClasses ):

• ocs-storagecluster-ceph-rbd: Armazenamento em bloco
• ocs-storagecluster-cephfs: Armazenamento de arquivos
• ocs-storagecluster-ceph-rgw: Armazenamento de objetos

Para permitir que as cargas de trabalho utilizem automaticamente o armazenamento em bloco persistente de alto desempenho baseado no ODF sem necessidade de configuração adicional, selecione “Usar dispositivo de bloco Ceph RADOS (RBD)” como classe de armazenamento padrão ou defina manualmente o RBD (ocs-storagecluster-ceph-rbd) como “ StorageClass ” padrão para o cluster após a instalação do complemento ODF.

1. Marcar RBD como padrão:

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. Se necessário, remova a configuração padrão da configuração padrão definida anteriormente:

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

Lista de verificação da configuração do ODF

• O cluster contém pelo menos um pool de servidores bare metal
• Red Hat OpenShift versão 4.17 ou superior
• O complemento e o operador do ODF estão instalados e em execução
• Os servidores bare metal têm unidades NVMe locais utilizáveis suficientes
• O perfil de recurso selecionado corresponde à capacidade do nó
• O cluster de armazenamento ODF utiliza no mínimo 3 nós; os clusters com várias zonas devem utilizar múltiplos de 3 (3, 6, 9, …) para manter o equilíbrio da zona
• Todos os nós participantes do ODF são bare metal
• O RBD StorageClass é criado e, de preferência, definido como padrão
• O status do cluster ODF é “Pronto” (oc get storagecluster -n openshift-storage)
• O estado do Ceph é HEALTH_OK (oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status)

Pré-requisitos: Instalar o operador de virtualização “ Red Hat OpenShift ”

Antes de usar a virtualização do Red Hat OpenShift no IBM Cloud, verifique se o operador de virtualização Red Hat OpenShift está instalado no seu cluster Red Hat OpenShift Kubernetes Service.

O operador de virtualização “ Red Hat OpenShift ” permite o gerenciamento de cargas de trabalho de máquinas virtuais nativas d Kubernetes. Ele também fornece os controladores, CRDs e integrações necessários com componentes de armazenamento e rede.

Para obter mais informações, consulte Red Hat OpenShift Virtualização em IBM Cloud.

Uso do armazenamento ODF para cargas de trabalho de máquinas virtuais

Red Hat OpenShift O Data Foundation (ODF) oferece armazenamento persistente e definido por software para cargas de trabalho de virtualização executadas em Red Hat OpenShift. Ao utilizar o ODF como back-end de armazenamento para máquinas virtuais, a escolha do “ StorageClass ” correto é fundamental para garantir desempenho, estabilidade e compatibilidade total com os recursos.

É necessário especificar o StorageClass adequado nas seguintes situações:

• Os servidores virtuais são criados
• Os servidores virtuais são importados ou clonados
• Os servidores virtuais são migrados para um cluster do Red Hat OpenShift Kubernetes Service

Virtualização padrão StorageClass

Quando o Operador de Virtualização do Red Hat OpenShift é instalado e um cluster ODF está disponível, é criado automaticamente um StorageClass otimizado para cargas de trabalho de virtualização:

• ocs-storagecluster-ceph-rbd-virtualization

Este StorageClass é:

• Ajustado para padrões de E/S de disco, como leituras e gravações aleatórias e taxa de transferência sustentada
• Validado para operações de ciclo de vida de virtualização, como iniciar, parar, migração em tempo real e instantâneos
• Totalmente suportado e recomendado para ambientes de virtualização de produção Red Hat OpenShift

Para a maioria dos casos de uso, use este StorageClass sem modificações.

Requisitos de armazenamento de migração em tempo real

A migração em tempo real move uma carga de trabalho de máquina virtual em execução de um nó de trabalho para outro sem tempo de inatividade. Para que a migração em tempo real seja bem-sucedida, o armazenamento deve estar acessível simultaneamente nos nós de origem e de destino. A migração dinâmica requer as seguintes configurações.

• ReadWriteMany modo de acesso em PVCs de carga de trabalho de máquinas virtuais. O Ceph RBD oferece suporte ao RWX no modo de bloco, que é a configuração padrão para a virtualização do ODF StorageClass.
• O ocs-storagecluster-ceph-rbd-virtualization StorageClass vem pré-configurado com suporte a ReadWriteMany por meio do modo de bloco RBD. Os servidores virtuais que usam esse StorageClass podem migrar ao vivo sem configuração adicional.
• O genérico ocs-storagecluster-ceph-rbd StorageClass usa o modo de acesso ReadWriteOnce por padrão. Os servidores virtuais que usam PVCs RWO não podem executar a migração em tempo real. A migração falha porque o PVC não pode ser montado no nó de destino enquanto estiver conectado à origem.

Se você criar um customStorageClasses s para servidores virtuais que precisam de migração dinâmica, verifique se os PVCs foram criados com accessModes: [ReadWriteMany] e volumeMode: Block.

A migração em tempo real também requer:

• Configuração do operador de virtualização Red Hat OpenShift com uma política de migração adequada
• Verificar se há CPU e memória suficientes disponíveis no nó de destino

Específico para virtualização em comparação com RBD genérico StorageClass

Embora as máquinas virtuais possam utilizar um RBD genérico do Ceph StorageClass,, o StorageClass, específico para virtualização, é otimizado para as características exclusivas de E/S e ciclo de vida dos discos de carga de trabalho das máquinas virtuais.

O RBD genérico StorageClasses continua sendo adequado para cargas de trabalho em contêineres, mas o StorageClass, específico para virtualização, é recomendado para ambientes de virtualização em produção.

Criação de um StorageClass personalizado para virtualização

Em alguns cenários, talvez você precise de um StorageClass personalizado para atender a requisitos específicos de desempenho, resiliência ou capacidade.

Para criar um StorageClass personalizado, é necessário primeiro criar um CephBlockPool personalizado. Ao criar um pool personalizado, você deve definir o endereço targetSizeRatio no pool. Sem essa configuração, o autoscaler de grupos de posicionamento do Ceph atribui apenas 1 grupo de posicionamento ao pool. Essa atribuição faz com que todas as operações de E/S fiquem concentradas em um único OSD, resultando em um desempenho inferior ao do pool padrão.

Quando você criar um StorageClass personalizado para cargas de trabalho de virtualização, verifique se os seguintes parâmetros estão configurados corretamente.

• Fornecedor

  O StorageClass deve utilizar o provisionador Ceph RBD CSI fornecido pela ODF:

  openshift-storage.rbd.csi.ceph.com
  

  Esse provisionador permite o provisionamento dinâmico de volumes Ceph RBD que são apoiados pelo cluster ODF.

• Conjunto de armazenamentos

  Especifique o endereço CephBlockPool que faz o backup dos discos de carga de trabalho da máquina virtual. Escolha uma das seguintes opções:

  • Pool de blocos padrão. O pool de blocos Ceph replicado de 3 vias padrão criado pelo ODF:

      ocs-storagecluster-cephblockpool
      ```
  
  - Piscina de blocos personalizada. Um site definido pelo usuário CephBlockPool. O pool deve incluir as seguintes configurações para evitar problemas de desempenho:
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• Recursos de imagem

  O site StorageClass deve incluir os recursos de imagem do RBD que são essenciais para o desempenho da carga de trabalho:

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  Recursos de imagem RBD e sua finalidade

  Recursos	Propósito
  exclusive-lock	Ativa o cache de writeback e as otimizações de gravador único. Sem esse recurso, o IOPS de gravação pode ser até 7x pior.
  object-map	Permite o rastreamento de bitmap de objetos alocados para imagens esparsas.
  fast-diff	Acelera as operações de comparação de snapshot e clonagem de DataVolume para tempos de inicialização mais rápidos.
  deep-flatten	Torna os clones totalmente independentes depois que eles são achatados.
  layering	Habilita a clonagem copy-on-write, necessária para a clonagem DataVolume.

• Opções do Mapa

  mapOptions: krbd:rxbounce
  

  Essa opção corrige problemas de corrupção de dados ao utilizar o driver RBD do kernel com servidores virtuais do Windows. Isso força o kernel a usar um buffer de rebote para os dados recebidos, a fim de garantir a compatibilidade. Essa opção deve ser definida em todos os StorageClasses de carga de trabalho.

• Exemplo completo de StorageClass personalizado

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  Para localizar o endereço clusterID de seu cluster, execute o seguinte comando:

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  Para pools com codificação de apagamento (apenas na pré-visualização para desenvolvedores), consulte “Noções básicas sobre proteção de dados ”, adicione dataPool, que aponta para o pool EC, e mantenha pool apontando para o pool replicado por padrão:

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

Compactação

O ODF oferece suporte à compactação em linha BlueStore nos pools de blocos do Ceph, o que pode reduzir o armazenamento bruto usado pelos discos. A compactação é aplicada de forma transparente na camada OSD; assim, a carga de trabalho da máquina virtual e seu sistema operacional convidado não percebem que os dados estão compactados.

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

Criptografia

O ODF oferece suporte à criptografia de dados em repouso em várias camadas que você pode ativar independentemente.

• IBM Cloud Criptografia de infraestrutura: Criptografia de disco completo em unidades NVMe físicas — gerenciada por IBM Cloud.
• Criptografia em todo o cluster ODF: Todos os discos OSD do Ceph são criptografados com o dm-crypt no nível do dispositivo. Habilitado por meio de encryption.clusterWide: true no CR do cluster de armazenamento. Protege contra roubo de disco físico.
• Criptografia por volume do ODF: Os volumes RBD individuais são criptografados com o LUKS2, cada um com sua própria chave de criptografia de dados. Oferece isolamento de locatários e gerenciamento granular de chaves.

Em Red Hat OpenShift Kubernetes Service, o ODF se integra ao IBM Key Protect como serviço de gerenciamento de chaves externas para criptografia em todo o cluster e por volume. Quando a criptografia por volume está ativada, o ODF cria automaticamente as variantes -encrypted StorageClass (por exemplo, ocs-storagecluster-ceph-rbd-encrypted).

Otimização de desempenho do Ceph para NVMe em bare-metal

A configuração padrão do Ceph é otimizada para cargas de trabalho gerais. Os valores dos parâmetros a seguir são validados no perfil “bare-metal” do mx2d.metal.96x768 e aumentam significativamente o IOPS, além de reduzirem a latência para cargas de trabalho de disco do VM nesse perfil. Se você estiver usando um perfil de bare-metal diferente, considere essas informações como uma referência inicial e ajuste os valores com base no número de unidades NVMe e na capacidade disponível da CPU do seu perfil específico.

Aplique cada parâmetro usando o comando ceph config set do pod “Ceph toolbox”:

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

Após a aplicação, verifique se a configuração foi aceita:

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

Não é necessário reiniciar os pods do OSD para alterações no ceph config set . O Ceph aplica a configuração dinamicamente. No entanto, as alterações no cache do BlueStore (osd_memory_target) só entram em vigor totalmente após a reciclagem de cada pod do OSD. É possível reciclar os pods OSD, um por vez, durante uma janela de manutenção, sem interromper as operações de E/S.

Referência de benchmark: Testes internos realizados em um cluster do mx2d.metal.96x768 com 3 nós, 200 VMs e IOPS ilimitadas mostraram que a combinação de 16 shards, 8 GB de memória OSD e um buffer de gravação de 256 MB RocksDB atingiu aproximadamente 194.000 IOPS e uma taxa de transferência de 758 MB/s. O aumento do número de shards de 8 para 16 produziu, de forma consistente, a maior melhoria isolada em IOPS em todas as configurações de teste.

Backup baseado em snapshot

O ODF é compatível com Kubernetes VolumeSnapshots para volumes Ceph RBD. Para tirar um instantâneo de um disco, use o seguinte comando:

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots são de cópia na gravação e de criação quase instantânea. Você pode usá-los para restaurar uma carga de trabalho de máquina virtual a um estado anterior ou clonar um disco. A virtualização do Red Hat OpenShift também oferece uma função integrada de “ VM API de instantâneos e restaurações ” que captura o estado completo da carga de trabalho da máquina virtual — incluindo a configuração e todos os discos — em uma única operação.

Cargas de trabalho de máquinas virtuais com quiescência para snapshots consistentes com aplicativos

Ao criar um snapshot de uma carga de trabalho em uma máquina virtual em execução, os dados no disco devem estar em um estado consistente. Sem quiescência, o instantâneo captura o que estiver no disco naquele instante, inclusive transações parcialmente gravadas, buffers sujos e E/S em andamento. Esse processo gera um instantâneo consistente com falha, o que pode exigir uma recuperação no nível do aplicativo durante a restauração.

Para obter instantâneos consistentes com os aplicativos, congele o sistema de arquivos do convidado antes do instantâneo e descongele-o depois. Red Hat OpenShift A virtualização automatiza esse processo por meio do agente convidado do QEMU.

O controlador de instantâneo detecta o agente convidado QEMU. Antes de criar o snapshot, ele executa o comando “ guest-fsfreeze-freeze ”, que interrompe todas as operações de E/S dos sistemas de arquivos. O snapshot “ VolumeSnapshot ” é criado enquanto o sistema de arquivos está congelado. Após a conclusão do snapshot, um comando guest-fsfreeze-thaw retoma a E/S. O status do snapshot indica o nível de consistência alcançado. Consulte a tabela a seguir para saber o significado de cada status.

Recomenda-se a instalação do agente convidado do QEMU em todas as VMs de produção. Em hosts do tipo “ Linux ”, use o comando a seguir.

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Para convidados do Windows, instale o pacote de drivers VirtIO, que inclui o serviço de agente convidado QEMU.

Ganchos personalizados de congelamento/descongelamento para aplicativos: Para bancos de dados e outros aplicativos com estado que exijam uma suspensão adicional além do congelamento do sistema de arquivos, coloque scripts de ganchos personalizados dentro da carga de trabalho da máquina virtual convidada em /etc/qemu-ga/fsfreeze-hook.d/. Esses scripts são executados automaticamente pelo agente convidado com o argumento freeze antes do congelamento do sistema de arquivos e com o argumento thaw após o descongelamento do sistema de arquivos. Os registros de execução de hooks são gravados em /var/log/qga-fsfreeze-hook.log.

Por exemplo, o seguinte PostgreSQL freeze hook pode ser colocado em /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh:

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware comparação: Este exemplo é análogo ao script de pré-congelamento e pós-descongelamento do VMware, utilizado com as Ferramentas VMware para criar instantâneos consistentes com o aplicativo. O agente convidado do QEMU desempenha a mesma função que as Ferramentas d VMware para a suspensão de instâncias (snapshot).

Alteradas as limitações do rastreamento de blocos

O Rastreamento de Blocos Alterados permite a realização de backups incrementais, identificando apenas os blocos que foram alterados desde o último backup. VMware O VADP ( vStorage APIs for Data Protection) utiliza esse mecanismo para oferecer backups incrementais eficientes.

O CBT não está disponível para ODF e Ceph RBD em Red Hat OpenShift Virtualization. Atualmente, os backups dependem de instantâneos completos, o que pode resultar em janelas de backup mais longas e maior uso de armazenamento.

O desenvolvimento do CBT está em andamento em vários níveis:

Embora o Ceph RBD ofereça suporte ao recurso subjacente “ rbd diff ” (Rastreamento de blocos alterados) para identificar blocos alterados entre instantâneos, esse recurso ainda não está disponível por meio da API CSI de rastreamento de blocos alterados do Kubernetes. Até que a pilha completa esteja implementada (API CSI CBT + suporte ao driver Ceph CSI + integração KubeVirt ), os backups incrementais no nível do bloco não estarão disponíveis.

Soluções de backup

Vários fornecedores de soluções de backup oferecem soluções para a virtualização do Red Hat OpenShift que funcionam dentro do modelo atual baseado em snapshots:

• Veeam® Kasten: Kubernetes-proteção de dados nativa com suporte à virtualização Red Hat OpenShift e recursos de snapshot incremental para ODF. Para obter mais informações, consulte a arquitetura de referência do Veeam Kasten.
• Trilio para Kubernetes: Backup e recuperação para cargas de trabalho de virtualização Red Hat OpenShift com integração ODF. Para obter mais informações, consulte o suporte à virtualização do Trilio Red Hat OpenShift.
• Veritas NetBackup: Backup corporativo com suporte à virtualização Red Hat OpenShift. Para obter mais informações, acesse NetBackup- Proteção abrangente de dados corporativos.

Recomendações para migrações para o site VMware

Se o seu ambiente VMware atual depende de backups incrementais baseados em CBT, considere as seguintes recomendações:

• Planeje backups de snapshot completo. Avalie suas janelas de backup e seus requisitos de armazenamento com base em backups completos ( VolumeSnapshots ), em vez de backups incrementais.
• Avalie as ferramentas de backup nativas do Kubernetes. O Veeam Kasten e o Trilio foram projetados para a virtualização do tipo “ Kubernetes ” e “ Red Hat OpenShift ” e operam dentro do modelo atual de snapshot.
• Use a eficiência do instantâneo do Ceph. Os snapshots do Ceph RBD funcionam com o mecanismo “copy-on-write” e utilizam espaço de armazenamento apenas para os blocos alterados após a criação do snapshot, o que torna o armazenamento contínuo dos snapshots mais eficiente do que cópias completas.

Monitorar a integridade do ODF e do Ceph

O monitoramento regular do cluster de armazenamento ODF é essencial para manter a disponibilidade e o desempenho. A seção a seguir descreve os principais comandos e seus resultados.

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

Atualização do ODF em Red Hat OpenShift Kubernetes Service

O complemento Data Foundation (ODF) do IBM Cloud Red Hat OpenShift aplica automaticamente as atualizações do z-stream dentro da mesma versão secundária. Essas atualizações são gerenciadas pelo site IBM Cloud.

No entanto, as atualizações de versão principal e secundária (por exemplo, 4.18 → 4.19 ) não são automáticas. Siga o procedimento de atualização manual para garantir a segurança dos dados e a estabilidade do cluster.

A atualização do ODF em um cluster Red Hat OpenShift Kubernetes Service consiste em duas fases principais, ambas necessárias para que a atualização seja bem-sucedida.

1. Faça upgrade ou substitua os nós de trabalho do ODF.

   • O ODF depende de nós de trabalho dedicados ou rotulados para hospedar componentes de armazenamento.
   • Durante uma atualização maior ou menor, esses nós de trabalho devem ser atualizados ou substituídos para se alinharem às versões de destino do Red Hat OpenShift e do ODF.
   • Esse processo ajuda a garantir que os pods ODF (como Ceph OSDs, MONs e gerentes) sejam reprogramados corretamente e continuem funcionando sem perda de dados.
   • Verifique se há capacidade adequada e se os nós estão em boas condições antes de iniciar esta etapa, a fim de manter a disponibilidade do armazenamento.

2. Atualize o complemento ODF.

   • Depois que os nós de trabalho forem atualizados ou substituídos, atualize o complemento ODF.
   • Esta etapa atualiza os operadores ODF, os drivers CSI e os componentes relacionados para a versão de destino.
   • Após a conclusão da atualização do add-on, o cluster reconcilia automaticamente os recursos do ODF e aplica as alterações necessárias.

   Execute a validação pós-atualização para confirmar:

   • Saúde do cluster do ODF e do Ceph
   • StorageClasses disponibilidade
   • Operações bem-sucedidas de leitura e gravação de PVC pelos aplicativos

Para obter mais informações, consulte Atualização do ODF em clusters VPC.

Ampliando o armazenamento ODF em Red Hat OpenShift Kubernetes Service

Assim, à medida que suas cargas de trabalho crescem e as demandas de armazenamento aumentam, torna-se essencial expandir sua infraestrutura de armazenamento. A expansão no ODF é uma operação essencial do Dia 2 que permite aumentar a capacidade de armazenamento, melhorar o desempenho e manter a resiliência sem interromper a execução dos aplicativos.

Em ambientes IBM Cloud Red Hat OpenShift Kubernetes Service, a expansão normalmente envolve a ampliação do pool de trabalhadores de armazenamento. Essa operação é realizada com o mínimo de tempo de inatividade, permitindo o crescimento contínuo de seu cluster de armazenamento.

1. Adicione nós de trabalho ao seu cluster VPC. Para clusters com várias zonas, nos quais o cluster de armazenamento abrange três zonas de disponibilidade, adicione nós de trabalho em múltiplos de 3 para manter o equilíbrio entre as zonas (por exemplo, 3, 6 ou 9). Para clusters de zona única com escalonamento flexível ativado, é possível adicionar nós um por vez.

2. Depois que os nós forem adicionados, registre-os no ODF. Se o ODF estiver em execução em todos os nós de trabalho do seu cluster, novos nós serão adicionados à topologia de armazenamento automaticamente. Se o ODF estiver em execução apenas em um subconjunto de nós de trabalho, passe para a próxima etapa.

3. Se o ODF for executado em todos os nós de trabalho em seu cluster, novos nós de trabalho serão adicionados automaticamente à topologia do cluster de armazenamento do ODF. Se o ODF for executado apenas em um subconjunto de nós de trabalho, especifique os parâmetros privados <workerNodes> no seu recurso personalizado OcsCluster. Adicione os nomes dos novos nós de trabalho à sua implantação de ODF editando a definição de recurso personalizado. Modifique o recurso personalizado OcsCluster da seguinte forma:

   • Encontre o ocscluster

     oc get ocscluster
     

   • Edite o arquivo de recursos personalizados do ocscluster e adicione novos nós de trabalho

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • Salve o arquivo de recurso personalizado OcsCluster para reaplicá-lo ao seu cluster.

4. Aumente o valor de 'numOfOsd' no seu recurso personalizado OcsCluster para permitir que o OCS implante componentes ODF em nós de trabalho recém-adicionados e provisionar OSDs adicionais no cluster de armazenamento.

   O ajuste do parâmetro “ 'numOfOsd' ” depende tanto do número de discos OSD por nó quanto do número de nós adicionados. Por exemplo, se cada nó tiver 8 discos NVMe dedicados aos OSDs, adicionar 3 nós aumenta o número de “ 'numOfOsd' ” em 8, enquanto adicionar 6 nós aumenta esse número em 16.

5. Verifique o resultado executando o seguinte comando:

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. Verifique se os novos nós de trabalho foram adicionados e distribuídos uniformemente por cada zona (para clusters com várias zonas) ou se aparecem como grupos de hosts individuais (para clusters de escalonamento flexível com uma única zona), juntamente com o número correspondente de OSDs atribuídos a cada nó.

Para obter mais informações, consulte “Expandindo o ODF adicionando nós de trabalho ao seu cluster VPC ”.

Ajuste de escala flexível

O complemento ODF do IBM Cloud utiliza diferentes topologias de domínios de falha, dependendo da configuração do seu cluster:

• Clusters multizona (3 zonas de disponibilidade): O domínio de falha está definido como zone. Os OSDs são provisionados em múltiplos de 3, um conjunto por zona, para manter a replicação de dados e a alta disponibilidade entre as zonas. O cluster de armazenamento deve crescer em múltiplos de 3 para manter o equilíbrio entre as zonas.
• Clusters de zona única ou clusters com menos de 3 zonas de disponibilidade: o dimensionamento flexível é ativado automaticamente. O domínio de falha está definido como host, o que significa que cada nó individual constitui um domínio de falha distinto. É possível adicionar um nó por vez e dimensionar o armazenamento de forma granular.

A partir do ODF 4.21, o comportamento de escalonamento flexível é determinado automaticamente na implantação inicial com base na topologia do cluster e não pode ser alterado posteriormente.

Em uma implantação de zona única ou com escalonamento flexível, um pool de servidores de armazenamento de dados ( replica-3 ) resiste à perda de qualquer host individual. Em uma implantação com várias zonas, um pool de “ replica-3 ” resiste à perda de uma zona inteira. Avalie se a topologia do seu cluster e a tolerância a falhas associada atendem aos seus requisitos de resiliência antes de implantar o ODF em produção.

Para obter o conjunto completo de parâmetros complementares e as etapas de instalação por meio do console, consulte “Implantação do OpenShift Data Foundation em clusters VPC ”.

Desempenho durante a expansão de nós: a adição de um nó a um cluster ODF com escalabilidade flexível aciona o rebalanceamento de dados do Ceph. No teste interno descrito a seguir, o IOPS e a taxa de transferência permaneceram estáveis, enquanto a latência de gravação aumentou temporariamente. Em testes internos realizados em um cluster de 3 nós com 100 VMs a 50.000 IOPS, foram observados os seguintes resultados:

A latência de gravação volta ao nível normal após a conclusão do rebalanceamento. Planeje a adição de nós durante períodos de menor atividade do serviço “ VM ” se suas cargas de trabalho forem sensíveis a picos de latência de gravação.