A Microsoft 365-höz készült ExpressRoute implementálása
Ez a cikk a Microsoft 365 Nagyvállalati verzió vonatkozik.
A Microsoft 365-höz készült ExpressRoute alternatív útválasztási útvonalat biztosít számos internetkapcsolattal rendelkező Microsoft 365-szolgáltatáshoz. A Microsoft 365-höz készült ExpressRoute architektúrája a Microsoft 365-szolgáltatások nyilvános IP-előtagjainak reklámozásán alapul, amelyek már elérhetők az interneten keresztül a kiépített ExpressRoute-kapcsolatcsoportokban, hogy az ip-előtagok később újraelosztásra kerülnek a hálózatra. Az ExpressRoute-tal számos különböző útválasztási útvonalat engedélyezhet az interneten és az ExpressRoute-on keresztül számos Microsoft 365-szolgáltatáshoz. A hálózat ezen útválasztási állapota jelentős változást jelenthet a belső hálózati topológia kialakításában.
Megjegyzés:
Nem javasoljuk a Microsoft 365-höz készült ExpressRoute használatát, mert a legtöbb esetben nem a legjobb kapcsolati modellt biztosítja a szolgáltatáshoz. Ezért a kapcsolati modell használatához Microsoft-engedély szükséges. Minden ügyfélkérést áttekintünk, és csak olyan ritka esetekben engedélyezzük az ExpressRoute-ot a Microsoft 365-höz, ahol erre szükség van. További információért olvassa el a Microsoft 365-höz készült ExpressRoute-útmutatót , és miután átfogó áttekintést adott a dokumentumról a hatékonysággal, a hálózattal és a biztonsági csapatokkal, a Microsoft-fiókért felelős csapatával együttműködve küldjön be kivételt, ha szükséges. A Microsoft 365 útvonalszűrőit létrehozó jogosulatlan előfizetések hibaüzenetet kapnak.
Gondosan meg kell terveznie a Microsoft 365-höz készült ExpressRoute-implementációt, hogy megfeleljen azoknak a hálózati összetettségeknek, amelyek miatt az útválasztás egy dedikált kapcsolatcsoporton keresztül is elérhető, az alaphálózatba és az internetre injektált útvonalakkal. Ha Ön és csapata nem végzi el a részletes tervezést és tesztelést ebben az útmutatóban, az ExpressRoute-kapcsolatcsoport engedélyezése esetén nagy a kockázata annak, hogy időszakosan megszakad a kapcsolat a Microsoft 365-szolgáltatásokkal.
A sikeres implementációhoz elemeznie kell az infrastruktúra követelményeit, részletes hálózatfelmérést és -kialakítást kell végeznie, gondosan kell megterveznie a bevezetést szakaszos és szabályozott módon, valamint létre kell hoznia egy részletes ellenőrzési és tesztelési tervet. Nagy, elosztott környezet esetén nem ritka, hogy az implementációk több hónapig is eltarthatnak. Ez az útmutató segít előre tervezni.
A nagy méretű sikeres telepítések tervezése hat hónapot vehet igénybe, és gyakran a szervezet számos területéről származó csapattagokat is magában foglal, beleértve a hálózatkezelést, a tűzfal- és proxykiszolgáló-rendszergazdákat, a Microsoft 365 rendszergazdáit, a biztonságot, a végfelhasználói támogatást, a projektkezelést és a vezetői szponzorálást. A tervezési folyamatba való befektetése csökkenti annak a valószínűségét, hogy üzembehelyezési hibákat fog tapasztalni, ami állásidőt vagy összetett és költséges hibaelhárítást eredményez.
Az implementálási útmutató elindítása előtt a következő előfeltételek teljesülnek.
Elvégezte a hálózatfelmérést annak megállapításához, hogy az ExpressRoute ajánlott-e és engedélyezve van-e.
Kiválasztott egy ExpressRoute hálózati szolgáltatót. Az ExpressRoute-partnerekkel és a társhálózat-létesítési helyekkel kapcsolatos információk.
Már elolvasta és megértette az ExpressRoute dokumentációját , és a belső hálózata képes teljes körűen teljesíteni az ExpressRoute előfeltételeit.
Csapata elolvasta az összes nyilvános útmutatót és dokumentációt a címen https://aka.ms/expressrouteoffice365, https://aka.ms/ertés megnézte a Microsoft 365-höz készült Azure ExpressRoute Képzési sorozatot a Channel 9-en, hogy megismerje a kritikus technikai részleteket, többek között a következőket:
Az SaaS-szolgáltatások internetes függőségei.
Az aszimmetrikus útvonalak elkerülése és az összetett útválasztás kezelése.
Szegélyhálózati biztonság, rendelkezésre állás és alkalmazásszintű vezérlők beépítése.
Első lépésként gyűjtse össze a követelményeket
Első lépésként határozza meg, hogy mely szolgáltatásokat és szolgáltatásokat szeretné bevezetni a szervezeten belül. Meg kell határoznia, hogy a különböző Microsoft 365-szolgáltatások mely funkciói lesznek használatban, és hogy a hálózat mely helyei fogják üzemeltetni ezeket a szolgáltatásokat használó személyeket. A forgatókönyvek katalógusával hozzá kell adnia az egyes forgatókönyvekhez szükséges hálózati attribútumokat; például a bejövő és kimenő hálózati forgalom, és hogy a Microsoft 365-végpontok elérhetők-e az ExpressRoute-on keresztül.
A szervezet követelményeinek összegyűjtése:
Katalógusba rendezheti a szervezet által használt Microsoft 365-szolgáltatások bejövő és kimenő hálózati forgalmát. A Különböző Microsoft 365-forgatókönyvek által igényelt folyamatok leírásáért tekintse meg a Microsoft 365 URL-címeit és IP-címtartományait ismertető oldalt.
Gyűjtse össze a meglévő hálózati topológia dokumentációját, amely bemutatja a belső WAN gerincét és topológiáját, a műholdas helyek kapcsolatát, az utolsó mérföld felhasználókapcsolatát, a hálózati peremhálózati kimenő pontokra való útválasztást és a proxyszolgáltatásokat.
Azonosítsa a bejövő szolgáltatásvégpontokat azon hálózati diagramokon, amelyekhez a Microsoft 365 és más Microsoft-szolgáltatások csatlakozni fognak, és megjeleníti az internetet és a javasolt ExpressRoute-kapcsolati útvonalakat.
Azonosítsa az összes földrajzi felhasználói helyet és a helyek közötti WAN-kapcsolatot, valamint azt, hogy mely helyeken van jelenleg kimenő forgalom az internetre, és mely helyeken javasolt az ExpressRoute-társviszony-létesítési helyre történő kimenő forgalom.
Azonosítsa az összes peremeszközt, például proxykat, tűzfalakat stb., és katalogizálja az interneten és az ExpressRoute-on keresztüli folyamatokhoz való kapcsolatukat.
Dokumentálja, hogy a végfelhasználók közvetlen útválasztással vagy közvetett alkalmazásproxyval férnek-e hozzá a Microsoft 365-szolgáltatásokhoz az internet és az ExpressRoute-folyamatok esetében.
Adja hozzá a bérlői és a találkozóhelyeket a hálózati diagramhoz.
Becsülje meg a főbb felhasználói helyektől a Microsoft 365-be való várható és megfigyelt hálózati teljesítmény- és késési jellemzőket. Ne feledje, hogy a Microsoft 365 egy globális és elosztott szolgáltatáskészlet, és a felhasználók olyan helyekhez csatlakoznak, amelyek eltérhetnek a bérlőjük helyétől. Ezért javasoljuk, hogy mérje és optimalizálja a felhasználó és a Microsoft globális hálózatának legközelebbi peremhálózata közötti késést ExpressRoute-on és internetkapcsolatokon keresztül. A hálózati értékelés eredményei alapján segítheti ezt a feladatot.
Sorolja fel azokat a vállalati hálózati biztonsági és magas rendelkezésre állási követelményeket, amelyeknek teljesülniük kell az új ExpressRoute-kapcsolattal. Például hogyan férhetnek hozzá a felhasználók a Microsoft 365-höz az internetes kimenő forgalom vagy az ExpressRoute-kapcsolatcsoport hibája esetén.
Az a dokumentum, amely a Microsoft 365 bejövő és kimenő hálózati folyamataihoz az internetelérési utat használja, és amely az ExpressRoute-ot fogja használni. A felhasználók földrajzi helyeinek és a helyszíni hálózati topológiának a részletei miatt előfordulhat, hogy a tervnek az egyik felhasználói helytől a másikig eltérőnek kell lennie.
A kimenő és bejövő hálózati forgalom katalógusa
Az útválasztás és az egyéb hálózati összetettségek minimalizálása érdekében azt javasoljuk, hogy csak a Microsoft 365-höz készült ExpressRoute-ot használja azokhoz a hálózati forgalmi folyamatokhoz, amelyek a jogszabályi követelmények miatt vagy a hálózatfelmérés eredményeként dedikált kapcsolaton keresztül haladnak át. Javasoljuk továbbá, hogy az ExpressRoute-útválasztás hatókörét az implementálási projekt különböző és különálló fázisaiként készítse elő, és közelítse meg a kimenő és bejövő hálózati forgalom áramlását. Telepítse az ExpressRoute-ot a Microsoft 365-höz a felhasználó által kezdeményezett kimenő hálózati forgalomhoz, és hagyja a bejövő hálózati forgalmat az interneten keresztül, így szabályozhatja a topológiai összetettség növekedését és a további aszimmetrikus útválasztási lehetőségek bevezetésének kockázatait.
A hálózati forgalomkatalógusnak tartalmaznia kell a helyszíni hálózat és a Microsoft közötti összes bejövő és kimenő hálózati kapcsolat listáját.
A kimenő hálózati forgalom olyan forgatókönyv, amelyben a helyszíni környezetből, például belső ügyfelekről vagy kiszolgálókról kezdeményeznek kapcsolatot a Microsoft-szolgáltatások célhelyével. Ezek a kapcsolatok lehetnek közvetlenül a Microsoft 365-höz vagy közvetettek, például amikor a kapcsolat proxykiszolgálókon, tűzfalakon vagy más hálózati eszközökön halad keresztül a Microsoft 365 felé vezető úton.
A bejövő hálózati forgalom olyan forgatókönyv, amelyben a Microsoft-felhőből egy helyszíni gazdagéppel létesít kapcsolatot. Ezeknek a kapcsolatoknak általában tűzfalon és más biztonsági infrastruktúrán kell keresztülmennie, amelyet az ügyfélbiztonsági szabályzat megkövetel a külső eredetű folyamatokhoz.
Olvassa el az Útvonalszimmetria biztosítása című szakaszt annak meghatározásához, hogy mely szolgáltatások küldenek bejövő forgalmat, és keresse meg a Microsoft 365-höz készült ExpressRoute-tal jelölt oszlopot a Microsoft 365-végpontok referenciacikkében a többi kapcsolati információ meghatározásához.
Minden olyan szolgáltatás esetében, amely kimenő kapcsolatot igényel, le kell írnia a szolgáltatás tervezett kapcsolatát, beleértve a hálózati útválasztást, a proxykonfigurációt, a csomagvizsgálatot és a sávszélesség-igényeket.
Minden olyan szolgáltatáshoz, amely bejövő kapcsolatot igényel, további információkra lesz szüksége. A Microsoft-felhőben lévő kiszolgálók kapcsolatot létesítenek a helyszíni hálózattal. A kapcsolatok megfelelőségének biztosítása érdekében érdemes a kapcsolat összes aspektusát leírni, beleértve a következőket is: a bejövő kapcsolatokat elfogadó szolgáltatások nyilvános DNS-bejegyzései, a CIDR formátumú IPv4 IP-címek, az isp-berendezések, valamint a bejövő NAT vagy a forrás NAT kezelése ezekhez a kapcsolatokhoz.
A bejövő kapcsolatokat függetlenül attól, hogy az interneten vagy az ExpressRoute-on keresztül csatlakoznak-e, ellenőrizni kell, hogy nem vezették-e be az aszimmetrikus útválasztást. Bizonyos esetekben a Microsoft 365-szolgáltatások által bejövő kapcsolatokat kezdeményező helyszíni végpontokhoz más Microsoft- és nem Microsoft-szolgáltatásoknak is hozzá kell férniük. Rendkívül fontos, hogy az ExpressRoute-útválasztás engedélyezése ezekhez a szolgáltatásokhoz Microsoft 365-beli célokra nem szakít meg más forgatókönyveket. Sok esetben előfordulhat, hogy az ügyfeleknek konkrét módosításokat kell végrehajtaniuk a belső hálózatukon, például a forrásalapú NAT-ot annak érdekében, hogy a Microsoft bejövő folyamatai szimmetrikusak maradjanak az ExpressRoute engedélyezése után.
Íme egy példa a szükséges részletességi szintről. Ebben az esetben az Exchange Hybrid az ExpressRoute-on keresztül irányítja a helyszíni rendszert.
| Kapcsolat tulajdonság | Érték |
|---|---|
| Hálózati forgalom iránya |
Bejövő |
| Szolgáltatás |
Hibrid Exchange |
| Nyilvános Microsoft 365-végpont (forrás) |
Exchange Online (IP-címek) |
| Nyilvános helyszíni végpont (cél) |
5.5.5.5 |
| Nyilvános (internetes) DNS-bejegyzés |
Autodiscover.contoso.com |
| Ezt a helyszíni végpontot más (nem Microsoft 365-ös) Microsoft-szolgáltatások is használni fogják? |
Nem |
| Ezt a helyszíni végpontot használják-e a felhasználók/rendszerek az interneten? |
Igen |
| Nyilvános végpontokon keresztül közzétett belső rendszerek |
Exchange Server ügyfél-hozzáférési szerepkör (helyszíni) 192.168.101, 192.168.102, 192.168.103 |
| A nyilvános végpont IP-hirdetése |
Internetre: 5.5.0.0/16 Az ExpressRoute-hoz: 5.5.5.0/24 |
| Biztonsági/szegélyhálózati vezérlők |
Internetelérési út: DeviceID_002 ExpressRoute-útvonal: DeviceID_003 |
| Magas rendelkezésre állás |
Aktív/Aktív 2 georedundáns/ExpressRoute-kapcsolatcsoportban – Chicago és Dallas |
| Elérési út szimmetriavezérlése |
Módszer: Forrás NAT internetes elérési útja: Forrás NAT bejövő kapcsolatai a 192.168.5.5 ExpressRoute-útvonalhoz: Forrás NAT-kapcsolatok a 192.168.1.0-s (Chicago) és a 192.168.2.0-s verzióhoz (Dallas) |
Íme egy példa egy csak kimenő szolgáltatásra:
| Kapcsolat tulajdonság | Érték |
|---|---|
| Hálózati forgalom iránya |
Kimenő |
| Szolgáltatás |
SharePoint |
| Helyszíni végpont (forrás) |
Felhasználói munkaállomás |
| Nyilvános Microsoft 365-végpont (cél) |
SharePoint (IP-címek) |
| Nyilvános (internetes) DNS-bejegyzés |
*.sharepoint.com (és további teljes tartománynevek) |
| CDN-javaslatok |
cdn.sharepointonline.com (és több FQDN) – A CDN-szolgáltatók által fenntartott IP-címek) |
| IP-hirdetmény és használatban lévő NAT |
Internetes elérési út/Forrás NAT: 1.1.1.0/24 ExpressRoute-útvonal/Forrás NAT: 1.1.2.0/24 (Chicago) és 1.1.3.0/24 (Dallas) |
| Kapcsolati módszer |
Internet: 7. rétegbeli proxyn keresztül (.pac fájl) ExpressRoute: közvetlen útválasztás (proxy nélkül) |
| Biztonsági/szegélyhálózati vezérlők |
Internetes elérési út: DeviceID_002 ExpressRoute-útvonal: DeviceID_003 |
| Magas rendelkezésre állás |
Internetes útvonal: Redundáns internetes kimenő forgalom ExpressRoute-útvonal: Aktív/aktív "forróburgonya" útválasztás 2 georedundáns ExpressRoute-kapcsolatcsoporton keresztül – Chicago és Dallas |
| Elérési út szimmetriavezérlése |
Metódus: Forrás NAT az összes kapcsolathoz |
A hálózati topológia kialakítása regionális kapcsolattal
Miután megismerte a szolgáltatásokat és a hozzájuk tartozó hálózati forgalomfolyamokat, létrehozhat egy hálózati diagramot, amely tartalmazza ezeket az új csatlakozási követelményeket, és bemutatja a Microsoft 365-höz készült ExpressRoute használatára vonatkozó módosításokat. A diagramnak a következőket kell tartalmaznia:
Minden olyan felhasználói hely, ahonnan a Microsoft 365 és más szolgáltatások elérhetők lesznek.
Minden internet- és ExpressRoute-kimenő pont.
Minden kimenő és bejövő eszköz, amely a hálózaton belüli és kimenő kapcsolatot kezeli, beleértve az útválasztókat, a tűzfalakat, az alkalmazásproxy-kiszolgálókat és a behatolásészlelést/-megelőzést.
Az összes bejövő forgalom belső célhelyei, például olyan belső ADFS-kiszolgálók, amelyek az ADFS-webalkalmazás proxykiszolgálóiról fogadnak kapcsolatokat.
Az összes meghirdetett IP-alhálózat katalógusa
Azonosítsa azokat a helyeket, ahonnan a felhasználók hozzáférhetnek a Microsoft 365-höz, és sorolja fel az ExpressRoute-hoz használt találkozóhelyeket.
A belső hálózati topológia azon helyei és részei, ahol az ExpressRoute-ból tanult Microsoft IP-előtagok elfogadásra, szűrésre és propagálásra kerülnek.
A hálózati topológiának ábrázolnia kell az egyes hálózati szegmensek földrajzi helyét, valamint azt, hogy hogyan csatlakozik a Microsoft-hálózathoz az ExpressRoute-on és/vagy az interneten keresztül.
Az alábbi ábrán minden olyan hely látható, ahonnan a felhasználók a Microsoft 365-öt fogják használni, valamint a Microsoft 365-be irányuló bejövő és kimenő útválasztási hirdetéseket.
Kimenő forgalom esetén a felhasználók háromféleképpen érhetik el a Microsoft 365-öt:
Egy találkozó helyszínén Észak-Amerika a kaliforniaiak számára.
Egy meet-me helyen Hong Kong különleges közigazgatási régióban az emberek Hong Kong KKT.
Az interneten keresztül Bangladesben, ahol kevesebb ember van, és nincs ExpressRoute-kapcsolatcsoport kiépítve.
Hasonlóképpen, a Microsoft 365 bejövő hálózati forgalma háromféleképpen tér vissza:
Egy találkozó helyszínén Észak-Amerika a kaliforniaiak számára.
Egy meet-me helyen Hong Kong különleges közigazgatási régióban az emberek Hong Kong KKT.
Az interneten keresztül Bangladesben, ahol kevesebb ember van, és nincs ExpressRoute-kapcsolatcsoport kiépítve.
A megfelelő találkozó helyének meghatározása
A meet-me helyek kiválasztását, amelyek az ExpressRoute-kapcsolatcsoport és a Microsoft-hálózat összekapcsolásának fizikai helyei, befolyásolják azokat a helyeket, ahonnan a felhasználók hozzáférhetnek a Microsoft 365-höz. SaaS-ajánlatként a Microsoft 365 nem ugyanúgy működik az IaaS- vagy PaaS-regionális modell alatt, mint az Azure. Ehelyett a Microsoft 365 az együttműködési szolgáltatások elosztott készlete, ahol előfordulhat, hogy a felhasználóknak több adatközpont és régió végpontjaihoz kell csatlakozniuk, amelyek nem feltétlenül ugyanazon a helyen vagy régióban találhatók, ahol a felhasználó bérlője üzemel.
Ez azt jelenti, hogy a Microsoft 365-höz készült ExpressRoute meet-me helyeinek kiválasztásakor a legfontosabb szempont az, ahonnan a szervezeten belüli személyek csatlakozni fognak. Az optimális Microsoft 365-kapcsolatra vonatkozó általános javaslat az útválasztás megvalósítása, hogy a Microsoft 365-szolgáltatásokra irányuló felhasználói kérések a legrövidebb hálózati útvonalon legyenek átadva a Microsoft-hálózatnak. Ezt gyakran "forróburgonya" útválasztásnak is nevezik. Ha például a Microsoft 365 legtöbb felhasználója egy vagy két helyen tartózkodik, akkor a felhasználók tartózkodási helyéhez legközelebbi helyek kiválasztása hozza létre az optimális kialakítást. Ha a vállalata számos különböző régióban rendelkezik nagy felhasználói sokaságokkal, érdemes lehet több ExpressRoute-kapcsolatcsoportot és meet-me helyet létrehozni. Egyes felhasználói helyek esetében előfordulhat, hogy a Microsoft hálózatába és a Microsoft 365-be vezető legrövidebb/legoptimálisabb elérési út nem a belső WAN-on és az ExpressRoute meet-me pontjain, hanem az interneten keresztül történik.
Gyakran több olyan találkozóhely is van, amely a felhasználókhoz való relatív közelséggel rendelkező régión belül választható ki. A döntések útmutatójához töltse ki az alábbi táblázatot.
Tervezett ExpressRoute-helyek Kaliforniában és New Yorkban
| Hely |
Személyek száma |
A Microsoft-hálózat várható késése internetes kimenő forgalomon keresztül |
Microsoft-hálózat várható késése ExpressRoute-on keresztül |
|---|---|---|---|
| Los Angeles |
10,000 |
~15ms |
~10ms (a Szilícium-völgyön keresztül) |
| Washington D.C. |
15,000 |
~20ms |
~10ms (New Yorkon keresztül) |
| Dallas |
5,000 |
~15ms |
~40ms (New Yorkon keresztül) |
A Microsoft 365-régiót, az ExpressRoute hálózati szolgáltató által megadott helyeket és a személyek hely szerinti mennyiségét megjelenítő globális hálózati architektúra fejlesztése után azonosítható, hogy van-e optimalizálási lehetőség. Emellett globális hajszálhálózati kapcsolatokat is megjeleníthet, ahol a forgalom egy távoli helyre irányítja az értekezlet helyszínét. Ha a globális hálózaton egy hajszálat fedeznek fel, a folytatás előtt ki kell szervizelni. Keressen egy másik találkozóhelyet, vagy használjon szelektív internetkitörési kimenő pontokat a hajszál elkerülése érdekében.
Az első ábrán egy olyan ügyfél látható, aki két fizikai hellyel rendelkezik Észak-Amerika. Megtekintheti az office-helyekre, a Microsoft 365-ös bérlői helyekre és az ExpressRoute-beli meet-me helyekre vonatkozó számos választási lehetőséget. Ebben a példában az ügyfél két alapelv alapján választotta ki a meet-me helyet, sorrendben:
A szervezeten belüli személyek legközelebbi közelsége.
A microsoftos adatközpont közelében, ahol a Microsoft 365 üzemel.
A koncepciót kissé tovább bővítve a második ábrán egy több országra kiterjedő példa látható, amely hasonló információkkal és döntéshozatalsal szembesült. Ennek az ügyfélnek van egy kis irodája Bangladesben, és csak egy 10 fős kis csapat összpontosított a régióban való lábnyomának növekedésére. Van egy találkozóhely Chennaiban és egy Microsoft-adatközpont, ahol a Microsoft 365 Chennai-ban van üzemeltetve, így a találkozó helyszínének értelme lenne; azonban 10 ember számára az extra kapcsolatcsoport költsége nehézkes. A hálózat megtekintésekor meg kell határoznia, hogy a hálózati forgalom hálózaton keresztüli küldésével járó késés hatékonyabb-e, mint a tőke elköltése egy másik ExpressRoute-kapcsolatcsoport beszerzésére.
Azt is megteheti, hogy a 10 bangladesi személy jobb teljesítményt tapasztal az interneten keresztül a Microsoft-hálózatra küldött hálózati forgalommal, mint amennyit a belső hálózatán irányítana, ahogy azt az alábbi bevezető ábrák is szemléltetik.
A Microsoft 365-höz készült ExpressRoute implementálási tervének Létrehozás
A megvalósítási tervnek magában kell foglalnia az ExpressRoute konfigurálásának technikai részleteit és a hálózat összes többi infrastruktúrájának konfigurálásának részleteit, például az alábbiakat.
Tervezze meg, hogy mely szolgáltatások oszlanak meg az ExpressRoute és az internet között.
Tervezze meg a sávszélességet, a biztonságot, a magas rendelkezésre állást és a feladatátvételt.
Bejövő és kimenő útválasztás tervezése, beleértve a különböző helyek útválasztási útvonalának megfelelő optimalizálását
Döntse el, hogy az ExpressRoute-útvonalak milyen messzire lesznek meghirdetve a hálózaton, és milyen mechanizmussal választhatják ki az ügyfelek az internetet vagy az ExpressRoute-útvonalat; például közvetlen útválasztás vagy alkalmazásproxy.
Tervezze meg a DNS-rekord módosításait, beleértve a küldőszabályzat-keretrendszer bejegyzéseit.
Tervezze meg a NAT-stratégiát, beleértve a kimenő és a bejövő forrás NAT-ot is.
Az útválasztás megtervezése az internet és az ExpressRoute hálózati útvonalaival
A kezdeti üzembe helyezéshez minden bejövő szolgáltatás, például a bejövő e-mail vagy a hibrid kapcsolat használata javasolt az internet használatához.
Tervezze meg a végfelhasználói ügyfél LAN-útválasztását, például a PAC-/WPAD-fájl konfigurálását, az alapértelmezett útvonalat, a proxykiszolgálókat és a BGP-útvonalhirdetéseket.
Tervezze meg a szegélyhálózati útválasztást, beleértve a proxykiszolgálókat, a tűzfalakat és a felhőproxykat.
Tervezze meg a sávszélességet, a biztonságot, a magas rendelkezésre állást és a feladatátvételt
Létrehozás a Microsoft 365 minden nagyobb számítási feladatához szükséges sávszélességet. Külön becsülje meg a Exchange Online, a SharePoint és a Skype Vállalati verzió Online sávszélességre vonatkozó követelményeit. Kiindulási helyként használhatja a Exchange Online és a Skype Vállalati verzió becslési kalkulátorait, azonban a szervezet sávszélesség-igényeinek teljes körű megértéséhez próbatesztre van szükség a felhasználói profilok és helyek reprezentatív mintáival.
Adja hozzá a csomaghoz az egyes internetes és ExpressRoute-kimenő forgalom biztonságának kezelését. Ne feledje, hogy a Microsoft 365-be irányuló expressRoute-kapcsolatok nyilvános társviszony-létesítést használnak, és a külső hálózatokhoz való csatlakozás vállalati biztonsági szabályzatainak megfelelően kell védeni.
Adja meg a terv részleteit arról, hogy mely személyeket fogja érinteni a szolgáltatáskimaradás típusa, és hogy ezek a személyek a legegyszerűbben teljes kapacitással végezhetik el a munkájukat.
Tervezze meg a sávszélességre vonatkozó követelményeket, beleértve a jitterre, a késésre, a torlódásra és a fejtérre vonatkozó Skype Vállalati verzió követelményeket
A Skype Vállalati verzió Online speciális további hálózati követelményekkel is rendelkezik, amelyeket a Médiaminőség és hálózati kapcsolat teljesítménye az Skype Vállalati verzió Online-ban című cikkben talál.
Olvassa el az Azure ExpressRoute sávszélesség-tervezését ismertető szakaszt. Amikor sávszélesség-felmérést végez a próbafelhasználókkal, a Microsoft 365 teljesítményhangolása alaptervek és teljesítményelőzmények használatával című útmutatónkat használhatja.
Magas rendelkezésre állási követelmények tervezése
Létrehozás a magas rendelkezésre állásra vonatkozó tervet, hogy megfeleljen az igényeinek, és ezt beépítse a frissített hálózati topológiadiagramba. Olvassa el a Magas rendelkezésre állás és feladatátvétel az Azure ExpressRoute-tal című szakaszt.
Hálózati biztonsági követelmények tervezése
Létrehozás egy tervet, amely megfelel a hálózati biztonsági követelményeknek, és beépíti azt a frissített hálózati topológiadiagramba. Olvassa el a Biztonsági vezérlők alkalmazása az Azure ExpressRoute-ra Microsoft 365-forgatókönyvekhez című szakaszt.
Kimenő szolgáltatáskapcsolat tervezése
A Microsoft 365-höz készült ExpressRoute kimenő hálózati követelményei ismeretlenek lehetnek. Pontosabban azoknak az IP-címeknek, amelyek a felhasználókat és a hálózatokat a Microsoft 365 felé képviselik, és a Microsoft felé irányuló kimenő hálózati kapcsolatok forrásvégpontjaiként szolgálnak, meg kell felelnie az alább ismertetett követelményeknek.
A végpontoknak olyan nyilvános IP-címeknek kell lenniük, amelyek regisztrálva vannak a vállalatnál vagy az ExpressRoute-kapcsolatot biztosító szolgáltatónál.
A végpontokat meg kell hirdetni a Microsoftnak, és ellenőrizni/elfogadni az ExpressRoute-nak.
A végpontok nem hirdethetők meg az interneten ugyanazzal vagy több előnyben részesített útválasztási metrikával.
A végpontok nem használhatók az ExpressRoute-on keresztül konfigurált Microsoft-szolgáltatásokhoz való csatlakozáshoz.
Ha a hálózat kialakítása nem felel meg ezeknek a követelményeknek, nagy a kockázata annak, hogy a felhasználók kapcsolódási hibákat tapasztalnak a Microsoft 365-tel és más Microsoft-szolgáltatásokkal kapcsolatban a fekete holing vagy az aszimmetrikus útválasztás miatt. Ez akkor fordul elő, ha a Microsoft-szolgáltatásoknak küldött kérések az ExpressRoute-on keresztül vannak átirányítva, de a válaszok vissza lesznek irányítva az interneten keresztül, vagy fordítva, és az állapotalapú hálózati eszközök, például tűzfalak elvetik a válaszokat.
A fenti követelmények teljesítéséhez leggyakrabban használt módszer a forrás NAT használata, amelyet a hálózat részeként vagy az ExpressRoute-szolgáltató biztosít. A forrás NAT lehetővé teszi az internetes hálózat részleteinek és magánhálózati IP-címzésének absztrakcióját az ExpressRoute-ról és; megfelelő IP-útvonalhirdetésekkel párosítva egyszerű mechanizmust biztosít az útvonal szimmetria biztosításához. Ha ExpressRoute-társviszony-létesítési helyekre jellemző állapotalapú hálózati eszközöket használ, az útvonal szimmetria biztosításához minden ExpressRoute-társviszony-létesítéshez külön NAT-készleteket kell implementálnia.
További információ az ExpressRoute NAT-követelményeiről.
Adja hozzá a kimenő kapcsolat módosításait a hálózati topológiadiagramhoz.
Bejövő szolgáltatáskapcsolat tervezése
A nagyvállalati Microsoft 365-környezetek többsége feltételezi a Microsoft 365-ből a helyszíni szolgáltatásokba irányuló bejövő kapcsolatokat, például exchange, SharePoint és Skype Vállalati verzió hibrid forgatókönyvekhez, postaládák áttelepítéséhez és ADFS-infrastruktúrát használó hitelesítéshez. Ha az ExpressRoute-tal további útválasztási útvonalat engedélyez a helyszíni hálózat és a Microsoft között a kimenő kapcsolatokhoz, ezeket a bejövő kapcsolatokat véletlenül érintheti az aszimmetrikus útválasztás, még akkor is, ha azt szeretné, hogy ezek a folyamatok továbbra is az internetet használják. Az alábbiakban ismertetett óvintézkedéseket javasoljuk, hogy ne legyenek hatással a Microsoft 365-ből a helyszíni rendszerekbe irányuló internetes bejövő forgalomra.
A bejövő hálózati forgalom aszimmetrikus útválasztásának kockázatainak minimalizálása érdekében az összes bejövő kapcsolatnak forrás NAT-ot kell használnia, mielőtt a hálózat olyan szegmenseibe irányítanák őket, amelyek útválasztási láthatóságot biztosítanának az ExpressRoute-ba. Ha a bejövő kapcsolatok olyan hálózati szegmensre vannak engedélyezve, amely a forrás NAT nélkül irányítja az ExpressRoute-ot, a Microsoft 365-ből érkező kérések az internetről érkeznek, de a Microsoft 365-re visszamenő válasz inkább az ExpressRoute hálózati útvonalát részesíti előnyben a Microsoft-hálózat felé, ami aszimmetrikus útválasztást okoz.
A következő megvalósítási minták egyikét érdemes megfontolnia, hogy megfeleljen ennek a követelménynek:
A kérések belső hálózatra való átirányítása előtt végezze el a forrás NAT-műveletet olyan hálózati berendezésekkel, mint a tűzfalak vagy a terheléselosztók az internetről a helyszíni rendszerekre vezető útvonalon.
Győződjön meg arról, hogy az ExpressRoute-útvonalak nincsenek propagálva azokra a hálózati szegmensekre, ahol a bejövő szolgáltatások, például az előtérbeli kiszolgálók vagy a fordított proxyrendszerek internetkapcsolatokat kezelnek.
Ha kifejezetten figyelembe veszik ezeket a forgatókönyveket a hálózatban, és az összes bejövő hálózati forgalom az interneten keresztül marad, az segít minimalizálni az aszimmetrikus útválasztás üzembe helyezésének és működési kockázatának minimalizálását.
Előfordulhat, hogy egyes bejövő folyamatokat ExpressRoute-kapcsolatokon keresztül irányít. Ezekben a forgatókönyvekben vegye figyelembe az alábbi további szempontokat.
A Microsoft 365 csak nyilvános IP-címeket használó helyszíni végpontokat célozhat meg. Ez azt jelenti, hogy még ha a helyszíni bejövő végpontot is csak az ExpressRoute-on keresztül teszi elérhetővé a Microsoft 365, akkor is hozzá kell társítani a nyilvános IP-címet.
Minden DNS-névfeloldás, amelyet a Microsoft 365-szolgáltatások végeznek a helyszíni végpontok feloldásához, nyilvános DNS használatával történik. Ez azt jelenti, hogy regisztrálnia kell a bejövő szolgáltatásvégpontok teljes tartománynevét az interneten található IP-leképezésekre.
Ahhoz, hogy bejövő hálózati kapcsolatokat fogadhasson az ExpressRoute-on keresztül, a végpontok nyilvános IP-alhálózatait az ExpressRoute-on keresztül kell hirdetni a Microsoft számára.
Gondosan értékelje ki ezeket a bejövő hálózati forgalmi folyamatokat, hogy a vállalati biztonsági és hálózati szabályzatokkal összhangban megfelelő biztonsági és hálózati vezérlőket alkalmazzanak rájuk.
Miután a helyszíni bejövő végpontokat meghirdette a Microsoft számára az ExpressRoute-on keresztül, az ExpressRoute lesz az összes Microsoft-szolgáltatás , köztük a Microsoft 365 által is használt végpontok előnyben részesített útválasztási útvonala. Ez azt jelenti, hogy ezek a végponti alhálózatok csak a Microsoft 365-szolgáltatásokkal folytatott kommunikációhoz használhatók, a Microsoft-hálózaton lévő egyéb szolgáltatásokhoz nem. Ellenkező esetben a terv aszimmetrikus útválasztást eredményez, ahol a más Microsoft-szolgáltatások bejövő kapcsolatai inkább az ExpressRoute-on keresztül irányítják a bejövő forgalmat, míg a visszatérési útvonal az internetet fogja használni.
Ha egy ExpressRoute-kapcsolatcsoport vagy a meet-me hely nem működik, gondoskodnia kell arról, hogy a helyszíni bejövő végpontok továbbra is elérhetők legyenek a kérések külön hálózati útvonalon való elfogadásához. Ez azt jelentheti, hogy ezekhez a végpontokhoz több ExpressRoute-kapcsolatcsoporton keresztül kell hirdetni az alhálózatokat.
Javasoljuk, hogy a forrás NAT-ot az ExpressRoute-on keresztül bemenő összes bejövő hálózati forgalomra alkalmazza, különösen akkor, ha ezek állapotalapú hálózati eszközök, például tűzfalak között haladnak át.
Egyes helyszíni szolgáltatások, például az ADFS-proxy vagy az Exchange automatikus észlelése bejövő kéréseket kaphatnak mind a Microsoft 365-szolgáltatásoktól, mind az internetről érkező felhasználóktól. Ezekhez a kérésekhez a Microsoft 365 ugyanazt a teljes tartománynevet célozza meg, mint az interneten keresztüli felhasználói kérések. Az internetkapcsolat és a helyszíni végpontok közötti bejövő felhasználói kapcsolatok engedélyezése, miközben a Microsoft 365-kapcsolatok ExpressRoute használatára kényszerítése jelentős útválasztási összetettséget jelent. Az ilyen összetett forgatókönyveket az ExpressRoute-on keresztül megvalósító ügyfelek túlnyomó többsége számára üzemeltetési szempontok miatt nem ajánlott. Ez a további többletterhelés magában foglalja az aszimmetrikus útválasztás kockázatainak kezelését, és megköveteli az útválasztási hirdetések és szabályzatok gondos kezelését több dimenzióban.
Frissítse a hálózati topológiatervet, hogy megmutassa, hogyan kerülheti el az aszimmetrikus útvonalakat
El szeretné kerülni az aszimmetrikus útválasztást, hogy a szervezet tagjai zökkenőmentesen használhassák a Microsoft 365-öt és más fontos szolgáltatásokat az interneten. Az ügyfelek két gyakori konfigurációval rendelkeznek, amelyek aszimmetrikus útválasztást okoznak. Ideje áttekinteni a használni kívánt hálózati konfigurációt, és ellenőrizni, hogy létezik-e ilyen aszimmetrikus útválasztási forgatókönyv.
Először is megvizsgálunk néhány különböző helyzetet, amelyek az alábbi hálózati diagramhoz kapcsolódnak. Ebben a diagramban minden bejövő kérést fogadó kiszolgáló, például az ADFS vagy a helyszíni hibrid kiszolgálók a New Jersey adatközpontban találhatók, és az interneten vannak meghirdetve.
Bár a szegélyhálózat biztonságos, a bejövő kérésekhez nem érhető el forrás NAT.
A New Jersey-i adatközpont kiszolgálói az internetes és az ExpressRoute-útvonalakat is láthatják.
Javaslatokkal is rendelkezünk a javításukhoz.
1. probléma: Felhő és helyszíni kapcsolat az interneten keresztül
Az alábbi ábrán az aszimmetrikus hálózati elérési út látható, ha a hálózati konfiguráció nem biztosít NAT-ot a Microsoft-felhőből az interneten keresztül érkező bejövő kérésekhez.
A Microsoft 365 bejövő kérése lekéri a helyszíni végpont IP-címét a nyilvános DNS-ből, és elküldi a kérést a szegélyhálózatnak.
Ebben a hibás konfigurációban nincs konfigurálva vagy elérhető forrás NAT azon a szegélyhálózaton, ahol a forgalom el lesz küldve, így a rendszer a tényleges forrás IP-címet használja a visszatérési célként.
A hálózaton lévő kiszolgáló az elérhető ExpressRoute-hálózati kapcsolaton keresztül irányítja át a visszatérő forgalmat a Microsoft 365-be.
Az eredmény a Microsoft 365 felé irányuló folyamat aszimmetrikus útvonala, amely megszakadt kapcsolatot eredményez.
1a. megoldás: Forrás NAT
Ha egyszerűen hozzáad egy forrás NAT-ot a bejövő kérelemhez, azzal megoldja a helytelenül konfigurált hálózatot. Ebben a diagramban:
A bejövő kérés továbbra is a New Jersey-i adatközpont szegélyhálózatán keresztül érkezik. Ezúttal a forrás NAT érhető el.
A kiszolgáló válasza az eredeti IP-cím helyett a forrás NAT-hoz társított IP-címre irányítja vissza, így a válasz ugyanazon a hálózati útvonalon tér vissza.
1b. megoldás: Útvonal hatókörének meghatározása
Másik lehetőségként dönthet úgy is, hogy nem engedélyezi az ExpressRoute BGP-előtagok meghirdetetté tételét, ezzel eltávolítva a számítógépek alternatív hálózati elérési útját. Ebben a diagramban:
A bejövő kérés továbbra is a New Jersey-i adatközpont szegélyhálózatán keresztül érkezik. A Microsoft által az ExpressRoute-kapcsolatcsoporton keresztül meghirdetett előtagok ezúttal nem érhetők el a New Jersey adatközpontban.
A kiszolgáló válasza az eredeti IP-címhez társított IP-címre irányítja vissza az egyetlen elérhető útvonalon keresztül, ami azt eredményezi, hogy a válasz ugyanazon a hálózati útvonalon tér vissza.
2. probléma: Felhő és helyszíni kapcsolat ExpressRoute-on keresztül
Az alábbi ábra azt az aszimmetrikus hálózati útvonalat mutatja be, amely akkor történik, amikor a hálózati konfiguráció nem biztosít NAT-ot a Microsoft-felhőből az ExpressRoute-on keresztül érkező bejövő kérésekhez.
A Microsoft 365 bejövő kérése lekéri az IP-címet a DNS-ből, és elküldi a kérést a szegélyhálózatnak.
Ebben a hibás konfigurációban nincs konfigurálva vagy elérhető forrás NAT azon a szegélyhálózaton, ahol a forgalom el lesz küldve, így a rendszer a tényleges forrás IP-címet használja a visszatérési célként.
A hálózatban lévő számítógép bármely elérhető ExpressRoute-hálózati kapcsolaton keresztül átirányítja a visszatérő forgalmat a Microsoft 365-be.
Az eredmény egy aszimmetrikus kapcsolat a Microsoft 365-höz.
2. megoldás: Forrás NAT
Ha egyszerűen hozzáad egy forrás NAT-ot a bejövő kérelemhez, azzal megoldja a helytelenül konfigurált hálózatot. Ebben a diagramban:
A bejövő kérés továbbra is a New York-i adatközpont szegélyhálózatán keresztül érkezik. Ezúttal a forrás NAT érhető el.
A kiszolgáló válasza az eredeti IP-cím helyett a forrás NAT-hoz társított IP-címre irányítja vissza, így a válasz ugyanazon a hálózati útvonalon tér vissza.
Papíron ellenőrizze, hogy a hálózat kialakítása rendelkezik-e elérésiút-szimmetriával
Ezen a ponton papíron ellenőriznie kell, hogy az implementációs terv útvonalszimmetriát biztosít-e a Microsoft 365-öt használó különböző forgatókönyvekhez. Azonosítani fogja azt a hálózati útvonalat, amelyet várhatóan akkor kell használni, ha egy személy a szolgáltatás különböző funkcióit használja. A helyszíni hálózattól és a WAN-útválasztástól a peremeszközökön át a kapcsolati útvonalig; ExpressRoute vagy az internet, valamint az online végponttal létesített kapcsolat.
Ezt az összes olyan Microsoft 365-ös hálózati szolgáltatás esetében el kell végeznie, amelyet korábban a szervezet által bevezetendő szolgáltatásként azonosítottak.
Segít, hogy ezt a tanulmányt végigvezeti az útvonalak egy második személy. Magyarázza el nekik, hogy az egyes hálózati ugrások honnan kapják meg a következő útvonalat, és győződjön meg arról, hogy ismeri az útválasztási útvonalakat. Ne feledje, hogy az ExpressRoute mindig több hatókörrel rendelkező útvonalat biztosít a Microsoft-kiszolgáló IP-címeinek, így alacsonyabb az útvonal költsége, mint az internetes alapértelmezett útvonal.
Ügyfélkapcsolat konfigurációjának megtervezése
Ha proxykiszolgálót használ az internethez kötött forgalomhoz, akkor módosítania kell a PAC- vagy ügyfélkonfigurációs fájlokat, hogy a hálózaton lévő ügyfélszámítógépek megfelelően legyenek konfigurálva a kívánt ExpressRoute-forgalomnak a Microsoft 365-be való továbbítására a proxykiszolgáló átvitele nélkül, és a fennmaradó forgalom , beleértve néhány Microsoft 365-forgalmat is, a rendszer a megfelelő proxynak küldi el. Olvassa el a Microsoft 365-végpontok, például a PAC-fájlok kezelésével kapcsolatos útmutatónkat.
Megjegyzés:
A végpontok gyakran, hetente változnak. Csak azoknak a szolgáltatásoknak és szolgáltatásoknak a alapján végezze el a módosításokat, amelyeket a szervezete elfogadott, hogy csökkentse a naprakész állapotban maradásához szükséges módosítások számát. Ügyeljen arra az RSS-hírcsatornában a hatálybalépési dátumra , ahol a változások bejelentése történik, és a korábbi változásokról nyilvántartást vezet, a bejelentett IP-címeket nem lehet meghirdetni vagy eltávolítani a hirdetésből, amíg el nem éri a hatálybalépési dátumot.
Útvonalszimmetria biztosítása
A Microsoft 365 előtér-kiszolgálók az interneten és az ExpressRoute-on is elérhetők. Ezek a kiszolgálók inkább expressRoute-kapcsolatcsoportokon keresztül visznek vissza a helyszínre, ha mindkettő elérhető. Emiatt lehetőség van az útvonal-aszimmetriára, ha a hálózatról érkező forgalom inkább az internetes kapcsolatcsoportokon halad át. Az aszimmetrikus útvonalak problémát jelentenek, mert az állapotalapú csomagvizsgálatot végző eszközök blokkolhatják a kimenő csomagoktól eltérő útvonalon érkező visszatérő forgalmat.
Függetlenül attól, hogy az interneten vagy az ExpressRoute-on keresztül kezdeményez kapcsolatot a Microsoft 365-höz, a forrásnak nyilvánosan átirányítható címnek kell lennie. Mivel sok ügyfél közvetlenül a Microsofttal társviszonyt létesít, nem valósítható meg olyan magáncímek használata, ahol duplikálás lehetséges az ügyfelek között.
Az alábbiakban a Microsoft 365 és a helyszíni hálózat közötti kommunikációt kezdeményezik. A hálózat kialakításának egyszerűsítése érdekében javasoljuk, hogy az alábbi útválasztást az internetes útvonalon keresztül hajtsa végre.
SMTP-szolgáltatások, például egy Exchange Online-bérlőből egy helyszíni gazdagépre küldött levelek vagy a SharePointból egy helyszíni gazdagépre küldött SharePoint Mail. Az SMTP protokollt szélesebb körben használják a Microsoft hálózatán belül, mint az ExpressRoute-kapcsolatcsoportokon megosztott útvonal-előtagok, és a helyszíni SMTP-kiszolgálók ExpressRoute-on keresztüli hirdetése hibákat okoz ezekkel a más szolgáltatásokkal.
ADFS a bejelentkezéshez használt jelszó érvényesítése során.
hibrid és/vagy Skype Vállalati verzió összevonás Skype Vállalati verzió.
Ahhoz, hogy a Microsoft visszairányuljon a hálózatra ezen kétirányú forgalomhoz, a helyszíni eszközökre irányuló BGP-útvonalakat meg kell osztani a Microsofttal. Amikor útválasztási előtagokat hirdet meg a Microsoftnak az ExpressRoute-on keresztül, kövesse az alábbi ajánlott eljárásokat:
Ne hirdetje meg ugyanazt a nyilvános IP-címútvonal-előtagot a nyilvános interneten és az ExpressRoute-on keresztül. Javasoljuk, hogy az EXPRESSRoute-on keresztül a Microsoftnak az IP BGP útvonalelőtag-hirdetései olyan tartományból származnak, amely egyáltalán nem van meghirdetve az interneten. Ha ez a rendelkezésre álló IP-címtér miatt nem érhető el, elengedhetetlen, hogy az ExpressRoute-on belül konkrétabb tartományt hirdessen meg, mint bármely internetes kapcsolatcsoport.
ExpressRoute-kapcsolatcsoportonként használjon külön NAT IP-készleteket, és válassza el őket az internetes kapcsolatcsoportoktól.
A Microsoft számára meghirdetett útvonalak a Microsoft hálózatának bármely kiszolgálójáról vonzzák a hálózati forgalmat, nem csak azokat, amelyek útvonalait az ExpressRoute-on keresztül hirdetik meg a hálózaton. Csak olyan kiszolgálókra hirdethet útvonalakat, ahol az útválasztási forgatókönyveket a csapata definiálja és jól értelmezi. Hirdessen külön IP-címútvonal-előtagokat a hálózattól több ExpressRoute-kapcsolatcsoport mindegyikén.
Magas rendelkezésre állás és feladatátvétel az Azure ExpressRoute-tal
Javasoljuk, hogy az ExpressRoute-tal rendelkező minden kimenő forgalomból legalább két aktív kapcsolatcsoportot építsen ki az ExpressRoute-szolgáltatónak. Ez a leggyakoribb hely, ahol hibákat látunk az ügyfelek számára, és könnyedén elkerülheti azokat egy aktív/aktív ExpressRoute-kapcsolatcsoport kiépítésével. Legalább két aktív/aktív internetes kapcsolatcsoport használatát is javasoljuk, mert számos Microsoft 365-szolgáltatás csak az interneten keresztül érhető el.
A hálózat kimenő forgalmi pontján számos más eszköz és kapcsolatcsoport található, amelyek kritikus szerepet játszanak abban, hogy az emberek hogyan érzékelik a rendelkezésre állást. A kapcsolati forgatókönyvek ezen részeit nem fedik le az ExpressRoute vagy a Microsoft 365 SLA-k, de kritikus szerepet játszanak a teljes körű szolgáltatás rendelkezésre állásában, ahogy azt a szervezet tagjai érzékelik.
A Microsoft 365-öt használó és üzemeltető személyekre összpontosítva, ha egy összetevő meghibásodása hatással lenne az emberek szolgáltatással kapcsolatos élményére, keressen módszereket az érintett személyek teljes százalékos arányának korlátozására. Ha egy feladatátvételi mód működési szempontból összetett, vegye figyelembe az emberek hosszú ideje tartó helyreállítási tapasztalatát, és keresse meg a működési szempontból egyszerű és automatizált feladatátvételi módokat.
A hálózaton kívül a Microsoft 365, az ExpressRoute és az ExpressRoute-szolgáltató is különböző rendelkezésre állási szintekkel rendelkezik.
Szolgáltatás rendelkezésre állása
A Microsoft 365-szolgáltatásokra jól meghatározott szolgáltatói szerződések vonatkoznak, amelyek az egyes szolgáltatások üzemidejét és rendelkezésre állási mérőszámait tartalmazzák. A Microsoft 365 egyik oka, hogy képes fenntartani az ilyen magas szolgáltatási rendelkezésre állási szinteket, az az, hogy az egyes összetevők zökkenőmentes feladatátvételt végezhetnek a microsoftos adatközpontok között a globális Microsoft-hálózat használatával. Ez a feladatátvétel az adatközponttól és a hálózattól a több internetes kimenő pontig terjed, és zökkenőmentes feladatátvételt tesz lehetővé a szolgáltatást használó személyek szempontjából.
Az ExpressRoute 99,9%-os rendelkezésre állási SLA-t biztosít a Microsoft Network Edge és az ExpressRoute-szolgáltató vagy -partnerinfrastruktúra közötti különálló dedikált kapcsolatcsoportokon. Ezek a szolgáltatási szintek az ExpressRoute-kapcsolatcsoport szintjén vannak alkalmazva, amely két független kapcsolatból áll a redundáns Microsoft-berendezések és a hálózatszolgáltatói berendezések között az egyes társviszony-létesítési helyeken.
Szolgáltató rendelkezésre állása
- A Microsoft szolgáltatásiszint-szabályozása megszűnik az ExpressRoute-szolgáltatónál vagy -partnernél. Ez az első hely, ahol olyan döntéseket hozhat, amelyek befolyásolják a rendelkezésre állási szintet. Alaposan ki kell értékelnie az ExpressRoute-szolgáltató által kínált architektúra-, rendelkezésre állási és rugalmassági jellemzőket a hálózat peremhálózata és a szolgáltatói kapcsolat között az egyes Microsoft társviszony-létesítési helyeken. Ügyeljen a redundancia logikai és fizikai aspektusaira, a társviszony-létesítési berendezésekre, a szolgáltató által biztosított WAN-kapcsolatcsoportokra, valamint az olyan további értékekkel rendelkező szolgáltatásokra, mint a NAT-szolgáltatások vagy a felügyelt tűzfalak.
A rendelkezésre állási terv megtervezése
Határozottan javasoljuk, hogy tervezze meg és tervezze meg a magas rendelkezésre állást és rugalmasságot a Microsoft 365 végpontok közötti kapcsolati forgatókönyveibe. A tervnek tartalmaznia kell;
Egyetlen meghibásodási pont sem, beleértve az internetes és az ExpressRoute-kapcsolatcsoportokat sem.
Az érintett személyek számának és időtartamának minimalizálása a várható meghibásodási módok esetében.
Optimalizálja az egyszerű, megismételhető és automatikus helyreállítási folyamatot a legtöbb előrejelezett hibaállapotból.
A hálózati forgalom és a funkciók teljes igényének támogatása redundáns útvonalakon keresztül, jelentős teljesítménycsökkenés nélkül.
A kapcsolódási forgatókönyveknek tartalmazniuk kell egy hálózati topológiát, amely a Microsoft 365 több független és aktív hálózati útvonalára van optimalizálva. Ez jobb teljes körű rendelkezésre állást eredményez, mint egy olyan topológia, amely csak az egyes eszközök vagy berendezések szintjén optimalizált redundanciára van optimalizálva.
Tipp
Ha a felhasználók több kontinensen vagy földrajzi régióban vannak elosztva, és mindegyik hely redundáns WAN-kapcsolatcsoportokon keresztül csatlakozik egy olyan helyszíni helyhez, ahol egyetlen ExpressRoute-kapcsolatcsoport található, a felhasználók kevesebb végpontok közötti szolgáltatás-rendelkezésre állást tapasztalnak, mint egy olyan hálózati topológiaterv, amely független ExpressRoute-kapcsolatcsoportokat tartalmaz, amelyek a különböző régiókat a legközelebbi társviszony-létesítési helyhez kötik.
Javasoljuk, hogy legalább két ExpressRoute-kapcsolatcsoportot építsen ki, és mindegyik kapcsolatcsoport más földrajzi társviszony-létesítési hellyel csatlakozik. Ezt az aktív-aktív kapcsolatcsoportot minden olyan régióhoz ki kell építenie, ahol a felhasználók ExpressRoute-kapcsolatot fognak használni a Microsoft 365-szolgáltatásokhoz. Ez lehetővé teszi, hogy minden régió kapcsolatban maradjon egy olyan katasztrófa során, amely hatással van egy nagyobb helyre, például egy adatközpontra vagy egy társviszony-létesítési helyre. Ha aktív/aktívként konfigurálja őket, a végfelhasználói forgalom több hálózati útvonal között is elosztható. Ez csökkenti az eszköz- vagy hálózati berendezések kimaradása során érintett személyek körét.
Nem javasoljuk, hogy egyetlen ExpressRoute-kapcsolatcsoportot használjon az internettel biztonsági mentésként.
Példa: Feladatátvétel és magas rendelkezésre állás
A Contoso több földrajzi kialakítását áttekintette az útválasztás, a sávszélesség, a biztonság, és most egy magas rendelkezésre állású felülvizsgálaton kell átesnie. A Contoso három kategóriába sorolja a magas rendelkezésre állást; rugalmasság, megbízhatóság és redundancia.
A rugalmasság lehetővé teszi, hogy a Contoso gyorsan helyreálljon a hibák után. A megbízhatóság lehetővé teszi, hogy a Contoso konzisztens eredményt biztosítson a rendszeren belül. A redundancia lehetővé teszi a Contoso számára az áthelyezést egy vagy több tükrözött infrastruktúrapéldány között.
A Contoso minden peremhálózati konfigurációban redundáns tűzfalakat, proxykat és IDS-t használ. A Észak-Amerika esetében a Contoso egy peremhálózati konfigurációval rendelkezik a Dallas-adatközpontban, egy másik peremhálózati konfigurációval pedig a Virginia-adatközpontban. Az egyes helyek redundáns berendezései rugalmasságot biztosítanak az adott helyhez.
A Contoso hálózati konfigurációja néhány alapelvre épül:
Minden földrajzi régióban több Azure ExpressRoute-kapcsolatcsoport található.
A régión belüli minden kapcsolatcsoport támogatja az adott régión belüli összes hálózati forgalmat.
Az útválasztás a rendelkezésre állástól, a helytől és egyebektől függően egyértelműen az egyik vagy a másik útvonalat részesíti előnyben.
Az Azure ExpressRoute-kapcsolatcsoportok közötti feladatátvétel automatikusan, a Contoso által igényelt további konfiguráció vagy művelet nélkül történik.
Az internetes kapcsolatcsoportok közötti feladatátvétel automatikusan történik a Contoso által megkövetelt további konfiguráció vagy művelet nélkül.
Ebben a konfigurációban a fizikai és virtuális szintű redundanciával a Contoso megbízható módon képes helyi rugalmasságot, regionális rugalmasságot és globális rugalmasságot nyújtani. A Contoso ezt a konfigurációt választotta, miután kiértékelte a régiónkénti egyetlen Azure ExpressRoute-kapcsolatcsoportot, valamint az internetes feladatátvétel lehetőségét.
Ha a Contoso régiónként nem tud több Azure ExpressRoute-kapcsolatcsoportot létrehozni, a Észak-Amerika-ből származó forgalom átirányítása a csendes-óceáni Azure ExpressRoute-kapcsolatcsoporthoz elfogadhatatlan mértékű késést eredményezne, és a szükséges DNS-továbbító konfiguráció összetettebbé tenné a forgalmat.
Az internet biztonsági mentési konfigurációként való használata nem ajánlott. Ez megtöri a Contoso megbízhatósági elvét, ami inkonzisztens felhasználói élményt eredményez a kapcsolat használatakor. Emellett manuális konfigurációra lenne szükség a feladatátvételhez, figyelembe véve a konfigurált BGP-hirdetéseket, a NAT-konfigurációt, a DNS-konfigurációt és a proxykonfigurációt. Ez a feladatátvétel összetettsége megnöveli a helyreállításhoz szükséges időt, és csökkenti az érintett lépések diagnosztizálásának és hibaelhárításának képességét.
Továbbra is kérdései vannak a forgalomkezelés vagy az Azure ExpressRoute tervezésével és megvalósításával kapcsolatban? Olvassa el a hálózatra és teljesítményre vonatkozó útmutatónk többi részét vagy az Azure ExpressRoute gyakori kérdéseit.
Biztonsági vezérlők alkalmazása az Azure ExpressRoute-ra Microsoft 365-forgatókönyvekhez
Az Azure ExpressRoute-kapcsolatok biztonságossá tétele ugyanazokkal az elvekkel kezdődik, mint az internetkapcsolat biztonságossá tétele. Számos ügyfél úgy dönt, hogy hálózati és szegélyhálózati vezérlőket helyez üzembe az ExpressRoute-útvonalon, amely összeköti a helyszíni hálózatot a Microsoft 365-tel és más Microsoft-felhőkkel. Ezek a vezérlők lehetnek tűzfalak, alkalmazásproxyk, adatszivárgás-megelőzés, behatolásészlelés, behatolásmegelőző rendszerek stb. Az ügyfelek sok esetben különböző szintű vezérlőket alkalmaznak a Helyszíni forgalomból a Microsoft felé indított forgalomra, szemben a Microsoft által kezdeményezett forgalommal, amely az ügyfél helyszíni hálózatára irányítja az ügyfelet, szemben az általános internetes célhelyre történő helyszíni forgalommal.
Íme néhány példa a biztonságnak az üzembe helyezésre kiválasztott ExpressRoute-kapcsolati modellel való integrálására.
| ExpressRoute-integrációs lehetőség | Hálózati biztonsági szegélyhálózati modell |
|---|---|
| Közös elhelyezés felhőbeli cserén |
Telepítsen új biztonsági/szegélyhálózati infrastruktúrát abban a közös elhelyezési létesítményben, ahol az ExpressRoute-kapcsolat létrejön. A közös elhelyezési létesítményt kizárólag útválasztási/összekapcsolási célokra, valamint a közös elhelyezési létesítményből a helyszíni biztonsági/szegélyhálózati infrastruktúrába irányuló visszahúzási kapcsolatokhoz használja. |
| Pont–pont Ethernet |
Állítsa le a pont–pont ExpressRoute-kapcsolatot a meglévő helyszíni biztonsági/szegélyhálózati infrastruktúra helyén. Telepítsen új, az ExpressRoute-útvonalra jellemző biztonsági/szegélyhálózati infrastruktúrát, és ott állítsa le a pont–pont kapcsolatot. |
| Any-to-Any IPVPN |
Használjon meglévő helyszíni biztonsági/szegélyhálózati infrastruktúrát minden olyan helyen, amely a Microsoft 365-höz készült ExpressRoute-kapcsolathoz használt IPVPN-be lép. A Microsoft 365-höz készült ExpressRoute-hoz használt IPVPN-t a biztonság/szegélyhálózatként kijelölt meghatározott helyszíni helyekre rögzítse. |
Egyes szolgáltatók felügyelt biztonsági/szegélyhálózati funkciókat is kínálnak az Azure ExpressRoute-tal való integrációs megoldások részeként.
A Microsoft 365-kapcsolatokhoz használt ExpressRoute-kapcsolatokhoz használt hálózati/biztonsági szegélyhálózati beállítások topológiaelhelyezésének mérlegelésekor az alábbiakban további szempontokat kell figyelembe venni
A hálózati/biztonsági vezérlők mélysége és típusa hatással lehet a Microsoft 365 felhasználói élményének teljesítményére és méretezhetőségére.
A kimenő (helyszíni-Microsoft>) és a bejövő (Microsoft-on-premises>) [ha engedélyezve van] folyamatok eltérő követelményekkel rendelkezhetnek. Ezek valószínűleg eltérnek az általános internetes célhelyek felé irányuló kimenő forgalomtól.
A Microsoft 365 portokra/protokollokra és a szükséges IP-alhálózatokra vonatkozó követelményei azonosak, függetlenül attól, hogy a forgalmat a Microsoft 365-höz készült ExpressRoute-on vagy az interneten keresztül irányítják.
Az ügyfélhálózat/biztonsági vezérlők topológiai elhelyezése határozza meg a felhasználó és a Microsoft 365 szolgáltatás közötti végső végpontok közötti hálózatot, és jelentős hatással lehet a hálózati késésre és a torlódásra.
Az ügyfeleknek javasoljuk, hogy tervezzék meg a biztonsági/peremhálózati topológiát a Microsoft 365-höz készült ExpressRoute-tal való használatra a redundancia, a magas rendelkezésre állás és a vészhelyreállítás ajánlott eljárásainak megfelelően.
Íme egy példa a Contoso-ra, amely összehasonlítja a különböző Azure ExpressRoute-kapcsolati lehetőségeket a fent tárgyalt szegélyhálózati biztonsági modellekkel.
Példa: Az Azure ExpressRoute biztonságossá tétele
A Contoso az Azure ExpressRoute implementálását fontolgatja, és miután megtervezte a Microsoft 365-höz készült ExpressRoute optimális architektúráját, és miután a fenti útmutató segítségével megismerte a sávszélességre vonatkozó követelményeket, ők határozzák meg a peremhálózat védelmének legjobb módját.
A Contoso, egy több országra kiterjedő, több kontinensen található szervezet esetében a biztonságnak az összes szegélyhálózatra kiterjednie kell. A Contoso számára az optimális csatlakozási lehetőség egy több pontból álló kapcsolat, amely világszerte több társviszony-létesítési hellyel rendelkezik az egyes kontinenseken dolgozó alkalmazottaik igényeinek kiszolgálása érdekében. Minden kontinens redundáns Azure ExpressRoute-kapcsolatcsoportokat tartalmaz a kontinensen belül, és a biztonságnak ezek mindegyikére ki kell terjednie.
A Contoso meglévő infrastruktúrája megbízható, és képes kezelni a többletmunkát, így a Contoso képes használni az infrastruktúrát az Azure ExpressRoute-hoz és az internet peremhálózati biztonságához. Ha nem ez a helyzet, a Contoso dönthet úgy, hogy további berendezéseket vásárol a meglévő berendezések kiegészítéséhez vagy egy másik típusú kapcsolat kezeléséhez.
Sávszélesség-tervezés az Azure ExpressRoute-hoz
Minden Microsoft 365-ügyfélnek egyedi sávszélességre van szüksége attól függően, hogy hányan tartózkodnak az egyes helyeken, milyen aktívak az egyes Microsoft 365-alkalmazásokkal, valamint egyéb tényezőktől, például a helyszíni vagy hibrid berendezések használatától és a hálózati biztonsági konfigurációktól függően.
A túl kevés sávszélesség torlódást, adatátadásokat és kiszámíthatatlan késéseket eredményez. A túl nagy sávszélesség szükségtelen költségekhez vezet. Egy meglévő hálózaton a sávszélességre gyakran hivatkoznak a kapcsolatcsoporton elérhető átjárótér mennyisége százalékban kifejezve. A 10%-os fejtér valószínűleg torlódást okoz, és a 80%-os fejtér általában szükségtelen költségeket jelent. A főszobai célfoglalások jellemzően 20–50%-osak.
A megfelelő sávszélesség-szint megtalálásához a legjobb mechanizmus a meglévő hálózathasználat tesztelése. Ez az egyetlen módja annak, hogy valódi használati és igénymérést kapjon, mivel minden hálózati konfiguráció és alkalmazás bizonyos szempontból egyedi. Méréskor érdemes nagy figyelmet fordítani a teljes sávszélesség-használatra, a késésre és a TCP-torlódásra, hogy megértse a hálózati igényeket.
Ha már rendelkezik az összes hálózati alkalmazást tartalmazó becsült alapkonfigurációval, tesztelje a Microsoft 365-öt egy kis csoporttal, amely a szervezeten belüli személyek különböző profiljait tartalmazza a tényleges használat meghatározásához, és a két mérés alapján becsülje meg az egyes irodai helyekhez szükséges sávszélességet. Ha késési vagy TCP-torlódási problémák merülnek fel a tesztelés során, előfordulhat, hogy közelebb kell helyeznie a kimenő forgalmat a Microsoft 365-öt használó felhasználókhoz, vagy el kell távolítania az intenzív hálózatvizsgálatot, például az SSL-visszafejtést/vizsgálatot.
A javasolt hálózati feldolgozás típusával kapcsolatos összes javaslatunk az ExpressRoute-ra és az internetes kapcsolatcsoportokra is vonatkozik. Ugyanez igaz a teljesítmény-finomhangolási oldalunkon található többi útmutatóra is.
Üzembe helyezési és tesztelési eljárások létrehozása
Az implementációs tervnek magában kell foglalnia a tesztelési és a visszaállítási tervezést is. Ha a megvalósítás nem a várt módon működik, a tervet úgy kell megtervezni, hogy a problémák észlelése előtt a legkevesebb embert befolyásolja. Az alábbiakban néhány magas szintű alapelvet érdemes figyelembe vennie.
A hálózati szegmens és a felhasználói szolgáltatás előkészítésének előkészítése a fennakadások minimalizálása érdekében.
Tervezze meg az útvonalak tesztelését traceroute-tal és TCP-kapcsolattal egy külön internetkapcsolattal rendelkező gazdagépről.
Lehetőleg a bejövő és kimenő szolgáltatások tesztelését egy elkülönített teszthálózaton kell elvégezni egy Microsoft 365-bérlővel.
Azt is megteheti, hogy éles hálózaton tesztel, ha az ügyfél még nem használja a Microsoft 365-öt, vagy próbaüzemben van.
Másik lehetőségként a tesztelés elvégezhető olyan éles üzemkimaradások során is, amelyek csak tesztelésre és monitorozásra vannak elkülönítve.
Másik lehetőségként a tesztelés elvégezhető az egyes szolgáltatások útvonalainak ellenőrzésével minden 3. rétegbeli útválasztó-csomóponton. Ezt a visszaesést csak akkor szabad használni, ha más tesztelés nem lehetséges, mivel a fizikai tesztelés hiánya kockázatot jelent.
Üzembehelyezési eljárások létrehozása
Az üzembehelyezési eljárásokat szakaszosan kell bevezetni a felhasználók kis csoportjaira, hogy lehetővé tegyék a tesztelést, mielőtt nagyobb csoportokat helyeznek üzembe. Az ExpressRoute üzembe helyezésének több módja is van az alábbiakban.
Állítsa be az ExpressRoute-ot a Microsoft társviszony-létesítéssel, és az útvonalhirdetéseket csak szakaszos tesztelés céljából továbbítsa egyetlen gazdagépre.
Először az ExpressRoute-hálózatra vezető útvonalakat hirdesse egyetlen hálózati szegmensre, majd bontsa ki az útvonalhirdetéseket hálózati szegmensek vagy régiók szerint.
Ha első alkalommal telepíti a Microsoft 365-öt, az ExpressRoute-hálózat üzembe helyezését néhány személy próbaüzemeként használhatja.
Proxykiszolgálók használata esetén úgy is konfigurálhat egy teszt PAC-fájlt, hogy néhány felhasználót teszteléssel és visszajelzéssel irányítsa az ExpressRoute-ra, mielőtt továbbiakat ad hozzá.
Az implementációs tervnek ki kell sorolnia az összes olyan üzembehelyezési eljárást, amelyet el kell végezni, vagy olyan parancsokat, amelyeket a hálózati konfiguráció üzembe helyezéséhez kell használni. Amikor a hálózati szolgáltatáskimaradás ideje megérkezik, az összes módosítást az előre megírt és a szakértői értékelésben szereplő írásos üzembehelyezési tervnek kell elvégeznie. Tekintse meg az ExpressRoute műszaki konfigurációjára vonatkozó útmutatónkat.
Az SPF TXT rekordok frissítése, ha módosította bármely olyan helyszíni kiszolgáló IP-címét, amely továbbra is e-mailt fog küldeni.
A helyszíni kiszolgálók DNS-bejegyzéseinek frissítése, ha az IP-címeket az új NAT-konfigurációnak megfelelően módosította.
Győződjön meg arról, hogy feliratkozott a Microsoft 365-végpontértesítések RSS-hírcsatornájára az útválasztási vagy proxykonfigurációk fenntartása érdekében.
Az ExpressRoute üzembe helyezésének befejezése után a teszttervben szereplő eljárásokat végre kell hajtani. Az egyes eljárások eredményeit naplózni kell. Ha a tesztterv eredményei azt mutatják, hogy az implementáció nem sikerült, az eredeti éles környezetbe való visszagördülésre vonatkozó eljárásokat kell tartalmaznia.
A tesztelési eljárások összeállítása
A tesztelési eljárásoknak tartalmazniuk kell teszteket a Microsoft 365 minden kimenő és bejövő hálózati szolgáltatásához, amelyek az ExpressRoute-ot fogják használni, és azokat is, amelyek nem. Az eljárásoknak magukban kell foglalniuk a tesztelést minden egyedi hálózati helyről, beleértve azokat a felhasználókat is, akik nem helyszíniek a vállalati helyi hálózaton.
Néhány példa a tesztelési tevékenységekre:
Pingeljen a helyszíni útválasztóról a hálózati operátor útválasztójára.
Ellenőrizze, hogy a helyszíni útválasztó megkapja-e az 500+ Microsoft 365 és CRM Online IP-címmel kapcsolatos hirdetéseket.
Ellenőrizze, hogy a bejövő és kimenő NAT működik-e az ExpressRoute és a belső hálózat között.
Ellenőrizze, hogy a NAT-hoz vezető útvonalak meghirdetve vannak-e az útválasztóról.
Ellenőrizze, hogy az ExpressRoute elfogadta-e a meghirdetett előtagokat.
- A társviszony-létesítési hirdetések ellenőrzéséhez használja a következő parancsmagot:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringEllenőrizze, hogy a nyilvános NAT IP-címtartomány nincs-e meghirdetve a Microsoft számára semmilyen más ExpressRoute- vagy nyilvános internetes hálózati kapcsolatcsoporton keresztül, kivéve, ha az egy nagyobb tartomány adott részhalmaza, mint az előző példában.
Az ExpressRoute-kapcsolatcsoportok párosítva vannak, és ellenőrizze, hogy mindkét BGP-munkamenet fut-e.
Állítson be egyetlen gazdagépet a NAT belsejében, és használja a ping, tracert és tcpping parancsot az új kapcsolatcsoport és a gazdagép outlook.office365.com közötti kapcsolat teszteléséhez. Másik lehetőségként használhat egy eszközt, például a Wiresharkot vagy a Microsoft Network Monitor 3.4-et az MSEE tükrözött portján annak ellenőrzésére, hogy tud-e csatlakozni a outlook.office365.com társított IP-címhez.
Alkalmazásszintű funkciók tesztelése Exchange Online.
Tesztelje, hogy az Outlook képes-e csatlakozni Exchange Online és e-maileket küldeni/fogadni.
Tesztelje, hogy az Outlook képes-e online módot használni.
Tesztelje az okostelefonok kapcsolatát és a küldési/fogadási képességet.
- Alkalmazásszintű funkciók tesztelése a SharePointban
Tesztelje OneDrive Vállalati verzió szinkronizálási ügyfelet.
A SharePoint webes hozzáférésének tesztelése.
- Alkalmazásszintű funkciók tesztelése Skype Vállalati verzió hívási forgatókönyvekhez:
Csatlakozzon a konferenciahíváshoz hitelesített felhasználóként [a meghívást a végfelhasználó kezdeményezte].
Felhasználó meghívása konferenciahívásra [az MCU-ból küldött meghívás].
Csatlakozzon a konferenciához névtelen felhasználóként a Skype Vállalati verzió webalkalmazással.
Csatlakozzon a híváshoz vezetékes PC-kapcsolatról, IP-telefonról és mobileszközről.
Hívás összevont felhasználónak o PsTN-érvényesítés hívása: a hívás befejeződött, a hívás minősége elfogadható, a kapcsolati idő elfogadható.
Ellenőrizze, hogy a partnerek jelenléti állapota frissült-e a bérlői és az összevont felhasználók esetében is.
Gyakori problémák
Az aszimmetrikus útválasztás a leggyakoribb megvalósítási probléma. Íme néhány gyakori forrás, amelyeket érdemes keresni:
Nyílt vagy lapos hálózati útválasztási topológia használata forrás NAT nélkül.
Nem használ SNAT-t a bejövő szolgáltatásokhoz való átirányításhoz az interneten és az ExpressRoute-kapcsolatokon keresztül.
Nem teszteli a bejövő szolgáltatásokat az ExpressRoute-on egy teszthálózaton a széles körű üzembe helyezés előtt.
ExpressRoute-kapcsolat üzembe helyezése a hálózaton keresztül
Az üzembe helyezést egyszerre a hálózat egy szegmensére bonthatja, és fokozatosan bevezetheti a hálózat különböző részeihez való csatlakozást, és tervben van az egyes új hálózati szegmensek visszaállításának terve. Ha az üzemelő példány egy Microsoft 365-ös üzemelő példányhoz van igazítva, először a Microsoft 365 próbafelhasználói számára telepítse, és onnan terjedjen ki.
Először a teszthez, majd az éles környezethez:
Az ExpressRoute engedélyezéséhez futtassa az üzembehelyezési lépéseket.
Ellenőrizze, hogy a hálózati útvonalak a vártak-e.
Végezzen tesztelést minden bejövő és kimenő szolgáltatáson.
Visszaállítás, ha bármilyen problémát észlel.
Tesztkapcsolat beállítása az ExpressRoute-hoz egy teszthálózati szegmenssel
Most, hogy elkészült a terv papíron, ideje kis léptékben tesztelni. Ebben a tesztben egyetlen ExpressRoute-kapcsolatot fog létesíteni a Microsoft Társviszony-létesítéssel a helyszíni hálózat tesztalhálózatához. Konfigurálhat egy próbaverziós Microsoft 365-bérlőt a tesztalhálózathoz való csatlakozással, és belefoglalhatja az összes kimenő és bejövő szolgáltatást, amelyet éles környezetben fog használni a tesztalhálózatban. Állítsa be a DNS-t a teszthálózati szegmenshez, és hozza létre az összes bejövő és kimenő szolgáltatást. Hajtsa végre a teszttervet, és győződjön meg arról, hogy ismeri az egyes szolgáltatások útválasztását és az útvonalpropagálást.
Az üzembe helyezési és tesztelési tervek végrehajtása
A fent leírt elemek elvégzése során ellenőrizze az elvégzett területeket, és győződjön meg arról, hogy Ön és csapata áttekintette őket az üzembehelyezési és tesztelési tervek végrehajtása előtt.
A hálózatváltozásban érintett kimenő és bejövő szolgáltatások listája.
A globális hálózati architektúra ábrája az internetes kimenő forgalomról és az ExpressRoute meet-me helyéről.
Hálózati útválasztási diagram az egyes üzembe helyezett szolgáltatásokhoz használt különböző hálózati útvonalakról.
Üzembe helyezési terv a módosítások implementálásának és szükség esetén a visszaállításnak a lépéseivel.
Tesztelési terv az egyes Microsoft 365-ös és hálózati szolgáltatások teszteléséhez.
A bejövő és kimenő szolgáltatások éles útvonalainak papíralapú ellenőrzése befejeződött.
Befejezett teszt egy teszthálózati szegmensben, beleértve a rendelkezésre állási tesztelést is.
Válasszon ki egy kimaradási időszakot, amely elég hosszú ahhoz, hogy a teljes üzembe helyezési terven és a tesztelési terven végig fusson, van némi ideje a hibaelhárításhoz és a visszaállításhoz, ha szükséges.
Figyelem!
Az interneten és az ExpressRoute-on keresztüli útválasztás összetett jellegéből adódóan javasoljuk, hogy az összetett útválasztás hibaelhárításához további pufferidőt adjon hozzá ehhez az ablakhoz.
QoS konfigurálása Skype Vállalati verzió Online-hoz
A QoS szükséges az Skype Vállalati verzió Online hang- és értekezleti előnyeinek eléréséhez. A QoS konfigurálható, miután meggyőződett arról, hogy az ExpressRoute hálózati kapcsolata nem blokkolja a többi Microsoft 365-szolgáltatáshoz való hozzáférést. A QoS konfigurációját az ExpressRoute és a QoS az Skype Vállalati verzió Online-ban című cikkben ismertetjük.
Az implementáció hibaelhárítása
Elsőként az ebben az implementációs útmutatóban szereplő lépéseket kell megvizsgálnia, hogy kimaradt-e a megvalósítási tervből? Vissza, és ha lehetséges, futtasson további kis hálózati teszteket a hiba replikálásához és hibakereséséhez.
Azonosítsa, hogy mely bejövő vagy kimenő szolgáltatások hiúsultak meg a tesztelés során. Kérje le kifejezetten a sikertelen szolgáltatások IP-címeit és alhálózatait. Haladjon végig papíron a hálózati topológia diagramon, és ellenőrizze az útválasztást. Ellenőrizze, hogy az ExpressRoute-útválasztás hol van meghirdetve. Ha lehetséges, tesztelje az útválasztást a szolgáltatáskimaradás során nyomkövetésekkel.
Futtassa a PSPing parancsot egy hálózati nyomkövetéssel az egyes ügyfélvégpontokhoz, és értékelje ki a forrás- és cél IP-címeket annak ellenőrzéséhez, hogy a vártnak megfelelően vannak-e. Futtassa a telnetet a 25-ös porton elérhetővé tott bármely levelezési gazdagépen, és ellenőrizze, hogy az SNAT elrejti-e az eredeti forrás IP-címét, ha ez várható.
Ne feledje, hogy a Microsoft 365 ExpressRoute-kapcsolattal történő üzembe helyezésekor gondoskodnia kell arról, hogy az ExpressRoute hálózati konfigurációja optimális legyen, és a hálózat többi összetevőjét, például az ügyfélszámítógépeket is optimalizálta. Amellett, hogy ezt a tervezési útmutatót használja a kihagyott lépések hibaelhárításához, a Microsoft 365 teljesítményével kapcsolatos hibaelhárítási tervet is írtunk.
Íme egy rövid hivatkozás, a segítségével visszatérhet: https://aka.ms/implementexpressroute365
Kapcsolódó témakörök
A Microsoft 365 hálózati adatkapcsolat felmérése
Microsoft 365-höz készült Azure ExpressRoute
Médiaminőség és hálózati kapcsolati teljesítmény az Skype Vállalati verzió Online-ban
A hálózat optimalizálása az Skype Vállalati verzió Online-hoz
ExpressRoute és QoS az Skype Vállalati verzió Online-ban
Hívási folyamat az ExpressRoute használatával
A Microsoft 365 teljesítményhangolása alaptervek és teljesítményelőzmények használatával
Teljesítménnyel kapcsolatos hibaelhárítási terv a Microsoft 365-höz
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: