VPN ద్వారా Cassandra: క్లయింట్లకు మరియు నోడ్లకు వేర్వేరు యాక్సెస్

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 వెనుక ఉండటం ఉపయోగకరమైన టోపాలజీ సమాచారం, కానీ అది ఆ మూడు ప్రశ్నలలో దేనికీ సమాధానం కాదు.