Implantar aplicativos clusterizados no Azure Elastic SAN

Os volumes do Azure Elastic SAN podem ser anexados simultaneamente a vários clientes de computação, permitindo que você implante ou migre aplicativos de cluster para o Azure. Você precisa usar um gerenciador de cluster para compartilhar um volume de SAN elástica, como o WSFC (Cluster de Failover do Windows Server) ou o Pacemaker. O gerenciador de cluster lida com comunicações de nó de cluster e bloqueio de gravação. O Elastic SAN não oferece nativamente um sistema de arquivos totalmente gerenciado que possa ser acessado por SMB ou NFS.

Quando usados como um volume compartilhado, os volumes de SAN elásticos podem ser compartilhados entre zonas ou regiões de disponibilidade. O compartilhamento de um volume em uma SAN de armazenamento com redundância local entre zonas reduz o desempenho devido ao aumento da latência entre o volume e os clientes.

Limitações

• Os scripts de conexão SAN elástica podem ser usados para anexar volumes compartilhados a máquinas virtuais em Conjuntos de Dimensionamento de Máquinas Virtuais ou máquinas virtuais em Conjuntos de Disponibilidade. Não há suporte para alinhamento de domínio com falha.
• O número máximo de sessões suportadas por um volume compartilhado é 128.
  • Um cliente individual pode criar várias sessões para um volume individual para aumentar o desempenho. Por exemplo, se você criar 32 sessões em cada um dos seus clientes, apenas quatro clientes poderão se conectar a um único volume.

Consulte Suporte para recursos de armazenamento do Azure para outras limitações do Elastic SAN.

Como funciona

Os volumes compartilhados de SAN elástica usam reservas persistentes SCSI-3 para permitir que os iniciadores (clientes) controlem o acesso a um volume de SAN elástica compartilhado. Esse protocolo permite que um iniciador reserve o acesso a um volume SAN elástico, limite o acesso de gravação (ou leitura) de outros iniciadores e persista a reserva em um volume além do tempo de vida de uma sessão por padrão.

O SCSI-3 PR tem um papel fundamental na manutenção da consistência e integridade dos dados em volumes compartilhados em cenários de cluster. Os nós de computação em um cluster podem ler ou gravar em seus volumes de SAN elástica anexados com base na reserva escolhida por seus aplicativos de cluster.

Fluxo de reservas persistente

O diagrama a seguir ilustra um aplicativo de banco de dados clusterizado de 2 nós de exemplo que usa SCSI-3 PR para habilitar o failover de um nó para o outro.

O fluxo é o seguinte:

1. O aplicativo clusterizado em execução no Azure VM1 e VM2 registra sua intenção de ler ou gravar no volume SAN elástico.
2. Em seguida, a instância do aplicativo no VM1 faz uma reserva exclusiva para gravar no volume.
3. Essa reserva é imposta ao seu volume e o banco de dados agora pode gravar exclusivamente no volume. Todas as gravações da instância do aplicativo no VM2 falham.
4. Se a instância do aplicativo no VM1 ficar inativa, a instância no VM2 poderá iniciar um failover de banco de dados e assumir o controle do volume.
5. Essa reserva agora é imposta no volume e não aceita gravações do VM1. Ele só aceita gravações de VM2.
6. O aplicativo clusterizado pode concluir o failover do banco de dados e atender solicitações do VM2.

O diagrama a seguir ilustra outra carga de trabalho clusterizada comum que consiste em vários nós lendo dados de um volume SAN elástico para executar processos paralelos, como o treinamento de modelos de aprendizado de máquina.

O fluxo é o seguinte:

1. O aplicativo clusterizado em execução em todas as VMs registra sua intenção de ler ou gravar no volume SAN elástico.
2. A instância do aplicativo no VM1 recebe uma reserva exclusiva para gravar no volume enquanto abre leituras para o volume de outras VMs.
3. Esta reserva é aplicada ao volume.
4. Todos os nós no cluster agora podem ler a partir do volume. Apenas um nó grava os resultados no volume, em nome de todos os nós no cluster.

Comandos SCSI PR suportados

Os seguintes comandos são compatíveis com volumes SAN elásticos:

Para interagir com o volume, comece com a ação de reserva persistente apropriada:

• PR_REGISTER_KEY
• PR_REGISTER_AND_IGNORE
• PR_GET_CONFIGURATION
• PR_RESERVE
• PR_PREEMPT_RESERVATION
• PR_CLEAR_RESERVATION
• PR_RELEASE_RESERVATION

Ao usar PR_RESERVE, PR_PREEMPT_RESERVATION ou PR_RELEASE_RESERVATION, forneça um dos seguintes tipos de reserva persistentes:

• PR_NONE
• PR_WRITE_EXCLUSIVE
• PR_EXCLUSIVE_ACCESS
• PR_WRITE_EXCLUSIVE_REGISTRANTS_ONLY
• PR_EXCLUSIVE_ACCESS_REGISTRANTS_ONLY
• PR_WRITE_EXCLUSIVE_ALL_REGISTRANTS
• PR_EXCLUSIVE_ACCESS_ALL_REGISTRANTS

O tipo de reserva persistente determina o acesso ao volume de cada nó do cluster.

Tipo de reserva persistente	Titular da Reserva	Registado	Outras
SEM RESERVA	N/A	Leitura/Escrita	Leitura/Escrita
ESCREVA EXCLUSIVO	Leitura/Escrita	Somente leitura	Somente leitura
ACESSO EXCLUSIVO	Leitura/Escrita	Sem Acesso	Sem Acesso
ESCREVA EXCLUSIVO - APENAS REGISTANTES	Leitura/Escrita	Leitura/Escrita	Somente leitura
ACESSO EXCLUSIVO - APENAS REGISTANTES	Leitura/Escrita	Leitura/Escrita	Sem Acesso
ESCREVA EXCLUSIVO - TODOS OS INSCRITOS	Leitura/Escrita	Leitura/Escrita	Somente leitura
ACESSO EXCLUSIVO - TODOS OS INSCRITOS	Leitura/Escrita	Leitura/Escrita	Sem Acesso

Você também precisa fornecer uma chave de reserva persistente ao usar:

• PR_RESERVE
• PR_REGISTER_AND_IGNORE
• PR_REGISTER_KEY
• PR_PREEMPT_RESERVATION
• PR_CLEAR_RESERVATION
• PR_RELEASE-RESERVA.