{
“title”: “ZFS ile Linux Sunucularda Performans ve Dayanıklılık: ARC, ZIL, SLOG, Snapshot ve send/receive Nasıl Tatlı Tatlı Ayarlanır?”,
“content”: “n
Hiç, gece geç saatte ofiste tek başına kalıp disk ışıklarının ritmini dinlediniz mi? Ben kaldım. O gün bir VM bir türlü ayağa kalkmıyor, I/O gecikmeleri dalgalanıyor, grafikte dikenler çıkıyor, CPU boşta ama kullanıcılar homurdanıyordu. Bende şu his uyandı: “Bu iş diskte bitiyor, ZFS’i biraz daha yakından dinlemeliyim.” ZFS’in büyüsü o akşam açıldı diyebilirim. ARC’nin belleği nasıl sevdiğini, ZIL’in senkron yazılardaki gizli rolünü, SLOG’un doğru donanımla nasıl fark yarattığını adım adım gördüm.
n
Şöyle düşünün: Sunucunuz küçük bir şehir, veri ise o şehrin trafiği. ARC geniş bir çevre yolu, ZIL ışıkların senkronizasyonu, SLOG ise kavşaktaki akıllı sistem. Yanlış ayarlarla trafik sıkışır; doğru ayarlarla akış pürüzsüzleşir. Bu yazıda hikâyenin içinden gidip ZFS’i sahada nasıl ayarladığımı, hangi ayarın hangi durumda nefes aldırdığını, snapshot ve send/receive ile yedekleri nasıl güvenle dışarı taşıdığımı anlatacağım. Bazı yerlerde “mesela şöyle” diye durup sade örnekler vereceğim. Kendi deneyimimden, hatalarımdan ve “ah keşke” dedirten anlardan söz edeceğim.
n
Hedef basit: Linux üzerinde ZFS ile hem performansı toparlamak hem de dayanıklılığı artırmak. ARC/ZIL/SLOG ayarlarıyla başlıyoruz, ardından dataset ufak dokunuşları, en sonda snapshot ve send/receive ile yedeklerin akışını kuruyoruz. Yol boyunca kısa notlar, küçük tüyolar, gereksiz risklerden kaçınma taktikleri… Hadi başlayalım.
nn
ZFS’i Kafada Oturtmak: ARC, ZIL ve SLOG Ne İşe Yarar?
n
ZFS’i sevdim çünkü düşünce biçimi net. Önce belleği iyi kullanıyor. ARC dediğimiz önbellek RAM’de yaşar ve sık okunan veriyi elde tutar. Mesela bir web sunucunuz var, sürekli aynı statik dosyalar isteniyor. ARC bu dosyaları RAM’de sıcak tutarak diske inmeyi azaltır. En bariz hissi: Okuma gecikmeleri düşer ve sistem daha esnek hale gelir. “Daha çok RAM, daha mutlu ARC” gibi düşünebilirsiniz ama fazlası her zaman iyi değildir; birazdan nedenini konuşacağız.
n
Sonra ZIL var: ZFS Intent Log. Senkron yazıların güvenliğini sağlar. Düşünün, veritabanı bir yazıyı “tamamlandı” demeden önce disk üzerinde garantilemek ister. ZIL bu noktada devreye girer. Peki SLOG nedir? ZIL’i hızlandırmak için ayırdığınız özel bir cihaz. Aslında ZIL her zaman vardır; SLOG ise onu ayrı ve hızlı bir yere almak demek. Eğer senkron yazılar yoğun değilse SLOG takmak şart değil. Ama NFS sunucusu, veritabanı veya VM diskleri gibi “fsync” seven iş yüklerinde SLOG, geceyle gündüz arasındaki farkı yaratır. Küçük bir uyarı: SLOG için seçtiğiniz SSD’nin elektrik kesintisinde veri koruması olmalı, yani güç kaybı korumalı bir model. Yoksa hızlanayım derken risk alırsınız.
n
Bu üçlüyü akılda şöyle canlandırın: ARC okuma hızını yükseltir; ZIL güvenliği sağlar, SLOG ise ZIL’i hızlandırır. Hepsi aynı anda sahnede değildir; iş yükünüz hangisine ihtiyaç duyuyorsa onu öne çeker. Bir gecelik performans düğününde DJ’yi doğru seçmek gibi.
nn
ARC Tuning: RAM’i Sevdiren Ayarlar, Abartmadan
n
Bir keresinde sunucuda hem veritabanı hem de çok sayıda PHP-FPM süreci vardı. RAM boldu ama hepsini ARC’ye bırakınca diğer süreçler nefes alamadı. Ders basit: ARC güçlüdür, evet, ama evde tek o yaşamaz. ZFS’in Linux tarafında zfs_arc_max ile ARC’nin tavanını, zfs_arc_min ile tabanını ayarlayabilirsiniz. Amacınız, iş yükünüzün geri kalanıyla kavga etmeyen bir denge kurmak. Mesela toplam RAM’in makul bir bölümünü ARC’ye ayırıp diğer servisler için alan bırakmak çoğu zaman doğru adım olur.
n
Ayarlama işi genellikle modül parametreleriyle yapılır. Kalıcı bir düzenleme için şuna benzer bir dosya oluşturabilirsiniz:
n
# /etc/modprobe.d/zfs.confnoptions zfs zfs_arc_max=8589934592noptions zfs zfs_arc_min=2147483648nn
Buradaki değerler bayt cinsinden. Sistem yeniden yüklendiğinde devreye girer. Geçici testler için sysfs üzerinden denemek mümkün, ama kalıcı düzen iyidir. Ayarı yapınca “oh tamam” demeyin; gözlemleyin. zpool iostat, arcstat ve sistem genel bellek kullanımını takip edin. ARC’nin çok büyüyüp sistemin swap’e düşmesine izin vermeyin. Bir iki gün akışa bakın, sonra ufak dokunuşlarla ayarı yerine oturtun.
n
ARC’ye eşlik eden başka ince ayarlar da var. primarycache ve secondarycache mesela. Bir VM imajlarını dosya olarak tuttuğunuz dataset’te primarycache=metadata seçerek RAM’i biraz ferahlatabilirsiniz. Okumaların çoğu rastgele ve büyük değilse, tüm veriyi önbelleğe almanın faydası sınırlı olur. Metadata’yı sıcak tutmak, verinin akışını yeterince hızlandırabilir. Öte yandan, sık okunan statik dosyalar için primarycache=all oldukça mantıklıdır. İş yükünü gözlemleyerek karar verin.
n
Bir diğer faydalı dokunuş sık erişilen dataset’lerde compression=lz4 kullanmaktır. LZ4 hem hızlı hem de nefes aldırır. Daha az veri, daha az disk işi demektir. Kazanılan alan kadar I/O da azalır ve ARC daha verimli çalışır. Her yerde değil, ama çoğu dosya için güvenli bir kazanım sağlar. Mesela log dosyaları, yapı çıktıları, metin içerikler. Medya dosyalarında az fark edilebilir ama zarar vermez.
nn
ZIL ve SLOG: Senkron Yazıların İnce Hesabı
n
Bir gün bir NFS sunucusunu devraldım. Kullanıcılar “dosyayı kaydediyorum ama anlık duraksama var” diyordu. Kontrol ettim, iş yükü bolca senkron yazı üretiyordu. ZIL zaten işini yapıyordu ama sistem diskleri bu yoğunluğu kaldıramıyordu. Çözüm olarak SLOG ekledik. Güç kaybı korumalı bir NVMe aldık, küçük bir dilimi ZIL için ayırdık. Sonuç belirgindi: o küçük duraksamalar yok oldu, akış pürüzsüzleşti.
n
Bu noktada iki ayarı hatırlayın: logbias ve sync. logbias=latency senkron yazılara öncelik verir, “gecikmeme” odaklıdır. Büyük ardışık yazılarda ise logbias=throughput farklı davranır, bu da bazı yedekleme işlerinde işinize yarar. sync=disabled seçeneğini duydunuz mu? Hız verir ancak riski büyüktür. Elektrik kesildiğinde veya sistem çöktüğünde son yazıların garanti altında olmaması kabul edilebilir bir şey değilse, bunu kaçının. Test ortamında belki, üretimde asla. Güvenli bir yol: sync=standard ile akışı korumak ve gerekliyse SLOG ile hızlandırmak.
n
SLOG eklemek kolaydır. Aynı anda verinizi riske atmamak için SLOG’u mümkünse yansılı (mirror) kurun. Basit bir örnek:
n
# SLOG olarak iki NVMe'yi ayna şeklinde eklemeknzpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1nn# Dataset bazında logbias ayarı nzfs set logbias=latency tank/nfsnn
SLOG cihazı küçük tutulabilir; ZIL, sonradan veriyi asıl pool’a yazar. Fakat cihaz seçimi önemlidir, çünkü bu yazılar çok küçük ve sık aralıklıdır. Güç kaybı korumalı, düşük gecikmeli bir cihaz arayın. Bu konularda sahada çok kafa yormuş kişilerin notlarını okumak isterseniz ZFS Evil Tuning Guide güzel bir perspektif sunar. Sakin ve temkinli ilerlemek, “hadi bir de bunu açalım” heyecanına kapılmamak, ZFS ile uzun vadede daha sağlıklıdır.
nn
Dataset Dokunuşları: recordsize, volblocksize, ashift, atime ve Küçük Sırlar
n
Performansın büyük kısmını küçük ayarlar belirler. Bir dosya sistemi dataset’lerle konuşur; her dataset’in yapısı iş yüküne göre biçimlenebilir. Mesela veritabanı dosyaları. Genelde daha küçük bloklar severler. Postgres için 8K-16K aralığı kulağa tanıdık gelir. Büyük medya dosyaları ise büyük blokları sever; 1M gibi değerler hoşlarına gider. Bu blok ayarını dosya tabanlı depoda recordsize ile yaparsınız. Örnek:
n
# Veritabanı dataset'i için daha küçük recordsizenzfs set recordsize=16K tank/dbnn# Medya arşivi için büyük recordsizenzfs set recordsize=1M tank/mediann
VM diskleri için iki yol var. Dosya olarak tutuyorsanız recordsize ile oynarsınız; zvol olarak blok aygıtı şeklinde veriyorsanız volblocksize devreye girer. Bu ayarı sonradan değiştirmek zahmetlidir; baştan planlamak daha iyi. Blok boyutu disk imajının erişim desenine yakın olmalı. Rastgele küçük yazı ağırlıklı VM’lerde gereksiz büyük bloklar “yaz-kopyala” yükü yaratır. Ölçün, deneyin ve ufak adımlarla ilerleyin.
n
Bir de ashift var. Pool kurulurken disklerin fiziksel sektör boyutuna göre seçilir. Modern disklerde genelde 4K sektör kullanılır ve ashift 12 (2^12=4096) güvenli bir tercih olur. Bunu sonradan değiştirmek kolay değildir, bu yüzden havuza başlarken doğru ayarı seçmek önemlidir. Yanlış ashift gereğinden fazla yazma işi doğurur, performans düşer, SSD ömrü de gereksiz tüketilir.
n
Küçük ama etkili iki dokunuş daha: atime ve xattr. atime, dosyaya her erişimde zaman damgası günceller. Eğer bu bilgiye ihtiyacınız yoksa atime=off demek disk üzerindeki küçük yazıları azaltır. Gerekliyse relatime da bir denge seçeneği sunar. xattr için xattr=sa bazı iş yüklerinde hız kazandırır, çünkü genişletilmiş öznitelikleri ayrı bir yerde değil verinin içinde saklar. Kullandığınız dağıtıma ve çekirdek versiyonuna göre davranış değişebilir; ufak bir test iyi gider.
n
Disk yaşam döngüsü için autotrim=on havuza nefes aldırır. SSD’lerin çöp toplama düzeni TRIM ile daha rahat çalışır. Aynı şekilde, compression=lz4 genelde varsayılan olmalı. Daha agresif sıkıştırmalar bazı işlerde faydalı görünse de CPU yükü ve gecikmeyi düşünmek gerekir. LZ4, “az risk, sık sık kazanç” çizgisini güzel tutar.
nn
Snapshot ve send/receive: Zamanı Durdurup Güvenle Taşımak
n
Bir sistemi rahat uyutan şey nedir biliyor musunuz? Yedeklerin düzenli ve geri döndürülebilir olması. Snapshot tam burada gülümser. ZFS snapshot’ları anlık bir fotoğraf gibi. Yaratması hızlı, etkisi sihirli. Asıl güzellik, bu snapshot’lardan zfs send ile akış üretip başka yere zfs receive ile taşıyabilmeniz. İlk akış tamdır, sonrakiler incremental, yani değişen bloklar kadardır. Bu sayede bant genişliği ve süre makul kalır.
n
Basit bir akış örneği verelim. Diyelim tank/prod dataset’inde her saat snapshot alıyorsunuz ve başka bir sunucuya aktarmak istiyorsunuz:
n
# Snapshot isimleri için bir şablon yakışırnzfs snapshot tank/prod@hourly-2025-11-16-10nn# İlk tam gönderimnzfs send tank/prod@hourly-2025-11-16-10 | ssh backup "zfs receive backup/prod"nn# Bir sonraki snapshot'tan sadece farkı yollamaknzfs send -i tank/prod@hourly-2025-11-16-10 tank/prod@hourly-2025-11-16-11 | \n ssh backup "zfs receive backup/prod"nn
Naming önemlidir. Tarih ve periyot bilgisini eklemek hem listeyi okunur kılar hem de silme politikası yürütmeyi kolaylaştırır. Snapshot silmek, referansı kaldırmak gibidir; veri, başka bir snapshot tarafından tutulmuyorsa alan geri kazanılır. “Snapshot diskimi şişirir mi?” sorusunun cevabı iş yüküne bağlıdır. Çok değişiklik yaparsanız, evet, alışılmıştan daha fazla yer tutar. Ama aynı zamanda geri dönüşün sigortasıdır. Bu yüzden akıllı bir tutma politikası şart. Günlükler için birkaç saatlik, gün sonu için birkaç günlük, haftalık ve aylık gibi katmanlı bir yaklaşım pratik olur.
n
ZFS’in şık tarafı, yeniden başlatmaya rağmen devam edebilen send akışları için resume token desteği sunmasıdır. Bir kopyalama yarıda kesilirse, token’ı alıp kaldığınız yerden devam etmek mümkün. Şifreli dataset’lerde ham gönderim (zfs send -w) ile içeriği ham haliyle aktarmak, uzak tarafta çözümlenmesini sağlamak da hoş bir güvenlik özelliğidir.
n
Otomasyon için çok pratik araçlar var. Örneğin Sanoid ve Syncoid ile otomatik snapshot ve replikasyon kurmak dakikalar alır. Snapshot verme, tutma, uzak kopya oluşturma ve silme politikalarını insan hatasına bırakmadan yürütür. Ben genelde Sanoid ile yerel snapshotları, Syncoid ile uzak sunucuya akışı yönetiyorum. Logları takip edip ufak aksaklıklarda e-posta atmasını sağlamak güzel bir güven duygusu veriyor.
n
Uzak kopyayı yalnızca başka bir ZFS havuzuna almak zorunda değilsiniz. Bazen işinize, “arşiv” olarak zfs send akışını dosyaya alıp nesne depoya yüklemek yarar. Bu noktada, S3 uyumlu bir depoya taşımak isterseniz, kendi altyapınızda S3 kurmanın bir yolu da var. Benim adım adım anlattığım VPS üzerinde MinIO ile S3‑uyumlu depolama kurma rehberi tam bu noktada elinizi güçlendirebilir. Böylece “offsite” kopyaları kendi kontrolünüzde, uygun maliyetle ve otomasyonla yönetebilirsiniz.
nn
Gerçek Bir Senaryo: Küçük Bir Hosting Sunucusunda Büyük Fark
n
Bir müşteride, tek bir fiziksel sunucu üzerinde birkaç VM ve bir veritabanı hizmeti çalışıyordu. Şikâyet basitti: “Bazı saatlerde sistem takılıyor, sonra akıyor.” İlk bakışta CPU ve RAM boldu. ZFS ise varsayılan ayarlardaydı. Önce ARC’yi kısmen dizginledik; toplam RAM’in büyük kısmını ARC’ye bırakmak yerine güvenli bir tavan belirledik. VM imajlarını taşıyan dataset’te primarycache=metadata yaptık. Random okumalarda ARC’yi zorlamayıp meta veride fayda gördük. Veritabanına bakan dataset’te recordsize=16K ve compression=lz4 ile küçük blok ve hafif sıkıştırma ikilisini kullandık.
n
Şikâyetin ikinci bacağı senkron yazılardı. NFS ve veritabanı birlikte, “kırpık” yazı fırtınası yaratıyordu. SLOG için güç kaybı korumalı bir NVMe ekledik, yansılı kurduk, dataset’lerde logbias=latency seçtik. sync=disabled tuzağına düşmedik; hız pahasına güvenlikten vazgeçmeyi istemedik. SLOG’dan sonra küçük dalgalanmalar göze görünmez hale geldi. Kullanıcı tarafında hissedilen şey “akışkanlık” oldu.
n
Yedek tarafında, saatlik snapshot ve günlük replikasyon kurduk. İlk gün tam gönderim uzun sürdü ama sonraki günlerde fark akışları hızlıydı. Öncesinde “yedek tamam” demek içime sinmiyordu. Sonrasında, “bir şey olursa şu sürüme döneriz” diyebildik. Haftalık bakımda zpool scrub çalıştırdık; sessiz veri çürümesine karşı düzenli bir kontrol gibi düşünün. Ayda bir rapor oluşturduk, “şu snapshotlar silindi, şu kadar alan geri kazanıldı” diye. Küçük adımlar, büyük rahatlıklar.
nn
İzleme, Temizlik ve Sakinlik: ZFS’te Günlük Hayat
n
Performans ayarları kadar, izleme ve temizlik ritmi de önemlidir. Ben genelde aşağıdaki komutlarla nabız tutarım:
n
# Havuzun sağlığınzpool status -vnn# I/O deseni ve gecikmelernzpool iostat -v 1nn# ARC davranışı (arcstat.py varsa tadından yenmez)narcstat 1nn# Dataset özelliklerini görmeknzfs get all tank/datasetnn
Havuzda scrub rutini, ayın belli bir gününde otomatiğe bağlanır. Yük düşükken yapmak iyidir. SSD havuzlarında autotrim=on tutmak genellikle fayda sağlar. Snapshot tutma politikası da mevsimlik değil, günlük bir pratik olmalı. “Kaç tane snapshot tutalım?” sorusunun cevabı değişir; değişim hızı yüksek dataset’lerde daha sık ama kısa süreli, arşiv dataset’lerinde daha seyrek ama uzun süreli tutmak mantıklı olur.
n
Performans sorunlarında ben önce “iş yükü ne istiyor?” diye sorarım. Rastgele mi yazıyor, ardışık mı? Senkron mu istiyor, yoksa asenkron akışa razı mı? Bu sorulara verdiğiniz cevaplar ayarları belirler. logbias, recordsize/volblocksize, primarycache üçlüsü ile ufak oynamalar çoğu zaman ağır sihirlerden daha etkili olur. Zaten ZFS’in güzelliği burada. Bütün sistemi alt üst etmeden, dataset seviyesinde hedefli iyileştirme yapabilmek.
n
Daha teknik detaylara meraklıysanız, resmi belge tadında anlatımlara bakmak iyi gelir. Ben çoğu zaman OpenZFS performans ve tuning kılavuzu ile başlar, sonra sahadaki notlar için tekrar ZFS Evil Tuning Guide’a göz atarım. Bir de snapshot/replication otomasyonu için arada Sanoid/Syncoid notlarını yenilerim. Hepsi aynı ezgiyi çalar: ölç, küçük adımlarla değiştir, tekrar ölç.
nn
Kapanış: Ayar Değil, Alışkanlık Kurtarır
n
Bu yazıyı yazarken dönüp o geceye baktım. Disk ışığına bakarken hissettiğim şey şuymuş: ZFS bir teknoloji değil, bir alışkanlıklar bütünü. ARC’yi şımartmadan, ZIL/SLOG dengesini iş yüküne göre kurarak, dataset’lerde ufak ama bilinçli dokunuşlarla, snapshot ve send/receive’i gündelik rutinin parçası yapmak… Teker teker küçük hamleler. Sonunda sistem bir anda “düzelmiş” gibi görünür. Oysa sihir, her gün bir damla oksijen vermektedir.
n
Eğer bugün bir yerden başlamak isterseniz, üç adım öneririm. Birincisi, ARC için makul bir tavan belirleyin ve bir hafta gözlem yapın. İkincisi, iş yüküne göre recordsize/volblocksize ve compression=lz4 ayarlarını sade sade oturtun. Üçüncüsü, snapshot ve incremental send ile uzak kopyayı kurun; haftalık bir scrub ekleyin. Hepsi bu. Zamanla neyin size iyi geldiğini sistem söyleyecek.
n
Umarım bu yazı elinizi rahatlattı. ZFS, doğru yaklaşımla hem hız hem güven verir. Takıldığınız bir nokta olursa, “şu iş yükünde şu ayar nasıl durur?” diye yorumlayın; ölçmeden değiştirip sonra tekrar ölçün. Bir dahaki yazıda, isterseniz daha ileri konulara, mesela native encryption ve ham gönderim stratejilerine dalarız. Şimdilik hoşça kalın; o disk ışığı artık daha sakin yanıp sönsün.
“,
“focus_keyword”: “ZFS performans ve dayanıklılık”,
“meta_description”: “ZFS ile Linux sunucularda performans ve dayanıklılığı artırmak için ARC/ZIL/SLOG tuning, recordsize ayarları ve snapshot ile send/receive yedekleri.”,
“faqs”: [
{
“question”: “SLOG şart mı? Hangi durumda gerçek fayda sağlar?”,
“answer”: “Her zaman şart değil. Senkron yazı ağırlıklı işlerde, örneğin NFS, veritabanı veya VM disklerinde belirgin fark yaratır. Güç kaybı korumalı, düşük gecikmeli bir SSD seçip mümkünse yansılı kurarsan hem hız hem güven kazanırsın.”
},
{
“question”: “Snapshot çok yer kaplar mı? Sunucuyu yavaşlatır mı?”,
“answer”: “Snapshot ilk anda yer kaplamaz; değişen bloklar arttıkça büyür. Çok değişen dataset’lerde daha hızlı büyür, bu normal. Uygun bir tutma politikasıyla (saatlik, günlük, haftalık) alanı kontrol edebilirsin. Performansı doğrudan yavaşlatmaz; asıl etkisi depolanan değişiklik miktarıyla ilgilidir.”
},
{
“question”: “ARC için ne kadar RAM ayırmalıyım?”,
“answer”: “Kesin bir sayı yok; iş yüküne göre denge kurmalısın. Diğer servislerin rahat çalışacağı payı bırakıp ARC için makul bir tavan belirle, sonra birkaç gün izleyip düzelt. Aşırı büyük ARC, sistemin swap’e düşmesine yol açarsa kazanım hızla kaybolur.”
}
]
}
