🥇etcd için yeterli performans için fio ile diskler nasıl kontrol edilir

Not. tercüme: Bu makale, etcd veritabanının işleyişiyle ilgili gerçek bir soruna çözüm bulmak amacıyla IBM Cloud mühendisleri tarafından yürütülen mini bir araştırmanın sonucudur. Benzer bir görev bizim için önemliydi, ancak yazarların düşünceleri ve eylemleri daha geniş bir bağlamda ilginç olabilir.

Tüm makalenin kısa özeti: fio ve etcd

Bir etcd kümesinin performansı büyük ölçüde temeldeki depolamanın hızına bağlıdır. etcd, performansı izlemek için çeşitli Prometheus ölçümlerini dışa aktarır. Onlardan biri wal_fsync_duration_seconds. etcd belgelerinde diyorbu ölçümün 99. yüzdelik dilimi 10 ms'yi geçmiyorsa, bu depolama yeterince hızlı kabul edilebilir…

Linux makinelerde bir etcd kümesi kurmayı düşünüyorsanız ve sürücülerin (SSD'ler gibi) yeterince hızlı olup olmadığını kontrol etmek istiyorsanız, adı verilen popüler I/O test cihazını kullanmanızı öneririz. fio. Aşağıdaki komutu çalıştırmanız yeterlidir (dizin test-data test edilen sürücünün bağlı bölümünde yer almalıdır):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Sadece çıktıya bakmak ve 99. yüzdelik dilimin uyup uymadığını kontrol etmek için kalır. fdatasync 10 ms'de Öyleyse, sürücünüz yeterince hızlı çalışıyor demektir. İşte bir örnek çıktı:

fsync/fdatasync/sync_file_range:
  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]

Birkaç not:

Yukarıdaki örnekte, parametreleri ayarladık --size и --bs belirli bir durum için. Anlamlı bir sonuç elde etmek için fio, kullanım durumunuza uygun değerleri belirtin. Bunların nasıl seçileceği aşağıda tartışılacaktır.
Yalnızca test sırasında fio disk alt sistemini yükler. Gerçek hayatta, diğer işlemlerin diske yazması muhtemeldir (bunlarla ilgili olanlar dışında). wal_fsync_duration_seconds). Bu ek yük artabilir wal_fsync_duration_seconds. Başka bir deyişle, testten elde edilen 99. yüzdelik dilim ise fio10 ms'den biraz daha az ise, depolama performansının yeterli olmama olasılığı yüksektir.
Test için sürüme ihtiyacınız olacak fio 3.5'dan düşük değil, çünkü eski sürümler sonuçları toplamaz fdatasync yüzdelikler şeklinde.
Yukarıdaki sonuç, genel sonuçtan yalnızca küçük bir alıntıdır. fio.

fio ve etcd hakkında daha fazla bilgi

WAL'ler vb. hakkında birkaç söz

Genel olarak, veritabanlarının kullandığı proaktif günlük kaydı (önceden yazma kaydı, WAL). etcd de etkilenir. WAL hakkında bir tartışma bu makalenin kapsamı dışındadır, ancak amaçlarımız açısından bilmeniz gereken şey, her etcd kümesi üyesinin WAL'ı kalıcı depolamada sakladığıdır. etcd, bazı anahtar/değer depolama işlemlerini (güncellemeler gibi) yürütmeden önce WAL'a yazar. Anlık görüntüler arasında bir düğüm çöker ve yeniden başlarsa, etcd, WAL'ın içeriğine dayalı olarak önceki anlık görüntüden sonraki işlemleri kurtarabilir.

Böylece, bir müşteri KV deposuna bir anahtar eklediğinde veya varolan bir anahtarın değerini güncellediğinde, etcd işlemin açıklamasını kalıcı depoda normal bir dosya olan WAL'a ekler. etcd Devam etmeden önce WAL girişinin gerçekten kaydedildiğinden %100 emin OLMALIDIR. Bunu Linux'ta başarmak için sistem çağrısını kullanmak yeterli değildir. write, çünkü fiziksel ortama yazma işleminin kendisi gecikebilir. Örneğin, Linux bir WAL girişini bellek içi çekirdek önbelleğinde (örn. sayfa önbelleğinde) bir süre tutabilir. Verilerin ortama yazıldığından emin olmak için, yazma işleminden sonra bir sistem çağrısı başlatılmalıdır. fdatasync - bu tam olarak etcd'nin yaptığı şeydir (aşağıdaki çıktıda görebileceğiniz gibi strace; Burada 8 - WAL dosya tanıtıcısı):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Ne yazık ki, kalıcı depolamaya yazmak biraz zaman alıyor. fdatasync çağrılarının uzun süre yürütülmesi etcd'nin performansını etkileyebilir. Depo belgelerinde gösterilir, yeterli performans için tüm çağrıların süresinin 99. yüzdelik diliminde olması gerekir fdatasync bir WAL dosyasına yazarken 10 ms'den azdı. Depolamayla ilgili başka metrikler de var, ancak bu makale buna odaklanacak.

fio ile depolamayı değerlendirme

Yardımcı programı kullanarak belirli bir depolamanın etcd ile kullanıma uygun olup olmadığını değerlendirebilirsiniz. fio — popüler bir G/Ç test cihazı. Disk G/Ç'nin birçok farklı şekilde gerçekleşebileceğini unutmayın: senkronizasyon/eşzamansız, birçok farklı sistem çağrısı sınıfı vb. Madalyonun diğer yüzü ise, fio kullanımı son derece zor. Yardımcı programın birçok parametresi vardır ve değerlerinin farklı kombinasyonları tamamen farklı sonuçlara yol açar. etcd için makul bir tahmin elde etmek için, fio tarafından oluşturulan yazma yükünün etcd'nin WAL dosyası yazma yüküne mümkün olduğunca yakın olduğundan emin olmanız gerekir:

Bu demektir ki üretilen fio yük en azından dosyaya bir dizi ardışık yazma olmalıdır, burada her yazma bir sistem çağrısından oluşur writebunu takiben fdatasync.
Sıralı yazmayı etkinleştirmek için bayrağı belirtmelisiniz --rw=write.
O fio çağrıları kullanarak yazdı write (diğer sistem çağrıları yerine - örneğin, pwrite), bayrağı kullanın --ioengine=sync.
Son olarak, bayrak --fdatasync=1 sağlar her write gerektiği fdatasync.
Örneğimizdeki diğer iki parametre şunlardır: --size и --bs - belirli kullanım durumuna bağlı olarak değişebilir. Bir sonraki bölüm, yapılandırmalarını açıklayacaktır.

Neden fio'yu seçtik ve onu nasıl kuracağımızı nasıl öğrendik?

Bu not, karşılaştığımız gerçek bir vakadan geliyor. Prometheus üzerinde izleme ile Kubernetes v1.13 üzerinde bir kümemiz vardı. SSD'ler etcd v3.2.24 için depolama olarak kullanıldı. Vb ölçümleri çok yüksek gecikmeler gösterdi fdatasync, küme boştayken bile. Bize göre bu ölçümler çok şüpheli görünüyordu ve tam olarak neyi temsil ettiklerinden emin değildik. Ek olarak, küme sanal makinelerden oluşuyordu, bu nedenle gecikmenin sanallaştırmadan mı yoksa SSD'den mi kaynaklandığını söylemek mümkün değildi.

Ek olarak, donanım ve yazılım konfigürasyonundaki çeşitli değişiklikleri de göz önünde bulundurduk, dolayısıyla bunları değerlendirmek için bir yola ihtiyacımız vardı. Elbette, etcd'yi her yapılandırmada çalıştırmak ve karşılık gelen Prometheus ölçümlerine bakmak mümkün olacaktır, ancak bu önemli bir çaba gerektirecektir. İhtiyacımız olan şey, belirli bir konfigürasyonu değerlendirmenin basit bir yoluydu. Etcd'den gelen Prometheus metrikleri hakkındaki anlayışımızı test etmek istedik.

Bu, iki sorunun çözülmesini gerektiriyordu:

İlk olarak, WAL dosyalarına yazarken etcd tarafından oluşturulan G/Ç yükü neye benziyor? Hangi sistem çağrıları kullanılır? Kayıt bloklarının boyutu nedir?
İkinci olarak, yukarıdaki soruların cevaplarını bulduğumuzu varsayalım. İlgili yük ile nasıl çoğaltılır fio? Nihayet fio — çok sayıda parametre ile son derece esnek yardımcı program (bunun doğrulanması kolaydır, örneğin, burada - yakl. çev.).

Her iki sorunu da aynı komut tabanlı yaklaşımla çözdük lsof и strace:

Ile lsof işlem tarafından kullanılan tüm dosya tanımlayıcıları ve başvurdukları dosyaları görüntüleyebilirsiniz.
Ile strace zaten çalışan bir işlemi analiz edebilir veya bir işlemi çalıştırıp izleyebilirsiniz. Komut, bu işlem tarafından yapılan tüm sistem çağrılarını ve gerekirse alt öğelerini görüntüler. İkincisi çatallanan süreçler için önemlidir ve etcd böyle bir süreçtir.

İlk yaptığımız şey kullanmak oldu. strace etcd sunucusunu boştayken Kubernetes kümesinde incelemek için.

Böylece, WAL kayıt bloklarının çok yoğun bir şekilde gruplandığı, çoğunluğun boyutunun 2200-2400 bayt aralığında olduğu bulundu. Bu makalenin başındaki komutun bayrağı kullanmasının nedeni budur. --bs=2300 (bs içindeki her yazma bloğunun bayt cinsinden boyutudur. fio).

Lütfen etcd yazma bloklarının boyutunun sürüme, dağıtıma, parametre değerlerine vb. bağlı olarak değişebileceğini unutmayın. - süreyi etkiler fdatasync. Benzer bir kullanım durumunuz varsa, ile analiz edin strace güncel değerler elde etmek için etcd işlemleriniz.

Ardından, etcd'nin dosya sistemiyle nasıl çalıştığına dair net ve kapsamlı bir fikir edinmek için, onu aşağıdan başlattık. strace bayraklı -ffttT. Bu, alt süreçlerin yakalanmasını ve her birinin çıktısının ayrı bir dosyaya yazılmasını mümkün kıldı. Ayrıca her bir sistem çağrısının başlama zamanı ve süresi hakkında detaylı bilgi edinilmiştir.

komutunu da kullandık. lsofçıktıyı anladığınızı doğrulamak için strace hangi dosya tanıtıcısının hangi amaçla kullanıldığı açısından. sonuca vardım strace, yukarıdakine benzer. Senkronizasyon süreleriyle yapılan istatistiksel manipülasyonlar, metriğin wal_fsync_duration_seconds etcd çağrılarıyla eşleşir fdatasync WAL dosya tanımlayıcıları ile.

ile üretmek fio etcd'den gelene benzer bir iş yükü, yardımcı programın dokümantasyonu incelendi ve görevimize uygun parametreler seçildi. Doğru sistem çağrılarının devam ettiğini doğruladık ve çalıştırarak sürelerini onayladık. fio arasında strace (vb durumunda yapıldığı gibi).

Parametrenin değerinin belirlenmesine özellikle dikkat edildi. --size. Fio yardımcı programı tarafından üretilen toplam G/Ç yükünü temsil eder. Bizim durumumuzda bu, ortama yazılan toplam bayt sayısıdır. Çağrı sayısı ile doğru orantılıdır. write (ve fdatasync). Belirli bir bs çağrı sayısı fdatasync olduğu size / bs.

Yüzdelikle ilgilendiğimiz için, örnek sayısının istatistiksel olarak anlamlı olacak kadar büyük olmasını istedik. Ve buna karar verdi 10^4 (22 MB'lık bir boyuta karşılık gelir) yeterli olacaktır. Daha küçük parametre değerleri --size daha belirgin gürültü verdi (örneğin, aramalar fdatasyncnormalden çok daha uzun sürer ve yüzde 99'u etkiler).

O size kalmış

Makale nasıl kullanılacağını gösterir fio etcd ile kullanılması amaçlanan ortamın yeterince hızlı olup olmadığı yargılanabilir. Şimdi size kalmış! Hizmette SSD tabanlı depolamaya sahip sanal makineleri keşfedebilirsiniz. IBM Cloud.

çevirmenden PS

Hazır kullanım durumları ile fio Diğer görevler için bkz. belgeleme veya doğrudan proje havuzları (belgelerde belirtilenden çok daha fazlası var).

çevirmenden PPS

Blogumuzda da okuyun:

Kaynak: habr.com

Etcd için yeterli performans için fio ile diskler nasıl kontrol edilir