Hálózati topológia és kapcsolat SAP-migráláshoz

Ez a cikk az Azure célzóna-tervezési területen a hálózati topológia és a kapcsolat szempontjából meghatározott szempontokra és javaslatokra épül. A jelen cikk útmutatása a Microsoft Azure- és SAP-környezetek hálózatkezelésének és kapcsolódásának főbb tervezési szempontjait és ajánlott eljárásait ismerteti. Mivel az SAP egy kritikus fontosságú platform, a tervezésnek az Azure-beli célzónák tervezési területeire vonatkozó útmutatást is követnie kell.

AZ IP-címzés megtervezése

Az Azure-beli IP-címzési terv létfontosságú annak biztosításához, hogy:

• Az IP-címtér nem fedi át a helyszíni helyeket és az Azure-régiókat.
• A virtuális hálózat a megfelelő címteret tartalmazza.
• Az alhálózati konfigurációs tervek előre történnek.

Az alábbi architektúradiagram egy Azure-beli célzónagyorsítón az SAP hálózatkezelési szempontjait mutatja be:

Tervezési szempontok az SAP-implementációhoz:

Alhálózatokat szentelhet és delegálhat bizonyos szolgáltatásoknak, majd létrehozhat példányokat ezen alhálózatokon belül. Bár az Azure segít több delegált alhálózat létrehozásában egy virtuális hálózatban, az Azure NetApp Files virtuális hálózatában csak egy delegált alhálózat lehet. Ha egynél több delegált alhálózatot használ az Azure NetApp Fileshoz, akkor nem hozhat létre új kötetet.

Használati eset:

Delegált alhálózatokra van szüksége az Azure NetApp Files implementálásához. Ez a megközelítés a fájlrendszereket használó SAP-környezetek esetében népszerű. Delegált alhálózatra csak egy application gatewayhez van szüksége a terheléselosztás során, vagy az SAP BusinessObjects üzleti intelligenciához, amely egy terheléselosztási SAP-webalkalmazás-kiszolgáló.

DNS- és névfeloldás konfigurálása helyszíni és Azure-erőforrásokhoz

A tartománynévrendszer (DNS) az Azure célzóna-architektúra kritikus része. Előfordulhat, hogy egyes szervezetek a DNS-ben meglévő befektetéseiket szeretnék használni. Mások úgy tekinthetnek a felhőbevezetésre, mint a belső DNS-infrastruktúra modernizálására és a natív Azure-képességek használatára.

Tervezési javaslatok az SAP-implementációhoz:

Ha a virtuális gép DNS-e vagy virtuális neve nem változik a migrálás során, használja az alábbi használati esetekre vonatkozó javaslatokat.

Használati eset:

• A háttérBELI DNS és a virtuális nevek számos rendszerillesztőt kötnek össze az SAP-környezetben, és az ügyfelek csak néha tudják, hogy milyen felületeket határoznak meg a fejlesztők az idő múlásával. Csatlakozás rendszerek között akkor merülnek fel problémák, ha a virtuális vagy DNS-nevek a migrálás után megváltoznak. Az egyszerűség kedvéért javasoljuk, hogy tartsa meg a DNS-aliasokat.

• Különböző DNS-zónákkal különböztethetők meg egymástól az egyes környezetek, köztük a tesztkörnyezetek, a fejlesztési, az előkészítési és az éles környezetek. Ez alól kivételt képeznek a saját virtuális hálózatukkal rendelkező SAP-üzemelő példányok. Ebben a forgatókönyvben előfordulhat, hogy nincs szükség privát DNS-zónákra.

Azure-hálózati topológia definiálása

A nagyvállalati szintű célzónák két hálózati topológiát támogatnak. Az egyik topológia az Azure Virtual WAN-on alapul. A másik egy hagyományos hálózati topológia, amely küllős architektúrán alapul. Ez a szakasz mindkét üzemi modellhez ajánlott SAP-konfigurációkat és eljárásokat ismerteti.

Használjon egy Virtual WAN-alapú hálózati topológiát, ha a szervezet a következőket tervezi:

• Több Azure-régióban is üzembe helyezhet erőforrásokat, és a globális helyeket azure-beli és helyszíni környezetekhez is csatlakoztathatja.
• Szoftveralapú WAN-üzemelő példányok teljes integrálása az Azure-ral.
• Akár 2000 virtuálisgép-számítási feladatot is üzembe helyezhet az összes virtuális hálózatban, amelyek egyetlen Virtual WAN-központhoz csatlakoznak.

A szervezetek a Virtual WAN használatával teljesítik a nagy léptékű összekapcsolhatósági követelményeket. A Microsoft kezeli ezt a szolgáltatást, amely segít csökkenteni a hálózat általános összetettségét, és modernizálni a szervezet hálózatát.

Használjon hagyományos Azure-hálózati topológiát küllős architektúrán alapuló, ha a szervezete:

• Azt tervezi, hogy csak bizonyos Azure-régiókban helyezi üzembe az erőforrásokat.
• Nincs szükség globális, összekapcsolt hálózatra.
• Régiónként kevés távoli vagy ághely van, és kevesebb mint 30 IPSec-alagutat igényel.
• Az Azure-hálózat manuális konfigurálásához teljes körű vezérlésre és részletességre van szükség.

Tervezési javaslatok az SAP-implementációhoz:

• Használja a Virtual WAN-t olyan új, nagy vagy globális hálózatok azure-beli üzemelő példányaihoz, amelyekben globális átviteli kapcsolatra van szükség az Azure-régiók és a helyszíni helyek között. Ezzel a megközelítéssel nem kell manuálisan beállítania a tranzitív útválasztást az Azure-hálózatkezeléshez, és az AZURE-üzemelő példányokon az SAP szabványát követheti.

• Fontolja meg a hálózati virtuális berendezések (NVA-k) régiók közötti üzembe helyezését csak akkor, ha partner NVA-kat használ. A régiók vagy virtuális hálózatok közötti NVA-k nem szükségesek, ha natív NVA-k vannak jelen. Partnerhálózati technológiák és NVA-k üzembe helyezésekor kövesse a szállító útmutatását az Ütköző konfigurációk Azure-hálózatkezeléssel való azonosításához.

• A Virtual WAN a virtuális WAN-alapú topológiák küllős virtuális hálózatai közötti kapcsolatot kezeli, így nem kell felhasználó által megadott útvonalakat (UDR-eket) vagy NVA-kat beállítania. Az azonos virtuális központban lévő hálózati forgalom maximális hálózati átviteli sebessége 50 Gb/s. Ennek a sávszélesség-korlátozásnak a leküzdése érdekében az SAP-célzónák virtuális hálózati társviszony-létesítéssel csatlakozhatnak más célzónákhoz.

• Egyik topológia sem támogatja az NVA-telepítéseket egy SAP-alkalmazás és egy adatbázis-kiszolgáló között.

• A helyi és a globális virtuális hálózatok közötti társviszony-létesítés biztosítja a kapcsolatot, és előnyben részesített megközelítések a több Azure-régióban üzemelő SAP-üzemelő példányok célzónái közötti kapcsolat biztosításához.

Bejövő és kimenő internetkapcsolat tervezése

Ez a szakasz a nyilvános internet felé és onnan érkező bejövő és kimenő kapcsolatokhoz ajánlott kapcsolati modelleket ismerteti. Az Azure-natív hálózati biztonsági szolgáltatások, például az Azure Firewall, az Azure-alkalmazás Gatewayen futó Azure Web Application Firewall és az Azure Front Door teljes mértékben felügyelt szolgáltatások, így nem merülnek fel az infrastruktúra üzembe helyezéséhez kapcsolódó üzemeltetési és felügyeleti költségek.

Tervezési javaslatok az SAP-implementációhoz:

• A globális lábnyomot használó ügyfelek számára az Azure Front Door webalkalmazási tűzfalszabályzatokkal segíti elő az SAP-telepítéseket az Azure-régiók globális HTTP- és HTTPS-alkalmazásainak biztosításához és védelméhez.

• Használja ki az Azure Front Door webalkalmazási tűzfalszabályzatait, amikor az Azure Front Doort és az Application Gatewayt használja a HTTP- és HTTPS-alkalmazások védelméhez. Tiltsa le az Application Gateway felé irányuló forgalmat, hogy csak az Azure Front Doortól fogadhassa a forgalmat.

• Az Application Gateway és a webalkalmazási tűzfal korlátozásokkal rendelkezik, ha az Application Gateway fordított proxyként szolgál az SAP-webalkalmazásokhoz. Mivel az SAP Web Dispatcher és a NetScaler intelligensebb, mint az Application Gateway, átfogó tesztelést kell végeznie, ha lecseréli őket az Application Gatewayre. Ellenőrizze a legfrissebb állapotot, és ha lehetséges, sorolja fel az összes támogatott, nem támogatott, tesztelt és nem tesztelt forgatókönyvet.

• Webalkalmazási tűzfal használatával ellenőrizze a forgalmat, amikor az az internethez van téve. Másik lehetőségként használhatja a terheléselosztóval vagy olyan erőforrásokkal, mint az Application Gateway vagy a beépített tűzfalfunkciókkal rendelkező külső megoldások.

• Az adatszivárgás megakadályozása érdekében az Azure Private Link használatával biztonságosan elérheti a szolgáltatásként (PaaS)-erőforrásokat, például az Azure Blob Storage-t, az Azure Filest, az Azure Data Lake Storage Gen2-t és az Azure Data Factoryt. A privát végpontok a virtuális hálózatok és szolgáltatások, például az Azure Storage és az Azure Backup közötti adatforgalom védelmét is segíthetik. A virtuális hálózat és a privát végpont-kompatibilis szolgáltatás közötti forgalom a Microsoft globális hálózatán halad át, ami megakadályozza a nyilvános internetnek való kitettségét.

Az Azure ExpressRoute megvalósítása magas rendelkezésre állással

Az Azure ExpressRoute magas rendelkezésre állásra lett tervezve, hogy szolgáltatói szintű magánhálózati kapcsolatot biztosítson a Microsoft-erőforrásokhoz. A Microsoft-hálózaton belüli ExpressRoute-útvonalon nincs egyetlen hibapont sem. A rendelkezésre állás maximalizálása érdekében az ExpressRoute-kapcsolatcsoport ügyfél- és szolgáltatói szegmensét is ki kell építeni a magas rendelkezésre állás érdekében.

Tervezési javaslatok SAP-implementációkhoz:

• Győződjön meg arról, hogy az ExpressRoute-kapcsolatcsoport két fizikai kapcsolatát a hálózat két különböző peremeszközéhez csatlakoztatja. Az ExpressRoute-kapcsolatcsoport rendelkezésre állásának maximalizálására vonatkozó javaslatokért tekintse meg az ExpressRoute-kapcsolatcsoportok rugalmassági javaslatait.
• Az ExpressRoute magas rendelkezésre állásának biztosítása. További információ: Tervezés magas rendelkezésre álláshoz az ExpressRoute-tal.
• Az ExpressRoute jól megszerkesztett felülvizsgálatának elvégzése. További információ: Azure Well-Architected Framework review – Azure ExpressRoute-javaslatok.
• Győződjön meg arról, hogy rendelkezik az ExpressRoute vészhelyreállítási tervvel. További információ: Vészhelyreállítás tervezése az ExpressRoute privát társviszony-létesítéssel.
• Győződjön meg arról, hogy az ExpressRoute-kapcsolatcsoport mindkét kapcsolata aktív-aktív módban van konfigurálva. További információ: Magas rendelkezésre állás tervezése az ExpressRoute - Aktív-aktív kapcsolatok használatával.
• Konfigurálja az ExpressRoute-kapcsolatcsoportok figyelését és riasztását.
• Konfigurálja a szolgáltatás állapotát az ExpressRoute-kapcsolatcsoport karbantartási értesítései fogadásához.

Hálózati titkosítási követelmények meghatározása

Ez a szakasz a helyszíni és az Azure-környezetek közötti hálózatok, valamint az Azure-régiók közötti hálózatok titkosítására vonatkozó főbb javaslatokat ismerteti.

Az SAP-implementációk tervezési szempontjai:

• A forgalom alapértelmezés szerint nincs titkosítva, amikor az ExpressRoute használatával konfigurálja a privát társviszony-létesítést.

• Nem kell titkosítania a forgalmat az ExpressRoute-on keresztül az SAP-üzemelő példányokhoz. Az SAP-forgalom általában nagy sávszélességet használ fel, és érzékeny a teljesítményre. Az IPSec-alagutak alapértelmezés szerint titkosítják az internetes forgalmat, és a titkosítás vagy a visszafejtés negatívan befolyásolhatja a forgalom teljesítményét.

• Az ügyfél határozza meg, hogy az SAP-forgalmat titkosítani kell-e. A nagyvállalati szintű kezdőzónák hálózati titkosítási lehetőségeiről a hálózati topológia és a kapcsolat című témakörben olvashat bővebben.

Rendszerek elkülönítése

Az SAP-forgatókönyvekben különböző környezetek vannak, például fejlesztési, tesztelési, minőségi, előkészítési és éles környezetek, és az ügyfelek általában logikai vagy fizikai szerkezetekre kategorizálják ezeket a rendszereket a biztonsági és megfelelőségi szabványok fenntartása érdekében. Az ötlet az, hogy egy közös erőforráscsoportban az összes olyan rendszert felügyelje, amelyek életciklusa azonos. Ezeket a csoportokat különböző szinteken határozhatja meg, például az előfizetés vagy az erőforráscsoport szintjén.

A szervezetnek figyelembe kell vennie a biztonsági és szabályzati struktúrát is, miközben erőforrásokat csoportosít egy SAP-környezetben. Ahhoz azonban, hogy az SAP-átvitelek a fejlesztési, tesztelési, minőségi és éles környezetek között folyjanak, a szervezetnek szüksége lehet a következőkre:

• Virtuális hálózatok közötti társviszony-létesítés.
• Tűzfalportok megnyitása a virtuális hálózatok között.
• UDR- és hálózati biztonsági csoport (NSG) szabályok.

Nem javasoljuk, hogy az SAP-rendszerek adatbázis-kezelő rendszerét (DBMS) és alkalmazásrétegeit különböző virtuális hálózatokban üzemeltetje, és virtuális hálózatok közötti társviszony-létesítéssel csatlakoztassa őket. A rétegek közötti túlzott hálózati forgalom jelentős költségeket okozhat.

További javaslatok sap-implementációkhoz:

• Egyik topológia sem támogatja az SAP-alkalmazásréteg és az SAP DBMS különböző, nem társviszonyban lévő Azure-beli virtuális hálózatokban való elhelyezését.

• Az alkalmazásbiztonsági csoport (ASG) és az NSG-szabályok használatával hálózati biztonsági hozzáférés-vezérlési listákat határozhat meg az SAP-alkalmazás és a DBMS-rétegek között. Virtuális gépeket is hozzáadhat az ASG-khez a biztonságuk kezeléséhez.

• Az Azure gyorsított hálózatkezelésének engedélyezése az SAP-alkalmazásban és a DBMS-rétegekben használt virtuális gépeken. Az alábbi operációs rendszerszintek támogatják a gyorsított hálózatkezelést az Azure-ban:

  • Windows Server 2012 R2 vagy újabb
  • SU Standard kiadás Linux Enterprise Desktop 12 SP3 vagy újabb
  • Red Hat Enterprise Linux 7.4 vagy újabb
  • Oracle Linux 7.5
    • A Red Hat Enterprise Linuxdal kompatibilis kernelhez a 3.10.0-862.13.1.el7-es kiadás szükséges.
    • Az Oracle Unbreakable Enterprise Kernelhez 5-ös kiadás szükséges.

• Győződjön meg arról, hogy beállítja az Azure Load Balancer belső üzembe helyezését a közvetlen kiszolgáló visszatérési funkciójának használatához. Ez a funkció csökkenti a késést, ha belső terheléselosztó-konfigurációkat használ a DBMS-réteg magas rendelkezésre állású konfigurációihoz.

• Ha a Load Balancert Linux-vendég operációs rendszerekkel használja, győződjön meg arról, hogy a Linux hálózati paraméter net.ipv4.tcp_timestamps értéke 0.

• Az SAP-alkalmazások optimális hálózati késése érdekében fontolja meg az Azure közelségi elhelyezési csoportjainak használatát.

• Áttelepítési projektek esetén fontolja meg a hálózati paraméterek finomhangolását. Például javíthatja a teljesítményt, ha letiltja a nyugtázást a migrálási időszakban.

• Az SAP-támogatási portál és az SAP Note 2391465 segítségével többet is megtudhat az SAP implementálásáról.

A ri Standard kiadás implementációk tervezési szempontjai

Ha SAP RI Standard kiadás azure-beli üzembe helyezéseket futtat, az SAP által felügyelt környezet integrálása a saját Azure-ökoszisztémájával rendkívül fontos. Az ajánlott eljárásokkal és útmutatásokkal kapcsolatos további információkért lásd: Azure integrálása az SAP RI-val Standard kiadás felügyelt számítási feladatok.

Az SAP RI Standard kiadás implementáció általában két lehetőséget kínál, a helyek közötti VPN-t vagy a virtuális hálózatok közötti társviszony-létesítést a kapcsolatokhoz. Ha nem rendelkezik korábbi Azure-számítási feladatokkal, a helyek közötti VPN lehet a könnyebb megoldás. Ha azonban stratégiai platformként szeretné bevezetni az Azure-t, érdemes lehet egy megfelelő Azure-célzónát beállítani, és virtuális hálózati társviszonyt létesíteni az SAP RI Standard kiadás-bérlővel. Ezekben a forgatókönyvekben egy egyszerűsített célzóna, például a felhőadaptálási keretrendszer migrálási célzóna jó választás lehet. Ezt a tervet egyszerűen az ügyfél igényeihez igazíthatja, a virtuális hálózati paraméterekre összpontosítva.

A bérlők közötti virtuális hálózatok közötti társviszony-létesítés üzembe helyezése az SAP RI-ben Standard kiadás bérlőhöz is több munkát igényel. Gondosan megterveznie kell a virtuális hálózati architektúrát, hogy ne legyenek átfedésben az osztály nélküli tartományközi útválasztási tartományok. A DNS-t megfelelően kell társítania az SAP RI Standard kiadás-bérlőhöz is.

Végül, ha úgy dönt, hogy beállít egy Virtual WAN-megoldást, és helyek közötti VPN- vagy ExpressRoute-kapcsolatokra is szüksége van, vegye figyelembe a korlátokat és a korlátozásokat.