შენახვის სიჩქარე შესაფერისია etcd-სთვის? ვკითხოთ ფიოს

მოკლე მოთხრობა ფიოსა და ა.შ

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

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

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

  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]

შენიშვნები

• ჩვენ მოვარგეთ --size და --bs ვარიანტები ჩვენი კონკრეტული სცენარისთვის. Fio-სგან სასარგებლო შედეგის მისაღებად, მიაწოდეთ საკუთარი ღირებულებები. სად მივიღოთ ისინი? წაიკითხეთ როგორ ვისწავლეთ fio-ს კონფიგურაცია.
• ტესტირების დროს, ყველა I/O დატვირთვა მოდის fio-დან. რეალურ სცენარში, სავარაუდოდ, იქნება საცავში ჩაწერის სხვა მოთხოვნები, გარდა wal_fsync_duration_seconds-თან დაკავშირებული. დამატებითი დატვირთვა გაზრდის wal_fsync_duration_seconds-ის მნიშვნელობას. ასე რომ, თუ 99-ე პროცენტული 10 ms-ს უახლოვდება, თქვენი მეხსიერება ამოიწურება.
• მიიღეთ ვერსია fio არანაკლებ 3.5 (წინა არ აჩვენებს fdatasync ხანგრძლივობის პროცენტულებს).
• ზემოთ მოცემულია მხოლოდ fio-ს შედეგების ფრაგმენტი.

გრძელი ამბავი ფიოსა და ა.შ

რა არის WAL და ა.შ

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

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

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>

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

შენახვის შეფასება fio-სთან ერთად

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

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

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

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

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

ჩვენ პირველად გამოვიყენეთ strace Kubernetes-ისთვის etcd სერვერის შესასწავლად, როდესაც კლასტერზე დატვირთვა არ იყო. ჩვენ დავინახეთ, რომ თითქმის ყველა WAL ჩანაწერი იყო დაახლოებით იგივე ზომის: 2200–2400 ბაიტი. ამიტომ, პოსტის დასაწყისში ბრძანებაში ჩვენ დავაზუსტეთ პარამეტრი -bs=2300 (bs ნიშნავს ზომას ბაიტებში თითოეული fio ჩანაწერისთვის). გაითვალისწინეთ, რომ etcd ჩანაწერის ზომა დამოკიდებულია etcd ვერსიაზე, განაწილებაზე, პარამეტრის მნიშვნელობებზე და ა.შ. და გავლენას ახდენს fdatasync-ის ხანგრძლივობაზე. თუ თქვენ გაქვთ მსგავსი სცენარი, შეამოწმეთ თქვენი etcd პროცესები strace-ით, რომ გაიგოთ ზუსტი რიცხვები.

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

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

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

სცადეთ თავს

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

წყარო: www.habr.com