Compartilhar via


Implantação do DBMS de Máquinas Virtuais do IBM Db2 Azure para carga de trabalho do SAP

Com o Microsoft Azure, você pode migrar seu aplicativo SAP existente em execução no IBM Db2 para LUW (Linux, UNIX e Windows) para máquinas virtuais do Azure. Com o SAP no IBM Db2 para LUW, os administradores e desenvolvedores ainda podem usar as mesmas ferramentas de desenvolvimento e administração que estão disponíveis localmente. Informações gerais sobre como executar o SAP Business Suite no IBM Db2 para LUW estão disponíveis no SAP Community Network (SCN) no SAP no IBM Db2 para Linux, UNIX e Windows.

Para obter mais informações e atualizações sobre o SAP no Db2 para LUW no Azure, confira a Nota SAP 2233094.

Há vários artigos para a carga de trabalho do SAP no Azure. Recomendamos começar com Introdução ao SAP em VMs do Azure e, em seguida, ler sobre outras áreas de interesse.

As seguintes notas SAP estão relacionadas ao SAP no Azure em relação à área de abordados neste documento:

Número da observação Title
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 aprimorado do Azure para SAP
2178632 Métricas-chave de monitoramento para SAP no Microsoft Azure
1409604 Virtualização no Windows: Monitoramento Avançado
2191498 SAP no Linux com o Azure: Monitoramento Avançado
2233094 DB6: Aplicativos SAP no Azure usando o IBM DB2 para Linux, UNIX e Windows - informações adicionais
2243692 Linux na VM (IaaS) do Microsoft Azure: Problemas de licença do SAP
1984787 SUSE Linux Enterprise Server 12: Notas de instalação
2002167 Red Hat Enterprise Linux 7.x: Instalação e atualização
1597355 Recomendação de troca de espaço para Linux

Como uma leitura preliminar para este documento, confira Considerações para implantação de DBMS de Máquinas Virtuais do Azure para a carga de trabalho SAP. Examine outros guias sobre a carga de trabalho do SAP no Azure.

Suporte de versão do IBM Db2 para Linux, UNIX e Windows

O SAP no IBM Db2 para LUW nos serviços de máquina virtual do Microsoft Azure é compatível desde a versão 10.5 do Db2.

Para obter informações sobre os tipos de VM (Máquina Virtual) do Azure e produtos SAP com suporte, consulte a Nota SAP 1928533.

Diretrizes de configuração do IBM Db2 para Linux, UNIX e Windows para instalações do SAP em VMs do Azure

Configuração de armazenamento

Para obter uma visão geral dos tipos de armazenamento do Azure para carga de trabalho do SAP, consulte o artigo Tipos de armazenamento do Azure para carga de trabalho do SAP Todos os arquivos de banco de dados precisam ser armazenados em discos montados do armazenamento de blocos do Azure (Windows: NTFS, Linux: XFS, com suporte a partir da versão Db2 11.1 ou ext3).

Volumes compartilhados remotos como os serviços do Azure nos cenários listados NÃO têm suporte para arquivos de banco de dados Db2:

Volumes compartilhados remotos como os serviços do Azure nos cenários listados têm suporte para arquivos de banco de dados Db2:

  • Há suporte para hospedagem de arquivos de log e dados do Db2 com base no sistema operacional convidado do Linux em compartilhamentos NFS hospedados no Azure NetApp Files!

Se você estiver usando discos baseados no Armazenamento de Blobs de Páginas do Azure ou Managed Disks, as instruções em Considerações para implantação do DBMS de Máquinas Virtuais do Azure para carga de trabalho do SAP também se aplicam a implantações com o Sistema de Gerenciamento de Banco de Dados (DBMS) do Db2.

Conforme explicado anteriormente na parte geral do documento, existem cotas na taxa de transferência de operações de E/S por segundo (IOPS) para discos do Azure. As cotas exatas dependem do tipo de VM usado. Uma lista de tipos VM com suas cotas pode ser encontrada aqui (Linux) e aqui (Windows).

Desde que a cota de IOPS por disco atual seja suficiente, é possível armazenar todos os arquivos de banco de dados no único disco montado. Onde você sempre deve separar os arquivos de dados e arquivos de log de transações em discos/VHDs diferentes.

Para considerações sobre o desempenho, consulte também o capítulo “Data Safety and Performance Considerations for Database Directories” (Considerações sobre segurança de dados e desempenho para diretórios de banco de dados) nos guias de instalação SAP.

Como alternativa, você pode usar Pools de Armazenamento do Windows (disponíveis apenas no Windows Server 2012 e superior) ou a divisão do Windows para o Windows 2008 R2, conforme descrito em Considerações para implantação de DBMS de máquinas virtuais do Azure para a carga de trabalho SAP. No Linux, você pode usar LVM ou mdadm para criar um dispositivo lógico grande em vários discos.

Para a VM da série M do Azure, a latência de gravação nos logs de transação pode ser reduzida por fatores, comparados ao desempenho do armazenamento Premium do Azure, ao usar o Acelerador de Gravação do Azure. Portanto, você deve implantar o Acelerador de Gravação do Azure para um ou mais VHDs que formam o volume para os logs de transação do Db2. Detalhes podem ser lidos no documento Acelerador de Gravação.

O IBM DB2 LUW 11.5 lançou o suporte para o tamanho de setor de 4 KB. Mas é necessário habilitar o uso do tamanho de setor 4 KB com 11,5 pela definição de configuração DB2_4K_DEVICE_SUPPORT=ON do db2set, conforme a documentação em:

Para versões mais antigas do Db2, é preciso usar um tamanho de setor de 512 bytes. Os discos SSD Premium são nativos de 4 KB e têm emulação de 512 bytes. O Ultra Disk usa o tamanho de setor de 4 KB por padrão. Você pode habilitar o tamanho de setor de 512 bytes durante a criação de um disco Ultra. Os detalhes estão disponíveis em usando os ultra discos do Azure. Esse tamanho de setor de 512 bytes é um pré-requisito para as versões do IBM Db2 LUW inferiores a 11.5.

No Windows, usando pools de armazenamento para caminhos de armazenamento Db2 para diretórios log_dir, sapdata e saptmp, você precisa especificar um tamanho de setor de disco físico de 512 bytes. Ao usar Pools de Armazenamento do Windows, você deve criá-los manualmente por meio da interface de linha de comando usando o parâmetro -LogicalSectorSizeDefault. Para obter mais informações, confira New-StoragePool.

Recomendação sobre estrutura de VM e disco para implantação do IBM Db2

Os aplicativos IBM DB2 para SAP NetWeaver têm suporte em qualquer tipo de VM listado na nota de suporte do SAP 1928533. As famílias de VM recomendadas para executar o banco de dados IBM Db2 são as séries Esd_v4/Eas_v4/Es_v3 e M/M_v2 para grandes bancos de dados multi-terabyte. O desempenho de gravação do disco de log de transações IBM Db2 pode ser melhorado ativando o Acelerador de Gravação da série M.

A seguir está uma configuração de linha de base para vários tamanhos e usos de implantações do SAP em Db2 de pequenas a extra grandes.

Importante

Os tipos de VM listados abaixo são exemplos que atendem aos critérios de vCPU e memória de cada uma das categorias. A configuração de armazenamento é baseada no Armazenamento Premium v1 do Azure. O SSD Premium v2 e o disco Ultra do Azure também têm suporte total com o IBM Db2 e podem ser usados para implantações. Use os valores para capacidade, taxa de transferência de intermitência e IOPS de intermitência para definir a configuração do Disco Ultra ou do SSD Premium v2. Você pode limitar o IOPS para /db2/ <SID> /log_dir em cerca de 5.000 IOPS. Ajuste a taxa de transferência e o IOPS para a carga de trabalho específica se essas recomendações de linha de base não atenderem aos requisitos

Sistema SAP extra pequeno: tamanho do banco de dados 50-200 GB: Gerenciador de soluções de exemplo

Tamanho da VM/Exemplos Ponto de montagem Db2 Disco Premium do Azure Nº de discos IOPS Até-
put [MB/s]
Tamanho (GB) IOPS de intermitência Intermitência até-
put [GB]
Tamanho da distribuição Cache
vCPU: 4 /db2 P6 1 240 50 64 3\.500 170
RAM: ~32 GiB /db2/<SID>/sapdata P10 2 1,000 200 256 7.000 340 256
KB
ReadOnly (somente-leitura)
E4(d)s_v5 /db2/<SID>/saptmp P6 1 240 50 128 3\.500 170
E4(d)as_v5 /db2/<SID>/log_dir P6 2 480 100 128 7.000 340 64
KB
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3\.500 170

Sistema SAP pequeno: tamanho do banco de dados 200-750 GB: Small Business Suite

Tamanho da VM/Exemplos Ponto de montagem Db2 Disco Premium do Azure Nº de discos IOPS Até-
put [MB/s]
Tamanho (GB) IOPS de intermitência Intermitência até-
put [GB]
Tamanho da distribuição Cache
vCPU: 16 /db2 P6 1 240 50 64 3\.500 170
RAM: ~128 GiB /db2/<SID>/sapdata P15 4 4\.400 500 1.024 14.000 680 256 KB ReadOnly
E16(d)s_v5 /db2/<SID>/saptmp P6 2 480 100 128 7.000 340 128 KB
E16(d)as_v5 /db2/<SID>/log_dir P15 2 2.200 250 512 7.000 340 64
KB
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3\.500 170

Sistema SAP médio: tamanho do banco de dados 500-1000 GB: Small Business Suite

Tamanho da VM/Exemplos Ponto de montagem Db2 Disco Premium do Azure Nº de discos IOPS Até-
put [MB/s]
Tamanho (GB) IOPS de intermitência Intermitência até-
put [GB]
Tamanho da distribuição Cache
vCPU: 32 /db2 P6 1 240 50 64 3\.500 170
RAM: ~256 GiB /db2/<SID>/sapdata P30 2 10.000 400 2.048 10.000 400 256 KB ReadOnly
E32(d)s_v5 /db2/<SID>/saptmp P10 2 1,000 200 256 7.000 340 128 KB
E32(d)as_v5 /db2/<SID>/log_dir P20 2 4,600 300 1.024 7.000 340 64
KB
M32ls /db2/<SID>/offline_log_dir P15 1 1.100 125 256 3\.500 170

Sistema SAP grande: tamanho do banco de dados 750-2000 GB: Business Suite

Tamanho da VM/Exemplos Ponto de montagem Db2 Disco Premium do Azure Nº de discos IOPS Até-
put [MB/s]
Tamanho (GB) IOPS de intermitência Intermitência até-
put [GB]
Tamanho da distribuição Cache
vCPU: 64 /db2 P6 1 240 50 64 3\.500 170
RAM: ~512 GiB /db2/<SID>/sapdata P30 4 20.000 800 4.096 20.000 800 256 KB ReadOnly
E64(d)s_v5 /db2/<SID>/saptmp P15 2 2.200 250 512 7.000 340 128 KB
E64(d)as_v5 /db2/<SID>/log_dir P20 4 9\.200 600 2.048 14.000 680 64
KB
M64ls /db2/<SID>/offline_log_dir P20 1 2\.300 150 512 3\.500 170

Sistema grande de SAP de múltiplos terabytes: tamanho do banco de dados 2 TB +: Global Business Suite System

Especialmente para sistemas maiores, é importante avaliar a infraestrutura em que o sistema está sendo executado no momento e os dados de consumo de recursos desses sistemas para encontrar a melhor combinação de infraestrutura e configuração de computação e armazenamento do Azure.

Nome/tamanho da VM Ponto de montagem Db2 Disco Premium do Azure Nº de discos IOPS Até-
put [MB/s]
Tamanho (GB) IOPS de intermitência Intermitência até-
put [GB]
Tamanho da distribuição Cache
vCPU: =>128 /db2 P10 1 500 100 128 3\.500 170
RAM: =>2.048 GiB /db2/<SID>/sapdata P40 4 30,000 1.000 8.192 30,000 1.000 256 KB ReadOnly
M128s_v2 /db2/<SID>/saptmp P20 2 4,600 300 1.024 7.000 340 128 KB
M176s_2_v3 /db2/<SID>/log_dir P30 4 20.000 800 4.096 20.000 800 64
KB
Gravar-
Acelerador
M176s_3_v3,
M176s_4_v3
/db2/<SID>/offline_log_dir P30 1 5\.000 200 1.024 5\.000 200

Uso do Azure NetApp Files

O uso de volumes NFS v4.1 baseados no ANF (Azure NetApp Files) tem suporte com o IBM Db2, hospedado no Suse ou no sistema operacional convidado do Red Hat Linux. Você deve criar pelo menos quatro volumes diferentes como a lista abaixo:

  • Volume compartilhado para saptmp1, sapmnt, usr_sap, <sid>_home, db2<sid>_home e db2_software
  • Um volume de dados para sapdata1 a sapdatan
  • Um volume de log para o diretório de log de restauração
  • Um volume para os backups e arquivos de log

Um quinto volume possível pode ser um ANF que você usa para backups de prazo mais longo que são usados para fazer e armazenar instantâneos no Armazenamento de Blobs do Azure.

A configuração pode ser como mostrado aqui:

Exemplo de configuração do Db2 usando o ANF

O nível de desempenho e o tamanho dos volumes hospedados pelo ANF devem ser escolhidos com base nos requisitos de desempenho. No entanto, é recomendado usar o nível de desempenho Ultra para os dados e o volume de log. Não há suporte para mesclar o armazenamento em bloco e os tipos de armazenamento compartilhado para os dados e o volume de log.

No caso das opções de montagem, a montagem desses volumes pode ser semelhante ao seguinte (você precisa substituir <SID> e <sid> pelo SID do sistema SAP):

vi /etc/idmapd.conf   
 # Example
 [General]
 Domain = defaultv4iddomain.com
 [Mapping]
 Nobody-User = nobody
 Nobody-Group = nobody

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2shared /mnt 
mkdir -p /db2/Software /db2/AN1/saptmp /usr/sap/<SID> /sapmnt/<SID> /home/<sid>adm /db2/db2<sid> /db2/<SID>/db2_software
mkdir -p /mnt/Software /mnt/saptmp  /mnt/usr_sap /mnt/sapmnt /mnt/<sid>_home /mnt/db2_software /mnt/db2<sid>
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2data /mnt
mkdir -p /db2/AN1/sapdata/sapdata1 /db2/AN1/sapdata/sapdata2 /db2/AN1/sapdata/sapdata3 /db2/AN1/sapdata/sapdata4
mkdir -p /mnt/sapdata1 /mnt/sapdata2 /mnt/sapdata3 /mnt/sapdata4
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2log /mnt 
mkdir /db2/AN1/log_dir
mkdir /mnt/log_dir
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2backup /mnt
mkdir /db2/AN1/backup
mkdir /mnt/backup
mkdir /db2/AN1/offline_log_dir /db2/AN1/db2dump
mkdir /mnt/offline_log_dir /mnt/db2dump
umount /mnt

Observação

As opções de montagem “hard” e “sync” são necessárias

Backup/restauração

A funcionalidade de backup/restauração para o IBM Db2 para LUW é compatível da mesma maneira que no Hyper-V e em sistemas operacionais Windows Server standard.

Confira se você tem uma estratégia de backup do banco de dados válida em vigor.

Como em implantações bare-metal, o desempenho de backup/restauração depende de quantos volumes podem ser lidos em paralelo e qual pode ser a taxa de transferência desses volumes. Além disso, o consumo de CPU usado pela compactação de backup pode desempenhar uma função significativa nas VMs com até oito threads por CPU. Portanto, é possível supor que:

  • Quanto menor o número de discos usados para armazenar os dispositivos de banco de dados, menor é a taxa de transferência geral na leitura
  • Quanto menor o número de threads de CPU na VM, mais severo é o impacto da compactação de backup
  • Quanto menos destinos (Diretórios de Faixa, discos) nos quais gravar o backup, menor é a taxa de transferência

Para aumentar o número de destinos nos quais gravar, é possível usar/combinar duas opções dependendo das suas necessidades:

  • Como dividir o volume de destino de backup em vários discos para melhorar a taxa de transferência de IOPS no volume dividido
  • Usando mais de um diretório de destino no qual gravar o backup

Observação

O Db2 no Windows não é compatível com a tecnologia VSS do Windows. Como resultado, o backup VM consistente de aplicativo do serviço de Backup do Azure não pode ser aproveitado para VMs DBMS Db2 no qual é implantado.

Alta disponibilidade e recuperação de desastre

Linux Pacemaker

Importante

Para as versões Db2 11.5.6 e superiores, é altamente recomendável o uso de uma solução integrada usando o Pacemaker da IBM.

Windows Cluster Server

Não há suporte para o Cluster de Failover do Windows Server (WSFC), também conhecido como Microsoft Cluster Server (MSCS).

A HADR (alta disponibilidade e recuperação de desastre) do Db2 é compatível. Se as máquinas virtuais da configuração de HA tiverem uma resolução de nome funcionando, a configuração no Azure não será diferente de nenhuma configuração feita localmente. Não é recomendável confiar apenas na resolução de IP.

Não use a replicação geográfica para as contas de armazenamento que armazenam os discos de banco de dados. Para obter mais informações, consulte o documento Considerações para implantação de DBMS de Máquinas Virtuais do Azure para a carga de trabalho SAP.

Rede Acelerada

Para implantações do Db2 no Windows, é altamente recomendável usar a funcionalidade do Azure de Rede Acelerada, conforme descrito no documento Rede Acelerada do Azure. Também considere as recomendações feitas em Considerações para implantação de DBMS de Máquinas Virtuais do Azure para a carga de trabalho SAP.

Informações específicas para implantações do Linux

Desde que a cota de IOPS por disco atual seja suficiente, é possível armazenar todos os arquivos de banco de dados em apenas um disco. Considerando que você sempre deve separar os arquivos de dados e os arquivos de log de transações em discos diferentes.

Se a taxa de transferência de IOPS ou E/S de apenas um VHD do Azure não for suficiente, você pode usar o LVM (Logical Volume Manager) ou o MDADM, conforme descrito no documento Considerações de implantação de DBMS de máquinas virtuais do Azure para cargas de trabalho SAP para criar um grande dispositivo lógico em vários discos. Para os discos que contêm os caminhos de armazenamento Db2 para seus diretórios sapdata e saptmp, você deve especificar um tamanho de setor do disco físico de 512 KB.

Outro

Todas as outras áreas gerais, como o monitoramento do SAP ou Conjuntos de Disponibilidade do Azure, se aplicam para implantações de VMs com o Banco de Dados IBM. Estas áreas gerais são descritas em Considerações para implantação de DBMS de máquinas virtuais do Azure para a carga de trabalho SAP.

Próximas etapas

Leia o artigo: