Partilhar via

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 (disco rígido virtual) 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 (Contratos de Nível de Serviço) 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 (Electronic Data Interchange) 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 (Database Management System), 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 Recomendado Não suportado
Volume de log DBMS Famílias VM SAP HANA M/Mv2 Não suportado Não suportado Recomendado1 Recomendado Recomendado Recomendado Não suportado
Volume de dados DBMS Famílias de VM SAP HANA Esv3/Edsv4 Não suportado Não suportado Recomendado Recomendado Recomendado Recomendado 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 Recomendado Não suportado
Volume compartilhado HANA Não suportado Não suportado Recomendado Recomendado Recomendado Recomendado Recomendado
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

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 Alto Médio a alto Baixo submilissegundos submilissegundos submilissegundos lowa
Gravações de latência Alto 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 Sim3 N.o2 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 A criação de pools de capacidade de Arquivos NetApp do Azure diferentes não garante a implantação de pools de capacidade em diferentes unidades de armazenamento

3 Instantâneos (incrementais) de um SSD Premium v2 ou de um disco Ultra não podem ser usados imediatamente após serem criados. A cópia em segundo plano deve ser concluída antes que você possa criar um disco a partir do instantâneo

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 1.024 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 com mais de 32 GiB a 1.024 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:

Funcionalidade 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 Médio -

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 do seu 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:

Funcionalidade 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 Sim1 -
Possíveis instantâneos da VM do Backup do Azure Sim -
Custos Médio -

1 Instantâneos (incrementais) de um SSD Premium v2 ou de um disco Ultra não podem ser usados imediatamente após serem criados. A cópia em segundo plano deve ser concluída antes que você possa criar um disco a partir do instantâneo

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:

Funcionalidade 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 Sim -
Snapshots de disco possíveis Sim1 -
Possíveis instantâneos da VM do Backup do Azure Sim -
Custos Armazenamento superior ao Premium -

1 Instantâneos (incrementais) de um SSD Premium v2 ou de um disco Ultra não podem ser usados imediatamente após serem criados. A cópia em segundo plano deve ser concluída antes que você possa criar um disco a partir do instantâneo

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). 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.

Azure NetApp Files

O Azure NetApp Files é um serviço de armazenamento de arquivos de alto desempenho nativo, primário, de classe empresarial e do Azure, certificado para uso com o SAP HANA. Ele fornece Volumes como um serviço para o qual você cria contas NetApp, pools de capacidade e volumes. Com os Arquivos NetApp do Azure, você seleciona níveis de serviço e desempenho e gerencia a proteção de dados para criar e gerenciar compartilhamentos de arquivos de alto desempenho, altamente disponíveis e escaláveis usando os mesmos protocolos e ferramentas com os quais você está familiarizado e confia no local.

Os seguintes tipos de carga de trabalho SAP são suportados nos volumes do Azure NetApp Files:

  • Carga de trabalho do SAP DBMS
  • Partilha SAPMNT
  • Diretório de transporte global

Os Arquivos NetApp do Azure estão disponíveis em três níveis de serviço, cada um com suas próprias especificações de taxa de transferência e preço. Qual deles é o certo para sua implantação depende do tamanho da implantação. Recomendações de dimensionamento personalizadas estão disponíveis no SAP on Azure NetApp Files TCO Estimator.

Para obter informações sobre níveis de serviço, consulte Níveis de serviço para arquivos NetApp do Azure.

Implantando volumes

Para obter resultados ideais, use o grupo de volumes de aplicativos para SAP HANA para implantar os volumes. O grupo de volumes de aplicativos coloca os volumes em locais ideais na infraestrutura do Azure usando regras de afinidade e antiafinidade para reduzir a contenção e permitir a melhor taxa de transferência e a menor latência.

Nota

Os pools de capacidade são uma unidade de provisionamento básica para Arquivos NetApp do Azure. As piscinas de capacidade são oferecidas a partir de 1 TiB de tamanho; você pode expandir um pool de capacidade em incrementos de 1 TiB. Os pools de capacidade são a unidade pai para volumes. Para obter informações sobre dimensionamento, consulte Limites de recursos dos Arquivos NetApp do Azure. Para obter preços, consulte Preços dos arquivos NetApp do Azure.

Os Arquivos NetApp do Azure são suportados em vários cenários de carga de trabalho SAP:

Nota

Para cargas de trabalho DBMS no Linux, use volumes baseados em NFS nos Arquivos NetApp do Azure.

Desacoplando a taxa de transferência do tamanho do volume

O armazenamento para aplicativos de banco de dados normalmente tem requisitos de taxa de transferência que não são dimensionados linearmente com o tamanho dos volumes, ou seja, os volumes de log são relativamente pequenos em tamanho, mas exigem altos níveis de taxa de transferência.

Os Arquivos NetApp do Azure permitem alocar a taxa de transferência de volume independentemente dos tamanhos de volume ao usar um pool de capacidade do tipo QoS manual.

Eis um exemplo:

  • Um volume para arquivos de banco de dados requer taxa de transferência de 500 MiB/s e capacidade de 39 TiB
  • Um volume para arquivos de log requer taxa de transferência de 2000 MiB/s e capacidade de 1 TiB

Você pode criar um pool de capacidade de QoS manual para esse cenário e alocar a taxa de transferência independentemente dos tamanhos de volume. A capacidade total necessária é de 40 TiB e o orçamento total de taxa de transferência é de 2500 MiB/s. Um pool de capacidade no nível de serviço Premium (64 MiB/s por TiB alocado) acomoda os requisitos de desempenho e capacidade (40 MiB * 64 iB/s/TiB = 2560 MiB).

O dimensionamento linear de desempenho exigiria um superprovisionamento considerável do volume de log para atingir o requisito de taxa de transferência. Para atingir a taxa de transferência de 2000 MiB/s para o volume de log, você precisaria implantar um pool de capacidade na camada Ultra (128 MiB/s por TiB alocado) de 16 TiB, resultando em um superprovisionamento e, portanto, uma capacidade desperdiçada de 15 TiB.

Use a Calculadora de Desempenho de Arquivos NetApp do Azure para obter uma estimativa para seu cenário.

A matriz de recursos para a carga de trabalho SAP nos Arquivos NetApp do Azure tem a seguinte aparência:

Funcionalidade Comentário Notas/Ligações
VHD base do SO Usar disco gerenciado -
Disco de dados Adequado SAP HANA, Oracle em Oracle Linux, DB2 e SAP ASE em SLES/RHEL, MAXDB, SQL Server
Diretório de transporte global SAP Sim SMB (somente Windows) e NFS (somente Linux)
SAP sapmnt Adequado SMB (somente Windows) ou NFS (somente Linux)
Armazenamento de cópias de segurança Adequado Usar instantâneos e/ou backup de Arquivos NetApp do Azure; o backup de log para HANA também pode ser usado como destino de backup baseado em arquivo
Partilhas/disco partilhado Sim SMB, NFS
Resiliência LRS e GRS GRS com replicação entre regiões; ZRS com replicação entre zonas
Latência Muito baixa Normalmente menos de 1 ms
IOPS SLA Sim -
IOPS linear à capacidade Linear com auto QoS; configurável de forma independente com QoS manual Três níveis de serviço disponíveis
SLA de produtividade Sim As recomendações de dimensionamento estão disponíveis no SAP no Estimador de TCO de Arquivos NetApp do Azure
Taxa de transferência linear à capacidade Linear com auto QoS; configurável de forma independente com QoS manual Três níveis de serviço disponíveis
Certificação HANA Sim -
Snapshots de disco possíveis Sim Veja como funcionam os instantâneos dos Arquivos NetApp do Azure
Snapshot consistente com aplicativos e orquestração de backup Não Usar o AzAcSnap ou o SnapCenter
Custos Usar ferramentas de estimativa de TCO Use o SAP on Azure NetApp Files TCO Estimator e insira o tamanho da paisagem

Outras funcionalidades internas do armazenamento de Arquivos NetApp do Azure:

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

Ao implantar os volumes de Arquivos NetApp do Azure, anote a zona na qual as máquinas virtuais estão ou serão implantadas. Certifique-se de selecionar a mesma zona. Essa funcionalidade está documentada no artigo Gerenciar o posicionamento do volume da zona de disponibilidade para arquivos NetApp do Azure. O grupo de volumes de aplicativos para SAP HANA usa a mesma funcionalidade para implantar os volumes na maior proximidade possível das VMs de aplicativos.

A motivação para ter esse tipo de alinhamento da zona de disponibilidade é a redução da superfície de risco por ter os compartilhamentos NFS na mesma zona de disponibilidade que as VMs do aplicativo.

  • Implante volumes de Arquivos NetApp do Azure para sua implantação do SAP HANA usando o grupo de volumes de aplicativos para SAP HANA. A vantagem do Application Volume Group é que os volumes de dados são implantados em vários pontos de extremidade de armazenamento, reduzindo a contenção de rede e melhorando o desempenho.

Resumo: O Azure NetApp Files é uma solução certificada de armazenamento de baixa latência para SAP HANA. O serviço fornece volumes esculpidos em um ou mais pools de capacidade. Os pools de capacidade estão disponíveis em três níveis de serviço que definem a capacidade total e a taxa de transferência alocada. Os volumes podem ser redimensionados e a taxa de transferência alocada pode ser ajustada sem interrupção do serviço para atender às mudanças de requisitos e controlar os custos. O serviço fornece funcionalidade para replicar volumes para outras regiões ou zonas para fins de recuperação de desastres e continuidade de negócios.

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.

Nota

Devido à arquitetura hierárquica dos Arquivos Premium do Azure, a latência de acesso aos metadados dos arquivos armazenados em compartilhamentos é significativamente maior do que com os Arquivos NetApp do Azure. Essa latência mais alta pode afetar, por exemplo, a criação em massa e a exclusão de arquivos. Mas também pode ter um impacto percetível no tempo que leva para listar o conteúdo de grandes diretórios, contendo centenas de milhares de arquivos. O principal caso de uso que vemos essa maior latência de metadados afetando é o uso como compartilhamento de interface, onde os clientes podem encontrar centenas de milhares ou até milhões de criações de arquivos e exclusões em massa todos os dias. Portanto, você deve testar os cenários de compartilhamento de interface diligentemente. Para determinar se sua carga de trabalho é pesada em metadados, marque Metadados ou namespace carga de trabalho pesada

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

Funcionalidade 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 Sim -
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:

Funcionalidade 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 baixas IOPS 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 relativa insensibilidade à latência 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:

Funcionalidade 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 Baixo -

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 aos Arquivos NetApp do Azure. 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 os Arquivos NetApp do Azure 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:

  • Nenhuma redundância de armazenamento configurada na VM deve ser usada, pois o armazenamento do Azure mantém o disco de dados redundante já no back-end de armazenamento do Azure
  • 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: