AZ SAP BusinessObjects BI platform üzembe helyezési útmutatója Az Azure-beli Windowshoz

Ez a cikk az SAP BusinessObjects Business Intelligence (SAP BOBI) platform Üzembe helyezésének stratégiáját ismerteti a Windows Azure-ban. Ebben a példában két virtuális gép (virtuális gép) és az Azure Premium SSD által felügyelt lemezek vannak konfigurálva a telepítési címtáruk konfigurálásakor. Az Azure SQL Database szolgáltatásként nyújtott platform (PaaS) a központi felügyeleti kiszolgálóhoz (CMS) és az adatbázisok naplózásához használható. Az Azure Premium Files, az SMB protokoll mindkét virtuális gépen megosztott fájltárolóként használatos. Az alapértelmezett Tomcat Java-webalkalmazás és üzletiintelligencia-platformalkalmazás együtt van telepítve mindkét virtuális gépen. A felhasználói kérések terheléselosztásához Azure-alkalmazás Átjárót használunk, amely natív TLS/SSL-kiszervezési képességekkel rendelkezik.

Ez az architektúratípus kis üzemi vagy nem gyártási környezetekben hatékony. Éles vagy nagy léptékű üzembe helyezés esetén külön kell elválasztani a webalkalmazások gazdagépeit, és több SAP BOBI-alkalmazás gazdagépe is lehet, amely lehetővé teszi a kiszolgáló számára további információk feldolgozását.

Ebben a példában a következő termékverziókat és fájlrendszer-elrendezést használjuk:

• SAP BusinessObjects platform 4.3 SP01 Patch 1
• Windows Server 2019
• SQL Database (verzió: 12.0.2000.8)
• Microsoft ODBC-illesztő – msodbcsql.msi (Verzió: 13.1)

Fájlrendszer	Leírás	Méret (GB)	Szükséges hozzáférés	Storage
F:	Az SAP BOBI-példány, az alapértelmezett Tomcat-webalkalmazás és az adatbázis-illesztőprogramok telepítésére szolgáló fájlrendszer (ha szükséges).	SAP méretezési irányelvek	Helyi rendszergazdai jogosultságok	Felügyelt Azure Premium SSD-lemezek
\\azusbobi.file.core.windows.net\frsinput	A csatlakoztatási könyvtár az összes SAP BOBI-gazdagép megosztott fájljaihoz tartozik, amelyek bemeneti fájltár könyvtárként lesznek használva.	Üzleti igény	Helyi rendszergazdai jogosultságok	Azure NetApp Files
\\azusbobi.file.core.windows.net\frsoutput	A csatlakoztatási könyvtár az összes SAP BOBI-gazdagép megosztott fájljaihoz készült, amelyek kimeneti fájltár könyvtárként lesznek használva.	Üzleti igény	Helyi rendszergazdai jogosultságok	Azure NetApp Files

Windows rendszerű virtuális gép üzembe helyezése az Azure Portalon

Ebben a szakaszban két virtuális gépet hozunk létre egy Windows operációs rendszer (OS) rendszerképpel az SAP BOBI platformhoz. A virtuális gépek létrehozásának magas szintű lépései a következők:

1. Hozzon létre egy erőforráscsoportot.

2. Virtuális hálózat létrehozása:

   • Ne használjon egyetlen alhálózatot az ÖSSZES Azure-szolgáltatáshoz egy SAP BI-platform üzembe helyezéséhez. Az SAP BI platformarchitektúrája alapján előfordulhat, hogy több alhálózatot kell létrehoznia. Ebben az üzembe helyezésben két alhálózatot hozunk létre: egy BI-alkalmazás alhálózatát és egy Application Gateway-alhálózatot.
   • Kövesse az SAP Note 2276646 az SAP BOBI platform különböző összetevők közötti kommunikációjához szükséges portok azonosításához.
   • Az SQL Database az 1433-as porton kommunikál. Az 1433-as porton keresztüli kimenő forgalmat engedélyezni kell az SAP BOBI-alkalmazáskiszolgálókról.
   • Az Azure-ban az Application Gatewaynek külön alhálózaton kell lennie. További információkért tekintse meg az Application Gateway konfigurációjának áttekintését.
   • Ha az Azure NetApp Filest az Azure Files helyett egy fájltárolóhoz használja, hozzon létre egy külön alhálózatot az Azure NetApp Fileshoz. További információ: Irányelvek az Azure NetApp Files hálózattervezéséhez.

3. Válassza ki a megfelelő rendelkezésre állási lehetőségeket az Azure-régióban előnyben részesített rendszerkonfigurációtól függően, legyen szó akár zónák közötti átnyúlásról, egyetlen zónán belül való működésről, akár zóna nélküli régióban való működésről.

4. 1. virtuális gép létrehozása (azuswinboap1):

   • Használhat egyéni rendszerképet, vagy választhat egy képet az Azure Marketplace-ről. Igény szerint lásd : Virtuális gép üzembe helyezése az Azure Marketplace-ről az SAP-hoz , vagy virtuális gép üzembe helyezése egyéni rendszerképpel az SAP-hoz.

5. 2. virtuális gép létrehozása (azuswinboap2).

6. Adjon hozzá egy Prémium SSD-lemezt. Sap BOBI telepítési könyvtárként fogjuk használni.

Azure Premium Files kiépítése

Az Azure Files beállításának folytatása előtt ismerkedjen meg az Azure Files dokumentációjával.

Az Azure Files standard fájlmegosztásokat kínál, amely HDD-alapú hardveren és prémium szintű, SSD-alapú hardveren üzemeltetett fájlmegosztásokon fut. SAP BusinessObjects-fájltárolókhoz használja az Azure Premium Filest.

A prémium szintű Azure-fájlmegosztások helyi és zónaredundanciával érhetők el a régiók egy részhalmazában. Ha szeretné megtudni, hogy a prémium fájlmegosztások jelenleg elérhetők-e a régióban, tekintse meg a régiónként elérhető termékeket. A zónaredundáns tárolást (ZRS) támogató régiókról további információt az Azure Storage redundanciájával kapcsolatban talál.

Azure Files Storage-fiók és NFS-megosztások üzembe helyezése

Az Azure-fájlmegosztások a tárfiókokban vannak üzembe helyezve, amelyek olyan legfelső szintű objektumok, amelyek megosztott tárkészletet képviselnek. Ez a tárkészlet több fájlmegosztás üzembe helyezésére is használható. Azure-támogatás több típusú tárfiókot használ a különböző tárolási forgatókönyvekhez, amelyeket az ügyfelek használhatnak. Az SAP BusinessObjects fájltárolójához létre kell hoznia egy FileStorage-fiókot. Ezzel azure-fájlmegosztásokat helyezhet üzembe prémium SSD-alapú hardvereken.

Megjegyzés:

A FileStorage-fiókok csak Azure-fájlmegosztások tárolására használhatók. Más tárolási erőforrások, például blobok, tárolók, üzenetsorok vagy táblák nem helyezhetők üzembe a FileStorage-fiókban.

A tárfiók privát végponton keresztül lesz elérhető, és egy SAP BOBI-platform ugyanazon virtuális hálózatában lesz üzembe helyezve. Ezzel a beállítással az SAP-rendszerből érkező forgalom soha nem hagyja el a virtuális hálózat biztonsági határait. Az SAP-rendszerek gyakran tartalmaznak bizalmas és üzleti szempontból kritikus adatokat, ezért a virtuális hálózat határain belül maradni sok ügyfél számára fontos biztonsági szempont.

Ha egy másik virtuális hálózatból kell elérnie a tárfiókot, használhatja az Azure Virtual Network társviszony-létesítést.

Azure Files Storage-fiók

1. Ha tárfiókot szeretne létrehozni az Azure Portalon keresztül, válassza az Erőforrás>tárfiók> létrehozása lehetőséget.

2. Az Alapszintű beállítások lapon töltse ki a tárfiók létrehozásához szükséges összes mezőt:

   1. Válassza az Előfizetési>erőforráscsoport régiója lehetőséget.>

   2. Adja meg a Tárfiók nevét. Írja be például az azusbobi nevet. Ennek a névnek globálisan egyedinek kell lennie, de ellenkező esetben bármilyen nevet megadhat.

   3. Válassza ki a Premiumot teljesítményszintként, és válassza a FileStorage lehetőséget fióktípusként.

   4. Replikációs címke esetén válasszon egy redundanciaszintet. Válassza aHelyileg redundáns tárolás (LRS) lehetőséget.

      A Premium FileStorage esetében a ZRS és az LRS az egyetlen elérhető lehetőség. A virtuális gép üzembehelyezési stratégiája (rugalmas méretezési csoport, rendelkezésre állási zóna vagy rendelkezésre állási csoport) alapján válassza ki a megfelelő redundanciaszintet. További információ: Azure Storage-redundancia.

   5. Válassza a Következő lehetőséget.

3. A Hálózatkezelés lapon válassza ki a privát végpontot kapcsolati módszerként. További információkért tekintse meg az Azure Files hálózatkezelési szempontjait.

   1. Válassza a Hozzáadás lehetőséget a privát végpont szakaszban.

   2. Válassza ki az Előfizetési>erőforráscsoport>helyét.

   3. Adja meg a privát végpont nevét . Írja be például az azusbobi-pe értéket.

   4. Válassza ki a fájlt a tárolási alerőforrásban.

   5. A Hálózatkezelés szakaszban válassza ki azt a virtuális hálózatot és alhálózatot, amelyen az SAP BusinessObjects BI-alkalmazás telepítve van.

   6. Fogadja el a privát DNS-zónával való integráció alapértelmezett (igen)értékét.

   7. Válassza ki a privát DNS-zónát a legördülő listából.

   8. Kattintson az OK gombra a Tárfiók létrehozása párbeszédpanel Hálózatkezelés lapjára való visszatéréshez.

4. Az Adatvédelem lapon konfigurálja a tárfiókban lévő Azure-fájlmegosztások helyreállítható törlési szabályzatát. Alapértelmezés szerint a helyreállítható törlés funkció ki van kapcsolva. A helyreállítható törlésről további információt az Azure-fájlmegosztások véletlen törlésének megakadályozása című témakörben talál.

5. A Speciális lapon válassza ki a különböző biztonsági beállításokat.

   A biztonságos átvitelhez szükséges mező azt jelzi, hogy a tárfiók titkosítást igényel-e a tárfiók felé irányuló kommunikációhoz. Ha SMB 2.1-támogatást igényel, tiltsa le ezt a mezőt. Az SAP BOBI-platform esetében tartsa alapértelmezettként (engedélyezve).

6. Folytassa és hozza létre a tárfiókot.

A tárfiókok létrehozásáról további információt a FileStorage tárfiók létrehozása című témakörben talál.

Azure-fájlmegosztások létrehozása

A következő lépés az Azure-fájlok létrehozása a tárfiókban. Az Azure-fájlok egy kiépített modellt használnak a prémium szintű fájlmegosztásokhoz. Egy kiépített üzleti modellben proaktív módon adja meg az Azure-fájloknak, hogy mik a tárolási követelmények, ahelyett, hogy a használat alapján számlázzák őket. A modellről további információt a Kiépített modell című témakörben talál. Ebben a példában két Azure-fájlt hozunk létre: frsinput (256 GB) és frsoutput (256 GB) az SAP BOBI-fájltárolóhoz.

1. Nyissa meg a tárfiók azusbobi>fájlmegosztásait.
2. Válassza az Új fájlmegosztás lehetőséget.
3. Adja meg a fájlmegosztás nevét . Írja be például az frsinput vagy az frsouput értéket.
4. Szúrja be a szükséges fájlmegosztási méretet a kiépített kapacitásba. Írja be például a 256 GB-ot.
5. Válassza az SMB protokollként lehetőséget.
6. Válassza a Létrehozás parancsot.

Adatlemez konfigurálása Windows rendszerű virtuális gépen

A szakasz lépései a következő előtagot használják:

[A]: A lépés az összes gazdagépre vonatkozik.

Új adatlemez inicializálása

Az SAP BusinessObjects BI-alkalmazáshoz olyan partícióra van szükség, amelyre a bináris fájlok telepíthetők. Sap BOBI-alkalmazást telepíthet az operációsrendszer-partícióra (C:), de gondoskodnia kell arról, hogy elegendő hely legyen az üzembe helyezéshez és az operációs rendszerhez. Javasoljuk, hogy legalább 2 GB legyen elérhető ideiglenes fájlokhoz és webalkalmazásokhoz. Javasoljuk továbbá, hogy külön partíciókban különítse el az SAP BOBI telepítési bináris fájljait.

Ebben a példában egy SAP BOBI-alkalmazás van telepítve egy külön partícióra (F:). Inicializálja a virtuális gép kiépítése során csatlakoztatott Prémium SSD-lemezt:

1. [A] Ha nincs adatlemez csatlakoztatva a virtuális géphez (azuswinboap1 és azuswinboap2), kövesse az Adatlemez hozzáadása új felügyelt adatlemez csatlakoztatásához című témakörben leírt lépéseket.
2. [A] Miután a felügyelt lemezt csatlakoztatta a virtuális géphez, inicializálja a lemezt az új adatlemez inicializálása című témakörben leírt lépésekkel.

Azure Premium Files csatlakoztatása

Az Azure Files fájltárolóként való használatához csatlakoztatnia kell, ami azt jelenti, hogy meghajtóbetűjelet vagy csatlakoztatási pont elérési útját rendeli hozzá.

[A] Az Azure-fájlmegosztás csatlakoztatásához kövesse az Azure-fájlmegosztás csatlakoztatásának lépéseit.

Az Azure-fájlmegosztás Windows-kiszolgálón való csatlakoztatásához az SMB protokollnak meg kell nyitnia a 445-ös TCP-portot. Csatlakozás a 445-ös port blokkolásakor sikertelen lesz. A parancsmaggal ellenőrizheti, hogy a tűzfal vagy az internetszolgáltató blokkolja-e a Test-NetConnection 445-ös portot. Lásd: A 445-ös port le van tiltva.

CMS-adatbázis konfigurálása: Azure SQL

Ez a szakasz részletesen bemutatja, hogyan építhet ki Azure SQL-t az Azure Portal használatával. Útmutatást nyújt arra is, hogyan hozhatja létre a CMS-t és a naplózási adatbázist egy SAP BOBI-platformhoz és egy felhasználói fiókhoz az adatbázisok eléréséhez.

Az irányelvek csak akkor alkalmazhatók, ha SQL Database-t használ. Más adatbázisokra vonatkozó útmutatásért tekintse meg az SAP-t vagy az adatbázis-specifikus dokumentációt.

SQL Database-kiszolgáló létrehozása

Az SQL Database különböző üzembehelyezési lehetőségeket kínál: önálló adatbázist, rugalmas készletet és adatbázis-kiszolgálót. Az SAP BOBI-platformhoz két adatbázisra, CMS-re és naplózásra van szükség. Két önálló adatbázis létrehozása helyett létrehozhat egy SQL Database-kiszolgálót, amely képes kezelni az önálló adatbázisok és rugalmas készletek csoportját. SQL Database-kiszolgáló létrehozásához kövesse az alábbi lépéseket:

1. Keresse meg az SQL-telepítés kiválasztása lehetőséget .

2. Az SQL-adatbázisok alatt módosítsa az erőforrás típusát adatbázis-kiszolgálóra. Válassza a Létrehozás parancsot.

3. Az Alapok lapon töltse ki az SQL Database Server létrehozásához szükséges összes mezőt:

   1. A Projekt részletei csoportban válassza ki az Előfizetés és az Erőforrás csoportot.

   2. Adjon meg egy kiszolgálónevet. Írja be például az azussqlbodb értéket. A kiszolgáló nevének globálisan egyedinek kell lennie, de ellenkező esetben bármilyen nevet megadhat.

   3. Válassza ki a Helyet.

   4. Adja meg a kiszolgáló rendszergazdai bejelentkezését. Írja be például a boadmin értéket. Ezután adjon meg egy jelszót.

4. A Hálózatkezelés lapon módosítsa az Azure-szolgáltatások és -erőforrások hozzáférésének engedélyezése nemre a tűzfalszabályok alatt.

5. A További beállítások területen tartsa meg az alapértelmezett beállításokat.

6. Folytassa és hozza létre az SQL Database Servert.

A következő lépésben hozza létre a CMS-t és a naplózási adatbázisokat az SQL Database-kiszolgálón (azussqlbodb.database.windows.net).

A CMS és a naplózási adatbázis létrehozása

Az SQL Database-kiszolgáló kiépítése után keresse meg az azussqlbodb erőforrást. Ezután kövesse az alábbi lépéseket a CMS létrehozásához és az adatbázisok naplózásához.

1. Az azussqlbodb áttekintési oldalán válassza az Adatbázis létrehozása lehetőséget.

2. Az Alapismeretek lapon töltse ki az összes kötelező mezőt:

   1. Adja meg az adatbázis nevét. Írja be például a bocms vagy a boaudit értéket.

   2. A Compute + Storage beállításban válassza az Adatbázis konfigurálása lehetőséget. A méretezési eredmény alapján válassza ki a megfelelő modellt. A lehetőségekről további információt az Azure SQL Database méretezési modelljeiben talál.

3. A Hálózatkezelés lapon válassza ki a privát végpontot a kapcsolati módszerhez. A privát végpont a konfigurált virtuális hálózaton belüli SQL Database elérésére szolgál.

   1. Válassza a Privát végpont hozzáadása lehetőséget.

   2. Válassza ki az Előfizetési>erőforráscsoport>helyét.

   3. Adja meg a privát végpont nevét . Írja be például az azusbodb-pe értéket.

   4. A Cél alerőforrásban válassza az SqlServer lehetőséget.

   5. A Hálózatkezelés szakaszban válassza ki azt a virtuális hálózatot és alhálózatot, amelyen az SAP BusinessObjects BI-alkalmazás telepítve van.

   6. Fogadja el az alapértelmezett (igen) értéket a privát DNS-zónával való integrációhoz.

   7. Válassza ki a privát DNS-zónát a legördülő listából.

   8. Az OK gombra kattintva lépjen vissza az SQL-adatbázis létrehozása hálózatkezelés lapjára.

4. A További beállítások lapon módosítsa a Rendezés beállítást SQL_Latin1_General_CP850_BIN2 értékre.

5. Folytassa és hozza létre a CMS-adatbázist.

Hasonlóképpen létrehozhatja a naplózási adatbázist is. Írja be például a boaudit nevet.

ODBC-illesztőprogram letöltése és telepítése

Az SAP BOBI-alkalmazáskiszolgálóknak adatbázis-ügyfélre/illesztőprogramokra van szükségük a CMS eléréséhez vagy az adatbázis naplózásához. A Microsoft ODBC-illesztővel elérheti az SQL Database-en futó CMS-adatbázisokat és naplózhatja az adatbázisokat. Ez a szakasz bemutatja, hogyan tölthet le és állíthat be ODBC-illesztőt Windows rendszeren.

1. Az SQL Database-vel kompatibilis adatbázis-összekötőkről az SAP BusinessObjects BI-platform termék rendelkezésre állási mátrixának (PAM) termék rendelkezésre állási mátrixában (PAM) található CMS + auditadattár-támogatás című szakaszban tájékozódhat.
2. Töltse le az ODBC-illesztőprogram verzióját a hivatkozásról. Ebben a példában az ODBC-illesztő 13.1-et töltjük le.
3. Telepítse az ODBC-illesztőt az összes BI-kiszolgálón (azuswinboap1 és azuswinboap2).
4. Miután telepítette az illesztőprogramot az azuswinboap1-ben, nyissa meg a Windows Rendszergazda istrative Tools>ODBC Data Sources (64 bites) elindítását>.
5. Lépjen a System DSN lapra .
6. Válassza a Hozzáadás lehetőséget a CMS-adatbázishoz való kapcsolat létrehozásához.
7. Válassza az SQL Server ODBC-illesztő 13-at, majd a Befejezés lehetőséget.
8. Adja meg a CMS-adatbázis adatait az alábbiakhoz hasonlóan, majd válassza a Tovább elemet:
   • Név: A "CMS és a naplózási adatbázis létrehozása" szakaszban létrehozott adatbázis neve. Írja be például a bocms vagy a boaudit értéket.
   • Leírás: Az adatforrást leíró leírás. Írja be például a CMS-adatbázist vagy a naplózási adatbázist.
   • Kiszolgáló: Az "SQL Database-kiszolgáló létrehozása" szakaszban létrehozott kiszolgáló neve. Írja be például a azussqlbodb.database.windows.net.
9. Válassza az SQL Server-hitelesítést a felhasználó által megadott bejelentkezési azonosító és jelszó használatával az Azure SQL Serverhez való hitelesítés ellenőrzéséhez. Adja meg az SQL Database-kiszolgáló létrehozásakor létrehozott felhasználói hitelesítő adatokat. Írja be például a boadmin értéket. Válassza a Következő lehetőséget.
10. Módosítsa az alapértelmezett adatbázist bocms értékre, és tartsa meg a többit alapértelmezettként. Válassza a Következő lehetőséget.
11. Jelölje be az Erős titkosítás használata az adatokhoz jelölőnégyzetet, és tartsa meg minden mást alapértelmezettként. Select Finish.
12. Létrejött a CMS-adatbázis adatforrása. Most az Adatforrás tesztelése lehetőséget választva ellenőrizheti a CMS-adatbázishoz való kapcsolatot a BI-alkalmazásból. Sikeresnek kell lennie. Ha nem sikerül, hárítsa el a csatlakozási problémát.

Megjegyzés:

Az SQL Database az 1433-as porton kommunikál. Az 1433-as porton keresztüli kimenő forgalmat engedélyezni kell az SAP BOBI-alkalmazáskiszolgálókról.

Ismételje meg az előző lépéseket, és hozzon létre kapcsolatot az auditadatbázishoz az azuswinboap1 kiszolgálón. Hasonlóképpen telepítse és konfigurálja az ODBC-adatforrásokat (bocms és boaudit) az összes BI-alkalmazáskiszolgálón (azuswinboap2).

Kiszolgáló előkészítése

Kövesse az SAP legújabb útmutatóját, hogy előkészítse a kiszolgálókat a BI-platform telepítésére. A legfrissebb információkért tekintse meg az SAP Business Intelligence Platform telepítési útmutatójának "Előkészítés" szakaszát a Windowshoz.

Telepítés

Ha windowsos gazdagépre szeretné telepíteni a BI platformot, jelentkezzen be egy helyi rendszergazdai jogosultságokkal rendelkező felhasználóval.

Nyissa meg az SAP BusinsessObjects BI platform adathordozóját, és futtassa setup.exe.

Kövesse az SAP Business Intelligence Platform windowsos telepítési útmutatójában szereplő, az Ön verziójára vonatkozó utasításokat. Az SAP BOBI platform Windows rendszeren való telepítése során az alábbiakat érdemes megjegyezni:

• A Célmappa konfigurálása képernyőn adja meg azt a célmappát, ahová telepíteni szeretné a BI-platformot. Írja be például az F:\SAP BusinessObjects* nevet.

• A Termékregisztráció konfigurálása képernyőn használhat ideiglenes licenckulcsot az SAP BusinessObjects-megoldásokhoz az SAP Megjegyzésből 1288121, vagy létrehozhat egy licenckulcsot az SAP Service Marketplace-en.

• A Telepítés típusának kiválasztása képernyőn válassza a Teljes telepítés lehetőséget az első kiszolgálón (azuswinboap1). A másik kiszolgáló (azuswinboap2) esetében válassza az Egyéni / Kibontás lehetőséget, amely kibővíti a meglévő SAP BOBI-beállítást.

• Az Alapértelmezett vagy a Meglévő adatbázis kiválasztása képernyőn válassza ki a meglévő adatbázis konfigurálását, amely a CMS és a naplózási adatbázis kiválasztását kéri. Válassza ki a Microsoft SQL Servert az ODBC használatával a CMS-adatbázis típusához és az adatbázis típusának naplózásához.

  Ha nem szeretné konfigurálni a naplózást a telepítés során, a Nincs naplózási adatbázis lehetőséget is választhatja.

• Válassza ki a megfelelő beállításokat a Java webalkalmazás-kiszolgáló kiválasztása képernyőn az SAP BOBI-architektúra alapján. Ebben a példában az 1. lehetőséget választottuk, amely egy Tomcat-kiszolgálót telepít ugyanarra az SAP BOBI-platformra.

• Adja meg a CMS-adatbázis adatait a CMS-adattáradatbázis – SQL Server (ODBC) konfigurálásához. Az alábbi képen egy Windows-telepítés CMS-adatbázisadatainak példabemenete látható.

  

• (Nem kötelező) Adja meg a naplózási adatbázis adatait a Naplózási adatbázis konfigurálása – SQL Server (ODBC) mezőben. Az alábbi képen egy Windows-telepítés adatbázisadatainak naplózására szolgáló példabemenet látható.

  

• Kövesse az utasításokat, és adja meg a szükséges bemeneteket a telepítés befejezéséhez.

Többpéldányos üzembe helyezés esetén futtassa a telepítési telepítőt a második gazdagépen (azuswinboap2). A Telepítés típusának kiválasztása képernyőn válassza az Egyéni / Kibontás lehetőséget, amely kibővíti a meglévő SAP BOBI-beállítást. További információ: SAP blog SAP BusinessObjects Business Intelligence platform beállítása az Azure SQL Database-hez.

Fontos

Az SQL Server és az SQL Database adatbázismotor-verziószámai nem hasonlíthatók össze egymással. Ezek belső buildszámok ezekhez a különálló termékekhez. Az SQL Database adatbázismotorja ugyanazon a kódbázison alapul, mint az SQL Server adatbázismotorja. A legfontosabb, hogy az SQL Database adatbázismotorja mindig a legújabb SQL Database-motorbitekkel rendelkezik. Az SQL Database 12-es verziója újabb, mint az SQL Server 15-ös verziója.

Az SQL Database aktuális verziójának megkereséséhez beadhatja a Központi felügyeleti konzol (CMC) beállításait, vagy futtathatja a következő lekérdezést az sqlcmd vagy az SQL Server Management Studio használatával. Az SQL-verziók alapértelmezett kompatibilitáshoz való igazítását az adatbázis kompatibilitási szintje című cikkben találja.

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)

Telepítés utáni

Az SAP BOBI platform többpéldányos telepítése után további konfiguráció utáni lépéseket kell végrehajtani az alkalmazások magas rendelkezésre állásának támogatásához.

Fürtnév konfigurálása

Az SAP BOBI platform többpéldányos üzembe helyezésében több CMS-kiszolgálót szeretne együtt futtatni egy fürtben. A fürtök két vagy több CMS-kiszolgálóból állnak, és egy közös CMS-rendszeradatbázison dolgoznak együtt. Ha egy CMS-en futó csomópont meghibásodik, egy másik CMS-sel rendelkező csomópont továbbra is kiszolgálja a BI-platform kéréseit. Az SAP BOBI-platformon alapértelmezés szerint a fürt neve az első telepített CMS állomásnevét tükrözi.

A fürtnév Windows rendszeren való konfigurálásához kövesse az SAP Business Intelligence Platform Rendszergazda istrator útmutatójában található utasításokat. Miután konfigurálta a fürt nevét, kövesse az SAP Megjegyzés 1660440 az alapértelmezett rendszerbevitel beállításához a CMC vagy a BI Launchpad bejelentkezési oldalán.

A bemeneti és kimeneti fájltár helyének konfigurálása az Azure Premium Filesra

A Filestore azokra a lemezkönyvtárakra hivatkozik, amelyekben a tényleges SAP BusinessObjects BI-fájlok találhatók. Az SAP BOBI platform fájladattár-kiszolgálójának alapértelmezett helye a helyi telepítési könyvtárban található. Többpéldányos üzembe helyezés esetén fontos, hogy egy fájltárolót olyan megosztott tárolókon állítson be, mint az Azure Premium Files vagy az Azure NetApp Files, hogy az elérhető legyen az összes tárolási rétegbeli kiszolgálóról.

1. Ha nincs létrehozva, kövesse az előző, "Azure Premium Files kiépítése" című szakaszban leírt utasításokat az Azure Premium Files létrehozásához és csatlakoztatásához.

   Tipp.

   Attól függően, hogy a virtuális gép zonális vagy regionális módon van-e üzembe helyezve, meg kell határozni az Azure Premium Files (ZRS vagy LRS) tárolási redundanciájának kiválasztását.

2. Kövesse az SAP Note 2512660 a fájltár elérési útjának módosításához (bemenet és kimenet).

Tomcat-fürtözés: Munkamenet-replikáció

A Tomcat két vagy több alkalmazáskiszolgáló fürtözését támogatja munkamenet-replikációhoz és feladatátvételhez. Ha az SAP BOBI platform munkamenetei szerializálva vannak, a felhasználói munkamenetek zökkenőmentesen át tudnak működni a Tomcat egy másik példányán, még akkor is, ha egy alkalmazáskiszolgáló meghibásodik. Előfordulhat például, hogy egy felhasználó olyan webkiszolgálóhoz csatlakozik, amely meghiúsul, miközben a felhasználó egy SAP BI-alkalmazásban navigál egy mappahierarchiában. Egy megfelelően konfigurált fürtön a felhasználó anélkül folytathatja a mappahierarchiát, hogy a rendszer átirányítja őket egy bejelentkezési lapra.

Az SAP Note 2808640 a Tomcat-fürtözés konfigurálásának lépései csoportos küldéssel érhetők el. A csoportos küldés azonban nem támogatott az Azure-ban. Ahhoz, hogy egy Tomcat-fürt működjön az Azure-ban, a StaticMembershipInterceptort (SAP Megjegyzés 2764907) kell használnia. Tomcat-fürt Azure-beli beállításához tekintse meg az SAP BusinessObjects BI platform statikus tagságát használó Tomcat-fürtözést az SAP-blogon.

Sap BI-platform webes rétegének terheléselosztása

Az SAP BOBI többpéldányos üzemelő példányaiban a Java-webalkalmazás-kiszolgálók (webszint) két vagy több gazdagépen futnak. Ha a felhasználó terhelését egyenletesen szeretné elosztani a webkiszolgálók között, használhat terheléselosztót a végfelhasználók és a webkiszolgálók között. Az Azure Load Balancer vagy az Application Gateway használatával kezelheti a webalkalmazás-kiszolgálók felé irányuló forgalmat. Az ajánlatok magyarázata a következő szakaszokban található:

• A Load Balancer egy nagy teljesítményű, alacsony késésű, 4. rétegű (TCP, UDP) terheléselosztó, amely osztja el a forgalmat az egészséges virtuális gépek között. A terheléselosztó állapotadat-mintavétele figyeli az egyes virtuális gépek adott portjait, és csak az operatív virtuális gépek felé osztja el a forgalmat. Választhat nyilvános terheléselosztót vagy belső terheléselosztót attól függően, hogy az SAP BI platformot az internetről szeretné-e elérni. Zónaredundáns, amely magas rendelkezésre állást biztosít a rendelkezésre állási zónák között.

  Az alábbi ábrán lásd a "Belső terheléselosztó" szakaszt, ahol a webalkalmazás-kiszolgáló a 8080-es porton (alapértelmezett Tomcat HTTP-porton) fut, amelyet egy állapotadat-mintavétel figyel. A felhasználóktól érkező bejövő kérések a háttérkészlet webalkalmazás-kiszolgálóira (azuswinboap1 vagy azuswinboap2) lesznek átirányítva. A Load Balancer nem támogatja a TLS/SSL-leállítást, amelyet TLS/SSL-kiszervezésnek is neveznek. Ha a Load Balancer használatával osztja el a forgalmat a webkiszolgálók között, javasoljuk a Standard Load Balancer használatát.

  Megjegyzés:

  Ha a nyilvános IP-címmel nem rendelkező virtuális gépek a standard Load Balancer belső (nyilvános IP-cím nélküli) háttérkészletébe kerülnek, nem lesz kimenő internetkapcsolat, kivéve, ha további konfigurációt végeznek a nyilvános végpontokhoz való útválasztás engedélyezéséhez. A kimenő kapcsolatok elérésével kapcsolatos információkért tekintse meg az Azure Standard Load Balancert használó virtuális gépek nyilvános végpontkapcsolatát az SAP magas rendelkezésre állású forgatókönyveiben.

  

• Az Application Gateway szolgáltatásként egy alkalmazáskézbesítési vezérlőt biztosít, amellyel az alkalmazások egy vagy több webalkalmazás-kiszolgálóra irányítják a felhasználói forgalmat. Különböző 7. rétegbeli terheléselosztási képességeket kínál, például TLS/SSL-kiszervezést, webalkalmazási tűzfalat és cookie-alapú munkamenet-affinitást az alkalmazásokhoz.

  Egy SAP BI-platformon az Application Gateway átirányítja az alkalmazás webes forgalmát egy háttérkészlet megadott erőforrásaihoz. Ebben az esetben vagy azuswinboap1 vagy azuswinboap2. Hozzárendelhet egy figyelőt a porthoz, szabályokat hozhat létre, és erőforrásokat adhat hozzá egy háttérkészlethez. Az alábbi ábrán a privát előtér-IP-címmel (10.31.3.25) rendelkező Application Gateway belépési pontként működik a felhasználók számára, kezeli a bejövő TLS/SSL -kapcsolatokat (HTTPS - TCP/443), visszafejti a TLS/SSL-t, és átadja a kérést (HTTP - TCP/8080) a háttérkészlet kiszolgálóinak. A beépített TLS/SSL-leállítási funkcióval csak egy TLS/SSL-tanúsítványt kell fenntartania az application gatewayen, ami leegyszerűsíti a műveleteket.

  

  Az Application Gateway SAP BOBI-webkiszolgálókhoz való konfigurálásához tekintse meg az SAP BOBI-webkiszolgálók terheléselosztását az Application Gateway használatával az SAP-blogon.

  Megjegyzés:

  Az Application Gateway használatával terheléseloszthatja a webkiszolgáló felé irányuló forgalmat, mivel olyan funkciókat biztosít, mint az SSL-kiszervezés, a központosított SSL-kezelés a kiszolgáló titkosítási és visszafejtési terhelésének csökkentéséhez, ciklikus időszeleteléses algoritmusok a forgalom elosztásához, a webalkalmazási tűzfal képességei és a magas rendelkezésre állás.

AZ SAP BusinessObjects BI platform megbízhatósága az Azure-ban

Az SAP BusinessObjects BI platform különböző szinteket tartalmaz, amelyek adott tevékenységekhez és műveletekhez vannak optimalizálva. Ha egy összetevő bármely szinten elérhetetlenné válik, az SAP BOBI-alkalmazás elérhetetlenné válik, vagy az alkalmazás bizonyos funkciói nem fognak működni. Meg kell győződnie arról, hogy az egyes szintek úgy vannak kialakítva, hogy megbízhatóak legyenek, hogy az alkalmazás üzleti fennakadások nélkül működjön.

Ez az útmutató bemutatja, hogy az Azure-ban natív funkciók és az SAP BOBI platformkonfiguráció együttesen hogyan javítják az SAP-üzemelő példányok rendelkezésre állását. Ez a szakasz az SAP BOBI platform megbízhatóságának alábbi lehetőségeire összpontosít az Azure-ban:

• Biztonsági mentés és visszaállítás: Ez a folyamat rendszeres adat- és alkalmazáspéldányokat hoz létre külön helyekre. Ha az eredeti adatok vagy alkalmazások elvesznek vagy megsérülnek, a másolatok felhasználhatók az előző állapot visszaállítására vagy helyreállítására.
• Magas rendelkezésre állás: A magas rendelkezésre állású platform legalább két azure-régióban található mindenből, hogy az alkalmazás működőképes maradjon, ha az egyik kiszolgáló elérhetetlenné válik.
• Vészhelyreállítás (DR): Ez a folyamat visszaállítja az alkalmazás funkcióit, ha katasztrofális veszteségeket okoz. Előfordulhat például, hogy egy teljes Azure-régió elérhetetlenné válik egy természeti katasztrófa miatt.

A megoldás megvalósítása az Azure-ban beállított rendszer jellegétől függően változik. Az üzleti követelményeknek megfelelően testre kell szabnia a biztonsági mentési és visszaállítási, magas rendelkezésre állási és DR-megoldásokat.

Backup and restore

A biztonsági mentés és a visszaállítás az adatok és alkalmazások rendszeres másolatának külön helyre történő létrehozásának folyamata, hogy visszaállíthatók vagy visszaállíthatók egy korábbi állapotba, ha az eredeti adatok vagy alkalmazások elvesznek vagy megsérülnek. Emellett minden üzleti dr. stratégia alapvető összetevője. Ezek a biztonsági másolatok lehetővé teszik az alkalmazás és az adatbázis visszaállítását a konfigurált megőrzési időszakon belül egy adott időpontra.

Ha átfogó biztonsági mentési és visszaállítási stratégiát szeretne kidolgozni egy SAP BOBI-platformhoz, azonosítsa azokat az összetevőket, amelyek a rendszer állásidejéhez vagy az alkalmazás leállásához vezetnek. Az SAP BOBI-platformon az alábbi összetevők biztonsági mentése létfontosságú az alkalmazás védelme érdekében:

• SAP BOBI telepítési könyvtár (felügyelt prémium lemezek)
• Filestore (Azure Premium Files vagy Azure NetApp Files elosztott telepítéshez)
• CMS- és naplózási adatbázis (SQL Database, Azure Database for MySQL vagy azure-beli virtuális gépeken lévő adatbázis)

Az alábbi szakasz bemutatja, hogyan valósíthat meg biztonsági mentési és visszaállítási stratégiát az SAP BOBI-platform egyes összetevőihez.

SAP BOBI telepítési címtár biztonsági mentése és visszaállítása

Az Azure-ban a virtuális gépek és a csatlakoztatott lemezek biztonsági mentésének legegyszerűbb módja az Azure Backup használata. Független és izolált biztonsági mentést biztosít, amely védelmet nyújt a virtuális gépeken lévő adatok nem szándékos megsemmisítése ellen. A biztonsági másolatok egy helyreállítási tárban vannak tárolva, a helyreállítási pontok beépített kezelésével. A konfiguráció és a skálázás egyszerű. A biztonsági mentések optimalizálva vannak, és szükség esetén könnyen visszaállíthatók.

A biztonsági mentési folyamat részeként pillanatkép készül. Az adatok a Recovery Services-tárolóba kerülnek, és nincs hatással az éles számítási feladatokra. A pillanatkép a Pillanatkép konzisztenciájában leírtaknak megfelelően eltérő konzisztenciaszintet biztosít. A biztonsági mentés az Azure-beli virtuális gépek biztonsági mentési megoldásán kívül az Azure-beli virtuális gépek biztonsági mentési megoldásával is támogatja a felügyelt lemezek biztonsági mentését. Ez akkor hasznos, ha naponta egyszer kell konzisztens biztonsági másolatot készítenie a virtuális gépekről, és gyakrabban kell biztonsági másolatot készítenie az operációsrendszer-lemezekről vagy egy adott adatlemezről, amelyek összeomlási konzisztensek. További információ: Tudnivalók az Azure-beli virtuális gépek biztonsági mentéséről, az Azure-lemez biztonsági mentéséről és a gyakori kérdésekről: Azure-beli virtuális gépek biztonsági mentése.

A filestore biztonsági mentése és visszaállítása

Az üzembe helyezés alapján az SAP BOBI-platform fájltárolója az Azure NetApp Filesban vagy az Azure Filesban lehet. A következő beállítások közül választhat a biztonsági mentéshez és a visszaállításhoz a fájltárhoz használt tároló alapján:

• Azure NetApp Files: Az Azure NetApp Fileshoz igény szerinti pillanatképeket hozhat létre, és pillanatkép-szabályzatok használatával ütemezhet automatikus pillanatképeket. A pillanatkép-másolatok az Azure NetApp Files-kötet időponthoz kötött másolatát biztosítják. További információ: Pillanatképek kezelése az Azure NetApp Files használatával.
• Azure Files: Az Azure Files biztonsági mentése a Backup natív példányával van integrálva, amely központosítja a biztonsági mentési és visszaállítási funkciót a virtuális gépek biztonsági mentésével együtt, és leegyszerűsíti a műveleti munkát. További információ: Azure-fájlmegosztás biztonsági mentése és gyakori kérdések: Az Azure Files biztonsági mentése.

Ha külön NFS-kiszolgálót hozott létre, győződjön meg arról, hogy ugyanahhoz a biztonsági mentési és visszaállítási stratégiához implementálja a biztonsági mentési és visszaállítási stratégiát.

A CMS és a naplózási adatbázis biztonsági mentése és visszaállítása

Windows rendszerű virtuális gépeken futó SAP BOBI-platform esetén a CMS és a naplózási adatbázis az Azure-beli SAP BOBI-platform tervezési és implementálási útmutatójának támogatási mátrixában leírtak szerint bármelyik támogatott adatbázison futtatható. Ezért fontos, hogy a CMS-hez és az adattároláshoz használt adatbázis alapján alkalmazza a biztonsági mentési és visszaállítási stratégiát.

• Az SQL Database az SQL Server technológiáját használja a teljes biztonsági mentések hetente történő létrehozásához, a különbségi biztonsági mentések 12–24 óránként, a tranzakciónaplók biztonsági mentése pedig 5–10 percenként. A tranzakciónaplók biztonsági mentésének gyakorisága a számítási méreten és az adatbázis-tevékenység mértékén alapul.

  A felhasználók választhatnak egy lehetőséget a biztonsági mentési tár redundanciáinak konfigurálására az LRS, a ZRS vagy a GRS-blobok között. A tárolási redundancia mechanizmusai az adatok több példányát tárolják, hogy megvédjék őket a tervezett és nem tervezett eseményektől, beleértve az átmeneti hardverhibákat, a hálózati vagy áramkimaradásokat vagy a súlyos természeti katasztrófákat. Az SQL Database alapértelmezés szerint a párosított régióba replikált GRS-blobokban tárolja a biztonsági mentést. Az üzleti követelmény alapján LRS- vagy ZRS-blobokra módosítható. Az SQL Database biztonsági mentési ütemezéséről, megőrzéséről és tárolási felhasználásáról további információt az Automatizált biztonsági mentések: Azure SQL Database és felügyelt Azure SQL-példányok című témakörben talál.

• Az Azure Database for MySQL automatikusan létrehoz kiszolgálói biztonsági mentéseket és tárolókat a felhasználó által konfigurált LRS-ben vagy GRS-ben. Az Azure Database for MySQL automatikusan biztonsági másolatokat készít az adatfájlokról és a tranzakciónaplóról. A támogatott maximális tárterület méretétől függően teljes és különbözeti biztonsági mentéseket (legfeljebb 4 TB-os tárolókiszolgálókat) vagy pillanatkép-biztonsági mentéseket (legfeljebb 16 TB-os maximális tárolókiszolgálókat) igényel. Ezek a biztonsági másolatok lehetővé teszik, hogy a konfigurált biztonsági mentési megőrzési időszakon belül bármikor visszaállítsa a kiszolgálót. Az alapértelmezett biztonsági mentési megőrzési idő 7 nap, amelyet igény szerint legfeljebb 35 napig konfigurálhat. Az összes biztonsági mentés AES 256 bites titkosítással van titkosítva. Ezek a biztonsági mentési fájlok nem jelennek meg a felhasználók számára, és nem exportálhatók. Ezek a biztonsági másolatok csak az Azure Database for MySQL visszaállítási műveleteihez használhatók. A mysqldump használatával adatbázist másolhat. További információt a Biztonsági mentés és visszaállítás az Azure Database for MySQL-ben című cikkben talál.

• Az Azure-beli virtuális gépekre telepített adatbázisok esetében használhatja a szabványos biztonsági mentési eszközöket vagy a biztonsági mentést a támogatott adatbázisokhoz. Ha az Azure-szolgáltatások és -eszközök nem felelnek meg a követelményeknek, használhat olyan támogatott külső biztonsági mentési eszközöket is, amelyek ügynököt biztosítanak az SAP BOBI-platform összes összetevőjének biztonsági mentéséhez és helyreállításához.

Magas szintű rendelkezésre állás

A magas rendelkezésre állás olyan technológiákra utal, amelyek minimalizálhatják az informatikai fennakadásokat azáltal, hogy redundáns, hibatűrő vagy feladatátvétel által védett összetevőkkel biztosítják az alkalmazások vagy szolgáltatások üzletmenet-folytonosságát ugyanazon adatközponton belül. Esetünkben az adatközpontok egy Azure-régión belül találhatók. Az SAP magas rendelkezésre állású architektúrája és forgatókönyvei című cikk bemutatja az Azure-ban az SAP-alkalmazásokhoz kínált különböző magas rendelkezésre állású technikákat és javaslatokat, amelyek kiegészítik az ebben a szakaszban található utasításokat.

Az SAP BOBI platform méretezési eredményei alapján meg kell terveznie a tájolást, és meg kell határoznia a BI-összetevők azure-beli virtuális gépek és alhálózatok közötti elosztását. Az elosztott architektúrában a redundancia szintje az üzletileg szükséges helyreállítási időkorláttól (RTO) és a helyreállítási pont célkitűzésétől (RPO) függ. Az SAP BOBI platform különböző szinteket tartalmaz, és az egyes szintek összetevőit a redundancia elérése érdekében kell megtervezni. Ha az egyik összetevő meghibásodik, az SAP BOBI-alkalmazásnak nincs semmi fennakadása. Például:

• Redundáns alkalmazáskiszolgálók, például BI-alkalmazáskiszolgálók és webkiszolgálók
• Egyedi összetevők, például CMS-adatbázis, filestore és terheléselosztó

Az alábbi szakasz azt ismerteti, hogyan lehet magas rendelkezésre állást elérni az SAP BOBI-platform egyes összetevőin.

Az alkalmazáskiszolgálók magas rendelkezésre állása

A BI- és webalkalmazás-kiszolgálóknak nincs szükségük egy adott magas rendelkezésre állású megoldásra, függetlenül attól, hogy külön vagy együtt vannak telepítve. A magas rendelkezésre állást redundanciával érheti el, azaz több BI-példány és webkiszolgáló konfigurálásával különböző Azure-beli virtuális gépeken. A virtuális gépeket rugalmas méretezési csoportokban, rendelkezésre állási csoportokban vagy rendelkezésre állási zónákban helyezheti üzembe az üzleti szempontból szükséges RTO alapján. A rendelkezésre állási zónák közötti üzembe helyezéshez győződjön meg arról, hogy az SAP BOBI platform összes többi összetevője zónaredundánsként is használható.

Jelenleg nem minden Azure-régió kínál rendelkezésre állási zónákat, ezért a régió alapján kell bevezetnie az üzembe helyezési stratégiát. A zónákat kínáló Azure-régiók az Azure rendelkezésre állási zónáiban jelennek meg.

Fontos

• Az Azure rendelkezésre állási zónáinak és az Azure rendelkezésre állási csoportjainak fogalmai kölcsönösen kizárják egymást. Egy pár vagy több virtuális gép üzembe helyezhető egy adott rendelkezésre állási zónában vagy rendelkezésre állási csoportban, de mindkettőt nem teheti meg.
• Ha rendelkezésre állási zónák közötti üzembe helyezést tervez, javasoljuk, hogy rugalmas méretezési csoportot használjon az FD=1 használatával a standard rendelkezésre állási zónák üzembe helyezéséhez.

Magas rendelkezésre állás a CMS-adatbázishoz

Ha azure-adatbázist használ a CMS-hez és a naplózási adatbázishoz, alapértelmezés szerint helyileg redundáns magas rendelkezésre állású keretrendszert biztosít. Válassza ki a régióval és szolgáltatással járó magas rendelkezésre állási, redundancia- és rugalmassági képességeket anélkül, hogy további összetevőket kellene konfigurálnia. Ha az SAP BOBI-platform üzembehelyezési stratégiája egy rendelkezésre állási zónán keresztül van, győződjön meg arról, hogy zónaredundanciát ér el a CMS és a naplózási adatbázis számára. Az Azure-ban támogatott adatbázis-ajánlatok magas rendelkezésre állásáról további információt az Azure SQL Database magas rendelkezésre állása és az Azure Database for MySQL magas rendelkezésre állása című témakörben talál.

A CMS-adatbázisok egyéb adatbázis-felügyeleti rendszer (DBMS) üzembe helyezéséhez tekintse meg az SAP-számítási feladatokHOZ készült DBMS-telepítési útmutatókat, és tekintse meg a különböző DBMS-telepítésekkel és a magas rendelkezésre állás elérésének megközelítésével kapcsolatos megállapításokat.

A filestore magas rendelkezésre állása

A Filestore azokra a lemezkönyvtárakra hivatkozik, amelyekben a rendszer olyan tartalmakat tárol, mint a jelentések, a világegyetemek és a kapcsolatok. A rendszer a rendszer összes alkalmazáskiszolgálóján megosztja. Ezért győződjön meg arról, hogy magas rendelkezésre állású, más SAP BOBI platformösszetevők mellett.

Windowson futó SAP BOBI-platform esetén választhatja az Azure Premium Filest vagy az Azure NetApp Filest a filestore-hoz, amely magas rendelkezésre állású és rendkívül tartós jellegű. Az Azure Premium Files támogatja a ZRS-t, amely hasznos lehet egy SAP BOBI-platform zónák közötti üzembe helyezéséhez. További információkért tekintse meg az Azure Files Redundancia szakaszát.

Mivel a fájlmegosztási szolgáltatás nem minden régióban érhető el, a naprakész információk kereséséhez győződjön meg arról, hogy a régiónként elérhető termékek listája jelenik meg. Ha a szolgáltatás nem érhető el a régióban, létrehozhat egy NFS-kiszolgálót, amelyről megoszthatja a fájlrendszert egy SAP BOBI-alkalmazással. De figyelembe kell vennie annak magas rendelkezésre állását is.

Magas rendelkezésre állás a terheléselosztóhoz

A forgalom webkiszolgálók közötti elosztásához használhatja a Load Balancert vagy az Application Gatewayt. A terheléselosztók redundanciája az üzembe helyezéshez választott termékváltozat alapján érhető el:

• Load Balancer: A redundancia a Standard Load Balancer előtér zónaredundánsként való konfigurálásával érhető el. További információ: Standard Load Balancer és rendelkezésre állási zónák.
• Application Gateway: A magas rendelkezésre állás az üzembe helyezés során kiválasztott szint típusától függően érhető el:
  • Az 1-es verziójú termékváltozat két vagy több példány üzembe helyezésekor támogatja a magas rendelkezésre állású forgatókönyveket. Az Azure ezeket a példányokat frissítési és tartalék tartományok között osztja el, hogy a példányok ne legyenek egyszerre sikertelenek. Ezzel a termékváltozattal redundancia érhető el a zónán belül.
  • A v2 termékváltozat automatikusan biztosítja, hogy az új példányok el legyenek oszlva a tartalék tartományok között, és frissítse a tartományokat. Ha zónaredundanciát választ, a legújabb példányok a rendelkezésre állási zónák között is el vannak osztva, hogy az zonális meghibásodási rugalmasságot nyújtson. További információ: Automatikus skálázás és zónaredundáns Application Gateway v2.

Referencia magas rendelkezésre állású architektúra az SAP BusinessObjects BI platformhoz

Az alábbi referenciaarchitektúra egy SAP BOBI-platform windowsos kiszolgálón futó rendelkezésre állási zónák közötti beállítását ismerteti. Az architektúra bemutatja a különböző Azure-szolgáltatások használatát, például az Application Gatewayt, az Azure Premium Filest (filestore) és az SQL Database-t (CMS és naplózási adatbázist). Az SAP BOBI platform beépített zónaredundanciát kínál, amely csökkenti a különböző magas rendelkezésre állású megoldások kezelésének összetettségét.

Az alábbi ábrán a bejövő forgalom (HTTPS - TCP/443) terheléselosztása az Application Gateway v2 termékváltozatával történik, amely több rendelkezésre állási zónára is kiterjed. Az Application Gateway elosztja a felhasználói kérést a webkiszolgálók között, amelyek a rendelkezésre állási zónák között vannak elosztva. A webkiszolgáló továbbítja a kérelmet a különálló virtuális gépeken üzembe helyezett felügyeleti és feldolgozási kiszolgálópéldányoknak a rendelkezésre állási zónák között. A ZRS-sel rendelkező Prémium Azure-fájlok felügyeleti és tárolási szintű virtuális gépekhez való privát kapcsolaton keresztül vannak csatolva, hogy elérhessék a tartalmakat, például a jelentéseket, az univerzumot és a kapcsolatokat. Az alkalmazás hozzáfér a CMS-hez és az SQL Database zónaredundáns példányán futó naplózási adatbázishoz, amely egy Azure-régió több fizikai helyére replikálja az adatbázisokat.

Az előző architektúra bemutatja, hogyan végezhető el az SAP BOBI üzembe helyezése az Azure-ban. Ez azonban nem terjed ki az Azure-beli SAP BOBI-platform összes lehetséges konfigurációs lehetőségére. Az üzembe helyezést az üzleti követelményeknek megfelelően testre szabhatja, ha különböző termékeket vagy szolgáltatásokat választ olyan összetevőkhöz, mint a Load Balancer, a Fájladattár-kiszolgáló és a DBMS.

Ha a rendelkezésre állási zónák nem érhetők el a kiválasztott régióban, azure-beli virtuális gépeket helyezhet üzembe rendelkezésre állási csoportokban. Az Azure gondoskodik arról, hogy a rendelkezésre állási csoportban található virtuális gépek több fizikai kiszolgálón, számítási állványon, tárolóegységen és hálózati kapcsolón futnak. Hardver- vagy szoftverhiba esetén a rendszer csak a virtuális gépek egy részhalmazát érinti, és a teljes megoldás működőképes marad.

Vészhelyreállítás

Ez a szakasz az SAP BOBI-platform DR-védelemmel kapcsolatos stratégiáját ismerteti. Kiegészíti az SAP-dokumentum vészhelyreállítását, amely egy általános SAP DR-megközelítés elsődleges erőforrásait jelöli. Az SAP BOBI platformról lásd az SAP Megjegyzés 2056228, amely a dr. környezet biztonságos implementálásának alábbi módszereit ismerteti:

• Az életciklus-felügyelet vagy összevonás teljes vagy szelektív használatával előléptetheti vagy terjesztheti a tartalmat az elsődleges rendszerből.
• Rendszeresen másolja át a CMS és az FRS tartalmát.

Ebben az útmutatóban a dr. környezet implementálásának második lehetőségéről lesz szó. Nem fogjuk lefedni a DR összes lehetséges konfigurációs beállításának teljes listáját. Bemutatunk egy megoldást, amely natív Azure-szolgáltatásokat és SAP BOBI-platformkonfigurációt tartalmaz.

Fontos

• Az SAP BOBI platform egyes összetevőinek rendelkezésre állását a másodlagos régióban kell figyelembe venni. A teljes DR-stratégiát alaposan tesztelni kell.
• Ha az SAP BI-platform rugalmas méretezési csoporttal van konfigurálva az FD=1 használatával, akkor a PowerShell használatával kell beállítania az Azure Site Recoveryt vészhelyreállításhoz. Jelenleg ez az egyetlen elérhető módszer a méretezési csoportban üzembe helyezett virtuális gépek vészhelyreállításának konfigurálására.

Referencia DR-architektúra egy SAP BusinessObjects BI-platformhoz

Ez a referenciaarchitektúra az SAP BOBI platform többpéldányos üzembe helyezését futtatja redundáns alkalmazáskiszolgálókkal. Dr esetén az SAP BOBI-platform összes összetevőjét egy másodlagos régióba kell átvennie. Az alábbi ábrán az Azure Premium Files lesz a fájltár, az SQL Database a CMS és a naplózási adattár, az Application Gateway pedig a forgalom terheléselosztására szolgál. Az egyes összetevők DR-védelemmel kapcsolatos stratégiája eltérő, amelyet a következő szakaszban ismertetünk.

Load Balancer

A Load Balancer egy SAP BOBI-platform webalkalmazás-kiszolgálói közötti forgalom elosztására szolgál. Az Azure-ban a Load Balancer vagy az Application Gateway használatával terheléseloszthatja a webkiszolgálók közötti forgalmat. A terheléselosztó-szolgáltatások dr. verziójának eléréséhez egy másik terheléselosztót vagy application gatewayt kell implementálnia egy másodlagos régióban. Ha ugyanazt az URL-címet szeretné megőrizni a dr. feladatátvétel után, módosítsa a bejegyzést a DNS-ben, és mutasson a másodlagos régión futó terheléselosztási szolgáltatásra.

Web- és BI-alkalmazáskiszolgálót futtató virtuális gépek

Az Azure Site Recovery web- és BI-alkalmazáskiszolgálókat futtató virtuális gépek replikálására használható a másodlagos régióban. Replikálja a kiszolgálókat és az összes csatlakoztatott felügyelt lemezt a másodlagos régióba, így vészhelyzetek és kimaradások esetén egyszerűen átadhatja a replikált környezetet, és folytathatja a munkát. Ha el szeretné kezdeni az összes SAP-alkalmazás virtuális gépének replikálását az Azure DR-adatközpontba, kövesse a virtuális gép Azure-ba való replikálásával kapcsolatos útmutatást.

Filestore

A Filestore egy olyan lemezkönyvtár, amelyben a tényleges fájlok, például a jelentések és a BI-dokumentumok vannak tárolva. Fontos, hogy a fájltárban lévő összes fájl szinkronban legyen a DR régióval. A Windows rendszeren futó SAP BOBI-platformhoz használt fájlmegosztási szolgáltatás típusától függően a tartalom szinkronizálásához el kell fogadni a szükséges DR-stratégiát. Például:

• Az Azure Premium Files csak az LRS-t és a ZRS-t támogatja. Az Azure Premium Files DR-stratégiához az AzCopy vagy az Azure PowerShell használatával másolhatja a fájlokat egy másik régióban lévő tárfiókba. További információ: Vészhelyreállítás és tárfiók feladatátvétele.

• Az Azure NetApp Files NFS- és SMB-köteteket biztosít, így bármilyen fájlalapú másolási eszköz használható az adatok Azure-régiók közötti replikálására. Az Azure NetApp Files egy másik régióban való másolásáról további információt az Azure NetApp Filesról szóló gyakori kérdésekben talál.

  Az Azure NetApp Files régiók közötti replikációja jelenleg előzetes verzióban érhető el, amely a NetApp SnapMirror technológiát használja. Ezzel a technológiával a rendszer csak a módosított blokkokat küldi el a hálózaton tömörített, hatékony formátumban. Ez a saját fejlesztésű technológia minimálisra csökkenti a régiók közötti replikáláshoz szükséges adatokat, ami az adatátviteli költségeket takarítja meg. A replikációs időt is lerövidíti, így kisebb RPO-t érhet el. További információ: Régiók közötti replikáció használatának követelményei és szempontjai.

CMS-adatbázis

A DR régió CMS- és naplózási adatbázisának az elsődleges régióban futó adatbázisok másolatának kell lennie. Az adatbázis típusa alapján fontos, hogy az adatbázist egy dr. régióba másolja az üzleti szempontból szükséges RTO és RPO alapján. Ez a szakasz a Windows rendszeren futó SAP BOBI-alkalmazásokhoz támogatott azure-beli adatbázis-megoldásokhoz különböző lehetőségeket ismertet.

Azure SQL Database

Sql Database DR-stratégia esetén két lehetőség áll rendelkezésre az adatbázis másodlagos régióba másolására. Mindkét helyreállítási lehetőség különböző RTO- és RPO-szinteket kínál. Az egyes helyreállítási lehetőségek RTO-jával és RPO-jával kapcsolatos további információkért lásd : Adatbázis helyreállítása meglévő kiszolgálóra.

1. lehetőség: Georedundáns adatbázis biztonsági mentésének visszaállítása

Az SQL Database alapértelmezés szerint egy párosított régióba replikált GRS-blobokban tárolja az adatokat. SQL-adatbázisok esetében a biztonsági mentési tár redundanciái konfigurálhatók a CMS létrehozásakor és az adatbázis naplózásakor, vagy frissíthetők egy meglévő adatbázis esetében. A meglévő adatbázis módosításai csak a jövőbeli biztonsági mentésekre vonatkoznak. A legutóbbi georeplikált biztonsági másolatokból bármely Azure-régióban visszaállíthatja az adatbázist bármely SQL-adatbázisban. A georeduktúra georeplikált biztonsági mentést használ forrásként. Késés van a biztonsági mentés készítése és a georeplikálás között egy másik régióban lévő Azure-blobba. Ennek eredményeképpen a visszaállított adatbázis akár egy órával is elmaradhat az eredeti adatbázistól.

Fontos

A georedundáns visszaállítás a georedundáns biztonsági mentési tárral konfigurált SQL-adatbázisokhoz érhető el.

2. lehetőség: Georeplikációs vagy automatikus feladatátvételi csoport

A georeplikációs funkció egy SQL Database-szolgáltatás, amellyel olvasható másodlagos adatbázisokat hozhat létre egy ugyanazon vagy különböző régióban lévő kiszolgálón. Ha a georeplikáció engedélyezve van a CMS-hez és a naplózási adatbázishoz, az alkalmazás feladatátvételt kezdeményezhet egy másik Azure-régióban lévő másodlagos adatbázisba. A georeplikáció engedélyezve van az egyes adatbázisok esetében, de ha több adatbázis (CMS és audit) transzparens és koordinált feladatátvételét szeretné engedélyezni egy SAP BOBI-alkalmazáshoz, célszerű automatikus feladatátvételi csoportot használni. A csoport szemantikáját az aktív georeplikációs adatokon felül biztosítja, ami azt jelenti, hogy a teljes SQL Server (minden adatbázis) replikálva lesz egy másik régióba az egyes adatbázisok helyett. Ellenőrizze a georeplikációs és feladatátvételi csoportokat összehasonlító képességtáblát.

Az automatikus feladatátvételi csoportok olvasási/írási és írásvédett figyelővégpontokat biztosítanak, amelyek a feladatátvétel során változatlanok maradnak. Az olvasási/írási végpont figyelőként tartható fenn a CMS és a naplózási adatbázis ODBC-kapcsolati bejegyzésében. Így akár manuális, akár automatikus feladatátvételi aktiválást használ, a feladatátvétel a csoport összes másodlagos adatbázisát elsődlegesre váltja. Az adatbázis feladatátvétele után a DNS-rekord automatikusan frissül, hogy átirányítsa a végpontokat az új régióba. Az alkalmazás automatikusan csatlakozik a CMS-adatbázishoz, mivel az írási/olvasási végpont figyelőként van fenntartva az ODBC-kapcsolatban.

Az alábbi képen az USA 2. keleti régiójában futó SQL Server (azussqlbodb) automatikus feladatátvételi csoportja az USA 2. keleti régiójába replikálódik. Az olvasási/írási figyelő végpontja figyelőként van fenntartva a Windowson futó BI-alkalmazáskiszolgáló ODBC-kapcsolatában. A feladatátvétel után a végpont változatlan marad. A BI-alkalmazásnak a másodlagos régióban lévő SQL-adatbázishoz való csatlakoztatásához nincs szükség manuális beavatkozásra.

Ez a beállítás alacsonyabb RTO-t és RPO-t biztosít, mint az 1. lehetőség. További információ erről a beállításról: Automatikus feladatátvételi csoportok használata több adatbázis transzparens és koordinált feladatátvételének engedélyezéséhez.

Azure Database for MySQL

Az Azure Database for MySQL lehetővé teszi az adatbázisok helyreállítását vészhelyzet esetén. Válassza ki a vállalkozása számára megfelelő lehetőséget:

• A régiók közötti olvasási replikák engedélyezése az üzletmenet folytonosságának és a dr.dr. tervezésének javítása érdekében. Egy forráskiszolgálóról legfeljebb öt replikát replikálhat. Az olvasási replikák aszinkron módon frissülnek az Azure Database for MySQL bináris naplóreplikációs technológiájának használatával. A replikák olyan új kiszolgálók, amelyeket a szokásos Azure Database for MySQL-kiszolgálókhoz hasonlóan kezel. Az olvasási replikákról, az elérhető régiókról, a korlátozásokról és a feladatátvétel módjáról további információt az Azure Database for MySQL replikáinak olvasása című témakörben talál.

• Használja az Azure Database for MySQL georedundáns biztonsági másolatok használatával visszaállítja a kiszolgálót. Ezek a biztonsági másolatok akkor is elérhetők, ha a kiszolgálót futtató régió offline állapotban van. Ezekből a biztonsági másolatokból bármely más régióba visszaállíthatja a biztonsági mentéseket, és visszaállíthatja a kiszolgálót az internetre.

  Fontos

  A georedundáns visszaállítás csak akkor lehetséges, ha a kiszolgálót georedundáns biztonsági mentési tárhellyel állította ki. A biztonsági mentési redundancia beállításainak módosítása a kiszolgáló létrehozása után nem támogatott. További információ: Backup redundancia.

Az alábbi táblázat az ebben a példában használt egyes szintekre vonatkozó DR-javaslatokat sorolja fel.

SAP BOBI platformszintek	Recommendation
Azure-alkalmazás Átjáró vagy Azure Load Balancer	Az Application Gateway párhuzamos beállítása egy másodlagos régióban
Webalkalmazás-kiszolgálók	Replikálás az Azure Site Recovery használatával
BI-alkalmazáskiszolgálók	Replikálás a Site Recovery használatával
Azure Premium Files	AzCopy vagy Azure PowerShell
Azure NetApp Files	Fájlalapú másolási eszköz, amely egy másodlagos régióba vagy az Azure NetApp Files régiók közötti replikációs előzetes verziójába replikálja az adatokat
Azure SQL Database	Georeplikációs/automatikus feladatátvételi csoportok vagy georeduktúra-visszaállítás
Azure Database for MySQL	Régiók közötti olvasási replikák vagy a georedundáns biztonsági másolatok biztonsági mentésének visszaállítása

Következő lépések

• Vészhelyreállítás beállítása többrétegű SAP-alkalmazások üzembe helyezéséhez
• Azure-beli virtuális gépek tervezése és implementálása az SAP-hoz
• Azure-beli virtuális gépek üzembe helyezése az SAP-hoz
• Azure Virtual Machines DBMS üzembe helyezése AZ SAP-hoz