பல-வாட அமைப்பு தனிமைப்படுத்தல் (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 இப்போது இறையாண்மை கொண்ட வாடிக்கையாளர்களுக்கு தனிப்பட்ட सबசைட் தரவுத்தளம் மற்றும் கோப்பு முறைமை தனிமைப்படுத்தலை ஆதரிக்கிறது. இது வாடிக்கையாளர் தரவை தனித்தனியாக வைத்திருக்கும் அதே வேளையில், பிணைய-நிலை வழங்கல் (network-level provisioning), கட்டணம் வசூலித்தல் (billing) மற்றும் நிர்வாகத்தை அப்படியே தக்க வைத்துக் கொள்கிறது.

தனிமைப்படுத்தல் உத்தி (Isolation strategy)

தரவுப் பிரிப்புக்கு அதிக தேவை உள்ள வாடிக்கையாளர்களுக்கும், பிரத்யேக கோப்பு முறைமை சேமிப்பகத்திற்கும் அல்லது தனிப்பட்ட ஹோஸ்ட் எல்லையமைப்புக்கும் தேவைப்படும் வாடிக்கையாளர்களுக்கு இறையாண்மை கொண்ட தனிமைப்படுத்தலைப் பயன்படுத்தவும்.

ஒவ்வொரு இறையாண்மை கொண்ட வாடிக்கையாளருக்கும் பின்வருபவை இருக்க வேண்டும்:

• ஹோஸ்டுக்கு அங்கீகரிக்கப்பட்ட ஒரு பிரத்யேக வாடிக்கையாளர் தரவுத்தளம் அல்லது தரவுத்தள முன்னொட்டு (database prefix) உத்தி.
• ஒரு பிரத்யேக வாடிக்கையாளர் கோப்பு முறைமை வேர் (filesystem root).
• அந்த தளத்தை அதன் தரவுத்தளம், ரூட் பாதை, ஹோஸ்ட் பெயர் மற்றும் தனிமைப்படுத்தல் மாதிரிக்கு ánhபயர்க்கும் ஒரு வாடிக்கையாளர் பதிவு நுழைவு (tenant registry entry).
• வாடிக்கையாளர் लाइव கருதப்படுவதற்கு முன்பு ஒரு இடம்பெயர்வு சரிபார்ப்பு முடிவு (migration verification result).

தரவுத்தளம் ஹோஸ்ட் பிணைப்பு (Database host binding)

பதிப்பு 1.2.0 இறையாண்மை கொண்ட நிறுவல்களுக்கான இயல்புநிலை அதே இயந்திர ஹோஸ்ட் பிணைப்பு நடத்தையை மாற்றுகிறது. localhost போன்ற அதே இயந்திர மதிப்புகள் Bedrock, FrankenPHP மற்றும் கண்டெய்னரைஸ் செய்யப்பட்ட WordPress நிறுவல்கள் MySQL உண்மையில் பார்க்கும் ஹோஸ்ட் சரத்திற்கு அனுமதி மற்றும் அனுமதிகளை வழங்க முடியும் மற்றும் சரிபார்க்க முடியும் என்பதை உறுதிப்படுத்த சாதாரணமாக்கப்படுகின்றன (normalized).

ஒரு இறையாண்மை கொண்ட வாடிக்கையாளரை கட்டமைக்கும்போது:

1. தரவுத்தள ஹோஸ்டை வாடிக்கையாளர் இயக்க நேரத்தால் (tenant runtime) தேவைப்படும் மதிப்புடன் அமைக்கவும்.
2. ஹோஸ்ட் உள்ளூர் இணைப்புகளை எதிர்பார்க்கும் போது உள்ளூர் соকেট நிறுவல்களுக்கு localhost ஐப் பயன்படுத்தவும்.
3. தரவுத்தள சேவையகம் அந்த ஹோஸ்டுக்கு சலுகைகளை வழங்கினால் மட்டுமே 127.0.0.1 அல்லது ஒரு சேவை ஹோஸ்ட் பெயரைப் பயன்படுத்தவும்.
4. ஹோஸ்ட் பிணைப்பை மாற்றிய பிறகு இடம்பெயர்வு சரிபார்ப்பைச் இயக்கவும்.

சரிபார்ப்பு தோல்வி அளித்தால், வாடிக்கையாளர் தரவுத்தள பயனரின் அனுமதிகளை கட்டமைக்கப்பட்ட ஹோஸ்ட் பிணைப்புடன் ஒப்பிட்டுப் பார்க்கவும். user@localhost க்கு வழங்கப்பட்ட பயனர் என்பது [email protected] அல்லது user@% உடன் வேறுபட்டது.

கோப்பு முறைமை வேர் (Filesystem root)

டென்யன்ட் ரூட் (tenant root) மறுதொடக்கம் மற்றும் வரிசைப்படுத்தல் (deployments) முழுவதும் நிலையாக இருக்க வேண்டும். தற்காலிக மாவுண்ட் பாதைகளைத் தவிர்க்கவும். Bedrock பாணியிலான நிறுவல்களுக்கு, டென்யன்ட் ரூட் என்பது திட்டத்தின் மூலத்தை மட்டுமல்லாமல், டென்யன்ட் பூட்ஸ்டிராப் (bootstrap) எதிர்பார்க்கும் WordPress வலை மூலத்தையும் சுட்டிக்காட்டுவதை உறுதிப்படுத்தவும்.

வழங்குவதற்கான வரிசை (Provisioning order)

புதிய இறையாண்மை டென்யன்ட்களுக்கு, இந்த வரிசையைப் பயன்படுத்தவும்:

1. டென்யன்ட் ரெஜிஸ்ட்ரி உள்ளீட்டை உருவாக்கவும்.
2. டென்யன்ட் தரவுத்தளம் மற்றும் தரவுத்தள பயனரை உருவாக்கவும்.
3. டென்யன்ட் ஸ்கீமாவை பூட்ஸ்டிராப் செய்யவும்.
4. டென்யன்ட் பயனர்களை வழங்கவும்.
5. டென்யன்ட் கோப்பு முறைமை பாதைகளை (filesystem paths) கட்டமைக்கவும்.
6. இடம்பெயர்வு சரிபார்ப்பைச் இயக்கவும் (Run migration verification).
7. சரிபார்ப்பு முடிந்த பிறகு ரூட்டிங் அல்லது DNS-ஐ மாற்றவும்.

இந்த வரிசை, தரவுத்தள எழுத்தாளர்கள் (database writer), பயனர்கள் மற்றும் கோப்பு முறைமை ஆகியவை தயாராகும் முன்பே பகுதி தனிமைப்படுத்தப்பட்ட டென்யன்ட்கள் போக்குவரத்தைப் பெறாமல் இருப்பதை உறுதி செய்கிறது.

இறையாண்மை வாடிக்கையாளர் மேலாண்மை ஓட்டங்கள் (Sovereign customer management flows)

Ultimate Multisite v2.13.0 இல், இறையாண்மை முறை (sovereign mode) செயல்படுத்தப்படும்போது, வாடிக்கையாளர் மேலாண்மை செயல்கள் பிரதான தளத்தில் (main site) இருக்கும். ஒரு டென்யன்ட் தனிமைப்படுத்தப்பட்ட WordPress நிறுவலாக இயங்க முடியும் என்றாலும், பிணைய கட்டணங்கள் (network billing), உறுப்பினர் தகுதிகள் (membership) அல்லது பகிரப்பட்ட கணக்கு தரவு ஆகியவற்றைப் பொறுத்த வாடிக்கையாளர் சார்ந்த செயல்பாடுகள், அந்தச் செயலை டென்யன்ட்运行时 (tenant runtime) முடிக்க முயற்சிக்காமல், வாடிக்கையாளரை பிரதான தளத்திற்கு அனுப்ப வேண்டும்.

பிரதான தள ஓட்டம் பின்வருவனவற்றிற்கு பொருந்தும்:

• செக்அவுட் மற்றும் திட்ட மாற்றங்கள் (Checkout and plan changes).
• கணக்கு கண்ணோட்டம் மற்றும் வாடிக்கையாளர் சுயவிவர செயல்பாடுகள் (Account overview and customer profile actions).
• கட்டண முகவரி புதுப்பிப்புகள் மற்றும் கட்டண மேலாண்மை திரைகள் (Billing address updates and payment-management screens).
• விலைப்பட்டியல் மற்றும் கட்டண வரலாறு காட்சிகள் (Invoice and payment-history views).
• தளங்களைச் சேர்த்தல் அல்லது நீக்குதல் போன்ற தள மேலாண்மை செயல்பாடுகள் (Site management actions such as adding sites or deleting a site).
• டெம்ப்ளேட் மாற்றுதல் (Template switching).
• டொமைன் வரைபடம் மற்றும் முதன்மை டொமைன் மாற்றங்கள் (Domain mapping and primary-domain changes).

ஒரு வாடிக்கையாளர் ஒரு இறையாண்மை டெண்டன்ட் (sovereign tenant) இலிருந்து இவற்றில் ஏதேனும் ஒரு செயலைத் தொடங்கும்போது, Ultimate Multisite அதற்குரிய பிரதான தளத்தின் URL-ஐ உருவாக்கும் மற்றும் பாதுகாப்பாக இருக்கும்போது மூல டெண்டன்ட்டை திரும்பும் இலக்காக (return target) தக்கவைத்துக் கொள்ளும். இது வாடிக்கையாளர்கள் நெட்வொர்க் பதிவுகளுக்கு எதிராக அந்த நிர்வாகச் செயலை முடித்துவிட்டு, இறையாண்மை தரவுத்தளத்தில் கட்டணம் அல்லது உறுப்பினர் நிலையை நகலெடுக்காமல் டெண்டன்ட் சூழலுக்குத் திரும்ப அனுமதிக்கிறது.

ஆபரேட்டர்களுக்கு, நடைமுறை விதி என்னவென்றால்: இறையாண்மை நெட்வொர்க்குகளுக்காகப் பணம் செலுத்துதல் (billing), கணக்கு (account), செக்அவுட் (checkout), விலைப்பட்டியல் (invoice), டெம்ப்ளேட் (template) மற்றும் டொமைன் மேலாண்மை (domain-management) பக்கங்கள் பிரதான தளத்தில் கிடைக்கச் செய்யப்பட வேண்டும். டெண்டன்ட் டாஷ்போர்டுகள் அந்தப் பக்கங்களுக்கு இணைக்க முடியும், ஆனால் செயலுக்கான மூல ஆதாரமாக (source of truth) பிரதான தளம் தொடர்ந்து இருக்கும்.