क्लाउड में अपना डेटा स्टोर करते समय आपको क्या सोचना चाहिए। भाग 1

इस लेख में, मैं बादलों में संग्रहीत डेटा की उपलब्धता पर चर्चा करने जा रहा हूं। कार्यक्रम का दूसरा (और सबसे दिलचस्प) बिंदु इस डेटा की गोपनीयता और सुरक्षा है।




मैं तुरंत ध्यान देना चाहता हूं, इस भाग में मैं व्यावहारिक के बारे में प्रश्न के सैद्धांतिक भाग के बारे में अधिक लिखता हूं। मान लीजिए कि कोई उपयोगकर्ता क्लाउड में अपने डेटा का बैकअप सेट करने जा रहा है। क्या संभावित समस्याएं पैदा हो सकती हैं और उनसे कैसे बचा जा सकता है? शुरू करने के लिए, यह स्पष्ट दोहराने के लायक है: उपयोगकर्ता इस प्रकार के डेटा बैकअप का उपयोग क्यों करना चाहेगा?

प्रेरणा

सबसे पहले, क्लाउड प्रदाता उच्च डेटा उपलब्धता का वादा करते हैं (बाद में पाठ में मैं कभी-कभी इसे उपलब्धता कहूंगा)। दूसरे, यह समझा जाता है कि डेटा, भले ही यह फिलहाल उपलब्ध नहीं है, अभी भी कहीं संग्रहीत है, और इस तक पहुंच बाद में दिखाई देगी। इस विशेषता को स्थायित्व कहा जाता है।

एक अतिरिक्त महत्वपूर्ण लाभ यह है कि संग्रहीत डेटा दुनिया में कहीं से भी सुलभ होगा, इंटरनेट तक सामान्य पहुंच होगी।

तो, विज्ञापित तीन मुख्य लाभ हैं:

• उच्च उपलब्धता
• उच्च स्थायित्व
• लचीलापन: इंटरनेट कनेक्शन के साथ दुनिया में कहीं से भी डेटा एक्सेस करना

क्या दावा किए गए गुण वास्तव में सच हैं?

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

निराधार न होने के लिए, मैं हाल के वर्षों में हुई घटनाओं के कुछ उदाहरण दूंगा। चलो पहुंच के साथ शुरू करते हैं। जानी-मानी अमेज़न S3 “थ्री नाइन” की घोषित उपलब्धता वाली एक सेवा है, जिसका अर्थ है कि यह सेवा सप्ताह में 10 मिनट से अधिक समय तक ऑफ़लाइन हो सकती है। दो गंभीर आउटेज वे 2008 में हुए थे। जून में, यह सेवा 8 घंटे के लिए अनुपलब्ध थी। फरवरी में, एक्सेस समस्याएं लगभग 3 घंटे तक चलीं। और ये केवल मामले नहीं हैं। पिछली बार 2011 में भी यही सेवा ऑफलाइन थी। फ्लेक्सीस्केल क्लाउड सेवा तक पहुंच की कमी कई दिनों तक चली। वैसे, कर्मचारी की गलती ठीक उसके कारण थी। उसने गलती से डेटा स्टोर में से एक को हटा दिया था। सौभाग्य से FlexiScale उपयोगकर्ताओं के लिए, डेटा बाद में पुनर्प्राप्त किया गया था।

कार्बोनाइट क्लाउड स्टोरेज उपयोगकर्ता इतने भाग्यशाली नहीं थे। 2009 में, ऑपरेटर ने कई ग्राहकों का डेटा खो दिया । कार्बोनाइट ने लोहे के आपूर्तिकर्ताओं पर घटना का आरोप लगाया। यह पसंद है या नहीं, यह हमारे लिए इतना महत्वपूर्ण नहीं है। नुकसान का तथ्य महत्वपूर्ण है। लिंकअप प्रदाता आमतौर पर अपने अधिकांश ग्राहकों का डेटा खो जाने के बाद अस्तित्व में नहीं रहता है।

वैसे, यह तथ्य कि एक प्रदाता आपके डेटा के साथ-साथ अस्तित्व में नहीं रह सकता है, एक और संभावित खतरा भी है। खासकर यदि डेटा को बहुत लंबे समय तक संग्रहीत करने की आवश्यकता होती है।

कारण

वर्णित समस्याओं का मुख्य स्रोत क्या है? तथ्य यह है कि एक एकल प्रदाता का उपयोग किया जाता है। बेशक, प्रदाता द्वारा उपयोग किए जाने वाले सर्वर स्तर पर अतिरेक होना बहुत अच्छा है। और कई उदाहरणों में संग्रहीत डेटा के स्तर पर। हालांकि, यह तथ्य कि क्लाउड एक ऑपरेटर, एक प्रकार के सॉफ़्टवेयर द्वारा नियंत्रित किया जाता है और, संभवतः, केंद्र द्वारा प्रबंधित किया जाता है, उपरोक्त सभी उपायों को कम कर सकता है।

क्या करें?

उत्तर स्पष्ट है। यदि डेटा उपलब्धता, और इसका अस्तित्व इतना महत्वपूर्ण नहीं है, तो चिंता न करें। या स्थानीय रूप से डेटा की एक और प्रतिलिपि सहेजें।
हैं:

• मैं बहुत लंबे समय के लिए डेटा स्टोर करना चाहता हूं
• उन्हें स्थानीय स्तर पर भी स्टोर करने का कोई तरीका नहीं है
• किसी अन्य कारण से, आपको नेटवर्क पर डेटा संग्रहीत करने की आवश्यकता है,

एक साथ कई क्लाउड डेटा स्टोरेज का उपयोग करने के लायक है। इस पोस्ट के लिए मोहक तस्वीर की तरह।

ऐसा करने के लिए, डेटा अतिरेक का उपयोग करना आवश्यक है, अर्थात अनावश्यक डेटा।
ऐसा करने का सबसे आसान तरीका डेटा प्रतिकृति का उपयोग करना है।

अपनी सादगी और पारंपरिकता के बावजूद, इस पद्धति में कई महत्वपूर्ण कमियां हैं। पहला यह है कि सर्वरों पर बहुत अधिक जगह घेर ली गई है। दूसरा यह है कि डेटा संग्रहण पर बहुत अधिक ट्रैफ़िक खर्च किया जाता है। डेटा का बैकअप लेते समय, सर्वर पर डेटा को स्टोर करना (और उन्हें अपडेट करना) सबसे आम ऑपरेशन है।

सौभाग्य से, ऐसे अन्य दृष्टिकोण हैं जो आपको डेटा उपलब्धता के स्तर को कम किए बिना, कब्जे वाले डिस्क स्थान और यातायात पर दोनों को बचाने की अनुमति देते हैं।

मैं उनके बारे में अगले भाग में विस्तार से लिखूंगा। तीसरा भाग सुरक्षा मुद्दों के लिए समर्पित होगा।