როგორ შევამოწმოთ დისკები fio-ით საკმარისი შესრულებისთვის etcd-სთვის

Შენიშვნა. თარგმნა: ეს სტატია არის მინი-კვლევის შედეგები, რომელიც ჩატარდა IBM Cloud-ის ინჟინრების მიერ etcd მონაცემთა ბაზის მუშაობასთან დაკავშირებული რეალური პრობლემის გადაჭრის მოსაძებნად. მსგავსი დავალება ჩვენთვის აქტუალური იყო, მაგრამ ავტორების აზრებისა და ქმედებების მიმდინარეობა შესაძლოა უფრო ფართო კონტექსტში იყოს საინტერესო.

მთელი სტატიის მოკლე რეზიუმე: fio და ა.შ

etcd კლასტერის შესრულება დიდად არის დამოკიდებული ფუძემდებლური შენახვის სიჩქარეზე. შესრულების მონიტორინგისთვის და ა.შ. ექსპორტირდება პრომეთეს სხვადასხვა მეტრიკა. ერთ-ერთი მათგანია wal_fsync_duration_seconds. etcd დოკუმენტაციაში ამბობს ის, ეს შენახვა შეიძლება ჩაითვალოს საკმარისად სწრაფად, თუ ამ მეტრიკის 99 პროცენტი არ აღემატება 10 ms...

თუ თქვენ განიხილავთ etcd კლასტერის დაყენებას Linux მანქანებზე და გსურთ შეამოწმოთ არის თუ არა შენახვის დისკები (როგორიცაა SSD-ები) საკმარისად სწრაფი, გირჩევთ გამოიყენოთ პოპულარული I/O ტესტერი ე.წ. fio. უბრალოდ გაუშვით შემდეგი ბრძანება (საქაღალდე test-data უნდა განთავსდეს შესამოწმებელი დისკის დამონტაჟებულ დანაყოფში):

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

რჩება მხოლოდ დათვალიერება გამოსავალს და შეამოწმეთ შეესაბამება თუ არა ის 99 პროცენტულს fdatasync 10 ms-ზე. თუ ასეა, მაშინ თქვენი დისკი საკმარისად სწრაფია. აქ არის გამომავალი მაგალითი:

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]

რამდენიმე შენიშვნა:

1. ზემოთ მოყვანილ მაგალითში ჩვენ დავარეგულირეთ პარამეტრები --size и --bs კონკრეტული შემთხვევისთვის. მნიშვნელოვანი შედეგების მისაღებად fio, მიუთითეთ მნიშვნელობები, რომლებიც შესაფერისია თქვენი გამოყენების შემთხვევისთვის. როგორ ავირჩიოთ ისინი ქვემოთ იქნება განხილული.
2. მხოლოდ ტესტირების დროს fio იტვირთება დისკის ქვესისტემა. რეალურ ცხოვრებაში, სავარაუდოა, რომ სხვა პროცესები (გარდა მათთან დაკავშირებული wal_fsync_duration_seconds). ასეთმა დამატებითმა დატვირთვამ შეიძლება გამოიწვიოს ზრდა wal_fsync_duration_seconds. სხვა სიტყვებით რომ ვთქვათ, თუ ტესტირების შედეგად მიღებული 99 პროცენტი fio, მხოლოდ 10 ms-ზე ოდნავ ნაკლებია, დიდი შანსია, რომ შენახვის შესრულება არასაკმარისია.
3. ტესტისთვის დაგჭირდებათ ვერსია fio არანაკლებ 3.5, რადგან ძველი ვერსიები არ აერთიანებს შედეგებს fdatasync პროცენტების სახით.
4. ზემოაღნიშნული დასკვნა საერთო დასკვნის მხოლოდ მცირე ნაწილია fio.

დეტალები fio და ა.შ

რამდენიმე სიტყვა WAL-ების შესახებ და ა.შ

როგორც წესი, მონაცემთა ბაზები გამოიყენება პროაქტიული ხე (წინასწარ ჩაწერა, WAL). და ა.შ. ეს ასევე ეხება. WAL-ის განხილვა სცილდება ამ სტატიის ფარგლებს, მაგრამ ჩვენი მიზნებისთვის აი, რა უნდა იცოდეთ: etcd კლასტერის თითოეული წევრი ინახავს WAL-ს მუდმივ საცავში. etcd წერს რამდენიმე გასაღების ღირებულების შენახვის ოპერაციებს (როგორიცაა განახლებები) WAL-ში მათ შესრულებამდე. თუ კვანძი ავარიულია და გადაიტვირთება სნეპშოტებს შორის, etcd-ს შეუძლია აღადგინოს წინა სნეპშოტის შემდეგ განხორციელებული ტრანზაქციები WAL-ის შიგთავსზე დაყრდნობით.

ამრიგად, ყოველ ჯერზე, როდესაც კლიენტი ამატებს გასაღებს KV მაღაზიაში ან განაახლებს არსებული გასაღების მნიშვნელობას, etcd ამატებს ოპერაციის აღწერას WAL-ს, რომელიც არის რეგულარული ფაილი მუდმივ საცავში. etcd უნდა იყოს 100% დარწმუნებული, რომ WAL ჩანაწერი რეალურად არის შენახული გაგრძელებამდე. Linux-ზე ამის მისაღწევად, საკმარისი არ არის სისტემური ზარის გამოყენება write, რადგან ფიზიკურ მედიაზე ჩაწერის ოპერაცია შეიძლება გადაიდოს. მაგალითად, Linux-მა შეიძლება გარკვეული დროით შეინახოს WAL ჩანაწერი ბირთვის ქეში მეხსიერებაში (როგორიცაა გვერდის ქეში). მონაცემთა მედიაში ჩაწერის უზრუნველსაყოფად, სისტემური ზარი უნდა გამოიძახოთ ჩაწერის შემდეგ fdatasync - ეს არის ზუსტად ის, რასაც etcd აკეთებს (როგორც ჩანს შემდეგ გამომავალში strace; Აქ 8 - WAL ფაილის სახელური):

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>

სამწუხაროდ, მუდმივ საცავში ჩაწერას გარკვეული დრო სჭირდება. fdatasync ზარის დასრულებას დიდი დრო სჭირდება, შეიძლება გავლენა მოახდინოს etcd შესრულებაზე. საცავის დოკუმენტაციაში მითითებულიარომ საკმარისი შესრულებისთვის აუცილებელია ყველა ზარის ხანგრძლივობის 99 პროცენტი fdatasync ფაილში ჩაწერისას WAL იყო 10 ms-ზე ნაკლები. შენახვასთან დაკავშირებული სხვა მეტრიკაა, მაგრამ ეს სტატია ამაზე იქნება ფოკუსირებული.

შენახვის შეფასება fio-ს გამოყენებით

თქვენ შეგიძლიათ შეაფასოთ, არის თუ არა გარკვეული საცავი შესაფერისი etcd-თან გამოსაყენებლად კომუნალური პროგრამის გამოყენებით fio - პოპულარული I/O ტესტერი. გაითვალისწინეთ, რომ დისკის I/O შეიძლება მოხდეს სხვადასხვა გზით: სინქრონიზაცია/ასინქრონიზაცია, სისტემური ზარების მრავალი განსხვავებული კლასი და ა.შ. მონეტის მეორე მხარე ისაა fio უკიდურესად რთული გამოსაყენებელი. პროგრამას აქვს მრავალი პარამეტრი და მათი მნიშვნელობების სხვადასხვა კომბინაცია იწვევს სრულიად განსხვავებულ შედეგებს. etcd-ის გონივრული შეფასების მისაღებად, თქვენ უნდა უზრუნველყოთ, რომ fio-ს მიერ გენერირებული ჩაწერის დატვირთვა მაქსიმალურად ჰგავს etcd-ის WAL ფაილებზე ჩაწერის დატვირთვას:

• ეს ნიშნავს, რომ გენერირებული fio სამუშაო დატვირთვა სულ მცირე უნდა იყოს ფაილში თანმიმდევრული ჩაწერების სერია, სადაც თითოეული ჩაწერის ოპერაცია შედგება სისტემური ზარისგან. writeრასაც მოჰყვა fdatasync.
• თანმიმდევრული ჩაწერის გასააქტიურებლად, თქვენ უნდა მიუთითოთ დროშა --rw=write.
• რომ fio წერდა ზარების გამოყენებით write (და არა სხვა სისტემური ზარები - მაგალითად, pwrite), გამოიყენეთ დროშა --ioengine=sync.
• ბოლოს დროშა --fdatasync=1 გარანტიას იძლევა, რომ უკან ყოველი write უნდა იყოს fdatasync.
• ორი სხვა პარამეტრი ჩვენს მაგალითში: --size и --bs - შეიძლება განსხვავდებოდეს კონკრეტული გამოყენების შემთხვევის მიხედვით. შემდეგი განყოფილება აღწერს, თუ როგორ უნდა დააკონფიგურიროთ ისინი.

რატომ ავირჩიეთ ფიო და როგორ ვისწავლეთ მისი დაყენება

ეს შენიშვნა მომდინარეობს რეალური შემთხვევიდან, რომელიც ჩვენ შევხვდით. ჩვენ გვქონდა კლასტერი Kubernetes v1.13-ზე პრომეთეს მონიტორინგით. მყარი მდგომარეობის დისკები გამოყენებული იყო etcd v3.2.24-ის შესანახად. etcd მეტრიკა აჩვენა ძალიან მაღალი შეყოვნება fdatasync, მაშინაც კი, როცა მტევანი უსაქმური იყო. ჩვენ აღმოვაჩინეთ, რომ ეს მეტრიკა ძალიან საეჭვო იყო და არ ვიყავით დარწმუნებული, რას წარმოადგენდნენ ისინი. გარდა ამისა, კლასტერი შედგებოდა ვირტუალური მანქანებისგან, ამიტომ შეუძლებელი იყო იმის დადგენა, შეფერხება ვირტუალიზაციის გამო იყო თუ SSD-ების ბრალი.

გარდა ამისა, ჩვენ ვუყურებდით სხვადასხვა ცვლილებებს ტექნიკისა და პროგრამული უზრუნველყოფის კონფიგურაციებში, ამიტომ გვჭირდებოდა მათი შეფასების გზა. რა თქმა უნდა, შესაძლებელი იქნებოდა etcd-ის გაშვება თითოეულ კონფიგურაციაში და შევხედოთ შესაბამის პრომეთეს მეტრიკას, მაგრამ ამას მნიშვნელოვანი ძალისხმევა დასჭირდება. ჩვენ გვჭირდებოდა მარტივი გზა კონკრეტული კონფიგურაციის შესაფასებლად. ჩვენ გვინდოდა გამოგვემოწმებინა ჩვენი გაგება პრომეთეს მეტრიკაზე, რომელიც მოდის etcd-დან.

ამისათვის ორი პრობლემის გადაჭრა იყო საჭირო:

• პირველი, რას ჰგავს I/O ჩატვირთვა, რომელსაც etcd წარმოქმნის WAL ფაილებში ჩაწერისას? რა სისტემური ზარები გამოიყენება? რა არის ჩაწერის ბლოკის ზომა?
• მეორეც, ვთქვათ, გვაქვს პასუხი ზემოხსენებულ კითხვებზე. როგორ გავამრავლოთ შესაბამისი დატვირთვა fio? Ყველაფრის შემდეგ fio - უკიდურესად მოქნილი პროგრამა უამრავი პარამეტრით (ამის შემოწმება მარტივია, მაგალითად, აქ - დაახლ. თარგმანი.).

ჩვენ გადავწყვიტეთ ორივე პრობლემა ერთი და იგივე ბრძანებაზე დაფუძნებული მიდგომის გამოყენებით lsof и strace:

• ერთად lsof თქვენ შეგიძლიათ ნახოთ პროცესის მიერ გამოყენებული ყველა ფაილის აღმწერი, ისევე როგორც ფაილები, რომლებსაც ისინი მიმართავენ.
• ერთად strace შეგიძლიათ გაანალიზოთ უკვე მიმდინარე პროცესი ან აწარმოოთ პროცესი და დააკვირდეთ მას. ბრძანება აჩვენებს ყველა სისტემურ ზარს ამ პროცესით და, სურვილისამებრ, მის შთამომავლებს. ეს უკანასკნელი მნიშვნელოვანია პროცესებისთვის, რომლებიც ჩანგალი ხდება და etcd ერთ-ერთი ასეთი პროცესია.

პირველი, რაც გავაკეთეთ, გამოვიყენეთ strace შეისწავლოს etcd სერვერი Kubernetes კლასტერში, სანამ ის უმოქმედო იყო.

ამრიგად, გაირკვა, რომ WAL-ში ჩაწერის ბლოკები ძალიან მჭიდროდ არის დაჯგუფებული, მათი უმრავლესობა 2200-2400 ბაიტის დიაპაზონშია. სწორედ ამიტომ ამ სტატიის დასაწყისში ბრძანება იყენებს დროშას --bs=2300 (bs - თითოეული ჩამწერი ბლოკის ზომა ბაიტებში fio).

გთხოვთ გაითვალისწინოთ, რომ etcd ჩაწერის ბლოკის ზომები შეიძლება განსხვავდებოდეს ვერსიის, განლაგების, პარამეტრის მნიშვნელობების და ა.შ. - ეს გავლენას ახდენს ხანგრძლივობაზე fdatasync. თუ თქვენ გაქვთ მსგავსი გამოყენების შემთხვევა, გააანალიზეთ strace თქვენი etcd ამუშავებს უახლესი მნიშვნელობების მისაღებად.

შემდეგ, იმის გასაგებად, თუ როგორ მუშაობს etcd ფაილურ სისტემასთან, ჩვენ ქვემოდან გავუშვით strace დროშებით -ffttT. ამან შესაძლებელი გახადა ბავშვის პროცესების გადაღება და თითოეულის გამომავალი ცალკე ფაილში ჩაწერა. გარდა ამისა, დეტალური ინფორმაცია იქნა მიღებული თითოეული სისტემური ზარის დაწყების მომენტისა და ხანგრძლივობის შესახებ.

ჩვენ ასევე გამოვიყენეთ ბრძანება lsofრომ დაადასტუროთ გამომავალი თქვენი გაგება strace თუ რომელი ფაილის აღმწერი რა მიზნით იქნა გამოყენებული. შედეგი იყო straceზემოაღნიშნულის მსგავსი. სტატისტიკურმა მანიპულაციებმა სინქრონიზაციის დროებით დაადასტურა, რომ მეტრიკა wal_fsync_duration_seconds etcd მატჩების ზარებიდან fdatasync WAL ფაილის აღწერებით.

გენერირება გამოყენებით fio დატვირთვის მსგავსი დატვირთვა etcd-დან, შესწავლილი იქნა კომუნალური დოკუმენტაცია და შეირჩა ჩვენი ამოცანისთვის შესაფერისი პარამეტრები. ჩვენ დავრწმუნდით, რომ სწორი სისტემური ზარები იყო ჩართული და დავადასტურეთ მათი ხანგრძლივობა გაშვებით fio საქართველოს strace (როგორც გაკეთდა etcd-ის შემთხვევაში).

განსაკუთრებული ყურადღება დაეთმო პარამეტრის მნიშვნელობის განსაზღვრას --size. ის წარმოადგენს fio უტილიტის მიერ გენერირებულ მთლიან I/O დატვირთვას. ჩვენს შემთხვევაში, ეს არის მედიაზე დაწერილი ბაიტების საერთო რაოდენობა. ეს პირდაპირპროპორციულია ზარების რაოდენობისა write (და fdatasync). გარკვეული bs ზარების რაოდენობა fdatasync ტოლია size / bs.

იმის გამო, რომ ჩვენ გვაინტერესებდა პროცენტული, ჩვენ ვცდილობდით დავრწმუნდეთ, რომ ნიმუშების რაოდენობა საკმარისად დიდი იყო სტატისტიკური მნიშვნელობისთვის. და მათ გადაწყვიტეს ეს 10^4 (რომელიც შეესაბამება 22 მბ ზომას) საკმარისი იქნება. პარამეტრის უფრო მცირე მნიშვნელობები --size წარმოქმნა უფრო გამოხატული ხმაური (მაგალითად, ზარები fdatasync, რომელსაც ჩვეულებრივზე ბევრად მეტი დრო სჭირდება და გავლენას ახდენს 99 პროცენტულზე).

Ეს შენზეა დამოკიდებული

სტატიაში ნაჩვენებია როგორ გამოიყენოთ fio შეგიძლიათ შეაფასოთ, არის თუ არა საკმარისად სწრაფი მედია etcd-ით გამოსაყენებლად. ახლა თქვენზეა დამოკიდებული! სერვისში შეგიძლიათ შეისწავლოთ ვირტუალური მანქანები SSD-ზე დაფუძნებული მეხსიერებით IBM Cloud.

PS მთარგმნელისგან

გამოყენების მზა მაგალითებით fio სხვა პრობლემების გადასაჭრელად შეგიძლიათ იპოვოთ დოკუმენტაცია ან პირდაპირ პროექტის საცავი (მათ შორის ბევრად მეტია, ვიდრე დოკუმენტაციაშია აღნიშნული).

PPS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «და ა.შ. 3.4.3: შენახვის საიმედოობისა და უსაფრთხოების შესწავლა";
• «ჩვენი გამოცდილება მონაცემებით etcd Kubernetes კლასტერში პირდაპირ (K8s API-ის გარეშე)";
• «6 გასართობი სისტემის შეცდომა Kubernetes-ის მუშაობაში [და მათი გადაწყვეტა]".

წყარო: www.habr.com