Partilhar via

Volumes NFS v4.1 no Azure NetApp Files para SAP HANA

  • Artigo

Os Arquivos NetApp do Azure fornecem compartilhamentos NFS nativos que podem ser usados para volumes /hana/shared, /hana/data e /hana/log . O uso de compartilhamentos NFS baseados em ANF para os volumes /hana/data e /hana/log requer o uso do protocolo NFS v4.1. O protocolo NFS v3 não é suportado para o uso de volumes /hana/data e /hana/log ao basear os compartilhamentos em ANF.

Importante

O protocolo NFS v3 implementado nos Arquivos NetApp do Azure não tem suporte para ser usado para /hana/data e /hana/log. O uso do NFS 4.1 é obrigatório para os volumes /hana/data e /hana/log do ponto de vista funcional. Enquanto para o volume /hana/shared o NFS v3 ou o protocolo NFS v4.1 pode ser usado de um ponto de vista funcional.

Considerações importantes

Ao considerar os Arquivos NetApp do Azure para o SAP Netweaver e o SAP HANA, esteja ciente das seguintes considerações importantes:

  • Para limites de volume e pool de capacidade, consulte Limites de recursos do Azure NetApp Files.

  • Os compartilhamentos NFS baseados em Arquivos NetApp do Azure e as máquinas virtuais que montam esses compartilhamentos devem estar na mesma Rede Virtual do Azure ou em redes virtuais emparelhadas na mesma região.

  • A rede virtual selecionada deve ter uma sub-rede, delegada aos Arquivos NetApp do Azure. Para a carga de trabalho SAP, é altamente recomendável configurar um intervalo /25 para a sub-rede delegada aos Arquivos NetApp do Azure.

  • É importante que as máquinas virtuais sejam implantadas com proximidade suficiente ao armazenamento NetApp do Azure para latência mais baixa como, por exemplo, exigido pelo SAP HANA para gravações de log de refazer.

    • Enquanto isso, os Arquivos NetApp do Azure têm funcionalidade para implantar volumes NFS em zonas de disponibilidade específicas do Azure. Tal proximidade zonal será suficiente na maioria dos casos para atingir uma latência inferior a 1 milissegundo. A funcionalidade está em pré-visualização pública e descrita no artigo Gerir o posicionamento do volume da zona de disponibilidade para ficheiros NetApp do Azure. Essa funcionalidade não está exigindo nenhum processo interativo com a Microsoft para obter proximidade entre sua VM e os volumes NFS que você aloca.
    • Para obter a melhor proximidade, a funcionalidade de Grupos de Volume de Aplicativos está disponível. Essa funcionalidade não está apenas procurando a proximidade ideal, mas também o posicionamento ideal dos volumes NFS, de modo que os volumes de dados HANA e de log de refazer sejam manipulados por controladores diferentes. A desvantagem é que esse método precisa de algum processo interativo com a Microsoft para fixar suas VMs.

  • Verifique se a latência do servidor de banco de dados para o volume de Arquivos NetApp do Azure está medida e abaixo de 1 milissegundo

  • A taxa de transferência de um volume do Azure NetApp é uma função da cota de volume e do nível de serviço, conforme documentado em Nível de serviço para arquivos NetApp do Azure. Ao dimensionar os volumes do HANA Azure NetApp, verifique se a taxa de transferência resultante atende aos requisitos de sistema do HANA. Como alternativa, considere o uso de um pool de capacidade de QoS manual, onde volume, capacidade e taxa de transferência podem ser configurados e dimensionados independentemente (exemplos específicos do SAP HANA estão neste documento;

  • Tente "consolidar" volumes para obter mais desempenho em um volume maior, por exemplo, use um volume para /sapmnt, /usr/sap/trans, ... se possível

  • O Azure NetApp Files oferece política de exportação: você pode controlar os clientes permitidos, o tipo de acesso (Leitura e Gravação, Somente Leitura, etc.).

  • A ID de Usuário para sidadm e a ID de Grupo para sapsys nas máquinas virtuais devem corresponder à configuração nos Arquivos NetApp do Azure.

  • Implementar parâmetros do sistema operacional Linux mencionados na nota SAP 3024346

Importante

Para as cargas de trabalho do SAP HANA, a baixa latência é crítica. Trabalhe com seu representante da Microsoft para garantir que as máquinas virtuais e os volumes de Arquivos NetApp do Azure sejam implantados em estreita proximidade.

Importante

Se houver uma incompatibilidade entre a ID de Usuário para sidadm e a ID de Grupo para sapsys entre a máquina virtual e a configuração da NetApp do Azure, as permissões para arquivos nos volumes NetApp do Azure, montadas na VM, serão exibidas como nobody. Certifique-se de especificar a ID de Usuário correta para sidadm e a ID de Grupo para sapsys, ao integrar um novo sistema aos Arquivos NetApp do Azure.

Opção de montagem NCONNECT

O Nconnect é uma opção de montagem para volumes NFS hospedados em Arquivos NetApp do Azure que permite que o cliente NFS abra várias sessões em um único volume NFS. O uso do nconnect com um valor maior que 1 também aciona o cliente NFS para usar mais de uma sessão RPC no lado do cliente (no SO convidado) para lidar com o tráfego entre o SO convidado e os volumes NFS montados. O uso de várias sessões que manipulam o tráfego de um volume NFS, mas também o uso de várias sessões RPC podem abordar cenários de desempenho e taxa de transferência como:

  • Montando vários volumes NFS hospedados em Arquivos NetApp do Azure com diferentes níveis de serviço em uma VM
  • A taxa de transferência máxima de gravação para um volume e uma única sessão Linux está entre 1,2 e 1,4 GB/s. Ter várias sessões em um volume NFS hospedado em Arquivos NetApp do Azure pode aumentar a taxa de transferência

Para versões do sistema operacional Linux que suportam nconnect como uma opção de montagem e algumas considerações importantes de configuração do nconnect, especialmente com diferentes pontos de extremidade do servidor NFS, leia o documento Linux NFS mount options best practices for Azure NetApp Files.

Dimensionamento para banco de dados HANA em arquivos NetApp do Azure

A taxa de transferência de um volume NetApp do Azure é uma função do tamanho do volume e do nível de serviço, conforme documentado em Níveis de serviço para arquivos NetApp do Azure.

Importante entender é a relação de desempenho, o tamanho e que há limites físicos para um ponto de extremidade de armazenamento do serviço. Cada ponto de extremidade de armazenamento será injetado dinamicamente na sub-rede delegada dos Arquivos NetApp do Azure após a criação do volume e receberá um endereço IP. Os volumes do Azure NetApp Files podem, dependendo da capacidade disponível e da lógica de implantação, compartilhar um ponto de extremidade de armazenamento

A tabela abaixo demonstra que poderia fazer sentido criar um grande volume "Padrão" para armazenar backups e que não faz sentido criar um volume "Ultra" maior que 12 TB porque a capacidade máxima de largura de banda física de um único volume seria excedida.

Se você precisar de mais do que a taxa de transferência de gravação máxima para seu volume /hana/data do que uma única sessão Linux pode fornecer, você também pode usar o particionamento de volume de dados do SAP HANA como alternativa. O particionamento de volume de dados do SAP HANA distribui a atividade de E/S durante a recarga de dados ou salva HANA em vários arquivos de dados HANA localizados em vários compartilhamentos NFS. Para obter mais detalhes sobre o striping de volume de dados HANA, leia estes artigos:

Tamanho Padrão de taxa de transferência Rendimento Premium Taxa de transferência Ultra
1 TB 16 MB/seg 64 MB/seg 128 MB/seg
2 TB 32 MB/seg 128 MB/seg 256 MB/seg
4 TB 64 MB/seg 256 MB/seg 512 MB/seg
10 TB 160 MB/seg 640 MB/seg 1.280 MB/seg
15 TB 240 MB/seg 960 MB/seg 1.400 MB/seg1
20 TB 320 MB/seg 1.280 MB/seg 1.400 MB/seg1
40 TB 640 MB/seg 1.400 MB/seg1 1.400 MB/seg1

1: limites de taxa de transferência de gravação ou leitura de sessão única (caso a opção de montagem NFS nconnect não seja usada)

É importante entender que os dados são gravados nos mesmos SSDs no back-end de armazenamento. A cota de desempenho do pool de capacidade foi criada para poder gerenciar o ambiente. Os KPIs de armazenamento são iguais para todos os tamanhos de banco de dados HANA. Em quase todos os casos, essa suposição não reflete a realidade e a expectativa do cliente. O tamanho dos sistemas HANA não significa necessariamente que um sistema pequeno exija baixa taxa de transferência de armazenamento – e um sistema grande requer alta taxa de transferência de armazenamento. Mas, geralmente, podemos esperar requisitos de taxa de transferência mais altos para instâncias de banco de dados HANA maiores. Como resultado das regras de dimensionamento do SAP para o hardware subjacente, essas instâncias HANA maiores também fornecem mais recursos de CPU e maior paralelismo em tarefas como carregar dados após a reinicialização de uma instância. Como resultado, os tamanhos de volume devem ser adotados de acordo com as expectativas e exigências do cliente. E não apenas impulsionado por requisitos de capacidade pura.

Ao projetar a infraestrutura para SAP no Azure, você deve estar ciente de alguns requisitos mínimos de taxa de transferência de armazenamento (para sistemas de produção) pela SAP. Esses requisitos se traduzem em características de rendimento mínimo de:

Tipo de volume e tipo de E/S KPI mínimo exigido pelo SAP Nível de serviço premium Nível de serviço ultra
Gravação de volume de log 250 MB/seg 4 TB 2 TB
Gravação de volume de dados 250 MB/seg 4 TB 2 TB
Leitura de Volume de Dados 400 MB/seg 6,3 TB 3,2 TB

Como todos os três KPIs são exigidos, o volume /hana/data precisa ser dimensionado para a maior capacidade para atender aos requisitos mínimos de leitura. Se você estiver usando pools de capacidade de QoS manuais, o tamanho e a taxa de transferência dos volumes poderão ser definidos de forma independente. Como a capacidade e a taxa de transferência são retiradas do mesmo pool de capacidade, o nível de serviço e o tamanho do pool devem ser grandes o suficiente para oferecer o desempenho total (veja o exemplo aqui)

Para sistemas HANA, que não exigem alta largura de banda, a taxa de transferência de volume dos Arquivos NetApp do Azure pode ser reduzida por um tamanho de volume menor ou, usando QoS manual, ajustando a taxa de transferência diretamente. E no caso de um sistema HANA exigir mais rendimento, o volume pode ser adaptado redimensionando a capacidade on-line. Nenhum KPI é definido para volumes de backup. No entanto, a taxa de transferência do volume de backup é essencial para um ambiente com bom desempenho. Log – e o desempenho do volume de dados deve ser projetado de acordo com as expectativas do cliente.

Importante

Independentemente da capacidade implantada em um único volume NFS, espera-se que a taxa de transferência se estabilize no intervalo de 1,2 a 1,4 GB/seg de largura de banda utilizada por um consumidor em uma única sessão. Isso tem a ver com a arquitetura subjacente da oferta do Azure NetApp Files e os limites de sessão Linux relacionados ao NFS. Os números de desempenho e taxa de transferência, conforme documentado no artigo Resultados do teste de benchmark de desempenho para Arquivos NetApp do Azure, foram conduzidos em relação a um volume NFS compartilhado com várias VMs cliente e, como resultado, com várias sessões. Esse cenário é diferente do cenário que medimos no SAP, em que medimos a taxa de transferência de uma única VM em relação a um volume NFS hospedado nos Arquivos NetApp do Azure.

Para atender aos requisitos mínimos de taxa de transferência do SAP para dados e log, e de acordo com as diretrizes para /hana/shared, os tamanhos recomendados seriam parecidos:

Volume Tamanho
Nível de armazenamento premium		 Tamanho
Nível de armazenamento Ultra		 Protocolo NFS suportado
/hana/log/ 4 TiB 2 TiB v4,1
/hana/dados 6,3 TiB 3,2 TiB v4,1
/HANA/Expansão compartilhada Mínimo (1 TB, 1 x RAM) Mínimo (1 TB, 1 x RAM) v3 ou v4.1
/hana/expansão compartilhada 1 x RAM do nó de trabalho
por quatro nós de trabalho		 1 x RAM do nó de trabalho
por quatro nós de trabalho		 v3 ou v4.1
/hana/logbackup 3 x RAM 3 x RAM v3 ou v4.1
/hana/backup 2 x RAM 2 x RAM v3 ou v4.1

Para todos os volumes, o NFS v4.1 é altamente recomendado.
Analise cuidadosamente as considerações para dimensionar /hana/shared, pois o volume /hana/shared de tamanho apropriado contribui para a estabilidade do sistema.

Os tamanhos dos volumes de backup são estimativas. Os requisitos exatos precisam ser definidos com base na carga de trabalho e nos processos operacionais. Para backups, você pode consolidar muitos volumes para diferentes instâncias do SAP HANA em um (ou dois) volumes maiores, que podem ter um nível de serviço mais baixo dos Arquivos NetApp do Azure.

Nota

Os Arquivos NetApp do Azure, recomendações de dimensionamento declaradas neste documento, visam os requisitos mínimos que a SAP expressa para seus provedores de infraestrutura. Em implantações reais de clientes e cenários de carga de trabalho, isso pode não ser suficiente. Use essas recomendações como ponto de partida e adapte-se, com base nos requisitos de sua carga de trabalho específica.

Portanto, você pode considerar implantar uma taxa de transferência semelhante para os volumes do Azure NetApp Files listados para o armazenamento em disco Ultra já. Considere também os tamanhos para os tamanhos listados para os volumes para as diferentes SKUs de VM, conforme feito nas tabelas de disco Ultra já feitas.

Gorjeta

Você pode redimensionar os volumes dos Arquivos NetApp do Azure dinamicamente, sem a necessidade dos unmount volumes, parar as máquinas virtuais ou parar o SAP HANA. Isso permite flexibilidade para atender às demandas de throughput esperadas e imprevistas do seu aplicativo.

A documentação sobre como implantar uma configuração de expansão do SAP HANA com nó de espera usando volumes NFS v4.1 baseados em Arquivos NetApp do Azure é publicada na expansão do SAP HANA com nó de espera em VMs do Azure com Arquivos NetApp do Azure no SUSE Linux Enterprise Server.

Configurações do kernel Linux

Para implantar com êxito o SAP HANA no Azure NetApp Files, as configurações do kernel do Linux precisam ser implementadas de acordo com a nota 3024346 do SAP.

Para sistemas que usam Alta Disponibilidade (HA) usando marcapasso e Azure Load Balancer, as seguintes configurações precisam ser implementadas no arquivo: /etc/sysctl.d/91-NetApp-HANA.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1

Os sistemas que executam sem marcapasso e o Azure Load Balancer devem implementar essas configurações em /etc/sysctl.d/91-NetApp-HANA.conf

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1

Implantação com proximidade zonal

Para obter uma proximidade zonal de seus volumes NFS e VMs, você pode seguir as instruções descritas em Gerenciar posicionamento de volume da zona de disponibilidade para Arquivos NetApp do Azure. Com esse método, as VMs e os volumes NFS estarão na mesma Zona de Disponibilidade do Azure. Na maioria das regiões do Azure, esse tipo de proximidade deve ser suficiente para obter latência inferior a 1 milissegundo para as gravações de log de refazer menores para o SAP HANA. Esse método não requer nenhum trabalho interativo com a Microsoft para colocar e fixar VMs em um datacenter específico. Como resultado, você é flexível com a alteração de tamanhos e famílias de VM em todos os tipos e famílias de VM oferecidos na zona de disponibilidade implantada. Assim, que você possa reagir de forma flexível em condições de mudança ou mudar mais rapidamente para tamanhos ou famílias de VM mais econômicos. Recomendamos esse método para sistemas que não são de produção e sistemas de produção que podem trabalhar com latências de log de refazer mais próximas de 1 milissegundo. A funcionalidade está atualmente em pré-visualização pública.

Implantação por meio do grupo de volumes de aplicativos Arquivos NetApp do Azure para SAP HANA (AVG)

Para implantar volumes de Arquivos NetApp do Azure com proximidade à sua VM, uma nova funcionalidade chamada grupo de volumes de aplicativos do Azure NetApp Files para SAP HANA (AVG) foi desenvolvida. Há uma série de artigos que documentam a funcionalidade. O melhor é começar com o artigo Compreender o grupo de volumes de aplicativos do Azure NetApp Files para SAP HANA. À medida que você lê os artigos, fica claro que o uso dos AVGs também envolve o uso de grupos de posicionamento de proximidade do Azure. Os grupos de posicionamento de proximidade são usados pela nova funcionalidade para se ligar aos volumes que estão sendo criados. Para garantir que, durante a vida útil do sistema HANA, as VMs não serão movidas para longe dos volumes de Arquivos NetApp do Azure, recomendamos o uso de uma combinação de Avset/PPG para cada uma das zonas em que você implanta. A ordem de implantação seria semelhante a:

  • Usando o formulário, você precisa solicitar uma fixação do AvSet vazio em um HW de computação para garantir que as VMs não se movam
  • Atribua um PPG ao Conjunto de Disponibilidade e inicie uma VM atribuída a este Conjunto de Disponibilidade
  • Usar o grupo de volumes de aplicativos do Azure NetApp Files para a funcionalidade SAP HANA para implantar seus volumes HANA

A configuração do grupo de posicionamento de proximidade para usar AVGs de uma maneira ideal seria parecida com:

Diagrama do grupo de volumes de aplicativos do Azure NetApp Files e arquitetura de grupo de posicionamento de proximidade.

O diagrama mostra que você usará um grupo de posicionamento de proximidade do Azure para a camada DBMS. Então, que ele pode ser usado junto com AVGs. É melhor incluir apenas as VMs que executam as instâncias HANA no grupo de posicionamento de proximidade. O grupo de posicionamento de proximidade é necessário, mesmo que apenas uma VM com uma única instância HANA seja usada, para que o AVG identifique a proximidade mais próxima do hardware dos Arquivos NetApp do Azure. E para alocar o volume NFS nos Arquivos NetApp do Azure o mais próximo possível da(s) VM(s) que estão usando os volumes NFS.

Este método gera os melhores resultados no que diz respeito à baixa latência. Não apenas aproximando os volumes NFS e as VMs o mais próximo possível. Mas as considerações de colocar os volumes de dados e refazer log em diferentes controladores no back-end da NetApp também são levadas em consideração. No entanto, a desvantagem é que sua implantação de VM é fixada em um datacenter. Com isso, você está perdendo flexibilidade na mudança de tipos e famílias de VMs. Como resultado, você deve limitar esse método aos sistemas que absolutamente exigem uma latência de armazenamento tão baixa. Para todos os outros sistemas, você deve tentar a implantação com uma implantação zonal tradicional da VM e dos Arquivos NetApp do Azure. Na maioria dos casos, isso é suficiente em termos de baixa latência. Isso também garante fácil manutenção e administração da VM e dos Arquivos NetApp do Azure.

Disponibilidade

As atualizações e upgrades do sistema ANF são aplicadas sem afetar o ambiente do cliente. O SLA definido é de 99,99%.

Volumes, endereços IP e pools de capacidade

Com a ANF, é importante entender como a infraestrutura subjacente é construída. Um pool de capacidade é apenas uma construção, que fornece um orçamento de capacidade e desempenho e uma unidade de faturamento, com base no nível de serviço do pool de capacidade. Um pool de capacidade não tem relação física com a infraestrutura subjacente. Quando você cria um volume no serviço, um ponto de extremidade de armazenamento é criado. Um único endereço IP é atribuído a esse ponto de extremidade de armazenamento para fornecer acesso de dados ao volume. Se você criar vários volumes, todos os volumes serão distribuídos pela frota bare metal subjacente, vinculados a esse ponto de extremidade de armazenamento. O ANF tem uma lógica que distribui automaticamente as cargas de trabalho do cliente assim que os volumes e/ou a capacidade do armazenamento configurado atingem um nível interno predefinido. Você pode notar esses casos porque um novo ponto de extremidade de armazenamento, com um novo endereço IP, é criado automaticamente para acessar os volumes. O serviço ANF não fornece controle ao cliente sobre essa lógica de distribuição.

Volume de log e volume de backup de log

O "volume de log" (/hana/log) é usado para escrever o log de refazer online. Assim, existem arquivos abertos localizados neste volume e não faz sentido fazer um instantâneo desse volume. Os arquivos de log de refazer online são arquivados ou copiados para o volume de backup de log assim que o arquivo de log de refazer online estiver completo ou um backup de log de refazer for executado. Para fornecer um desempenho de backup razoável, o volume de backup de log requer uma boa taxa de transferência. Para otimizar os custos de armazenamento, pode fazer sentido consolidar o volume de backup de log de várias instâncias HANA. Para que várias instâncias HANA usem o mesmo volume e gravem seus backups em diretórios diferentes. Usando essa consolidação, você pode obter mais taxa de transferência, já que você precisa tornar o volume um pouco maior.

O mesmo se aplica ao volume no qual você usa gravar backups completos do banco de dados HANA.
 

Backup

Além de transmitir backups e o serviço de Backup do Azure fazer backup de bancos de dados SAP HANA conforme descrito no artigo Guia de backup do SAP HANA em Máquinas Virtuais do Azure, o Azure NetApp Files abre a possibilidade de executar backups instantâneos baseados em armazenamento.

O SAP HANA suporta:

  • Suporte de backup de snapshot baseado em armazenamento para sistema de contêiner único com SAP HANA 1.0 SPS7 e superior
  • Suporte de backup de snapshot baseado em armazenamento para ambientes HANA Multi Database Container (MDC) com um único locatário com SAP HANA 2.0 SPS1 e superior
  • Suporte de backup de snapshot baseado em armazenamento para ambientes HANA Multi Database Container (MDC) com vários locatários com SAP HANA 2.0 SPS4 e superior

A criação de backups instantâneos baseados em armazenamento é um procedimento simples de quatro etapas,

  1. Criando um instantâneo de banco de dados HANA (interno) - uma atividade que você ou ferramentas precisam executar
  2. O SAP HANA grava dados nos arquivos de dados para criar um estado consistente no armazenamento - o HANA executa esta etapa como resultado da criação de um snapshot do HANA
  3. Crie um snapshot no volume /hana/data no armazenamento - uma etapa que você ou as ferramentas precisam executar. Não há necessidade de executar um snapshot no volume /hana/log
  4. Exclua o instantâneo do banco de dados HANA (interno) e retome a operação normal - uma etapa que você ou as ferramentas precisam executar

Aviso

Perder a última etapa ou não executar a última etapa tem um impacto grave na demanda de memória do SAP HANA e pode levar a uma interrupção do SAP HANA

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';

Backup de snapshot ANF para SAP HANA

az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname

Backup de snapshot ANF para SAP HANA part2

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID 47110815 SUCCESSFUL SNAPSHOT-2020-08-18:11:00';

Esse procedimento de backup de instantâneo pode ser gerenciado de várias maneiras, usando várias ferramentas.

Atenção

Um snapshot em si não é um backup protegido, pois está localizado no mesmo armazenamento físico do volume do qual você acabou de tirar um snapshot. É obrigatório "proteger" pelo menos um instantâneo por dia para um local diferente. Isso pode ser feito no mesmo ambiente, em uma região remota do Azure ou no armazenamento de Blob do Azure.

Soluções disponíveis para backup consistente de aplicativos baseado em snapshot de armazenamento:

  • A ferramenta Microsoft What is Azure Application Consistent Snapshot é uma ferramenta de linha de comando que permite a proteção de dados para bancos de dados de terceiros. Ele lida com toda a orquestração necessária para colocar os bancos de dados em um estado consistente do aplicativo antes de tirar um instantâneo de armazenamento. Depois que o instantâneo de armazenamento for tirado, a ferramenta retornará os bancos de dados a um estado operacional. O AzAcSnap oferece suporte a backups baseados em instantâneo para HANA Large Instance e Arquivos NetApp do Azure. para obter mais detalhes, leia o artigo O que é a ferramenta de instantâneo consistente de aplicativo do Azure
  • Para usuários de produtos de backup Commvault, outra opção é o Commvault IntelliSnap V.11.21 e posterior. Esta ou versões posteriores do Commvault oferecem suporte a instantâneos do Azure NetApp Files. O artigo Commvault IntelliSnap 11.21 fornece mais informações.

Fazer backup do instantâneo usando o armazenamento de blob do Azure

O backup no armazenamento de blob do Azure é um método econômico e rápido para salvar backups instantâneos de armazenamento de banco de dados HANA baseados em ANF. Para salvar os instantâneos no armazenamento de Blob do Azure, a ferramenta AzCopy é preferida. Faça o download da versão mais recente desta ferramenta e instale-a, por exemplo, no diretório bin onde o script Python do GitHub está instalado. Faça o download da ferramenta AzCopy mais recente:

root # wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Saving to: ‘azcopy_v10.tar.gz’

O recurso mais avançado é a opção SYNC. Se você usar a opção SYNC, azcopy manterá o diretório de origem e de destino sincronizado. O uso do parâmetro --delete-destination é importante. Sem esse parâmetro, o azcopy não está excluindo arquivos no local de destino e a utilização de espaço no lado de destino aumentaria. Crie um contêiner de Blob de Bloco em sua conta de armazenamento do Azure. Em seguida, crie a chave SAS para o contêiner de blob e sincronize a pasta de instantâneo com o contêiner de Blob do Azure.

Por exemplo, se um instantâneo diário deve ser sincronizado com o contêiner de blob do Azure para proteger os dados. E apenas um instantâneo deve ser mantido, o comando abaixo pode ser usado.

root # > azcopy sync '/hana/data/SID/mnt00001/.snapshot' 'https://azacsnaptmytestblob01.blob.core.windows.net/abc?sv=2021-02-02&ss=bfqt&srt=sco&sp=rwdlacup&se=2021-02-04T08:25:26Z&st=2021-02-04T00:25:26Z&spr=https&sig=abcdefghijklmnopqrstuvwxyz' --recursive=true --delete-destination=true

Próximos passos

Leia o artigo: