Cassandra வரிசைப்படுத்தலுக்கு ஒரே பொது தரவுத்தள வலையமைப்பு இல்லை. பயன்பாடுகள் வாடிக்கையாளர் சேவையுடன் பேசுகின்றன, தொகுதி உறுப்பினர்கள் ஒருவரோடொருவர் பேசுகிறார்கள், இயக்குநர்கள் நிர்வாக இடைமுகங்களைப் பயன்படுத்துகிறார்கள், அந்த மூன்று பார்வையாளர் குழுக்களும் ஒருவருக்கொருவர் அணுகல்தன்மையை மரபாகப் பெறக்கூடாது. VPN போன்ற தனியார் பாதை நல்ல தொடக்கப் புள்ளி, ஆனால் அது தரவுத்தளத்தின் பயனர் அடையாளம் அல்ல, அதன் மறையாக்கக் கொள்கையும் அல்ல. இணைப்பு முடிவையும் அனுமதி முடிவையும் இரண்டு தனித்த மதிப்பாய்வுகளாகக் கருதுங்கள்.

மூன்று பார்வையாளர் குழுக்களில் ஒவ்வொன்றும் அதன் சொந்த பதிலைப் பெறுகிறது, கீழேயுள்ள பகுதிகள் அவற்றை வெளிப்பாட்டு வரிசையில் எடுக்கின்றன.

மூன்று பார்வையாளர் குழுக்கள், மூன்று முடிவுகள்

ஒரு விதியைத் தொடுவதற்கு முன் ஒவ்வொரு குழுவுக்கும் உண்மையில் என்ன தேவை என்பதைக் கண்டறியுங்கள். வாடிக்கையாளர்களுக்கு வாடிக்கையாளர் கேட்பான் மற்றும் அவர்களுக்கு வழங்கப்படக்கூடிய ஒவ்வொரு முனைக்கும் அடைய போதுமான தகவல் தேவை, இணை முனைகளுக்கு internode துறையில் ஒருவருக்கொருவர் தேவை, இயக்குநர்களுக்கு runbook உண்மையில் கோருவதற்கு நிர்வாக இடைமுகம் தேவை. மூன்று பட்டியல்கள், மூன்று பார்வையாளர் குழுக்கள், மூன்று நம்பிக்கை நிலைகள்.

வழக்கமான தவறு என்னவென்றால் ஒரு தட்டையான தனியார் பகுதியைக் கட்டி VPN எல்லை மீதியைச் செய்யும் என்று கருதுவது. அதன் உள்ளே, வாடிக்கையாளர் துறையை அடையும் பயன்பாடு பொதுவாக internode துறையையும் அடையும், இயக்குநரின் நிர்வாகக் கருவிகள் பெரும்பாலும் பயன்பாட்டுடன் அதே தாவல் புரவலனில் அமர்ந்திருக்கும். அவற்றை ஒன்றாகத் தட்டையாக்குவது என்பது சமரசம் செய்யப்பட்ட பயன்பாட்டு அடையாளத்துக்கு அதன் சொந்த வினவல்களை விட அதிக அணுகல் ஏற்கனவே உள்ளது என்பதாகும். மூன்று பார்வையாளர் குழுக்களையும் வடிவமைப்பு ஆவணத்தில் மூன்று வரிசைகளாக வரையுங்கள், ஒவ்வொன்றும் அதை அனுமதிக்கும் விதியுடன், யாரும் அவற்றைக் கட்டுவதற்கு முன் இடைவெளிகள் தெரியும்.

வாடிக்கையாளர்களுக்கு என்ன தேவை, அதற்கு மேல் எதுவுமில்லை

வரிசைப்படுத்தப்பட்ட பதிப்புக்கான நோக்கமான பயன்பாட்டு மூலங்களை வாடிக்கையாளர் முனைப்புள்ளிகளுக்கு அனுமதியுங்கள், தொடர்பில்லாத தொகுதி மற்றும் நிர்வாக சேவைகளை அந்த அணுகலுக்கு வெளியே வையுங்கள். பின்னர் இயக்கி முனைகளை எப்படிக் கண்டுபிடிக்கிறது என்பதைச் சரிபாருங்கள். அடையக்கூடிய ஆரம்ப தொடர்புப் புள்ளி என்பது இயக்கி பின்னர் தேர்ந்தெடுக்கும் ஒவ்வொரு முனை முகவரியும் அந்த வாடிக்கையாளர் சூழலில் இருந்து அடையக்கூடியது என்பதை நிரூபிக்காது, ஏனெனில் இயக்கி தொகுதியிடம் இணைகளைக் கேட்டு பின்னர் தொகுதி அறிவிக்கும் முகவரிகளுடன் இணைகிறது.

அதனால்தான் தனியார் முகவரிகளில் ஒரு பொருந்தாமை பரிச்சயமான வடிவத்தை உருவாக்குகிறது: வெற்றிகரமான முதல் இணைப்பு, பின்னர் நேர முடிவுகள். அறிவிக்கப்பட்ட முகவரிகள் மற்றும் வாடிக்கையாளர் வழியமைப்பை வேண்டுமென்றே கட்டமைக்கவும்; ஒரு பொருந்தாமையைச் சரிசெய்ய முழுத் தொகுதியையும் இணையத்தில் வெளியிடுவது வழியமைப்பு பிழையை நீங்கள் திரும்பப் பெற முடியாத வெளிப்பாட்டுக்கு மாற்றுகிறது.

பயன்பாட்டின் தரவுத்தள அங்கீகாரம் மற்றும் பங்கு அனுமதிகளையும் வைத்திருங்கள். பகிரப்பட்ட மொழிபெயர்க்கப்பட்ட VPN முகவரி பல பயனர்கள் அல்லது சேவைகளைக் குறிக்கலாம், எனவே அது தனித்த தரவுத்தள அடையாளங்களுக்கு மாற்றாக ஒருபோதும் இருக்காது.

வாடிக்கையாளர்-முதல்-முனை மற்றும் internode ஆகியவற்றைத் தனித்தனியாக மறையாக்குங்கள்

Apache பாதுகாப்பு ஆவணம் வாடிக்கையாளர்-முதல்-முனை மற்றும் internode மறையாக்கத்தைத் தனித்த கட்டமைப்புகளாகக் கருதுகிறது, ஒன்றை இயக்குவது மற்றொன்றை இயக்காது. அந்த வேறுபாடு VPN உள்ளேயும் இன்னும் பொருந்தும், ஏனெனில் சுரங்கப்பாதை அதன் சொந்தப் பகுதியைப் பாதுகாக்கிறது, பயன்பாட்டு செயல்முறையிலிருந்து தரவுத்தள செயல்முறைக்கு அல்லது தொகுதி உறுப்பினர்களின் ஒவ்வொரு இணைக்கும் இடையே தானாக நீட்டிக்காது.

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

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

விருப்ப வாடிக்கையாளர் மறையாக்கத்தை அனுமதிக்கும் சேவையக கட்டமைப்புகளில், TLS ஏற்பது மறையாக்கப்படாத இணைப்புகளை ஏற்பதுடன் ஒன்றாக இருக்கலாம், எனவே நோக்கத்தை அல்ல, பயனுள்ள கொள்கையைப் படியுங்கள். ஒவ்வொரு வாடிக்கையாளரும் உண்மையில் தொடர்பு கொள்ளும் முனைப்புள்ளிகளுக்கான சான்றிதழ் பெயர்கள், நம்பிக்கைப் பங்கீடு மற்றும் புதுப்பித்தலைத் திட்டமிடுங்கள்; புரவலன் பெயரை IP முகவரியால் மாற்றுவது வாடிக்கையாளரின் அடையாளச் சரிபார்ப்பை மாற்றுகிறது, அதன் வழித்தடத்தை மட்டுமல்ல.

நிர்வாகத்தை அதன் சொந்தப் பாதையில் வையுங்கள்

internode போக்குவரத்துக்கு அனுமதிக்கப்பட்ட இணைத் தொகுப்பும் அதன் சொந்தப் பாதுகாப்புக் கொள்கையும் தேவை. நிர்வாக அணுகலுக்கு, பயன்படுத்தப்படும் இடத்தில் JMX உட்பட, தனி பார்வையாளர் குழுவும் அதன் சொந்த அங்கீகாரமும் தேவை. சாதாரண வினவல்களை வழங்க அனுமதிக்கப்பட்ட பயன்பாட்டுக்கு அதனால் ஒவ்வொரு நிர்வாக திறனும் தேவைப்படாது, எதிர்மறையானது மோசமானது: பயன்பாட்டுப் பகுதிக்கு வெளிப்படுத்தப்பட்ட நிர்வாகப் பாதை பிழையிலிருந்து மீள்கட்டமைப்புக்கு மிகக் குறுகிய பாதை. அந்த இரண்டு பார்வையாளர் குழுக்களையும் தனித்தனியாக எழுதி அவற்றின் உரிமையாளர்களைப் பெயரிடுங்கள், ஏனெனில் அவை பொதுவாக வெவ்வேறு குழுக்கள், அவற்றின் விதிகள் தற்செயலாக இணைக்கப்பட்டுள்ளன.

பயனுள்ள மேக விதிகள், புரவலன் விதிகள் மற்றும் கேட்பான் கட்டமைப்பை ஒரே வரியில் வையுங்கள். தனியார் கேட்பான் இன்னும் திட்டமிடாத மொழிபெயர்ப்பு அல்லது ப்ராக்ஸி வழியாக வெளிப்படுத்தப்படலாம், பரந்த பொது விதி யாராவது இரண்டையும் ஒரே நேரத்தில் தணிக்கை செய்யும் வரை குறுகிய VPN விதிக்கு அருகில் அமைதியாக இருக்கலாம்.

இயக்குநர்களுக்கு உண்மையில் நிர்வாகப் பாதை தேவைப்படும் இடத்தில், அதற்கு பெயரிடப்பட்ட உரிமையாளரையும் பயன்பாட்டை விடக் குறுகிய சான்று ஆயுட்காலத்தையும் கொடுங்கள். அடுத்த நபர் தொகுதியை மரபாகப் பெறும்போது ஒப்படைப்பு தெரியும் வகையில் இருக்கும்.

வடிவமைப்பு என்ன உறுதியளிக்கிறது

மூன்று உறுதிமொழிகளையும் இணைப்புச் சோதனைகளால் மட்டுமல்ல, உண்மையான பங்குகளால் சரிபார்க்கவும். அங்கீகரிக்கப்பட்ட பயன்பாடு அதன் அனுமதிக்கப்பட்ட வேலையை முடிக்க வேண்டும், அதற்கு மேல் எதுவுமில்லை, விலக்கப்பட்ட மூலம் வாடிக்கையாளர் நுழைவில் தோல்வியடைய வேண்டும், பயன்பாட்டு அடையாளம் ஒதுக்கப்பட்ட நிர்வாகப் பாதைகளில் மறுக்கப்பட வேண்டும். வாடிக்கையாளர் மறு-இணைப்பு மற்றும் முனைத் தேர்வை அதே வரிசைப்படுத்தல் சோதனையில் சேர்க்கவும், ஏனெனில் கண்டுபிடிப்பு தவறுகள் அங்கேயே வெளிப்படுகின்றன.

வடிவமைப்பு ஆவணத்தில் மூன்று வாக்கியங்களுடன் முடிக்கவும்: எந்த வாடிக்கையாளர்கள் வினவலாம், எந்த முனைகள் தொடர்பு கொள்ளலாம், எந்த இயக்குநர்கள் நிர்வகிக்கலாம். VPN பின்னால் இருப்பது பயனுள்ள இடவியல் தகவல், ஆனால் அது அந்த மூன்று கேள்விகளில் எதற்கும் பதில் அல்ல.

தொடர்புடைய கட்டுரைகள்