Microsoft Azure’un sunduğu File Share servisini, gerek onprem file server’ınızı buluta taşımak gerekse hybrid bir kullanım modeli (tiering vb.) için tercih etmiş olabilirsiniz. Her iki senaryoda da mevcut dosyalarınızı buluta taşımak ve sürekli bir senkronizasyon sağlamak için en pratik çözüm Azure File sync servisini kullanmaktır. Fakat File sync servisini kullanırken dikkat etmeniz gereken bazı noktalar olacaktır. Bandwidth kullanımı da bunlardan birisi. Önce File sync nedir kısaca bir hatırlayalım sonrasında bu noktaları sizlerle paylaşacağım.
File sync nasıl çalışır?
Bu yazının ana konusu kurulum adımları olmadığı için eğer detaylı bir kurulum rehberine ihtiyacınız varsa, Veysel Onat’ın Çözümpark’ta hazırladığı detaylı içeriğe göz atabilirsiniz.
İlk adım Azure üzerinde bir File sync oluşturmak. Ardından File server üzerinde kurduğumuz bir agent sayesinde Windows sunucuyu Azure file sync servisine kaydederiz. Agent üzerinde yetkili Azure hesabınız ile oturum açtıktan sonra Azure subscription, RG ve Sync Service kutucuklarını doldurarak işlemi tamamlayabilirsiniz.
Bunun ardından Azure File sync üzerinde bir sync group oluşturup ve hem bu işlem için Azure üzerinde daha önce hazırladığımız File share’i (Cloud endpoint) hem de File Server’i barındıran Windows server’i (Server endpoint) bu gruba ekleriz. Ardından Windows server’daki Disk veya dosya lokasyonunu göstererek sync işlemini başlatırız.
Bu ilk sync (senkronizasyon), tüm dosyalar eşitlenene kadar devam eder. Belki bunun ne kadar süreceğini zaman olarak öngörebilir ve iş saatleri dışında gerçekleştirebilirsiniz. Böylece bant genişliği vs gibi unsurlara minimum etki etmiş olur. Fakat sonrasında gerçekleşecek delta senkronizasyonlara asıl problemi teşkil etmekte. Çünkü bu delta sync’ler için herhangi bir kontrol mekanizması bulunmuyor.
Delta sync nasıl çalışır?
File sync servisi, ilk sync bittikten sonra bir soluklanıyor ve ardından Windows Server üzerindeki Windows USN Journaling özelliğinden yararlanarak dosya değişikliklerini algılıyor. Bu değişiklikler algılandığı andan itibaren dosya bazında senkronizasyonu tekrar tetikliyor.
Belki küçük ölçekteki firmalar için bu problem olmayabilir. Fakat orta ve büyük ölçekteki firmalarda File server sadece kullanıcılar değil uygulamalar tarafından da kullanılan bir ortak dosya depolama alanı olabiliyor. Bu da gün içerisinde on binlerce dosya değişikliği veya yeni dosya yazılmasına neden oluyor. Hal böyle olunca ofisinizde bulunan File server ile Azure File share arasında sürekli bir dosya senkronizasyonu gerçekleşiyor. Eğer Azure sunucularına fiziki olarak uzak bir lokasyondaysanız ve üstüne bir de Office bağlantınız çok iyi durumda değilse aynı ağı paylaşan diğer iş yükleri için de bir felakete yol açıyor. File sync işlemi sırasında servise, şu saatler arasında senkronizasyon yap veya şu durumda yap gibi bir planlama opsiyonumuz olmadığı için, servis kontrolsüzce bant genişliğini kullanmaya başlıyor.
Tabi anlattığım bu senaryo tiering senaryolarında veya kısa süreli geçişlerde daha kolay kotarılabilir. Fakat uzun süreli geçişlerde ise tam bir baş ağrısına dönüşüyor.
Bu arada ismi geçmişken Tiering’den de kısaca bahsedelim:
Tiering
File sync ile senkronizasyonu başlatmadan önce bu özelliği aktif ettiğinizde, sadece sık erişilen dosyalar (hot) onprem File server’da depolanır. Fakat daha az erişilen veriler (cool), namespace (dosya ve klasör yapısı) ve dosya içeriği olarak iki katmana ayrılır. Namespace, onprem file server’da depolanırken dosya içeriği ise File Share’de depolanır. Böylece kullanıcı bu dosya ve dizinleri File Server üzerinde de görür fakat içeriğe erişmek istediğinde File sync servisi bu içeriği File share’den çağırarak kullanıcıya sunar.
Tiering konusunda önemli bir detay da tiering politikalarıdır. Volume free space policy and Date policy olmak üzere iki tane politika bulunmaktadır. Bunlar, File share’de depolanacak soğuk verinin (cool) niteliğini tanımlamaya yarar.
Örneğin her iki politika ile şöyle tanımlamalar yapabiliriz;
Volume Space policy; File Server diskimde 50GB’dan az yer kaldığında az erişilen dosyaları Azure File Share’e taşı.
Date policy; 30 günden daha uzun süre önce erişilmiş dosyaları Azure File Share’e taşı.
Tierin özelliği ile hem kullanıcı deneyimi hem de dosya taşınma eforunu ve maliyetini optimize edebiliriz.
Fakat hem File share hem de File sync henüz optimize olmuş servisler değiller. Bu nedenle bazı ihtiyaçları tam olarak karşılayamıyor ve sorunları kolayca çözemiyoruz. Bunlardan biri de yukarıda bahsettiğim senkronizasyonu kontrol altına alıp planlayamamak.
Peki bu durumda ne yapabiliriz?
Neyse ki Microsoft, en azından File Sync servisinin bandwith kullanımını planlayabileceğimiz bir opsiyon sunuyor.
Belki Windows Journaling veya File Sync servisine müdahale edecek bir script gibi bir çözüm de düşünülebilir. Fakat kendi adıma sırtımı script’e yaslamayı pek sürdürülebilir bulmuyorum.
Bunun yerine File sync Agent’ın kurulu olduğu Windows Server üzerinde birkaç powershell komutu ile file sync servisinin hangi saatlerde ne kadar bandwidth kullanacağını planlayalım.
Windows server üzerinde powershell’i yönetici olarak çalıştırdıktan sonra aşağıdaki komutu çalıştıralım. Bu komut File sync agent ile gelen powershell modülünü kullanılabilir hale getirecek.
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Sonraki adımımız gün ve saat bazlı bandwidth limitini tanımlamak. Aşağıdaki örnek komutta haftanın her günü gece 00.00 ile 05.00 saatleri arasında 5 Mbps kullanım limiti tanımlamaktayız.
New-StorageSyncNetworkLimit -Day Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday -StartHour 00 -StartMinute 00 -EndHour 04 -EndMinute 59 -LimitKbps 5000
Bu özelliğin en güzel yanı da farklı zaman aralıklarına farklı limitler atayabilmeniz.
Bu sayede limiti, aktif saatlerde (5.00-23.59) 1 Mbps gibi çok daha düşük bir değere indirgiyorum.
New-StorageSyncNetworkLimit -Day Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday -StartHour 05 -StartMinute 00 -EndHour 23 -EndMinute 59 -LimitKbps 1000
Aşağıdaki komut ile de mevcut Sync limitlerini görebilirsiniz.
Get-StorageSyncNetworkLimit | ForEach-Object { Remove-StorageSyncNetworkLimit -Id $_.Id }
Bu da limiti düşürmeden önceki ve sonraki ping sonuçları. Gördüğünüz gibi File sync servisinin kullanımını kısıtladıktan sonra çok ciddi bir düşüş var.
Umarım File server’dan File share’e taşınmayı planlarken yardımı dokunacak bir içerik olmuştur. Bir sorunuz olursa yorum veya Çözümpark üzerinden bana ulaşabilirsiniz.