Longhorn-ის ტომი, რომელსაც გაზრდა არ სურდა: ცუდ ნოდაზე მიმაგრებული attachment ticket

Optimacros-ში MySQL-ის ერთ წევრს მეტი ადგილი დასჭირდა: მისი PVC 6 GiB იყო და 20 GiB-მდე გავზარდე. StorageClass გაფართოებას უშვებს, Longhorn ონლაინ resize-ს უჭერს მხარს, ხოლო სხვა ნოდაზე იდენტური PVC დაახლოებით 40 წამში გაიზარდა. ეს კი — არა.

სიმპტომი

PVC დაუსრულებლად რჩებოდა Resizing=True-ში. Longhorn-ის ობიექტები ნახევრად შესრულებულად გამოიყურებოდა: ტომის spec.size უკვე 20 GiB იყო, status.expansionRequired — true, მაგრამ ძრავის currentSize 6 GiB-ს არ გასცდა. პოდის შიგნით ფაილური სისტემა კვლავ 6 GiB იყო.

longhorn-manager ყოველ ხუთ წამში წერდა Starting engine expansion from 6→20Gi-ს ერთსა და იმავე ნოდაზე — და არანაირი შეცდომა. ციკლი შეცდომის შეტყობინების გარეშე ყველაზე ცუდი ვარიანტია: საძებნიც არაფერია.

წრის შევიწროება

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

აშკარა ნაბიჯი იყო პოდის ჯანმრთელ ნოდაზე გადატანა, რომ ძრავი იქ გადატვირთულიყო. Kubernetes-მა Multi-Attach error-ით უარი თქვა: ტომი „უკვე ექსკლუზიურად არის მიერთებული სხვა ნოდასთან“.

ურთიერთბლოკირება

Longhorn თვალს ადევნებს, ვის სჭირდება მიერთებული ტომი, volumeattachments.longhorn.io ობიექტზე attachment ticket-ებით. ტიკეტების სიამ დამნაშავე აჩვენა: volume-expansion-controller ტიკეტი, რომელიც ტომს ცუდ ნოდაზე აკრავდა.

სისტემამ თავი თავად შეიკრა:

• გაფართოებას სჭირდებოდა ცუდ ნოდასთან მიერთებული ტომი;
• ცუდი ნოდა ძრავის დონეზე გაფართოებას ვერ ასრულებდა;
• პოდი ჯანმრთელ ნოდაზე ვერ გადადიოდა, რადგან გაფართოების ტიკეტი ტომს ცუდზე აკავებდა.

გამოსავალი

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

რომ ახალი ძრავი სხვაგან ამდგარიყო, ცუდ ნოდას cordon გავუკეთე და StatefulSet-ის პოდი წავშალე. ის ჯანმრთელ ნოდაზე ავიდა, CSI პლაგინმა resize2fs გაუშვა და პოდის შიგნით df-მა 20 GiB აჩვენა. ამის შემდეგ ნოდას uncordon გავუკეთე.

ერთი გაფრთხილება stateful დატვირთვებისთვის: პოდის გადატანა ბაზის წევრს გადატვირთავს. ჯერ დარწმუნდით, რომ კვორუმი შენარჩუნებულია (MySQL Group Replication-ში 3-დან 2 გადარჩება), და რესტარტის შემდეგ წევრზე errant transaction-ს უყურეთ: მასთან ინკრემენტული rejoin შეუძლებელია და clone-ით აღდგენა მოგიწევთ.

დასკვნები

• გამეორებების ციკლი შეცდომის გარეშე თავისთავად მინიშნებაა: რაღაც ელოდება პირობას, რომელიც არასოდეს დადგება. მოძებნეთ, რა აკავებს მას ადგილზე.
• თუ გაფართოება ნოდაზე ლოკალურად ფუჭდება, შეადარეთ იმავე ოპერაციას სხვა ნოდაზე, სანამ საცავის სისტემას დაადანაშაულებთ.
• Longhorn-ის attachment ticket-ები ადრე ნახეთ: მოძველებული ტიკეტი ხსნის როგორც გაჭედილ გაფართოებას, ისე Multi-Attach error-ს.
• ტომის შეკეთება ნოდის შეკეთებას არ ნიშნავს. stateful ტომები საეჭვო ნოდიდან შორს დაიჭირეთ, სანამ მასზე ცალკე ანალიზი არ ჩატარდება.