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:

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:

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

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

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:

• Variável de desempenho do Db1 11.5
• Variáveis de ambiente e registro do DB2

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.

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

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

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

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

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.

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:

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

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

Alta disponibilidade e recuperação de desastre

Linux Pacemaker

• SLES: Alta disponibilidade do IBM Db2 LUW nas VMs do Azure no SUSE Linux Enterprise Server com o Pacemaker
• RHEL: Alta disponibilidade do IBM Db2 LUW nas VMs do Azure no Red Hat Enterprise Linux Server

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:

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