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:
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.
- Solução integrada com Pacemaker
- Há suporte para configurações alternativas ou adicionais disponíveis no Microsoft Azure DB2 de recuperação de desastres de alta disponibilidade (HADR) com marcapasso. Os sistemas operacionais SLES e RHEL são suportados. Essa configuração permite alta disponibilidade do IBM Db2 for SAP. Guias de implantação:
- SLES: Alta disponibilidade do IBM Db2 LUW em VMs do Azure no SUSE Linux Enterprise Server com Pacemaker
- RHEL: Alta disponibilidade do IBM Db2 LUW em VMs do Azure no Red Hat Enterprise Linux Server
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: