ಹೇ ಹಬ್ರ್! ನಾನು ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಲೇಖನದ ಅನುವಾದವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇನೆ ಆಂಡ್ರ್ಯೂ ಬೀಖೋಫ್ ಅವರಿಂದ.
ಅನೇಕ ಜನರು ಎರಡು-ನೋಡ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಬಯಸುತ್ತಾರೆ ಏಕೆಂದರೆ ಅವುಗಳು ಕಲ್ಪನಾತ್ಮಕವಾಗಿ ಸರಳವೆಂದು ತೋರುತ್ತದೆ ಮತ್ತು ಅವರ ಮೂರು-ನೋಡ್ ಕೌಂಟರ್‌ಪಾರ್ಟ್‌ಗಳಿಗಿಂತ 33% ಅಗ್ಗವಾಗಿದೆ. ಎರಡು ನೋಡ್ಗಳ ಉತ್ತಮ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಒಟ್ಟುಗೂಡಿಸಲು ಸಾಕಷ್ಟು ಸಾಧ್ಯವಾದರೂ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪರಿಗಣಿಸದ ಸನ್ನಿವೇಶಗಳಿಂದಾಗಿ, ಅಂತಹ ಸಂರಚನೆಯು ಅನೇಕ ಅಸ್ಪಷ್ಟ ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಯಾವುದೇ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವ ಮೊದಲ ಹಂತವೆಂದರೆ ವೈಫಲ್ಯದ ವೈಯಕ್ತಿಕ ಅಂಶಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮತ್ತು ತೊಡೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸುವುದು, ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಸ್ಪಿಒಎಫ್ (ವೈಫಲ್ಯದ ಏಕ ಬಿಂದು).
ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅಲಭ್ಯತೆಯ ಎಲ್ಲಾ ಸಂಭವನೀಯ ಅಪಾಯಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಅಸಾಧ್ಯವೆಂದು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಅಪಾಯದ ವಿರುದ್ಧ ವಿಶಿಷ್ಟವಾದ ರಕ್ಷಣೆಯು ಕೆಲವು ಪುನರಾವರ್ತನೆಯನ್ನು ಪರಿಚಯಿಸುವುದು ಎಂಬ ಅಂಶದಿಂದ ಇದು ಉದ್ಭವಿಸುತ್ತದೆ, ಇದು ಹೆಚ್ಚಿದ ಸಿಸ್ಟಮ್ ಸಂಕೀರ್ಣತೆ ಮತ್ತು ವೈಫಲ್ಯದ ಹೊಸ ಬಿಂದುಗಳ ಹೊರಹೊಮ್ಮುವಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಆರಂಭದಲ್ಲಿ ರಾಜಿ ಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ವೈಫಲ್ಯದ ವೈಯಕ್ತಿಕ ಅಂಶಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಘಟನೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಸಂಬಂಧಿತ ಮತ್ತು ಆದ್ದರಿಂದ ಕಡಿಮೆ ಸಂಭವನೀಯ ಘಟನೆಗಳ ಸರಪಳಿಗಳ ಮೇಲೆ ಅಲ್ಲ.
ಟ್ರೇಡ್-ಆಫ್‌ಗಳನ್ನು ನೀಡಿದರೆ, ನಾವು SPoF ಅನ್ನು ಮಾತ್ರ ನೋಡುವುದಿಲ್ಲ, ಆದರೆ ಅಪಾಯಗಳು ಮತ್ತು ಪರಿಣಾಮಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸುತ್ತೇವೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ಯಾವುದು ನಿರ್ಣಾಯಕ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ ಎಂಬ ತೀರ್ಮಾನವು ಪ್ರತಿ ನಿಯೋಜನೆಗೆ ಭಿನ್ನವಾಗಿರಬಹುದು.
ಎಲ್ಲರಿಗೂ ಸ್ವತಂತ್ರ ವಿದ್ಯುತ್ ಮಾರ್ಗಗಳೊಂದಿಗೆ ಪರ್ಯಾಯ ವಿದ್ಯುತ್ ಸರಬರಾಜುದಾರರ ಅಗತ್ಯವಿಲ್ಲ. ಅವರ ಮೇಲ್ವಿಚಾರಣೆಯು ದೋಷಪೂರಿತ ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿದಾಗ ಕನಿಷ್ಠ ಒಬ್ಬ ಗ್ರಾಹಕನಿಗೆ ಮತಿವಿಕಲ್ಪವು ಪಾವತಿಸಿದ್ದರೂ ಸಹ. ದೋಷಪೂರಿತ ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್ ಸ್ಫೋಟಗೊಳ್ಳುವವರೆಗೂ ಗ್ರಾಹಕರು ಫೋನ್ ಕರೆಗಳನ್ನು ಮಾಡಿ ವಿದ್ಯುತ್ ಕಂಪನಿಯನ್ನು ಎಚ್ಚರಿಸಲು ಪ್ರಯತ್ನಿಸಿದರು.
ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದು ನೈಸರ್ಗಿಕ ಆರಂಭಿಕ ಹಂತವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ವೈಫಲ್ಯದ ನಂತರ ಸಿಸ್ಟಮ್ ಸೇವೆಗಳನ್ನು ಉಳಿದಿರುವ ನೋಡ್‌ಗೆ ಚಲಿಸುವ ಮೊದಲು, ಸರಿಸಲಾಗುತ್ತಿರುವ ಸೇವೆಗಳು ಬೇರೆಡೆ ಸಕ್ರಿಯವಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಿದೆ.
ಎರಡೂ ನೋಡ್‌ಗಳು ಒಂದೇ ಸ್ಥಿರ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವಲ್ಲಿ ವಿಫಲವಾದರೆ ಎರಡು-ನೋಡ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಫಲಿತಾಂಶವು ಎರಡೂ ಪಕ್ಷಗಳು ಸ್ವತಂತ್ರವಾಗಿ ಹಂಚಿಕೆಯ ಉದ್ಯೋಗ ಸರದಿಯನ್ನು ನಿರ್ವಹಿಸಿದರೆ ಅಥವಾ ಪುನರಾವರ್ತಿತ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಹಂಚಿದ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗೆ ಅಸಂಘಟಿತ ಬರವಣಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಿದರೆ ವಿಷಯಗಳು ಬದಲಾಗುತ್ತವೆ.
ಆದ್ದರಿಂದ, ಒಂದೇ ನೋಡ್ ವೈಫಲ್ಯದ ಪರಿಣಾಮವಾಗಿ ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರವನ್ನು ತಡೆಗಟ್ಟಲು - ನಾವು ಯಾವುದನ್ನಾದರೂ ಕರೆಯುತ್ತೇವೆ "ವಿಯೋಗ" (ಫೆನ್ಸಿಂಗ್).
ವಿಘಟನೆಯ ತತ್ವ
ವಿಘಟನೆಯ ತತ್ವದ ಹೃದಯಭಾಗದಲ್ಲಿ ಪ್ರಶ್ನೆ ಇದೆ: ಸ್ಪರ್ಧಾತ್ಮಕ ನೋಡ್ ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು? ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರವು ಸಂಭವನೀಯ ಸನ್ನಿವೇಶವಾಗಿದ್ದರೆ, ಒಳಬರುವ ವಿನಂತಿಗಳು ಮತ್ತು ನಿರಂತರ ಸಂಗ್ರಹಣೆ ಎರಡರಿಂದಲೂ ನೋಡ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ದೋಷಯುಕ್ತ ನೋಡ್‌ಗಳನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವುದು ವಿಘಟನೆಗೆ ಸಾಮಾನ್ಯ ವಿಧಾನವಾಗಿದೆ.
ವಿಘಟನೆಯ ವಿಧಾನಗಳಲ್ಲಿ ಎರಡು ವರ್ಗಗಳಿವೆ, ಅದನ್ನು ನಾನು ಕರೆಯುತ್ತೇನೆ ನೇರ и ಪರೋಕ್ಷ, ಆದರೆ ಅವುಗಳನ್ನು ಸಮಾನವಾಗಿ ಕರೆಯಬಹುದು ಸಕ್ರಿಯ и ನಿಷ್ಕ್ರಿಯ. ನೇರ ವಿಧಾನಗಳು IPMI (ಇಂಟೆಲಿಜೆಂಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಇಂಟರ್ಫೇಸ್) ಅಥವಾ iLO (ಅವರಿಗೆ ಭೌತಿಕ ಪ್ರವೇಶದ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಕಾರ್ಯವಿಧಾನ) ಸಾಧನದೊಂದಿಗೆ ಸಂವಹನದಂತಹ ಉಳಿದಿರುವ ಗೆಳೆಯರ ಭಾಗದಲ್ಲಿನ ಕ್ರಿಯೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಆದರೆ ಪರೋಕ್ಷ ವಿಧಾನಗಳು ವಿಫಲವಾದವುಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ. ಇದು ಅನಾರೋಗ್ಯಕರ ಸ್ಥಿತಿಯಲ್ಲಿದೆ ಎಂದು ಹೇಗಾದರೂ ಗುರುತಿಸಲು ನೋಡ್ (ಅಥವಾ ಕನಿಷ್ಠ ಇತರ ಸದಸ್ಯರು ಚೇತರಿಸಿಕೊಳ್ಳುವುದನ್ನು ತಡೆಯುತ್ತದೆ) ಮತ್ತು ಸಂಕೇತ ವಿಫಲವಾದ ನೋಡ್ ಅನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವ ಅಗತ್ಯತೆಯ ಬಗ್ಗೆ.
ನೇರ ಮತ್ತು ಪರೋಕ್ಷ ವಿಧಾನಗಳನ್ನು ಬಳಸುವಾಗ ಕೋರಮ್ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ನೇರ ವಿಘಟನೆ
ನೇರ ವಿಘಟನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ವಿಘಟನೆಯ ರೇಸ್‌ಗಳನ್ನು ತಡೆಯಲು ನಾವು ಕೋರಮ್ ಅನ್ನು ಬಳಸಬಹುದು.
ಕೋರಮ್‌ನ ಪರಿಕಲ್ಪನೆಯೊಂದಿಗೆ, ನೋಡ್‌ಗಳು ವಿಘಟನೆ ಮತ್ತು/ಅಥವಾ ಚೇತರಿಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕೆ ಎಂದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತಿಳಿಯಲು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ (ಅದರ ಗೆಳೆಯರೊಂದಿಗೆ ಸಂಪರ್ಕವಿಲ್ಲದೆ) ಸಾಕಷ್ಟು ಮಾಹಿತಿ ಇದೆ.
ಕೋರಂ ಇಲ್ಲದೆ, ನೆಟ್ವರ್ಕ್ ವಿಭಜನೆಯ ಎರಡೂ ಬದಿಗಳು ಇನ್ನೊಂದು ಬದಿಯು ಸತ್ತಿದೆ ಎಂದು ಸರಿಯಾಗಿ ಊಹಿಸುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದನ್ನು ಬೇರ್ಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ಎರಡೂ ಪಕ್ಷಗಳು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮುಚ್ಚಲು ನಿರ್ವಹಿಸುತ್ತವೆ. ಪರ್ಯಾಯ ಸನ್ನಿವೇಶವೆಂದರೆ ಡೆತ್‌ಮ್ಯಾಚ್, ನೋಡ್ಗಳ ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ ಮೊಟ್ಟೆಯಿಡುವುದು, ಅವರ ಗೆಳೆಯರನ್ನು ನೋಡುವುದಿಲ್ಲ, ಅವರನ್ನು ರೀಬೂಟ್ ಮಾಡುವುದು ಮತ್ತು ಅವರ ಪೀರ್ ಅದೇ ತರ್ಕವನ್ನು ಅನುಸರಿಸಿದಾಗ ರೀಬೂಟ್ ಮಾಡಲು ಮಾತ್ರ ಚೇತರಿಕೆ ಪ್ರಾರಂಭಿಸುವುದು.
ವಿಘಟನೆಯ ಸಮಸ್ಯೆಯೆಂದರೆ, ನಾವು ಚೇತರಿಕೆಗೆ ಗುರಿಪಡಿಸಲು ಬಯಸುವ ಅದೇ ವೈಫಲ್ಯದ ಘಟನೆಗಳ ಕಾರಣದಿಂದಾಗಿ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಸಾಧನಗಳು ಲಭ್ಯವಿಲ್ಲ. ಹೆಚ್ಚಿನ IPMI ಮತ್ತು iLO ಕಾರ್ಡ್‌ಗಳನ್ನು ಅವರು ನಿಯಂತ್ರಿಸುವ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಅದೇ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಇತರ ಹೋಸ್ಟ್‌ಗಳು ಆಫ್‌ಲೈನ್‌ನಲ್ಲಿದೆ ಎಂದು ಗುರಿ ಹೋಸ್ಟ್‌ಗಳನ್ನು ನಂಬುವಂತೆ ಮಾಡುತ್ತದೆ.
ದುರದೃಷ್ಟವಶಾತ್, ಉಪಕರಣಗಳ ಖರೀದಿಯ ಸಮಯದಲ್ಲಿ IPMI ಮತ್ತು iLo ಸಾಧನಗಳ ಕಾರ್ಯಾಚರಣಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ವಿರಳವಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
ಪರೋಕ್ಷ ವಿಘಟನೆ
ಪರೋಕ್ಷ ವಿಘಟನೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಕೋರಮ್ ಸಹ ಮುಖ್ಯವಾಗಿದೆ; ಸರಿಯಾಗಿ ಮಾಡಿದರೆ, ಕಳೆದುಹೋದ ನೋಡ್‌ಗಳು ಒಂದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯ ನಂತರ ಸುರಕ್ಷಿತ ಸ್ಥಿತಿಗೆ ಪರಿವರ್ತನೆಯಾಗುತ್ತವೆ ಎಂದು ಬದುಕುಳಿದವರು ಊಹಿಸಲು ಕೋರಮ್ ಅನುಮತಿಸುತ್ತದೆ.
ಈ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ, ಕೋರಂ ಕಳೆದುಹೋಗದಿದ್ದರೆ ಹಾರ್ಡ್‌ವೇರ್ ವಾಚ್‌ಡಾಗ್ ಟೈಮರ್ ಅನ್ನು ಪ್ರತಿ N ಸೆಕೆಂಡ್‌ಗೆ ಮರುಹೊಂದಿಸಲಾಗುತ್ತದೆ. ಟೈಮರ್ (ಸಾಮಾನ್ಯವಾಗಿ N ನ ಹಲವಾರು ಗುಣಾಕಾರಗಳು) ಅವಧಿ ಮುಗಿದರೆ, ನಂತರ ಸಾಧನವು ಅನಪೇಕ್ಷಿತ ಪವರ್ ಡೌನ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ (ಶಟ್‌ಡೌನ್ ಅಲ್ಲ).
ಈ ವಿಧಾನವು ತುಂಬಾ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ, ಆದರೆ ಕೋರಂ ಇಲ್ಲದೆ ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಮಾಹಿತಿ ಇಲ್ಲ. ನೆಟ್ವರ್ಕ್ ಸ್ಥಗಿತ ಮತ್ತು ಪೀರ್ ನೋಡ್ ವೈಫಲ್ಯದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಹೇಳುವುದು ಸುಲಭವಲ್ಲ. ಇದು ಮುಖ್ಯವಾದ ಕಾರಣವೆಂದರೆ, ಎರಡು ಪ್ರಕರಣಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸುವ ಸಾಮರ್ಥ್ಯವಿಲ್ಲದೆ, ನೀವು ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಂದೇ ನಡವಳಿಕೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಬಲವಂತವಾಗಿ.
ಒಂದು ಮೋಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸಮಸ್ಯೆಯೆಂದರೆ, ಲಭ್ಯತೆಯನ್ನು ಗರಿಷ್ಠಗೊಳಿಸುವ ಮತ್ತು ಡೇಟಾ ನಷ್ಟವನ್ನು ತಡೆಯುವ ಯಾವುದೇ ಕ್ರಮವಿಲ್ಲ.
- ಪೀರ್ ನೋಡ್ ಸಕ್ರಿಯವಾಗಿದೆ ಆದರೆ ವಾಸ್ತವವಾಗಿ ವಿಫಲವಾದರೆ, ವಿಫಲವಾದ ಪೀರ್ ನೋಡ್‌ನಿಂದ ಸೇವೆಗಳ ನಷ್ಟವನ್ನು ಸರಿದೂಗಿಸಲು ಕ್ಲಸ್ಟರ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಸೇವೆಗಳನ್ನು ಅನಗತ್ಯವಾಗಿ ನಿಲ್ಲಿಸುತ್ತದೆ.
- ನೋಡ್ ಡೌನ್ ಆಗಿದೆ ಎಂದು ನೀವು ಊಹಿಸಲು ನಿರ್ಧರಿಸಿದರೆ, ಆದರೆ ಇದು ಕೇವಲ ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ರಿಮೋಟ್ ನೋಡ್ ಕ್ರಿಯಾತ್ಮಕವಾಗಿದ್ದರೆ, ಫಲಿತಾಂಶದ ಡೇಟಾ ಸೆಟ್‌ಗಳ ಕೆಲವು ಭವಿಷ್ಯದ ಹಸ್ತಚಾಲಿತ ಸಮನ್ವಯಕ್ಕಾಗಿ ನೀವು ಸೈನ್ ಅಪ್ ಮಾಡುತ್ತಿರುವಿರಿ.
ನೀವು ಯಾವ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಅನ್ನು ಬಳಸುತ್ತೀರಿ ಎಂಬುದರ ಹೊರತಾಗಿಯೂ, ಎರಡೂ ಕಡೆ ವಿಫಲಗೊಳ್ಳಲು ಅಥವಾ ಕ್ಲಸ್ಟರ್ ಉಳಿದಿರುವ ನೋಡ್‌ಗಳನ್ನು ಮುಚ್ಚಲು ಕಾರಣವಾಗುವ ವೈಫಲ್ಯವನ್ನು ರಚಿಸುವುದು ಕ್ಷುಲ್ಲಕವಾಗಿದೆ. ಕೋರಂ ಅನ್ನು ಬಳಸದಿರುವುದು ಅದರ ಆರ್ಸೆನಲ್‌ನಲ್ಲಿರುವ ಅತ್ಯಂತ ಶಕ್ತಿಶಾಲಿ ಸಾಧನಗಳ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಕಸಿದುಕೊಳ್ಳುತ್ತದೆ.
ಬೇರೆ ಯಾವುದೇ ಪರ್ಯಾಯವಿಲ್ಲದಿದ್ದರೆ, ಲಭ್ಯತೆಯನ್ನು ತ್ಯಾಗ ಮಾಡುವುದು ಉತ್ತಮ ವಿಧಾನವಾಗಿದೆ (ಇಲ್ಲಿ ಲೇಖಕರು CAP ಪ್ರಮೇಯವನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತಾರೆ). ದೋಷಪೂರಿತ ಡೇಟಾದ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯು ಯಾರಿಗೂ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ವಿಭಿನ್ನ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಸಮನ್ವಯಗೊಳಿಸುವುದು ವಿನೋದವಲ್ಲ.
ಕೋರಂ
ಕೋರಮ್ ಉತ್ತಮವಾಗಿದೆ, ಸರಿ?
ಒಂದೇ ತೊಂದರೆಯೆಂದರೆ, ಅದನ್ನು N ಸದಸ್ಯರೊಂದಿಗೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹೊಂದಲು, ನೀವು ಉಳಿದಿರುವ ನಿಮ್ಮ ನೋಡ್ಗಳ N/2+1 ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರಬೇಕು. ಒಂದು ನೋಡ್ ವಿಫಲವಾದ ನಂತರ ಎರಡು ನೋಡ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಇದು ಸಾಧ್ಯವಿಲ್ಲ.
ಇದು ಅಂತಿಮವಾಗಿ ಎರಡು ನೋಡ್‌ಗಳೊಂದಿಗಿನ ಮೂಲಭೂತ ಸಮಸ್ಯೆಗೆ ನಮ್ಮನ್ನು ತರುತ್ತದೆ:
ಕೋರಮ್ ಎರಡು ನೋಡ್ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಅರ್ಥವಿಲ್ಲ, ಮತ್ತು ಅದು ಇಲ್ಲದೆ ಲಭ್ಯತೆಯನ್ನು ಗರಿಷ್ಠಗೊಳಿಸುವ ಮತ್ತು ಡೇಟಾ ನಷ್ಟವನ್ನು ತಡೆಯುವ ಕ್ರಿಯೆಯ ಕೋರ್ಸ್ ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ನಿರ್ಧರಿಸುವುದು ಅಸಾಧ್ಯ.
ಕ್ರಾಸ್‌ಒವರ್ ಕೇಬಲ್‌ನಿಂದ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಎರಡು ನೋಡ್ಗಳ ವ್ಯವಸ್ಥೆಯಲ್ಲಿಯೂ ಸಹ, ನೆಟ್ವರ್ಕ್ ಸ್ಥಗಿತ ಮತ್ತು ಇತರ ನೋಡ್‌ನ ವೈಫಲ್ಯದ ನಡುವೆ ನಿರ್ಣಾಯಕವಾಗಿ ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಸಾಧ್ಯ. ಲಿಂಕ್‌ನ ಆರೋಗ್ಯವು ಪಾಲುದಾರ ನೋಡ್‌ನ ಆರೋಗ್ಯಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ ಎಂಬ ಯಾವುದೇ ಊಹೆಯನ್ನು ಅಮಾನ್ಯಗೊಳಿಸಲು ಒಂದು ತುದಿಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು (ಸಂಭವನೀಯತೆ, ನೋಡ್ಗಳ ನಡುವಿನ ಅಂತರಕ್ಕೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ) ಸಾಕಾಗುತ್ತದೆ.
ಎರಡು-ನೋಡ್ ಕ್ಲಸ್ಟರ್ ಕೆಲಸ ಮಾಡುವುದು
ಕೆಲವೊಮ್ಮೆ ಕ್ಲೈಂಟ್ ಮೂರನೇ ನೋಡ್ ಅನ್ನು ಖರೀದಿಸಲು ಬಯಸುವುದಿಲ್ಲ ಅಥವಾ ಬಯಸುವುದಿಲ್ಲ, ಮತ್ತು ನಾವು ಪರ್ಯಾಯವನ್ನು ಹುಡುಕಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ.
ಆಯ್ಕೆ 1 - ನಕಲಿ ವಿಘಟನೆ ವಿಧಾನ
ನೋಡ್‌ನ iLO ಅಥವಾ IPMI ಸಾಧನವು ವೈಫಲ್ಯದ ಹಂತವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಅದು ವಿಫಲವಾದರೆ, ಬದುಕುಳಿದವರು ನೋಡ್ ಅನ್ನು ಸುರಕ್ಷಿತ ಸ್ಥಿತಿಗೆ ತರಲು ಅದನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. 3 ಅಥವಾ ಹೆಚ್ಚಿನ ನೋಡ್ಗಳ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ, ಕೋರಮ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಮೂಲಕ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ವಾಚ್‌ಡಾಗ್ ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ನಾವು ಇದನ್ನು ತಗ್ಗಿಸಬಹುದು (ಮೊದಲೇ ಚರ್ಚಿಸಿದಂತೆ ಪರೋಕ್ಷ ವಿಘಟನೆಯ ಕಾರ್ಯವಿಧಾನ). ಎರಡು ನೋಡ್ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಬದಲಿಗೆ ನೆಟ್ವರ್ಕ್ ವಿದ್ಯುತ್ ವಿತರಣಾ ಘಟಕಗಳನ್ನು (PDUs) ಬಳಸಬೇಕು.
ವೈಫಲ್ಯದ ನಂತರ, ಬದುಕುಳಿದವರು ಮೊದಲು ಪ್ರಾಥಮಿಕ ವಿಘಟನೆ ಸಾಧನವನ್ನು ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ (ಎಂಬೆಡೆಡ್ iLO ಅಥವಾ IPMI). ಇದು ಯಶಸ್ವಿಯಾದರೆ, ಚೇತರಿಕೆ ಎಂದಿನಂತೆ ಮುಂದುವರಿಯುತ್ತದೆ. iLO/IPMI ಸಾಧನವು ವಿಫಲವಾದರೆ ಮಾತ್ರ PDU ಅನ್ನು ಪ್ರವೇಶಿಸಲಾಗುತ್ತದೆ; ಪ್ರವೇಶವು ಯಶಸ್ವಿಯಾದರೆ, ಮರುಪಡೆಯುವಿಕೆ ಮುಂದುವರಿಯಬಹುದು.
PDU ಅನ್ನು ಕ್ಲಸ್ಟರ್ ಟ್ರಾಫಿಕ್‌ಗಿಂತ ಬೇರೆ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಇರಿಸಲು ಮರೆಯದಿರಿ, ಇಲ್ಲದಿದ್ದರೆ ಒಂದೇ ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯವು ಎರಡೂ ಡಿಸ್ಸೋಸಿಯೇಶನ್ ಸಾಧನಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಸೇವೆಗಳ ಮರುಸ್ಥಾಪನೆಯನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ.
ಇಲ್ಲಿ ನೀವು ಕೇಳಬಹುದು - PDU ಒಂದು ವೈಫಲ್ಯದ ಬಿಂದುವೇ? ಇದಕ್ಕೆ ಉತ್ತರ, ಖಂಡಿತ ಅದು.
ಈ ಅಪಾಯವು ನಿಮಗೆ ಮಹತ್ವದ್ದಾಗಿದ್ದರೆ, ನೀವು ಒಬ್ಬಂಟಿಯಾಗಿಲ್ಲ: ಎರಡೂ ನೋಡ್‌ಗಳನ್ನು ಎರಡು PDU ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ನೋಡ್‌ಗಳನ್ನು ಆನ್ ಮತ್ತು ಆಫ್ ಮಾಡುವಾಗ ಎರಡನ್ನೂ ಬಳಸಲು ಕ್ಲಸ್ಟರಿಂಗ್ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ತಿಳಿಸಿ. ಒಂದು PDU ಸತ್ತರೆ ಕ್ಲಸ್ಟರ್ ಈಗ ಸಕ್ರಿಯವಾಗಿರುತ್ತದೆ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆಯನ್ನು ನಿರ್ಬಂಧಿಸಲು ಇನ್ನೊಂದು PDU ಅಥವಾ IPMI ಸಾಧನದ ಎರಡನೇ ವೈಫಲ್ಯದ ಅಗತ್ಯವಿದೆ.
ಆಯ್ಕೆ 2 - ಆರ್ಬಿಟರ್ ಅನ್ನು ಸೇರಿಸುವುದು
ಕೆಲವು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ನಕಲಿ ವಿಘಟನೆಯ ವಿಧಾನವು ತಾಂತ್ರಿಕವಾಗಿ ಸಾಧ್ಯವಾದರೆ, ಇದು ರಾಜಕೀಯವಾಗಿ ಕಷ್ಟಕರವಾಗಿದೆ. ಅನೇಕ ಕಂಪನಿಗಳು ನಿರ್ವಾಹಕರು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮಾಲೀಕರ ನಡುವೆ ಕೆಲವು ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತವೆ, ಮತ್ತು ಭದ್ರತೆ-ಪ್ರಜ್ಞೆಯ ನೆಟ್ವರ್ಕ್ ನಿರ್ವಾಹಕರು PDU ಪ್ರವೇಶ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಯಾರೊಂದಿಗೂ ಹಂಚಿಕೊಳ್ಳಲು ಯಾವಾಗಲೂ ಉತ್ಸಾಹ ಹೊಂದಿರುವುದಿಲ್ಲ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಶಿಫಾರಸು ಮಾಡಲಾದ ಪರ್ಯಾಯವು ಕೋರಂ ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ಪೂರಕವಾದ ತಟಸ್ಥ ಮೂರನೇ ವ್ಯಕ್ತಿಯನ್ನು ರಚಿಸುವುದು.
ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, ಸೇವೆಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ನೋಡ್ ತನ್ನ ಪೀರ್ ಅಥವಾ ಆರ್ಬಿಟರ್ನ ಏರ್ವೇವ್ಗಳನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಎರಡೂ ನೋಡ್‌ಗಳು ಆರ್ಬಿಟರ್ ಅನ್ನು ನೋಡಬಹುದಾದರೂ ಪರಸ್ಪರ ನೋಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಮಧ್ಯಸ್ಥಿಕೆಯು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವ ಕಾರ್ಯವನ್ನು ಸಹ ಒಳಗೊಂಡಿರುತ್ತದೆ.
ಯಂತ್ರವನ್ನು ಅದರ ಪೀರ್ ಮತ್ತು ಆರ್ಬಿಟರ್ ನೋಡ್‌ಗೆ ಸಂಪರ್ಕವನ್ನು ಕಳೆದುಕೊಂಡರೆ ಅದನ್ನು ಕೊಲ್ಲಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಹಾರ್ಡ್‌ವೇರ್ ವಾಚ್‌ಡಾಗ್ ಟೈಮರ್‌ನಂತಹ ಪರೋಕ್ಷ ವಿಘಟನೆಯ ವಿಧಾನದೊಂದಿಗೆ ಈ ಆಯ್ಕೆಯನ್ನು ಬಳಸಬೇಕು. ಹೀಗಾಗಿ, ಹಾರ್ಡ್‌ವೇರ್ ವಾಚ್‌ಡಾಗ್ ಟೈಮರ್ ಅವಧಿ ಮುಗಿದ ನಂತರ ಅದರ ಪೀರ್ ನೋಡ್ ಸುರಕ್ಷಿತ ಸ್ಥಿತಿಯಲ್ಲಿರುತ್ತದೆ ಎಂದು ಬದುಕುಳಿದವರು ಸಮಂಜಸವಾಗಿ ಊಹಿಸಬಹುದು.
ಆರ್ಬಿಟರ್ ಮತ್ತು ಮೂರನೇ ನೋಡ್ ನಡುವಿನ ಪ್ರಾಯೋಗಿಕ ವ್ಯತ್ಯಾಸವೆಂದರೆ, ಆರ್ಬಿಟರ್ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಕಡಿಮೆ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ಸಮರ್ಥವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಬಹುದು.
ಆಯ್ಕೆ 3 - ಮಾನವ ಅಂಶ
ಬದುಕುಳಿದವರು ಅವರು ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಯಾವುದೇ ಸೇವೆಗಳನ್ನು ಮುಂದುವರಿಸುವುದು ಅಂತಿಮ ವಿಧಾನವಾಗಿದೆ, ಆದರೆ ಸಮಸ್ಯೆಯು ಸ್ವತಃ ಪರಿಹರಿಸುವವರೆಗೆ (ನೆಟ್ವರ್ಕ್ ಮರುಸ್ಥಾಪನೆ, ನೋಡ್ ರೀಬೂಟ್) ಅಥವಾ ಇನ್ನೊಂದು ಬದಿಯು ಸತ್ತಿದೆ ಎಂದು ಹಸ್ತಚಾಲಿತವಾಗಿ ದೃಢೀಕರಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ವ್ಯಕ್ತಿಯು ತೆಗೆದುಕೊಳ್ಳುವವರೆಗೆ ಹೊಸದನ್ನು ಪ್ರಾರಂಭಿಸಬೇಡಿ.
ಬೋನಸ್ ಆಯ್ಕೆ
ನೀವು ಮೂರನೇ ನೋಡ್ ಅನ್ನು ಸೇರಿಸಬಹುದು ಎಂದು ನಾನು ಹೇಳಿದ್ದೇನೆಯೇ?
ಎರಡು ಚರಣಿಗೆಗಳು
ವಾದದ ಸಲುವಾಗಿ, ಮೂರನೇ ನೋಡ್‌ನ ಅರ್ಹತೆಗಳನ್ನು ನಾನು ನಿಮಗೆ ಮನವರಿಕೆ ಮಾಡಿದ್ದೇನೆ ಎಂದು ನಟಿಸೋಣ, ಈಗ ನಾವು ನೋಡ್ಗಳ ಭೌತಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಪರಿಗಣಿಸಬೇಕು. ಅವುಗಳನ್ನು ಒಂದೇ ರಾಕ್‌ನಲ್ಲಿ ಇರಿಸಿದ್ದರೆ (ಮತ್ತು ಚಾಲಿತವಾಗಿದ್ದರೆ), ಇದು SPoF ಅನ್ನು ಸಹ ರೂಪಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯ ರಾಕ್ ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುವುದಿಲ್ಲ.
ಇದು ಆಶ್ಚರ್ಯಕರವಾಗಿದ್ದರೆ, ಎರಡು ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ರ್ಯಾಕ್ ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ ಮತ್ತು ಉಳಿದಿರುವ ನೋಡ್ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯದ ನಡುವೆ ಹೇಗೆ ವ್ಯತ್ಯಾಸವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಗಣಿಸಿ.
ಸಣ್ಣ ಉತ್ತರವೆಂದರೆ ಅದು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಮತ್ತೆ ನಾವು ಎರಡು-ನೋಡ್ ಪ್ರಕರಣದಲ್ಲಿ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತಿದ್ದೇವೆ. ಅಥವಾ ಬದುಕುಳಿದವರು:
- ಕೋರಂ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಸ್ಥಗಿತದ ಸಮಯದಲ್ಲಿ ಮರುಸ್ಥಾಪನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ತಪ್ಪಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತದೆ (ವಿಯೋಜನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವು ವಿಭಿನ್ನ ಕಥೆಯಾಗಿದೆ ಮತ್ತು PDU ತೊಡಗಿಸಿಕೊಂಡಿದೆಯೇ ಮತ್ತು ಅವರು ಯಾವುದೇ ರಾಕ್‌ಗಳೊಂದಿಗೆ ಅಧಿಕಾರವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆಯೇ) ಅಥವಾ
- ಕೋರಮ್ ಅನ್ನು ಗೌರವಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಪೀರ್ ನೋಡ್ ವಿಫಲವಾದಾಗ ಅಕಾಲಿಕವಾಗಿ ಸಂಪರ್ಕ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ
ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಎರಡು ಚರಣಿಗೆಗಳು ಒಂದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿಲ್ಲ, ಮತ್ತು ನೋಡ್‌ಗಳು ಸ್ವತಂತ್ರ ವಿದ್ಯುತ್ ಸರಬರಾಜುಗಳನ್ನು ಪಡೆಯಬೇಕು ಅಥವಾ ಮೂರು (ಅಥವಾ ಹೆಚ್ಚು, ನೀವು ಎಷ್ಟು ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ) ರ್ಯಾಕ್‌ಗಳಲ್ಲಿ ವಿತರಿಸಬೇಕು.
ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳು
ಈ ಹಂತದಲ್ಲಿ, ಇನ್ನು ಮುಂದೆ ಅಪಾಯವನ್ನು ಎದುರಿಸದ ಓದುಗರು ವಿಪತ್ತು ಚೇತರಿಕೆಯನ್ನು ಪರಿಗಣಿಸಲು ಬಯಸಬಹುದು. ಕ್ಷುದ್ರಗ್ರಹವು ನಮ್ಮ ಮೂರು ನೋಡ್‌ಗಳನ್ನು ಮೂರು ವಿಭಿನ್ನ ರಾಕ್‌ಗಳಲ್ಲಿ ಹರಡಿರುವ ಅದೇ ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಹೊಡೆದಾಗ ಏನಾಗುತ್ತದೆ? ನಿಸ್ಸಂಶಯವಾಗಿ ಕೆಟ್ಟ ವಿಷಯಗಳು, ಆದರೆ ನಿಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಎರಡನೇ ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಸೇರಿಸುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ.
ಸರಿಯಾಗಿ ಮಾಡಿದರೆ, ಎರಡನೇ ಡೇಟಾ ಕೇಂದ್ರವು ನಿಮಗೆ (ಮತ್ತು ಸಮಂಜಸವಾಗಿ) ನಿಮ್ಮ ಸೇವೆಗಳು ಮತ್ತು ಅವುಗಳ ಡೇಟಾದ ನವೀಕೃತ ಮತ್ತು ಸ್ಥಿರವಾದ ಪ್ರತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಎರಡು-ನೋಡ್, ಎರಡು-ರ್ಯಾಕ್ ಸನ್ನಿವೇಶಗಳಂತೆ, ಗರಿಷ್ಠ ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಭ್ರಷ್ಟಾಚಾರವನ್ನು ತಡೆಯಲು (ಅಥವಾ ಡೇಟಾ ಸೆಟ್ ವ್ಯತ್ಯಾಸಗಳು) ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಾಕಷ್ಟು ಮಾಹಿತಿ ಇಲ್ಲ. ಮೂರು ನೋಡ್‌ಗಳೊಂದಿಗೆ (ಅಥವಾ ರಾಕ್‌ಗಳು) ಸಹ, ಅವುಗಳನ್ನು ಕೇವಲ ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ವಿತರಿಸುವುದರಿಂದ ಎರಡೂ ಪಕ್ಷಗಳು ಸಂವಹನ ನಡೆಸಲು ಸಾಧ್ಯವಾಗದ (ಈಗ ಹೆಚ್ಚು ಸಾಧ್ಯತೆ) ಈವೆಂಟ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಸರಿಯಾದ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಿಸ್ಟಮ್‌ಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಡ್ಯುಯಲ್ ಡೇಟಾ ಸೆಂಟರ್ ಪರಿಹಾರವು ಎಂದಿಗೂ ಸೂಕ್ತವಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಬ್ಯಾಕ್‌ಅಪ್ ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ತೆರಳುವ ಅಸಾಧಾರಣ ಹೆಜ್ಜೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ವ್ಯಕ್ತಿಯು ತಿಳಿದಿರಬೇಕೆಂದು ಕಂಪನಿಗಳು ಬಯಸುತ್ತವೆ. ನೀವು ನಿಲುಗಡೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಬಯಸಿದರೆ, ಕೋರಮ್‌ಗೆ ಅರ್ಥ ಮಾಡಿಕೊಳ್ಳಲು ಮೂರನೇ ಡೇಟಾ ಕೇಂದ್ರದ ಅಗತ್ಯವಿದೆ (ನೇರವಾಗಿ ಅಥವಾ ಮಧ್ಯಸ್ಥಗಾರರ ಮೂಲಕ), ಅಥವಾ ಸಂಪೂರ್ಣ ಡೇಟಾವನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮುಚ್ಚುವ ಮಾರ್ಗವನ್ನು ನೀವು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ. ಕೇಂದ್ರ.
ಮೂಲ: www.habr.com