Distribuire la piattaforma SAP BusinessObjects BI in Azure per Windows

Questo articolo descrive la strategia per distribuire la piattaforma SAP BusinessObjects Business Intelligence (BOBI) in Azure per Windows. In questo esempio, vengono configurate due macchine virtuali (VM) con dischi gestiti SSD Premium di Azure come directory di installazione. Database SQL di Azure, un'offerta di PaaS (Platform as a Service), viene usato per il server di gestione centrale (CMS) e per i database di audit. File Premium di Azure, un protocollo SMB, viene usato come filetore condiviso in entrambe le macchine virtuali. L'applicazione Web Java Tomcat predefinita e l'applicazione della piattaforma business intelligence (BI) vengono installate insieme in entrambe le macchine virtuali. Per bilanciare il carico delle richieste utente, viene utilizzato Azure Application Gateway, che include funzionalità native di offload TLS/SSL.

Questo tipo di architettura è efficace per ambienti di distribuzione di piccole dimensioni o non di produzione. Per la distribuzione su larga scala o di produzione, è necessario separare gli host per le applicazioni Web ed è possibile avere più host applicazioni SAP BOBI, che consentono al server di elaborare altre informazioni.

Diagramma che mostra una distribuzione SAP BOBI in Azure per Windows.

Sistema di file Descrizione Dimensione (GB) Accesso obbligatorio Archiviazione
F: File system per l'installazione di un'istanza di SAP BOBI, applicazione Web Tomcat predefinita e driver di database (se necessario). Linee guida per il dimensionamento SAP Privilegi amministrativi locali Dischi gestiti Premium SSD di Azure
\\azusbobi.file.core.windows.net\frsinput La directory di montaggio è per i file condivisi in tutti gli host SAP BOBI che verranno usati come directory Filestore di input. Esigenza aziendale Privilegi amministrativi locali Azure NetApp Files
\\azusbobi.file.core.windows.net\frsoutput La directory di montaggio è per i file condivisi in tutti gli host SAP BOBI che verranno usati come directory Filestore di output. Esigenza aziendale Privilegi amministrativi locali Azure NetApp Files

Prerequisiti

  • Una sottoscrizione di Azure con autorizzazioni per creare risorse come macchine virtuali, account di archiviazione, istanze del database SQL e reti virtuali.
  • Il dimensionamento della piattaforma SAP BOBI è stato completato in base alla guida alla pianificazione e all'implementazione di SAP BOBI in Azure.
  • Media di installazione della piattaforma SAP BusinessObjects BI (versione 4.3 SP01 Patch 1 o successiva). Per un codice di licenza temporaneo, vedere SAP Note 1288121.
  • Driver MICROSOFT ODBC compatibile con il database SQL di Azure. Questo articolo usa la versione 13.1.
  • Windows Server 2019 o una versione supportata del sistema operativo in base alla matrice di disponibilità del prodotto SAP.
  • Accesso alla rete in uscita sulla porta 1433 dai server applicazioni SAP BOBI al database SQL di Azure.
  • Accesso alla rete in uscita sulla porta 445 dai server applicazioni SAP BOBI se si usa File Premium di Azure (SMB).

Distribuire una macchina virtuale Windows usando il portale di Azure

In questa sezione vengono create due macchine virtuali con un'immagine del sistema operativo Windows per la piattaforma SAP BOBI. I passaggi generali per creare macchine virtuali sono i seguenti:

  1. Creare un gruppo di risorse.

  2. Creare una rete virtuale:

    • Non usare una singola subnet per tutti i servizi di Azure in una distribuzione della piattaforma SAP BI. In base all'architettura della piattaforma SAP BI, potrebbe essere necessario creare più subnet. In questa distribuzione vengono create due subnet: una subnet per l'applicazione BI e una subnet per il gateway di applicazione.
    • Seguire la nota SAP 2276646 per identificare le porte per la comunicazione della piattaforma SAP BOBI tra componenti diversi.
    • Il database SQL comunica attraverso la porta 1433. Il traffico in uscita sulla porta 1433 deve essere consentito dai server applicazioni SAP BOBI.
    • In Azure, l'Application Gateway deve trovarsi in una subnet separata. Per altre informazioni, vedere Panoramica della configurazione del gateway dell'applicazione.
    • Se si utilizza Azure NetApp Files per l'archiviazione file anziché File di Azure, creare una subnet separata per Azure NetApp Files. Per altre informazioni, vedere Linee guida per la pianificazione di rete di Azure NetApp Files.

  3. Selezionare le opzioni di disponibilità appropriate a seconda della configurazione del sistema preferita all'interno di un'area di Azure, indipendentemente dal fatto che:

    • Implica l'estensione su più zone
    • Si trova all'interno di una singola zona
    • Opera in un'area senza zona

  4. Creare la macchina virtuale 1 (azuswinboap1):

  5. Creare la macchina virtuale 2 (azuswinboap2).

  6. Aggiungere un'unità SSD Premium. Viene usato come directory di installazione di SAP BOBI.

Configurare i File Premium di Azure

Prima di continuare con la configurazione per File di Azure, acquisire familiarità con la documentazione di File di Azure.

File di Azure offre condivisioni file standard ospitate su hardware basato su HDD e condivisioni file Premium ospitate su hardware basato su SSD. Per un file store SAP BusinessObjects, usare Azure Premium Files.

Le condivisioni file Premium di Azure sono disponibili con ridondanza locale e di zona in un subset di aree. Per scoprire se le condivisioni file Premium sono attualmente disponibili nell'area, vedere Prodotti disponibili in base all'area. Per informazioni sulle aree che supportano l'archiviazione con ridondanza di zona (ZRS), vedere Archiviazione di Azure con ridondanza.

Distribuire un account di archiviazione Azure Files e condivisioni NFS

Le condivisioni file di Azure vengono distribuite in account di archiviazione, ovvero oggetti di primo livello che rappresentano un pool di archiviazione condiviso. Questo pool di archiviazione può essere usato per distribuire più condivisioni file. Azure supporta più tipi di account di archiviazione per diversi scenari di archiviazione che i clienti potrebbero avere. Per l'archiviazione di file SAP BusinessObjects, è necessario creare un account FileStorage. Viene usato per distribuire condivisioni file di Azure su hardware basato su SSD Premium.

Nota

Gli account FileStorage possono essere usati solo per archiviare condivisioni file di Azure. Nessun'altra risorsa di archiviazione, ad esempio BLOB, contenitori, code o tabelle, può essere distribuita in un account FileStorage.

L'account di archiviazione è accessibile tramite un endpoint privato e distribuito nella stessa rete virtuale di una piattaforma SAP BOBI. Con questa configurazione, il traffico proveniente dal sistema SAP non lascia mai i limiti di sicurezza della rete virtuale. I sistemi SAP contengono spesso dati sensibili e critici per l'azienda, quindi rimanere entro i limiti della rete virtuale è una considerazione importante per la sicurezza per molti clienti.

Se devi accedere all'account di archiviazione da una rete virtuale diversa, è possibile usare Peering Rete Virtuale di Azure.

Account di archiviazione file di Azure

  1. Per creare un account di archiviazione usando il portale di Azure, selezionare Crea una risorsa>Archiviazione>Account di archiviazione.

  2. Nella scheda Informazioni di base completare tutti i campi obbligatori per creare un account di archiviazione:

    1. Selezionare Sottoscrizione>Gruppo di risorse>Area.

    2. Inserisci il Nome account di archiviazione. Ad esempio, immettere azusbobi. Questo nome deve essere univoco a livello globale, ma in caso contrario è possibile specificare qualsiasi nome desiderato.

    3. Selezionare Premium come livello di prestazioni e selezionare FileStorage come tipo di account.

    4. Per Etichetta di replica scegliere un livello di ridondanza. selezionare Archiviazione con ridondanza locale.

      Per FileStorage Premium, ZRS e LRS sono le uniche opzioni disponibili. In base alla strategia di distribuzione delle macchine virtuali (set di scalabilità flessibile, zona di disponibilità o set di disponibilità), scegliere il livello di ridondanza appropriato. Per altre informazioni, vedere Ridondanza di Archiviazione di Azure.

    5. Selezionare Avanti.

  3. Nella scheda Rete selezionare Endpoint privato come metodo di connettività. Per ulteriori informazioni, vedere considerazioni sulla rete di Azure Files.

    1. Selezionare Aggiungi nella sezione endpoint privato.

    2. Selezionare Sottoscrizione>Gruppo di risorse>Località.

    3. Immettere il nome dell'endpoint privato. Ad esempio, immettere azusbobi-pe.

    4. Selezionare il file nella sotto-risorsa di archiviazione.

    5. Nella sezione Rete selezionare la rete virtuale e la subnet in cui viene distribuita l'applicazione SAP BusinessObjects BI.

    6. Accettare il valore predefinito (sì) per l'integrazione con la zona DNS privata.

    7. Selezionare la zona DNS privata dall'elenco a discesa.

    8. Selezionare OK per tornare alla scheda Networking in Crea account di archiviazione.

  4. Nella scheda Protezione dati, configurare i criteri di eliminazione temporanea per le condivisioni file di Azure nell'account di archiviazione. Per impostazione predefinita, la funzionalità di eliminazione temporanea è disattivata. Per ulteriori informazioni sulla cancellazione reversibile, vedere Impedire l'eliminazione accidentale delle condivisioni di file di Azure.

  5. Nella scheda Avanzate selezionare diverse opzioni di sicurezza.

    Il campo Trasferimento sicuro obbligatorio indica se l'account di archiviazione richiede la crittografia in transito per la comunicazione con l'account di archiviazione. Se è necessario il supporto SMB 2.1, è necessario disabilitare questo campo. Per la piattaforma SAP BOBI, mantenere l'impostazione predefinita (abilitata).

  6. Continuare a creare l'account di archiviazione.

Per informazioni dettagliate su come creare un account di archiviazione, vedere Creare un account di archiviazione FileStorage.

Creare condivisioni file di Azure

Il passaggio successivo consiste nel creare condivisioni file di Azure nell'account di archiviazione. Le condivisioni file di Azure usano un modello con provisioning per le condivisioni file Premium. In un modello aziendale con provisioning si specifica in modo proattivo nel servizio File di Azure i requisiti di archiviazione, invece di essere fatturati in base a ciò che si usa. Per altre informazioni circa questo modello, vedere Provisioned model. In questo esempio vengono create due condivisioni file di Azure: frsinput (256 GB) e frsoutput (256 GB) per il filetore SAP BOBI.

  1. Vai all'account di archiviazione azusbobi>condivisioni di file.
  2. Selezionare Nuova condivisione file.
  3. Immettere il nome della condivisione file. Ad esempio, immettere frsinput o frsoutput.
  4. Immettere la dimensione necessaria per la condivisione file nella Capacità provisionata. Ad esempio, immettere 256 GB.
  5. Selezionare SMB come Protocollo.
  6. Selezionare Crea.

Configurare un disco dati in una macchina virtuale Windows

I passaggi di questa sezione usano il prefisso seguente:

[A]: il passaggio si applica a tutti gli host.

Inizializzare un nuovo disco dati

L'applicazione SAP BusinessObjects BI richiede una partizione in cui è possibile installare i relativi file binari. È possibile installare un'applicazione SAP BOBI nella partizione del sistema operativo (C:), ma è necessario assicurarsi di disporre di spazio sufficiente per la distribuzione e il sistema operativo. È consigliabile avere almeno 2 GB disponibili per file temporanei e applicazioni Web. È anche consigliabile separare i file binari di installazione di SAP BOBI in partizioni separate.

In questo esempio, un'applicazione SAP BOBI viene installata in una partizione separata (F:). Inizializza l'unità SSD Premium che hai collegato durante il provisioning della macchina virtuale.

  1. [A] Se alla macchina virtuale non è collegato alcun disco dati (azuswinboap1 e azuswinboap2), seguire la procedura descritta in Aggiungere un disco dati per collegare un nuovo disco dati gestito.
  2. [A] Dopo che il disco gestito è collegato alla macchina virtuale, inizializzare il disco seguendo i passaggi descritti in Inizializzare un nuovo disco dati.

Montare File Premium di Azure

Per usare File di Azure come archivio file, è necessario montarlo, ovvero assegnare a esso una lettera di unità o un percorso del punto di montaggio.

[A] Per montare la condivisione file di Azure, seguire la procedura descritta in Montare la condivisione file di Azure.

Per montare una condivisione file di Azure in un server Windows, il protocollo SMB richiede che la porta TCP 445 sia aperta. Le connessioni hanno esito negativo se la porta 445 è bloccata. È possibile verificare se il firewall o l'ISP blocca la porta 445 usando il Test-NetConnection cmdlet . Vedere La porta 445 è bloccata.

Configurare un database CMS: Azure SQL

Questa sezione fornisce informazioni dettagliate su come effettuare il provisioning di SQL di Azure usando il portale di Azure. Vengono inoltre fornite istruzioni su come creare cms e il database di controllo per una piattaforma SAP BOBI e un account utente per accedere ai database.

Le linee guida sono applicabili solo se si usa database SQL. Per altri database, vedere la documentazione di SAP o quella specifica del database per istruzioni dettagliate.

Creare un server di database SQL

database SQL offre diverse opzioni di distribuzione: database singolo, pool elastico e server di database. Per una piattaforma SAP BOBI sono necessari due database, CMS e controllo. Anziché creare due database singoli, è possibile creare un server database SQL in grado di gestire il gruppo di database singoli e pool elastici. Seguire questa procedura per creare un server database SQL:

  1. Accedere alla pagina Selezione l’opzione di distribuzione SQL.

  2. Nei database SQL, modificare Tipo di risorsa in server di database. Selezionare Crea.

  3. Nella scheda Informazioni di base completare tutti i campi obbligatori per Creare un server di database SQL:

    1. Sotto Dettagli del progetto, selezionare la sottoscrizione e il gruppo di risorse.

    2. Immettere un nome server. Ad esempio, immettere azussqlbodb. Il nome del server deve essere globalmente univoco, ma in caso contrario, è possibile specificare qualsiasi nome desiderato.

    3. Selezionare la posizione.

    4. Immettere il login dell'amministratore del server. Ad esempio, immettere boadmin. Immettere quindi una password.

  4. Nella scheda Rete modificare Consenti ai servizi e alle risorse di Azure di accedere al server su No in Regole del firewall.

  5. In Impostazioni aggiuntive mantenere le impostazioni predefinite.

  6. Continuare e creare database SQL Server.

Nel passaggio successivo creare cms e i database di controllo nel server di database SQL (azussqlbodb.database.windows.net).

Creare cms e il database di controllo

Dopo aver effettuato il provisioning del server di database SQL, navigare alla risorsa azussqlbodb. Seguire quindi questa procedura per creare cms e controllare i database.

  1. Nella pagina di panoramica di azussqlbodb selezionare Crea database.

  2. Nella scheda Informazioni di base completare tutti i campi obbligatori:

    1. Immettere il nome del database. Ad esempio, immettere bocms o boaudit.

    2. Nell'opzione Calcolo e archiviazione selezionare Configura database. Scegliere il modello appropriato in base al risultato del ridimensionamento. Per informazioni dettagliate sulle opzioni, vedere Ridimensionamento dei modelli per database SQL di Azure.

  3. Nella scheda Rete selezionare endpoint privato per il metodo di connettività. L'endpoint privato viene usato per accedere al database SQL all'interno della rete virtuale configurata.

    1. Seleziona Aggiungi endpoint privato.

    2. Selezionare Sottoscrizione>Gruppo di risorse>Località.

    3. Immettere il nome dell'endpoint privato. Ad esempio, immettere azusbodb-pe.

    4. In Sotto-risorsa di destinazione selezionare SqlServer.

    5. Nella sezione Rete selezionare la rete virtuale e la subnet in cui viene distribuita l'applicazione SAP BusinessObjects BI.

    6. Accettare il valore predefinito (sì) per l'integrazione con la zona DNS privata.

    7. Selezionare la zona DNS privata dall'elenco a discesa.

    8. Selezionare OK per tornare alla scheda Networking in Crea database SQL.

  4. Nella scheda Impostazioni aggiuntive, modificare l'impostazione della Clausola di confronto su SQL_Latin1_General_CP850_BIN2.

  5. Continuare e creare il database CMS.

Analogamente, è possibile creare il database di controllo. Ad esempio, immettere boaudit.

Scaricare e installare un driver ODBC

I server delle applicazioni SAP BOBI richiedono client e driver di database per accedere al database CMS o al database di audit. Un driver ODBC Di Microsoft viene usato per accedere a CMS e controllare i database in esecuzione in database SQL. Questa sezione fornisce istruzioni su come scaricare e configurare un driver ODBC in Windows.

  1. Per informazioni sui connettori di database compatibili con database SQL, vedere la sezione Supporto del repository CMS + Audit per sistema operativo nella piattaforma PAM (Product Availability Matrix) per SAP BusinessObjects BI.
  2. Scaricare il driver ODBC. In questo esempio questo articolo usa il driver ODBC 13.1.
  3. Installare il driver ODBC in tutti i server BI (azuswinboap1 e azuswinboap2).
  4. Dopo aver installato il driver in azuswinboap1, passare a Start>Windows Administrative Tools>ODBC Data Sources (64-bit).
  5. Vai alla scheda DSN di sistema.
  6. Selezionare Aggiungi per creare una connessione al database CMS.
  7. Selezionare ODBC Driver 13 per SQL Server e selezionare Fine.
  8. Immettere le informazioni del database CMS come indicato di seguito e selezionare Avanti:
    • Nome: nome del database creato nella sezione "Creare cms e il database di controllo". Ad esempio, immettere bocms o boaudit.
    • Descrizione: descrizione che descrive l'origine dati. Ad esempio, immettere database CMS o Database di controllo.
    • Server: nome del server creato nella sezione "Creare un server di database SQL". Ad esempio, immettere azussqlbodb.database.windows.net.
  9. Selezionare Con l'autenticazione di SQL Server usando un ID di accesso e una password immessi dall'utente per verificare l'autenticità in Azure SQL Server. Immettere le credenziali utente create al momento della creazione del server database SQL. Ad esempio, immettere boadmin. Selezionare Avanti.
  10. Modificare il database predefinito in bocmse mantenere tutto il resto come predefinito. Selezionare Avanti.
  11. Selezionare la casella di controllo Usa crittografia avanzata per i dati e mantenere tutto il resto come predefinito. Selezionare Fine.
  12. Viene creata l'origine dati per il database CMS. È ora possibile selezionare Test origine dati per convalidare la connessione al database CMS dall'applicazione BI. Il processo dovrebbe poi essere completato correttamente. In caso di errore, risolvere il problema di connettività.

Nota

Il database SQL comunica attraverso la porta 1433. Il traffico in uscita sulla porta 1433 deve essere consentito dai server applicazioni SAP BOBI.

Ripetere i passaggi precedenti per creare una connessione per il database di controllo nel server azuswinboap1. Analogamente, installare e configurare entrambe le origini dati ODBC (bocms e boaudit) in tutti i server di applicazioni BI (azuswinboap2).

Preparazione del server

Seguire la guida più recente di SAP per preparare i server per l'installazione della piattaforma BI. Per le informazioni più aggiornate, vedere la sezione "Preparazione" nella Guida all'installazione di SAP Business Intelligence Platform per Windows.

Installare la piattaforma BI in un host Windows

Per installare la piattaforma BI in un host Windows, accedere con un utente con privilegi amministrativi locali.

Accedere ai media della piattaforma SAP BusinessObjects BI ed eseguire setup.exe.

Seguire le istruzioni della Guida all'installazione di SAP Business Intelligence Platform per Windows specifiche della versione. Ecco alcuni punti da notare durante l'installazione della piattaforma SAP BOBI in Windows:

  • Nella schermata Configura cartella di destinazione specificare la cartella di destinazione in cui si vuole installare la piattaforma BI. Ad esempio, immettere F:\SAP BusinessObjects*.

  • Nella schermata Configura registrazione prodotto è possibile usare un codice di licenza temporaneo per le soluzioni SAP BusinessObjects dalla nota SAP 1288121 o generare un codice di licenza in SAP Service Marketplace.

  • Nella schermata Seleziona tipo di installazione selezionare Installazione completa nel primo server (azuswinboap1). Per l'altro server (azuswinboap2), selezionare Personalizzato/Espandi, che espande la configurazione esistente di SAP BOBI.

  • Nella schermata Seleziona database predefinito o esistente selezionare Configura un database esistente, che richiede di selezionare CMS e il database di controllo. Selezionare Microsoft SQL Server usando ODBC per il tipo di database CMS e il tipo di database di controllo.

    È anche possibile selezionare Nessun database di controllo se non si vuole configurare il controllo durante l'installazione.

  • Selezionare le opzioni appropriate nella schermata Seleziona server applicazioni Web Java in base all'architettura SAP BOBI. In questo esempio viene selezionata l'opzione 1, che installa un server Tomcat nella stessa piattaforma SAP BOBI.

  • Immettere le informazioni sul database CMS in Configurare il database del repository CMS - SQL Server (ODBC). L'immagine seguente mostra l'input di esempio per le informazioni sul database CMS per un'installazione di Windows.

    Screenshot che mostra le informazioni sul database CMS per Windows.

  • (Facoltativo) Immettere le informazioni sul database di controllo in Configurare il database di controllo - SQL Server (ODBC). L'immagine seguente mostra l'input di esempio per le informazioni sul database di controllo per un'installazione di Windows.

    Screenshot che mostra le informazioni sul database di controllo per Windows.

  • Completare l'installazione seguendo le istruzioni e immettere gli input necessari.

Per una distribuzione a istanze multipla, eseguire l'installazione nel secondo host (azuswinboap2). Nella schermata Seleziona tipo di installazione selezionare Personalizzato/Espandi, che espande l'installazione esistente di SAP BOBI. Per ulteriori informazioni, vedere il blog SAP Configurazione della piattaforma SAP BusinessObjects Business Intelligence con Database SQL di Azure.

Importante

I numeri di versione del motore di database per SQL Server e database SQL non sono confrontabili tra loro. Sono numeri di compilazione interni per questi separati prodotti. Il motore di database per database SQL si basa sulla stessa codebase del motore di database di SQL Server. Soprattutto, il motore del database di SQL Database contiene sempre le componenti più recenti del motore SQL. La versione 12 di database SQL è più recente della versione 15 di SQL Server.

Per individuare la versione corrente del database SQL, è possibile controllare nelle impostazioni della Central Management Console (CMC) oppure eseguire la query seguente usando sqlcmd o SQL Server Management Studio. L'allineamento delle versioni SQL alla compatibilità predefinita può essere trovato nell'articolo livello di compatibilità del database.

Screenshot che mostra le informazioni sul database 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)

Post-installazione

Dopo un'installazione a più istanze della piattaforma SAP BOBI, è necessario eseguire altri passaggi di post-configurazione per supportare la disponibilità elevata dell'applicazione.

Configurare un nome del cluster

In una distribuzione a più istanze della piattaforma SAP BOBI, si vogliono eseguire più server CMS insieme in un cluster. Un cluster è costituito da due o più server CMS che interagiscono con un database di sistema CMS comune. Se un nodo in esecuzione in CMS ha esito negativo, un nodo con un altro cms continua a gestire le richieste della piattaforma BI. Per impostazione predefinita in una piattaforma SAP BOBI, un nome cluster riflette il nome host del primo CMS installato.

Per configurare il nome del cluster in Windows, seguire le istruzioni riportate nella Guida dell'amministratore di SAP Business Intelligence Platform. Dopo aver configurato il nome del cluster, seguire la nota di SAP 1660440 per impostare l'elemento di sistema predefinito nella pagina di accesso di CMC o di BI Launchpad.

Configurare il percorso archivio di input e di output in File Premium di Azure

Filestore fa riferimento alle directory del disco in cui si trovano i file reali di SAP BusinessObjects. Il percorso predefinito del file repository server per la piattaforma SAP BOBI si trova nella directory di installazione locale. In una distribuzione a più istanze, è importante configurare un filetore in un archivio condiviso, ad esempio File Premium di Azure o Azure NetApp Files, in modo che sia accessibile da tutti i server di livello di archiviazione.

  1. Se i File Premium di Azure non sono stati creati, seguire le istruzioni fornite nella sezione precedente "Effettuare il provisioning di File Premium di Azure" per creare e montare i File Premium di Azure.

    Suggerimento

    In base al fatto che la macchina virtuale venga distribuita in modo zonale o a livello di area, è necessario determinare la selezione della ridondanza dell'archiviazione per File Premium di Azure (ZRS o LRS).

  2. Seguire la nota SAP 2512660 per modificare il percorso del repository di file (input e output).

Clustering Tomcat: replica di sessione

Tomcat supporta il clustering di due o più server applicazioni per la replica di sessione e il failover. Se le sessioni della piattaforma SAP BOBI vengono serializzate, una sessione utente può passare senza problemi a un'altra istanza di Tomcat, anche quando un server applicazioni si guasta. Ad esempio, un utente potrebbe essere connesso a un server Web che ha esito negativo mentre l'utente sta navigando in una gerarchia di cartelle in un'applicazione SAP BI. In un cluster configurato correttamente, l'utente può continuare a spostarsi nella gerarchia di cartelle senza essere reindirizzato a una pagina di accesso.

In SAP Note 2808640, i passaggi per configurare il clustering Tomcat vengono forniti tramite multicast. Ma il multicast non è supportato in Azure. Per consentire il funzionamento di un cluster Tomcat in Azure, è necessario usare StaticMembershipInterceptor (SAP Note 2764907).

Per configurare un cluster Tomcat in Azure, vedere Clustering Tomcat usando l'appartenenza statica per la piattaforma SAP BusinessObjects BI nel blog di SAP.

Bilanciare il carico di un livello Web di una piattaforma SAP BI

In una distribuzione a più istanze DI SAP BOBI, i server applicazioni Web Java (livello Web) vengono eseguiti in due o più host. Per distribuire il carico utente in modo uniforme tra server Web, è possibile usare un servizio di bilanciamento del carico tra gli utenti finali e i server Web. È possibile usare Azure Load Balancer o Application Gateway per gestire il traffico verso i server applicazione web. Le offerte sono illustrate nelle sezioni seguenti:

  • Load Balancer è un servizio di bilanciamento del carico a prestazioni elevate, bassa latenza, livello 4 (TCP, UDP) che distribuisce il traffico tra macchine virtuali integre. Una sonda di integrità del bilanciatore di carico monitora una porta specifica in ogni macchina virtuale e distribuisce solo il traffico alle macchine virtuali operative. È possibile scegliere un servizio di bilanciamento del carico pubblico o un servizio di bilanciamento del carico interno a seconda che la piattaforma SAP BI sia accessibile da Internet o meno. È ridondante a livello di zona, il che garantisce un'elevata disponibilità tra le zone di disponibilità.

    Nella figura seguente, vedere la sezione "Bilanciamento del carico interno" in cui il server applicazioni Web viene eseguito sulla porta 8080. Questa porta è la porta HTTP Tomcat predefinita monitorata da una sonda di integrità. Qualsiasi richiesta in ingresso dagli utenti viene reindirizzata ai server applicazioni Web (azuswinboap1 o azuswinboap2) nel pool back-end. Load Balancer non supporta la terminazione del TLS/SSL, nota anche come scaricamento TLS/SSL. Se si usa Load Balancer per distribuire il traffico tra server Web, è consigliabile usare Load Balancer Standard.

    Nota

    Quando le macchine virtuali senza indirizzi IP pubblici vengono inserite nel pool back-end di Load Balancer Standard (nessun indirizzo IP pubblico), non esiste connettività Internet in uscita, a meno che non si esegua una configurazione aggiuntiva per consentire il routing agli endpoint pubblici. Per informazioni su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali con Azure Load Balancer Standard in scenari a disponibilità elevata SAP.

    Screenshot che mostra Load Balancer usato per bilanciare il traffico tra server Web.

  • Gateway applicazione fornisce un controller di recapito delle applicazioni come un'infrastruttura, che aiuta a indirizzare il traffico degli utenti verso uno o più server di applicazioni web. Offre varie funzionalità di bilanciamento del carico di livello 7, ad esempio l'offload TLS/SSL, web application firewall e l'affinità di sessione basata su cookie per le applicazioni.

    In una piattaforma SAP BI, il gateway applicativo indirizza il traffico web dell'applicazione alle risorse specificate in un pool back-end. In questo caso, è azuswinboap1 o azuswinboap2. Si assegna un listener alla porta, si creano regole e si aggiungono risorse a un pool back-end. Nella figura seguente, gateway applicazione con un indirizzo IP front-end privato (10.31.3.25) funge da punto di ingresso per gli utenti, gestisce le connessioni TLS/SSL in ingresso (HTTPS - TCP/443), decrittografa TLS/SSL e passa la richiesta (HTTP - TCP/8080) ai server nel pool back-end. Con la funzionalità di terminazione TLS/SSL predefinita, è necessario mantenere un solo certificato TLS/SSL nel gateway applicazione, semplificando le operazioni.

    Screenshot che mostra l'Application Gateway usato per bilanciare il traffico tra i server web.

    Per configurare l'Application Gateway per un server Web SAP BOBI, vedere Bilanciamento del carico dei server Web SAP BOBI usando l'Application Gateway nel blog SAP.

    Nota

    Usa Application Gateway per bilanciare il carico del traffico verso il server Web perché offre funzionalità come SSL offloading, la gestione centralizzata di SSL per ridurre il sovraccarico di crittografia e decrittografia nel server, algoritmi round-robin per distribuire il traffico, funzionalità di Web Application Firewall e alta disponibilità.

Affidabilità della piattaforma SAP BusinessObjects BI in Azure

La piattaforma SAP BusinessObjects BI include livelli diversi, ottimizzati per attività e operazioni specifiche. Quando un componente di un livello non è più disponibile, l'applicazione SAP BOBI diventa inaccessibile o alcune funzionalità dell'applicazione non funzionano. È necessario assicurarsi che ogni livello sia progettato per essere affidabile per mantenere operativa l'applicazione senza interruzioni aziendali.

Questa sezione è incentrata sul modo in cui le funzionalità native di Azure si combinano con una configurazione della piattaforma SAP BOBI per migliorare la disponibilità di una distribuzione SAP. Questa sezione illustra le opzioni seguenti per l'affidabilità della piattaforma SAP BOBI in Azure:

  • Backup e ripristino: questo processo crea copie periodiche di dati e applicazioni in posizioni separate. Se i dati o le applicazioni originali vengono persi o danneggiati, è possibile usare le copie per ripristinare o ripristinare lo stato precedente.
  • Disponibilità elevata: una piattaforma a disponibilità elevata ha almeno due elementi all'interno di un'area di Azure per mantenere operativa l'applicazione se uno dei server non è più disponibile.
  • Ripristino di emergenza: questo processo ripristina le funzionalità dell'applicazione in caso di perdite irreversibili. Ad esempio, un'intera area di Azure potrebbe non essere disponibile a causa di un'emergenza naturale.

L'implementazione di questa soluzione varia in base alla natura del sistema configurato in Azure. È necessario personalizzare le soluzioni di backup e ripristino, disponibilità elevata e ripristino di emergenza in base ai requisiti aziendali.

Backup e ripristino

Il processo di backup e ripristino crea copie periodiche di dati e applicazioni in una posizione separata. Possono essere ripristinati o ripristinati in uno stato precedente se i dati o le applicazioni originali vengono persi o danneggiati. È anche un componente essenziale di qualsiasi strategia di ripristino di emergenza aziendale. Questi backup consentono il ripristino dell'applicazione e del database a un punto nel tempo entro il periodo di conservazione configurato.

Per sviluppare una strategia completa di backup e ripristino per una piattaforma SAP BOBI, identificare i componenti che causano tempi di inattività o interruzioni del sistema nell'applicazione. In una piattaforma SAP BOBI, il backup dei componenti seguenti è fondamentale per proteggere l'applicazione:

  • Directory di installazione di SAP BOBI (dischi gestiti Premium)
  • Filestore (File Premium di Azure o Azure NetApp Files per l'installazione distribuita)
  • Cms e database di controllo (database SQL, Database di Azure per MySQL o un database in macchine virtuali di Azure)

La sezione seguente descrive come implementare una strategia di backup e ripristino per ogni componente in una piattaforma SAP BOBI.

Backup e ripristino della directory di installazione di SAP BOBI

In Azure il modo più semplice per eseguire il backup di macchine virtuali e tutti i dischi collegati consiste nell'usare Backup di Azure. Fornisce un backup indipendente e isolato per evitare la distruzione accidentale dei dati nelle macchine virtuali. I backup vengono archiviati in una cassetta di sicurezza di Servizi di ripristino con gestione integrata dei punti di ripristino. La configurazione e il ridimensionamento sono semplici. I backup sono ottimizzati e possono essere ripristinati facilmente quando necessario.

Come parte del processo di backup, viene creato uno snapshot. I dati vengono trasferiti al vault dei Servizi di ripristino senza alcun effetto sui carichi di lavoro di produzione. Lo snapshot offre un livello di coerenza diverso, come descritto in Coerenza dello snapshot. Il backup offre anche il supporto side-by-side per il backup di dischi gestiti usando il backup su disco di Azure oltre a una soluzione di backup di macchine virtuali di Azure. È utile quando sono necessari backup coerenti delle macchine virtuali una volta al giorno e backup più frequenti dei dischi del sistema operativo o di un disco dati specifico che sia coerente con l'arresto anomalo. Per altre informazioni, vedere Informazioni sul backup di macchine virtuali di Azure, backup su disco di Azure e domande frequenti: Eseguire il backup di macchine virtuali di Azure.

Backup e ripristino per filestore

In base alla tua distribuzione, l'archivio di una piattaforma SAP BOBI può essere su Azure NetApp Files o Azure Files. Scegliere tra le opzioni seguenti per il backup e il ripristino in base alla risorsa di archiviazione usata per filestore:

  • Azure NetApp Files: per Azure NetApp Files è possibile creare snapshot su richiesta e pianificare uno snapshot automatico usando i criteri di snapshot. Le copie snapshot consentono di ottenere un'istantanea del volume di Azure NetApp Files relativa a un punto nel tempo. Per altre informazioni, vedere Gestire gli snapshot tramite Azure NetApp Files.

  • File di Azure: il backup di File di Azure è integrato con un'istanza nativa di Backup, che centralizza la funzione di backup e ripristino insieme al backup della macchina virtuale e semplifica le operazioni. Per altre informazioni, vedere Backup e domande frequenti sulla condivisione file di Azure: Backup File di Azure.

Se si crea un server NFS separato, assicurarsi di implementare la strategia di backup e ripristino.

Backup e ripristino per cms e database di controllo

Per una piattaforma SAP BOBI in esecuzione in macchine virtuali Windows, il database di gestione cloud e controllo può essere eseguito in uno qualsiasi dei database supportati. Per altre informazioni, vedere la matrice di supporto nella guida alla pianificazione e all'implementazione della piattaforma SAP BOBI in Azure. È quindi importante adottare la strategia di backup e ripristino in base al database usato per CMS e controllare l'archiviazione dei dati.

  • SQL Database utilizza la tecnologia SQL Server per creare backup completi ogni settimana, backup differenziali ogni 12-24 ore e backup del log delle transazioni ogni 5-10 minuti. La frequenza dei backup del log delle transazioni è basata sulle dimensioni di calcolo e sulla quantità di attività del database.

    Gli utenti possono scegliere un'opzione per configurare la ridondanza dell'archiviazione di backup tra BLOB con ridondanza locale (LRS), BLOB con ridondanza di zona (ZRS) o BLOB con ridondanza geografica (GRS). I meccanismi di ridondanza dell'archiviazione archiviano più copie dei dati per proteggerli da eventi pianificati e non pianificati, che includono errori hardware temporanei, interruzioni di rete o interruzioni dell'alimentazione o gravi calamità naturali. Per impostazione predefinita, il database SQL archivia il backup in BLOB GRS replicati in un'area abbinata. Può essere modificato in base ai requisiti aziendali affinché supporti BLOB di archiviazione con ridondanza locale (LRS) o archiviazione con ridondanza della zona (ZRS). Per informazioni più aggiornate sulla pianificazione dei backup del database SQL, sulla conservazione dei backup e sull'utilizzo dell'archiviazione, vedere Backup automatici: Database SQL di Azure e Istanza gestita di Azure SQL.

  • Database di Azure per MySQL crea automaticamente backup del server e li memorizza in LRS o GRS configurati dall'utente. Database di Azure per MySQL esegue il backup dei file di dati e del log delle transazioni. A seconda delle dimensioni massime di archiviazione supportate, esegue backup completi e differenziali (server di archiviazione max di 4 TB) o backup di snapshot (fino a 16 TB di server di archiviazione massimi). Questi backup consentono di ripristinare un server in qualsiasi momento entro il periodo di conservazione dei backup configurato. Il periodo di conservazione dei backup predefinito è di sette giorni, che è possibile configurare facoltativamente fino a 35 giorni. Tutti i backup vengono crittografati usando la crittografia AES a 256 bit. Questi file di backup non sono esposti dall'utente e non possono essere esportati. Questi backup possono essere usati solo per le operazioni di ripristino in Database di Azure per MySQL. È possibile usare mysqldump per copiare un database. Per altre informazioni, vedere Eseguire il backup e il ripristino in Database di Azure per MySQL.

  • Per un database installato in una macchina virtuale di Azure, è possibile usare gli strumenti di backup standard o Backup per i database supportati. Inoltre, se i servizi e gli strumenti di Azure non soddisfano i requisiti, è possibile usare gli strumenti di backup di terze parti supportati che forniscono un agente per il backup e il ripristino di tutti i componenti della piattaforma SAP BOBI.

Disponibilità elevata

La disponibilità elevata si riferisce a un set di tecnologie che possono ridurre al minimo le interruzioni IT fornendo la continuità aziendale di applicazioni o servizi tramite componenti ridondanti, a tolleranza di errore o protetti da failover all'interno dello stesso data center. In questo caso, i data center si trovano all'interno di un'area di Azure. L'articolo Architettura e scenari a disponibilità elevata per SAP fornisce informazioni dettagliate sulle diverse tecniche e raccomandazioni a disponibilità elevata offerte in Azure per le applicazioni SAP, che completano le istruzioni riportate in questa sezione.

In base al risultato del dimensionamento della piattaforma SAP BOBI, è necessario progettare l'infrastruttura e determinare la distribuzione dei componenti BI tra le macchine virtuali e le subnet di Azure. Il livello di ridondanza nell'architettura distribuita dipende dall'obiettivo del tempo di ripristino (RTO) richiesto dall'azienda e dall'obiettivo del punto di ripristino (RPO). La piattaforma SAP BOBI include livelli diversi e i componenti in ogni livello devono essere progettati per ottenere la ridondanza. In caso di errore di un componente, l'applicazione SAP BOBI non causa alcuna interruzione. Ad esempio:

  • Server di applicazioni ridondanti come i server di applicazioni BI e i server web
  • Componenti univoci come database CMS, archivio file e bilanciatore di carico

La sezione seguente descrive come ottenere una disponibilità elevata in ogni componente di una piattaforma SAP BOBI.

Disponibilità elevata per i server applicazioni

I server applicazioni BI e Web non necessitano di una soluzione specifica a disponibilità elevata, indipendentemente dal fatto che siano installati separatamente o insieme. È possibile ottenere la disponibilità elevata tramite ridondanza, ovvero configurando più istanze di BI e server Web in varie macchine virtuali di Azure. È possibile distribuire le macchine virtuali in set di scalabilità flessibile, set di disponibilità o zone di disponibilità in base all'obiettivo RTO richiesto dall'azienda. Per la distribuzione tra zone di disponibilità, assicurarsi che anche tutti gli altri componenti della piattaforma SAP BOBI siano progettati per essere ridondanti per la zona.

Attualmente, non tutte le aree di Azure offrono zone di disponibilità, quindi è necessario adottare la strategia di distribuzione in base all'area. Le aree di Azure che offrono zone sono elencate nelle zone di disponibilità di Azure.

Importante

  • I concetti delle zone di disponibilità di Azure e dei set di disponibilità di Azure si escludono a vicenda. È possibile distribuire una coppia o più macchine virtuali in una zona di disponibilità specifica o in un set di disponibilità, ma non è possibile eseguire entrambe le operazioni.
  • Se si prevede di distribuire tra zone di disponibilità, è consigliabile usare un set di scalabilità flessibile con FD=1 rispetto alla distribuzione della zona di disponibilità standard.

Disponibilità elevata per il database CMS

Se si usa un database di Azure come soluzione per cms e database di controllo, per impostazione predefinita viene fornito un framework a disponibilità elevata con ridondanza locale. Selezionare le funzionalità di disponibilità elevata, ridondanza e resilienza intrinseche del servizio e dell'area senza dover configurare altri componenti. Se la strategia di distribuzione per una piattaforma SAP BOBI copre una zona di disponibilità, assicurarsi di ottenere la ridondanza della zona per il CMS e il database di auditing. Per altre informazioni sulla disponibilità elevata per le offerte di database supportate in Azure, vedere Disponibilità elevata per il database SQL di Azure. Vedere anche Disponibilità elevata in Database di Azure per MySQL.

Vedere Le guide alla distribuzione DBMS per il carico di lavoro SAP per informazioni dettagliate su una distribuzione DBMS diversa e il relativo approccio al raggiungimento della disponibilità elevata per un database CMS.

Disponibilità elevata per filestore

Filestore fa riferimento alle directory del disco in cui vengono archiviati contenuti come report, universi e connessioni. Viene condiviso tra tutti i server applicazioni del sistema. È quindi necessario assicurarsi che sia a disponibilità elevata, insieme ad altri componenti della piattaforma SAP BOBI.

Per una piattaforma SAP BOBI in esecuzione in Windows, è possibile scegliere File Premium di Azure o Azure NetApp Files per filestore. Entrambe le opzioni sono progettate per essere a disponibilità elevata e altamente durevole. File Premium di Azure supportano l'archiviazione con ridondanza della zona (ZRS), che può essere utile per la distribuzione tra zone di una piattaforma SAP BOBI. Per altre informazioni, vedere la sezione Ridondanza dei file di Azure.

Poiché il servizio di condivisione file non è disponibile in tutte le aree, assicurarsi di visualizzare l'elenco dei prodotti disponibili in base all'area per trovare informazioni aggiornate. Se il servizio non è disponibile nell'area, è possibile creare un server NFS da cui è possibile condividere il file system in un'applicazione SAP BOBI. Tuttavia, è necessario considerare anche la disponibilità elevata.

Disponibilità elevata per il servizio di bilanciamento del carico

Per distribuire il traffico su un server web, è possibile utilizzare un *Load Balancer* o un *Application Gateway*. La ridondanza per entrambi i bilanciatori del carico può essere ottenuta in base allo SKU scelto per la distribuzione:

  • Load Balancer: la ridondanza può essere ottenuta configurando il front end del Load Balancer Standard come ridondante a livello di zona. Per ulteriori informazioni, vedere Load Balancer Standard e zone di disponibilità.

  • Gateway applicazione: la disponibilità elevata può essere raggiunta in base al tipo di livello selezionato durante la distribuzione:

    • Lo SKU v1 supporta scenari a disponibilità elevata quando si distribuiscono due o più istanze. Azure distribuisce queste istanze nei domini di errore e di aggiornamento per impedire l'arresto simultaneo di tutte le istanze. Con questo SKU, la ridondanza può essere ottenuta all'interno della zona.

    • Lo SKU v2 garantisce automaticamente che le nuove istanze vengano distribuite tra domini di errore e domini di aggiornamento. Se si sceglie la ridondanza della zona, le istanze più recenti vengono anche distribuite tra le zone di disponibilità per offrire resilienza dagli errori delle zone. Per altre informazioni, vedere Gateway applicazione v2 con scalabilità automatica e ridondanza della zona.

Architettura di riferimento a disponibilità elevata per la piattaforma SAP BusinessObjects BI

L'architettura di riferimento seguente descrive la configurazione di una piattaforma SAP BOBI tra zone di disponibilità in esecuzione in un server Windows. L'architettura illustra l'uso di diversi servizi di Azure, ad esempio gateway applicazione, File Premium di Azure (filestore) e database SQL (CMS e database di controllo). La piattaforma SAP BOBI offre ridondanza della zona predefinita, riducendo la complessità della gestione di diverse soluzioni a disponibilità elevata.

Nella figura seguente, il traffico in ingresso (HTTPS - TCP/443) viene bilanciato utilizzando il Gateway Applicazione SKU v2, che si estende su più zone di disponibilità. Il gateway applicativo distribuisce la richiesta dell'utente tra i server web, che sono distribuiti tra zone di disponibilità. Il server Web inoltra la richiesta alle istanze del server di gestione ed elaborazione distribuite in macchine virtuali separate tra zone di disponibilità. I file Premium di Azure con archiviazione ZRS vengono collegati tramite collegamento privato alle macchine virtuali del livello di gestione e di archiviazione per accedere ai contenuti, come report, ambiente e connessioni. L'applicazione accede al database CMS e di controllo, in esecuzione su un'istanza di SQL Database con ridondanza geografica, che replica i database in più sedi fisiche all'interno di una stessa area di Azure.

Diagramma che mostra l'architettura a disponibilità elevata per una piattaforma SAP BOBI in Windows.

L'architettura precedente fornisce informazioni dettagliate sul modo in cui è possibile eseguire una distribuzione SAP BOBI in Azure. Ma non copre tutte le opzioni di configurazione possibili per una piattaforma SAP BOBI in Azure. È possibile personalizzare la distribuzione in base ai requisiti aziendali scegliendo prodotti o servizi diversi per componenti come Load Balancer, File Repository Server e DBMS.

Se le zone di disponibilità non sono disponibili nell'area selezionata, è possibile distribuire macchine virtuali di Azure nei set di disponibilità. Azure assicura che le macchine virtuali inserite all'interno di un set di disponibilità vengano eseguite su più server fisici, rack di calcolo, unità di archiviazione e commutatori di rete. Se si verifica un errore hardware o software, viene interessato solo un subset delle macchine virtuali e la soluzione complessiva rimane operativa.

Ripristino di emergenza

Questa sezione illustra la strategia per fornire la protezione di disaster recovery per una piattaforma SAP BOBI. Completa l'articolo Ripristino di emergenza per SAP , che è la risorsa primaria per un approccio di ripristino di emergenza SAP complessivo. Per la piattaforma SAP BOBI, vedere SAP Note 2056228, che descrive i metodi seguenti per implementare un ambiente di ripristino di emergenza in modo sicuro:

  • Usare completamente o selettivamente la gestione del ciclo di vita o la federazione per promuovere o distribuire il contenuto dal sistema primario.
  • Copiare periodicamente il contenuto di CMS e FRS.

In questa sezione viene illustrata la seconda opzione per implementare un ambiente di ripristino di emergenza. Questo articolo non include un elenco completo di tutte le opzioni di configurazione possibili per il ripristino di emergenza, ma illustra una soluzione che include servizi nativi di Azure in combinazione con la configurazione della piattaforma SAP BOBI.

Importante

  • La disponibilità di ogni componente nella piattaforma SAP BOBI deve essere inserita nell'area secondaria. L'intera strategia di ripristino di emergenza deve essere testata accuratamente.
  • Se la piattaforma SAP BI è configurata con un set di scalabilità flessibile con FD=1, è necessario usare PowerShell per configurare Azure Site Recovery per il ripristino di emergenza.

Architettura di disaster recovery di riferimento per una piattaforma BI SAP BusinessObjects

Questa architettura di riferimento esegue una distribuzione a più istanze della piattaforma SAP BOBI con server applicazioni ridondanti. Per il ripristino di emergenza, è necessario eseguire il failover di tutti i componenti della piattaforma SAP BOBI in un'area secondaria. Nella figura seguente, Azure Premium Files viene usato come filestore, SQL Database viene usato come CMS e repository di audit, e Application Gateway viene usato per bilanciare il carico del traffico. La strategia per ottenere la protezione del ripristino di emergenza per ogni componente è diversa, descritta nella sezione seguente.

Diagramma che mostra il disaster recovery della piattaforma SAP BusinessObjects BI per Windows.

Load Balancer

Load Balancer viene usato per distribuire il traffico tra server applicazioni Web di una piattaforma SAP BOBI. In Azure è possibile usare Load Balancer o gateway applicazione per bilanciare il carico del traffico tra server Web. Per ottenere il ripristino di emergenza per i servizi di bilanciamento del carico, è necessario implementare un altro servizio di bilanciamento del carico o un gateway applicativo in un'area secondaria. Per mantenere lo stesso URL dopo il failover del ripristino di emergenza, modificare la voce nel DNS e puntare al servizio di bilanciamento del carico eseguito nell'area secondaria.

Macchine virtuali che eseguono server applicazioni Web e BI

Azure Site Recovery può essere usato per replicare le macchine virtuali che eseguono server applicazioni Web e BI nell'area secondaria. Site Recovery replica i server e tutti i dischi gestiti collegati all'area secondaria. Quando si verificano emergenze o interruzioni, è possibile eseguire facilmente il failover nell'ambiente replicato e continuare a lavorare. Per iniziare a replicare tutte le macchine virtuali dell'applicazione SAP nel data center di ripristino di emergenza di Azure, seguire le indicazioni in Replicare una macchina virtuale in Azure.

Directory del disco Filestore

Filestore è una directory del disco in cui vengono memorizzati file effettivi come report e documenti BI. Assicurarsi che tutti i file nell'archivio file siano sincronizzati con la regione DR. La strategia DR utilizzata per sincronizzare il contenuto dipende dal tipo di servizio di condivisione di file per la piattaforma SAP BOBI su Windows. Ad esempio:

  • File Premium di Azure supporta solo archiviazione con ridondanza locale e archiviazione con ridondanza della zona. Per la strategia di ripristino di emergenza di File Premium di Azure, è possibile usare AzCopy o Azure PowerShell per copiare i file in un altro account di archiviazione in un'area diversa. Per informazioni aggiuntive, vedere Ripristino di emergenza e failover dell'account di archiviazione.

  • Azure NetApp Files fornisce volumi NFS e SMB, quindi qualsiasi strumento di copia basato su file può essere usato per replicare i dati tra aree di Azure. Per altre informazioni su come copiare il volume di Azure NetApp Files in un'altra area, vedere Domande frequenti su Azure NetApp Files.

    È possibile utilizzare la replica tra regioni di Azure NetApp Files, che usa la tecnologia NetApp SnapMirror. Con questa tecnologia, solo i blocchi modificati vengono inviati in rete in un formato compresso ed efficiente. Questa tecnologia proprietaria riduce al minimo la quantità di dati necessari per la replica tra le aree, risparmiando così i costi di trasferimento dei dati. Riduce anche il tempo di replica in modo che sia possibile ottenere un RPO più piccolo. Per altre informazioni, vedere Requisiti e considerazioni per l'uso della replica tra aree.

Database CMS

Il database cms e il database di controllo nell'area di ripristino di emergenza devono essere una copia dei database in esecuzione nell'area primaria. In base al tipo di database, è importante copiare il database in una regione di ripristino di emergenza in base ai tempi di RTO e RPO richiesti dall'azienda. Questa sezione descrive le diverse opzioni disponibili per ogni soluzione di database in Azure supportata per un'applicazione SAP BOBI in esecuzione in Windows.

Database SQL di Azure

Per una strategia di ripristino di emergenza database SQL, sono disponibili due opzioni per copiare il database nell'area secondaria. Entrambe le opzioni di ripristino offrono livelli diversi di RTO e RPO. Per altre informazioni sull'opzione RTO e RPO per ogni opzione di ripristino, vedere Ripristinare un database in un server esistente.

Opzione 1: ripristino del backup del database con ridondanza geografica

  • Per impostazione predefinita, il database SQL archivia i dati in BLOB GRS replicati in un'area abbinata. Per un database SQL, la ridondanza dell'archiviazione di backup può essere configurata al momento della creazione del CMS e del database di audit. Può anche essere aggiornato per un database esistente. Le modifiche apportate a un database esistente si applicano solo ai backup futuri. È possibile ripristinare un database in qualsiasi database SQL in qualsiasi area di Azure dai backup con replica geografica più recente. Il ripristino geografico usa come origine un backup con replica geografica. Un ritardo si verifica tra il momento in cui il sistema crea un backup e il momento in cui replica il backup in un BLOB di Azure in un'area diversa. Di conseguenza, il database ripristinato può essere precedente fino a un'ora rispetto al database originale.

    Importante

    Il ripristino geografico è disponibile per i database SQL configurati con archiviazione di backup con ridondanza geografica.

Opzione 2: replica geografica o un gruppo di failover automatico

  • La replica geografica è una funzionalità di database SQL che consente di creare database secondari leggibili di singoli database in un server nella stessa area o in un'area diversa. Se la replica geografica è abilitata per il CMS e il database di audit, l'applicazione può avviare il failover verso un database secondario in una diversa area di Azure. La replica geografica è abilitata per i singoli database. Per abilitare il failover trasparente e coordinato di più database (CMS e controllo) per un'applicazione SAP BOBI, è consigliabile usare un gruppo di failover automatico. Fornisce la semantica del gruppo oltre alla replica geografica attiva, ovvero l'intero server SQL (tutti i database) viene replicato in un'altra area anziché in singoli database. Consulta la tabella delle funzionalità che confronta la replica geografica con i gruppi di failover.

  • I gruppi di failover automatico offrono endpoint listener di sola lettura e lettura/scrittura che rimangono invariati durante il failover. L'endpoint di lettura/scrittura può essere mantenuto come listener nella voce di connessione ODBC per il CMS e il database di verifica. Sia che si utilizzi l'attivazione manuale o automatica del failover, tutti i database secondari del gruppo vengono commutati a primario. Dopo aver completato il failover del database, il record DNS viene automaticamente aggiornato per reindirizzare gli endpoint alla nuova area. L'applicazione viene connessa automaticamente al database CMS perché l'endpoint di lettura/scrittura viene mantenuto come listener nella connessione ODBC.

    Nell'immagine seguente, un gruppo di failover automatico per il server SQL (azussqlbodb), in esecuzione nella regione Stati Uniti orientali 2, viene replicato nella regione secondaria Stati Uniti orientali, nota come sito di ripristino di emergenza (DR site). L'endpoint listener di lettura/scrittura viene mantenuto come listener in una connessione ODBC per il server di applicazioni BI in esecuzione su Windows. Dopo il failover, l'endpoint rimane invariato. Non è necessario alcun intervento manuale per connettere l'applicazione BI al database SQL nell'area secondaria.

    Screenshot che mostra i gruppi di failover automatico del database SQL.

    Questa opzione fornisce un valore RTO e RPO inferiore rispetto all'opzione 1. Per altre informazioni su questa opzione, vedere Usare i gruppi di failover automatico per abilitare il failover trasparente e coordinato di più database.

Database di Azure per MySQL

Database di Azure per MySQL offre opzioni per ripristinare un database in caso di emergenza. Scegliere l'opzione appropriata che funziona per l'azienda:

  • Abilitare le repliche in lettura tra aree per migliorare la continuità aziendale e la pianificazione del ripristino di emergenza. È possibile eseguire la replica da un server di origine fino a cinque repliche. Le repliche in lettura vengono aggiornate in modo asincrono usando la tecnologia di replica dei log binari di Azure Database per MySQL. Le repliche sono nuovi server da gestire in modo simile ai normali server di Database di Azure per MySQL. Per altre informazioni sulle repliche in lettura, sulle aree disponibili, sulle restrizioni e su come eseguire il failover, vedere Leggere le repliche in Database di Azure per MySQL.

  • Usare la funzionalità di ripristino geografico di Azure Database per MySQL, che ripristina il server usando backup con ridondanza geografica. Questi backup sono accessibili anche quando l'area in cui è ospitato il server è offline. È possibile eseguire il ripristino da questi backup a qualsiasi altra area e riportare il server online.

    Importante

    È possibile eseguire il Geo-restore solo se il server è stato configurato con un archivio di backup con ridondanza geografica. La modifica delle opzioni di ridondanza del backup dopo la creazione del server non è supportata. Per altre informazioni, vedere Ridondanza del backup.

Nella tabella seguente sono elencate le raccomandazioni per il ripristino di emergenza per ogni livello usato in questo esempio.

Livelli di piattaforma SAP BOBI Raccomandazione
Azure Application Gateway o Azure Load Balancer Configurazione parallela di Application Gateway in una regione secondaria
Server applicazioni Web Eseguire la replica utilizzando Azure Site Recovery
Server applicazioni BI Replica tramite Site Recovery
File Premium di Azure AzCopy o Azure PowerShell
Azure NetApp Files Strumento di copia basato su file per replicare i dati in un'area secondaria oppure replica tra aree di Azure NetApp Files
Database SQL di Azure Replica geografica/gruppi di failover automatico o ripristino geografico
Database di Azure per MySQL Repliche in lettura tra aree o backup di ripristino da backup con ridondanza geografica

Contenuti correlati

  • Last updated on