मल्टी-टेनन्सी आयसोलेशन (Multi-Tenancy Isolation)
Ultimate Multisite: Multi-Tenancy 1.2.0 आता आहे, जो सॉवरेन टेनंट्ससाठी प्रति-सबसाइट डेटाबेस आणि फाईलसिस्टम आयसोलेशनला समर्थन देतो. यामुळे नेटवर्क-स्तरीय प्रोव्हिजनिंग, बिलिंग आणि प्रशासनाचे स्वरूप कायम राहते, तर टेनंट डेटा वेगळा ठेवता येतो.
आयसोलेशन स्ट्रॅटेजी (Isolation strategy)
ज्या ग्राहकांना अधिक मजबूत डेटा वेगळेपणा, समर्पित फाईलसिस्टम स्टोरेज किंवा वेगळी होस्ट बाउंड्री (host boundary) आवश्यक आहे त्यांच्यासाठी सॉवरेन आयसोलेशनचा वापर करा.
प्रत्येक सॉवरेन टेनंटकडे खालील गोष्टी असाव्यात:
- होस्टसाठी मंजूर केलेले एक समर्पित टेनंट डेटाबेस किं वा डेटाबेस प्रीफिक्स स्ट्रॅटेजी.
- एक समर्पित टेनंट फाईलसिस्टम रूट (root).
- एक टेनंट रजिस्ट्री एंट्री जी साइटला त्याच्या डेटाबेस, रूट पाथ, होस्टनाव आणि आयसोलेशन मॉडेलशी मॅप करते.
- टेनंट लाइव्ह मानण्यापूर्वी एक मायग्रेशन व्हेरिफिकेशन रिझल्ट.
डेटाबेस होस्ट बाइंडिंग (Database host binding)
Version 1.2.0 मध्ये सॉवरेन इन्स्टॉल्ससाठी डिफॉल्ट सेम-मशीन होस्ट बाइंडिंग वर्तनात बदल करण्यात आले आहेत. localhost सारखे सेम-मशीन व्हॅल्यूज सामान्यकृत (normalized) केल्या जातात, जेणेकरून Bedrock, FrankenPHP आणि कंटेनराईज्ड WordPress इन्स्टॉल्स MySQL प्रत्यक्षात पाहणाऱ्या होस्ट स्ट्रिंगविरुद्ध परवानग्या देऊ शकतील आणि सत्या पित करू शकतील.
सॉवरेन टेनंट कॉन्फिगर करताना:
- डेटाबेस होस्टला टेनंट रनटाइमद्वारे आवश्यक असलेल्या मूल्यावर सेट करा.
- जेव्हा होस्ट स्थानिक कनेक्शन अपेक्षित करते, तेव्हा लोकल सॉकेट इन्स्टॉल्ससाठी
localhostवापरा. - फक्त तेव्हाच
127.0.0.1किंवा सर्व्हिस होस्टनेम वापरावा जेव्हा डेटाबेस सर्व्हर त्या होस्टला विशेषाधिकार (privileges) देतो. - होस्ट बाइंडिंग बदलल्यानंतर मायग्रेशन व्हेरिफिकेशन चालवा.
जर व्हेरिफिकेशन रिपोर्टमध्ये ग्रँट फेल्युअर (grant failures) दर्शवले, तर टेनंट DB युजरच्या ग्रँट्सची कॉन्फिगर केलेल्या होस्ट बाइंडिंगशी तुलना करा. user@localhost साठी दिलेला यूजर [email protected] किंवा user@% पेक्षा वेगळा असतो.
फाईलसिस्टम रूट (Filesystem root)
भाडेकरू रूट रीस्टार्ट आणि डिप्लॉयमेंट दरम्यान स्थिर असावा. तात्पुरत्या माउंट पाथ टाळा. Bedrock-शैलीतील इन्स्टॉल्ससाठी, तपासा की टेनंट रूट तुमच्या टेनंट बूटस्ट्रॅपद्वारे अपेक्षित असलेल्या वर्डप्रेस वेब रूटवर पॉइंट करत आहे, केवळ प्रोजेक्ट रूटवर नाही.
प्रोव्हिजनिंग क्रम (Provisioning order)
नवीन सॉव्हेरेन टेनंट्ससाठी, हा क्रम वापरा:
१. टेनंट रजिस्ट्री एंट्री तयार करा. २. टेनंट डेटाबेस आणि डेटाबेस युजर तयार करा. ३. टेनंट स्कीमा बूटस्ट्रॅप करा. ४. टेनंट युजर्स प्रोव्हिजन करा. ५. टेनंट फाईलसिस्टम पाथ कॉन्फिगर करा. ६. मायग्रेशन व्हेरिफिकेशन रन करा. ७. व्हेरिफिकेशन पास झाल्यानंतर रूटिंग कि ंवा DNS बदला.
हा क्रम डेटाबेस रायटर, युजर्स आणि फाईलसिस्टम तयार होण्यापूर्वी आंशिकरित्या वेगळे केलेले टेनंट ट्रॅफिक स्वीकारू नये म्हणून मदत करतो.
सॉव्हेरेन ग्राहक व्यवस्थापन प्रवाह (Sovereign customer management flows)
Ultimate Multisite v2.13.0 मध्ये सॉव्हेरेन मोड सक्षम असताना, ग्राहक व्यवस्थापनाचे कार्य मुख्य साइटवर ठेवले जाते. एक टेनंट अजूनही वेगळे वर्डप्रेस इन्स्टॉल म्हणून चालू शकतो, परंतु नेटवर्क बिलिंग, सदस्यता किंवा सामायिक खाते डेटावर अवलंबून असलेल्या ग्राहकांशी संबंधित क्रिया (customer-facing actions) हे टेनंट रनटाइममध्ये पूर्ण करण्याचा प्रय त्न करण्याऐवजी ग्राहकाला मुख्य साइटवर परत पाठवावेत.
मुख्य-साइट प्रवाह खालील गोष्टींसाठी लागू होतो:
- चेकआउट आणि प्लॅन बदल.
- खाते ओव्हरव्ह्यू आणि ग्राहक प्रोफाइल क्रिया.
- बिलिंग पत्ता अद्यतने आणि पेमेंट-व्यवस्थापन स्क्रीन.
- इन्व्हॉइस आणि पेमेंट-इतिहास दृश्ये.
- साइट जोडणे किंवा साइट हटवणे यांसारखी साइट व्यवस्थापन क्रिया.
- टेम्पलेट स्विच करणे.
- डोमेन मॅपिंग आणि प्राथमिक-डोमेन बदल.
जेव्हा ग्राहक एका सॉवरेन टेनंटमधून (sovereign tenant) एखादी क्रिया सुरू करतो, तेव्हा Ultimate Multisite त्या संबंधित मुख्य-साइट URL तयार करते आणि सुरक्षित असल्यास मूळ टेनंटला परत येण्यासाठी सोर्स टेनंट म्हणून जतन करते. यामुळे ग्राहक नेटवर्क रेकॉर्ड्सविरुद्ध व्यवस्थापित कृती पूर्ण करू शकतात आणि सॉवरेन डेटाबेसमध्ये बिलिंग किंवा मेंबरशिप स्थितीची डुप्लिकेशन टाळ ू शकतात.
ऑपरेटर्ससाठी, व्यावहारिक नियम असा आहे: सॉवरेन नेटवर्क्ससाठी बिलिंग, खाते (account), चेकआउट, इनव्हॉइस, टेम्पलेट आणि डोमेन व्यवस्थापन पृष्ठ मुख्य साइटवर उपलब्ध ठेवा. टेनंट डॅशबोर्ड त्या पृष्ठांशी लिंक करू शकतात, परंतु कृतीचा मूळ स्रोत (source of truth) मुख्य साइटच राहते.