Microsoft 365 için ExpressRoute Uygulama
Bu makale Microsoft 365 Kurumsal için geçerlidir.
Microsoft 365 için ExpressRoute, İnternet'e yönelik birçok Microsoft 365 hizmeti için alternatif bir yönlendirme yolu sağlar. Microsoft 365 için ExpressRoute mimarisi, bu IP ön eklerinin ağınıza daha sonra yeniden dağıtılma amacıyla sağlanan ExpressRoute bağlantı hatlarınıza İnternet üzerinden zaten erişilebilen Microsoft 365 hizmetlerinin genel IP ön eklerini tanıtma temel alır. ExpressRoute ile birçok Microsoft 365 hizmeti için İnternet üzerinden ve ExpressRoute aracılığıyla birçok farklı yönlendirme yolunu etkili bir şekilde etkinleştirirsiniz. Ağınızdaki bu yönlendirme durumu, iç ağ topolojinizin tasarımında önemli bir değişikliği temsil edebilir.
Not
Çoğu durumda hizmet için en iyi bağlantı modelini sağlamadığından Microsoft 365 için ExpressRoute'u önermeyiz . Bu nedenle, bu bağlantı modelini kullanmak için Microsoft yetkilendirmesi gerekir. Microsoft 365 için expressRoute'u yalnızca gerekli olduğu nadir senaryolarda gözden geçiriyor ve yetkilendiriyoruz. Daha fazla bilgi için lütfen Microsoft 365 için ExpressRoute kılavuzunu okuyun ve üretkenlik, ağ ve güvenlik ekiplerinizle birlikte belgenin kapsamlı bir incelemesini takip edin, gerekirse bir özel durum göndermek için Microsoft hesabı ekibinizle birlikte çalışın. Microsoft 365 için yol filtreleri oluşturmaya çalışan yetkisiz abonelikler bir hata iletisi alır.
Microsoft 365 için ExpressRoute uygulamanızı, hem çekirdek ağınıza hem de İnternet'e eklenen yolların bulunduğu ayrılmış bir bağlantı hattı aracılığıyla kullanılabilir yönlendirmeye sahip ağ karmaşıklıklarına uyum sağlamak için dikkatle planlamanız gerekir. Siz ve ekibiniz bu kılavuzda ayrıntılı planlama ve test gerçekleştirmezseniz, ExpressRoute bağlantı hattı etkinleştirildiğinde microsoft 365 hizmetlerine yönelik aralıklı veya toplam bağlantı kaybıyla karşılaşma riskiniz yüksektir.
Başarılı bir uygulama elde etmek için altyapı gereksinimlerinizi analiz etmeniz, ayrıntılı ağ değerlendirmesi ve tasarımından geçmeniz, dağıtımı aşamalı ve denetimli bir şekilde dikkatle planlamanız ve ayrıntılı bir doğrulama ve test planı oluşturmanız gerekir. Büyük ve dağıtılmış bir ortamda, uygulamaların birkaç aya yayıldığını görmek yaygın bir durum değildir. Bu kılavuz, önceden planlamanıza yardımcı olmak için tasarlanmıştır.
Büyük başarılı dağıtımların planlanması altı ay sürebilir ve genellikle ağ, Güvenlik Duvarı ve Proxy sunucu yöneticileri, Microsoft 365 yöneticileri, güvenlik, son kullanıcı desteği, proje yönetimi ve yönetici sponsorluğu gibi kuruluştaki birçok alandan ekip üyelerini içerebilir. Planlama sürecine yaptığınız yatırım, kesinti süresine veya karmaşık ve pahalı sorun giderme işlemlerine neden olan dağıtım hatalarıyla karşılaşma olasılığını azaltır.
Bu uygulama kılavuzu başlatılmadan önce aşağıdaki önkoşulların tamamlanmasını bekliyoruz.
ExpressRoute'un önerilip önerilmediğini ve onaylanıp onaylanmadığını belirlemek için bir ağ değerlendirmesi tamamladınız.
Bir ExpressRoute ağ hizmeti sağlayıcısı seçtiniz. ExpressRoute iş ortakları ve eşleme konumları hakkındaki ayrıntıları bulun.
ExpressRoute belgelerini zaten okuyup anladınız ve iç ağınız ExpressRoute önkoşullarını uçtan uca karşılayabilir.
Ekibiniz , konumundaki tüm genel yönergeleri ve belgeleri https://aka.ms/expressrouteoffice365okudu ve aşağıdakiler gibi kritik teknik ayrıntıları anlamak için Channel 9'daki Microsoft 365 için Azure ExpressRoute Eğitim serisini izledi: https://aka.ms/ert
SaaS hizmetlerinin internet bağımlılıkları.
Asimetrik yollardan kaçınma ve karmaşık yönlendirmeyi işleme.
Çevre güvenliği, kullanılabilirlik ve uygulama düzeyi denetimlerini birleştirme.
Gereksinimleri toplayarak başlayın
Kuruluşunuzda benimsemeyi planladığınız özellikleri ve hizmetleri belirleyerek başlayın. Farklı Microsoft 365 hizmetlerinin hangi özelliklerinin kullanılacağını ve ağınızdaki hangi konumların bu özellikleri kullanan kişileri barındıracağını belirlemeniz gerekir. Senaryo kataloğuyla, bu senaryoların her birinin gerektirdiği ağ özniteliklerini eklemeniz gerekir; örneğin, gelen ve giden ağ trafiği akışları ve Microsoft 365 uç noktalarının ExpressRoute üzerinden kullanılabilir olup olmadığı gibi.
Kuruluşunuzun gereksinimlerini toplamak için:
Kuruluşunuzun kullandığı Microsoft 365 hizmetleri için gelen ve giden ağ trafiğini kataloglar. Farklı Microsoft 365 senaryolarının gerektirdiği akışların açıklaması için Microsoft 365 URL'leri ve IP adresi aralıkları sayfasına bakın.
İç WAN omurganızın ve topolojinizin ayrıntılarını, uydu sitelerinin bağlantısını, son mil kullanıcı bağlantısını, ağ çevre çıkış noktalarına yönlendirmeyi ve ara sunucu hizmetlerini gösteren mevcut ağ topolojisinin belgelerini toplayın.
Microsoft 365 ve diğer Microsoft hizmetlerinin bağlanacağı ağ diyagramlarındaki gelen hizmet uç noktalarını belirleyin ve hem İnternet hem de önerilen ExpressRoute bağlantı yollarını gösterir.
Tüm coğrafi kullanıcı konumlarını ve konumlar arasındaki WAN bağlantısının yanı sıra şu anda İnternet'e çıkış yapan konumları ve ExpressRoute eşleme konumuna çıkış yapılmasının önerildiği konumları belirleyin.
Proxy'ler, güvenlik duvarları vb. gibi tüm uç cihazları tanımlayın ve İnternet ve ExpressRoute üzerinden giden akışlarla ilişkilerini kataloglar.
Son kullanıcıların Hem İnternet hem de ExpressRoute akışları için Doğrudan Yönlendirme veya dolaylı uygulama ara sunucusu aracılığıyla Microsoft 365 hizmetlerine erişip erişmeyeceğini belgeleyin.
Ağ diyagramınıza kiracınızın ve meet-me konumlarınızın konumunu ekleyin.
Ana kullanıcı konumlarından Microsoft 365'e kadar beklenen ve gözlemlenen ağ performansı ve gecikme süresi özelliklerini tahmin edin. Microsoft 365'in genel ve dağıtılmış bir hizmet kümesi olduğunu ve kullanıcıların kiracılarının konumundan farklı olabilecek konumlara bağlanacağını unutmayın. Bu nedenle, kullanıcı ile ExpressRoute ve İnternet bağlantıları üzerinden Microsoft genel ağının en yakın kenarı arasındaki gecikme süresini ölçmek ve iyileştirmek önerilir. Bu göreve yardımcı olmak için ağ değerlendirmesinden elde ettiğiniz bulguları kullanabilirsiniz.
Yeni ExpressRoute bağlantısıyla karşılanması gereken şirket ağ güvenliği ve yüksek kullanılabilirlik gereksinimlerini listeleyin. Örneğin, İnternet çıkışı veya ExpressRoute bağlantı hattı hatası durumunda kullanıcılar Microsoft 365'e erişmeye nasıl devam eder?
Hangi gelen ve giden Microsoft 365 ağ akışlarının İnternet yolunu ve hangilerinin ExpressRoute kullanacağını belgele. Kullanıcılarınızın coğrafi konumlarının özellikleri ve şirket içi ağ topolojinizin ayrıntıları, planın bir kullanıcı konumundan diğerine farklı olmasını gerektirebilir.
Giden ve gelen ağ trafiğinizi katalogla
Yönlendirmeyi ve diğer ağ karmaşıklıklarını en aza indirmek için, microsoft 365 için ExpressRoute'u yalnızca mevzuat gereksinimleri nedeniyle veya ağ değerlendirmesinin sonucu olarak ayrılmış bir bağlantı üzerinden geçmek için gereken ağ trafiği akışları için kullanmanızı öneririz. Ayrıca, ExpressRoute yönlendirme ve yaklaşım giden ve gelen ağ trafiği akışlarının kapsamını uygulama projesinin farklı ve ayrı aşamaları olarak hazırlamanızı öneririz. Microsoft 365 için ExpressRoute'u yalnızca kullanıcı tarafından başlatılan giden ağ trafiği akışları için dağıtın ve İnternet genelinde gelen ağ trafiği akışlarını bırakın, topolojik karmaşıklıktaki artışı ve ek asimetrik yönlendirme olasılıkları sunma risklerini denetlemeye yardımcı olabilir.
Ağ trafiği kataloğunuz, şirket içi ağınızla Microsoft arasında sahip olduğunuz tüm gelen ve giden ağ bağlantılarının listelerini içermelidir.
Giden ağ trafiği akışları, şirket içi ortamınızdan (örneğin, iç istemcilerden veya sunuculardan) Microsoft hizmetlerinin hedefine sahip bir bağlantının başlatıldığı tüm senaryolardır. Bu bağlantılar, bağlantının Microsoft 365 yolundaki ara sunuculardan, güvenlik duvarlarından veya diğer ağ cihazlarından geçmesi gibi doğrudan Microsoft 365'e veya dolaylı olabilir.
Gelen ağ trafiği akışları, Microsoft bulutundan şirket içi konağa bağlantının başlatıldığı tüm senaryolardır. Bu bağlantıların genellikle dış kaynaklı akışlar için müşteri güvenlik ilkesinin gerektirdiği güvenlik duvarından ve diğer güvenlik altyapısından geçmesi gerekir.
Hangi hizmetlerin gelen trafik göndereceğini belirlemek için Rota simetrisini sağlama bölümünü okuyun ve bağlantı bilgilerinin geri kalanını belirlemek için Microsoft 365 uç noktaları başvuru makalesinde Microsoft 365 için ExpressRoute olarak işaretlenmiş sütunu arayın.
Giden bağlantı gerektiren her hizmet için ağ yönlendirme, ara sunucu yapılandırması, paket incelemesi ve bant genişliği gereksinimleri gibi hizmet için planlanan bağlantıyı açıklamak istersiniz.
Gelen bağlantı gerektiren her hizmet için bazı ek bilgilere ihtiyacınız olacaktır. Microsoft bulutundaki sunucular, şirket içi ağınızla bağlantı kurar. Bağlantıların doğru yapıldığından emin olmak için; bu gelen bağlantıları kabul edecek hizmetlerin genel DNS girişleri, CIDR biçimlendirilmiş IPv4 IP adresleri, hangi ISS ekipmanının dahil olduğu ve bu bağlantılar için gelen NAT veya kaynak NAT'nin nasıl işlendiği.
Asimetrik yönlendirmenin kullanılmadığından emin olmak için İnternet üzerinden mi yoksa ExpressRoute üzerinden mi bağlandıklarına bakılmaksızın gelen bağlantılar gözden geçirilmelidir. Bazı durumlarda, Microsoft 365 hizmetlerinin gelen bağlantıları başlattığı şirket içi uç noktalarına diğer Microsoft ve Microsoft dışı hizmetler de erişmesi gerekebilir. Microsoft 365 amacıyla bu hizmetlere ExpressRoute yönlendirmesini etkinleştirmenin diğer senaryoları bozmaması çok önemlidir. Çoğu durumda müşterilerin, ExpressRoute etkinleştirildikten sonra Microsoft'tan gelen akışların simetrik kalmasını sağlamak için kaynak tabanlı NAT gibi iç ağlarında belirli değişiklikler yapmaları gerekebilir.
Aşağıda gerekli ayrıntı düzeyinin bir örneği verilmişti. Bu durumda Exchange Karma, ExpressRoute üzerinden şirket içi sisteme yönlendirilir.
| Bağlantı özelliği | Değer |
|---|---|
| Ağ trafiği yönü |
Gelen |
| Hizmet |
Exchange Karma |
| Genel Microsoft 365 uç noktası (kaynak) |
Exchange Online (IP adresleri) |
| Genel Şirket İçi Uç Nokta (hedef) |
5.5.5.5 |
| Genel (İnternet) DNS girişi |
Autodiscover.contoso.com |
| Bu şirket içi uç nokta diğer (Microsoft 365 dışı) Microsoft hizmetleri için kullanılacak mı? |
Hayır |
| Bu şirket içi uç nokta İnternet'te kullanıcılar/sistemler tarafından kullanılacak mı? |
Evet |
| Genel uç noktalar aracılığıyla yayımlanan iç sistemler |
Exchange Server istemci erişim rolü (şirket içi) 192.168.101, 192.168.102, 192.168.103 |
| Genel uç noktanın IP tanıtımı |
İnternet'e: 5.5.0.0/ 16-ExpressRoute: 5.5.5.0/24 |
| Güvenlik/Çevre Denetimleri |
İnternet yolu: ExpressRoute yolunu DeviceID_002: DeviceID_003 |
| Yüksek Kullanılabilirlik |
2 coğrafi olarak yedekli / ExpressRoute bağlantı hattında Etkin/Etkin - Chicago ve Dallas |
| Yol simetri denetimi |
Yöntem: Kaynak NAT İnternet yolu: 192.168.5.5 ExpressRoute yoluna kaynak NAT gelen bağlantıları: 192.168.1.0 (Chicago) ve 192.168.2.0 (Dallas) ile kaynak NAT bağlantıları |
Aşağıda yalnızca giden bir hizmet örneği verilmiştir:
| Bağlantı özelliği | Değer |
|---|---|
| Ağ trafiği yönü |
Giden |
| Hizmet |
SharePoint |
| Şirket içi uç nokta (kaynak) |
Kullanıcı iş istasyonu |
| Genel Microsoft 365 uç noktası (hedef) |
SharePoint (IP adresleri) |
| Genel (İnternet) DNS girişi |
*.sharepoint.com (ve daha fazla FQDN) |
| CDN Başvuruları |
cdn.sharepointonline.com (ve daha fazla FQDN) - CDN sağlayıcıları tarafından tutulan IP adresleri) |
| IP tanıtımı ve NAT kullanımda |
İnternet yolu/Kaynak NAT: 1.1.1.0/24 ExpressRoute yolu/Kaynak NAT: 1.1.2.0/24 (Chicago) ve 1.1.3.0/24 (Dallas) |
| Bağlantı yöntemi |
İnternet: katman 7 ara sunucusu (.pac dosyası) aracılığıyla ExpressRoute: doğrudan yönlendirme (ara sunucu yok) |
| Güvenlik/Çevre Denetimleri |
İnternet yolu: DeviceID_002 ExpressRoute yolu: DeviceID_003 |
| Yüksek Kullanılabilirlik |
İnternet yolu: Yedekli internet çıkışı ExpressRoute yolu: 2 coğrafi olarak yedekli ExpressRoute bağlantı hattı boyunca etkin/etkin 'sıcak patates' yönlendirmesi - Chicago ve Dallas |
| Yol simetri denetimi |
Yöntem: Tüm bağlantılar için kaynak NAT |
Bölgesel bağlantı ile ağ topolojisi tasarımınız
Hizmetleri ve bunlarla ilişkili ağ trafiği akışlarını anladıktan sonra, bu yeni bağlantı gereksinimlerini içeren ve Microsoft 365 için ExpressRoute'u kullanmak için yaptığınız değişiklikleri gösteren bir ağ diyagramı oluşturabilirsiniz. Diyagramınız şunları içermelidir:
Microsoft 365 ve diğer hizmetlerin erişileceği tüm kullanıcı konumları.
Tüm internet ve ExpressRoute çıkış noktaları.
Yönlendiriciler, güvenlik duvarları, uygulama ara sunucuları ve yetkisiz erişim algılama/önleme dahil olmak üzere ağ içinde ve dışında bağlantıyı yöneten tüm giden ve gelen cihazlar.
ADFS web uygulaması proxy sunucularından bağlantıları kabul eden iç ADFS sunucuları gibi tüm gelen trafik için iç hedefler.
Tanıtılacak tüm IP alt ağlarının kataloğu
Kişilerin Microsoft 365'e erişeceği her konumu belirleyin ve ExpressRoute için kullanılacak meet-me konumlarını listeleyin.
ExpressRoute'tan öğrenilen Microsoft IP ön eklerinin kabul edildiği, filtreleneceği ve yayılacağı iç ağ topolojinizin konumları ve bölümleri.
Ağ topolojisi, her ağ kesiminin coğrafi konumunu ve ExpressRoute ve/veya İnternet üzerinden Microsoft ağına nasıl bağlanıyor olduğunu göstermelidir.
Aşağıdaki diyagramda, kişilerin Microsoft 365'e gelen ve giden yönlendirme tanıtımlarıyla birlikte Microsoft 365'i kullanacakları her konum gösterilmektedir.
Giden trafik için kişiler Microsoft 365'e şu üç yoldan biriyle erişer:
California'daki insanlar için Kuzey Amerika'da bir buluşma yeri aracılığıyla.
Hong Kong ÖİB'deki insanlar için Hong Kong Özel İdari Bölgesi'ndeki bir buluşma konumu aracılığıyla.
Bangladeş'te daha az kişinin bulunduğu ve ExpressRoute bağlantı hattının sağlanmamış olduğu İnternet üzerinden.
Benzer şekilde, Microsoft 365'ten gelen ağ trafiği üç yoldan biriyle döndürülüyor:
California'daki insanlar için Kuzey Amerika'da bir buluşma yeri aracılığıyla.
Hong Kong ÖİB'deki insanlar için Hong Kong Özel İdari Bölgesi'ndeki bir buluşma konumu aracılığıyla.
Bangladeş'te daha az kişinin bulunduğu ve ExpressRoute bağlantı hattının sağlanmamış olduğu İnternet üzerinden.
Uygun buluşma konumunu belirleme
ExpressRoute bağlantı hattınızın ağınızı Microsoft ağına bağladığı fiziksel konum olan meet-me konumlarının seçimi, kişilerin Microsoft 365'e erişeceği konumlardan etkilenir. SaaS teklifi olarak Microsoft 365, IaaS veya PaaS bölgesel modeli kapsamında Azure ile aynı şekilde çalışmaz. Bunun yerine Microsoft 365, kullanıcıların birden çok veri merkezi ve bölgede uç noktalara bağlanması gerekebileceği ve kullanıcının kiracısının barındırıldığı aynı konumda veya bölgede olmayabileceği dağıtılmış bir işbirliği hizmetleri kümesidir.
Bu, Microsoft 365 için ExpressRoute için benimle buluşma konumlarını seçerken dikkat etmeniz gereken en önemli nokta, kuruluşunuzdaki kişilerin bağlanacağı yerdir. En iyi Microsoft 365 bağlantısı için genel öneri yönlendirme uygulamaktır; böylece Microsoft 365 hizmetlerine yönelik kullanıcı istekleri en kısa ağ yolu üzerinden Microsoft ağına iletilir; bu genellikle "sıcak patates" yönlendirmesi olarak da adlandırılır. Örneğin, Microsoft 365 kullanıcılarının çoğu bir veya iki konumdaysa, bu kullanıcıların konumuna en yakın olan meet-me konumlarının seçilmesi en uygun tasarımı oluşturur. Şirketinizin birçok farklı bölgede büyük kullanıcı popülasyonları varsa, birden çok ExpressRoute bağlantı hattına ve meet-me konumuna sahip olmayı düşünebilirsiniz. Bazı kullanıcı konumlarınız için, Microsoft ağına ve Microsoft 365'e giden en kısa/en uygun yol, iç WAN ve ExpressRoute meet-me noktalarınız üzerinden değil, İnternet üzerinden olabilir.
Çoğu zaman, kullanıcılarınıza göreli yakınlığı olan bir bölge içinde seçilebilen birden çok meet-me konumu vardır. Kararlarınıza yol göstermek için aşağıdaki tabloyu doldurun.
California ve New York'ta planlanan ExpressRoute buluşma konumları
| Konum |
Kişi sayısı |
İnternet çıkışı üzerinden Microsoft ağında beklenen gecikme süresi |
ExpressRoute üzerinden Microsoft ağında beklenen gecikme süresi |
|---|---|---|---|
| Los Angeles |
10,000 |
~15ms |
~10ms (Silikon Vadisi aracılığıyla) |
| Washington DC |
15,000 |
~20ms |
~10ms (New York üzerinden) |
| Dallas |
5,000 |
~15ms |
~40ms (New York üzerinden) |
Microsoft 365 bölgesini, ExpressRoute ağ hizmeti sağlayıcısının benimle toplantı konumlarını ve konuma göre kişi sayısını gösteren genel ağ mimarisi geliştirildikten sonra, herhangi bir iyileştirme yapılıp yapılamadığını belirlemek için kullanılabilir. Ayrıca, benimle buluşma konumuna ulaşmak için trafiğin uzak bir konuma yönlendirildiği küresel saç tokası ağ bağlantılarını da gösterebilir. Küresel ağda bir saç tokası bulunursa, devam etmeden önce düzeltilmelidir. Başka bir buluşma konumu bulun veya saç tokasından kaçınmak için seçmeli İnternet çıkış noktalarını kullanın.
İlk diyagramda, Kuzey Amerika iki fiziksel konumu olan bir müşteri örneği gösterilmektedir. Office konumları, Microsoft 365 kiracı konumları ve ExpressRoute meet-me konumları için çeşitli seçenekler hakkındaki bilgileri görebilirsiniz. Bu örnekte müşteri, iki ilkeye göre meet-me konumunu şu sırayla seçmiştir:
Kuruluşundaki kişilere en yakın olan.
Microsoft 365'in barındırıldığı microsoft veri merkezine en yakın konum.
Bu kavramı biraz daha genişleten ikinci diyagramda, benzer bilgiler ve karar alma süreciyle karşı karşıya kalan çok uluslu bir müşteri örneği gösterilmektedir. Bu müşterinin Bangladeş'te küçük bir ofisi var ve bölgede ayak izini büyütmeye odaklanan 10 kişilik küçük bir ekip var. Chennai'de bir buluşma konumu ve Chennai'de barındırılan Microsoft 365'in bulunduğu bir Microsoft veri merkezi var, bu nedenle bir buluşma konumu mantıklı olacaktır; Ancak, 10 kişi için ekstra devrenin maliyeti ağırdır. Ağınıza baktığınızda, ağ trafiğinizi ağınıza gönderirken gecikme süresinin başka bir ExpressRoute bağlantı hattı elde etmek için sermaye harcamaktan daha etkili olup olmadığını belirlemeniz gerekir.
Alternatif olarak, Bangladeş'teki 10 kişi İnternet üzerinden Microsoft ağına gönderilen ağ trafiğinde giriş diyagramlarında gösterdiğimiz ve aşağıda yeniden üretilen iç ağlarına yönlendireceklerinden daha iyi performansla karşılaşabilir.
Microsoft 365 için ExpressRoute uygulama planınızı İçerik Oluşturucu
Uygulama planınız hem ExpressRoute'u yapılandırmayla ilgili teknik ayrıntıları hem de ağınızdaki diğer tüm altyapıyı yapılandırma ayrıntılarını (örneğin, aşağıdakiler) içermelidir.
ExpressRoute ile İnternet arasında hangi hizmetlerin bölündüğünü planlayın.
Bant genişliği, güvenlik, yüksek kullanılabilirlik ve yük devretmeyi planlayın.
Farklı konumlar için uygun yönlendirme yolu iyileştirmeleri de dahil olmak üzere gelen ve giden yönlendirme tasarlama
ExpressRoute yollarının ağınıza ne kadar tanıtılacağına ve istemcilerin İnternet veya ExpressRoute yolunu seçme mekanizmasının ne olduğuna karar verin; örneğin, doğrudan yönlendirme veya uygulama ara sunucusu.
Sender Policy Framework girişleri de dahil olmak üzere DNS kaydı değişikliklerini planlayın.
Giden ve gelen kaynak NAT'sı da dahil olmak üzere NAT stratejisini planlayın.
Yönlendirmenizi hem İnternet hem de ExpressRoute ağ yolları ile planlama
İlk dağıtımınızda, gelen e-posta veya karma bağlantı gibi tüm gelen hizmetlerin İnternet'i kullanması önerilir.
PAC/WPAD dosyası, varsayılan yol, ara sunucu ve BGP yol tanıtımlarını yapılandırma gibi son kullanıcı istemci LAN yönlendirmesini planlayın.
Ara sunucular, güvenlik duvarları ve bulut proxy'leri de dahil olmak üzere çevre yönlendirmesini planlayın.
Bant genişliğinizi, güvenliğinizi, yüksek kullanılabilirliğinizi ve yük devretmenizi planlama
Her büyük Microsoft 365 iş yükü için gereken bant genişliği planını İçerik Oluşturucu. Exchange Online, SharePoint ve Skype Kurumsal Online bant genişliği gereksinimlerini ayrı ayrı tahmin edin. başlangıç noktası olarak Exchange Online ve Skype Kurumsal için sağladığımız tahmin hesaplayıcılarını kullanabilirsiniz; ancak kuruluşunuzun bant genişliği gereksinimlerini tam olarak anlamak için kullanıcı profillerinin ve konumlarının temsili bir örneğini içeren bir pilot test gereklidir.
Her İnternet'te ve ExpressRoute çıkış konumunda güvenliğin nasıl işleneceğini planınıza ekleyin, Microsoft 365'e yapılan tüm ExpressRoute bağlantılarının genel eşleme kullandığını ve dış ağlara bağlanmaya yönelik şirketinizin güvenlik ilkelerine uygun olarak korunması gerektiğini unutmayın.
Planınıza, hangi kişilerin ne tür bir kesintiden etkileneceği ve bu kişilerin işlerini en basit şekilde tam kapasitede nasıl gerçekleştirebileceklerine ilişkin ayrıntıları ekleyin.
Jitter, Gecikme Süresi, Tıkanıklık ve Kafa Odası ile ilgili Skype Kurumsal gereksinimleri de dahil olmak üzere bant genişliği gereksinimlerini planlama
Skype Kurumsal Online ayrıca, Skype Kurumsal Online'da Medya Kalitesi ve Ağ Bağlantısı Performansı makalesinde ayrıntılı olarak verilen belirli ek ağ gereksinimlerine sahiptir.
Azure ExpressRoute için bant genişliği planlaması bölümünü okuyun. Pilot kullanıcılarınız ile bant genişliği değerlendirmesi yaparken temelleri ve performans geçmişini kullanarak Microsoft 365 performans ayarlama kılavuzumuzu kullanabilirsiniz.
Yüksek kullanılabilirlik gereksinimlerini planlama
gereksinimlerinizi karşılamak için yüksek kullanılabilirlik planı İçerik Oluşturucu ve bunu güncelleştirilmiş ağ topolojisi diyagramınıza dahil edin. Azure ExpressRoute ile yüksek kullanılabilirlik ve yük devretme bölümünü okuyun.
Ağ güvenlik gereksinimlerini planlama
Ağ güvenlik gereksinimlerinizi karşılamaya yönelik bir plan İçerik Oluşturucu ve bunu güncelleştirilmiş ağ topolojisi diyagramınıza dahil edin. Microsoft 365 senaryoları için Azure ExpressRoute'a güvenlik denetimleri uygulama bölümünü okuyun.
Giden hizmet bağlantısı tasarlama
Microsoft 365 için ExpressRoute'un yabancı olabilecek giden ağ gereksinimleri vardır. Özellikle, kullanıcılarınızı ve ağlarınızı Microsoft 365'e temsil eden ve Microsoft'a giden ağ bağlantıları için kaynak uç noktalar olarak görev alan IP adresleri aşağıda belirtilen belirli gereksinimleri karşılamalıdır.
Uç noktaların şirketinize veya size ExpressRoute bağlantısı sağlayan operatöre kayıtlı genel IP adresleri olması gerekir.
Uç noktaların Microsoft'a tanıtılması ve ExpressRoute tarafından doğrulanması/kabul edilmesi gerekir.
Uç noktalar, aynı veya daha fazla tercih edilen yönlendirme ölçümüyle İnternet'e tanıtılmamalıdır.
ExpressRoute üzerinden yapılandırılmamış Microsoft hizmetlerine bağlantı için uç noktalar kullanılmamalıdır.
Ağ tasarımınız bu gereksinimleri karşılamıyorsa, kullanıcılarınızın siyah hol veya asimetrik yönlendirme yönlendirmesi nedeniyle Microsoft 365 ve diğer Microsoft hizmetlerine bağlantı hataları yaşama riski yüksektir. Bu durum, Microsoft hizmetlerine yönelik istekler ExpressRoute üzerinden yönlendirildiğinde, ancak yanıtlar İnternet üzerinden geri yönlendirildiğinde (veya tam tersi) ve yanıtlar güvenlik duvarları gibi durum bilgisi olan ağ cihazları tarafından bırakıldığında oluşur.
Yukarıdaki gereksinimleri karşılamak için kullanabileceğiniz en yaygın yöntem, ağınızın bir parçası olarak uygulanan veya ExpressRoute operatörünüz tarafından sağlanan kaynak NAT'yi kullanmaktır. Kaynak NAT, internet ağınızın ayrıntılarını ve özel IP adreslemesini ExpressRoute'tan soyutlamanızı sağlar ve; uygun IP yolu tanıtımlarıyla birleştiğinde, yol simetrisini sağlamak için kolay bir mekanizma sağlar. ExpressRoute eşleme konumlarına özgü durum bilgisi olan ağ cihazları kullanıyorsanız yol simetrisini sağlamak için her ExpressRoute eşlemesi için ayrı NAT havuzları uygulamanız gerekir.
ExpressRoute NAT gereksinimleri hakkında daha fazla bilgi edinin.
Ağ topolojisi diyagramına giden bağlantı için değişiklikleri ekleyin.
Gelen hizmet bağlantısını tasarlama
Kurumsal Microsoft 365 dağıtımlarının çoğu Exchange, SharePoint ve Skype Kurumsal karma senaryoları, posta kutusu geçişleri ve ADFS altyapısı kullanılarak kimlik doğrulaması gibi şirket içi hizmetlere Microsoft 365'ten gelen bir tür bağlantı olduğunu varsayar. ExpressRoute, giden bağlantı için şirket içi ağınız ile Microsoft arasında ek bir yönlendirme yolu etkinleştirdiğinizde, bu akışların İnternet'i kullanmaya devam etmesi amaçlanmış olsa bile bu gelen bağlantılar yanlışlıkla asimetrik yönlendirmeden etkilenebilir. Microsoft 365'ten şirket içi sistemlere İnternet tabanlı gelen akışları etkilemediğinden emin olmak için aşağıda açıklanan birkaç önlem önerilir.
Gelen ağ trafiği akışları için asimetrik yönlendirme risklerini en aza indirmek için, tüm gelen bağlantıların ağınızın segmentlerine yönlendirilmeden önce kaynak NAT kullanması gerekir ve bu da ExpressRoute'a yönlendirme görünürlüğü sağlar. Gelen bağlantılara kaynak NAT olmadan ExpressRoute'a yönlendirme görünürlüğü olan bir ağ kesimine izin veriliyorsa, Microsoft 365'ten kaynaklanan istekler İnternet'ten girer, ancak Microsoft 365'e geri dönen yanıt ExpressRoute ağ yolunu Microsoft ağına geri tercih eder ve bu da asimetrik yönlendirmeye neden olur.
Bu gereksinimi karşılamak için aşağıdaki uygulama desenlerinden birini düşünebilirsiniz:
İstekler, İnternet'ten şirket içi sistemlerinize giden yolda güvenlik duvarları veya yük dengeleyiciler gibi ağ donanımlarını kullanarak iç ağınıza yönlendirilmeden önce kaynak NAT gerçekleştirin.
ExpressRoute yollarının, ön uç sunucuları veya ters ara sunucu sistemleri gibi gelen hizmetlerin bulunduğu ağ kesimlerine yayılmadığından ve İnternet bağlantılarının işlenmediğinden emin olun.
Ağınızdaki bu senaryoların açıkça hesaplanması ve İnternet üzerinden gelen tüm ağ trafiği akışlarının tutulması, asimetrik yönlendirme dağıtım ve işletimsel riskin en aza indirilmesine yardımcı olur.
Bazı gelen akışları ExpressRoute bağlantıları üzerinden yönlendirmeyi seçebileceğiniz durumlar olabilir. Bu senaryolar için aşağıdaki ek konuları dikkate alın.
Microsoft 365 yalnızca genel IP'leri kullanan şirket içi uç noktaları hedefleyebilir. Başka bir deyişle, şirket içi gelen uç nokta ExpressRoute üzerinden yalnızca Microsoft 365'e açık olsa bile bununla ilişkilendirilmiş genel IP'ye sahip olması gerekir.
Microsoft 365 hizmetlerinin şirket içi uç noktaları çözümlemek için gerçekleştirdiği tüm DNS ad çözümlemesi genel DNS kullanılarak gerçekleşir. Bu, gelen hizmet uç noktalarının FQDN'sini İnternet'teki IP eşlemelerine kaydetmeniz gerektiği anlamına gelir.
ExpressRoute üzerinden gelen ağ bağlantılarını almak için bu uç noktaların genel IP alt ağlarının ExpressRoute üzerinden Microsoft'a tanıtılması gerekir.
Bu gelen ağ trafiği akışlarını dikkatle değerlendirerek şirketinizin güvenlik ve ağ ilkelerine uygun güvenlik ve ağ denetimlerinin uygulandığını doğrulayın.
Şirket içi gelen uç noktalarınız ExpressRoute üzerinden Microsoft'a tanıtıldıktan sonra ExpressRoute, Microsoft 365 dahil olmak üzere tüm Microsoft hizmetleri için bu uç noktaların tercih edilen yönlendirme yolu haline gelir. Bu, bu uç nokta alt ağlarının yalnızca Microsoft 365 hizmetleriyle iletişim için ve Microsoft ağındaki diğer hizmetlerle iletişim için kullanılması gerektiği anlamına gelir. Aksi takdirde, tasarımınız diğer Microsoft hizmetlerinden gelen bağlantıların ExpressRoute üzerinden gelen bağlantıları yönlendirmeyi tercih ettiği asimetrik yönlendirmeye neden olurken, dönüş yolu İnternet'i kullanır.
ExpressRoute bağlantı hattının veya meet-me konumunun devre dışı olması durumunda, şirket içi gelen uç noktaların istekleri ayrı bir ağ yolu üzerinden kabul etmek için hala kullanılabilir olduğundan emin olmanız gerekir. Bu, bu uç noktaların alt ağlarını birden çok ExpressRoute bağlantı hattı üzerinden tanıtma anlamına gelebilir.
Özellikle bu akışlar güvenlik duvarları gibi durum bilgisi olan ağ cihazları arasında geçiş yaparken, ExpressRoute aracılığıyla ağınıza giren tüm gelen ağ trafiği akışları için kaynak NAT uygulamanızı öneririz.
ADFS ara sunucusu veya Exchange otomatik bulma gibi bazı şirket içi hizmetler hem Microsoft 365 hizmetlerinden hem de İnternet'ten gelen istekler alabilir. Bu istekler için Microsoft 365, İnternet üzerinden kullanıcı istekleriyle aynı FQDN'yi hedefleyecektir. Microsoft 365 bağlantılarını ExpressRoute kullanmaya zorlarken, İnternet'ten bu şirket içi uç noktalara gelen kullanıcı bağlantılarına izin vermek, önemli yönlendirme karmaşıklığını temsil eder. ExpressRoute üzerinden bu tür karmaşık senaryolar uygulayan müşterilerin büyük çoğunluğu, operasyonel konular nedeniyle önerilmez. Bu ek yük, asimetrik yönlendirme risklerini yönetmeyi içerir ve yönlendirme tanıtımlarını ve ilkelerini birden çok boyutta dikkatle yönetmenizi gerektirir.
Asimetrik yollardan nasıl kaçınabileceğinizi göstermek için ağ topolojisi planınızı güncelleştirin
Kuruluşunuzdaki kişilerin Hem Microsoft 365'i hem de İnternet'teki diğer önemli hizmetleri sorunsuz bir şekilde kullanabilmesini sağlamak için asimetrik yönlendirmeden kaçınmak istiyorsunuz. Müşterilerin asimetrik yönlendirmeye neden olan iki yaygın yapılandırması vardır. Şimdi kullanmayı planladığınız ağ yapılandırmasını gözden geçirmek ve bu asimetrik yönlendirme senaryolarından birinin mevcut olup olmadığını denetlemek için uygun bir zaman.
Başlamak için aşağıdaki ağ diyagramıyla ilişkili birkaç farklı durumu inceleyeceğiz. Bu diyagramda, ADFS veya şirket içi karma sunucular gibi gelen istekleri alan tüm sunucular New Jersey veri merkezindedir ve İnternet'e tanıtılır.
Çevre ağı güvenli olsa da, gelen istekler için kullanılabilir Kaynak NAT yoktur.
New Jersey veri merkezindeki sunucular hem internet hem de ExpressRoute yollarını görebilir.
Bunların nasıl düzeltileceğini de önerebiliriz.
Sorun 1: İnternet üzerinden buluttan şirket içi bağlantıya
Aşağıdaki diyagramda, ağ yapılandırmanız İnternet üzerinden Microsoft bulutundan gelen istekler için NAT sağlamadığında alınan asimetrik ağ yolu gösterilmektedir.
Microsoft 365'ten gelen istek, şirket içi uç noktanın IP adresini genel DNS'den alır ve isteği çevre ağınıza gönderir.
Bu hatalı yapılandırmada trafiğin gönderildiği çevre ağında yapılandırılmış veya kullanılabilir kaynak NAT yoktur ve sonuç olarak dönüş hedefi olarak gerçek kaynak IP adresi kullanılır.
Ağınızdaki sunucu, dönüş trafiğini kullanılabilir herhangi bir ExpressRoute ağ bağlantısı aracılığıyla Microsoft 365'e yönlendirir.
Sonuç, Microsoft 365'e giden akışın Asimetrik bir yoludur ve bağlantının bozulmasına neden oluyor.
Çözüm 1a: Kaynak NAT
Gelen isteğe kaynak NAT eklemek, yanlış yapılandırılmış bu ağı çözer. Bu diyagramda:
Gelen istek, New Jersey veri merkezinin çevre ağı üzerinden girmeye devam eder. Bu kez Kaynak NAT kullanılabilir.
Sunucudan gelen yanıt, özgün IP adresi yerine Kaynak NAT ile ilişkili IP'ye geri yönlendirilir ve bu da yanıtın aynı ağ yolu boyunca dönmesine neden olur.
Çözüm 1b: Yol Kapsamı
Alternatif olarak, ExpressRoute BGP ön eklerinin tanıtılmamasına izin vermemeyi seçebilir ve bu bilgisayarlar için alternatif ağ yolunu kaldırabilirsiniz. Bu diyagramda:
Gelen istek, New Jersey veri merkezinin çevre ağı üzerinden girmeye devam eder. Bu kez ExpressRoute bağlantı hattı üzerinden Microsoft'tan tanıtılan ön ekler New Jersey veri merkezinde kullanılamaz.
Sunucudan gelen yanıt, kullanılabilir tek yol üzerinden özgün IP adresiyle ilişkilendirilmiş IP'ye geri yönlendirilir ve bu da yanıtın aynı ağ yolu boyunca dönmesine neden olur.
Sorun 2: ExpressRoute üzerinden buluttan şirket içi bağlantıya
Aşağıdaki diyagramda, ağ yapılandırmanız ExpressRoute üzerinden Microsoft bulutundan gelen istekler için NAT sağlamadığında alınan asimetrik ağ yolu gösterilmektedir.
Microsoft 365'ten gelen istek, DNS'den IP adresini alır ve isteği çevre ağınıza gönderir.
Bu hatalı yapılandırmada trafiğin gönderildiği çevre ağında yapılandırılmış veya kullanılabilir kaynak NAT yoktur ve sonuç olarak dönüş hedefi olarak gerçek kaynak IP adresi kullanılır.
Ağınızdaki bilgisayar, dönüş trafiğini kullanılabilir herhangi bir ExpressRoute ağ bağlantısı aracılığıyla Microsoft 365'e yönlendirir.
Sonuç, Microsoft 365'e asimetrik bir bağlantıdır.
Çözüm 2: Kaynak NAT
Gelen isteğe kaynak NAT eklemek, yanlış yapılandırılmış bu ağı çözer. Bu diyagramda:
Gelen istek, New York veri merkezinin çevre ağı üzerinden girmeye devam eder. Bu kez Kaynak NAT kullanılabilir.
Sunucudan gelen yanıt, özgün IP adresi yerine Kaynak NAT ile ilişkili IP'ye geri yönlendirilir ve bu da yanıtın aynı ağ yolu boyunca dönmesine neden olur.
Kağıt ağ tasarımının yol simetrisine sahip olduğunu doğrulama
Bu noktada, uygulama planınızın Microsoft 365'i kullanacağınız farklı senaryolar için rota simetrisi sunduğunu kağıt üzerinde doğrulamanız gerekir. Bir kişi hizmetin farklı özelliklerini kullandığında alınması beklenen belirli ağ yolunu tanımlayacaksınız. Şirket içi ağ ve WAN yönlendirmesinden çevre cihazlarına, bağlantı yoluna; ExpressRoute veya internet ve çevrimiçi uç nokta bağlantısı.
Daha önce kuruluşunuzun benimseyeceği hizmetler olarak tanımlanan tüm Microsoft 365 ağ hizmetleri için bunu yapmanız gerekir.
Bu belgenin ikinci bir kişiyle yolları gözden geçirmesine yardımcı olur. Her ağ atlamasının bir sonraki yolunu nereden alması beklendiğini açıklayın ve yönlendirme yollarını bildiğinizden emin olun. ExpressRoute'un Microsoft sunucusu IP adreslerine her zaman daha kapsamlı bir yol sağladığını ve bunun İnternet varsayılan yolundan daha düşük yol maliyeti sağlayacağını unutmayın.
İstemci Bağlantı Yapılandırması Tasarlama
İnternet'e bağlı trafik için ara sunucu kullanıyorsanız, ağınızdaki istemci bilgisayarların proxy sunucunuza geçiş yapmadan istediğiniz ExpressRoute trafiğini Microsoft 365'e gönderecek şekilde doğru yapılandırıldığından ve bazı Microsoft 365 trafiği de dahil olmak üzere kalan trafiğin ilgili ara sunucuya gönderildiğinden emin olmak için PAC veya istemci yapılandırma dosyalarını ayarlamanız gerekir. Pac dosyaları gibi Microsoft 365 uç noktalarını yönetme kılavuzumuzu okuyun.
Not
Uç noktalar haftalık olarak sık sık değişir. Güncel kalmak için yapmanız gereken değişikliklerin sayısını azaltmak için yalnızca kuruluşunuzun benimsediği hizmetlere ve özelliklere göre değişiklik yapmalısınız. Değişikliklerin duyurulduğu ve tüm geçmiş değişikliklerin kaydının tutulduğu, duyurulan IP adreslerinin geçerlilik tarihine ulaşılana kadar tanıtılmayabileceği veya reklamdan kaldırılmayabileceği RSS akışındaki Geçerlilik Tarihi'ne çok dikkat edin.
Rota simetrisini sağlama
Microsoft 365 ön uç sunucularına hem İnternet'te hem de ExpressRoute'ta erişilebilir. Bu sunucular, her ikisi de kullanılabilir olduğunda ExpressRoute bağlantı hatları üzerinden şirket içine geri yönlendirmeyi tercih eder. Bu nedenle, ağınızdan gelen trafik İnternet bağlantı hatlarınız üzerinden yönlendirmeyi tercih ederse rota asimetrisi olasılığı vardır. Durum bilgisi olan paket incelemesi gerçekleştiren cihazlar, takip edilen giden paketlerden farklı bir yol izleyen dönüş trafiğini engelleyebileceğinden, asimetrik yollar bir sorundur.
Microsoft 365'e İnternet veya ExpressRoute üzerinden bağlantı başlatmanıza bakılmaksızın, kaynak genel olarak yönlendirilebilir bir adres olmalıdır. Birçok müşteri doğrudan Microsoft ile eşlendiğinde, müşteriler arasında yinelemenin mümkün olduğu özel adreslere sahip olmak mümkün değildir.
Aşağıda, Microsoft 365'ten şirket içi ağınıza yönelik iletişimlerin başlatılacağı senaryolar yer almaktadır. Ağ tasarımınızı basitleştirmek için aşağıdakileri İnternet yolu üzerinden yönlendirmenizi öneririz.
Exchange Online kiracıdan şirket içi konağa posta veya SharePoint'ten şirket içi konağa gönderilen SharePoint Mail gibi SMTP hizmetleri. SMTP protokolü, Microsoft'un ağı içinde ExpressRoute bağlantı hatları üzerinden paylaşılan yol ön eklerinden daha geniş bir şekilde kullanılır ve ExpressRoute üzerinden şirket içi SMTP sunucularının reklamı bu diğer hizmetlerde hatalara neden olur.
Oturum açmak için parola doğrulaması sırasında ADFS.
Microsoft'un bu çift yönlü trafik akışları için ağınıza geri yönlendirebilmesi için BGP'nin şirket içi cihazlarınıza yönlendirmeleri Microsoft ile paylaşılmalıdır. ExpressRoute üzerinden Yol ön eklerini Microsoft'a tanıttığınızda şu en iyi yöntemleri izlemeniz gerekir:
Aynı genel IP Adresi yol ön ekini genel İnternet'e ve ExpressRoute üzerinden tanıtmayın. ExpressRoute üzerinden Microsoft'a yönelik IP BGP Yol Ön Eki tanıtımlarının İnternet'e tanıtılan bir aralıktan olması önerilir. Kullanılabilir IP Adresi alanı nedeniyle bunu başarmak mümkün değilse, ExpressRoute üzerinden herhangi bir İnternet bağlantı hattından daha belirli bir aralığı tanıtmanızı sağlamak önemlidir.
ExpressRoute bağlantı hattı başına ayrı NAT IP havuzları kullanın ve İnternet bağlantı hatlarınızdan ayırın.
Microsoft'a tanıtılan tüm yollar, yalnızca ExpressRoute üzerinden ağınıza tanıtılan yolların değil, Microsoft'un ağındaki herhangi bir sunucudan gelen ağ trafiğini çeker. Rotaları yalnızca yönlendirme senaryolarının tanımlandığı ve ekibiniz tarafından iyi anlaşıldığı sunuculara tanıtın. Ağınızdan birden çok ExpressRoute bağlantı hattının her birinde ayrı IP Adresi yol ön eklerini tanıtın.
Azure ExpressRoute ile yüksek kullanılabilirlik ve yük devretme
ExpressRoute ile her çıkıştan ExpressRoute sağlayıcınıza en az iki etkin bağlantı hattı sağlamanızı öneririz. Burası, müşteriler için hatalar gördüğümüz en yaygın yerdir ve bir çift etkin/etkin ExpressRoute bağlantı hattı sağlayarak bunu kolayca önleyebilirsiniz. Ayrıca, birçok Microsoft 365 hizmeti yalnızca İnternet üzerinden kullanılabildiğinden en az iki etkin/etkin İnternet bağlantı hattı öneririz.
Ağınızın çıkış noktası içinde, kişilerin kullanılabilirliği nasıl algıladıklarında kritik rol oynayan diğer birçok cihaz ve bağlantı hattı vardır. Bağlantı senaryolarınızın bu bölümleri ExpressRoute veya Microsoft 365 SLA'ları kapsamında değildir, ancak kuruluşunuzdaki kişiler tarafından algılanan uçtan uca hizmet kullanılabilirliği açısından kritik bir rol oynar.
Microsoft 365'i kullanan ve işleten kişilere odaklanın. Herhangi bir bileşenin başarısız olması kişilerin hizmeti kullanma deneyimini etkileyecekse, etkilenen kişilerin toplam yüzdesini sınırlamanın yollarını arayın. Bir yük devretme modu operasyonel olarak karmaşıksa, insanların kurtarma için uzun süre yaşadığı deneyimi göz önünde bulundurun ve operasyonel olarak basit ve otomatik yük devretme modlarını arayın.
Ağınızın dışında Microsoft 365, ExpressRoute ve ExpressRoute sağlayıcınızın tümü farklı kullanılabilirlik düzeylerine sahiptir.
Hizmet Kullanılabilirliği
Microsoft 365 hizmetleri, tek tek hizmetler için çalışma süresi ve kullanılabilirlik ölçümlerini içeren iyi tanımlanmış hizmet düzeyi sözleşmeleri kapsamındadır. Microsoft 365'in bu kadar yüksek hizmet kullanılabilirlik düzeylerini koruyabilmesinin bir nedeni, tek tek bileşenlerin genel Microsoft ağını kullanarak birçok Microsoft veri merkezi arasında sorunsuz bir şekilde yük devretme yapabilmesidir. Bu yük devretme, veri merkezinden ve ağdan birden çok İnternet çıkış noktasına genişletir ve hizmeti kullanan kişilerin perspektifinden sorunsuz bir şekilde yük devretmeyi etkinleştirir.
ExpressRoute, Microsoft Network Edge ile ExpressRoute sağlayıcısı veya iş ortağı altyapısı arasındaki ayrı ayrılmış devrelerde %99,9 kullanılabilirlik SLA'sı sağlar . Bu hizmet düzeyleri, her eşleme konumunda yedekli Microsoft ekipmanı ile ağ sağlayıcısı ekipmanı arasında iki bağımsız bağlantıdan oluşan ExpressRoute bağlantı hattı düzeyinde uygulanır.
Sağlayıcı Kullanılabilirliği
- Microsoft'un hizmet düzeyi düzenlemeleri ExpressRoute sağlayıcınızda veya iş ortağınızda durduruluyor. Burası aynı zamanda kullanılabilirlik düzeyinizi etkileyecek seçimler yapabileceğiniz ilk yerdir. ExpressRoute sağlayıcınızın ağ çevreniz ile her Microsoft eşleme konumundaki sağlayıcılarınız arasında sunduğu mimari, kullanılabilirlik ve dayanıklılık özelliklerini yakından değerlendirmeniz gerekir. Yedeklilik, eşleme ekipmanı, taşıyıcı tarafından sağlanan WAN devreleri ve nat hizmetleri veya yönetilen güvenlik duvarları gibi ek değer ekleme hizmetlerinin hem mantıksal hem de fiziksel yönlerine çok dikkat edin.
Kullanılabilirlik planınızı tasarlama
Microsoft 365 için uçtan uca bağlantı senaryolarınızda yüksek kullanılabilirlik ve dayanıklılık planlamanızı ve tasarlamanızı kesinlikle öneririz. Tasarım şunları içermelidir:
Hem İnternet hem de ExpressRoute bağlantı hatları dahil olmak üzere tek bir hata noktası yoktur.
En çok beklenen hata modları için etkilenen kişi sayısını ve bu etkinin süresini en aza indirme.
En çok beklenen hata modlarından basit, tekrarlanabilir ve otomatik kurtarma işlemi için iyileştirme.
Önemli bir düşüş olmadan, yedekli yollar aracılığıyla ağ trafiğinizin ve işlevselliğinizin tüm taleplerini destekleme.
Bağlantı senaryolarınız, Microsoft 365'e yönelik birden çok bağımsız ve etkin ağ yolu için iyileştirilmiş bir ağ topolojisi içermelidir. Bu, yalnızca tek tek cihaz veya ekipman düzeyinde yedeklilik için iyileştirilmiş bir topolojiden daha iyi bir uçtan uca kullanılabilirlik sağlar.
İpucu
Kullanıcılarınız birden çok kıtaya veya coğrafi bölgeye dağıtılmışsa ve bu konumların her biri yedekLI WAN devreleri üzerinden tek bir ExpressRoute bağlantı hattının bulunduğu tek bir şirket içi konuma bağlanıyorsa, kullanıcılarınız farklı bölgeleri en yakın eşleme konumuna bağlayan bağımsız ExpressRoute bağlantı hatları içeren ağ topolojisi tasarımından daha az uçtan uca hizmet kullanılabilirliğiyle karşılaşır.
Her bağlantı hattının farklı bir coğrafi eşleme konumuna bağlanmasıyla en az iki ExpressRoute bağlantı hattı sağlamanızı öneririz. Kişilerin Microsoft 365 hizmetleri için ExpressRoute bağlantısını kullanacağı her bölge için bu etkin-etkin bağlantı hattı çiftini sağlamalısınız. Bu, her bölgenin veri merkezi veya eşleme konumu gibi önemli bir konumu etkileyen bir olağanüstü durum sırasında bağlı kalmasını sağlar. Bunları içinde etkin/etkin olarak yapılandırmak, son kullanıcı trafiğinin birden çok ağ yoluna dağıtılmasını sağlar. Bu, cihaz veya ağ ekipmanı kesintileri sırasında etkilenen kişilerin kapsamını azaltır.
Yedek olarak İnternet ile tek bir ExpressRoute bağlantı hattı kullanmanızı önermeyiz.
Örnek: Yük devretme ve Yüksek Kullanılabilirlik
Contoso'nun çok coğrafi tasarımında yönlendirme, bant genişliği, güvenlik gözden geçirildi ve şimdi yüksek kullanılabilirlik gözden geçirmesi gerekiyor. Contoso üç kategoriyi kapsayan yüksek kullanılabilirlik hakkında düşünür; dayanıklılık, güvenilirlik ve yedeklilik.
Dayanıklılık, Contoso'nın hatalardan hızlı bir şekilde kurtulmasını sağlar. Güvenilirlik, Contoso'nın sistem içinde tutarlı bir sonuç sunmasını sağlar. Yedeklilik, Contoso'nun bir veya daha fazla yansıtılmış altyapı örneği arasında geçiş yapmasını sağlar.
Her uç yapılandırmasında Contoso'nun yedekli Güvenlik Duvarları, Proxy'leri ve IDS'si vardır. Kuzey Amerika için Contoso'nun Dallas veri merkezinde bir uç yapılandırması ve Virginia veri merkezinde başka bir uç yapılandırması vardır. Her konumdaki yedekli ekipman, bu konuma dayanıklılık sağlar.
Contoso'daki ağ yapılandırması birkaç temel ilkeye göre oluşturulur:
Her coğrafi bölgede birden çok Azure ExpressRoute bağlantı hattı vardır.
Bir bölgedeki her bağlantı hattı, o bölgedeki tüm ağ trafiğini destekleyebilir.
Yönlendirme, kullanılabilirliğe, konuma vb. bağlı olarak bir yolu veya diğer yolu açıkça tercih eder.
Azure ExpressRoute bağlantı hatları arasında yük devretme, Contoso tarafından ek yapılandırma veya eylem gerekmeden otomatik olarak gerçekleşir.
İnternet devreleri arasında yük devretme, Contoso tarafından ek yapılandırma veya eylem gerekmeden otomatik olarak gerçekleşir.
Bu yapılandırmada, fiziksel ve sanal düzeyde yedeklilik ile Contoso, güvenilir bir şekilde yerel dayanıklılık, bölgesel dayanıklılık ve küresel dayanıklılık sunabilir. Contoso, bölge başına tek bir Azure ExpressRoute bağlantı hattını ve İnternet'e yük devretme olasılığını değerlendirdikten sonra bu yapılandırmayı seçti.
Contoso bölge başına birden çok Azure ExpressRoute bağlantı hattına sahip olamadıysa, Kuzey Amerika kaynaklı trafiğin Asya Pasifik'teki Azure ExpressRoute bağlantı hattına yönlendirilmesi kabul edilemez bir gecikme düzeyi ekler ve gerekli DNS ileticisi yapılandırması karmaşıklık ekler.
İnternet'i yedekleme yapılandırması olarak kullanmak önerilmez. Bu, Contoso'nun güvenilirlik ilkesini bozarak bağlantıyı kullanma konusunda tutarsız bir deneyime neden olur. Ayrıca yapılandırılan BGP tanıtımları, NAT yapılandırması, DNS yapılandırması ve ara sunucu yapılandırması dikkate alınarak el ile yapılandırmanın yük devretmesi gerekir. Bu ek yük devretme karmaşıklığı kurtarma süresini artırır ve ilgili adımları tanılama ve sorun giderme becerilerini azaltır.
Trafik yönetimini veya Azure ExpressRoute'u planlama ve uygulama hakkında hala sorularınız mı var? Ağ ve performans kılavuzumuzun geri kalanını veya Azure ExpressRoute SSS bölümünü okuyun.
Microsoft 365 senaryoları için Azure ExpressRoute'a güvenlik denetimleri uygulama
Azure ExpressRoute bağlantısının güvenliğini sağlamak, İnternet bağlantısının güvenliğini sağlamakla aynı ilkelerle başlar. Birçok müşteri, şirket içi ağını Microsoft 365 ve diğer Microsoft bulutlarına bağlayan ExpressRoute yolu boyunca ağ ve çevre denetimleri dağıtmayı tercih eder. Bu denetimler güvenlik duvarları, uygulama proxy'leri, veri sızıntısını önleme, izinsiz giriş algılama, izinsiz girişi önleme sistemleri vb. içerebilir. Çoğu durumda müşteriler şirket içinden Microsoft'a giden trafiğe, Microsoft'tan müşteri şirket içi ağına giden trafikle şirket içi ortamdan genel bir İnternet hedefine giden trafik arasında farklı denetim düzeyleri uygular.
Dağıtımı seçtiğiniz ExpressRoute bağlantı modeliyle güvenliği tümleştirmeye yönelik birkaç örnek aşağıda verilmiştir.
| ExpressRoute tümleştirme seçeneği | Ağ güvenliği çevre modeli |
|---|---|
| Bulut değişiminde birlikte bulunma |
ExpressRoute bağlantısının kurulduğu ortak konum tesisinde yeni bir güvenlik/çevre altyapısı yükleyin veya mevcut güvenlik/çevre altyapısını kullanın. Birlikte bulundurma tesisini yalnızca yönlendirme/ara bağlantı amaçları için kullanın ve birlikte bulundurma tesisinden şirket içi güvenlik/çevre altyapısına geri taşıma bağlantıları. |
| Noktadan Noktaya Ethernet |
Mevcut şirket içi güvenlik/çevre altyapısı konumunda Noktadan Noktaya ExpressRoute bağlantısını sonlandırın. ExpressRoute yoluna özgü yeni güvenlik/çevre altyapısı yükleyin ve noktadan noktaya bağlantıyı orada sonlandırın. |
| Herhangi bir IPVPN'e |
Microsoft 365 bağlantısı için ExpressRoute için kullanılan IPVPN'e giren tüm konumlarda mevcut bir şirket içi güvenlik/çevre altyapısı kullanın. Microsoft 365 için ExpressRoute için kullanılan IPVPN'i güvenlik/çevre olarak görev yapmak üzere belirlenen belirli şirket içi konumlara yönlendirin. |
Bazı hizmet sağlayıcıları, Azure ExpressRoute ile tümleştirme çözümlerinin bir parçası olarak yönetilen güvenlik/çevre işlevleri de sunar.
Microsoft 365 bağlantıları için ExpressRoute için kullanılan ağ/güvenlik çevre seçeneklerinin topoloji yerleşimi göz önünde bulundurulduğunda, ek dikkat edilmesi gerekenler aşağıdadır
Derinlik ve tür ağ/güvenlik denetimleri, Microsoft 365 kullanıcı deneyiminin performansını ve ölçeklenebilirliğini etkileyebilir.
Giden (şirket içi-Microsoft>) ve gelen (microsoft-şirket> içi) akışların [etkinse] akışları farklı gereksinimlere sahip olabilir. Bunlar büyük olasılıkla genel İnternet hedeflerine giden hedeflerden farklıdır.
Trafiğin Microsoft 365 için ExpressRoute üzerinden veya İnternet üzerinden yönlendirilmesi fark etmeksizin bağlantı noktaları/protokoller ve gerekli IP alt ağları için Microsoft 365 gereksinimleri aynıdır.
Müşteri ağı/güvenlik denetimlerinin topolojik yerleşimi, kullanıcı ile Microsoft 365 hizmeti arasındaki nihai uçtan uca ağı belirler ve ağ gecikmesi ve tıkanıklığı üzerinde önemli bir etkiye sahip olabilir.
Müşterilerin, yedeklilik, yüksek kullanılabilirlik ve olağanüstü durum kurtarma için en iyi yöntemlere uygun olarak Microsoft 365 için ExpressRoute ile kullanılacak güvenlik/çevre topolojilerini tasarlamaları teşvik edilir.
Aşağıda, yukarıda açıklanan çevre güvenlik modelleri ile farklı Azure ExpressRoute bağlantı seçeneklerini karşılaştıran bir Contoso örneği verilmiştir.
Örnek: Azure ExpressRoute güvenliğini sağlama
Contoso, Azure ExpressRoute'u uygulamayı düşünüyor ve Microsoft 365 için ExpressRoute için en uygun mimariyi planladıktan sonra ve bant genişliği gereksinimlerini anlamak için yukarıdaki kılavuzu kullandıktan sonra çevrelerinin güvenliğini sağlamak için en iyi yöntemi belirler.
Birden çok kıtada konumları olan çok uluslu bir kuruluş olan Contoso için güvenliğin tüm çevrelere yayılması gerekir. Contoso için en uygun bağlantı seçeneği, her kıtadaki çalışanlarının ihtiyaçlarına hizmet etmek için dünyanın dört bir yanındaki birden çok eşleme konumuyla çok noktalı bir bağlantıdır. Her kıtada, kıta içindeki yedekli Azure ExpressRoute bağlantı hatları vardır ve güvenlik bunların tümüne yayılmalıdır.
Contoso'nun mevcut altyapısı güvenilirdir ve ek işleri gerçekleştirebilir. Bunun sonucunda Contoso, Azure ExpressRoute ve internet çevre güvenliği için altyapıyı kullanabilir. Böyle bir durum söz konusu değilse Contoso, mevcut ekipmanlarını desteklemek veya farklı bir bağlantı türünü işlemek için daha fazla ekipman satın almayı seçebilir.
Azure ExpressRoute için bant genişliği planlaması
Her Microsoft 365 müşterisinin her konumdaki kişi sayısına, her Microsoft 365 uygulamasında ne kadar etkin olduklarına ve şirket içi veya hibrit ekipman kullanımı ve ağ güvenlik yapılandırmaları gibi diğer faktörlere bağlı olarak benzersiz bant genişliği gereksinimleri vardır.
Bant genişliğinin çok az olması tıkanıklık, verilerin yeniden iletimleri ve öngörülemeyen gecikmelere neden olur. Çok fazla bant genişliğine sahip olmak gereksiz maliyete neden olur. Mevcut bir ağda bant genişliği genellikle devredeki kullanılabilir oda miktarı açısından yüzde olarak adlandırılır. %10 tuvalete sahip olmak büyük olasılıkla tıkanıklıklara neden olur ve %80'lik oda başı genellikle gereksiz maliyet anlamına gelir. Tipik oda başı hedef ayırmaları %20 ile %50 arasındadır.
Doğru bant genişliği düzeyini bulmak için en iyi mekanizma mevcut ağ tüketiminizi test etmektir. Her ağ yapılandırması ve uygulaması bazı yönlerden benzersiz olduğundan, gerçek bir kullanım ve ihtiyaç ölçüsü almanın tek yolu budur. Ölçüm yaparken ağ gereksinimlerinizi anlamak için toplam bant genişliği tüketimine, gecikme süresine ve TCP tıkanıklığına dikkat etmek istersiniz.
Tüm ağ uygulamalarını içeren tahmini bir temele sahip olduğunuzda, gerçek kullanımı belirlemek için kuruluşunuzdaki farklı kişi profillerinden oluşan küçük bir grupla Microsoft 365'i pilot yapın ve her ofis konumu için gereken bant genişliği miktarını tahmin etmek için iki ölçümü kullanın. Testinizde herhangi bir gecikme süresi veya TCP tıkanıklığı sorunu varsa, çıkışı Microsoft 365 kullanan kişilere yaklaştırmanız veya SSL şifre çözme/denetleme gibi yoğun ağ taramasını kaldırmanız gerekebilir.
Önerilen ağ işleme türüyle ilgili tüm önerilerimiz hem ExpressRoute hem de İnternet bağlantı hatları için geçerlidir. Aynı durum , performans ayarlama sitemizdeki yönergelerin geri kalanı için de geçerlidir.
Dağıtım ve test yordamlarınızı oluşturma
Uygulama planınız hem test hem de geri alma planlaması içermelidir. Uygulamanız beklendiği gibi çalışmıyorsa plan, sorunlar keşfedilmeden önce en az sayıda kişiyi etkileyecek şekilde tasarlanmalıdır. Planınızın dikkate alması gereken bazı üst düzey ilkeler aşağıdadır.
Kesintiyi en aza indirmek için ağ kesimi ve kullanıcı hizmeti ekleme aşamasını oluşturun.
ayrı bir İnternet bağlantılı konaktan izleme yolu ve TCP bağlantısı ile yolları test etme planı.
Tercihen, microsoft 365 kiracısı test edilmiş yalıtılmış bir test ağında gelen ve giden hizmetlerin testi yapılmalıdır.
Alternatif olarak, müşteri henüz Microsoft 365 kullanmıyorsa veya pilot durumdaysa üretim ağında test gerçekleştirilebilir.
Alternatif olarak, yalnızca test ve izleme için ayrılmış bir üretim kesintisi sırasında test gerçekleştirilebilir.
Alternatif olarak, her katman 3 yönlendirici düğümündeki her hizmet için yollar denetlenerek test yapılabilir. Bu geri dönüş yalnızca fiziksel test eksikliği risk oluşturacağı için başka bir test mümkün değilse kullanılmalıdır.
Dağıtım yordamlarınızı oluşturma
Dağıtım yordamlarınız, daha büyük kişi gruplarına dağıtmadan önce test edilmesine izin vermek için aşamalı olarak küçük kişi gruplarına dağıtılmalıdır. ExpressRoute dağıtımını hazırlamanın birkaç yolu aşağıdadır.
ExpressRoute'u Microsoft eşlemesi ile ayarlayın ve yol tanıtımlarının yalnızca aşamalı test amacıyla tek bir konağa iletilmesine izin verme.
ExpressRoute ağına giden yolları ilk başta tek bir ağ kesimine tanıtın ve yol tanıtımlarını ağ kesimine veya bölgeye göre genişletin.
Microsoft 365'i ilk kez dağıtıyorsanız ExpressRoute ağ dağıtımını birkaç kişi için pilot olarak kullanın.
Ara sunucu kullanıyorsanız, daha fazla eklemeden önce test ve geri bildirimle birkaç kişiyi ExpressRoute'a yönlendirmek için alternatif olarak bir test PAC dosyası yapılandırabilirsiniz.
Uygulama planınız, alınması gereken dağıtım yordamlarının her birini veya ağ yapılandırmasını dağıtmak için kullanılması gereken komutları listelemelidir. Ağ kesintisi süresi geldiğinde, yapılan değişikliklerin tümü önceden yazılmış ve eş gözden geçirilmiş olan yazılı dağıtım planından olmalıdır. ExpressRoute'un teknik yapılandırmasıyla ilgili kılavuzumuza bakın.
E-posta göndermeye devam edecek şirket içi sunucuların IP adreslerini değiştirdiyseniz SPF TXT kayıtlarınızı güncelleştirme.
IP adreslerini yeni bir NAT yapılandırmasını barındıracak şekilde değiştirdiyseniz, şirket içi sunucular için dns girdilerini güncelleştirme.
Yönlendirme veya ara sunucu yapılandırmalarını korumak için Microsoft 365 uç nokta bildirimleri için RSS akışına abone olduğunuzdan emin olun.
ExpressRoute dağıtımınız tamamlandıktan sonra test planındaki yordamlar yürütülmelidir. Her yordamın sonuçları günlüğe kaydedilmelidir. Test planı sonuçlarının uygulamanın başarılı olmadığını belirtmesi durumunda özgün üretim ortamına geri dönme yordamları eklemeniz gerekir.
Test yordamlarınızı oluşturma
Test yordamlarınız, Hem ExpressRoute kullanacak hem de kullanmayacak microsoft 365 için giden ve gelen ağ hizmetlerinin testlerini içermelidir. Yordamlar, şirket LAN'ında şirket içi olmayan kullanıcılar da dahil olmak üzere her benzersiz ağ konumundan test içermelidir.
Test etkinliklerine örnek olarak aşağıdakiler verilebilir.
Şirket içi yönlendiricinizden ağ operatörü yönlendiricinize ping gönderme.
500+ Microsoft 365 ve CRM Online IP adresi tanıtımlarının şirket içi yönlendiriciniz tarafından alınıp alınmadığı doğrulayın.
Gelen ve giden NAT'nizin ExpressRoute ile iç ağ arasında çalıştığını doğrulayın.
NAT'nize giden yolların yönlendiricinizden tanıtıldığını doğrulayın.
ExpressRoute'un tanıtılan ön eklerinizi kabul ettiğini doğrulayın.
- Eşleme tanıtımlarını doğrulamak için aşağıdaki cmdlet'i kullanın:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringÖnceki örnekte olduğu gibi daha büyük bir aralığın belirli bir alt kümesi olmadığı sürece genel NAT IP aralığınızın microsoft'a başka bir ExpressRoute veya genel İnternet ağ bağlantı hattı üzerinden tanıtılmadığından emin olun.
ExpressRoute bağlantı hatları eşleştirilir ve her iki BGP oturumlarının da çalıştığını doğrulayın.
NAT'nizin içinde tek bir konak ayarlayın ve yeni bağlantı hattı üzerinden konak outlook.office365.com bağlantıyı test etmek için ping, tracert ve tcpping kullanın. Alternatif olarak, outlook.office365.com ile ilişkili IP adresine bağlanabildiğinizi doğrulamak için MSEE'ye yansıtılmış bir bağlantı noktasında Wireshark veya Microsoft Network Monitor 3.4 gibi bir araç kullanabilirsiniz.
Exchange Online için uygulama düzeyi işlevselliğini test edin.
Outlook'un Exchange Online bağlanıp e-posta gönderip alabilmesini test edin.
Outlook'un çevrimiçi modu kullanabileceğini test edin.
Akıllı telefon bağlantısını ve gönderme/alma özelliğini test edin.
- SharePoint için uygulama düzeyi işlevselliğini test edin
Eşitleme istemcisini test OneDrive İş.
SharePoint web erişimini test edin.
- Skype Kurumsal çağırma senaryoları için uygulama düzeyi işlevselliğini test edin:
Konferans aramasına kimliği doğrulanmış kullanıcı [son kullanıcı tarafından başlatılan davet] olarak katılın.
Kullanıcıyı [MCU'dan gönderilen davet] konferans aramasına davet edin.
Skype Kurumsal web uygulamasını kullanarak konferansa anonim kullanıcı olarak katılın.
Kablolu bilgisayar bağlantınızdan, IP telefonunuzdan ve mobil cihazınızdan aramaya katılın.
Federasyon kullanıcısına çağrı o PSTN Doğrulama çağrısı: çağrı tamamlandı, çağrı kalitesi kabul edilebilir, bağlantı süresi kabul edilebilir.
Kişilerin iletişim durumunun hem kiracının üyeleri hem de federasyon kullanıcıları için güncelleştirildiğinden emin olun.
Yaygın sorunlar
Asimetrik yönlendirme en yaygın uygulama sorunudur. Aranacak bazı yaygın kaynaklar şunlardır:
Kaynak NAT olmadan açık veya düz ağ yönlendirme topolojisi kullanma.
Hem İnternet hem de ExpressRoute bağlantıları üzerinden gelen hizmetlere yönlendirmek için SNAT kullanmama.
Geniş bir dağıtım öncesinde expressroute'ta gelen hizmetleri test etme.
Ağınız üzerinden ExpressRoute bağlantısını dağıtma
Dağıtımınızı bir kerede ağın bir parçasına hazırlayın ve her yeni ağ kesimi için geri alma planıyla ağın farklı bölümlerine bağlantıyı aşamalı olarak dağıtın. Dağıtımınız bir Microsoft 365 dağıtımıyla uyumluysa, önce Microsoft 365 pilot kullanıcılarınıza dağıtın ve buradan genişletin.
Önce testiniz ve ardından üretim için:
ExpressRoute'u etkinleştirmek için dağıtım adımlarını çalıştırın.
Ağ yollarının beklendiği gibi olduğunu görmek için test edin.
Her gelen ve giden hizmette test gerçekleştirin.
Herhangi bir sorun bulursanız geri alın.
Test ağı kesimiyle ExpressRoute'a test bağlantısı ayarlama
Artık planı kağıt üzerinde tamamladığınıza göre, küçük ölçekte test etme zamanı geldi. Bu testte, şirket içi ağınızdaki bir test alt ağına Microsoft Eşleme ile tek bir ExpressRoute bağlantısı kuracaksınız. Test alt ağından ve test alt ağından bağlantısı olan bir deneme Microsoft 365 kiracısı yapılandırabilir ve test alt ağından üretimde kullanmakta olduğunuz tüm giden ve gelen hizmetleri ekleyebilirsiniz. Test ağı kesimi için DNS'yi ayarlayın ve tüm gelen ve giden hizmetleri oluşturun. Test planınızı yürütür ve her hizmet için yönlendirme ve yol yayma hakkında bilgi sahibi olduğunuzdan emin olun.
Dağıtım ve test planlarını yürütme
Yukarıda açıklanan öğeleri tamamlarken tamamladığınız alanları gözden geçirin ve dağıtım ve test planlarınızı yürütmeden önce sizin ve ekibinizin bunları incelediğinden emin olun.
Ağ değişikliğine dahil olan giden ve gelen hizmetlerin listesi.
Hem internet çıkışı hem de ExpressRoute meet-me konumlarını gösteren genel ağ mimarisi diyagramı.
Dağıtılan her hizmet için kullanılan farklı ağ yollarını gösteren ağ yönlendirme diyagramı.
Değişiklikleri uygulama ve gerekirse geri alma adımlarını içeren bir dağıtım planı.
Her Microsoft 365'i ve ağ hizmetini test eden bir test planı.
Gelen ve giden hizmetler için üretim yollarının kağıt doğrulaması tamamlandı.
Kullanılabilirlik testi de dahil olmak üzere bir test ağ kesiminde tamamlanmış bir test.
Dağıtım planının ve test planının tamamından geçebilecek kadar uzun bir kesinti penceresi seçin. Sorun giderme için uygun zaman ve gerekirse geri dönme süresi vardır.
Dikkat
Hem İnternet hem de ExpressRoute üzerinden yönlendirmenin karmaşık yapısı nedeniyle, karmaşık yönlendirme sorunlarını gidermek için bu pencereye ek arabellek süresi eklenmesi önerilir.
Skype Kurumsal Online için QoS'yi yapılandırma
QoS, Skype Kurumsal Online için ses ve toplantı avantajları elde etmek için gereklidir. ExpressRoute ağ bağlantısının diğer Microsoft 365 hizmet erişiminizin hiçbirini engellemediğinden emin olduktan sonra QoS'yi yapılandırabilirsiniz. QoS yapılandırması, Skype Kurumsal Online'da ExpressRoute ve QoS makalesinde açıklanmıştır.
Uygulamanızın sorunlarını giderme
İlk olarak bu uygulama kılavuzundaki adımlara bakılacaktır. Uygulama planınızda gözden kaçırılan var mı? Hatayı çoğaltmak ve hata ayıklamak için mümkünse Geri dön ve daha fazla küçük ağ testi çalıştırın.
Test sırasında hangi gelen veya giden hizmetlerin başarısız olduğunu belirleyin. Özellikle başarısız olan hizmetlerin her biri için IP adreslerini ve alt ağları alın. Devam edin ve kağıt üzerinde ağ topolojisi diyagramında ilerleyin ve yönlendirmeyi doğrulayın. Özellikle ExpressRoute yönlendirmesinin tanıtıldığı yeri doğrulayın, mümkünse izlemelerle kesinti sırasında bu yönlendirmeyi test edin.
PSPing'i her müşteri uç noktasına bir ağ izlemesi ile çalıştırın ve kaynak ve hedef IP adreslerini değerlendirerek beklendiği gibi olduklarını doğrulayın. Telnet'i 25 numaralı bağlantı noktasında kullanıma eklediğiniz herhangi bir posta konağına çalıştırın ve bu beklenen bir durumsa SNAT'nin özgün kaynak IP adresini gizlediğini doğrulayın.
Microsoft 365'i bir ExpressRoute bağlantısıyla dağıtırken ExpressRoute için hem ağ yapılandırmasının en uygun şekilde tasarlandığından hem de ağınızdaki istemci bilgisayarlar gibi diğer bileşenleri iyileştirdiğinizden emin olmanız gerektiğini unutmayın. Atlamış olabileceğiniz adımları gidermek için bu planlama kılavuzunu kullanmanın yanı sıra, Microsoft 365 için bir Performans sorun giderme planı da yazdık.
İşte geri dönmek için kullanabileceğiniz kısa bir bağlantı: https://aka.ms/implementexpressroute365
İlgili Konular
Microsoft 365 ağ bağlantısını değerlendirme
Microsoft 365 için Azure ExpressRoute
Skype Kurumsal Online'da Medya Kalitesi ve Ağ Bağlantısı Performansı
Ağınızı Skype Kurumsal Online için iyileştirme
Skype Kurumsal Online'da ExpressRoute ve QoS
ExpressRoute kullanarak çağrı akışı
Temelleri ve performans geçmişini kullanarak Microsoft 365 performans ayarlama
Microsoft 365 için performans sorunlarını giderme planı
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin