होस्टिंग मॉडल की तुलना उनके द्वारा सौंपी गई संचालन जिम्मेदारियों और उनके द्वारा सक्षम आर्किटेक्चर के आधार पर करें। क्लाउड स्केल, एक वर्चुअल मशीन और समर्पित हार्डवेयर किसी सिस्टम के अलग-अलग पहलुओं का वर्णन करते हैं; इनमें से कोई अकेला गोपनीयता, लागत या रिकवरी व्यवहार सिद्ध नहीं करता।
उस काम से शुरू करें जिसका स्वामित्व आप किसी को देना चाहते हैं
होस्टिंग निर्णय कंप्यूटिंग संसाधनों के साथ-साथ संचालन कार्य भी सौंपता है। एक प्रोजेक्ट को ऐसा खाता चाहिए जो पारंपरिक वेबसाइट चलाए; दूसरे को ऑपरेटिंग-सिस्टम पैकेज और पृष्ठभूमि प्रक्रियाओं पर नियंत्रण चाहिए। तीसरे को ऐसा डेटाबेस प्लेटफ़ॉर्म चाहिए जिसका रखरखाव किसी विशिष्ट सेवा अनुबंध के अंतर्गत होता हो। पहले उन जिम्मेदारियों की सूची बनाएँ, साथ ही उन्हें निभाने के लिए उपलब्ध लोगों की भी।
साझा होस्टिंग आम तौर पर खाता-स्तरीय वातावरण देती है। एक VPS अतिथि ऑपरेटिंग सिस्टम उजागर करता है, जबकि समर्पित हार्डवेयर मशीन सीमा को भौतिक सर्वर तक ले जाता है। प्रबंधित एक अलग प्रश्न है: उत्पाद लेबल यह नहीं बताता कि पैच कौन लगाता है, डेटा कौन पुनर्स्थापित करता है या घटना की जाँच कौन करता है। इसे सार्वभौमिक सुविधा मानने के बजाय प्रबंधन का दायरा और रिकवरी प्रक्रिया माँगें।
समझें कि क्लाउड तुलना में क्या जोड़ता है
NIST क्लाउड कंप्यूटिंग का वर्णन माँग-आधारित पहुँच, संसाधन पूलिंग, लोच और मापी गई सेवा जैसी विशेषताओं के माध्यम से करता है। एक वर्चुअल मशीन क्लाउड प्लेटफ़ॉर्म का एक घटक हो सकती है, इसलिए VPS और क्लाउड परस्पर अनन्य तकनीकें नहीं हैं। उपयोगी तुलना विशिष्ट दी जाने वाली सेवाओं के बीच है: एक निश्चित वर्चुअल मशीन, एक लोचदार फ्लीट या प्रबंधित सेवाओं के इर्द-गिर्द बनाया गया एप्लिकेशन।
हाइपरस्केलर उद्योग का एक शब्द है ऐसे प्रदाता के लिए जो बहुत बड़े पैमाने पर अवसंरचना और सेवा प्लेटफ़ॉर्म संचालित करता है। वह पैमाना विविध प्रकार के डिप्लॉयमेंट टूल और भौगोलिक विकल्प दे सकता है; यह नहीं बताता कि कोई विशिष्ट आर्किटेक्चर आपकी आवश्यकताएँ पूरी करता है। प्रत्येक घटक के क्षेत्र, सेवा निर्भरताओं, पहचान मॉडल और अनुबंध का मूल्यांकन करें। छोटे प्रदाता और बड़े प्लेटफ़ॉर्म दोनों के लिए यह स्पष्ट लेखा आवश्यक है कि डेटा कहाँ जाता है।
| संचालन मॉडल | प्रोजेक्ट के लिए उपलब्ध नियंत्रण | चुनने से पहले प्रश्न |
|---|---|---|
| साझा होस्टिंग खाता | खाता दायरे के भीतर साइट सेटिंग्स | क्या रनटाइम एप्लिकेशन के अनुकूल है? |
| वर्चुअल मशीन | अतिथि OS और स्थापित सेवाएँ | अतिथि का रखरखाव और पुनर्स्थापन कौन करता है? |
| समर्पित मशीन | एक भौतिक सर्वर सीमा | क्या वर्कलोड इस सीमा को उचित ठहराता है? |
| प्रबंधित क्लाउड सेवा | सेवा API और समर्थित सेटिंग्स | ग्राहक की जिम्मेदारी क्या बनी रहती है? |
ऐसी आर्किटेक्चर चुनें जो रिकवर कर सके
छोटे एप्लिकेशन के लिए एक ही मशीन उचित शुरुआत हो सकती है जब उसकी रिकवरी आवश्यकताएँ पुनर्स्थापन या नियोजित रखरखाव विंडो की अनुमति देती हों। दूसरा एप्लिकेशन नोड जोड़ना डिज़ाइन को तभी बदलता है जब ट्रैफ़िक रूटिंग, सत्र और स्थायी डेटा दोनों पर सही ढंग से काम करें। समान अपूर्ण रिकवरी योजना चलाने वाले दो सर्वर अभी भी एक अपूर्ण रिकवरी योजना हैं।
वितरित स्टोरेज इस अंतर को दर्शाता है। Ceph जैसा सॉफ़्टवेयर स्टोरेज कार्य को क्लस्टर में फैलाता है और ऑब्जेक्ट, ब्लॉक और फ़ाइल इंटरफ़ेस देता है। प्रतिकृति या इरेज़र कोडिंग विशिष्ट हार्डवेयर विफलताओं को सहन करने में मदद कर सकती है, लेकिन क्लस्टर को रिकवरी और रीबैलेंसिंग के लिए क्षमता भी चाहिए। वितरित लाइव प्रति स्वतंत्र बैकअप की जगह नहीं लेती। तय करें कि नेटवर्क विभाजन के दौरान लेखन कैसे व्यवहार करेगा और अपने चुने हुए कार्यान्वयन से संबंधित विफलता मामलों का परीक्षण करें।
पूर्ण संचालन बजट की तुलना करें
बजट को वर्कलोड के रूप में लिखें: सामान्य ट्रैफ़िक, व्यस्त अंतराल, संग्रहीत डेटा, बैकअप प्रतिधारण और रिकवरी के लिए आवश्यक स्थानांतरण। सशुल्क सॉफ़्टवेयर, बाहरी API, प्रशासन समय और डेटा दोबारा स्थानांतरित करने की लागत शामिल करें। शुरुआती मासिक आँकड़ा और उपयोग-आधारित अनुमान अलग-अलग प्रश्नों के उत्तर देते हैं। उनकी तुलना समान अवधि पर करें और परिणाम के साथ अनुमान रखें।
बड़े क्लाउड प्लेटफ़ॉर्म के लिए, एप्लिकेशन को चालू रखने के लिए आवश्यक प्रत्येक सेवा की पहचान करें। एक VPS के लिए, वह काम शामिल करें जो प्रबंधित सेवाएँ अन्यथा सँभाल लेतीं। कोई भी दृष्टिकोण स्वतः सस्ता नहीं है। एक छोटे प्रतिनिधि डिप्लॉयमेंट या दस्तावेज़ीकृत कोटेशन से शुरू करें, फिर वास्तविक बिल की मॉडल से तुलना करें। केवल स्थिर स्थिति का बजट बनाने के बजाय रिकवरी ट्रैफ़िक और अस्थायी माइग्रेशन क्षमता के लिए जगह रखें।
गोपनीयता को निर्भरता मानचित्र मानें
मशीन का क्षेत्र व्यापक मानचित्र में एक प्रविष्टि है। प्रमाणीकरण, निगरानी, सहायता टूल, बैकअप और मॉडल API अलग-अलग सेवाओं के माध्यम से संचालित हो सकते हैं। दर्ज करें कि प्रत्येक को क्या मिलता है, कौन उस तक पहुँच सकता है और यह कितने समय तक रखा जाता है। AWS का साझा-जिम्मेदारी मॉडल एक उदाहरण है जहाँ प्रदाता अपने अवसंरचना कर्तव्यों को ग्राहक कर्तव्यों से स्पष्ट रूप से अलग करता है; सेवा के साथ दायरा बदलता है।
प्रदाताओं की तुलना करते समय उस अंतर का उपयोग करें, बिना एक प्रदाता के दायित्वों को दूसरे अनुबंध में आरोपित किए। एक SwissOctet कॉन्फ़िगरेशन होस्टिंग स्थान और सूचीबद्ध संसाधनों का वर्णन करता है। यह उन इंटीग्रेशन का स्थान स्थापित नहीं करता जो आप बाद में जोड़ते हैं। प्रत्येक निर्भरता को मिलने वाला डेटा न्यूनतम करें, प्रशासन सुरक्षित करें और अपने एप्लिकेशन की डेटा यात्रा के बारे में कथन देने से पहले बैकअप गंतव्यों को सत्यापित करें।
निर्णय के भाग के रूप में माइग्रेशन पथ का उपयोग करें
जाँचें कि आप एप्लिकेशन डेटा, कॉन्फ़िगरेशन और पहचानें कैसे निर्यात कर सकते हैं। वर्चुअल मशीन पर पारंपरिक एप्लिकेशन को स्थानांतरित करना सीधा हो सकता है, जबकि सेवा-विशिष्ट डेटाबेस या इवेंट सिस्टम को अनुकूलन की आवश्यकता हो सकती है। पोर्टेबिलिटी संचालन ज्ञान पर भी निर्भर करती है: जिस बैकअप को पुनर्स्थापित करना किसी को न आता हो, वह कमजोर निकास योजना है, भले ही उसका प्रारूप खुला हो।
पहली SwissOctet शॉर्टलिस्ट के लिए, Canvas की तुलना तब करें जब खाता-स्तरीय वेब वातावरण उपयुक्त हो, अतिथि OS नियंत्रण के लिए Vector और जब भौतिक सीमा मायने रखती हो तो Metal रेंज। स्टोरेज-केंद्रित विकल्प एक अलग क्षमता प्रश्न का समर्थन करते हैं और उन्हें प्रबंधित वितरित क्लस्टर नहीं कहा जाना चाहिए। आर्किटेक्चर को संचालित करने योग्य छोटा रखें, और प्लेटफ़ॉर्म जटिलता तब जोड़ें जब वह परीक्षित आवश्यकता को संबोधित करे, न कि कल्पित भविष्य के पैमाने को।
आपकी व्यावहारिक चेकलिस्ट।
- प्रशासन और रिकवरी का स्वामित्व सौंपें।
- VM को व्यापक क्लाउड प्लेटफ़ॉर्म से अलग करें।
- निर्भरताओं, स्थानांतरण और रखरखाव का बजट बनाएँ।
- नोड जोड़ने से पहले विफलता सीमा का परीक्षण करें।
- एक व्यावहारिक डेटा निर्यात और माइग्रेशन पथ दर्ज करें।
महत्वपूर्ण विवरण।
क्या एक VPS क्लाउड प्लेटफ़ॉर्म का हिस्सा हो सकता है?+
हाँ। एक वर्चुअल मशीन क्लाउड सेवा हो सकती है। यह मानने के बजाय कि नाम अनन्य तकनीकों का वर्णन करते हैं, वास्तविक संसाधन, स्केलिंग और प्रबंधन मॉडल की तुलना करें।
क्या वितरित स्टोरेज बैकअप की जगह लेता है?+
नहीं। लाइव रिडंडेंसी चुने हुए घटक विफलताओं को संबोधित करती है। एक स्वतंत्र बैकअप और पुनर्स्थापन परीक्षण अन्य विफलताओं जैसे विलोपन और क्षतिग्रस्त एप्लिकेशन डेटा को संबोधित करते हैं।
क्या बड़ा क्लाउड हमेशा गोपनीयता के लिए खराब विकल्प है?+
नहीं। विशिष्ट सेवाओं, डेटा प्रवाह और संविदात्मक नियंत्रणों का मूल्यांकन करें। अकेला प्रदाता आकार आर्किटेक्चर की उपयुक्तता स्थापित नहीं करता।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- NIST SP 800-145: क्लाउड कंप्यूटिंग की परिभाषा nvlpubs.nist.gov
- AWS: साझा जिम्मेदारी मॉडल aws.amazon.com
- Ceph: स्टोरेज आर्किटेक्चर docs.ceph.com
- Ceph: इरेज़र कोडिंग docs.ceph.com
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।