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:
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:
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:
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.
- Solução integrada usando o Pacemaker
- Configurações alternativas ou adicionais disponíveis no Microsoft Azure Há suporte para db2 HADR (recuperação de desastre de alta disponibilidade) com o pacemaker. Há suporte para sistemas operacionais SLES e RHEL. Essa configuração permite a alta disponibilidade do IBM Db2 para SAP. Guias de implantação:
- 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: