Pertanyaan: Apakah ada cara untuk membuat backlog file 350.000 ini selesai lebih cepat? Untuk hampir setiap file, satu-satunya perubahan adalah perubahan ke ACL untuk setiap file yang terpengaruh. Beberapa file telah mengubah konten, tetapi itu bukan kasus umum dalam situasi ini.
Ini mungkin diperbaiki. Saya akan mengedit teks ini untuk mengkonfirmasi keberhasilan / kegagalan setelah periode waktu dan verifikasi. Menjelang akhir teks pertanyaan ini saya telah merinci perubahan yang dibuat baru-baru ini yang mungkin telah memperbaikinya.
Kami memiliki grup replikasi DFSR dengan sekitar 450.000 file dan membutuhkan ruang 1,5TB. Dalam situasi ini, ada dua server Windows Server 2008 R2 yang berjarak sekitar 500 mil. Ada server lain, tetapi mereka tidak terlibat dalam grup replikasi ini. Server ALPHA adalah server utama dan yang digunakan oleh sebagian besar staf. Server BETA adalah server di kantor jarak jauh dan kurang sibuk.
Berikut adalah grafik backlog untuk grup replikasi ini (PNG yang dihosting di Google Drive) yang menunjukkan proses sinkronisasi lambat.
Saya perlu menghapus entri izin yang ada di direktori root grup replikasi itu, yang tentu saja diwarisi di sebagian besar subfolder. Saya membuat perubahan ini di server ALPHA. Segera setelah itu, DFSR memiliki 350.000 tumpukan file. Sudah lebih dari seminggu dan sekarang mencapai 267.000. Satu-satunya hal yang berubah (awalnya) adalah perubahan izin tunggal.
Inilah yang terjadi (ini bukan solusinya, hanya penjelasan lain tentang apa yang terjadi yang menyebabkan masalah ini): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -karena itu-ternyata-keluar-Jumat-malam-adalah-baik-untuk-bertarung.aspx # dfsr
Setiap perubahan yang terjadi pada server BETA direplikasi ke server ALPHA dengan sangat cepat karena tidak ada jaminan simpanan ke arah itu. File apa pun yang diubah pada BETA akan membuatnya menjadi ALPHA tanpa masalah.
Ini mereplikasi 24/7 dengan kecepatan penuh di koneksi 50Mbps satu ujung ke serat 100Mbps di ujung lainnya. Area pementasan adalah 100GB di setiap server. Tidak ada yang menarik di log peristiwa sama sekali. Ada peristiwa watermark tinggi yang tidak terkait yang muncul untuk grup replikasi yang tidak terkait yang tidak untuk replikasi khusus ini atau untuk pasangan server ALPHA / BETA ini. Khususnya tidak ada entri log peristiwa untuk tanda air tinggi atau untuk kesalahan koneksi.
Pandangan ALPHA tentang kelompok replikasi:
Penghematan Bandwidth : Pengurangan 99,83% (30,85 MB direplikasi alih-alih 18,1 GB)
Saya percaya bahwa 30.85MB / 18.1GB terjadi sejak saya me-restart layanan DFSR pada ALPHA dan BETA. Jika demikian, ini menunjukkan bahwa meskipun itu memakan waktu yang sangat lama (lebih lama dari yang saya percaya seharusnya), sebenarnya tidak mentransfer isi file di seluruh kawat.
Folder yang direplikasi: 1.46TB (ukuran sebenarnya), 439.387 (file), 52.886 (folder)
Folder konflik dan terhapus: 100.00GB (ukuran terkonfigurasi), 34.01GB (ukuran sebenarnya), 19.620 (file), 2.393 (folder)
Staging folder : 200.00GB (ukuran yang dikonfigurasi), 92.54GB (ukuran sebenarnya)
Saya mendapat satu kesalahan watermark yang tinggi di log (14 Mei, 7 malam) dan telah menaikkan kuota pementasan menjadi 200GB dari 100GB. Saya tahu bahwa rute yang disetujui Microsoft akan meningkat 20%, tapi saya tidak mempermasalahkan hal ini. Kami memiliki banyak ruang disk untuk disimpan pada array disk panggung.
Menonaktifkan anti-virus di semua server tidak membantu, meskipun saya pikir itu akan membantu sedikit. Untuk saat ini saya telah mengaktifkan kembali anti-virus tetapi mengatur jalur grup replikasi untuk dikecualikan dari pemindaian untuk menghapus variabel itu dari persamaan.
Apakah ada cara untuk mempercepat ini? Saya hanya akan membuat perubahan ini pada server BETA juga, tetapi ada file yang telah berubah pada ALPHA tetapi belum direplikasi ke BETA dan dengan membuat perubahan izin yang diwarisi pada BETA akan mendorong file LAMA dari BETA ke ALPHA (karena DFSR tampaknya abaikan cap waktu file ketika membandingkan file mana yang merupakan pemenang dalam suatu tabrakan). Dan memiliki itu terjadi akan agak buruk.
Tumpukan berkurang perlahan. Sangat, sangat lambat. Tapi ini akan terus maju. Tetapi pada tingkat ini, itu akan menjadi minggu sebelum selesai. Saya sedang mempertimbangkan hanya mendorong salinan data yang ditetapkan ke drive 3TB dan mengirimkannya ke kantor jarak jauh. Apakah ada cara yang lebih baik?
16 Mei 4:00 PT AS: Apa yang mungkin telah memperbaiki masalah (dengan asumsi itu telah diperbaiki dengan jujur)
Saya membuat beberapa perubahan pada DC yang seharusnya dibuat sejak lama. Masalahnya adalah bahwa jaringan ini diwarisi dari orang lain yang mungkin mewarisinya dari orang lain, dll. Saya tidak bisa menjanjikan perubahan mana yang memperbaiki masalahnya. Di sini mereka tanpa urutan tertentu:
- Semua DC tidak dalam OU "Pengontrol Domain". Saya belum pernah melihat Domain Windows yang memiliki DC mereka di tempat lain. Saya memindahkan mereka kembali ke tempat mereka seharusnya berada. Mereka sebelumnya berada di OU yang dipisahkan dengan nama kota di mana masing-masing kantor berada. (Saya punya perasaan saya punya beberapa pekerjaan pipa yang harus saya selesaikan sekarang karena saya memindahkannya, tetapi semua tampak baik-baik saja saat ini ...)
- AVG Anti-Virus berjalan di semua server yang berpartisipasi dalam DC dan DFSR. Saya mengecualikan folder yang direplikasi dan folder pementasan dari pemindaian aktif / saat akses. Saya tidak berpikir ini memperbaiki masalah dan saya mungkin akan menguji masalah ini nanti untuk melihat apakah membatalkan perubahan itu akan mengganggu kecepatan replikasi DFSR. Itu tantangan untuk hari lain.
- dcdiag.exe mengeluhkan masalah DNS terkait RODC. Saya memperbaiki masalah itu meskipun kami tidak memiliki RODC di domain sama sekali. Saya ragu ini memperbaiki apa pun.
- Salah satu catatan _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV hilang untuk salah satu DC (bukan salah satu server DFSR) dan saya memperbaikinya. Saya pikir ini juga tidak membantu.
- Salah satu kali saya reboot server BETA itu mengeluhkan shutdown yang buruk dari database DFSR (peristiwa 2212) dan kemudian dilanjutkan dengan mengambil jam untuk membangun kembali database. Setelah selesai, saya melaporkan acara 2214 untuk memberi tahu saya bahwa itu sudah selesai. Setelah itu, replikasi masih berjalan sangat lambat, tetapi mungkin membantu menghapuskan apa pun yang macet.
- Salah satu DC tidak memiliki 127.0.0.1 sebagai server DNS sekunder dalam konfigurasi antarmuka. Saya menambahkannya. Ini bukan salah satu server DFSR, jadi mungkin tidak ada hubungannya dengan itu.
- Saya mengikuti Blog TechNet: Tuning kinerja replikasi di DFSR direkomendasikan pengaturan Registry untuk server DFSR. Saya menggunakan semua nilai "nilai kinerja tinggi yang diuji" kecuali untuk AsyncIoMaxBufferSizeBytes diatur ke 4194304, yang satu tingkat lebih rendah dari nilai tinggi. Ini bisa membantu dengan masalah ... atau mungkin tidak. Sulit untuk mengatakan kapan seseorang mengubah terlalu banyak variabel.
- dcdiag.exe mengeluh tentang masalah dengan berkomunikasi dengan layanan RPC di BETA, tetapi hanya setelah sudah membuat perubahan di atas. Tampaknya ini adalah masalah yang paling mungkin terjadi, tetapi tidak ada yang saya lakukan untuk memperbaikinya. VPN berjalan dengan benar dan firewall tidak memblokirnya. Mungkin saja salah satu dari item di atas adalah penyebab dan kemudian memperbaiki masalah RPC atau itu bisa saja kebetulan sederhana. Saya tidak mendapatkan kesalahan itu sekarang dan replikasi berjalan lancar saat ini.
Moral dari cerita ini adalah: ubah satu hal pada satu waktu atau Anda tidak akan pernah tahu apa yang memperbaikinya. Tapi saya putus asa dan kehabisan waktu untuk memperbaikinya, jadi saya hanya menembakkan banyak peluru ke masalah. Jika saya pernah menemukan perbaikannya, saya akan melaporkannya di sini. Jangan mengandalkan saya untuk mempersempitnya.
EDIT 5/21/2012: Saya memecahkan masalah ini dengan mengemudi selama sekitar tujuh jam dengan server cadangan (GAMMA) ke kantor jarak jauh kemarin. GAMMA sekarang bertindak sebagai server lokal utama mereka sementara server biasa (BETA) mengejar replikasi. Sejak saya menempatkannya, server telah menggandakan kecepatan replikasi. Meskipun hal ini memberitahu saya bahwa ini bisa menjadi masalah terkait VPN, saya cenderung tidak percaya bahwa itu karena semua pembaruan baru yang tampaknya meniru GAMMA dari ALPHA sangat cepat dan berjalan dengan baik.
EDIT 5/22/2012: Sekarang sudah di 12000 dan harus selesai dalam beberapa jam. Saya akan memposting grafik perkembangan dari awal yang lambat ke penyelesaian cepat. Masalahnya adalah bahwa satu-satunya hal yang benar-benar benar-benar "diperbaiki" adalah koneksi server lokal. Saat ini saya berpikir bahwa mungkin VPN adalah bagian dari masalah. Dan jika itu masalahnya, saya merasa bahwa pertanyaan ini belum terjawab. Setelah saya memiliki lebih banyak waktu untuk memeriksa bagaimana hal-hal direplikasi melalui VPN dan melihat kegagalan, saya akan men-debug dan melaporkan perkembangannya.
Jika ada perubahan, saya akan memperbarui di sini.
dfsrdiag replicationstate /amenunjukkan bahwa ia hanya mengirim dua file, tetapi keduanya memiliki nama file yang sama. Ia mengatakan bahwa ia memiliki dua koneksi keluar ke BETA dari ALPHA. File yang dikirim adalah 850MB. Seperti yang dijelaskan sebelumnya, saya tidak yakin bahwa itu sebenarnya mengirim seluruh isi file, meskipun saya tidak yakin apa yang akan dilakukan jika tidak karena butuh waktu yang sangat lama hanya untuk berurusan dengan satu file. File ini terakhir diperbarui pada 2008 (di kedua server) sehingga tidak ada alasan untuk melakukan apa pun kecuali memperbarui informasi ACL pada file di BETA.