Considerações para Implantação do DBMS de Máquinas de Virtuais do Azure para carga de trabalho do 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 que o guia de planejamento aponta para você. Este documento aborda os aspectos de implantação genérica dos sistemas DBMS relacionados ao SAP em VMs (máquinas virtuais) do Microsoft Azure, usando os recursos de IaaS (infraestrutura como serviço) do Azure.

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

Neste documento, são introduzidas considerações sobre a execução de sistemas DBMS relacionados ao SAP em VMs do Azure. Há algumas referências a sistemas de DBMS específicos neste documento. Neste caso, os sistemas de DBMS específicos são abordados 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 Carga de trabalho do SAP no Azure: Introdução e escolha sua área de interesse.

As seguintes observações do SAP estão relacionadas ao SAP no Azure em relação à área abordada neste documento.

Número da observação Title
1928533 Aplicativos SAP no Azure: produtos com suporte e tipos de VM do Azure
2015553 SAP no Microsoft Azure: pré-requisitos de suporte
1999351 Solução de problemas de monitoramento aprimorado do Azure para SAP
2178632 Métricas-chave de monitoramento para SAP no Microsoft Azure
1409604 Virtualização no Windows: monitoramento aprimorado
2191498 SAP no Linux com o Azure: monitoramento aprimorado
2039619 Os aplicativos SAP no Microsoft Azure que usam o Oracle Database: produtos e versões com suporte
2233094 DB6: Aplicativos SAP no Azure usando IBM DB2 para Linux, UNIX e Windows: Informações adicionais
2243692 Linux na VM (IaaS) do Microsoft Azure: Problemas de licença do 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 Atualização e instalação do SAP do Oracle Linux 7.x
1597355 Recomendação de troca de espaço para Linux
2799900 Nota técnica central do 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 – O HCMT falha durante alguns testes de desempenho de disco

Para obter informações sobre todas as observações do SAP para Linux, confira a wiki da comunidade do SAP.

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

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

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

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

Para o armazenamento em bloco do Azure, o uso do Azure Managed Disks é obrigatório. Para obter detalhes sobre o Azure Managed disks, leia o artigo Introdução aos discos gerenciados para VMs do Azure.

Em uma configuração básica, nós normalmente recomendamos uma estrutura de implantação na qual o sistema operacional, o DBMS e eventuais binários SAP são separados dos arquivos de banco de dados. É recomendável usar discos do Azure separados para:

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

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

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

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 compartilhamento de disco ou NFS.
  • O número de discos de dados adicionais possíveis por tamanho da VM.
  • A taxa de transferência geral do armazenamento que uma VM pode fornecer.
  • A latência que diferentes tipos de Armazenamento do Azure podem fornecer.
  • Cota de IOPS de armazenamento e de taxa de transferência da VM.
  • Cota de rede da VM em caso de uso do NFS – O tráfego para compartilhamentos NFS é contabilizado na cota de rede da VM e NÃO na cota de armazenamento.
  • SLAs de VM.

O Azure impõe uma cota de IOPS por disco de dados ou compartilhamento NFS. Essas cotas são diferentes para discos hospedados em diferentes soluções ou compartilhamentos de armazenamento de blocos 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 podem ser anexados. Outra restrição é que somente determinados tipos de VM podem usar o 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 de acordo com o número de discos ou o tipo de discos do armazenamento Premium v1. O número de IOPS e a taxa de transferência a serem atingidos em cada disco podem determinar o tamanho do disco, principalmente com o armazenamento Premium v1. Com o armazenamento Premium v2 ou Disco Ultra, você pode selecionar o IOPS e taxa de transferência provisionados, independentemente da capacidade do disco.

Observação

Para implantações de DBMS, é altamente recomendável o armazenamento Premium do Azure (v1 e v2), compartilhamentos NFS com base em disco Ultra ou no Azure NetApp Files para arquivos de dados, de logs de transações ou refazer. Não importa se você deseja implantar sistemas de produção ou não produção. A latência do HD ou do SSD Standard do Azure não é aceitável para nenhum tipo de sistema de produção.

Observação

Para maximizar o SLA de VM individual do Azure, todos os discos anexados precisam ser do tipo de armazenamento Premium do Azure (v1 ou v2) ou do tipo de Disco Ultra do Azure, incluindo VHD base (armazenamento Premium do Azure).

Observação

Não há suporte para a hospedagem de arquivos de banco de dados principal, como arquivos de log e de bancos de dados do SAP no 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 tem suporte para esse caso de uso. Para cargas de trabalho SAP DBMS, apenas armazenamento que é representado como nativo do serviço do Azure tem suporte para os arquivos de log de transações e dados de bancos de dados SAP em geral. Um DBMS diferente pode dar suporte a diferentes tipos de armazenamento do Azure. Para obter mais detalhes, verifique o artigo tipos de armazenamento do Azure para carga de trabalho do SAP

O posicionamento de arquivos de banco de dados e arquivos de log e restauração, além do tipo de Armazenamento do Microsoft Azure usado devem ser definidos por requisitos de taxa de transferência, latência e IOPS. Especificamente para o armazenamento Premium do Azure v1, para obter IOPS suficiente, você poderá 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 restauração. Nesses casos, o IOPS e SLAs de discos do armazenamento premium subjacentes ou o máximo de discos de IOPS de armazenamento padrão que podem ser obtido da taxa de transferência de disco são cumulativos para o conjunto resultante de distribuição.

Se os requisitos de IOPS excedem o que um só VHD oferece, balanceie a IOPS necessária para os arquivos de banco de dados entre vários VHDs. A maneira mais fácil de distribuir a carga de IOPS em discos é criar uma distribuição de software nos diferentes discos e colocar um número de arquivos de dados do SAP DBMS nos LUNs retirados da distribuição de software. O número de discos na distribuição é orientado pelas demandas de IOPs, pelas demandas de taxa de transferência de disco e pelas demandas de volume.

Windows storage striping Windows

Recomendamos usar espaços de armazenamento do Windows para criar conjuntos de distribuição entre vários VHDs do Azure. Use pelo menos o Windows Server 2012 R2 ou o Windows Server 2016.

Linux storage striping Linux

Há suporte apenas para MDADM e LVM (Logical Volume Manager) para criar um RAID de software no Linux. Para obter mais informações, consulte:

Para o armazenamento Premium do Azure v2 e o disco Ultra, a distribuição pode não ser necessária, pois você pode definir a IOPS e a taxa de transferência de disco independentemente do tamanho do disco.

Observação

Como o Armazenamento do Microsoft Azure mantém três imagens dos VHDs, não faz sentido configurar uma redundância enquanto estiver distribuindo. Você só precisa configurar a distribuição para que as E/S sejam distribuídas nos diferentes VHDs.

Discos gerenciados ou não gerenciados

Uma conta de armazenamento do Azure é uma construção administrativa e também está sujeita a limitações. Para obter informações sobre recursos e limitações, confira Metas de desempenho e escalabilidade do Armazenamento do Microsoft Azure. Para o armazenamento padrão, lembre-se de que há um limite de IOPS por conta de armazenamento. Consulte a linha que contém a Taxa de solicitação total no artigo Metas de desempenho e escalabilidade do Armazenamento do Microsoft Azure. Também há um limite inicial para o número de contas de armazenamento por assinatura do Azure. A partir de 2017, o Azure introduziu os conceitos dos Azure Managed Disks, com os quais você não precisa cuidar da administração da conta de armazenamento. O uso dos Azure Managed Disks é o padrão a ser implantado para a carga de trabalho SAP no Azure.

Importante

Considerando as vantagens dos Azure Managed Disks, é necessário usá-los para implantações de DBMS e implantações do SAP em geral.

Se você tiver uma carga de trabalho SAP que ainda não esteja usando discos gerenciados, para converter os discos não gerenciados em discos gerenciados, confira:

Cache de VMs e discos de dados

Quando você monta discos carregados em VMs, é possível escolher se o tráfego de E/S entre a VM e os discos no armazenamento do Azure são armazenados em cache.

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

  • É principalmente uma carga de trabalho lida em arquivos de dados de um banco de dados. Essas leituras são críticas para o desempenho do sistema de DBMS.
  • A gravação nos arquivos de dados ocorre em intermitências baseadas nos pontos de verificação ou num fluxo constante. Com média de um dia, há menos gravações do que leituras. Em vez de leituras de arquivos de dados, essas gravações são assíncronas e não obstruem nenhuma transação do usuário.
  • Praticamente, não há nenhuma leitura dos arquivos de refazer ou log de transação. As exceções incluem E/Ss grandes ao executar backups de log de transações.
  • A carga principal em relação a arquivos de log de transações ou refazer são gravações. Dependendo da natureza da carga de trabalho, você pode ter E/S pequenas de 4 KB ou, em outros casos, tamanhos de E/S iguais ou superiores a 1 MB.
  • Todas as gravações devem ser persistidas em disco de forma confiável.

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

  • Nenhum
  • Ler
  • Leitura/gravação
  • Nenhum + Acelerador de Gravação, que é somente para VMs da série M do Azure
  • Leitura + Acelerador de Gravação, que é apenas para VMs da série M do Azure

Para o armazenamento Premium v1, é recomendável usar o Cache de leitura de arquivos de dados do banco de dados SAP e escolher Sem cache para os discos dos arquivos de log.

Para implantações da série M, é recomendável usar o Acelerador de Gravação do Azure somente para os discos dos arquivos de log. Para obter mais informações, restrições e implantar o Acelerador de Gravação do Azure, confira Habilitar o Acelerador de Gravação.

Para armazenamento Premium v2, disco Ultra e Azure NetApp Files, não é oferecida nenhuma opção de cache.

Discos não persistentes do Azure

As VMs do Azure oferecem discos não persistentes depois que uma VM é implantada. Se uma VM for reinicializada, todo o conteúdo nessas unidades poderá ser apagado. Portanto, consideramos que os arquivos de dados e arquivos de log e refazer de bancos de dados não devem ficar nessas unidades não persistentes sob nenhuma circunstância. Pode haver exceções para alguns bancos de dados, em que essas unidades não persistentes poderiam ser adequadas para espaços de tabela temporários e tempdb.

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

Windows nonpersisted disk Windows

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 ela 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 Linux

As VMs do Azure do 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 ela 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 do Armazenamento do Microsoft Azure

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

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

Observação

O armazenamento Premium do Azure v1 e v2, o disco Ultra e o Azure NetApp Files são o tipo recomendado de armazenamento para VMs de DBMS e discos que armazenam arquivos de banco de dados, 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 os métodos de banco de dados para habilitar a replicação de banco de dados em outra região do Azure ou zona de disponibilidade. Os métodos de banco de dados incluem SQL Server AlwaysOn, Oracle Data Guard e replicação do sistema HANA.

Resiliência de nó de VM

O Azure oferece vários SLAs diferentes para VMs. Para obter mais informações, veja a versão mais recente do SLA de máquinas virtuais. Como a camada DBMS é crítica para a disponibilidade em um sistema SAP, você precisa entender 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 de DBMS de produção com carga de trabalho do SAP é:

  • Implante duas VMs usando o tipo de implantação escolhido na mesma região do Azure.
  • Executar essas duas VMs na mesma rede virtual do Azure e ter NICs anexadas nas mesmas sub-redes.
  • Use os métodos de banco de dados para manter um modo de espera ativo com a segunda VM. Métodos podem ser SQL Server Always On, o 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 sobre a rede do Azure

Em implantações do SAP em larga escala, use o blueprint do Datacenter virtual do Azure. Use-o para sua configuração de rede virtual, bem como para atribuições de função e permissões 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 na rede virtual têm uma alocação estática do endereço IP privado. Para obter mais informações, confira Tipos de endereço IP e métodos de alocação no Azure.
  • As restrições de roteamento de e para as VMs de DBMS não são definidas com firewalls instalados nas VMs de DBMS locais. Em vez disso, o roteamento de tráfego é definido com NSG (grupos de segurança de rede).
  • Para separar e isolar o tráfego para a VM do DBMS, atribua diferentes NICs à VM. Cada NIC recebe um endereço IP diferente e a cada uma é atribuída a uma sub-rede de rede virtual diferente. Cada sub-rede tem regras de NSG diferentes. O isolamento ou a separação do tráfego de rede é uma medida para o roteamento. Não é usado a fim de definir cotas para taxa de transferência de rede.

Observação

A atribuição de endereços IP estáticos por meio do Azure significa atribuí-los a NICs virtuais individuais. Não atribua endereços IP estáticos no sistema operacional convidado a uma NIC virtual. Alguns serviços do Azure, como o Backup do Azure, dependem pelo menos do adaptador de rede virtual primário no sistema operacional convidado definido para DHCP e não para endereços IP estáticos. Para obter mais informações, confira Solucionar problemas de backup da 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 de virtuais de rede no caminho de comunicação entre o aplicativo SAP e a camada DBMS de um SAP NetWeaver, Hybris ou sistemas SAP baseados em S/4HANA. Essa restrição destina-se a questõ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 as regras de ASG (grupo de segurança de aplicativo) e NSG se elas permitirem um caminho de comunicação direto. Isso também inclui o tráfego para compartilhamentos NFS que hospedam arquivos de dados e de log refazer do DBMS.

Outros cenários em que as soluções de virtualização de rede não têm suporte estão em:

Soluções de virtualização de rede em caminhos de comunicação podem facilmente dobrar a latência de rede entre dois parceiros de comunicação. Eles também podem restringir a taxa de transferência em caminhos críticos entre a camada do aplicativo SAP e a camada do DBMS. Em alguns cenários de clientes, as soluções de virtualização de rede podem resultar na falha dos clusters do Pacemaker Linux. Estes são casos em que as comunicações entre os nós de cluster do Pacemaker do Linux se comunicam com o dispositivo SBD por meio de uma solução de virtualização de rede.

Importante

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

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

Esteja ciente de que o tráfego entre duas redes virtuais emparelhadas do Azure está sujeito a custos de transferência. Um grande volume de dados que consiste em muitos terabytes é trocado entre a camada do aplicativo SAP e a camada do DBMS. Você poderá acumular custos substanciais se a camada do aplicativo SAP e a camada do DBMS estiverem separadas entre duas redes virtuais emparelhadas do Azure.

Usar o Azure Load Balancer para redirecionar o tráfego

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

Caso ocorra um failover de nó do banco de dados, o aplicativo SAP não precisa reconfigurar. Em vez disso, as arquiteturas de aplicativos SAP mais comuns se reconectarão ao endereço IP virtual. Enquanto isso, o balanceador de carga reage ao failover de nó redirecionando o tráfego do endereço IP virtual para o segundo nó.

O Azure oferece dois SKUs de balanceador de carga diferentes: um SKU básico e um SKU padrão. Com base nas vantagens na configuração e na funcionalidade, você deve usar a SKU Standard 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 é encaminhado por meio do balanceador de carga em si.

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

Observação

Há diferenças no comportamento da SKU básica e padrão relacionadas ao acesso de endereços IP públicos. A maneira de resolver as restrições do SKU Standard para acessar endereços IP públicos é descrita no documento Conectividade de ponto de extremidade público para máquinas virtuais usando o Azure Standard Load Balancer em cenários de alta disponibilidade do SAP

Implantação do monitoramento de host

Para o uso produtivo de aplicativos SAP nas máquinas virtuais do Azure, o SAP requer a capacidade de obter dados de monitoramento dos hosts físicos em execução nas máquinas virtuais do Azure. É necessário um nível de patch do Agente de Host SAP específico que habilite essa funcionalidade no SAPOSCOL e no Agente de Host SAP. O nível de patch exato está documentado na Nota SAP 1409604.

Para obter mais informações sobre a implantação de componentes que entregam dados do host ao SAPOSCOL e ao SAP Host Agent e sobre 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óximas etapas

Para obter mais informações sobre um DBMS específico, confira: