Office 365'e posta geçişi | Posta Taşıma verimini optimize etme | Bölüm 3/4
Bu yazıda “posta altyapımızı buluta taşıma” projesinin sonuçlarını iyileştirmemize ve optimize etmemize yardımcı olabilecek önerileri ve “en iyi uygulamaları” inceliyoruz.
Office 365'e posta geçişi | Posta Taşıma verimini optimize etme | Makale serisi
Makale serisi aşağıdaki makaleleri içermektedir:
- Office 365'e posta geçişi | Posta Taşıma yöntemleri
- Office 365'e posta geçişi | Posta Taşıma performansını etkileyen faktörler
- Office 365'e posta geçişi | Posta Taşıma işlemini optimize etme (bu makale)
- Office 365'e Posta Geçişi | Posta Taşıma işlemlerini ölçün ve tahmin edin
Office 365 zaman çizelgesine posta geçişi
Genel olarak ölçebileceğimiz iki faktör vardır:
- Posta taşıma verimi - belirli miktarda verinin buluta aktarılması için gereken süre (Exchange Online)
- Posta taşıma işleminin tamamlanması için gereken süre*
*Örneğin yönetimin bize kurumun tüm mail altyapısını 10 günü geçmeyecek bir sürede buluta taşımamızı söylemesi durumunda bu görevi başarabilir miyiz?
Bu makalede, posta taşıma işleminin sonuçlarını veya posta taşıma projesini gerçekleştirmek için ihtiyaç duyacağımız süreyi iyileştirmek ve optimize etmek için elimizdeki bazı faktörleri ve seçenekleri gözden geçiriyoruz.
Posta taşıma işlemini etkileyen faktörler
Aşağıdaki bölümde, posta taşıma işleminin aktarım hızını (aktarım hızını) etkileyen bazı faktörleri ve bu işlemi gerçekleştirmek için kullanılabilecek seçenekleri inceleyeceğiz. Posta taşıma işlemlerinin sonuçlarını iyileştirmek için bu faktörlere ince ayar yapın veya optimize edin.
Ağ altyapısı
1. İletişim hattı bant genişliği
Kurumsal iletişim hattının "hızı" (bant genişliği).
İletişim hattımızın performansını ölçebilmek için ISP'nin sağladığı bir web aracını veya speedtest gibi halka açık araçları kullanabiliriz.
Sonuçları kullanarak, Yükleme hızı (bir kuruluş posta kutusunu buluta taşıdığımızda "yükleme kanalını kullanırız), indirme hızı vb. gibi kullanabileceğimiz mevcut kaynakları daha iyi anlayabiliriz.
Sonuçlarımıza göre mevcut iletişim hattının bant genişliğinin arttırılmasına ihtiyaç olup olmadığına karar verebiliriz.
İletişim hattının gün, hafta vb. içindeki yükü ve performansı hakkında daha detaylı bilgi almak istememiz durumunda.
Çoğu İSS, iletişim hattı performansının günlük, haftalık ve aylık sonuçlarını görüntüleyecek bir web arayüzüne erişerek bu bilgiyi (çoğu zaman ücretsiz olarak) sağlayabilir.
Şahsen ben ağ performansını çok net ve grafiksel olarak görmemizi sağlayan PRTG adlı ürünü kullanmayı seviyorum.
2. Çalışma saatleri ve hafta sonları
Office 365 yerel posta taşıma araçları, posta taşıma sürecini planlamamıza olanak tanır. Posta geçişinin kuruluşun iletişim hattını "yükleyeceği" (ve ağ performansını - iletişim hatlarının kullanılabilir bant genişliğini düşüreceği) bir senaryodan kaçınmak istediğimizde veya mevcut tüm iletişim hattı bant genişliğini kullanmak istediğimiz durumda, posta taşıma işlemini “mesai saatleri dışında” bir zamana planlamayı veya posta taşıma işlemini hafta sonları uygulamayı düşünebiliriz.
3. Ağ cihazlarının performansı ve ayarlanması
Güvenlik Duvarı veya Proxy yükü ve performansı
Güvenlik Duvarı veya Proxy gibi mevcut ağ cihazlarının "Darboğaza" veya posta taşıma performansını yavaşlatmaya neden olmadığını doğrulayabilmek için en iyi uygulama, bir posta kutusu geçişi Pilotu uygulamak ve yük performansını izlemektir. Sunucu kullanımının yüksek olmadığını veya Güvenlik Duvarı/Proxy'nin "son sınırına ulaşmasına neden olmadığını" doğrulamak için Güvenlik Duvarı/Proxy'yi kontrol edin.
Posta taşıma işleminin performansını etkileyebilecek bir diğer önemli faktör, "izin verilen oturumların" maksimum değerini kısıtlayan yapılandırma ayarlarıdır.
Güvenlik Duvarı/Proxy | izin verilen maksimum oturumların olası kısıtlaması
Geçiş işlemi oturumunun Güvenlik Duvarı/Proxy ilkesi tarafından engellenmediğini veya kısıtlanmadığını doğrulamak için Güvenlik Duvarı/Proxy sunucusunu kontrol edin.
4. Kuruluşun ağının coğrafi konumu
Exchange Online'a posta taşıma verimini etkileyen faktörlerden biri, kuruluş ağı ile Office 365 veri merkezleri arasındaki "fiziksel mesafedir".
Teknik olarak, A noktasından (organizasyon ağı) hedefe (Office 365 veri merkezi) kadar olan iletişim yolunun kalitesini ölçmek veya değerlendirmek kolay değildir, ancak iyi haber şu ki Microsoft, şu adla adlandırılan yararlı bir Web tabanlı araç sunmaktadır: Office 365 Ağ Analizi Aracı, belirli bir kuruluş ağı ile kuruluşun posta kutusunu barındıran Office 365 veri merkezi arasındaki iletişim kanalının performansı hakkında ayrıntılı bilgi edinmemize yardımcı olabilir.
Office 365 Ağ Analizi Aracı, Java tabanlı bir araçtır ve bir web uygulaması olarak uygulanır.
Gerekli sonuçları alabilmek için kuruluşun posta kutusunu barındıran Office 365 veri merkezi için uygun URL'yi seçmemiz, Office 365'e kayıtlı Genel alan adımızı belirtmemiz gerekecek; araçlar bilgi toplamaya başlayacak ve bir sonraki adımda adım, ayrıntılı sonuçları görüntüleyin.
Office 365 Ağ Analizi Aracını kullanmak için öncelikle java istemcisini indirip kurmamız gerekiyor.
Aracı kullanmayı denediğinizde "uygulama bir güvenlik ayarı tarafından engellendi" hatasını alırsanız, kontrol paneline gidin, Java adlı simgeyi arayın ve güvenlik sekmesinde varsayılan ayarları şu şekilde değiştirin: orta
İlk ekranda Office 365'te barındırılan alan adını sağlamamız gerekecek.
5. QoS (Hizmet Kalitesi) ürününün kullanılması
Çoğu zaman önemli olan soru “iletişim hattının bant genişliği nedir” değildir? Ama bunun yerine “iletişim hattının kullanımı nedir veya iletişim hattının “serbest yüzdesi” nedir?
Posta geçişi süreci zorlu olarak kabul edilir, çünkü çoğu zaman önemli miktarda veriyi kuruluşun ağından buluta "aktarıyoruz".
Kuruluşunuzun bir QoS ürünü kullanması durumunda en iyi uygulama, ağ bant genişliğinin önceden tanımlanmış bir yüzdesini posta taşıma görevi için tahsis etmek veya posta taşımayla ilgili iletişime öncelik vermektir.
6. Gerekli iletişim hattı bant genişliğini planlayın
"Gerekli iletişim hattı bant genişliğini planlayın" kavramıyla ilgili olarak, önemli aşamalardan biri posta geçişi için gereken bant genişliğidir (Exchange şirket içi sunucudan buluta aktarılacak posta kutusu verileri). Ek olarak, Exchange Online posta kutularına erişen kuruluş kullanıcıları arasındaki iletişime tahsis edilen gerekli iletişim hattı bant genişliğini önceden planlamamız gerekecektir.
Exchange Şirket İçi altyapısı
1. Veri kaynağı (Exchange Sunucusu) - Performans
Geçiş işlemi, kullanıcının posta kutularını barındıran Şirket içi Exchange sunucularına veya Exchange Şirket içi hibrit sunucusunun hibrit yapılandırmasını kullanmamız durumunda ağır bir yük oluşturacaktır.
Geçiş işlemine başlamadan önce en iyi uygulama, mevcut Exchange şirket içi sunucularının, bu sunucunun en iyi şekilde performans göstermesini sağlayacak gerekli kaynaklara (RAM, CPU, Depolama vb.) sahip olmasını sağlamaktır.
S: Geçiş işleminin Şirket içi Exchange sunucusunu zorlayıp zorlamadığını nasıl bilebilirim?
C: 10 ile düşük bir sayıyla başlayın ve ardından son kullanıcı erişim sorunlarını önlemek için veri kaynağı performansını izlerken bu sayıyı artırın.
Bana göre, "mevcut Exchange şirket içi sunucu donanımını yükseltme" seçeneği, Exchange şirket içi sunucusunun bir sanal makineyi temel alması durumunda en uygunudur çünkü bu senaryoda, donanım yükseltme işlemi "tek taraflı" bir işlemdir. prosedüre tıklayın.”
Hibrit geçiş | Sunucu performansı
Mail geçiş işleminde “Yönlendirici” olarak kullanılacak Hibrit sunucu kullanmanız durumunda Exchange 2013 ve 2010 hibrit sunucularda sanal makineler yerine güçlü sunucu sınıfı fiziksel makineler kullanmak en iyi uygulamadır.
2. MRSProxy kaynak tahsisini ayarlama
MRSProxy, bir posta kutusu taşıma işleminin uygulanmasından sorumlu olan Exchange sunucusu bileşenidir (senaryomuzda posta kutusunun Exchange Şirket İçi sunucusundan Exchange Online'a taşınması).
MRSProxy tarafından yürütülen görevler, bağlantılar olarak tanımlanır. Maksimum bağlantı sayısı için varsayılan değer 100'dür, ancak bu değerleri ihtiyaçlarımıza göre "ayarlama" olanağımız vardır.
Senaryo 1: Exchange Sunucusu taşıma yükünden dolayı bunalıyor. Geçiş işleminin Exchange şirket içi sunucusunun performansını olumsuz etkilediğini tespit etmemiz durumunda, MRSProxy'nin kullanabileceği maksimum bağlantı sayısını azaltabiliriz.
Senaryo 2: Mevcut Exchange Şirket İçi sunucusunun yeterli donanım kaynağına sahip olması durumunda ve MRSProxy'ye daha fazla kaynak genişletmek istiyorsak, MRSProxy için kullanılabilecek varsayılan bağlantı sayısını artırabiliriz ve bunu yaparak, posta kutusu geçiş aktarım hızını optimize eden bir program.
Kullanabileceğimiz PowerShell komutu:
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>3. Exchange Şirket İçi sunucu kısıtlama politikası
Posta geçişi işleminin performansını "yavaşlatabilecek" veya "düşürebilecek" bir Exchange şirket içi sunucu kısıtlama ilkesi uygulamanız varsa, posta geçişi çalışırken bu ayarları durdurmayı veya devre dışı bırakmayı düşünün.
4. Mümkünse Hibrit geçişin kullanılması
Karma geçiş seçeneğinin kullanılması, posta geçişiyle ilgili veri miktarını azaltır.
Önceki makalede Office 365'e posta geçişi | Posta Taşıma işlemini etkileyen faktörler, posta taşıma işleminde yer alan veri miktarına ilişkin olarak Karma geçiş ile aşama geçişi ve Kesin geçiş arasında var olan farkı açıklıyoruz.
Kısa bir özet: Karma geçiş seçeneğini kullanırken, yeni bir Outlook posta profili yapılandırmamız gerekmez; bunun yerine aynı Outlook posta profilini ve mevcut OST dosyasını kullanabiliriz. Bunu yaparak, posta kutusu içeriğini kullanıcının masaüstüne "geri indirme" ihtiyacını ortadan kaldırıyoruz.
Mevcut üçüncü taraf posta taşıma araçlarının her birine aşina değilim ve tüm posta kutusu verilerini yeni bir OST dosyasına indirmek yerine yerel Outlook OST'nin nasıl kullanılacağını "bilen" üçüncü taraf posta taşıma araçlarının olup olmadığı konusunda bilgi sahibi değilim.
Karma geçiş seçeneğinin kullanılması minimum, Exchange 2010 SP3 şirket içi sunucusunun minimum gereksinimlerine dayanmaktadır. Kuruluşun posta altyapısının 2003, 2007 gibi eski Exchange şirket içi sunucusunu temel aldığı bir senaryoda, posta taşıma projesi için “geçici Exchange 2010 şirket içi sunucusu” kurma seçeneğini değerlendirmenizi öneririm.
İlginç gerçek şu ki, lisans için ödeme yapmanıza bile gerek yok. Microsoft, Exchange 2010/2013/2016/2019 Şirket İçi sunucusunu yalnızca karma sunucu olarak (posta kutusu kuralı seçeneğini kullanmadan) yüklemek isteyen bir kuruluşun, bu sunucu için ücretsiz bir lisans almasına olanak sağlar.
5. Çoklu site altyapısını değiştirin
Orta ve büyük ölçekli kuruluşların genellikle birden fazla Exchange sitesi bulunur.
Kuruluşunuzun birden fazla Exchange sitesi kullanması durumunda (Birden fazla Exchange sitesi) ve bu Exchange sitelerinin her birinin, Exchange'i "temsil eden" harici ana bilgisayarların Exchange şirket içi Exchange sunucusuna bağlanmasını sağlayan "genel bir varlığa" sahip olması durumunda sitesi sayesinde posta taşıma işlemlerini önemli ölçüde artırabiliriz.
Örneğin senaryomuzda 300 yüz posta kutusunu organizasyonun Exchange On-Premises sunucularından buluta taşımamız gerekiyor.
Bu görevi tamamlamak için çok dar bir zaman aralığımız var ve posta taşıma sürecini kısaltmak veya hızlandırmak istiyoruz.
Aşağıdaki diyagramda, birden fazla Exchange sitesinden aynı anda (paralel) posta taşıma işlemi uygulama konseptini kullanarak, aynı anda taşıyabileceğimiz posta kutusu miktarını çarpabileceğimizi veya üçgenleyebileceğimizi görebiliriz.
6. Çoklu Exchange sitesinin altyapısı ve Otomatik Keşfet
Birden çok Exchange sitesi altyapısı senaryosunda, kullanıcı posta kutusunun (Exchange sitesi ve Exchange sunucusunu barındıran Exchange sunucusu) konumuna bağlı olarak, birden çok Exchange sitesinden aynı anda posta geçişini uygulamak için Otomatik Bulma hizmetine güvenebiliriz. kullanıcı posta kutusu).
Ön gereksinimler, Exchange sitelerinin her birinin, genel ağdan erişilebilen "Genel ad" (URL) içeren genel bir varlığa sahip olmasıdır.
Bu süreci daha iyi anlayabilmek için aşağıdaki örneği kullanalım:
o365info adlı bir kuruluşun iki Exchange sitesi vardır. Bir site New York'ta bulunmaktadır ve ek site Los Angles'ta bulunmaktadır.
- New York sitesindeki Exchange posta sunucusu şu genel adı kullanır:
Mail.Ny-o365info.com - Los Angles sitesindeki Exchange posta sunucusu şu genel adı kullanır:
Mail.La-o365info.com
Hibrit geçiş seçeneğini kullanıyoruz ve buluta (Exchange Online) taşımak istediğimiz kullanıcıların listesini içeren bir CSV dosyasına dayalı yeni bir geçiş toplu işlemi oluşturuyoruz. CSV kullanıcıları listesi, her iki kuruluş sitesinden kullanıcıların bir "karışımını" içerir.
Örneğimizde: Kullanıcı1 ve Kullanıcı2 posta kutuları New York sitesinde bulunur ve Kullanıcı3 ve Kullanıcı4 posta kutuları Los Angeles sitesinde yer almaktadır.
Senaryomuzda o365info.com'un Otomatik Bulma kaydı, şirket sitesinde bulunmayan ek Exchange sunucusunu işaret ediyor.
Geçiş toplu işlemini başlattığımızda Exchange Online, posta altyapısı vb. hakkında gerekli bilgileri almak için Otomatik Bulma hizmetini kullanır.
Aşağıdaki diyagramda Exchange Online'ın Kullanıcı1@o365info.com'a bilgi verebilecek ve posta kutusu verilerine erişim sağlayabilecek Exchange sunucusunu (CAS sunucusu) sorduğunu görebiliriz.
Kaynak Exchange sunucusu, Exchange Online'ı ek sunucuya yönlendirerek bir "cevap" sağlar: Mail.Ny-o365info.com
İkinci adımda Exchange Online, Mail.Ny-o365info.com'a bağlanmayı deneyecek ve Kullanıcı1'in posta kutusu verilerini kopyalamak için “izin isteyecektir”.
Exchange Online, başarıyla keşfedilen veya manuel olarak sağladığınız bağlantı ayarlarını kullanarak yeni bir geçiş uç noktası oluşturur. Ayarlarını manuel olarak girdiğiniz uç noktaları oluşturmak yerine, bağlantı ayarları otomatik olarak keşfedilen geçiş uç noktaları oluşturmanızı öneririz. Bunun nedeni, geçiş sırasında her kullanıcı posta kutusuna bağlanmak için Otomatik Bulma hizmetinin kullanılmasıdır.
El ile ayarlar kullanılırsa Exchange Online, Otomatik Bulma hizmetini kullanmaz ancak el ile girdiğiniz bağlantı ayarlarını kullanarak belirli bir kaynak sunucuya bağlanır. El ile ayarlar kullanıyorsanız ve birden fazla şirket içi Exchange sunucunuz varsa, her sunucuya karşılık gelen farklı geçiş uç noktaları oluşturmanız gerekebilir.
Office 365/Exchange Online faktörleri
1. Office 365/Exchange Çevrimiçi Kısıtlama politikası
Posta geçişiyle ilgili Kısıtlama politikası, geçiş hizmeti kısıtlaması olarak tanımlanır. Bu politika, maksimum geçiş eşzamanlılığını sınırlamak için tasarlanmıştır.
İyi haber şu ki, varsayılan değeri kolayca artırabiliyoruz ve bunu yaparak taşınabilecek posta kutularının sayısını artırabiliyoruz.
Benim düşünceme göre varsayılan değer olan “aynı anda maksimum 20 posta kutusu” Exchange Online sunucu performansını korumak için oluşturulmamıştır çünkü teorik olarak Exchange Online sunucusuna ayrılan kaynaklarda herhangi bir sınırlama yoktur.
Dikkat edilen nokta, Exchange şirket içi sunucusunu "ezici" bir senaryodan korumaktı. Exchange şirket içi sunucusuna çok fazla yük yüklememiz durumunda, geçiş sürecinin yükü diğer Exchange şirket içi sunucu hizmetlerini etkileyebilir.
Bu nedenle, geçiş hizmeti kısıtlamasının değerini artırmayı düşünüyorsanız lütfen Şirket içi Exchange sunucunuzun, Exchange Online'a taşınan posta kutusu miktarını desteklemek için gerekli kaynaklara sahip olduğunu doğrulayın.
Bir geçiş toplu işlemi oluşturduktan sonra bunu en fazla 100'e çıkarmak için aşağıdaki Windows PowerShell komutunu kullanabilirsiniz.
Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>2. Taşıma Uç Noktaları için maksimum eşzamanlı hareket sayısı
Her geçiş uç noktası türü için 100 eşzamanlı geçiş sınırı vardır. Örneğin, kuruluşunuzda beş adet Outlook Anywhere geçiş uç noktası olabilir ve her uç nokta, maksimum 20 eşzamanlı geçiş için yapılandırılabilir. Veya her bir uç noktası maksimum 50 eşzamanlı geçişi destekleyecek şekilde yapılandırılmış iki IMAP geçiş uç noktanız olabilir.
Aşağıdaki ekran görüntüsünde 100'den büyük bir değer kullanmaya çalıştığımızda bunu görebilirsiniz.
Sonuç aşağıdaki hatadır:
Bu uç nokta, maksimum eşzamanlı geçiş sayısını '101' yapar ve bu da 'ExchangeRemoteMove' türündeki uç noktalar için izin verilen '100' sınırını aşar.
Sadece dostane bir tavsiye: Office 365'in eşzamanlı posta kutusu taşıma işleminin değerini "genişletmemize" olanak sağlaması, bu seçeneği otomatik olarak kullanmanız gerektiği anlamına gelmez.
Paralel posta kutusu taşımalarının yüksek değeri, ağ bant genişliğinizin ve Exchange Şirket İçi sunucularınızın aşırı yüklenmesine neden olabilir.
Geçirilecek posta kutusu sayısı alanı aynı anda şirket içi posta sunucunuza geçiş sırasında kullanılan bağlantı sayısını belirtir. Şirket içi posta sunucunuzla ne kadar çok bağlantınız varsa, tek seferde o kadar çok posta kutusunu taşıyabilirsiniz. Bu, posta kutularını taşımak için gereken süreyi azaltırken, bu ek bağlantılar İnternet bant genişliğinizi tüketerek ağ performansını ve kullanıcıların İnternet kaynaklarına erişme yeteneğini olumsuz yönde etkileyebilir.
Bir sonraki makalede Office 365'e Posta Geçişini inceleyeceğiz | Posta Taşıma işlemlerini ölçün ve tahmin edin.