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 ಹಿಂದೆ ಇರುವುದು ಉಪಯುಕ್ತ ಟೋಪೋಲಜಿ ಮಾಹಿತಿ, ಆದರೆ ಅದು ಆ ಮೂರು ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಉತ್ತರವಲ್ಲ.