Considerações para a implantação do DBMS de Máquinas Virtuais do Azure para carga de trabalho SAP

  • Artigo

Este guia faz parte da documentação sobre como implementar e implantar o software SAP no Microsoft Azure. Antes de ler este guia, leia o guia de planejamento e implementação e os artigos para os quais o guia de planejamento aponta para você. Este documento aborda os aspetos genéricos de implantação de sistemas DBMS relacionados ao SAP em máquinas virtuais (VMs) do Microsoft Azure usando os recursos de infraestrutura como serviço (IaaS) do Azure.

O documento complementa a documentação de instalação SAP e o SAP Notes, que representam os principais recursos para instalações e implantações de software SAP em determinadas plataformas.

Neste documento, são apresentadas considerações sobre a execução de sistemas DBMS relacionados ao SAP em VMs do Azure. Há poucas referências a sistemas DBMS específicos neste documento. Em vez disso, os sistemas DBMS específicos são tratados em outros documentos específicos do sistema de banco de dados.

Recursos

Há outros artigos disponíveis sobre a carga de trabalho do SAP no Azure. Comece com a carga de trabalho do SAP no Azure: comece e escolha sua área de interesse.

As seguintes notas SAP estão relacionadas ao SAP no Azure em relação à área coberta neste documento.

Número da nota Título
1928533 Aplicativos SAP no Azure: produtos suportados e tipos de VM do Azure
2015553 SAP no Microsoft Azure: pré-requisitos de suporte
1999351 Solução de problemas de monitoramento avançado do Azure para SAP
2178632 Principais métricas de monitoramento para SAP no Microsoft Azure
1409604 Virtualização no Windows: monitoramento aprimorado
2191498 SAP no Linux com Azure: monitoramento aprimorado
2039619 Aplicativos SAP no Microsoft Azure usando o banco de dados Oracle: produtos e versões suportados
2233094 DB6: Aplicativos SAP no Azure usando IBM DB2 para Linux, UNIX e Windows: Informações adicionais
2243692 Linux on Microsoft Azure (IaaS) VM: Problemas de licença SAP
2578899 SUSE Linux Enterprise Server 15: Nota de Instalação
1984787 SUSE LINUX Enterprise Server 12: Notas de instalação
2772999 Red Hat Enterprise Linux 8.x: Instalação e Configuração
2002167 Red Hat Enterprise Linux 7.x: Instalação e atualização
2069760 Instalação e atualização do Oracle Linux 7.x SAP
1597355 Recomendação de espaço de troca para Linux
2799900 Nota técnica central para o Oracle Database 19c
2171857 Oracle Database 12c: Suporte ao sistema de arquivos no Linux
1114181 Oracle Database 11g: Suporte ao sistema de arquivos no Linux
2969063 Falha na validação de microcódigo no HCMT no Azure
3246210 Azure - HCMT falha durante alguns testes de desempenho de disco

Para obter informações sobre todas as SAP Notes para Linux, consulte o wiki da comunidade SAP.

Você precisa de um conhecimento prático da arquitetura do Microsoft Azure e de como as máquinas virtuais do Microsoft Azure são implantadas e operadas. Para obter mais informações, consulte a documentação do Azure.

Em geral, a instalação e configuração do Windows, Linux e DBMS são essencialmente as mesmas que qualquer máquina virtual ou máquina bare metal instalada localmente. Há algumas decisões de implementação de arquitetura e gerenciamento de sistema que são diferentes quando você usa a IaaS do Azure. Este documento explica as diferenças específicas de arquitetura e gerenciamento de sistema para as quais você deve estar preparado quando você usa a IaaS do Azure.

Estrutura de armazenamento de uma VM para implantações RDBMS

Para acompanhar este capítulo, leia e compreenda as informações apresentadas em:

Para o armazenamento de blocos do Azure, o uso de discos gerenciados do Azure é obrigatório. Para obter detalhes sobre os discos gerenciados do Azure, leia o artigo Introdução aos discos gerenciados para VMs do Azure.

Em uma configuração básica, geralmente recomendamos uma estrutura de implantação em que o sistema operacional, o DBMS e eventuais binários SAP sejam separados dos arquivos de banco de dados. Recomendamos ter discos do Azure separados para:

  • O sistema operacional (VHD base ou OS VHD)
  • Executáveis do sistema de gerenciamento de banco de dados
  • Executáveis SAP como /usr/sap
  • Arquivos de dados DBMS
  • Arquivos de log de refazer DBMS

Uma configuração que separa esses componentes em cinco volumes diferentes pode resultar em maior resiliência, uma vez que o uso excessivo em um volume não interfere necessariamente no uso de outros volumes, desde que a cota e os limites de armazenamento da VM não sejam excedidos.

Os dados DBMS e os arquivos de log de transação/refazer são armazenados no armazenamento de blocos com suporte do Azure ou nos Arquivos NetApp do Azure. Não há suporte para Arquivos do Azure ou Arquivos Premium do Azure como armazenamento para dados DBSM e/ou arquivos de log de refazer com a carga de trabalho SAP. Eles são armazenados em discos separados e anexados como discos lógicos à VM de imagem original do sistema operacional Azure. Para implantações Linux, diferentes recomendações são documentadas. Leia o artigo Tipos de armazenamento do Azure para carga de trabalho SAP para os recursos e o suporte dos diferentes tipos de armazenamento para o seu cenário. Especificamente para SAP HANA, comece com o artigo Configurações de armazenamento de máquina virtual do Azure SAP HANA.

Ao planejar o layout do disco, encontre o melhor equilíbrio entre estes itens:

  • O número de arquivos de dados.
  • O número de discos que contêm os arquivos.
  • As cotas IOPS de um único disco ou compartilhamento NFS.
  • A taxa de transferência de dados por disco ou compartilhamento NFS.
  • O número de discos de dados adicionais possíveis por tamanho de VM.
  • A taxa de transferência geral de armazenamento ou de rede que uma VM pode fornecer.
  • A latência que diferentes tipos de Armazenamento do Azure podem fornecer.
  • IOPS de armazenamento de VM e cota de taxa de transferência.
  • Cota de rede da VM caso você esteja usando NFS - o tráfego para compartilhamentos NFS está contando com a cota de rede da VM e NÃO com a cota de armazenamento.
  • SLAs de VM.

O Azure impõe uma cota IOPS por disco de dados ou compartilhamento NFS. Essas cotas são diferentes para discos hospedados nas diferentes soluções ou compartilhamentos de armazenamento em bloco do Azure. A latência de E/S também é diferente entre esses diferentes tipos de armazenamento.

Cada um dos diferentes tipos de VM tem um número limitado de discos de dados que você pode anexar. Outra restrição é que apenas determinados tipos de VM podem usar, por exemplo, armazenamento premium. Normalmente, você decide usar um determinado tipo de VM com base nos requisitos de CPU e memória. Você também precisa considerar os requisitos de IOPS, latência e taxa de transferência de disco que geralmente são dimensionados com o número de discos ou o tipo de discos de armazenamento premium v1. O número de IOPS e a taxa de transferência a ser alcançada por cada disco podem ditar o tamanho do disco, especialmente com o armazenamento premium v1. Com o armazenamento premium v2 ou Ultra disk, você pode selecionar IOPS provisionadas e taxa de transferência independente da capacidade do disco.

Nota

Para implantações de DBMS, é altamente recomendável o armazenamento premium do Azure (v1 e v2), disco Ultra ou compartilhamentos NFS baseados em Arquivos NetApp do Azure para quaisquer dados, log de transações ou arquivos de refazer. Não importa se você deseja implantar sistemas de produção ou não. A latência do HDD ou SSD padrão do Azure não é aceitável para qualquer tipo de sistema de produção.

Nota

Para maximizar o SLA de VM única do Azure, todos os discos anexados devem ser o armazenamento premium do Azure (v1 ou v2) ou o tipo de disco Azure Ultra, que inclui o VHD base (armazenamento premium do Azure).

Nota

Não há suporte para hospedagem de arquivos de banco de dados principais, como arquivos de dados e log, de bancos de dados SAP em hardware de armazenamento localizado em data centers de terceiros colocalizados adjacentes aos data centers do Azure. O armazenamento fornecido por meio de dispositivos de software hospedados em VMs do Azure também não é suportado para este caso de uso. Para cargas de trabalho do SAP DBMS, apenas o armazenamento representado como serviço nativo do Azure é suportado para os arquivos de log de dados e transações dos bancos de dados SAP em geral. DBMS diferentes podem dar suporte a diferentes tipos de armazenamento do Azure. Para obter mais detalhes, consulte o artigo Tipos de armazenamento do Azure para carga de trabalho SAP

O posicionamento dos arquivos de banco de dados e dos arquivos de log e refazer e o tipo de Armazenamento do Azure que você usa são definidos pelos requisitos de IOPS, latência e taxa de transferência. Especificamente para o armazenamento premium do Azure v1, para obter IOPS suficientes, você pode ser forçado a usar vários discos ou usar um disco de armazenamento premium maior. Se você usar vários discos, crie uma distribuição de software nos discos que contêm os arquivos de dados ou os arquivos de log e refazer. Nesses casos, as IOPS e os SLAs de taxa de transferência de disco dos discos de armazenamento premium subjacentes ou as IOPS máximas alcançáveis de discos de armazenamento padrão são acumuladas para o conjunto de distribuição resultante.

Se o requisito de IOPS exceder o que um único VHD pode fornecer, equilibre o IOPS necessário para os arquivos de banco de dados em vários VHDs. A maneira mais fácil de distribuir a carga IOPS entre discos é criar uma distribuição de software sobre os diferentes discos. Em seguida, coloque vários arquivos de dados do DBMS SAP nos LUNs esculpidos na faixa de software. O número de discos na distribuição é controlado por demandas de IOPS, taxas de transferência de disco e demandas de volume.

Windows storage striping Mac OS

Recomendamos que você use os Espaços de Armazenamento do Windows para criar conjuntos de distribuição em vários VHDs do Azure. Use pelo menos o Windows Server 2012 R2 ou o Windows Server 2016.

Linux storage striping Aplicações Linux

Apenas MDADM e Logical Volume Manager (LVM) são suportados para construir um RAID de software no Linux. Para obter mais informações, consulte:

Para o armazenamento premium do Azure v2 e Ultra disk, o striping pode não ser necessário, pois você pode definir IOPS e taxa de transferência de disco independentemente do tamanho do disco.

Nota

Como o Armazenamento do Azure mantém três imagens dos VHDs, não faz sentido configurar uma redundância quando você distribui. Você só precisa configurar o striping para que as E/S sejam distribuídas pelos diferentes VHDs.

Discos gerenciados ou não gerenciados

Uma conta de armazenamento do Azure é uma construção administrativa e também um assunto de limitações. Para obter informações sobre recursos e limitações, consulte Metas de desempenho e escalabilidade do Armazenamento do Azure. Para armazenamento padrão, lembre-se de que há um limite de IOPS por conta de armazenamento. Consulte a linha que contém a Taxa Total de Solicitações no artigo Metas de desempenho e escalabilidade do Armazenamento do Azure. Há também um limite inicial para o número de contas de armazenamento por assinatura do Azure. A partir de 2017, o Azure introduziu os conceitos de Discos Gerenciados do Azure que ajudam você a cuidar de qualquer administração de conta de armazenamento. Usar discos gerenciados do Azure é o padrão a ser implantado para a carga de trabalho do SAP no Azure.

Importante

Dadas as vantagens dos Managed Disks do Azure, é obrigatório que você use o Azure Managed Disks para suas implantações de DBMS e SAP em geral.

Se acontecer de você ter uma carga de trabalho SAP que ainda não está usando discos gerenciados, para converter de discos não gerenciados para gerenciados, consulte:

Cache para VMs e discos de dados

Ao montar discos em VMs, você pode escolher se o tráfego de E/S entre a VM e os discos localizados no armazenamento do Azure será armazenado em cache.

As recomendações a seguir assumem essas características de E/S para SGBD padrão:

  • É principalmente uma carga de trabalho de leitura em relação a arquivos de dados de um banco de dados. Essas leituras são críticas para o desempenho do sistema DBMS.
  • A gravação nos arquivos de dados ocorre em rajadas com base em pontos de verificação ou em um fluxo constante. Em média, ao longo de um dia, há menos gravações do que leituras. Ao contrário das leituras de arquivos de dados, essas gravações são assíncronas e não retêm nenhuma transação do usuário.
  • Quase não há leituras do log de transações ou arquivos de refazer. As exceções são E/S grandes quando você executa backups de log de transações.
  • A principal carga em relação aos arquivos de log de transação ou refazer é a gravação. Dependendo da natureza da carga de trabalho, você pode ter E/S tão pequenas quanto 4 KB ou, em outros casos, tamanhos de E/S de 1 MB ou mais.
  • Todas as gravações devem ser mantidas no disco de forma confiável.

Para o armazenamento premium do Azure v1, existem as seguintes opções de cache:

  • Nenhuma
  • Lida
  • Leitura/escrita
  • Nenhum + Acelerador de Gravação, que é apenas para VMs do Azure M-Series
  • Acelerador de Leitura + Gravação, que é apenas para VMs da Série M do Azure

Para armazenamento premium v1, recomendamos que você use o cache de leitura para arquivos de dados do banco de dados SAP e escolha Sem cache para os discos do(s) arquivo(s) de log.

Para implantações da Série M, recomendamos que você use o Azure Write Accelerator somente para os discos de seus arquivos de log. Para obter detalhes, restrições e implantação do Azure Write Accelerator, consulte Habilitar o Acelerador de Gravação.

Para armazenamento premium v2, disco Ultra e Arquivos NetApp do Azure, nenhuma opção de cache é oferecida.

Discos não persistentes do Azure

As VMs do Azure oferecem discos não persistentes após a implantação de uma VM. Se uma VM for reinicializada, todo o conteúdo dessas unidades poderá ser apagado. É um dado adquirido que os arquivos de dados e arquivos de log e refazer de bancos de dados não devem, em nenhuma circunstância, ser localizados nessas unidades não persistentes. Pode haver exceções para alguns bancos de dados, onde essas unidades não persistentes podem ser adequadas para tempdb e temp tablespaces.

Para obter mais informações, consulte Compreender a unidade temporária em VMs do Windows no Azure.

Windows nonpersisted disk Mac OS

A unidade D em uma VM do Azure é uma unidade não persistente, que é apoiada por alguns discos locais no nó de computação do Azure. Como não é persistente, todas as alterações feitas no conteúdo da unidade D são perdidas quando a VM é reinicializada. As alterações incluem arquivos que foram armazenados, diretórios que foram criados e aplicativos que foram instalados.

Linuxnonpersisted disk Aplicações Linux

As VMs do Azure Linux montam automaticamente uma unidade em /mnt/resource que é uma unidade não persistente apoiada por discos locais no nó de computação do Azure. Como não é persistente, todas as alterações feitas no conteúdo em /mnt/resource são perdidas quando a VM é reinicializada. As alterações incluem arquivos que foram armazenados, diretórios que foram criados e aplicativos que foram instalados.

Resiliência de armazenamento do Microsoft Azure

O Armazenamento do Microsoft Azure armazena o VHD base, com SO e discos ou blobs anexados, em pelo menos três nós de armazenamento separados. Esse tipo de armazenamento é chamado de armazenamento com redundância local (LRS). O LRS é o padrão para todos os tipos de armazenamento no Azure.

Existem outros métodos de redundância. Para obter mais informações, consulte Replicação do Armazenamento do Azure.

Nota

O armazenamento premium do Azure v1 e v2, o disco Ultra e os Arquivos NetApp do Azure são o tipo recomendado de armazenamento para VMs DBMS e discos que armazenam banco de dados e arquivos de log e refazer. Com exceção do armazenamento premium v1, o único método de redundância disponível para esses tipos de armazenamento é o LRS. Como resultado, você precisa configurar métodos de banco de dados para habilitar a replicação de dados de banco de dados em outra região ou zona de disponibilidade do Azure. Os métodos de banco de dados incluem SQL Server Always On, Oracle Data Guard e HANA System Replication.

Resiliência do nó VM

O Azure oferece vários SLAs diferentes para VMs. Para obter mais informações, consulte a versão mais recente do SLA para máquinas virtuais. Como a camada DBMS é crítica para a disponibilidade em um sistema SAP, você precisa entender os diferentes tipos de implantação e eventos de manutenção. Para obter mais informações sobre esses conceitos, consulte Gerenciar a disponibilidade de máquinas virtuais no Azure.

A recomendação mínima para cenários DBMS de produção com uma carga de trabalho SAP é:

  • Implante duas VMs usando o tipo de implantação escolhido na mesma região do Azure.
  • Execute essas duas VMs na mesma rede virtual do Azure e tenha NICs conectadas fora das mesmas sub-redes.
  • Use métodos de banco de dados para manter um hot standby com a segunda VM. Os métodos podem ser SQL Server Always On, Oracle Data Guard ou HANA System Replication.

Você também pode implantar uma terceira VM em outra região do Azure e usar os mesmos métodos de banco de dados para fornecer uma réplica assíncrona em outra região do Azure.

Considerações de rede do Azure

Em implantações SAP de grande escala, use o blueprint do Azure Virtual Datacenter. Use-o para sua configuração de rede virtual e permissões e atribuições de função para diferentes partes da sua organização.

Essas práticas recomendadas são o resultado de milhares de implantações de clientes:

  • As redes virtuais nas quais o aplicativo SAP é implantado não têm acesso à Internet.
  • As VMs de banco de dados são executadas na mesma rede virtual que a camada de aplicativo, separadas em uma sub-rede diferente da camada de aplicativo SAP.
  • As VMs dentro da rede virtual têm uma alocação estática do endereço IP privado. Para obter mais informações, consulte Tipos de endereço IP e métodos de alocação no Azure.
  • As restrições de roteamento de e para as VMs DBMS não são definidas com firewalls instalados nas VMs DBMS locais. Em vez disso, o roteamento de tráfego é definido com grupos de segurança de rede (NSGs).
  • Para separar e isolar o tráfego para a VM DBMS, atribua NICs diferentes à VM. Cada NIC obtém um endereço IP diferente e cada NIC é atribuída a uma sub-rede de rede virtual diferente. Cada sub-rede tem regras NSG diferentes. O isolamento ou separação do tráfego de rede é uma medida de roteamento. Ele não é usado para definir cotas para taxa de transferência de rede.

Nota

Atribuir endereços IP estáticos através do Azure significa atribuí-los a NICs virtuais individuais. Não atribua endereços IP estáticos dentro do SO convidado a uma placa de rede virtual. Alguns serviços do Azure, como o Backup do Azure, dependem do fato de que pelo menos a NIC virtual primária no SO convidado está definida como DHCP e não para endereços IP estáticos. Para obter mais informações, consulte Solucionar problemas de backup de máquina virtual do Azure. Para atribuir vários endereços IP estáticos a uma VM, atribua várias NICs virtuais a uma VM.

Aviso

Não há suporte para a configuração de dispositivos virtuais de rede no caminho de comunicação entre o aplicativo SAP e a camada DBMS de um sistema SAP baseado em SAP NetWeaver, Hybris ou S/4HANA. Esta restrição deve-se a razões de funcionalidade e desempenho. O caminho de comunicação entre a camada de aplicativo SAP e a camada DBMS deve ser direto. A restrição não inclui regras de grupo de segurança de aplicativo (ASG) e NSG se essas regras ASG e NSG permitirem um caminho de comunicação direta. Isso também inclui tráfego para compartilhamentos NFS que hospedam dados DBMS e refazem arquivos de log.

Outros cenários em que os dispositivos virtuais de rede não são suportados encontram-se em:

Os dispositivos virtuais de rede em caminhos de comunicação podem facilmente duplicar a latência da rede entre dois parceiros de comunicação. Eles também podem restringir a taxa de transferência em caminhos críticos entre a camada de aplicativos SAP e a camada DBMS. Em alguns cenários de clientes, os dispositivos virtuais de rede podem fazer com que os clusters Linux do Pacemaker falhem. Estes são casos em que as comunicações entre os nós de cluster Linux Pacemaker se comunicam com seu dispositivo SBD através de um dispositivo virtual de rede.

Importante

Outro design sem suporte é a segregação da camada de aplicativos SAP e da camada DBMS em diferentes redes virtuais do Azure que não são emparelhadas entre si. Recomendamos que você segregue a camada de aplicativo SAP e a camada DBMS usando sub-redes em uma rede virtual do Azure em vez de usar diferentes redes virtuais do Azure.

Se você decidir não seguir a recomendação e, em vez disso, segregar as duas camadas em redes virtuais diferentes, as duas redes virtuais devem ser emparelhadas.

Lembre-se de que o tráfego de rede entre duas redes virtuais do Azure emparelhadas está sujeito a custos de transferência. Um enorme volume de dados que consiste em muitos terabytes é trocado entre a camada de aplicativos SAP e a camada DBMS. Você pode acumular custos substanciais se a camada de aplicativo SAP e a camada DBMS forem segregadas entre duas redes virtuais do Azure emparelhadas.

Usar o Azure Load Balancer para redirecionar o tráfego

O uso de endereços IP virtuais privados usados em funcionalidades como SQL Server Always On ou HANA System Replication requer a configuração de um balanceador de carga do Azure. O balanceador de carga usa portas de teste para determinar o nó DBMS ativo e rotear o tráfego exclusivamente para esse nó de banco de dados ativo.

Se houver um failover do nó do banco de dados, não será necessário reconfigurar o aplicativo SAP. Em vez disso, as arquiteturas de aplicativos SAP mais comuns se reconectam com o endereço IP virtual privado. Enquanto isso, o balanceador de carga reage ao failover do nó redirecionando o tráfego contra o endereço IP virtual privado para o segundo nó.

O Azure oferece duas SKUs de balanceador de carga diferentes: uma SKU básica e uma SKU padrão. Com base nas vantagens de configuração e funcionalidade, você deve usar a SKU padrão do balanceador de carga do Azure. Uma das grandes vantagens da versão Standard do balanceador de carga é que o tráfego de dados não é roteado através do próprio balanceador de carga.

Um exemplo de como você pode configurar um balanceador de carga interno pode ser encontrado no artigo Tutorial: Configurar um grupo de disponibilidade do SQL Server em Máquinas Virtuais do Azure manualmente

Nota

Existem diferenças no comportamento do SKU básico e padrão relacionado ao acesso de endereços IP públicos. A maneira de contornar as restrições da SKU padrão para acessar endereços IP públicos é descrita no documento Conectividade de ponto de extremidade público para máquinas virtuais usando o balanceador de carga padrão do Azure em cenários de alta disponibilidade SAP

Implantação do monitoramento de host

Para uso de produção de aplicativos SAP em máquinas virtuais do Azure, o SAP requer a capacidade de obter dados de monitoramento de host dos hosts físicos que executam as máquinas virtuais do Azure. É necessário um nível de patch específico do SAP Host Agent que permita esse recurso no SAPOSCOL e no SAP Host Agent. O nível exato do patch está documentado no SAP Note 1409604.

Para obter mais informações sobre a implantação de componentes que fornecem dados de host para SAPOSCOL e SAP Host Agent e o gerenciamento do ciclo de vida desses componentes, comece com o artigo Implementar a extensão de VM do Azure para soluções SAP.

Próximos passos

Para obter mais informações sobre um SGBD específico, consulte: