Soru: Bu 350.000 dosya biriktirme listesini daha hızlı tamamlamanın bir yolu var mı? Hemen hemen her dosya için tek değişiklik, etkilenen her dosya için ACL'deki bir değişiklikti. Bazı dosyalar içeriği değiştirdi, ancak bu durumda bu yaygın bir durum değil.
Bu düzeltilebilir. Belirli bir süre ve doğrulamadan sonra başarılı / başarısız olduğunu onaylamak için bu metni düzenleyeceğim. Bu soru metninin sonuna doğru, son zamanlarda yapılan ve düzeltmiş olabilecek değişiklikleri ayrıntılı olarak anlattım.
Yaklaşık 450.000 dosyaya sahip bir DFSR çoğaltma grubumuz var ve 1,5 TB alan kaplıyor. Bu durumda, yaklaşık 500 mil uzaklıktaki iki Windows Server 2008 R2 sunucusu vardır. Başka sunucular da var, ancak bu çoğaltma grubuna dahil değiller. Sunucu ALPHA ana sunucudur ve çoğu personel tarafından kullanılan sunucudur. Sunucu BETA uzak ofisdeki sunucudur ve daha az meşguldür.
Bu senkronizasyon ilerlemesini gösteren bu çoğaltma grubu (Google Drive'da barındırılan PNG) için bir biriktirme listesi grafiği .
Tabii ki alt klasörlerin çoğunda devralınan çoğaltma grubunun kök dizininde olan bir izin girdisini kaldırmam gerekiyordu. Bu değişikliği sunucu ALPHA'da yaptım. Bundan hemen sonra, DFSR'nin 350.000 dosya biriktirme listesi vardı. Bir haftadan fazla oldu ve şimdi 267.000'de. Değişen tek şey (başlangıçta) tek izin değişikliğiydi.
Olan şey bu (bu çözüm değil, bu soruna neden olan şeyin başka bir açıklaması): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -çünkü-it-dönüşler aşımı-cuma-gece-oldu-tamam-için-fighting.aspx # dfsr
BETA sunucusunda meydana gelen değişiklikler, ALPHA sunucusuna çok hızlı bir şekilde çoğaltılır, çünkü bu yönde bir birikim yoktur. BETA'da değiştirilen dosyalar sorunsuz bir şekilde ALPHA'ya ulaşır.
Bir ucunda 50Mbps bağlantıda diğer ucunda 100Mbps fiberle tam hızda 7/24 çoğalıyor. Hazırlama alanı her sunucuda 100 GB'dir. Olay günlüklerinde hiç ilginç bir şey yok. Ne bu özel çoğaltma ne de bu ALPHA / BETA sunucu çifti için alakasız bir çoğaltma grubu için gösterilen ilişkisiz yüksek filigran olayı vardır. Özellikle yüksek filigran veya bağlantı hataları için olay günlüğü girişi yoktur.
ALPHA'nın çoğaltma grubuna bakışı:
Bant Genişliği Tasarrufu :% 99,83 azalma (18,1 GB yerine 30,85 MB çoğaltılmış)
ALPHA ve BETA'da DFSR hizmetini son olarak yeniden başlattığımdan beri 30.85MB / 18.1GB'ın gerçekleştiğine inanıyorum. Eğer öyleyse, bu çok uzun zaman alsa bile (alması gerektiğine inandığımdan daha uzun) aslında dosya içeriğini kablo üzerinden aktarmadığını gösterir.
Çoğaltılmış klasör : 1.46 TB (gerçek boyut), 439.387 (dosya), 52.886 (klasör)
Çakışma ve Silinen klasör : 100.00GB (yapılandırılmış boyut), 34.01GB (gerçek boyut), 19.620 (dosya), 2.393 (klasör)
Hazırlama klasörü : 200.00GB (yapılandırılmış boyut), 92.54GB (gerçek boyut)
Günlüklerde bir yüksek filigran hatası aldım (14 Mayıs, 19:00) ve böylece 100GB'dan 200GB'a kadar hazırlama kotasını yükselttik. Microsoft onaylı rotanın% 20 artacağını biliyorum, ama bu konuda oynamıyorum. Hazırlama diski dizilerine yüklenecek çok fazla disk alanımız var.
Tüm sunucularda anti-virüs vermedi devre dışı bırakılması değil diye düşündüm gerçi o biraz yardımcı olmuştur, yardım ederim. Şimdilik anti-virüsü yeniden etkinleştirdim ancak bu değişkeni denklemden kaldırmak için çoğaltma grubunun yolunu tarama dışında bırakılacak şekilde ayarladım.
Bunu daha hızlı yapmanın bir yolu var mı? Bu değişikliği sunucu BETA'da da yapardım, ancak ALPHA'da değişmiş ancak BETA'ya çoğaltılmamış dosyalar var ve BETA'da devralınan izin değişikliği yaparak ESKİ dosyaları BETA'dan ALPHA'ya iter (çünkü DFSR, bir çarpışmada hangi dosyanın kazanan olduğunu karşılaştırırken dosya zaman damgalarını yoksay). Ve bunun olması oldukça kötü olurdu.
İş yığını yavaş yavaş azalıyor. Çok, çok yavaş. Yine de ilerliyor. Ancak bu oranda, bitmesi haftalar olacaktır. Sadece 3 TB'lık bir sürücüye veri setinin bir kopyasını alıp uzak ofise göndermeyi düşünüyorum. Daha iyi bir yol var mı?
16 Mayıs, 04:00 ABD PT: Sorunu ne çözmüş olabilir (yine de dürüstçe düzeltildiği varsayılarak):
DC'lerde uzun zaman önce yapılması gereken birden fazla değişiklik yaptım. Sorun, bu ağın muhtemelen başka birinden miras alan başka birinden miras alınmış olmasıdır. Hangi değişikliğin sorunu düzelttiğine söz veremem. Burada belirli bir sırada değiller:
- Tüm DC'ler "Etki Alanı Denetleyicileri" kuruluş biriminde değildi. DC'leri başka yerlerde olan bir Windows Etki Alanı görmedim. Onları ait oldukları yere geri götürdüm. Onlar her bir ofis bulunmaktadır şehrin adını ayrılmış olduğunu OU'larda önce idi. (Ben ben o taşındı şimdi ile başa çıkmak için bazı sıhhi tesisat işler var his var, ama hepsi görünüyor şu anda tamam ...)
- AVG Anti-Virus tüm DC'lerde ve DFSR'ye katılan sunucularda çalışıyor. Çoğaltılmış klasörleri ve hazırlama klasörlerini etkin / erişimde tarama dışında bıraktım. Bunun sorunu çözdüğünü sanmıyorum ve bu değişikliği geri almanın DFSR'nin çoğaltma hızına müdahale edip etmeyeceğini görmek için bu sorunu daha sonra test edeceğim. Bu başka bir gün için zor.
- dcdiag.exe , RODC'lerle ilgili bir DNS sorunundan şikayet etti. Etki alanında hiç RODC olmamasına rağmen bu sorunu çözdüm. Bunun sabit bir şey olduğundan şüphe ediyorum.
- _Ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV kayıtlarından biri DC'lerden biri (DFSR sunucularından biri değil) için eksikti ve bunu düzelttim. Bunun da yardımcı olduğunu düşünmüyorum.
- Bir kez sunucu BETA yeniden önyükleme DFSR veritabanı (olay 2212) kötü bir kapatma şikayet ve daha sonra veritabanını yeniden oluşturmak için saatler sürdü. İşiniz bittiğinde, işin bittiğini bildirmek için olay 2214'ü bildirdi. Bundan sonra, çoğaltma hala çok yavaş çalışıyordu, ancak sıkışmış olan her şeyi açmaya yardımcı olabilirdi.
- DC'lerden birinde arayüz yapılandırmasında ikincil DNS sunucusu olarak 127.0.0.1 yoktu. Ekledim. Bu DFSR sunucularından biri değildi, bu yüzden muhtemelen onunla hiçbir ilgisi yoktu.
- TechNet Blog'u izledim : DFSR'de çoğaltma performansını ayarlama DFSR sunucuları için önerilen Kayıt Defteri ayarları. I haricinde "test yüksek performans değeri," tüm değerleri kullanılan AsyncIoMaxBufferSizeBytes ayarlandı , 4194304 bir çentik yüksek değerden daha düşüktür. Bu sorunla yardımcı olabilirdi ... belki de değil. Çok değişken değiştiğinde bunu söylemek zor.
- dcdiag.exe , yalnızca yukarıdaki değişiklikleri yaptıktan sonra BETA'daki RPC hizmetiyle iletişim kurma ile ilgili bir sorundan şikayet etti. Bu en olası sorun gibi görünüyordu, ama düzeltmek için yaptığım hiçbir şey yoktu. VPN düzgün çalışıyordu ve güvenlik duvarı onu engellemiyordu. Yukarıdaki maddelerden birinin RPC sorununa neden olan ve daha sonra çözülmüş olması mümkündür veya basit bir tesadüf olabilir. Ben am değil şimdi bu hatayı alıyorum ve çoğaltma şu anda sorunsuz çalışıyor.
Hikayenin ahlaki şöyledir: her seferinde bir şeyi değiştir, yoksa onu neyin düzelttiğini asla bilemezsin. Ama çaresizdim ve düzeltmek için zamanım tükeniyordu, bu yüzden problemde bir sürü mermi ateşledim. Düzeltmeyi hiç tespit edersem, bunu burada rapor edeceğim. Yine de bana daraltma.
EDIT 5/21/2012: Bunu, dün uzak bir servise yedek bir sunucu (GAMMA) ile yaklaşık yedi saat sürerek çözdüm . GAMMA artık birincil yerel sunucu gibi davranırken, normal sunucuları (BETA) çoğaltmayı yakalar. Yerine koyduğumdan beri, sunucular çoğaltma hızını ikiye katlıyorlar. Bu bana VPN ile ilgili bir sorun olabileceğini söylese de, tüm yeni güncellemelerin ALPHA'dan GAMMA'ya çoğaltıldığı için çok hızlı ve iyi gittiğine inanmaya daha az eğilimliyim.
EDIT 5/22/2012: Şu anda 12000'de ve birkaç saat içinde bitmesi gerekiyor. Yavaş başlangıçtan hızlı bitişe kadar ilerlemenin güzel bir grafiğini yayınlayacağım. Sorun gerçekten "sabit" tek şey yerel sunucu bağlantısı olmasıdır. Şu anda VPN'nin sorunun bir parçası olduğunu düşünüyorum. Ve eğer durum buysa, bu sorunun henüz tam olarak cevaplanmadığını hissediyorum. İşlerin VPN üzerinden nasıl çoğaltıldığını ve herhangi bir hatayı gördüğünü kontrol etmek için biraz zamanımdan sonra hata ayıklayacağım ve ilerlemeyi rapor edeceğim.
Bir şey değişirse, burada güncelleyeceğim.
dfsrdiag replicationstate /ayalnızca iki dosya gönderdiğini, ancak her ikisinin de aynı dosya adına sahip olduğunu gösterir. Zaten ALPHA'dan BETA'ya iki giden bağlantısı olduğunu söylüyor. Gönderdiği dosya 850 MB'dir. Daha önce açıklandığı gibi, aslında tüm dosyanın içeriğini gönderdiğine ikna olmadım , ancak tek bir dosyayla uğraşmak çok uzun zaman aldığından, ne yapacağından emin değilim . Dosya en son 2008'de (her iki sunucuda) güncellendiğinden, BETA'daki dosyadaki ACL bilgilerini güncellemek dışında bir şey yapması için hiçbir neden yoktur.