Implantar a plataforma SAP BusinessObjects BI no Azure para Windows

Este artigo descreve a estratégia para implantar a plataforma SAP BusinessObjects Business Intelligence (BOBI) no Azure para Windows. Neste exemplo, duas VMs (máquinas virtuais) com discos gerenciados SSD Premium do Azure como seu diretório de instalação são configuradas. O Banco de Dados SQL do Azure, uma oferta de PaaS (plataforma como serviço), é usado para o CMS (servidor de gerenciamento central) e bancos de dados de auditoria. Os Arquivos Premium do Azure, um protocolo SMB, são usados como um repositório de arquivos compartilhado em ambas as VMs. O aplicativo Web Tomcat Java padrão e o aplicativo da plataforma de BI (Business Intelligence) são instalados juntos em ambas as VMs. Para balancear a carga da solicitação do usuário, o Gateway de Aplicativo do Azure é usado com recursos de descarregamento de TLS/SSL nativos.

Esse tipo de arquitetura é eficaz para implantações pequenas ou ambientes de não produção. Para produção ou implantação em grande escala, você deve separar hosts para aplicativos Web e pode ter vários hosts de aplicativos SAP BOBI, o que permite que o servidor processe mais informações.

Diagrama que mostra uma implantação do SAP BOBI no Azure para Windows.

Sistema de arquivos Descrição Tamanho (GB) Acesso necessário Armazenamento
F: O sistema de arquivos para instalação de uma instância do SAP BOBI, do aplicativo Web Tomcat padrão e de drivers de banco de dados (se necessário). Diretrizes de dimensionamento SAP Privilégios administrativos locais Discos SSD Premium gerenciados do Azure
\\azusbobi.file.core.windows.net\frsinput O diretório de montagem é destinado aos arquivos compartilhados em todos os hosts SAP BOBI, que são utilizados como o diretório do Input Filestore. Necessidade comercial Privilégios administrativos locais Azure NetApp Files
\\azusbobi.file.core.windows.net\frsoutput O diretório de montagem é para os arquivos compartilhados em todos os hosts SAP BOBI que são usados como o diretório Output Filestore. Necessidade comercial Privilégios administrativos locais Azure NetApp Files

Pré-requisitos

  • Uma assinatura do Azure com permissões para criar recursos como VMs, contas de armazenamento, instâncias do Banco de Dados SQL e redes virtuais.
  • Dimensionamento completo da plataforma SAP BOBI com base no guia de planejamento e implementação do SAP BOBI no Azure.
  • Mídia de instalação da plataforma SAP BusinessObjects BI (versão 4.3 SP01 Patch 1 ou posterior). Para obter uma chave de licença temporária, consulte a nota sap 1288121.
  • Um driver ODBC da Microsoft compatível com o Banco de Dados SQL do Azure. Este artigo usa a versão 13.1.
  • Windows Server 2019 ou uma versão do sistema operacional com suporte de acordo com a Matriz de Disponibilidade do Produto SAP.
  • Acesso à rede de saída na porta 1433 dos servidores de aplicativos SAP BOBI para o Banco de Dados SQL do Azure.
  • Acesso à rede de saída na porta 445 dos servidores de aplicativos SAP BOBI se você usar Arquivos Premium do Azure (SMB).

Implantar uma VM do Windows usando o portal do Azure

Nesta seção, você criará duas VMs com uma imagem do sistema operacional Windows (SO) para a plataforma SAP BOBI. As etapas de alto nível para criar VMs são as seguintes:

  1. Crie um grupo de recursos.

  2. Crie uma rede virtual:

    • Não use uma sub-rede única para todos os serviços do Azure em uma implantação da plataforma de BI SAP. Com base na arquitetura da plataforma SAP BI, talvez seja necessário criar várias sub-redes. Nesta implantação, você cria duas sub-redes: uma sub-rede de aplicativo de BI e uma sub-rede do Gateway de Aplicativo.
    • Siga a SAP Note 2276646 para identificar portas para comunicação da plataforma SAP BOBI entre diferentes componentes.
    • O Banco de Dados SQL se comunica pela porta 1433. O tráfego de saída pela porta 1433 deve ser permitido a partir de seus servidores de aplicação SAP BOBI.
    • No Azure, o Gateway de Aplicativo precisa estar em uma sub-rede separada. Para obter mais informações, confira Visão geral da configuração do Gateway de Aplicativo.
    • Se você estiver usando o Azure NetApp Files para um armazenamento de arquivos em vez de arquivos do Azure, crie uma sub-rede separada para o Azure NetApp Files. Para obter mais informações, confira Diretrizes para planejamento de rede do Azure NetApp Files.

  3. Selecione as opções de disponibilidade adequadas, dependendo da configuração do sistema preferencial em uma região do Azure, se:

    • Envolve cobrir várias zonas
    • Reside em uma única zona
    • Opera em uma região sem zona

  4. Criar VM 1 (azuswinboap1):

  5. Crie a VM 2 (azuswinboap2).

  6. Adicione um SSD Premium. Ele é usado como um diretório de instalação do SAP BOBI.

Configurar Arquivos Premium do Azure

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

O Arquivos do Azure oferece compartilhamentos de arquivos padrão hospedados em hardware baseado em HDD e compartilhamentos de arquivos premium hospedados em hardware baseado em SSD. Para um repositório de arquivos SAP BusinessObjects, use os Arquivos Premium do Azure.

Os compartilhamentos de arquivos premium do Azure estão disponíveis com redundância local e de zona em um subconjunto de regiões. Para descobrir se os compartilhamentos de arquivos premium estão disponíveis atualmente em sua região, consulte Produtos disponíveis por região. Para obter informações sobre regiões que dão suporte ao ZRS (armazenamento com redundância de zona), confira Redundância do Armazenamento do Microsoft Azure.

Implantar uma conta de armazenamento Azure Files e compartilhamentos de NFS

Os compartilhamentos de arquivo do Azure são implantados em contas de armazenamento, que são objetos de nível superior que representam um pool de armazenamento compartilhado. Este pool de armazenamento pode ser usado para implantar vários compartilhamentos de arquivos. O Azure oferece suporte a vários tipos de contas de armazenamento para diferentes cenários de armazenamento que os clientes podem ter. Para o armazenamento de arquivos do SAP BusinessObjects, você precisa criar uma conta FileStorage. Use-a para implantar compartilhamentos de arquivos do Azure em hardware com base em SSD Premium.

Observação

As contas FileStorage só podem ser usadas para armazenar compartilhamentos de arquivos do Azure. Nenhum outro recurso de armazenamento, como blobs, contêineres, filas ou tabelas, pode ser implantado em uma conta FileStorage.

A conta de armazenamento é acessada por meio de um ponto de extremidade privado e implantada na mesma rede virtual de uma plataforma SAP BOBI. Com essa configuração, o tráfego do seu sistema SAP nunca sai dos limites de segurança da rede virtual. Os sistemas SAP geralmente contêm dados confidenciais e críticos para os negócios, e permanecer dentro dos limites da rede virtual é uma consideração de segurança importante para muitos clientes.

Se precisar acessar a conta de armazenamento de uma rede virtual diferente, você pode usar o peering da Rede Virtual do Azure.

Conta de armazenamento dos Arquivos do Azure

  1. Para criar uma conta de armazenamento usando o portal do Azure, selecione Criar um recurso>Armazenamento>Conta de armazenamento.

  2. Na guiaBásico, preencha todos os campos necessários para criar uma conta de armazenamento:

    1. Escolha Assinatura>Grupo de recursos>Região.

    2. Insira o Nome da conta de armazenamento. Por exemplo, insira azusbobi. Esse nome deve ser exclusivo globalmente, mas, caso contrário, pode ser qualquer nome desejado.

    3. Escolha Premium como o nível de desempenho e FileStorage como o tipo de conta.

    4. Para o rótulo Replicação, escolha nível de redundância. selecione LRS (armazenamento com redundância local).

      Para FileStorage Premium, ZRS e LRS são as únicas opções disponíveis. Com base em sua estratégia de implantação de VM (conjunto de dimensionamento flexível, zona de disponibilidade ou conjunto de disponibilidade), escolha o nível de redundância apropriado. Para mais informações, confira Redundância do Armazenamento do Microsoft Azure.

    5. Selecione Avançar.

  3. Na guia Rede, escolha Ponto de extremidade privado como o método de conectividade. Confira Considerações de rede dos Arquivos do Azure para mais informações.

    1. Selecione Adicionar na seção endpoint privado.

    2. Selecione Assinatura>Grupo de recursos>Local.

    3. Insira o Nome do ponto de extremidade privado. Por exemplo, insira azusbobi-pe.

    4. Selecione arquivo no sub-recurso de armazenamento.

    5. Na seção Rede, escolha a Rede virtual e a Sub-rede na qual o aplicativo SAP BusinessObjects BI está implantado.

    6. Aceite o padrão (sim) para integrar-se com a zona DNS privada.

    7. Escolha a zona DNS privada na lista suspensa.

    8. Escolha OKpara voltar para a guia Rede em Criar conta de armazenamento.

  4. Na guiaProteção de dados configure a política de exclusão reversível para compartilhamentos de arquivos do Azure na conta de armazenamento. Por padrão, a funcionalidade de exclusão reversível está desativada. Para saber mais sobre a exclusão temporária, confira Impedir a exclusão acidental de compartilhamentos de arquivo do Azure.

  5. Na guia Avançado, escolha opções de segurança diferentes.

    O campo Transferência segura necessária indica se a conta de armazenamento requer criptografia em trânsito para comunicação com a conta de armazenamento. Se precisar de suporte para o SMB 2.1, você deve desabilitar este campo. Para a plataforma SAP BOBI, mantenha-a como padrão (habilitada) .

  6. Continue e crie a conta de armazenamento.

Para detalhes sobre como criar uma conta de armazenamento, confira Criar uma conta de armazenamento FileStorage.

Criar Compartilhamentos de Arquivos do Azure

A próxima etapa é criar compartilhamentos de arquivos do Azure na conta de armazenamento. Os compartilhamentos de arquivos do Azure usam um modelo provisionado para compartilhamentos de arquivos premium. Em um modelo de negócios provisionado, você especifica proativamente para o serviço arquivos do Azure quais são seus requisitos de armazenamento, em vez de ser cobrado com base no que você usa. Para entender mais sobre esse modelo, confira Modelo provisionado. Neste exemplo, você cria dois compartilhamentos de arquivos do Azure: frsinput (256 GB) e frsoutput (256 GB) para o armazenamento de arquivos SAP BOBI.

  1. Navegue até a conta de armazenamento azusbobi>Compartilhamento de arquivos.
  2. Escolha Novo compartilhamento de arquivos.
  3. Insira o Nome do compartilhamento de arquivo. Por exemplo, insira frsinput ou frsoutput.
  4. Insira o tamanho do compartilhamento de arquivo necessário na capacidade provisionada. For exemplo, insira 256 GB.
  5. Selecione SMB como Protocolo.
  6. Selecione Criar.

Configurar um disco de dados em uma VM do Windows

As etapas nesta seção usam os seguintes prefixos:

[A] : a etapa aplica-se a todos os hosts.

Inicializar um novo disco de dados

O aplicativo de BI SAP BusinessObjects requer uma partição na qual seus binários podem ser instalados. Você pode instalar um aplicativo SAP BOBI na partição do sistema operacional (C:), mas certifique-se de ter espaço suficiente para a implantação e o sistema operacional. É recomendável que você tenha pelo menos 2 GB disponíveis para arquivos temporários e aplicativos Web. Além disso, recomendamos que você separe binários de instalação do SAP BOBI em partições separadas.

Neste exemplo, um aplicativo SAP BOBI será instalado em uma partição separada (F:). Inicialize o SSD Premium que você anexou durante o provisionamento de VM:

  1. [A] Se nenhum disco de dados estiver anexado à VM (azuswinboap1 e azuswinboap2), siga as etapas em Adicionar um disco de dados para anexar um novo disco de dados gerenciado.
  2. [A] Depois que o disco gerenciado for anexado à VM, inicialize o disco seguindo as etapas em Inicializar um novo disco de dados.

Montar Arquivos Premium do Azure

Para usar os Arquivos do Azure como um armazenamento de arquivos, você deve montá-lo, o que significa atribuir a ele uma letra de unidade ou um caminho de ponto de montagem.

[A] Para montar o compartilhamento de arquivo do Azure, siga as etapas em Montar o compartilhamento de arquivo do Azure.

Para montar um compartilhamento de arquivo do Azure em um servidor Windows, o protocolo SMB requer que a porta TCP 445 esteja aberta. As conexões falharão se a porta 445 estiver bloqueada. Você pode verificar se o firewall ou o ISP está bloqueando a porta 445 usando o Test-NetConnection cmdlet. Confira A porta 445 está bloqueada.

Configurar um banco de dados CMS: SQL do Azure

Esta seção apresenta detalhes sobre como provisionar o SQL do Azure usando o portal do Azure. Ela também apresenta instruções sobre como criar o CMS e o bancos de dados de auditoria para a plataforma SAP BOBI e uma conta de usuário para acessar os bancos de dados.

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

Criar um servidor do Banco de Dados SQL

O Banco de Dados SQL oferece diferentes opções de implantação: banco de dados individual, pool elástico e servidor de banco de dados. Para uma plataforma SAP BOBI, você precisa de dois bancos de dados, CMS e auditoria. Em vez de criar dois bancos de dados individuais, você pode criar um servidor do Banco de Dados SQL do Microsoft Azure que possa gerenciar o grupo de bancos de dados individuais e pools elásticos. Siga estas etapas para criar um servidor do Banco de Dados SQL do Microsoft Azure:

  1. Navegue até a página Selecionar uma opção de implantação do SQL.

  2. Em Bancos de dados SQL, mude o Tipo de recurso para Servidor de banco de dados. Selecione Criar.

  3. Na guia Noções básicas , conclua todos os campos necessários para criar o SQL Database Server:

    1. Em Detalhes do projeto, escolha a Assinatura e o Grupo de recursos.

    2. Insira um Nome de servidor. Por exemplo, insira azussqlbodb. Esse nome do servidor deve ser globalmente exclusivo, mas, caso contrário, você pode informar qualquer nome desejado.

    3. Selecione o Local.

    4. Insira o Logon do administrador do servidor. Por exemplo, digite boadmin. Insira uma Senha.

  4. Na guia Rede, altere Permitir que os serviços e recursos do Azure acessem este servidor para Nenhuma emRegras de firewall.

  5. Em configurações adicionais, mantenha as configurações padrão.

  6. Continue e crie o Servidor SQL de Banco de Dados.

Na próxima etapa, crie o CMS e os bancos de dados de auditoria no servidor do Banco de Dados SQL (azussqlbodb.database.windows.net).

Criar o CMS e o banco de dados de auditoria

Depois de provisionar o servidor do Banco de Dados SQL do Microsoft Azure, navegue até o recurso azussqlbodb. Em seguida, siga estas etapas para criar os bancos de dados de CMS e de auditoria.

  1. Na página Visão geral do azussqlbodb, escolha Criar banco de dados.

  2. Na guia Noções básicas , conclua todos os campos necessários:

    1. Insira o Nome do banco de dados. Por exemplo, introduza bocms ou boaudit.

    2. Na opção Computação + armazenamento, escolha Configurar banco de dados. Escolha o modelo apropriado com base no resultado do dimensionamento. Para saber mais sobre as opções, confira Modelos de dimensionamento para Banco de Dados SQL do Azure.

  3. Na guia Rede, escolha ponto de extremidade privado como o método de conectividade. O ponto de extremidade privado é usado para acessar o Banco de Dados SQL na rede virtual configurada.

    1. SelecioneAdicionar ponto de extremidade privado.

    2. Selecione Assinatura>Grupo de recursos>Local.

    3. Insira o Nome do ponto de extremidade privado. Por exemplo, insira azusbodb-pe.

    4. Em Sub-recurso de destino, escolha SqlServer.

    5. Na seção Rede, escolha a Rede virtual e a Sub-rede na qual o aplicativo SAP BusinessObjects BI está implantado.

    6. Aceite o padrão (sim) para integrar com a zona DNS privada.

    7. Escolha a zona DNS privada na lista suspensa.

    8. Escolha OKpara voltar para a guia Rede em Criar banco de dados SQL.

  4. Na guia Configurações adicionais, mude o Agrupamento para SQL_Latin1_General_CP850_BIN2.

  5. Continue e crie o banco de dados de CMS.

Da mesma forma, você pode criar o banco de dados de auditoria. Por exemplo, digite boaudit.

Faça download e instale um driver ODBC

Os servidores de aplicativos SAP BOBI exigem clientes/drivers de banco de dados para acessar o banco de dados de CMS ou de auditoria. O driver ODBC da Microsoft é usado para acessar os bancos de dados de CMS e de auditoria em execução no Banco de Dados SQL do Azure. Esta seção apresenta instruções sobre como fazer download e configurar um driver ODBC no Windows.

  1. Confira a seção Suporte de repositório CMS + Auditoria por SO em Matriz de disponibilidade de produto (PAM) para a Plataforma SAP BusinessObjects BI para descobrir os conectores de banco de dados compatíveis com o Banco de Dados SQL do Azure.
  2. Baixe o ODBC driver. Neste exemplo, este artigo usa o driver ODBC 13.1.
  3. Instale o driver ODBC em todos os servidores de BI (azuswinboap1 e azuswinboap2).
  4. Depois de instalar o driver no azuswinboap1, acesse Iniciar>Ferramentas administrativas do Windows>Fontes de dados ODBC (64 bits) .
  5. Vá para a guia DSN do sistema.
  6. Escolha Adicionar para criar uma conexão com o banco de dados de CMS.
  7. Selecione Driver ODBC 13 para SQL Servere selecione Concluir.
  8. Insira as informações do banco de dados de CMS como a seguir e escolha Avançar:
    • Nome: o nome do banco de dados criado na seção "Criar o CMS e o banco de dados de auditoria". Por exemplo, enter bocms ou boaudit.
    • Descrição: uma descrição que descreve a fonte de dados. Por exemplo, insira Banco de dados de CMS ou Banco de dados de auditoria.
    • Servidor: o nome do servidor criado na seção "Criar um servidor do Banco de Dados SQL". Por exemplo, insira azussqlbodb.database.windows.net.
  9. Escolha Com a autenticação do SQL Server usando uma ID de logon e senha inseridas pelo usuário para verificar a autenticidade do Azure SQL Server. Insira a credencial do usuário que foi criada no momento da criação do servidor do Banco de Dados SQL do Microsoft Azure. Por exemplo, digite boadmin. Selecione Avançar.
  10. Altere o banco de dados padrão para bocmse mantenha todo o resto como padrão. Selecione Avançar.
  11. Marque a caixa de seleção Usar criptografia forte para dados e mantenha todo o restante como padrão. Selecione Concluir.
  12. A fonte de dados para o banco de dados CMS é criada. Agora você pode selecionar a Fonte de Dados de Teste para validar a conexão com o banco de dados CMS no aplicativo de BI. O teste deve ser concluído com êxito. Se falhar, solucione o problema de conectividade.

Observação

O Banco de Dados SQL se comunica pela porta 1433. O tráfego de saída pela porta 1433 deve ser permitido a partir de seus servidores de aplicação SAP BOBI.

Repita as etapas anteriores para criar uma conexão para o banco de dados de auditoria no servidor azuswinboap1. Da mesma forma, instale e configure fontes de dados ODBC (bocms e boaudit) em todos os servidores de aplicativos de BI (azuswinboap2).

Preparação do servidor

Siga o guia mais recente da SAP para preparar servidores para a instalação da plataforma de BI. Para obter as informações mais atualizadas, confira a seção "Preparação" no Guia de instalação da plataforma SAP Business Intelligence para Windows.

Instalar a plataforma de BI em um host do Windows

Para instalar a plataforma de BI em um host do Windows, entre com um usuário que tenha privilégios administrativos locais.

Acesse a mídia da plataforma SAP BusinessObjects BI e execute setup.exe.

Siga as instruções no Guia de instalação da plataforma SAP Business Intelligence para Windows que são específicos para sua versão. Aqui estão alguns pontos a serem observados enquanto você instala a plataforma SAP BOBI no Windows:

  • Na tela Configurar Pasta de Destino, informe a pasta de destino na qual você gostaria de instalar a plataforma de BI. Por exemplo, insira F:\SAP BusinessObjects*.

  • Na tela Configurar Registro do Produto, você pode usar a chave de licença temporária para soluções SAP BusinessObjects da SAP Note 1288121 ou gerar a chave de licença no SAP Service Marketplace.

  • Na tela Selecionar tipo de instalação, escolha instalação Completa no primeiro servidor (azuswinboap1). Para o outro servidor (azuswinboap2), escolha Personalizado/Expandir, que expande a configuração existente do SAP BOBI.

  • Na tela Selecionar banco de dados padrão ou existente, escolha Configurar um banco de dados existente, que solicita que você escolha o banco de dados de CMS e de auditoria. Escolha Microsoft SQL Server usando ODBC para o tipo de Banco de dados de CMS e tipo de Banco de dados de auditoria.

    Você também poderá escolher Sem banco de dados de auditoria se não quiser configurar a auditoria durante a instalação.

  • Escolha as opções apropriadas na tela Selecionar o Servidor de Aplicativos Web Java com base em sua arquitetura SAP BOBI. Neste exemplo, a opção 1 está selecionada, que instala um servidor Tomcat na mesma plataforma SAP BOBI.

  • Insira as informações do banco de dados CMS em Configurar Banco de Dados do Repositório CMS – SQL Server (ODBC) . A imagem a seguir mostra a entrada de exemplo para informações de banco de dados CMS para uma instalação do Windows.

    Captura de tela que mostra as informações do banco de dados de CMS para Windows.

  • (Opcional) Insira informações do banco de dados de auditoria em Configurar Banco de Dados de Auditoria – SQL Server (ODBC) . A imagem a seguir mostra a entrada de exemplo para informações de banco de dados de auditoria para uma instalação do Windows.

    Captura de tela que mostra as informações do banco de dados de auditoria para Windows.

  • Conclua a instalação seguindo as instruções e insira as entradas necessárias.

Para uma implantação de várias instâncias, execute a configuração de instalação no segundo host (azuswinboap2). Na tela Selecionar tipo de instalação, escolha Personalizado/Expandir, que expande a configuração existente do SAP BOBI. Para obter mais informações, confira o blog do SAP Instalação da plataforma de Business Intelligence SAP BusinessObjects com o Banco de Dados SQL do Azure.

Importante

Os números de versão do mecanismo de banco de dados para SQL Server e Banco de Dados SQL não são comparáveis entre si. Eles são números de compilação internos para esses produtos separados. O mecanismo de banco de dados para o Banco de Dados SQL se baseia na mesma base de código do mecanismo de banco de dados do SQL Server. O mais importante é que o mecanismo de banco de dados do Banco de Dados SQL sempre tem os bits mais recentes do mecanismo de Banco de Dados SQL. A versão 12 do Banco de Dados SQL é mais recente do que a versão 15 do SQL Server.

Para descobrir a versão atual do Banco de Dados SQL do Azure, você pode verificar as configurações do CMC (console de gerenciamento central) ou executar a consulta a seguir usando sqlcmd ou SQL Server Management Studio. O alinhamento das versões do SQL à compatibilidade padrão pode ser encontrado no artigo Nível de compatibilidade do banco de dados.

Captura de tela que mostra informações do banco de dados em CMC. 

1> select @@version as version;
2> go
version
------------------------------------------------------------------------------------------
Microsoft SQL Azure (RTM) - 12.0.2000.8
        Feb 20 2021 17:51:58
        Copyright (C) 2019 Microsoft Corporation

(1 rows affected)

1> select name, compatibility_level from sys.databases;
2> go
name                                                                  compatibility_level
--------------------------------------------------------------------- -------------------
master                                                                                150
bocms                                                                                 150
boaudit                                                                               150

(3 rows affected)

Pós-instalação

Após a instalação de várias instâncias da plataforma SAP BOBI, mais etapas de pós-configuração precisam ser executadas para dar suporte à alta disponibilidade do aplicativo.

Configurar um nome de cluster

Na 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 de sistema CMS comum. 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, em uma plataforma SAP BOBI, um nome de cluster reflete o nome do host do primeiro CMS que você instala.

Para configurar o nome do cluster no Windows, siga as instruções no Guia do administrador da plataforma de Business Intelligence SAP. Depois de configurar o nome do cluster, siga a SAP Note 1660440 para definir a entrada padrão do sistema no CMC ou na página de login no BI Launchpad.

Configurar o local do filestore de entrada e saída para arquivos Premium do Azure

O Filestore refere-se aos diretórios de disco em que os arquivos reais de BI do SAP BusinessObjects estão. 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 repositório de arquivo em um armazenamento compartilhado, como Arquivos Premium do Azure ou Azure NetApp Files para que possa ser acessado de todos os servidores da camada de armazenamento.

  1. Se não for criado, siga as instruções fornecidas na seção anterior, "Provisionar Arquivos Premium do Azure", para criar e montar Arquivos Premium do Azure.

    Dica

    Com base em se a VM é implantada de maneira zonal ou regional, a seleção de redundância de armazenamento para Arquivos Premium do Azure (ZRS ou LRS) deve ser determinada.

  2. Siga a SAP Note 2512660 para mudar o caminho do repositório de arquivos (Entrada e Saída).

Clusterização do Tomcat: replicação de sessão

O Tomcat dá suporte ao clustering de dois ou mais servidores de aplicativos para replicação e failover de sessão. Se as sessões da plataforma SAP BOBI forem serializadas, uma sessão de usuário pode fazer failover diretamente para outra instância do Tomcat, mesmo quando um servidor de aplicativos falha. Por exemplo, se um usuário estiver 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 uma página de entrada.

Na SAP Note 2808640, as etapas para configurar o clustering do Tomcat são fornecidas usando multicast. No entanto, no Azure, não há suporte para multicast. Para que o cluster do Tomcat funcione no Azure, você deve usar StaticMembershipInterceptor (SAP Note 2764907).

Para configurar um cluster do Tomcat no Azure, consulte Clustering do Tomcat com associação estática para a plataforma de BI SAP BusinessObjects no blog da SAP.

Balancear a carga de uma camada web de uma plataforma SAP BI

Em uma implantação de várias instâncias do SAP BOBI, os servidores de aplicativos Web Java (camada da Web) estão em execução em dois ou mais hosts. Para distribuir a carga de usuário uniformemente entre servidores Web, você poderá usar um balanceador de carga entre usuários finais e servidores Web. Você pode usar o Azure Load Balancer ou o Gateway de Aplicativo para gerenciar o tráfego para seus servidores de aplicativos Web. As ofertas são explicadas nas seguintes seções:

  • O Load Balancer é um balanceador de carga de camada 4 (TCP, UDP) de baixa latência e alto desempenho que distribui o tráfego entre VMs íntegras. Uma sonda de integridade do balanceador de carga monitora uma porta específica em cada VM e distribui o tráfego somente para as VMs operacionais. Você pode escolher um balanceador de carga público ou um balanceador de carga interno, dependendo se deseja que a plataforma SAP BI seja acessível pela Internet ou não. Ele tem redundância de zona, o que garante alta disponibilidade entre zonas de disponibilidade.

    Na figura a seguir, consulte a seção "Balanceador de Carga Interno" em que o servidor de aplicativos Web é executado na porta 8080. Essa porta é a porta padrão HTTP do Tomcat que uma sonda de verificação de integridade monitora. Qualquer solicitação recebida dos usuários é redirecionada para os servidores de aplicativos Web (azuswinboap1 ou azuswinboap2) no pool de back-end. O Load Balancer não permite terminação TLS/SSL, que também é conhecida como descarregamento de TLS/SSL. Caso você esteja usando o Load Balancer para distribuir o tráfego entre servidores Web, recomendamos usar o Standard Load Balancer.

    Observação

    Quando VMs sem endereços IP públicos são colocadas no pool de back-end do Standard Load Balancer (sem endereço IP público), não há conectividade de saída com a Internet, a menos que você execute uma configuração extra para permitir o roteamento para pontos de extremidade públicos. Para obter informações sobre como obter conectividade de saída, consulte Conectividade de ponto de extremidade público para VMs usando o Azure Standard Load Balancer em cenários de alta disponibilidade SAP.

    Captura de tela que mostra o Load Balancer usado para balancear o tráfego entre servidores Web.

  • O Gateway de Aplicações oferece o controlador de entrega de aplicações como um serviço, que é usado para ajudar as aplicações a direcionar o tráfego de usuários para um ou mais servidores de aplicações web. Ele oferece vários recursos de balanceamento de carga da camada 7, como descarregamento de TLS/SSL, Firewall de Aplicativo Web e afinidade de sessão baseada em cookies para seus aplicativos.

    Em uma plataforma SAP BI, o Gateway de Aplicativo direciona o tráfego da Web do aplicativo para os recursos especificados em um pool de back-end. Nesse caso, é azuswinboap1 ou azuswinboap2. Você atribuirá um ouvinte à porta, criará regras e adicionará recursos a um pool de back-end. Na figura a seguir, o Gateway de Aplicativo com um endereço IP de front-end privado (10.31.3.25) age como um ponto de entrada para usuários, lida com conexões de entrada TLS/SSL (HTTPS – TCP/443), descriptografa o TLS/SSL e passa a solicitação (HTTP – TCP/8080) para os servidores no pool de back-end. Com o recurso de terminação TLS/SSL integrado, você precisa manter apenas um certificado TLS/SSL no gateway de aplicativo, o que simplifica as operações.

    Captura de tela que mostra o Gateway de Aplicativo usado para equilibrar o tráfego entre servidores Web.

    Para configurar o Gateway de Aplicativo para um servidor SAP BOBI da Web, confira Balanceamento de carga de servidores SAP BOBI da Web usando Gateway de Aplicativo no blog da SAP.

    Observação

    Use o Gateway de Aplicativo para balancear a carga do tráfego para o servidor da Web porque ele fornece recursos como descarregamento de SSL, gerenciamento centralizado de SSL para reduzir a sobrecarga de criptografia e descriptografia no servidor, algoritmos round-robin para distribuir tráfego, recursos de Firewall de Aplicativo Web e alta disponibilidade.

Confiabilidade da plataforma SAP BusinessObjects BI no Azure

A plataforma SAP BusinessObjects BI inclui diferentes camadas, que são otimizadas para tarefas e operações específicas. Quando um componente de qualquer camada fica indisponível, o aplicativo SAP BOBI fica inacessível ou determinada funcionalidade do aplicativo não funciona. É necessário ter certeza de que cada camada foi projetada para ser confiável a fim de manter o aplicativo operacional sem nenhuma interrupção dos negócios.

Esta seção se concentra em como os recursos nativos do Azure combinam com uma configuração de plataforma SAP BOBI para melhorar a disponibilidade de uma implantação sap. Esta seção aborda as seguintes opções de confiabilidade da plataforma SAP BOBI no Azure:

  • Backup e restauração: este processo cria cópias periódicas de dados e aplicativos para locais separados. Se os dados originais ou aplicativos forem perdidos ou danificados, as cópias poderão ser usadas para restaurar ou recuperar para o estado anterior.
  • Alta disponibilidade: uma plataforma altamente disponível terá pelo menos dois de todos os elementos na região do Azure para manter o aplicativo operacional caso um dos servidores fique indisponível.
  • DR (recuperação de desastre) : esse processo restaura a funcionalidade do aplicativo se há perdas catastróficas. Por exemplo, uma região inteira do Azure pode ficar indisponível devido a um desastre natural.

A implementação dessa solução varia de acordo com a natureza da configuração do sistema no Azure. Você precisa adaptar suas soluções de backup e restauração, alta disponibilidade e DR com base em seus requisitos de negócios.

Backup e restauração

O processo de backup e restauração cria cópias periódicas de dados e aplicativos para um local separado. Eles poderão ser restaurados ou recuperados para um estado anterior se os dados ou aplicativos originais forem perdidos ou danificados. Também é um componente essencial de qualquer estratégia de DR de negócios. Esses backups permitem a restauração de aplicativos e do banco de dados para um ponto no tempo dentro do período de retenção configurado.

Para desenvolver uma estratégia abrangente de backup e restauração 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 componentes a seguir é fundamental para proteger o aplicativo:

  • Diretório de instalação do SAP BOBI (Discos Premium Gerenciados)
  • Repositório de arquivo (Arquivos Premium do Azure ou Azure NetApp Files para instalação distribuída)
  • CMS e banco de dados de auditoria (Banco de Dados SQL, Banco de Dados do Azure para MySQL ou um banco de dados em VMs do Azure)

A seção a seguir descreve como implementar a estratégia de backup e restauração para cada componente em uma plataforma SAP BOBI.

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

No Azure, a maneira mais simples de fazer backup de VMs e todos os discos anexados é usando o Backup do Azure. Ele fornece backups independentes e isolados para proteger contra a destruição indesejada dos dados em suas VMs. Os backups são armazenados em um cofre dos 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 podem ser facilmente restaurados conforme necessário.

Como parte do processo de backup, um instantâneo é tirado. Os dados são transferidos para o cofre dos Serviços de Recuperação sem afetar as cargas de trabalho de produção. O instantâneo fornece um nível de consistência diferente, conforme descrito no artigo Consistência do instantâneo. O backup também oferece suporte lado a lado para backup de discos gerenciados usando o Backup de disco do Azure, além da solução de Backup de VM do Azure. É útil quando você precisa de backups consistentes de VMs uma vez por dia e backups mais frequentes de discos do sistema operacional, ou de um disco de dados específico, que sejam consistentes em caso de falha. Para obter mais informações, confira Sobre o backup de VM do Azure, Backup de disco do Azure e Perguntas frequentes: backup de VMs do Azure .

Backup e restauração para repositório de arquivo

Com base em sua implantação, o armazenamento da plataforma SAP BOBI pode estar no Azure NetApp Files ou no Azure Files. Escolha entre as seguintes opções de backup e restauração com base no armazenamento que você usa para o repositório de arquivo:

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

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

Para uma plataforma SAP BOBI em execução em VMs do Windows, o CMS e o banco de dados de auditoria podem ser executados em qualquer um dos bancos de dados com suporte. Para obter mais informações, consulte a matriz de suporte no guia de planejamento e implementação da plataforma SAP BOBI no Azure. Portanto, é 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 SQL usa a tecnologia do SQL Server para criar backups completos toda semana, backups diferenciais a cada 12 a 24 horas e backups de log de transações a cada 5 a 10 minutos. A frequência dos backups de logs de transações é baseada no tamanho da computação e na quantidade de atividade do banco de dados.

    Os usuários podem escolher uma opção para configurar a redundância de armazenamento de backup entre blobs LRS, ZRS ou GRS. Os mecanismos de redundância de armazenamento armazenam várias cópias de seus dados para que eles sejam protegidos contra eventos planejados e não planejados, o que inclui falhas transitórias de hardware, interrupções de rede ou energia ou grandes desastres naturais. Por padrão, o Banco de Dados SQL armazena o backup em blobs GRS replicados para uma região emparelhada. Ele pode ser alterado com base nos requisitos de negócios para blobs LRS ou ZRS. Para obter informações mais atualizadas sobre a programação, retenção e consumo de armazenamento de backup do Banco de Dados SQL, confira Backups automatizados: Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

  • O Banco de Dados do Azure para MySQL cria automaticamente backups de servidor e armazenamentos em LRS ou GRS configurados pelo usuário. O Banco de Dados do Azure para MySQL faz backups dos arquivos de dados e do log de transações. Dependendo do tamanho máximo de armazenamento compatível, ele faz backups totais e diferenciais (servidores de armazenamento máximo de 4 TB) ou backups de instantâneo (servidores de armazenamento máximo de até 16 TB). Esses backups permitem que você restaure um servidor pontualmente dentro de seu período de retenção de backup configurado. O período de retenção de backup padrão é de sete dias, que opcionalmente você pode configurar até 35 dias. Todos os backups são criptografados usando a criptografia AES de 256 bits. Esses arquivos de backup não são expostos pelo usuário e não podem ser exportados. Os backups podem ser usados somente para operações de restauração no Banco de Dados do Azure para MySQL. Você pode utilizar mysqldump para copiar um banco de dados. Para mais informações, confira Backup e restauração no Banco de Dados do Azure para MySQL.

  • Para um banco de dados instalado em uma VM do Azure, você pode usar ferramentas de backup padrão ou Backup para bancos de dados compatíveis. Além disso, se as ferramentas e serviços do Azure não atenderem aos seus requisitos, você poderá usar ferramentas de backup de terceiros compatíveis que fornecem um agente para backup e recuperação de todos os componentes da plataforma SAP BOBI.

Alta disponibilidade

Alta disponibilidade se refere a um conjunto de tecnologias que pode minimizar as interrupções da TI, proporcionando a continuidade dos negócios em serviços ou aplicativos por meio de componentes redundantes, tolerantes a falhas ou protegidos contra failover no mesmo data center. Nesse caso, os datacenters estão dentro de uma região do Azure. O artigo Arquitetura e cenários de alta disponibilidade para SAP fornece insights sobre diferentes técnicas e recomendações de alta disponibilidade oferecidas no Azure para aplicativos SAP, que complementa as instruções nesta seção.

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 em sub-redes e VMs do Azure. O nível de redundância na arquitetura distribuída depende do objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO) exigidos pelo negócio. A plataforma SAP BOBI inclui diferentes camadas e os componentes em cada camada devem ser projetados para obter redundância. Assim, se um componente falhar, haverá pouca ou nenhuma interrupção no aplicativo SAP BOBI. Por exemplo:

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

A seção a seguir descreve como obter alta disponibilidade em cada componente da plataforma SAP BOBI.

Alta disponibilidade para servidores de aplicativos

Os servidores de aplicativos Web e BI não precisam de uma solução específica de alta disponibilidade, independentemente de eles estar instalados separadamente ou juntos. Você pode obter alta disponibilidade por redundância, ou seja, configurando várias instâncias de servidores Web e BI em várias VMs do Azure. Você pode implantar as VMs em conjunto de dimensionamento flexível, conjuntos de disponibilidade ou zonas de disponibilidade com base no RTO necessário para os negócios. Para a implantação em zonas de disponibilidade, verifique se todos os outros componentes na plataforma SAP BOBI também foram projetados para serem redundantes por zona.

Atualmente, nem todas as regiões do Azure oferecem zonas de disponibilidade, portanto, você precisa adotar a estratégia de implantação com base em sua região. As regiões do Azure que oferecem zonas são listadas em zonas de disponibilidade do Azure.

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 em ambas.
  • Se você planeja implantar em zonas de disponibilidade, recomendamos usar conjunto de escala flexível com FD=1 em vez da implantação de zona de disponibilidade padrão.

Alta disponibilidade para banco de dados CMS

Se você estiver usando um banco de dados do Azure como uma solução para seu banco de dados de CMS e de auditoria, uma estrutura de alta disponibilidade localmente redundante é fornecida por padrão. Escolha a região e os recursos inerentes de alta disponibilidade, redundância e resiliência do serviço sem exigir que você configure mais nenhum componente. Se a estratégia de implantação de uma plataforma SAP BOBI for em uma zona de disponibilidade, obtenha redundância de zona para seu banco de dados de CMS e de auditoria. Para obter mais informações sobre alta disponibilidade para ofertas de banco de dados com suporte no Azure, consulte Alta disponibilidade para o Banco de Dados SQL do Azure. Veja também, Alta disponibilidade no Banco de Dados do Azure para MySQL.

Consulte os guias de implantação do DBMS para cargas de trabalho SAP para obter informações sobre uma abordagem diferente de implantação de DBMS e seu método para alcançar alta disponibilidade para um banco de dados CMS.

Alta disponibilidade para armazenamento de arquivos

O FileStore refere-se aos diretórios de disco em que o conteúdo é armazenado, como relatórios, universos e conexões. Ele é compartilhado entre todos os servidores de aplicativos do sistema. Portanto, você deve garantir que ele esteja altamente disponível, com outros componentes da plataforma SAP BOBI.

Para uma plataforma SAP BOBI em execução no Windows, você pode escolher o Azure Premium Files ou o Azure NetApp Files para armazenamento de arquivos. Ambas as opções foram projetadas para serem altamente disponíveis e altamente duráveis. Os Arquivos Premium do Azure são compatíveis com ZRS, que pode ser útil para a implantação entre zonas de uma plataforma SAP BOBI. Para mais informações, confira a seção Redundância para Arquivos do Azure.

Como o serviço de compartilhamento de arquivos não está disponível em todas as regiões, confira a lista de 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 no qual é possível compartilhar o sistema de arquivos para um aplicativo SAP BOBI. Mas você também precisa considerar sua alta disponibilidade.

Alta disponibilidade para o balanceador de carga

Para distribuir o tráfego em um servidor da Web, você pode usar o Load Balancer ou o Gateway de Aplicativo. A redundância para qualquer um dos balanceadores de carga pode ser obtida com base no SKU escolhido para implantação:

  • Load Balancer: a redundância pode ser obtida configurando o front-end do Standard Load Balancer com redundância de zona. Para mais informações, confira Standard Load Balancer e zonas de disponibilidade.

  • Gateway de Aplicativo: a alta disponibilidade pode ser alcançada com base no tipo de camada selecionada durante a implantação:

    • O SKU v1 dá suporte a cenários de alta disponibilidade ao implantar duas ou mais instâncias. O Azure distribui essas instâncias entre domínios de atualização e de falha para garantir que todas as instâncias não falham ao mesmo tempo. Com esse SKU, a redundância pode ser alcançada dentro da zona.

    • O SKU v2 garante automaticamente que novas instâncias sejam distribuídas entre domínios de falha e domínios de atualização. Se a redundância de zona for escolhida, as instâncias mais recentes também serão distribuídas entre as zonas de disponibilidade para oferecer resiliência em caso de falhas nas zonas. Para obter mais informações, confira Dimensionamento automático e o Gateway de Aplicativo com redundância de zona v2.

Arquitetura de alta disponibilidade de referência para plataforma de BI SAP BusinessObjects

A arquitetura de referência a seguir descreve a configuração de uma plataforma SAP BOBI entre zonas de disponibilidade em execução em um servidor Windows. A arquitetura demonstra o uso de diferentes serviços do Azure, como Gateway de Aplicativo, Arquivos Premium do Azure (repositório de arquivos) e Banco de Dados SQL (banco de dados de CMS e de auditoria). A plataforma SAP BOBI oferece redundância de zona integrada, o que reduz a complexidade do gerenciamento de diferentes soluções de alta disponibilidade.

Na figura a seguir, o tráfego de entrada (HTTPS – TCP/443) tem balanceamento de carga usando o SKU v2 do Gateway de Aplicativo, que abrange várias zonas de disponibilidade. O gateway de aplicativo distribui a solicitação do usuário entre servidores Web, que são distribuídos entre zonas de disponibilidade. O servidor Web encaminha a solicitação para gerenciamento e processamento de instâncias de servidor que são implantadas em VMs separadas entre zonas de disponibilidade. Os arquivos premium do Azure com ZRS são anexados a VMs de camada de gerenciamento e armazenamento por meio de um link privado para acessar conteúdos como relatórios, ambientes, e conexões. O aplicativo acessa o banco de dados de CMS e de auditoria em execução em uma instância com redundância de zona do Banco de Dados SQL, que replica bancos de dados em vários locais físicos em uma região do Azure.

Diagrama que mostra a arquitetura de alta disponibilidade para uma plataforma SAP BOBI no Windows.

A arquitetura acima apresenta informações sobre como a implantação do SAP BOBI no Azure pode ser feita. Mas ela não cobre todas as opções de configuração possíveis para uma plataforma SAP BOBI no Azure. Você pode personalizar sua implantação com base em seus requisitos de negócios, escolhendo diferentes produtos ou serviços para componentes como Load Balancer, servidor do repositório de arquivos e gerenciador de banco de dados.

Se as zonas de disponibilidade não estiverem disponíveis em sua região escolhida, você pode implantar VMs do Azure em conjuntos de disponibilidade. O Azure garante que as VMs que você coloca em um conjunto de disponibilidade sejam executadas em vários servidores físicos, racks de computação, unidades de armazenamento e comutadores de rede. Se uma falha de hardware ou de software ocorrer, somente um subconjunto de suas VMs será afetado e a solução geral permanecerá operacional.

Recuperação de desastre

Esta seção explica a estratégia para oferecer proteção de DR para uma plataforma SAP BOBI. Ele complementa o artigo Recuperação de Desastre para SAP, que é o principal recurso para uma abordagem geral de SAP DR. Para a plataforma SAP BOBI, confira a SAP Note 2056228, que descreve os seguintes métodos para implementar um ambiente de DR com segurança:

  • Use total ou seletivamente o Gerenciamento do ciclo de vida ou federação para promover ou distribuir o conteúdo do sistema primário.
  • Copie periodicamente os conteúdos do CMS e do FRS.

Nesta seção, a segunda opção é abordada para implementar um ambiente de recuperação de desastre. Este artigo não aborda uma lista completa de todas as opções de configuração possíveis para DR, mas aborda uma solução que apresenta serviços nativos do Azure em combinação com a configuração da plataforma SAP BOBI.

Importante

  • A disponibilidade de cada componente na plataforma SAP BOBI deve ser considerada para a região secundária. Toda a estratégia de DR deve ser completamente testada.
  • Se a plataforma SAP BI estiver configurada com um conjunto de dimensionamento flexível com FD=1, você precisará usar o PowerShell para configurar o Azure Site Recovery para recuperação de desastre.

Arquitetura de referência de DR para uma plataforma de BI SAP BusinessObjects

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 DR, você deve fazer failover de todos os componentes da plataforma SAP BOBI para uma região secundária. Na figura a seguir, os Arquivos Premium do Azure são usados como o repositório de arquivos, o Banco de Dados SQL é usado como o CMS e o repositório de auditoria, e o Gateway de Aplicativo é usado para balancear a carga do tráfego. A estratégia para obter proteção de DR para cada componente é diferente, que é descrita na seção a seguir.

Diagrama que mostra a DR da plataforma de BI SAP BusinessObjects para Windows.

Load Balancer

O Load Balancer é usado para distribuir o tráfego entre servidores de aplicativos Web da plataforma SAP BOBI. No Azure, você pode usar o Load Balancer ou o Gateway de Aplicativo para balancear a carga do tráfego em servidores Web. Para obter DR para os serviços do balanceador de carga, você precisa implementar outro balanceador de carga ou gateway de aplicativo em uma região secundária. Para manter a mesma URL após o failover de DR, mude a entrada no DNS e aponte para o serviço de balanceamento de carga executado na região secundária.

VMs que executam servidores de aplicativos Web e BI

O Azure Site Recovery pode ser usado para replicar VMs que executam servidores de aplicativos Web e de BI na região secundária. O Site Recovery replica os servidores e todos os discos gerenciados anexados à região secundária. Quando ocorrem desastres ou interrupções, você pode fazer failover facilmente para o ambiente replicado e continuar trabalhando. Para começar a replicar todas as VMs do aplicativo SAP para o datacenter de DR do Azure, siga as diretrizes em Replicar uma VM para o Azure.

Diretório de disco de armazenamento de arquivos

Filestore é um diretório de disco em que arquivos reais, como relatórios e documentos de BI, são armazenados. Verifique se todos os arquivos no repositório de arquivos estão sincronizados com a região de recuperação de desastre. A estratégia de recuperação de desastre usada para sincronizar o conteúdo depende do tipo de serviço de compartilhamento de arquivos para sua plataforma SAP BOBI no Windows. Por exemplo:

  • Os Arquivos Premium do Azure só são compatíveis com LRS e ZRS. Para a estratégia de DR de Arquivos do Azure Premium, você pode usar AzCopy ou o Azure PowerShell para copiar os arquivos para outra conta de armazenamento em uma região diferente. Para saber mais, confira Recuperação de desastre e failover da conta de armazenamento.

  • O Azure NetApp Files fornece volumes NFS e SMB. Portanto, qualquer ferramenta de cópia baseada em arquivo pode ser usada para replicar dados entre regiões do Azure. Para mais informações sobre como copiar o volume Azure NetApp Files em outra região, confira Perguntas frequentes sobre o Azure NetApp Files.

    Você pode usar a replicação entre regiões do Azure NetApp Files, que usa a tecnologia SnapMirror do NetApp. Com essa tecnologia, apenas blocos de alterações são enviados pela rede em um formato compactado eficiente. Essa tecnologia exclusiva minimiza a quantidade de dados necessária para replicar entre as regiões, economizando nos custos de transferência de dados. Além disso, reduz o tempo de replicação para que você possa ter um RPO menor. Para mais informações, confira Requisitos e considerações para usar a replicação entre regiões.

Banco de dados do CMS

O banco de dados de CMS e de auditoria na região de DR 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 copiar o banco de dados para uma região de DR com base no RTO e RPO necessários para os negócios. Esta seção descreve as diferentes opções disponíveis para cada solução de banco de dados no Azure com suporte para um aplicativo SAP BOBI em execução no Windows.

Banco de Dados SQL do Azure

Para uma estratégia de DR do Banco de Dados SQL, duas opções estão disponíveis para copiar o banco de dados para a região secundária. Ambas as opções de recuperação oferecem diferentes níveis de RTO e RPO. Para mais informações sobre o RTO e o RPO para cada opção de recuperação, confira Recuperar um banco de dados em um servidor existente.

Opção 1: restauração de backup de banco de dados com redundância geográfica

  • Por padrão, o Banco de Dados SQL armazena os dados em blobs GRS replicados para uma região emparelhada. Para um banco de dados SQL, a redundância de armazenamento de backup pode ser configurada no momento da criação do CMS e da auditoria do banco de dados. Ele também pode ser atualizado para um banco de dados existente. As mudanças feitas em um banco de dados existente se aplicam apenas a backups futuros. Você pode restaurar um banco de dados em qualquer banco de dados SQL em qualquer região do Azure a partir dos backups replicados geograficamente mais recentes. A restauração geográfica usa um backup de replicação geográfica como origem. Ocorre um atraso entre o tempo em que o sistema cria um backup e a hora em que replica geograficamente o backup para um blob do Azure em uma região diferente. Como resultado, o banco de dados restaurado pode ter até uma hora de atraso em relação ao banco de dados original.

    Importante

    A restauração geográfica está disponível para os bancos de dados SQL configurados com armazenamento de backup com redundância geográfica.

Opção 2: replicação geográfica ou um grupo de failover automático

  • A replicação geográfica é um recurso de Banco de Dados SQL que permite que você crie bancos de dados secundários legíveis de bancos de dados individuais em um servidor na mesma ou em uma região diferente. Se a replicação geográfica estiver habilitada para o banco de dados de CMS e auditoria, o aplicativo poderá iniciar o failover para um banco de dados secundário em uma região do Azure diferente. A replicação geográfica está habilitada para bancos de dados individuais. Para habilitar o failover transparente e coordenado de vários bancos de dados (CMS e auditoria) para um aplicativo SAP BOBI, recomendamos que você use um grupo de failover automático. Ele fornece a semântica de grupo sobre a replicação geográfica ativa, o que significa que todo o servidor SQL (todos os bancos de dados) é replicado para outra região em vez de bancos de dados individuais. Verifique a tabela de funcionalidades que compara a replicação geográfica com grupos de failover.

  • Os grupos de failover automático fornecem pontos de extremidade de ouvinte de leitura/gravação e somente leitura que permanecem inalterados durante failovers. O ponto de extremidade de leitura/gravação pode ser mantido como ouvinte na entrada de conexão ODBC para o banco de dados de CMS e de auditoria. Não importa se você usa a ativação de failover manual ou automática, o failover alterna todos os bancos de dados secundários no grupo para primário. Após a conclusão da comutação por falha do banco de dados, o registro DNS é atualizado automaticamente para redirecionar os endpoints para a nova região. O aplicativo é conectado automaticamente ao banco de dados de CMS, pois o ponto de extremidade de leitura/gravação é mantido como um ouvinte na conexão ODBC.

    Na imagem a seguir, um grupo de failover automático para o servidor SQL (azussqlbodb) em execução na região Leste dos EUA 2 é replicado para a região secundária do Leste dos EUA (site de DR). O ponto de extremidade do ouvinte de leitura/gravação é mantido como um ouvinte em uma conexão ODBC para o servidor de aplicativos do BI em execução no Windows. Após o failover, o ponto de extremidade permanece o mesmo. Nenhuma intervenção manual é necessária para conectar o aplicativo de BI ao banco de dados SQL na região secundária.

    Captura de tela que mostra os grupos de failover automático do Banco de Dados SQL.

    Essa opção fornece um RTO e RPO menores do que a opção 1. Para obter mais informações sobre essa opção, consulte Usar grupos de failover automático para habilitar o failover transparente e coordenado de vários bancos de dados.

Banco de Dados do Azure para MySQL

O Banco de Dados MySQL do Azure oferece várias opções para recuperar o banco de dados se houver qualquer desastre. Escolha a opção apropriada que funciona para sua empresa:

  • Habilite as réplicas de leitura entre regiões para aprimorar a continuidade dos negócios e o planejamento de DR. Você pode replicar de um servidor de origem para até cinco réplicas. As réplicas de leitura são atualizadas de forma assíncrona usando o Banco de Dados do Azure para MySQL de replicação de log binário. As réplicas são novos servidores que você gerencia de modo semelhante aos servidores normais do Banco de Dados do Azure para PostgreSQL. Para saber mais sobre réplicas de leitura, regiões disponíveis, restrições e como realizar um failover, confira Réplicas de leitura no Banco de Dados do Azure para MySQL.

  • Use o recurso de restauração geográfica do Banco de Dados do Azure para MySQL, que restaura o servidor usando backups com redundância geográfica. Esses backups serão acessíveis mesmo quando a região em que seu servidor está hospedado estiver offline. É possível restaurar a partir desses backups para qualquer outra região e retornar o servidor para online.

    Importante

    A restauração geográfica somente será possível se o servidor foi provisionado com armazenamento de backup com redundância geográfica. Não há compatibilidade com a alteração das opções de redundância de backup após a criação do servidor. Para obter mais informações, confira Redundância de backup.

A tabela a seguir lista as recomendações de DR para cada camada usada neste exemplo.

Camadas da plataforma SAP BOBI Recomendação
Gateway de Aplicativo do Azure ou Balanceador de Carga do Azure Configuração paralela do Gateway de Aplicativo em uma região secundária
Servidores de aplicativo Web Replicar usando o Azure Site Recovery
Servidores de aplicativo de BI Replicar usando o Site Recovery
Arquivos Premium do Azure AzCopy ou Azure PowerShell
Azure NetApp Files Ferramenta de cópia baseada em arquivo para replicar dados para uma região secundária ou replicação entre regiões do Azure NetApp Files
Banco de Dados SQL do Azure Replicação geográfica/grupos de failover automático ou restauração geográfica.
Banco de Dados do Azure para MySQL Réplicas de leitura entre regiões ou Restaurar backups com redundância geográfica

Conteúdo relacionado

  • Last updated on