Udostępnij za pośrednictwem


Przewodnik wdrażania platformy SAP BusinessObjects BI dla systemu Linux na platformie Azure

W tym artykule opisano strategię wdrażania platformy SAP BusinessObjects BI (BOBI) na platformie Azure dla systemu Linux. W tym przykładzie skonfigurujesz dwie maszyny wirtualne z zarządzanymi dyskami SSD klasy Premium jako katalogiem instalacyjnym. Używasz usługi Azure Database for MySQL dla bazy danych CMS i udostępniasz usługę Azure NetApp Files dla serwera repozytorium plików na obu serwerach. Na obu maszynach wirtualnych zainstalujesz razem domyślną aplikację internetową Tomcat Java oraz aplikację platformy BI. Aby równoważyć obciążenie żądań użytkowników, należy użyć bramy aplikacyjnej Azure z natywnymi funkcjami odciążania protokołu TLS/SSL.

Ten typ architektury jest skuteczny w przypadku małych wdrożeń lub środowisk nieprodukcyjnych. W przypadku dużych wdrożeń lub środowisk produkcyjnych można mieć oddzielne hosty dla aplikacji internetowej. Można również mieć wiele hostów aplikacji BOBI, dzięki czemu serwer może przetworzyć więcej informacji.

Diagram przedstawiający wdrażanie rozwiązania SAP BOBI na platformie Azure dla systemu Linux

Oto wersja produktu i układ systemu plików dla tego przykładu:

  • PLATFORMA SAP BusinessObjects 4.3
  • SUSE Linux Enterprise Server 12 SP5
  • Azure Database for MySQL (wersja: 8.0.15)
  • Łącznik interfejsu API języka C mySQL — libmysqlclient (wersja: 6.1.11)
System plików opis Rozmiar (GB) Właściciel Grupa Przechowywanie
/usr/sap System plików do instalacji wystąpienia SAP BOBI, domyślnej webowej aplikacji Tomcat oraz sterowników bazy danych, jeśli to konieczne. Wskazówki dotyczące określania rozmiaru oprogramowania SAP bl1adm sapsys Zarządzany dysk Premium SSD
/usr/sap/frsinput Katalog instalacji jest przeznaczony dla plików udostępnionych na wszystkich hostach BOBI, które będą używane jako katalog repozytorium plików wejściowych. Potrzeba biznesowa bl1adm sapsys Azure NetApp Files
/usr/sap/frsoutput Katalog instalacji jest przeznaczony dla plików udostępnionych na wszystkich hostach BOBI, które będą używane jako katalog repozytorium plików wyjściowych Potrzeba biznesowa bl1adm sapsys Pliki Azure NetApp

Ważne

Podczas gdy konfiguracja platformy SAP BusinessObjects jest wyjaśniona przy użyciu usługi Azure NetApp Files, można użyć systemu plików NFS w usłudze Azure Files jako repozytorium plików wejściowych i wyjściowych.

Wdrażanie maszyny wirtualnej z systemem Linux za pośrednictwem witryny Azure Portal

W tej sekcji utworzysz dwie maszyny wirtualne z obrazem systemu operacyjnego Linux dla platformy SAP BOBI. Ogólne kroki tworzenia maszyn wirtualnych są następujące:

  1. Utwórz grupę zasobów.

  2. Utwórz sieć prywatną.

    • Nie używaj jednej podsieci dla wszystkich usług platformy Azure we wdrożeniu platformy SAP BI. W oparciu o architekturę platformy SAP BI należy utworzyć wiele podsieci. W tym wdrożeniu utworzysz trzy podsieci: jedną dla aplikacji, magazynu repozytorium plików i usługi Application Gateway.
    • Na platformie Azure usługa Application Gateway i usługa Azure NetApp Files muszą zawsze znajdować się w oddzielnej podsieci. Aby uzyskać więcej informacji, zobacz Azure Application Gateway i Wskazówki dotyczące planowania sieci Azure NetApp Files.
  3. Wybierz odpowiednie opcje dostępności w zależności od preferowanej konfiguracji systemu w regionie świadczenia usługi Azure, niezależnie od tego, czy obejmuje ona łączenie stref, znajduje się w jednej strefie, czy działa w regionie bez strefy.

  4. Utwórz maszynę wirtualną 1 o nazwie (azusbosl1).

  5. Utwórz maszynę wirtualną 2 o nazwie (azusbosl2).

  6. Dodaj jeden dysk SSD w warstwie Premium. Użyjesz go jako katalogu instalacyjnego SAP BOBI.

Skonfiguruj usługę Azure NetApp Files

Przed kontynuowaniem konfiguracji usługi Azure NetApp Files zapoznaj się z dokumentacją usługi Azure NetApp Files.

Usługa Azure NetApp Files jest dostępna w kilku regionach świadczenia usługi Azure. Sprawdź, czy wybrany region platformy Azure oferuje usługę Azure NetApp Files.

Użyj dostępności usługi Azure NetApp Files według regionu platformy Azure, aby sprawdzić dostępność usługi Azure NetApp Files według regionów.

Wdrażanie zasobów usługi Azure NetApp Files

W poniższych instrukcjach założono, że sieć wirtualna platformy Azure została już wdrożona. Zasoby usługi Azure NetApp Files oraz maszyny wirtualne, na których zostaną zainstalowane zasoby usługi Azure NetApp Files, muszą zostać wdrożone w tej samej sieci wirtualnej platformy Azure lub w równorzędnych sieciach wirtualnych platformy Azure.

  1. Utwórz konto usługi Azure NetApp Files w wybranym regionie świadczenia usługi Azure.

  2. Skonfiguruj pulę pojemności usługi Azure NetApp Files. Architektura platformy SAP BI przedstawiona w tym artykule używa pojedynczej puli pojemności usługi Azure NetApp Files na poziomie usługi Premium. W przypadku serwera repozytorium plików SAP BI na platformie Azure zalecamy użycie usługi Azure NetApp Files w warstwie Premium lub Ultra.

  3. Delegowanie podsieci do usługi Azure NetApp Files.

  4. Wdróż woluminy usługi Azure NetApp Files, postępując zgodnie z instrukcjami w temacie Tworzenie woluminu NFS dla usługi Azure NetApp Files.

    Woluminy można wdrożyć jako NFSv3 i NFSv4.1, ponieważ oba protokoły są obsługiwane dla platformy SAP BOBI. Wdróż woluminy w odpowiednich podsieciach usługi Azure NetApp Files. Adresy IP woluminów usługi Azure NetApp Files są przypisywane automatycznie.

Należy pamiętać, że zasoby usługi Azure NetApp Files i maszyny wirtualne platformy Azure muszą znajdować się w tej samej sieci wirtualnej platformy Azure lub w równorzędnych sieciach wirtualnych platformy Azure. Na przykład azusbobi-frsinput i azusbobi-frsoutput to nazwy woluminów, a nfs://10.31.2.4/azusbobi-frsinput i nfs://10.31.2.4/azusbobi-frsoutput to ścieżki plików dla woluminów usługi Azure NetApp Files.

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

Ważne uwagi

Podczas tworzenia serwera repozytorium plików platformy SAP BOBI dla usługi Azure NetApp Files należy pamiętać o następujących kwestiach:

  • Minimalna pojemność puli wynosi 4 tebibajty (TiB). Rozmiar puli pojemności można zwiększać o przyrosty po 1 TiB.
  • Minimalny rozmiar woluminu to 100 gibibajtów (GiB).
  • Usługa Azure NetApp Files i wszystkie maszyny wirtualne, na których będą zainstalowane woluminy usługi Azure NetApp Files, muszą znajdować się w tej samej sieci wirtualnej platformy Azure lub w równorzędnych sieciach wirtualnych w tym samym regionie. Obsługiwany jest dostęp do usługi Azure NetApp Files za pośrednictwem komunikacji równorzędnej sieci wirtualnych w tym samym regionie. Dostęp do usługi Azure NetApp Files za pośrednictwem peeringu globalnego nie jest obecnie obsługiwany.
  • Wybrana sieć wirtualna musi mieć podsieć delegowana do usługi Azure NetApp Files.
  • Charakterystyka przepływności i wydajności woluminu usługi Azure NetApp Files jest funkcją limitu przydziału woluminu i poziomu usługi, zgodnie z opisem w artykule Poziom usługi dla usługi Azure NetApp Files. Podczas określania rozmiaru woluminów SAP Azure NetApp upewnij się, że wynikowa przepływność spełnia wymagania aplikacji.
  • Za pomocą zasad eksportu Azure NetApp Files można kontrolować dozwolonych klientów oraz typ dostępu (na przykład odczyt i zapis lub tylko do odczytu).
  • Funkcja usługi Azure NetApp Files nie jest jeszcze świadoma strefy. Obecnie funkcja nie jest wdrażana we wszystkich strefach dostępności w regionie świadczenia usługi Azure. Należy pamiętać o potencjalnych konsekwencjach opóźnień w niektórych regionach świadczenia usługi Azure.
  • Woluminy usługi Azure NetApp Files można wdrożyć jako woluminy NFSv3 lub NFSv4.1. Oba protokoły są obsługiwane dla aplikacji platformy SAP BI.

Konfigurowanie systemów plików na serwerach z systemem Linux

Kroki opisane w tej sekcji używają następującego prefiksu:

[A]: Krok dotyczy wszystkich hostów.

Formatowanie i instalowanie systemu plików SAP

  1. [A] Wyświetl listę wszystkich dołączonych dysków.

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

    sudo mkfs.xfs /dev/sdc
    
  3. [A] Utwórz katalog instalacji.

    sudo mkdir -p /usr/sap
    
  4. [A] Pobierz identyfikator UUID urządzenia blokowego.

    sudo blkid
    
    # It will display information about block device. Copy UUID of the formatted block device
    
    /dev/sdc: UUID="0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b" TYPE="xfs"
    
  5. [A] Zachowaj wpis montowania systemu plików w /etc/fstab.

    sudo echo "UUID=0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b /usr/sap xfs defaults,nofail 0 2" >> /etc/fstab
    
  6. [A] Zainstaluj system plików.

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

Instalowanie woluminu usługi Azure NetApp Files

  1. [A] Tworzenie katalogów instalacji.

    sudo mkdir -p /usr/sap/frsinput
    sudo mkdir -p /usr/sap/frsoutput
    
  2. [A] Skonfiguruj system operacyjny klienta do obsługi podłączenia NFSv4.1 (dotyczy tylko NFSv4.1).

    Jeśli używasz woluminów usługi Azure NetApp Files z protokołem NFSv4.1, uruchom następującą konfigurację na wszystkich maszynach wirtualnych, na których woluminy usługi Azure NetApp Files NFSv4.1 muszą być zainstalowane.

    W tym kroku należy zweryfikować ustawienia domeny systemu plików NFS. Upewnij się, że domena jest skonfigurowana jako domyślna domena usługi Azure NetApp Files (defaultv4iddomain.com) i że mapowanie ma wartość nobody.

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

    Ważne

    Upewnij się, że na maszynie wirtualnej ustawiono domenę NFS w folderze /etc/idmapd.conf, aby dopasować domyślną konfigurację domeny w usłudze Azure NetApp Files (defaultv4iddomain.com). Jeśli wystąpi niezgodność, uprawnienia do plików na woluminach usługi Azure NetApp Files zainstalowanych na maszynach wirtualnych będą wyświetlane jako nobody.

    Zweryfikuj nfs4_disable_idmapping. Powinna być ustawiona wartość Y. Aby utworzyć strukturę katalogów, w której nfs4_disable_idmapping się znajduje, uruchom polecenie instalacji. Nie będzie można ręcznie utworzyć katalogu w katalogu /sys/modules, ponieważ dostęp jest zarezerwowany dla jądra /sterowników.

    # Check nfs4_disable_idmapping
    cat /sys/module/nfs/parameters/nfs4_disable_idmapping
    
    # If you need to set nfs4_disable_idmapping to Y
    mkdir /mnt/tmp
    mount -t nfs -o sec=sys,vers=4.1 10.31.2.4:/azusbobi-frsinput /mnt/tmp
    umount /mnt/tmp
    
    echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
    
    # Make the configuration permanent
    echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
    
  3. [A] Dodaj wpisy instalacji.

    Jeśli używasz systemu plików NFSv3:

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

    Jeśli używasz systemu plików NFSv4.1:

    sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab
    sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab
    
  4. [A] Instalowanie woluminów NFS.

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

Konfigurowanie usługi Azure Database for MySQL

Ta sekcja zawiera szczegółowe informacje na temat aprowizacji usługi Azure Database for MySQL przy użyciu witryny Azure Portal. Zawiera również instrukcje dotyczące tworzenia baz danych CMS i inspekcji dla platformy SAP BOBI oraz konta użytkownika w celu uzyskania dostępu do bazy danych.

Wytyczne mają zastosowanie tylko wtedy, gdy używasz usługi Azure Database for MySQL. W przypadku innych baz danych zapoznaj się z dokumentacją specyficzną dla oprogramowania SAP lub bazy danych, aby uzyskać instrukcje.

Utwórz bazę danych

Zaloguj się do witryny Azure Portal i wykonaj kroki opisane w przewodniku Szybki start: tworzenie serwera usługi Azure Database for MySQL przy użyciu witryny Azure Portal. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas aprowizowania usługi Azure Database for MySQL:

  • Wybierz ten sam region dla usługi Azure Database for MySQL, w którym działają serwery aplikacji platformy SAP BI.

  • Wybierz obsługiwaną wersję bazy danych na podstawie macierzy dostępności produktu (PAM) dla usługi SAP BI specyficznej dla wersji SAP BOBI.

  • W compute+storage wybierz Konfiguruj serwer i wybierz odpowiednią warstwę cenową na podstawie wyników rozmiaru.

  • Automatyczny przyrost miejsca do przechowywania jest domyślnie włączony. Należy pamiętać, że przechowywanie można skalować tylko w górę, a nie w dół.

  • Domyślnie okres przechowywania kopii zapasowej wynosi siedem dni. Można je skonfigurować opcjonalnie na okres do 35 dni.

  • Kopie zapasowe usługi Azure Database for MySQL są domyślnie nadmiarowe lokalnie. Jeśli chcesz tworzyć kopie zapasowe serwera w magazynie geograficznie nadmiarowym, wybierz pozycję Geograficznie nadmiarowe w obszarze Opcje nadmiarowości kopii zapasowych.

Ważne

Zmiana opcji nadmiarowości kopii zapasowej po utworzeniu serwera nie jest obsługiwana.

Uwaga

Funkcja łącza prywatnego jest dostępna tylko dla serwerów usługi Azure Database for MySQL w warstwach cenowych Ogólnego przeznaczenia lub Zoptymalizowane pod kątem pamięci. Upewnij się, że serwer bazy danych znajduje się w jednej z tych warstw cenowych.

W tej sekcji utworzysz link prywatny, który umożliwia maszynom wirtualnym SAP BOBI łączenie się z usługą Azure Database for MySQL za pośrednictwem prywatnego punktu końcowego. Usługa Azure Private Link udostępnia usługi platformy Azure wewnątrz prywatnej sieci wirtualnej.

  1. Wybierz bazę danych utworzoną w poprzedniej sekcji.
  2. Przejdź do Zabezpieczenia>Połączenia prywatnych punktów końcowych.
  3. W Połączeniach prywatnego punktu końcowego wybierz Prywatny punkt końcowy.
  4. Wybierz Subskrypcja>Grupa zasobów>Lokalizacja.
  5. Wprowadź nazwę prywatnego punktu końcowego.
  6. W sekcji Zasób określ następujące elementy:
    • Typ zasobu: Microsoft.DBforMySQL/servers
    • Zasób: baza danych MySQL utworzona w poprzedniej sekcji
    • Docelowy zasób podrzędny: mysqlServer
  7. W sekcji Sieć wybierz sieć wirtualną i podsieć, w której wdrożono aplikację SAP BOBI.

    Uwaga

    Jeśli masz włączoną sieciową grupę zabezpieczeń dla podsieci, będzie ona wyłączona tylko dla prywatnych punktów końcowych w tej podsieci. Inne zasoby w podsieci nadal będą podlegały wymuszaniu przez sieciową grupę zabezpieczeń.

  8. W obszarze Integracja z prywatną strefą DNS zaakceptuj wartość domyślną (tak)..
  9. Wybierz prywatną strefę DNS z listy rozwijanej.
  10. Wybierz pozycję Przegląd+Utwórz i utwórz prywatny punkt końcowy.

Aby uzyskać więcej informacji, zobacz Usługa Private Link dla usługi Azure Database for MySQL.

Utwórz bazy danych CMS i audytów

  1. Pobierz i zainstaluj aplikację MySQL Workbench z witryny internetowej MySQL. Upewnij się, że na serwerze zainstalowano aplikację MySQL Workbench, która może uzyskiwać dostęp do usługi Azure Database for MySQL.

  2. Nawiąż połączenie z serwerem przy użyciu programu MySQL Workbench. Postępuj zgodnie z instrukcjami w temacie Uzyskiwanie informacji o połączeniu. Jeśli test połączenia zakończy się pomyślnie, zostanie wyświetlony następujący komunikat:

    Zrzut ekranu przedstawiający komunikat w aplikacji MySQL Workbench.

  3. Na karcie Zapytanie SQL uruchom następujące zapytanie, aby utworzyć schemat dla baz danych CMS i inspekcji.

    # Here cmsbl1 is the database name of CMS database. You can provide the name you want for CMS database.
    CREATE SCHEMA `cmsbl1` DEFAULT CHARACTER SET utf8;
    
    # auditbl1 is the database name of Audit database. You can provide the name you want for CMS database.
    CREATE SCHEMA `auditbl1` DEFAULT CHARACTER SET utf8;
    
  4. Utwórz konto użytkownika, aby nawiązać połączenie ze schematem.

    # Create a user that can connect from any host, use the '%' wildcard as a host part
    CREATE USER 'cmsadmin'@'%' IDENTIFIED BY 'password';
    CREATE USER 'auditadmin'@'%' IDENTIFIED BY 'password';
    
    # Grant all privileges to a user account over a specific database:
    GRANT ALL PRIVILEGES ON cmsbl1.* TO 'cmsadmin'@'%' WITH GRANT OPTION;
    GRANT ALL PRIVILEGES ON auditbl1.* TO 'auditadmin'@'%' WITH GRANT OPTION;
    
    # Following any updates to the user privileges, be sure to save the changes by issuing the FLUSH PRIVILEGES
    FLUSH PRIVILEGES;
    
  5. Aby sprawdzić uprawnienia i role konta użytkownika MySQL:

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

Instalowanie łącznika interfejsu API języka C mySQL na serwerze z systemem Linux

Aby serwer aplikacji SAP BOBI uzyskiwał dostęp do bazy danych, wymaga sterowników klienta bazy danych. Aby uzyskać dostęp do baz danych CMS i audytu, należy użyć konektora MySQL C API dla systemu Linux. Połączenie ODBC z bazą danych CMS nie jest obsługiwane. Ta sekcja zawiera instrukcje dotyczące konfigurowania łącznika interfejsu API języka C mySQL w systemie Linux.

  1. Zapoznaj się ze sterownikami MySQL i narzędziami do zarządzania zgodnymi z usługą Azure Database for MySQL. Sprawdź sterownik MySQL Connector/C (libmysqlclient) w artykule.

  2. Aby pobrać sterowniki, zobacz MySQL Product Archives (Archiwa produktów MySQL).

  3. Wybierz system operacyjny i pobierz pakiet rpm współdzielonego komponentu MySQL Connector. W tym przykładzie jest używana wersja łącznika mysql-connector-c-shared-6.1.11.

  4. Zainstaluj konektor we wszystkich wystąpieniach aplikacji SAP BOBI.

    # Install rpm package
    SLES: sudo zypper install <package>.rpm
    RHEL: sudo yum install <package>.rpm
    
  5. Sprawdź ścieżkę libmysqlclient.so.

    # Find the location of libmysqlclient.so file
    whereis libmysqlclient
    
    # sample output
    libmysqlclient: /usr/lib64/libmysqlclient.so
    
  6. Ustaw LD_LIBRARY_PATH, aby wskazać /usr/lib64 jako katalog docelowy dla konta użytkownika, które będzie używane do instalacji.

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

Przygotowywanie serwera

Kroki opisane w tej sekcji używają następującego prefiksu:

[A]: Krok dotyczy wszystkich hostów.

  1. [A] Na podstawie odmiany systemu Linux (SLES lub RHEL) należy ustawić parametry jądra i zainstalować wymagane biblioteki. Zapoznaj się z sekcją "Wymagania systemowe" w przewodniku instalacji platformy analizy biznesowej dla systemu Unix.

  2. [A] Upewnij się, że strefa czasowa na maszynie jest ustawiona poprawnie. W przewodniku instalacji zobacz Dodatkowe wymagania dotyczące systemów Unix i Linux.

  3. [A] Utwórz konto użytkownika (bl1adm) i grupę (sapsys), w ramach której mogą być uruchamiane procesy w tle oprogramowania. Użyj tego konta, aby uruchomić instalację i oprogramowanie. Konto nie wymaga uprawnień głównych.

  4. [A] Ustaw środowisko konta użytkownika (bl1adm) do używania obsługiwanych ustawień regionalnych UTF-8 i upewnij się, że oprogramowanie konsolowe obsługuje zestawy znaków UTF-8. Aby upewnić się, że system operacyjny używa poprawnych ustawień regionalnych, ustaw LC_ALL zmienne środowiskowe i LANG na preferowane ustawienia regionalne w środowisku użytkownika (bl1adm).

    # This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly.
    vi /home/bl1adm/.bashrc
    
    export LANG=en_US.utf8
    export LC_ALL=en_US.utf8
    
  5. [A] Konfigurowanie konta użytkownika (bl1adm).

    # Set ulimit for bl1adm to unlimited
    root@azusbosl1:~> ulimit -f unlimited bl1adm
    root@azusbosl1:~> ulimit -u unlimited bl1adm
    
    root@azusbosl1:~> su - bl1adm
    bl1adm@azusbosl1:~> ulimit -a
    
    core file size          (blocks, -c) unlimited
    data seg size           (kbytes, -d) unlimited
    scheduling priority             (-e) 0
    file size               (blocks, -f) unlimited
    pending signals                 (-i) 63936
    max locked memory       (kbytes, -l) 64
    max memory size         (kbytes, -m) unlimited
    open files                      (-n) 1024
    pipe size            (512 bytes, -p) 8
    POSIX message queues     (bytes, -q) 819200
    real-time priority              (-r) 0
    stack size              (kbytes, -s) 8192
    cpu time               (seconds, -t) unlimited
    max user processes              (-u) unlimited
    virtual memory          (kbytes, -v) unlimited
    file locks                      (-x) unlimited
    
  6. Pobierz i wyodrębnij media dla platformy SAP BusinessObjects BI z witryny SAP Service Marketplace.

Instalacja

Sprawdź ustawienia regionalne dla konta użytkownika bl1adm na serwerze:

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

Przejdź do nośnika platformy SAP BOBI i uruchom następujące polecenie za pomocą użytkownika usługi bl1adm:

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

Postępuj zgodnie z przewodnikiem instalacji platformy SAP BOBI dla systemu Unix, specyficznym dla używanej wersji. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas instalowania platformy SAP BOBI:

  • Podczas konfigurowania rejestracji produktu można użyć tymczasowego klucza licencji dla rozwiązań SAP BusinessObjects z programu SAP Note 1288121 lub wygenerować klucz licencji w witrynie SAP Service Marketplace.

  • Na stronie Wybierz typ instalacji wybierz pozycję Pełna instalacja na pierwszym serwerze (azusbosl1). W przypadku innego serwera (azusbosl2) wybierz pozycję Niestandardowa / Rozwiń, co spowoduje rozszerzenie istniejącej konfiguracji BOBI.

  • W obszarze Wybierz domyślną lub Istniejącą bazę danych wybierz pozycję Skonfiguruj istniejącą bazę danych, co spowoduje wyświetlenie monitu o wybranie usługi CMS i baz danych inspekcji. Dla tych typów baz danych wybierz pozycję MySQL .

    Możesz również wybrać opcję Brak bazy danych inspekcji, jeśli nie chcesz konfigurować inspekcji podczas instalacji.

  • Na ekranie Wybierz serwer aplikacji internetowej Java wybierz odpowiednie opcje na podstawie architektury SAP BOBI. W tym przykładzie wybrano opcję 1, która instaluje serwer tomcat na tej samej platformie SAP BOBI.

  • Wprowadź informacje o bazie danych CMS w temacie Konfigurowanie bazy danych repozytorium CMS — MySQL. W poniższym przykładzie przedstawiono dane wejściowe dla informacji o bazie danych CMS dla instalacji w systemie Linux. Usługa Azure Database for MySQL jest używana na domyślnym porcie 3306.

    Zrzut ekranu przedstawiający wdrożenie SAP BOBI w systemie Linux — baza danych CMS.

  • (Opcjonalnie) Wprowadź informacje o bazie danych inspekcji w temacie Konfigurowanie bazy danych repozytorium inspekcji — MySQL. W poniższym przykładzie pokazano dane wejściowe dotyczące bazy danych audytu dla instalacji Linux.

    Zrzut ekranu przedstawiający wdrożenie SAP BOBI w systemie Linux — baza danych inspekcji.

  • Postępuj zgodnie z instrukcjami i wprowadź wymagane dane wejściowe, aby ukończyć instalację.

W przypadku wdrożenia z wieloma wystąpieniami uruchom instalatora na drugim hoście (azusbosl2). W oknie Wybierz typ instalacji wybierz Niestandardowy / Rozwiń, aby rozszerzyć istniejącą konfigurację BOBI.

W usłudze Azure Database for MySQL brama przekierowuje połączenia do wystąpień serwera. Po nawiązaniu połączenia klient oprogramowania MySQL wyświetla wersję oprogramowania MySQL ustawioną w bramie, a nie rzeczywistą wersję uruchomioną w wystąpieniu serwera MySQL. Aby określić wersję wystąpienia serwera MySQL, użyj polecenia SELECT VERSION(); w wierszu polecenia MySQL. Aby uzyskać więcej informacji, zobacz Obsługiwane wersje serwera usługi Azure Database for MySQL.

Zrzut ekranu przedstawiający wdrożenie SAP BOBI w systemie Linux — ustawienia CMC.

# Run direct query to the database using MySQL Workbench

select version();

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

Po instalacji

Po zainstalowaniu wieloinstancyjnej platformy SAP BOBI należy wykonać dodatkowe kroki po konfiguracji, aby zapewnić wysoką dostępność aplikacji.

Konfigurowanie nazwy klastra

W przypadku wdrożenia wielu wystąpień platformy SAP BOBI chcesz uruchomić kilka serwerów CMS razem w klastrze. Klaster składa się z co najmniej dwóch serwerów CMS współpracujących ze wspólną bazą danych systemu CMS. Jeśli węzeł uruchomiony w usłudze CMS ulegnie awarii, węzeł z innym cmS będzie nadal obsługiwać żądania platformy analizy biznesowej. Domyślnie na platformie SAP BOBI nazwa klastra odzwierciedla nazwę hosta pierwszego instalowanego programu CMS.

Aby skonfigurować nazwę klastra w systemie Linux, postępuj zgodnie z instrukcjami w przewodniku administratora platformy SAP Business Intelligence Platform. Po skonfigurowaniu nazwy klastra, postępuj zgodnie z SAP Note 1660440, aby ustawić domyślny wpis systemowy na stronie logowania CMC lub BI launchpad.

Konfigurowanie lokalizacji wejściowego i wyjściowego magazynu plików w usłudze Azure NetApp Files

Magazyn plików oznacza katalogi dysków, w których znajdują się rzeczywiste pliki SAP BusinessObjects. Domyślna lokalizacja serwera repozytorium plików dla platformy SAP BOBI znajduje się w lokalnym katalogu instalacyjnym. W przypadku wdrożenia obejmującego wiele instancji ważne jest skonfigurowanie magazynu plików w udostępnionej pamięci masowej, takiej jak Azure NetApp Files. Umożliwia to dostęp do magazynu plików ze wszystkich serwerów warstwy magazynowania.

  1. Jeśli jeszcze nie utworzono woluminów NFS, utwórz je w usłudze Azure NetApp Files. (Postępuj zgodnie z instrukcjami we wcześniejszej sekcji "Aprowizuj usługę Azure NetApp Files".

  2. Zainstaluj wolumin NFS. (Postępuj zgodnie z instrukcjami we wcześniejszej sekcji "Instalowanie woluminu usługi Azure NetApp Files").

  3. Skorzystaj z SAP Note 2512660, aby zmienić ścieżkę repozytorium plików (zarówno wejściowych, jak i wyjściowych).

Replikacja sesji w klastrze Tomcat

Serwer Tomcat obsługuje klastrowanie co najmniej dwóch serwerów aplikacji na potrzeby replikacji sesji i trybu failover. Sesje platformy SAP BOBI są serializowane, więc sesja użytkownika może bezproblemowo przełączyć się do innego wystąpienia serwera Tomcat, nawet jeśli serwer aplikacji zostanie wyłączony.

Załóżmy na przykład, że użytkownik jest podłączony do serwera internetowego, który ulega awarii podczas nawigowania po hierarchii folderów w aplikacji SAP BI. W przypadku poprawnie skonfigurowanego klastra użytkownik może kontynuować nawigowanie po hierarchii folderów bez przekierowywania do strony logowania.

Zobacz notatkę SAP 2808640, aby poznać kroki do skonfigurowania klastrowania Tomcat przy użyciu multiemisji. Należy jednak pamiętać, że platforma Azure nie obsługuje multiemisji. Aby więc klaster Tomcat działał na platformie Azure, należy użyć StaticMembershipInterceptor (nota SAP 2764907). Aby uzyskać więcej informacji, zobacz wpis w blogu Tomcat Clustering using Static Membership for SAP BusinessObjects BI Platform (Klaster tomcat using Static Membership for SAP BusinessObjects BI Platform).

Równoważenie obciążenia warstwy internetowej platformy SAP BI

W przypadku wdrożenia wielu wystąpień SAP BOBI, serwery aplikacji webowych Java (warstwa webowa) działają na dwóch lub więcej hostach. Aby równomiernie dystrybuować obciążenie użytkownika między serwerami internetowymi, można użyć modułu równoważenia obciążenia między użytkownikami końcowymi i serwerami internetowymi. Na platformie Azure możesz użyć usługi Azure Load Balancer lub Azure Application Gateway do zarządzania ruchem do serwerów aplikacji internetowych. Szczegółowe informacje o każdej ofercie opisano w poniższej sekcji.

Azure Load Balancer

Usługa Azure Load Balancer to moduł równoważenia obciążenia warstwy 4 (TCP, UDP) o wysokiej wydajności. Dystrybuuje ruch między sprawnymi maszynami wirtualnymi. Sonda kondycji modułu równoważenia obciążenia monitoruje określony port na każdej maszynie wirtualnej i dystrybuuje ruch tylko do operacyjnej maszyny wirtualnej. Możesz wybrać publiczny moduł równoważenia obciążenia lub wewnętrzny moduł równoważenia obciążenia, w zależności od tego, czy chcesz uzyskać dostęp do platformy SAP BI z Internetu. Jest strefowo nadmiarowa, zapewniając wysoką dostępność w różnych strefach dostępności.

Na poniższym diagramie zapoznaj się z sekcją Wewnętrzny moduł równoważenia obciążenia. Serwer aplikacji internetowej działa na porcie 8080, domyślnym portem HTTP serwera Tomcat, który będzie monitorowany przez sondę kondycji. Każde przychodzące żądanie pochodzące od użytkowników końcowych jest przekierowywane do serwerów aplikacji internetowych (azusbosl1 lub azusbosl2). Usługa Load Balancer nie obsługuje zakończenia protokołu TLS/SSL (znanego również jako odciążanie TLS/SSL). Jeśli używasz Standardowego Load Balancera do dystrybucji ruchu między serwerami internetowymi, użyj Standardowego Load Balancera.

Uwaga

Jeśli maszyny wirtualne bez publicznych adresów IP są umieszczone w puli wewnętrznej standardowego modułu równoważenia obciążenia (bez publicznego adresu IP), nie będzie zapewnione wychodzące połączenie z Internetem, chyba że przeprowadzisz dodatkową konfigurację, aby umożliwić trasowanie do publicznych punktów końcowych. Aby uzyskać więcej informacji, zobacz Łączność z publicznym punktem końcowym dla maszyn wirtualnych używających Standardowej usługi równoważenia obciążenia Azure w scenariuszach wysokiej dostępności SAP.

Diagram przedstawiający równoważenie ruchu usługi Azure Load Balancer między serwerami internetowymi.

Usługa Azure Application Gateway

Azure Application Gateway zapewnia funkcje kontrolera dostarczania aplikacji (ADC) jako usługa. Ta usługa ułatwia aplikacji kierowanie ruchu użytkowników do co najmniej jednego serwera aplikacji internetowej. Oferuje ona różne funkcje równoważenia obciążenia warstwy 7, takie jak odciążanie protokołu TLS/SSL, zapora aplikacji internetowej (WAF) i koligacja sesji opartej na plikach cookie.

Na platformie SAP BI, Application Gateway kieruje ruch internetowy aplikacji do określonych zasobów: azusbosl1 lub azusbos2. Przypisujesz odbiornik do portu, tworzysz reguły i dodajesz zasoby do puli. Na poniższym diagramie usługa Application Gateway ma prywatny adres IP (10.31.3.20), który działa jako punkt wejścia dla użytkowników. Obsługuje również przychodzące połączenia TLS/SSL (HTTPS — TCP/443), odszyfrowuje protokół TLS/SSL i przekazuje niezaszyfrowane żądanie (HTTP — TCP/8080) do serwerów. Upraszcza ona obsługę tylko jednego certyfikatu TLS/SSL w usłudze Application Gateway.

Diagram przedstawiający równoważenie ruchu między serwerami internetowymi w usłudze Application Gateway.

Aby skonfigurować usługę Azure Application Gateway dla serwera internetowego SAP BOBI, zobacz wpis na blogu Równoważenie obciążenia serwerów internetowych SAP BOBI przy użyciu Azure Application Gateway.

Uwaga

Azure Application Gateway jest preferowany do równoważenia obciążenia ruchu do serwera internetowego. Udostępnia ona przydatne funkcje, takie jak odciążanie SSL, scentralizowane zarządzanie SSL, aby zmniejszyć obciążenie związane z szyfrowaniem i odszyfrowywaniem na serwerze, algorytmem round-robin do dystrybucji ruchu, funkcje zapory sieciowej WAF i wysoka dostępność.

Niezawodność platformy SAP BOBI na platformie Azure

Platforma SAP BOBI obejmuje różne warstwy, które są zoptymalizowane pod kątem określonych zadań i operacji. Gdy składnik z dowolnej warstwy stanie się niedostępny, aplikacja SAP BOBI stanie się niedostępna lub ograniczona w jej funkcjonalności. Upewnij się, że każda warstwa została zaprojektowana tak, aby zapewnić niezawodność działania aplikacji bez żadnych zakłóceń biznesowych.

W tym przewodniku opisano, w jaki sposób funkcje natywne platformy Azure, w połączeniu z konfiguracją platformy SAP BOBI, poprawiają dostępność wdrożenia SAP. Ta sekcja koncentruje się na następujących opcjach:

  • Tworzenie kopii zapasowych i przywracanie: jest to proces tworzenia okresowych kopii danych i aplikacji do oddzielnej lokalizacji. Możesz przywrócić lub odzyskać do poprzedniego stanu, jeśli oryginalne dane lub aplikacje zostaną utracone lub uszkodzone.

  • Wysoka dostępność: platforma o wysokiej dostępności ma co najmniej dwa elementy w regionie świadczenia usługi Azure, aby zachować działanie aplikacji, jeśli jeden z serwerów stanie się niedostępny.

  • Odzyskiwanie po awarii: jest to proces przywracania funkcji aplikacji, jeśli wystąpi jakakolwiek katastrofalna strata, taka jak niedostępność całego regionu świadczenia usługi Azure z powodu niektórych klęsk żywiołowych.

Implementacja tego rozwiązania różni się w zależności od charakteru konfiguracji systemu na platformie Azure. Dostosuj kopię zapasową/przywracanie, wysoką dostępność i rozwiązania do odzyskiwania po awarii zgodnie z wymaganiami biznesowymi.

Tworzenie kopii zapasowej i przywracanie

Tworzenie kopii zapasowych i przywracanie jest istotnym składnikiem każdej strategii odzyskiwania po awarii biznesowej. Aby opracować kompleksową strategię platformy SAP BOBI, zidentyfikuj składniki, które prowadzą do przestoju systemu lub zakłóceń w aplikacji. Na platformie SAP BOBI kopia zapasowa następujących składników jest niezbędna do ochrony aplikacji:

  • Katalog instalacyjny SAP BOBI (dyski zarządzane w warstwie Premium)
  • Serwer repozytorium plików (Azure NetApp Files lub Azure Premium Files)
  • Baza danych CMS (Azure Database for MySQL lub baza danych na maszynach wirtualnych Azure)

W poniższej sekcji opisano sposób implementowania strategii tworzenia kopii zapasowych i przywracania dla każdego z tych składników.

Tworzenie kopii zapasowej i przywracanie katalogu instalacyjnego SAP BOBI

Na platformie Azure najprostszym sposobem tworzenia kopii zapasowych serwerów aplikacji i wszystkich dołączonych dysków jest użycie usługi Azure Backup. Zapewnia niezależne i izolowane kopie zapasowe w celu ochrony przed niezamierzonym zniszczeniem danych na maszynach wirtualnych. Kopie bezpieczeństwa są przechowywane w sejfie Usług odzyskiwania, z wbudowanym zarządzaniem punktami odzyskiwania. Konfiguracja i skalowanie są proste, kopie zapasowe są zoptymalizowane i można je łatwo przywrócić, gdy zajdzie taka potrzeba.

W ramach procesu tworzenia kopii zapasowej wykonywana jest migawka, a dane są przesyłane do magazynu bez wpływu na obciążenia produkcyjne. Aby uzyskać więcej informacji, zobacz Spójność migawek. Możesz również utworzyć kopię zapasową podzestawu dysków danych na maszynie wirtualnej przy użyciu funkcji tworzenia kopii zapasowych i przywracania selektywnych dysków. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych maszyn wirtualnych platformy Azure i często zadawane pytania — tworzenie kopii zapasowych maszyn wirtualnych platformy Azure.

Tworzenie kopii zapasowej i przywracanie serwera repozytorium plików

Na podstawie wdrożenia SAP BOBI w systemie Linux możesz użyć usługi Azure NetApp Files jako magazynu plików platformy SAP BOBI. Wybierz jedną z następujących opcji tworzenia kopii zapasowych i przywracania, w zależności od używanego systemu przechowywania plików.

  • Azure NetApp Files: można tworzyć migawki na żądanie i planować automatyczne migawki przy użyciu zasad migawek. Migawkowe kopie zapewniają migawkową kopię wolumenu w określonym momencie. Aby uzyskać więcej informacji, zobacz Zarządzanie migawkami przy użyciu usługi Azure NetApp Files.

  • Jeśli utworzono oddzielny serwer NFS, upewnij się, że wdrożono strategię tworzenia i przywracania kopii zapasowych dla tego samego serwera.

Tworzenie kopii zapasowych i przywracanie dla baz danych CMS i audytu

Na maszynach wirtualnych z systemem Linux systemy CMS i bazy danych inspekcji mogą być uruchamiane w dowolnej z obsługiwanych baz danych. Aby uzyskać więcej informacji, zobacz macierz pomocy technicznej. Ważne jest, aby wdrożyć strategię tworzenia i przywracania kopii zapasowych w oparciu o bazę danych używaną dla usługi CMS i magazynu danych inspekcji.

  • Usługa Azure Database for MySQL automatycznie tworzy kopie zapasowe serwera i przechowuje je w magazynie skonfigurowanym przez użytkownika, lokalnie redundantnym lub geograficznie redundantnym. Usługa Azure Database for MySQL wykonuje kopie zapasowe plików danych i dziennika transakcji. W zależności od obsługiwanego maksymalnego rozmiaru magazynu, wykonuje pełne i różnicowe kopie zapasowe (dla serwerów z maksymalnym rozmiarem magazynu 4 TB) lub kopie zapasowe migawek (dla serwerów z maksymalnym rozmiarem magazynu do 16 TB). Te kopie zapasowe umożliwiają przywracanie serwera w dowolnym momencie w skonfigurowanym okresie przechowywania kopii zapasowych. Domyślny okres przechowywania kopii zapasowych to siedem dni, które można opcjonalnie skonfigurować do trzech dni. Wszystkie kopie zapasowe są szyfrowane przy użyciu 256-bitowego szyfrowania AES. Te pliki kopii zapasowej nie są uwidocznione przez użytkownika i nie można ich eksportować. Te kopie zapasowe mogą być używane tylko na potrzeby operacji przywracania w usłudze Azure Database for MySQL. Aby skopiować bazę danych, możesz użyć narzędzia mysqldump . Aby uzyskać więcej informacji, zobacz Tworzenie i przywracanie kopii zapasowej w usłudze Azure Database for MySQL.

  • W przypadku bazy danych zainstalowanej na maszynie wirtualnej platformy Azure można użyć standardowych narzędzi do tworzenia kopii zapasowych lub usługi Azure Backup dla obsługiwanych baz danych. Możesz również użyć obsługiwanych narzędzi do tworzenia kopii zapasowych innych firm, które udostępniają agenta do tworzenia kopii zapasowych i odzyskiwania wszystkich składników platformy SAP BOBI.

Wysoka dostępność

Wysoka dostępność odnosi się do zestawu technologii, które mogą zminimalizować zakłócenia IT, zapewniając ciągłość działalności biznesowej aplikacji i usług. Robi to za pośrednictwem nadmiarowych, odpornych na uszkodzenia lub chronionych w trybie failover składników w tym samym centrum danych. W naszym przypadku centra danych znajdują się w jednym regionie świadczenia usługi Azure. Aby uzyskać więcej informacji, zobacz Architektura i scenariusze wysokiej dostępności dla oprogramowania SAP.

Na podstawie wyniku analizy rozmiaru platformy SAP BOBI należy zaprojektować krajobraz i określić dystrybucję składników BI w maszynach wirtualnych Azure i podsieciach. Poziom nadmiarowości w architekturze rozproszonej zależy od celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO), który jest potrzebny dla Twojej firmy. Platforma SAP BOBI obejmuje różne warstwy, a składniki w każdej warstwie powinny być zaprojektowane w celu zapewnienia nadmiarowości. Na przykład:

  • Nadmiarowe serwery aplikacji, takie jak serwery aplikacji analizy biznesowej i serwer internetowy.
  • Unikatowe składniki, takie jak baza danych CMS, serwer repozytorium plików i moduł równoważenia obciążenia.

W poniższych sekcjach opisano sposób uzyskiwania wysokiej dostępności na poszczególnych składnikach platformy SAP BOBI.

Wysoka dostępność serwerów aplikacji

Wysoką dostępność serwerów aplikacji można osiągnąć, stosując nadmiarowość. W tym celu skonfiguruj wiele instancji usługi BI oraz serwerów internetowych na różnych maszynach wirtualnych w ramach platformy Azure.

Aby zmniejszyć wpływ przestojów z powodu planowanych i nieplanowanych zdarzeń, warto postępować zgodnie ze wskazówkami dotyczącymi architektury wysokiej dostępności.

Aby uzyskać więcej informacji, zobacz Zarządzanie dostępnością maszyn wirtualnych z systemem Linux.

Ważne

  • Pojęcia dotyczące stref dostępności platformy Azure i zestawów dostępności platformy Azure wzajemnie się wykluczają. Można wdrożyć parę lub wiele maszyn wirtualnych w określonej strefie dostępności lub zestawie dostępności, ale nie można wykonać obu tych czynności.
  • Jeśli planujesz wdrożenie w różnych strefach dostępności, zaleca się użycie elastycznego zestawu skalowania z FD=1 zamiast standardowego wdrożenia strefy dostępności.

Wysoka dostępność bazy danych CMS

Jeśli używasz usługi Azure Database for MySQL dla baz danych CMS i audytu, masz domyślnie lokalnie nadmiarową platformę wysokiej dostępności. Wystarczy wybrać region, a usługa automatycznie zapewnia wysoką dostępność, nadmiarowość i odporność, bez potrzeby konfigurowania dodatkowych składników. Jeśli strategia deploymentu platformy SAP BOBI jest realizowana w różnych strefach dostępności, należy upewnić się, że zapewniono nadmiarowość strefową dla baz danych CMS i auditowych. Aby uzyskać więcej informacji, zobacz Wysoka dostępność w usłudze Azure Database for MySQL i Wysoka dostępność dla usługi Azure SQL Database.

Aby zapoznać się z innymi wdrożeniami bazy danych CMS, zobacz informacje o wysokiej dostępności w przewodnikach wdrażania systemu DBMS dla obciążenia SAP.

Wysoka dostępność magazynu plików

System przechowywania plików to katalogi dysków, w których przechowywane są takie treści jak raporty, modele danych i połączenia. Jest on współużytkowany na wszystkich serwerach aplikacji tego systemu. Dlatego należy upewnić się, że jest wysoce dostępna wraz z innymi składnikami platformy SAP BOBI.

W przypadku platformy SAP BOBI działającej w systemie Linux możesz wybrać usługę Azure Premium Files lub Azure NetApp Files dla udziałów plików, które mają być wysoce dostępne i wysoce trwałe. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Files.

Należy pamiętać, że ta usługa udostępniania plików nie jest dostępna we wszystkich regionach. Zobacz Dostępność produktów według regionów , aby znaleźć aktualne informacje. Jeśli usługa nie jest dostępna w Twoim regionie, możesz utworzyć serwer NFS, z którego można udostępnić system plików aplikacji SAP BOBI. Należy jednak również wziąć pod uwagę jego wysoką dostępność.

Wysoka dostępność modułu równoważenia obciążenia

Aby dystrybuować ruch na serwerach internetowych, możesz użyć Azure Load Balancer lub Azure Application Gateway. Redundancję każdej z tych opcji można osiągnąć w zależności od wybranego SKU do wdrożenia.

  • W przypadku usługi Azure Load Balancer nadmiarowość można osiągnąć, konfigurując usługę Load Balancer w warstwie Standardowej jako strefowo nadmiarowy. Aby uzyskać więcej informacji, zobacz Standard Load Balancer i Strefy dostępności.

  • W przypadku usługi Application Gateway można uzyskać wysoką dostępność na podstawie typu warstwy wybranej podczas wdrażania.

    • Jednostka SKU w wersji 1 obsługuje scenariusze wysokiej dostępności podczas wdrażania co najmniej dwóch wystąpień. Platforma Azure dystrybuuje te wystąpienia między domenami aktualizacji i błędów, aby upewnić się, że wystąpienia nie wszystkie kończą się niepowodzeniem w tym samym czasie. Osiągasz redundancję w strefie.
    • Jednostka SKU w wersji 2 automatycznie zapewnia, że nowe wystąpienia są rozmieszczone w domenach błędów i domenach aktualizacji. W przypadku wybrania nadmiarowości strefy najnowsze wystąpienia są również rozmieszczone w różnych strefach dostępności, aby zapewnić odporność na awarie strefowe. Aby uzyskać więcej informacji, zobacz Autoskalowanie i strefowo redundantne Application Gateway w wersji 2.

Referencyjna architektura wysokiej dostępności dla platformy SAP BOBI

Na poniższym diagramie przedstawiono konfigurację platformy SAP BOBI uruchomionej na serwerze z systemem Linux. Architektura pokazuje użycie różnych usług, takich jak Azure Application Gateway, Azure NetApp Files i Azure Database for MySQL. Te usługi oferują wbudowaną nadmiarowość, co zmniejsza złożoność zarządzania różnymi rozwiązaniami o wysokiej dostępności.

Zwróć uwagę, że ruch przychodzący (HTTPS) jest zrównoważony za pomocą Azure Application Gateway SKU w wersjach v1/v2, które są wysoce dostępne, gdy są wdrażane na dwóch lub więcej instancjach. W celu zapewnienia nadmiarowości wdrożono wiele serwerów internetowych, serwerów zarządzania i serwerów przetwarzania. Usługa Azure NetApp Files ma wbudowaną nadmiarowość w centrum danych, więc woluminy usługi Azure NetApp Files dla serwera repozytorium plików będą wysoce dostępne. Baza danych CMS jest aprowizowana w usłudze Azure Database for MySQL, która ma nieodłączną wysoką dostępność. Aby uzyskać więcej informacji, zobacz Wysoka dostępność w usłudze Azure Database for MySQL.

Diagram przedstawiający awaryjność platformy SAP BusinessObjects BI z zestawami dostępności.

Poprzednia architektura zawiera szczegółowe informacje na temat sposobu wdrażania rozwiązania SAP BOBI na platformie Azure. Nie obejmuje to jednak wszystkich możliwych opcji konfiguracji. Wdrożenie można dostosować zgodnie z wymaganiami biznesowymi.

W kilku regionach świadczenia usługi Azure można używać stref dostępności. Oznacza to, że można korzystać z niezależnego źródła zasilania, chłodzenia i sieci. Umożliwia wdrażanie aplikacji w dwóch lub trzech strefach dostępności. Jeśli chcesz uzyskać wysoką dostępność w różnych strefach dostępności, możesz wdrożyć platformę SAP BOBI w tych strefach, upewniając się, że każdy składnik w aplikacji jest strefowo nadmiarowy.

Odzyskiwanie po awarii

W tej sekcji opisano strategię zapewniania ochrony odzyskiwania po awarii dla platformy SAP BOBI działającej w systemie Linux. Uzupełnia dokument Odzyskiwania po awarii dla oprogramowania SAP , który reprezentuje podstawowe zasoby dla ogólnego podejścia do odzyskiwania po awarii SAP. W przypadku rozwiązania SAP BOBI zapoznaj się z artykułem SAP Note 2056228, w którym opisano następujące metody bezpiecznego implementowania środowiska odzyskiwania po awarii.

  • Należy w pełni lub selektywnie korzystać z zarządzania cyklem życia lub federacji, aby promować i rozpowszechniać treści z systemu podstawowego.
  • Okresowo kopiuje zawartość serwera CMS i repozytorium plików.

Ten przewodnik koncentruje się na drugiej opcji. Nie obejmuje wszystkich możliwych opcji konfiguracji odzyskiwania po awarii, ale obejmuje rozwiązanie, które zawiera natywne usługi platformy Azure w połączeniu z konfiguracją platformy SAP BOBI.

Ważne

  • Dostępność każdego składnika na platformie SAP BOBI powinna być uwzględniana w regionie pomocniczym i należy dokładnie przetestować całą strategię odzyskiwania po awarii.
  • W przypadku, gdy platforma SAP BI jest skonfigurowana z elastycznym zestawem skalowania z FD=1, należy użyć programu PowerShell do skonfigurowania usługi Azure Site Recovery na potrzeby odzyskiwania po awarii. Obecnie to jedyna dostępna metoda konfiguracji odzyskiwania po katastrofie dla maszyn wirtualnych wdrożonych w zestawie skalującym.

Referencyjna architektura odzyskiwania po awarii dla platformy SAP BOBI

Ta architektura referencyjna obsługuje wdrożenie z wieloma instancjami platformy SAP BOBI, z nadmiarowymi serwerami aplikacji. W przypadku odzyskiwania po awarii należy przełączyć wszystkie składniki platformy SAP BOBI do regionu zapasowego. Na poniższym diagramie usługa Azure NetApp Files jest używana jako magazyn plików, Azure Database for MySQL jako system zarządzania treścią i repozytorium audytów, a Azure Application Gateway jako moduł równoważenia obciążenia. Strategia osiągnięcia ochrony odzyskiwania po awarii dla każdego składnika jest inna, a te różnice opisano w poniższych sekcjach.

Diagram przedstawiający odzyskiwanie po awarii platformy SAP BusinessObjects BI.

Moduł równoważenia obciążenia

Moduł równoważenia obciążenia służy do dystrybucji ruchu między serwerami aplikacji internetowych platformy SAP BOBI. Na platformie Azure możesz w tym celu użyć usługi Azure Load Balancer lub usługi Azure Application Gateway. Aby uzyskać odzyskiwanie po awarii dla usług modułu równoważenia obciążenia, należy zaimplementować drugą usługę Azure Load Balancer lub Azure Application Gateway w regionie zapasowym. Aby zachować ten sam adres URL po przejściu w tryb failover odzyskiwania po awarii, należy zmienić wpis w systemie DNS, wskazując usługę równoważenia obciążenia uruchomioną w regionie pomocniczym.

Maszyny wirtualne z uruchomionymi serwerami aplikacji internetowych i biznesowych

Usługa Azure Site Recovery umożliwia replikowanie maszyn wirtualnych z uruchomionymi serwerami aplikacji internetowych i biznesowych w regionie pomocniczym. Replikuje serwery i wszystkie dołączone zarządzane dyski do regionu pomocniczego, dzięki czemu w przypadku awarii i zakłóceń można łatwo przełączyć się na zreplikowane środowisko i kontynuować pracę. Aby rozpocząć replikację wszystkich maszyn wirtualnych aplikacji SAP do centrum danych odzyskiwania po awarii platformy Azure, postępuj zgodnie ze wskazówkami w temacie Replikowanie maszyny wirtualnej na platformę Azure.

Serwery repozytorium plików

Magazyn plików to katalog dysku, w którym przechowywane są rzeczywiste pliki, takie jak raporty i dokumenty analizy biznesowej. Ważne jest, aby wszystkie pliki w magazynie plików zostały zsynchronizowane z regionem odzyskiwania po awarii. Na podstawie typu usługi udostępniania plików używanej dla platformy SAP BOBI działającej w systemie Linux należy zastosować właściwą strategię odzyskiwania po awarii w celu zsynchronizowania zawartości.

  • Usługa Azure NetApp Files udostępnia woluminy NFS i SMB, dzięki czemu można replikować dane między regionami platformy Azure za pomocą dowolnego narzędzia do kopiowania opartego na plikach. Aby uzyskać więcej informacji na temat kopiowania woluminu w innym regionie, zobacz Często zadawane pytania dotyczące usługi Azure NetApp Files.

    Można użyć replikacji między regionami usługi Azure NetApp Files, obecnie w wersji zapoznawczej. Tylko zmienione bloki są wysyłane przez sieć w skompresowanym, wydajnym formacie. Minimalizuje to ilość danych wymaganych do replikacji w różnych regionach, co pozwala zaoszczędzić koszty transferu danych. Skraca również czas replikacji, dzięki czemu można osiągnąć mniejsze RPO (Recovery Point Objective). Aby uzyskać więcej informacji, zobacz Wymagania i zagadnienia dotyczące korzystania z replikacji między regionami.

  • Usługa Azure Premium Files obsługuje tylko magazyn lokalnie nadmiarowy (LRS) i magazyn strefowo nadmiarowy (ZRS). W przypadku strategii odzyskiwania po awarii możesz użyć narzędzia AzCopy lub programu Azure PowerShell , aby skopiować pliki na inne konto magazynu w innym regionie. Aby uzyskać więcej informacji, zobacz Odzyskiwanie po awarii i przełączanie awaryjne konta magazynowego.

    Ważne

    Protokół SMB dla usługi Azure Files jest ogólnie dostępny, ale obsługa protokołu NFS dla usługi Azure Files jest obecnie dostępna w wersji zapoznawczej. Aby uzyskać więcej informacji, zobacz Obsługa systemu plików NFS 4.1 dla usługi Azure Files jest teraz dostępna w wersji zapoznawczej.

Baza danych cms

Bazy danych CMS oraz audytowe w regionie odzyskiwania po awarii muszą być kopią baz danych działających w regionie podstawowym. Na podstawie typu bazy danych ważne jest skopiowanie jej do regionu odzyskiwania po awarii z uwzględnieniem wymagań firmy co do czasu RTO i punktu RPO.

Azure Database for MySQL (usługa bazy danych MySQL)

Usługa Azure Database for MySQL oferuje wiele opcji odzyskiwania bazy danych w przypadku awarii. Wybierz odpowiednią opcję, która działa dla Twojej firmy.

  • Włącz repliki odczytu międzyregionowego, aby zwiększyć ciągłość działania i ulepszyć planowanie odzyskiwania po awarii. Z serwera źródłowego można replikować maksymalnie pięć replik. Repliki do odczytu są aktualizowane asynchronicznie przy użyciu technologii replikacji dziennika binarnego mySQL. Repliki to nowe serwery, którymi zarządzasz podobnie jak zwykłe serwery w usłudze Azure Database for MySQL. Aby uzyskać więcej informacji, zobacz Read replicas in Azure Database for MySQL (Repliki do odczytu w usłudze Azure Database for MySQL).

  • Użyj funkcji przywracania geograficznego, aby przywrócić serwer przy użyciu geograficznie nadmiarowych kopii zapasowych. Te kopie zapasowe są dostępne nawet wtedy, gdy region, w którym jest hostowany serwer, jest w trybie offline. Możesz przywrócić z tych kopii zapasowych do dowolnego innego regionu i przywrócić serwer z powrotem do trybu online.

    Uwaga

    Przywracanie geograficzne jest możliwe tylko jeśli przygotowałeś serwer z geo-redundantnym przechowywaniem kopii zapasowych. Zmiana opcji nadmiarowości kopii zapasowej po utworzeniu serwera nie jest obsługiwana. Aby uzyskać więcej informacji, zobacz Nadmiarowość kopii zapasowych.

W poniższej tabeli przedstawiono zalecenie dotyczące odzyskiwania po awarii poszczególnych warstw używanych w tym przykładzie.

Poziomy platformy SAP BOBI Zalecenie
Usługa Azure Application Gateway Równoległa konfiguracja usługi Application Gateway w regionie sekundarnym.
Serwery aplikacji internetowych Replikuj przy użyciu usługi Azure Site Recovery.
Serwery aplikacji analizy biznesowej Replikuj przy użyciu usługi Site Recovery.
Azure NetApp Files Narzędzie do kopiowania opartego na plikach w celu replikowania danych do regionu pomocniczego lub przy użyciu replikacji między regionami.
Azure Database for MySQL Repliki do odczytu między regionami lub przywracanie kopii zapasowych z geograficznie nadmiarowych kopii zapasowych.

Następne kroki