Arquitetura de alta disponibilidade e cenários para SAP NetWeaver
Definições de terminologia
Alta disponibilidade: Refere-se a um conjunto de tecnologias que minimiza as interrupções de TI proporcionando a continuidade dos negócios de serviços de TI por meio de componentes redundantes e tolerantes a falhas ou protegidos contra failover no mesmo data center. Em nosso caso, o data center reside em uma região do Azure.
Recuperação de desastre: Também se refere à redução da interrupção dos serviços de TI e sua recuperação, mas em vários data centers que podem estar a centenas de quilômetros de distância uns dos outros. Em nosso caso, os data centers podem residir em várias regiões do Azure na mesma região geopolítica ou em locais estabelecidos por você como cliente.
Visão geral de alta disponibilidade
A alta disponibilidade do SAP no Azure pode ser classificada em três tipos:
Alta disponibilidade de infraestrutura do Azure:
Por exemplo, a alta disponibilidade pode incluir VMs (computação), rede ou armazenamento e seus benefícios para aumentar a disponibilidade de aplicativos SAP.
Utilizando a reinicialização da VM de infraestrutura do Azure para proteger aplicativos SAP:
Se você decidir não usar as funcionalidades, como o WSFC (Clustering de Failover do Windows Server) ou o Pacemaker no Linux, a reinicialização de VM do Azure será utilizada. Ele restaura a funcionalidade nos sistemas SAP se houver algum tempo de inatividade planejado e não planejado da infraestrutura de servidor físico do Azure e da plataforma geral subjacente do Azure.
Alta disponibilidade de aplicativo SAP:
Para obter toda a alta disponibilidade do sistema SAP, você precisa proteger todos os componentes essenciais do sistema SAP. Por exemplo:
- Servidores de aplicativos SAP redundantes.
- Componentes exclusivos. Um exemplo pode ser um componente SPOF (ponto único de falha), como uma instância SAP ASCS/SCS ou um DBMS (sistema de gerenciamento de banco de dados).
A alta disponibilidade do SAP no Azure é diferente da alta disponibilidade do SAP em um ambiente físico ou virtual local.
Não há nenhuma configuração de alta disponibilidade SAP integrada ao sapinst para Linux como existe para o Windows. Para saber mais sobre alta disponibilidade da SAP local para Linux, confira Informações do parceiro de alta disponibilidade.
Alta disponibilidade de infraestrutura do Azure
SLA para máquinas virtuais de instância única
Atualmente, há um SLA de VM única de 99,9% com armazenamento premium. Para ter uma ideia de como é a disponibilidade de uma única VM, você pode compilar o produto dos diferentes Contratos de Nível de Serviço do Azure disponíveis.
A base para o cálculo é 30 dias por mês, ou 43.200 minutos. Por exemplo, um tempo de inatividade de 0,05% corresponde a 21,6 minutos. Normalmente, a disponibilidade dos serviços é calculada da seguinte maneira:
(Serviço de Disponibilidade #1/100) x (Serviço de Disponibilidade #2/100) x (Serviço de Disponibilidade #3/100) *...
Por exemplo:
(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 ou uma disponibilidade geral de 99,75%.
Várias instâncias de máquinas virtuais no mesmo conjunto de disponibilidade
Para todas as máquinas virtuais que têm duas ou mais instâncias implantadas no mesmo conjunto de disponibilidade, garantimos que você tenha conectividade de máquina virtual com pelo menos uma instância pelo menos 99,95% do tempo.
Quando duas ou mais VMs são parte do mesmo conjunto de disponibilidade, cada máquina virtual em um conjunto de disponibilidade recebe um domínio de atualização e um domínio de falha da plataforma subjacente do Azure.
- Os domínios de atualização garantem que várias VMs não sejam reinicializadas ao mesmo tempo durante a manutenção planejada de uma infraestrutura do Azure. Apenas uma VM é reiniciada por vez.
- Os domínios de falha garantem que as VMs sejam implantadas em componentes de hardware que não compartilham uma fonte de alimentação e um switch de rede comuns. Quando os servidores, as chaves de rede ou as fontes de alimentação passam por tempo de inatividade não planejado, apenas uma VM é afetada.
Para obter mais informações, consulte gerenciar a disponibilidade de máquinas virtuais no Azure usando o conjunto de disponibilidade.
Zonas de Disponibilidade do Azure
O Azure está em processo de implantação de um conceito de Zonas de Disponibilidade do Azure em diferentes Regiões do Azure. Nas regiões do Azure em que as Zonas de Disponibilidade são oferecidas, as regiões do Azure têm vários data centers, que são independentes em relação a fonte de alimentação, resfriamento e rede. O motivo para a oferta de diferentes zonas em uma única região do Azure é permitir que você implante aplicativos em duas ou três Zonas de Disponibilidade oferecidas. Supondo que os problemas em fontes de alimentação e/ou rede afetem apenas uma infraestrutura de Zona de Disponibilidade, a implantação do aplicativo dentro de uma região do Azure permanece totalmente funcional. Eventualmente com alguma capacidade reduzida, pois algumas máquinas virtuais em uma região podem ser perdidas. Mas as VMs nas outras duas zonas ainda estão em execução. As regiões do Azure que oferecem zonas são listadas em Zonas de Disponibilidade do Azure.
Ao usar zonas de disponibilidade, há algumas coisas a serem consideradas. A lista de considerações é semelhante à seguinte:
- Não é possível implantar Conjuntos de Disponibilidade do Azure em uma Zona de Disponibilidade. Combinar conjuntos e zonas de disponibilidade somente é possível com grupos de posicionamento por proximidade. Para obter mais informações, consulte o artigo Combinar conjuntos de disponibilidade e zonas de disponibilidade com grupos de posicionamento de proximidade.
- Não é possível usar o Basic Load Balancer para criar soluções de cluster de failover baseadas em Serviços de Cluster de Failover do Windows ou no Linux Pacemaker. Em vez disso, você precisa usar o SKU do Azure Standard Load Balancer.
- As Zonas de Disponibilidade do Azure não estão dando garantias de certa distância entre as diferentes zonas em uma região.
- A latência da rede entre diferentes Zonas de Disponibilidade do Azure em diferentes regiões do Azure poderá variar conforme a região do Azure. Haveria casos em que você, como cliente, pode executar razoavelmente a camada de aplicativo SAP implantada em diferentes zonas, já que a latência de rede de uma zona para a VM DBMS ativa ainda é aceitável devido ao impacto no processo de negócios. Considerando que pode haver cenários de cliente em que a latência entre a VM DBMS ativa em uma zona e uma instância de aplicativo SAP em uma VM em outra zona pode ser muito intrusiva e não aceitável para os processos de negócios SAP. Como resultado, as arquiteturas de implantação precisam ser diferentes com uma arquitetura ativa/ativa para o aplicativo ou uma arquitetura ativa/passiva, caso a latência seja muito alta.
- O uso de discos gerenciados do Azure é obrigatório para implantação em zonas de disponibilidade do Azure.
Conjunto de dimensionamento de máquina virtual com orquestração flexível
No Azure, os Conjuntos de Dimensionamento de Máquina Virtual com orquestração flexível oferecem um meio de obter alta disponibilidade para cargas de trabalho SAP, assim como outras estruturas de implantação, como conjuntos de disponibilidade e zonas de disponibilidade. Com o conjunto de dimensionamento flexível, as VMs podem ser distribuídas entre várias zonas de disponibilidade e domínios de falha, tornando-se uma opção adequada para implantar cargas de trabalho SAP altamente disponíveis.
O conjunto de dimensionamento de máquina virtual com orquestração flexível oferece a flexibilidade de criar o conjunto de escala dentro de uma região ou estendê-lo entre zonas de disponibilidade. Ao criar, o conjunto de escala flexível dentro de uma região com platformFaultDomainCount>1 (FD>1), as VMs implantadas no conjunto de escala seriam distribuídas entre o número especificado de domínios de falha na mesma região. Por outro lado, a criação do conjunto de escala flexível entre zonas de disponibilidade com platformFaultDomainCount=1 (FD=1) distribuiria as VMs em diferentes zonas e o conjunto de escala também distribuiria VMs em diferentes domínios de falha dentro de cada zona com base no melhor esforço. Para carga de trabalho SAP, somente o conjunto de dimensionamento flexível com FD=1 é suportado.
A vantagem de usar conjuntos de escala flexíveis com FD=1 para implantação zonal cruzada, em vez da implantação tradicional da zona de disponibilidade, é que as VMs implantadas com o conjunto de escala seriam distribuídas entre diferentes domínios de falha dentro da zona da maneira mais esforçada. Para evitar as limitações associadas à utilização do grupo de posicionamento de proximidade para garantir a disponibilidade das VMs em todos os datacenters do Azure ou em cada coluna da rede, é aconselhável implantar a carga de trabalho SAP em zonas de disponibilidade usando um conjunto de escala flexível com FD=1. Essa estratégia de implantação garante que as VMs implantadas em cada zona não fiquem restritas a um único datacenter ou espinha dorsal de rede, e todos os componentes do sistema SAP, como bancos de dados, ASCS/ERS e camada de aplicativo, tenham escopo no nível zonal.
Portanto, para a nova implantação de carga de trabalho SAP em zonas de disponibilidade, recomendamos usar um conjunto de escala flexível com FD=1. Para obter mais informações, consulte Conjunto de dimensionamento de máquina virtual para documento de carga de trabalho SAP.
Manutenção planejada e não planejada de máquinas virtuais
Dois tipos de eventos da plataforma Azure podem afetar a disponibilidade das máquinas virtuais:
- Os eventos de Manutenção planejada são atualizações periódicas da plataforma subjacente do Azure feitas pela Microsoft. As atualizações melhoram a confiabilidade, o desempenho e a segurança da infraestrutura de plataforma onde as máquinas virtuais são executadas.
- Os eventos de manutenção não planejada ocorrem quando o hardware ou a infraestrutura física subjacente à sua máquina virtual apresentou algum tipo de falha. Isso pode incluir falhas na rede local, falhas no disco local ou outras falhas no nível de rack. Quando tal falha é detectada, a plataforma do Azure migra automaticamente sua máquina virtual do servidor físico não íntegro que hospeda sua máquina virtual para um servidor físico íntegro. Esses eventos são raros, mas podem também causar a reinicialização da sua máquina virtual.
Para obter mais informações, consulte Manutenção de máquinas virtuais no Azure.
Redundância do Armazenamento do Azure
Os dados em sua conta de armazenamento sempre são replicados para garantir durabilidade e alta disponibilidade, cumprindo o SLA do Armazenamento do Azure mesmo diante de falhas transitórias de hardware.
Como o Armazenamento do Azure mantém três imagens dos dados por padrão, o uso de RAID 5 ou RAID 1 em vários discos do Azure é desnecessário.
Para obter mais informações, consulte Replicação do Armazenamento do Azure.
Azure Managed Disks
Managed Disks é um tipo de recurso no Gerenciador de Recursos do Azure, é uma opção de armazenamento recomendada em vez de VHDs (discos rígidos virtuais) que são armazenados em contas de armazenamento do Azure. Os discos gerenciados se alinham automaticamente a um conjunto de disponibilidade do Azure da máquina virtual à qual estão conectados. Eles aumentam a disponibilidade da máquina virtual e os serviços que estão sendo executados nela.
Para saber mais, veja Visão geral dos Azure Managed Disks.
Recomendamos que você use discos gerenciados porque eles simplificam a implantação e o gerenciamento de suas máquinas virtuais.
Comparação de diferentes tipos de implantação para carga de trabalho SAP
Aqui está um resumo rápido dos vários tipos de implantação disponíveis para cargas de trabalho SAP.
| Recursos | Conjunto de dimensionamento de máquina virtual com orquestração flexível (FD=1) | Zona de disponibilidade | Conjunto de disponibilidade |
|---|---|---|---|
| Comportamento de implantação | As instâncias chegam a 1, 2 ou 3 zonas de disponibilidade e são distribuídas em diferentes racks dentro de cada zona com base no melhor esforço | As instâncias chegam a 1, 2 ou 3 zonas de disponibilidade | As instâncias são aterrissadas na região e distribuídas em diferentes domínios de falha/atualização |
| Atribuir VM e discos gerenciados a uma zona de disponibilidade específica | Sim | Sim | Não |
| Domínio de falha - Propagação máxima (o Azure espalhará instâncias ao máximo) | Sim | Não | Sim, com base no número de domínios de falha definidos durante a criação. |
| Alinhamento de domínio de falha de computação para armazenamento | Não | No | Sim |
| Reserva de capacidade | Sim (atribuir reserva de capacidade no nível da VM) | Sim | Não |
Observação
- Os domínios de atualização foram preteridos no modo de orquestração flexível. Para obter mais informações, consulte Migrar implantações e recursos para conjuntos de dimensionamento de máquina virtual em orquestração flexível
- Para obter mais informações sobre o alinhamento de domínio de falha de computação para armazenamento, consulte Escolhendo o número certo de domínios de falha para o Conjunto de Dimensionamento de Máquina Virtual e Como funcionam os conjuntos de disponibilidade?.
- Para habilitar a reserva de capacidade, é importante verificar as limitações e restrições da reserva de capacidade.
Opções de implantação de alta disponibilidade para carga de trabalho SAP
Ao implantar uma carga de trabalho SAP de alta disponibilidade no Azure, é importante levar em conta os vários tipos de implantação disponíveis e como eles podem ser aplicados em diferentes regiões do Azure (como entre zonas, em uma única zona ou em uma região sem zonas). A tabela a seguir ilustra várias opções de alta disponibilidade para sistemas SAP em regiões do Azure.
| Tipo do sistema | Em diferentes zonas de uma região | Em uma única zona de uma região | Em uma região sem zonas |
|---|---|---|---|
| Sistema SAP de alta disponibilidade | Conjunto de balança flexível com FD=1 | Conjuntos de disponibilidade com grupos de posicionamento de proximidade | Conjuntos de Disponibilidade |
| Conjuntos de disponibilidade e zonas de disponibilidade com grupos de posicionamento de proximidade | Conjunto de escala flexível com FD=1 (selecione apenas uma zona) | Conjunto de escala flexível com FD=1 (nenhuma zona é definida) | |
| Zonas de Disponibilidade | Conjuntos de Disponibilidade |
- Implantação em diferentes zonas em uma região: para obter a maior disponibilidade, os sistemas SAP devem ser implantados em diferentes zonas de uma região. Isso garante que, se uma zona não estiver disponível, o sistema SAP continuará disponível em outra zona. Se você estiver implantando uma nova carga de trabalho SAP em zonas de disponibilidade, é aconselhável usar escalas de máquina virtual flexíveis definidas com a opção de implantação FD=1. Ele permite que você implante várias VMs em diferentes zonas em uma região sem se preocupar com restrições de capacidade ou grupos de posicionamento. A estrutura do conjunto de escala garante que as VMs implantadas com o conjunto de escala sejam distribuídas entre diferentes domínios de falha dentro da zona da maneira mais adequada. Todos os componentes SAP altamente disponíveis, como SAP ASCS/ERS, bancos de dados SAP, são distribuídos em diferentes zonas, enquanto vários servidores de aplicativos em cada zona são distribuídos em diferentes domínios de falha com base no melhor esforço.
- Implantação em uma única zona de uma região: para implantar seu sistema SAP de alta disponibilidade regionalmente em um local com várias zonas de disponibilidade e, se for essencial que todos os componentes do sistema estejam em uma única zona, é aconselhável usar a opção de implantação de Conjuntos de Disponibilidade com Grupos de Posicionamento de Proximidade. Essa abordagem permite agrupar todos os componentes do sistema SAP em uma única zona de disponibilidade, garantindo que as máquinas virtuais dentro do conjunto de disponibilidade estejam espalhadas por diferentes domínios de falha e atualização. Embora essa implantação alinhe a computação aos domínios de falha de armazenamento, a proximidade não é garantida. No entanto, como essa opção de implantação é regional, ela não oferece suporte ao Azure Site Recovery para recuperação de desastres zona a zona. Além disso, essa opção restringe toda a implantação do SAP a um data center, o que pode levar a limitações de capacidade se você precisar alterar o tamanho da SKU ou as instâncias de aplicativos de expansão.
- Implantação em uma região sem zonas: se você estiver implantando seu sistema SAP em uma região que não tenha zonas, é aconselhável usar conjuntos de disponibilidade. Essa opção fornece redundância e tolerância a falhas colocando VMs em diferentes domínios de falha e domínios de atualização.
Importante
Deve-se notar que as opções de implantação para regiões do Azure são apenas sugestões. A estratégia de implantação mais adequada para seu sistema SAP dependerá de seus requisitos e ambiente específicos.
Utilizando a alta disponibilidade da infraestrutura do Azure para proteger aplicativos SAP
Se você decidir não usar funcionalidades como WSFC ou Pacemaker no Linux (com suporte para SUSE Linux Enterprise Server 12 e posterior e Red Hat Enterprise Linux 7 e posterior), a reinicialização da VM do Azure será utilizada. Ele restaura a funcionalidade nos sistemas SAP se houver algum tempo de inatividade planejado e não planejado da infraestrutura de servidor físico do Azure e da plataforma geral subjacente do Azure.
Para obter mais informações sobre a abordagem, consulte Utilizar a reinicialização da VM de infraestrutura do Azure para obter maior disponibilidade do sistema SAP.
Alta disponibilidade de aplicativos SAP no Azure IaaS
Para obter toda a alta disponibilidade do sistema SAP, você precisa proteger todos os componentes essenciais do sistema SAP. Por exemplo:
- Servidores de aplicativos SAP redundantes.
- Componentes exclusivos. Um exemplo pode ser um componente SPOF (ponto único de falha), como uma instância SAP ASCS/SCS ou um DBMS (sistema de gerenciamento de banco de dados).
As seções a seguir abordam como alcançar alta disponibilidade para todos os três componentes essenciais do sistema SAP.
Arquitetura de alta disponibilidade para servidores de aplicativos SAP
Logotipo do Windows e do
Linux
Normalmente, não é necessária uma solução específica de alta disponibilidade para servidor de aplicativos SAP e instâncias de diálogo. Você atinge alta disponibilidade por redundância e configura várias instâncias de caixa de diálogo em várias instâncias de máquinas virtuais do Azure. Você deve ter pelo menos duas instâncias do aplicativo SAP instaladas em duas máquinas virtuais do Azure.
Dependendo do tipo de implantação (conjunto de escala flexível com FD=1, zona de disponibilidade ou conjunto de disponibilidade), você deve distribuir suas instâncias do servidor de aplicativos SAP de acordo para obter redundância.
- Conjunto de escala flexível com platformFaultDomainCount=1 (FD=1): os servidores de aplicativos SAP implantados com conjunto de escala flexível (FD=1) distribuem as máquinas virtuais em diferentes zonas de disponibilidade e o conjunto de escalas também distribuiria VMs em diferentes domínios de falha dentro de cada zona com base no melhor esforço. Isso garante que, se uma zona não estiver disponível, os servidores de aplicativos SAP implantados em outra zona continuarão disponíveis.
- Zona de disponibilidade: os servidores de aplicativos SAP implantados em zonas de disponibilidade garantem que as VMs sejam estendidas em diferentes zonas para obter redundância. Isso garante que, se uma zona não estiver disponível, os servidores de aplicativos SAP implantados em outra zona continuarão disponíveis. Para obter mais informações, consulte Configurações de carga de trabalho SAP com zonas de disponibilidade do Azure
- Conjunto de disponibilidade: os servidores de aplicativos SAP implantados no conjunto de disponibilidade garantem que as VMs sejam distribuídas entre diferentes domínios de falha e domínios de atualização. Ao colocar VMs em diferentes domínios de atualização, certifique-se de que as VMs não sejam atualizadas ao mesmo tempo durante o tempo de inatividade de manutenção planejado. Considerando que, colocar VMs em domínio de falha diferente garante que a VM esteja protegida contra falhas de hardware ou interrupções de energia em um data center. Mas o número de domínios de falha e atualização que você pode usar no conjunto de disponibilidade do Azure em uma unidade de escala do Azure é finito. Se você continuar adicionando VMs a um único conjunto de disponibilidade, duas ou mais VMs acabarão no mesmo domínio de falha ou atualização. Para saber mais, confira a seção Conjuntos de disponibilidade do Azure do documento de planejamento e implantação de máquinas virtuais do Azure para SAP NetWeaver.
Somente discos não gerenciados: ao usar discos não gerenciados com disponibilidade definida, é importante reconhecer que a conta de armazenamento do Azure se torna um único ponto de falha. Portanto, é imperativo possuir um mínimo de duas contas de armazenamento do Azure, nas quais pelo menos duas máquinas virtuais são distribuídas. Em uma configuração ideal, os discos de cada máquina virtual que está executando uma instância de diálogo SAP deveria ser implantada em uma conta de armazenamento diferente.
Importante
Recomendamos que você use os discos gerenciados do Azure nas instalações de alta disponibilidade do SAP. Como os discos gerenciados alinham-se automaticamente ao conjunto de disponibilidade da máquina virtual à qual eles estão conectados, eles aumentam a disponibilidade da sua máquina virtual e dos serviços que estão em execução nela.
Arquitetura de alta disponibilidade para uma instância do SAP ASCS/SCS no Windows
Você pode usar uma solução WSFC para proteger a instância SAP ASCS/SCS. Com base no tipo de configuração de compartilhamento de cluster (compartilhamento de arquivos ou disco compartilhado), você pode consultar a solução apropriada com base no seu tipo de armazenamento.
Compartilhamento de cluster - Compartilhamento de arquivos
Compartilhamento de cluster - Disco compartilhado
Arquitetura de alta disponibilidade para uma instância do SAP ASCS/SCS no Linux
No Linux, a configuração do cluster de instâncias SAP ASCS/SCS depende da distribuição do sistema operacional e do tipo de armazenamento que está sendo usado. É recomendável implementar a solução adequada de acordo com sua estrutura de cluster de sistema operacional específica.
SUSE Linux Enterprise Server (SLES)
- Alta disponibilidade da instância SAP ASCS/SCS usando NFS com montagem simples.
- Alta disponibilidade da instância SAP ASCS/SCS usando NFS em arquivos do Azure.
- Alta disponibilidade da instância SAP ASCS/SCS usando NFS nos Arquivos NetApp do Azure.
- Alta disponibilidade da instância SAP ASCS/SCS usando o NFS Server.
Red Hat Enterprise Linux (RHEL)
Configuração multi-SID do SAP NetWeaver para uma instância do SAP ASCS/SCS em cluster
Há suporte para multi-SID com o WSFC usando o compartilhamento de arquivos e o disco compartilhado. Para obter mais informações sobre a arquitetura de alta disponibilidade multi-SID, confira:
- Compartilhamento de arquivos: alta disponibilidade de vários SID de instância SAP ASCS/SCS para Clustering de Failover do Windows Server e compartilhamento de arquivos.
- Disco compartilhado: alta disponibilidade multi-SID da instância SAP ASCS/SCS para Clustering de Failover do Windows Server e disco compartilhado.
Há suporte para o clustering multi-SID em clusters Linux Pacemaker para SAP ASCS/ERS, limitado a cinco SIDs da SAP no mesmo cluster. Para saber mais sobre a arquitetura de alta disponibilidade multi-SID, confira:
- SUSE Linux Enterprise Server (SLES): HA para SAP NW em VMs do Azure no SLES para aplicativos SAP guia multi-SID.
- Red Hat Linux Enterprise (RHEL): HA para SAP NW em VMs do Azure no RHEL para aplicativos SAP guia multi-SID.
Alta disponibilidade da instância do DBMS
Em um sistema SAP, os servidores DBMS também são o único ponto de falha. Portanto, é importante proteger o banco de dados implementando uma solução de alta disponibilidade. A solução de alta disponibilidade do SGBD varia de acordo com o banco de dados utilizado para o sistema SAP. Com base no banco de dados, siga as diretrizes para obter alta disponibilidade no banco de dados.
| Banco de dados | Recomendação de DR |
|---|---|
| SAP HANA | HSR (Replicação do Sistema HANA) |
| Oracle | Oracle Data Guard |
| IBM DB2 | HADR (Alta Disponibilidade e Recuperação de Desastre) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | ASE HADR Always On |