Clustering de uma instância do SAP ASCS/SCS em um cluster de failover do Windows usando o arquivo compartilhado de cluster no Azure

  • Artigo

Windows logo. Windows

O Windows Server Failover Clustering é a base de uma instalação do SAP ASCS/SCS de alta disponibilidade e DBMS no Windows.

Um cluster de failover é um grupo servidores 1+n independentes (nós) que trabalham juntos para aumentar a disponibilidade de aplicativos e serviços. Se ocorrer uma falha de nó, o clustering de failover do Windows Server calculará o número de falhas que podem ocorrer e manterá um cluster íntegro para fornecer serviços e aplicativos. Você pode escolher dentre diferentes modos de quorum para obter o clustering de failover.

Pré-requisitos

Antes de começar as tarefas descritas neste artigo, examine os seguintes artigos e notas SAP:

Observação

O cluster de instâncias SAP ASCS/SCS com compartilhamento de arquivo é compatível com sistemas SAP com o kernel do SAP 7.22 (e posteriores). Para obter mais detalhes, confira a Nota da SAP 2698948

Clustering de Failover do Windows Server no Azure

Comparados a implantações de nuvem privada ou bare metal, as Máquinas Virtuais do Azure exigem etapas adicionais para configurar o clustering de failover do Windows Server. 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.

Resolução de nomes no Azure e nome do host virtual do cluster

A plataforma de nuvem do Azure não oferece a opção de configurar endereços IP virtual, como endereços IPs flutuantes. Você precisa de uma solução alternativa para configurar um endereço IP virtual a fim de alcançar o recurso de cluster na nuvem.

O serviço Azure Load Balancer fornece um balanceador de carga interno para o Azure. Com o balanceador de carga interno, os clientes alcançam o cluster pelo endereço IP virtual do cluster.

Implante o balanceador de carga interno no grupo de recursos que contém os nós do cluster. Em seguida, configure todas as regras necessárias de encaminhamento de porta usando as portas de investigação do balanceador de carga interno. Os clientes podem se conectar por meio do nome de host virtual. O servidor DNS resolve o endereço IP do cluster. O balanceador de carga interno trata da porta que encaminha para o nó ativo do cluster.

Figure 1: Windows Server Failover Clustering configuration in Azure without a shared disk

Figura 1: configuração do Clustering de Failover do Windows Server no Azure sem um disco compartilhado

SAP ASCS/SCS HA com compartilhamento de arquivos

SAP desenvolveu uma nova abordagem e alternativa para o cluster de discos compartilhados para fazedr cluster de instância SAP ASCS/SCS no Windows Failover Cluster. Em vez de usar discos de cluster compartilhado, você pode usar um compartilhamento de arquivos SMB para implantar arquivos de host global do SAP.

Observação

O compartilhamento de arquivos SMB é uma alternativa para discos compartilhados de cluster de instâncias SAP ASCS/SCS de cluster.

O que é específico para essa arquitetura é o seguinte:

  • Serviços SAP centrais (com processos de estrutura e mensagens e enfileiramento do próprio arquivo) são separados dos arquivos Host global do SAP.
  • Serviços de central SAP executados na instância do SAP ASCS/SCS.
  • Instância SAP ASCS/SCS estiver em cluster e está acessível usando o <nome de host virtual ASCS/SCS> nome de host virtual.
  • Os arquivos globais da SAP são colocados no compartilhamento de arquivo SMB e acessados usando o <host global SAP> chamado: \\<SAP global host>\sapmnt\<SID>\SYS...
  • A instância do SAP ASCS/SCS é instalada em um disco local em ambos os nós de cluster.
  • O <nome de host virtual ASCS/SCS> nome de rede é diferente do <host global SAP>.

Figure 2: SAP ASCS/SCS HA architecture with SMB file share

Figura 2: Arquitetura de alta disponibilidade do SAP ASCS/SCS com disco compartilhado

Pré-requisitos para o compartilhamento de arquivos SMB:

  • Protocolo SMB 3.0 (ou posterior).
  • Capacidade de definir a lista de controle de acesso (ACLs) do Active Directory (AD) para grupos de usuários do AD e objeto de computador computer$.
  • O compartilhamento de arquivos deve ser habilitado para HA:
    • Os discos usados para armazenar os arquivos não devem ser um ponto único de falha.
    • Servidor ou tempo de inatividade da VM não faz com que o tempo de inatividade no compartilhamento de arquivos.

Agora, a função de cluster <SAP> não contêm discos compartilhados pelo cluster nem recursos de cluster do Compartilhamento de Arquivo Genérico.

Figure 3: SAP <SID> cluster role resources for using a file share

Figura 3: recursos de função do cluster SAP <SID> ao usar o compartilhamento de arquivos

Expansão de compartilhamento de arquivos com Espaços de Armazenamento Diretos no Azure como compartilhamento de arquivos SAPMNT

Você pode usar uma expansão de arquivos de escalabilidade horizontal para hospedar e proteger os arquivos de host global do SAP. Um compartilhamento de arquivos de expansão também oferece um serviço de compartilhamento de arquivo SAPMNT altamente disponível.

Figure 4: Scale-out file share used to protect SAP global host files

Figura 4: expansão de arquivos SOFS usado para proteger os arquivos de Host GLOBAL do SAP

Importante

Compartilhamentos de arquivos de expansão totalmente têm suporte na nuvem do Microsoft Azure e em ambientes locais.

Uma expansão de arquivos altamente disponível e escalonável horizontalmente SAPMNT.

Espaços de armazenamento diretos é usado como um disco compartilhado para expansão de arquivos de escalabilidade horizontal. Espaços de Armazenamento Diretos, permite a criação de armazenamento altamente disponível e escalonável usando servidores com armazenamento local. Armazenamento que é usado para um compartilhamento de arquivos de expansão compartilhado, como SAP global para arquivos de host, não é um ponto único de falha.

Ao escolher Espaços de Armazenamento Diretos, considere estes casos de uso:

  • As máquinas virtuais usadas para criar o cluster de Espaços de Armazenamento Diretos precisam ser implantadas em um conjunto de disponibilidade do Azure.
  • Para a recuperação de desastre de um Cluster de Espaços de Armazenamento Diretos, você pode usar Azure Site Recovery Services.
  • Não há suporte para a ampliação do Cluster de Espaço de Armazenamento Direto entre Zonas de Disponibilidade do Azure diferentes.

Pré-requisitos do SAP para expansão de arquivos de escalabilidade horizontal no Azure

Para usar uma expansão de arquivos de escalabilidade horizontal, o sistema deve atender aos seguintes requisitos:

  • Pelo menos dois nós para um compartilhamento de arquivos de expansão de cluster.
  • Cada nó deve ter pelo menos dois discos locais.
  • Por motivos de desempenho, você deve usar a resiliência de espelhamento:
    • Para uma expansão de arquivos de escalabilidade horizontal com dois nós de cluster de espelhamento bidirecional.
    • Para um compartilhamento de arquivos de escalabilidade horizontal com três nós (ou mais) de cluster de espelhamento bidirecional.
  • Recomendamos que nós de cluster de três (ou mais) para um compartilhamento de arquivos de expansão, com o espelhamento de três vias. Essa configuração oferece mais escalabilidade e resiliência de expansão que a instalação com 2 nós de cluster e espelhamento de 2 vias.
  • Você deve usar disco Premium do Azure.
  • Recomendamos que você use o Azure Managed Disks.
  • É recomendável que você formate os volumes usando o sistema de arquivos resiliente (ReFS).
  • Você pode usar tamanhos de VM do Azure da série DS ou série DSv2.
  • Para ter bom desempenho da rede VM interno necessário para sincronização de Espaços de Armazenamento Diretos de disco, você deve usar um tipo de VM que tenha pelo menos uma largura de banda de rede "alta". Para obter mais detalhes, consulte a especificação da série DSv2 e série DS.
  • Recomendamos que você reserve alguns capacidade não alocada no pool de armazenamento. Deixar alguma capacidade não alocada no pool de armazenamento fornece espaço em volumes para reparar "no local", se um disco falhar. Isso melhora o desempenho e segurança dos dados. Para obter mais informações, consulte escolhendo o tamanho do volume.
  • Você não precisa configurar o balanceador de carga interno do Azure para o nome de rede do compartilhamento de arquivos de expansão, como para <host global SAP>. Isso é feito para o <nome de host virtual ASCS/SCS> da instância SAP ASCS/SCS ou para o DBMS. Um compartilhamento de arquivos de expansão seja dimensionável a carga em todos os nós de cluster. <Host global SAP> usa o endereço IP local para todos os nós de cluster.

Importante

Não é possível renomear o compartilhamento de arquivos SAPMNT, que aponta para <host global SAP>. SAP suporta apenas o compartilhamento de nome "sapmnt."

Para mais informações, veja Observação 2492395 do SAP – O nome do compartilhamento sapmnt pode ser alterado?

Configurar instâncias SAP ASCS/SCS e um expansão compartilhamento de arquivos em dois clusters

Você precisa implantar as instâncias do SAP ASCS/SCS em um cluster separado, com a própria função de cluster <SID> do SAP. Nesse caso, você deve configurar o compartilhamento de arquivos de expansão horizontal em outro cluster, com outra função de cluster.

Importante

A instalação deve cumprir o seguinte requisito: as instâncias do SAP ASCS/SCS e o compartilhamento SOFS devem ser implantados em clusters separados.

Importante

Nesse cenário, a instância do SAP ASCS/SCS está configurada para acessar o host global SAP usando o caminho UNC \\<SAP global host>\sapmnt\<SID>\SYS.

Figure 5: SAP ASCS/SCS instance and a scale-out file share deployed in two clusters

Figure 5: Configurar instâncias SAP ASCS/SCS e um expansão compartilhamento de arquivos em dois clusters

Configurações opcionais

Os diagramas a seguir mostram várias instâncias SAP em VMs do Azure que executam o Cluster de Failover do Microsoft Windows para reduzir o número total de VMs.

Essas instâncias podem ser Servidores de Aplicativos SAP locais em um cluster SAP ASCS/SCS ou Funções de Cluster SAP ASCS/SCS em nós de Always On do Microsoft SQL Server.

Importante

Não há suporte para a instalação de um Servidor de Aplicativos SAP local em nós de Always On do SQL Server.

Tanto o SAP ASCS/SCS quanto o banco de dados do Microsoft SQL Server são SPOF (pontos individuais de falha). Para proteger esses SPOFs em um ambiente Windows, o WSFC é usado.

Embora o consumo de recursos do SAP ASCS/SCS seja bastante pequeno, uma redução da configuração de memória para o SQL Server ou Servidor de Aplicativo SAP em 2 GB é recomendada.

Servidores de Aplicativos SAP em nós WSFC usando o Windows SOFS

Figure 6: Windows Server failover clustering configuration in Azure with Windows SOFS and locally installed SAP Application Server

Observação

A imagem mostra o uso de discos locais adicionais. Isso é opcional para os clientes que não instalarão o software de aplicativo na unidade do sistema operacional (C:)

SAP ASCS/SCS nos nós do Always On do SQL Server usando Windows SOFS

Figure 7: SAP ASCS/SCS on SQL Server Always On nodes using Windows SOFS

Observação

A imagem mostra o uso de discos locais adicionais. Isso é opcional para os clientes que não instalarão o software de aplicativo na unidade do sistema operacional (C:)

Importante

Na nuvem do Azure, cada cluster que é usado para o SAP e arquivos de expansão compartilhamentos devem ser implantados no próprio conjunto de disponibilidade do Azure definido ou entre Zonas de Disponibilidade do Azure. Isso garante distribuído posicionamento de máquinas virtuais do cluster em toda a infraestrutura do Azure subjacente. Há suporte para implantações de zona de disponibilidade com essa tecnologia.

Compartilhamento de arquivo genérico com SIOS como discos compartilhados de Cluster

O Compartilhamento de Arquivos Genérico é outra opção para alcançar o compartilhamento de arquivo altamente disponível.

Aqui, como o disco compartilhado de um cluster, você pode usar solução do SIOS de terceiros.

Próximas etapas