प्रॉम्प्ट और संदर्भ
Kubernetes v1.36 ने VolumeGroupSnapshot, VolumeGroupSnapshotContent, और VolumeGroupSnapshotClass को groupsnapshot.storage.k8s.io/v1 में प्रमोट किया है। साक्षात्कारकर्ता यह जानना चाहता है कि कई PersistentVolumeClaims मिलकर एक रिकवरी पॉइंट कैसे बनाते हैं, CSI ड्राइवर का क्या उत्तरदायित्व है, और आप स्टोरेज-लेवल और एप्लिकेशन-लेवल निरंतरता के बीच के अंतर को कैसे संभालते हैं।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- क्या आप क्रैश निरंतरता (crash consistency), एप्लिकेशन निरंतरता और अंतिम निरंतरता (eventual consistency) में अंतर कर सकते हैं।
- क्या आप Kubernetes कंट्रोलर्स, external snapshot controller और CSI ड्राइवर के बीच की सीमा को समझा सकते हैं।
- क्या आप CSI सपोर्ट, क्षमता, टोपोलॉजी और स्नैपशॉट लाइफसाइकिल सीमाओं जैसी पूर्व-आवश्यकताओं की पहचान करते हैं।
- क्या आप रिकवरी उद्देश्यों, ड्रिल मेट्रिक्स और विफलता रोलबैक को एक निष्पादन योग्य प्रक्रिया में बदलते हैं।
पहले स्पष्ट करने योग्य प्रश्न
पुष्टि करें कि क्या डेटाबेस ऑनलाइन बैकअप का समर्थन करता है, क्या प्रत्येक वॉल्यूम समान CSI ड्राइवर का उपयोग करता है, और आवश्यक RPO, RTO और क्रॉस-ज़ोन व्यवहार क्या हैं। यह भी पुष्टि करें कि क्या स्टोरेज सिस्टम राइट ऑर्डरिंग को बनाए रखता है या क्या एप्लिकेशन को पहले राइट्स को फ्लश, फ्रीज या पॉज करना होगा।
30-सेकंड का उत्तर
मैं चार लेयर्स का उपयोग करूँगा: एप्लिकेशन एक कंसिस्टेंसी पॉइंट बनाता है; Kubernetes VolumeGroupSnapshot के साथ PVC सेट को रिकॉर्ड करता है; CSI ड्राइवर स्टोरेज में एक ग्रुप स्नैपशॉट बनाता है; और रिकवरी नए वॉल्यूम्स को रीस्टोर करके उन्हें सत्यापित करती है। यह API v1.36 में GA है, लेकिन यह क्रैश-कंसिस्टेंट वॉल्यूम स्नैपशॉट्स को समन्वित करता है; यह डेटाबेस लॉग्स, की (key) मैनेजमेंट या आवर्ती रिकवरी ड्रिल्स की जगह नहीं लेता है।
चरण-दर-चरण गहन विश्लेषण
1. एक कंसिस्टेंसी पॉइंट स्थापित करें
डेटाबेस एक प्रमाणित करने योग्य बैकअप क्रिया निष्पादित करता है, जैसे कि कुछ समय के लिए राइट्स को फ्रीज करना, WAL फ्लश करना, या चेकपॉइंट बनाना। ग्रुप स्नैपशॉट बनाने से पहले ट्रांजेक्शन स्थिति, स्नैपशॉट समय और एप्लिकेशन वर्शन रिकॉर्ड करें। बिना एप्लिकेशन समन्वय के केवल-स्टोरेज स्नैपशॉट डिस्क-कंसिस्टेंट हो सकता है जबकि व्यावसायिक स्थिति असंगत (inconsistent) हो सकती है।
2. ग्रुप स्नैपशॉट बनाएं और निरीक्षण करें
एक डेटाबेस इंस्टेंस के PVCs के लिए VolumeGroupSnapshot बनाएं और इसके तैयार स्थिति में आने की प्रतीक्षा करें। कंट्रोलर्स Kubernetes ऑब्जेक्ट्स का समन्वय करते हैं; CSI ड्राइवर स्टोरेज ऑपरेशंस करता है और उसे वॉल्यूम-ग्रुप स्नैपशॉट एक्सटेंशन API का समर्थन करना चाहिए। प्रत्येक सदस्य के स्नैपशॉट हैंडल, क्षमता, टोपोलॉजी और एरर को रिकॉर्ड करें ताकि आंशिक सफलता को कभी भी पुनर्प्राप्ति योग्यता (recoverability) समझने की भूल न हो।
3. पुनर्प्राप्ति (Recover) और सत्यापन करें
डेटाबेस-से-वॉल्यूम मैपिंग को बनाए रखते हुए प्रत्येक सदस्य के लिए नए PVCs बनाएं। डेटाबेस को एक अलग (isolated) वातावरण में शुरू करें, WAL स्थिति, टेबल काउंट, चेकसम और मुख्य व्यावसायिक क्वेरीज़ को सत्यापित करें, और फिर ट्रैफ़िक स्विच करें। क्रॉस-ज़ोन रिकवरी को यह भी सत्यापित करना चाहिए कि स्नैपशॉट प्रतिकृति (replica) पठनीय है और CSI ड्राइवर लक्षित टोपोलॉजी को स्वीकार करता है।
4. परिचालन सीमाएं (Operational boundaries)
रीटेंशन, एन्क्रिप्शन और एक्सेस कंट्रोल्स को परिभाषित करें; स्नैपशॉट की अवधि और विफलता दर की निगरानी करें। स्नैपशॉट को स्थायी अभिलेखागार (archives) के बजाय रिकवरी सामग्री के रूप में मानें: उन्हें स्वतंत्र मीडिया पर निर्यात करें और अभ्यास (drills) के माध्यम से वास्तविक RPO और RTO को मापें। PVCs, स्नैपशॉट ऑब्जेक्ट्स या बैकएंड ऑब्जेक्ट्स को हटाने से पहले, पुष्टि करें कि रिक्लेम पॉलिसी (reclaim policy) अभी भी उपयोग में आने वाले रिकवरी पॉइंट को नहीं हटाएगी।
एक उत्कृष्ट उत्तर का उदाहरण
मैं सबसे पहले रिकवरी उद्देश्यों को परिभाषित करूँगा और एक ही CSI ड्राइवर द्वारा प्रबंधित PVCs का चयन करूँगा। एप्लिकेशन एक चेकपॉइंट बनाता है और अपनी WAL स्थिति को रिकॉर्ड करता है, आवश्यकता पड़ने पर थोड़ी देर के लिए राइट्स को रोकता है; फिर हम एक groupsnapshot.storage.k8s.io/v1 VolumeGroupSnapshot बनाते हैं। कंट्रोलर Kubernetes ऑब्जेक्ट्स का समन्वय करता है, जबकि CSI ड्राइवर और स्टोरेज सिस्टम ग्रुप सेमांटिक्स प्रदान करते हैं। मैं ड्राइवर वर्शन, टोपोलॉजी, क्षमता और स्नैपशॉट कोटा को सत्यापित करूँगा, और प्रत्येक सदस्य की रेडी स्थिति पर अलर्ट सेट करूँगा।
रिकवरी कभी भी प्रोडक्शन वॉल्यूम को ओवरराइट नहीं करती है। यह ग्रुप स्नैपशॉट से नए PVCs बनाती है, डेटाबेस को एक आइसोलेटेड नेमस्पेस में शुरू करती है, WAL, चेकसम और व्यावसायिक क्वेरीज़ को सत्यापित करती है, और उसके बाद ही ट्रैफ़िक स्विच करती है। यदि कोई भी सदस्य विफल होता है, तो वह ग्रुप अनुपयोगी हो जाता है और वर्कफ़्लो रोलबैक हो जाता है; आंशिक स्नैपशॉट को पूरा बैकअप नहीं कहा जाता है। निर्धारित ड्रिल्स RPO और RTO को साबित करते हैं, जबकि स्वतंत्र संग्रह (archival), एन्क्रिप्शन और न्यूनतम विशेषाधिकार स्नैपशॉट सिस्टम को सिंगल पॉइंट ऑफ़ फेलियर या लीकेज बनने से रोकते हैं।
सामान्य गलतियाँ
- यह मान लेना कि GA का अर्थ है कि प्रत्येक स्टोरेज ड्राइवर इस सुविधा का स्वचालित रूप से समर्थन करता है; यह अभी भी CSI और स्टोरेज कार्यान्वयन पर निर्भर करता है।
- केवल निर्माण का वर्णन करना, सदस्य-स्तरीय विफलता, टोपोलॉजी और लाइफसाइकिल हैंडलिंग को छोड़ देना।
- क्रैश निरंतरता को एप्लिकेशन निरंतरता कहना और फ्लश, WAL, या चेकपॉइंट्स को छोड़ देना।
- केवल स्नैपशॉट मेटाडेटा को बनाए रखना और रीस्टोर किए गए डेटाबेस को कभी भी एक आइसोलेटेड वातावरण में शुरू न करना।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि एक सदस्य वॉल्यूम का स्नैपशॉट विफल हो जाता है?
ग्रुप स्नैपशॉट को अनुपयोगी के रूप में चिह्नित करें, ईवेंट्स और बनाए गए हैंडल्स को बनाए रखें, अप्रयुक्त संसाधनों (orphaned resources) को साफ़ करें, और पुनः प्रयास करें। रिकवरी केवल एक पूर्ण सदस्य सेट को स्वीकार करती है, जबकि आंशिक सफलता की रिपोर्ट अलर्टिंग और क्षमता ऑडिट के लिए की जाती है।
प्रत्येक PVC का अलग-अलग स्नैपशॉट क्यों नहीं लिया जाता?
व्यक्तिगत स्नैपशॉट्स में एक साझा रिकवरी पॉइंट की कमी होती है, इसलिए क्रॉस-वॉल्यूम राइट ऑर्डर में अंतर आ सकता है। एक ग्रुप स्नैपशॉट सदस्य सेट और ग्रुप ऑपरेशन को स्टोरेज को सौंपता है, जबकि व्यावसायिक निरंतरता के लिए अभी भी एप्लिकेशन चेकपॉइंट्स की आवश्यकता होती है।
आप कैसे साबित करते हैं कि योजना RPO और RTO को पूरा करती है?
एक निश्चित शेड्यूल पर एक आइसोलेटेड क्लस्टर में रिकवर करें, चेकपॉइंट से क्वेरी करने योग्य सेवा तक का समय, डेटा-पोजिशन ड्रिफ्ट और विफलता दर रिकॉर्ड करें। ड्रिल परिणाम रिलीज़ गेट्स बन जाते हैं; यदि थ्रेशोल्ड छूट जाते हैं, तो स्नैपशॉट आवृत्ति, संग्रह पथ, या कटओवर प्रक्रियाओं को समायोजित करें।