VPN üzerinden DFS çoğaltma: kilitleme elde ettiğiniz şey değildir

Bağlantı şifrelenmiş, her zaman açık ve yeterince hızlı; bu yüzden paylaşılan klasör iki sitede de tek bir klasör gibi davranmalı. İnsanları sonradan şaşırtan DFS çoğaltma tasarımlarının çoğunun arkasında bu varsayım var. DFSR çok ustalı ve eşzamansızdır: her replika sürümleri bağımsız izler ve protokolde sunucular arasında kilit tutan hiçbir şey yoktur. VPN aralarındaki trafiği taşır ve bu varsayımın gerektirdiği eşgüdümden hiçbir şey eklemez. Yazma düzenini ve kapasite modelini planlayın, yoksa ilk gerçek çakışma bir destek olayına dönüşür.

Efsane: VPN replikaları tek bir dosya sistemi yapar

Tünel bir taşıma yoludur. İki sunucu arasında izin verilen bir yol sağlar ve aradaki atlamaları gizler. Kimin dosyayı düzenleyebileceği, sürümlerin hangi sırayla geldiği veya iki düzenleme yarıştığında ne olacağı hakkında hiçbir şey söylemez.

Şifreleme ve kullanılabilirlik bağlantının özellikleridir; tutarlılık ise çoğaltma motorunun ve iş akışınızın özelliğidir.

DFSR gerçekte neyi çoğaltır

Her sunucu kendi kopyasını ve kendi sürüm üstverisini tutar. Değişiklikler bağlantı ve zamanlama izin verdiğinde yayılır ve motor, dosyanın yalnızca değişen bölümlerini göndermek için uzak fark sıkıştırmasını kullanır. İki replika, güncellemelerin hiçbiri ulaşmadan aynı dosyayı değiştirdiğinde bir sürüm kazanır, diğeri çakışma kopyası olarak kenara alınır. Hiçbir sunucu ikinci düzenlemeyi engellemedi, çünkü engelleme DFSR’nin sunmadığı dağıtık kilidi gerektirirdi.

Ad alanı yolu kopyalara ulaşmayı kolaylaştırır ve onları tutarlı yapmaz.

Staging alanı çalışma kapasitesidir, yedek değildir

Staging, çoğaltmanın değişiklikleri bir araya getirirken kullandığı çalışma alanıdır. Microsoft’un boyutlandırma kılavuzu, çoğaltılan klasördeki en büyük 32 dosyanın toplam boyutunu asgari olarak alır ve ilk çoğaltma sırasında ek alan yararlıdır. Bu nedenle küçük belgelerden oluşan bir ağaç ile birkaç büyük arşiv tutan bir klasör farklı staging biçimlerine ihtiyaç duyar. Staging tükendiğinde çoğaltma, ağ arızası gibi görünen biçimlerde durur. Boyutu verilerden hesaplayın, sonra veriler değiştikçe izlemeye devam edin.

Staging bir yedek değildir ve değişiklikleri yaymak sürüm geçmişi değildir.

Ön tohumlama bir iyileştirmedir, kısayol değildir

Büyük mevcut bir ağaç için Robocopy ile desteklenen ön tohumlama, ilk eşitleme sırasında bağlantıdan geçmesi gerekeni azaltabilir ve Microsoft’un kılavuzu dosya bilgilerinin korunmasını ve kilitli veya atlanan dosyaların ele alınmasını kapsar. Bu bir iyileştirmedir, hedefin zaten doğru olduğuna dair bir söz değildir, bu yüzden ilk çoğaltma yine de tamamlanmalı ve doğrulanmalıdır. Tam olarak bu doğrulamayı atlamak, bir sitenin çoğaltılan kümede hiç bulunmamış dosyaları sunmasına yol açar.

Başlangıç durumunu kullanıcılar hedefe güvenmeden önce doğrulayın, ilk şikâyetten sonra değil.

Pencereyi seçin ve güncelin ne anlama geldiğini tanımlayın

Çoğaltma zamanlaması ve bant genişliği denetimleri, ortakların veri alışverişi yapabileceği zamanı belirler. Mesai sonrası dar bir pencere, gün içinde birikim bırakan meşru bir tasarımdır; yeter ki herkes uzak kopyanın yalnızca sabaha kadar güncel olması gerektiğinde anlaşsın.

O cümleyi yazın, çünkü birikim kırk dakika ifadesi ancak kimse hedefi tanımlamadıysa endişe vericidir.

Tek bir dosyayla değil, iş akışıyla kabul edin

İnsanların gerçekten kullandığı dosyalarla test edin: büyük bir belge, rutin bir düzenleme, bir silme ve her iki sitede kasıtlı eşzamanlı düzenleme. Çakışma davranışının iş birimine söylediğinizle eşleştiğini ve yedekten kurtarma yolunun replikalardan ayrı olduğunu doğrulayın. Ardından birkaç hafta boyunca değişiklik hacmini, kuyruk büyümesini ve staging payını hizmet penceresine göre izleyin. VPN kapasitesi birkaç sınırdan biridir ve ulaştığınız ilk sınır olması nadirdir.

Gecikmesini ve düzenleme kurallarını belgeleyen bir tasarımı desteklemek, aynı kopyaları vaat eden bir tasarımdan çok daha kolaydır.