RAID sonrası kullanılabilir depolama

01

Baytları, TB ve TiB'yi normalleştirin

Sürücü etiketleri ve Tungsto kataloğu ondalık birimler kullanır: bir TB, 1,000,000,000,000 bayttır. Bir TiB, 1,099,511,627,776 bayttır. Bu nedenle aynı bayt sayısı TiB cinsinden daha küçük bir sayı olarak görünür. Yuvarlanmış bir yüzdeyi tekrar tekrar uygulamak yerine kaynak baytlardan dönüştürün ve her çalışma sayfası sütununu birimiyle etiketleyin.

Örneğin, 12 × 16 TB katalog dizisi yedeklilikten önce 192 TB ham içerirken, 24 × 20 TB 480 TB ham içerir. Bu rakamlar ayrı NVMe önyükleme çiftini hariç tutar. Bunlar envanter gerçekleridir, dosya sistemi görünür veya yazılabilir kapasite iddiaları değildir.

02

Gerçek topolojiyi modelleyin, tek bir toplam satırı değil

Seçilen uygulama aksini belgelemediği sürece üyeler farklıysa en küçük katılımcı aygıt boyutunu kullanın; daha büyük kısımlar kullanılamaz kalabilir. Önyükleme, önbellek, günlük, yedek ve veri aygıtlarını ayırın. ZFS için her üst düzey vdev'i ve yedekliliğini tanımlayın. Veriler üst düzey vdev'ler arasında şeritlenir, bu nedenle yedeksiz bir vdev, aksi takdirde yansıtılmış bir havuzu o tek aygıta karşı savunmasız hale getirebilir.

Basit eşlik formülü, bir RAIDZ grubunu veri aygıtları çarpı aygıt boyutu olarak yaklaşık hesaplar, ancak gerçek tahsis kayıt boyutuna, sektör geometrisine ve eşlik davranışına bağlıdır. Bu nedenle OpenZFS, kullanılabilir havuz özelliğini kesin bir vaat değil, sezgisel bir değer olarak tanımlar.

• Havuz kapasitesi özelliklerini açZFS ↗

03

Kapasite şelalesi uygulayın

Ham baytlarla başlayın, yedekliliği ve özel sıcak yedekleri çıkarın, ardından oluşturulan dosya sistemi veya havuzun kendi kullanılabilir özelliğini okuyun. Bu sonuçtan, politika, anlık görüntüler, yazarken kopyalama davranışı, geçici çoğaltma veya geri yükleme çalışması ve uygulama büyümesi için gereken alanı ayırın. Sıkıştırma veya tekilleştirme tasarruflarını varsaymayın; her ikisi de veri ve yapılandırmaya bağlıdır ve muhafazakar bir tahminden kaybolabilir.

İki çıktı tutun: düzenleri karşılaştırmak için teorik kapasite ve veri kabul etmek için operasyonel kapasite. İkincisi, operatör tarafından seçilen bir uyarı eşiği ve bir kabul durdurma eşiği içermelidir. Son bildirilen bayta kadar dolan bir dosya sistemi, aritmetik başlangıçta doğru görünse bile bakım ve kurtarmayı engelleyebilir.

04

Veri taahhüt etmeden önce oluşturulan havuzu doğrulayın

Seçilen düzeni oluşturduktan sonra aygıt üyeliğini, yedekliliği, sağlığı ve uygulamanın bildirdiği kullanılabilir kapasiteyi kaydedin. ZFS üzerinde, kotalar, rezervasyonlar ve eşlik bunları farklılaştırabileceğinden havuz düzeyindeki tahminleri veri kümesi kullanılabilirliğinden ayırın. TrueNAS kapasite hesaplayıcı ZFS geometrisini planlamak için yararlıdır, ancak girdileri yine de gerçek sürücüler, ashift, kayıt boyutu, yedekler ve rezervasyon politikasıyla eşleşmelidir.

Üretimden önce bir kabul kaydı oluşturun: ham baytlar, yerleşim şeması, hesaplanan değer, raporlanan değer, yedek, anlık görüntü politikası ve yedekleme hedefi. Sayılar eşleşiyor gibi görünene kadar birimleri değiştirmek yerine açıklanamayan herhangi bir boşluğu araştırın.

05

Kapasiteyi ve kurtarmayı ayrı tutun

Daha büyük bir kullanılabilir rakam, daha güvenli bir tasarımı kanıtlamaz. Kapasite sonucunun yanında tolere edilen aygıt arızalarını, izlemeyi, yedek prosedürünü, temizleme veya tutarlılık kontrolü politikasını ve geri yükleme kaynağını belirtin. RAID ve ZFS yedekliliği tek bir kasa içinde kalır; silme, ele geçirme veya sunucu kaybına karşı koruma sağlamaz.

Beklenen sonuç, başka bir operatörün cihaz baytlarından ve topolojiden yeniden hesaplayabileceği tekrarlanabilir bir kapasite çalışma sayfasıdır. Kısa liste için hesaplayıcıyı kullanın, ardından uygulama kapasitesi sunmadan önce tahminini dağıtılan havuzdan gözlemlenen özelliklerle değiştirin.