Share via

Disciplinas de armazenamento para SQL Managed Instance compatíveis com o Azure Arc

  • Artigo

O armazenamento é um componente crítico numa implementação de SQL Managed Instance compatível com o Azure Arc (SQL Managed Instance compatível com o Arc). Compreender como os conceitos relacionados com o armazenamento descritos neste documento afetam o funcionamento dos clusters do Kubernetes é um aspeto importante das opções e da gestão da estrutura de armazenamento.

Em vez de interagir diretamente com o armazenamento subjacente, o Kubernetes fornece uma camada de abstração para várias tecnologias de armazenamento através de classes de armazenamento. Os fornecedores de cloud, fornecedores de hardware e outras plataformas geridas pelo Kubernetes oferecem diferentes opções de StorageClass para se adequarem a ambientes e cenários de implementação específicos.

O SQL Managed Instance compatível com o Arc não limita nem impõe a utilização de classes de armazenamento, pelo que é importante escolher a configuração e a estrutura de armazenamento corretas. A estrutura de armazenamento para SQL Managed Instance compatíveis com o Arc é tão importante como se estivesse a escolher os dispositivos de armazenamento de cópia de segurança para um SQL Server em execução em máquinas virtuais ou bare-metal. Estas opções representam, em última análise, os seus requisitos em torno do RPO, RTO, capacidade e desempenho.

Para implementações de SQL Managed Instance compatíveis com o Arc, o planeamento eficaz das capacidades de armazenamento e da configuração é crucial para funcionar com êxito. Continue a ler para saber mais sobre os fatores relacionados com o armazenamento a considerar, seguido de recomendações para configurar SQL Managed Instance compatíveis com o Arc.

Arquitetura

O diagrama de arquitetura seguinte mostra a estrutura lógica dos componentes dos serviços de dados preparados para o Azure Arc. Estes componentes incluem um Controlador de Dados do Azure Arc necessário e um ou mais SQL Managed Instance compatíveis com o Arc que contêm bases de dados aprovisionadas para referência. Tanto o Controlador de Dados do Azure Arc como os SQL Managed Instance compatíveis com o Arc fornecem opções para criar cópias de segurança de dispositivos de armazenamento, que dependem dos fornecedores de infraestrutura de armazenamento e distribuição do Kubernetes.

Captura de ecrã a mostrar o diagrama de arquitetura lógica dos serviços de dados preparados para o Azure Arc.

Considerações de design

Seguem-se considerações sobre a sua estrutura e configuração de armazenamento.

Classes de Armazenamento

Escolher a Classe de Armazenamento e a configuração corretas do Kubernetes para os componentes dos serviços de dados compatíveis com o Azure Arc é importante para o desempenho, resiliência e capacidade do armazenamento de dados.

StorageClass, PersistentVolume (PV) e PersistentVolumeClaim (PVC) são objetos de recursos do Kubernetes que o sistema cria no cluster do Kubernetes ao aprovisionar os componentes dos serviços de dados compatíveis com o Azure Arc.

As opções StorageClass variam consoante o fornecedor de cloud, o fornecedor de hardware e o que o Administrador do Kubernetes configurou. O PersistentVolumeClaim pede a criação de um PersistentVolume para StorageClass e o tamanho pedido. O diagrama seguinte é uma referência da relação entre estes recursos do Kubernetes e potenciais opções para as classes de armazenamento.

Captura de ecrã a mostrar os conceitos de armazenamento do Kubernetes com as opções de classes de armazenamento.

Os recursos do Kubernetes PV e PVC são configurados ao aprovisionar o Controlador de Dados do Azure Arc e SQL Managed Instance compatíveis com o Arc, respetivamente.

Existem dois tipos de armazenamento diferentes à escolha:

  • Local: Um volume montado num dispositivo de armazenamento local ligado ao nó do Kubernetes onde o pod está em execução. Normalmente, este tipo de armazenamento fornece uma latência mais baixa, juntamente com operações de entrada/saída mais elevadas por segundo (IOPS) e débito em comparação com o armazenamento Remoto/Partilhado.
  • Armazenamento remoto/partilhado: Dispositivos de armazenamento ligados à rede que tendem a ser fornecidos com redundância incorporada. As opções de armazenamento comuns são os dispositivos NAS e SAN.

Considere as seguintes normas ao escolher uma StorageClass. Estes critérios também seriam verdadeiros para qualquer servidor de bases de dados que criasse:

  • Desempenho: O débito de entrada/saída (E/S) do dispositivo de armazenamento e o IOPS devem satisfazer as necessidades da base de dados.
  • Taxa de leitura/escrita: Compreender a carga de trabalho pode ajudá-lo a escolher o hardware de apoio para satisfazer melhor as suas necessidades com os custos adequados. As cargas de trabalho de escrita pesadas podem tirar partido das configurações do RAID 0, ao passo que os dados acedidos com pouca frequência podem ser melhor servidos através de um armazenamento de dispositivos SAN.
  • Isolamento e colocalização da base de dados: Todas as bases de dados numa instância de PV de partilha de SQL Managed Instance compatível com o Arc, para que possa optar por mover bases de dados para instâncias separadas de SQL Managed Instance compatíveis com o Arc e evitar a contenção de recursos de armazenamento.
  • Capacidade: O tamanho de armazenamento definido deve satisfazer a capacidade futura do controlador de dados e das instâncias da base de dados para evitar ter de redimensionar um PVC. Considere quaisquer limitações de armazenamento que a StorageClass escolhida possa ter.
  • Modo de acesso: Os fornecedores de Classe de Armazenamento têm diferentes modos de acesso, suportando diferentes capacidades para a forma como o armazenamento pode ser montado e lido ou escrito por pods. O RWX (Muitos de Escrita de Leitura) é necessário para o volume de Cópia de Segurança do SQL.
  • Redundância: Replicação dos dados na camada de armazenamento físico (RAID) para suportar a ativação pós-falha totalmente integrada se ocorrer uma falha do disco de hardware, que é separada da redundância ao nível da base de dados feita pelos Grupos de Disponibilidade (AG).

Tanto o Controlador de Dados do Azure Arc como os serviços de dados do Arc SQL Managed Instance compatíveis com o Arc fornecem opções granulares para configurar diferentes classes de armazenamento para dados de base de dados. Estes serviços de dados também fornecem registos, que permitem flexibilidade na escolha de classes de armazenamento para satisfazer as necessidades.

Controlador de dados

É necessário um único Controlador de Dados do Azure Arc para um Cluster do Kubernetes como pré-requisito para criar instâncias de SQL Managed Instance compatíveis com o Arc. Não é suportado mais do que um controlador de dados em execução num cluster.

O Controlador de Dados do Azure Arc terá quatro pods com monitorização de estado diferentes em execução no cluster do Kubernetes: SQL do Controlador, API do Controlador, BD de Registos e DB de Métricas. Cada pod requer dois Volumes Persistentes para os volumes de dados e registos. Todos os componentes do controlador de dados requerem uma StorageClass remota para garantir a durabilidade dos dados, uma vez que os próprios componentes do controlador de dados não fornecem durabilidade de dados de forma nativa.

Não se esqueça de considerar os recursos de computação e memória necessários para o Controlador de Dados do Azure Arc. O diagrama seguinte representa os recursos de armazenamento, PV e PVC kubernetes do controlador de dados.

Captura de ecrã a mostrar o armazenamento do Controlador de Dados do Azure Arc.

O dimensionamento do volume predefinido do controlador de dados é o mínimo recomendado. O armazenamento que utilizar depende do número de bases de dados, da forma como utiliza as bases de dados e do número de registos gerados. O StorageClass do Controlador de Dados do Azure Arc não é sensível à baixa latência. Mesmo assim, os utilizadores poderão ver benefícios nas interfaces do Grafana e do Kibana com armazenamento de desempenho mais rápido se tiver muitas implementações de SQL Managed Instance compatíveis com o Arc num cluster. O Grafana e o Kibana estão open source ferramentas de visualização de monitorização implementadas com o controlador de dados e aprovisionadas com dashboards para visualização de métricas e registos para SQL Managed Instance compatíveis com o Arc.

Aprovisionamento do controlador de dados

Quando aprovisionar o Controlador de Dados do Azure Arc, configure a StorageClass e a capacidade de armazenamento para registos e dados. Configurar o armazenamento para registos e dados aplica-se, em seguida, aos oito PVs que criar para os pods do controlador de dados. Durante o aprovisionamento, pode especificar um modelo de implementação personalizado que substitui os parâmetros predefinidos, como a capacidade, a retenção de registos e itens relacionados com segurança, como os Tipos de Serviço do Kubernetes. Assim que o aprovisionamento estiver concluído, são criados objetos kubernetes de PV e PVC.

É importante compreender que a StorageClass para o controlador de dados não pode ser alterada depois de ser aprovisionada. Se não especificar uma StorageClass, o controlador de dados utiliza a StorageClass predefinida do Kubernetes, que pode variar consoante a sua instância ou fornecedor do Kubernetes.

Ao desinstalar o Controlador de Dados do Azure Arc, todos os Volumes Persistentes associados são eliminados. Arquive todos os registos ao nível do plano de controlo dos serviços de dados preparados para o Azure Arc que a sua organização precisa de guardar antes de desinstalar o controlador de dados.

SQL Managed Instance compatível com o Azure Arc

O SQL Managed Instance compatível com o Arc oferece dois escalões diferentes, consoante os requisitos comerciais: Fins Gerais e Crítico para a Empresa. Para ambos os escalões, é importante rever os limites mínimos e máximos de SQL Managed Instance compatíveis com o Arc, que são configuráveis e garantir que o cluster do Kubernetes implementado tem a capacidade de computação e memória adequada.

Em cenários com várias bases de dados numa determinada instância de base de dados, todas as bases de dados utilizam a mesma StorageClass, PVC e PV especificadas para o SQL Managed Instance compatível com o Arc. É possível ter várias instâncias de SQL Managed Instance compatíveis com o Arc num único cluster do Kubernetes. Esta configuração permite Volumes Persistentes independentes e pode ajudar a separar a contenção de E/S de diferentes bases de dados ao implementar as bases de dados em diferentes instâncias de SQL Managed Instance compatíveis com o Arc.

A tabela seguinte descreve os diferentes Volumes Persistentes utilizados por cada pod SQL Managed Instance compatível com o Arc e a respetiva finalidade.

Volume Persistente Descrição Requisitos da Classe de Armazenamento
Dados Base de Dados SQL ficheiros de dados (ficheiros .mdf) Depende do escalão
DataLogs Base de Dados SQL ficheiros de registo (ficheiros.ldf) Depende do escalão
Registos Agente SQL, registos de erros, ficheiros de rastreio, registos de estado de funcionamento Depende do escalão
Cópias de segurança SQL Server ficheiros de Cópia de Segurança, incluindo Full, Diff, Transactional Log Modo de Acesso Remoto ReadWriteMany

Fins Gerais escalão de serviço

A camada Fins Gerais do SQL Managed Instance compatível com o Arc tem de utilizar o armazenamento remoto para a instância da base de dados para que, após a falha de um pod, os dados permaneçam disponíveis para pods criados recentemente. A ativação pós-falha é gerida pelo pod do Kubernetes e pela orquestração de nós. Esta configuração é menos complexa em comparação com Crítico para a Empresa, que utiliza Grupos de Disponibilidade SQL e várias réplicas de SQL Managed Instance compatíveis com o Arc. A configuração de pod único da camada de Fins Gerais significa que pode minimizar a quantidade de armazenamento porque não tem de duplicar a capacidade de armazenamento para outras réplicas.

Captura de ecrã a mostrar o armazenamento de SQL Managed Instance Fins Gerais compatível com o Arc.

Crítico para a Empresa escalão de serviço

Crítico para a Empresa camada utiliza um modelo de vários pods onde os volumes de dados e de registo podem ser armazenados em classes de armazenamento local ou remoto. Normalmente, as classes de armazenamento local têm um melhor desempenho em termos de latência e débito, porque o dispositivo de armazenamento está diretamente ligado ao nó. Normalmente, o armazenamento remoto oferece redundância incorporada, mas muitas vezes tem menor latência e débito em comparação com o armazenamento local. Tenha em atenção que a utilização de mais réplicas de base de dados Crítico para a Empresa requer Volumes Persistentes adicionais para Dados, Registos e DataLogs. A capacidade de armazenamento total necessária é muito superior.

O diagrama seguinte mostra a configuração de armazenamento Crítico para a Empresa para Arc-Enabled SQL Managed Instance com duas réplicas.

Captura de ecrã a mostrar o armazenamento de SQL Managed Instance Crítico para a Empresa compatível com o Arc.

Crítico para a Empresa permite-lhe configurar duas ou três réplicas secundárias. A ativação pós-falha é gerida pelo Grupo de Disponibilidade AlwaysOn do SQL, que proporciona menos tempo de inatividade para atualizações e falhas do que o escalão Fins Gerais.

Configurar várias réplicas com a replicação de dados do modo de consolidação síncrona garante uma melhor proteção contra falhas, como um pod com falha, nó ou hardware de armazenamento. Protege contra falhas porque existem várias cópias dos dados nas réplicas. Considere configurar réplicas secundárias como instâncias de escalamento horizontal de leitura, às quais os clientes se podem ligar ao utilizar o ponto final do serviço de escuta secundário.

Aprovisionamento e desinstalação do Azure Arc SQL Managed Instance

Ao aprovisionar SQL Managed Instance compatíveis com o Arc, tem a flexibilidade de atribuir diferentes classes de armazenamento a cada um dos Volumes Persistentes SQL Managed Instance compatíveis com o Arc necessários. Poderá querer opções de armazenamento de desempenho mais elevado para Dados e DataLogs, mas os volumes de Registos e Cópia de Segurança podem utilizar opções storageClass mais económicas para poupar nos custos. Em cenários em que utiliza o armazenamento local, certifique-se de que os volumes são capazes de aceder a nós diferentes e dispositivos de armazenamento físico para evitar a contenção na E/S do disco. Colocar os Data and DataLogs na mesma unidade física pode causar contenção para essa unidade de armazenamento, o que resulta num fraco desempenho. Em vez disso, considere colocar os Dados e os DataLogs em unidades de armazenamento separadas para paralelizar a E/S tanto para os dados da base de dados como para os registos.

Quando elimina SQL Managed Instance compatíveis com o Arc, os PVs e PVCs associados não são removidos. Este comportamento garante que pode aceder aos ficheiros da base de dados caso a eliminação tenha sido acidental.

Recomendações de conceção

Seguem-se recomendações para a sua estrutura e configuração de armazenamento.

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

Para clouds públicas específicas, as classes de armazenamento recomendadas para cargas de trabalho de produção são apresentadas na tabela seguinte.

Fornecedor Armazenamento validado e recomendado
Azure Kubernetes Service (AKS) Azure Managed Disks (escalão Premium)
Amazon Elastic Kubernetes Service (EKS) Controlador de armazenamento CSI do EBS
Google (GKE) Discos persistentes do GCE

Ao escolher um StorageClass de produção em cenários no local ou em várias clouds, certifique-se de que é capaz de satisfazer as suas necessidades de capacidade de armazenamento, IOPS, redundância e débito pretendidas. As secções seguintes fornecem mais recomendações para estes cenários.

Design do controlador de dados

Escolha um StorageClass remoto e partilhado para garantir a durabilidade dos dados. No caso de um pod ou nó ser removido, pode fazer com que o pod volte a ser criado e volte a ligar-se ao Volume Persistente. O sublinhado StorageClass tem de fornecer redundância e elevada disponibilidade.

Recomendamos que utilize um modelo de implementação personalizado quando criar o controlador de dados dos serviços de dados compatíveis com o Arc. Um modelo personalizado permite-lhe otimizar classes de armazenamento, tamanho de armazenamento para dados e registos, segurança e Tipos de Serviço do Kubernetes. Pode personalizá-los para as suas necessidades empresariais e de ambiente. O Controlador de Dados do Azure Arc requer um total de oito Volumes Persistentes. A configuração mínima predefinida permite 15Gi para dados e 10Gi para registos nos PVs. Configure a capacidade que não só cumpre as recomendações mínimas como suporta um crescimento mais elevado, uma vez que tem muitas implementações de SQL Managed Instance compatíveis com o Arc em execução num cluster. Esta configuração impedirá a necessidade de redimensionar PVCs no futuro.

Recomendamos que escolha uma StorageClass de baixa latência caso o cluster tenha muitas bases de dados e implementações de SQL Managed Instance compatíveis com o Arc. A latência mais baixa melhora a experiência do utilizador nas interfaces do Grafana e do Kibana.

Migração de SQL Managed Instance compatível com o Azure Arc

Recomendamos que planeie e tenha em conta todas as bases de dados novas e existentes envolvidas na migração e implementação do seu SQL Managed Instance compatível com o Arc. O planeamento impede a necessidade de mover bases de dados entre instâncias mais tarde.

Consoante a sua organização de cluster do Kubernetes, aprovisione implementações de SQL Managed Instance compatíveis com o Arc para diferentes clusters do Kubernetes com base na necessidade de separar ambientes (não prod, prod), regiões e outros fatores empresariais. Reveja a área estrutura da Organização de recursos para obter mais recomendações. Ao configurar várias instâncias de base de dados num cluster, certifique-se de que separa as bases de dados ocupadas na sua própria instância para evitar a contenção de E/S.

Utilize etiquetas de nós para garantir que as instâncias de base de dados são colocadas em nós separados para distribuir o tráfego de E/S geral por vários nós. Veja Etiquetas de Nó do Kubernetes juntamente com a afinidade do Nó do Kubernetes e etiquetas anti-afinidade para configurar as etiquetas. Se estiver a operar num ambiente virtualizado, certifique-se de que a E/S é distribuída adequadamente ao nível do anfitrião físico.

Planeie a capacidade de SQL Managed Instance compatíveis com o Arc para incluir tamanhos de armazenamento adequados para Dados, Registos, DataLogs e Cópias de Segurança. Quando planeia a capacidade para acomodar as necessidades atuais e o crescimento previsto para todas as bases de dados que irão residir nas instâncias de SQL Managed Instance compatíveis com o Arc, evita ter de redimensionar os PVCs no futuro. Escolha unidades físicas separadas para Dados e DataLogs para permitir a ocorrência de atividade de E/S paralela. A atividade de E/S paralela resulta num desempenho melhorado ao evitar a possível contenção causada ao utilizar uma unidade partilhada.

Embora existam vários fatores que podem ditar uma implementação da camada Crítico para a Empresa ou Fins Gerais de SQL Managed Instance compatíveis com o Arc, Crítico para a Empresa a utilização do armazenamento local fornece a menor latência e a maior disponibilidade. Reveja a área de conceção da continuidade de negócio SQL Managed Instance compatível com o Arc para obter recomendações relativas ao restauro para um ponto anterior no tempo, elevada disponibilidade e recuperação após desastre. Além disso, reveja a área de design de governação de custos SQL Managed Instance compatível com o Arc para saber mais sobre as implicações de custos entre camadas.

As subsecções seguintes fornecem recomendações mais específicas para cada camada:

Fins Gerais recomendações do escalão de serviço

Recomenda-se escolher uma StorageClass remota de baixa latência para os Volumes Persistentes de Dados e DataLogs para um desempenho ideal. Evite utilizar uma StorageClass que introduz partições de rede, como ter um cluster no local configurado para utilizar uma StorageClass fornecida pela Internet para os Volumes Persistentes de Cópia de Segurança e Registos.

Crítico para a Empresa recomendações do escalão de serviço

Recomenda-se que reveja as diferenças do Modo de disponibilidade, o que exigirá uma configuração diferente para cada modo escolhido.

Para os cenários de requisitos de latência mais baixos possíveis, selecione armazenamento local se for uma opção para a sua infraestrutura do Kubernetes. Os volumes de armazenamento local devem ser colocados 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 alojar a partição do Sistema Operativo.

Para cargas de trabalho de leitura intensiva e elevada disponibilidade, configure várias réplicas e configure as suas aplicações ou clientes para utilizar réplicas secundárias como instâncias de leitura Scale-Out. As réplicas secundárias não são legíveis por predefinição; pode configurar a definição.

Monitorização

É recomendado monitorizar todos os PVCs criados por serviços de dados compatíveis com o Arc, incluindo o Controlador de Dados do Azure Arc e todas as instâncias de SQL Managed Instance compatíveis com o Arc num cluster. Defina alertas para notificá-lo quando um PVC estiver a aproximar-se da capacidade. A notificação permite-lhe redimensionar o PVC antes de atingir a capacidade. Para clusters Ligados Diretamente, a monitorização de PVCs e alertas é efetuada pelo Azure Monitor e pelo Container Insights. Quando utiliza clusters Ligados Indiretos, efetue a monitorização e os alertas no Grafana e no Kibana. A instalação do Grafana inclui dashboards para métricas de SQL Managed Instance compatíveis com o Arc e recursos do Kubernetes.

Reveja as disciplinas de governação de SQL Managed Instance compatíveis com o Arc para obter mais recomendações sobre a monitorização de SQL Managed Instance compatíveis com o Arc.

Passos seguintes

Para obter mais informações sobre o seu percurso na cloud híbrida e multicloud, veja os seguintes artigos: