Disponibilidade do SAP HANA em todas as regiões do Azure
Este artigo descreve cenários relacionados à disponibilidade do SAP HANA em diferentes regiões do Azure. Devido à distância entre as regiões do Azure, configurar a disponibilidade do SAP HANA em várias regiões do Azure envolve considerações especiais.
Por que implantar em várias regiões do Azure
As regiões do Azure geralmente são separadas por grandes distâncias. Dependendo da região geopolítica, a distância entre as regiões do Azure pode ser de centenas de milhas, ou até mesmo vários milhares de milhas, como nos Estados Unidos. Devido à distância, o tráfego de rede entre ativos implantados em duas regiões diferentes do Azure experimenta latência de ida e volta de rede significativa. A latência é significativa o suficiente para excluir a troca de dados síncrona entre duas instâncias do SAP HANA em cargas de trabalho SAP típicas.
Por outro lado, as organizações geralmente têm um requisito de distância entre o local do datacenter primário e um datacenter secundário. Um requisito de distância ajuda a fornecer disponibilidade se ocorrer um desastre natural em uma localização geográfica mais ampla. Exemplos incluem os furacões que atingiram o Caribe e a Flórida em setembro e outubro de 2017. Sua organização pode ter pelo menos um requisito de distância mínima. Para a maioria dos clientes do Azure, uma definição de distância mínima exige que você projete para disponibilidade em todas as regiões do Azure. Como a distância entre duas regiões do Azure é muito grande para usar o modo de replicação síncrona HANA, os requisitos de RTO e RPO podem forçá-lo a implantar configurações de disponibilidade em uma região e, em seguida, complementar com implantações adicionais em uma segunda região.
Outro aspeto a considerar neste cenário é o failover e o redirecionamento do cliente. A suposição é que um failover entre instâncias do SAP HANA em duas regiões diferentes do Azure sempre é um failover manual. Como o modo de replicação do sistema SAP HANA está definido como assíncrono, há um potencial de que os dados confirmados na instância HANA primária ainda não tenham chegado à instância HANA secundária. Portanto, o failover automático não é uma opção para configurações em que a replicação é assíncrona. Mesmo com failover controlado manualmente, como em um exercício de failover, você precisa tomar medidas para garantir que todos os dados confirmados no lado primário cheguem à instância secundária antes de passar manualmente para a outra região do Azure.
A Rede Virtual do Azure usa um intervalo de endereços IP diferente. Os endereços IP são implantados na segunda região do Azure. Portanto, você precisa alterar a configuração do cliente SAP HANA ou, de preferência, precisa criar etapas para alterar a resolução de nomes. Desta forma, os clientes são redirecionados para o novo endereço IP do servidor do site secundário. Para obter mais informações, consulte o artigo SAP Client connection recovery after takeover.
Disponibilidade simples entre duas regiões do Azure
Você pode optar por não colocar nenhuma configuração de disponibilidade em uma única região, mas ainda ter a demanda de ter a carga de trabalho atendida se ocorrer um desastre. Casos típicos para tais cenários são sistemas de não-produção. Embora ter o sistema inativo por meio dia ou até mesmo um dia seja sustentável, você não pode permitir que o sistema fique indisponível por 48 horas ou mais. Para tornar a configuração menos dispendiosa, execute outro sistema que seja ainda menos importante na VM. O outro sistema funciona como um destino. Você também pode dimensionar a VM na região secundária para ser menor e optar por não pré-carregar os dados. Como o failover é manual e envolve muitas outras etapas para fazer failover de toda a pilha de aplicativos, o tempo adicional para desligar a VM, redimensioná-la e reiniciar a VM é aceitável.
Se você estiver usando o cenário de compartilhar o destino de DR com um sistema de controle de qualidade em uma VM, precisará levar estas considerações em consideração:
- Existem dois modos de operação com delta_datashipping e logreplay, que estão disponíveis para tal cenário
- Ambos os modos de operação têm requisitos de memória diferentes sem pré-carregar dados
- Delta_datashipping pode exigir drasticamente menos memória sem a opção de pré-carregamento do que o logreplay poderia exigir. Consulte o capítulo 4.3 do documento SAP How To Perform System Replication for SAP HANA
- O requisito de memória do modo de operação logreplay sem pré-carregamento não é determinístico e depende das estruturas columnstore carregadas. Em casos extremos, você pode precisar de 50% da memória da instância primária. A memória para o modo de operação logreplay é independente se você escolheu ter os dados pré-carregados definidos ou não.
Nota
Nessa configuração, não é possível fornecer um RPO=0 porque o modo de replicação do sistema HANA é assíncrono. Se você precisar fornecer um RPO=0, essa configuração não é a configuração preferida.
Uma pequena alteração que você pode fazer na configuração pode ser configurar os dados como pré-carregamento. No entanto, dada a natureza manual do failover e o fato de que as camadas de aplicativo também precisam ser movidas para a segunda região, pode não fazer sentido pré-carregar dados.
Combine a disponibilidade dentro de uma região e entre regiões
Uma combinação de disponibilidade dentro e entre regiões pode ser impulsionada pelos seguintes fatores:
- Um requisito de RPO=0 dentro de uma região do Azure.
- A organização não está disposta ou capaz de ter operações globais afetadas por uma grande catástrofe natural que afeta uma região maior. Foi o caso de alguns furacões que atingiram as Caraíbas nos últimos anos.
- Regulamentos que exigem distâncias entre sites primários e secundários que estão claramente além do que as zonas de disponibilidade do Azure podem fornecer.
Nesses casos, você pode configurar o que o SAP chama de configuração de replicação de sistema multicamadas do SAP HANA usando a replicação do sistema HANA. A arquitetura seria parecida com:
A SAP introduziu a replicação de sistemas de vários destinos com o HANA 2.0 SPS3. A replicação de sistemas de vários destinos traz algumas vantagens em cenários de atualização. Por exemplo, o site de DR (Região 2) não é afetado quando o site de HA secundário está inativo para manutenção ou atualizações. Você pode saber mais sobre a replicação do sistema HANA de vários destinos no SAP Help Portal. A arquitetura possível com replicação de vários destinos seria semelhante a:
Se a organização tiver requisitos de prontidão para alta disponibilidade na segunda região (DR) do Azure, a arquitetura terá a seguinte aparência:
Usando logreplay como modo de operação, essa configuração fornece um RPO=0, com baixo RTO, dentro da região primária. A configuração também fornece RPO decente se uma mudança para a segunda região estiver envolvida. Os tempos de RTO na segunda região dependem se os dados são pré-carregados. Muitos clientes usam a VM na região secundária para executar um sistema de teste. Nesse caso de uso, os dados não podem ser pré-carregados.
Importante
Os modos de operação entre os diferentes níveis precisam ser homogêneos. Não é possível usar o logreplay como modo de operação entre a camada 1 e a camada 2 e delta_datashipping para fornecer a camada 3. Você só pode escolher um ou outro modo de operação que precisa ser consistente para todas as camadas. Como delta_datashipping não é adequado para fornecer um RPO=0, o único modo de operação razoável para tal configuração de várias camadas continua sendo o logreplay. Para obter detalhes sobre os modos de operação e algumas restrições, consulte o artigo SAP Operation modes for SAP HANA system replication.
Próximos passos
Para obter orientação passo a passo sobre como configurar essas configurações no Azure, consulte: