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.
Uso da 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 restaurará a funcionalidade nos sistemas SAP se houver algum tempo de inatividade planejado e não planejado da infraestrutura do 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 sapinst integrada ao SAP para Linux como há para 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 nº 1/100) x (Serviço de Disponibilidade nº 2/100) x (Serviço de Disponibilidade nº 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 tenham 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 energia comum e um comutador de rede. 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, confira gerenciar a disponibilidade de máquinas virtuais no Azure usando conjuntos 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 as 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, confira o artigo Combinar conjuntos de disponibilidade e zonas de disponibilidade com grupos de posicionamento por 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 a SKU do Azure Standard Load Balancer.
- As Zonas de Disponibilidade do Azure não estão dando garantias de determinada 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, poderia executar razoavelmente a camada de aplicativo SAP implantada em diferentes zonas, uma vez que a latência de rede de uma zona para a VM DBMS ativa ainda é aceitável devido a um impacto no processo de negócios. Considerando que pode haver cenários de clientes 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áquinas Virtuais com Orquestração Flexível
No Azure, os Conjuntos de Dimensionamento de Máquinas Virtuais com orquestração flexível oferecem um meio de alcançar 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áquinas virtuais com orquestração flexível oferece a flexibilidade para criar o conjunto de dimensionamento dentro de uma região ou estendê-lo para diferentes zonas de disponibilidade. Ao criar o conjunto de dimensionamento flexível em uma região com platformFaultDomainCount>1 (FD>1), as VMs implantadas no conjunto de dimensionamento seriam distribuídas por um número especificado de domínios de falha na mesma região. Por outro lado, a criação do conjunto de dimensionamento flexível entre zonas de disponibilidade com platformFaultDomainCount=1 (FD=1) distribuiria as VMs em diferentes zonas e o conjunto de dimensionamento também distribuiria VMs em diferentes domínios de falha dentro de cada zona na base do melhor esforço. Para a carga de trabalho do SAP, há suporte apenas para o conjunto de dimensionamento flexível com FD=1.
A vantagem de usar conjuntos de dimensionamento flexíveis com FD=1 para implantação entre zonas, em vez da implantação tradicional da zona de disponibilidade, é que as VMs implantadas com o conjunto de dimensionamento seriam distribuídas por diferentes domínios de falha dentro da zona da melhor maneira possível. Para evitar as limitações associadas à utilização do grupo de posicionamento por proximidade para garantir a disponibilidade de VMs em todos os datacenters do Azure ou em cada espinha de rede, é recomendável implantar a carga de trabalho SAP entre zonas de disponibilidade usando um conjunto de dimensionamento flexível com FD=1. Esta estratégia de implantação garante que as VMs implantadas em cada zona não sejam restritas a um único datacenter ou coluna de rede, e todos os componentes do sistema SAP, como bancos de dados, ASCS/ERS e camada de aplicativo, estejam no escopo em nível zonal.
Portanto, para uma nova implantação de carga de trabalho SAP em zonas de disponibilidade, aconselhamos usar o conjunto de dimensionamento flexível com FD=1. Para obter mais informações, consulte o documento conjunto de dimensionamento de máquinas virtuais para a 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, confira 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 Azure Resource Manager, uma opção de armazenamento recomendada em vez de discos rígidos virtuais (VHDs) armazenados em contas de armazenamento do Azure. Os discos gerenciados se alinham automaticamente com um conjunto de disponibilidade do Azure da máquina virtual à qual estão anexados. 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 a carga de trabalho do SAP
Aqui está um resumo rápido dos vários tipos de implantação que estão disponíveis para cargas de trabalho do SAP.
| Recursos | Conjunto de Dimensionamento de Máquinas Virtuais com Orquestração Flexível (FD=1) | Zona de disponibilidade | Conjunto de disponibilidade |
|---|---|---|---|
| Comportamento de implantação | As instâncias chegam em 1, 2 ou 3 zonas de disponibilidade e são distribuídas entre racks diferentes dentro de cada zona na base do melhor esforço | As instâncias chegam a 1, 2 ou 3 zonas de disponibilidade | As instâncias chegam à região e são distribuídas em diferentes domínios de falha/atualização |
| Atribuir VM e discos gerenciados a uma zona de disponibilidade específica | Sim | Sim | No |
| Domínio de falha – propagação máxima (o Azure espalhará as instâncias o máximo) | Sim | No | Sim, com base no número de domínios de falha definidos durante a criação. |
| Computação para o alinhamento do domínio de falha de 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, confira Migrar implantações e recursos para Conjuntos de Dimensionamento de Máquinas Virtuais em orquestração flexível
- Para obter mais informações sobre a computação para o alinhamento de domínio de falha de armazenamento, confira Escolher o número correto de domínios de falha para o conjunto de dimensionamento de máquinas virtuais 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 a carga de trabalho do 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 | Entre diferentes zonas em uma região | Em uma única zona de uma região | Em uma região sem zonas |
|---|---|---|---|
| Sistema SAP de alta disponibilidade | Conjunto de dimensionamento flexível com FD=1 | Conjuntos de disponibilidade com grupos de posicionamento por proximidade | Conjuntos de Disponibilidade |
| Conjuntos de disponibilidade e Zonas de Disponibilidade com grupos de posicionamento por proximidade | Conjunto de dimensionamento flexível com FD=1 (selecione apenas uma zona) | Conjunto de dimensionamento flexível com FD=1 (nenhuma zona definida) | |
| Zonas de Disponibilidade | Conjuntos de Disponibilidade |
- Implantação em diferentes zonas em uma região: para a maior disponibilidade, os sistemas SAP devem ser implantados em diferentes zonas em 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 entre zonas de disponibilidade, é recomendável usar escalas de máquina virtual flexíveis definidas com a opção de implantação FD=1. Isso permite implantar 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 dimensionamento garante que as VMs implantadas com o conjunto de dimensionamento sejam distribuídas entre diferentes domínios de falha dentro da zona na base do melhor esforço. Todos os componentes SAP de alta disponibilidade, como SAP ASCS/ERS, bancos de dados SAP são distribuídos entre zonas diferentes, enquanto vários servidores de aplicativos em cada zona são distribuídos em diferentes domínios de falha na base do melhor esforço.
- Implantação em uma única zona de uma região: para implantar o 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, é recomendável usar conjuntos de disponibilidade com a opção de implantação Grupos de Posicionamento por Proximidade. Esta abordagem permite que você agrupe todos os componentes do sistema SAP em uma única zona de disponibilidade, garantindo que as máquinas virtuais dentro do conjunto de disponibilidade sejam distribuídas entre diferentes domínios de falha e atualização. Embora esta implantação alinhe a computação aos domínios de falha de armazenamento, a proximidade não é garantida. No entanto, como esta opção de implantação é regional, ela não dá suporte ao Azure Site Recovery para recuperação de desastre zona a zona. Além disso, esta 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 aplicativo de expansão.
- Implantação em uma região sem zonas: se você estiver implantando o seu sistema SAP em uma região que não tenha zonas, é recomendável usar conjuntos de disponibilidade. Esta 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 observar 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 o seu sistema SAP dependerá de seus requisitos e ambiente específicos.
Uso de 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 restaurará a funcionalidade nos sistemas SAP se houver algum tempo de inatividade planejado e não planejado da infraestrutura do servidor físico do Azure e da plataforma geral subjacente do Azure.
Para obter mais informações sobre a abordagem, confira 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 dimensionamento flexível com FD=1, zona de disponibilidade ou conjunto de disponibilidade), você deve distribuir as instâncias do servidor de aplicativos SAP adequadamente para obter redundância.
- Conjunto de dimensionamento flexível com platformFaultDomainCount=1 (FD=1): os servidores de aplicativos SAP implantados com o conjunto de dimensionamento flexível (FD=1) distribuem as máquinas virtuais em diferentes zonas de disponibilidade e o conjunto de dimensionamento também distribui as VMs entre diferentes domínios de falha em 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 continuem disponíveis.
- Zona de disponibilidade: os servidores de aplicativos SAP implantados entre zonas de disponibilidade garantem que as VMs se esteram por 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 continuem disponíveis. Para obter mais informações, confira Configurações de carga de trabalho do 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 em 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 planejada. Enquanto que colocar VMs em um 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 o conjunto de disponibilidade, é importante reconhecer que a conta de armazenamento do Azure se torna um único ponto de falha. Portanto, é fundamental ter 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 em 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 clustering de instância do 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 do sistema operacional específica.
SUSE Linux Enterprise Server (SLES)
- Alta disponibilidade da instância do SAP ASCS/SCS usando NFS com montagem simples.
- Alta disponibilidade da instância do SAP ASCS/SCS usando o NFS nos Arquivos do Azure.
- Alta disponibilidade da instância do SAP ASCS/SCS usando o NFS no Azure NetApp Files.
- Alta disponibilidade da instância do SAP ASCS/SCS usando o servidor NFS.
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 SIDs da instância do SAP ASCS/SCS para clustering de failover do Windows Server e compartilhamento de arquivos.
- Disco compartilhado: alta disponibilidade de vários SIDs da instância do 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): Guia multi-SID de HA para SAP NW em VMs do Azure em SLES para aplicativos SAP.
- RHEL (Red Hat Linux Enterprise): Guia multi-SID de HA para SAP NW em VMs do Azure no RHEL para aplicativos SAP.
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 a solução de alta disponibilidade. A solução de alta disponibilidade do DBMS varia de acordo com o banco de dados usado para o sistema SAP. Com base em seu banco de dados, siga as diretrizes para obter alta disponibilidade em seu 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 |