Bu rehber neyi çözer?
Windows ağırlıklı kullanıcı dosya paylaşımında SMB/Samba, Linux/Unix sunucu paylaşımında NFS daha doğal olabilir; doğru seçim kimlik, ACL ve workload’a bağlıdır.
Samba/SMB
Windows istemci uyumluluğu, AD kimlikleri, ağ sürücüleri ve Windows tarzı ACL ihtiyacında güçlü seçenektir.
Share izinleri ve filesystem ACL’leri birlikte tasarlanmalıdır.
NFS
Linux/Unix sunucular arası paylaşım, uygulama verisi ve bazı storage senaryolarında daha doğal olabilir.
UID/GID eşleşmesi, root squash, export izinleri ve network segmentasyonu kritik güvenlik başlıklarıdır.
Performans ve kapasite
Disk IOPS, network, dosya boyutu dağılımı, eşzamanlı kullanıcı ve metadata yükü ölçülmelidir.
10GbE üzerinde darboğazın storage tarafında olup olmadığı ayrıca test edilmelidir.
Yedekleme
Snapshot, immutable/offsite kopya, retention ve restore testi birlikte planlanmalıdır.
Kullanıcı yazma yetkileri ile backup repository yetkileri ayrılmalıdır.
Sık Sorulan Sorular
Windows kullanıcıları NFS kullanmalı mı?
Mümkün olsa da Windows ağırlıklı kullanıcı paylaşımında SMB/Samba genellikle daha doğal yönetim sağlar.
Samba Windows File Server’dan yavaş mı?
Genellenemez; storage, network, SMB ayarları ve workload performansı belirler.
Snapshot yedek yerine geçer mi?
Hayır. Snapshot hızlı geri dönüş sağlar ama bağımsız offsite/immutable yedeğin yerini tutmaz.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
SMB/Samba ve NFS farklı kimlik ve dosya paylaşım modelleri sunar. Windows istemcileri için SMB ACL davranışı, Unix istemcileri için UID/GID ve NFS sürümü önemlidir. Guest veya geniş export ayarı kimliği zayıflatabilir. Protokol seçimi yalnız hız testinden değil istemci, izin ve kilit gereksiniminden çıkarılmalıdır.
- 1İstemci ve kimlik
- 2SMB veya NFS
- 3Paylaşım + dosya izinleri
- 4Kilit ve restore testi
Tasarım parametreleri
- İzin katmanları
- Share izni, filesystem ACL, UID/GID ve güvenlik modülünü ayrı değerlendirin.
- Protokol ve kilitleme
- SMB/NFS sürümü, client desteği, kilit davranışı ve isim özelliklerini uygulamayla test edin.
- Servis ve kullanıcı
- Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
- Depolama ve kalıcılık
- Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
- Ağ ve güvenlik katmanı
- Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
- Paket ve işletim yöntemi
- Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.
Hesap ve uygulama örneği
Örnek pilotta iki kullanıcı ve bir yetkisiz hesapla okuma/yazma test edin. Aynı dosyanın eşzamanlı açılması, dosya kilidi, ACL korunması ve restore sonrası sahiplik doğrulanır. NFS’de farklı UID ile aynı kullanıcı adının aynı yetkiyi sağlayacağını varsaymayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Root okuyabiliyor, kullanıcı okuyamıyor | Dizin geçişi veya kimlik eşleştirmesi eksik olabilir. | Dosyaya kadar tüm dizin ACL’lerini gerçek kimlikle kontrol edin. |
| Servis aktif ama yanıt vermiyor | Process sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir. | Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin. |
| Dosya yazılamıyor | İzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir. | Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın. |
| Reboot sonrası yapılandırma kayboldu | Geçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir. | Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın. |
Kabul ve doğrulama kontrolleri
- İzinli/izinsiz erişimi paylaşım ve dosya sistemi katmanlarında ayrı doğrulayın.
- Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
- Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
- Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
- Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
- Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.
İlgili kavramlar
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.