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

  • Artigo

Este artigo descreve a estratégia para implantar a plataforma SAP BusinessObjects Business Intelligence (SAP 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 armazenamento de arquivos compartilhado entre 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.

Diagram that shows an SAP BOBI deployment on Azure for Windows.

Neste exemplo, as seguintes versões de produto e layout do sistema de arquivos são usados:

  • Plataforma SAP BusinessObjects 4.3 SP01 Patch 1
  • Windows Server 2019
  • Banco de Dados SQL (versão: 12.0.2000.8)
  • Driver ODBC da Microsoft – msodbcsql.msi (versão: 13.1)
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 gerenciados SSD Premium do Azure
\\azusbobi.file.core.windows.net\frsinput O diretório de montagem é para os arquivos compartilhados em todos os hosts SAP BOBI que serão usados como diretório do Filestore de Entrada. 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 serão usados como diretório do Filestore de Saída. Necessidade comercial Privilégios administrativos locais Azure NetApp Files

Implantar uma máquina virtual Windows por meio do portal do Azure

Nesta seção, criaremos duas VMs com uma imagem do SO (sistema operacional) Windows 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 de BI SAP, você precisa criar sub-redes múltiplas. Nesta implantação, criaremos duas sub-redes: sub-rede do aplicativo de BI e 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 de seus servidores de aplicativos 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 preferida em uma região do Azure, quer envolva a extensão entre zonas, residindo em uma única zona ou operando em uma região sem zona.

  4. Crie uma máquina virtual 1 (azuswinboap1):

  5. Crie uma máquina virtual 2 (azuswinboap2).

  6. Adicione um disco SSD Premium. Ela será usado como o diretório de Instalação do SAP BOBI.

Provisionar 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 armazenamento de arquivos SAP BusinessObjects, use 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, confira 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 de arquivos do Azure e compartilhamentos 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 será acessada por meio doponto de extremidade privado, implantado na mesma rede virtual da plataforma SAP BOBI. Com essa configuração, o formulário de tráfego do 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 de arquivos do Azure

  1. Para criar uma conta de armazenamento por meio do portal do Azure, escolha 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 Premium FileStorage, ZRS e LRS são as únicas opções disponíveis. Com base em sua estratégia de implantação de VM (conjunto de escala 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 ponto de extremidade privado.

    2. Escolha 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 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 arquivos do Azure na conta de armazenamento. Os Arquivos do Azure usam um modelo provisionado para compartilhamentos de arquivos premium. Em um modelo de negócios provisionado, você especifica proativamente para os 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, criamos dois arquivos do Azure: frsinput (256 GB) e frsoutput (256 GB) para o repositório de arquivos do 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 frsouput.
  4. Insira o tamanho de compartilhamento de arquivos necessário em Capacidade provisionada. For exemplo, insira 256 GB.
  5. Escolha SMB como Protocolo.
  6. Selecione Criar.

Configurar um disco de dados na máquina virtual 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 deve garantir que haja 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, é aconselhável separar binários de instalação do SAP BOBI em partição separada.

Neste exemplo, um aplicativo SAP BOBI será instalado em uma partição separada (F:). Inicialize o disco SSD Premium que você anexou durante o provisionamento da 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 Arquivos do Azure como um armazenamento de arquivos, você deve montá-lo, o que significa atribuir uma letra da unidade no caminho do 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 arquivos 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. Verifique se o firewall ou o ISP está bloqueando a porta 445 usando o cmdlet Test-NetConnection. 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, precisamos de dois bancos de dados, de CMS e de 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 Básico, preencha todos os campos necessários para Criar Servidor de Banco de Dados SQL:

    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 do banco de dados do SQL.

Na próxima etapa, crie os bancos de dados de CMS e de auditoria no servidor do Banco de Dados SQL do Microsoft Azure (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 Básico, preencha todos os campos necessários:

    1. Insira o Nome do banco de dados. Por exemplo, insira 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 será usado para acessar o Banco de Dados SQL do Azure dentro da rede virtual configurada.

    1. SelecioneAdicionar ponto de extremidade privado.

    2. Escolha 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. Faça download da versão do driver ODBC pelo link. Neste exemplo, estamos baixando 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 CMS da seguinte forma e selecione Avançar:
    • Nome: o nome do banco de dados criado na seção "Criar o banco de dados de CMS e de auditoria". " Por exemplo, digitebocms 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 de 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. Mude o banco de dados padrão para bocms e mantenha todo o restante 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 de CMS foi criada. Agora você pode escolher Testar fonte de dados para validar a conexão com o banco de dado de CMS do 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 de seus servidores de aplicativos 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 as 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.

Instalação

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 BusinsessObjects 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, escolhemos a opção 1, que instala o 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.

    Screenshot that shows the CMS database information for 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.

    Screenshot that shows the audit database information for Windows.

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

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.

Screenshot that shows database information in 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 do sistema padrão no CMC ou na página Launchpad de entrada do BI.

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 máquina virtual é 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).

Clustering 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, confira Clustering do Tomcat usando a associação estática para a plataforma de BI SAP BusinessObjects no blog da SAP.

Balancear a carga de uma camada da 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 investigação de integridade do balanceador de carga monitora uma determinada porta em cada VM e distribui o tráfego somente para 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, confira a seção "Balanceador de carga interno" em que o servidor de aplicativos Web é executado na porta 8080 (porta HTTP Tomcat padrão), que será monitorada por uma investigação de integridade. Qualquer solicitação de entrada que venha dos usuários será 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 as VMs sem endereços IP públicos forem colocadas no pool de back-end do Standard Load Balancer (sem endereço IP público), não haverá nenhuma conectividade de saída com a Internet se não houver configuração adicional a fim de permitir o roteamento para pontos de extremidade públicos. Para obter informações sobre como alcançar conectividade de saída, veja Conectividade de ponto de extremidade público para máquinas virtuais usando o Azure Standard Load Balancer em cenários de alta disponibilidade do SAP.

    Screenshot that shows Load Balancer used to balance traffic across web servers.

  • O Gateway de Aplicativo oferece o controlador de entrega de aplicativos como um serviço, que é usado para ajudar o aplicativo a direcionar o tráfego de usuários para um ou mais servidores de aplicativos 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.

    Screenshot that shows Application Gateway used to balance traffic across web servers.

    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 se tornar indisponível, o aplicativo SAP BOBI se tornará inacessível ou determinadas funcionalidades do aplicativo não funcionarão. É 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.

Este guia explora como os recursos nativos do Azure em combinação com uma configuração de plataforma SAP BOBI melhoram a disponibilidade de uma implantação SAP. Esta seção se concentra nas seguintes opções para a confiabilidade da plataforma SAP BOBI no Azure:

  • Backup e restauração: esse 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 backup e a restauração são um processo de criação periódica de cópias de dados e aplicativos em um local separado para que possam ser restaurados ou recuperados em um estado anterior caso os dados ou aplicativos originais sejam perdidos ou danificados. Também é um componente essencial de qualquer estratégia de DR de negócios. Esses backups permitem a restauração 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)
  • Banco de dados de CMS e de auditoria (Banco de Dados SQL do Azure, Banco de Dados do Azure para MySQL ou Máquinas Virtuais do Microsoft 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 um disco de dados específico com falha consistente. 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 repositório de um arquivo da plataforma SAP BOBI pode estar em arquivos Azure NetApp Files ou dos Arquivos do Azure. 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ê tiver criado um servidor NFS separado, implemente a estratégia de backup e restauração nele.

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 banco de dados de CMS e de auditoria podem ser executados em qualquer um dos bancos de dados com suporte, conforme descrito na matriz de suporte do 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 7 dias, em que você tem a opção de configurar para 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. Em nosso caso, os data centers residem em uma região do Azure. O artigo Arquitetura e cenários de alta disponibilidade para o SAP apresenta uma visão inicial de diferentes técnicas de alta disponibilidade e recomendações oferecidas em aplicativos do Azure para SAP, que complementam as instruções desta 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 RTO (objetivo de tempo de recuperação) e do RPO (objetivo de ponto de recuperação) necessários. 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 conjuntos de escala flexíveis, conjuntos de disponibilidade ou zonas de disponibilidade com base no RTO exigido pelos 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, é aconselhável usar um conjunto de escala flexível com FD=1 sobre a 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 compatíveis com Azure, confira Alta disponibilidade para Banco de Dados SQL do Azure e Alta disponibilidade no Banco de Dados do Azure para MySQL.

Para outras implantações do DBMS (sistema de gerenciamento de banco de dados) para um banco de dados CMS, confira Guias de implantação do DBMS para carga de trabalho SAP para obter informações sobre uma implantação diferente do gerenciador de banco de dados e sua abordagem para obter alta disponibilidade.

Alta disponibilidade para clientes

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 a plataforma SAP BOBI em execução no Windows, você pode escolher Arquivos Premium do Azure ou Azure NetApp Files para armazenamento de arquivos, que foi projetado para ser altamente disponível e altamente durável por natureza. 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 precisará 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 obtida com base no tipo de camada selecionada durante a implantação:
    • O SKU v1 permite cenários de alta disponibilidade quando duas ou mais instâncias são implantadas. 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 obtida dentro da zona.
    • A 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 zonal em caso de falha. 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 por meio de link privado para VMs de camada de armazenamento e gerenciamento para acessar o conteúdo como relatórios, universo 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.

Diagram that shows high-availability architecture for an SAP BOBI platform on 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 documento Recuperação de desastre para SAP, que representa os recursos primários para uma abordagem geral de DR da SAP. 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 CMS e FRS.

Neste guia, vamos falar sobre a segunda opção para implementar um ambiente de DR. Não vamos cobrir uma lista completa de todas as opções de configuração possíveis para DR. Vamos abranger 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 fatorada para a região secundária. Toda a estratégia de DR deve ser completamente testada.
  • Caso sua plataforma SAP BI esteja configurada com um conjunto de escala flexível 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 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.

Diagram that shows SAP BusinessObjects BI platform DR for 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.

Máquinas virtuais que executam servidores de aplicativos Web e de 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. Ele replica os servidores e todos os discos gerenciados anexos na região secundária para que, quando desastres e interrupções ocorrerem, você possa fazer failover facilmente para seu ambiente replicado e continuar trabalhando. Para começar a replicar todas as VMs do aplicativo SAP para o data center de DR do Azure, siga as diretrizes em Replicar uma máquina virtual para o Azure.

FileStore

Filestore é um diretório de disco em que os arquivos reais, como relatórios, documentos de BI são armazenados. É importante que todos os arquivos no repositório de arquivo estejam em sincronia com a região de DR. Com base no tipo de serviço de compartilhamento de arquivos que você usa para a plataforma SAP BOBI em execução no Windows, a estratégia de DR necessária deve ser adotada para sincronizar o conteúdo. 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, atualmente em versão prévia, que usa a tecnologia NetApp SnapMirror. 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 compatível com 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 banco de dados de CMS e de auditoria ou pode ser atualizada 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. Há um atraso entre o momento em que um backup é realizado e quando ele é replicado geograficamente 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 backupcom redundância geográfica.

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

A replicação geográfica ativa é um recurso de Banco de Dados SQL que permite que você crie bancos de dados secundários legíveis com base em bancos de dados individuais em um servidor na mesma região ou 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, mas para habilitar o failover transparente e coordenado de vários bancos de dados (CMS e auditoria) para um aplicativo SAP BOBI, é aconselhável usar 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 escuta de leitura/gravação e somente leitura que permanecem inalterados durante o failover. 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 o failover de banco de dados ser concluído, o registro DNS é atualizado automaticamente para redirecionar os pontos de extremidade 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 SQL Server (azussqlbodb) em execução na região Leste dos EUA 2 é replicado para a região secundária 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 permanecerá o mesmo. Nenhuma intervenção manual é necessária para conectar o aplicativo de BI ao banco de dados SQL na região secundária.

Screenshot that shows SQL Database auto-failover groups.

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 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 réplicas de leitura entre regiões para aprimorar o planejamento de continuidade dos negócios e 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 fazer 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 Azure Load Balancer 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 Azure NetApp Files (versão prévia)
Banco de Dados SQL do Azure Grupos de replicação geográfica/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

Próximas etapas