Configuração de armazenamento

Artigo
10/16/2024

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:

Serviço	Declarações de Volume Persistente
OpenSearch	`<namespace>/logs-logsdb-0`, `<namespace>/data-logsdb-0`
InfluxDB	`<namespace>/logs-metricsdb-0`, `<namespace>/data-metricsdb-0`
Instância do SQL do Controlador	`<namespace>/logs-controldb`, `<namespace>/data-controldb`
Serviço de API do Controlador	`<namespace>/data-controller`

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.

Observação

Se nenhuma classe de armazenamento for especificada, a classe de armazenamento padrão será usada. Pode haver apenas uma classe de armazenamento padrão por cluster Kubernetes. Você pode alterar a classe de armazenamento padrã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:

Nome do parâmetro, nome curto	Usado para
`--storage-class-data`, `-d`	Classe de armazenamento para todos os arquivos de dados (.mdf, ndf). Se não for especificado, o padrão será a classe de armazenamento do controlador de dados.
`--storage-class-logs`, `-g`	Classe de armazenamento para todos os arquivos de log. Se não for especificado, o padrão será a classe de armazenamento do controlador de dados.
`--storage-class-data-logs`	Classe de armazenamento para os arquivos de log de transações do banco de dados. Se não for especificado, o padrão será a classe de armazenamento do controlador de dados.
`--storage-class-backups`	Classe de armazenamento para todos os arquivos de backup. Se não for especificado, o padrão será a classe de armazenamento para dados (`--storage-class-data`). Use uma classe de armazenamento compatível com RWX (ReadWriteMany) para backups. Saiba mais sobre os modos de acesso.

Aviso

Se você não especificar uma classe de armazenamento para backups, a implantação usará a classe de armazenamento especificada para dados. Se essa classe de armazenamento não for compatível com RWX, a restauração pontual poderá não funcionar conforme desejado.

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:

Nome do parâmetro, nome curto	Caminho dentro do contêiner `mssql-miaa`	Descrição
`--storage-class-data`, `-d`	/var/opt	Contém diretórios para a instalação do mssql e outros processos do sistema. O diretório mssql contém dados padrão (incluindo logs de transações), log de erros e diretórios de backup
`--storage-class-logs`, `-g`	/var/log	Contém diretórios que armazenam a saída do console (stderr, stdout), outras informações de log de processos dentro do contêiner

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:

Nome do parâmetro, nome curto	Caminho dentro do contêiner postgres	Descrição
`--storage-class-data`, `-d`	/var/opt/postgresql	Contém diretórios de dados e de log para a instalação do postgres
`--storage-class-logs`, `-g`	/var/log	Contém diretórios que armazenam a saída do console (stderr, stdout), outras informações de log de processos dentro do contêiner

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:

Instância	Declarações de Volume Persistente
Instância Gerenciada do SQL do Azure	`<namespace>/logs-<instance name>-0`, `<namespace>/data-<instance name>-0`
Instância do Banco de Dados do Azure para PostgreSQL	`<namespace>/logs--<instance name>-0`, `<namespace>/data--<instance name>-0`
PostgreSQL do Azure	`<namespace>/logs-<instance name>-<ordinal>`, `<namespace>/data-<instance name>-0`

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:

Tipo de recurso	Número de pods com estado	Número necessário de volumes persistentes
Controlador de Dados	4 (`control`, `controldb`, `logsdb`, `metricsdb`)	4 * 2 = 8
Instância Gerenciada de SQL do Azure	1	2
PostgreSQL do Azure	1	2

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

Tipo de recurso	Número de instâncias	Número necessário de volumes persistentes
Controlador de Dados	1	4 * 2 = 8
Instância Gerenciada de SQL do Azure	5	5 * 2 = 10
PostgreSQL do Azure	5	5 * 2 = 10
Número total de volumes persistentes		8 + 10 + 10 = 28

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:

Serviço de nuvem pública	Recomendação
AKS (Serviço de Kubernetes do Azure)	O AKS (Serviço Kubernetes do Azure) tem dois tipos de armazenamento, o de Arquivos do Azure e o Managed Disks do Azure. Cada tipo de armazenamento tem dois níveis de preço/desempenho, o padrão (HDD) e Premium (SSD). Portanto, as quatro classes de armazenamento fornecidas no AKS são `azurefile` (camada padrão de Arquivos do Azure), `azurefile-premium` (camada Premium de Arquivos do Azure), `default` (camada padrão do Disk do Azure) e `managed-premium` (camada Premium do Disk do Azure). A classe de armazenamento padrão é a `default` (camada padrão de Disk do Azure). Existem grandes diferenças de preço entre os tipos e as camadas que você deve considerar. Para cargas de trabalho de produção com requisitos de alto desempenho, é recomendável usar `managed-premium` para todas as classes de armazenamento. Para cargas de trabalho de desenvolvimento/teste, provas de conceito etc., `azurefile` é a opção menos cara, quando o custo considerado. Todas as quatro opções podem ser usadas para situações que exigem armazenamento remoto e compartilhado, pois são todos os dispositivos de armazenamento conectados à rede no Azure. Leia mais sobre o Armazenamento do AKS.
AWS Elastic Kubernetes Service (EKS)	O serviço elástico Kubernetes da Amazon tem uma classe de armazenamento principal baseada no Driver de armazenamento do EBS da CSI. Ele é recomendado para cargas de trabalho de produção. Há um novo driver de armazenamento – Driver de armazenamento do EFS da CSI – que pode ser adicionado a um cluster de EKS, mas ele está em um estágio Beta e está sujeito a alterações. Embora o AWS informe que esse driver de armazenamento tem suporte para produção, não é recomendável usá-lo porque ele ainda está na versão beta e está sujeito a alterações. A classe de armazenamento EBS é o padrão e é chamada `gp2`. Leia mais sobre o Armazenamento do EKS.
Google Kubernetes Engine (GKE)	O GKE (Google Kubernetes Engine) tem apenas uma classe de armazenamento chamada `standard`. Essa classe é usada para discos persistentes de GCE. Por ser o único, ele também é o padrão. Embora exista um provisionamento de volume estático e local para o GKE que você pode usar com os SSDs com anexados diretamente, não é recomendável usá-lo, pois ele não tem suporte e nem é mantido pelo Google. Leia mais sobre o Armazenamento do GKE.

Compartilhar via