Guia de implantação da plataforma SAP BusinessObjects BI para Linux no Azure

  • Artigo

Este artigo descreve a estratégia para implantar a plataforma SAP BusinessObjects BI (BOBI) no Azure para Linux. Neste exemplo, você configura duas máquinas virtuais com discos gerenciados de unidade de estado sólido (SSD) premium como o diretório de instalação. Você usa o Banco de Dados do Azure para MySQL para seu banco de dados CMS e compartilha Arquivos NetApp do Azure para seu servidor de repositório de arquivos em ambos os servidores. Em ambas as máquinas virtuais, você instala o aplicativo Web Java Tomcat padrão e o aplicativo da plataforma BI juntos. Para balancear a carga das solicitações do usuário, use o Gateway de Aplicativo do Azure com recursos nativos de descarregamento de TLS/SSL.

Esse tipo de arquitetura é eficaz para pequenas implantações ou ambientes que não sejam de produção. Para grandes implantações ou ambientes de produção, você pode ter hosts separados para seu aplicativo Web. Você também pode ter vários hosts de aplicativos BOBI, permitindo que o servidor processe mais informações.

Diagram of the SAP BOBI deployment on Azure for Linux

Aqui está a versão do produto e o layout do sistema de arquivos para este exemplo:

  • Plataforma SAP BusinessObjects 4.3
  • SUSE Linux Enterprise Server 12 SP5
  • Banco de Dados do Azure para MySQL (versão: 8.0.15)
  • MySQL C API Connector - libmysqlclient (Versão: 6.1.11)
Sistema de ficheiros Descrição Tamanho (GB) Proprietário Agrupar Armazenamento
/usr/sap O sistema de arquivos para instalação da instância do SAP BOBI, o aplicativo Web Tomcat padrão e os drivers de banco de dados (se necessário). Diretrizes de dimensionamento SAP bl1adm Sapsys Disco premium gerenciado - SSD
/usr/sap/frsinput O diretório mount é para os arquivos compartilhados em todos os hosts BOBI que serão usados como o diretório do repositório de arquivos de entrada. Necessidade do negócio bl1adm Sapsys Azure NetApp Files
/usr/sap/frsoutput O diretório mount é para os arquivos compartilhados em todos os hosts BOBI que serão usados como o diretório do repositório de arquivos de saída Necessidade do negócio bl1adm Sapsys Azure NetApp Files

Importante

Embora a configuração da plataforma SAP BusinessObjects seja explicada usando os Arquivos NetApp do Azure, você pode usar NFS nos Arquivos do Azure como o repositório de arquivos de entrada e saída.

Implantar a máquina virtual Linux por meio do portal do Azure

Nesta seção, você cria duas máquinas virtuais com a imagem do sistema operacional Linux para a plataforma SAP BOBI. As etapas de alto nível para criar as máquinas virtuais são as seguintes:

  1. Crie um grupo de recursos.

  2. Crie uma rede virtual.

    • Não use uma única sub-rede para todos os serviços do Azure na implantação da plataforma SAP BI. Com base na arquitetura da plataforma SAP BI, você precisa criar várias sub-redes. Nesta implantação, você cria três sub-redes: uma para cada aplicativo, o repositório de arquivos e o Application Gateway.
    • No Azure, o Gateway de Aplicativo e os Arquivos NetApp do Azure devem estar sempre em uma sub-rede separada. Para obter mais informações, consulte Gateway de Aplicativo do Azure e Diretrizes para planejamento de rede do Azure NetApp Files.

  3. Selecione as opções de disponibilidade adequadas, dependendo da sua configuração de sistema preferida dentro de uma região do Azure, quer envolva a abrangência entre zonas, resida em uma única zona ou opere em uma região sem zona.

  4. Crie a máquina virtual 1, chamada (azusbosl1).

  5. Crie a máquina virtual 2, chamada (azusbosl2).

  6. Adicione um disco SSD premium. Você o usará como diretório de instalação do SAP BOBI.

Provisionar arquivos NetApp do Azure

Antes de continuar com a configuração dos Arquivos NetApp do Azure, familiarize-se com a documentação dos Arquivos NetApp do Azure.

Os Arquivos NetApp do Azure estão disponíveis em várias regiões do Azure. Verifique se a região do Azure selecionada oferece Arquivos NetApp do Azure.

Use a disponibilidade dos Arquivos NetApp do Azure por Região do Azure para verificar a disponibilidade dos Arquivos NetApp do Azure por região.

Implantar recursos do Azure NetApp Files

As instruções a seguir pressupõem que você já implantou sua rede virtual do Azure. Os recursos dos Arquivos NetApp do Azure e as VMs onde os recursos dos Arquivos NetApp do Azure serão montados devem ser implantados na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas.

  1. Crie uma conta do Azure NetApp Files na região do Azure selecionada.

  2. Configure um pool de capacidade de Arquivos NetApp do Azure. A arquitetura da plataforma SAP BI apresentada neste artigo usa um único pool de capacidade do Azure NetApp Files no nível de serviço Premium. Para o SAP BI File Repository Server no Azure, recomendamos o uso de um Nível de serviço Azure NetApp Files Premium ou Ultra.

  3. Delegue uma sub-rede aos Arquivos NetApp do Azure.

  4. Implante volumes de Arquivos NetApp do Azure seguindo as instruções em Criar um volume NFS para Arquivos NetApp do Azure.

    Você pode implantar os volumes como NFSv3 e NFSv4.1, porque ambos os protocolos são suportados para a plataforma SAP BOBI. Implante os volumes em suas respetivas sub-redes do Azure NetApp Files. Os endereços IP dos volumes dos Arquivos NetApp do Azure são atribuídos automaticamente.

Lembre-se de que os recursos dos Arquivos NetApp do Azure e as VMs do Azure devem estar na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas. Por exemplo, azusbobi-frsinput e azusbobi-frsoutput são os nomes de volume e nfs://10.31.2.4/azusbobi-frsinput e nfs://10.31.2.4/azusbobi-frsoutput são os caminhos de arquivo para os volumes de Arquivos NetApp do Azure.

  • Volume azusbobi-frsinput (nfs://10.31.2.4/azusbobi-frsinput)
  • Volume azusbobi-frsoutput (nfs://10.31.2.4/azusbobi-frsoutput)

Considerações importantes

Ao criar seu servidor de repositório de arquivos da plataforma Azure NetApp Files for SAP BOBI, esteja ciente das seguintes considerações:

  • O pool de capacidade mínima é de 4 tebibytes (TiB). O tamanho do pool de capacidade pode ser aumentado em incrementos de 1 TiB.
  • O tamanho mínimo do volume é de 100 gibibytes (GiB).
  • Os Arquivos NetApp do Azure e todas as máquinas virtuais onde os volumes dos Arquivos NetApp do Azure serão montados devem estar na mesma rede virtual do Azure ou em redes virtuais emparelhadas na mesma região. O acesso aos Arquivos NetApp do Azure por emparelhamento de rede virtual na mesma região é suportado. O acesso aos Arquivos NetApp do Azure por emparelhamento global não é suportado no momento.
  • A rede virtual selecionada deve ter uma sub-rede delegada aos Arquivos NetApp do Azure.
  • A taxa de transferência e as características de desempenho de um volume de Arquivos NetApp do Azure são uma função da cota de volume e do nível de serviço, conforme documentado em Nível de serviço para Arquivos NetApp do Azure. Ao dimensionar os volumes do SAP Azure NetApp, certifique-se de que a taxa de transferência resultante atenda aos requisitos do aplicativo.
  • Com a política de exportação de Arquivos NetApp do Azure, você pode controlar os clientes permitidos, o tipo de acesso (por exemplo, leitura-gravação ou somente leitura).
  • O recurso Arquivos NetApp do Azure ainda não reconhece zona. Atualmente, o recurso não é implantado em todas as zonas de disponibilidade em uma região do Azure. Esteja ciente das possíveis implicações de latência em algumas regiões do Azure.
  • Os volumes de Arquivos NetApp do Azure podem ser implantados como volumes NFSv3 ou NFSv4.1. Ambos os protocolos são suportados para os aplicativos da plataforma SAP BI.

Configurar sistemas de arquivos em servidores Linux

As etapas nesta seção usam o seguinte prefixo:

[R]: O passo aplica-se a todos os anfitriões.

Formatar e montar o sistema de arquivos SAP

  1. [A] Liste todos os discos anexados.

    sudo lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   30G  0 disk
├─sda1   8:1    0    2M  0 part
├─sda2   8:2    0  512M  0 part /boot/efi
├─sda3   8:3    0    1G  0 part /boot
└─sda4   8:4    0 28.5G  0 part /
sdb      8:16   0   32G  0 disk
└─sdb1   8:17   0   32G  0 part /mnt
sdc      8:32   0  128G  0 disk
sr0     11:0    1  628K  0 rom  
# Premium SSD of 128 GB is attached to virtual machine, whose device name is sdc

  2. [A] Formate o dispositivo de bloco para /usr/sap.

    sudo mkfs.xfs /dev/sdc

  3. [A] Crie o diretório mount.

    sudo mkdir -p /usr/sap

  4. [A] Obtenha o UUID do dispositivo de bloco.

    sudo blkid

# It will display information about block device. Copy UUID of the formatted block device

/dev/sdc: UUID="0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b" TYPE="xfs"

  5. [A] Mantenha a entrada de montagem do sistema de arquivos em /etc/fstab.

    sudo echo "UUID=0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b /usr/sap xfs defaults,nofail 0 2" >> /etc/fstab

  6. [A] Monte o sistema de arquivos.

    sudo mount -a

sudo df -h

Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.9G  8.0K  7.9G   1% /dev
tmpfs                          7.9G   82M  7.8G   2% /run
tmpfs                          7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/sda4                       29G  1.8G   27G   6% /
tmpfs                          1.6G     0  1.6G   0% /run/user/1000
/dev/sda3                     1014M   87M  928M   9% /boot
/dev/sda2                      512M  1.1M  511M   1% /boot/efi
/dev/sdb1                       32G   49M   30G   1% /mnt
/dev/sdc                       128G   29G  100G  23% /usr/sap

Monte o volume de Arquivos NetApp do Azure

  1. [A] Criar diretórios de montagem.

    sudo mkdir -p /usr/sap/frsinput
sudo mkdir -p /usr/sap/frsoutput

  2. [A] Configure o sistema operacional cliente para suportar a montagem NFSv4.1 (aplicável somente se estiver usando NFSv4.1).

    Se você estiver usando volumes de Arquivos NetApp do Azure com o protocolo NFSv4.1, execute a seguinte configuração em todas as VMs em que os volumes NFSv4.1 dos Arquivos NetApp do Azure precisam ser montados.

    Nesta etapa, você precisa verificar as configurações de domínio NFS. Verifique se o domínio está configurado como o domínio padrão dos Arquivos NetApp do Azure (defaultv4iddomain.com) e se o mapeamento está definido como nobody.

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

    Importante

    Certifique-se de definir o domínio NFS em /etc/idmapd.conf na VM para corresponder à configuração de domínio padrão nos Arquivos NetApp do Azure (defaultv4iddomain.com). Se houver uma incompatibilidade, as permissões para arquivos nos volumes de Arquivos NetApp do Azure montados nas VMs serão exibidas como nobody.

    Verificar nfs4_disable_idmapping. Deve ser definido como Y. Para criar a estrutura de diretórios onde nfs4_disable_idmapping está localizado, execute o comando mount. Você não poderá criar manualmente o diretório em /sys/modules, porque o acesso é reservado para o kernel / drivers.

    # Check nfs4_disable_idmapping
cat /sys/module/nfs/parameters/nfs4_disable_idmapping

# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount -t nfs -o sec=sys,vers=4.1 10.31.2.4:/azusbobi-frsinput /mnt/tmp
umount /mnt/tmp

echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping

# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

  3. [A] Adicionar entradas de montagem.

    Se você estiver usando NFSv3:

    sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput  nfs   rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstab
sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput  nfs   rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstab

    Se você estiver usando NFSv4.1:

    sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab
sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab

  4. [A] Monte volumes NFS.

    sudo mount -a

sudo df -h

Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.9G  8.0K  7.9G   1% /dev
tmpfs                          7.9G   82M  7.8G   2% /run
tmpfs                          7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/sda4                       29G  1.8G   27G   6% /
tmpfs                          1.6G     0  1.6G   0% /run/user/1000
/dev/sda3                     1014M   87M  928M   9% /boot
/dev/sda2                      512M  1.1M  511M   1% /boot/efi
/dev/sdb1                       32G   49M   30G   1% /mnt
/dev/sdc                       128G   29G  100G  23% /usr/sap
10.31.2.4:/azusbobi-frsinput   101T   18G  100T   1% /usr/sap/frsinput
10.31.2.4:/azusbobi-frsoutput  100T  512K  100T   1% /usr/sap/frsoutput

Configurar a Base de Dados do Azure para MySQL

Esta seção fornece detalhes sobre como provisionar o Banco de Dados do Azure para MySQL usando o portal do Azure. Ele também fornece instruções sobre como criar o CMS e bancos de dados de auditoria para a plataforma SAP BOBI, e uma conta de usuário para acessar o banco de dados.

As diretrizes são aplicáveis somente se você estiver usando o Banco de Dados do Azure para MySQL. Para outros bancos de dados, consulte o SAP ou a documentação específica do banco de dados para obter instruções.

Criar uma base de dados

Entre no portal do Azure e siga as etapas em Guia de início rápido: criar um banco de dados do Azure para o servidor MySQL usando o portal do Azure. Aqui estão alguns pontos a serem observados enquanto você provisiona o Banco de Dados do Azure para MySQL:

  • Selecione a mesma região para o Banco de Dados do Azure para MySQL como onde seus servidores de aplicativos da plataforma SAP BI estão sendo executados.

  • Escolha uma versão de banco de dados suportada, com base na Matriz de Disponibilidade do Produto (PAM) para SAP BI específica para sua versão do SAP BOBI.

  • Em computação+armazenamento, selecione Configurar servidor e selecione a camada de preço apropriada com base na saída de dimensionamento.

  • O crescimento automático do armazenamento está habilitado por padrão. Lembre-se de que o armazenamento só pode ser ampliado, não reduzido.

  • Por padrão, o período de retenção de backup é de sete dias. Opcionalmente, você pode configurá-lo até 35 dias.

  • Os backups do Banco de Dados do Azure para MySQL são localmente redundantes por padrão. Se desejar backups de servidor em armazenamento com redundância geográfica, selecione Geograficamente redundante em Opções de redundância de backup.

Importante

Não há suporte para alterar as opções de redundância de backup após a criação do servidor.

Nota

O recurso de link privado só está disponível para o Banco de Dados do Azure para servidores MySQL nas camadas de preços de Uso Geral ou Memória Otimizada. Verifique se o servidor de banco de dados está em uma dessas camadas de preço.

Nesta seção, você cria um link privado que permite que as máquinas virtuais SAP BOBI se conectem ao Banco de Dados do Azure para MySQL por meio de um ponto de extremidade privado. O Azure Private Link traz os serviços do Azure para dentro da sua rede virtual privada.

  1. Selecione o banco de dados criado na seção anterior.
  2. Vá para Conexões de ponto de extremidade Privado de Segurança>.
  3. Em Conexões de ponto de extremidade privado, selecione Ponto de extremidade privado.
  4. Selecione Local do grupo>de recursos de assinatura.>
  5. Insira o Nome do ponto de extremidade privado.
  6. Na seção Recurso, especifique o seguinte:
    • Tipo de recurso: Microsoft.DBforMySQL/servers
    • Recurso: banco de dados MySQL criado na seção anterior
    • Sub-recurso de destino: mysqlServer
  7. Na seção Rede, selecione a Rede virtual e a Sub-rede na qual o aplicativo SAP BOBI está implantado.

    Nota

    Se você tiver um NSG (grupo de segurança de rede) habilitado para a sub-rede, ele será desabilitado apenas para pontos de extremidade privados nessa sub-rede. Outros recursos na sub-rede ainda terão aplicação do NSG.

  8. Para Integrar com zona DNS privada, aceite o padrão (sim).
  9. Selecione sua zona DNS privada na lista suspensa.
  10. Selecione Revisão+Criar e crie um ponto de extremidade privado.

Para obter mais informações, consulte Link privado para o Banco de Dados do Azure para MySQL.

Criar o CMS e bancos de dados de auditoria

  1. Baixe e instale o MySQL Workbench do site do MySQL. Certifique-se de instalar o MySQL Workbench no servidor que pode acessar o Banco de Dados do Azure para MySQL.

  2. Conecte-se ao servidor usando o MySQL Workbench. Siga as instruções em Obter informações de conexão. Se o teste de conexão for bem-sucedido, você receberá a seguinte mensagem:

    Screenshot of message in MySQL Workbench.

  3. Na guia Consulta SQL, execute a seguinte consulta para criar um esquema para o CMS e bancos de dados de auditoria.

    # Here cmsbl1 is the database name of CMS database. You can provide the name you want for CMS database.
CREATE SCHEMA `cmsbl1` DEFAULT CHARACTER SET utf8;

# auditbl1 is the database name of Audit database. You can provide the name you want for CMS database.
CREATE SCHEMA `auditbl1` DEFAULT CHARACTER SET utf8;

  4. Crie uma conta de usuário para se conectar ao esquema.

    # Create a user that can connect from any host, use the '%' wildcard as a host part
CREATE USER 'cmsadmin'@'%' IDENTIFIED BY 'password';
CREATE USER 'auditadmin'@'%' IDENTIFIED BY 'password';

# Grant all privileges to a user account over a specific database:
GRANT ALL PRIVILEGES ON cmsbl1.* TO 'cmsadmin'@'%' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON auditbl1.* TO 'auditadmin'@'%' WITH GRANT OPTION;

# Following any updates to the user privileges, be sure to save the changes by issuing the FLUSH PRIVILEGES
FLUSH PRIVILEGES;

  5. Para verificar os privilégios e funções da conta de usuário do MySQL:

    USE sys;
SHOW GRANTS for 'cmsadmin'@'%';
+------------------------------------------------------------------------+
| Grants for cmsadmin@%                                                  |
+------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `cmsadmin`@`%`                                   |
| GRANT ALL PRIVILEGES ON `cmsbl1`.* TO `cmsadmin`@`%` WITH GRANT OPTION |
+------------------------------------------------------------------------+

USE sys;
SHOW GRANTS FOR 'auditadmin'@'%';
+----------------------------------------------------------------------------+
| Grants for auditadmin@%                                                    |
+----------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `auditadmin`@`%`                                     |
| GRANT ALL PRIVILEGES ON `auditbl1`.* TO `auditadmin`@`%` WITH GRANT OPTION |
+----------------------------------------------------------------------------+

Instale o conector MySQL C API em um servidor Linux

Para que o servidor de aplicativos SAP BOBI acesse um banco de dados, ele requer drivers de cliente de banco de dados. Para acessar o CMS e os bancos de dados de auditoria, você deve usar o MySQL C API Connector for Linux. Não há suporte para uma conexão ODBC com o banco de dados CMS. Esta seção fornece instruções sobre como configurar o MySQL C API Connector no Linux.

  1. Consulte Drivers MySQL e ferramentas de gerenciamento compatíveis com o Banco de Dados do Azure para MySQL. Verifique o driver MySQL Connector/C (libmysqlclient) no artigo.

  2. Para baixar drivers, consulte MySQL Product Archives.

  3. Selecione o sistema operacional e baixe o pacote rpm do componente compartilhado do MySQL Connector. Neste exemplo, a versão do conector mysql-connector-c-shared-6.1.11 é usada.

  4. Instale o conector em todas as instâncias do aplicativo SAP BOBI.

    # Install rpm package
SLES: sudo zypper install <package>.rpm
RHEL: sudo yum install <package>.rpm

  5. Verifique o caminho de libmysqlclient.so.

    # Find the location of libmysqlclient.so file
whereis libmysqlclient

# sample output
libmysqlclient: /usr/lib64/libmysqlclient.so

  6. Defina LD_LIBRARY_PATH para apontar para o /usr/lib64 diretório da conta de usuário que será usada para a instalação.

    # This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly.
vi /home/bl1adm/.bashrc

export LD_LIBRARY_PATH=/usr/lib64

Preparação do servidor

As etapas nesta seção usam o seguinte prefixo:

[R]: O passo aplica-se a todos os anfitriões.

  1. [A] Com base no sabor do Linux (SLES ou RHEL), você precisa definir os parâmetros do kernel e instalar as bibliotecas necessárias. Consulte a seção "Requisitos do sistema" no Guia de Instalação da Plataforma de Business Intelligence para Unix.

  2. [A] Certifique-se de que o fuso horário na sua máquina está definido corretamente. No Guia de Instalação, consulte Requisitos adicionais de Unix e Linux.

  3. [A] Crie uma conta de usuário (bl1adm) e um grupo (sapsys) sob os quais os processos em segundo plano do software podem ser executados. Use esta conta para executar a instalação e o software. A conta não requer privilégios de root.

  4. [A] Defina o ambiente da conta de utilizador (bl1adm) para utilizar uma localidade UTF-8 suportada e certifique-se de que o software da consola suporta conjuntos de carateres UTF-8. Para garantir que seu sistema operacional use a localidade correta, defina as LC_ALL variáveis e LANG de ambiente para sua localidade preferida em seu ambiente de usuário (bl1adm).

    # This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly.
vi /home/bl1adm/.bashrc

export LANG=en_US.utf8
export LC_ALL=en_US.utf8

  5. [A] Configurar conta de usuário (bl1adm).

    # Set ulimit for bl1adm to unlimited
root@azusbosl1:~> ulimit -f unlimited bl1adm
root@azusbosl1:~> ulimit -u unlimited bl1adm

root@azusbosl1:~> su - bl1adm
bl1adm@azusbosl1:~> ulimit -a

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63936
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

  6. Faça download e extraia mídia para a plataforma de BI SAP BusinessObjects do SAP Service Marketplace.

Instalação

Verifique a localidade da conta de usuário bl1adm no servidor:

bl1adm@azusbosl1:~> locale
LANG=en_US.utf8
LC_ALL=en_US.utf8

Vá para a mídia da plataforma SAP BOBI e execute o seguinte comando com o usuário bl1adm:

./setup.sh -InstallDir /usr/sap/BL1

Siga o Guia de Instalação da plataforma SAP BOBI para Unix, específico para a sua versão. Aqui estão alguns pontos a serem observados durante a instalação da plataforma SAP BOBI:

  • Em Configurar o registro de produto, você pode usar uma chave de licença temporária para SAP BusinessObjects Solutions a partir do SAP Note 1288121 ou pode gerar uma chave de licença no SAP Service Marketplace.

  • Em Selecionar Tipo de Instalação, selecione Instalação completa no primeiro servidor (azusbosl1). Para o outro servidor (azusbosl2), selecione Personalizar / Expandir, que expandirá a configuração BOBI existente.

  • Em Selecionar Banco de Dados Padrão ou Existente, selecione Configurar um banco de dados existente, que solicitará que você selecione CMS e bancos de dados de auditoria. Selecione MySQL para esses tipos de banco de dados.

    Você também pode selecionar Sem banco de dados de auditoria, se não quiser configurar a auditoria durante a instalação.

  • Na tela Selecionar Java Web Application Server, selecione as opções apropriadas com base na sua arquitetura SAP BOBI. Neste exemplo, selecionamos a opção 1, que instala um servidor tomcat na mesma plataforma SAP BOBI.

  • Insira as informações do banco de dados CMS em Configurar banco de dados de repositório CMS - MySQL. O exemplo a seguir mostra a entrada para informações de banco de dados CMS para uma instalação Linux. O Banco de Dados do Azure para MySQL é usado na porta padrão 3306.

    Screenshot that shows SAP BOBI Deployment on Linux - CMS database.

  • (Opcional) Insira as informações do banco de dados de auditoria em Configurar banco de dados do repositório de auditoria - MySQL. O exemplo a seguir mostra a entrada para informações de banco de dados de auditoria para uma instalação do Linux.

    Screenshot that shows SAP BOBI Deployment on Linux - audit database.

  • Siga as instruções e insira as entradas necessárias para concluir a instalação.

Para implantação em várias instâncias, execute a instalação em um segundo host (azusbosl2). Em Selecionar Tipo de Instalação, selecione Personalizar / Expandir, o que expandirá a configuração BOBI existente.

No Banco de Dados do Azure para MySQL, um gateway redireciona as conexões para instâncias de servidor. Depois de a ligação ser estabelecida, o cliente MySQL apresenta a versão do MySQL definida no gateway, não a versão real em execução na instância do servidor MySQL. Para determinar a versão da instância do servidor MySQL, utilize o comando SELECT VERSION(); no prompt do MySQL. Para obter mais detalhes, consulte Banco de Dados do Azure com suporte para versões de servidor MySQL.

Screenshot that shows SAP BOBI Deployment on Linux - CMC Settings.

# Run direct query to the database using MySQL Workbench

select version();

+-----------+
| version() |
+-----------+
| 8.0.15    |
+-----------+

Pós-instalação

Após uma instalação em várias instâncias da plataforma SAP BOBI, você precisa executar etapas adicionais de pós-configuração para oferecer suporte à alta disponibilidade do aplicativo.

Configurar o nome do cluster

Em uma implantação de várias instâncias da plataforma SAP BOBI, você deseja executar vários servidores CMS juntos em um cluster. Um cluster consiste em dois ou mais servidores CMS trabalhando juntos em um banco de dados comum do sistema CMS. Se um nó em execução no CMS falhar, um nó com outro CMS continuará a atender às solicitações da plataforma de BI. Por padrão, na plataforma SAP BOBI, um nome de cluster reflete o nome do host do primeiro CMS instalado.

Para configurar o nome do cluster no Linux, siga as instruções no SAP Business Intelligence Platform Administrator Guide. Depois de configurar o nome do cluster, siga o SAP Note 1660440 para definir a entrada padrão do sistema na página de entrada da barra de ativação do CMC ou BI.

Configurar o local do armazenamento de arquivos de entrada e saída para os Arquivos NetApp do Azure

Filestore refere-se aos diretórios de disco onde estão os arquivos reais do SAP BusinessObjects. O local padrão do servidor de repositório de arquivos para a plataforma SAP BOBI está localizado no diretório de instalação local. Em uma implantação de várias instâncias, é importante configurar o armazenamento de arquivos em um armazenamento compartilhado, como os Arquivos NetApp do Azure. Isso permite o acesso ao armazenamento de arquivos de todos os servidores de camada de armazenamento.

  1. Se você ainda não criou volumes NFS, crie-os nos Arquivos NetApp do Azure. (Siga as instruções na seção anterior "Provisionar arquivos NetApp do Azure.")

  2. Monte o volume NFS. (Siga as instruções na seção anterior "Monte o volume de arquivos NetApp do Azure.")

  3. Siga o SAP Note 2512660 para alterar o caminho do repositório de arquivos (entrada e saída).

Replicação de sessão em clustering Tomcat

O Tomcat oferece suporte ao clustering de dois ou mais servidores de aplicativos para replicação e failover de sessão. As sessões da plataforma SAP BOBI são serializadas, de modo que uma sessão de usuário pode fazer failover sem problemas para outra instância do Tomcat, mesmo quando um servidor de aplicativos falha.

Por exemplo, suponha que um usuário esteja conectado a um servidor Web que falha enquanto o usuário está navegando em uma hierarquia de pastas em um aplicativo SAP BI. Com um cluster configurado corretamente, o usuário pode continuar navegando na hierarquia de pastas sem ser redirecionado para a página de entrada.

Consulte SAP Note 2808640 para conhecer as etapas para configurar o clustering do Tomcat usando multicast. Observe que o Azure, no entanto, não oferece suporte a multicast. Portanto, para fazer o cluster Tomcat funcionar no Azure, você deve usar StaticMembershipInterceptor (SAP Note 2764907). Para obter mais informações, consulte a postagem do blog Tomcat Clustering using Static Membership for SAP BusinessObjects BI Platform.

Camada da Web de balanceamento de carga da plataforma SAP BI

Em uma implantação multiinstância do SAP BOBI, os servidores Java Web Application (camada da web) são executados em dois ou mais hosts. Para distribuir a carga do usuário uniformemente entre servidores Web, você pode usar um balanceador de carga entre usuários finais e servidores Web. No Azure, você pode usar o Balanceador de Carga do Azure ou o Gateway de Aplicativo do Azure para gerenciar o tráfego para seus servidores de aplicativos Web. Os detalhes sobre cada oferta são explicados na seção a seguir.

Balanceador de Carga do Azure

O Azure Load Balancer é um balanceador de carga de camada 4 (TCP, UDP) de alto desempenho e baixa latência. Ele distribui o tráfego entre máquinas virtuais (VMs) íntegras. Uma sonda de integridade do balanceador de carga monitora uma porta especificada em cada VM e distribui apenas o tráfego para uma VM operacional. Você pode escolher um balanceador de carga público ou um balanceador de carga interno, dependendo se deseja ou não que a plataforma SAP BI seja acessível pela Internet. É redundante de zona, garantindo alta disponibilidade em todas as zonas de disponibilidade.

No diagrama a seguir, consulte a seção Balanceador de carga interno. O servidor de aplicativos Web é executado na porta 8080, a porta HTTP Tomcat padrão, que será monitorada pela sonda de integridade. Qualquer solicitação de entrada proveniente de usuários finais é redirecionada para os servidores de aplicativos Web (azusbosl1 ou azusbosl2). O Load Balancer não suporta terminação TLS/SSL (também conhecida como descarregamento TLS/SSL). Se você estiver usando o Load Balancer para distribuir o tráfego entre servidores Web, use o Standard Load Balancer.

Nota

Quando VMs sem endereços IP públicos são colocadas no pool de Balanceador de Carga Padrão interno (sem endereço IP público), não haverá conectividade de saída com a Internet, a menos que você execute uma configuração adicional para permitir o roteamento para pontos finais públicos. Para obter mais informações, consulte Conectividade de ponto de extremidade público para máquinas virtuais usando o Azure Standard Load Balancer em cenários de alta disponibilidade SAP.

Diagram that shows Azure Load Balancer balancing traffic across web servers.

Gateway de Aplicação do Azure

O Gateway de Aplicativo do Azure fornece o Controlador de Entrega de Aplicativo (ADC) como um serviço. Este serviço é usado para ajudar o aplicativo a direcionar o tráfego do usuário para um ou mais servidores de aplicativos Web. Ele oferece vários recursos de balanceamento de carga de camada 7, como descarregamento de TLS/SSL, firewall de aplicativos da Web (WAF) e afinidade de sessão baseada em cookies.

Na plataforma SAP BI, o Application Gateway direciona o tráfego da web do aplicativo para os recursos especificados, ou azusbosl1azusbos2. Você atribui um ouvinte a uma porta, cria regras e adiciona recursos a um pool. No diagrama a seguir, o Application Gateway tem um endereço IP privado (10.31.3.20) que atua como um ponto de entrada para os usuários. Ele também lida com conexões TLS/SSL (HTTPS - TCP/443) de entrada, descriptografa o TLS/SSL e passa a solicitação não criptografada (HTTP - TCP/8080) para os servidores. Ele simplifica as operações para manter apenas um certificado TLS/SSL no Application Gateway.

Diagram that shows Application Gateway balancing traffic across web servers.

Para configurar o Application Gateway para um servidor Web SAP BOBI, consulte a postagem do blog Load Balancing SAP BOBI Web Servers using Azure Application Gateway.

Nota

O Gateway de Aplicativo do Azure é preferível para balancear a carga do tráfego para um servidor Web. Ele fornece recursos úteis, como descarregamento de SSL, gerenciamento centralizado de SSL para reduzir a sobrecarga de criptografia e descriptografia no servidor, um algoritmo round-robin para distribuir tráfego, recursos WAF e alta disponibilidade.

Confiabilidade da plataforma SAP BOBI no Azure

A plataforma SAP BOBI inclui diferentes níveis, que são otimizados para tarefas e operações específicas. Quando um componente de qualquer camada fica indisponível, um aplicativo SAP BOBI torna-se inacessível ou limitado em sua funcionalidade. Certifique-se de que cada camada foi projetada para ser confiável, para manter o aplicativo operacional sem qualquer interrupção nos negócios.

Este guia explora como os recursos nativos do Azure, em combinação com a configuração da plataforma SAP BOBI, melhoram a disponibilidade da implantação do SAP. Esta secção centra-se nas seguintes opções:

  • Backup e restauração: é um processo de criação de cópias periódicas de dados e aplicativos para um local separado. Você pode restaurar ou recuperar para um estado anterior se os dados ou aplicativos originais forem perdidos ou danificados.

  • Alta disponibilidade: uma plataforma altamente disponível tem pelo menos dois de tudo dentro de uma região do Azure, para manter o aplicativo operacional se um dos servidores ficar indisponível.

  • Recuperação de desastres: é um processo de restauração da funcionalidade do aplicativo se houver alguma perda catastrófica, como uma região inteira do Azure ficando indisponível devido a algum desastre natural.

A implementação desta solução varia de acordo com a natureza da configuração do sistema no Azure. Personalize suas soluções de backup/restauração, alta disponibilidade e recuperação de desastres de acordo com suas necessidades de negócios.

Cópia de segurança e restauro

O backup e a restauração são um componente essencial de qualquer estratégia de recuperação de desastres de negócios. Para desenvolver uma estratégia abrangente para a plataforma SAP BOBI, identifique os componentes que levam ao tempo de inatividade do sistema ou interrupção no aplicativo. Na plataforma SAP BOBI, o backup dos seguintes componentes é vital para proteger o aplicativo:

  • Diretório de instalação do SAP BOBI (Managed Premium Disks)
  • Servidor de repositório de ficheiros (Azure NetApp Files ou Azure Premium Files)
  • Banco de dados CMS (Banco de Dados do Azure para MySQL ou um banco de dados em Máquinas Virtuais do Azure)

A seção a seguir descreve como implementar uma estratégia de backup e restauração para cada um desses componentes.

Backup e restauração do diretório de instalação do SAP BOBI

No Azure, a maneira mais simples de fazer backup de servidores de aplicativos e todos os discos anexados é usando o Backup do Azure. Ele fornece backups independentes e isolados para proteger contra a destruição não intencional dos dados em suas VMs. Os backups são armazenados em um cofre de serviços de recuperação, com gerenciamento interno de pontos de recuperação. A configuração e o dimensionamento são simples, os backups são otimizados e você pode restaurar facilmente quando precisar.

Como parte do processo de backup, um instantâneo é tirado e os dados são transferidos para o cofre sem impacto nas cargas de trabalho de produção. Para obter mais informações, consulte Consistência de instantâneo. Você também pode optar por fazer backup de um subconjunto dos discos de dados em sua VM, usando a funcionalidade de backup e restauração de discos seletivos. Para obter mais informações, consulte Backup de VM do Azure e Perguntas frequentes - Backup de VMs do Azure.

Backup e restauração para servidor de repositório de arquivos

Com base em sua implantação do SAP BOBI no Linux, você pode usar o Azure NetApp Files como o armazenamento de arquivos da sua plataforma SAP BOBI. Escolha entre as seguintes opções de backup e restauração com base no armazenamento que você usa para armazenamento de arquivos.

  • Arquivos NetApp do Azure: você pode criar instantâneos sob demanda e agendar instantâneos automáticos usando políticas de instantâneo. As cópias instantâneas fornecem uma cópia point-in-time do seu volume. Para obter mais informações, veja Gerir instantâneos com o Azure NetApp Files.

  • Se você criou um servidor NFS separado, certifique-se de implementar a estratégia de backup e restauração para o mesmo servidor.

Backup e restauração para CMS e bancos de dados de auditoria

Em VMs Linux, o CMS e os bancos de dados de auditoria podem ser executados em qualquer um dos bancos de dados suportados. Para obter mais informações, veja a matriz de suporte. É importante que você adote a estratégia de backup e restauração com base no banco de dados usado para o CMS e o armazenamento de dados de auditoria.

  • O Banco de Dados do Azure para MySQL cria automaticamente backups de servidor e os armazena em armazenamento configurado pelo usuário, localmente redundante ou com redundância geográfica. A Base de Dados do Azure para MySQL tira cópias de segurança dos ficheiros de dados e do registo de transações. Dependendo do tamanho máximo de armazenamento suportado, são necessários backups completos e diferenciais (servidores de armazenamento máximos de 4 TB) ou backups instantâneos (servidores de armazenamento máximos de 16 TB). Esses backups permitem que você restaure um servidor a qualquer momento dentro do período de retenção de backup configurado. O período de retenção de backup padrão é de sete dias, que você pode configurar opcionalmente até três dias. Todos os backups são criptografados usando criptografia AES de 256 bits. Esses arquivos de backup não são expostos ao usuário e não podem ser exportados. Esses backups só podem ser usados para operações de restauração no Banco de Dados do Azure para MySQL. Você pode usar mysqldump para copiar um banco de dados. Para obter mais informações, veja Cópia de segurança e restauro na Base de Dados do Azure para MySQL.

  • Para um banco de dados instalado em uma máquina virtual do Azure, você pode usar ferramentas de backup padrão ou o Backup do Azure para bancos de dados com suporte. Você também pode usar ferramentas de backup de terceiros suportadas que fornecem um agente para backup e recuperação de todos os componentes da plataforma SAP BOBI.

Elevada disponibilidade

Alta disponibilidade refere-se a um conjunto de tecnologias que podem minimizar as interrupções de TI fornecendo continuidade de negócios de aplicativos e serviços. Ele faz isso por meio de componentes redundantes, tolerantes a falhas ou protegidos contra failover dentro do mesmo datacenter. No nosso caso, os datacenters estão dentro de uma região do Azure. Para obter mais informações, consulte Arquitetura de alta disponibilidade e cenários para SAP.

Com base no resultado de dimensionamento da plataforma SAP BOBI, você precisa projetar o cenário e determinar a distribuição de componentes de BI entre Máquinas Virtuais e sub-redes do Azure. O nível de redundância na arquitetura distribuída depende do RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e do RPO (Recovery Point Objetive, objetivo de ponto de recuperação) de que você precisa para sua empresa. A plataforma SAP BOBI inclui diferentes camadas, e os componentes em cada camada devem ser projetados para obter redundância. Por exemplo:

  • Servidores de aplicativos redundantes, como servidores de aplicativos de BI e servidor web.
  • Componentes exclusivos, como banco de dados CMS, servidor de repositório de arquivos e balanceador de carga.

As seções a seguir descrevem como obter alta disponibilidade em cada componente da plataforma SAP BOBI.

Alta disponibilidade para servidores de aplicativos

Você pode obter alta disponibilidade para servidores de aplicativos empregando redundância. Para fazer isso, configure várias instâncias de BI e servidores Web em várias VMs do Azure.

Para reduzir o impacto do tempo de inatividade devido a eventos planejados e não planejados, é uma boa ideia seguir as diretrizes de arquitetura de alta disponibilidade.

Para obter mais informações, consulte Gerenciar a disponibilidade de máquinas virtuais Linux.

Importante

  • Os conceitos de zonas de disponibilidade do Azure e conjuntos de disponibilidade do Azure são mutuamente exclusivos. Você pode implantar um par ou várias VMs em uma zona de disponibilidade específica ou em um conjunto de disponibilidade, mas não pode fazer as duas coisas.
  • Se você planeja implantar em zonas de disponibilidade, é recomendável usar o conjunto de escala flexível com FD=1 sobre a implantação da zona de disponibilidade padrão.

Alta disponibilidade para um banco de dados CMS

Se você estiver usando o Banco de Dados do Azure para MySQL para seu CMS e bancos de dados de auditoria, terá uma estrutura de alta disponibilidade localmente redundante por padrão. Você só precisa selecionar a região e os recursos inerentes de alta disponibilidade, redundância e resiliência do serviço, sem precisar configurar componentes adicionais. Se a estratégia de implantação para a plataforma SAP BOBI estiver em zonas de disponibilidade, você precisará garantir a redundância de zona para seus bancos de dados CMS e de auditoria. Para obter mais informações, consulte Alta disponibilidade no Banco de Dados do Azure para MySQL e Alta disponibilidade para o Banco de Dados SQL do Azure.

Para outras implantações para o banco de dados CMS, consulte as informações de alta disponibilidade nos guias de implantação do DBMS para SAP Workload.

Alta disponibilidade para armazenamento de arquivos

Filestore refere-se aos diretórios de disco onde conteúdos como relatórios, universos e conexões são armazenados. Ele é compartilhado em todos os servidores de aplicativos desse sistema. Portanto, você deve certificar-se de que ele esteja altamente disponível, juntamente com outros componentes da plataforma SAP BOBI.

Para a plataforma SAP BOBI em execução no Linux, você pode escolher Arquivos Premium do Azure ou Arquivos NetApp do Azure para compartilhamentos de arquivos projetados para serem altamente disponíveis e duráveis por natureza. Para obter mais informações, consulte Redundância para arquivos do Azure.

Observe que esse serviço de compartilhamento de arquivos não está disponível em todas as regiões. Consulte Produtos disponíveis por região para encontrar informações atualizadas. Se o serviço não estiver disponível em sua região, você poderá criar um servidor NFS a partir do qual poderá compartilhar o sistema de arquivos com o aplicativo SAP BOBI. Mas você também precisará considerar sua alta disponibilidade.

Alta disponibilidade para o Load Balancer

Para distribuir o tráfego em um servidor Web, você pode usar o Balanceador de Carga do Azure ou o Gateway de Aplicativo do Azure. A redundância para qualquer um deles pode ser obtida com base na SKU escolhida para implantação.

  • Para o Azure Load Balancer, a redundância pode ser obtida configurando o Standard Load Balancer como redundante de zona. Para obter mais informações, consulte Balanceador de carga padrão e zonas de disponibilidade.

  • Para o Application Gateway, a alta disponibilidade pode ser obtida com base no tipo de camada selecionada durante a implantação.

    • O SKU v1 oferece suporte a cenários de alta disponibilidade quando você implanta duas ou mais instâncias. O Azure distribui essas instâncias entre domínios de atualização e falha para garantir que as instâncias não falhem todas ao mesmo tempo. Você consegue redundância dentro da zona.
    • O SKU v2 garante automaticamente que novas instâncias sejam espalhadas entre domínios de falha e domínios de atualização. Se você escolher redundância de zona, as instâncias mais recentes também serão distribuídas pelas zonas de disponibilidade para oferecer resiliência a falhas zonais. Para obter mais detalhes, consulte Autoscaling and Zone-redundant Application Gateway v2.

Arquitetura de referência de alta disponibilidade para a plataforma SAP BOBI

O diagrama a seguir mostra a configuração da plataforma SAP BOBI em execução no servidor Linux. A arquitetura mostra o uso de diferentes serviços, como o Gateway de Aplicativo do Azure, os Arquivos NetApp do Azure e o Banco de Dados do Azure para MySQL. Esses serviços oferecem redundância integrada, o que reduz a complexidade do gerenciamento de diferentes soluções de alta disponibilidade.

Observe que o tráfego de entrada (HTTPS) é balanceado de carga usando a SKU do Gateway de Aplicativo do Azure v1/v2, que é altamente disponível quando implantada em duas ou mais instâncias. Várias instâncias do servidor Web, servidores de gerenciamento e servidores de processamento são implantadas em VMs separadas para obter redundância. Os Arquivos NetApp do Azure têm redundância interna no datacenter, portanto, seus volumes de Arquivos NetApp do Azure para o servidor de repositório de arquivos estarão altamente disponíveis. O banco de dados CMS é provisionado no Banco de Dados do Azure para MySQL, que tem alta disponibilidade inerente. Para obter mais informações, veja Elevada disponibilidade na Base de Dados do Azure para MySQL.

Diagram that shows SAP BusinessObjects BI platform redundancy with availability sets.

A arquitetura anterior fornece informações sobre como uma implantação do SAP BOBI no Azure pode ser feita. Mas não cobre todas as opções de configuração possíveis. Você pode personalizar sua implantação com base em seus requisitos de negócios.

Em várias regiões do Azure, você pode usar zonas de disponibilidade. Isso significa que você pode tirar proveito de uma fonte de alimentação independente, resfriamento e rede. Ele permite que você implante um aplicativo em duas ou três zonas de disponibilidade. Se quiser obter alta disponibilidade em zonas de disponibilidade, você pode implantar a plataforma SAP BOBI nessas zonas, certificando-se de que cada componente do aplicativo seja redundante de zona.

Recuperação após desastre

Esta seção explica a estratégia para fornecer proteção de recuperação de desastres para uma plataforma SAP BOBI em execução no Linux. Ele complementa o documento Disaster Recovery for SAP , que representa os principais recursos para a abordagem geral de recuperação de desastres SAP. Para SAP BOBI, consulte SAP Note 2056228, que descreve os seguintes métodos para implementar um ambiente de recuperação de desastres com segurança.

  • Usar total ou seletivamente o gerenciamento ou a federação do ciclo de vida para promover e distribuir o conteúdo do sistema primário.
  • Copiando periodicamente o CMS e o conteúdo do servidor de repositório de arquivos.

Este guia centra-se na segunda opção. Ele não cobrirá todas as opções de configuração possíveis para recuperação de desastres, mas abrange uma solução que apresenta serviços nativos do Azure em combinação com uma configuração de plataforma SAP BOBI.

Importante

  • A disponibilidade de cada componente na plataforma SAP BOBI deve ser considerada na região secundária e você deve testar completamente toda a estratégia de recuperação de desastres.
  • Caso sua plataforma SAP BI esteja configurada com escala flexível definida com FD=1, você precisará usar o PowerShell para configurar o Azure Site Recovery para recuperação de desastres. Atualmente, é o único método disponível para configurar a recuperação de desastres para VMs implantadas em conjunto de escala.

Arquitetura de recuperação de desastres de referência para a plataforma SAP BOBI

Essa arquitetura de referência está executando uma implantação de várias instâncias da plataforma SAP BOBI, com servidores de aplicativos redundantes. Para recuperação de desastres, você deve fazer failover de todos os componentes da plataforma SAP BOBI para uma região secundária. No diagrama a seguir, os Arquivos NetApp do Azure são usados como o armazenamento de arquivos, o Banco de Dados do Azure para MySQL como o CMS e o repositório de auditoria e o Gateway de Aplicativo do Azure como o balanceador de carga. A estratégia para obter proteção de recuperação de desastres para cada componente é diferente, e essas diferenças são descritas nas seções a seguir.

Diagram that shows SAP BusinessObjects BI platform disaster recovery.

Balanceador de carga

Um balanceador de carga é usado para distribuir o tráfego entre servidores de aplicativos Web da plataforma SAP BOBI. No Azure, você pode usar o Azure Load Balancer ou o Azure Application Gateway para essa finalidade. Para obter recuperação de desastres para os serviços de balanceador de carga, você precisa implementar outro Balanceador de Carga do Azure ou Gateway de Aplicativo do Azure na região secundária. Para manter a mesma URL após um failover de recuperação de desastre, você precisa alterar a entrada no DNS, apontando para o serviço de balanceamento de carga em execução na região secundária.

VMs executando servidores de aplicativos Web e BI

Use o Azure Site Recovery para replicar VMs que executam servidores de aplicativos Web e BI na região secundária. Ele replica os servidores e todo o disco gerenciado conectado à região secundária, para que, quando ocorrerem desastres e interrupções, você possa facilmente fazer failover para o ambiente replicado e continuar trabalhando. Para começar a replicar todas as VMs do aplicativo SAP para o datacenter de recuperação de desastres do Azure, siga as orientações em Replicar uma máquina virtual para o Azure.

Servidores de repositório de arquivos

Filestore é um diretório de disco onde os arquivos reais, como relatórios e documentos de BI, são armazenados. É importante que todos os arquivos no armazenamento de arquivos estejam sincronizados com uma região de recuperação de desastres. Com base no tipo de serviço de compartilhamento de arquivos que você usa para a plataforma SAP BOBI em execução no Linux, a estratégia de recuperação de desastres apropriada precisa ser adotada para sincronizar o conteúdo.

  • Os Arquivos NetApp do Azure fornecem volumes NFS e SMB, para que você possa usar qualquer ferramenta de cópia baseada em arquivo para replicar dados entre regiões do Azure. Para obter mais informações sobre como copiar um volume em outra região, consulte Perguntas frequentes sobre arquivos NetApp do Azure.

    Você pode usar a replicação entre regiões do Azure NetApp Files, atualmente em visualização. Apenas os blocos alterados são enviados através da rede num formato comprimido e eficiente. Isso minimiza a quantidade de dados necessária para replicar entre as regiões, economizando custos de transferência de dados. Ele também reduz o tempo de replicação, para que você possa obter um RPO menor. Para obter mais informações, consulte Requisitos e considerações sobre o uso da replicação entre regiões.

  • Os ficheiros premium do Azure suportam apenas LRS (redundante local) e armazenamento redundante de zona (ZRS). Para a estratégia de recuperação de desastres, você pode usar o AzCopy ou o Azure PowerShell para copiar seus arquivos para outra conta de armazenamento em uma região diferente. Para obter mais informações, consulte Recuperação de desastres e failover de conta de armazenamento.

    Importante

    O Protocolo SMB para Arquivos do Azure está disponível em geral, mas o suporte ao Protocolo NFS para Arquivos do Azure está atualmente em visualização. Para obter mais informações, consulte O suporte do NFS 4.1 para Arquivos do Azure agora está em visualização.

Base de dados CMS

O CMS e os bancos de dados de auditoria na região de recuperação de desastres devem ser uma cópia dos bancos de dados em execução na região primária. Com base no tipo de banco de dados, é importante copiá-lo para a região de recuperação de desastres com base no RTO e no RPO que sua empresa exige.

Base de Dados do Azure para MySQL

O Banco de Dados do Azure para MySQL fornece várias opções para recuperar um banco de dados se houver um desastre. Escolha uma opção apropriada que funcione para o seu negócio.

  • Habilite réplicas de leitura entre regiões para aprimorar a continuidade de negócios e o planejamento de recuperação de desastres. Pode replicar do servidor de origem para até cinco réplicas. As réplicas de leitura são atualizadas de forma assíncrona usando a tecnologia de replicação de log binário do MySQL. As réplicas são novos servidores que você gerencia de forma semelhante aos servidores regulares no Banco de Dados do Azure para MySQL. Para obter mais informações, consulte Ler réplicas no Banco de Dados do Azure para MySQL.

  • Use o recurso de restauração geográfica para restaurar o servidor usando backups com redundância geográfica. Esses backups são acessíveis mesmo quando a região na qual o servidor está hospedado está offline. Você pode restaurar a partir desses backups para qualquer outra região e colocar seu servidor online novamente.

    Nota

    A restauração geográfica só é possível se você provisionou o servidor com armazenamento de backup com redundância geográfica. Não há suporte para alterar as opções de redundância de backup após a criação do servidor. Para obter mais informações, consulte Redundância de backup.

A tabela a seguir mostra a recomendação para recuperação de desastres de cada camada usada neste exemplo.

Níveis da plataforma SAP BOBI Recomendação
Gateway de Aplicação do Azure Configuração paralela do Application Gateway em uma região secundária.
Servidores de aplicativos Web Replicar usando o Azure Site Recovery.
Servidores de aplicativos de BI Replicar usando o Site Recovery.
Azure NetApp Files Ferramenta de cópia baseada em arquivo para replicar dados para uma região secundária ou usando replicação entre regiões.
Base de Dados do Azure para MySQL Réplicas de leitura entre regiões ou restaure o backup a partir de backups com redundância geográfica.

Próximos passos