VPN वरून Cassandra: क्लायंट आणि नोड्ससाठी वेगळा प्रवेश

Cassandra उपयोजनात एक सार्वत्रिक डेटाबेस नेटवर्क नसते. अनुप्रयोग क्लायंट सेवेशी बोलतात, क्लस्टर सदस्य एकमेकांशी बोलतात, आणि ऑपरेटर प्रशासकीय इंटरफेस वापरतात, आणि या तीन गटांनी एकमेकांची पोहोच वारसाहक्काने घेऊ नये. VPN सारखा खाजगी मार्ग चांगली सुरुवात आहे, पण ती डेटाबेसची वापरकर्ता ओळख नाही आणि त्याची एन्क्रिप्शन धोरण नाही. कनेक्टिव्हिटीचा निर्णय आणि अधिकृततेचा निर्णय यांना दोन वेगळ्या आढाव्यांप्रमाणे पहा.

तिन्ही गटांपैकी प्रत्येकाला स्वतःचे उत्तर मिळते, आणि खालील विभाग त्यांचा उघड होण्याच्या क्रमाने विचार करतात.

तीन गट, तीन निर्णय

कोणत्याही नियमाला हात लावण्यापूर्वी प्रत्येक गटाला प्रत्यक्षात काय आवश्यक आहे ते ओळखा. क्लायंटना क्लायंट श्रोता आणि त्यांना दिला जाऊ शकणार्‍या प्रत्येक नोडपर्यंत पोहोचण्यासाठी पुरेशी माहिती आवश्यक आहे, पीअर नोड्सना आंतर-नोड पोर्टवर एकमेकांची आवश्यकता असते, आणि ऑपरेटरना रनबुक प्रत्यक्षात जे मागते त्यासाठी व्यवस्थापन इंटरफेस आवश्यक आहे. तीन याद्या, तीन गट, विश्वासाचे तीन स्तर.

नेहमीची चूक म्हणजे एक सपाट खाजगी विभाग तयार करून VPN सीमा बाकीचे करेल असे गृहीत धरणे. त्याच्या आत, क्लायंट पोर्टपर्यंत पोहोचणारा अनुप्रयोग सामान्यतः आंतर-नोड पोर्टपर्यंतही पोहोचतो, आणि ऑपरेटरची प्रशासकीय साधने बऱ्याचदा अनुप्रयोगाच्या त्याच जंप होस्टवर असतात. हे सर्व एकत्र सपाट करणे म्हणजे तडजोड झालेल्या अनुप्रयोग ओळखीकडे आधीच स्वतःच्या क्वेरींपेक्षा जास्त पोहोच आहे. डिझाइन दस्तऐवजात तिन्ही गट तीन ओळींप्रमाणे काढा, प्रत्येकासोबत ती परवानगी देणारा नियम, आणि कोणीही ते बांधण्यापूर्वी अंतर दिसू लागतील.

क्लायंटना काय आवश्यक आहे, आणि त्यापेक्षा जास्त काही नाही

उपयोजित आवृत्तीसाठी इच्छित अनुप्रयोग स्रोतांना क्लायंट अंतबिंदूपर्यंत पोहोचू द्या, आणि असंबंधित क्लस्टर व व्यवस्थापन सेवा त्या पोहोचेबाहेर ठेवा. नंतर ड्रायव्हर नोड्स कसे शोधतो ते तपासा. उपलब्ध प्रारंभिक संपर्क बिंदू हे सिद्ध करत नाही की ड्रायव्हरने नंतर निवडलेला प्रत्येक नोड पत्ता त्या क्लायंट संदर्भातून उपलब्ध आहे, कारण ड्रायव्हर क्लस्टरला पीअरविषयी विचारतो आणि नंतर क्लस्टर जाहीर करत असलेल्या पत्त्यांशी जोडतो.

म्हणूनच खाजगी पत्त्यातील एक विसंगती परिचित नमुना निर्माण करते: यशस्वी पहिले कनेक्शन आणि त्यानंतर कालबाह्यता. जाहीर केलेले पत्ते आणि क्लायंट राउटिंग जाणीवपूर्वक संरचीत करा; एक विसंगती दुरुस्त करण्यासाठी संपूर्ण क्लस्टर इंटरनेटवर प्रकाशित करणे हे राउटिंग बगच्या बदल्यात परत घेता येणार नाही असे उघड होणे देते.

अनुप्रयोगाचे डेटाबेस प्रमाणीकरण आणि भूमिका परवानग्या देखील त्यांच्या जागी ठेवा. सामायिक अनुवादित VPN पत्ता अनेक वापरकर्ते किंवा सेवांचे प्रतिनिधित्व करू शकतो, म्हणून तो कधीही वेगळ्या डेटाबेस ओळखींचा पर्याय नाही.

क्लायंट-ते-नोड आणि आंतर-नोड वेगळे एन्क्रिप्ट करा

Apache चे सुरक्षा दस्तऐवज क्लायंट-ते-नोड आणि आंतर-नोड एन्क्रिप्शनला वेगळे संरचना मानते, आणि एक सक्षम केल्याने दुसरे सक्षम होत नाही. तो फरक VPN च्या आतही लागू होतो, कारण बोगदा स्वतःच्या विभागाचे संरक्षण करतो आणि अनुप्रयोग प्रक्रियेपासून डेटाबेस प्रक्रियेपर्यंत किंवा क्लस्टर सदस्यांच्या प्रत्येक जोडीदरम्यान आपोआप विस्तारत नाही.

दोन्ही स्पष्टपणे सुरू करणारी संरचना, टेम्पलेटचे मूलभूत मूल्य वारसाहक्काने घेण्याऐवजी, साधारणपणे अशी दिसते:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

ज्या सर्व्हर संरचनांमध्ये पर्यायी क्लायंट एन्क्रिप्शनला परवानगी आहे, तेथे TLS स्वीकारणे हे एन्क्रिप्ट न केलेली कनेक्शन स्वीकारण्याबरोबर राहू शकते, म्हणून हेतू नाही तर प्रत्यक्ष धोरण वाचा. प्रत्येक क्लायंट प्रत्यक्षात संपर्क करत असलेल्या अंतबिंदूंसाठी प्रमाणपत्रांची नावे, विश्वास वितरण आणि नूतनीकरणाचे नियोजन करा; होस्टनावाच्या जागी IP पत्ता ठेवल्यास क्लायंटची ओळख पडताळणी बदलते, केवळ त्याचा मार्ग नाही.

प्रशासन स्वतःच्या मार्गावर ठेवा

आंतर-नोड रहदारीसाठी परवानगी असलेला पीअर संच आणि स्वतःचे संरक्षण धोरण आवश्यक आहे. प्रशासकीय प्रवेशास, जेथे वापरला जातो तेथे JMX सह, वेगळा गट आणि स्वतःचे प्रमाणीकरण आवश्यक आहे. सामान्य क्वेरी देण्याची परवानगी असलेल्या अनुप्रयोगाला त्यामुळे प्रत्येक व्यवस्थापन क्षमता आवश्यक नसते, आणि उलटे अधिक वाईट आहे: अनुप्रयोग विभागासाठी उघडा प्रशासकीय मार्ग हा बगपासून पुनर्बांधणीपर्यंतचा सर्वात लहान मार्ग आहे. ते दोन गट वेगळे लिहा, आणि त्यांच्या मालकांची नावे द्या, कारण सामान्यतः ते वेगळे संघ असतात ज्यांचे नियम अपघाताने एकत्र केले गेले.

प्रत्यक्ष क्लाउड नियम, होस्ट नियम आणि श्रोता संरचना एकरेषीय ठेवा. खाजगी श्रोता अजूनही अनपेक्षित भाषांतर किंवा प्रॉक्सीमधून उघडा राहू शकतो, आणि रुंद सार्वजनिक नियम अरुंद VPN नियमाच्या शेजारी शांतपणे बसू शकतो, जोपर्यंत कोणी दोन्हींचे एकत्रितपणे अंकेक्षण करत नाही.

जेथे ऑपरेटरना खरोखर व्यवस्थापन मार्ग आवश्यक आहे, तेथे त्याला नामनिर्देशित मालक आणि अनुप्रयोगापेक्षा कमी क्रेडेन्शियल आयुष्य द्या. त्यामुळे पुढील व्यक्ती क्लस्टर वारसाहक्काने घेते तेव्हा प्रतिनिधित्व दृश्यमान राहते.

डिझाइन काय वचन देते

तिन्ही वचने केवळ कनेक्टिव्हिटी चाचण्यांनी नाही तर प्रत्यक्ष भूमिकांनी सत्यापित करा. मंजूर अनुप्रयोगाने परवानगी असलेले काम पूर्ण करावे आणि त्यापेक्षा जास्त नाही, वगळलेल्या स्रोताने क्लायंट प्रवेशद्वारावर अपयशी व्हावे, आणि अनुप्रयोग ओळख राखीव प्रशासकीय मार्गांवर नाकारली जावी. क्लायंट पुनर्जोडणी आणि नोड निवड त्याच रोलआउट चाचणीत जोडा, कारण शोधातील चुका तिथेच समोर येतात.

डिझाइन दस्तऐवजात तीन वाक्यांसह समारोप करा: कोणते क्लायंट क्वेरी करू शकतात, कोणते नोड्स संवाद साधू शकतात आणि कोणते ऑपरेटर प्रशासन करू शकतात. VPN मागे असणे ही उपयुक्त टोपोलॉजी माहिती आहे, पण ती या तीनपैकी कोणत्याही प्रश्नाचे उत्तर नाही.