Tipos de Armazenamento do Azure para carga de trabalho SAP
O Azure tem vários tipos de armazenamento que diferem amplamente em recursos, taxa de transferência, latência e preços. Alguns dos tipos de armazenamento não são utilizáveis ou têm uso limitado em cenários do SAP. Enquanto vários tipos de armazenamento do Azure são adequados ou otimizados para cenários de carga de trabalho do SAP específicos. Especialmente para o SAP HANA, alguns tipos de armazenamento do Azure receberam certificação para o uso com o SAP HANA. Neste documento, examinaremos os diferentes tipos de armazenamento e descreveremos a capacidade e usabilidade deles com as cargas de trabalho e com os componentes do SAP.
Comentário sobre as unidades usadas neste 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, todas as documentações e preços do Azure estão usando essas unidades. Em todo o documento faremos referência somente às unidades de tamanho MiB, GiB e TiB. Talvez seja necessário planejar com MB, GB e TB. Portanto, esteja ciente de algumas pequenas diferenças nos cálculos se você precisar dimensionar para uma taxa de transferência de 400 MiB/s, em vez de uma taxa de transferência de 250 MiB/s.
Resiliência do Armazenamento do Microsoft Azure
Armazenamento do Microsoft Azure de HDD Standard, SSD Standard, armazenamento Premium do Azure, SSD Premium v2 e Disco Ultra mantêm o VHD base (com o sistema operacional) e os discos de dados anexados à 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 é transparente, se houver uma falha de nó de armazenamento. Como resultado dessa redundância, NÃO é necessário usar um tipo de camada de redundância de armazenamento em vários discos do Azure. Esse fato é chamado de Armazenamento com Redundância Local (LRS). O LRS é o padrão para esses tipos de armazenamento no Azure. Azure NetApp Files fornece redundância suficiente para alcançar os mesmos SLAs que o armazenamento do Azure nativo.
Há vários outros métodos de redundância, descritos no artigo Replicação do Armazenamento do Azure, que se aplicam a alguns dos diferentes tipos de armazenamento que o Azure oferece.
Observação
Usando o armazenamento do Azure para armazenar dados de banco de dados e refazer o arquivo de log, o LRS é o único nível de resiliência com suporte neste momento
Lembre-se também que diferentes tipos de armazenamento do Azure influenciam os SLAs de disponibilidade de VM única lançados no SLA para Máquinas Virtuais.
Azure Managed Disks
Discos gerenciados são um tipo de recurso no Azure Resource Manager que pode ser usado em vez de VHDs armazenados em Contas de Armazenamento do Azure. Os discos gerenciados se alinham automaticamente ao [conjunto de disponibilidade][disponibilidade gerenciada de máquinas virtuais] da máquina virtual ao qual estão anexados. Com esse alinhamento, você experimenta uma melhoria da disponibilidade da máquina virtual e dos serviços que estão em execução na máquina virtual. Para obter mais informações, leia o artigo de visão geral.
Observação
Exigimos que as novas implantações de VMs que usam o armazenamento em bloco do Azure nos discos (todo o armazenamento do Azure, exceto o Azure NetApp Files e os Arquivos do Azure) usem os Azure Managed Disks nos discos VHD/SO de base e nos discos de dados que armazenam arquivos de banco de dados SAP. Isso é exigido independentemente de você implantar as VMs por meio do conjunto de disponibilidade, entre Zonas de Disponibilidade ou dos conjuntos e das zonas. Os discos que são usados com a finalidade de armazenar backups não precisam necessariamente ser discos gerenciados.
Cenários de armazenamento com as cargas de trabalho SAP
O armazenamento persistente é necessário na carga de trabalho do SAP em vários componentes da pilha que você implanta no Azure. Esses cenários constam, no mínimo, os seguintes:
- O armazenamento persistente do VHD de base da sua VM que contém o sistema operacional e outro software que você instala nesse disco. Este disco/VHD é a raiz de sua VM. Todas as alterações feitas nele precisam ser persistidas. Assim, na próxima vez que você interromper e reiniciar a VM, todas as alterações feitas anteriormente ainda existirão. Especialmente nos casos em que a VM está sendo implantada pelo Azure em outro host diferente daquele que estava em execução originalmente
- Discos de dados persistentes. Esses discos são VHDs anexados para armazenar dados de aplicativo. Esses dados de aplicativos podem ser arquivos de log/refazer e dados de um banco de dados, arquivos de backup ou instalações de software. Isso significa qualquer disco além do seu VHD de 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 pelo 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 semelhantes. O conteúdo desses compartilhamentos é consumido pelo 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, serão discutidos os diferentes tipos de armazenamento do Azure que se aplicam aos quatro cenários acima e a usabilidade deles na carga de trabalho SAP. Uma categorização geral de como os diferentes tipos de armazenamento do Azure devem ser usados está descrita 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 do SAP não serão muito diferentes.
Para obter as restrições de suporte dos tipos de armazenamento do Azure para camada de NetWeaver/application SAP do S/4HANA, confira a Observação de suporte do SAP 2015553. Para obter os tipos de armazenamento do Azure certificados e com suporte do SAP HANA, confira o artigo Configurações de armazenamento de máquina virtual SAP HANA no Azure.
As seções que descrevem os diferentes tipos de armazenamento do Azure fornecerão mais informações sobre as restrições e as possibilidades usando o armazenamento com suporte ao SAP.
Opções de armazenamento ao usar a replicação de DBMS
Nossas arquiteturas de referência preveem o uso da funcionalidade do DBMS, como o SQL Server Always On, a Replicação de Sistema do HANA, o DB2 HADR ou o Oracle Data Guard. Caso você use essas tecnologias entre duas ou várias máquinas virtuais do Azure, os tipos de armazenamento escolhidos para cada uma das VMs precisam ser iguais. Isso significa que a configuração de armazenamento entre o nó ativo e o nó de réplica na configuração de HA do DBMS precisa ser a mesma.
Recomendações de armazenamento para cenários de armazenamento SAP
Antes de entrar em detalhes, apresentaremos o resumo e as recomendações já no início do documento. Enquanto os detalhes dos tipos específicos de armazenamento do Azure serão descritos após esta seção do documento. Resumimos as recomendações de armazenamento dos cenários de armazenamento do SAP em uma tabela:
| Cenário de uso | HDD Standard | SSD Standard | Armazenamento Premium | SSD Premium v2 | Disco Ultra | Azure NetApp Files | Arquivos Premium do Azure |
|---|---|---|---|---|---|---|---|
| Disco do sistema operacional | Inadequado | Adequado com restrições (não usar em produção) | Recomendadas | Impossível | Impossível | Impossível | Impossível |
| Diretório de transporte global | Sem suporte | Sem suporte | Recomendadas | Recomendadas | Recomendadas | Recomendadas | Altamente recomendado |
| /sapmnt | Inadequado | Adequado com restrições (não usar em produção) | Recomendadas | Recomendadas | Recomendadas | Recomendadas | Altamente recomendado |
| Famílias de VM M/Mv2 do SAP HANA para volume de dados do DBMS | Sem suporte | Sem suporte | Recomendadas | Recomendadas | Recomendadas | Recomendado2 | Sem suporte |
| Famílias de VM M/Mv2 do SAP HANA para volume do log do DBMS | Sem suporte | Sem suporte | Recomendado1 | Recomendadas | Recomendadas | Recomendado2 | Sem suporte |
| Famílias de VM Esv3/Edsv4 do SAP HANA para volume de dados do DBMS | Sem suporte | Sem suporte | Recomendadas | Recomendadas | Recomendadas | Recomendado2 | Sem suporte |
| Famílias de VM Esv3/Edsv4 do SAP HANA para volume do log do DBMS | Sem suporte | Sem suporte | Sem suporte | Recomendadas | Recomendadas | Recomendado2 | Sem suporte |
| Volume compartilhado do HANA | Sem suporte | Sem suporte | Recomendadas | Recomendadas | Recomendadas | Recomendadas | Recomendado3 |
| Volume de dados do DBMS não HANA | Sem suporte | Adequado com restrições (não usar em produção) | Recomendadas | Recomendadas | Recomendadas | Somente para versões do Oracle específicas no Oracle Linux, DB2 e SAP ASE em SLES/RHEL Linux | Sem suporte |
| Famílias de VM M/Mv2 não HANA para volume do log do DBMS | Sem suporte | Adequado com restrições (não usar em produção) | Recomendado1 | Recomendadas | Recomendadas | Somente para versões do Oracle específicas no Oracle Linux, DB2 e SAP ASE em SLES/RHEL Linux | Sem suporte |
| Famílias de VMs que não são M/Mv2 nem HANA para volume de log do DBMS | Sem suporte | adequado com restrições (não usar em produção) | Adequado, no máximo, para a carga de trabalho média | Recomendadas | Recomendadas | Somente para versões do Oracle específicas no Oracle Linux, DB2 e SAP ASE em SLES/RHEL Linux | Sem suporte |
1 Com o uso do Acelerador de Gravação do Azure nas famílias de VM M/Mv2 para log/volume do log de restauração
2 O uso do ANF exige que o /hana/data e o /hana/log estejam no ANF
3 Até agora testado somente no SLES
Características que você pode esperar da lista de diferentes tipos de armazenamento, como:
| Cenário de uso | HDD Standard | SSD Standard | Armazenamento Premium | SSD Premium v2 | Disco Ultra | Azure NetApp Files | Arquivos Premium do Azure |
|---|---|---|---|---|---|---|---|
| SLA de taxa de transferência/IOPS | Não | No | Sim | Sim | Sim | Sim | Yes |
| Leituras de latência | Alto | Médio a alto | Baixo | submilissegundos | submilissegundos | submilissegundos | low |
| Gravações de latência | Alto | Médio a alto | Baixo (submilissegundos 1) | submilissegundos | submilissegundos | submilissegundos | low |
| Com suporte ao HANA | Não | Não | sim1 | Sim | Sim | Sim | Não |
| Instantâneos de disco possíveis | Sim | Sim | Sim | Não | No | Sim | Não |
| Alocação de discos em diferentes clusters de armazenamento ao usar conjuntos de disponibilidade | Por meio de discos gerenciados | Por meio de discos gerenciados | Por meio de discos gerenciados | Tipo de disco sem suporte com VMs implantadas por meio de conjuntos de disponibilidade | Tipo de disco sem suporte com VMs implantadas por meio de conjuntos de disponibilidade | Nº3 | Não |
| Alinhado com as Zonas de Disponibilidade | Sim | Sim | Sim | Sim | Yes | Em versão prévia pública | Não |
| Redundância zonal síncrona | Não para discos gerenciados | Não para discos gerenciados | Sem suporte para DBMS | Não | No | No | Sim |
| Redundância zonal assíncrona | Não para discos gerenciados | Não para discos gerenciados | Sem suporte para DBMS | Não | Não | Em visualização | Não |
| Redundância geográfica | Não para discos gerenciados | Não para discos gerenciados | Não | No | Não | Possível | Não |
1 Com o uso do Acelerador de Gravação do Azure nas famílias de VM M/Mv2 para log/volume do log de restauração
2 Os custos dependem da IOPS e da taxa de transferência provisionadas
3 A criação de diferentes pools de capacidade do ANF não garante a implantação de pools de capacidade em unidades de armazenamento diferentes
Importante
Confira a seção Azure NetApp Files deste documento para ver detalhes sobre o posicionamento por proximidade de volumes e VMs NFS em caso de necessidade de menos de 1 milissegundos de latência.
Armazenamento Premium do Azure
O armazenamento SSD Premium do Azure foi introduzido com a meta de fornecer:
- Latência de E/S baixa
- SLAs para IOPS e taxa de transferência
- Menos variabilidade na latência de E/S
Esse tipo de armazenamento tem como destino cargas de trabalho do DBMS, tráfego de armazenamento que exige baixa latência de milissegundos de dígito único e SLAs em IOPS e taxa de transferência. A base de custo para o armazenamento Premium do Azure não é o volume real de dados armazenados nesses discos, mas a categoria de tamanho desses discos, independentemente da quantidade de dados armazenados no disco em questão. Você também pode criar discos no armazenamento Premium que não estão sendo mapeados diretamente para as categorias de tamanho mostradas no artigo SSD Premium. As conclusões deste artigo são:
- O armazenamento é organizado em intervalos. Por exemplo, um disco no intervalo de capacidade de 513 GiB a 1024 GiB compartilha as mesmas funcionalidades e os mesmos custos mensais
- A IOPS por GiB não está sendo acompanhada linearmente nas categorias de tamanho. Discos menores abaixo de 32 GiB têm taxas de IOPS maiores por GiB. Para discos com mais de 32 GiB a 1024 GiB, a taxa de IOPS por GiB está entre 4 e 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 desse armazenamento não é linear com o tamanho da categoria de disco. Para discos menores, como na categoria com capacidade entre 65 GiB e 128 GiB, a taxa de transferência fica em torno de 780 KB por GiB. Por outro lado, para discos muito grandes, como um disco de 32.767 GiB, a taxa de transferência fica em torno de 28 KB por GiB
- Os SLAs de taxa de transferência e de IOPS não podem ser alterados sem alterar a capacidade do disco
A matriz de capacidade da carga de trabalho do SAP é semelhante a:
| Funcionalidade | Comentário | Observações/links |
|---|---|---|
| VHD de base do sistema operacional | Adequado | Todos os sistemas |
| Disco de dados | Adequado | Todos os sistemas – especialmente para SAP HANA |
| Diretório de transporte global do SAP | Sim | Com suporte |
| sapmnt do SAP | Adequado | Todos os sistemas |
| Armazenamento de backup | Adequado | Para armazenamento de backups de curto prazo |
| Compartilhamentos/disco compartilhado | Não disponível | Precisa de Arquivos Premium do Azure ou de terceiros |
| Resiliência | LRS | Nenhum GRS ou ZRS disponível para discos |
| Latency | Baixo a médio | - |
| SLA de IOPS | Sim | - |
| IOPS linear com a capacidade | semilinear entre colchetes | Preço do Managed Disk |
| IOPS máxima por disco | 20.000 dependendo do tamanho do disco | Considere também os limites da VM |
| SLA de taxa de transferência | Sim | - |
| Taxa de transferência linear com a capacidade | Semilinear entre colchetes | Preço do Managed Disk |
| Certificado pelo HANA | Yes | especialmente para SAP HANA |
| Suporte do Acelerador de Gravação do Azure | Não | - |
| Intermitência de disco | Yes | - |
| Instantâneos de disco possíveis | Sim | - |
| Instantâneos de VM do Backup do Azure possíveis | Sim | - |
| Custos | Médio | - |
O armazenamento Premium do Azure não atende os KPIs de latência de armazenamento do SAP HANA com os tipos de cache comuns oferecidos com o armazenamento Premium do Azure. Para atender aos KPIs de latência de armazenamento para gravações de log do SAP HANA, você precisa usar o cache do Acelerador de Gravação do Azure, conforme descrito no artigo Habilitar o Acelerador de Gravação. O Acelerador de Gravação do Azure beneficia todos os outros sistemas de DBMS para as gravações de log de transações e gravações de log de restauração. Portanto, é recomendável usá-lo em todas as implantações do DBMS do SAP. No SAP HANA, é obrigatório o uso do Acelerador de Gravação do Azure para /hana/log com o armazenamento Premium do Azure.
Resumo: o armazenamento Premium do Azure é um dos tipos de armazenamento do Azure recomendados para a carga de trabalho do SAP. Essa recomendação é aplicável em sistemas de produção e de não produção. O armazenamento Premium do Azure é adequado para lidar com as cargas de trabalho do banco de dados. O uso do Acelerador de Gravação do Azure aprimora substancialmente a latência de gravação em discos premium do Azure. No entanto, para sistemas do DBMS com taxas de transferência e de IOPS altas é necessário superprovisionar capacidade de armazenamento. Ou você precisa usar funcionalidade como Espaços de armazenamento do Windows ou gerentes de volumes lógicos no Linux para criar conjuntos de faixa que fornecem a capacidade desejada por um lado. Mas também fornecem o IOPS ou a taxa de transferência necessária de forma mais econômica.
Funcionalidade de intermitência do Azure para armazenamento premium
É oferecida a funcionalidade de intermitência a discos de armazenamento premium do Azure com capacidade menor ou igual a 512 GiB. A maneira exata que o bursting de disco funciona é descrita no artigo Bursting de disco. Ao ler o artigo, você entenderá o conceito de acumular IOPS e taxa de transferência quando a sua carga de trabalho de E/S estiver abaixo do IOPS nominal e da taxa de transferência dos discos (para obter detalhes sobre a taxa de transferência nominal, confira Preço do Managed Disk). Você acumulará o delta do IOPS e da taxa de transferência sobre o uso atual e os valores nominais do disco. As intermitências são limitadas a 30 minutos no máximo.
Os casos ideais em que essa funcionalidade de intermitência pode ser planejada provavelmente serão os volumes ou discos que contêm arquivos de dados para o DBMS diferente. A carga de trabalho de E/S esperada nesses volumes, especialmente com sistemas de pequeno a médio porte, deve ser semelhante a:
- Carga de trabalho de leitura baixa a moderada pois os dados são preferencialmente armazenados em cache na memória. Ou, como com o SAP HANA, que deve ser completamente na memória
- Intermitências de gravações disparadas por pontos de verificação de banco de dados ou por pontos de salvamento emitidos regularmente
- Carga de trabalho de backup que faz leituras em um fluxo contínuo, nos casos em que os backups não são executados por meio de instantâneos de armazenamento
- Para o SAP HANA, carregar os dados na memória após uma reinicialização da instância
Especialmente em sistemas DBMS menores em que a carga de trabalho lida apenas com algumas centenas de transações por segundo, uma funcionalidade de intermitência também pode fazer sentido para os discos ou volumes que armazenam a transação ou o log refazer. A carga de trabalho esperada nesse disco ou nesses volumes é semelhante a:
- Gravações regulares no disco que dependem da carga de trabalho e da natureza da carga de trabalho, pois cada confirmação emitida pelo aplicativo provavelmente dispara uma operação de E/S
- Maior carga de trabalho na taxa de transferência para casos de tarefas operacionais, como criar ou recriar índices
- Intermitências de leitura ao executar o log de transações ou backups de log de refazer
Azure Premium SSD v2
O armazenamento do Azure SSD Premium v2 é 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 do IOPS e taxa de transferência de armazenamento por disco
- Fornece a possibilidade de adicionar mais IOPS e taxa de transferência em cada disco e pagar separadamente por esses recursos provisionados adicionais
- Passar na certificação SAP HANA sem a ajuda de outras funcionalidades, como o Acelerador de Gravação do Azure ou outros caches
Esse tipo de armazenamento tem como destino cargas de trabalho do DBMS, tráfego de armazenamento que exige latência de submilissegundos e SLAs em IOPS e taxa de transferência. Os discos SSD Premium v2 são entregues com um conjunto padrão de 3.000 IOPS e 125 MBps de taxa de transferência. Além da possibilidade de adicionar mais IOPS e taxa de transferência em discos individuais. O preço do armazenamento é estruturado para que ao ser adicionado mais taxa de transferência ou IOPS isso não influencie principalmente o preço. Mesmo assim, deixamos que você decida como será a configuração de armazenamento do SSD Premium v2. Para um início básico, confira Configurações de armazenamento da máquina virtual do Azure SAP HANA do SSD Premium v2.
Para obter as regiões de fato, esse novo tipo de armazenamento de blocos está disponível e as restrições estão no documento Premium SSD v2.
A matriz de capacidade da carga de trabalho do SAP é semelhante a:
| Funcionalidade | Comentário | Observações/links |
|---|---|---|
| VHD de base do sistema operacional | Sem suporte | Nenhum sistema |
| Disco de dados | Adequado | Todos os sistemas |
| Diretório de transporte global do SAP | Sim | Todos os sistemas |
| sapmnt do SAP | Adequado | Todos os sistemas |
| Armazenamento de backup | Adequado | Para armazenamento de backups de curto prazo |
| Compartilhamentos/disco compartilhado | Não disponível | Precisa dos Arquivos Premium do Azure ou do Azure NetApp Files |
| Resiliência | LRS | Nenhum GRS ou ZRS disponível para discos |
| Latency | submilissegundos | - |
| SLA de IOPS | Sim | - |
| IOPS linear com a capacidade | semilinear | Preço do Managed Disk |
| IOPS máxima por disco | 80.000 dependendo do tamanho do disco | Considere também os limites da VM |
| SLA de taxa de transferência | Sim | - |
| Taxa de transferência linear com a capacidade | Semilinear | Preço do Managed Disk |
| Certificado pelo HANA | Sim | - |
| Suporte do Acelerador de Gravação do Azure | Não | - |
| Intermitência de disco | Não | - |
| Instantâneos de disco possíveis | Não | - |
| Instantâneos de VM do Backup do Azure possíveis | Não | - |
| Custos | Médio | - |
Ao contrário do armazenamento Premium do Azure, o Azure SSD Premium v2 atende aos KPIs de latência de armazenamento do SAP HANA. Como resultado, NÃO é necessário usar o cache do Acelerador de Gravação do Azure, conforme descrito no artigo Habilitar Acelerador de Gravação.
Resumo: o Azure SSD Premium v2 é o armazenamento em bloco que ajusta a melhor taxa de preço/desempenho para cargas de trabalho SAP. O Azure SSD Premium v2 é adequado para tratar cargas de trabalho de banco de dados. A latência de submilissegundos é o armazenamento ideal para cargas de trabalho do DBMS exigentes. Apesar de ser um tipo de armazenamento mais recente, lançado em novembro de 2022. Portanto, ele ainda pode ter algumas limitações que desaparecerão nos próximos meses.
Disco Ultra do Azure
Os discos Ultra do Azure proporcionam uma alta taxa de transferência, alta IOPS e armazenamento em disco de baixa latência e consistente para as VMs de IaaS do Azure. Alguns benefícios dos Discos Ultra incluem a capacidade de alterar dinamicamente a IOPS e a taxa de transferência do disco junto as suas cargas de trabalho, sem a necessidade de reiniciar as VMs (máquinas virtuais). Os Discos Ultra são adequados para cargas de trabalho com uso intensivo de dados, como carga de trabalho do SAP DBMS. Os Discos Ultra só podem ser usados como discos de dados e não podem ser usados como um disco VHD de base que armazena o sistema operacional. É recomendável que o armazenamento Premium do Azure seja usado como um disco VHD de base.
Ao criar um Disco Ultra, você tem três dimensões que podem ser definidas:
- A capacidade do disco. Os intervalos são de 4 GiB a 65.536 GiB
- IOPS provisionada para o disco. Diferentes valores máximos se aplicam à capacidade do disco. Leia o artigo Disco Ultra para obter mais detalhes
- Largura de banda de armazenamento provisionada. Diferentes larguras de banda máximas são aplicáveis de acordo com a capacidade do disco. Leia o artigo Disco Ultra para obter mais detalhes
O custo de um disco é determinado pelas três dimensões que você pode definir para os discos específicos separadamente.
A matriz de capacidade da carga de trabalho do SAP é semelhante a:
| Funcionalidade | Comentário | Observações/links |
|---|---|---|
| VHD de base do sistema operacional | Não funciona | - |
| Disco de dados | Adequado | Todos os sistemas |
| Diretório de transporte global do SAP | Sim | Com suporte |
| sapmnt do SAP | Adequado | Todos os sistemas |
| Armazenamento de backup | Adequado | Para armazenamento de backups de curto prazo |
| Compartilhamentos/disco compartilhado | Não disponível | Precisa de terceiros |
| Resiliência | LRS | Nenhum GRS ou ZRS disponível para discos |
| Latency | Muito baixa | - |
| SLA de IOPS | Sim | - |
| IOPS linear com a capacidade | Semilinear entre colchetes | Preço do Managed Disk |
| IOPS máxima por disco | 1\.200 a 160.000 | dependendo da capacidade do disco |
| SLA de taxa de transferência | Sim | - |
| Taxa de transferência linear com a capacidade | Semilinear entre colchetes | Preço do Managed Disk |
| Certificado pelo HANA | Sim | - |
| Suporte do Acelerador de Gravação do Azure | Não | - |
| Intermitência de disco | Não | - |
| Instantâneos de disco possíveis | Não | - |
| Instantâneos de VM do Backup do Azure possíveis | Não | - |
| Custos | Maior do que o armazenamento Premium | - |
Resumo: os Discos Ultra do Azure são um armazenamento adequado com latência de submilissegundos baixa para todos os tipos de carga de trabalho do SAP. Até agora, o Disco Ultra só pode ser usado em combinações com VMs implantadas por meio de Zonas de Disponibilidade (implantação zonal). O Disco Ultra não dá suporte a instantâneos de armazenamento. Ao contrário de todos os outros armazenamentos, o Disco Ultra não pode ser usado para o disco VHD base. O Disco Ultra é 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 a IOPS aos padrões de carga de trabalho de armazenamento, em vez de dimensionar para uso máximo de largura de banda e IOPS.
ANF (Azure NetApp Files)
O Azure NetApp Files é o resultado de uma cooperação entre a Microsoft e a NetApp com a meta de fornecer compartilhamentos SMB e NFS nativos do Azure de alto desempenho. A ênfase é fornecer um armazenamento de baixa latência e de alta largura de banda que possibilite cenários de implantação de DBMS e, ao longo do tempo, permita também a funcionalidade operacional típica do armazenamento do NetApp por meio do Azure. Os compartilhamentos NFS/SMB são oferecidos em três níveis de serviço com diferentes preços e taxas de transferência de armazenamento. Os níveis de serviço são documentados no artigo Níveis de serviço do Azure NetApp Files. Para diferentes tipos de carga de trabalho do SAP, os seguintes níveis de serviço são altamente recomendados:
- Carga de trabalho do SAP DBMS: desempenho, idealmente Ultra
- Compartilhamento SAPMNT: desempenho, idealmente Ultra
- Diretório de transporte global: desempenho, idealmente Ultra
Observação
O tamanho mínimo de provisionamento é uma unidade de 4 TiB que é chamada de pool de capacidade. Em seguida, crie volumes provenientes desse pool de capacidade. O menor volume que você pode criar é 100 GiB. Entretanto, você pode expandir um pool de capacidade nas etapas do TiB. Para obter os preços, veja o artigo Preço do Azure NetApp Files
Atualmente, o armazenamento do ANF tem suporte em vários cenários de carga de trabalho do SAP:
- Como fornecer compartilhamentos SMB ou NFS para o diretório de transporte global do SAP
- O sapmnt de compartilhamento em cenários de alta disponibilidade, conforme documentado em:
- Alta disponibilidade do SAP NetWeaver em VMs do Azure no Windows com o Azure NetApp Files (SMB) para aplicativos SAP
- Alta disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com o Azure NetApp Files para aplicativos SAP
- Alta disponibilidade de Máquinas Virtuais do Azure para SAP NetWeaver no Red Hat Enterprise Linux com o Azure NetApp Files para aplicativos SAP
- As implantações do SAP HANA que usam os compartilhamentos NFS v4.1 para volumes /hana/data e /hana/log e/ou volumes do NFS v4.1 ou do NFS v3 para volumes /hana/shared, conforme documentado no artigo Configurações de armazenamento de máquina virtual do Azure para SAP HANA
- IBM Db2 no Suse ou SO convidado do Red Hat Linux
- Implantações Oracle no sistema operacional convidado Oracle Linux usando dNFS para dados Oracle e volumes de log de restauração. Veja mais detalhes no artigo Implantações de Oracle DBMS de máquinas virtuais do Azure para carga de trabalho do SAP
- SAP ASE no Suse ou SO convidado do Red Hat Linux
Observação
Até agora, nenhuma carga de trabalho DBMS tem suporte no SMB com base no Azure NetApp Files.
Como já ocorre no armazenamento Premium do Azure, um tamanho de taxa de transferência fixo ou linear por GB pode ser um problema quando você precisar cumprir alguns valores mínimos na taxa de transferência. Esse é o caso do SAP HANA. Com o ANF, esse problema pode se tornar mais nítido do que com o disco Premium do Azure. Ao usar o disco Premium do Azure, você pode pegar vários discos menores com uma taxa de transferência relativamente alta por GiB e distribuí-los para que eles sejam econômicos e tenham uma taxa de transferência maior em uma capacidade menor. Esse tipo de distribuição não funciona em compartilhamentos NFS ou SMB hospedados no ANF. Essa restrição resultou na implantação além da capacidade como:
- Para obter, por exemplo, uma taxa de transferência de 250 MiB/s em um volume NFS hospedado no ANF, você precisará implantar a capacidade de 1,95 TiB do nível de serviço Ultra.
- Para obter 400 MiB/s, você precisará implantar a capacidade de 3.125 TiB. Mas talvez você precise superprovisionar a capacidade para atingir a taxa de transferência necessária do volume. Esse excesso de provisionamento de capacidade afeta o preço das instâncias menores do HANA.
- Ao usar o NFS com o ANF no diretório /sapmnt do SAP, normalmente você está indo muito bem com a capacidade mínima de 100 GiB a 150 GiB que é imposta pelo Azure NetApp Files. No entanto, a experiência do cliente mostrou que a taxa de transferência relacionada de 12,8 MiB/s (usando o nível de serviço Ultra) pode não ser suficiente e ter um impacto negativo na estabilidade do sistema SAP. Nesses casos, os clientes podem evitar problemas aumentando o volume do volume /sapmnt, para que mais taxa de transferência seja fornecida para ele.
A matriz de capacidade da carga de trabalho do SAP é semelhante a:
| Funcionalidade | Comentário | Observações/links |
|---|---|---|
| VHD de base do sistema operacional | Não funciona | - |
| Disco de dados | Adequado | SAP HANA, Oracle no Oracle Linux, Db2 e SAP ASE no SLES/RHEL |
| Diretório de transporte global do SAP | Sim | SMB e NFS |
| sapmnt do SAP | Adequado | Todos os sistemas com SMB (somente Windows) ou NFS (somente Linux) |
| Armazenamento de backup | Adequado | - |
| Compartilhamentos/disco compartilhado | Sim | SMB 3.0, NFS v3 e NFS v4.1 |
| Resiliência | LRS e GRS | GRS disponível |
| Latency | Muito baixa | - |
| SLA de IOPS | Sim | - |
| IOPS linear com a capacidade | estritamente linear | Depende do nível de serviço |
| SLA de taxa de transferência | Sim | - |
| Taxa de transferência linear com a capacidade | linear | Depende do nível de serviço |
| Certificado pelo HANA | Sim | - |
| Instantâneos de disco possíveis | Sim | - |
| Instantâneos de VM do Backup do Azure possíveis | Não | - |
| Custos | Maior do que o armazenamento Premium | - |
Outra funcionalidade interna do armazenamento do ANF:
- Capacidade de executar instantâneos do volume
- Clonagem de volumes do ANF por meio de instantâneos
- Restauração de volumes de instantâneos (snap-revert)
- Backup de instantâneo consistente do aplicativo para SAP HANA e Oracle
Importante
Especificamente para implantações de banco de dados, você deseja obter latências baixas pelo menos para os logs de refazer. Especialmente para o SAP HANA, O SAP requer uma latência de menos de 1 milissegundo para gravações de log de refazer HANA de tamanhos menores. Para atingir essas latências, confira 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 você colocou a(s) sua(s) VM(s) que devem montar os compartilhamentos NFS. Essa funcionalidade está documentada no artigo Gerenciar o posicionamento do volume na zona de disponibilidade do Azure NetApp Files. A motivação para ter esse tipo de alinhamento de 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.
- Escolha a maior proximidade entre a VM e o compartilhamento NFS que possa ser obtida usando grupos de volumes de aplicativo. A vantagem dos grupos de volumes de aplicativo, além de alocar a melhor proximidade e obtendo a menor latência, é que os diferentes compartilhamentos NFS de implantações do SAP HANA são distribuídos entre diferentes controladores nos clusters de back-end do Azure NetApp Files. A desvantagem desse método é que você precisa passar por um processo de fixação novamente. Um processo que acabará restringindo a implantação de VM a um só datacenter. Em vez de Zonas de Disponibilidade como o primeiro método introduzido. Isso significa menos flexibilidade na alteração dos tamanhos de VM e das famílias de VMs das VMs que têm os volumes NFS montados.
- Processo atual de não usar grupos de posicionamento por proximidade. Que até agora estão disponíveis apenas para o SAP HANA. Esse processo também usa o mesmo processo de fixação manual que nos grupos de volume de disponibilidade. Esse método foi usado nos últimos três anos. Ele tem as mesmas restrições de flexibilidade que o processo com grupos de volume de disponibilidade.
Como preferências para alocar volumes NFS com base no ANF para uso específico do banco de dados, você deve tentar alocar o volume NFS na mesma zona que a VM primeiro. Principalmente para bancos de dados que não são HANA. Somente se a latência for insuficiente, você deverá executar o processo de fixação manual. Para uma carga de trabalho do HANA menor ou que não seja de produção, você também deverá 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ê deverá usar grupos de volumes de aplicativo.
Resumo: o Azure NetApp Files é um armazenamento de baixa latência certificado por 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 distintas de maneira linear por capacidade de GiB do volume. O armazenamento ANF está habilitando a implantação de 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 SAP ou /sapmnt. O armazenamento ANF é fornecido com a disponibilidade de funcionalidade que está disponível como uma funcionalidade nativa do NetApp.
Arquivos Premium do Azure
O Arquivos Premium do Azure é um armazenamento compartilhado que oferece SMB e NFS por um preço moderado e latência suficiente para tratar compartilhamentos da camada de aplicativo do SAP. Além disso, os Arquivos Premium do Azure oferecem 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 comando. Ao contrário do Azure NetApp Files, não há camadas de desempenho. Além de não haver necessidade de um pool de capacidade. O carregamento é baseado na capacidade real provisionada dos diferentes compartilhamentos. Os Arquivos Premium do Azure não foram testados como armazenamento do DBMS para a carga de trabalho do SAP. Em vez disso, o cenário de uso da carga de trabalho do SAP se concentrou em todos os tipos de compartilhamentos SMB e NFS, pois eles são usados na camada de aplicativo do SAP. Os Arquivos Premium do Azure também são adequados para o uso do /hana/shared.
Observação
Não há suporte para cargas de trabalho do DBMS SAP em volumes compartilhados com base nos Arquivos Premium do Azure até o momento.
Cenários SAP com suporte na lista de Arquivos Premium do Azure, como:
- Como fornecer compartilhamentos SMB ou NFS para o diretório de transporte global do SAP
- O sapmnt de compartilhamento em cenários de alta disponibilidade, conforme documentado em:
- Alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com o NFS nos Arquivos do Azure
- Alta disponibilidade para SAP NetWeaver em VMs do Azure no Red Hat Enterprise Linux com NFS nos Arquivos do Azure
- Alta disponibilidade do SAP NetWeaver em VMs do Azure no Windows com os Arquivos do Azure Premium (SMB) para aplicativos SAP
- Alta disponibilidade para o sistema de expansão SAP HANA com HSR no SUSE Linux Enterprise Server
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 o Azure NetApp Files. Essa barra mais alta de IOPS pode evitar o superprovisionamento de capacidade para alcançar determinados valores de IOPS e taxa de transferência. Para IOPS e taxa de transferência de armazenamento, confira a seção Destinos de escala de compartilhamento de arquivos do Azure nas metas de escalabilidade e desempenho dos Arquivos do Azure.
A matriz de capacidade da carga de trabalho do SAP é semelhante a:
| Funcionalidade | Comentário | Observações/links |
|---|---|---|
| VHD de base do sistema operacional | Não funciona | - |
| Disco de dados | Sem suporte para cargas de trabalho SAP | - |
| Diretório de transporte global do SAP | Sim | SMB e NFS |
| sapmnt do SAP | Adequado | Todos os sistemas com SMB (somente Windows) ou NFS (somente Linux) |
| Armazenamento de backup | Adequado | - |
| Compartilhamentos/disco compartilhado | Sim | SMB 3.0, NFS v4.1 |
| Resiliência | LRS e ZRS | Nenhum GRS disponível para os Arquivos Premium do Azure |
| Latency | low | - |
| SLA de IOPS | Sim | - |
| IOPS linear com a capacidade | estritamente linear | - |
| SLA de taxa de transferência | Sim | - |
| Taxa de transferência linear com a capacidade | estritamente linear | - |
| Certificado pelo HANA | Não | - |
| Instantâneos de disco possíveis | Não | - |
| Instantâneos de VM do Backup do Azure possíveis | Não | - |
| Custos | low | - |
Resumo: os Arquivos Premium do Azure são um armazenamento de baixa latência que permite implantar volumes ou compartilhamentos NFS e SMB. Os Arquivos Premium do Azure fornecem excelente taxa de preço/desempenho para compartilhamentos de camada de aplicativo SAP. Eles também fornecem replicação zonal síncrona para esses compartilhamentos. Até agora, não oferecemos suporte a esse tipo de armazenamento para carga de trabalho do DBMS SAP. Embora os volumes /hana/shared possam ser usados.
Armazenamento SSD Standard do Azure
Em comparação com o armazenamento HDD Standard do Azure, o armazenamento SSD Standard 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 de IOPS mais baixos. Esse armazenamento é o armazenamento mínimo usado para sistemas SAP que não são de produção que têm baixas demandas de taxa de transferência e de IOPS. A matriz de capacidade da carga de trabalho do SAP é semelhante a:
| Funcionalidade | Comentário | Observações/links |
|---|---|---|
| VHD de base do sistema operacional | Adequado, mas restrito | Sistemas de não produção |
| Disco de dados | Adequado, mas restrito | Alguns sistemas que não são de produção com baixas demandas de IOPS e de latência |
| Diretório de transporte global do SAP | Não | Sem suporte |
| sapmnt do SAP | Adequado, mas restrito | Sistemas de não produção |
| Armazenamento de backup | Adequado | - |
| Compartilhamentos/disco compartilhado | Não disponível | Precisa de terceiros |
| Resiliência | LRS, GRS | Nenhum ZRS disponível para discos |
| Latency | high | Muito alto para o Diretório de Transporte Global do SAP ou para sistemas de produção |
| SLA de IOPS | Não | - |
| IOPS máxima por disco | 500 | Independente do tamanho do disco |
| SLA de taxa de transferência | Não | - |
| Certificado pelo HANA | Não | - |
| Instantâneos de disco possíveis | Sim | - |
| Instantâneos de VM do Backup do Azure possíveis | Sim | - |
| Custos | LOW | - |
Resumo: o armazenamento SSD Standard do Azure é a recomendação mínima para VMs que não são de produção para o VHD de base, implantações eventuais de DBMS com insensibilidade à latência relativa e/ou baixas taxas de IOPS e de transferência. Esse tipo de armazenamento do Azure não tem mais suporte para hospedar o Diretório de Transporte Global SAP.
Armazenamento HDD Standard do Azure
O armazenamento HDD Standard do Azure era o único tipo de armazenamento disponível quando a infraestrutura do Azure obteve a certificação para a carga de trabalho do SAP NetWeaver no ano de 2014. Em 2014, as máquinas virtuais do Azure eram pequenas e tinham taxas de transferência de armazenamento baixas. Portanto, esse tipo de armazenamento conseguia apenas acompanhar as demandas. O armazenamento é ideal para cargas de trabalho sem sensibilidade de latência, que você dificilmente experimenta no espaço do SAP. Com o aumento das taxas de transferência das VMs do Azure e a maior carga de trabalho produzida por essas VMs, esse tipo de armazenamento não é mais usado com cenários de SAP. A matriz de capacidade da carga de trabalho do SAP é semelhante a:
| Funcionalidade | Comentário | Observações/links |
|---|---|---|
| VHD de base do sistema operacional | Inadequado | - |
| Disco de dados | Inadequado | - |
| Diretório de transporte global do SAP | Não | Sem suporte |
| sapmnt do SAP | Não | Sem suporte |
| Armazenamento de backup | Adequado | - |
| Compartilhamentos/disco compartilhado | Não disponível | Precisa de Arquivos do Azure ou de terceiros |
| Resiliência | LRS, GRS | Nenhum ZRS disponível para discos |
| Latency | high | Muito alto para uso de DBMS, Diretório de Transporte Global do SAP ou sapmnt/saploc |
| SLA de IOPS | Não | - |
| IOPS máxima por disco | 500 | Independente do tamanho do disco |
| SLA de taxa de transferência | Não | - |
| Certificado pelo HANA | Não | - |
| Instantâneos de disco possíveis | Sim | - |
| Instantâneos de VM do Backup do Azure possíveis | Sim | - |
| Custos | Baixo | - |
Resumo: HDD Standard é um tipo de armazenamento do Azure que só deve ser usado para armazenar backups do SAP. Ele só deve ser usado como um VHD base para sistemas inativos, como sistemas descontinuados usados para pesquisar dados aqui e lá. Porém, nenhuma VM de desenvolvimento ativo, garantia de qualidade ou produção deve ser baseada nesse armazenamento. Os arquivos de banco de dados também não devem ser hospedados no armazenamento
Limites de 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 uma função vital na largura de banda de armazenamento que você pode obter. Para os diferentes tipos de armazenamento, você precisa considerar:
| Tipo de armazenamento | Linux | Windows | Comentários |
|---|---|---|---|
| HDD Standard | Tamanhos de VMs do Linux no Azure | Tamanhos de VMs do Windows no Azure | Provavelmente é difícil alterar os limites de armazenamento de VMs médias ou grandes |
| SSD Standard | Tamanhos de VMs do Linux no Azure | Tamanhos de VMs do Windows no Azure | Provavelmente é difícil alterar os limites de armazenamento de VMs médias ou grandes |
| Armazenamento Premium | Tamanhos de VMs do Linux no Azure | Tamanhos de VMs do Windows no Azure | Limites de VM de taxa de transferência de armazenamento e de IOPS fáceis de alcançar com a configuração de armazenamento |
| SSD Premium v2 | Tamanhos de VMs do Linux no Azure | Tamanhos de VMs do Windows no Azure | Limites de VM de taxa de transferência de armazenamento e de IOPS fáceis de alcançar com a configuração de armazenamento |
| Armazenamento de Disco Ultra | Tamanhos de VMs do Linux no Azure | Tamanhos de VMs do Windows no Azure | Limites de VM de taxa de transferência de armazenamento e de IOPS fáceis de alcançar com a configuração de armazenamento |
| Azure NetApp Files | Tamanhos de VMs do Linux no Azure | Tamanhos de 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 a largura de banda de armazenamento. |
| Arquivos Premium do Azure | Tamanhos de VMs do Linux no Azure | Tamanhos de 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 a largura de banda de armazenamento. |
Como limitações, você precisa observar que:
- Quanto menor a VM, menos discos você pode anexar. Essa restrição não se aplica ao 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 limites de taxa de transferência de E/S e IOPS que podem ser excedidos facilmente com discos de armazenamento Premium e Discos Ultra
- Com ANF e Arquivos Premium do Azure, o tráfego para os volumes compartilhados está consumindo a largura de banda da 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 fora de uma só VM atingirá um platô com base nos limites do Linux para uma só sessão que interage com o volume compartilhado.
Ao dimensionar as VMs do Azure no ciclo de vida de um sistema SAP, você deve avaliar os limites de taxa de transferência de IOPS e armazenamento do tipo de VM novo e maior. Em alguns casos, também poderia fazer sentido ajustar a configuração de armazenamento para as novas funcionalidades da VM do Azure.
Distribuição ou não distribuição
A criação de um conjunto de distribuição de vários discos do Azure em um volume maior permite que você acumule a IOPS e a taxa de transferência dos discos individuais em um volume. Ele só é usado para o Armazenamento Standard do Azure e o Armazenamento Premium do Azure. O Disco Ultra do Azure, no qual você pode configurar a taxa de transferência e a IOPS independentes da capacidade de um disco, não exige o uso de conjuntos de distribuição. Volumes compartilhados baseados em NFS ou SMB não podem ser distribuídos. Devido à natureza não linear da taxa de transferência e da IOPS do armazenamento Premium do Azure, você pode provisionar capacidade menor com a mesma IOPS e taxa de transferência do que grandes discos únicos de armazenamento Premium do Azure. Esse é o método para obter uma taxa de transferência maior ou IOPS com custo mais baixo usando o armazenamento Premium do Azure. Por exemplo, a distribuição entre dois discos de armazenamento P15 Premium faz com que você tenha uma taxa de transferência de:
- 250 MiB/s. Esse volume terá uma capacidade de 512 GiB. Se você quiser ter um disco que forneça uma taxa de transferência de 250 MiB por segundo, precisará escolher um disco P40 com capacidade de 2 TiB.
- 400 MiB/s distribuindo quatro discos de armazenamento Premium P10 com uma capacidade geral de 512 GiB por distribuição. Se você quiser ter um disco com uma taxa de transferência mínima de 500 MiB por segundo, precisará escolher um disco de armazenamento Premium P60 com 8 TiB. Como o custo do armazenamento Premium é quase linear com a capacidade, você pode perceber a economia de custos usando a distribuição.
Algumas regras precisam ser seguidas na distribuição:
- Nenhum armazenamento configurado na VM deve ser usado, já que o armazenamento do Azure mantém os dados redundantes
- Os discos aos quais o conjunto de distribuição é aplicado precisam ter o mesmo tamanho
- Com o disco Ultra e SSD Premium v2 a capacidade, o IOPS provisionado e a taxa de transferência provisionada precisam ser iguais
A distribuição em vários discos menores é a melhor maneira de atingir um bom preço/taxa de desempenho usando o armazenamento Premium do Azure. Considera-se que a distribuição possa ter alguma sobrecarga de implantação e gerenciamento extra.
Para obter recomendações específicas de tamanho de distribuição, leia a documentação do DBMS diferente, como Configurações de armazenamento de máquina virtual do Azure para SAP HANA.
Próximas etapas
Leia os artigos: