Configuração de armazenamento

Conceitos de armazenamento do Kubernetes

O Kubernetes fornece uma camada de abstração de infraestrutura sobre a pilha técnica de virtualização subjacente (opcional) e o hardware. A maneira como o Kubernetes abstrai o armazenamento é por meio de Classes de armazenamento. Quando você provisiona um pod, pode especificar uma classe de armazenamento para cada volume. No momento em que o pod é provisionado, o provisionamento de classe de armazenamento é chamado para provisionar o armazenamento e, em seguida, um volume persistente é criado no armazenamento provisionado e então o pod é montado no volume persistente por uma declaração de volume persistente.

O Kubernetes oferece uma maneira de os provedores de infraestrutura de armazenamento conectarem drivers (também chamados de "Complementos") que estendam o Kubernetes. Os complementos de armazenamento devem estar em conformidade com o Padrão de Interface de Armazenamento de Contêiner. Existem dezenas de complementos que podem ser encontrados nessa lista não definitiva de drivers do CSI. O driver CSI específico que você depende de fatores como, por exemplo, se você estiver executando em um serviço de Kubernetes gerenciado hospedado na nuvem ou qual provedor OEM usa para o hardware.

Para exibir as classes de armazenamento configuradas no cluster do Kubernetes, execute este comando:

kubectl get storageclass

Exemplo de saída de um cluster do AKS (Serviço de Kubernetes do Azure):

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

Você pode obter detalhes sobre uma classe de armazenamento executando este comando:

kubectl describe storageclass/<storage class name>

Exemplo:

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

Você pode ver os volumes persistentes provisionados no momento e as declarações de volume persistentes executando os seguintes comandos:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Exemplo de exibição de volumes persistentes:

kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Exemplo de exibição de declarações de volumes persistentes:

kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Fatores a considerar ao escolher a configuração de armazenamento

A seleção da classe de armazenamento ideal é importante para a resiliência e o desempenho dos dados. Escolher a classe de armazenamento incorreta pode colocar seus dados em risco de perda total de dados no caso de uma falha de hardware ou pode resultar em um desempenho menor do que o ideal.

Em geral, há dois tipos de armazenamento:

• Armazenamento local – armazenamento provisionado em discos rígidos locais em um determinado nó. Esse tipo de armazenamento pode ser ideal em termos de desempenho, mas requer design específico para redundância de dados, replicando os dados entre vários nós.
• Armazenamento remoto e compartilhado – armazenamento provisionado em algum dispositivo de armazenamento remoto, por exemplo, um serviço de armazenamento em nuvem, SAN ou NAS, como o EBS ou Arquivos do Azure. Esse tipo de armazenamento em geral fornece automaticamente a redundância de dados, mas não é tão rápido quanto o armazenamento local pode ser.

Classes de armazenamento baseadas em NFS

Dependendo da configuração do servidor NFS e do provisionador de classe de armazenamento, talvez seja necessário definir os supplementalGroups nas configurações de pod para instâncias de banco de dados. Além disso, talvez seja necessário alterar a configuração do servidor NFS para usar as IDs de grupo passadas pelo cliente (em vez de procurar IDs de grupo no servidor usando a ID de usuário passada). Confira o administrador do NFS para determinar se esse é o caso.

A propriedade supplementalGroups usa uma matriz de valores que você pode definir na implantação. O controlador de dados do Azure Arc aplica-os a todas as instância do banco de dados que ele cria.

Para definir essa propriedade, execute o seguinte comando:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Configuração de armazenamento do controlador de dados

Alguns serviços no Azure Arc para serviços de dados dependem de serem configurados para usar o armazenamento remoto compartilhado, pois os serviços não têm a capacidade de replicar os dados. Esses serviços são encontrados na coleção de pods do controlador de dados:

No momento em que o controlador de dados é provisionado, a classe de armazenamento a ser usada para cada um desses volumes persistentes é especificada pela passagem da --classe-armazenamento | -parâmetro SC para o comando az arcdata dc create ou definindo as classes de armazenamento no arquivo de modelo de implantação control.json que é usado. Se você estiver usando o portal do Azure para criar o controlador de dados no modo de conexão direta, o modelo de implantação escolhido terá a classe de armazenamento predefinida no modelo ou será possível selecionar um modelo que não tem uma classe de armazenamento predefinida. Se o modelo não definir uma classe de armazenamento, o portal solicitará uma. Se você usar um modelo de implantação personalizado, poderá especificar a classe de armazenamento.

Os modelos de implantação fornecidos prontos para uso têm uma classe de armazenamento padrão especificada apropriada para o ambiente de destino, mas ela pode ser substituída durante a implantação. Consulte as etapas detalhadas para criar modelos de configuração personalizada para alterar a configuração da classe de armazenamento para o pods do controlador de dados no momento da implantação.

Se você definir a classe de armazenamento usando o parâmetro --storage-class ou -sc, essa classe de armazenamento será usada para as classes de armazenamento de dados e de log. Se você definir as classes de armazenamento no arquivo de modelo de implantação, poderá especificar classes de armazenamento diferentes para logs e dados.

Fatores importantes a serem considerados ao escolher uma classe de armazenamento para o pods do controlador de dados:

• Você deve usar uma classe de armazenamento compartilhada remota para garantir a durabilidade dos dados e, portanto, se um pod ou nó se tornar inativo quando o pod for colocado em backup, ele poderá se conectar novamente ao volume persistente.
• Os dados que estão sendo gravados na instância do SQL do controlador, no banco de dados de métricas e no BD de logs normalmente são um volume bem baixo e não são sensíveis à latência, portanto, o armazenamento de desempenho extremamente rápido não é crítico. Se você tiver usuários usando com frequência as interfaces Grafana e Kibana e tiver um grande número de instâncias de banco de dados, os usuários poderão se beneficiar do armazenamento mais rápido.
• A capacidade de armazenamento necessária varia de acordo com o número de instâncias de banco de dados que você implantou, já que os logs e as métricas são coletados para cada instância do banco de dados. Os dados são retidos no BD de logs e métricas por 2 (duas) semanas antes de serem limpos.
• A alteração da classe de armazenamento após a implantação é difícil, não documentada e não tem suporte. Verifique se escolheu a classe de armazenamento corretamente no momento da implantação.

Configuração de armazenamento da instância do banco de dados

Cada instância de banco de dados tem os volumes persistentes de dados, logs e backup. As classes de armazenamento desses volumes persistentes podem ser especificadas no momento da implantação. Se nenhuma classe de armazenamento for especificada, a classe de armazenamento padrão será usada.

Ao criar uma instância usando az sql mi-arc create ou az postgres server-arc create, há quatro parâmetros que podem ser usados para definir as classes de armazenamento:

A tabela a seguir lista os caminhos dentro do contêiner da Instância Gerenciada de SQL do Azure que é mapeado para o volume persistente para dados e logs:

A tabela a seguir lista os caminhos dentro do contêiner da Instância PostgreSQL do Azure que é mapeado para o volume persistente para dados e logs:

Cada instância do banco de dados tem um volume persistente separado para arquivos de dados, logs e backups. Isso significa que há separação de E/S para cada desses tipos de arquivos, sujeito a como o provisionador de volume provisiona o armazenamento. Cada instância de banco de dados tem suas próprias declarações de volume persistentes e volumes persistentes.

Se houver vários bancos de dados em uma determinada instância do banco de dados, todos os bancos de dados usarão a mesma declaração de volume persistente, volume persistente e classe de armazenamento. Todos os backups, backups de log diferenciais e backups completos, usam a mesma declaração de volume persistente e volume persistente. As declarações de volume persistente para os pods da instância do banco de dados são mostradas abaixo:

Fatores importantes a serem considerados ao escolher uma classe de armazenamento para o pods de instância de dados:

• A partir da versão de fevereiro de 2022 dos serviços de dados do Azure Arc, você precisa especificar uma classe de armazenamento compatível com RWX (ReadWriteMany) para backups. Saiba mais sobre os modos de acesso. Se nenhuma classe de armazenamento for especificada para backups, a classe de armazenamento padrão do Kubernetes será usada e, se ela não for compatível com o RWX, uma implantação de Instância Gerenciada do SQL do Azure poderá não funcionar.
• As instâncias de banco de dados podem ser implantadas em um padrão de pod único ou em um padrão de pod múltiplo. Um exemplo de um padrão de pod único é uma instância gerenciada do SQL do Azure do tipo de preço de Uso Geral. Um exemplo de um padrão de pods múltiplos é uma instância gerenciada do SQL do Azure do tipo de preço Comercialmente Crítico altamente disponível. As instâncias do banco de dados implantadas com o padrão de pod único devem usar uma classe de armazenamento compartilhada e remota para garantir a durabilidade dos dados e, portanto, se um pod ou nó se tornar inativo quando o pod for colocado em backup, ele poderá se conectar novamente ao volume persistente. Por outro lado, uma instância gerenciada do SQL do Azure altamente disponível usa grupos de disponibilidade Always On para replicar os dados de uma instância para outra de forma síncrona ou assíncrona. Especialmente no caso em que os dados são replicados de forma síncrona, sempre existem várias cópias dos dados – geralmente três cópias. Por isso, é possível usar o armazenamento local ou as classes de armazenamento compartilhadas remotas para arquivos de dados e de log. Se estiver utilizando armazenamento local, os dados ainda serão preservados mesmo no caso de um pod, nó ou hardware de armazenamento com falha, pois há várias cópias dos dados. Devido a essa flexibilidade, você pode optar por usar o armazenamento local para melhorar o desempenho.
• O desempenho do banco de dados é basicamente uma função da taxa de transferência de E/S de um determinado dispositivo de armazenamento. Se o banco de dados for usado para muita leitura ou gravação, você deverá escolher uma classe de armazenamento com hardware projetado para esse tipo de carga de trabalho. Por exemplo, se o banco de dados for usado principalmente para gravações, você poderá escolher o armazenamento local com RAID 0. Se o seu banco de dados for usado principalmente para leituras de uma pequena quantidade de “dados de acesso frequente”, mas houver um grande volume de armazenamento geral de dados frios, você poderá escolher um dispositivo SAN capaz de armazenar em camadas. Escolher a classe de armazenamento correta não é muito diferente de escolher o tipo de armazenamento que você usaria para qualquer banco de dados.
• Se você estiver usando um provisionador de volume de armazenamento local, certifique-se de que os volumes locais provisionados de dados, logs e backups estão chegando em dispositivos de armazenamento subjacentes diferentes para evitar contenção na E/S do disco. O sistema operacional também deve estar em um volume montado em discos(s) separados. Essa é essencialmente a mesma orientação que seria seguida para uma instância de banco de dados em hardware físico.
• Como todos os bancos de dados em uma determinada instância compartilham uma declaração de volume persistente e um volume persistente, certifique-se de não colocar as instâncias de banco de dados ocupadas na mesma instância de banco de dados. Se possível, separe bancos de dados ocupados em suas próprias instâncias de banco de dados para evitar contenção de E/S. Além disso, use o direcionamento de rótulo de nó para dividir instâncias de banco de dados em nós separados para distribuir o tráfego de E/S geral entre vários nós. Se você estiver usando a virtualização, não deixe de considerar a distribuição do tráfego de E/S não apenas no nível do nó, mas também a atividade combinada de E/S ocorrendo por todas as VMs de nó em um determinado host físico.

Estimando os requisitos de armazenamento

Cada pod que contém dados com estado usa pelo menos dois volumes persistentes – um volume persistente para dados e outro volume persistente para logs. A tabela a seguir lista o número de volumes persistentes necessários para um único controlador de dados, Instância Gerenciada do SQL do Azure, instância do Banco de Dados do Azure para PostgreSQL e instância do Azure PostgreSQL HyperScale:

A tabela abaixo mostra o número total de volumes persistentes necessários para uma implantação de exemplo:

Esse cálculo pode ser usado para planejar o armazenamento de seu cluster de Kubernetes com base no provisionamento ou no ambiente de armazenamento. Por exemplo, se o provisionamento de armazenamento local for usado para um cluster de Kubernetes com cinco nós (5), então para a implantação de exemplo acima, cada nó exigirá pelo menos o armazenamento para 10 volumes persistentes. Da mesma forma, ao provisionar um cluster do AKS (Serviço de Kubernetes do Azure) com cinco nós (5), é essencial escolher um tamanho de VM apropriado para o pool de nós, de modo que 10 discos de dados possam ser anexados é crítico. Mais detalhes sobre como dimensionar os nós para as necessidades de armazenamento para nós AKS podem ser encontrados aqui.

Escolhendo a classe de armazenamento correta

Sites locais e de borda

A Microsoft e seus parceiros OEM, SO e Kubernetes têm um programa de validação para os serviços de dados do Azure Arc. Este programa fornece resultados de teste comparáveis de um kit de ferramentas de teste de certificação. Os testes avaliarão a compatibilidade de recursos, os resultados de testes de estresse, o desempenho e a escalabilidade. Os resultados do teste indicam o sistema operacional usado, a distribuição do Kubernetes usada, o HW usado, o complemento da CSI usado e as classes de armazenamento usadas. Isso ajuda os clientes a escolher a melhor classe de armazenamento, o sistema operacional, a distribuição do Kubernetes e o hardware para seus requisitos. Mais informações sobre esse programa e sobre os resultados de testes podem ser encontradas aqui.

Nuvem pública, serviços Kubernetes gerenciados

Para serviços de Kubernetes gerenciados baseados em nuvem pública, podemos fazer as seguintes recomendações: