Configurações de armazenamento de máquina virtual do SAP HANA no Azure

  • Artigo

O Azure fornece diferentes tipos de armazenamento principais adequados a máquinas virtuais do Azure que executam o SAP HANA. Os tipos de armazenamento do Azure certificados pelo SAP HANA que podem ser considerados para implantações do SAP HANA são listados como:

Para saber mais sobre esses tipos de disco, confira o artigo Tipos de Armazenamento do Azure para carga de trabalho do SAP e Selecione um tipo de disco

O Azure oferece dois métodos de implantação para VHDs nos Armazenamentos Standard e Premium do Azure v1/v2. Esperamos que você aproveite o disco gerenciado do Azure para implantações de armazenamento em bloco do Azure.

Para obter uma lista de tipos de armazenamento e os respectivos SLAs em IOPS e taxa de transferência de armazenamento, revise a documentação do Azure para discos gerenciado.

Importante

Independentemente do tipo de armazenamento do Azure escolhido, o sistema de arquivos usado nesse armazenamento precisa ter suporte do SAP para o sistema operacional específico e o DBMS. A Nota de suporte nº 2972496 do SAP lista os sistemas de arquivos com suporte para diferentes sistemas operacionais e bancos de dados, incluindo o SAP HANA. Isso se aplica a todos os volumes que o SAP HANA pode acessar para leitura e gravação de qualquer tarefa. Especificamente usando o NFS no Azure para o SAP HANA, restrições adicionais de versões do NFS se aplicam conforme mencionado mais adiante neste artigo

As condições mínimas certificadas pelo SAP HANA para os diferentes tipos de armazenamento são:

  • Armazenamento premium do Azure v1: deve haver suporte para o /hana/log no Acelerador de Gravação do Azure. O volume /hana/data pode ser colocado no armazenamento premium v1 sem o Acelerador de Gravação do Azure ou no Disco Ultra. O armazenamento premium do Azure v2 ou o SSD premium do Azure v2 não dá suporte ao uso do Acelerador de Gravação do Azure
  • Disco Ultra do Azure pelo menos para o volume /hana/log. O volume /hana/data pode ser colocado em qualquer armazenamento premium v1/v2 sem o Acelerador de Gravação do Azure ou para obter um disco Ultra com tempos de reinicialização mais rápidos
  • Os volumes NFS v4.1 baseados no Azure NetApp Files para /hana/log e /hana/data. O volume /hana/shared pode usar o protocolo NFS v3 ou NFS v4.1

Com base na experiência obtida com os clientes, alteramos o suporte para combinar diferentes tipos de armazenamento entre /hana/data e /hana/log. Há suporte para combinar o uso dos diferentes armazenamentos de blocos do Azure certificados para compartilhamentos HANA e NFS com base no Azure NetApp Files. Por exemplo, é possível colocar /hana/data no armazenamento Premium v1/v2 e /hana/log pode ser colocado no armazenamento do Disco Ultra para obter a latência baixa necessária. Se você usar um volume baseado em ANF para /hana/data, o volume /hana/log também poderá ser colocado em um dos tipos de armazenamento de blocos do Azure certificados pelo HANA. O uso do NFS baseado no ANF para um dos volumes (como /hana/data) e o armazenamento premium do Azure v1/v2 ou Disco Ultra para o outro volume (como /hana/log) tem suporte.

No mundo local, você raramente precisava preocupar-se com os subsistemas de E/S e as funcionalidades. O motivo era que o fornecedor do dispositivo precisava certificar-se de que os requisitos mínimos de armazenamento fossem atendidos para o SAP HANA. Ao criar a infraestrutura do Azure por conta própria, você deve estar ciente de alguns desses requisitos emitidos pelo SAP. Algumas características mínimas da taxa de transferência que o SAP recomenda são:

  • Leitura/gravação em /hana/log de 250 MB/s com tamanhos de E/S de 1 MB
  • Atividade de leitura de pelo menos 400 MB/s para /hana/data para tamanhos de E/S de 16 MB e 64 MB
  • Atividade de gravação de pelo menos 250 MB/s para /hana/data com tamanhos de E/S de 16 MB e 64 MB

Uma vez que a baixa latência de armazenamento é crítica aos sistemas DBMS, mesmo que o DBMS, como SAP HANA, mantenha os dados na memória. O caminho crítico no armazenamento é geralmente em torno das gravações de log de transações dos sistemas DBMS. Mas também operações como gravar pontos de salvamento ou carregar dados na memória após a recuperação de falhas poderão ser críticas. Portanto, é obrigatório usar o armazenamento Premium do Azure v1/v2, Disco Ultra ou ANF para os volumes /hana/data e /hana/log.

Alguns princípios orientadores na seleção da configuração de armazenamento para HANA podem ser listados como:

  • Decida o tipo de armazenamento com base nos Tipos de Armazenamento do Azure para carga de trabalho SAP e Selecione um tipo de disco
  • Considere a taxa de transferência de E/S geral e limites de IOPS ao dimensionar ou escolher uma VM. A taxa de transferência de armazenamento de VM geral está documentada no artigo Tamanhos da máquina virtual otimizada para memória
  • Ao decidir a configuração de armazenamento, tente ficar abaixo da taxa de transferência geral da VM com a configuração do volume /hana/data. Os pontos de salvamento de gravação do SAP HANA pode ser a agressivo na emissão de E/S. É fácil atingir os limites de taxa de transferência do volume /hana/data ao gravar um ponto de salvamento. Se os discos que criam o volume /hana/data tiverem uma taxa de transferência maior do que a sua VM permitir, você poderá se deparar com situações onde a taxa de transferência utilizada pela gravação do ponto de salvamento está interferindo nas demandas de taxa de transferência das gravações do log de restauração. Uma situação que pode afetar a taxa de transferência do aplicativo
  • No caso da replicação de sistema do HANA, tanto o armazenamento usado para /hana/data quanto o tipo de armazenamento usado para /hana/log em cada réplica devem ser os mesmos. Por exemplo, não há suporte para o uso do armazenamento Premium do Azure v1 para /hana/data com uma VM e o Disco Ultra do Azure para /hana/data em outra VM que está executando uma réplica da mesma configuração da replicação de sistema do HANA

Importante

As sugestões para as configurações de armazenamento nestes ou em documentos subsequentes são destinadas como instruções para começar. Ao executar a carga de trabalho e analisar os padrões de utilização de armazenamento, você pode perceber que não está utilizando toda a largura de banda de armazenamento ou IOPS fornecidos. Neste caso, você pode considerar o downsizing no armazenamento. Ou sua carga de trabalho pode precisar de mais taxa de transferência de armazenamento do que o sugerido para essas configurações. Neste caso, talvez seja necessário implantar mais capacidade, IOPS ou taxa de transferência. Na busca de equilíbrio entre a capacidade de armazenamento necessária, a latência de armazenamento necessária, a taxa de transferência de armazenamento e o IOPS necessários e a configuração mais barata, o Azure oferece tipos de armazenamento diferentes com recursos variados e pontos de preço diferentes para encontrar e ajustar o compromisso correto para você e sua carga de trabalho do HANA.

Conjuntos de distribuição versus particionamento de volume de dados do SAP HANA

Usando o armazenamento Premium do Azure v1, você pode atingir a melhor taxa de preço/desempenho ao distribuir o volume de /hana/data e/ou /hana/log em vários discos do Azure. Em vez de implantar volumes de disco maiores que fornecem mais informações sobre IOPS ou taxa de transferência necessária. A criação de um único volume em vários discos do Azure pode ser realizada com gerenciadores de volume LVM e MDADM, que fazem parte do Linux. O método de distribuição de discos é antigo e bem conhecido. Por mais benéficos que sejam os volumes distribuídos para atingir os recursos de IOPS ou de taxa de transferência que você precise, eles adicionam complexidades ao gerenciamento desses volumes distribuídos. Especialmente quando os volumes precisam ter sua capacidade estendida. Pelo menos para /hana/data, o SAP introduziu um método alternativo que alcança a mesma meta que a distribuição entre vários discos do Azure. Desde o SAP HANA 2.0 SPS03, o servidor de indexação do HANA é capaz de distribuir sua atividade de E/S em vários arquivos de dados do HANA localizados em discos diferentes do Azure. A vantagem é que você não precisa cuidar da criação e do gerenciamento de um volume distribuído em discos diferentes do Azure. A funcionalidade SAP HANA do particionamento de volume de dados está detalhada em:

Lendo os detalhes, fica aparente que a aplicação dessa funcionalidade retira as complexidades dos conjuntos de distribuição baseados no gerenciador de volumes. Você também percebe que o particionamento do volume de dados do HANA não está funcionando apenas para o armazenamento de blocos do Azure, como o armazenamento Premium do Azure v1/v2. Você também pode usar essa funcionalidade para distribuir entre compartilhamentos NFS caso esses compartilhamentos tenham limitações de IOPS ou taxa de transferência.

Modo Agendador de E/S do Linux

O Linux possui vários modos de agendamento de E/S diferentes. A recomendação comum por meio de fornecedores do Linux e do SAP é reconfigurar o modo de agendador de E/S para volumes de disco do modo mq-deadline ou kyber para o modo noop (não multifila) ou none (multifila), se ainda não foi feito pelos perfis do SLES saptune. Detalhes são referenciados na:

No Red Hat, deixe as configurações como estabelecidas pelos perfis de ajuste específicos para os diferentes aplicativos SAP.

Tamanhos da listra ao usar gerenciadores de volume lógico

Se você estiver usando LVM ou mdadm para criar conjuntos de distribuição em vários discos Premium do Azure, será necessário definir tamanhos de distribuição. Esses tamanhos diferem entre /hana/data e /hana/log. Recomendação: com tamanhos de faixa, o recomendável é usar:

  • 256 KB para /hana/data
  • 64 KB para hana/log

Observação

O tamanho de faixa para /hana/data foi alterado das recomendações anteriores que chamam 64 KB ou 128 KB para 256 KB com base nas experiências do cliente com versões mais recentes do Linux. O tamanho de 256 KB fornece um desempenho ligeiramente melhor. Também alteramos a recomendação para os tamanhos de distribuição de /hana/log de 32 KB para 64 KB para obter uma taxa de transferência suficiente com tamanhos maiores de E/S.

Observação

Não é necessário configurar nenhum nível de redundância usando volumes RAID, pois o armazenamento em bloco do Azure mantém três imagens de um VHD. O uso de um conjunto de distribuição com discos Premium do Azure é exclusivamente para configurar volumes que fornecem IOPS e/ou taxa de transferência de E/S suficiente.

A acumulação de vários discos do Azure sob um conjunto de distribuição é cumulativa de um lado de taxa de transferência de IOPS e armazenamento. Portanto, se você colocar um conjunto de distribuição em 3 em discos P30 de armazenamento premium do Azure v1, ele deverá fornecer três vezes a IOPS e três vezes a taxa de transferência de armazenamento de um único disco P30 do Armazenamento premium do Azure v1.

Importante

Caso você esteja usando LVM ou mdadm como gerenciador de volumes para criar conjuntos de distribuição em vários discos Premium do Azure, os três FileSystems do SAP HANA, quais sejam, /data, /log e /shared, não devem ser colocados em um grupo de volumes padrão ou raiz. É altamente recomendável seguir as diretrizes de fornecedores do Linux, que costumam criar grupos de volumes individuais para /data, /log e /shared.

Considerações para o sistema de arquivos compartilhado do HANA

Ao dimensionar os sistemas de arquivos do HANA, a maior parte da atenção é dada aos sistemas HANA de arquivos de log e de dados. No entanto, /hana/shared também desempenha um papel importante na operação de um sistema HANA estável, pois hospeda componentes essenciais como os binários do HANA.
Se for subdimensionado, /hana/shared poderá ficar saturado de E/S devido a operações excessivas de leitura/gravação, por exemplo, ao escrever um despejo grande ou durante o rastreamento intensivo ou se o backup for gravado no sistema de arquivos /hana/shared. A latência também pode aumentar.

Se o sistema HANA estiver em uma configuração de HA, respostas lentas do sistema de arquivos compartilhado, ou seja, /hana/shared pode atingir tempos limite de recursos do cluster. Esses tempos limite podem levar a failovers desnecessários, pois os agentes de recursos do HANA podem assumir incorretamente que o banco de dados não está disponível.

As diretrizes do SAP para tamanhos recomendados do /hana/shared seriam semelhantes a:

Volume Tamanho recomendado
Expansão vertical do /hana/shared Mín. (1 TB, 1 x RAM)
Expansão horizontal /hana/shared 1 x RAM do nó de trabalho
por quatro nós de trabalho

Consulte as seguintes observações do SAP para obter mais detalhes:
3288971 – Perguntas frequentes: Gerenciador de Recursos de Cluster SUSE HAE/RedHat HAA Pacemaker em Ambientes de Replicação do Sistema SAP HANA
1999930 – Perguntas frequentes: Análise de E/S do SAP HANA

Como melhor prática, dimensione /hana/shared para evitar gargalos de desempenho. Lembre-se de que um sistema de arquivos /hana/shared contribui para a estabilidade e a confiabilidade do sistema SAP HANA, especialmente em cenários de HA.

Configurações de Armazenamento Premium do Azure v1 para HANA

Para obter as recomendações detalhadas da configuração de armazenamento do HANA usando o armazenamento Premium do Azure v1, leia o documento Configurações de armazenamento de SSD Premium de máquina virtual do SAP HANA no Azure.

Configurações do SSD Premium v2 do Azure para HANA

Para obter as recomendações detalhadas da configuração de armazenamento do HANA usando o armazenamento do SSD Premium v2 do Azure, leia o documento Configurações de armazenamento do SSD Premium v2 de máquina virtual do SAP HANA no Azure.

Configuração de armazenamento de disco Ultra do Azure para SAP HANA

Para obter as recomendações detalhadas da configuração de armazenamento do HANA usando o Disco Ultra do Azure, leia o documento Configurações de Armazenamento do Disco Ultra de máquina virtual do SAP HANA no Azure.

Volumes NFS v4.1 em Azure NetApp Files

Para obter detalhes sobre o ANF para HANA, leia o documento Volumes NFS v4.1 no Azure NetApp Files para SAP HANA.

Próximas etapas

Para obter mais informações, consulte: