Fio ve vbd hakkında kısa bir hikaye
Küme performansı büyük ölçüde depolamanın performansına bağlıdır. vbd bazı metrikleri dışa aktarır İhtiyacınız olan depolama performansı bilgilerini sağlamak için. Örneğin, wal_fsync_duration_seconds metriği. : Depolamanın yeterince hızlı sayılması için bu ölçümün 99. yüzdelik diliminin 10 ms'den az olması gerekir. Linux makinelerde bir etcd kümesi çalıştırmayı planlıyorsanız ve depolama alanınızın (SSD gibi) yeterince hızlı olup olmadığını değerlendirmek istiyorsanız, kullanabilirsiniz. G/Ç işlemlerini test etmek için popüler bir araçtır. Test-data'nın depolama bağlama noktasının altındaki dizin olduğu aşağıdaki komutu çalıştırın:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestSadece sonuçlara bakmanız ve sürenin 99. yüzdelik diliminde olup olmadığını kontrol etmeniz yeterlidir. 10 ms'den az. Cevabınız evet ise, yeterince hızlı depolama alanınız var. İşte sonuçların bir örneği:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]Notlar
- Özel senaryomuz için -size ve -bs parametrelerinin değerlerini özelleştirdik. Fio'dan faydalı sonuçlar almak için değerlerinizi girin. Onları nereden alabilirim? Okumak, .
- Test sırasında tüm G/Ç yükü fio'dan gelir. Gerçek hayattaki bir senaryoda, depolama alanına wal_fsync_duration_seconds ile ilişkili olanlardan başka yazma istekleri gelmesi muhtemeldir. Ek yük, wal_fsync_duration_seconds değerini artıracaktır. Yani eğer 99. yüzdelik dilim neredeyse 10ms ise depolama alanınız yeterince hızlı değil demektir.
- Sürümü al 3.5'dan düşük değil (öncekiler fdatasync süre yüzdelik dilimlerini göstermez).
- Yukarıda fio'dan elde edilen sonuçların sadece bir kısmı var.
Fio ve vbd hakkında uzun hikaye
vbd'de WAL nedir
Genellikle veritabanları kullanılır ; vbd de bunu kullanıyor. Yazma öncesi günlüğünü (WAL) burada ayrıntılı olarak tartışmayacağız. Etcd kümesinin her üyesinin onu kalıcı depolamada tuttuğunu bilmek bizim için yeterlidir. etcd, anahtar/değer çiftleri üzerindeki her işlemi (güncelleme gibi) mağazaya uygulamadan önce WAL'a yazar. Depolama üyelerinden biri anlık görüntüler arasında çökerse ve yeniden başlarsa, WAL içeriğini kullanarak son anlık görüntüdeki işlemleri yerel olarak geri yükleyebilir.
Bir istemci anahtar/değer deposuna bir anahtar eklediğinde veya mevcut bir anahtarın değerini güncellediğinde, etcd bu işlemin kaydını kalıcı depolamadaki normal bir dosya olan WAL'a yazar. vbd, işleme devam etmeden önce WAL yazma işleminin gerçekten gerçekleştiğinden tamamen emin OLMALIDIR. Linux'ta bunun için bir sistem çağrısı yeterli değil , çünkü aslında fiziksel depolamaya yazma işlemi gecikebilir. Örneğin Linux, bir WAL girişini geçici olarak çekirdek belleğindeki bir önbellekte (sayfa önbelleği gibi) saklayabilir. Verilerin kalıcı depolamaya doğru bir şekilde yazılması için kayıt sonrasında fdatasync sistem çağrısına ihtiyaç duyulur ve etcd sadece bunu kullanır (çalışma sonucunda görülebileceği gibi) , burada 8 bir WAL dosya tanımlayıcısıdır):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Ne yazık ki, kalıcı depolamaya yazma anlık bir işlem değildir. Fdatasync çağrısı yavaşsa, etcd sistem performansı düşecektir. fdatasync çağrılarının 99'uncu yüzdelik diliminin WAL dosyasına yazılması 10 ms'den az sürüyorsa depolamanın yeterince hızlı olduğu kabul edilir. Başka yararlı depolama ölçümleri de var, ancak bu yazıda bahsettiğimiz tek ölçüm bu.
Fio kullanarak depolama değerlendirmesi
Depolamanızın etcd için uygun olup olmadığını değerlendirmeniz gerekiyorsa, çok popüler bir I/O yük test aracı olan fio'yu kullanın. Disk işlemlerinin çok farklı olabileceği unutulmamalıdır: eşzamanlı ve eşzamansız, birçok sistem çağrısı sınıfı vb. Sonuç olarak fio'nun kullanımı oldukça zordur. Birçok parametresi vardır ve bunların değerlerinin farklı kombinasyonları, çok farklı G/Ç iş yükleri üretir. Etcd için yeterli sayıları elde etmek amacıyla, WAL dosyalarını yazarken fio'dan gelen test yazma yükünün, etcd'den gelen gerçek yüke mümkün olduğunca yakın olmasını sağlamalısınız.
Bu nedenle, fio'nun en azından dosyaya bir dizi ardışık yazma yükü oluşturması gerekir; her yazma bir sistem çağrısından oluşur. ardından fdatasync sistem çağrısı gelir. Sıralı fio yazma işlemleri için --rw=write seçeneği gereklidir. Böylece fio yazarken sistem çağrısını kullanmak yerine yazma sistem çağrısını kullanır. –ioengine=sync parametresini belirtmeye değer. Son olarak, her yazmadan sonra fdatasync'i çağırmak için --fdatasync=1 seçeneğini eklemeniz gerekir. Bu örnekteki diğer iki seçenek (--size ve -bs) senaryoya özeldir. Bir sonraki bölümde size bunları nasıl kuracağınızı göstereceğiz.
Neden fio ve onu yapılandırmayı nasıl öğrendik?
Bu yazımızda gerçek bir vakayı anlatacağız. Bir kümemiz vardı v1.13'ü Prometheus kullanarak izledik. etcd v3.2.24 bir SSD'de barındırılıyordu. Etcd ölçümleri, küme hiçbir şey yapmadığında bile fdatasync için çok yüksek gecikme süresi gösterdi. Ölçüler tuhaftı ve ne anlama geldiklerini gerçekten bilmiyorduk. Küme sanal makinelerden oluşuyordu, sorunun ne olduğunu anlamak gerekiyordu: fiziksel SSD'lerde mi yoksa sanallaştırma katmanında mı? Ayrıca donanım ve yazılım konfigürasyonlarında sık sık değişiklikler yapıyorduk ve bunların sonuçlarını değerlendirebileceğimiz bir yola ihtiyacımız vardı. Her konfigürasyonda etcd'yi çalıştırabilir ve Prometheus metriklerine bakabiliriz, ancak bu çok zahmetlidir. Belirli bir konfigürasyonu değerlendirmenin oldukça basit bir yolunu arıyorduk. Etcd'nin Prometheus metriklerini doğru anlayıp anlamadığımızı kontrol etmek istedik.
Ancak bunun için iki sorunu çözmek gerekiyordu. Öncelikle, etcd'nin WAL'a yazarken oluşturduğu G/Ç yükü nedir? Hangi sistem çağrıları kullanılıyor? Gönderilerin boyutu nedir? İkinci olarak bu sorulara cevap verirsek fio ile benzer bir iş yükünü nasıl yeniden üretebiliriz? Fio'nun birçok seçeneğe sahip çok esnek bir araç olduğunu unutmayın. Her iki sorunu da tek bir yaklaşımla, komutları kullanarak çözdük и . lsof, bir işlem tarafından kullanılan tüm dosya tanımlayıcılarını ve bunlarla ilişkili dosyaları görüntüler. Strace ile halihazırda çalışan bir süreci inceleyebilir veya bir süreci başlatıp onu inceleyebilirsiniz. strace, incelenen süreçten (ve onun alt süreçlerinden) gelen tüm sistem çağrılarını yazdırır. İkincisi oldukça önemlidir, çünkü etcd de benzer bir yaklaşım benimser.
Yaptığımız ilk şey, kümede yük olmadığında Kubernetes için etcd sunucusunu incelemek için strace kullanmaktı. Hemen hemen tüm WAL kayıtlarının yaklaşık olarak aynı boyutta olduğunu gördük: 2200–2400 bayt. Bu nedenle yazının başındaki komutta -bs=2300 parametresini belirttik (bs, her fio girişi için bayt cinsinden boyut anlamına gelir). Etcd girişinin boyutunun, etcd sürümüne, nakliyeye, parametre değerlerine vb. bağlı olduğunu ve fdatasync süresini etkilediğini unutmayın. Benzer bir senaryonuz varsa, tam sayıları bulmak için strace kullanarak etcd süreçlerinizi inceleyin.
Daha sonra, etcd dosya sisteminin ne yaptığına dair iyi bir fikir edinmek için onu strace ve -ffttT seçenekleriyle çalıştırdık. Bu yüzden alt süreçleri inceleyip her birinin çıktısını ayrı bir dosyaya kaydetmeye ve ayrıca her sistem çağrısının başlangıcı ve süresi hakkında ayrıntılı raporlar almaya çalıştık. Strace çıktısına ilişkin analizimizi doğrulamak ve hangi dosya tanımlayıcının hangi amaçlarla kullanıldığını görmek için lsof'u kullandık. Strace kullanarak yukarıda gösterilen sonuçları elde ettik. Senkronizasyon süresi istatistikleri, etcd'deki wal_fsync_duration_seconds ölçümünün WAL dosya tanımlayıcıları olan fdatasync çağrılarına karşılık geldiğini doğruladı.
Fio belgelerine baktık ve betiğimizin parametrelerini fio'nun etcd'ye benzer bir yük oluşturacağı şekilde seçtik. Ayrıca sistem çağrılarını ve sürelerini strace'den fio komutunu çalıştırarak, etcd'ye benzer şekilde kontrol ettik.
Fio'nun tüm G/Ç yükünü temsil eden --size parametresinin değerini dikkatle seçtik. Bizim durumumuzda bu, depoya yazılan toplam bayt sayısıdır. Yazma (ve fdatasync) sistem çağrılarının sayısıyla doğru orantılı olduğu ortaya çıktı. Belirli bir bs değeri için, fdatasync'e yapılan çağrıların sayısı = boyut/bs. Yüzdelik dilimle ilgilendiğimiz için güvenilir olması için yeterli örneğe ihtiyacımız vardı ve 10^4'ün bizim için yeterli olacağını hesapladık (bu 22 mebibayt). --size daha küçükse aykırı değerler oluşabilir (örneğin, birkaç fdatasync çağrısı normalden daha uzun sürer ve 99'uncu yüzdelik dilimi etkiler).
Dene kendini
Fio'nun nasıl kullanılacağını gösterdik ve depolamanın etcd'nin iyi performans göstermesi için yeterince hızlı olup olmadığını öğrendik. Artık bunu, örneğin SSD depolamalı sanal makineleri kullanarak pratikte kendiniz deneyebilirsiniz. .
Kaynak: habr.com