Agrupar uma instância SAP ASCS/SCS em um cluster de failover do Windows usando um compartilhamento de arquivos no Azure

  • Artigo

Windows logo. Mac OS

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

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

Pré-requisitos

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

Nota

O agrupamento de instâncias SAP ASCS/SCS usando um compartilhamento de arquivos é suportado para sistemas SAP com SAP Kernel 7.22 (e posterior). Para obter detalhes, consulte a nota SAP 2698948

Clustering de failover do Windows Server no Azure

Em comparação com implantações de nuvem bare-metal ou privada, as Máquinas Virtuais do Azure exigem etapas adicionais para configurar o cluster de failover do Windows Server. Ao criar um cluster, você precisa definir vários endereços IP e nomes de host virtual para a instância SAP ASCS/SCS.

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

A plataforma de nuvem do Azure não oferece a opção de configurar endereços IP virtuais, como endereços IP flutuantes. Você precisa de uma solução alternativa para configurar um endereço IP virtual para acessar 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 de encaminhamento de porta necessárias usando as portas de teste do balanceador de carga interno. Os clientes podem se conectar através do nome do host virtual. O servidor DNS resolve o endereço IP do cluster. O balanceador de carga interno lida com o encaminhamento de porta para o nó ativo do cluster.

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

Figura 1: Configuração de clustering de failover do Windows Server no Azure sem um disco compartilhado

SAP ASCS/SCS HA com compartilhamento de arquivos

A SAP desenvolveu uma nova abordagem, e uma alternativa aos discos compartilhados de cluster, para agrupar uma instância SAP ASCS/SCS em um cluster de failover do Windows. Em vez de usar discos compartilhados de cluster, você pode usar um compartilhamento de arquivos SMB para implantar arquivos de host global SAP.

Nota

Um compartilhamento de arquivos SMB é uma alternativa ao uso de discos compartilhados de cluster para clusterizar instâncias SAP ASCS/SCS.

Essa arquitetura é específica das seguintes maneiras:

  • Os serviços centrais SAP (com sua própria estrutura de arquivos e processos de mensagem e enfileiramento) são separados dos arquivos host globais SAP.
  • Os serviços centrais SAP são executados sob uma instância SAP ASCS/SCS.
  • A instância SAP ASCS/SCS é clusterizada e pode ser acessada usando o nome> do <host virtual ASCS/SCS.
  • Os arquivos globais SAP são colocados no compartilhamento de arquivos SMB e são acessados usando o nome do <host> global SAP: \\SAP global host>\sapmnt\SID>\<<SYS...
  • A instância SAP ASCS/SCS é instalada em um disco local em ambos os nós do cluster.
  • O <nome da rede do nome> do host virtual ASCS/SCS é diferente do <host> global SAP.

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

Figura 2: Nova arquitetura SAP ASCS/SCS HA com um compartilhamento de arquivos SMB

Pré-requisitos para um compartilhamento de arquivos SMB:

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

A função de cluster SAP <SID> não contém discos compartilhados de cluster ou um recurso genérico de cluster de compartilhamento de arquivos.

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

Figura 3: Recursos da função de cluster SAP <SID> para usar um compartilhamento de arquivos

Compartilhamentos de arquivos de expansão com Espaços de Armazenamento Diretos no Azure como um compartilhamento de arquivos SAPMNT

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

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

Figura 4: Um compartilhamento de arquivos de expansão usado para proteger arquivos de host global SAP

Importante

Os compartilhamentos de arquivos de expansão são totalmente suportados na nuvem do Microsoft Azure e em ambientes locais.

Um compartilhamento de arquivos escalável oferece um compartilhamento de arquivos SAPMNT altamente disponível e escalável horizontalmente.

O Storage Spaces Direct é usado como um disco compartilhado para um compartilhamento de arquivos em expansão. Você pode usar os Espaços de Armazenamento Diretos para criar armazenamento altamente disponível e escalável usando servidores com armazenamento local. O armazenamento compartilhado usado para um compartilhamento de arquivos de expansão, como para arquivos de host global SAP, não é um único ponto de falha.

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

  • As máquinas virtuais usadas para criar o cluster Storage Spaces Direct precisam ser implantadas em um conjunto de disponibilidade do Azure.
  • Para recuperação de desastres de um Cluster Direto de Espaços de Armazenamento, você pode usar os Serviços de Recuperação de Site do Azure.
  • Não há suporte para estender o Cluster Direto de Espaço de Armazenamento em diferentes Zonas de Disponibilidade do Azure.

Pré-requisitos SAP para compartilhamentos de arquivos de expansão no Azure

Para usar um compartilhamento de arquivos em expansão, seu sistema deve atender aos seguintes requisitos:

  • Pelo menos dois nós de cluster para um compartilhamento de arquivos em expansão.
  • Cada nó deve ter pelo menos dois discos locais.
  • Por motivos de desempenho, você deve usar a resiliência de espelhamento:
    • Espelhamento bidirecional para um compartilhamento de arquivos em expansão com dois nós de cluster.
    • Espelhamento de três vias para um compartilhamento de arquivos em expansão com três (ou mais) nós de cluster.
  • Recomendamos três (ou mais) nós de cluster para um compartilhamento de arquivos em expansão, com espelhamento de três vias. Essa configuração oferece mais escalabilidade e mais resiliência de armazenamento do que a configuração de compartilhamento de arquivos em expansão com dois nós de cluster e espelhamento bidirecional.
  • Você deve usar discos Premium do Azure.
  • Recomendamos que você use o Azure Managed Disks.
  • Recomendamos que você formate volumes usando o Sistema de Arquivos Resiliente (ReFS).
  • Você pode usar tamanhos de VM do Azure DS-Series ou DSv2-Series.
  • Para um bom desempenho de rede entre VMs, que é necessário para a sincronização direta de disco dos Espaços de Armazenamento, use um tipo de VM que tenha pelo menos uma largura de banda de rede "alta". Para obter mais informações, consulte as especificações das séries DSv2 e DS.
  • Recomendamos que você reserve alguma capacidade não alocada no pool de armazenamento. Deixar alguma capacidade não alocada no pool de armazenamento dá aos volumes espaço para reparar "no lugar" se uma unidade falhar. Isso melhora a segurança e o desempenho dos dados. Para obter mais informações, consulte Escolhendo o tamanho do volume.
  • Não é necessário configurar o balanceador de carga interno do Azure para o nome da rede de compartilhamento de arquivos de expansão, como para <o host> global SAP. Isso é feito para o nome> do host virtual ASCS/SCS da instância SAP ASCS/SCS ou para o <DBMS. Um compartilhamento de arquivos de expansão dimensiona a carga em todos os nós do cluster. <O host> global SAP usa o endereço IP local para todos os nós do cluster.

Importante

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

Para obter mais informações, consulte SAP Note 2492395 - O nome do compartilhamento sapmnt pode ser alterado?

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

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

Importante

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

Importante

Nesse cenário, a instância SAP ASCS/SCS é 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

Figura 5: Uma instância SAP ASCS/SCS e um compartilhamento de arquivos de expansão implantados 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.

Isso pode ser servidores de aplicativos SAP locais em um cluster SAP ASCS/SCS ou uma função de cluster SAP ASCS/SCS em nós Always On do Microsoft SQL Server.

Importante

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

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

Embora o consumo de recursos do SAP ASCS/SCS seja relativamente pequeno, recomenda-se uma redução de 2 GB na configuração de memória do SQL Server ou do SAP Application Server.

Servidores de aplicativos SAP em nós WSFC usando SOFS do Windows

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

Nota

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

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

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

Nota

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

Importante

Na nuvem do Azure, cada cluster usado para compartilhamentos de arquivos SAP e de expansão deve ser implantado em seu próprio conjunto de disponibilidade do Azure ou nas Zonas de Disponibilidade do Azure. Isso garante o posicionamento distribuído das VMs de cluster na infraestrutura subjacente do Azure. As implantações da zona de disponibilidade são suportadas com essa tecnologia.

Compartilhamento de arquivos genéricos com o SIOS DataKeeper como discos compartilhados de cluster

Um compartilhamento de arquivos genérico é outra opção para obter um compartilhamento de arquivos altamente disponível.

Nesse caso, você pode usar uma solução SIOS de terceiros como um disco compartilhado de cluster.

Próximos passos