[Catatan penerjemah. Artikel ini untuk Windows Server 2003 / 2003R2 / 2008 / 2008R2, tetapi sebagian besar di atas berlaku untuk versi OS selanjutnya]Halo semuanya!
Warren ada di sini lagi, dan posting blog ini adalah kompilasi dari masalah DFSR paling umum yang saya temui selama beberapa tahun terakhir. Tujuan dari posting ini adalah untuk membuat daftar kesalahan umum dalam konfigurasi DFSR yang menyebabkan masalah ini dan untuk mencegah Anda membuat kesalahan serupa. Mengetahui apa yang seharusnya
tidak dilakukan sama pentingnya dengan mengetahui
apa yang harus dilakukan. Banyak item yang dijelaskan terkait dengan topik lain, sehingga tautan yang sesuai disediakan untuk studi mendalam tentang masalah ini.
Ukuran kuota terlalu kecil untuk pementasan folder
Apakah Anda melihat banyak acara di majalah dengan kode 4202 dan 4204? Dalam hal ini, ukuran folder pementasan diatur secara tidak benar. Konsekuensi yang tidak menyenangkan dari ukuran folder pementasan yang tidak tepat adalah pengurangan kinerja replikasi, karena alih-alih mereplikasi file, layanan akan menghabiskan waktu membersihkan folder pementasan.
Server DFSR yang dikonfigurasi dengan ukuran folder pementasan yang memadai lebih efisien untuk setidaknya dua alasan:
- Jauh lebih efisien jika hanya meletakkan file di folder perantara satu kali, lalu mengirimnya ke semua mitra replikasi host, daripada membuat file, mereplikasi, dan kemudian menghapus salinan untuk setiap mitra host.
- Jika edisi Enterprise dari sistem operasi diinstal pada setidaknya satu anggota, server dapat menggunakan teknologi RDC lintas-file [sekitar. penerjemah: dimulai dengan Windows Server 2012, teknologi ini juga tersedia dalam edisi Standar]
Ukuran yang tidak dikonfigurasi dengan benar untuk folder staging juga dapat menyebabkan loop replikasi. Ini terjadi jika file yang direplikasi telah disalin ke folder pementasan pada server penerima, tetapi mekanisme pembersihan folder pementasan menghapus file ini sebelum dapat pindah ke folder tujuan. File yang dihapus akan direplikasi ke server lagi dan akan dihapus oleh server ini dari folder pementasan lagi, akibatnya server tidak akan pernah bisa menerima file. Proses ini akan diulang sampai server menerima file.
Jangan abaikan acara log untuk folder pementasan.
Lihat
posting ini yang menjelaskan cara menggunakan metode untuk menentukan ukuran minimum folder perantara.
Lihat bagian “Meningkatkan kuota sementara” di
sini .
Untuk informasi tentang RDC lintas-file, Anda dapat membaca artikel "Informasi tentang kompresi diferensial jarak jauh", diposting di
sini .
Prosedur preseeding yang salah atau belum diuji
Prosedur preseeding adalah menyalin data yang akan direplikasi ke server anggota replikasi baru sebelum ditambahkan ke folder tujuan server ini, untuk mengurangi waktu yang diperlukan untuk menyelesaikan replikasi primer. Sebagian besar kegagalan prosedur preseeding yang saya temui disebabkan oleh tiga alasan.
- Ketidakcocokan ACL pada sumber dan tujuan.
- Setelah menyalin ke anggota replikasi baru, perubahan dilakukan ke file.
- Tidak ada pra-pengujian yang dilakukan untuk memverifikasi bahwa prosedur pra-digunakan yang digunakan berfungsi seperti yang diharapkan.
Singkatnya, file harus disalin dengan cara tertentu, dan mereka tidak dapat diubah setelah disalin ke folder perantara, dan seluruh proses harus diuji terlebih dahulu oleh Anda.
Klik di
sini untuk membaca blog Mr. Pile tentang cara mengatur prosedur preseeding untuk server DFSR Anda.
Ukuran antrian salinan besar dari waktu ke waktu
Selain fakta bahwa antrian salinan besar yang ada untuk waktu yang lama berarti bahwa data Anda tidak disinkronkan, ini dapat menyebabkan resolusi konflik yang tidak diinginkan ketika file dengan konten lama menang dalam skrip resolusi konflik. Skenario yang paling umum di mana saya menemukan perilaku ini adalah penambahan besar folder replikasi baru. Alih-alih melakukan penyebaran bertahap, beberapa administrator sekaligus menambahkan 20 folder baru untuk replikasi dari 20 cabang yang berbeda, sehingga membebani server host secara berlebihan. Menyebarkan secara bertahap sehingga replikasi primer selesai dalam jumlah waktu yang wajar.
DFSR digunakan sebagai solusi cadangan
Percaya atau tidak, beberapa administrator menggunakan DFSR tanpa cadangan offline dari data yang direplikasi. DFSR tidak dirancang sebagai solusi cadangan. Salah satu tujuan pengembangan DFSR adalah menjadi bagian dari strategi cadangan perusahaan, karena DFSR memungkinkan Anda mengumpulkan data yang didistribusikan secara geografis di situs terpusat untuk pencadangan, pemulihan, dan pengarsipan nanti. Beberapa anggota replikasi memberikan perlindungan terhadap kegagalan server, tetapi ini tidak melindungi Anda dari penghapusan tidak disengaja. Agar sepenuhnya terlindungi, Anda perlu membuat cadangan data Anda.
Replikasi satu arah: penggunaannya dan metode perbaikan yang salah
Dalam upaya untuk mencegah pembaruan yang tidak diinginkan muncul di server di mana data tidak akan pernah berubah (atau jika mereka ingin mencegah perubahan pada mereka), banyak pelanggan membuat replikasi satu arah dengan menghapus koneksi keluar untuk anggota replikasi. Replikasi satu arah tidak didukung dalam versi DFSR apa pun sebelum Windows Server 2008 R2. Windows 2008 R2 mendukung replikasi satu arah, yang memungkinkan Anda untuk mengonfigurasi folder read-only untuk folder yang direplikasi.
Penggunaan anggota replikasi hanya baca dapat mencapai tujuan replikasi satu arah, yang mencegah perubahan yang tidak diinginkan dalam data yang direplikasi. Jika Anda ingin menggunakan replikasi satu arah menggunakan DFSR, gunakan Windows 2008 R2 dan untuk anggota yang tidak boleh diubah, pilih mode hanya baca.
Klik di
sini dan di
sini untuk mempelajari tentang replikasi baca-saja DFSR.
Masalah umum lainnya terjadi ketika administrator menemukan bahwa replikasi satu arah tidak didukung, dan mencoba untuk memperbaiki situasi, tetapi apakah itu dengan cara yang salah. Cukup mengaktifkan kembali dua arah kembali dapat memiliki hasil yang tidak diinginkan.
Klik di
sini untuk mempelajari cara memperbaiki replikasi satu arah.
Node server sebagai titik kegagalan tunggal dan server node kelebihan beban
Saya telah melihat banyak penyebaran dengan server node tunggal. Jika server simpul ini gagal, maka seluruh penyebaran berisiko. Jika Anda menggunakan Windows Server 2003 atau 2008, Anda harus memiliki setidaknya dua server host, dan jika salah satu dari mereka crash, yang lain harus menangani beban pada waktu pemulihan yang pertama dengan dampak minimal pada pengguna akhir. Dimulai dengan Windows Server 2008 R2, DFSR dapat digunakan pada kluster failover Windows, memberikan ketersediaan tinggi sementara mengurangi separuh persyaratan penyimpanan.
Cepat atau lambat, administrator memiliki situasi di mana ada terlalu banyak server di cabang yang dikonfigurasi untuk mereplikasi dengan server node tunggal. Hal ini dapat menyebabkan keterlambatan dalam replikasi. Untuk memahami berapa banyak server server kantor yang dapat dilayani oleh satu server node, Anda dapat menggunakan pelacakan antrian salin. Tidak ada formula ajaib, karena setiap lingkungan unik dan ada banyak ketergantungan.
Baca bagian "Konfigurasi Topologi" di
sini untuk mempelajari cara menggunakan server host.
Klik di
sini untuk mempelajari cara mengkonfigurasi DFSR pada kluster failover Windows Server 2008.
Terlalu banyak folder untuk direplikasi ke satu basis data Jet
DFSR menggunakan satu database Jet pada volume. Akibatnya, menempatkan semua folder yang direplikasi pada volume yang sama menghasilkan semua folder itu berada dalam basis data Jet yang sama. Jika muncul masalah dalam database ini yang perlu diperbaiki atau dikembalikan, database akan mempengaruhi semua folder yang direplikasi pada disk ini.
[Catatan penerjemah. jelas, ini bukan disk, tetapi volume.] Akan lebih tepat untuk menggunakan disk sebanyak mungkin dan mendistribusikan folder yang direplikasi di antara mereka, sehingga memastikan waktu ketersediaan data maksimum.
Penyebaran Berdasarkan Solusi Anggaran iSCSI
Saya sering melihat penyebaran DFSR menggunakan perangkat keras iSCSI termurah. Biasanya, jika Anda menggunakan DFSR, maka Anda melakukan ini untuk mencapai tujuan penting, seperti redundansi data, konsolidasi cadangan, pengiriman aplikasi yang dijadwalkan dan pembaruan OS. Membuat diri Anda bergantung pada peralatan berkualitas rendah yang tidak memiliki dukungan vendor normal bukanlah ide yang baik. Jika data penting untuk bisnis Anda, maka peralatan tempat OS dan mekanisme replikasi bekerja penting untuknya.
Layanan DFSR tidak menginstal tambalan saat ini
DFSR secara aktif didukung oleh Microsoft dan diperbarui sesuai kebutuhan. Perbarui DFSR jika ada rilis baru untuk itu pada saat siklus instalasi pembaruan Anda berikutnya. Pastikan server Anda diperbarui sesuai dengan artikel basis pengetahuan yang tercantum di bawah ini.
Perbaikan terbaru DFSR untuk Windows 2003 R2Perbaikan terbaru DFSR untuk Windows 2008 dan Windows 2008 R2Harap dicatat bahwa selain DFSR.EXE / DFSRS.EXE, pembaruan yang tercantum juga untuk NTFS.SYS dan file lainnya. Agar replikasi berfungsi dengan benar, selalu pastikan patch terbaru diinstal setidaknya untuk DFSR dan NTFS. Koreksi lain dari daftar terutama menyangkut masalah antarmuka pengguna, dan Anda harus menginstalnya setidaknya pada sistem-sistem di mana tugas konfigurasi DFSR dilakukan.
Disarankan bahwa tambalan diinstal pada server DFSR terlebih dahulu, bahkan jika semuanya berfungsi dengan baik, karena nanti ini akan membantu Anda menghindari munculnya masalah yang diketahui.
Driver adaptor jaringan tidak didukung terbaru
DFSR hanya akan dapat berfungsi secara normal jika jaringan yang Anda berikan juga berfungsi tanpa masalah. Menggunakan driver 5 tahun lalu bukanlah solusi yang paling cerdas. Saya memiliki pengalaman berkomunikasi dengan beberapa pelanggan yang masalah replikasi DFSR diselesaikan dengan memperbarui driver NIC yang sudah ketinggalan zaman.
Pemantauan DFSR Hilang
Terlepas dari kenyataan bahwa DFSR digunakan untuk memindahkan, sebagai aturan, data penting, banyak admin tidak tahu apa yang dilakukan DFSR sampai mereka menemukan masalah. Mereka yang lebih banyak akal membuat skrip sendiri untuk memantau antrian salin di server mereka, tetapi kebanyakan hanya mengandalkan itu. Paket manajemen untuk DFSR dirilis hampir setahun yang lalu (dan versi lain muncul sebelumnya). Instal dan gunakan - dan kemudian Anda dapat mendeteksi masalah dan menanggapinya sebelum mereka berubah menjadi mimpi buruk. Jika Anda tidak dapat menggunakan Paket Manajemen Manajemen Operasi untuk DFSR, maka setidaknya tuliskan skrip untuk memantau antrian salin setiap hari untuk memahami apakah file DFSR bereplikasi atau tidak.
Klik di
sini untuk informasi tentang Paket Manajemen Manajemen Operasi untuk DFSR.
Diperbarui 19 Januari 2011:Membuat perubahan pada penyimpanan disk tanpa terlebih dahulu mengarsipkan data
Jika server DFSR perlu mengganti hard drive atau menambahkan yang baru untuk menambah ruang penyimpanan, sangat penting untuk memiliki cadangan data terbaru jika terjadi kesalahan. Semuanya bisa salah, paling sering peristiwa konflik terjadi karena perubahan tak terduga di folder induk atau penghapusan folder induk yang tidak disengaja, yang direplikasi ke semua mitra. Anda harus mencadangkan data Anda sebelum membuat perubahan dan menyimpannya hingga proyek selesai.
Menghentikan layanan DFSR untuk menghentikan replikasi sementara
Terkadang Anda perlu menghentikan replikasi sementara. Cara yang tepat untuk melakukan ini adalah menonaktifkan replikasi untuk grup yang diinginkan menggunakan jadwal. Layanan DFSR harus berjalan agar dapat membaca pembaruan di log USN. Jangan menghentikan layanan DFSR untuk waktu yang lama (berhari-hari, berminggu-minggu), karena ini dapat menyebabkan log overflow (jika banyak file telah diubah, ditambahkan atau dihapus selama waktu ini). DFSR akan pulih dari log overflows, tetapi dalam penyebaran besar akan membutuhkan waktu yang lama dan replikasi tidak akan berfungsi atau akan sangat lambat selama pemulihan log. Selain itu, Anda cenderung mengamati antrian salinan yang sangat besar sampai pemulihan log selesai.
Semoga daftar ini membantu Anda. Replikasi yang bagus!
Warren "jaring lebar" Williams
[Catatan penerjemah. Jika ada minat pembaca, saya akan mencoba nanti untuk menerjemahkan artikel yang diposting pada tautan yang ditunjukkan dalam teks, serta artikel lain dari penulis asli]