ಎರಡು ಸೈಟ್ಗಳ Kubernetes ಕ್ಲಸ್ಟರ್ಗೆ ಮೂರು etcd ಮತದಾರರು ಬೇಕೇ?
ಎರಡು VPN ಸೈಟ್ಗಳಾದ್ಯಂತ ಮೂರು ನಿಯಂತ್ರಣ-ಸಮತಲ ನೋಡ್ಗಳು ದೊಡ್ಡ ಸೈಟ್ ಆರಿಹೋದಾಗ ಇನ್ನೂ ಕ್ವೋರಂ ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ. ನಿಜವಾದ etcd ಮತದಾರರನ್ನು ಎಣಿಸಿ ಮತ್ತು ನೀವು ಉಳಿಸಿಕೊಳ್ಳುವ ನಷ್ಟವನ್ನು ಆರಿಸಿ.
ಮೂರು ನಿಯಂತ್ರಣ-ಸಮತಲ VMಗಳು ಕೆಟ್ಟ ರಾತ್ರಿಯಿಂದ ಪಾರಾಗುವ ಮೂರು ಅವಕಾಶಗಳಂತೆ ತೋರುತ್ತವೆ. ಆದರೆ ಹಾಗಲ್ಲ, ಮತ್ತು ಈ ಎರಡು ನಂಬಿಕೆಗಳ ನಡುವಿನ ಅಂತರವೇ ಒಂದು ಅಚ್ಚುಕಟ್ಟಾದ ಮೂರು-ನೋಡ್ ವಿನ್ಯಾಸವನ್ನು, ಒಂದು ಕಟ್ಟಡ ವಿದ್ಯುತ್ ಕಳೆದುಕೊಂಡಾಗ ಬರವಣಿಗೆ ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಕ್ಲಸ್ಟರ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಸೈಟ್ಗಳ ನಡುವಿನ VPN ಲಿಂಕ್ ಯಂತ್ರಗಳನ್ನು ಒಂದಕ್ಕೊಂದು ತಲುಪುವಂತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸುವ ಬದಲು ಮುಚ್ಚಿಡುತ್ತದೆ. ಮತಗಳನ್ನು ಪ್ರತಿ etcd ಸದಸ್ಯರಿಗೆ ಎಣಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಆ ಸದಸ್ಯರಲ್ಲಿ ಇಬ್ಬರು ಇನ್ನೂ ಒಂದು ಸ್ವಿಚ್, ಒಂದು UPS ಮತ್ತು ಒಂದು ಅಪ್ಲಿಂಕ್ನ ಹಿಂದೆ ಕುಳಿತುಕೊಳ್ಳಬಹುದು.
ಮೂರು ನಿಯಂತ್ರಣ-ಸಮತಲ ನೋಡ್ಗಳು, ಒಂದು ವೈಫಲ್ಯ ಡೊಮೇನ್
ನೀವು kubectl get nodes ಚಲಾಯಿಸುತ್ತೀರಿ, ಮೂರು ನಿಯಂತ್ರಣ-ಸಮತಲ ನಮೂದುಗಳನ್ನು ನೋಡುತ್ತೀರಿ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚು ಲಭ್ಯವೆಂದು ದಾಖಲಿಸುತ್ತೀರಿ. ಆ ಸಂಖ್ಯೆ ನಿಗದಿಪಡಿಸಬಹುದಾದ ಸಾಮರ್ಥ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಉಳಿವನ್ನಲ್ಲ. ಬಾಹ್ಯ etcd ಇಲ್ಲದೆ ಇರಿಸಿದ kubeadm ನಲ್ಲಿ, ಪ್ರತಿ ನಿಯಂತ್ರಣ-ಸಮತಲ ನೋಡ್ ಕೂಡ ಒಂದು ಸದಸ್ಯವನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೂರು ನೋಡ್ಗಳು ನಿಜವಾಗಿಯೂ ಮೂರು ಮತದಾರರನ್ನು ನೀಡುತ್ತವೆ. ಆ ಮತದಾರರು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗುತ್ತಾರೆಯೇ ಎಂಬುದು ನೋಡ್ ಪಟ್ಟಿ ಉತ್ತರಿಸಲಾಗದ ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆ.
ಒಂದು ಹೈಪರ್ವೈಸರ್ನಲ್ಲಿ ಎರಡು VMಗಳು, ಒಂದು ವಿದ್ಯುತ್ ಸರಬರಾಜಿನಲ್ಲಿ ಎರಡು ರ್ಯಾಕ್ಗಳು, ಒಂದು ISP ಯಿಂದ ಎರಡು ಅಪ್ಲಿಂಕ್ುಗಳು: ಪ್ರತಿ ಜೋಡಿ ಎರಡು ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ಧರಿಸಿದ ಒಂದೇ ಡೊಮೇನ್. ನಿಯೋಜನೆಯನ್ನು ಬರೆಯಿರಿ ಮತ್ತು ಪ್ರತಿ ಮತದಾರ ಏನನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾನೆ ಎಂದು ಗುರುತಿಸಿ — ಹೈಪರ್ವೈಸರ್, PDU, ರ್ಯಾಕ್ನ ಮೇಲ್ಭಾಗದ ಸ್ವಿಚ್, ಸಂಗ್ರಹಣಾ ಸರಣಿ, NAT ಸಾಧನ, VPN ಕೇಂದ್ರೀಕರಣಕಾರ. ನಂತರ ಕಾಗದದ ಮೇಲೆ ಪ್ರತಿ ಹಂಚಿದ ವಸ್ತುವನ್ನು ತೆಗೆದುಹಾಕಿ ಮತ್ತು ಉಳಿದ ಮತಗಳನ್ನು ಮತ್ತೆ ಎಣಿಸಿ. ಒಂದು ವಿಫಲ ಹೋಸ್ಟ್ನಿಂದ ಎರಡು ಮತದಾರರನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಕ್ಲಸ್ಟರ್ ಆರಂಭದಿಂದಲೂ ಒಂದು-ಮತದಾರ ಕ್ಲಸ್ಟರ್ ಆಗಿತ್ತು; ಯಾರೂ ಅದಕ್ಕೆ ಈ ಪ್ರಶ್ನೆಯನ್ನು ಇನ್ನೂ ಕೇಳಿರಲಿಲ್ಲ.
ಎರಡು ಸೈಟ್ ವಿಭಜನೆ ಏನನ್ನು ತಾಳಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಏನನ್ನು ತಾಳಿಕೊಳ್ಳಲಾರದು
ಮೂರು ಮತದಾರರನ್ನು ಎರಡು ಸೈಟ್ಗಳ ಮೇಲೆ ಎರಡು ಮತ್ತು ಒಂದಾಗಿ ಇರಿಸಿದಾಗ, ಇನ್ನೊಂದು ಸೈಟ್ ಕಣ್ಮರೆಯಾದಾಗ ದೊಡ್ಡ ಭಾಗ ಕ್ವೋರಂ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಒಂದು-ಮತದಾರ ಭಾಗ ಎಂದಿಗೂ ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಆ ಅಸಮಾನತೆ ಅಂಕಗಣಿತ, ಟ್ಯೂನಿಂಗ್ ಅಲ್ಲ. ನಿಖರವಾಗಿ ಎರಡು ಸ್ವತಂತ್ರ ಸೈಟ್ಗಳ ಮೇಲೆ ಹರಡಿರುವ ಯಾವುದೇ ಬಹುಮತ-ಆಧಾರಿತ etcd ಕ್ಲಸ್ಟರ್ "ಯಾವುದೇ ಸೈಟ್ ಕಳೆದುಕೊಂಡು ಬದ್ಧವಾಗುತ್ತಿರಿ" ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಎರಡೂ ಬದಿಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚು ಮತಗಳನ್ನು ಹೊಂದಿರಬೇಕು.
ಕೆಳಗಿನ ಕೋಷ್ಟಕವು ನೀವು ನಿಜವಾಗಿ ಯಾವ ವೈಫಲ್ಯಗಳನ್ನು ಖರೀದಿಸಿದ್ದೀರಿ ಎಂದು ನೋಡಲು ವೇಗವಾದ ದಾರಿ. ಪ್ರತಿ ಸಾಲನ್ನು ಹೀಗೆ ಓದಿ: ಇಂದು ರಾತ್ರಿ ಈ ಇಡೀ ಸಾಲು ಕಣ್ಮರೆಯಾದರೆ, ಉಳಿದವರು ಇನ್ನೂ ಬರವಣಿಗೆಯನ್ನು ಬದ್ಧಪಡಿಸಬಹುದೇ?
| What disappears | Voters left | Writes still commit |
|---|---|---|
| Site B, holding voter 3 | 2 of 3 | Yes |
| Site A, holding voters 1 and 2 | 1 of 3 | No |
| One hypervisor carrying any two voters | 1 of 3 | No |
| The inter-site VPN only | 2 of 3 on one side | Only on the majority side |
ಸುರಂಗ ಏಕೆ ಎಂದಿಗೂ ಮತವನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ
VPN ಸಾಗಣೆ, ಸದಸ್ಯ ಅಲ್ಲ. ಅದು ದೂರದ ಮತದಾರನನ್ನು ತಲುಪುವಂತೆ ಮಾಡಬಹುದು ಮತ್ತು ವಿಭಜನೆಯನ್ನು ನಿಧಾನ ಸಮಯ ಮಿತಿಯಂತೆ ಕಾಣುವ ಯಾವುದಕ್ಕಾದರೂ ಪರಿವರ್ತಿಸಬಹುದು, ಮತ್ತು ಕ್ವೋರಂಗೆ ಅದರ ಸಂಪೂರ್ಣ ಕೊಡುಗೆ ಅಷ್ಟೇ. ಅದು ಸೇರಿಸುವುದು ವೆಚ್ಚ, ಏಕೆಂದರೆ ಪ್ರತಿ ಬದ್ಧತೆ ಲಿಂಕ್ ದಾಟಬೇಕು ಮತ್ತು raft ಲಾಗ್ ಸ್ಪರ್ಶಿಸುವ ಬರವಣಿಗೆಗಳಲ್ಲಿ etcd ಆ ಹೋಗಿಬರುವಿಕೆಯನ್ನು ಪಾವತಿಸುತ್ತದೆ. ಮಿಡಿಯುವ ಮಾರ್ಗ ಪ್ರತಿಕೃತಿಯನ್ನು ಮರುಪ್ರಯತ್ನಗಳು ಮತ್ತು ಚುನಾವಣೆಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ವಿಭಜನೆಗಳು ಜನರು ಮಾಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸುವ ಸ್ಥಳ, ಆದ್ದರಿಂದ ಅವುಗಳ ಬಗ್ಗೆ ನಿಖರವಾಗಿರಿ. ಹಳೆಯ ನಾಯಕ ಒಂದು-ಮತದಾರ ಬದಿಯಲ್ಲಿ ಕುಳಿತಿರುವಾಗ ಲಿಂಕ್ ಬಿದ್ದರೆ, ಆ ಬದಿ ಬದ್ಧಪಡಿಸಲಾರದು ಮತ್ತು ಚುನಾವಣಾ ಸಮಯ ಮಿತಿ ಮುಗಿದಾಗ ನಾಯಕ ಕೆಳಗಿಳಿಯುತ್ತಾನೆ, ಆದರೆ ಎರಡು-ಮತದಾರ ಬದಿ ಬದಲಿ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. etcd ನ ವೈಫಲ್ಯ ಮೋಡ್ ಮಾರ್ಗದರ್ಶಿ ವರ್ತನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸುತ್ತದೆ: ಬಹುಮತ ಬದಿಯಲ್ಲಿ ಮುಂದುವರಿದ ಸೇವೆ, ಪ್ರತ್ಯೇಕಿಸಿದ ಬದಿಯಲ್ಲಿ ಎರಡನೇ ಬರೆಯಬಹುದಾದ ಕ್ಲಸ್ಟರ್ ಇಲ್ಲ.
ನೀವು ಯಾವ ಅಡಚಣೆಯನ್ನು ಖರೀದಿಸುತ್ತೀರಿ ಎಂದು ನಿರ್ಧರಿಸಿ
ಸೈಟ್ A ಪ್ರಾಥಮಿಕವಾಗಿದ್ದು, ಅದನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಯಾರಾದರೂ ಕ್ರಮ ಕೈಗೊಳ್ಳುವವರೆಗೆ ನಿಯಂತ್ರಣ-ಸಮತಲ ಬರವಣಿಗೆಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಎಂದು ನೀವು ಒಪ್ಪಿದಾಗ ಎರಡು ಜೊತೆಗೆ ಒಂದು ಕಾನೂನುಬದ್ಧ ವಿನ್ಯಾಸ. ಅದನ್ನು ದೋಷವಾಗಿ ಪರಿವರ್ತಿಸುವುದು ಆ ನಿರ್ಧಾರವನ್ನು ಗುಪ್ತವಾಗಿ ಬಿಡುವುದು. ಅದನ್ನು ರನ್ಬುಕ್ನಲ್ಲಿ ಬರೆಯಿರಿ: ನಿಮ್ಮ ನಿಯಂತ್ರಣ ಸಮತಲ ಯಾವ ಸೈಟ್ನಿಂದ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಇನ್ನೊಂದು ಸೈಟ್ 03:00ಕ್ಕೆ ಆರಿಹೋದಾಗ ನಿರ್ವಾಹಕ ಏನು ಮಾಡುತ್ತಾನೆ.
ಅಗತ್ಯವು ಬದಲಿಗೆ "ಯಾವುದೇ ಸೈಟ್ ವಿಫಲವಾಗಬಹುದು" ಆಗಿದ್ದರೆ, ನಿಯೋಜನೆ ಪ್ರತಿ ಸೈಟ್ನಲ್ಲಿ ಬಹುಮತವನ್ನು ಹೊಂದಿರಬೇಕು, ಮತ್ತು ಎರಡು ಸೈಟ್ಗಳ ಮೇಲೆ ಮೂರು ಮತದಾರರು ಅದನ್ನು ಮಾಡಲಾರರು. ನೀವು ನಿಜವಾಗಿಯೂ ಸ್ವತಂತ್ರವಾದ ಮೂರನೇ ಡೊಮೇನ್ ಸೇರಿಸುತ್ತೀರಿ — ಇನ್ನೊಂದು ಪೂರೈಕೆದಾರರಲ್ಲಿನ ಸಣ್ಣ ಪ್ರದೇಶವು ಅಲ್ಲಿಗೆ ಮಾರ್ಗ ಸ್ಥಿರವಾಗಿದ್ದರೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ — ಅಥವಾ ಪ್ರತ್ಯೇಕ etcd ಹೊಂದಿರುವ ಎರಡು ಕ್ಲಸ್ಟರ್ಗಳಾಗಿ ಒಡೆದು ಆ ಒಡೆತನದ ಕಾರ್ಯಾಚರಣಾ ವೆಚ್ಚವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೀರಿ. ಯಾವುದೇ ಸಾಕ್ಷಿ ಚುಟುಕು ಇದನ್ನು ತಪ್ಪಿಸುವುದಿಲ್ಲ: etcd ನಲ್ಲಿ ಹಗುರ ಮಧ್ಯಸ್ಥ ಸದಸ್ಯನಿಲ್ಲ, ಆದ್ದರಿಂದ ಮೂರನೇ ಮತದಾರ ತನ್ನದೇ ಡಿಸ್ಕ್, ಮೆಮೊರಿ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಅಗತ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ಪೂರ್ಣ ಸದಸ್ಯ. ರೇಖಾಚಿತ್ರದಲ್ಲಿ "ಸಾಕ್ಷಿ" ಎಂದು ಬರೆದ ಪೆಟ್ಟಿಗೆಯನ್ನು ಎಳೆಯುವುದು ಸಾಕ್ಷಿಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.
ಕ್ವೋರಂ ಸೇವೆಗೆ ಸಮಾನವಲ್ಲ
etcd ಕ್ವೋರಂ API ಸರ್ವರ್ ಬರವಣಿಗೆ ಸ್ವೀಕರಿಸಲು ಸಮರ್ಥವಾಗಿರುವಂತೆ ಇಡುತ್ತದೆ, ಮತ್ತು ಇಡುವುದು ಅಷ್ಟೇ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆಗಳು, ingress, ಸುರಂಗದಾದ್ಯಂತ CNI ತಲುಪುವಿಕೆ, ಸಂಪುಟ ಜೋಡಣೆ ವಲಯಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿಕೃತಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಉತ್ತರ ಬೇಕು. ಕ್ಲಸ್ಟರ್ ಸ್ವಚ್ಛ ಬಹುಮತವನ್ನು ಹೊಂದಿದ್ದರೂ ಬಳಕೆದಾರರಿಗೆ ಉಪಯುಕ್ತವಾದ ಯಾವುದನ್ನೂ ನೀಡದೇ ಇರಬಹುದು.
ನಂತರ ನಿಮಗೆ ಇದೆ ಎಂದು ನೀವು ಭಾವಿಸುವ ಸದಸ್ಯತ್ವವನ್ನು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ರೇಖಾಚಿತ್ರಗಳು ಜಾರುತ್ತವೆ:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
ಸದಸ್ಯರ ಪಟ್ಟಿಯನ್ನು ನಿಯೋಜನೆ ಚಿತ್ರದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಎರಡು ಸದಸ್ಯರು ಒಂದೇ ಹೋಸ್ಟ್ ಅಥವಾ ಒಂದೇ ರ್ಯಾಕ್ಗೆ ಪರಿಹಾರವಾದರೆ, ತಪ್ಪು ಕ್ಲಸ್ಟರ್ನಲ್ಲಲ್ಲ, ಚಿತ್ರದಲ್ಲಿದೆ, ಮತ್ತು ತಪ್ಪು ಟೋಪೋಲಜಿ ಸುತ್ತ ಗಾತ್ರ ಬದಲಾಯಿಸುವುದು ಅದೇ ಅಡಚಣೆಯ ಹೆಚ್ಚು ದುಬಾರಿ ಆವೃತ್ತಿಯನ್ನು ಮಾತ್ರ ಖರೀದಿಸುತ್ತದೆ.
ಯಾವುದೇ ಮೂರು-ಮತದಾರ ವಿನ್ಯಾಸವನ್ನು ಅನುಮೋದಿಸುವ ಮೊದಲು ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಿ: ಎಷ್ಟು ಮತದಾರರು ಒಟ್ಟಿಗೆ ವಿದ್ಯುತ್ ಕಳೆದುಕೊಳ್ಳುತ್ತಾರೆ, ಯಾವ ಸೈಟ್ನ ನಷ್ಟವು ಇನ್ನೂ ಬಹುಮತವನ್ನು ಬಿಡುತ್ತದೆ, ಸುರಂಗ ಬಿದ್ದಾಗ ನಾಯಕ ಎಲ್ಲಿದ್ದಾನೆ, ಮತ್ತು ಉಳಿದ ಸೈಟ್ ಇನ್ನೂ ಏನು ಮಾಡಬಲ್ಲದು. ಅವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕಾದರೂ "ಖಚಿತವಿಲ್ಲ" ಎಂದರೆ ಕ್ಲಸ್ಟರ್ ಇನ್ನೂ ಹೆಚ್ಚು ಲಭ್ಯವಿಲ್ಲ. ಅದು ಅದೃಷ್ಟವಂತ ಮೂರು ಯಂತ್ರಗಳು.