Partilhar via

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

  • Artigo

O Azure fornece diferentes tipos de armazenamento que são adequados para VMs 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 listam como:

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

O Azure oferece dois métodos de implantação para VHDs no Azure Standard e no armazenamento premium 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 seus SLAs em IOPS e taxa de transferência de armazenamento, consulte a documentação do Azure para discos gerenciados.

Importante

Independentemente do tipo de armazenamento do Azure escolhido, o sistema de arquivos usado nesse armazenamento precisa ser suportado pelo SAP para o sistema operacional específico e o DBMS. A nota de suporte SAP #2972496 lista os sistemas de arquivos suportados para diferentes sistemas operacionais e bancos de dados, incluindo o SAP HANA. Isso se aplica a todos os volumes que o SAP HANA possa acessar para leitura e gravação de qualquer tarefa. Usando especificamente o NFS no Azure para SAP HANA, restrições adicionais de versões do NFS se aplicam, conforme declarado posteriormente neste artigo

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

  • O armazenamento premium do Azure v1 - /hana/log é necessário para ser suportado pelo Azure Write Accelerator. O volume /hana/data pode ser colocado no armazenamento premium v1 sem o Azure Write Accelerator ou no disco Ultra. O armazenamento premium do Azure v2 ou o SSD premium do Azure v2 não está suportando o uso do Azure Write Accelerator
  • Disco Ultra do Azure pelo menos para o volume /hana/log . O volume /hana/data pode ser colocado no armazenamento premium v1/v2 sem o Azure Write Accelerator ou para obter tempos de reinicialização mais rápidos Ultra disk
  • Volumes NFS v4.1 sobre os Arquivos NetApp do Azure para /hana/log e /hana/data. O volume de /hana/shared pode usar o protocolo NFS v3 ou NFS v4.1

Com base na experiência adquirida 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 bloco do Azure certificados para compartilhamentos HANA E NFS com base nos Arquivos NetApp do Azure. Por exemplo, é possível colocar /hana/data no armazenamento premium v1 ou v2 e /hana/log pode ser colocado no armazenamento em disco Ultra para obter a baixa latência 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 em bloco do Azure certificados pelo HANA. Há suporte para o uso de NFS sobre ANF para um dos volumes (como /hana/data) e armazenamento premium do Azure v1/v2 ou disco Ultra para o outro volume (como /hana/log).

No mundo local, você raramente precisava se preocupar com os subsistemas de E/S e seus recursos. O motivo era que o fornecedor do dispositivo precisava garantir 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 das características mínimas de taxa de transferência recomendadas pela SAP são:

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

Dado que a baixa latência de armazenamento é crítica para os sistemas DBMS, mesmo que o DBMS, como o SAP HANA, mantenha os dados na memória. O caminho crítico no armazenamento geralmente está em torno das gravações de log de transações dos sistemas DBMS. Mas também operações como gravar savepoints ou carregar dados na memória após a recuperação de falhas podem ser críticas. Portanto, é obrigatório usar o armazenamento premium do Azure v1/v2, Ultra disk 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
  • A taxa de transferência geral de E/S da VM e os limites de IOPS em mente ao dimensionar ou decidir por uma VM. A taxa de transferência geral de armazenamento de VM está documentada no artigo Tamanhos de máquina virtual otimizados para memória
  • Ao decidir pela configuração de armazenamento, tente ficar abaixo da taxa de transferência geral da VM com sua configuração /hana/volume de dados . SAP HANA escrevendo savepoints, HANA pode ser agressivo emitindo E/S. É facilmente possível ultrapassar os limites de taxa de transferência do seu volume /hana/data ao escrever um savepoint. Se o(s) seu(s) disco(s) que criam o volume /hana/data tiverem uma taxa de transferência maior do que a sua VM permite, você poderá se deparar com situações em que a taxa de transferência utilizada pela gravação de savepoint está interferindo com as demandas de taxa de transferência das gravações de log de refazer. Uma situação que pode afetar a taxa de transferência do aplicativo
  • Se você estiver considerando usar a Replicação do Sistema HANA, o armazenamento usado para /hana/data em cada réplica deve ser o mesmo e o tipo de armazenamento usado para /hana/log em cada réplica deve ser o mesmo. Por exemplo, não há suporte para o uso do armazenamento premium do Azure v1 para /hana/data com uma VM e o disco Azure Ultra para /hana/data em outra VM executando uma réplica da mesma configuração de replicação do Sistema HANA

Importante

As sugestões para as configurações de armazenamento neste ou em documentos subsequentes servem como instruções para começar. Executando a carga de trabalho e analisando os padrões de utilização do armazenamento, você pode perceber que não está utilizando toda a largura de banda de armazenamento ou IOPS fornecidas. Você pode considerar reduzir o tamanho do armazenamento então. Ou, pelo contrário, sua carga de trabalho pode precisar de mais taxa de transferência de armazenamento do que o sugerido com essas configurações. Como resultado, talvez seja necessário implantar mais capacidade, IOPS ou taxa de transferência. No campo da tensão entre a capacidade de armazenamento necessária, a latência de armazenamento necessária, a taxa de transferência de armazenamento e IOPS necessárias e a configuração menos dispendiosa, o Azure oferece tipos de armazenamento diferentes suficientes com diferentes capacidades e diferentes faixas de preço para encontrar e ajustar ao compromisso certo para si e para a sua carga de trabalho 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 relação preço/desempenho ao distribuir o volume /hana/data e/ou /hana/log em vários discos do Azure. Em vez de implantar volumes de disco maiores que forneçam mais 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 os gerenciadores de volumes LVM e MDADM, que fazem parte do Linux. O método de striping de discos tem décadas e é bem conhecido. Por mais benéfico que esses volumes distribuídos sejam para chegar aos recursos de IOPS ou taxa de transferência que você pode precisar, ele adiciona complexidades em torno do gerenciamento desses volumes distribuídos. Especialmente nos casos em que os volumes precisam ser ampliados em capacidade. Pelo menos para /hana/data, a SAP introduziu um método alternativo que atinge o mesmo objetivo do striping em vários discos do Azure. Desde o SAP HANA 2.0 SPS03, o servidor de indexação HANA é capaz de distribuir sua atividade de E/S em vários arquivos de dados HANA, localizados em diferentes discos do Azure. A vantagem é que você não precisa cuidar da criação e do gerenciamento de um volume distribuído em diferentes discos do Azure. A funcionalidade SAP HANA de particionamento de volume de dados é descrita em detalhes em:

Lendo os detalhes, fica evidente que a aplicação dessa funcionalidade elimina as complexidades dos conjuntos de faixas baseados no gerenciador de volumes. Você também percebe que o particionamento de volume de dados 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 IOPS ou limitações de taxa de transferência.

Modo Agendador de E/S Linux

O Linux tem vários modos diferentes de agendamento de E/S. A recomendação comum através dos fornecedores de Linux e 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 nenhum para o modo (multifila) se ainda não tiver sido feito pelos perfis saptune SLES. Os detalhes são referenciados em:

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

Tamanhos de distribuição ao usar gerenciadores de volumes lógicos

Se estiver a utilizar LVM ou mdadm para criar conjuntos de distribuição em vários discos premium do Azure, tem de definir tamanhos de distribuição. Esses tamanhos diferem entre /hana/data e /hana/log. Recomendação: Como tamanhos de listras a recomendação é usar:

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

Nota

O tamanho da faixa para /hana/data foi alterado de recomendações anteriores que pediam 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 está proporcionando um desempenho ligeiramente melhor. Também alteramos a recomendação para tamanhos de distribuição de /hana/log de 32 KB para 64 KB para obter taxa de transferência suficiente com tamanhos de E/S maiores.

Nota

Você não precisa 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 é puramente para configurar volumes que fornecem IOPS e/ou taxa de transferência de E/S suficientes.

Acumular vários discos do Azure sob um conjunto de distribuição é acumular a partir de um lado de IOPS e taxa de transferência de armazenamento. Portanto, se você colocar um conjunto de distribuição em mais de 3 x discos P30 Azure premium storage v1, ele deverá oferecer três vezes o IOPS e três vezes a taxa de transferência de armazenamento de um único disco P30 do Azure Premium Storage 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 sistemas de arquivos SAP HANA /data, /log e /shared não devem ser colocados em um grupo de volumes padrão ou raiz. É altamente recomendável seguir a orientação dos fornecedores do Linux, que normalmente é criar grupos de volumes individuais para /data, /log e /shared.

Considerações para o sistema de arquivos compartilhados HANA

Ao dimensionar os sistemas de arquivos HANA, a maior atenção é dada aos sistemas HANA de dados e arquivos de log. 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 HANA.
Se subdimensionado, /hana/shared pode 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 HA, respostas lentas do sistema de arquivos compartilhado, ou seja , /hana/shared podem causar tempos limite de recursos de cluster. Esses tempos limite podem levar a failovers desnecessários, porque os agentes de recursos HANA podem presumir incorretamente que o banco de dados não está disponível.

As diretrizes SAP para /hana/shared tamanhos recomendados seriam parecidas com:

Volume Tamanho recomendado
/HANA/Expansão compartilhada Mínimo (1 TB, 1 x RAM)
/hana/expansão compartilhada 1 x RAM do nó de trabalho
por quatro nós de trabalho

Consulte as seguintes notas SAP para obter mais detalhes:
3288971 - FAQ: SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager em ambientes de replicação do sistema SAP HANA
1999930 - FAQ: SAP HANA I/O Analysis

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

Configurações do Azure Premium Storage v1 para HANA

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

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

Para obter recomendações detalhadas de configuração de armazenamento HANA usando o armazenamento ssd premium v2 do Azure, leia o documento Configurações de armazenamento SAP HANA Azure virtual machine Premium SSD v2.

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

Para obter recomendações detalhadas de configuração de armazenamento HANA usando o Azure Ultra Disk, leia o documento SAP HANA Azure machine Ultra Disk storage configurations.

Volumes NFS v4.1 nos Arquivos NetApp do Azure

Para obter detalhes sobre os Arquivos NetApp do Azure para HANA, leia os volumes do documento NFS v4.1 nos Arquivos NetApp do Azure para SAP HANA.

Próximos passos

Para obter mais informações, consulte: