საწარმოო კლასტერის გადატანა Longhorn-იდან LINSTOR-ზე — და მოლოდინი, რომელიც არ ახდა

კლასტერი, რომელზეც Optimacros-ის მარკეტინგული საიტები ცხოვრობს, არის self-managed kubeadm ვირტუალურ მანქანებზე, Longhorn-ით ტომებისთვის: MySQL InnoDB Cluster, სამნოდიანი Vault, Prometheus, Grafana და Alertmanager. აგვისტოში ეს ყველაფერი LINSTOR-ზე (Piraeus) გადავიტანე, ქვეშ DRBD-ით. ეს არის ამბავი იმაზე, რატომ, როგორ და სად შევცდი.

არა გამტარუნარიანობის გამო

დისკები დროის 96% უმოქმედოდ იყვნენ. MySQL-ს ჰქონდა ნული ნელი მოთხოვნა, ნული innodb_log_waits და buffer pool-ში 99.99% მოხვედრა. გამტარუნარიანობა მიზეზი არ იყო.

მიზეზი იყო ოპერაციული დინამიკა, გაზომილი ნებისმიერ ცვლილებამდე:

• PVC-ის შექმნა Bound-მდე: 21 წამი;
• პირველი attach: 14 წამი;
• ტომის გადატანა ნოდებს შორის: 46 წამი, პლუს Multi-Attach შეცდომა;
• ჩაწერის დაყოვნება: 0.16 მწ ლოკალურ დისკზე 12 მწ-ის წინააღმდეგ Longhorn-ის ტომზე.

მონაცემთა გზაში ნაკლები მოძრავი ნაწილი და ლოკალური დისკის დაყოვნება მიგრაციად ღირდა.

ჯერ რისკიანი ნაწილის შემოწმება

DRBD ბირთვის მოდულია და ეს ერთადერთი ახალი გაუმართაობის კლასია, რომელიც LINSTOR-ს მოაქვს: Longhorn მთლიანად user-space-ში ცხოვრობს, DRBD — არა. ამიტომ ნებისმიერ გეგმამდე DRBD 9.3.3 ნოდების ბირთვზე ავაწყვე ზუსტად იმ ჩამტვირთავი იმიჯით, რომელსაც Piraeus პროდაქშენში გამოიყენებდა, და ერთ ნოდზე ჩავტვირთე და გამოვტვირთე. Secure Boot შეუსაბამო აღმოჩნდა (legacy BIOS ჩატვირთვა), Ubuntu-ს რეპოზიტორიებში კი იყო drbd-utils, მაგრამ არა drbd-dkms — რაც არ იყო მნიშვნელოვანი: მოდულს Piraeus-ის ჩამტვირთავი DaemonSet აწყობს და იმიჯს ნოდის ოს-ის მიხედვით ირჩევს.

დარჩენილი რისკი პირდაპირ ჩავწერე: ბირთვის ყოველი განახლება მოდულს თავიდან აწყობს და წარუმატებელი აწყობა ნოდს საცავის გარეშე დატოვებს. შემსუბუქება — ჩამტვირთავი მოდულს პოდის გაშვებისას აწყობს, ამიტომ გაუმართაობა რებუტისთანავე გამოჩნდება და არა დღეების შემდეგ, — ბირთვები კი ისედაც სათითაოდ ნოდებზე პატჩდება.

ზომა დასაბუთებით

127 GiB მონაცემი ორი რეპლიკით — 254 GiB კლასტერზე. ვორკერზე 200 GiB ვითხოვე — 3.2-ჯერ მარაგით — სამი კონკრეტული მიზეზით: Longhorn-ის სნეპშოტების გამო Prometheus-ის 30 GiB ტომი დისკებზე 68 GiB-ს იკავებდა; მიგრაციისას ორივე საცავი ერთად მუშაობს; რეპლიკები არასდროს ნაწილდება თანაბრად (ერთ ვორკერზე 51 GiB იყო თავისუფალი, მეორეზე — 156). დისკები ცალკე მოწყობილობებად მოვიდა; LINSTOR მათ მთლიანად LVM thin pool-ში იღებს.

ნაკლებად კრიტიკულიდან, ყოველ ჯერზე თავისი გზით

Longhorn დაყენებული რჩებოდა დაბრუნების წერტილად, ტომები კი სათითაოდ გადადიოდა, ნაკლებად კრიტიკულიდან ყველაზე კრიტიკულისკენ:

• Grafana (Deployment): rsync ორ ტომს შორის, შემდეგ existingClaim ჩარტის values-ში.
• Prometheus: rsync ზუსტად ერთხელ დროებით ტომში Retain-ით, შემდეგ მოხსნა და თავიდან მიერთება იმ სახელით, რომელსაც StatefulSet ელოდება.
• Vault და MySQL: კოპირების გარეშე. Raft და InnoDB clone მონაწილეს მეზობლებისგან აღადგენენ, ამიტომ საკმარისი იყო ერთი მონაწილის PVC-ის წაშლა და მისი ახალ storage class-ზე ამოსვლის მიცემა.

რა წავიდა ცუდად

პოდები, რომლებმაც წინა დღის DNS-ის ცვლილებას გაუძლეს, ჯერ კიდევ იმ კომპონენტის რეზოლვერს იყენებდნენ, რომელიც აღარ არსებობდა. Vault-ის Raft არჩევნებზე no such host-ით იშლებოდა, MySQL კი ჯგუფს ვერ აწყობდა. ეს მხოლოდ პოდების თავიდან შექმნით კურნავს და MySQL rebootClusterFromCompleteOutage-ით უნდა აგვეყვანა, მონაწილეების კლონირებით დამატებით.

და ერთი შეცდომა ჩემია: MySQL-ის StatefulSet --cascade=orphan-ით წავშალე მანიფესტის შენახვის გარეშე. ოპერატორმა უარი თქვა მის ხელახლა შექმნაზე owner reference-ის გარეშე დარჩენილი პოდების გარშემო და StatefulSet ხელით ავაწყვე ცოცხალი პოდის სპეციფიკაციიდან. მარკეტინგული საიტების ბაზა რამდენიმე წუთით მიუწვდომელი იყო, სანამ primary თავიდან იქმნებოდა; თავად საიტები მთელი დრო პასუხობდნენ.

გულწრფელი შედეგი

ყველაფერი იმავე დღეს გადავიდა, linstor-r2 (LVM thin, ორი რეპლიკა) ნაგულისხმევ კლასად იქცა, ამის შემდეგ კი Longhorn მთლიანად წაიშალა. მაგრამ მოლოდინი, რომ Multi-Attach შეცდომები გაქრებოდა, არ გამართლდა: ისინი ორივე საცავზე ერთნაირად მეორდება, რადგან ასე ექცევა Kubernetes RWO ტომებს და ეს Longhorn-ის დეფექტი არ არის. ტომის გადატანა მხოლოდ ზომიერად აჩქარდა — ხელახალ გაზომვაზე 14 წამი 19-ის ნაცვლად. დაყოვნების მოგება ნამდვილი იყო; attach-ის მოგება — ძირითადად მითი.

დასკვნები

• გაზომე ოპერაციები, რომელთა გაუმჯობესებაც გინდა, მიგრაციამდე — და გადაზომე შემდეგ. მხოლოდ ასე შეამჩნევ, რომ დაპირებული მოგება რეალური არ ყოფილა.
• ჯერ ახალი გაუმართაობის კლასი შეამოწმე. DRBD-სთვის ეს ბირთვის მოდულია, აწყობილი იმავე იმიჯით, რაც პროდაქშენში წავა.
• სხვადასხვა დატვირთვას — გადატანის სხვადასხვა გზა; კლასტერული ბაზები ხშირად თავად აღდგებიან კოპირების გარეშე.
• --cascade=orphan-მდე ყოველთვის შეინახე მანიფესტი.