Sobre os discos compartilhados do Azure

Concluído

Suponha que você queira migrar muitos servidores que estão executando cargas de trabalho em cluster de sua rede local para o Azure. Você pode criar discos compartilhados do Azure e anexá-los a várias VMs (máquinas virtuais) ao mesmo tempo.

Os discos compartilhados do Azure oferecem armazenamento em bloco compartilhado baseado em nuvem. Esse armazenamento compartilhado dá suporte a aplicativos em cluster baseados no Windows e baseados no Linux.

O Azure exibe um disco compartilhado como um LUN (número de unidade lógica) para a VM de destino, que o usa como armazenamento conectado direto.

Os aplicativos que usam discos compartilhados do Azure usam um padrão SCSI PR (reserva persistente SCSI) para habilitar o failover de um nó para outro. As VMs no cluster podem ler ou gravar em seus discos anexados com base na reserva escolhida do aplicativo em cluster que usa PR SCSI.

Observação

A PR SCSI é um padrão do setor que os aplicativos em execução em SANs (redes de área do sistema) locais usam.

Você usa discos compartilhados do Azure para executar bancos de dados em cluster, sistemas de arquivos paralelos, volumes de contêiner persistentes e aplicativos de machine learning.

Recursos de discos compartilhados do Azure

Um disco compartilhado do Azure é criado como um disco gerenciado. Um disco gerenciado é um disco rígido virtual para o qual o Azure gerencia toda a infraestrutura física necessária. Como o Azure cuida da complexidade subjacente, os discos gerenciados são fáceis de usar. Basta configurar e anexar esse disco às VMs.

Os discos compartilhados do Azure estão disponíveis nos seguintes tipos de disco:

  • Discos Ultra. Esses discos oferecem alta taxa de transferência, alta IOPS (operações de E/S por segundo) e armazenamento em disco consistente de baixa latência para VMs de IaaS (infraestrutura como serviço) do Azure. Usando Discos Ultra, você pode alterar dinamicamente o desempenho de um disco sem reiniciar as VMs. Discos Ultra têm o desempenho mais rápido no Azure, juntamente com baixas latências inferiores a um milissegundo. Eles são escalonáveis para 64 TiB (tebibytes).
  • O SSD Premium v2 oferece maior desempenho do que o SSD Premium, além de ser geralmente mais barato. Você pode ajustar individualmente o desempenho do SSD Premium v2 a qualquer momento, permitindo que suas cargas de trabalho sejam mais econômicas.
  • SSD Premium (P15 e superior). Os SSDs Premium são apoiados por SSDs (unidades de estado sólido). Eles oferecem suporte de disco de alto desempenho e baixa latência para VMs que estão executando cargas de trabalho intensivas para entradas e saídas.
  • Os SSDs Standard são otimizados para cargas de trabalho que precisam de desempenho consistente em níveis mais baixos de IOPS do que o SSD Premium ou o SSD Premium v2.

Para o SSD Premium e o SSD Standard, o tamanho do disco define o número máximo de compartilhamentos, que não pode ser superior a 10. Para cada disco, um valor de maxShares representa o número máximo de nós que podem compartilhar o disco ao mesmo tempo.

Os Discos Ultra e o SSD Premium v2 não têm restrições de tamanho. O valor máximo para a configuração de maxShares é 5.

Observação

Você pode compartilhar discos compartilhados do Azure apenas como discos de dados, não como discos do SO.

Cenários de caso de uso para discos compartilhados do Azure

Os discos compartilhados do Azure oferecem a flexibilidade para migrar ambientes em cluster locais que são executados no Windows ou no Linux. Aplicativos executados no Windows Server podem usar o serviço de cluster de failover para controlar a operação de leitura e gravação dos discos compartilhados do Azure.

Um cenário de cluster de failover

Em um cenário de cluster de failover, você usa várias VMs para acessar um disco compartilhado do Azure. Uma das VMs atua como um nó primário e lê e grava no disco. As outras VMs atuam como nós secundários. Se o nó primário perder o acesso ao disco, os nós secundários poderão assumir as operações de leitura e gravação. Um cenário comum de caso de uso que usa um cluster de failover com o modo ativo-passivo é um banco de dados em cluster como uma FCI (instância de cluster de failover) do SQL Server.

Para ajudar você a entender como os discos compartilhados funcionam, vamos examinar o seguinte exemplo passo a passo:

  1. O aplicativo em cluster que é executado nas VMs usa o protocolo SCSI PR para registrar sua intenção de ler ou gravar no disco. Nesta etapa, cada VM lê informações sobre o destino sobre reservas e registros.
  2. Uma instância do aplicativo na VM1 usa a reserva exclusiva para gravar no disco.
  3. Depois que a reserva for imposta, somente a VM1 poderá gravar no disco. Essa ação impede que outras VMs gravem no disco ao mesmo tempo.
  4. Se a instância do aplicativo na VM1 for inativa, a VM2 emitirá um comando preempt and abort e assumirá o controle do disco.
  5. A reserva a ser gravada agora é imposta na VM2 e outras VMs não podem gravar no disco.
  6. Os aplicativos que estavam em execução na VM1 agora fazem failover para a VM2.

Diagrama que mostra como o clustering de failover funciona com discos compartilhados no Azure.

Instância de cluster de failover do SQL Server

Você pode criar uma FCI do SQL Server usando duas ou mais VMs do Microsoft Azure. Para obter alta disponibilidade, use SSDs Premium com suporte para conjuntos de disponibilidade e grupos de posicionamento por proximidade. Como alternativa, você pode usar Discos Ultra que incluem suporte para zonas de disponibilidade. Você deve usar discos compartilhados do Azure para armazenar diretórios de dados da FCI do SQL Server. Você também poderá implementar divisão em vários discos compartilhados se criar um pool de armazenamento compartilhado.

Observação

Conjuntos de disponibilidade e grupos de posicionamento por proximidade não são necessários para implementar uma FCI do SQL Server com um disco compartilhado. Eles são usados para aumentar a disponibilidade e o desempenho da FCI do SQL Server.

SAP ASCS/SCS

Os servidores de aplicativo SAP usam discos compartilhados em cluster para colocar arquivos de host global do SAP e SAP ASCS/SCS. Você pode implantar aplicativos SAP no Windows e no Linux.

O clustering de failover do Windows Server com as VMs do Azure requer mais etapas de configuração. Quando você compila um cluster, precisa definir vários endereços IP e nomes de host virtual para a instância do SAP ASCS/SCS. Você pode implantar opções de SID (identificador de segurança) único e múltiplo para o SAP ASCS/SCS. Você só pode usar SSDs Premium como discos compartilhados do Azure para uma instância do SAP ASCS/SCS.

Servidores de arquivos

Os servidores de arquivos para uso geral podem usar o disco compartilhado para habilitar a alta disponibilidade para a função de serviço de arquivo. Você também pode usar os recursos de Servidor de Arquivos de Escalabilidade Horizontal implantados em um cluster de failover do Windows Server, que usa discos compartilhados do Azure no modo ativo-ativo. Os recursos de testemunha de cluster são armazenados em discos compartilhados do Azure. Todos os compartilhamentos de arquivos ficam online em todos os nós simultaneamente.

Use um modelo do ARM (modelo do Azure Resource Manager) para implantar um cluster de Servidor de Arquivos de Escalabilidade Horizontal do Windows Server 2019 com discos compartilhados do Azure.

Aplicativos distribuídos com requisitos de várias leituras ou de várias gravações

O aplicativo em cluster em execução em várias VMs pode acessar o disco compartilhado do Azure usando a estratégia de "Gravar depois de ler muitas". Uma VM tem uma reserva exclusiva para gravar no disco compartilhado usando a reserva persistente SCSI. Enquanto isso, outras VMs podem ler simultaneamente do disco. Somente um nó grava os resultados no disco para todos os nós no cluster.

O diagrama a seguir ilustra outra carga de trabalho em cluster comum. Ele consiste em vários nós que leem os dados de um disco para executar processos paralelos.

Diagrama de treinamento de modelo para machine learning usando disco compartilhado.

Observação

Você também pode habilitar um cenário de gravação múltipla. No entanto, esse cenário requer que os aplicativos possam gravar.

Clustering no Linux

Os clusters do Linux podem usar gerenciadores de cluster, como o Pacemaker, com suporte para sistemas de arquivos em cluster comuns, como ocfs2 e gf2.

Há suporte para os seguintes clusters do Linux em discos compartilhados do Azure:

  • SLES (SUSE Linux Enterprise Server) para SAP
  • Ubuntu 18.04 e posteriores
  • Versão prévia do desenvolvedor do RHEL (Red Hat Enterprise Linux) em qualquer versão do RHEL 8
  • Oracle Enterprise Linux

SLES para SAP

Use a distribuição SLES com discos compartilhados do Azure para criar um dos seguintes:

  • Um servidor NFS (sistema de arquivos de rede) ativo/passivo.
  • Um sistema de arquivos de cluster do OCFS2 (Oracle Cluster File System versão 2) ativo/ativo.

Você controla o acesso ao disco compartilhado usando a PR SCSI ou usando SBD (dispositivo de bloco STONITH). O clustering no SLES usa um watchdog para redefinição de dispositivo. Você também pode implementar o watchdog em um disco compartilhado do Azure.

Para obter informações detalhadas sobre como criar o SLES para SAP, confira Discos compartilhados do Azure com "SLES para SAP/SLE HA 15 SP2".

Alta disponibilidade do Ubuntu

Os clusters do Ubuntu usam o Pacemaker como um gerenciador de cluster que é executado sobre o mecanismo de cluster Corosync. Controle a consistência entre vários recursos de cluster usando uma das seguintes opções de isolamento:

  • SCSI PR
  • SBD

Semelhante ao SLES, um pequeno modelo de kernel do Linux chamado softdog controla o acesso ao disco compartilhado. Você pode implantar um cluster ativo/passivo e ativo/ativo. No entanto, para o cluster ativo/ativo, um DLM (gerenciador de bloqueio distribuído) também é necessário.

Cluster RHEL usando discos compartilhados

Você pode usar um disco compartilhado como um armazenamento em bloco compartilhado para um cluster de alta disponibilidade do RHEL. Aplicativos em cluster em execução em VMs altamente disponíveis do RHEL acessam o mesmo dispositivo de armazenamento em cada servidor em um cluster por meio do GFS2 (Sistema de Arquivos Global 2). Use o Pacemaker para gerenciamento de cluster, o Corosync para comunicações de membro e o STONITH para integridade de dados e de isolamento.

Para obter informações detalhadas sobre como criar um cluster RHEL com discos compartilhados, confira a documentação do Red Hat Enterprise Linux para RHEL 7.9 ou RHEL 8.3+.

Usar discos compartilhados do Azure em contêineres

Os aplicativos que estão em execução no AKS (Serviço de Kubernetes do Azure) podem usar o armazenamento persistente em discos compartilhados do Azure. O arquivo YAML de manifesto deve conter uma configuração devicePath, em vez de mountPaths. Essa configuração permite que as instâncias de contêiner usem o sistema de arquivos montado.

Observação

O recurso de disco compartilhado dá suporte apenas a dispositivos de bloco brutos. Os aplicativos Kubernetes devem gerenciar a coordenação e o controle de gravações, leituras, bloqueios, caches, montagens e isolamento no disco compartilhado, que é exposto como um dispositivo de bloco bruto.