Partilhar via


Implementação em IBM DB2 do DBMS para Máquinas Virtuais do Azure para a carga de trabalho SAP

Com o Microsoft Azure, você pode migrar seu aplicativo SAP existente em execução no IBM Db2 para Linux, UNIX e Windows (LUW) para máquinas virtuais do Azure. Com o SAP no IBM Db2 for 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 for LUW estão disponíveis através do 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, consulte SAP Note 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 abordada 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 do 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
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
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 espaço de troca para Linux

Como uma leitura prévia deste documento, revise Considerações sobre a implantação do DBMS de Máquinas Virtuais do Azure para carga de trabalho SAP. Analise outros guias na carga de trabalho do SAP no Azure.

Suporte à versão IBM DB2 para Linux, UNIX e Windows

O SAP no IBM Db2 for LUW no Microsoft Azure Virtual Machine Services é suportado a partir do DB2 versão 10.5.

Para obter informações sobre produtos SAP suportados e tipos de VM do Azure (Máquinas Virtuais), consulte SAP Note 1928533.

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

Configuração do Armazenamento

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

Volumes compartilhados remotos, como os serviços do Azure nos cenários listados, NÃO são suportados para arquivos de banco de dados DB2:

  • Serviço de Arquivo do Microsoft Azure para todos os sistemas operacionais convidados.

  • Arquivos NetApp do Azure para Db2 em execução no sistema operacional convidado do Windows.

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

  • A hospedagem de dados Db2 e arquivos de log baseados no sistema operacional convidado Linux em compartilhamentos NFS hospedados no Azure NetApp Files é suportada!

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

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

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

Para obter considerações sobre desempenho, consulte também o capítulo "Considerações de segurança e desempenho de dados para diretórios de banco de dados" nos guias de instalação do SAP.

Como alternativa, você pode usar os Pools de Armazenamento do Windows, que só estão disponíveis no Windows Server 2012 e superior, conforme descrito Considerações para a implantação do DBMS de Máquinas Virtuais do Azure para carga de trabalho SAP. No Linux, você pode usar LVM ou mdadm para criar um grande dispositivo lógico em vários discos.

Para a VM do Azure M-Series, você pode reduzir por fatores a latência gravada nos logs de transações, em comparação com o desempenho do armazenamento Premium do Azure, ao usar o Azure Write Accelerator. Portanto, você deve implantar o Azure Write Accelerator para um ou mais VHDs que formam o volume para os logs de transações do DB2. Os detalhes podem ser lidos no documento Write Accelerator.

IBM Db2 LUW 11.5 liberou suporte para tamanho de setor de 4 KB. Embora você precise habilitar o uso do tamanho do setor de 4 KB com 11,5 pela configuração de configurações de db2set DB2_4K_DEVICE_SUPPORT=ON, conforme documentado em:

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

No Windows usando pools de armazenamento para caminhos de armazenamento DB2 para log_dirdiretórios e sapdata saptmp diretórios, você deve especificar um tamanho de setor de disco físico de 512 Bytes. Ao usar os Pools de Armazenamento do Windows, você deve criar os pools de armazenamento manualmente por meio da interface de linha de comando usando o parâmetro -LogicalSectorSizeDefault. Para obter mais informações, consulte New-StoragePool.

Recomendação sobre VM e estrutura de disco para implementação do IBM DB2

O IBM Db2 for SAP NetWeaver Applications é suportado em qualquer tipo de VM listado na nota de suporte SAP 1928533. As famílias de VM recomendadas para executar o banco de dados IBM DB2 são Esd_v4/Eas_v4/Es_v3 e M/M_v2-series para grandes bancos de dados de vários terabytes. O desempenho de gravação em disco do 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 do SAP em implantações do DB2, de pequeno a x-grande.

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 do Azure v1. O SSD Premium v2 e o disco Azure Ultra também são totalmente suportados com o IBM DB2 e podem ser usados para implementações. Use os valores de capacidade, taxa de transferência de intermitência e IOPS de intermitência para definir a configuração de disco Ultra ou SSD Premium v2. Você pode limitar as IOPS para o /db2/<SID>/log_dir em cerca de 5000 IOPS. Ajuste a taxa de transferência e o IOPS à 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: exemplo Solution Manager

Tamanho da VM / Exemplos Ponto de montagem DB2 Disco Premium do Azure # de Discos IOPS Através de-
colocar [MB/s]
Tamanho [GB] IOPS de intermitência Explosão através-
colocar [GB]
Tamanho da risca Colocação em cache
vCPU: 4 /db2 P6 1 240 50 64 3500 170
RAM: ~32 GiB /db2/<SID>/sapdata P10 2 1,000 200 256 7000 340 256
KB
ReadOnly
E4, alínea d)s_v5 /db2/<SID>/saptmp P6 1 240 50 128 3500 170
E4, alínea d)as_v5 /db2/<SID>/log_dir P6 2 480 100 128 7000 340 64
KB
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3500 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 # de Discos IOPS Através de-
colocar [MB/s]
Tamanho [GB] IOPS de intermitência Explosão através-
colocar [GB]
Tamanho da risca Colocação em cache
vCPU: 16 /db2 P6 1 240 50 64 3500 170
RAM: ~128 GiB /db2/<SID>/sapdata P15 4 4,400 500 1.024 14 000 680 256 KB ReadOnly
E16, alínea d)s_v5 /db2/<SID>/saptmp P6 2 480 100 128 7000 340 128 KB
E16, alínea d)as_v5 /db2/<SID>/log_dir P15 2 2200 250 512 7000 340 64
KB
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3500 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 # de Discos IOPS Através de-
colocar [MB/s]
Tamanho [GB] IOPS de intermitência Explosão através-
colocar [GB]
Tamanho da risca Colocação em cache
vCPU: 32 /db2 P6 1 240 50 64 3500 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 7000 340 128 KB
E32, alínea d)as_v5 /db2/<SID>/log_dir P20 2 4,600 300 1.024 7000 340 64
KB
M32ls /db2/<SID>/offline_log_dir P15 1 1100 125 256 3500 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 # de Discos IOPS Através de-
colocar [MB/s]
Tamanho [GB] IOPS de intermitência Explosão através-
colocar [GB]
Tamanho da risca Colocação em cache
vCPU: 64 /db2 P6 1 240 50 64 3500 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 2200 250 512 7000 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 2300 150 512 3500 170

Grande sistema SAP de vários terabytes: tamanho do banco de dados 2 TB+: sistema Global Business Suite

Especialmente para esses sistemas maiores, é importante avaliar a infraestrutura na qual o sistema está sendo executado atualmente e os dados de consumo de recursos desses sistemas para encontrar a melhor correspondência entre a infraestrutura e a configuração de computação e armazenamento do Azure.

Nome / Tamanho da VM Ponto de montagem DB2 Disco Premium do Azure # de Discos IOPS Através de-
colocar [MB/s]
Tamanho [GB] IOPS de intermitência Explosão através-
colocar [GB]
Tamanho da risca Colocação em cache
vCPU: =>128 /db2 P10 1 500 100 128 3500 170
Memória RAM: =>2.048 GiB /db2/<SID>/sapdata P40 4 30 000 1000 8.192 30 000 1000 256 KB ReadOnly
M128s_v2 /db2/<SID>/saptmp P20 2 4,600 300 1.024 7000 340 128 KB
M176s_2_v3 /db2/<SID>/log_dir P30 4 20.000 800 4.096 20.000 800 64
KB
Escrever-
Acelerador
M176s_3_v3,
M176s_4_v3
/db2/<SID>/offline_log_dir P30 1 5.000 200 1.024 5.000 200

Usando arquivos NetApp do Azure

O uso de volumes NFS v4.1 baseados em Arquivos NetApp do Azure (ANF) é suportado com o IBM DB2, hospedado no SO convidado Suse ou Red Hat Linux. Você deve criar pelo menos quatro volumes diferentes que listam como:

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

Um quinto volume potencial pode ser um volume ANF que você usa para backups de longo prazo que você usa para criar instantâneos e armazenar os instantâneos no repositório de Blob do Azure.

A configuração pode ser mostrada aqui:

Exemplo de configuração do DB2 usando ANF

A camada de desempenho e o tamanho dos volumes hospedados ANF devem ser escolhidos com base nos requisitos de desempenho. No entanto, recomendamos o nível de desempenho Ultra para os dados e o volume de log. Não há suporte para misturar tipos de armazenamento em bloco e armazenamento compartilhado para o volume de dados e log.

A partir das opções de montagem, a montagem desses volumes pode ser semelhante (você precisa substituir <SID> e <sid> pelo SID do seu 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

Nota

A opção de montagem rígida e sincronização são necessárias

Cópia de segurança/Restauro

A funcionalidade de backup/restauração para IBM Db2 for LUW é suportada da mesma forma que nos sistemas operacionais Windows Server padrão e Hyper-V.

Certifique-se de ter uma estratégia de backup de 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 um papel significativo em VMs com até oito threads de CPU. Portanto, pode-se supor:

  • 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 será o impacto da compactação de backup
  • Quanto menos destinos (Stripe Directories, discos) para gravar o backup, menor será a taxa de transferência

Para aumentar o número de destinos para gravar, duas opções podem ser usadas/combinadas dependendo de suas necessidades:

  • Distribuição do volume de destino de backup em vários discos para melhorar a taxa de transferência de IOPS nesse volume distribuído
  • Usando mais de um diretório de destino para gravar o backup em

Nota

O db2 no Windows não suporta a tecnologia VSS do Windows. Como resultado, o backup de VM consistente do aplicativo do Serviço de Backup do Azure não pode ser aproveitado para VMs nas quais o DBMS DB2 é implantado.

Elevada disponibilidade e Recuperação após desastre

Marcapasso Linux

Importante

Para DB2 versões 11.5.6 e superiores, é altamente recomendável a solução integrada usando Pacemaker da IBM.

Servidor de Cluster do Windows

O WSFC (Cluster de Failover do Windows Server), também conhecido como Microsoft Cluster Server (MSCS), não é suportado.

A recuperação de desastres de alta disponibilidade (HADR) do DB2 é suportada. Se as máquinas virtuais da configuração HA tiverem resolução de nome de trabalho, a instalação no Azure não será diferente de nenhuma configuração feita localmente. Não é recomendado confiar apenas na resolução IP.

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

Redes Aceleradas

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. Considere também as recomendações feitas em Considerações para a implantação do DBMS de Máquinas Virtuais do Azure para carga de trabalho SAP.

Especificidades para implantações Linux

Desde que a cota IOPS atual por disco seja suficiente, é possível armazenar todos os arquivos de banco de dados em um único 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 um único VHD do Azure não for suficiente, você poderá usar LVM (Gerenciador de Volume Lógico) ou MDADM conforme descrito no documento Considerações para a implantação de DBMS de Máquinas Virtuais do Azure para carga de trabalho SAP para criar um dispositivo lógico grande em vários discos. Para os discos que contêm os caminhos de armazenamento DB2 para seus sapdata diretórios e saptmp , você deve especificar um tamanho de setor de disco físico de 512 KB.

Outro

Todas as outras áreas gerais, como Conjuntos de Disponibilidade do Azure ou monitoramento SAP, também se aplicam a implementações de VMs com o Banco de Dados IBM. Essas áreas gerais que descrevemos em Considerações para a implantação do DBMS de Máquinas Virtuais do Azure para carga de trabalho SAP.

Próximos passos

Leia o artigo: