JuiceFS, exabayt ölçekli yapay zeka eğitimi için kurumsal dosya sistemi metadata katmanını yeniden inşa etti

JuiceFS neyi değiştirdi

JuiceFS, petabayttan exabayta doğru ilerleyen yapay zeka eğitim ortamlarını hedefleyerek, cloud-native dosya sisteminin Enterprise Edition sürümünde kapsamlı bir yenileme gerçekleştirdi. dev.to'da yayımlanan bir mühendislik yazısına göre yeniden tasarım, yüz milyarlarca dosya barındıran dosya sistemleri ve binlerden milyonlara uzanabilecek istemci sayılarını hedefliyor. Şirket, bu ölçekte dört baskı noktası tespit ediyor: metadata motoru, veri yaşam döngüsü yönetimi, veri yolu ile istemci ve kontrol düzlemleri. Yazı, otonom sürüş şirketi Horizon Robotics'in JuiceFS Community Edition'ı exabayt ölçeğinde nasıl kullandığını anlatan önceki bir yazının ardından geldi.

Bellek merkezli bir metadata servisi

Yazıya göre yüz milyarlarca dosya düzeyinde metadata erişimi üç duvara çarpıyor: yoğun eğitim döneminde tek bir düğümü darboğaz haline getiren sıcak dizinler, işleri doğrudan yavaşlatan yol çözümleme ve dosya açma sırasında oluşan ek gidiş-dönüşler, ayrıca dev dizinlerin getirdiği ölçek yükü — yalnızca çöp kutusu on milyarlarca kayıt tutabiliyor — ve mount yapılandırması ile kapasite verileri gibi sürekli sorgulanan global durum.

Bunun yanıtı, özel olarak tasarlanmış bir metadata servisidir. Tüm çekirdek veri yapıları tek bir iş parçacığı tarafından yönetilir; şirket buna göre bu, işlemleri varsayılan olarak atomik kılar ve kilit çekişmesinden kaynaklanan gecikme artışlarını önler. Metadata tamamen bellekte tutulduğu için istekler diske hiç dokunmaz ve yüzlerce mikrosaniye içinde işlenir; replikasyon ve otomatik yük devri ise Raft tarafından yönetilir. Tek bir metadata süreci, 30 GiB bellek kullanarak yaklaşık 300 milyon dosyayı yönetir.

Bellek içi bir tasarım maliyeti doğrudan bellek kullanımına bağladığından JuiceFS, bellek havuzları, manuel bellek yönetimi, boştaki dizinlerin serileştirilip sıkıştırılması ve küçük dosyaların kompakt temsillerini uyguladı. Dosya başına ortalama bellek neredeyse 600 bayttan yaklaşık 100 bayta düştü — bu, HDFS NameNode'un dosya başına yaklaşık 370 baytının %27'sine ve yaklaşık 2.700 bayt olan CephFS MDS'nin %3,7'sine denk. Yazı ayrıca Alluxio'dan dosya başına yaklaşık 2.100 bayt ve JuiceFS Community Edition'dan yaklaşık 430 bayt rakamlarını veriyor.

Metadata bölgeleriyle yatay ölçekleme

Tek bir sürecin ötesinde Enterprise Edition, dosya ağacını istemcilerin tek bir namespace halinde birleştirdiği birden çok metadata bölgesine (zone) bölüyor. Alt ağaçlar mümkün olduğunca bütün tutuluyor; böylece işlemlerin çoğu tek bir bölge içinde kalıyor ve daha az dağıtık işlem gerekiyor. Bölgeler arası geçiş, POSIX yollarına şeffaf kalan bağlantı ve referanslarla yapılıyor; ayrıca aşırı büyük dizinler sanal alt dizinlere bölünebiliyor, böylece tek bir sıcak dizin tek bir bölgeyi kilitlemiyor. Bölge bilgisi her inode'un yüksek anlamlı bitlerine kodlanıyor ve istemciler topolojiyi kendileri keşfediyor, dolayısıyla yeni bölge eklemek için uygulamada değişiklik gerekmiyor. Her bölge üç örnek çalıştırıyor — servis, sıcak yedek ve soğuk yedek — servis ve sıcak yedek farklı bellek sıkıştırma stratejileri kullanırken, snapshotlar ve değişiklik günlükleri sürekli kalıcı hale getiriliyor ve uzaktan yedeklenebiliyor.

Sürüm kilometre taşları ve istemci fan-out

Yazı, sürümler boyunca ölçek kazanımlarını izliyor. v5.2 çok bölgeli kararlılık ve daha düşük bellek kullanımı getirdi; üretimdeki bir küme şu anda 50 milyardan fazla dosyayı milisaniye düzeyinde metadata erişim gecikmesiyle yönetiyor. v5.3 bölge üst sınırını 1.024'e çıkardı — tek bir dosya sisteminin 500 milyar dosyayı aşması için yeterli — ve sık erişilen dizinleri eşzamanlı taşınan daha küçük birimlere bölen otomatik hotspot geçişi ile bölgeler arası taşımaların bıraktğı ara durumları onaran periyodik özdenetimler ekledi. v5.4 ise istemci ölçeğine odaklandı: metadata düğümleri ve ağ proxy'leri birlikte dağıtılabilir, istemciler herhangi bir düğüme bağlanabilir ve diğer bölgelere yönelik istekler küme içinde iletilirken, bağlantı yeniden kullanımı bir milyona kadar istemci bağlantısını destekliyor.

Silme, kurtarma ve geri kazanım

Petabaytlarca veriyi silmek birinci sınıf bir iş akışı olarak ele alınıyor; çünkü geri kazanım yalnızca yer açmakla ilgili değil: sistem, yanlışlıkla silinmeden kurtarma, silme izlenebilirliği ve sahipsiz nesneler için denetimleri de desteklemeli. Çöp kutusu varsayılan olarak etkin ve yapılandırılabilir bir saklama süresiyle geliyor (genellikle yedi gün); bir dosyayı geri yüklemek yalnızca metadata'yı güncelliyor, veri kopyalanmıyor. v5.3'ten itibaren çok bölgeli çöp kutusu her dosyanın özgün yolunu kaydediyor, böylece geri yüklemeler doğru yere düşüyor; v5.4 ise silinen dosyaların zaman aralığına ve anahtar kelimeye göre filtrelenmesini ekliyor. Geri kazanım, birleşik bir arka plan görev çerçevesinde çalışıyor; metadata servisi chunk birleştirme, çöp kutusu temizliği ve bulutlar arası replikasyon gibi işleri planlıyor ve bunlar istemciler genelinde eşzamanlı yürütülüyor — yazıya göre böylece silme kapasitesi istemci sayısıyla birlikte büyüyor.

Neden önemli

Eğitim verimliliği, en yavaş metadata araması kadar hızlı olabilir ve yüz milyarlarca dosya düzeyinde dosya başına bellek ayak izi fiilen donanım maliyetini belirliyor: bunu yaklaşık 600 bayttan 100 bayta indirmek, kontrol düzlemi altyapısında bir büyüklük mertebesi azalma demek. Tasarım ayrıca yapay zeka çağı depolamanın yönünü de gösteriyor — POSIX uygulamalarına şeffaf kalan ölçeklenebilir metadata, bir milyon bağlantıya yaklaşan istemci fan-out'u ve çöp kutusu, kurtarma ile geri kazanım gibi yaşam döngüsü özelliklerinin sonradan eklenen katmanlar değil, dosya sisteminin içine gömülü olması.