Disciplinas de armazenamento para o Instância Gerenciada de SQL habilitado para Azure Arc

O armazenamento é um componente crítico em uma implantação de Instância Gerenciada de SQL habilitada para Azure Arc (Instância Gerenciada de SQL habilitada para Arc). Entender como os conceitos relacionados ao armazenamento descritos neste documento afetam o funcionamento dos clusters do Kubernetes é um aspecto importante das opções de design de armazenamento e do gerenciamento.

Em vez de interagir diretamente com o armazenamento subjacente, o Kubernetes fornece uma camada de abstração para várias tecnologias de armazenamento por meio de classes de armazenamento. Provedores de nuvem, fornecedores de hardware e outras plataformas gerenciadas pelo Kubernetes oferecem opções diferentes de StorageClass para atender a ambientes específicos e cenários de implementação.

A Instância Gerenciada de SQL habilitada para Arc não limita nem impõe o uso de classes de armazenamento, portanto, é importante escolher o design e a configuração de armazenamento corretos. O design de armazenamento para Instância Gerenciada de SQL habilitado para Arc é tão importante quanto se você estivesse escolhendo os dispositivos de armazenamento de suporte para um SQL Server ao executar em máquinas virtuais ou bare-metal. Essas opções representam, em última análise, seus requisitos em torno de RPO, RTO, capacidade e desempenho.

Para implantações de Instância Gerenciada de SQL habilitadas para Arc, planejar efetivamente os recursos de armazenamento e a configuração é crucial para operar com êxito. Continue a leitura para saber mais sobre os fatores relacionados ao armazenamento a serem considerados, seguidos de recomendações para configurar Instância Gerenciada de SQL habilitados para Arc.

Arquitetura

O diagrama de arquitetura a seguir mostra o design lógico dos componentes de serviços de dados habilitados para Azure Arc. Esses componentes incluem um Controlador de Dados do Azure Arc necessário e um ou mais Instância Gerenciada de SQL(s) habilitados para Arc que contêm bancos de dados provisionados para referência. O Controlador de Dados do Azure Arc e o Instância Gerenciada de SQL habilitado para Arc fornecem opções para fazer backup de dispositivos de armazenamento, que dependem de provedores de infraestrutura de armazenamento e distribuição do Kubernetes.

Considerações sobre o design

Veja a seguir considerações sobre o design e a configuração do armazenamento.

Classes de armazenamento

Escolher o StorageClass do Kubernetes correto e a configuração para seus componentes de serviços de dados habilitados para Azure Arc é importante para seu desempenho, resiliência e capacidade de armazenamento de dados.

StorageClass, PersistentVolume (PV) e PersistentVolumeClaim (PVC) são objetos de recurso do Kubernetes que o sistema cria no cluster do Kubernetes ao provisionar os componentes de serviços de dados habilitados para Azure Arc.

As opções StorageClass variam dependendo do que o provedor de nuvem, o fornecedor de hardware oferece e o que o Administrador do Kubernetes configurou. O PersistentVolumeClaim solicita que um PersistentVolume seja criado para StorageClass e o tamanho solicitado. O diagrama a seguir é uma referência da relação entre esses recursos do Kubernetes e as opções potenciais para as classes de armazenamento.

Os recursos do Kubernetes PV e PVC são configurados ao provisionar o Controlador de Dados do Azure Arc e os Instância Gerenciada de SQL habilitados para Arc, respectivamente.

Há dois tipos de armazenamento diferentes para escolher:

• Local: Um volume montado em um dispositivo de armazenamento local anexado ao nó kubernetes em que o pod está em execução. Esse tipo de armazenamento geralmente fornece menor latência, juntamente com operações de entrada/saída mais altas por segundo (IOPS) e taxa de transferência em comparação com o armazenamento remoto/compartilhado.
• Armazenamento remoto/compartilhado: Dispositivos de armazenamento anexados à rede que tendem a vir com redundância interna. As opções comuns de armazenamento são dispositivos NAS e SAN.

Considere os padrões a seguir ao escolher um StorageClass. Esses critérios também seriam válidos para qualquer servidor de banco de dados que você compilaria:

• Desempenho: A taxa de transferência de entrada/saída (E/S) do dispositivo de armazenamento e o IOPS devem atender às suas necessidades de banco de dados.
• Taxa de leitura/gravação: Entender a carga de trabalho pode ajudá-lo a escolher o hardware de suporte para atender melhor às suas necessidades com os custos apropriados. Cargas de trabalho de gravação pesadas podem aproveitar as configurações raid 0, enquanto os dados acessados com pouca frequência podem ser melhor atendidos usando um armazenamento de dispositivo SAN.
• Isolamento e co-localização do banco de dados: Todos os bancos de dados em uma instância do Instância Gerenciada de SQL compartilhamento PV habilitado para Arc, para que você possa optar por mover bancos de dados para instâncias separadas do Instância Gerenciada de SQL habilitado para Arc e evitar a contenção de recursos de armazenamento.
• Capacidade: O tamanho de armazenamento definido deve atender à capacidade futura do controlador de dados e das instâncias de banco de dados para evitar a necessidade de redimensionar um PVC. Considere quaisquer limitações de armazenamento que o StorageClass escolhido possa ter.
• Modo de acesso: Os provedores de Classe de Armazenamento têm modos de acesso diferentes, dando suporte a diferentes recursos de como o armazenamento pode ser montado e lido ou gravado por pods. O RWX (Gravação de Leitura Muitos) é necessário para o volume de Backup do SQL.
• Redundância: Replicação dos dados na RAID (camada de armazenamento físico) para dar suporte ao failover contínuo se ocorrer uma falha no disco de hardware, que é separada da redundância no nível do banco de dados feita pelos Grupos de Disponibilidade (AG).

O Controlador de Dados do Azure Arc e os serviços de dados arc habilita Instância Gerenciada de SQL dos para Arc fornecem opções granulares para configurar classes de armazenamento diferentes para dados de banco de dados. Esses serviços de dados também fornecem logs, que permitem flexibilidade na escolha de classes de armazenamento para atender às necessidades.

Controlador de dados

Um único Controlador de Dados do Azure Arc é necessário para um Cluster kubernetes como um pré-requisito para criar instâncias de Instância Gerenciada de SQL habilitadas para Arc. Não há suporte para mais de um controlador de dados em execução em um cluster.

O Controlador de Dados do Azure Arc terá quatro pods com estado diferentes em execução no cluster do Kubernetes: SQL do Controlador, API do Controlador, BD de Logs e BD de Métricas. Cada pod requer dois Volumes Persistentes para os volumes de dados e logs. Todos os componentes do controlador de dados exigem um StorageClass remoto para garantir a durabilidade dos dados, pois os próprios componentes do controlador de dados não fornecem nativamente a durabilidade dos dados.

Considere os recursos de computação e memória exigidos pelo Controlador de Dados do Azure Arc. O diagrama a seguir representa os recursos de armazenamento, PV e Kubernetes do controlador de dados.

O dimensionamento de volume padrão do controlador de dados é o mínimo recomendado. O armazenamento usado depende do número de bancos de dados, da forma como você usa os bancos de dados e do número de logs gerados. O StorageClass do Controlador de Dados do Azure Arc não é sensível à baixa latência. Mesmo assim, os usuários poderão ver benefícios nas interfaces grafana e kibana com armazenamento de desempenho mais rápido se você tiver muitas implantações de Instância Gerenciada de SQL habilitadas para Arc em um cluster. Grafana e Kibana são código aberto ferramentas de visualização de monitoramento implantadas com o controlador de dados e provisionadas com painéis para exibir métricas e logs para Instância Gerenciada de SQL habilitadas para Arc.

Provisionamento do controlador de dados

Ao provisionar o Controlador de Dados do Azure Arc, configure o StorageClass e a capacidade de armazenamento para logs e dados. A configuração do armazenamento para logs e dados se aplica a todas as oito PVs criadas para os pods do controlador de dados. Durante o provisionamento, você pode especificar um modelo de implantação personalizado que substitui parâmetros padrão, como capacidade, retenção de log e itens relacionados à segurança, como Tipos de Serviço do Kubernetes. Depois que o provisionamento for concluído, os objetos PV e PVC Kubernetes serão criados.

É importante entender que o StorageClass para o controlador de dados não pode ser alterado depois de provisionado. Se você não especificar um StorageClass, o controlador de dados usará o StorageClass padrão do Kubernetes, que pode variar dependendo da instância ou do provedor do Kubernetes.

Quando você desinstala o Controlador de Dados do Azure Arc, todos os Volumes Persistentes associados a ele são excluídos. Arquive todos os logs de nível do plano de controle dos serviços de dados habilitados para Azure Arc que sua organização precisa salvar antes de desinstalar o controlador de dados.

Instância Gerenciada de SQL habilitada para Azure Arc

O Instância Gerenciada de SQL habilitado para Arc oferece duas camadas diferentes dependendo dos requisitos de negócios: Uso Geral e Comercialmente Crítico. Para ambas as camadas, é importante examinar os limites mínimo e máximo de Instância Gerenciada de SQL habilitados para Arc, que são configuráveis e garantir que o cluster kubernetes implantado tenha a capacidade de computação e memória apropriada.

Em cenários com vários bancos de dados em uma determinada instância de banco de dados, todos os bancos de dados usam os mesmos StorageClass, PVC e PV especificados para o Instância Gerenciada de SQL habilitado para Arc. É possível ter várias instâncias de Instância Gerenciada de SQL habilitadas para Arc em um único cluster do Kubernetes. Essa configuração permite volumes persistentes independentes e pode ajudar a separar a contenção de E/S de bancos de dados diferentes implantando os bancos de dados em diferentes instâncias de Instância Gerenciada de SQL habilitadas para Arc.

A tabela a seguir descreve os diferentes Volumes Persistentes usados por cada pod de Instância Gerenciada de SQL habilitado para Arc e sua finalidade.

Volume Persistente	Descrição	Requisitos de classe de armazenamento
Dados	Banco de Dados SQL arquivos de dados (arquivos.mdf)	Depende da camada
DataLogs	Banco de Dados SQL arquivos de log (arquivos.ldf)	Depende da camada
Logs	SQL Agent, logs de erros, arquivos de rastreamento, logs de integridade	Depende da camada
Backups	SQL Server arquivos de backup, incluindo log completo, dif. transacional	Modo de Acesso Remoto ReadWriteMany

Camada de serviço de Uso Geral

A camada Uso Geral do Instância Gerenciada de SQL habilitado para Arc deve usar o armazenamento remoto para a instância do banco de dados para que, após a falha de um pod, os dados permaneçam disponíveis para pods recém-criados. O failover é gerenciado pelo pod do Kubernetes e pela orquestração de nós. Essa configuração é menos complexa em comparação com Comercialmente Crítico, que usa grupos de disponibilidade do SQL e várias réplicas de Instância Gerenciada de SQL habilitadas para Arc. A configuração de pod único da camada Uso Geral significa que você pode minimizar a quantidade de armazenamento porque não precisa duplicar a capacidade de armazenamento para outras réplicas.

Camada de serviço comercialmente crítica

Comercialmente Crítico camada usa um modelo de pod múltiplo em que os volumes de log e dados podem ser armazenados em classes de armazenamento local ou remota. As classes de armazenamento local normalmente têm melhor desempenho em termos de latência e taxa de transferência porque o dispositivo de armazenamento está diretamente anexado ao nó. O armazenamento remoto normalmente oferece redundância interna, mas geralmente tem menor latência e taxa de transferência em comparação com o armazenamento local. Tenha em mente que usar mais Comercialmente Crítico réplicas de banco de dados requer volumes persistentes extras para Dados, Logs e DataLogs. A capacidade de armazenamento total necessária é muito maior.

O diagrama a seguir mostra a configuração de armazenamento Comercialmente Crítico para Arc-Enabled Instância Gerenciada de SQL com duas réplicas.

Comercialmente Crítico permite configurar duas ou três réplicas secundárias. O failover é gerenciado pelo Grupo de Disponibilidade do SQL Always On, que fornece menos tempo de inatividade para atualizações e falhas do que a camada de Uso Geral.

Configurar várias réplicas com replicação de dados do modo de confirmação síncrona garante uma melhor proteção contra falhas, como um pod, nó ou hardware de armazenamento com falha. Ele protege contra falhas porque há várias cópias dos dados nas réplicas. Considere configurar réplicas secundárias como instâncias de expansão de leitura, às quais os clientes podem se conectar ao usar o ponto de extremidade do ouvinte secundário.

Provisionamento e desinstalação do Azure Arc Instância Gerenciada de SQL

Ao provisionar Instância Gerenciada de SQL habilitados para Arc, você tem a flexibilidade de atribuir classes de armazenamento diferentes a cada uma das Instância Gerenciada de SQL Volumes Persistentes habilitadas para Arc necessárias. Talvez você queira opções de armazenamento de alto desempenho para Data e DataLogs, mas os volumes Logs e Backup podem usar opções storageClass mais econômicas para economizar nos custos. Em cenários em que você usa o armazenamento local, verifique se os volumes são capazes de pousar em nós diferentes e dispositivos de armazenamento físico para evitar contenção na E/S do disco. Colocar os Data e DataLogs na mesma unidade física pode causar contenção para essa unidade de armazenamento, resultando em baixo desempenho. Em vez disso, considere colocar os Data e DataLogs em unidades de armazenamento separadas para paralelizar e/S para dados de banco de dados e logs.

Quando você exclui Instância Gerenciada de SQL habilitados para Arc, seus PVs e PVCs associados não são removidos. Esse comportamento garante que você possa acessar os arquivos de banco de dados caso a exclusão tenha sido acidental.

Recomendações sobre design

Veja a seguir as recomendações para o design e a configuração do armazenamento.

Classes de armazenamento para cargas de trabalho de produção

Para nuvens públicas específicas, as classes de armazenamento recomendadas para cargas de trabalho de produção são mostradas na tabela a seguir.

Provedor	Armazenamento validado e recomendado
AKS (Serviço de Kubernetes do Azure)	Azure Managed Disks (camada Premium)
Amazon EKS (Elastic Kubernetes Service)	Driver de armazenamento CSI do EBS
Google (GKE)	GCE Discos persistentes

Ao escolher um StorageClass de produção em cenários locais ou multinuvem, verifique se ele é capaz de atender às suas necessidades de capacidade de armazenamento, IOPS, redundância e taxa de transferência pretendidas. As seções a seguir fornecem mais recomendações para esses cenários.

Design do controlador de dados

Escolha um StorageClass compartilhado remoto para garantir a durabilidade dos dados. Caso um pod ou nó seja removido, você poderá colocar o pod novamente para cima e se conectar novamente ao Volume Persistente. O StorageClass sublinhado deve fornecer redundância e alta disponibilidade.

É recomendável usar um modelo de implantação personalizado ao criar seu controlador de dados de serviços de dados habilitado para Arc. Um modelo personalizado permite ajustar classes de armazenamento, tamanho de armazenamento para dados e logs, segurança e Tipos de Serviço do Kubernetes. Você pode personalizá-los para seu ambiente e necessidades corporativas. O Controlador de Dados do Azure Arc requer um total de oito volumes persistentes. A configuração mínima padrão permite 15Gi para dados e 10Gi para logs nas PVs. Configure a capacidade que não apenas atenda às recomendações mínimas, mas dê suporte a um crescimento maior por ter muitas implementações de Instância Gerenciada de SQL habilitadas para Arc em execução em um cluster. Essa configuração impedirá a necessidade de redimensionar PVCs no futuro.

Recomendamos que você escolha um StorageClass de latência inferior caso o cluster tenha muitos bancos de dados e implantações de Instância Gerenciada de SQL habilitadas para Arc. A latência mais baixa melhora a experiência do usuário nas interfaces do Grafana e do Kibana.

Migração de Instância Gerenciada de SQL habilitada para Azure Arc

Recomendamos que você planeje e contabilize todos os bancos de dados novos e existentes envolvidos na migração e implantação do Instância Gerenciada de SQL habilitado para Arc. O planejamento impede a necessidade de mover bancos de dados entre instâncias posteriormente.

Dependendo da sua organização de cluster do Kubernetes, provisione implantações de Instância Gerenciada de SQL habilitadas para Arc em diferentes clusters do Kubernetes com base na necessidade de separar ambientes (não prod, prod), regiões e outros fatores de negócios. Examine a área de design da organização de recursos para obter mais recomendações. Ao configurar várias instâncias de banco de dados em um cluster, certifique-se de separar bancos de dados ocupados em sua própria instância para evitar a contenção de E/S.

Use rótulos de nó para garantir que as instâncias de banco de dados sejam colocadas em nós separados para distribuir o tráfego geral de E/S entre vários nós, confira Rótulos de Nó do Kubernetes junto com afinidade de nó do Kubernetes e rótulos antia afinidade para configurar os rótulos. Se estiver operando em um ambiente virtualizado, verifique se a E/S é distribuída adequadamente no nível do host físico.

Planeje a capacidade do Instância Gerenciada de SQL habilitado para Arc para incluir tamanhos de armazenamento adequados para Dados, Logs, DataLogs e Backups. Quando você planeja a capacidade de acomodar as necessidades atuais e o crescimento projetado para todos os bancos de dados que viverão nas instâncias do Instância Gerenciada de SQL habilitado para Arc, isso impede a necessidade de redimensionar os PVCs no futuro. Escolha unidades físicas separadas para Data e DataLogs para permitir que a atividade de E/S paralela ocorra. A atividade de E/S paralela resulta em um melhor desempenho, evitando a possível contenção causada ao usar uma unidade compartilhada.

Embora existam vários fatores que podem ditar uma implantação do Comercialmente Crítico ou Uso Geral camada de Instância Gerenciada de SQL habilitada para Arc, Comercialmente Crítico usando o armazenamento local fornece a menor latência e a maior disponibilidade. Examine a área de design de continuidade de negócios Instância Gerenciada de SQL habilitada para Arc para obter recomendações sobre restauração pontual, alta disponibilidade e recuperação de desastres. Além disso, examine a área de design de governança de custo Instância Gerenciada de SQL habilitada para Arc para saber mais sobre as implicações de custo entre as camadas.

As subseções a seguir fornecem recomendações mais específicas para cada camada:

recomendações da camada de serviço Uso Geral

É recomendável escolher um StorageClass remoto de baixa latência para os Volumes Persistentesde Dados e DataLogs para obter um desempenho ideal. Evite usar um StorageClass que introduz partições de rede, como ter um cluster local configurado para usar um StorageClass fornecido pela Internet para os Volumes Persistentes de Backup e Logs.

Comercialmente Crítico recomendações da camada de serviço

É recomendável examinar as diferenças de modo de disponibilidade, o que exigirá uma configuração diferente para cada modo escolhido.

Para os cenários de requisito de latência mais baixos possíveis, escolha armazenamento local se for uma opção para sua infraestrutura do Kubernetes. Os volumes de armazenamento locais devem pousar em diferentes dispositivos de armazenamento subjacentes para evitar contenção na E/S do disco e maximizar o desempenho. O dispositivo de armazenamento não deve ter várias funções, como hospedar a partição do Sistema Operacional.

Para cargas de trabalho com uso intensivo de leitura e alta disponibilidade, configure várias réplicas e configure seus aplicativos ou clientes para usar réplicas secundárias como instâncias de leitura Scale-Out. As réplicas secundárias não são legíveis por padrão; você pode definir a configuração.

Monitoramento

É recomendável monitorar todos os PVCs criados pelos serviços de dados habilitados para Arc, incluindo o Controlador de Dados do Azure Arc e todas as instâncias de Instância Gerenciada de SQL habilitadas para Arc em um cluster. Defina alertas para notificá-lo quando um PVC estiver se aproximando da capacidade. A notificação permite redimensionar o PVC antes de atingir a capacidade. Para clusters conectados diretamente, o monitoramento de PVCs e alertas é feito pelo Azure Monitor e pelo Container Insights. Ao usar clusters conectados indiretos, faça o monitoramento e os alertas no Grafana e no Kibana. A instalação do Grafana inclui painéis para métricas de Instância Gerenciada de SQL habilitadas para Arc e recursos do Kubernetes.

Examine as disciplinas de governança de Instância Gerenciada de SQL habilitadas para Arc para obter mais recomendações sobre como monitorar Instância Gerenciada de SQL habilitados para Arc.

Próximas etapas

Para obter mais informações sobre o percurso de nuvem híbrida e multicloud, confira os seguintes artigos:

• Examine a configuração de armazenamento para serviços de dados habilitados para Azure Arc.
• Examine as distribuições validadas do Kubernetes para serviços de dados habilitados para Azure Arc.
• Examine as diretrizes de dimensionamento dos serviços de dados habilitados para Azure Arc.
• Examine o monitoramento com Grafana e Kibana de um Instância Gerenciada de SQL habilitado para Arc.
• Experimente cenários automatizados Instância Gerenciada de SQL habilitados para Arc com o Azure Arc Jumpstart.
• Para saber mais sobre o Azure Arc, examine o Roteiro de aprendizagem do Azure Arc no Microsoft Learn.