TR-4614: Backup e recuperação do SAP HANA com o SnapCenter
Sugerir alterações
PDFs
Hoje, as empresas exigem disponibilidade contínua e ininterrupta para suas aplicações SAP. Elas esperam níveis de performance consistentes diante de volumes cada vez maiores de dados e da necessidade de tarefas de manutenção de rotina, como backups do sistema. Realizar backups de bancos de dados SAP é uma tarefa crítica e pode ter um efeito significativo no desempenho do sistema SAP de produção.
Autor: Nils Bauer, NetApp
As janelas de backup estão encolhendo, enquanto a quantidade de dados a serem copiados está aumentando. Portanto, é difícil encontrar um momento em que os backups podem ser realizados com o mínimo efeito nos processos de negócios. O tempo necessário para restaurar e recuperar os sistemas SAP é uma preocupação, porque o tempo de inatividade para sistemas de produção e não produção SAP precisa ser minimizado para reduzir a perda de dados e o custo para os negócios.
Os pontos a seguir resumem os desafios enfrentados pelo backup e recuperação SAP:
-
* Efeitos de desempenho em sistemas SAP de produção.* Normalmente, os backups tradicionais baseados em cópia criam um consumo significativo de desempenho em sistemas SAP de produção devido às cargas pesadas colocadas no servidor de banco de dados, no sistema de storage e na rede de storage.
-
* Janelas de backup encolhidas.* Os backups convencionais só podem ser feitos quando poucas atividades de diálogo ou lote estão em andamento no sistema SAP. O agendamento de backups torna-se mais difícil quando os sistemas SAP estão em uso 24 horas por dia.
-
Rápido crescimento de dados. O rápido crescimento de dados e a diminuição dos períodos de backup exigem um investimento contínuo na infraestrutura de backup. Em outras palavras, você deve adquirir mais unidades de fita, espaço em disco de backup adicional e redes de backup mais rápidas. Você também deve cobrir as despesas contínuas de armazenamento e gerenciamento desses ativos de fita. Backups incrementais ou diferenciais podem resolver esses problemas, mas esse arranjo resulta em um processo de restauração muito lento, complicado e complexo que é mais difícil de verificar. Esses sistemas geralmente aumentam os tempos de objetivo de tempo de recuperação (rto) e objetivo do ponto de restauração (RPO) de maneiras que não são aceitáveis para os negócios.
-
Aumento do custo do tempo de inatividade. O tempo de inatividade não planejado de um sistema SAP geralmente afeta as finanças da empresa. Uma parte significativa de qualquer tempo de inatividade não planejado é consumida pelo requisito de restaurar e recuperar o sistema SAP. Portanto, o rto desejado dita o design da arquitetura de backup e recuperação.
-
Tempo de backup e recuperação para projetos de atualização SAP. O plano de projeto para uma atualização SAP inclui pelo menos três backups do banco de dados SAP. Esses backups reduzem significativamente o tempo disponível para o processo de atualização. A decisão de prosseguir é geralmente baseada no tempo necessário para restaurar e recuperar o banco de dados do backup criado anteriormente. Em vez de apenas restaurar um sistema para o seu estado anterior, uma restauração rápida fornece mais tempo para resolver problemas que podem ocorrer durante uma atualização.
A solução NetApp
A tecnologia NetApp Snapshot pode ser usada para criar backups de bancos de dados em minutos. O tempo necessário para criar uma cópia Snapshot não depende do tamanho do banco de dados, pois a cópia Snapshot não move blocos de dados físicos na plataforma de storage. Além disso, o uso da tecnologia Snapshot não afeta a performance do sistema SAP ao vivo, pois a tecnologia NetApp Snapshot não move nem copia blocos de dados quando a cópia Snapshot é criada ou quando os dados no sistema de arquivos ativo são alterados. Portanto, a criação de cópias Snapshot pode ser programada sem considerar períodos de atividade de lote ou diálogos de pico. Em geral, os clientes da SAP e da NetApp agendam vários backups de Snapshot on-line durante o dia; por exemplo, a cada quatro horas é comum. Esses backups Snapshot costumam ser mantidos por três a cinco dias no sistema de storage primário antes de serem removidos.
As cópias Snapshot também oferecem vantagens importantes para operações de restauração e recuperação. O software de recuperação de dados NetApp SnapRestore permite a restauração de um banco de dados inteiro ou, como alternativa, de uma parte de um banco de dados para qualquer ponto no tempo, com base nas cópias Snapshot disponíveis. Esses processos de restauração são concluídos em poucos minutos, independentemente do tamanho do banco de dados. Como vários backups Snapshot on-line são criados durante o dia, o tempo necessário para o processo de recuperação é significativamente reduzido em relação a uma abordagem de backup tradicional. Como uma restauração pode ser realizada com uma cópia Snapshot que tenha apenas algumas horas de vida (em vez de até 24 horas), menos Registros de transações devem ser aplicados. Portanto, o rto é reduzido para vários minutos, em vez das várias horas necessárias para backups convencionais de fita de ciclo único.
Os backups de cópias snapshot são armazenados no mesmo sistema de disco que os dados on-line ativos. Portanto, a NetApp recomenda o uso de backups de cópias Snapshot como um suplemento, em vez de um substituto para backups em um local secundário. A maioria das ações de restauração e recuperação é tratada com o SnapRestore no sistema de storage primário. As restaurações de um local secundário só serão necessárias se o sistema de storage primário que contém as cópias Snapshot estiver danificado. O local secundário também pode ser usado se for necessário restaurar um backup que não esteja mais disponível em uma cópia Snapshot: Um backup de fim de mês, por exemplo.
Um backup em um local secundário é baseado nas cópias Snapshot criadas no storage primário. Portanto, os dados são lidos diretamente do sistema de armazenamento primário sem gerar carga no servidor de banco de dados SAP. O storage primário se comunica diretamente com o storage secundário e envia os dados de backup para o destino usando um backup disco a disco do NetApp SnapVault.
O SnapVault oferece vantagens significativas em comparação com os backups tradicionais. Após uma transferência inicial de dados, na qual todos os dados foram transferidos da origem para o destino, todos os backups subsequentes copiam apenas os blocos alterados para o armazenamento secundário. Portanto, a carga no sistema de storage primário e o tempo necessário para um backup completo são reduzidos significativamente. Como o SnapVault armazena apenas os blocos alterados no destino, um backup completo do banco de dados requer menos espaço em disco.
A solução também pode ser ampliada de forma otimizada para um modelo de operação de nuvem híbrida. A replicação de dados para recuperação de desastres ou backup externo pode ser feita de sistemas NetApp ONTAP locais para instâncias do Cloud Volumes ONTAP executadas na nuvem. Você pode usar o SnapCenter como uma ferramenta central para gerenciar a proteção de dados e a replicação de dados, independentemente de o sistema SAP HANA ser executado no local ou na nuvem. A figura a seguir mostra uma visão geral da solução de backup.
Tempo de execução dos backups Snapshot
A próxima captura de tela mostra o HANA Studio do cliente executando o SAP HANA no storage NetApp. O cliente está usando cópias Snapshot para fazer backup do banco de DADOS HANA. A imagem mostra que o backup do banco de DADOS HANA (tamanho aproximado de 2,3TB TB) é feito em 2 minutos e 11 segundos com o uso da tecnologia de backup Snapshot.
|
A maior parte do tempo de execução geral do fluxo de trabalho de backup é o tempo necessário para executar a operação savepoint de BACKUP HANA, e essa etapa depende da carga no banco de DADOS HANA. O backup do Snapshot de armazenamento em si sempre termina em alguns segundos. |
Comparação do objetivo de tempo de recuperação
Esta seção fornece uma comparação rto dos backups Snapshot baseados em arquivo e baseados em storage. O rto é definido pela soma do tempo necessário para restaurar o banco de dados e o tempo necessário para iniciar e recuperar o banco de dados.
Tempo necessário para restaurar o banco de dados
Com um backup baseado em arquivo, o tempo de restauração depende do tamanho do banco de dados e da infraestrutura de backup, que define a velocidade de restauração em megabytes por segundo. Por exemplo, se a infraestrutura oferecer suporte a uma operação de restauração a uma velocidade de 250MBps Gbps, levará aproximadamente 1 hora e 10 minutos para restaurar um banco de dados de tamanho 1TB.
Com os backups de cópia Snapshot do storage, o tempo de restauração é independente do tamanho do banco de dados e está no intervalo de alguns segundos quando a restauração pode ser realizada a partir do storage primário. A restauração do storage secundário só é necessária em caso de desastre quando o storage primário não estiver mais disponível.
Tempo necessário para iniciar o banco de dados
A hora de início do banco de dados depende do tamanho do armazenamento de linhas e colunas. Para o armazenamento de colunas, a hora de início também depende da quantidade de dados pré-carregados durante o início da base de dados. Nos exemplos a seguir, assumimos que a hora de início é de 30 minutos. A hora de início é a mesma para uma restauração e recuperação baseadas em arquivos, além de uma restauração e recuperação com base no Snapshot.
Tempo necessário para recuperar o banco de dados
O tempo de recuperação depende do número de logs que devem ser aplicados após a restauração. Este número é determinado pela frequência em que os backups de dados são feitos.
Com backups de dados baseados em arquivos, o agendamento de backup geralmente é uma vez por dia. Uma frequência de backup maior normalmente não é possível, porque o backup degrada o desempenho de produção. Portanto, no pior dos casos, todos os logs que foram escritos durante o dia devem ser aplicados durante a recuperação futura.
Os backups de dados de cópia Snapshot do storage normalmente são programados com uma frequência maior, porque não influenciam o desempenho do banco de dados SAP HANA. Por exemplo, se os backups de cópias Snapshot forem programados a cada seis horas, o tempo de recuperação seria, no pior dos casos, um quarto do tempo de recuperação para um backup baseado em arquivo (6 horas / 24 horas ¼).
A figura a seguir mostra um exemplo de rto para um banco de dados 1TB quando backups de dados baseados em arquivos são usados. Neste exemplo, um backup é feito uma vez por dia. O rto difere dependendo de quando a restauração e a recuperação foram executadas. Se a restauração e a recuperação foram executadas imediatamente após a realização de um backup, o rto é baseado principalmente no tempo de restauração, que é de 1 hora e 10 minutos no exemplo. O tempo de recuperação aumentou para 2 horas e 50 minutos quando a restauração e recuperação foram realizadas imediatamente antes do próximo backup, e o rto máximo foi de 4 horas e 30 minutos.
A figura a seguir mostra um exemplo de rto para um banco de dados 1TB quando os backups Snapshot são usados. Com os backups Snapshot baseados em storage, o rto depende apenas da hora de início do banco de dados e do tempo de recuperação avançada, pois a restauração é concluída em poucos segundos, independentemente do tamanho do banco de dados. O tempo de recuperação para a frente também aumenta dependendo de quando a restauração e a recuperação são feitas, mas devido à maior frequência de backups (a cada seis horas neste exemplo), o tempo de recuperação para a frente é de no máximo 43 minutos. Neste exemplo, o rto máximo é de 1 hora e 13 minutos.
A figura a seguir mostra uma comparação rto de backups Snapshot baseados em arquivos e baseados em armazenamento para diferentes tamanhos de banco de dados e diferentes frequências de backups Snapshot. A barra verde mostra a cópia de segurança baseada em ficheiros. As outras barras mostram backups de cópias Snapshot com diferentes frequências de backup.
Com um único backup de dados de cópia Snapshot por dia, o rto já é reduzido em 40% em comparação com um backup de dados baseado em arquivo. A redução aumenta para 70% quando quatro backups Snapshot são feitos por dia. A figura também mostra que a curva fica fixa se você aumentar a frequência de backup do Snapshot para mais de quatro a seis backups do Snapshot por dia. Portanto, nossos clientes normalmente configuram de quatro a seis backups Snapshot por dia.
|
|
O gráfico mostra o tamanho da RAM do servidor HANA. O tamanho do banco de dados na memória é calculado para ser metade do tamanho da RAM do servidor. |
|
|
O tempo de restauração e recuperação é calculado com base nas seguintes suposições. O banco de dados pode ser restaurado em 250MBps. O número de arquivos de log por dia é de 50% do tamanho do banco de dados. Por exemplo, um banco de dados 1TB cria 500MB de arquivos de log por dia. Uma recuperação pode ser realizada em 100Mbps. |