हमारे हाथ बोरियत के लिए नहीं हैं: K8s में रूक क्लस्टर को पुनर्स्थापित करना

हमने पहले से ही बात की कि हम कैसे / क्यों रूक को पसंद करते हैं: काफी हद तक, यह कुबेरनेट्स समूहों में भंडारण के साथ काम करना सरल करता है। हालाँकि, इस सरलता के साथ कुछ कठिनाइयाँ आती हैं। हमें उम्मीद है कि नई सामग्री स्वयं को प्रकट करने से पहले भी ऐसी कठिनाइयों को बेहतर ढंग से समझने में मदद करेगी।

और इसे पढ़ने के लिए और अधिक दिलचस्प था, हम क्लस्टर में एक काल्पनिक समस्या के परिणामों से शुरू करते हैं।

"सब कुछ छूट गया!"

कल्पना करें कि आपने एक बार अपने K8s क्लस्टर में रूक को कॉन्फ़िगर और लॉन्च किया था, वह अपने काम से प्रसन्न था, लेकिन कुछ "अद्भुत" क्षणों में निम्न होता है:

• नई पॉड्स सेफ आरबीडी को माउंट नहीं कर सकती हैं।
• Ksernetes होस्ट पर lsblk और df जैसे कमांड काम नहीं करते हैं। यह स्वचालित रूप से नोड-माउंटेड आरबीडी छवियों के साथ "कुछ गलत है" का अर्थ है। मैं उन्हें नहीं पढ़ सकता, जो मॉनिटर की अक्षमता को इंगित करता है ...
• हां, क्लस्टर में कोई ऑपरेशनल मॉनिटर नहीं हैं। इसके अलावा - OSD के साथ पॉड्स भी नहीं हैं, न ही MGR की पॉड्स।

पॉड rook-ceph-operator कब लॉन्च किया गया था? इतना समय पहले नहीं जब वह तैनात था। क्यों? रूक-ऑपरेटर ने एक नया क्लस्टर बनाने का फैसला किया ... अब हम क्लस्टर और डेटा को कैसे पुनर्स्थापित कर सकते हैं?

आरंभ करने के लिए, चलिए एक और दिलचस्प तरीके से चलते हैं, रूक के "आंतरिक" और इसके घटकों की एक कदम-दर-चरण बहाली में एक विचारशील जांच की। बेशक, एक छोटा सही तरीका है: बैकअप का उपयोग करना। जैसा कि आप जानते हैं, प्रवेश दो प्रकारों में विभाजित हैं: वे जो बैकअप नहीं करते हैं, और वे जो पहले से ही करते हैं ... लेकिन जांच के बाद इसके बारे में अधिक।

थोड़ा अभ्यास, या लंबा रास्ता

एक नज़र डालें और मॉनिटर को पुनर्स्थापित करें

तो, चलिए ConfigMaps की सूची देखें: बैकअप के लिए आवश्यक rook-config-override सेफ rook-ceph-config और rook-config-override । वे क्लस्टर की सफल तैनाती पर दिखाई देते हैं।

एनबी : नए संस्करणों में, इस पीआर को अपनाने के बाद, कॉन्फ़िगरमैप्स एक क्लस्टर परिनियोजन की सफलता का सूचक बन गया है।

आगे की कार्रवाई करने के लिए, हमें उन सभी सर्वरों की हार्ड रिबूट की आवश्यकता है जिन्होंने आरबीडी चित्र ( ls /dev/rbd* ) को माउंट किया है। यह sysrq (या "पैदल" डेटा सेंटर पर) के माध्यम से किया जाना चाहिए। यह आवश्यकता माउंटेड आरबीडी को डिस्कनेक्ट करने के कार्य के कारण होती है, जिसके लिए एक नियमित रिबूट काम नहीं करेगा (यह सामान्य रूप से उन्हें अनमाउंट करने का असफल प्रयास करेगा)।

थिएटर एक पिछलग्गू के साथ शुरू होता है, और सीफ क्लस्टर मॉनिटर के साथ शुरू होता है। आइए उन पर नजर डालते हैं।

रूक मॉनिटर पॉड में निम्नलिखित संस्थाओं को मापता है:

 Volumes: rook-ceph-config: Type: ConfigMap (a volume populated by a ConfigMap) Name: rook-ceph-config rook-ceph-mons-keyring: Type: Secret (a volume populated by a Secret) SecretName: rook-ceph-mons-keyring rook-ceph-log: Type: HostPath (bare host directory volume) Path: /var/lib/rook/kube-rook/log ceph-daemon-data: Type: HostPath (bare host directory volume) Path: /var/lib/rook/mon-a/data Mounts: /etc/ceph from rook-ceph-config (ro) /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro) /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw) /var/log/ceph from rook-ceph-log (rw) 

आइए देखें कि rook-ceph-mons-keyring रहस्य क्या rook-ceph-mons-keyring :

 kind: Secret data: keyring: LongBase64EncodedString= 

हम डिकोड करते हैं और व्यवस्थापक और मॉनिटर के अधिकारों के साथ सामान्य कीरिंग प्राप्त करते हैं:

 [mon.] key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA== caps mon = "allow *" [client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *" 

याद रखें। अब देखिए गुप्त rook-ceph-admin-keyring :

 kind: Secret data: keyring: anotherBase64EncodedString= 

इसमें क्या है?

 [client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *" 

वही वाला। आइए अधिक देखें ... यहां, उदाहरण के लिए, rook-ceph-mgr-a-keyring का रहस्य है:

 [mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *" 

अंत में, हमें configMap rook-ceph-mon में कुछ और रहस्य मिलते हैं:

 kind: Secret data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA== 

और यह कीरिंग के साथ प्रारंभिक सूची है, जहां ऊपर वर्णित सभी रहस्य आते हैं।

जैसा कि आप जानते हैं (देखें dataDirHostPath में dataDirHostPath ), रूक इस डेटा को दो स्थानों पर संग्रहीत करता है। इसलिए, चलो मॉनिटरिंग और ओएसडी के साथ पॉड्स में घुड़सवार निर्देशिकाओं में झूठ बोलने वाले कीरिंग को देखने के लिए नोड्स पर जाएं। ऐसा करने के लिए, नोड्स /var/lib/rook/mon-a/data/keyring देखें और देखें:

 # cat /var/lib/rook/mon-a/data/keyring [mon.] key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg== caps mon = "allow *" 

अचानक, रहस्य अलग हो गया - कॉन्फिगरेशन की तरह नहीं।

व्यवस्थापक कीरिंग के बारे में क्या? हमारे पास भी है:

 # cat /var/lib/rook/kube-rook/client.admin.keyring [client.admin] key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *" 

यहाँ समस्या है। एक विफलता थी: क्लस्टर को फिर से बनाया गया था ... लेकिन वास्तव में नहीं।

यह स्पष्ट हो जाता है कि नवनिर्मित कीरिंग को रहस्यों में संग्रहीत किया गया है, और वे हमारे पुराने क्लस्टर से नहीं हैं। इसलिए:

• हम फाइल /var/lib/rook/mon-a/data/keyring से मॉनिटर से कीरिंग लेते हैं (या बैकअप से);
• गुप्त rook-ceph-mons-keyring में कीरिंग बदलें;
• व्यवस्थापक से कीरिंग रजिस्टर करें और कॉन्फ़िगरेप रो rook-ceph-mon सीफ़ rook-ceph-mon में मॉनिटर करें;
• मॉनिटर के साथ फली नियंत्रकों को हटा दें।

चमत्कार लंबा नहीं लगेगा: मॉनिटर दिखाई देंगे और शुरू हो जाएंगे। हुर्रे, एक शुरुआत!

OSD को पुनर्स्थापित करें

हम पॉड rook-operator : ceph mon dump कॉल करना दिखाता है कि सभी मॉनिटर जगह में हैं, और ceph -s कि वे एक कोरम में हैं। हालाँकि, यदि आप OSD ट्री ( ceph osd tree ) को देखते हैं, तो आपको इसमें कुछ अजीब लगेगा: OSD दिखने लगा है, लेकिन वे खाली हैं। यह पता चला है कि उन्हें भी किसी तरह बहाल करने की आवश्यकता है। लेकिन कैसे?

इस बीच, rook-ceph-config और rook-config-override के साथ-साथ कई अन्य configMaps जो फॉर्म rook-ceph-osd-$nodename-config नाम के साथ हैं, rook-ceph-osd-$nodename-config की इतनी जरूरत में दिखाई दिए। आइए नजर डालते हैं इन पर:

 kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}' 

सब कुछ गलत है, सब कुछ मिला हुआ है!

ऑपरेटर पॉड को शून्य पर स्केल करें, OSD से उत्पन्न परिनियोजन फली को हटाएं, और इन कॉन्फ़िगैप्स को ठीक करें। लेकिन नोड्स द्वारा सही ओएसडी नक्शा कहां प्राप्त करें?

• चलो फिर से नोड्स पर /mnt/osd[1-2] निर्देशिकाओं में तल्लीन करने की कोशिश करें - इस उम्मीद में कि हम वहां कुछ पकड़ सकते हैं।
• /mnt/osd1 निर्देशिका में 2 उपनिर्देशिकाएँ हैं: osd0 और osd16 । अंतिम एक ही वह आईडी है जो विन्यास मानचित्र (16) में निर्दिष्ट है?
• चलो आकार की osd0 हैं और देखते हैं कि osd0 तुलना में बहुत बड़ा है।

हम यह निष्कर्ष निकालते हैं कि osd0 आवश्यक OSD है, जो /mnt/osd1 में /mnt/osd1 रूप में निर्दिष्ट किया गया था (क्योंकि हम निर्देशिका आधारित osd का उपयोग करते हैं।)

कदम से कदम, हम सभी नोड्स की जांच करते हैं और कॉन्फ़िगर करते हैं। सभी निर्देशों के बाद, आप रूक ऑपरेटर के पॉड को चला सकते हैं और इसके लॉग पढ़ सकते हैं। और उनमें सब कुछ अद्भुत है:

• मैं एक क्लस्टर ऑपरेटर हूं;
• मुझे नोड्स पर ड्राइव मिला;
• मुझे मॉनिटर मिले;
• मॉनिटर दोस्त बन गए, अर्थात् एक कोरम का गठन;
• ओएसडी की तैनाती चल रही है ...

आइए हम रूक ऑपरेटर की पॉड पर जाएं और क्लस्टर लाइनिंग की जांच करें ... हां, हमने कुछ नोड्स पर ओएसडी नामों के बारे में निष्कर्ष के साथ थोड़ी गलती की! इससे कोई फर्क नहीं पड़ता: उन्होंने फिर से कॉन्फ़िगमैप्स को ठीक किया, नए OSDs से अतिरिक्त निर्देशिकाओं को हटा दिया और HEALTH_OK की लंबे समय से प्रतीक्षित स्थिति में HEALTH_OK !

पूल में चित्र देखें:

 # rbd ls -p kube pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb pvc-9fcc4308-0343-434c-a65f-9fd181ab103e pvc-a6466fea-bded-4ac7-8935-7c347cff0d43 pvc-b284d098-f0fc-420c-8ef1-7d60e330af67 pvc-b6d02124-143d-4ce3-810f-3326cfa180ae pvc-c0800871-0749-40ab-8545-b900b83eeee9 pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32 … acb26c7118fb # rbd ls -p kube pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb pvc-9fcc4308-0343-434c-a65f-9fd181ab103e pvc-a6466fea-bded-4ac7-8935-7c347cff0d43 pvc-b284d098-f0fc-420c-8ef1-7d60e330af67 pvc-b6d02124-143d-4ce3-810f-3326cfa180ae pvc-c0800871-0749-40ab-8545-b900b83eeee9 pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32 … 8ef1-7d60e330af67 # rbd ls -p kube pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb pvc-9fcc4308-0343-434c-a65f-9fd181ab103e pvc-a6466fea-bded-4ac7-8935-7c347cff0d43 pvc-b284d098-f0fc-420c-8ef1-7d60e330af67 pvc-b6d02124-143d-4ce3-810f-3326cfa180ae pvc-c0800871-0749-40ab-8545-b900b83eeee9 pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32 … 

सब कुछ जगह में है - क्लस्टर बचा लिया गया है!

मैं आलसी बैकअप कर रहा हूं, या फास्ट वे

यदि बैकअप रूक के लिए किया गया था, तो रिकवरी प्रक्रिया बहुत सरल हो जाती है और निम्नलिखित के लिए फोड़ा जाता है:

1. रूक ऑपरेटर की शून्य तैनाती के लिए स्केल;
2. हम रूक ऑपरेटर को छोड़कर सभी तैनाती को हटा देते हैं;
3. हम बैकअप से सभी रहस्यों और कॉन्फ़िगैप को पुनर्स्थापित करते हैं;
4. नोड्स पर /var/lib/rook/mon-* की सामग्री को पुनर्स्थापित करें;
5. पुनर्स्थापित करें (यदि अचानक खो गया) सीआरडी CephCluster , CephFilesystem , CephBlockPool , CephNFS , CephObjectStore ;
6. रूक ऑपरेटर की तैनाती को वापस 1 पर स्केल करें।

उपयोगी सुझाव

बैकअप बनाओ!

और उन परिस्थितियों से बचने के लिए जब आपको उनसे उबरने की आवश्यकता होती है:

1. सर्वर रिबूट में शामिल क्लस्टर के साथ बड़े पैमाने पर काम करने से पहले, रूक ऑपरेटर को शून्य पर स्केल करें ताकि यह बहुत अधिक न हो।
2. मॉनिटर पर, पहले से नोडऑफिनिटी जोड़ें ।
3. समयबाह्य ROOK_MON_HEALTHCHECK_INTERVAL और ROOK_MON_OUT_TIMEOUT पूर्व- सेटिंग पर ध्यान ROOK_MON_OUT_TIMEOUT ।

एक निष्कर्ष के बजाय

यह तर्क देने का कोई मतलब नहीं है कि रूक, एक अतिरिक्त "परत" (कुबेरनेट्स में भंडारण के आयोजन की सामान्य योजना में) है, जितना सरल होता है, यह बुनियादी ढांचे में नई कठिनाइयों और संभावित समस्याओं को भी जोड़ता है। बात "छोटी" बनी हुई है: एक तरफ इन जोखिमों के बीच एक संतुलित, सूचित विकल्प और उन लाभों के बीच जो आपके विशेष मामले में समाधान लाता है, दूसरी तरफ।

वैसे, खंड "एक मौजूदा रूक सेफ क्लस्टर को एक नए कुबेरनेट क्लस्टर में" अपनाने से हाल ही में रूक प्रलेखन में जोड़ा गया है । यह अधिक विस्तार से वर्णन करता है कि मौजूदा डेटा को एक नए कुबेरनेट क्लस्टर में स्थानांतरित करने या एक कारण या किसी अन्य के लिए ध्वस्त क्लस्टर को पुनर्स्थापित करने के लिए क्या करने की आवश्यकता है।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " Rook या नहीं - Rook - यह सवाल है ";
• " रूब एक" स्व-सेवा "कुबेरनेट्स के लिए डेटा वेयरहाउस " है;
• " लॉन्गहॉर्न, K8s के लिए रैन्चर का वितरित भंडारण, सीएनसीएफ को हस्तांतरित ।"
• " सिफ के आधार पर कुबेरनेट्स में प्रावधान के साथ लगातार भंडारण बनाना ।"