A figura a seguir mostra a visão lógica da comunicação entre o servidor SnapCenter , o banco de dados SAP HANA e o sistema de armazenamento. O servidor SnapCenter utiliza o HANA e os plug-ins do Linux para se comunicar com o banco de dados HANA e os sistemas operacionais Linux.

A opção de implantação recomendada e padrão para os plug-ins do SnapCenter é a instalação no host do banco de dados HANA. Com essa opção de implantação, todas as configurações e recursos descritos no capítulo Configuração compatível com o SnapCenter são válidos. Existem algumas exceções em que os plug-ins do SnapCenter não podem ser instalados no host do banco de dados HANA, mas precisam ser configurados em um host central de plug-ins, que pode ser o próprio servidor SnapCenter . É necessário um host central de plug-in para sistemas HANA com múltiplos hosts ou sistemas HANA executados na plataforma IBM Power. Ambas as opções de implantação também podem ser combinadas, por exemplo, usando o servidor SnapCenter como um host central de plug-ins para um sistema com vários hosts e implantando os plug-ins nos hosts do banco de dados HANA para todos os outros sistemas HANA de host único.

No SnapCenter, um recurso HANA pode ser descoberto automaticamente ou configurado manualmente. Por padrão, um sistema HANA é descoberto automaticamente assim que os plug-ins HANA e Linux são implantados no host do banco de dados. A descoberta automática do SnapCenter não suporta várias instalações do HANA no mesmo host. Os sistemas HANA gerenciados por meio de um host plug-in central devem ser configurados manualmente no SnapCenter. Além disso, os volumes que não contêm dados são, por padrão, recursos configurados manualmente.

Embora o SnapCenter ofereça suporte a uma implantação centralizada de plug-ins para sistemas HANA, existem limitações em termos de suporte a plataformas e recursos. As seguintes configurações e operações de infraestrutura não são suportadas para sistemas HANA configurados com um host plug-in central:

A SAP recomenda incluir verificações regulares de consistência de blocos do HANA na estratégia geral de backup. Com backups tradicionais baseados em arquivos, essa verificação é feita a cada operação de backup. Com backups de snapshot, a verificação de consistência deve ser executada além das operações de backup de snapshot, por exemplo, uma vez por semana.

Tecnicamente, existem duas opções para executar a verificação de consistência de bloco.

A ferramenta hdbpersdiag do HANA faz parte da instalação do HANA e permite executar operações de verificação de consistência de blocos em um banco de dados HANA offline. Portanto, é ideal para ser usado em conjunto com backups de Snapshot, onde os backups de Snapshot existentes podem ser apresentados ao hdbpersdiag.

Ao comparar as duas abordagens, o hdbpersdiag apresenta vantagens significativas em relação ao backup baseado em arquivos para verificações de consistência de blocos do HANA. Uma das dimensões é a capacidade de armazenamento necessária. Com backups baseados em arquivos, é necessário que haja espaço disponível pelo menos no tamanho de um backup para cada sistema HANA. Se você tiver, por exemplo, 15 sistemas HANA com um tamanho de persistência de 3 TB, precisará de mais 45 TB apenas para as verificações de consistência. Com o hdbpersdiag, não é necessária capacidade de armazenamento adicional, pois a operação é executada em um backup Snapshot existente ou em um FlexClone de um backup Snapshot existente. A segunda dimensão é a carga da CPU no host HANA durante a operação de verificação de consistência. Um backup baseado em arquivos exigirá ciclos de CPU no host do banco de dados HANA, enquanto o processamento do hdbpersdiag pode ser totalmente descarregado do host HANA quando usado em combinação com um host de verificação central. A tabela abaixo resume as principais características.

A NetApp recomenda o uso do hdbpersdiag para executar verificações de consistência de blocos do HANA. Mais detalhes sobre a implementação estão disponíveis no capítulo "Verificações de consistência de blocos com o SnapCenter".

Antes de configurar o SnapCenter e o plug-in SAP HANA, a estratégia de proteção de dados deve ser definida com base nos requisitos de rto e RPO dos vários sistemas SAP.

Uma abordagem comum é definir tipos de sistemas como produção, desenvolvimento, teste ou sistemas sandbox. Todos os sistemas SAP do mesmo tipo de sistema normalmente têm os mesmos parâmetros de proteção de dados.

Os parâmetros que devem ser definidos são:

A tabela a seguir mostra um exemplo de parâmetros de proteção de dados para os tipos de sistema produção, desenvolvimento e teste. Para o sistema de produção, foi definida uma alta frequência de backup, e os backups são replicados para um site de backup secundário uma vez por dia. Os sistemas de teste têm requisitos mais baixos e não realizam replicação dos backups.

A tabela a seguir mostra as políticas e os agendamentos que precisariam ser configurados para os parâmetros de proteção de dados acima.

A figura abaixo resume os cronogramas e os períodos de retenção de backups. Se o SnapCenter for usado para gerenciar a retenção de backups de log, todos os backups de log mais antigos que o backup de Snapshot mais antigo serão excluídos. Em outras palavras, os backups de log são mantidos pelo tempo necessário para permitir a recuperação até o ponto atual, para cada backup disponível.

Quando a criptografia de persistência do HANA é utilizada, é fundamental criar backups das chaves raiz, além dos backups de dados padrão. É necessário fazer backup da chave raiz para recuperar o banco de dados HANA caso o volume de dados e o sistema de arquivos de instalação do HANA sejam perdidos. Para obter mais informações, consulte "Guia de administração do SAP HANA".

O SnapCenter oferece suporte a operações de backup de snapshots de sistemas HANA MDC com um único locatário ou com vários locatários. O SnapCenter também oferece suporte a duas operações de restauração diferentes de um sistema HANA MDC. Você pode restaurar o sistema completo, o banco de dados do sistema e todos os tenants, ou pode restaurar apenas um tenant. Existem alguns pré-requisitos para permitir que o SnapCenter execute essas operações.

Em um sistema MDC, a configuração do locatário não é necessariamente estática. É possível adicionar ou remover inquilinos. O SnapCenter não pode confiar na configuração descoberta quando o banco de dados HANA é adicionado ao SnapCenter. Para permitir uma operação de restauração de locatário único, o SnapCenter precisa saber quais locatários estão incluídos em cada backup de Snapshot. Além disso, precisa saber quais arquivos e diretórios pertencem a cada locatário incluído no backup do Snapshot.

Portanto, a cada operação de backup, o SnapCenter identifica as informações do locatário. Isso inclui os nomes dos inquilinos e as informações correspondentes de arquivos e diretórios. Esses dados devem ser armazenados nos metadados de backup do Snapshot para que seja possível realizar uma operação de restauração em um único locatário.

Outra etapa da descoberta automática de aplicativos é a detecção do nó primário ou secundário do HANA System Replication (HSR). Se um sistema HANA estiver configurado com HSR, o SnapCenter deve identificar o nó primário em cada operação de backup para que os comandos SQL de backup sejam executados no nó primário do HSR. Veja também "Replicação do sistema SAP HANA: Backup e recuperação com o SnapCenter".

O SnapCenter também detecta a configuração do volume de dados do HANA e a mapeia para o sistema de arquivos e recursos de armazenamento. Com essa abordagem, o SnapCenter consegue lidar com alterações na configuração de volumes do HANA, como múltiplas partições ou alterações na configuração de armazenamento, como migrações de volumes.

O próximo passo é a própria operação de backup do Snapshot. Esta etapa inclui o comando SQL para acionar o snapshot do banco de dados HANA, o backup do snapshot de armazenamento e o comando SQL para encerrar a operação de snapshot do HANA. Ao usar o comando close, o banco de dados HANA atualiza o catálogo de backup do banco de dados do sistema e de cada locatário.

Para o gerenciamento da retenção de backups de dados e o gerenciamento do catálogo de backup HANA, a SnapCenter deve executar as operações de exclusão de catálogo para o banco de dados do sistema e todos os bancos de dados de locatários identificados na primeira etapa. Da mesma forma para os backups de log, o fluxo de trabalho do SnapCenter deve operar em cada locatário que fazia parte da operação de backup.

A figura a seguir mostra uma visão geral do fluxo de trabalho de backup.

O gerenciamento de retenção de backup de dados e o gerenciamento de backup de log podem ser divididos em cinco áreas principais, incluindo o gerenciamento de retenção de:

A figura a seguir fornece uma visão geral dos diferentes fluxos de trabalho e das dependências de cada operação. As seções a seguir descrevem as diferentes operações em detalhes.