Post-prodüksiyon stüdyosu için ZFS tabanlı ortak depolama

44 TB’lık bir render deposunun dataset düzeni, SMB paylaşımları, yetkilendirme tarafında sık karşılaşılan tuzaklar ve snapshot planı.

Render ve post-prodüksiyon yapan bir stüdyoda depolama, altyapının en görünmeyen ama en kritik parçası. Bu projede 44 TB'lık aktif bir veri havuzu TrueNAS üzerinde çalışıyor ve tüm ekip aynı depoya bağlı.

Havuz ve dataset düzeni

İki havuz var: biri üretim verisi için, biri sistem veri seti için. Üretim havuzu altında iş akışına göre ayrılmış dataset'ler bulunuyor:

• COMPOSITE
• KAPLAMA
• RENDER
• TASARIM
• Texture_Cache
• YAYIN

Her aşamayı ayrı dataset yapmanın sebebi sadece düzen değil. ZFS'te sıkıştırma, snapshot sıklığı, kayıt boyutu ve kota ayarları dataset seviyesinde tanımlanıyor. Texture cache'i günlük snapshot almaya değmez, YAYIN klasörü ise en sık yedeklenmesi gereken yer. Hepsini tek klasör altında tutarsanız bu ayrımı yapamazsınız.

Kullanıcılar paylaşımlara Windows tarafında sürücü harfi eşlemesiyle erişiyor. Bu, kullanıcı tarafında hiçbir alışkanlık değişikliği gerektirmiyor.

Yetkilendirme: en sık takılınan yer

ZFS ve SMB birlikte çalıştığında sorunların büyük çoğunluğu depolamadan değil yetkilendirmeden çıkıyor. Bu sistemde de karşılaştığımız klasik bir durum vardı: bir klasör "sahipsiz" kalmıştı ve Windows tarafından hiçbir kullanıcı tarafından silinemiyordu.

Kök neden genellikle şudur. Sistem bir Active Directory alanına bağlıysa ve bağlantı koparsa ya da bir kullanıcı alandan silinirse, klasördeki ACL kaydındaki SID artık çözümlenemiyor. ls -l çıktısında kullanıcı adı yerine sayısal bir kimlik görünüyor ve silme yetkisi hiç kimsede kalmıyor.

Teşhis için baktığımız yerler:

midclt call activedirectory.get_state
ls -lan /mnt/havuz/yol
getfacl /mnt/havuz/yol

AD durumu DISABLED veya FAULTED görünüyorsa ve klasörün sahibi yüksek bir sayısal kimlikse teşhis kesinleşiyor. Müdahale SMB üzerinden değil, TrueNAS kabuğundan root yetkisiyle yapılıyor: sahiplik root'a alınıyor, ACL kayıtları temizleniyor, değişmezlik bayrakları kaldırılıyor.

İkinci ihtimal, uzun süredir açık olan sistemde SMB tarafında takılı kalmış bir oturum. smbstatus çıktısında açık kilit varsa Samba servisinin yeniden başlatılması yetiyor.

Üçüncü ihtimal ise silinmeye çalışılan şeyin klasör değil dataset olması. zfs list -r çıktısında görünüyorsa rm ile değil zfs destroy ile gider.

Arayüz tarafında kalıcı çözüm, ilgili dataset'in izinlerini ACL editöründen düzeltmek: sahip ve grup ayarlandıktan sonra "recursive" seçenekleriyle alt klasörlere uygulanıyor.

Snapshot ve yedekleme planı

Ortak depolamada asıl risk disk arızası değil, kullanıcı hatası. Yanlışlıkla silinen bir sahne klasörü, bozulan bir proje dosyası, üzerine yazılan bir render çıktısı. RAID bunların hiçbirine karşı korumaz.

Bu yüzden dataset bazlı snapshot planı kuruyoruz. Aktif çalışılan dataset'lerde sık ve kısa saklamalı, teslim edilen işlerin bulunduğu dataset'lerde daha seyrek ve uzun saklamalı.

Yedekleme kopyalarını mesai dışına, gece saatlerine zamanlıyoruz. Render çiftliği zaten geceleri çalıştığı için pencereyi ona göre seçmek gerekiyor; depolamayı aynı anda hem yedekleme hem render okumasıyla meşgul etmek iki işi de yavaşlatır.

Kurulum sırasında karar verilmesi gereken şeyler

Ortak depolama kurgularken erken cevaplanması gereken sorular:

Kaç kullanıcı aynı anda okuma yapacak, tepe yükte ne kadar bant genişliği gerekiyor. Dosyalar büyük mü küçük mü, kayıt boyutu buna göre ayarlanıyor. Alan yönetimi olacak mı, olacaksa yetkilendirme baştan ona göre kurulmalı. Yedek nereye gidecek, ikinci bir cihaza mı yoksa aynı cihazın başka havuzuna mı. Kapasite dolduğunda genişleme nasıl yapılacak.

Bu soruları kurulumdan sonra cevaplamak, çoğu zaman baştan kurmak anlamına geliyor.