Volumes NFS v4.1 no Azure NetApp Files para SAP HANA
O Azure NetApp Files fornece 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. Não há suporte para o protocolo NFS v3 no uso de volumes /hana/data e /hana/log ao basear os compartilhamentos no ANF.
Importante
Não há suporte para o protocolo NFS v3 implementado no Azure NetApp Files para ser usado com /hana/data e /hana/log. O uso do NFS 4.1 é obrigatório para volumes /hana/data e /hana/log por questões funcionais. Enquanto que, para o volume /hana/shared, o protocolo NFS v3 ou o NFS v4.1 pode ser usado por questões funcionais.
Considerações importantes
Ao considerar Azure NetApp Files para o SAP Netweaver e o SAP HANA, esteja ciente das seguintes considerações importantes:
Para limites de volume e pool de capacidade, confira Limites de recursos do Azure NetApp Files.
Os compartilhamentos NFS baseados no Azure NetApp Files e as máquinas virtuais que montam esses compartilhamentos precisam estar na mesma Rede Virtual do Azure ou em redes virtuais emparelhadas na mesma região.
A rede virtual selecionada precisa ter uma sub-rede, delegada ao Azure NetApp Files. Para a carga de trabalho do SAP, é altamente recomendável configurar um intervalo /25 para a sub-rede delegada ao Azure NetApp Files.
É importante que as máquinas virtuais sejam implantadas com proximidade suficiente ao armazenamento do Azure NetApp para reduzir a latência, por exemplo, exigida pelo SAP HANA para gravações de log refazer.
- No entanto, o Azure NetApp Files tem a funcionalidade de implantar volumes NFS em Zonas de Disponibilidade específicas do Azure. Essa proximidade zonal será suficiente na maioria dos casos para alcançar uma latência inferior a um milissegundo. A funcionalidade está em versão prévia pública e descrita no artigo Gerenciar o posicionamento do volume da zona de disponibilidade do Azure NetApp Files. Essa funcionalidade não exige nenhum processo interativo com a Microsoft para alcançar a proximidade entre a VM e os volumes NFS alocados.
- Para conseguir a proximidade ideal, a funcionalidade dos grupos de volumes de aplicativos está disponível. Essa funcionalidade não está apenas procurando a proximidade ideal, mas também o posicionamento ideal dos volumes NFS, portanto, os volumes de log refazer e de dados do HANA são tratados por controladores diferentes. A desvantagem é que esse método precisa de um processo interativo com a Microsoft para fixar as VMs.
Verifique se a latência do servidor de banco de dados para o volume do Azure NetApp Files seja medida e esteja 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 no Nível de serviço para Azure NetApp Files. Ao dimensionar os volumes Azure NetApp do HANA, verifique se a taxa de transferência resultante atende aos requisitos do sistema do HANA. Como alternativa, use um pool de capacidade de QoS manual em que a capacidade de volume e a taxa de transferência possam ser configuradas e dimensionadas de forma independente (os exemplos específicos do SAP HANA estão neste documento
Tente "consolidar" volumes para obter melhor desempenho em um volume maior; por exemplo, use um volume para /sapmnt, /usr/SAP/trans... se possível
Azure NetApp Files oferece a política de exportação: você pode controlar os clientes permitidos e o tipo de acesso (leitura e gravação, somente leitura etc.).
A ID de usuário para sidadm e a ID de Grupo para
sapsysnas máquinas virtuais devem corresponder à configuração no Azure NetApp Files.Implementar os parâmetros do sistema operacional Linux mencionados na nota da SAP 3024346
Importante
Para cargas de trabalho do SAP HANA, baixa latência é fundamental. Trabalhe com seu representante da Microsoft para verificar se as máquinas virtuais e os volumes do Azure NetApp Files foram implantados bem próximos.
Importante
Se houver uma incompatibilidade entre a ID de Usuário do sidadm e a ID de Grupo do sapsys se comparadas a máquina virtual e a configuração do Azure NetApp, as permissões dos arquivos em volumes do Azure NetApp, montadas na VM, seriam exibidas como nobody. Especifique a ID de Usuário correta para sidadm e a ID do Grupo para sapsys, ao integrar um novo sistema ao Azure NetApp Files.
Opção de montagem NCONNECT
O NCONNECT é uma opção de montagem para volumes NFS hospedados no Azure NetApp Files que permite que o cliente NFS abra várias sessões em um único volume NFS. O uso de NCONNECT com um valor maior que 1 também dispara o cliente NFS para usar mais de uma sessão de RPC no lado do cliente (no sistema operacional convidado) para tratar o tráfego entre o sistema operacional convidado e os volumes NFS montados. O uso de várias sessões para tratar o tráfego de um volume NFS, mas também o uso de várias sessões RPC, pode atender cenários de desempenho e taxa de transferência, como:
- Montagem de vários volumes NFS hospedados pelo Azure NetApp Files com diferentes níveis de serviço em uma VM
- A taxa de transferência máxima de gravação para um volume e para uma única sessão do Linux fica entre 1,2 e 1,4 GB/s. Ter várias sessões em um volume NFS hospedado pelo Azure NetApp Files pode aumentar a taxa de transferência
Para obter versões do sistema operacional Linux que dão suporte à NCONNECT como uma opção de montagem e algumas considerações de configuração importantes sobre a NCONNECT, especialmente com pontos de extremidade de servidor NFS diferentes, leia o documento Melhores práticas das opções de montagem NFS do Linux para Azure NetApp Files.
Dimensionar o banco de dados do HANA no Azure NetApp Files
A taxa de transferência de um volume do Azure NetApp é uma função do tamanho do volume e do nível de serviço, conforme documentado no Nível de serviço para Azure NetApp Files.
É importante entender a relação do desempenho com o tamanho e que existem 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 do Azure NetApp Files na criação do volume e vai receber um endereço IP. Os volumes de 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 a seguir demonstra que pode fazer sentido criar um volume "Standard" grande para armazenar backups e que não faz sentido criar um volume "Ultra" com mais de 12 TB porque a capacidade 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 o volume /hana/data do que uma única sessão do 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 o recarregamento de dados ou os pontos de salvamento do HANA em vários arquivos de dados do HANA localizados em múltiplos compartilhamentos NFS. Para obter mais detalhes sobre a distribuição de volumes de dados do HANA, leia estes artigos:
- Guia do Administrador do HANA
- Blog sobre SAP HANA – Particionando Volumes de Dados
- Nota SAP Nº 2400005
- Nota SAP Nº 2700123
| Tamanho | Taxa de transferência Standard | Taxa de transferência Premium | Taxa de transferência Ultra |
|---|---|---|---|
| 1 TB | 16 MB/s | 64 MB/s | 128 MB/s |
| 2 TB | 32 MB/s | 128 MB/s | 256 MB/s |
| 4 TB | 64 MB/s | 256 MB/s | 512 MB/s |
| 10 TB | 160 MB/s | 640 MB/s | 1\.280 MB/s |
| 15 TB | 240 MB/s | 960 MB/s | 1\.400 MB/s1 |
| 20 TB | 320 MB/s | 1\.280 MB/s | 1\.400 MB/s1 |
| 40 TB | 640 MB/s | 1\.400 MB/s1 | 1\.400 MB/s1 |
1: limites de taxa de transferência de leitura de única sessão ou de gravação (caso o nconnect da opção de montagem de NFS não seja usado)
É 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 do 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 exige baixa taxa de transferência de armazenamento – e que um sistema grande exige alta taxa de transferência de armazenamento. Mas, em geral, podemos esperar requisitos maiores de taxa de transferência para instâncias de banco de dados do HANA maiores. Como resultado das regras de dimensionamento do SAP para o hardware subjacente, essas instâncias maiores do HANA também fornecem mais recursos de CPU e maior paralelismo em tarefas como o carregamento de dados após uma reinicialização de instâncias. Como resultado, os tamanhos dos volumes devem ser adotados de acordo com as expectativas e os requisitos do cliente. E não somente orientados puramente por requisitos de capacidade.
Ao criar a infraestrutura do SAP no Azure, você deve estar ciente de alguns requisitos de taxa de transferência mínima de armazenamento do SAP (para sistemas de produção). Esses requisitos são as características mínimas de taxa de transferência de:
| Tipo de volume e tipo de E/S | KPI mínimo exigido pelo SAP | Camada de serviço Premium | Camada de serviço Ultra |
|---|---|---|---|
| Gravação de volume de log | 250 MB/s | 4 TB | 2 TB |
| Gravação de volume de dados | 250 MB/s | 4 TB | 2 TB |
| Leitura de volume de dados | 400 MB/s | 6,3 TB | 3,2 TB |
Como todos os três KPIs possuem demanda, o volume /hana/data precisa ser dimensionado em direção à capacidade maior para atender aos requisitos mínimos de leitura. Se estiver usando pools de capacidade de QoS manuais, o tamanho e a taxa de transferência dos volumes podem ser definidos de modo independente. Como a capacidade e a taxa de transferência são obtidas do mesmo pool de capacidade, o nível de serviço e o tamanho do pool devem ser grandes o suficiente para promover o desempenho total (confira o exemplo aqui)
Para sistemas HANA, que não exigem largura de banda elevada, a taxa de transferência de volume ANF pode ser reduzida por um tamanho de volume menor ou, usando a QoS manual, ajustando a taxa de transferência diretamente. Caso um sistema HANA exija mais taxa de transferência, o volume pode ser adaptado redimensionando a capacidade online. Nenhum KPI é definido para volumes de backup. No entanto, a taxa de transferência do volume de backup é essencial para um ambiente ter bom desempenho. O desempenho dos volumes de log e de dados devem ser projetados de acordo com as expectativas do cliente.
Importante
Independentemente da capacidade que você implantar em um único volume NFS, espera-se que a taxa de transferência fique estável no intervalo de largura de banda de 1,2 a 1,4 GB/s utilizada por um consumidor em uma única sessão. Isso tem a ver com a arquitetura subjacente da oferta do Azure NetApp Files e com os limites de sessão do Linux relacionados em relação ao NFS. Os números de desempenho e taxa de transferência, conforme documentado no artigo Resultados do teste de benchmark de desempenho para Azure NetApp Files foram realizados em um volume NFS compartilhado com várias VMs de cliente e como resultado com várias sessões. Esse cenário é diferente do cenário medido no SAP, no qual medimos a taxa de transferência de uma única VM em relação a um volume NFS hospedado no Azure NetApp Files.
Para atender aos requisitos de taxa de transferência mínima do SAP para dados e log, de acordo com as diretrizes para o /hana/shared, os tamanhos recomendados seriam semelhantes a:
| Volume | Tamanho Camada de armazenamento Premium |
Tamanho Camada de armazenamento Ultra |
Protocolo do NFS com suporte |
|---|---|---|---|
| /hana/log/ | 4 TiB | 2 TiB | v4.1 |
| /hana/data | 6,3 TiB | 3,2 TiB | v4.1 |
| Expansão vertical do /hana/shared | Mín. (1 TB, 1 x RAM) | Mín. (1 TB, 1 x RAM) | v3 ou v4.1 |
| Expansão horizontal /hana/shared | 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, é altamente recomendado o NFS v 4.1.
Examine cuidadosamente as considerações sobre o dimensionamento de /hana/shared, pois o volume de /hana/shared de tamanho adequado contribui para a estabilidade do sistema.
Os tamanhos dos volumes de backup são estimativas. Os requisitos exatos precisam ser definidos com base em processos de carga de trabalho e operação. Para backups, você pode consolidar muitos volumes de diferentes instâncias do SAP HANA em um (ou dois) volumes maiores, o que poderia gerar um nível de serviço inferior do Azure NetApp Files.
Observação
As recomendações de dimensionamento do Azure NetApp Files declaradas neste documento estão visando os requisitos mínimos que o SAP expressa para seus provedores de infraestrutura. Em implantações de clientes e cenários de carga de trabalho reais, isso pode não ser suficiente. Use essas recomendações como um 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 conforme já listado para o armazenamento de disco Ultra. Além disso, considere os tamanhos listados para os volumes dos diferentes SKUs de VM, como já foi feito nas tabelas do disco Ultra.
Dica
Você pode redimensionar os volumes do Azure NetApp Files dinamicamente, sem a necessidade de unmount os volumes, parar as máquinas virtuais ou parar o SAP HANA. Isso oferece flexibilidade para você atender às demandas de taxa de transferência tanto esperadas quanto imprevistas do seu aplicativo.
A documentação de como implantar uma configuração de expansão do SAP HANA com o nó em espera usando volumes NFS v4.1 hospedados no Azure NetApp Files foi publicada em Expansão do SAP HANA com o nó em espera em VMs do Azure com o Azure NetApp Files no SUSE Linux Enterprise Server.
Configurações do Kernel do Linux
Para implantar com êxito o SAP HANA no Azure NetApp Files, as configurações de kernel do Linux precisam ser implementadas de acordo com a nota da SAP 3024346.
Para sistemas que usam HA (alta disponibilidade) com o Pacemaker e o Azure Load Balancer, as configurações a seguir 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
Sistemas em execução sem o Pacemaker 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 volumes e VMs NFS, siga as instruções descritas em Gerenciar o posicionamento do volume de zona de disponibilidade do Azure NetApp Files. 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 menos de um milissegundo de latência nas gravações de log refazer menores do SAP HANA. Esse método não exige nenhum trabalho interativo com a Microsoft para colocar e fixar VMs em um datacenter específico. Como resultado, há flexibilidade para alterar tamanhos e famílias de VM em todos os tipos e famílias de VM oferecidos na Zona de Disponibilidade implantada. Portanto, você pode reagir com flexibilidade na alteração das condições ou mudar com mais rapidez para tamanhos ou famílias de VM mais econômicas. Recomendamos esse método para sistemas que não sejam de produção e para sistemas de produção que possam trabalhar com latências de log refazer mais próximas de um milissegundo. A funcionalidade está em versão prévia pública no momento.
Implantação por meio do AVG (grupo de volumes de aplicativo) do Azure NetApp Files para SAP HANA
Para implantar volumes do Azure NetApp Files com proximidade à VM, foi desenvolvida uma nova funcionalidade chamada AVG (grupo de volumes de aplicativo) do Azure NetApp Files para SAP HANA. Há uma série de artigos que documentam a funcionalidade. O melhor é começar com o artigo Saiba sobre o grupo de volumes de aplicativo do Azure NetApp Files para SAP HANA. Conforme você lê os artigos, fica claro que o uso de AVGs também envolve o uso de grupos de posicionamento por proximidade do Azure. Os grupos de posicionamento de proximidade são usados pela nova funcionalidade para se vincular ao com os volumes que estão sendo criados. Para garantir que, durante o tempo de vida do sistema HANA, as VMs não sejam removidas dos volumes do Azure NetApp Files, recomendamos o uso de uma combinação de Avset/PPG para cada uma das zonas de implantação. A ordem de implantação teria a seguinte aparência:
- Usando o formulário, você precisa solicitar uma fixação do AvSet vazio em um hardware de computação para garantir que as VMs não sejam movidas
- Atribuir um PPG ao conjunto de disponibilidade e iniciar uma VM atribuída a esse conjunto de disponibilidade
- Use o grupo de volumes de aplicativo do Azure NetApp Files para SAP HANA a fim de implantar os volumes do HANA
A configuração do grupo de posicionamento de proximidade para usar o AVGs de forma ideal seria semelhante a:
O diagrama mostra que você pretende usar um grupo de posicionamento de proximidade do Azure para a camada DBMS. Portanto, ele pode ser usado junto com AVGs. É melhor incluir apenas as VMs que executam as instâncias do HANA no grupo de posicionamento por proximidade. O grupo de posicionamento por proximidade é necessário, mesmo que apenas uma VM com uma só instância do HANA seja usada, para que o AVG identifique a proximidade mais próxima do hardware do Azure NetApp Files. E para alocar o volume do NFS no Azure NetApp Files o mais próximo possível das VMs que estão usando os volumes do NFS.
Esse método gera os resultados ideais relacionados à baixa latência. Não apenas aproximando ao máximo os volumes NFS e as VMs. Mas também é considerado como colocar os volumes de log de dados e refazer em diferentes controladores no back-end do NetApp. No entanto, a desvantagem é que a implantação da VM é fixada em um datacenter. Com isso, você perde a flexibilidade de alteração de tipos e famílias de VM. Como resultado, você deve limitar esse método aos sistemas que realmente exigem uma latência de armazenamento muito baixa. Para todos os outros sistemas, você deve tentar a implantação com uma implantação zonal tradicional da VM e do Azure NetApp Files. Geralmente, isto é suficiente em termos de baixa latência. Isso também garante uma fácil manutenção e administração da VM e do Azure NetApp Files.
Disponibilidade
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 o ANF, é importante entender como a infraestrutura subjacente é criada. Um pool de capacidade é apenas um constructo, que fornece um orçamento de capacidade e de desempenho e uma unidade de cobrança, com base no nível de serviço do pool de capacidade. Um pool de capacidade não tem nenhuma 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 aos dados para o volume. Se você criar vários volumes, todos os volumes serão distribuídos pela frota de computador bare-metal subjacente, vinculada a esse ponto de extremidade de armazenamento. O ANF tem uma lógica que distribui automaticamente cargas de trabalho do cliente quando os volumes ou/e a capacidade do armazenamento configurado atingem um nível predefinido interno. Você pode observar 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 do ANF não fornece controle personalizado sobre essa lógica de distribuição.
Volume de log e volume de backup de log
O "volume de log" ( /hana/log) é usado para gravar o log de restauração online. Portanto, há arquivos abertos localizados neste volume e não faz sentido fazer um instantâneo desse volume. Os arquivos de log de restauração online são arquivados ou copiados via backup no volume de backup de logs quando o arquivo de log de restauração online está cheio ou um backup de log de restauração é executado. Para fornecer um desempenho de backup razoável, o volume de backup de log exige 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 do HANA. Para que várias instâncias do HANA aproveitem o mesmo volume e gravem seus backups em diretórios diferentes. Usando essa consolidação, você pode obter maior taxa de transferência, pois precisa aumentar um pouco o volume.
O mesmo se aplica ao volume que você usa para gravar backups completos do banco de dados do HANA.
Backup
Além dos backups de streaming e do serviço de Backup do Azure fazendo backup dos bancos de dados SAP HANA, conforme a descrição no artigo Guia de backup do SAP HANA em máquinas virtuais do Azure, o Azure NetApp Files permite executar backups de instantâneos baseados em armazenamento.
SAP HANA tem suporte para:
- Suporte de backup de instantâneo baseado em armazenamento para o sistema de contêiner individual com SAP HANA 1.0 SPS7 e superior
- Suporte de backup de instantâneo baseado em armazenamento para ambientes HANA MDC (Contêiner de Vários Bancos de Dados) com um único locatário com SAP HANA 2.0 SPS1 e superior
- Suporte de backup de instantâneo baseado em armazenamento para ambientes HANA MDC (Contêiner de Vários Bancos de Dados) com vários locatários com SAP HANA 2.0 SPS4 e superior
A criação de backups de instantâneos baseados em armazenamento é um procedimento simples, composto por quatro etapas,
- Criar um instantâneo do banco de dados (interno) do HANA - uma atividade que você ou as ferramentas precisam executar
- O SAP HANA grava os dados nos arquivos de dados para criar um estado consistente no armazenamento - o HANA executa essa etapa como resultado da criação de um instantâneo do HANA
- Criar um instantâneo no volume /hana/data no armazenamento - uma etapa que você ou que ferramentas que precisam executar. Não é necessário fazer um instantâneo no volume /hana/log
- Excluir o instantâneo do banco de dados (interno) do HANA e retomar a operação normal - uma etapa que você ou que ferramentas precisam executar
Aviso
Esquecer a última etapa ou falhar na execução da ú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';
az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname
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. Um exemplo é o script Python "ntaphana_azure.py", disponível no GitHub. https://github.com/netapp/ntaphana É um código de exemplo fornecido "no estado em que se encontra" sem nenhuma manutenção ou suporte.
Cuidado
Um instantâneo em si não é um backup protegido, pois está localizado no mesmo armazenamento físico que o volume do qual você acabou de fazer um instantâneo. É obrigatório "proteger" pelo menos um instantâneo por dia em um local diferente. Isso pode ser feito no mesmo ambiente, em uma região remota do Azure ou no Armazenamento de Blobs do Azure.
Soluções disponíveis para backup constante de aplicativo baseado em instantâneo de armazenamento:
- Microsoft O que é a ferramenta Instantâneo Consistente com Aplicativos do Azure é uma ferramenta de linha de comando que permite a proteção de dados para bancos de dados de terceiros. Ela processa toda a orquestração necessária para colocar os bancos de dados em um estado consistente com aplicativos antes de obter um instantâneo de armazenamento. Depois que o instantâneo de armazenamento for obtido, a ferramenta retornará os bancos de dados para um estado operacional. O AzAcSnap dá suporte a backups baseados em instantâneo para o HANA em Instâncias Grandes e o Azure NetApp Files. Para saber mais detalhes, leia o artigo O que é a ferramenta Instantâneo Consistente com Aplicativos do Azure
- Para usuários dos produtos de backup do CommVault, outra opção é o CommVault IntelliSnap V.11.21 e versões mais recentes. Essa ou versões mais recentes do CommVault oferecem suporte ao instantâneo do Azure NetApp Files. O artigo CommVault IntelliSnap 11.21 fornece mais informações.
Fazer backup do instantâneo usando o Armazenamento de Blobs do Azure
Fazer backup no Armazenamento de Blobs do Azure é um método econômico e rápido para salvar backups de instantâneos do armazenamento de banco de dados do HANA baseados em ANF. Para salvar os instantâneos no armazenamento de Blob do Azure, a ferramenta AzCopy é a preferencial. Baixe a versão mais recente dessa ferramenta e instale-a, por exemplo, no diretório bin em que o script Python do GitHub está instalado. Baixe a 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, o azcopy manterá os diretórios de origem e de destino sincronizados. O uso do parâmetro --delete-destination é importante. Sem esse parâmetro, o azcopy não exclui arquivos no site de destino e a utilização de espaço no lado do destino aumentaria. Crie um contêiner de blob de blocos em sua Conta de Armazenamento do Azure. Em seguida, crie a chave SAS para o contêiner de blobs e sincronize a pasta de instantâneos com o contêiner de blobs do Azure.
Por exemplo, se um instantâneo diário deve ser sincronizado com o contêiner de blobs do Azure para proteger os dados. E apenas um instantâneo deve ser mantido. O comando a seguir 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óximas etapas
Leia o artigo: