ExpressRoute for Office 365 juurutamine

ExpressRoute for Office 365 pakub alternatiivset marsruutimisteed mitme võrgu poole suunatud Office 365 teenuse jaoks. ExpressRoute for Office 365-e arhitektuuri aluseks on Internetis juba saadaolevate Office 365 teenuste IP-aadresside eesliidete saadavusest teatamine ettevalmistatud ExpressRoute‘i kanalitele, et need IP-aadresside eesliited teie võrgus laiali jaotada. ExpressRoute võimaldab paljude Office 365 teenuste jaoks lubada mitu eri marsruutimisteed Interneti ja ExpressRoute‘i kaudu. Teie võrgu marsruutimise olek võib sõltuvalt sisevõrgu topoloogia ülesehitusest oluliselt muutuda.

Olek: Täielik juhend (v2)

ExpressRoute for Office 365-e juurutust tuleb hoolikalt plaanida, et see suudaks keerukate võrguolude korral tagada marsruutimise saadavuse nii eriotstarbelise kanali kaudu, mille marsruudid sisestatakse põhivõrku, kui ka Interneti kaudu. Kui teie meeskond ei vii läbi selles juhendis kirjeldatud üksikasjalikku plaanimis- ja testimistoiminguid, on suur oht, et ExpressRoute‘i kanali sisselülitamisel muutuvad Office 365 teenused ajutiselt või täielikult kättesaamatuks.

Edukaks juurutamiseks on vaja taristu vajadusi analüüsida, võrku ja selle ülesehitust põhjalikult hinnata, kasutuselevõttu hoolikalt etapiviisiliselt plaanida ja koostada üksikasjalik valideerimis- ja testimisplaan. Suurte hajutatud keskkondade korral võib juurutamiseks kuluda mitu kuud. Selle juhendi eesmärk on aidata teil plaanida.

Suurte edukate juurutuste plaanimine võib võtta kuus kuud ja hõlmab sageli liikmeid ettevõtte eri valdkondadest, sh võrguspetsialistid, tulemüüri ja puhverserverite administraatorid, Office 365 administraatorid, turve, lõppkasutaja tugiteenused, projektihaldus ja juhtkonna abi. Plaanimisse investeerimine aitab vältida olukordi, kus töös esineb juurutamisvigu, mis põhjustavad seisakuid või mille tõttu tuleb teha keerukaid ja kulukaid tõrkeotsinguid.

Enne selle juurutamisjuhendi alustamist peaksid olema täidetud järgmised eeltingimused.

  1. Olete võrku hinnanud ja veendunud, et ExpressRoute oleks soovitatav ja sobiv.

  2. Olete valinud ExpressRoute'i võrguteenuse pakkuja. Hankige lisateavet ExpressRoute‘i partnerite ja võrgujagamiskohtade kohta.

  3. Olete lugenud ExpressRoute‘i dokumentatsiooni ja teie sisevõrk vastab täies ulatuses ExpressRoute‘i tingimustele.

  4. Teie meeskond on lugenud avalikke juhiseid ja dokumente lehtedel https://aka.ms/expressrouteoffice365 ja https://aka.ms/ert ning vaadanud saidil Channel 9 Azure ExpressRoute for Office 365-e koolitussarja järgmistest oluliste tehniliste üksikasjade mõistmiseks:

    • SaaS-teenuste seos Internetiga;

    • asümmeetriliste marsruutide vältimine ja keerukate marsruutimiste haldamine;

    • perimeetriturbe, saadavuse ja rakendusetaseme kontrolli kombineerimine.

Esialge nõuetega tutvumine

Alustuseks selgitage välja, milliseid funktsioone ja teenuseid plaanite oma ettevõttes kasutama hakata. Teil tuleb kindlaks teha, milliseid Office 365 teenuste funktsioone kasutama hakatakse ja millistes võrguosades nende funktsioonide kasutajaid majutatakse. Stsenaariumide kataloogis saate iga stsenaariumi jaoks lisada võrguatribuudid (nt sissetulevad ja väljaminevad võrguliiklusvood ja Office 365 lõpp-punktide saadavus ExpressRoute‘i kaudu).

Ettevõtte vajaduste väljaselgitamiseks tehke järgmist.

  • Kaardistage teie ettevõttes kasutusel olevate Office 365 teenuste sissetulev ja väljaminev võrguliiklus. Uurige Office 365 URL-ide ja IP-aadresside vahemike lehelt eri Office 365 stsenaariumide liiklusvoogude kirjeldusi.

  • Koostage olemasoleva võrgutopoloogia dokumentatsioon, kus kajastuks üksikasjad sisemise WAN-võrgu tuuma ja topoloogia, satelliitsaitide ühenduvuse, lõppkasutajate ühenduvuse, võrgu perimeetri väljumispunktidesse marsruutimise ja puhverserveri teenuste kohta.

    • Määrake võrguskeemil sissetulevate teenuste lõpp-punktid, millega Office 365 ja muud Microsofti teenused ühenduse loovad, ning märkige ära nii Interneti kui ka eeldatavad ExpressRoute‘i kaudu loodavad ühenduseteed.

    • Selgitage välja kasutajate geograafilised asukohad ja WAN-võrgu ühenduvus nendes kohtades, samuti see, kus on praegu väljumispunktid Internetti ja kus võiks eelduste kohaselt olla väljumispunktid ExpressRoute‘i võrgujagamiskeskkonda.

    • Tehke kindlaks kõik perimeeterseadmed (nt puhverserverid, tulemüürid) ja kaardistage nende seosed Interneti ja ExpressRoute‘i voogude kontekstis.

    • Selgitage välja, kas kasutajad pääsevad Interneti ja ExpressRoute‘i voogude raames Office 365 teenustele juurde otsese või kaudse rakenduste puhverserveri kaudu.

  • Lisage võrguskeemile rentniku asukoht ja MMR-i asukohad.

  • Leidke hinnanguline ja tegelik võrgujõudlus ning latentsusaeg Office 365 teenuste olulisemates kasutuskohtades. Pidage meeles, et Office 365 sisaldab globaalselt levivaid teenuseid ja kasutajad võivad ühenduse luua rentnikust erinevates kohtades. Seetõttu on soovitatav lähtuda kasutaja ja talle Interneti või ExpressRoute‘i kaudu lähima Microsofti globaalse võrgu serva vahelisest latentsusajast. Selle juures aitavad teid võrgu hindamise tulemused.

  • Loetlege ettevõtte võrgu turbe ja kättesaadavuse nõuded, millele uus ExpressRoute‘i ühendus kindlasti vastama peab. Pange paika näiteks see, kuidas kasutajad Office 365 keskkonnale Interneti väljumispunkti või ExpressRoute‘i tõrke korral juurde pääsevad.

  • Kaardistage, millised Office 365 sissetulevad ja väljaminevad vood kasutavad Internetti ja millised ExpressRoute‘i. Võimalik, et kasutajate geograafilistest asukohtadest ja kohapealse võrgu topoloogiast tulenevalt peab eri kasutuskohtade jaoks looma erinevad plaanid.

Võrgu marsruutimise ja muude keerukate protsesside minimeerimiseks soovitame kasutada ExpressRoute for Office 365-e ainult nende võrguliiklusvoogude jaoks, mis peavad regulatiivsete nõuete tõttu või võrgu hindamistulemite põhjal spetsiaalse ühenduse kaudu kulgema. Lisaks soovitame ExpressRoute‘i marsruutida etapikaupa ja tegeleda sissetuleva ja väljamineva võrguliiklusega juurutamise käigus eri projektide raames. Juurutage ExpressRoute for Office 365 ainult kasutaja algatatava väljaminevate võrguliiklusvoogude jaoks ja jätke sissetulevad liiklusvood Internetti. Nii saate topoloogia keerukust kontrolli all hoida ja vähendada täiendavate asümmeetriliste marsruutimisvõimaluste lisandumist.

Teie võrguliikluse kataloogis peaks olema loetletud kõik kohapealse võrgu ja Microsofti vahelised sissetulevad ja väljaminevad ühendused.

  • Väljaminevad ühendused hõlmavad selliseid ühendusi, mis algatatakse kohapealses keskkonnas (nt sisevõrgu klientrakenduses või serveris) Microsofti teenuste suunas. Need ühendused võivad olla suunatud Office 365 keskkonda otse või kaudselt, näiteks juhul kui ühendus kulgeb puhverserverite, tulemüüride või muude Office 365 teele jäävate võrgusüsteemide.

  • Sissetulevad liiklusvood on sellised, mille puhul ühendus algatatakse Microsofti pilves kohapealse hosti suunas. Tavaliselt peavad need ühendused läbima tulemüüri või muud turbesüsteemid, mis on ette nähtud kliendi turbepoliitikas väljast pärit ühenduste puhul.

Lugege teema Marsuutimine teenusega ExpressRoute for Office 365 jaotist Marsuudi sümmeetria tagamine, et selgitada välja, millised teenused loovad sissetulevaid ühendusi, ja otsige veergu ExpressRoute for Office 365 artiklis Office 365 lõpp-punktid, et panna paika ühenduse ülejäänud andmed.

Kõigi väljaminevat ühendust kasutavate teenuste puhul peaks kirjeldama teenuse plaanitavat ühendust (sh võrgu marsruutimine, puhverserveri konfiguratsioon, pakettide kontrollimine ja läbilaskevõime tingimused).

Sissetulevaid ühendusi kasutavate teenuste puhul on vaja lisateavet. Microsofti pilveserverid loovad ühenduse teie kohapealse võrguga. Veendumaks, et ühendused luuakse õigesti, peaks kirjeldama kõiki selle ühenduse aspekte, nagu näiteks neid sissetulevaid ühendusi aktsepteerivate teenuste avalikud DNS-i kirjed, CIDR-vormingus IPv4 IP-aadressid, kasutatavad ISP seadmed ja sissetuleva ühenduse NAT-i või lähtekoha NAT-i käsitlemise viis.

Sissetulevad ühendused peaks üle kontrollima olenemata sellest, kas need luuakse Interneti kaudu või ExpressRoute‘i kaudu. Nii saate välistada asümmeetriliste ühenduste lisandumise. Võib juhtuda, et nendele kohapealsetele lõpp-punktidele, millega Office 365 teenused ühendusi loovad, peavad juurde pääsema ka muud Microsofti ja teiste tootjate teenused. On äärmiselt oluline jälgida, et nende teenuste jaoks Office 365 kasutamiseks ExpressRoute‘i lubamine ei katkestaks teiste süsteemide tööd. Paljudel juhtudel on võimalik, et kliendid peavad oma sisevõrgus midagi muutma (nt lähtekohal põhinev NAT), veendumaks, et Microsofti-poolsed sissetulevad ühendused jääks sümmeetriliseks ka pärast ExpressRoute‘i lubamist.

Siin on üksikasjade näide. Praegusel juhul marsruudiks Exchange‘i hübriidjuurutus ExpressRoute‘i kaudu kohapealsesse süsteemi.

Ühenduse atribuut

Väärtus

Võrguliikluse suund

Sissetulev

Teenus

Exchange’i hübriidjuurutus

Avalik Office 365 lõpp-punkt (lähtekoht)

Exchange Online (IP-aadressid)

Avalik kohapealne lõpp-punkt (sihtkoht)

5.5.5.5

Avalik (Internet) DNS-i kirje

Autodiscover.contoso.com

Kas seda kohapealset lõpp-punkti kasutab ka mõni muu (mitte Office 365-s) Microsofti teenus

Ei

Kas seda kohapealset lõpp-punkti kasutavad kasutajad/süsteemid Internetis?

Jah

Avalike lõpp-punktide kaudu avaldatud sisesüsteemid

Exchange Serveri kliendi juurdepääsuroll (kohapealne) 192.168.101, 192.168.102, 192.168.103

Avaliku lõpp-punkti IP saadavusest teatamine

Internetti 5.5.0.0/16

ExpressRoute‘i 5.5.5.0/24

Turve, perimeetri kontrollid

Interneti tee SeadmeID_002

ExpressRoute‘i tee SeadmeID_003

Suur kättesaadavus

Aktiivne / aktiivne 2 geo-liiasus

Expressroute'i kanalid – Chicago ja Dallas

Tee sümmeetria kontroll

Meetod: Allika NAT

Interneti tee Allika NAT-i sissetulevad ühendused aadressile 192.168.5.5

ExpressRoute‘i tee Allika NAT-i ühendus 192.168.1.0 (Chicago) ja 192.168.2.0 (Dallas)

Siin on näide ainult väljamineva teenuse kohta.

Ühenduse atribuut

Väärtus

Võrguliikluse suund

Väljaminev

Teenus

SharePoint Online

Kohapealne lõpp-punkt (allikas)

Kasutaja töökoht

Avalik Office 365 lõpp-punkt (sihtkoht)

SharePoint Online (IP-aadressid)

Avalik (Internet) DNS-i kirje

*. sharepoint.com (ja täiendavad FQDN-id)

CDN-i viited

cdn.sharepointonline.com (ja täiendavad FQDN-id) – IP-aadressid, mida haldavad CDN-i pakkujad)

IP-aadresside saadavuse teatamine ja kasutatav NAT

Interneti tee / allika NAT: 1.1.1.0/24

Expressroute'i tee / allika NAT: 1.1.2.0/24 (Chicago) ja 1.1.3.0/24 (Dallas)

Ühenduse meetod

Internet: 7. kihi puhverserveri kaudu (.pac)

ExpressRoute: otsene marsruutimine (puhverserverita)

Turve, perimeetri kontrollid

Interneti tee SeadmeID_002

ExpressRoute‘i tee SeadmeID_003

Suur kättesaadavus

Interneti tee Liiased Interneti väljumispunktid

ExpressRoute‘i tee Aktiivne / aktiivne esimesel võimalusel marsruutimine 2 geo-liiase ExpressRoute‘i kanali kaudu : Chicago ja Dallas

Tee sümmeetria kontroll

Meetod: Allika NAT kõigi ühenduste jaoks

Kui teil on hea ülevaade teenustest ja nendega seotud võrguliiklusest, saate luua skeemi, mis kajastab neid uusi ühenduste nõudeid ja illustreerib muudatusi, mis tuleb teha ExpressRoute for Office 365 kasutamiseks. Skeem peaks hõlmama järgmist:

  1. kõik kohad, kust kasutajad Office 365-e ja muudele teenustele juurde pääsevad;

  2. kõik Interneti ja ExpressRoute‘i väljumispunktid;

  3. kõik sissetulevate ja väljaminevate ühenduste seadmed, mis haldavad sisenevaid ja väljuvaid ühendusi (sh ruuterid, tulemüürid, rakenduste puhverserverid ja sissetungi tuvastamise/vältimise seadmed);

  4. võrgusisesed sihtkohad sissetulevate voogude jaoks (nt sisemised ADFS-i serverid, mis võtavad vastu ühendusi ADFS-i veebirakenduste puhverserveritest);

  5. kõigi pakutavate IP-alamvõrkude kataloog;

  6. kõik kohad, mille kaudu Office 365 teenuseid kasutatakse, ja ExpressRoute‘i ühenduskohad;

  7. sisevõrgu topoloogia asukohad ja piirkonnad, kus ExpressRoute‘i kaudu saadud Microsofti IP-eesliiteid aktsepteeritakse, filtreeritakse ja levitatakse;

  8. võrgu topoloogia peaks kajastama iga võrgusegmendi geograafilist asukohta ja seda, kuidas see Microsofti võrguga ExpressRoute‘i ja/või Interneti kaudu ühendatakse.

Alltoodud skeemil on kohad, kus teenusekomplekti Office 365 kasutatakse, ja sissetulevate ja väljaminevate ühenduste marsruutimisteavitused teenusekomplekti Office 365.

ExpressRoute'i piirkondlik geograafiline ühenduskoht

Väljamineva ühenduse puhul pääsevad Office 365 kasutajad teenusele juurde ühel järgmistest viisidest:

  1. Põhja-Ameerikas oleva ühenduspunkti kaudu California elanike jaoks;

  2. Hongkongis oleva ühenduspunkti kaudu Hongkongi elanike jaoks;

  3. Bangladeshi Interneti-ühenduse kaudu, kus on vähem inimesi ja puudub ExpressRoute.

Piirkondlike väljaminevate ühenduste skeem

Samamoodi tagastab Office 365 sissetuleva ühenduse ühel järgmistest viisidest:

  1. Põhja-Ameerikas oleva ühenduspunkti kaudu California elanike jaoks;

  2. Hongkongis oleva ühenduspunkti kaudu Hongkongi elanike jaoks;

  3. Bangladeshi Interneti-ühenduse kaudu, kus on vähem inimesi ja puudub ExpressRoute.

Piirkondlike sissetulevate ühenduste skeem

ExpressRoute‘i ja Microsofti võrgu ühenduste füüsiliste asukohtade ehk ühenduspunktide valik sõltub sellest, kust inimesed teenusekomplektile Office 365 juurde pääsevad. SaaS-teenus Office 365 ei tööta Azure‘i kombel IaaS-i või PaaS-i piirkondliku mudeli alusel. Office 365 on hoopis jaotatud koostööteenuste kogum, kus kasutajatel tuleb luua ühendus lõpp-punktidega eri andmekeskustes ja piirkondades, mis ei pruugi olla kasutaja hostiga samas kohas ega piirkonnas.

Seega kõige olulisem asjaolu ExpressRoute for Office 365-e ühenduspunktide valimisel on see, kust teie ettevõtte inimesed peamiselt ühenduse loovad. Üldine soovitus optimaalse Office 365-e ühenduvuse tagamiseks on rakendada marsruutimist, et kasutajate päringud Office 365 teenustele edastataks Microsofti võrku kõige lühema võrgutee kaudu. Seda nimetatakse ka „kuuma kartuli“ põhimõttel marsruutimiseks. Näiteks kui enamik Office 365 kasutajaid on ühes või kahes kohas, on kõige optimaalsem lahendus valida nendele kasutajatele kõige lähemal olevad ühenduskohad. Kui teie ettevõttes on palju eri piirkondadest pärit kasutajaid, võiksite kaaluda mitme ExpressRoute‘i kanali ja ühenduskoha kasutamist. Mõne koha puhul ei pruugi lühim/optimaalseim tee Microsofti võrku ja Office 365-e olla sisemise WAN-i ega ExpressRoute‘i ühenduskohtade kaudu, vaid Interneti kaudu.

Sageli on kasutajatele suhteliselt lähedal võimalik valida mitu ühenduskohta. Järgmine tabel aitab teil otsustada.

Kavandatud ExpressRoute'i ühenduskohad Californias ja New Yorgis

Asukoht

Inimeste arv

Eeldatav latentsusaeg Microsofti võrguni Interneti väljumispunkti kaudu

Eeldatav latentsusaeg Microsofti võrguni ExpressRoute‘i kaudu

Los Angeles

10 000

~ 15 ms

~ 10 ms (Silicon Valley kaudu)

Washington DC

15 000

~ 20 ms

~ 10 ms (New Yorgi kaudu)

Dallas

5 000

~ 15 ms

~ 40 ms (New Yorgi kaudu)

Kui globaalse võrgu arhitektuur sisaldab Office 365 piirkonda, ExpressRoute‘i võrguteenusepakkuja ühenduskohti ja inimeste arvu asukohtade kaupa, saab selle põhjal välja selgitada optimeerimisvõimalused. Lisaks võib see kajastada globaalseid hairpin-ühendusi, mille korral liiklus suunatakse ühenduskoha saamiseks kaugele. Globaalses võrgus hairpin-ühenduse avastamisel peaks selle enne jätkamist kõrvaldama. Selleks leidke mõni muu ühenduskoht või kasutage valikulisi Interneti väljumispunkte.

Esimesel skeemil on kujutatud klienti kahe füüsilise asukohaga Põhja-Ameerikas. Saate vaadata kontorite asukohtade ja Office 365 rentnike asukohtade teavet ning ExpressRoute‘i ühenduskohtade eri variante. Selles näites on klient valinud ühenduskoha kahe asjaolu põhjal samas järjestuses:

  1. lähedus töötajatele;

  2. lähedus Office 365 majutamiseks kasutatavale Microsofti andmekeskusele.

ExpressRoute'i USA geograafiline ühenduskoht

Teisel skeemil on kujutatud sarnastes oludes tegutseva ja sarnaseid asjaolusid arvestava rahvusvahelise ettevõtte võrku. Kliendil on Bangladeshis väike kontor, kus kohaliku tuntuse tõstmise nimel töötab üksnes kümme inimest. Chennais on ühenduspunkt ja teenusekomplekti Office 365 majutav Microsofti andmekeskus, seega sealne ühenduspunkt oleks loogiline lahendus, kuid kümne inimese jaoks lisakanali lisamine oleks koormav. Peaksite võrku vaadates välja selgitama, kas teie võrguliikluse latentsusaeg muudab võrgu nii ebatõhusaks, et uus ExpressRoute‘i kanal ennast ära tasub.

On võimalik, et kümne Bangladeshis oleva inimese jaoks on sisevõrgu kaudu marsruutimisest parem variant see, kui Microsofti-suunaline võrguliiklus toimub Interneti kaudu, nagu on näidatud sissejuhataval skeemil ja allpool.

Piirkondlike väljaminevate ühenduste skeem

ExpressRoute for Office 365-e juurutusplaani loomine

Juurutusplaan peaks hõlmama nii ExpressRoute‘i konfigureerimise tehnilisi andmeid kui ka võrgu ülejäänud süsteemide konfigureerimise etappe, mis on järgmised.

  • Pange paika ExpressRoute‘i ja Interneti vahel jagatavad teenused.

  • Looge plaan läbilaskevõime, turvalisuse ja kättesaadavuse tagamiseks ning tõrkesiirde jaoks.

  • Kujundage sissetulevate ja väljaminevate ühenduste marsruutimine (sh marsruutimisteede optimeerimine eri asukohtade jaoks).

  • Otsustage, kui kaugele teie võrku ExpressRoute‘i marsruute levitatakse ja millise mehhanismi põhjal klientrakendused Interneti või ExpressRoute‘i valivad (nt otsemarsruutimine või rakenduse puhverserver).

  • Plaanige DNS-i kirjete muudatusi (sh saatmispoliitika raamistiku kirjed).

  • Pange paika NAT-iga seotud strateegia (sh väljaminevate ja sissetulevate ühenduste allika NAT).

  • Algses juurutuses on soovitatav kõigi sissetulevate ühenduste (nt meiliteenus või hübriidühendus) jaoks kasutada Internetti.

  • Plaanige kasutaja klientrakenduse LAN-marsruutimist ja selle raames PAC-/WPAD-faili, vaikemarsruudi, puhverserverite ja BGP marsruuditeavituste konfigureerimist.

  • Plaanige perimeetri marsruutimist (sh puhverserverid, tulemüürid ja pilvepõhised puhverserverid).

Looge plaan Office 365 töövoogude jaoks vajaliku läbilaskevõime jaoks. Hinnake eraldi Exchange Online’i, SharePoint Online’i ja Skype’i ärirakenduse nõudeid läbilaskevõimele. Saate alustuseks kasutada meie loodud kalkulaatoreid Exchange Online‘i ja Skype‘i ärirakenduse jaoks, kuid ettevõtte vajadustest täpse ülevaate saamiseks on vaja läbi viia katseprojekt kasutajate profiile ja asukohti esindava valimiga.

Arvestage plaanides ka sellega, kuidas on tagatud Interneti ja ExpressRoute‘i väljumispunktide turvalisus ning pidage meeles, et kõik Office 365-e suunatud ExpressRoute‘i ühendused kasutavad avalikku võrgujagamist ja neid peab kaitsma vastavalt teie ettevõtte turbepoliitikatele välisvõrkudega ühenduse loomise kohta.

Lisage plaani andmed selle kohta, mis tüüpi katkestused milliseid kasutajaid mõjutavad ja kuidas need inimesed kõige hõlpsamalt oma tööd täies mahus teha saaksid.

Arvestage nõuetega läbilaskevõime osas (sh Skype‘i ärirakenduse nõuded virvenduse, latentsuse, võrguummistuste ja kaablisüsteemi jõudluse osas).

Skype’i ärirakenduse veebiväljaandel on täiendavaid võrgunõudeid, mida on kirjeldatud artiklis Meediumikvaliteet ja võrguühenduse jõudlus Skype‘i ärirakenduse veebiväljaandes (inglise keeles).

Lugege teema Võrgu planeerimine teenusega ExpressRoute for Office 365 jaotist Läbilaskevõime planeerimine Azure ExpressRoute‘i jaoks.

Katseprojekti kasutajatega läbilaskevõime hindamiseks saate kasutada meie juhendit: Office 365 jõudluse suurendamine võrdlusandmete ja jõudlusajaloo abil.

Parima kättesaadavuse nõuete põhjal plaanimine

Looge plaan teie vajadustele vastava kättesaadavuse tagamiseks ja lisage see oma värskendatud võrgutopoloogia skeemile. Lugege teema Võrgu planeerimine teenusega ExpressRoute for Office 365 jaotist Läbilaskevõime ja tõrkesiire Azure ExpressRoute‘is.

Võrgu turbenõuetest lähtuvalt plaanimine

Looge plaan vastavalt teie võrgu turbenõuetele ja lisage see oma värskendatud võrgutopoloogia skeemile. Lugege teema Võrgu planeerimine teenusega ExpressRoute for Office 365 jaotist Turbemeetmete rakendamine Azure ExpressRoute for Office 365 stsenaariumide korral.

ExpressRoute for Office 365-l on väljaminevate ühenduste jaoks võrgunõuded, millest te ei pruugi teadlik olla. IP-aadressid, mis esindavad Office 365-s teie kasutajaid ja võrke ja toimivad Microsofti suunatud väljaminevate ühenduste lõpp-punktidena, peavad vastama allpool loetletud tingimustele.

  1. Lõpp-punktid peavad olema avalikud IP-aadressid, mis on registreeritud teie ettevõttele või teenusepakkujale, kes teile ExpressRoute‘i ühenduvust pakub.

  2. Lõpp-punktide teave peab olema Microsoftile edastatud ja ExpressRoute‘is valideeritud/aktsepteeritud.

  3. Lõpp-punkte ei peaks Interneti-ühenduse kaudu levitama samade ega eelistatumate marsruutimismõõdikutega.

  4. Lõpp-punkte ei tohi kasutada ExpressRoute‘is konfigureerimata Microsofti teenustega ühenduse loomiseks.

Kui teie võrgustruktuur ei võimalda neid tingimusi täita, on suur oht, et kasutajatel ilmneb Office 365 või muude Microsofti teenustega ühenduse loomisel probleeme marsruudi katkemise või asümmeetrilise marsruutimise tõttu. See juhtub siis, kui Microsofti teenuste päringud marsruuditakse ExpressRoute‘i kaudu, aga vastused saadetakse tagasi Interneti kaudu või vastupidi, ning olekupõhised võrguseadmed (nt tulemüürid) katkestavad vastuse saatmise.

Kõige levinum viis ülaltoodud tingimuste täitmiseks on allika NAT-i kasutamine võrgu osana või ExpressRoute‘i pakkuja teenusena. Allika NAT-i abil saate ülevaate kogu oma ExpressRoute‘ist Internetti suunduva võrgu üksikasjadest ja privaatsetest IP-aadressidest ja koos õige IP-de levitamise süsteemiga tagada marsruutide sümmeetria. Kui kasutate ExpressRoute‘i võrgujagamiskohtades kohaspetsiifilisi olekupõhiseid võrguseadmeid, peate teede sümmeetria tagamiseks rakendama igale ExpressRoute‘i võrgujagamiskohale eraldi NAT-i kogumeid.

Lugege lisateavet ExpressRoute‘i NAT-i nõuete kohta.

Lisage väljaminevate ühenduste muudatused võrgutopoloogia skeemile.

Enamiku ettevõtete Office 365 juurutuste puhul eeldatakse, et Office 365 loob mingil kujul sissetulevaid ühendusi kohapealsete teenustega (nt Exchange‘i, SharePointi ja Skype‘i ärirakenduse hübriidstsenaariumid, postkasti migreerimised ja ADFS-i taristutel põhinev autentimine). Kui lubade ExpressRoute‘is väljamineva ühenduse jaoks täiendava marsruutimistee kohapealse võrgu ja Microsofti vahel, võib asümmeetriline marsruutimine neid sissetulevaid ühendusi tahtmatult mõjutada isegi siis, kui plaanite neid vooge ka edaspidi Interneti kaudu marsruutida. Allpool on kirjeldatud paari abinõud, mis aitavad veenduda, et miski ei mõjutaks Office 365-st kohapealsetesse süsteemidesse saabuvaid Interneti-põhiseid liiklusvooge.

Sissetulevate liiklusvoogudega seoses asümmeetrilise marsruutimise riski minimeerimiseks peaks kõik sissetulevad ühendused kasutama allika NAT-i, enne kui need ExpressRoute‘i jaoks nähtavana teie võrgu segmentidesse marsruuditakse. Kui sissetulevad ühendused marsruuditakse võrgusegmenti ExpressRoute‘i jaoks nähtavana ilma allika NAT-ita, sisenevad Office 365-e päringud Interneti kaudu, aga vastused saadetakse Microsofti võrku Office 365 keskkonda tagasi ExpressRoute‘i kaudu, mis põhjustab asümmeetrilist marsruutimist.

Nende nõute täitmiseks võite kaaluda mõnda järgmist juurutussüsteemi.

  1. Käivitage võrguseadmete (nt tulemüürid või koormuse tasakaalustajad) abil allika NAT enne päringute teie sisevõrgu kaudu kohapealsetesse süsteemidesse suunamist.

  2. Veenduge, et ExpressRoute‘i marsruute ei levitataks nendesse võrgusegmentidesse, kus on sissetulevate teenuste (nt kasutajapoolsed serverid või pöördpuhverserverid) Interneti-ühendusi töötlevad seadmed.

Oma võrku plaanides nende võimalustega arvestamine ja kogu sissetuleva liiklusvoo Interneti kaudu marsruutimine hõlbustab juurutamist ja aitab minimeerida asümmeetrilise marsruutimise riske.

Mõnel juhul võite siiski otsustada osa sissetulevatest voogudest marsruutida ExpressRoute‘i kaudu. Sellistel juhtudel arvestage järgmiste täiendavate asjaoludega.

  1. Office 365 saab ühendusi suunata ainult kohapealsetesse lõpp-punktidesse, mis kasutavad avalikke IP-sid. See tähendab, et isegi juhul, kui kohapealne sissetuleva ühenduse lõpp-punkt on Office 365-e jaoks saadaval ainult ExpressRoute‘i kaudu, peab sellega siiski olema seotud avalik IP.

  2. Office 365 teenused kasutavad kõigi kohapealsete lõpp-punktide resolvimisel DNS-i lahendamiseks avalikku DNS-i. See tähendab, et sissetulevate teenuseühenduste lõpp-punktide FQDN-id tuleb Internetis IP-vastendustega registreerida.

  3. ExpressRoute‘i kaudu sissetulevate ühenduste vastuvõtmiseks peab nende lõpp-punktide avalikke IP-alamvõrke ExpressRoute‘i kaudu Microsoftile levitama.

  4. Hinnake hoolikalt neid sissetulevaid liiklusvooge, veendumaks, et neile rakendatakse sobivaid turbe- ja võrgumeetmeid vastavalt teie ettevõtte turbe- ja võrgupoliitikatele.

  5. Pärast kohapealsete sissetulevate ühenduste lõpp-punktide ExpressRoute‘i kaudu Microsoftile levitamist saab ExpressRoute‘ist nende lõpp-punktide jaoks eelistatud marsruutimistee kõigi Microsofti teenuste (sh Office 365) lõikes. See tähendab, et nende lõpp-punktidega alamvõrke saab kasutada ainult Office 365 teenustega suhtlemiseks, kuid mitte muude selle võrgu Microsofti teenustega suhtlemiseks. Vastasel juhul tekib teie kujunduse tõttu asümmeetriline marsruutimine, kus muudest Microsofti teenustest saabuvaid ühendusi eelistatakse marsruutida ExpressRoute‘i kaudu, kuid mille vastused saadetakse Interneti kaudu.

  6. Kui ExpressRoute‘i kanal või ühenduskoht parasjagu ei tööta, peate tagama kohapealsete sissetulevate ühenduste lõpp-punktide saadavuse, et need saaks päringuid teise võrgutee kaudu vastu võtta. Selleks võite mitme ExpressRoute‘i kanali kaudu alamvõrke nendele lõpp-punktidele levitada.

  7. Soovitame kasutada allika NAT-i kõigil ExpressRoute‘i kaudu teie võrku saabuvatel liiklusvoogudel, eriti siis, kui need vood saabuvad läbi olekupõhiste võrguseadmete (nt tulemüürid).

  8. Mõned kohapealsed teenused (nt ADFS-i puhverserver või Exchange‘i automaattuvastus) võivad saada sissetulevaid päringuid nii Office 365 teenustest kui ka Interneti-kasutajatelt. Office 365 kasutab nende päringute suunamisel sama FQDN-i nagu Interneti teel saabuvate päringute puhul. Internetist sissetulevatel kasutajaühendustel nende kohapealsete lõpp-punktidega ühenduse loomise lubamine ja samal ajal Office 365 ühenduste sunniviisiline ExpressRoute‘i kaudu marsruutimine muudab võrgu üsna keerukaks. Enamiku klientide jaoks pole selliste keerukate süsteemide juurutamine ExpressRoute‘i kaudu soovitatav, sest sellega kaasnevad täiendavad protseduurid. Need täiendavad protseduurid hõlmavad näiteks asümmeetrilise marsruutimise riskide haldamist ja nõuavad marsruudilevitamise ja poliitikate hoolikat haldamist mitmel tasandil.

Asümmeetrilisi marsruute peaks vältima selleks, et teie ettevõtte inimesed saaksid nii Office 365-e kui ka muid Interneti-teenuseid ilma tõrgeteta kasutada. Enamasti põhjustavad asümmeetrilise marsruutimise kaks levinud konfiguratsiooni. Praegu on sobiv aeg plaanitav võrgukonfiguratsioon üle vaadata ja kontrollida, kas selles võib tekkida üks nendest asümmeetrilise marsruutimise olukordadest.

Alustuseks uurime paari järgmise võrguskeemiga seotud situatsiooni. Sellel skeemil on kõik sissetulevaid päringuid vastu võtvad serverid (ADFS-id või kohapealsed hübriidserverid) New Jersey andmekeskuses ja nende saadavuse teavet edastatakse Internetti.

  1. Kuigi perimeetervõrk on turvaline, pole sissetulevate päringute jaoks allika NAT saadaval.

  2. New Jersey andmekeskuste serverite jaoks on nähtaval nii Interneti-põhised kui ka ExpressRoute‘i marsruudid.

ExpressRoute'i ühenduvuse ülevaade

Meil on ka soovitus olukorra lahendamiseks.

Probleem 1: Interneti-põhine ühendus pilvteenuste ja kohapealsete serverite vahel

Järgmisel skeemil on kujutatud asümmeetrilist võrguteed, mida kasutatakse siis, kui võrgukonfiguratsioon ei paku Microsofti pilvest Interneti kaudu saabuvate päringute jaoks NAT-i.

  1. Office 365-st saabuv päring toob avalikust DNS-ist kohapealse lõpp-punkti IP-aadressi ja saadab päringu teie perimeetervõrku.

  2. Selles vigases konfiguratsioonis pole allika NAT konfigureeritud või liiklust vastu võtvas perimeetervõrgus saadaval, mille tõttu kasutatakse tegelikku lähtekoha IP-aadressi sihtkohana.

    • Teie võrgu server suunab liikluse Office 365-e mis tahes saadaoleva ExpressRoute‘i võrguühenduse kaudu.

    • Tulemuseks on selle voo asümmeetriline tee teenusekomplekti Office 365, mis põhjustab ühenduse katkemise.

ExpressRoute'i asümmeetriline marsruutimise probleem 1

Lahendus 1a: allika NAT

Sissetulevatele päringutele allika NAT-i rakendamine on lihtne viis selle vale konfiguratsiooni lahendamiseks. Sellel skeemil on kujutatud järgmist.

  1. Sissetulev päring siseneb New Jersey andmekeskuse perimeetervõrgu kaudu. Allika NAT on sel korral saadaval.

  2. Serveri vastus suunatakse tagasi allika NAT-iga seotud IP-aadressi suunas, mitte algse IP-aadressi suunas, tänu millele saadetakse vastus sama võrguteed kaudu.

ExpressRoute'i asümmeetriline marsruutimise lahendus 1

Lahendus 1b: marsruudi ulatuse määramine

Teine võimalus on keelata ExpressRoute‘i BGP-marsruutidest teatamine, et eemaldada alternatiivsed võrguteed nende arvutiteni. Sellel skeemil on kujutatud järgmist.

  1. Sissetulev päring siseneb New Jersey andmekeskuse perimeetervõrgu kaudu. Seekord pole ExpressRoute‘i kaudu teatatud Microsoft marsruudid New Jersey andmekeskuse jaoks saadaval.

  2. Serveri vastus suunatakse ainukese saadaoleva marsruudi kaudu tagasi algse IP-ga seotud IP-aadressi suunas, tänu millele saadetakse vastus sama võrguteed kaudu.

ExpressRoute'i asümmeetriline marsruutimise lahendus 2

Probleem 2: ExpressRoute‘i ühendus pilvteenuste ja kohapealsete serverite vahel

Järgmisel skeemil on kujutatud asümmeetrilist võrguteed, mida kasutatakse siis, kui võrgukonfiguratsioon ei paku Microsofti pilvest ExpressRoute‘i kaudu saabuvate päringute jaoks NAT-i.

  1. Office 365-st saabuv päring toob DNS-ist IP-aadressi ja saadab päringu teie perimeetervõrku.

  2. Selles vigases konfiguratsioonis pole allika NAT konfigureeritud või liiklust vastu võtvas perimeetervõrgus saadaval, mille tõttu kasutatakse tegelikku lähtekoha IP-aadressi sihtkohana.

    • Teie võrgus olev arvuti suunab liikluse Office 365-e mis tahes saadaoleva ExpressRoute‘i võrguühenduse kaudu.

    • Tulemuseks on asümmeetriline ühendus teenusekomplektiga Office 365.

ExpressRoute'i asümmeetriline marsruutimise probleem 2

Lahendus 2: allika NAT

Sissetulevatele päringutele allika NAT-i rakendamine on lihtne viis selle vale konfiguratsiooni lahendamiseks. Sellel skeemil on kujutatud järgmist.

  1. Sissetulev päring siseneb New Yorgi andmekeskuse perimeetervõrgu kaudu. Allika NAT on sel korral saadaval.

  2. Serveri vastus suunatakse tagasi allika NAT-iga seotud IP-aadressi suunas, mitte algse IP-aadressi suunas, tänu millele saadetakse vastus sama võrguteed kaudu.

ExpressRoute'i asümmeetriline marsruutimise lahendus 3

Skeemi põhjal veendumine, et võrgustruktuuri teed oleks sümmeetrilised

Selles etapis tuleb nö paberil veenduda, et teie juurutusplaan tagaks marsruutide sümmeetria Office 365 eri kasutusjuhtude korral. Peaksite tegema kindlaks eeldatava marsruudi, mida teenuse eri funktsioonide jaoks kasutatakse. Kohapealse võrgu ja WAN-ist marsruutidest perimeetriseadeteni ja ühendusteeni ExpressRoute‘i või Internetti ja edasi lõpp-punkti.

Seda tuleb teha kõigi Office 365 teenuste puhul, mille olete eelnevalt loetlenud oma ettevõttes kasutatavate teenuste hulgas.

Soovitatav on need skeemid läbi vaadata koos teise isikuga. Selgitage talle, kuhu iga võrguvoog üleminekukohas edasi suunatakse, ja veenduge, et oleksite marsruutidega hästi kursis. Pidage meeles, et ExpressRoute pakub Microsofti serveri IP-aadressidele alati laiemat ulatust, nii et sel juhul on see marsruut tõhusam kui vaikimisi marsruut Interneti kaudu.

Kliendi ühenduste konfiguratsiooni kujundus

PAC-failide kasutamine ExpressRoute‘is

Kui kasutate Interneti-põhise liikluse jaoks puhverserverit, peate kohandama PAC-faile või kliendi konfiguratsioonifaile, veendumaks, et klientarvutid oleks võrgus õigesti konfigureeritud ja saaks soovitud ExpressRoute‘i liikluse saata teenusekomplekti Office 365 ilma seda teie puhverserverisse edastamata, ning et ülejäänud liiklus (sh osa Office 365 liiklusest) edastataks asjakohasesse puhverserverisse. Lugege meie juhiseid Office 365 lõpp-punktide (nt PAC-failid) haldamise kohta.

Märkus.: Lõpp-punktid muutuvad sageli, lausa kord nädalas. Muudatused tuleks teha vastavalt ettevõttes kasutusele võetud teenustele ja funktsioonidele, et te ei peaks vähendamiseks tarbetult palju vaeva nägema. Pöörake tähelepanu ka kuupäevale Effective date (Kehtivuskuupäev) RSS-kanalis, kus antakse teada muudatustest ja registreeritakse kõik varasemad muudatused. Teatatud IP-aadresse ei tohi võrgus avaldada ega avaldamisest eemaldada kuni kehtivuskuupäevani.

Juurutamis- ja testimistoimingute paikapanek

Juurutamisplaan peaks hõlmama nii testimise kui ka tagasipööramise kava. Kui juurutatud süsteem ei toimi ootuspäraselt, peaks süsteemi struktuur töötama nii, et enne probleem mõjutab enne avastamist võimalikult vähe inimesi. Allpool on toodud olulised põhimõtted, mida peaksite planeerides silmas pidama.

  1. Töökatkestuste minimeerimiseks plaanige võrgusegmente etappidena ja rakendage kasutuselevõtusüsteemi.

  2. Plaanige marsruutide testimist Traceroute‘iga ja TCP-ga mõne muu Internetiga ühendatud hosti kaudu.

  3. Eelistatult peaks sissetulevaid ja väljaminevaid teenuseühendusi testima isoleeritud testvõrgus Office 365-e testrentnikuga.

    • Teine võimalus on testida tegelikus võrgus, kui klient teenusekomplekti Office 365 veel ei kasuta või kasutab katseversiooni.

    • Veel üks võimalus on testimiseks kasutada tegeliku võrgu katkestust, mis on ette nähtud üksnes testimiseks ja jälgimiseks.

    • Samuti võib testimiseks kontrollida iga teenuse marsruute igas 3. kihi ruuterisõlmes. Seda varianti peaks kasutama ainult siis, kui muul moel ei saa testida, sest füüsilise testimise puudumine tähendab suuremaid riske.

Peaksite juurutama etappide kaupa väikeste kasutajarühmade jaoks, et saaksite süsteeme testida enne paljude kasutajate jaoks juurutamist. Allpool on toodud mitu võimalust ExpressRoute‘i etapiviisiliseks juurutamiseks.

  1. Etapiviisiliseks testimiseks seadistage ExpressRoute Microsofti võrgujagamisteenusega ja laske marsruudist teavitada ainult ühte hosti.

  2. Teavitage ExpressRoute‘i marsruutidest esmalt ainult ühte võrgusegmenti ja laiendage teavitamist võrgusegmentide või piirkondade kaupa.

  3. Office 365 esmakordsel juurutamisel kasutage ExpressRoute‘i võrgu juurutust katseprojektina väikese kasutajarühma jaoks.

  4. Kui kasutate puhverservereid, saate konfigureerida ka test-PAC-faili, mille alusel suunatakse mõned inimesed testimiseks ja tagasiside saamiseks ExpressRoute‘i enne rohkemate inimeste suunamist.

Teie juurutamisplaanis peaks olema loetletud kõik vajalikud juurutamistoimingud ja võrgukonfiguratsiooni juurutamiseks kasutatavad käsud. Võrgu katkestuse ajal peaks tegema üksnes need muudatused, mis on kirjas eelnevalt koostatud ja teiste spetsialistide kontrollitud juurutusplaanis. Vaadake ExpressRoute‘i tehnilise konfiguratsiooni juhiseid.

  • Värskendage oma SPF-i TXT-kirjeid, kui olete muutnud mõne sellise kohapealse server IP-aadressi, mida kasutatakse ka edaspidi meilisõnumite saatmiseks.

  • Värskendage kohapealsete serverite DNS-i kirjeid, kui olete muutnud IP-aadresse vastavalt uuele NAT-i konfiguratsioonile.

  • Kontrollige, et olete tellinud Office 365-e lõpp-punktide teatiste RSS-kanali, et säilitada õigeid marsruutimis- ja puhverserveri konfiguratsioone.

Pärast ExpressRoute‘i juurutamist peaks jätkama testimisplaani järgmiste toimingutega. Kõigi protseduuride tulemid peaks logima. Peaksite lisama toimingud algse keskkonna taastamiseks, kui testitulemustest selgub, et juurutamine ei õnnestunud.

Testimine peaks hõlmama nii väljaminevate kui ka sissetulevate ning nii ExpressRoute‘i kasutavate kui ka muude Office 365-e teenusteühenduste testimist. Testima peaks eraldi igast võrgukohast, ka nende kasutajate asukohtadest, kes pole ettevõtte kohapealses LAN-võrgus.

Testimise käigus peaks sooritama näiteks järgmised tegevused.

  1. Pingige kohapealsest ruuterist oma võrguoperaatori ruuterit.

  2. Veenduge, et kohapealsesse ruuterisse saabuks vähemalt 500 Office 365 ja CRM Online‘i IP-aadressi teavitust.

  3. Veenduge, et ExpressRoute‘i ja sisevõrgu vaheliste sissetulevate ja väljaminevate ühenduste NAT toimiks.

  4. Kontrollige, et teie ruuterile pakutaks NAT-ini viivaid marsruute.

  5. Veenduge, et ExpressRoute oleks aktsepteerinud teie välja pakutud marsruudid.

    • Kasutage võrdõigusvõrgus marsruutide väljapakkumise kontrollimiseks järgmist cmdlet-käsku:

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. Veenduge, et teie NAT-i IP-vahemikku ei pakutaks Microsoftile ühegi teise ExpressRoute‘i ega avaliku Internetivõrgu kaudu, välja arvatud juhul, kui tegu on suurema vahemiku konkreetse alamkogumiga, nagu on kirjeldatud eelmises näites.

  7. ExpressRoute‘i kanalid on seotud; veenduge, et mõlemad BGP seansid oleksid aktiivsed.

  8. Uues kanalis hostiga outlook.office365.com ühenduvuse testimiseks seadistage NAT-is üks host ning kasutage pingimist ja diagnostikariistu Tracert ja Tcpping. Samuti saate kasutada MSEE-sse peegeldatud pordi jaoks tööriista Wireshark või Microsoft Network Monitor 3.4, veendumaks, et saate luua ühenduse hostiga outlook.office365.com seotud IP-aadressiga.

  9. Testige rakenduse tasemel funktsioone Exchange Online‘is.

    • Testige, kas Outlook saab Exchange Online‘iga ühenduse luua ja meilisõnumeid saata / vastu võtta.

    • Testige, kas Outlook saab töötada võrguühendusega režiimis.

    • Testige nutitelefonide ühenduvust ja sisu saatmise/vastuvõtmise võimalust.

  10. Testige rakenduse tasemel funktsioone SharePoint Online‘is.

    • Testige OneDrive for Businessi sünkroonimisrakendust.

    • Testige SharePoint Online‘i veebiühendust.

  11. Testige rakenduse tasemel funktsioone seoses Skype‘i ärirakenduse kõnedega.

    • Liituge konverentskõnega autenditud kasutajana (kutse loob lõppkasutaja)

    • Kutsuge mõni kasutaja konverentskõnega liituma (kutse saadetakse MCU-st).

    • Liituge Skype’i ärirakenduse veebiversiooni kaudu konverentsiga anonüümse kasutajana.

    • Liituge kõnega juhtmega ühenduse kaudu arvutis, IP-telefonis ja mobiilsideseadmes.

    • Helistage väliskasutajale või PSTN-i testnumbrile ja jälgige, kas kõne viiakse lõpule, kvaliteet on aktsepteeritav ja ühendamise aeg on mõistlik.

    • Veenduge, et värskendataks nii sama rentniku kui ka muude rentnike kasutajate võrgusolekuteavet.

Asümmeetriline marsruutimine on kõige levinum probleem juurutamisel. Siin on loetletud mõned sagedasemad põhjused.

  • Kasutatakse avatud või lamedat võrgutopoloogiat, kus pole allika NAT-i.

  • Interneti ega ExpressRoute‘i ühenduste kaudu saabuvate teenusevoogude marsruutimiseks ei kasutata SNAT-i.

  • Enne laialdaselt juurutamist ei testita sissetulevaid teenuseühendusi ExpressRoute‘i testvõrgus.

Võrgus ExpressRoute‘i ühenduse juurutamine

Juurutage etappide kaupa korraga ainult ühes võrgusegmendis, laiendage ühenduvust järk-järgult muudesse võrgu osadesse ja olge vajaduse korral valmis iga segmendi puhul tagasi pöörama. Kui juurutate paralleelselt Office 365 juurutamisega, seadistage süsteem esmalt Office 365 katseprojekti kasutajate jaoks ja laiendage juurutust sealt edasi.

Tehke testimiseks ja seejärel töökeskkonnas järgmist.

  • ExpressRoute‘i lubamiseks juurutage see.

  • Veenduge, et võrgu marsruudid oleksid ootuspärased.

  • Testige kõiki sissetulevaid ja väljaminevaid teenuseühendusi.

  • Probleemide ilmnemisel pöörake juurutus tagasi.

Kui plaan on paberil valmis, saate seda väikeses ulatuses testida. Selle testi jaoks tuleb luua üks ExpressRoute‘i ühendus Microsofti võrgujagamisteenuse ja teie kohapealse serveri testalamvõrgu vahel. Saate konfigureerida Office 365 proovirentniku, mille saab ühendada testalamvõrguga, kuhu saab kaasata kõik väljaminevad ja sissetulevad teenuseühendused, mida te tegelikus töökeskkonnas kasutada plaanite. Seadistage testvõrgusegmendi jaoks DNS ja häälestage kõik sissetulevad ja väljaminevad teenuseühendused. Alustage testimist ja jälgige, et teaksite iga teenuse marsruutimise ja marsruutide levitamise kohta.

Pärast loetletud materjalide koostamist märkige need lõpuleviiduks ning veenduge, et teie ise ja teie meeskond oleks need enne juurutamis- ja testimisplaanide elluviimist üle kontrollinud.

  • Võrgu muudatustega seotud sissetuleva ja väljamineva ühendusega teenuste loend.

  • Globaalse võrgustruktuuri skeem, kus on nii Interneti väljumispunktid kui ka ExpressRoute‘i ühenduspunktid.

  • Võrgu marsruutimisskeem, kus on näidatud iga teenuse jaoks ette nähtud võrguteed.

  • Juurutusplaan muudatuste rakendamise ja vajaduse korral tagasipööramise etappidega.

  • Testimiskava kõigi Office 365 teenuste ja võrguteenuste testimiseks.

  • Paberile kantud valideeritud skeem kõigi sissetulevate ja väljaminevate teenuseühenduste jaoks.

  • Testvõrgusegmendis läbi viidud test (sh kättesaadavuse test).

Valige katkestuse, mis on piisavalt pikk kogu juurutamissplaani ja testimisplaani läibkäimiseks, ning jätke aega tõrkeotsinguks ja vajaduse korral tagasipööramiseks.

Hoiatus.: Kuna korraga Interneti ja ExpressRoute‘i kaudu marsruutimine on olemuselt keerukas, soovitame lisada täiendava varuaja, mis võimaldaks teha keeruka marsruutimise tõrkeotsingut.

QoS on vajalik Skype’i ärirakenduse veebiväljaande kõne- ja koosolekufunktsioonide kasutamiseks. Saate QoS-i konfigureerida pärast seda, kui olete veendunud, et ExpressRoute‘i võrk ei blokeeri ühegi teise Office 365 teenuse ühendust. QoS-i jaoks konfigureerimist kirjeldatakse artiklis ExpressRoute ja QoS Skype’i ärirakenduse veebiväljaandes.

Juurutuse tõrkeotsing

Esmalt peaks vaatama selles juurutamisjuhendis toodud etappe ja veenduma, et te poleks ühtegi neist vahele jätnud. Minge tagasi ja testige võimaluse korral uuesti väikese võrgu ulatuses ning proovige tõrget seal siluda.

Tehke kindlaks, millistes sissetulevates või väljaminevates teenuseühendustes viga ilmnes. Hankige probleemsete teenuste IP-aadressid ja alamvõrkude teave. Uurige võrgutopoloogia skeemi üksikasjalikult ja kontrollige marsruutimist. Selgitage välja, kuhu ExpressRoute‘i marsruuti välja pakutakse, ja võimaluse korral testige seda marsruuti katkestuse ajal koos jälgimisega.

Käivitage iga kliendipoolse lõpp-punkti jaoks koos jälgimisega RSP ning hinnake siht- ja lähtekoha IP-aadresse, et veenduda nende ootuspärasuses. Saatke telneti päring kõigile porti 25 kasutavatele meilihostidele ja veenduge, et SNAT peidaks algse lähtekoha IP-aadressi, kui see on nii ette nähtud.

Pidage meeles, et Office 365-e koos ExpressRoute‘iga juurutamisel tuleb veenduda, et võrgukonfiguratsioon oleks ExpressRoute‘i jaoks optimaalselt kujundatud ja et ka muud võrgu komponendid (nt klientarvutid) oleksid optimeeritud. Lisaks sellest juhendist kahe silma vahele jäänud toimingute otsimisele võite lugeda ka teemat Jõudluse tõrkeotsingu plaan Office 365 jaoks.

Selle lühikese lingi kaudu saate siia alati tagasi tulla: https://aka.ms/implementexpressroute365

Seotud teemad

Office 365 võrguühendused
Azure ExpressRoute for Office 365
ExpressRoute for Office 365 ühenduvuse haldamine
Marsruutimine teenusega ExpressRoute for Office 365
Võrgu planeerimine teenusega ExpressRoute for Office 365
BGP kogukondade kasutamine ExpressRoute for Office 365 stsenaariumide korral (eelvaade)
Meediumikvaliteet ja võrguühendused Skype‘i ärirakenduse veebiväljaandes
Võrgu optimeerimine Skype‘i ärirakenduse veebiväljaande jaoks
ExpressRoute ja QoS Skype‘i ärirakenduse veebiväljaandes
Kõnevoog ExpressRoute‘i kaudu
Office 365-e jõudluse parandamine võrdlusandmete ja jõudluse ajaloo põhjal
Jõudluse tõrkeotsingu plaan Office 365-e jaoks
Office 365-e URL-ide ja IP-aadresside vahemikud
Office 365-e võrk ja jõudluse parandamine

Täiendage Office'i kasutamise oskusi
Tutvuge koolitusmaterjalidega
Kasutage uusi funktsioone enne teisi
Liituge Office Insideri programmiga

Kas sellest teabest oli abi?

Täname tagasiside eest!

Täname tagasiside eest! Tundub, et võiksime teid kokku viia ühega meie Office'i tugiagentidest, kes aitab teil probleemi lahendada.

×