Hace tiempo desde el último blog, pero decidí escribir un seguimiento a mi blog
High Availability Explained
para hablar sobre los detalles de la oferta de alta disponibilidad para SAP HANA 2.0.
Desde el punto de vista de S/4 (ou qualquer outro produto que execute no HANA), a arquitetura geral permanece intacta, ainda há uma instância ASCS, AS e um banco de dados, a principal diferença é que o HANA é executado em hardware dedicado, o que significa que os sistemas estão sempre distribuídos (CI e DB em servidores diferentes).
Então, como tornamos o HANA altamente disponível?
No nível mais básico, você precisa de dois bancos de dados HANA, idealmente em dispositivos separados, um servindo como primário e o outro como secundário... até aqui tudo bem... aqui é onde as coisas ficam interessantes, o HANA oferece uma série de modos de replicação para o envio de registros para o banco de dados secundário, que é basicamente a forma como os registros são tratados, replicados e confirmados pelo banco de dados secundário.
Quais são as opções de Modo de Replicação?
Síncrono (SYNC)
,
Principalmente utilizado em cenários onde os dispositivos estão no mesmo data center ou muito próximos, neste modo o banco de dados secundário envia ao primário uma confirmação quando o registro é recebido e escrito no disco, somente então o primário confirma os dados. Existe um ajuste adicional chamado
Full Sync
, essa opção é uma extensão do modo Síncrono, que considera bem-sucedida a gravação de registros somente quando o buffer de registros é gravado tanto no banco de dados primário quanto no secundário.
Síncrono em memória (SYNCMEM)
, igual ao acima, mas a confirmação é enviada ao primário quando os dados são recebidos na memória, isso tem uma vantagem significativa em termos de desempenho, pois o banco secundário não precisa esperar os dados serem gravados no disco, assim como o modo Síncrono, isso é projetado para ser usado em bancos de dados em proximidade próxima.
Assíncrono (ASYNC)
, vai ainda mais longe, o registro é enviado ao banco de dados secundário e não requer nenhuma confirmação antes que os dados sejam confirmados no primário, por isso esse é o modo preferido para replicar registros em um banco de dados de recuperação de desastres geralmente localizado em um local remoto.
Você pode ler mais detalhes sobre isso em
SAP Help - Modos de Replicação para a Replicação do Sistema SAP HANA
Isso é tudo?... Não, você também precisa escolher seu modo de operação
Os modos de operação são simplesmente a forma como a replicação opera e devem ser escolhidos ao registrar o banco de dados secundário, existem 3 modos de operação para escolher:
delta_datashipping
, exatamente como parece, ocorre um delta dos dados além do envio contínuo de registros, executa e aplica um delta usando um intervalo definido (por padrão, é de 10 minutos), envia uma coleção de dados para o sistema secundário e são aplicados juntamente com os registros, na prática isso tem mais contras do que prós, o delta datashipping cria picos na transferência de dados e também significa que, se houver um problema, haverá tempo de recuperação adicional, pois você precisará reproduzir os registros até o último delta.
logreplay
, neste modo os registros de refazer são reproduzidos continuamente no sistema secundário, o que significa que, se houver um problema, o secundário pode assumir o controle imediatamente, como bônus, o fluxo de dados transferidos é constante e, como só precisa de um envio inicial completo de dados, a quantidade de dados transferidos é consideravelmente reduzida.
logreplay_readaccess
, isso é exatamente igual ao logreplay, mas o acesso de leitura ao sistema secundário fica disponível. Isso só é usado em sistemas secundários ativos/ativos (com leitura habilitada), o que é uma característica que permite que o banco de dados secundário seja consultado, por exemplo, para relatórios. (Essa função requer licenças adicionais)
Você pode ler mais detalhes sobre isso em
SAP Help - Modos de Operação