Bereitstellen der SAP BusinessObjects BI-Plattform in Azure für Windows

In diesem Artikel wird die Strategie zum Bereitstellen der SAP BusinessObjects Business Intelligence (BOBI)-Plattform in Azure für Windows beschrieben. Im Rahmen des verwendeten Beispiels werden zwei virtuelle Computer (VMs) mit Azure SSD Premium Managed Disks als Installationsverzeichnis konfiguriert. Azure SQL-Datenbank – ein PaaS-Angebot (Platform-as-a-Service) – wird für die CMS- (Central Management Server) und die Überwachungsdatenbank verwendet. Azure Premium Files, ein SMB-Protokoll, wird als Dateispeicher verwendet, der für beide VMs freigegeben ist. Die standardmäßige Tomcat Java-Webanwendung und die BI-Plattformanwendung (Business Intelligence) werden zusammen auf beiden VMs installiert. Für den Lastenausgleich der Benutzeranforderungen wird das Azure Application Gateway verwendet, das native TLS/SSL-Auslagerungsfunktionen besitzt.

Diese Art von Architektur eignet sich für kleine Bereitstellungen oder Nichtproduktionsumgebungen. Für die Bereitstellung in der Produktion bzw. im großen Stil sollten Sie die Hosts für Webanwendungen trennen. Darüber hinaus können Sie auch mehrere SAP BOBI-Anwendungshosts verwenden, damit vom Server mehr Informationen verarbeitet werden können.

Diagramm: SAP BOBI-Bereitstellung in Azure für Windows

Dateisystem BESCHREIBUNG Größe (GB) Erforderlicher Zugriff Speicher
F: Das Dateisystem für die Installation einer SAP BOBI-Instanz, der Tomcat-Standard-Webanwendung und der Datenbanktreiber (falls erforderlich). SAP-Richtlinien zur Dimensionierung Lokale Administratorrechte Azure Premium SSD verwaltete Datenträger
\\azusbobi.file.core.windows.net\frsinput Das Einbindungsverzeichnis ist für die freigegebenen Dateien aller SAP BOBI-Hosts vorgesehen und wird als Eingangsverzeichnis für die Dateispeicherung (Filestore) verwendet. Geschäftliche Anforderung Lokale Administratorrechte Azure NetApp Files
\\azusbobi.file.core.windows.net\frsoutput Das Einbindungsverzeichnis ist für die freigegebenen Dateien aller SAP BOBI-Hosts vorgesehen und wird als Ausgangsverzeichnis für die Dateispeicherung (Filestore) verwendet. Geschäftliche Anforderung Lokale Administratorrechte Azure NetApp Files

Voraussetzungen

  • Ein Azure-Abonnement mit Berechtigungen zum Erstellen von Ressourcen wie VMs, Speicherkonten, SQL-Datenbankinstanzen und virtuellen Netzwerken.
  • Die Dimensionierung der SAP BOBI-Plattform wurde basierend auf der Planungs- und Implementierungsanleitung für SAP BOBI auf Azure abgeschlossen.
  • INSTALLATIONSmedien der SAP BusinessObjects BI-Plattform (Version 4.3 SP01 Patch 1 oder höher). Einen temporären Lizenzschlüssel finden Sie unter SAP Note 1288121.
  • Ein Microsoft ODBC-Treiber , der mit Azure SQL-Datenbank kompatibel ist. In diesem Artikel wird Version 13.1 verwendet.
  • Windows Server 2019 oder eine unterstützte Betriebssystemversion pro SAP-Produktverfügbarkeitsmatrix.
  • Ausgehender Netzwerkzugriff auf Port 1433 von SAP BOBI-Anwendungsservern zu Azure SQL-Datenbank.
  • Ausgehender Netzwerkzugriff auf Port 445 von SAP BOBI-Anwendungsservern, wenn Sie Azure Premium Files (SMB) verwenden.

Bereitstellen einer Windows-VM mithilfe des Azure-Portals

In diesem Abschnitt erstellen Sie zwei VMs mit einem Windows-Betriebssystemimage (OS) für die SAP BOBI-Plattform. Allgemeine Schritte für die Erstellung von VMs:

  1. Erstellen Sie eine Ressourcengruppe.

  2. Erstellen Sie ein virtuelles Netzwerk:

    • Verwenden Sie bei der Bereitstellung der SAP BI-Plattform nicht nur ein gemeinsames Subnetz für alle Azure-Dienste. Basierend auf der SAP BI-Plattformarchitektur müssen Sie möglicherweise mehrere Subnetze erstellen. In dieser Bereitstellung erstellen Sie zwei Subnetze: ein BI-Anwendungssubnetz und ein Anwendungsgateway-Subnetz.
    • Befolgen Sie SAP-Hinweis 2276646, um Ports für die Kommunikation der SAP BOBI-Plattform über verschiedene Komponenten hinweg zu identifizieren.
    • SQL-Datenbank kommuniziert über Port 1433. Der ausgehende Datenverkehr über Port 1433 von Ihren SAP BOBI-Anwendungsservern sollte zugelassen sein.
    • In Azure muss sich die Application Gateway-Instanz in einem separaten Subnetz befinden. Weitere Informationen finden Sie unter Application Gateway-Konfiguration: Übersicht.
    • Wenn Sie Azure NetApp-Dateien für einen Dateispeicher anstelle von Azure Files verwenden, erstellen Sie ein separates Subnetz für Azure NetApp-Dateien. Weitere Informationen finden Sie unter Richtlinien für die Azure NetApp Files-Netzwerkplanung.

  3. Wählen Sie je nach ihrer bevorzugten Systemkonfiguration in einer Azure-Region die geeigneten Verfügbarkeitsoptionen aus, unabhängig davon, ob:

    • Es umfasst das Übergreifen von Zonen.
    • Befindet sich innerhalb einer einzelnen Zone
    • Arbeitet in einer zonenfreien Region

  4. Erstellen sie VM 1 (azuswinboap1):

  5. Erstellen Sie VM 2 (azuswinboap2).

  6. Fügen Sie eine Premium-SSD hinzu. Es wird als SAP BOBI-Installationsverzeichnis verwendet.

Bereitstellung von Azure Premium-Dateien

Bevor Sie mit der Einrichtung von Azure Files beginnen, sollten Sie sich mit der Azure Files-Dokumentation vertraut machen.

Azure Files verfügt über Standard-Dateifreigaben, die auf festplattenbasierter Hardware (HDD) gehostet werden, und über Premium-Dateifreigaben, die auf SSD-basierter Hardware gehostet werden. Verwenden Sie für einen SAP BusinessObjects-Dateispeicher Azure Premium Files.

Azure Premium-Dateifreigaben sind in einigen Regionen mit lokaler Redundanz und Zonenredundanz verfügbar. Informationen dazu, ob Premium-Dateifreigaben derzeit in Ihrer Region verfügbar sind, finden Sie unter "Produkte, die nach Region verfügbar sind". Informationen zu Regionen, die zonenredundanten Speicher (ZRS) unterstützen, finden Sie unter Azure Storage-Redundanz.

Bereitstellen eines Azure Files-Speicherkontos und von NFS-Freigaben

Azure-Dateifreigaben werden in Speicherkonten bereitgestellt, die als Objekte der höchsten Ebene einen gemeinsam genutzten Speicherpool repräsentieren. Dieser Speicherpool kann verwendet werden, um mehrere Dateifreigaben bereitzustellen. Azure unterstützt mehrere Arten von Speicherkonten für die möglichen unterschiedlichen Speicherszenarien der Kunden. Für SAP BusinessObjects-Dateispeicher müssen Sie ein FileStorage-Konto erstellen. Sie verwenden es, um Azure-Dateifreigaben auf Premium-SSD-basierter Hardware bereitzustellen.

Hinweis

FileStorage-Konten können nur zum Speichern von Azure-Dateifreigaben verwendet werden. Unter einem FileStorage-Konto können keine anderen Speicherressourcen, z. B. Blobs, Container, Warteschlangen oder Tabellen, bereitgestellt werden.

Auf das Speicherkonto wird über einen privaten Endpunkt zugegriffen und im selben virtuellen Netzwerk einer SAP BOBI-Plattform bereitgestellt. Bei diesem Setup verlässt der Datenverkehr Ihres SAP-Systems niemals die Sicherheitsgrenzen des virtuellen Netzwerks. Da SAP-Systeme häufig vertrauliche und unternehmenskritische Daten enthalten, ist der Verbleib innerhalb der Grenzen des virtuellen Netzwerks für viele Kunden ein wichtiger Sicherheitsaspekt.

Wenn Sie über ein anderes virtuelles Netzwerk auf das Speicherkonto zugreifen müssen, können Sie das Peering in virtuellen Azure-Netzwerken verwenden.

Azure Files-Speicherkonto

  1. Wählen Sie zum Erstellen eines Speicherkontos mithilfe des Azure-Portals Ressource erstellen>Speicher> und Speicherkonto aus.

  2. Füllen Sie auf der Registerkarte Grundlagen alle erforderlichen Felder aus, um ein Speicherkonto zu erstellen:

    1. Wählen Sie Abonnement>Ressourcengruppe>Region aus.

    2. Geben Sie den Namen des Speicherkontos ein. Geben Sie beispielsweise azusbobi ein. Dieser Name muss global eindeutig sein, aber ansonsten haben Sie freie Wahl.

    3. Wählen Sie Premium als Leistungsstufe und FileStorage als Kontoart aus.

    4. Wählen Sie für die Bezeichnung Replikation eine Redundanzstufe aus. Wählen Sie Lokal redundanter Speicher (LRS) aus.

      Für FileStorage vom Typ „Premium“ sind „ZRS“ und „LRS“ die einzigen verfügbaren Optionen. Wählen Sie basierend auf Ihrer VM-Bereitstellungsstrategie (flexibler Skalierungssatz, Verfügbarkeitszone oder Verfügbarkeitssatz) die entsprechende Redundanzstufe aus. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

    5. Wählen Sie Weiter aus.

  3. Wählen Sie auf der Registerkarte Netzwerk die Option Privater Endpunkt als Konnektivitätsmethode aus. Weitere Informationen finden Sie unter Azure Files – Überlegungen zum Netzwerkbetrieb.

    1. Wählen Sie im Abschnitt privater Endpunkt die Option Hinzufügen aus.

    2. Wählen Sie Abonnement>Ressourcengruppe>Standort aus.

    3. Geben Sie im Feld Name den Namen des privaten Endpunkts ein. Geben Sie beispielsweise azusbobi-pe ein.

    4. Wählen Sie die Datei in der Speicherunterressource aus.

    5. Wählen Sie im Abschnitt Netzwerk das virtuelle Netzwerk und das Subnetz aus, in dem die SAP BusinessObjects BI-Anwendung bereitgestellt wird.

    6. Übernehmen Sie die Standardeinstellung (Ja) für In private DNS-Zone integrieren.

    7. Wählen Sie in der Dropdownliste Ihre private DNS-Zone aus.

    8. Wählen Sie OK aus, um zurück zur Registerkarte Netzwerk unter Speicherkonto erstellen zu wechseln.

  4. Im Abschnitt „Datenschutz“ können Sie die Richtlinie für vorläufiges Löschen für Azure-Dateifreigaben in Ihrem Speicherkonto konfigurieren. Standardmäßig ist die Funktion für vorläufiges Löschen deaktiviert. Weitere Informationen zu Soft Delete finden Sie unter Verhindern eines versehentlichen Löschens von Azure-Dateifreigaben.

  5. Wählen Sie auf der Registerkarte Erweitert verschiedene Sicherheitsoptionen aus.

    Im Feld Sichere Übertragung erforderlich wird angegeben, ob für die eingehende Kommunikation mit dem Speicherkonto eine Verschlüsselung für die Übertragung erforderlich ist. Wenn Sie Unterstützung für SMB 2.1 benötigen, müssen Sie diese Option deaktivieren. Behalten Sie für die SAP BOBI-Plattform die Einstellung Standard (Aktiviert) bei.

  6. Fahren Sie fort und erstellen Sie das Speicherkonto.

Weitere Informationen zum Erstellen eines Speicherkontos finden Sie unter Erstellen eines FileStorage-Speicherkontos.

Erstellen Sie Azure-Dateifreigaben

Der nächste Schritt besteht darin, Azure-Dateifreigaben im Speicherkonto zu erstellen. Azure-Dateifreigaben verwenden ein bereitgestelltes Modell für Premium-Dateifreigaben. In einem bereitgestellten Geschäftsmodell definieren Sie proaktiv Ihre Speicheranforderungen für den Azure Files-Dienst, anstatt nach Nutzung abgerechnet zu werden. Weitere Informationen zu diesem Modell finden Sie unter Bereitgestelltes Modell. In diesem Beispiel erstellen Sie zwei Azure-Dateifreigaben: frsinput (256 GB) und frsoutput (256 GB) für den SAP BOBI-Dateispeicher.

  1. Gehen Sie zu dem Speicherkonto azusbobi>Dateifreigaben.
  2. Wählen Sie Neue Dateifreigabe aus.
  3. Geben Sie den Namen der Dateifreigabe ein. Geben Sie beispielsweise frsinput oder frsoutput ein.
  4. Geben Sie die erforderliche Größe der Dateifreigabe in bereitgestellter Kapazität ein. Geben Sie beispielsweise 256 GB ein.
  5. Wählen Sie SMB als Protokoll aus.
  6. Klicken Sie auf Erstellen.

Konfigurieren eines Datenträgers auf einer Windows-VM

Für die Schritte in diesem Abschnitt wird das folgende Präfix verwendet:

[A] : Der Schritt gilt für alle Hosts.

Initialisieren eines neuen Datenträgers

Für die SAP BusinessObjects BI-Anwendung ist eine Partition erforderlich, auf der die zugehörigen Binärdateien installiert werden können. Sie können eine SAP BOBI-Anwendung auf der Betriebssystempartition (C:) installieren, aber Sie müssen sicherstellen, dass genügend Speicherplatz für die Bereitstellung und das Betriebssystem vorhanden ist. Wir empfehlen Ihnen, mindestens 2 GB für temporäre Dateien und Webanwendungen verfügbar zu halten. Außerdem wird empfohlen, sap BOBI-Installationsbinärdateien in separate Partitionen zu trennen.

In diesem Beispiel wird eine SAP BOBI-Anwendung auf einer separaten Partition (F:) installiert. Initialisieren Sie die Premium-SSD, die Sie während der VM-Bereitstellung angefügt haben:

  1. [A] Wenn kein Datenträger an die VM („azuswinboap1“ und „azuswinboap2“) angefügt ist, befolgen Sie die Schritte unter Hinzufügen eines Datenträgers, um einen neuen verwalteten Datenträger anzufügen.
  2. [A] Nachdem der verwaltete Datenträger an die VM angefügt wurde, initialisieren Sie den Datenträger mit den Schritten unter Initialisieren eines neuen Datenträgers.

Einbinden von Azure Files Premium

Um Azure Files als Dateispeicher zu verwenden, müssen Sie es einbinden, das bedeutet, dass Sie ihm einen Laufwerkbuchstaben oder einen Einbindungspunktpfad zuweisen.

[A] Führen Sie zum Einbinden der Azure-Dateifreigabe die Schritte unter Einbinden der Azure-Dateifreigabe aus.

Zum Mounten einer Azure-Dateifreigabe auf einem Windows Server muss für das SMB-Protokoll TCP-Port 445 geöffnet sein. Verbindungen schlagen fehl, wenn Port 445 blockiert wird. Sie können mithilfe des Test-NetConnection Cmdlets überprüfen, ob Ihre Firewall oder Ihr ISP Port 445 blockiert. Siehe Port 445 ist blockiert.

Konfigurieren einer CMS-Datenbank: Azure SQL

Dieser Abschnitt enthält ausführliche Informationen zur Bereitstellung von Azure SQL über das Azure-Portal. Er enthält auch Anweisungen zum Erstellen der CMS- und der Überwachungsdatenbank für eine SAP BOBI-Plattform und ein Benutzerkonto für den Zugriff auf die Datenbanken.

Die Anleitung ist nur gültig, wenn Sie SQL-Datenbank verwenden. Eine Anleitung für andere Datenbanken finden Sie in der SAP- oder datenbankspezifischen Dokumentation.

Erstellen eines SQL-Datenbank-Servers

SQL-Datenbank verfügt über verschiedene Bereitstellungsoptionen: Einzeldatenbank, Pool für elastische Datenbanken und Datenbankserver. Für eine SAP BOBI-Plattform benötigen Sie zwei Datenbanken, CMS und Audit. Anstatt zwei Einzeldatenbanken zu erstellen, können Sie auch einen SQL-Datenbank-Server erstellen, über den die Gruppe mit den Einzeldatenbanken und Pools für elastische Datenbanken verwaltet werden kann. Führen Sie die folgenden Schritte aus, um einen SQL-Datenbank-Server zu erstellen:

  1. Navigieren Sie zur Seite SQL-Bereitstellungsoption auswählen.

  2. Ändern Sie unter SQL-Datenbanken den Ressourcentyp in Datenbankserver. Klicken Sie auf Erstellen.

  3. Füllen Sie auf der Registerkarte " Grundlagen " alle erforderlichen Felder zum Erstellen von SQL-Datenbankserver aus:

    1. Wählen Sie unter Projektdetails das Abonnement und die Ressourcengruppe aus.

    2. Geben Sie im Feld Servername einen Namen ein. Geben Sie beispielsweise azussqlbodb ein. Der Servername muss global eindeutig sein, aber ansonsten haben Sie freie Wahl.

    3. Wählen Sie den Ort aus.

    4. Geben Sie die Serveradministratoranmeldung ein. Geben Sie beispielsweise boadmin ein. Geben Sie anschließend ein Kennwort ein.

  4. Ändern Sie auf der Registerkarte Netzwerk unter Firewallregeln den Zugriff von Azure-Diensten und -Ressourcen auf diesen Server erlauben in Nein.

  5. Behalten Sie unter Zusätzliche Einstellungen die Standardeinstellungen bei.

  6. Fahren Sie fort und erstellen Sie den SQL-Datenbank-Server.

Erstellen Sie im nächsten Schritt das CMS und die Überwachungsdatenbanken auf dem SQL-Datenbankserver (azussqlbodb.database.windows.net).

Erstellen der CMS- und der Überwachungsdatenbank

Navigieren Sie nach der Bereitstellung des SQL-Datenbank-Servers zur Ressource „azussqlbodb“. Führen Sie dann die folgenden Schritte aus, um die CMS- und die Überwachungsdatenbank zu erstellen.

  1. Wählen Sie auf der Seite Übersicht für „azussqlbodb“ die Option Datenbank erstellen aus.

  2. Füllen Sie auf der Registerkarte " Grundlagen " alle erforderlichen Felder aus:

    1. Geben Sie den Datenbankname ein. Geben Sie z. B. bocms oder boaudit ein.

    2. Wählen Sie unter Compute + Speicher die Option Datenbank konfigurieren aus. Wählen Sie basierend auf Ihrem Dimensionierungsergebnis das passende Modell aus. Informationen zu den Optionen finden Sie unter Dimensionierungsmodelle für Azure SQL-Datenbank.

  3. Wählen Sie auf der Registerkarte Netzwerk die Option Privater Endpunkt als Konnektivitätsmethode aus. Der private Endpunkt wird für den Zugriff auf die SQL-Datenbank innerhalb des konfigurierten virtuellen Netzwerks verwendet.

    1. Wählen Sie Privaten Endpunkt hinzufügen.

    2. Wählen Sie Abonnement>Ressourcengruppe>Standort aus.

    3. Geben Sie im Feld Name den Namen des privaten Endpunkts ein. Geben Sie beispielsweise azusbodb-pe ein.

    4. Wählen Sie unter Zielunterressource die Option SqlServer aus.

    5. Wählen Sie im Abschnitt Netzwerk das virtuelle Netzwerk und das Subnetz aus, in dem die SAP BusinessObjects BI-Anwendung bereitgestellt wird.

    6. Übernehmen Sie die Standardeinstellung (Ja) für In private DNS-Zone integrieren.

    7. Wählen Sie in der Dropdownliste Ihre private DNS-Zone aus.

    8. Wählen Sie OK aus, um zurück zur Registerkarte Netzwerk unter SQL-Datenbank erstellen zu wechseln.

  4. Ändern Sie auf der Registerkarte Zusätzliche Einstellungen die Einstellung Kollationierung in SQL_Latin1_General_CP850_BIN2.

  5. Fahren Sie fort, und erstellen Sie die CMS-Datenbank.

Auf ähnliche Weise können Sie auch die Überwachungsdatenbank erstellen. Geben Sie beispielsweise boaudit ein.

Herunterladen und Installieren eines ODBC-Treibers

Für SAP BOBI-Anwendungsserver müssen der Datenbankclient bzw. die Datenbanktreiber auf die CMS- oder die Überwachungsdatenbank zugreifen können. Ein Microsoft ODBC-Treiber wird verwendet, um auf CMS- und Überwachungsdatenbanken zuzugreifen, die unter SQL-Datenbank ausgeführt werden. Dieser Abschnitt enthält Anweisungen zum Herunterladen und Einrichten eines ODBC-Treibers unter Windows.

  1. Informationen zu den Datenbank-Connectors, die mit der SQL-Datenbank kompatibel sind, finden Sie im Abschnitt CMS- und Audit-Repository-Unterstützung nach Betriebssystem in der Produktverfügbarkeitsmatrix (PAM) für die SAP BusinessObjects BI-Plattform.
  2. Laden Sie den ODBC-Treiber herunter. In diesem Beispiel verwendet dieser Artikel ODBC-Treiber 13.1.
  3. Installieren Sie den ODBC-Treiber auf allen BI-Servern (azuswinboap1 und azuswinboap2).
  4. Navigieren Sie nach dem Installieren des Treibers auf azuswinboap1 zu Start>Windows-Verwaltungsprogramme>ODBC-Datenquellen (64 Bit) .
  5. Wechseln Sie zur Registerkarte System-DSN.
  6. Wählen Sie Hinzufügen aus, um eine Verbindung mit der CMS-Datenbank herzustellen.
  7. Wählen Sie ODBC Driver 13 for SQL Server und dann Fertig stellen aus.
  8. Geben Sie die Informationen Ihrer CMS-Datenbank wie unten angegeben ein, und wählen Sie Weiter aus:
    • Name: Der Name der Datenbank, die im Abschnitt "Erstellen des CMS und der Überwachungsdatenbank" erstellt wurde. Geben Sie bocms z. B. ein oder .boaudit
    • Beschreibung: Enthält eine Beschreibung der Datenquelle. Geben Sie beispielsweise CMS-Datenbank oder Überwachungsdatenbank ein.
    • Server: Der Name des Servers, der im Abschnitt "Erstellen eines SQL-Datenbankservers" erstellt wurde. Geben Sie azussqlbodb.database.windows.netz. B. ein .
  9. Wählen Sie Mit SQL Server-Authentifizierung anhand der vom Benutzer eingegebenen Anmelde-ID und des Kennworts aus, um die Authentizität für Azure SQL Server zu überprüfen. Geben Sie die Benutzeranmeldeinformationen ein, die während der Erstellung des SQL-Datenbank-Servers erstellt wurden. Geben Sie beispielsweise boadmin ein. Wählen Sie Weiter aus.
  10. Ändern Sie die Standarddatenbank in bocms, und lassen Sie alle anderen Einstellungen auf Standard. Wählen Sie Weiter aus.
  11. Aktivieren Sie das Kontrollkästchen Starke Verschlüsselung für Daten verwenden, und behalten Sie für alle anderen Optionen die Standardeinstellung bei. Wählen Sie Fertig stellen aus.
  12. Die Datenquelle für die CMS-Datenbank wird erstellt. Sie können jetzt " Datenquelle testen " auswählen, um die Verbindung mit der CMS-Datenbank aus der BI-Anwendung zu überprüfen. Es sollte erfolgreich abgeschlossen werden. Wenn ein Fehler auftritt, beheben Sie das Konnektivitätsproblem.

Hinweis

SQL-Datenbank kommuniziert über Port 1433. Der ausgehende Datenverkehr über Port 1433 von Ihren SAP BOBI-Anwendungsservern sollte zugelassen sein.

Wiederholen Sie die obigen Schritte, um eine Verbindung für die Überwachungsdatenbank auf dem Server „azuswinboap1“ zu erstellen. Installieren und konfigurieren Sie auf ähnliche Weise beide ODBC-Datenquellen (bocms und boaudit) auf allen BI-Anwendungsservern (azuswinboap2).

Servervorbereitung

Befolgen Sie die neuesten Anleitungen von SAP, um Server für die Installation der BI-Plattform vorzubereiten. Aktuelle Informationen finden Sie im Abschnitt „Vorbereitung“ des Installationshandbuchs der SAP Business Intelligence-Plattform für Windows.

Installieren der BI-Plattform auf einem Windows-Host

Melden Sie sich mit einem Benutzer an, der über lokale Administratorrechte verfügt, um die BI-Plattform auf einem Windows-Host zu installieren.

Navigieren Sie zu den Medien der SAP BusinessObjects BI-Plattform, und führen Sie setup.exe aus.

Befolgen Sie die für Ihre Version bestimmte Anleitung im Installationshandbuch der SAP Business Intelligence-Plattform für Windows. Beachten Sie bei der Installation der SAP BOBI-Plattform unter Windows die folgenden Punkte:

  • Geben Sie auf dem Bildschirm Zielordner konfigurieren den Zielordner an, in dem Sie die BI-Plattform installieren möchten. Geben Sie beispielsweise F:\SAP BusinessObjects* ein.

  • Auf dem Bildschirm Produktregistrierung konfigurieren können Sie entweder einen temporären Lizenzschlüssel für SAP BusinessObjects Solutions aus dem SAP-Hinweis 1288121 verwenden oder einen Lizenzschlüssel über den SAP Service Marketplace generieren.

  • Wählen Sie auf dem Bildschirm Select Install Type (Installationstyp auswählen) die vollständige Installation auf dem ersten Server (azuswinboap1) aus. Wählen Sie für den anderen Server (azuswinboap2) die Option Anpassen/Erweitern aus, mit der das vorhandene SAP BOBI-Setup erweitert wird.

  • Wählen Sie auf dem Bildschirm zum Auswählen der Standard- oder einer vorhandenen Datenbank die Option zum Konfigurieren einer vorhandenen Datenbank aus. Sie werden dann aufgefordert, die CMS- und die Überwachungsdatenbank auszuwählen. Wählen Sie Microsoft SQL Server für ODBC für den Typ CMS-Datenbank und den Typ Überwachungsdatenbank aus.

    Sie können auch die Option für Keine Überwachungsdatenbank auswählen, wenn Sie die Überwachung während der Installation nicht konfigurieren möchten.

  • Wählen Sie geeignete Optionen auf dem Bildschirm zum Auswählen des Java-Webanwendungsservers basierend auf Ihrer SAP BOBI-Architektur aus. In diesem Beispiel ist Option 1 ausgewählt, wodurch ein Tomcat-Server auf derselben SAP BOBI-Plattform installiert wird.

  • Geben Sie CMS-Datenbankinformationen in CMS-Repository-Datenbank konfigurieren: SQL-Server (ODBC) ein. In der folgenden Abbildung ist eine Beispieleingabe für CMS-Datenbankinformationen für eine Windows-Installation dargestellt.

    Screenshot: CMS-Datenbankinformationen für Windows

  • (Optional) Geben Sie Informationen zur Überwachungsdatenbank unter Configure Auditing Database – SQL Server (ODBC) (Überwachungsdatenbank konfigurieren – SQL Server (ODBC)) ein. In der folgenden Abbildung ist eine Beispieleingabe für Informationen zur Überwachungsdatenbank für eine Windows-Installation dargestellt.

    Screenshot, der die Überwachungsdatenbank-Informationen für Windows zeigt.

  • Führen Sie die Installation nach den Anweisungen aus, und geben Sie die erforderlichen Eingaben ein.

Bei einer Bereitstellung mit mehreren Instanzen führen Sie das Installationssetup auf dem zweiten Host (azuswinboap2) aus. Wählen Sie auf dem Bildschirm zum Auswählen des Installationstyps die Option zum Anpassen/Erweitern aus, um das vorhandene SAP BOBI-Setup zu erweitern. Weitere Informationen finden Sie im SAP-Blog zum Thema Setup der SAP BusinessObjects Business Intelligence-Plattform mit Azure SQL-Datenbank.

Wichtig

Die Versionsnummern der Datenbank-Engine für SQL Server und SQL-Datenbank sind nicht miteinander vergleichbar. Es handelt sich hierbei um interne Buildnummern für diese separaten Produkte. Die Datenbank-Engine für SQL-Datenbank basiert auf der gleichen Codebasis wie die SQL Server-Datenbank-Engine. Am wichtigsten ist, dass die Datenbank-Engine in der SQL-Datenbank immer die neuesten SQL-Datenbank-Engine-Komponenten enthält. Die Version 12 von SQL-Datenbank ist neuer als die Version 15 von SQL Server.

Um die aktuelle Version von SQL-Datenbank zu ermitteln, können Sie entweder in den Einstellungen der zentralen Verwaltungskonsole (Central Management Console, CMC) nachsehen oder die folgende Abfrage mit sqlcmd oder SQL Server Management Studio ausführen. Informationen zur Ausrichtung von SQL-Versionen an der Standardkompatibilität finden Sie im Artikel Datenbank-Kompatibilitätsgrad.

Screenshot mit Datenbankinformationen 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)

Nach der Installation

Nach einer Installation der SAP BOBI-Plattform mit mehreren Instanzen müssen zusätzliche Nachbearbeitungsschritte ausgeführt werden, um die Hochverfügbarkeit von Anwendungen zu unterstützen.

Konfigurieren eines Clusternamens

Bei einer Bereitstellung der SAP BOBI-Plattform mit mehreren Instanzen sollen mehrere CMS-Server gemeinsam in einem Cluster ausgeführt werden. Ein Cluster besteht aus zwei oder mehr CMS-Servern, die mit einer gemeinsamen CMS-Systemdatenbank zusammenarbeiten. Wenn ein Knoten, der auf CMS ausgeführt wird, fehlschlägt, verwendet ein Knoten mit einem anderen CMS weiterhin BI-Plattformanforderungen. Standardmäßig wird mit einem Clusternamen auf der SAP BOBI-Plattform der Hostname des ersten CMS angegeben, das Sie installieren.

Befolgen Sie die Anleitung im Administratorhandbuch für die SAP Business Intelligence-Plattform, um den Clusternamen unter Windows zu konfigurieren. Befolgen Sie nach dem Konfigurieren des Clusternamens den SAP-Hinweis 1660440, um den Standardsystemeintrag auf der Anmeldeseite der CMC oder des BI-Launchpads festzulegen.

Konfigurieren des Speicherorts des Eingangs- und Ausgangsdateispeichers in Azure Files Premium

Mit dem Dateispeicher (Filestore) sind hier die Datenträgerverzeichnisse gemeint, in denen sich die eigentlichen SAP BusinessObjects-Dateien befinden. Der Standardspeicherort des Dateirepositoryservers für die SAP BOBI-Plattform befindet sich im lokalen Installationsverzeichnis. Bei der Bereitstellung mit mehreren Instanzen ist es wichtig, den Filestore in einem freigegebenen Speicher wie Azure Premium Files oder Azure NetApp Files einzurichten, damit darauf von allen Servern der Speicherebene zugegriffen werden kann.

  1. Wenn die Erstellung nicht durchgeführt wird, sollten Sie die Anleitung im obigen Abschnitt „Bereitstellen von Azure Files Premium“ befolgen, um Azure Files Premium zu erstellen und einzubinden.

    Tipp

    Basierend darauf, ob der virtuelle Computer auf zonal oder regionaler Weise bereitgestellt wird, sollte die Auswahl der Speicherredundanz für Azure Premium Files (ZRS oder LRS) ermittelt werden.

  2. Befolgen Sie den SAP-Hinweis 2512660, um den Pfad des Dateirepositorys (Eingabe und Ausgabe) zu ändern.

Tomcat-Clustering: Sitzungsreplikation

Tomcat unterstützt das Clustering von mindestens zwei Anwendungsservern für Sitzungsreplikation und Failover. SAP BOBI-Plattformsitzungen sind serialisiert. Für eine Benutzersitzung kann selbst dann reibungslos ein Failover auf eine andere Instanz von Tomcat ausgeführt werden, wenn ein Anwendungsserver ausfällt. Es kann beispielsweise sein, dass ein Benutzer mit einem Webserver verbunden ist, der ausfällt, während der Benutzer in einer Ordnerhierarchie in einer SAP BI-Anwendung navigiert. In einem richtig konfigurierten Cluster kann der Benutzer weiterhin in der Ordnerhierarchie navigieren, ohne zu einer Anmeldeseite umgeleitet zu werden.

Im SAP-Hinweis 2808640 sind die Schritte zum Konfigurieren von Tomcat-Clusterings per Multicast angegeben. Multicast wird in Azure aber nicht unterstützt. Damit ein Tomcat-Cluster in Azure funktioniert, müssen Sie StaticMembershipInterceptor verwenden (SAP-Hinweis 2764907).

Informationen zum Einrichten eines Tomcat-Clusters in Azure finden Sie unter Tomcat-Clustering mit statischer Mitgliedschaft für die SAP BusinessObjects BI-Plattform im SAP-Blog.

Lastenausgleich für eine Webebene einer SAP BI-Plattform

Bei einer Bereitstellung von SAP BOBI mit mehreren Instanzen werden Java-Webanwendungsserver (Webebene) auf zwei oder mehr Hosts ausgeführt. Um die Benutzerauslastung gleichmäßig auf die Webserver zu verteilen, können Sie einen Lastenausgleich zwischen Endbenutzern und Webservern verwenden. Sie können Azure Load Balancer oder Azure Application Gateway verwenden, um den Datenverkehr zu verwalten, der an Ihre Webanwendungsserver fließt. Die verfügbaren Angebote werden in den folgenden Abschnitten näher beschrieben:

  • Azure Load Balancer ist ein Layer 4-Lastenausgleichsmodul (TCP, UDP) mit hoher Leistung und geringer Latenz, mit dem der Datenverkehr auf fehlerfreie VMs verteilt wird. Über den Integritätstest eines Lastenausgleichsmoduls wird ein bestimmter Port auf jeder VM überwacht und Datenverkehr nur auf betriebsbereite VMs verteilt. Sie können entweder ein öffentliches oder ein internes Lastenausgleichsmodul wählen. Dies richtet sich danach, ob die SAP BI-Plattform über das Internet zugänglich sein soll. Hierbei ist für Zonenredundanz gesorgt, damit die Hochverfügbarkeit über mehrere Verfügbarkeitszonen hinweg sichergestellt ist.

    In der folgenden Abbildung finden Sie den Abschnitt "Internal Load Balancer", in dem der Webanwendungsserver auf Port 8080 ausgeführt wird. Dieser Port ist der standardmäßige Tomcat-HTTP-Port, den ein Integritätstest überwacht. Jede eingehende Anforderung von Benutzern wird im Back-End-Pool an die Webanwendungsserver (azuswinboap1 oder azuswinboap2) umgeleitet. Für das Lastenausgleichsmodul wird der TLS/SSL-Abschluss (auch als TLS/SSL-Abladung bezeichnet) nicht unterstützt. Wenn Sie Load Balancer verwenden, um Datenverkehr auf Webserver zu verteilen, empfehlen wir die Nutzung von Load Balancer Standard.

    Hinweis

    Wenn VMs ohne öffentliche IP-Adressen im Back-End-Pool des internen Standardlastenausgleichs (keine öffentliche IP-Adresse) platziert werden, gibt es keine ausgehende Internetverbindung, es sei denn, Sie führen eine zusätzliche Konfiguration aus, um das Routing an öffentliche Endpunkte zu ermöglichen. Für Informationen zur Erreichung der ausgehenden Konnektivität siehe Public Endpoint-Konnektivität für VMs mit Azure Standard Load Balancer in SAP-Hochverfügbarkeitsszenarien.

    Screenshot, der zeigt, wie ein Load Balancer den Datenverkehr auf Webserver verteilt.

  • Application Gateway verfügt über einen Controller zur Anwendungsbereitstellung als Dienst, mit dessen Hilfe Anwendungen Benutzerdatenverkehr an einen oder mehrere Webanwendungsserver leiten können. Sie können für Ihre Anwendungen verschiedene Layer 7-Lastenausgleichsfunktionen nutzen, z. B. TLS/SSL-Abladung, Web Application Firewall (WAF) und cookiebasierte Sitzungsaffinität.

    Auf einer SAP BI-Plattform leitet Application Gateway den Webdatenverkehr von Anwendungen an die angegebenen Ressourcen in einem Back-End-Pool weiter. In diesem Fall ist dies entweder „azuswinboap1“ oder „azuswinboap2“. Sie weisen dem Port einen Listener zu, erstellen Regeln und fügen einem Back-End-Pool Ressourcen hinzu. In der folgenden Abbildung fungiert eine Application Gateway-Instanz mit einer privaten Front-End-IP-Adresse (10.31.3.25) als Einstiegspunkt für Benutzer, verarbeitet eingehende TLS/SSL-Verbindungen (HTTPS – TCP/443), führt die TLS/SSL-Entschlüsselung durch und übergibt die Anforderung (HTTP – TCP/8080) an die Server im Back-End-Pool. Dank der integrierten Funktion für den TLS/SSL-Abschluss müssen Sie nur ein TLS/SSL-Zertifikat auf dem Anwendungsgateway verwenden. Dies bedeutet für Sie eine Vereinfachung des Betriebs.

    Screenshot, das ein Application Gateway zeigt, das den Datenverkehr gleichmäßig auf Webserver verteilt

    Informationen zum Konfigurieren von Application Gateway für einen SAP BOBI-Webserver finden Sie unter Lastenausgleich für SAP BOBI-Webserver mit Application Gateway im SAP-Blog.

    Hinweis

    Verwenden Sie das Application Gateway für die Lastverteilung des Datenverkehrs zum Webserver, da es Funktionen wie SSL-Auslagerung, gebündeltes SSL-Management zur Reduzierung des Ver- und Entschlüsselungsaufwands auf dem Server, Round-Robin-Algorithmen zur Verteilung des Datenverkehrs, Web Application Firewall-Funktionen und hohe Verfügbarkeit bietet.

Zuverlässigkeit der SAP BusinessObjects BI-Plattform in Azure

Die SAP BusinessObjects BI-Plattform umfasst unterschiedliche Ebenen, die für bestimmte Aufgaben und Vorgänge optimiert sind. Wenn eine Komponente aus einer ebene nicht verfügbar ist, funktioniert die SAP BOBI-Anwendung entweder nicht mehr oder bestimmte Funktionen der Anwendung nicht mehr. Daher müssen Sie sicherstellen, dass jede Ebene auf Zuverlässigkeit ausgelegt ist, um die Anwendung betriebsbereit zu halten und eine Unterbrechung des Geschäftsbetriebs zu vermeiden.

In diesem Abschnitt wird erläutert, wie features, die für Azure nativ sind, mit einer SAP BOBI-Plattformkonfiguration kombiniert werden, um die Verfügbarkeit einer SAP-Bereitstellung zu verbessern. In diesem Abschnitt werden die folgenden Optionen für die Zuverlässigkeit der SAP BOBI-Plattform in Azure behandelt:

  • Sicherung und Wiederherstellung: Bei diesem Prozess werden regelmäßig Kopien von Daten und Anwendungen an separaten Standorten erstellt. Wenn die ursprünglichen Daten oder Anwendungen verloren gehen oder beschädigt sind, können die Kopien verwendet werden, um den vorherigen Zustand wiederherzustellen.
  • Hochverfügbarkeit: Eine Plattform mit Hochverfügbarkeit verfügt innerhalb einer Azure-Region von jeder Komponente über mindestens zwei Kopien, damit die Anwendung betriebsbereit bleibt, wenn einer der Server nicht mehr verfügbar ist.
  • Notfallwiederherstellung (Disaster Recovery, DR) : Bei diesem Prozess wird Ihre Anwendungsfunktionalität wiederhergestellt, wenn es zu schwerwiegenden Verlusten kommt. Beispielsweise kann aufgrund einer Naturkatastrophe eine gesamte Azure-Region nicht mehr verfügbar sein.

Die Implementierung dieser Lösung variiert je nach Art des Systems, das in Azure eingerichtet wurde. Sie müssen Ihre Lösungen für die Bereiche Sicherung und Wiederherstellung, Hochverfügbarkeit und Notfallwiederherstellung basierend auf Ihren Geschäftsanforderungen entsprechend anpassen.

Sichern und Wiederherstellen

Der Sicherungs- und Wiederherstellungsvorgang erstellt regelmäßige Kopien von Daten und Anwendungen an einen separaten Speicherort. Sie können wiederhergestellt oder in einem vorherigen Zustand wiederhergestellt werden, wenn die ursprünglichen Daten oder Anwendungen verloren gehen oder beschädigt sind. Dies ist auch ein wesentlicher Bestandteil jeder Notfallwiederherstellungsstrategie jedes Unternehmens. Diese Sicherungen ermöglichen die Wiederherstellung von Anwendungen und Datenbanken bis zu einem bestimmten Zeitpunkt innerhalb des konfigurierten Aufbewahrungszeitraums.

Identifizieren Sie zur Entwicklung einer umfassenden Sicherungs- und Wiederherstellungsstrategie für eine SAP BOBI-Plattform die Komponenten, die zu Systemausfällen oder Störungen der Anwendung führen. Auf einer SAP BOBI-Plattform ist die Sicherung der folgenden Komponenten für den Schutz der Anwendung unerlässlich:

  • SAP BOBI-Installationsverzeichnis (verwaltete Premium-Datenträger)
  • Filestore (Azure Files Premium oder Azure NetApp Files für verteilte Installation)
  • CMS- und Überwachungsdatenbank (SQL-Datenbank, Azure-Datenbank für MySQL oder eine Datenbank auf Azure-VMs)

Im folgenden Abschnitt wird beschrieben, wie die Sicherungs- und Wiederherstellungsstrategie für die einzelnen Komponenten auf einer SAP BOBI-Plattform implementiert wird.

Sicherung und Wiederherstellung für ein SAP BOBI-Installationsverzeichnis

In Azure ist die einfachste Möglichkeit zur Sicherung von VMs und allen angefügten Datenträgern die Verwendung von Azure Backup. Hiermit können unabhängige und isolierte Sicherungen erstellt werden, damit ein Schutz vor dem versehentlichen Löschen der Daten auf Ihren VMs besteht. Sicherungen werden in einem Recovery Services-Tresor mit integrierter Verwaltung von Wiederherstellungspunkten gespeichert. Die Konfiguration und die Skalierung können leicht durchgeführt werden. Die Sicherungen werden optimiert und können bei Bedarf leicht wiederhergestellt werden.

Im Rahmen des Sicherungsprozesses wird eine Momentaufnahme erstellt. Die Daten werden in den Recovery Services-Tresor übertragen, ohne dass es Auswirkungen auf die Produktionsworkloads hat. Die Erstellung der Momentaufnahme ermöglicht einen anderen Konsistenzgrad. Dies ist unter Konsistenz von Momentaufnahmen beschrieben. Darüber hinaus verfügt Backup auch über eine parallele Unterstützung für die Sicherung verwalteter Datenträger per Azure Disk Backup und einer Lösung für die Sicherung von Azure-VMs. Es ist nützlich, wenn Sie täglich konsistente Sicherungen von VMs benötigen und häufigere Sicherungen von Betriebssystemdatenträgern oder eines speziellen Datenträgers, die absturzsicher sind. Weitere Informationen finden Sie unter Ein Überblick über die Sicherung von Azure-VMs, Übersicht über Azure Disk Backup und Häufig gestellte Fragen: Sichern von Azure-VMs.

Sichern und Wiederherstellen für Filestore

Abhängig von Ihrer Bereitstellung kann sich der Filestore einer SAP BOBI-Plattform in Azure NetApp Files oder Azure Files befinden. Wählen Sie basierend auf dem Speicher, den Sie für den Filestore verwenden, eine der folgenden Optionen für die Sicherung und Wiederherstellung aus:

  • Azure NetApp Files: Für Azure NetApp Files können Sie bedarfsabhängige Momentaufnahmen erstellen und mithilfe von Momentaufnahmerichtlinien eine automatische Momentaufnahme planen. Momentaufnahmekopien sind zu einem bestimmten Zeitpunkt erstellte Kopien Ihres Azure NetApp Files-Volumes. Weitere Informationen finden Sie unter Verwalten von Momentaufnahmen mithilfe von Azure NetApp Files.

  • Azure Files: Die Azure Files-Sicherung ist in eine native Instanz von Backup integriert. Auf diese Weise wird die Sicherungs- und Wiederherstellungsfunktion mit der VM-Sicherung zusammengefasst und der Betrieb vereinfacht. Weitere Informationen finden Sie unter Azure-Dateifreigaben sichern und Häufig gestellte Fragen: Azure-Dateien sichern.

Wenn Sie einen separaten NFS-Server erstellen, stellen Sie sicher, dass Sie die Sicherungs- und Wiederherstellungsstrategie dafür implementieren.

Sicherung und Wiederherstellung für die CMS- und die Überwachungsdatenbank

Für eine AUF Windows-VMs ausgeführte SAP BOBI-Plattform kann der CMS und die Überwachungsdatenbank auf einer der unterstützten Datenbanken ausgeführt werden. Weitere Informationen finden Sie in der Supportmatrix im Leitfaden zur Planung und Implementierung der SAP-BOBI-Plattform in Azure. Daher ist es wichtig, dass Sie die Sicherungs- und Wiederherstellungsstrategie basierend auf der Datenbank nutzen, die für die Speicherung der CMS- und Überwachungsdaten verwendet wird.

  • Für SQL-Datenbank wird SQL Server-Technologie genutzt, um wöchentlich vollständige Sicherungen, alle 12 bis 24 Stunden differenzielle Sicherungen und alle 5 bis 10 Minuten Transaktionsprotokollsicherungen zu erstellen. Die Häufigkeit von Transaktionsprotokollsicherungen basiert auf der Computegröße und dem Umfang der Datenbankaktivität.

    Benutzer können eine Option zum Konfigurieren der Sicherungsspeicherredundanz zwischen LRS-, ZRS- und GRS-Blobs auswählen. Bei den Mechanismen der Speicherredundanz werden mehrere Kopien Ihrer Daten gespeichert, damit diese vor geplanten und ungeplanten Ereignissen geschützt sind. Dies können vorübergehend auftretende Hardwarefehler, Netzwerk- oder Stromausfälle oder schwere Naturkatastrophen sein. Standardmäßig werden Sicherungsdaten von SQL-Datenbank in GRS-Blobs gespeichert, die in einer gekoppelten Region repliziert werden. Je nach den geschäftlichen Anforderungen kann dies auf LRS- oder ZRS-Blobs umgestellt werden. Weitere aktuelle Informationen zur Planung, Aufbewahrung und Speichernutzung bei SQL-Datenbank-Sicherungen finden Sie unter Automatisierte Sicherungen – Azure SQL-Datenbank und SQL Managed Instance.

  • Azure Database for MySQL erstellt automatisch Serversicherungen und speichert sie in benutzerkonfiguriertem LRS oder GRS. Von Azure Database for MySQL werden die Datendateien und das Transaktionsprotokoll gesichert. Abhängig von der unterstützten maximalen Speichergröße werden entweder vollständige oder differenzielle Sicherungen (Server mit maximal 4 TB Speicher) oder Momentaufnahmesicherungen (Server mit bis zu 16 TB Speicher) erstellt. Diese Sicherungen ermöglichen es Ihnen, einen Server zu jedem beliebigen Zeitpunkt innerhalb des von Ihnen konfigurierten Aufbewahrungszeitraums wiederherzustellen. Der standardmäßige Aufbewahrungszeitraum für die Sicherung beträgt sieben Tage, die Sie optional bis zu 35 Tage konfigurieren können. Für die Verschlüsselung aller Sicherungen wird die AES-256-Bit-Verschlüsselung verwendet. Diese Sicherungsdateien sind nicht für Benutzer verfügbar und können nicht exportiert werden. Sie können nur für Wiederherstellungsvorgänge in Azure Database for MySQL verwendet werden. Zum Kopieren einer Datenbank können Sie mysqldump verwenden. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung in Azure Database for MySQL.

  • Für eine auf einer Azure-VM installierte Datenbank können Sie Standardtools für die Sicherung nutzen. Verwenden Sie Backup für unterstützte Datenbanken. Falls die Azure-Dienste und -Tools Ihre Anforderungen nicht erfüllen, können Sie auch unterstützte Sicherungstools von Drittanbietern verwenden, die über einen Agent für die Sicherung und Wiederherstellung aller Komponenten der SAP BOBI-Plattform verfügen.

Hochverfügbarkeit

Zur Erzielung von Hochverfügbarkeit wird eine Reihe von Technologien genutzt, mit denen Störungen im IT-Bereich minimiert werden können. Hierbei wird die Geschäftskontinuität für Anwendungen oder Dienste sichergestellt, indem redundante, fehlertolerante oder durch Failover geschützte Komponenten innerhalb desselben Rechenzentrums bereitgestellt werden. In diesem Fall befinden sich die Rechenzentren in einer Azure-Region. Der Artikel Hochverfügbarkeitsarchitektur und -szenarien für SAP bietet Einblicke in verschiedene Hochverfügbarkeitstechniken und Empfehlungen für Azure für SAP-Anwendungen, die die Anweisungen in diesem Abschnitt ergänzen.

Basierend auf dem Dimensionierungsergebnis der SAP BOBI-Plattform müssen Sie die Umgebung entwerfen und die Verteilung der BI-Komponenten auf die Azure-VMs und Subnetze festlegen. Der Redundanzgrad der verteilten Architektur richtet sich nach den geschäftlichen Anforderungen in Bezug auf den RTO- (Recovery Time Objective) und RPO-Wert (Recovery Point Objective). Die SAP BOBI-Plattform verfügt über unterschiedliche Ebenen, und die Komponenten auf den einzelnen Ebenen sollten so konzipiert sein, dass Redundanz erzielt wird. Wenn dann eine Komponente ausfällt, kommt es für Ihre SAP BOBI-Anwendung nur zu einer kurzen oder zu gar keiner Unterbrechung. Beispiel:

  • Redundante Anwendungsserver, z. B. BI-Anwendungsserver und -Webserver
  • Eindeutige Komponenten, z. B. CMS-Datenbank, Filestore und Lastenausgleich

Im folgenden Abschnitt wird beschrieben, wie Sie für jede Komponente einer SAP BOBI-Plattform Hochverfügbarkeit erzielen können.

Hochverfügbarkeit für Anwendungsserver

Für BI- und Webanwendungsserver wird keine spezifische Hochverfügbarkeitslösung benötigt. Dies gilt unabhängig davon, ob sie zusammen oder getrennt installiert werden. Sie können Hochverfügbarkeit durch Redundanz erzielen, indem Sie mehrere Instanzen von BI- und Webservern auf verschiedenen Azure-VMs konfigurieren. Sie können die virtuellen Computer entweder in flexiblen Skalierungssätzen, Verfügbarkeitssätzen oder Verfügbarkeitszonen basierend auf business-required RTO bereitstellen. Stellen Sie für die übergreifende Bereitstellung in mehreren Verfügbarkeitszonen sicher, dass auch alle anderen Komponenten der SAP BOBI-Plattform zonenredundant sind.

Da derzeit nicht alle Azure-Regionen über Verfügbarkeitszonen verfügen, müssen Sie die Bereitstellungsstrategie nach Ihrer Region ausrichten. Die Azure-Regionen, in denen Zonen verfügbar sind, sind unter Regionen und Verfügbarkeitszonen in Azure aufgelistet.

Wichtig

  • Die Konzepte von Azure-Verfügbarkeitszonen und Azure-Verfügbarkeitsgruppen schließen sich gegenseitig aus. Sie können zwei oder mehr VMs entweder in einer bestimmten Verfügbarkeitszone oder in einer Verfügbarkeitsgruppe bereitstellen, aber nicht in beiden.
  • Wenn Sie planen, über Verfügbarkeitszonen hinweg bereitzustellen, empfehlen wir, einen flexiblen Skalierungssatz mit FD=1 anstatt der Bereitstellung in Standardverfügbarkeitszonen zu verwenden.

Hochverfügbarkeit für die CMS-Datenbank

Wenn Sie eine Azure-Datenbank als Lösung für Ihre CMS- und Überwachungsdatenbank verwenden, wird standardmäßig ein lokal redundantes Framework für Hochverfügbarkeit bereitgestellt. Sie können die Funktionen für Hochverfügbarkeit, Redundanz und Resilienz auswählen, die in der Region bzw. für den Dienst verfügbar sind, ohne dass Sie zusätzliche Komponenten konfigurieren müssen. Wenn die Bereitstellungsstrategie für eine SAP BOBI-Plattform per Verfügbarkeitszone erfolgt, sollten Sie sicherstellen, dass Sie Zonenredundanz für Ihre CMS- und Überwachungsdatenbank erzielen. Weitere Informationen zur hohen Verfügbarkeit für unterstützte Datenbankangebote in Azure finden Sie unter Hohe Verfügbarkeit für Azure SQL-Datenbank. Siehe auch hohe Verfügbarkeit in der Azure-Datenbank für MySQL.

Informationen zu einer anderen DBMS-Bereitstellung und zum Erreichen einer hohen Verfügbarkeit für eine CMS-Datenbank finden Sie in den DBMS-Bereitstellungshandbüchern für SAP-Workload .

Hochverfügbarkeit für Filestore

Filestore bezieht sich auf die Datenträgerverzeichnisse, in denen Inhalte wie Berichte, Universen und Verbindungen gespeichert werden. Es wird von allen Anwendungsservern dieses Systems gemeinsam genutzt. Daher müssen Sie sicherstellen, dass für Hochverfügbarkeit gesorgt ist (wie auch für die anderen Komponenten der SAP BOBI-Plattform).

Für eine AUF Windows ausgeführte SAP BOBI-Plattform können Sie entweder Azure Premium-Dateien oder Azure NetApp-Dateien für den Dateispeicher auswählen. Beide Optionen sind so konzipiert, dass sie hochverfügebar und sehr langlebig sind. Für Azure Files Premium wird ZRS unterstützt. Dies kann für die zonenübergreifende Bereitstellung einer SAP BOBI-Plattform nützlich sein. Weitere Informationen finden Sie im Abschnitt Redundanz für Azure Files.

Da der Dateifreigabedienst nicht in allen Regionen verfügbar ist, sollten Sie in der Liste mit den verfügbaren Produkten nach Region nach aktuellen Informationen suchen. Wenn der Dienst in Ihrer Region nicht verfügbar ist, können Sie einen NFS-Server erstellen, über den Sie das Dateisystem für eine SAP BOBI-Anwendung freigeben. Sie müssen aber auch die hohe Verfügbarkeit berücksichtigen.

Hochverfügbarkeit für den Load Balancer

Für die Verteilung von Datenverkehr für einen Webserver können Sie Load Balancer oder Application Gateway verwenden. Bei beiden Lastenausgleichsmodulen kann Redundanz basierend auf der SKU erzielt werden, die Sie für die Bereitstellung auswählen:

  • Load Balancer: Hierbei kann Redundanz erzielt werden, indem das Front-End von Load Balancer Standard als zonenredundant konfiguriert wird. Weitere Informationen finden Sie unter Standard Load Balancer und Verfügbarkeitszonen.

  • Anwendungsgateway: Hohe Verfügbarkeit kann basierend auf dem Typ der während der Bereitstellung ausgewählten Ebene erreicht werden:

    • Die v1-SKU unterstützt Szenarien mit hoher Verfügbarkeit, wenn Sie zwei oder mehr Instanzen bereitstellen. Azure verteilt diese Instanzen auf Update- und Fehlerdomänen, um sicherzustellen, dass nicht alle Instanzen gleichzeitig ausfallen. Mit dieser SKU kann die Redundanz in der Zone erzielt werden.

    • Die v2-SKU stellt automatisch sicher, dass neue Instanzen über Fehlerdomänen und Aktualisierungsdomänen verteilt werden. Haben Sie Zonenredundanz gewählt, werden die neuesten Instanzen darüber hinaus über Verfügbarkeitszonen hinweg verteilt, um Resilienz gegen Zonenausfälle zu erreichen. Weitere Informationen finden Sie unter Automatische Skalierung und zonenredundantes Application Gateway v2.

Referenzarchitektur für Hochverfügbarkeit für die SAP BusinessObjects BI-Plattform

In der folgenden Referenzarchitektur wird die übergreifende Einrichtung einer SAP BOBI-Plattform für mehrere Verfügbarkeitszonen auf einem Windows-Server beschrieben. Die Architektur veranschaulicht die Verwendung unterschiedlicher Azure-Dienste, z. B. Application Gateway, Azure Files Premium (Filestore) und SQL-Datenbank (CMS- und Überwachungsdatenbank). Die SAP BOBI-Plattform verfügt über eine integrierte Zonenredundanz. Hierdurch kann die Komplexität der Verwaltung verschiedener Hochverfügbarkeitslösungen reduziert werden.

In der folgenden Abbildung wird für den eingehenden Datenverkehr (HTTPS – TCP/443) ein Lastenausgleich mithilfe der Application Gateway v2-SKU über mehrere Verfügbarkeitszonen hinweg durchgeführt. Das Anwendungsgateway verteilt die Benutzeranforderung auf Webserver, die über Verfügbarkeitszonen verteilt sind. Der Webserver gibt die Anforderung an Verwaltungs- und Verarbeitungsserverinstanzen weiter, die in den Verfügbarkeitszonen auf separaten VMs bereitgestellt werden. Azure Premium-Dateien mit ZRS sind über eine private Verbindung an VMs in der Verwaltungs- und Speicherebene angefügt, um auf Inhalte wie Berichte, Universen und Verbindungen zuzugreifen. Die Anwendung greift auf die CMS- und die Überwachungsdatenbank zu, die auf einer zonenredundanten Instanz von SQL-Datenbank ausgeführt werden. Hierbei werden die Datenbanken an mehreren physischen Standorten innerhalb einer Azure-Region repliziert.

Diagramm: Hochverfügbarkeitsarchitektur für eine SAP BOBI-Plattform unter Windows

Die obige Architektur gewährt Ihnen einen Einblick, wie eine SAP BOBI-Bereitstellung in Azure erfolgen kann. Sie deckt aber nicht alle möglichen Konfigurationsoptionen für eine SAP BOBI-Plattform in Azure ab. Sie können die Bereitstellung basierend auf Ihren Geschäftsanforderungen anpassen, indem Sie für Komponenten wie Load Balancer, File Repository Server und DBMS andere Produkte oder Dienste auswählen.

Falls Verfügbarkeitszonen in Ihrer ausgewählten Region nicht verfügbar sind, können Sie Azure-VMs in Verfügbarkeitsgruppen bereitstellen. In Azure wird gewährleistet, dass die VMs, die Sie innerhalb einer Verfügbarkeitsgruppe platzieren, auf mehrere physische Server, Compute-Racks, Speichereinheiten und Netzwerkswitches verteilt werden. Falls es dann zu einem Hardware- oder Softwareausfall kommt, ist nur ein Teil Ihrer VMs betroffen, während die Gesamtlösung weiter betriebsbereit ist.

Notfallwiederherstellung

In diesem Abschnitt wird die Strategie beschrieben, mit der für eine SAP BOBI-Plattform der Schutz per Notfallwiederherstellung erzielt werden kann. Es ergänzt den Artikel "Notfallwiederherstellung für SAP ", der die primäre Ressource für einen gesamten SAP DR-Ansatz ist. Sehen Sie sich für die SAP BOBI-Plattform den SAP-Hinweis 2056228 an. Darin werden die folgenden Methoden für die sichere Implementierung einer Umgebung für die Notfallwiederherstellung beschrieben:

  • Verwenden Sie vollständig oder selektiv Lifecycle-Management oder einen Verbund, um den Inhalt aus dem primären System zu fördern oder zu verteilen.
  • Regelmäßiges Kopieren der CMS- und FRS-Inhalte

In diesem Abschnitt wird die zweite Option zum Implementieren einer DR-Umgebung behandelt. In diesem Artikel wird keine vollständige Liste aller möglichen Konfigurationsoptionen für DR behandelt, sondern eine Lösung behandelt, die systemeigene Azure-Dienste in Kombination mit der SAP BOBI-Plattformkonfiguration bietet.

Wichtig

  • Die Verfügbarkeit der einzelnen Komponenten auf der SAP BOBI-Plattform sollte in die sekundäre Region integriert werden. Die gesamte Disaster Recovery Strategie muss gründlich getestet werden.
  • Wenn Ihre SAP BI-Plattform mit einem flexiblen Skalierungssatz mit FD=1 konfiguriert ist, müssen Sie PowerShell verwenden, um Azure Site Recovery für die Notfallwiederherstellung einzurichten.

Referenzarchitektur für das Desaster Recovery einer SAP BusinessObjects BI-Plattform

Bei dieser Referenzarchitektur wird eine Multi-Instanz-Bereitstellung der SAP BOBI-Plattform mit redundanten Anwendungsservern ausgeführt. Für die Notfallwiederherstellung sollten Sie für alle Komponenten der SAP BOBI-Plattform ein Failover in eine sekundäre Region ausführen. In der folgenden Abbildung werden Azure Files Premium als Filestore, SQL-Datenbank als CMS- und Überwachungsrepository und Application Gateway zum Vornehmen eines Lastenausgleichs für den Datenverkehr genutzt. Die Strategie zur Erzielung des Notfallwiederherstellungsschutzes ist für jede Komponente anders. Dies ist im folgenden Abschnitt beschrieben.

Diagramm, das DR (Notfallwiederherstellung) für die SAP BusinessObjects BI-Plattform unter Windows zeigt.

Lastverteiler

Load Balancer wird verwendet, um Datenverkehr auf die Webanwendungsserver einer SAP BOBI-Plattform zu verteilen. In Azure können Sie Load Balancer oder Application Gateway verwenden, um den Datenverkehr über Ihre Webserver auszugleichen. Um eine Notfallwiederherstellung für die Lastenausgleichsdienste zu erzielen, müssen Sie ein weiteres Lastenausgleichsmodul oder Anwendungsgateway in einer sekundären Region implementieren. Ändern Sie den Eintrag im DNS, und richten Sie einen Verweis auf den Lastenausgleichsdienst ein, der in der sekundären Region ausgeführt wird, damit die URL nach dem DR-Failover unverändert bleibt.

VMs, die Web- und BI-Anwendungsserver ausführen

Azure Site Recovery kann verwendet werden, um VMs, auf denen Web- und BI-Anwendungsserver ausgeführt werden, in der sekundären Region zu replizieren. Die Site Recovery repliziert die Server und alle angefügten verwalteten Datenträger in die sekundäre Region. Wenn Katastrophen oder Ausfälle auftreten, können Sie problemlos zu Ihrer replizierten Umgebung übergehen und weiterarbeiten. Um mit dem Replizieren aller SAP-Anwendungs-VMs im Azure DR-Rechenzentrum zu beginnen, befolgen Sie die Anleitungen unter "Replizieren eines virtuellen Computers in Azure".

Dateispeicher-Datenträgerverzeichnis

Der Dateispeicher ist ein Datenträgerverzeichnis, in dem tatsächliche Dateien wie Berichte und BI-Dokumente gespeichert werden. Stellen Sie sicher, dass alle Dateien im Dateispeicher mit der DR-Region synchronisiert werden. Die DR-Strategie, die Sie zum Synchronisieren von Inhalten verwenden, hängt vom Typ des Dateifreigabediensts für Ihre SAP BOBI-Plattform unter Windows ab. Beispiel:

  • Azure Files Premium unterstützt nur LRS und ZRS. Für die Azure Files Premium-Strategie zur Notfallwiederherstellung können Sie AzCopy oder Azure PowerShell verwenden, um die Dateien in ein anderes Speicherkonto in einer anderen Region zu kopieren. Weitere Informationen finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

  • Azure NetApp Files stellt NFS- und SMB-Volumes bereit, sodass jedes dateibasierte Kopiertool zur Replikation von Daten zwischen Azure-Regionen verwendet werden kann. Weitere Informationen zum Kopieren eines Azure NetApp Files-Volumes in eine andere Region finden Sie unter Häufig gestellte Fragen zu Azure NetApp Files.

    Sie können die regionsübergreifende Azure NetApp Files-Replikation verwenden, die netApp SnapMirror-Technologie verwendet. Bei dieser Technologie werden nur geänderte Blöcke in einem komprimierten, effizienten Format über das Netzwerk gesendet. Diese proprietäre Technologie minimiert die Menge an Daten, die regionsübergreifend repliziert werden muss, wodurch Datenübertragungskosten eingespart werden. Darüber hinaus wird auch die Replikationsdauer reduziert, damit Sie einen niedrigeren RPO-Wert erzielen können. Weitere Informationen finden Sie unter Regionsübergreifende Replikation: Anforderungen und Überlegungen.

CMS-Datenbank

Bei der CMS- und der Überwachungsdatenbank in der DR-Region muss es sich um eine Kopie der Datenbanken handeln, die in der primären Region ausgeführt werden. Es ist wichtig, die Datenbank je nach Datenbanktyp und den geschäftlichen Anforderungen an RTO und RPO in eine DR-Region zu kopieren. In diesem Abschnitt werden verschiedene Optionen beschrieben, die für jede Datenbanklösung in Azure verfügbar sind, die für eine AUF Windows ausgeführte SAP BOBI-Anwendung unterstützt wird.

Azure SQL-Datenbank

Für eine DR-Strategie für SQL-Datenbank sind zwei Optionen zum Kopieren der Datenbank in die sekundäre Region verfügbar. Die beiden Wiederherstellungsoptionen weisen unterschiedliche RTO- und RPO-Ebenen auf. Weitere Informationen zum RTO- und RPO-Wert für die Wiederherstellungsoptionen finden Sie unter Wiederherstellen einer Datenbank auf dem vorhandenen Server.

Option 1: Georedundante Datenbankwiederherstellung

  • Standardmäßig werden Daten von SQL-Datenbank in GRS-Blobs gespeichert, die in einer gekoppelten Region repliziert werden. Bei einer SQL-Datenbank kann die Sicherungsspeicherredundanz zum Zeitpunkt der CMS- und Überwachungsdatenbankerstellung konfiguriert werden. Sie kann auch für eine vorhandene Datenbank aktualisiert werden. Änderungen, die an einer vorhandenen Datenbank vorgenommen werden, gelten nur für zukünftige Sicherungen. Sie können eine Datenbank in einer beliebigen SQL-Datenbank-Instanz in einer beliebigen Azure-Region aus den letzten georeplizierten Sicherungen wiederherstellen. Die Geowiederherstellung nutzt ein georepliziertes Backup als Quelle. Eine Verzögerung tritt zwischen dem Zeitpunkt auf, zu dem das System eine Sicherung erstellt, und dem Zeitpunkt, zu dem die Sicherung in einem Azure-Blob in einer anderen Region geo-repliziert wird. Daher kann die wiederhergestellte Datenbank bis zu einer Stunde hinter der ursprünglichen Datenbank zurückliegen.

    Wichtig

    Die Geowiederherstellung ist für SQL-Datenbanken verfügbar, für die georedundanter Sicherungsspeicher konfiguriert wurde.

Option 2: Georeplikation oder Autofailover-Gruppe

  • Die aktive Georeplikation ist ein Feature von SQL-Datenbank, mit dem Sie lesbare sekundäre Datenbanken für einzelne Datenbanken auf einem Server in derselben oder einer anderen Region erstellen können. Wenn die Georeplikation für CMS- und die Überwachungsdatenbank aktiviert ist, kann die Anwendung ein Failover in eine sekundäre Datenbank in einer anderen Azure-Region initiieren. Die Georeplikation ist für einzelne Datenbanken aktiviert. Um ein transparentes und koordiniertes Failover mehrerer Datenbanken (CMS und Audit) für eine SAP BOBI-Anwendung zu ermöglichen, empfiehlt es sich, eine Automatische Failovergruppe zu verwenden. Hierüber wird die Gruppensemantik auf Grundlage der aktiven Georeplikation zur Verfügung gestellt. Dies bedeutet, dass der gesamte SQL-Server (alle Datenbanken) in einer anderen Region repliziert wird, und nicht in einzelnen Datenbanken. Sehen Sie sich die Tabelle mit den Funktionen an, in der die Georeplikation mit Failovergruppen verglichen wird.

  • Autofailover-Gruppen verfügen über Listenerendpunkte mit Lese-/Schreibzugriff bzw. Schreibschutz, die während eines Failovers unverändert bleiben. Der Endpunkt mit Lese-/Schreibzugriff kann als Listener im ODBC-Verbindungseintrag für die CMS- und die Überwachungsdatenbank genutzt werden. Sowohl bei manueller als auch automatischer Failover-Aktivierung schaltet das Failover alle sekundären Datenbanken in der Gruppe zur primären um. Nach Abschluss des Datenbankfailovers wird der DNS-Eintrag automatisch aktualisiert, um die Endpunkte in die neue Region umzuleiten. Die Anwendung wird automatisch mit der CMS-Datenbank verbunden, da der Endpunkt mit Lese-/Schreibzugriff als Listener für die ODBC-Verbindung genutzt wird.

    In der folgenden Abbildung wird eine Autofailover-Gruppe für den SQL-Server (azussqlbodb), der in der Region „USA, Osten 2“ ausgeführt wird, in der sekundären Region „USA, Osten“ (Standort für die Notfallwiederherstellung) repliziert. Der Listenerendpunkt mit Lese-/Schreibzugriff wird als Listener in einer ODBC-Verbindung für den BI-Anwendungsserver unter Windows genutzt. Nach dem Failover bleibt der Endpunkt gleich. Es ist kein manueller Eingriff erforderlich, um die BI-Anwendung mit der SQL-Datenbank in der sekundären Region zu verbinden.

    Ein Screenshot, der die Autofailover-Gruppen der SQL-Datenbank zeigt.

    Diese Option bietet eine niedrigere RTO und RPO als Option 1. Weitere Informationen zu dieser Option finden Sie unter Verwenden von Autofailover-Gruppen für transparentes und koordiniertes Failover mehrerer Datenbanken

Azure Database for MySQL

Azure Database for MySQL verfügt über Optionen für die Wiederherstellung einer Datenbank, wenn es zu einem Katastrophenfall kommt. Wählen Sie die passende Option für Ihr Unternehmen aus:

  • Aktivieren Sie die Nutzung regionsübergreifender Lesereplikate, um Ihre Planung für die Geschäftskontinuität und Notfallwiederherstellung zu verbessern. Sie können über einen Quellserver die Replikation für bis zu fünf Replikate durchführen. Lesereplikate werden asynchron aktualisiert, indem die Azure Database for MySQL-Replikationstechnologie für binäre Protokolle verwendet wird. Replikate sind neue Server, die Sie ähnlich wie normale Azure Database for MySQL-Server verwalten. Weitere Informationen zu Lesereplikaten, verfügbaren Regionen, Einschränkungen und zur Vorgehensweise beim Failover finden Sie unter Lesereplikate in Azure Database for MySQL.

  • Verwenden Sie das Geowiederherstellungsfeature von Azure Database for MySQL, bei dem der Server mithilfe von georedundanten Sicherungen wiederhergestellt wird. Auf diese Sicherungen kann selbst dann zugegriffen werden, wenn die Region, in der Ihr Server gehostet wird, offline ist. Sie können eine Wiederherstellung aus diesen Sicherungen in eine andere Region ausführen und den Server wieder online schalten.

    Wichtig

    Die Geowiederherstellung ist nur möglich, wenn Sie den Server mit einem georedundanten Sicherungsspeicher bereitgestellt haben. Das Ändern der Optionen für die Sicherungsredundanz nach der Erstellung des Servers wird nicht unterstützt. Weitere Informationen finden Sie unter Optionen für Sicherungsredundanz.

In der folgenden Tabelle sind die Empfehlungen für die Notfallwiederherstellung für alle Ebenen aufgeführt, die in diesem Beispiel verwendet werden.

Ebenen der SAP BOBI-Plattform Empfehlung
Azure Application Gateway oder Azure Load Balancer Parallele Einrichtung von Application Gateway in einer sekundären Region
Webanwendungsserver Replikation mit Azure Site Recovery
BI-Anwendungsserver Replizieren über Site Recovery
Azure Premium-Dateien AzCopy oder Azure PowerShell
Azure NetApp Files Dateibasiertes Kopiertool zum Replizieren von Daten in einer sekundären Region oder regionsübergreifende Replikation in Azure NetApp Files
Azure SQL-Datenbank Georeplikation bzw. Autofailover-Gruppen oder Geowiederherstellung
Azure Database for MySQL Regionsübergreifende Lesereplikate oder Wiederherstellung einer Sicherung aus georedundanten Sicherungen

Verwandte Inhalte

  • Last updated on