Beş haftadır vSAN'ın blok depolama tarafını (VMDK'lar, storage policy'ler, cluster mimarileri) işledim. Modül 6 farklı bir katmana giriyor: File Services. Bu modülde vSAN datastore üzerinde NFS ve SMB paylaşımları oluşturmayı, bunları izlemeyi ve gerçek bir client'tan mount edip dosya yazmayı görüyoruz.
Bu konu ilk bakışta "neden vSAN bir NAS gibi davransın ki" sorusunu akla getirebiliyor. Ama mantığını anlayınca aslında oldukça pratik bir kullanım alanı ortaya çıkıyor: zaten var olan vSAN altyapısını, ayrı bir dosya sunucusu kurmadan, dosya paylaşımı ihtiyaçları için de kullanabilmek.
vSAN File Services Nedir?
vSAN File Services, vSAN datastore üzerinde dosya paylaşımları (file share) oluşturmayı sağlıyor; bu paylaşımlara client workstation'lar veya VM'ler erişebiliyor. Desteklenen protokoller: SMB, NFSv3 ve NFSv4.1.
Mimarinin altında vSAN Distributed File System (vDFS) yatıyor. Bu, vSAN nesnelerini birleştirerek ölçeklenebilir bir dosya sistemi sağlıyor. File share'ler, mevcut Storage Policy Based Management mekanizmasına entegre; yani her paylaşıma, VMDK'lara atadığımız gibi bir storage policy atanabiliyor.
Teknik olarak dikkat çeken bir nokta: File Service etkinleştirildiğinde vSAN, cluster için tek bir vDFS dağıtık dosya sistemi oluşturuyor ve bunu her host üzerinde container'lar halinde çalıştırıyor. Bu container'lar hypervisor ile sıkı entegre, dosya servislerini sağlamanın birincil aracı olarak çalışıyorlar.
IP Havuzu Mantığı
File Service etkinleştirilirken statik bir IP adres havuzu tanımlanması gerekiyor. Bu havuzdaki adreslerden biri "primary IP" olarak atanıyor; SMB ve NFSv4.1 referral mekanizması sayesinde, tüm paylaşımlara bu tek IP üzerinden erişilebiliyor.
Her IP adresi için ayrı bir file server başlatılıyor, ama paylaşımlar bu sunucular arasında dengeli dağıtılıyor. İdeal performans için IP adres sayısının, vSAN cluster'ındaki host sayısına eşit olması öneriliyor. Bu IP'lerin DNS'te forward ve reverse lookup kayıtlarının olması da gerekiyor.
Bu detayı okurken şunu düşündüm: bu, tipik bir load-balanced servis mimarisi. Tek bir giriş noktası (primary IP) sunarken arkada birden fazla worker'a (file server) dağıtım yapması, kullanıcı deneyimini basitleştirirken ölçeklenebilirliği koruyor.
Bir Kısıtlama: Stretched Cluster Desteklenmiyor
Manuel'de net bir uyarı var: File Services şu anda vSAN Stretched Cluster üzerinde desteklenmiyor, sadece normal (standart) bir vSAN cluster üzerinde etkinleştirilebiliyor. Bu, Modül 4'te öğrendiğimiz stretched cluster mimarisiyle File Services'i aynı cluster'da birleştiremeyeceğimiz anlamına geliyor; bu iki özelliği aynı anda isteyen bir tasarım için ayrı cluster'lar planlamak gerekecek.
Ağ Gereksinimleri
File Services'i etkinleştirmeden önce birkaç ağ gereksinimi karşılanmalı:
- Dosya paylaşımlarına tek erişim noktası olacak statik IP adresleri; en iyi performans için host sayısı kadar.
- Bu IP'lerin DNS'te forward ve reverse lookup zone'larında kayıtlı olması.
- Tüm statik IP'lerin aynı subnet'te olması.
- DVS (Distributed Virtual Switch) sürüm 6.6.0 veya üzeri; File Service için ayrı bir dedicated port group oluşturulması.
- Promiscuous Mode ve Forged Transmits'in, File Services etkinleştirme süreci sırasında otomatik olarak açılması. NSX tabanlı ağlar kullanılıyorsa bu ayarların NSX admin konsolundan da yapılması gerekiyor.
HOL'da File Services zaten önceden etkinleştirilmiş durumda; biz bu adımları uygulamıyoruz, ama gerçek bir kurulumda networking hazırlığının en az storage cluster networking'i kadar dikkat gerektirdiğini not etmek istedim (Modül 5'teki front-end/back-end ayrımına benzer bir dikkat seviyesi burada da geçerli).
File Services'in Etkin Olduğunu Doğrulamak
Site B vCenter'a giriş yapılıyor (vc-mgmt-b). Doğrulama adımları:
dc-b > vsan-storage-cluster-01b > Configure > vSAN > Services
Aşağı kaydırılınca File Service bölümünün "Enabled" durumda olduğu görülüyor.
Bu bölümde file service'in ağ detayları da görünüyor. Sol panelde vsan-storage-cluster-01b altında vSAN File Service node'larının oluşturulduğu görülüyor; her vSAN node için bir tane. Her File Service VM'i (FSVM) en fazla 50 paylaşım destekliyor, cluster başına toplam paylaşım limiti 500 (bunun içinde en fazla 100 tanesi SMB paylaşımı olabiliyor).
Bu limitleri görünce aklıma şu geldi: 500 paylaşım/cluster gibi bir üst sınır, küçük-orta ölçekli dosya paylaşımı ihtiyaçları için gayet yeterli, ama büyük bir dosya sunucusu konsolidasyonu planlıyorsanız bu sınırı erkenden hesaba katmak gerekiyor.
File Server Health Check
File Service'in sağlığını kontrol etmek için Skyline Health'e dönüyoruz, artık tanıdık bir akış:
Monitor > vSAN > Skyline Health > Health findings > ALL > Category filtresi > File Service
"File Server Health" bulgusunun üç nokta menüsünden "View Current Result" seçiliyor. Bu ekran, File Servers Service'e katkı veren host'ları, her file server node'unda çalışan servisleri ve atanmış IP adreslerini detaylı olarak gösteriyor.
Bu adım, Modül 3'teki (şifreleme) health check akışıyla neredeyse birebir aynı desende ilerliyor: kategori filtrele, bulguyu seç, View Current Result ile detaya in. vSAN'ın health check mimarisinin tutarlılığı, farklı özellikler için bile aynı zihinsel modeli kullanmanıza izin veriyor.
NFS Paylaşımı Oluşturmak
Paylaşım isimlendirmesi için birkaç kural var, not almaya değer:
- ASCII olmayan karakterler içeren kullanıcı adları paylaşım verisine erişim için kullanılabiliyor.
- Paylaşım isimleri sadece İngilizce karakterler içerebiliyor.
- Salt NFSv4 tipi paylaşımlarda dosya ve dizin isimleri herhangi bir UTF-8 uyumlu karakter içerebiliyor.
- Salt NFSv3 ve NFSv3+NFSv4 paylaşımlarında dosya ve dizin isimleri sadece ASCII uyumlu olabiliyor.
Bu kısıtlama listesi ilk okuyuşta teknik bir detay gibi görünüyor, ama gerçek bir ortamda özellikle Türkçe karakterler (ç, ş, ğ, ı, ö, ü) içeren dosya/dizin isimleriyle çalışırken, protokol seçiminin (salt NFSv4 mü, yoksa NFSv3 uyumlu mu) doğrudan bir etkisi olacağını gösteriyor.
Oluşturma Adımları
vsan-storage-cluster-01b > Configure > vSAN > File Shares > ADD
General sayfası:
- İsim:
VMSharesNFS - Protokol: NFS, hem NFS 4.1 hem NFS 3 versiyonları seçili
- Storage Policy:
vsan-storage-cluster-01b - Optimal Datastore Default Policy - RAID5 - Share warning threshold 5 GB, share hard quota 10 GB olarak etkinleştiriliyor
- NEXT
Net access control sayfası:
- "Allow access from any IP" seçiliyor
- NEXT
Review sayfası: Girilen bilgiler gözden geçirilip FINISH ile paylaşım oluşturuluyor.
Burada dikkatimi çeken şey, storage policy'nin ve quota ayarlarının (warning threshold, hard quota) aynı wizard içinde birlikte tanımlanması. Bu, bir dosya paylaşımının sadece "nerede depolanacağını" değil, aynı zamanda "ne kadar büyüyebileceğini" de aynı yerde yönetmenizi sağlıyor.
Oluşturulan Paylaşımı Görüntülemek
Paylaşım listesinde VMSharesNFS, atanmış storage policy, kullanım/kota ve gerçek kullanım bilgileriyle görünüyor. "Show or Hide Columns" ile Hard Quota ve Warning Threshold sütunları da eklenebiliyor.
Paylaşımı Başka Sistemlere Mount Etmek
Bu bölüm, HOL'un daha "elle dokunulan" kısımlarından biri; gerçekten bir Linux terminalinden mount komutu çalıştırıp dosya yazıyoruz.
Bağlantı Yolunu Kopyalamak
VMShareNFS seçilip "COPY PATH" dropdown'ından NFS 3 veya NFS 4.1 seçilebiliyor. NFS 4.1 seçildiğinde örnek bağlantı dizesi şöyle görünüyor:
- NFSv3:
vsan-fs-06a.vcf.sddc.lab:/VMSharesNFS - NFSv4.1:
vsan-fs-01a.vcf.sddc.lab:/vsanfs/VMSharesNFS
Not: NFSv4.1 referral mekanizmasıyla mount etmek için, mount path'inde kök paylaşımı (/vsanfs) dahil edilmesi gerekiyor.
Terminal Üzerinden Mount Etmek
Terminal açılıp şu komut çalıştırılıyor:
sudo mount vsan-fs-07b.site-b.vcf.lab:/VMSharesNFS /mnt/newfs
Şifre istendiğinde VMware123!VMware123! giriliyor. Mount'un başarılı olduğu şu komutla doğrulanıyor:
sudo mount | grep /mnt/newfs
Manuel'de bir not var: NFS 4.1 aynı zamanda varsayılan mount versiyonu; eğer protokol belirtilmezse, client sunucuyla en yüksek uyumlu protokolü otomatik müzakere ediyor, vSAN 9 Native File Services için bu NFS v4.1.
Dosya Yazıp Okumak
cd /mnt/newfs
echo "NFS 4 Share" >> newfs.txt
cat newfs.txt
Bu üç komutla paylaşıma bir dosya yazılıyor ve tekrar okunarak doğrulanıyor.
Bu basit test, aslında modülün en somut kanıtı: vSAN üzerinde oluşturduğumuz bir "storage policy'ye bağlı nesne", gerçek bir Linux client'tan standart NFS protokolüyle erişilebilir, yazılabilir bir dosya sistemi olarak çalışıyor. Bunun arkasında vDFS, container'lar, IP havuzu gibi karmaşık bir mimari olsa da, client tarafında deneyim sıradan bir NFS mount'undan farksız.
vSAN Nesne Görünümü ve Placement Details
Paylaşımın vSAN'ın kendi nesne yapısına nasıl entegre olduğunu görmek için:
vsan-storage-cluster-01b > Monitor > vSAN > Virtual Objects
VMSharesNFS seçilip "VIEW PLACEMENT DETAILS" tıklanıyor.
Bu ekran, dosya paylaşımının bileşenlerinin hangi host'larda ve hangi fiziksel storage cihazlarında yerleştiğini gösteriyor.
Bu, Modül 1'de bir VM'in VMDK'sı için gördüğümüz Placement Details ekranıyla aynı arayüz, aynı mantık. Bir dosya paylaşımının da tıpkı bir sanal disk gibi vSAN nesnesi olarak ele alınması ve aynı görselleştirme aracıyla incelenebilmesi, vSAN'ın "her şey bir nesne" felsefesinin tutarlılığını gösteriyor.
File Service Health'i Tekrar Kontrol Etmek
Yeni paylaşım oluşturulduktan sonra Skyline Health'e dönülüp RETEST yapılıyor (health check zaten periyodik çalışıyor, ama yeni bir servis eklendiği için manuel tetiklemek öneriliyor).
Filtre yine File Service kategorisine ayarlanıyor. Bu sefer "Share Health" bulgusunun üç nokta menüsünden "View Current Result" seçiliyor.
Sonuç, oluşturduğumuz paylaşımın sağlıklı olduğunu gösteriyor.
Performans ve Kapasite İzleme
File Services için de, önceki modüllerde gördüğümüz izleme mantığı geçerli.
Performans:
vsan-storage-cluster-01b > Monitor > vSAN > Performance > FILE SHARE > VMSharesNFS
Burada file service için toplanan çeşitli metrikler görülüyor.
Kapasite:
Monitor > vSAN > Capacity, aşağı kaydırılıp "Usage breakdown" bölümünde "User Data" genişletilerek File Shares kapasite kullanımı görülüyor.
Bu iki ekran, Modül 2'de öğrendiğimiz izleme çerçevesinin (Skyline Health, Kapasite, Performans) File Services için de birebir geçerli olduğunu gösteriyor. Yeni bir özellik öğrenirken sıfırdan bir izleme mantığı öğrenmek yerine, var olan çerçeveyi yeni bir nesne tipine uygulamak yeterli oluyor.
Genel Değerlendirme
Bu modül, vSAN'ın "sadece blok depolama" olmadığını gösteren iyi bir örnekti. File Services, temelde aynı vSAN altyapısını (aynı disk grupları, aynı SPBM mekanizması, aynı health check çerçevesi) kullanarak farklı bir erişim modeli (dosya paylaşımı) sunuyor.
Benim için en dikkat çekici üç nokta şunlardı:
Birincisi, IP havuzu ve primary IP mekanizmasının load-balancing mantığıyla çalışması. Host sayısı kadar IP tanımlayıp bunları file server'lara dağıtmak, basit ama etkili bir ölçeklenebilirlik yaklaşımı.
İkincisi, paylaşım isimlendirme kurallarındaki ASCII/UTF-8 ayrımı. Küçük bir detay gibi görünüyor ama gerçek bir ortamda, özellikle Türkçe gibi ASCII-dışı karakterler kullanan dil ortamlarında, protokol seçiminin doğrudan pratik bir etkisi oluyor.
Üçüncüsü, tüm bu modül boyunca "yeni bir şey öğreniyormuşum" hissinden çok, "tanıdık araçları yeni bir nesne tipine uyguluyormuşum" hissi baskındı. Placement Details, Skyline Health akışı, Performance ve Capacity sekmeleri; hepsi önceki modüllerden tanıdık. Bu tutarlılık, vSAN'ın farklı özelliklerini öğrenirken kümülatif bir öğrenme eğrisi sağlıyor: her yeni modül, sıfırdan başlamak yerine önceki modüllerin üzerine inşa ediyor.
Bir sonraki hafta son modül olan Modül 7'ye geçiyorum: Data Protection.
Bu seri VMware HOL ortamı (HOL-2634-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production ortamı kararları için mutlaka resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.
Top comments (0)