Tipos de Armazenamento do Microsoft Azure para a carga de trabalho SAP

  • Artigo

O Azure tem vários tipos de armazenamento que diferem muito em recursos, taxa de transferência, latência e preços. Alguns dos tipos de armazenamento não são, ou são de uso limitado para cenários SAP. Considerando que vários tipos de armazenamento do Azure são adequados ou otimizados para cenários específicos de carga de trabalho SAP. Especialmente para o SAP HANA, alguns tipos de armazenamento do Azure foram certificados para uso com o SAP HANA. Neste documento, analisamos os diferentes tipos de armazenamento e descrevemos sua capacidade e usabilidade com cargas de trabalho SAP e componentes SAP.

Observação sobre as unidades usadas ao longo deste artigo. Os fornecedores de nuvem pública passaram a usar GiB (Gibibyte) ou TiB (Tebibyte como unidades de tamanho, em vez de Gigabyte ou Terabyte. Portanto, toda a documentação e prática do Azure estão usando essas unidades. Ao longo do documento, estamos fazendo referência a essas unidades de tamanho de unidades MiB, GiB e TiB exclusivamente. Talvez seja necessário planejar com MB, GB e TB. Portanto, esteja ciente de algumas pequenas diferenças nos cálculos se precisar dimensionar para uma taxa de transferência de 400 MiB/seg, em vez de uma taxa de transferência de 250 MiB/seg.

Resiliência de armazenamento do Microsoft Azure

O armazenamento do Microsoft Azure de HDD padrão, SSD padrão, armazenamento premium do Azure, SSD Premium v2 e disco Ultra mantém o VHD base (com SO) e discos de dados conectados à VM ou VHDs em três cópias em três nós de armazenamento diferentes. O failover para outra réplica e a propagação de uma nova réplica se houver uma falha no nó de armazenamento são transparentes. Como resultado dessa redundância, NÃO é necessário usar nenhum tipo de camada de redundância de armazenamento em vários discos do Azure. Esse fato é chamado de LRS (Local Redundant Storage, armazenamento redundante local). O LRS é padrão para esses tipos de armazenamento no Azure. Os Arquivos NetApp do Azure fornecem redundância suficiente para alcançar os mesmos SLAs que outros armazenamentos nativos do Azure.

Há vários outros métodos de redundância, todos descritos no artigo Replicação do Armazenamento do Azure que se aplica a alguns dos diferentes tipos de armazenamento que o Azure tem a oferecer.

Nota

Usando o armazenamento do Azure para armazenar dados de banco de dados e refazer arquivo de log, o LRS é o único nível de resiliência com suporte neste momento

Lembre-se também de que diferentes tipos de armazenamento do Azure influenciam os SLAs de disponibilidade de VM única, conforme lançados no SLA para Máquinas Virtuais.

Discos gerenciados do Azure

Os discos gerenciados são um tipo de recurso no Azure Resource Manager que pode ser usado em vez de VHDs armazenados nas Contas de Armazenamento do Azure. Os Managed Disks alinham-se automaticamente com o [availability set][virtual-machines-manage-availability] da máquina virtual à qual estão ligados. Com esse alinhamento, você experimenta uma melhoria da disponibilidade de sua máquina virtual e dos serviços que estão sendo executados na máquina virtual. Para obter mais informações, leia o artigo de visão geral.

Nota

Exigimos que as novas implantações de VMs que usam o armazenamento em bloco do Azure para seus discos (todo o armazenamento do Azure, exceto Arquivos NetApp do Azure e Arquivos do Azure) precisem usar discos gerenciados do Azure para os discos VHD/OS de base e discos de dados que armazenam arquivos de banco de dados SAP. Independentemente de você implantar as VMs por meio do conjunto de disponibilidade, entre zonas de disponibilidade ou independente dos conjuntos e zonas. Os discos usados com a finalidade de armazenar backups não precisam necessariamente ser discos gerenciados.

Cenários de armazenamento com cargas de trabalho SAP

O armazenamento persistente é necessário na carga de trabalho SAP em vários componentes da pilha que você implanta no Azure. Esses cenários listam, no mínimo, como:

  • Persista o VHD base da sua VM que contém o sistema operacional e outros softwares instalados nesse disco. Este disco/VHD é a raiz da sua VM. Quaisquer alterações feitas a ele, precisam ser persistentes. Assim, que da próxima vez, você parar e reiniciar a VM, todas as alterações feitas antes ainda existem. Especialmente nos casos em que a VM está sendo implantada pelo Azure em outro host que não estava sendo executado originalmente
  • Discos de dados persistentes. Esses discos são VHDs que você anexa para armazenar dados do aplicativo. Esses dados de aplicativo podem ser dados e arquivos de log/refazer de um banco de dados, arquivos de backup ou instalações de software. Significa qualquer disco além do VHD base que contém o sistema operacional
  • Compartilhamentos de arquivos ou discos compartilhados que contêm seu diretório de transporte global para NetWeaver ou S/4HANA. O conteúdo desses compartilhamentos é consumido por software em execução em várias VMs ou é usado para criar cenários de cluster de failover de alta disponibilidade
  • O diretório /sapmnt ou compartilhamentos de arquivos comuns para processos EDI ou similares. O conteúdo desses compartilhamentos é consumido por software em execução em várias VMs ou é usado para criar cenários de cluster de failover de alta disponibilidade

Nas próximas seções, os diferentes tipos de armazenamento do Azure e sua usabilidade para os quatro cenários de carga de trabalho SAP são discutidos. Uma categorização geral de como os diferentes tipos de armazenamento do Azure devem ser usados está documentada no artigo Quais tipos de disco estão disponíveis no Azure?. As recomendações para usar os diferentes tipos de armazenamento do Azure para carga de trabalho SAP não serão muito diferentes.

Para obter restrições de suporte sobre tipos de armazenamento do Azure para SAP NetWeaver/camada de aplicativo do S/4HANA, leia a nota de suporte do SAP 2015553. Para obter os tipos de armazenamento do Azure certificados e suportados pelo SAP HANA, leia o artigo Configurações de armazenamento de máquina virtual do SAP HANA Azure.

As seções que descrevem os diferentes tipos de armazenamento do Azure fornecerão mais informações básicas sobre as restrições e possibilidades de uso do armazenamento suportado pelo SAP.

Opções de armazenamento ao usar a replicação DBMS

Nossas arquiteturas de referência preveem o uso de funcionalidades DBMS como SQL Server Always On, HANA System Replication, Db2 HADR ou Oracle Data Guard. Caso você esteja usando essas tecnologias entre duas ou várias máquinas virtuais do Azure, os tipos de armazenamento escolhidos para cada uma das VMs devem ser os mesmos. Significa que a configuração de armazenamento entre o nó ativo e o nó de réplica na configuração HA do DBMS precisa ser a mesma.

Recomendações de armazenamento para cenários de armazenamento SAP

Antes de entrar nos detalhes, apresentamos o resumo e as recomendações já no início do documento. Considerando que os detalhes para os tipos específicos de armazenamento do Azure estão seguindo esta seção do documento. Quando resumimos as recomendações de armazenamento para os cenários de armazenamento SAP em uma tabela, parece:

Cenário de utilização HDD Standard SSD Standard Armazenamento Premium SSD Premium v2 Disco Ultra Azure NetApp Files Azure Premium Files
Disco do SO Não adequado Restrito adequado (não-prod) Recomendado Não é possível Não é possível Não é possível Não é possível
Diretório Global de Transportes Não suportado Não suportado Recomendado Recomendado Recomendado Recomendado Altamente Recomendado
/sapmnt Não adequado Restrito adequado (não-prod) Recomendado Recomendado Recomendado Recomendado Altamente Recomendado
Volume de dados DBMS Famílias VM SAP HANA M/Mv2 Não suportado Não suportado Recomendado Recomendado Recomendado Recomendado2 Não suportado
Volume de log DBMS Famílias VM SAP HANA M/Mv2 Não suportado Não suportado Recomendado1 Recomendado Recomendado Recomendado2 Não suportado
Volume de dados DBMS Famílias de VM SAP HANA Esv3/Edsv4 Não suportado Não suportado Recomendado Recomendado Recomendado Recomendado2 Não suportado
Volume de log DBMS Famílias de VM SAP HANA Esv3/Edsv4 Não suportado Não suportado Não suportado Recomendado Recomendado Recomendado2 Não suportado
Volume compartilhado HANA Não suportado Não suportado Recomendado Recomendado Recomendado Recomendado Recomendado3
DBMS Volume de dados não-HANA Não suportado Restrito adequado (não-prod) Recomendado Recomendado Recomendado Somente para versões específicas do Oracle no Oracle Linux, DB2 e SAP ASE no SLES/RHEL Linux Não suportado
Volume de log DBMS não famílias de VM HANA M/Mv2 Não suportado Restrito adequado (não-prod) Recomendado1 Recomendado Recomendado Somente para versões específicas do Oracle no Oracle Linux, DB2 e SAP ASE no SLES/RHEL Linux Não suportado
Volume de log DBMS não-HANA não-famílias de VM M/Mv2 Não suportado restrito adequado (não-prod) Adequado para cargas de trabalho até médias Recomendado Recomendado Somente para versões específicas do Oracle no Oracle Linux, DB2 e SAP ASE no SLES/RHEL Linux Não suportado

1 Com o uso do Azure Write Accelerator para famílias de VM M/Mv2 para volumes de log de log/redo

2 Usar ANF requer que /hana/data e /hana/log estejam em ANF

3 Até agora testado apenas no SLES

Características que você pode esperar da lista de diferentes tipos de armazenamento, como:

Cenário de utilização HDD Standard SSD Standard Armazenamento Premium SSD Premium v2 Disco Ultra Azure NetApp Files Azure Premium Files
SLA de Taxa de Transferência/IOPS No No Sim Sim Sim Sim Sim
Leituras de latência Máximo Médio a alto Mínimo submilissegundos submilissegundos submilissegundos lowa
Gravações de latência Máximo Médio a alto Baixo (submilissegundo1) submilissegundos submilissegundos submilissegundos lowa
HANA suportado No Não sim 1 Sim Sim Sim No
Snapshots de disco possíveis Sim Sim Sim No No Sim No
Alocação de discos em diferentes clusters de armazenamento ao usar conjuntos de disponibilidade Através de discos geridos Através de discos geridos Através de discos geridos Tipo de disco não suportado com VMs implantadas por meio de conjuntos de disponibilidade Tipo de disco não suportado com VMs implantadas por meio de conjuntos de disponibilidade N.o3 Não
Alinhado com as zonas de disponibilidade Sim Sim Sim Sim Sim Em pré-visualização pública Não
Redundância zonal síncrona Não se destina a discos geridos Não se destina a discos geridos Não suportado para DBMS No No No Sim
Redundância zonal assíncrona Não se destina a discos geridos Não se destina a discos geridos Não suportado para DBMS No Não Em pré-visualização Não
Redundância geográfica Não se destina a discos geridos Não se destina a discos geridos No No Não Possível Não

1 Com o uso do Azure Write Accelerator para famílias de VM M/Mv2 para volumes de log de log/redo

2 Os custos dependem de IOPS provisionadas e taxa de transferência

3 A criação de diferentes pools de capacidade ANF não garante a implantação de pools de capacidade em diferentes unidades de armazenamento

Importante

Confira a seção Arquivos NetApp do Azure deste documento para encontrar detalhes sobre o posicionamento de proximidade de volumes NFS e VMs quando latências inferiores a 1 milissegundo são necessárias.

Armazenamento premium do Azure

O armazenamento SSD premium do Azure foi introduzido com o objetivo de fornecer:

  • Baixa latência de E/S
  • SLAs para IOPS e taxa de transferência
  • Menor variabilidade na latência de E/S

Esse tipo de armazenamento tem como alvo cargas de trabalho de DBMS, tráfego de armazenamento que requer baixa latência de milissegundos de um dígito e SLAs em IOPS e taxa de transferência. A base de custo para o armazenamento premium do Azure não é o volume de dados real armazenado nesses discos, mas a categoria de tamanho desse disco, independentemente da quantidade de dados armazenados no disco. Você também pode criar discos em armazenamento premium que não estão mapeando diretamente para as categorias de tamanho mostradas no artigo SSD Premium. As conclusões deste artigo são:

  • O armazenamento está organizado em intervalos. Por exemplo, um disco na faixa de capacidade de 513 GiB a 1024 GiB compartilha os mesmos recursos e os mesmos custos mensais
  • As IOPS por GiB não estão rastreando linearmente entre as categorias de tamanho. Discos menores abaixo de 32 GiB têm taxas de IOPS mais altas por GiB. Para discos além de 32 GiB a 1024 GiB, a taxa de IOPS por GiB está entre 4-5 IOPS por GiB. Para discos maiores de até 32.767 GiB, a taxa de IOPS por GiB está abaixo de 1
  • A taxa de transferência de E/S para esse armazenamento não é linear com o tamanho da categoria de disco. Para discos menores, como a categoria entre 65 GiB e 128 GiB de capacidade, a taxa de transferência é de cerca de 780 KB por GiB. Enquanto para os discos extremamente grandes, como um disco de 32.767 GiB, a taxa de transferência é de cerca de 28 KB por GiB
  • Os SLAs de IOPS e taxa de transferência não podem ser alterados sem alterar a capacidade do disco

A matriz de recursos para a carga de trabalho SAP tem a seguinte aparência:

Capacidade Comentário Notas/Ligações
VHD base do SO Adequado Todos os sistemas
Disco de dados Adequado Todos os sistemas - Especialmente para SAP HANA
Diretório de transporte global SAP Sim Suportado
SAP sapmnt Adequado Todos os sistemas
Armazenamento de cópias de segurança Adequado Para armazenamento de curto prazo de backups
Partilhas/disco partilhado Não disponível Precisa de Arquivos Premium do Azure ou de terceiros
Resiliência LRS Nenhum GRS ou ZRS disponível para discos
Latência Baixo a médio -
IOPS SLA Sim -
IOPS linear à capacidade semi-linear entre parênteses Preços do Managed Disk
IOPS máximo por disco 20.000 dependentes do tamanho do disco Considere também os limites de VM
SLA de produtividade Sim -
Taxa de transferência linear à capacidade Semi-linear entre parênteses Preços do Managed Disk
Certificação HANA Sim especialmente para SAP HANA
Suporte do Azure Write Accelerator Não -
Expansão do disco Sim -
Snapshots de disco possíveis Sim -
Possíveis instantâneos da VM do Backup do Azure Sim -
Custos Meio -

O armazenamento premium do Azure não atende aos KPIs de latência de armazenamento do SAP HANA com os tipos de cache comuns oferecidos com o armazenamento premium do Azure. Para cumprir os KPIs de latência de armazenamento para gravações de log do SAP HANA, você precisa usar o cache do Azure Write Accelerator conforme descrito no artigo Enable Write Accelerator. O Azure Write Accelerator beneficia todos os outros sistemas DBMS para suas gravações de log de transações e gravações de log de refazer. Portanto, é recomendável usá-lo em todas as implantações do SAP DBMS. Para o SAP HANA, o uso do Azure Write Accelerator para /hana/log com armazenamento premium do Azure é obrigatório.

Resumo: O armazenamento premium do Azure é um dos tipos de armazenamento do Azure recomendados para a carga de trabalho do SAP. A presente recomendação aplica-se aos sistemas de não produção e de produção. O armazenamento premium do Azure é adequado para lidar com cargas de trabalho de banco de dados. O uso do Azure Write Accelerator vai melhorar substancialmente a latência de gravação em relação aos discos premium do Azure. No entanto, para sistemas DBMS com IOPS e taxas de transferência altas, você precisa provisionar a capacidade de armazenamento em excesso. Ou você precisa usar funcionalidades como Espaços de Armazenamento do Windows ou gerenciadores de volumes lógicos no Linux para criar conjuntos de distribuição que oferecem a capacidade desejada de um lado. Mas também o IOPS necessário ou taxa de transferência na melhor eficiência de custo.

Funcionalidade de intermitência do Azure para armazenamento premium

Para discos de armazenamento premium do Azure menores ou iguais a 512 GiB de capacidade, a funcionalidade burst é oferecida. A maneira exata como o bursting de disco funciona é descrita no artigo Disk bursting. Ao ler o artigo, você entende o conceito de acumulação de IOPS e taxa de transferência nos momentos em que sua carga de trabalho de E/S está abaixo das IOPS nominais e da taxa de transferência dos discos (para obter detalhes sobre a taxa de transferência nominal, consulte Preço do disco gerenciado). Você acumulará o delta de IOPS e a taxa de transferência entre seu uso atual e os valores nominais do disco. As explosões são limitadas a um máximo de 30 minutos.

Os casos ideais em que essa funcionalidade de burst pode ser planejada provavelmente serão os volumes ou discos que contêm arquivos de dados para os diferentes DBMS. Espera-se que a carga de trabalho de E/S esperada em relação a esses volumes, especialmente com sistemas de pequeno a médio alcance, se pareça com:

  • Carga de trabalho de leitura baixa a moderada, uma vez que os dados são idealmente armazenados em cache na memória. Ou como com o SAP HANA deve estar completamente na memória
  • Explosões de gravação acionadas por pontos de verificação ou salvamentos de banco de dados emitidos regularmente
  • Carga de trabalho de backup que é lida em um fluxo contínuo nos casos em que os backups não são executados por meio de snapshots de armazenamento
  • Para o SAP HANA, carregue os dados na memória após a reinicialização de uma instância

Especialmente em sistemas DBMS menores, onde sua carga de trabalho está lidando com algumas centenas de transações por segundo apenas, essa funcionalidade de intermitência também pode fazer sentido para os discos ou volumes que armazenam a transação ou o log de refazer. A carga de trabalho esperada em relação a esse disco ou volumes é semelhante a:

  • Gravações regulares no disco que dependem da carga de trabalho e da natureza da carga de trabalho, uma vez que cada confirmação emitida pelo aplicativo provavelmente acionará uma operação de E/S
  • Maior carga de trabalho na taxa de transferência para casos de tarefas operacionais, como criação ou reconstrução de índices
  • Leituras rápidas ao executar backups de log de transações ou refazer logs

SSD Premium do Azure v2

O armazenamento SSD Premium v2 do Azure é uma nova versão do armazenamento premium que foi introduzida com o objetivo de fornecer:

  • Latência de E/S de submilissegundos para tamanhos menores de E/S de leitura e gravação
  • SLAs para IOPS e taxa de transferência
  • Capacidade de pagamento pelo GB provisionado
  • Fornecer um conjunto padrão de IOPS e taxa de transferência de armazenamento por disco
  • Dê a possibilidade de adicionar mais IOPS e taxa de transferência a cada disco e pagar separadamente por esses recursos provisionados extras
  • Passe na certificação SAP HANA sem a ajuda de outras funcionalidades, como o Azure Write Accelerator ou outros caches

Esse tipo de armazenamento tem como alvo cargas de trabalho de DBMS, tráfego de armazenamento que requer latência de submilissegundos e SLAs em IOPS e taxa de transferência. Os discos SSD Premium v2 são fornecidos com um conjunto padrão de 3.000 IOPS e taxa de transferência de 125 MBps. E a possibilidade de adicionar mais IOPS e taxa de transferência a discos individuais. O preço do armazenamento é estruturado de tal forma que a adição de mais taxa de transferência ou IOPS não está influenciando o preço principalmente. No entanto, deixamos a você decidir como será a configuração de armazenamento para SSD Premium v2. Para um início básico, leia Configurações de armazenamento SAP HANA Azure virtual machine Premium SSD v2.

Para as regiões reais, este novo tipo de armazenamento de bloco está disponível e as restrições reais lêem o documento SSD Premium v2.

A matriz de recursos para a carga de trabalho SAP tem a seguinte aparência:

Capacidade Comentário Notas/Ligações
VHD base do SO Não suportado Sem sistema
Disco de dados Adequado Todos os sistemas
Diretório de transporte global SAP Sim Todos os sistemas
SAP sapmnt Adequado Todos os sistemas
Armazenamento de cópias de segurança Adequado Para armazenamento de curto prazo de backups
Partilhas/disco partilhado Não disponível Precisa de Arquivos Premium do Azure ou Arquivos NetApp do Azure
Resiliência LRS Nenhum GRS ou ZRS disponível para discos
Latência submilissegundos -
IOPS SLA Sim -
IOPS linear à capacidade semi-linear Preços do Managed Disk
IOPS máximo por disco 80.000 dependentes do tamanho do disco Considere também os limites de VM
SLA de produtividade Sim -
Taxa de transferência linear à capacidade Semi-linear Preços do Managed Disk
Certificação HANA Sim -
Suporte do Azure Write Accelerator Não -
Expansão do disco Não -
Snapshots de disco possíveis Não -
Possíveis instantâneos da VM do Backup do Azure Não -
Custos Meio -

Ao contrário do armazenamento premium do Azure, o SSD Premium do Azure v2 cumpre os KPIs de latência de armazenamento do SAP HANA. Como resultado, você NÃO precisa usar o cache do Azure Write Accelerator conforme descrito no artigo Habilitar Acelerador de Gravação.

Resumo: O SSD Premium do Azure v2 é o armazenamento em bloco que se adapta à melhor relação preço/desempenho para cargas de trabalho SAP. O SSD Premium do Azure v2 é adequado para lidar com cargas de trabalho de banco de dados. A latência de submilissegundos é o armazenamento ideal para cargas de trabalho DBMS exigentes. Embora seja um tipo de armazenamento mais recente que foi lançado em novembro de 2022. Portanto, ainda pode haver algumas limitações que vão desaparecer nos próximos meses.

Azure Ultra disk

Os discos Ultra do Azure têm um débito elevado, IOPS elevado e armazenamento no disco com latência baixa consistente para VMs IaaS do Azure. Alguns benefícios dos ultradiscos incluem a capacidade de alterar dinamicamente as IOPS e a taxa de transferência do disco, juntamente com suas cargas de trabalho, sem a necessidade de reiniciar suas máquinas virtuais (VM). Os discos Ultra são adequados para cargas de trabalho com uso intensivo de dados, como a carga de trabalho SAP DBMS. Os discos Ultra só podem ser usados como discos de dados e não podem ser usados como disco VHD base que armazena o sistema operacional. Recomendamos o uso do armazenamento premium do Azure como disco VHD baseado.

Ao criar um disco ultra, você tem três dimensões que pode definir:

  • A capacidade do disco. Os intervalos são de 4 GiB a 65.536 GiB
  • IOPS provisionadas para o disco. Diferentes valores máximos se aplicam à capacidade do disco. Leia o artigo Ultra disk para mais detalhes
  • Largura de banda de armazenamento provisionada. Diferentes larguras de banda máximas se aplicam dependendo da capacidade do disco. Leia o artigo Ultra disk para mais detalhes

O custo de um único disco é determinado pelas três dimensões que você pode definir para os discos específicos separadamente.

A matriz de recursos para a carga de trabalho SAP tem a seguinte aparência:

Capacidade Comentário Notas/Ligações
VHD base do SO Não funciona -
Disco de dados Adequado Todos os sistemas
Diretório de transporte global SAP Sim Suportado
SAP sapmnt Adequado Todos os sistemas
Armazenamento de cópias de segurança Adequado Para armazenamento de curto prazo de backups
Partilhas/disco partilhado Não disponível Precisa de terceiros
Resiliência LRS Nenhum GRS ou ZRS disponível para discos
Latência Muito baixa -
IOPS SLA Sim -
IOPS linear à capacidade Semi-linear entre parênteses Preços do Managed Disk
IOPS máximo por disco 1.200 a 160.000 dependente da capacidade do disco
SLA de produtividade Sim -
Taxa de transferência linear à capacidade Semi-linear entre parênteses Preços do Managed Disk
Certificação HANA Sim -
Suporte do Azure Write Accelerator Não -
Expansão do disco Não -
Snapshots de disco possíveis Não -
Possíveis instantâneos da VM do Backup do Azure Não -
Custos Armazenamento superior ao Premium -

Resumo: Os discos ultra do Azure são um armazenamento adequado com baixa latência de submilissegundos para todos os tipos de carga de trabalho SAP. Até agora, o disco Ultra só pode ser usado em combinações com VMs que foram implantadas por meio de zonas de disponibilidade (implantação zonal). O Ultra Disk não suporta snapshots de armazenamento. Ao contrário de todos os outros armazenamentos, o disco Ultra não pode ser usado para o disco VHD base. O Ultra Disk é ideal para casos em que a carga de trabalho de E/S flutua muito e você deseja adaptar a taxa de transferência de armazenamento implantada ou IOPS aos padrões de carga de trabalho de armazenamento em vez de dimensionar para uso máximo de largura de banda e IOPS.

Arquivos NetApp do Azure (ANF)

Os Arquivos NetApp do Azure são o resultado da cooperação entre a Microsoft e a NetApp com o objetivo de fornecer compartilhamentos NFS e SMB nativos do Azure de alto desempenho. A ênfase é fornecer armazenamento de alta largura de banda e baixa latência que permita cenários de implantação de DBMS e, ao longo do tempo, habilite a funcionalidade operacional típica do armazenamento NetApp por meio do Azure também. Os compartilhamentos NFS/SMB são oferecidos em três níveis de serviço diferentes que se diferenciam em taxa de transferência de armazenamento e em preço. Os níveis de serviço estão documentados no artigo Níveis de serviço para arquivos NetApp do Azure. Para os diferentes tipos de carga de trabalho SAP, os seguintes níveis de serviço são altamente recomendados:

  • Carga de trabalho do SAP DBMS: desempenho, idealmente Ultra
  • Partilha SAPMNT: Desempenho, idealmente Ultra
  • Diretório de transporte global: Desempenho, idealmente Ultra

Nota

O tamanho mínimo de provisionamento é uma unidade de 4 TiB chamada pool de capacidade. Em seguida, você cria volumes a partir desse pool de capacidade. Considerando que o menor volume que você pode construir é de 100 GiB. Você pode expandir um pool de capacidade em etapas TiB. Para obter preços, consulte o artigo Azure NetApp Files Pricing

Atualmente, o armazenamento ANF é suportado para vários cenários de carga de trabalho SAP:

Nota

Até agora, nenhuma carga de trabalho DBMS é suportada no SMB com base nos Arquivos NetApp do Azure.

Como já acontece com o armazenamento premium do Azure, um tamanho de taxa de transferência fixa ou linear por GB pode ser um problema quando você precisa aderir a alguns números mínimos na taxa de transferência. É o caso do SAP HANA. Com o ANF, esse problema pode se tornar mais pronunciado do que com o disco premium do Azure. Usando o disco premium do Azure, você pode usar vários discos menores com uma taxa de transferência relativamente alta por GiB e distribuí-los para ser econômico e ter uma taxa de transferência mais alta em menor capacidade. Esse tipo de striping não funciona para ações NFS ou SMB hospedadas no ANF. Esta restrição resultou na implantação de sobrecapacidades, como:

  • Para alcançar, por exemplo, uma taxa de transferência de 250 MiB/seg em um volume NFS hospedado no ANF, você precisa implantar uma capacidade de 1,95 TiB do nível de serviço Ultra.
  • Para atingir 400 MiB/seg, você precisaria implantar uma capacidade de 3,125 TiB. Mas você pode precisar do provisionamento excessivo de capacidade para atingir a taxa de transferência necessária para o volume. Esse provisionamento excessivo de capacidade afeta a precificação de instâncias HANA menores.
  • Usando NFS sobre ANF para o diretório SAP /sapmnt, você geralmente está indo longe com a capacidade mínima de 100 GiB a 150 GiB que é imposta pelos Arquivos NetApp do Azure. No entanto, a experiência do cliente mostrou que a taxa de transferência relacionada de 12,8 MiB/seg (usando o nível de serviço Ultra) pode não ser suficiente e pode ter impacto negativo na estabilidade do sistema SAP. Nesses casos, os clientes poderiam evitar problemas aumentando o volume do volume /sapmnt, de modo que mais taxa de transferência seja fornecida para esse volume.

A matriz de recursos para a carga de trabalho SAP tem a seguinte aparência:

Capacidade Comentário Notas/Ligações
VHD base do SO Não funciona -
Disco de dados Adequado SAP HANA, Oracle em Oracle Linux, DB2 e SAP ASE em SLES/RHEL
Diretório de transporte global SAP Sim SMB e NFS
SAP sapmnt Adequado Todos os sistemas SMB (somente Windows) ou NFS (somente Linux)
Armazenamento de cópias de segurança Adequado -
Partilhas/disco partilhado Sim SMB 3.0, NFS v3 e NFS v4.1
Resiliência LRS e GRS GRS disponível
Latência Muito baixa -
IOPS SLA Sim -
IOPS linear à capacidade estritamente linear Dependente do nível de serviço
SLA de produtividade Sim -
Taxa de transferência linear à capacidade Linear Dependente do nível de serviço
Certificação HANA Sim -
Snapshots de disco possíveis Sim -
Possíveis instantâneos da VM do Backup do Azure Não -
Custos Armazenamento superior ao Premium -

Outras funcionalidades integradas do armazenamento ANF:

Importante

Especificamente para implantações de banco de dados, você deseja obter latências baixas para pelo menos seus logs de refazer. Especialmente para o SAP HANA, O SAP requer uma latência inferior a 1 milissegundo para gravações de log de refazer HANA de tamanhos menores. Para chegar a essas latências, veja as possibilidades abaixo.

Importante

Mesmo para uso que não seja DBMS, você deve usar a funcionalidade de visualização que permite criar o compartilhamento NFS nas mesmas Zonas de Disponibilidade do Azure em que colocou sua(s) VM(s) que devem montar os compartilhamentos NFS. Essa funcionalidade está documentada no artigo Gerenciar o posicionamento do volume da zona de disponibilidade para arquivos NetApp do Azure. A motivação para ter esse tipo de alinhamento da Zona de Disponibilidade é a redução da superfície de risco ao ter os compartilhamentos NFS ainda em outra AvZone onde você não executa VMs.

  • Você opta pela proximidade mais próxima entre VM e compartilhamento NFS que pode ser organizada usando Grupos de Volume de Aplicativos. A vantagem dos Grupos de Volume de Aplicativos, além de alocar a melhor proximidade e criar a menor latência, é que seus diferentes compartilhamentos NFS para implantações do SAP HANA são distribuídos entre diferentes controladores nos clusters de back-end do Azure NetApp Files. A desvantagem deste método é que você precisa passar por um processo de fixação novamente. Um processo que terminará restringindo sua implantação de VM a um único datacenter. Em vez de zonas de disponibilidade como o primeiro método introduzido. Isso significa menos flexibilidade na alteração de tamanhos de VM e famílias de VMs das VMs que têm os volumes NFS montados.
  • Processo atual de não usar grupos de posicionamento de disponibilidade. Que até agora estão disponíveis apenas para SAP HANA. Esse processo também usa o mesmo processo de fixação manual como é o caso dos grupos de Volume de Disponibilidade. Este método é o utilizado nos últimos três anos. Ele tem as mesmas restrições de flexibilidade que o processo tem com os Grupos de Volume de Disponibilidade.

Como preferências para alocar volumes NFS com base em ANF para uso específico do banco de dados, você deve tentar alocar o volume NFS na mesma zona que sua VM primeiro. Especialmente para bancos de dados não HANA. Somente se a latência se mostrar insuficiente, você deve passar por um processo de fixação manual. Para cargas de trabalho HANA menores ou cargas de trabalho HANA que não sejam de produção, você também deve seguir um método de alocação zonal. Somente nos casos em que o desempenho e a latência não são suficientes, você deve usar os Grupos de Volume de Aplicativos.

Resumo: Os Arquivos NetApp do Azure são um armazenamento de baixa latência certificado pelo HANA que permite implantar volumes ou compartilhamentos NFS e SMB. O armazenamento vem com três níveis de serviço diferentes que fornecem taxa de transferência e IOPS diferentes de forma linear por capacidade GiB do volume. O armazenamento ANF está permitindo implantar cenários de expansão do SAP HANA com um nó em espera. O armazenamento é adequado para fornecer compartilhamentos de arquivos conforme necessário para o diretório de transporte global /sapmnt ou SAP. O armazenamento ANF vem com disponibilidade de funcionalidade que está disponível como funcionalidade nativa da NetApp.

Azure Premium Files

O Azure Premium Files é um armazenamento compartilhado que oferece SMB e NFS por um preço moderado e latência suficiente para lidar com compartilhamentos da camada de aplicativos SAP. Além disso, o Azure Premium Files oferece replicação zonal síncrona dos compartilhamentos com um automatismo que, caso uma réplica falhe, outra réplica em outra zona pode assumir o controle. Ao contrário dos Arquivos NetApp do Azure, não há camadas de desempenho. Também não há necessidade de um pool de capacidade. A tarifação baseia-se na capacidade real provisionada das diferentes ações. Os Arquivos Premium do Azure não foram testados como armazenamento DBMS para carga de trabalho SAP. Mas, em vez disso, o cenário de uso da carga de trabalho SAP se concentrou em todos os tipos de compartilhamentos SMB e NFS à medida que são usados na camada de aplicativos SAP. Os Arquivos Premium do Azure também são adequados para o uso de /hana/shared.

Nota

Até agora, nenhuma carga de trabalho do SAP DBMS é suportada em volumes compartilhados com base nos Arquivos Premium do Azure.

Cenários SAP suportados na lista de Arquivos Premium do Azure como:

Os Arquivos Premium do Azure estão começando com uma quantidade maior de IOPS no tamanho mínimo de compartilhamento de 100 GB em comparação com os Arquivos NetApp do Azure. Essa barra mais alta de IOPS pode evitar o provisionamento excessivo de capacidade para atingir determinados valores de IOPS e taxa de transferência. Para IOPS e taxa de transferência de armazenamento, leia a seção Destinos de escala de compartilhamento de arquivos do Azure em Destinos de escalabilidade e desempenho do Azure Files.

A matriz de recursos para a carga de trabalho SAP tem a seguinte aparência:

Capacidade Comentário Notas/Ligações
VHD base do SO Não funciona -
Disco de dados Não suportado para cargas de trabalho SAP -
Diretório de transporte global SAP Sim SMB e NFS
SAP sapmnt Adequado Todos os sistemas SMB (somente Windows) ou NFS (somente Linux)
Armazenamento de cópias de segurança Adequado -
Partilhas/disco partilhado Sim SMB 3.0, NFS v4.1
Resiliência LRS e ZRS Nenhum GRS disponível para Arquivos Premium do Azure
Latência lowa -
IOPS SLA Sim -
IOPS linear à capacidade estritamente linear -
SLA de produtividade Sim -
Taxa de transferência linear à capacidade estritamente linear -
Certificação HANA Não -
Snapshots de disco possíveis Não -
Possíveis instantâneos da VM do Backup do Azure Não -
Custos lowa -

Resumo: O Azure Premium Files é um armazenamento de baixa latência que permite implantar volumes ou compartilhamentos NFS e SMB. O Azure Premium Files fornece uma excelente relação preço/desempenho para compartilhamentos de camada de aplicativos SAP. Ele também fornece replicação zonal síncrona para esses compartilhamentos. Até agora, não oferecemos suporte a esse tipo de armazenamento para a carga de trabalho do SAP DBMS. Embora possa ser usado para /hana/volumes compartilhados .

Armazenamento SSD padrão do Azure

Em comparação com o armazenamento HDD padrão do Azure, o armazenamento SSD padrão do Azure oferece melhor disponibilidade, consistência, confiabilidade e latência. Ele é otimizado para cargas de trabalho que precisam de desempenho consistente em níveis mais baixos de IOPS. Esse armazenamento é o armazenamento mínimo usado para sistemas SAP que não são de produção e têm baixas demandas de IOPS e taxa de transferência. A matriz de recursos para a carga de trabalho SAP tem a seguinte aparência:

Capacidade Comentário Notas/Ligações
VHD base do SO Restrito adequado Sistemas não produtivos
Disco de dados Restrito adequado Alguns sistemas de não-produção com IOPS baixas e demandas de latência
Diretório de transporte global SAP Não Não suportado
SAP sapmnt Restrito adequado Sistemas não produtivos
Armazenamento de cópias de segurança Adequado -
Partilhas/disco partilhado Não disponível Precisa de terceiros
Resiliência LRS, GRS Não há ZRS disponível para discos
Latência alto Muito alto para o diretório SAP Global Transport ou sistemas de produção
IOPS SLA Não -
IOPS máximo por disco 500 Independentemente do tamanho do disco
SLA de produtividade Não -
Certificação HANA Não -
Snapshots de disco possíveis Sim -
Possíveis instantâneos da VM do Backup do Azure Sim -
Custos LOW -

Resumo: O armazenamento SSD padrão do Azure é a recomendação mínima para VMs que não são de produção para VHD base, eventuais implantações de DBMS com insensibilidade de latência relativa e/ou baixas IOPS e taxas de transferência. Esse tipo de armazenamento do Azure não é mais suportado para hospedar o SAP Global Transport Directory.

Armazenamento de HDD padrão do Azure

O armazenamento HDD padrão do Azure era o único tipo de armazenamento quando a infraestrutura do Azure foi certificada para a carga de trabalho do SAP NetWeaver no ano de 2014. No ano de 2014, as máquinas virtuais do Azure eram pequenas e com baixa taxa de transferência de armazenamento. Portanto, esse tipo de armazenamento foi capaz de apenas acompanhar as demandas. O armazenamento é ideal para cargas de trabalho insensíveis à latência, que você dificilmente experimenta no espaço SAP. Com o aumento da taxa de transferência das VMs do Azure e o aumento da carga de trabalho que essas VMs estão produzindo, esse tipo de armazenamento não é mais considerado para uso com cenários SAP. A matriz de recursos para a carga de trabalho SAP tem a seguinte aparência:

Capacidade Comentário Notas/Ligações
VHD base do SO Não adequado -
Disco de dados Não adequado -
Diretório de transporte global SAP Não Não suportado
SAP sapmnt Não Não suportado
Armazenamento de cópias de segurança Adequado -
Partilhas/disco partilhado Não disponível Precisa de Arquivos do Azure ou de terceiros
Resiliência LRS, GRS Não há ZRS disponível para discos
Latência alto Muito alto para uso de DBMS, diretório SAP Global Transport ou sapmnt/saploc
IOPS SLA Não -
IOPS máximo por disco 500 Independentemente do tamanho do disco
SLA de produtividade Não -
Certificação HANA Não -
Snapshots de disco possíveis Sim -
Possíveis instantâneos da VM do Backup do Azure Sim -
Custos Mínimo -

Resumo: HDD padrão é um tipo de armazenamento do Azure que só deve ser usado para armazenar backups SAP. Ele só deve ser usado como VHD de base para sistemas bastante inativos, como sistemas aposentados usados para procurar dados aqui e ali. Mas nenhuma VM de desenvolvimento, controle de qualidade ou produção ativa deve ser baseada nesse armazenamento. Os arquivos de banco de dados também não devem ser hospedados nesse armazenamento

Limites da VM do Azure no tráfego de armazenamento

Ao contrário dos cenários locais, o tipo de VM individual que você está selecionando desempenha um papel vital na largura de banda de armazenamento que você pode alcançar. Para os diferentes tipos de armazenamento, você precisa considerar:

Tipo de armazenamento Linux Windows Comentários
HDD Standard Tamanhos para VMs Linux no Azure Tamanhos para VMs do Windows no Azure Provavelmente difícil de tocar nos limites de armazenamento de VMs médias ou grandes
SSD Standard Tamanhos para VMs Linux no Azure Tamanhos para VMs do Windows no Azure Provavelmente difícil de tocar nos limites de armazenamento de VMs médias ou grandes
Armazenamento Premium Tamanhos para VMs Linux no Azure Tamanhos para VMs do Windows no Azure Fácil de atingir IOPS ou limites de VM de taxa de transferência de armazenamento com configuração de armazenamento
SSD Premium v2 Tamanhos para VMs Linux no Azure Tamanhos para VMs do Windows no Azure Fácil de atingir IOPS ou limites de VM de taxa de transferência de armazenamento com configuração de armazenamento
Armazenamento em disco ultra Tamanhos para VMs Linux no Azure Tamanhos para VMs do Windows no Azure Fácil de atingir IOPS ou limites de VM de taxa de transferência de armazenamento com configuração de armazenamento
Azure NetApp Files Tamanhos para VMs Linux no Azure Tamanhos para VMs do Windows no Azure O tráfego de armazenamento está usando largura de banda de taxa de transferência de rede e não largura de banda de armazenamento!
Azure Premium Files Tamanhos para VMs Linux no Azure Tamanhos para VMs do Windows no Azure O tráfego de armazenamento está usando largura de banda de taxa de transferência de rede e não largura de banda de armazenamento!

Como limitações, você precisa observar que:

  • Quanto menor a VM, menos discos você pode anexar. Esta restrição não se aplica à ANF. Como você monta compartilhamentos NFS ou SMB, não encontra um limite de número de volumes compartilhados a serem anexados
  • As VMs têm taxa de transferência de E/S e limites de IOPS que podem ser facilmente excedidos com discos de armazenamento premium e discos Ultra
  • Com o ANF e os Arquivos Premium do Azure, o tráfego para os volumes compartilhados está consumindo a largura de banda de rede da VM e não a largura de banda de armazenamento
  • Com grandes volumes NFS no espaço de capacidade TiB de dois dígitos, a taxa de transferência que acessa esse volume de uma única VM vai estabilizar com base nos limites do Linux para uma única sessão interagindo com o volume compartilhado.

À medida que você aumenta o tamanho das VMs do Azure no ciclo de vida de um sistema SAP, você deve avaliar os limites de IOPS e taxa de transferência de armazenamento do tipo de VM novo e maior. Em alguns casos, também pode fazer sentido ajustar a configuração de armazenamento aos novos recursos da VM do Azure.

Listras ou não listras

Criar um conjunto de distribuição de vários discos do Azure em um volume maior permite acumular as IOPS e a taxa de transferência dos discos individuais em um volume. Ele é usado apenas para o armazenamento padrão do Azure e o armazenamento premium do Azure. O disco Ultra do Azure, onde você pode configurar a taxa de transferência e o IOPS independentemente da capacidade de um disco, não requer o uso de conjuntos de distribuição. Os volumes compartilhados baseados em NFS ou SMB não podem ser distribuídos. Devido à natureza não linear da taxa de transferência de armazenamento premium e IOPS do Azure, você pode provisionar capacidade menor com as mesmas IOPS e taxa de transferência do que grandes discos de armazenamento premium do Azure únicos. Esse é o método para obter maior taxa de transferência ou IOPS a um custo mais baixo usando o armazenamento premium do Azure. Por exemplo, distribuir por dois discos de armazenamento premium P15 leva a uma taxa de transferência de:

  • 250 MiB/seg. Esse volume vai ter capacidade de 512 GiB. Se você quiser ter um único disco que lhe dê uma taxa de transferência de 250 MiB por segundo, você precisaria escolher um disco P40 com capacidade de 2 TiB.
  • 400 MiB/seg através da distribuição de quatro discos de armazenamento premium P10 com uma capacidade total de 512 GiB por striping. Se você gostaria de ter um único disco com um mínimo de 500 MiB de taxa de transferência por segundo, você precisaria escolher um disco de armazenamento premium P60 com 8 TiB. Como o custo do armazenamento premium é quase linear com a capacidade, você pode sentir a economia de custos usando striping.

Algumas regras precisam ser seguidas no striping:

  • Nenhum armazenamento configurado na VM deve ser usado, pois o armazenamento do Azure já mantém os dados redundantes
  • Os discos aos quais o conjunto de distribuição é aplicado precisam ser do mesmo tamanho
  • Com o SSD Premium v2 e o disco Ultra, a capacidade, as IOPS provisionadas e a taxa de transferência provisionada precisam ser as mesmas

Distribuir por vários discos menores é a melhor maneira de obter uma boa relação preço/desempenho usando o armazenamento premium do Azure. Entende-se que o striping pode ter alguma sobrecarga extra de implantação e gerenciamento.

Para obter recomendações específicas de tamanho de faixa, leia a documentação para os diferentes DBMS, como as configurações de armazenamento de máquina virtual do SAP HANA Azure.

Próximos passos

Leia os artigos: