Configuração do Armazenamento
Conceitos de armazenamento do Kubernetes
O Kubernetes fornece uma camada de abstração de infraestrutura sobre a pilha de tecnologia de virtualização subjacente (opcional) e hardware. A maneira como o Kubernetes abstrai o armazenamento é por meio das classes de armazenamento. Ao provisionar um pod, você pode especificar uma classe de armazenamento para cada volume. No momento em que o pod é provisionado, o provisionador de classe de armazenamento é chamado para provisionar o armazenamento e, em seguida, um volume persistente é criado nesse armazenamento provisionado e, em seguida, o pod é montado no volume persistente por uma declaração de volume persistente.
O Kubernetes fornece uma maneira para os provedores de infraestrutura de armazenamento conectarem drivers (também chamados de "Addons") que estendem o Kubernetes. Os complementos de armazenamento devem estar em conformidade com o padrão Container Storage Interface. Existem dezenas de addons que podem ser encontrados nesta lista não definitiva de drivers CSI. O driver CSI específico que você usa depende de fatores como se você está executando em um serviço Kubernetes gerenciado hospedado na nuvem ou qual provedor OEM você usa para seu 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 Serviço Kubernetes do Azure (AKS):
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 atualmente provisionados e as declarações de volume persistente 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 demonstração de declarações de volume 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 sua configuração de armazenamento
Selecionar a classe de armazenamento certa é importante para a resiliência e o desempenho dos dados. Escolher a classe de armazenamento errada pode colocar seus dados em risco de perda total de dados no caso de uma falha de hardware ou pode resultar em um desempenho menos ideal.
Geralmente, existem 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 um projeto específico para redundância de dados replicando os dados em vários nós.
- Armazenamento remoto e compartilhado - armazenamento provisionado em algum dispositivo de armazenamento remoto - por exemplo, uma SAN, NAS ou serviço de armazenamento em nuvem, como EBS ou Arquivos do Azure. Esse tipo de armazenamento geralmente fornece redundância de dados automaticamente, 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 as supplementalGroups configurações do pod para instâncias de banco de dados e 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). Consulte o administrador do NFS para determinar se esse é o caso.
A supplementalGroups propriedade 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âncias de banco de dados que criar.
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 for data services dependem de serem configurados para usar armazenamento remoto e compartilhado porque os serviços não têm a capacidade de replicar os dados. Estes serviços encontram-se na recolha de pods do controlador de dados:
| Serviço | Reclamações de volume persistentes |
|---|---|
| Pesquisa aberta | <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0 |
| InfluxDB | <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0 |
| Instância 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 passando a --storage-class | -sc parâmetro para o az arcdata dc create comando 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 conectado diretamente, o modelo de implantação escolhido terá a classe de armazenamento predefinida no modelo ou poderá selecionar um modelo que não tenha 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 imediatamente têm uma classe de armazenamento padrão especificada que é apropriada para o ambiente de destino, mas pode ser substituída durante a implantação. Consulte as etapas detalhadas para criar modelos de configuração personalizados para alterar a configuração da classe de armazenamento para os pods do controlador de dados no momento da implantação.
Se você definir a classe de armazenamento usando o --storage-class parâmetro or -sc, essa classe de armazenamento será usada para as classes de armazenamento de log e de dados. Se você definir as classes de armazenamento no arquivo de modelo de implantação, poderá especificar diferentes classes de armazenamento para logs e dados.
Fatores importantes a serem considerados ao escolher uma classe de armazenamento para os pods do controlador de dados:
- Você deve usar uma classe de armazenamento remoto e compartilhado para garantir a durabilidade dos dados e para que, se um pod ou nó morrer, quando o pod for trazido de volta, ele possa se conectar novamente ao volume persistente.
- Os dados que estão sendo gravados na instância SQL do controlador, no banco de dados de métricas e no banco de dados de logs geralmente são de volume bastante baixo e não sensíveis à latência, portanto, o armazenamento de desempenho ultrarrápido não é crítico. Se você tiver usuários que usam frequentemente as interfaces Grafana e Kibana e tiver um grande número de instâncias de banco de dados, seus usuários poderão se beneficiar de um armazenamento de desempenho mais rápido.
- A capacidade de armazenamento necessária é variável com o número de instâncias de banco de dados que você implantou, pois os logs e métricas são coletados para cada instância de banco de dados. Os dados são retidos no banco de dados de logs e métricas por duas (2) semanas antes de serem limpos.
- Alterar a classe de armazenamento após a implantação é difícil, não está documentado e não tem suporte. Certifique-se de escolher a classe de armazenamento corretamente no momento da implantação.
Nota
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 do Kubernetes. Você pode alterar a classe de armazenamento padrão.
Configuração de armazenamento de instância de banco de dados
Cada instância de banco de dados tem dados, logs e volumes persistentes de backup. As classes de armazenamento para esses 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.
Quando você cria uma instância usando um ou az sql mi-arc createaz postgres server-arc create, há quatro parâmetros que você pode usar para definir as classes de armazenamento:
| Nome do parâmetro, nome abreviado | Utilizado 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 para o 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 para o 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 para o 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 ReadWriteMany (RWX) 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 point-in-time pode não funcionar como desejado.
A tabela abaixo lista os caminhos dentro do contêiner da Instância Gerenciada SQL do Azure que é mapeado para o volume persistente de dados e logs:
| Nome do parâmetro, nome abreviado | Caminho dentro mssql-miaa do contêiner |
Description |
|---|---|---|
--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 registro de processos dentro do contêiner |
A tabela abaixo lista os caminhos dentro do contêiner de instância do PostgreSQL que é mapeado para o volume persistente de dados e logs:
| Nome do parâmetro, nome abreviado | Caminho dentro do contêiner postgres | Description |
|---|---|---|
--storage-class-data, -d |
/var/opt/postgresql | Contém dados e diretórios 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 registro de processos dentro do contêiner |
Cada instância de banco de dados tem um volume persistente separado para arquivos de dados, logs e backups. Isso significa que há separação da E/S para cada um desses tipos de arquivos, dependendo de como o provisionador de volume provisiona o armazenamento. Cada instância de banco de dados tem suas próprias declarações de volume persistente e volumes persistentes.
Se houver vários bancos de dados em uma determinada instância de 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 - tanto os backups de log diferenciais quanto os backups completos usam a mesma declaração de volume persistente e o mesmo volume persistente. As declarações de volume persistente para os pods de instância de banco de dados são mostradas abaixo:
| Instância | Reclamações de volume persistentes |
|---|---|
| Instância Gerida do SQL no Azure | <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0 |
| Banco de dados do Azure para instância PostgreSQL | <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0 |
| Azure PostgreSQL | <namespace>/logs-<instance name>-<ordinal>, <namespace>/data-<instance name>-0 |
Fatores importantes a serem considerados ao escolher uma classe de armazenamento para os pods de instância de banco 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 ReadWriteMany (RWX) para backups. Saiba mais sobre os modos de acesso. Se nenhuma classe de armazenamento for especificada para backups, a classe de armazenamento padrão no kubernetes será usada e, se isso não for compatível com RWX, uma implantação de instância gerenciada SQL do Azure pode não ter êxito.
- 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 SQL do Azure da camada de preços de uso geral. Um exemplo de um padrão de vários pods é uma camada de preços Crítica para Negócios altamente disponível Instância gerenciada SQL do Azure. As instâncias de banco de dados implantadas com o padrão de pod único devem usar uma classe de armazenamento remoto e compartilhado para garantir a durabilidade dos dados e para que, se um pod ou nó morrer, quando o pod for trazido de volta, ele possa se conectar novamente ao volume persistente. Por outro lado, uma instância gerenciada 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, há sempre várias cópias dos dados - normalmente três cópias. Por isso, é possível usar armazenamento local ou classes de armazenamento remoto e compartilhado para dados e arquivos de log. Se utilizar armazenamento local, os dados ainda serão preservados mesmo no caso de um pod, nó ou hardware de armazenamento com falha, porque há várias cópias dos dados. Dada essa flexibilidade, você pode optar por usar o armazenamento local para obter um melhor desempenho.
- O desempenho do banco de dados é em grande parte uma função da taxa de transferência de E/S de um determinado dispositivo de armazenamento. Se o banco de dados for pesado em leituras ou em gravações, 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ê pode escolher armazenamento local com RAID 0. Se o banco de dados for usado principalmente para leituras de uma pequena quantidade de "dados quentes", mas houver um grande volume geral de armazenamento de dados frios, você poderá escolher um dispositivo SAN capaz de armazenamento hierárquico. Escolher a classe de armazenamento certa não é 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 para dados, logs e backups estejam cada um chegando em diferentes dispositivos de armazenamento subjacentes para evitar contenção na E/S de disco. O sistema operacional também deve estar em um volume montado em um disco separado. Esta é 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 colocalizar instâncias de banco de dados ocupadas na mesma instância de banco de dados. Se possível, separe os bancos de dados ocupados em suas próprias instâncias de banco de dados para evitar a contenção de E/S. Além disso, use a segmentação por rótulo de nó para colocar instâncias de banco de dados em nós separados, de modo a distribuir o tráfego geral de E/S entre vários nós. Se você estiver usando virtualização, considere distribuir o tráfego de E/S não apenas no nível do nó, mas também a atividade de E/S combinada que está acontecendo por todas as VMs de nó em um determinado host físico.
Estimativa dos requisitos de armazenamento
Cada pod que contém dados com monitoração de estado usa pelo menos dois volumes persistentes - um volume persistente para dados e outro volume persistente para logs. A tabela abaixo lista o número de volumes persistentes necessários para um único Controlador de Dados, instância SQL Managed do Azure, Banco de Dados do Azure para instância PostgreSQL e instância HyperScale do Azure PostgreSQL:
| Tipo de Recurso | Número de pods com estado | Número necessário de volumes persistentes |
|---|---|---|
| Controlador de Dados | 4 (control, , controldblogsdb, metricsdb) |
4 * 2 = 8 |
| Instância Gerida do Azure SQL | 1 | 2 |
| Azure PostgreSQL | 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 | 5 | 4 * 2 = 8 |
| Instância Gerida do Azure SQL | 5 | 5 * 2 = 10 |
| Azure PostgreSQL | 5 | 5 * 2 = 10 |
| Número total de volumes persistentes | 8 + 10 + 10 = 28 |
Esse cálculo pode ser usado para planejar o armazenamento do cluster Kubernetes com base no provisionador de armazenamento ou no ambiente. Por exemplo, se o provisionador de armazenamento local for usado para um cluster Kubernetes com cinco (5) nós, a implantação de exemplo acima de cada nó exigirá pelo menos armazenamento para 10 volumes persistentes. Da mesma forma, ao provisionar um cluster do Serviço Kubernetes do Azure (AKS) com cinco (5) nós, escolher um tamanho de VM apropriado para o pool de nós, de modo que 10 discos de dados possam ser anexados, é fundamental. Mais detalhes sobre como dimensionar os nós para necessidades de armazenamento para nós AKS podem ser encontrados aqui.
Escolhendo a classe de armazenamento certa
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 avaliam a compatibilidade de recursos, os resultados dos testes de esforço e 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 CSI usado e as classes de armazenamento usadas. Isso ajuda os clientes a escolher a melhor classe de armazenamento, sistema operacional, distribuição Kubernetes e hardware para suas necessidades. Mais informações sobre este programa e resultados de testes podem ser encontradas aqui.
Nuvem pública, serviços Kubernetes gerenciados
Para serviços Kubernetes gerenciados baseados em nuvem pública, podemos fazer as seguintes recomendações:
| Serviço de nuvem pública | Recomendação |
|---|---|
| Azure Kubernetes Service (AKS) | O Serviço Kubernetes do Azure (AKS) tem dois tipos de armazenamento - Arquivos do Azure e Discos Gerenciados do Azure. Cada tipo de armazenamento tem dois níveis de preço/desempenho - standard (HDD) e premium (SSD). Assim, as quatro classes de armazenamento fornecidas no AKS são azurefile (camada padrão do Azure Files), (camada premium do Azure Files), azurefile-premiumdefault (camada padrão do Azure Disks) e managed-premium (camada premium do Azure Disks). A classe de armazenamento padrão é default (camada padrão do Azure Disks). Há diferenças substanciais de preços entre os tipos e níveis que você deve considerar. Para cargas de trabalho de produção com requisitos de alto desempenho, recomendamos o uso managed-premium para todas as classes de armazenamento. Para cargas de trabalho de desenvolvimento/teste, provas de conceito, etc., onde o custo é uma consideração, então azurefile é a opção menos dispendiosa. Todas as quatro opções podem ser usadas para situações que exigem armazenamento remoto e compartilhado, pois são todos dispositivos de armazenamento conectados à rede no Azure. Leia mais sobre o AKS Storage. |
| Serviço AWS Elastic Kubernetes (EKS) | O Elastic Kubernetes Service da Amazon tem uma classe de armazenamento principal - baseada no driver de armazenamento EBS CSI. Isso é recomendado para cargas de trabalho de produção. Há um novo driver de armazenamento - driver de armazenamento EFS CSI - que pode ser adicionado a um cluster EKS, mas está atualmente em um estágio beta e sujeito a alterações. Embora a AWS diga que esse driver de armazenamento é compatível com a produção, não recomendamos usá-lo porque ele ainda está em versão beta e sujeito a alterações. A classe de armazenamento do EBS é o padrão e é chamada gp2de . Leia mais sobre o EKS Storage. |
| Motor Kubernetes do Google (GKE) | O Google Kubernetes Engine (GKE) tem apenas uma classe de armazenamento chamada standard. Esta classe é usada para discos persistentes GCE. Sendo o único, é também o padrão. Embora exista um provisionador de volume estático local para o GKE que você pode usar com SSDs de conexão direta, não recomendamos usá-lo, pois ele não é mantido ou suportado pelo Google. Leia mais sobre o armazenamento GKE. |