2010 ರಲ್ಲಿ ಕಂಪನಿ 50 ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಸರಳ ನೆಟ್ವರ್ಕ್ ಮಾದರಿ: ಬ್ಯಾಕೆಂಡ್, ಮುಂಭಾಗ ಮತ್ತು ಫೈರ್ವಾಲ್. ಸರ್ವರ್‌ಗಳ ಸಂಖ್ಯೆಯು ಬೆಳೆಯಿತು, ಮಾದರಿಯು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಯಿತು: ಹಂತ, ACL ಗಳೊಂದಿಗೆ ಪ್ರತ್ಯೇಕವಾದ VLAN ಗಳು, ನಂತರ VRF ಗಳೊಂದಿಗೆ VPN ಗಳು, L2 ನಲ್ಲಿ ACL ಗಳೊಂದಿಗೆ VLAN ಗಳು, L3 ನಲ್ಲಿ ACL ಗಳೊಂದಿಗೆ VRF ಗಳು. ತಲೆ ತಿರುಗುತ್ತಿದೆಯೇ? ಇದು ನಂತರ ಹೆಚ್ಚು ಖುಷಿಯಾಗುತ್ತದೆ.
16 ಸರ್ವರ್‌ಗಳು ಇದ್ದಾಗ, ಹಲವಾರು ವೈವಿಧ್ಯಮಯ ವಿಭಾಗಗಳೊಂದಿಗೆ ಕಣ್ಣೀರು ಇಲ್ಲದೆ ಕೆಲಸ ಮಾಡುವುದು ಅಸಾಧ್ಯವಾಯಿತು. ಆದ್ದರಿಂದ ನಾವು ಇನ್ನೊಂದು ಪರಿಹಾರವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ನಾವು Netfilter ಸ್ಟಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದಕ್ಕೆ ಕಾನ್ಸುಲ್ ಅನ್ನು ಡೇಟಾ ಮೂಲವಾಗಿ ಸೇರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ವೇಗವಾಗಿ ವಿತರಿಸಿದ ಫೈರ್ವಾಲ್ ಅನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಅವರು ರೂಟರ್‌ಗಳಲ್ಲಿ ACL ಗಳನ್ನು ಬದಲಾಯಿಸಿದರು ಮತ್ತು ಅವುಗಳನ್ನು ಬಾಹ್ಯ ಮತ್ತು ಆಂತರಿಕ ಫೈರ್‌ವಾಲ್‌ನಂತೆ ಬಳಸಿದರು. ಉಪಕರಣವನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ನಿರ್ವಹಿಸಲು, ನಾವು BEFW ವ್ಯವಸ್ಥೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಇದನ್ನು ಎಲ್ಲೆಡೆ ಬಳಸಲಾಗುತ್ತಿತ್ತು: ಉತ್ಪನ್ನ ನೆಟ್ವರ್ಕ್ಗೆ ಬಳಕೆದಾರರ ಪ್ರವೇಶವನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ ಹಿಡಿದು ನೆಟ್ವರ್ಕ್ ವಿಭಾಗಗಳನ್ನು ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕಿಸುವವರೆಗೆ.
ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ನೀವು ಏಕೆ ಹತ್ತಿರದಿಂದ ನೋಡಬೇಕು ಎಂದು ಅವರು ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ. ಇವಾನ್ ಅಗರ್ಕೋವ್ () ಕಂಪನಿಯ ಮಿನ್ಸ್ಕ್ ಅಭಿವೃದ್ಧಿ ಕೇಂದ್ರದಲ್ಲಿ ನಿರ್ವಹಣೆ ವಿಭಾಗದ ಮೂಲಸೌಕರ್ಯ ಭದ್ರತಾ ಗುಂಪಿನ ಮುಖ್ಯಸ್ಥರಾಗಿದ್ದಾರೆ. ಇವಾನ್ ಒಬ್ಬ SELinux ಅಭಿಮಾನಿ, ಪರ್ಲ್ ಅನ್ನು ಪ್ರೀತಿಸುತ್ತಾನೆ ಮತ್ತು ಕೋಡ್ ಬರೆಯುತ್ತಾನೆ. ಮಾಹಿತಿ ಭದ್ರತಾ ಗುಂಪಿನ ಮುಖ್ಯಸ್ಥರಾಗಿ, ಹ್ಯಾಕರ್‌ಗಳಿಂದ ವಾರ್‌ಗೇಮಿಂಗ್ ಅನ್ನು ರಕ್ಷಿಸಲು ಮತ್ತು ಕಂಪನಿಯಲ್ಲಿನ ಎಲ್ಲಾ ಆಟದ ಸರ್ವರ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅವರು ನಿಯಮಿತವಾಗಿ ಲಾಗ್‌ಗಳು, ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಮತ್ತು R&D ಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.
ಐತಿಹಾಸಿಕ ಹಿನ್ನೆಲೆ
ನಾವು ಅದನ್ನು ಹೇಗೆ ಮಾಡಿದ್ದೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುವ ಮೊದಲು, ನಾವು ಇದನ್ನು ಮೊದಲು ಹೇಗೆ ಬಂದಿದ್ದೇವೆ ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು 9 ವರ್ಷಗಳ ಹಿಂದೆ ಹೋಗೋಣ: 2010, ವರ್ಲ್ಡ್ ಆಫ್ ಟ್ಯಾಂಕ್ಸ್ ಇದೀಗ ಕಾಣಿಸಿಕೊಂಡಿದೆ. Wargaming ಸರಿಸುಮಾರು 50 ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿತ್ತು.
ಕಂಪನಿ ಸರ್ವರ್ ಬೆಳವಣಿಗೆಯ ಚಾರ್ಟ್.
ನಾವು ನೆಟ್ವರ್ಕ್ ಮಾದರಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆ ಕಾಲಕ್ಕೆ ಇದು ಸೂಕ್ತವಾಗಿತ್ತು.
2010 ರಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಮಾದರಿ.
ಮುಂಭಾಗದಲ್ಲಿ ನಮ್ಮನ್ನು ಮುರಿಯಲು ಬಯಸುವ ಕೆಟ್ಟ ವ್ಯಕ್ತಿಗಳು ಇದ್ದಾರೆ, ಆದರೆ ಅದು ಫೈರ್ವಾಲ್ ಅನ್ನು ಹೊಂದಿದೆ. ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಯಾವುದೇ ಫೈರ್ವಾಲ್ ಇಲ್ಲ, ಆದರೆ ಅಲ್ಲಿ 50 ಸರ್ವರ್‌ಗಳಿವೆ, ಅವೆಲ್ಲವೂ ನಮಗೆ ತಿಳಿದಿದೆ. ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
4 ವರ್ಷಗಳಲ್ಲಿ, ಸರ್ವರ್ ಫ್ಲೀಟ್ 100 ಪಟ್ಟು ಹೆಚ್ಚಾಯಿತು, 5000. ಮೊದಲ ಪ್ರತ್ಯೇಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡವು - ಸ್ಟೇಜಿಂಗ್: ಅವು ಉತ್ಪಾದನೆಗೆ ಹೋಗಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಮತ್ತು ಆಗಾಗ್ಗೆ ಅಲ್ಲಿ ಚಲಿಸುವ ವಿಷಯಗಳು ಅಪಾಯಕಾರಿ.
2014 ರಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಮಾದರಿ.
ಜಡತ್ವದಿಂದ, ನಾವು ಒಂದೇ ರೀತಿಯ ಹಾರ್ಡ್‌ವೇರ್ ತುಣುಕುಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾದ VLAN ಗಳಲ್ಲಿ ನಡೆಸಲಾಯಿತು: ACL ಗಳನ್ನು VLAN ಗಳಿಗೆ ಬರೆಯಲಾಗುತ್ತದೆ, ಅದು ಕೆಲವು ರೀತಿಯ ಸಂಪರ್ಕವನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಅಥವಾ ನಿರಾಕರಿಸುತ್ತದೆ.
2016 ರಲ್ಲಿ, ಸರ್ವರ್‌ಗಳ ಸಂಖ್ಯೆ 8000 ತಲುಪಿತು. ವಾರ್‌ಗೇಮಿಂಗ್ ಇತರ ಸ್ಟುಡಿಯೊಗಳನ್ನು ಹೀರಿಕೊಳ್ಳಿತು ಮತ್ತು ಹೆಚ್ಚುವರಿ ಅಂಗಸಂಸ್ಥೆ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡವು. ಅವರು ನಮ್ಮದೇ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಸಾಕಷ್ಟು ಅಲ್ಲ: VLAN ಸಾಮಾನ್ಯವಾಗಿ ಪಾಲುದಾರರಿಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ನೀವು VRF ನೊಂದಿಗೆ VPN ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ, ಪ್ರತ್ಯೇಕತೆಯು ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ. ACL ನಿರೋಧನ ಮಿಶ್ರಣವು ಬೆಳೆಯಿತು.
2016 ರಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಮಾದರಿ.
2018 ರ ಆರಂಭದ ವೇಳೆಗೆ, ಯಂತ್ರಗಳ ಫ್ಲೀಟ್ 16 ಕ್ಕೆ ಬೆಳೆದಿದೆ. 000 ವಿಭಾಗಗಳಿವೆ ಮತ್ತು ಹಣಕಾಸಿನ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲಾದ ಮುಚ್ಚಿದವುಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಉಳಿದವುಗಳನ್ನು ನಾವು ಲೆಕ್ಕಿಸಲಿಲ್ಲ. ಕಂಟೈನರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು (ಕುಬರ್ನೆಟ್ಸ್), ಡೆವೊಪ್ಸ್, ವಿಪಿಎನ್ ಮೂಲಕ ಸಂಪರ್ಕಗೊಂಡ ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಉದಾಹರಣೆಗೆ, ಐವಿಎಸ್‌ನಿಂದ, ಕಾಣಿಸಿಕೊಂಡಿವೆ. ಬಹಳಷ್ಟು ನಿಯಮಗಳಿವೆ - ಇದು ನೋವಿನಿಂದ ಕೂಡಿದೆ.
2018 ರಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಮಾದರಿ ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯ ವಿಧಾನಗಳು.
ಪ್ರತ್ಯೇಕತೆಗಾಗಿ ನಾವು ಬಳಸಿದ್ದೇವೆ: L2 ನಲ್ಲಿ ACL ಜೊತೆಗೆ VLAN, L3 ನಲ್ಲಿ ACL ಜೊತೆಗೆ VRF, VPN ಮತ್ತು ಇನ್ನಷ್ಟು. ತುಂಬಾ ಹೆಚ್ಚು.
ತೊಂದರೆಗಳು
ಪ್ರತಿಯೊಬ್ಬರೂ ACL ಮತ್ತು VLAN ನೊಂದಿಗೆ ವಾಸಿಸುತ್ತಾರೆ. ಏನು ತಪ್ಪಾಯಿತು? ಈ ಪ್ರಶ್ನೆಗೆ ಹೆರಾಲ್ಡ್ ಉತ್ತರಿಸುತ್ತಾನೆ, ನೋವನ್ನು ಮರೆಮಾಡುತ್ತಾನೆ.
ಅನೇಕ ಸಮಸ್ಯೆಗಳಿದ್ದವು, ಆದರೆ ಐದು ಬೃಹತ್ ಸಮಸ್ಯೆಗಳಿದ್ದವು.
- ಹೊಸ ನಿಯಮಗಳಿಗೆ ಜ್ಯಾಮಿತೀಯ ಬೆಲೆ ಹೆಚ್ಚಳ. ಪ್ರತಿಯೊಂದು ಹೊಸ ನಿಯಮವು ಹಿಂದಿನದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಅಂತಹ ನಿಯಮವು ಈಗಾಗಲೇ ಇದೆಯೇ ಎಂದು ಮೊದಲು ನೋಡುವುದು ಅಗತ್ಯವಾಗಿತ್ತು.
- ವಿಭಾಗಗಳ ಒಳಗೆ ಫೈರ್ವಾಲ್ ಇಲ್ಲ. ವಿಭಾಗಗಳನ್ನು ಹೇಗಾದರೂ ಪರಸ್ಪರ ಬೇರ್ಪಡಿಸಲಾಯಿತು, ಮತ್ತು ಒಳಗೆ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಈಗಾಗಲೇ ಇರಲಿಲ್ಲ.
- ನಿಯಮಗಳನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಅನ್ವಯಿಸಲಾಗಿದೆ. ನಿರ್ವಾಹಕರು ಒಂದು ಗಂಟೆಯಲ್ಲಿ ಒಂದು ಸ್ಥಳೀಯ ನಿಯಮವನ್ನು ಕೈಯಿಂದ ಬರೆಯಬಹುದು. ಜಾಗತಿಕವು ಹಲವಾರು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು.
- ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ನಿಯಮಗಳೊಂದಿಗೆ ತೊಂದರೆಗಳು. ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಅದು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಮೊದಲ ನಿಯಮಗಳನ್ನು 2010 ರಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಮತ್ತು ಅವರ ಹೆಚ್ಚಿನ ಲೇಖಕರು ಇನ್ನು ಮುಂದೆ ಕಂಪನಿಗೆ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ.
- ಕಡಿಮೆ ಮಟ್ಟದ ಮೂಲಸೌಕರ್ಯ ನಿಯಂತ್ರಣ. ಇದು ಮುಖ್ಯ ಸಮಸ್ಯೆ - ನಮ್ಮ ದೇಶದಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂದು ನಮಗೆ ಚೆನ್ನಾಗಿ ತಿಳಿದಿರಲಿಲ್ಲ.
2018 ರಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಇಂಜಿನಿಯರ್ ಅವರು ಕೇಳಿದಾಗ ಹೇಗಿತ್ತು: "ಇನ್ನಷ್ಟು ACL ಬೇಕು."
ಪರಿಹಾರಗಳು
2018 ರ ಆರಂಭದಲ್ಲಿ, ಅದರ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಲು ನಿರ್ಧರಿಸಲಾಯಿತು.
ಏಕೀಕರಣಗಳ ಬೆಲೆ ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ. ಆರಂಭಿಕ ಹಂತವೆಂದರೆ ದೊಡ್ಡ ಡೇಟಾ ಸೆಂಟರ್‌ಗಳು ಪ್ರತ್ಯೇಕವಾದ VLAN ಗಳು ಮತ್ತು ACL ಗಳನ್ನು ಬೆಂಬಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದವು ಏಕೆಂದರೆ ಸಾಧನಗಳು ಮೆಮೊರಿ ಖಾಲಿಯಾಗಿವೆ.
ಪರಿಹಾರ: ನಾವು ಮಾನವ ಅಂಶವನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ ಮತ್ತು ಗರಿಷ್ಠ ಪ್ರವೇಶದ ನಿಬಂಧನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿದ್ದೇವೆ.
ಹೊಸ ನಿಯಮಗಳು ಅನ್ವಯಿಸಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಪರಿಹಾರ: ನಿಯಮಗಳ ಅನ್ವಯವನ್ನು ವೇಗಗೊಳಿಸಿ, ಅದನ್ನು ವಿತರಿಸಿ ಮತ್ತು ಸಮಾನಾಂತರವಾಗಿ ಮಾಡಿ. ಇದಕ್ಕೆ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಮಗಳನ್ನು ಸ್ವತಃ ವಿತರಿಸಲಾಗುತ್ತದೆ, rsync ಅಥವಾ SFTP ಇಲ್ಲದೆ ಸಾವಿರ ವ್ಯವಸ್ಥೆಗಳಿಗೆ.
ವಿಭಾಗಗಳ ಒಳಗೆ ಫೈರ್ವಾಲ್ ಇಲ್ಲ. ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಸೇವೆಗಳು ಕಾಣಿಸಿಕೊಂಡಾಗ ವಿಭಾಗಗಳೊಳಗಿನ ಫೈರ್ವಾಲ್ ನಮಗೆ ಬರಲು ಪ್ರಾರಂಭಿಸಿತು. ಪರಿಹಾರ: ಹೋಸ್ಟ್ ಮಟ್ಟದಲ್ಲಿ ಫೈರ್ವಾಲ್ ಅನ್ನು ಬಳಸಿ - ಹೋಸ್ಟ್-ಆಧಾರಿತ ಫೈರ್ವಾಲ್ಗಳು. ಬಹುತೇಕ ಎಲ್ಲೆಡೆ ನಾವು Linux ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲೆಡೆ ನಾವು iptables ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದು ಸಮಸ್ಯೆಯಲ್ಲ.
ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ನಿಯಮಗಳೊಂದಿಗೆ ತೊಂದರೆಗಳು. ಪರಿಹಾರ: ಪರಿಶೀಲನೆ ಮತ್ತು ನಿರ್ವಹಣೆಗಾಗಿ ಎಲ್ಲಾ ನಿಯಮಗಳನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ, ಆದ್ದರಿಂದ ನಾವು ಎಲ್ಲವನ್ನೂ ಆಡಿಟ್ ಮಾಡಬಹುದು.
ಮೂಲಸೌಕರ್ಯದ ಮೇಲೆ ಕಡಿಮೆ ಮಟ್ಟದ ನಿಯಂತ್ರಣ. ಪರಿಹಾರ: ಎಲ್ಲಾ ಸೇವೆಗಳು ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಪ್ರವೇಶಗಳ ದಾಸ್ತಾನು ತೆಗೆದುಕೊಳ್ಳಿ.
ಇದು ತಾಂತ್ರಿಕ ಪ್ರಕ್ರಿಯೆಗಿಂತ ಹೆಚ್ಚು ಆಡಳಿತಾತ್ಮಕ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ನಾವು ವಾರಕ್ಕೆ 200-300 ಹೊಸ ಬಿಡುಗಡೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ವಿಶೇಷವಾಗಿ ಪ್ರಚಾರಗಳು ಮತ್ತು ರಜಾದಿನಗಳಲ್ಲಿ. ಇದಲ್ಲದೆ, ಇದು ನಮ್ಮ DevOps ನ ಒಂದು ತಂಡಕ್ಕೆ ಮಾತ್ರ. ಹಲವಾರು ಬಿಡುಗಡೆಗಳೊಂದಿಗೆ, ಯಾವ ಪೋರ್ಟ್‌ಗಳು, ಐಪಿಗಳು ಮತ್ತು ಏಕೀಕರಣಗಳು ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಅಸಾಧ್ಯ. ಆದ್ದರಿಂದ, ನಮಗೆ ವಿಶೇಷವಾಗಿ ತರಬೇತಿ ಪಡೆದ ಸೇವಾ ವ್ಯವಸ್ಥಾಪಕರು ಬೇಕಾಗಿದ್ದಾರೆ, ಅವರು ತಂಡಗಳನ್ನು ಕೇಳಿದರು: "ಹೇಗಿದ್ದರೂ ಏನು ಮತ್ತು ನೀವು ಅದನ್ನು ಏಕೆ ತಂದಿದ್ದೀರಿ?"
ನಾವು ಪ್ರಾರಂಭಿಸಿದ ಎಲ್ಲದರ ನಂತರ, 2019 ರಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಎಂಜಿನಿಯರ್ ಈ ರೀತಿ ಕಾಣಲಾರಂಭಿಸಿದರು.
ಸಲಹೆಗಾರ
ಸೇವಾ ನಿರ್ವಾಹಕರ ಸಹಾಯದಿಂದ ನಾವು ಕಂಡುಕೊಂಡ ಎಲ್ಲವನ್ನೂ ಕಾನ್ಸುಲ್ಗೆ ಹಾಕಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅಲ್ಲಿಂದ ನಾವು iptables ನಿಯಮಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ.
ಇದನ್ನು ಮಾಡಲು ನಾವು ಹೇಗೆ ನಿರ್ಧರಿಸಿದ್ದೇವೆ?
- ನಾವು ಎಲ್ಲಾ ಸೇವೆಗಳು, ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಬಳಕೆದಾರರನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ.
- ಅವುಗಳ ಆಧಾರದ ಮೇಲೆ iptables ನಿಯಮಗಳನ್ನು ರಚಿಸೋಣ.
- ನಾವು ನಿಯಂತ್ರಣವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತೇವೆ.
- ....
- ಲಾಭ.
ಕಾನ್ಸುಲ್ ರಿಮೋಟ್ API ಅಲ್ಲ, ಇದು ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ ರನ್ ಆಗಬಹುದು ಮತ್ತು iptables ಗೆ ಬರೆಯಬಹುದು. ಅನಗತ್ಯ ವಸ್ತುಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವ ಸ್ವಯಂಚಾಲಿತ ನಿಯಂತ್ರಣಗಳೊಂದಿಗೆ ಬರಲು ಮಾತ್ರ ಉಳಿದಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲಾಗುತ್ತದೆ! ನಾವು ಹೋದಂತೆ ಉಳಿದ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ.
ಏಕೆ ಕಾನ್ಸಲ್?
ತನ್ನನ್ನು ತಾನು ಚೆನ್ನಾಗಿ ಸಾಬೀತುಪಡಿಸಿದೆ. 2014-15 ರಲ್ಲಿ, ನಾವು ಅದನ್ನು ವಾಲ್ಟ್‌ಗೆ ಬ್ಯಾಕೆಂಡ್ ಆಗಿ ಬಳಸಿದ್ದೇವೆ, ಇದರಲ್ಲಿ ನಾವು ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ.
ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಬಳಕೆಯ ಸಮಯದಲ್ಲಿ, ಕಾನ್ಸುಲ್ ಒಂದೇ ಅಪಘಾತದ ಸಮಯದಲ್ಲಿ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಲಿಲ್ಲ. ಫೈರ್ವಾಲ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗೆ ಇದು ಒಂದು ದೊಡ್ಡ ಪ್ಲಸ್ ಆಗಿದೆ.
P2P ಸಂಪರ್ಕಗಳು ಬದಲಾವಣೆಯ ಹರಡುವಿಕೆಯನ್ನು ವೇಗಗೊಳಿಸುತ್ತವೆ. P2P ಯೊಂದಿಗೆ, ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ತ್ವರಿತವಾಗಿ ಬರುತ್ತವೆ, ಗಂಟೆಗಳವರೆಗೆ ಕಾಯುವ ಅಗತ್ಯವಿಲ್ಲ.
ಅನುಕೂಲಕರ REST API. ನಾವು Apache ZooKeeper ಅನ್ನು ಸಹ ಪರಿಗಣಿಸಿದ್ದೇವೆ, ಆದರೆ ಇದು REST API ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಊರುಗೋಲುಗಳನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗುತ್ತದೆ.
ಕೀ ವಾಲ್ಟ್ (ಕೆವಿ) ಮತ್ತು ಡೈರೆಕ್ಟರಿ (ಸೇವೆ ಡಿಸ್ಕವರಿ) ಎರಡರಲ್ಲೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಸೇವೆಗಳು, ಕ್ಯಾಟಲಾಗ್‌ಗಳು ಮತ್ತು ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು. ಇದು ನಮಗೆ ಮಾತ್ರವಲ್ಲ, ನೆರೆಯ ತಂಡಗಳಿಗೂ ಅನುಕೂಲಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ಜಾಗತಿಕ ಸೇವೆಯನ್ನು ನಿರ್ಮಿಸುವಾಗ, ನಾವು ದೊಡ್ಡದಾಗಿ ಯೋಚಿಸುತ್ತೇವೆ.
ವಾರ್‌ಗೇಮಿಂಗ್ ಸ್ಟಾಕ್‌ನ ಭಾಗವಾಗಿರುವ Go ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ನಾವು ಈ ಭಾಷೆಯನ್ನು ಪ್ರೀತಿಸುತ್ತೇವೆ, ನಮ್ಮಲ್ಲಿ ಅನೇಕ ಗೋ ಡೆವಲಪರ್‌ಗಳಿದ್ದಾರೆ.
ಶಕ್ತಿಯುತ ACL ವ್ಯವಸ್ಥೆ. ಕಾನ್ಸುಲ್ನಲ್ಲಿ, ಯಾರು ಏನು ಬರೆಯುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸಲು ನೀವು ACL ಗಳನ್ನು ಬಳಸಬಹುದು. ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಬೇರೆ ಯಾವುದಕ್ಕೂ ಅತಿಕ್ರಮಿಸುವುದಿಲ್ಲ ಮತ್ತು ಇದರೊಂದಿಗೆ ನಮಗೆ ಸಮಸ್ಯೆಗಳಿಲ್ಲ ಎಂದು ನಾವು ಖಾತರಿಪಡಿಸುತ್ತೇವೆ.
ಆದರೆ ಕಾನ್ಸುಲ್ ಅದರ ನ್ಯೂನತೆಗಳನ್ನು ಸಹ ಹೊಂದಿದೆ.
- ನೀವು ವ್ಯಾಪಾರ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿರದ ಹೊರತು ಡೇಟಾ ಕೇಂದ್ರದೊಳಗೆ ಅಳೆಯುವುದಿಲ್ಲ. ಇದು ಒಕ್ಕೂಟದಿಂದ ಮಾತ್ರ ಸ್ಕೇಲೆಬಲ್ ಆಗಿದೆ.
- ನೆಟ್ವರ್ಕ್ ಮತ್ತು ಸರ್ವರ್ ಲೋಡ್‌ನ ಗುಣಮಟ್ಟವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಯಾವುದೇ ಲ್ಯಾಗ್‌ಗಳು ಇದ್ದಲ್ಲಿ ಕಾರ್ಯನಿರತ ಸರ್ವರ್‌ನಲ್ಲಿ ಸರ್ವರ್ ಆಗಿ ಕಾನ್ಸುಲ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, ಅಸಮ ವೇಗ. ಇದು P2P ಸಂಪರ್ಕಗಳು ಮತ್ತು ನವೀಕರಣ ವಿತರಣಾ ಮಾದರಿಗಳಿಂದಾಗಿ.
- ತೊಂದರೆ ಮೇಲ್ವಿಚಾರಣೆ ಲಭ್ಯತೆ. ಕಾನ್ಸುಲ್ ಸ್ಥಿತಿಯಲ್ಲಿ ಅವರು ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ ಎಂದು ಹೇಳಬಹುದು, ಆದರೆ ಅವರು ಬಹಳ ಹಿಂದೆಯೇ ನಿಧನರಾದರು.
ಕಾನ್ಸುಲ್ ಅನ್ನು ಬಳಸುವಾಗ ನಾವು ಈ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ, ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಅದನ್ನು ಆರಿಸಿದ್ದೇವೆ. ಕಂಪನಿಯು ಪರ್ಯಾಯ ಬ್ಯಾಕೆಂಡ್‌ಗಾಗಿ ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ನಾವು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಲು ಕಲಿತಿದ್ದೇವೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಕಾನ್ಸುಲ್‌ನೊಂದಿಗೆ ವಾಸಿಸುತ್ತಿದ್ದೇವೆ.
ಕಾನ್ಸಲ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
ನಾವು ಷರತ್ತುಬದ್ಧ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಮೂರರಿಂದ ಐದು ಸರ್ವರ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ಒಂದು ಅಥವಾ ಎರಡು ಸರ್ವರ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ: ಅವರು ಕೋರಮ್ ಅನ್ನು ಸಂಘಟಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಡೇಟಾ ಹೊಂದಾಣಿಕೆಯಾಗದಿದ್ದಾಗ ಯಾರು ಸರಿ ಮತ್ತು ಯಾರು ತಪ್ಪು ಎಂದು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಐದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅರ್ಥವಿಲ್ಲ, ಉತ್ಪಾದಕತೆ ಕುಸಿಯುತ್ತದೆ.
ಗ್ರಾಹಕರು ಯಾವುದೇ ಕ್ರಮದಲ್ಲಿ ಸರ್ವರ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತಾರೆ: ಅದೇ ಏಜೆಂಟ್‌ಗಳು, ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಮಾತ್ರ server = false.
ಇದರ ನಂತರ, ಗ್ರಾಹಕರು P2P ಸಂಪರ್ಕಗಳ ಪಟ್ಟಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ತಮ್ಮ ನಡುವೆ ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ.
ಜಾಗತಿಕ ಮಟ್ಟದಲ್ಲಿ, ನಾವು ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತೇವೆ. ಅವರು P2P ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತಾರೆ ಮತ್ತು ಸಂವಹನ ಮಾಡುತ್ತಾರೆ.
ನಾವು ಇನ್ನೊಂದು ಡೇಟಾ ಕೇಂದ್ರದಿಂದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಲು ಬಯಸಿದಾಗ, ವಿನಂತಿಯು ಸರ್ವರ್‌ನಿಂದ ಸರ್ವರ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಈ ಯೋಜನೆಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಸೆರ್ಫ್ ಪ್ರೋಟೋಕಾಲ್. ಕಾನ್ಸುಲ್ ನಂತಹ ಸೆರ್ಫ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹ್ಯಾಶಿಕಾರ್ಪ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ.
ಕಾನ್ಸುಲ್ ಬಗ್ಗೆ ಕೆಲವು ಪ್ರಮುಖ ಸಂಗತಿಗಳು
ಕಾನ್ಸುಲ್ ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವ ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದೆ. ನಾನು ತಿಳಿದುಕೊಳ್ಳಲು ಯೋಗ್ಯವಾದ ಆಯ್ದ ಸಂಗತಿಗಳನ್ನು ಮಾತ್ರ ನೀಡುತ್ತೇನೆ.
ಕಾನ್ಸಲ್ ಸರ್ವರ್‌ಗಳು ಮತದಾರರಲ್ಲಿ ಒಬ್ಬ ಮಾಸ್ಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ. ಕಾನ್ಸುಲ್ ಪ್ರತಿ ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ಸರ್ವರ್‌ಗಳ ಪಟ್ಟಿಯಿಂದ ಮಾಸ್ಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಸರ್ವರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಿಸದೆ ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಅದಕ್ಕೆ ಮಾತ್ರ ಹೋಗುತ್ತವೆ. ಮಾಸ್ಟರ್ ಫ್ರೀಜಿಂಗ್ ಮರು-ಚುನಾವಣೆಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ. ಮಾಸ್ಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡದಿದ್ದರೆ, ವಿನಂತಿಗಳನ್ನು ಯಾರಿಂದಲೂ ಸೇವೆ ಮಾಡಲಾಗುವುದಿಲ್ಲ.
ನಿಮಗೆ ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ ಬೇಕೇ? ಕ್ಷಮಿಸಿ, ಇಲ್ಲ.
ಮತ್ತೊಂದು ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ವಿನಂತಿಯು ಮಾಸ್ಟರ್‌ನಿಂದ ಮಾಸ್ಟರ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಅದು ಯಾವ ಸರ್ವರ್‌ಗೆ ಬಂದಿದ್ದರೂ ಸಹ. ಆಯ್ದ ಮಾಸ್ಟರ್ 100% ಲೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ಫಾರ್ವರ್ಡ್ ವಿನಂತಿಗಳ ಮೇಲಿನ ಲೋಡ್ ಅನ್ನು ಹೊರತುಪಡಿಸಿ. ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳು ಡೇಟಾದ ಅಪ್-ಟು-ಡೇಟ್ ನಕಲನ್ನು ಹೊಂದಿವೆ, ಆದರೆ ಒಬ್ಬರು ಮಾತ್ರ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ.
ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಸ್ಥಬ್ದ ಮೋಡ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಅಳೆಯುವ ಏಕೈಕ ಮಾರ್ಗವಾಗಿದೆ.
ಸ್ಥಬ್ದ ಮೋಡ್‌ನಲ್ಲಿ, ನೀವು ಕೋರಂ ಇಲ್ಲದೆ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು. ಇದು ನಾವು ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಬಿಟ್ಟುಕೊಡುವ ಮೋಡ್ ಆಗಿದೆ, ಆದರೆ ಸಾಮಾನ್ಯಕ್ಕಿಂತ ಸ್ವಲ್ಪ ವೇಗವಾಗಿ ಓದುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಮಾಸ್ಟರ್ ಮೂಲಕ ಮಾತ್ರ ರೆಕಾರ್ಡಿಂಗ್.
ಕಾನ್ಸುಲ್ ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ನಕಲಿಸುವುದಿಲ್ಲ. ಒಕ್ಕೂಟವನ್ನು ಜೋಡಿಸಿದಾಗ, ಪ್ರತಿ ಸರ್ವರ್ ತನ್ನದೇ ಆದ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಹೊಂದಿರುತ್ತದೆ. ಇತರರಿಗೆ, ಅವನು ಯಾವಾಗಲೂ ಬೇರೆಯವರ ಕಡೆಗೆ ತಿರುಗುತ್ತಾನೆ.
ವಹಿವಾಟಿನ ಹೊರಗೆ ಕಾರ್ಯಾಚರಣೆಗಳ ಪರಮಾಣು ಖಾತರಿಯಿಲ್ಲ. ವಿಷಯಗಳನ್ನು ಬದಲಾಯಿಸಲು ನೀವು ಮಾತ್ರ ಒಬ್ಬರಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ನೀವು ವಿಭಿನ್ನವಾಗಿ ಬಯಸಿದರೆ, ಲಾಕ್ನೊಂದಿಗೆ ವಹಿವಾಟು ನಡೆಸಿ.
ನಿರ್ಬಂಧಿಸುವ ಕಾರ್ಯಾಚರಣೆಗಳು ಲಾಕ್ ಅನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ವಿನಂತಿಯು ಮಾಸ್ಟರ್‌ನಿಂದ ಮಾಸ್ಟರ್‌ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ನೇರವಾಗಿ ಅಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ನಿರ್ಬಂಧಿಸಿದಾಗ ನಿರ್ಬಂಧಿಸುವಿಕೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ, ಉದಾಹರಣೆಗೆ, ಮತ್ತೊಂದು ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ.
ACL ಸಹ ಪ್ರವೇಶವನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ (ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ). ACL ಕಾರ್ಯನಿರ್ವಹಿಸದೇ ಇರಬಹುದು ಏಕೆಂದರೆ ಇದನ್ನು ಒಂದು ಫೆಡರೇಶನ್ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ - ACL ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ (ಪ್ರಾಥಮಿಕ DC). ಡಿಸಿ ನಿಮಗೆ ಉತ್ತರಿಸದಿದ್ದರೆ, ಎಸಿಎಲ್ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ಒಬ್ಬ ಹೆಪ್ಪುಗಟ್ಟಿದ ಮಾಸ್ಟರ್ ಇಡೀ ಒಕ್ಕೂಟವನ್ನು ಫ್ರೀಜ್ ಮಾಡಲು ಕಾರಣವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಒಕ್ಕೂಟದಲ್ಲಿ 10 ಡೇಟಾ ಸೆಂಟರ್‌ಗಳಿವೆ, ಮತ್ತು ಒಂದು ಕೆಟ್ಟ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಒಬ್ಬ ಮಾಸ್ಟರ್ ವಿಫಲವಾಗಿದೆ. ಅವನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ಪ್ರತಿಯೊಬ್ಬರೂ ವೃತ್ತದಲ್ಲಿ ಫ್ರೀಜ್ ಮಾಡುತ್ತಾರೆ: ವಿನಂತಿಯಿದೆ, ಅದಕ್ಕೆ ಯಾವುದೇ ಉತ್ತರವಿಲ್ಲ, ಥ್ರೆಡ್ ಹೆಪ್ಪುಗಟ್ಟುತ್ತದೆ. ಇದು ಯಾವಾಗ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ತಿಳಿಯಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಕೇವಲ ಒಂದು ಅಥವಾ ಎರಡು ಗಂಟೆಗಳಲ್ಲಿ ಇಡೀ ಒಕ್ಕೂಟವು ಬೀಳುತ್ತದೆ. ಅದರ ಬಗ್ಗೆ ನೀವು ಏನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಸ್ಥಿತಿ, ಕೋರಂ ಮತ್ತು ಚುನಾವಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಮರು ಚುನಾವಣೆ ನಡೆಯುವುದಿಲ್ಲ, ಸ್ಥಿತಿ ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ. ನೀವು ಲೈವ್ ಕಾನ್ಸುಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ, ನೀವು ಕೇಳುತ್ತೀರಿ ಮತ್ತು ಏನೂ ಆಗುವುದಿಲ್ಲ - ಯಾವುದೇ ಉತ್ತರವಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಸ್ಥಿತಿ ತೋರಿಸುತ್ತದೆ.
ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ತಪ್ಪಿಸಲು ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಿರ್ದಿಷ್ಟ ಭಾಗಗಳನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಬೇಕಾಗಿದೆ.
ಕಾನ್ಸುಲ್ ಎಂಟರ್‌ಪ್ರೈಸ್‌ನ ವ್ಯಾಪಾರ ಆವೃತ್ತಿಯು ಮೇಲಿನ ಕೆಲವು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಇದು ಅನೇಕ ಉಪಯುಕ್ತ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿದೆ: ಮತದಾರರ ಆಯ್ಕೆ, ವಿತರಣೆ, ಸ್ಕೇಲಿಂಗ್. ಒಂದೇ ಒಂದು “ಆದರೆ” ಇದೆ - ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗೆ ಪರವಾನಗಿ ವ್ಯವಸ್ಥೆಯು ತುಂಬಾ ದುಬಾರಿಯಾಗಿದೆ.
ಲೈಫ್ ಹ್ಯಾಕಿಂಗ್: rm -rf /var/lib/consul - ಏಜೆಂಟ್ನ ಎಲ್ಲಾ ರೋಗಗಳಿಗೆ ಚಿಕಿತ್ಸೆ. ನಿಮಗಾಗಿ ಏನಾದರೂ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಅಳಿಸಿ ಮತ್ತು ನಕಲಿನಿಂದ ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ. ಹೆಚ್ಚಾಗಿ, ಕಾನ್ಸಲ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
BEFW
ಈಗ ನಾವು ಕಾನ್ಸುಲ್ಗೆ ಏನು ಸೇರಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡೋಣ.
ಎಂಬುದರ ಸಂಕ್ಷಿಪ್ತ ರೂಪವಾಗಿದೆ Bಅಕ್EndFಕೋಪWಎಲ್ಲಾ. ಮೊದಲ ಪರೀಕ್ಷಾ ಕಮಿಟ್‌ಗಳನ್ನು ಹಾಕಲು ನಾನು ರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸಿದಾಗ ನಾನು ಉತ್ಪನ್ನವನ್ನು ಹೇಗಾದರೂ ಹೆಸರಿಸಬೇಕಾಗಿತ್ತು. ಈ ಹೆಸರು ಉಳಿದಿದೆ.
ನಿಯಮ ಟೆಂಪ್ಲೇಟ್‌ಗಳು
ನಿಯಮಗಳನ್ನು iptables ಸಿಂಟ್ಯಾಕ್ಸ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ.
- -ಎನ್ BEFW
- -ಪಿ ಇನ್‌ಪುಟ್ ಡ್ರಾಪ್
- -ಎ ಇನ್‌ಪುಟ್ -ಎಂ ಸ್ಟೇಟ್-ರಾಜ್ಯ ಸಂಬಂಧಿತ,ಸ್ಥಾಪಿತ -ಜೆ ಸ್ವೀಕರಿಸಿ
- -A INPUT -i lo -j ಒಪ್ಪಿಕೊಳ್ಳಿ
- -ಎ ಇನ್‌ಪುಟ್ -ಜೆ ಬಿಇಎಫ್‌ಡಬ್ಲ್ಯೂ
ಎಲ್ಲವನ್ನೂ ಹೊರತುಪಡಿಸಿ, BEFW ಸರಪಳಿಗೆ ಹೋಗುತ್ತದೆ ESTABLISHED, RELATED ಮತ್ತು ಲೋಕಲ್ ಹೋಸ್ಟ್. ಟೆಂಪ್ಲೇಟ್ ಯಾವುದಾದರೂ ಆಗಿರಬಹುದು, ಇದು ಕೇವಲ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.
BEFW ಹೇಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ?
ಸೇವೆಗಳು
ನಮ್ಮಲ್ಲಿ ಸೇವೆ ಇದೆ, ಅದು ಯಾವಾಗಲೂ ಪೋರ್ಟ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಅದು ಚಲಿಸುವ ನೋಡ್. ನಮ್ಮ ನೋಡ್‌ನಿಂದ, ನಾವು ಸ್ಥಳೀಯವಾಗಿ ಏಜೆಂಟ್ ಅನ್ನು ಕೇಳಬಹುದು ಮತ್ತು ನಾವು ಕೆಲವು ರೀತಿಯ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಕಂಡುಹಿಡಿಯಬಹುದು. ನೀವು ಟ್ಯಾಗ್‌ಗಳನ್ನು ಸಹ ಹಾಕಬಹುದು.
ಕಾನ್ಸಲ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಮತ್ತು ನೋಂದಾಯಿಸಲಾದ ಯಾವುದೇ ಸೇವೆಯು iptables ನಿಯಮವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ನಾವು SSH - ತೆರೆದ ಪೋರ್ಟ್ 22 ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ ಸರಳವಾಗಿದೆ: ಕರ್ಲ್ ಮತ್ತು ಐಪ್ಟೇಬಲ್ಸ್, ಬೇರೆ ಏನೂ ಅಗತ್ಯವಿಲ್ಲ.
ಗ್ರಾಹಕರು
ಎಲ್ಲರಿಗೂ ಅಲ್ಲ, ಆದರೆ ಆಯ್ದ ಪ್ರವೇಶವನ್ನು ಹೇಗೆ ತೆರೆಯುವುದು? ಸೇವೆಯ ಹೆಸರಿನ ಮೂಲಕ KV ಸಂಗ್ರಹಣೆಗೆ IP ಪಟ್ಟಿಗಳನ್ನು ಸೇರಿಸಿ.
ಉದಾಹರಣೆಗೆ, ಹತ್ತನೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಬ್ಬರೂ SSH_TCP_22 ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಒಂದು ಸಣ್ಣ TTL ಕ್ಷೇತ್ರವನ್ನು ಸೇರಿಸುವುದೇ? ಮತ್ತು ಈಗ ನಾವು ತಾತ್ಕಾಲಿಕ ಪರವಾನಗಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು ದಿನಕ್ಕೆ.
ಪ್ರವೇಶಗಳು
ನಾವು ಸೇವೆಗಳು ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತೇವೆ: ನಮ್ಮಲ್ಲಿ ಸೇವೆ ಇದೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ KV ಸಂಗ್ರಹಣೆ ಸಿದ್ಧವಾಗಿದೆ. ಈಗ ನಾವು ಎಲ್ಲರಿಗೂ ಪ್ರವೇಶವನ್ನು ನೀಡುವುದಿಲ್ಲ, ಆದರೆ ಆಯ್ದವಾಗಿ.
ಗುಂಪುಗಳು
ಪ್ರತಿ ಬಾರಿ ಪ್ರವೇಶಕ್ಕಾಗಿ ನಾವು ಸಾವಿರಾರು ಐಪಿಗಳನ್ನು ಬರೆದರೆ, ನಾವು ಸುಸ್ತಾಗುತ್ತೇವೆ. KV ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಉಪವಿಭಾಗ - ಗುಂಪುಗಳೊಂದಿಗೆ ಬರೋಣ. ನಾವು ಅದನ್ನು ಅಲಿಯಾಸ್ (ಅಥವಾ ಗುಂಪುಗಳು) ಎಂದು ಕರೆಯೋಣ ಮತ್ತು ಅದೇ ತತ್ತ್ವದ ಪ್ರಕಾರ ಗುಂಪುಗಳನ್ನು ಸಂಗ್ರಹಿಸೋಣ.
ನಾವು ಸಂಪರ್ಕಿಸೋಣ: ಈಗ ನಾವು SSH ಅನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ P2P ಗಾಗಿ ಅಲ್ಲ, ಆದರೆ ಸಂಪೂರ್ಣ ಗುಂಪು ಅಥವಾ ಹಲವಾರು ಗುಂಪುಗಳಿಗೆ ತೆರೆಯಬಹುದು. ಅದೇ ರೀತಿಯಲ್ಲಿ, TTL ಇದೆ - ನೀವು ಗುಂಪಿಗೆ ಸೇರಿಸಬಹುದು ಮತ್ತು ಗುಂಪಿನಿಂದ ತಾತ್ಕಾಲಿಕವಾಗಿ ತೆಗೆದುಹಾಕಬಹುದು.
ಏಕೀಕರಣ
ನಮ್ಮ ಸಮಸ್ಯೆ ಮಾನವ ಅಂಶ ಮತ್ತು ಯಾಂತ್ರೀಕರಣವಾಗಿದೆ. ಇಲ್ಲಿಯವರೆಗೆ ನಾವು ಇದನ್ನು ಈ ರೀತಿ ಪರಿಹರಿಸಿದ್ದೇವೆ.
ನಾವು ಪಪಿಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಸಿಸ್ಟಮ್‌ಗೆ (ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್) ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವನ್ನೂ ಅವರಿಗೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ. Puppetdb (ನಿಯಮಿತ PostgreSQL) ಅಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸೇವೆಗಳ ಪಟ್ಟಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರದಿಂದ ಕಂಡುಹಿಡಿಯಬಹುದು. ಅಲ್ಲಿ ಯಾರು ಎಲ್ಲಿ ಅರ್ಜಿ ಸಲ್ಲಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು. ಇದಕ್ಕಾಗಿ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ಮತ್ತು ಮರ್ಜ್ ರಿಕ್ವೆಸ್ಟ್ ಸಿಸ್ಟಂ ಕೂಡ ನಮ್ಮಲ್ಲಿದೆ.
ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ಸಹಾಯ ಮಾಡುವ ಸರಳ ಪರಿಹಾರವಾದ befw-sync ಅನ್ನು ನಾವು ಬರೆದಿದ್ದೇವೆ. ಮೊದಲಿಗೆ, ಸಿಂಕ್ ಕುಕೀಗಳನ್ನು puppetdb ಮೂಲಕ ಪ್ರವೇಶಿಸಲಾಗುತ್ತದೆ. HTTP API ಅನ್ನು ಅಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ: ನಾವು ಯಾವ ಸೇವೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಏನು ಮಾಡಬೇಕೆಂದು ನಾವು ವಿನಂತಿಸುತ್ತೇವೆ. ನಂತರ ಅವರು ಕಾನ್ಸುಲ್ಗೆ ಮನವಿ ಮಾಡುತ್ತಾರೆ.
ಏಕೀಕರಣವಿದೆಯೇ? ಹೌದು: ಅವರು ನಿಯಮಗಳನ್ನು ಬರೆದರು ಮತ್ತು ಪುಲ್ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಅನುಮತಿಸಿದರು. ನಿಮಗೆ ನಿರ್ದಿಷ್ಟ ಪೋರ್ಟ್ ಅಗತ್ಯವಿದೆಯೇ ಅಥವಾ ಕೆಲವು ಗುಂಪಿಗೆ ಹೋಸ್ಟ್ ಅನ್ನು ಸೇರಿಸುವುದೇ? ವಿನಂತಿಯನ್ನು ಎಳೆಯಿರಿ, ಪರಿಶೀಲಿಸಿ - ಇನ್ನು ಮುಂದೆ ಇಲ್ಲ "ಇತರ 200 ACL ಗಳನ್ನು ಹುಡುಕಿ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ."
ಆಪ್ಟಿಮೈಸೇಶನ್
ಖಾಲಿ ನಿಯಮ ಸರಪಳಿಯೊಂದಿಗೆ ಲೋಕಲ್ ಹೋಸ್ಟ್ ಅನ್ನು ಪಿಂಗ್ ಮಾಡುವುದು 0,075 ms ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಈ ಸರಪಳಿಗೆ 10 iptables ವಿಳಾಸಗಳನ್ನು ಸೇರಿಸೋಣ. ಪರಿಣಾಮವಾಗಿ, ಪಿಂಗ್ 000 ಪಟ್ಟು ಹೆಚ್ಚಾಗುತ್ತದೆ: iptables ಸಂಪೂರ್ಣವಾಗಿ ರೇಖಾತ್ಮಕವಾಗಿರುತ್ತದೆ, ಪ್ರತಿ ವಿಳಾಸವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ನಾವು ಸಾವಿರಾರು ACL ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸುವ ಫೈರ್‌ವಾಲ್‌ಗಾಗಿ, ನಾವು ಬಹಳಷ್ಟು ನಿಯಮಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಇದು ಲೇಟೆನ್ಸಿಯನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. ಗೇಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಇದು ಕೆಟ್ಟದು.
ಆದರೆ ನಾವು ಹಾಕಿದರೆ ipset ನಲ್ಲಿ 10 ವಿಳಾಸಗಳು ಪಿಂಗ್ ಕೂಡ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಅಂಶವೆಂದರೆ ipset ಗಾಗಿ "O" (ಅಲ್ಗಾರಿದಮ್ ಸಂಕೀರ್ಣತೆ) ಯಾವಾಗಲೂ 1 ಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ, ಎಷ್ಟು ನಿಯಮಗಳಿದ್ದರೂ ಸಹ. ನಿಜ, ಒಂದು ಮಿತಿ ಇದೆ - 65535 ಕ್ಕಿಂತ ಹೆಚ್ಚು ನಿಯಮಗಳು ಇರುವಂತಿಲ್ಲ. ಸದ್ಯಕ್ಕೆ ನಾವು ಇದರೊಂದಿಗೆ ವಾಸಿಸುತ್ತೇವೆ: ನೀವು ಅವುಗಳನ್ನು ಸಂಯೋಜಿಸಬಹುದು, ಅವುಗಳನ್ನು ವಿಸ್ತರಿಸಬಹುದು, ಒಂದರಲ್ಲಿ ಎರಡು ಇಪ್ಸೆಟ್ಗಳನ್ನು ಮಾಡಬಹುದು.
ಸಂಗ್ರಹಣೆ
ಪುನರಾವರ್ತನೆಯ ಪ್ರಕ್ರಿಯೆಯ ತಾರ್ಕಿಕ ಮುಂದುವರಿಕೆಯು ipset ನಲ್ಲಿ ಸೇವೆಗಾಗಿ ಕ್ಲೈಂಟ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
ಈಗ ನಾವು ಅದೇ SSH ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಏಕಕಾಲದಲ್ಲಿ 100 IP ಗಳನ್ನು ಬರೆಯುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಸಂವಹನ ಮಾಡಬೇಕಾದ ipset ಹೆಸರನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ಕೆಳಗಿನ ನಿಯಮವನ್ನು ಹೊಂದಿಸಿ DROP. ಇದನ್ನು "ಯಾರು ಇಲ್ಲಿಲ್ಲ, ಡ್ರಾಪ್" ಎಂಬ ಒಂದು ನಿಯಮವಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು, ಆದರೆ ಇದು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ಈಗ ನಾವು ನಿಯಮಗಳು ಮತ್ತು ಸೆಟ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಿಯಮವನ್ನು ಬರೆಯುವ ಮೊದಲು ಒಂದು ಸೆಟ್ ಮಾಡುವುದು ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಇಲ್ಲದಿದ್ದರೆ iptables ನಿಯಮವನ್ನು ಬರೆಯುವುದಿಲ್ಲ.
ಸಾಮಾನ್ಯ ಯೋಜನೆ
ರೇಖಾಚಿತ್ರದ ರೂಪದಲ್ಲಿ, ನಾನು ಹೇಳಿದ ಎಲ್ಲವೂ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.
ನಾವು ಪಪಿಟ್‌ಗೆ ಬದ್ಧರಾಗಿದ್ದೇವೆ, ಎಲ್ಲವನ್ನೂ ಹೋಸ್ಟ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಇಲ್ಲಿ ಸೇವೆಗಳು, ಅಲ್ಲಿ ಐಪ್‌ಸೆಟ್, ಮತ್ತು ಅಲ್ಲಿ ನೋಂದಾಯಿಸದ ಯಾರನ್ನೂ ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ.
ನಿರಾಕರಿಸಲು ಅವಕಾಶ
ಜಗತ್ತನ್ನು ತ್ವರಿತವಾಗಿ ಉಳಿಸಲು ಅಥವಾ ಯಾರನ್ನಾದರೂ ತ್ವರಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು, ಎಲ್ಲಾ ಸರಪಳಿಗಳ ಆರಂಭದಲ್ಲಿ ನಾವು ಎರಡು ಇಪ್ಸೆಟ್ಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ: rules_allow и rules_deny. ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
ಉದಾಹರಣೆಗೆ, ಯಾರಾದರೂ ನಮ್ಮ ವೆಬ್‌ನಲ್ಲಿ ಬಾಟ್‌ಗಳೊಂದಿಗೆ ಲೋಡ್ ಅನ್ನು ರಚಿಸುತ್ತಿದ್ದಾರೆ. ಹಿಂದೆ, ನೀವು ಲಾಗ್‌ಗಳಿಂದ ಅವನ ಐಪಿಯನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು, ಅದನ್ನು ನೆಟ್ವರ್ಕ್ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ತೆಗೆದುಕೊಂಡು ಹೋಗಬೇಕು, ಇದರಿಂದ ಅವರು ದಟ್ಟಣೆಯ ಮೂಲವನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು ಮತ್ತು ಅವನನ್ನು ನಿಷೇಧಿಸಬಹುದು. ಈಗ ಅದು ವಿಭಿನ್ನವಾಗಿ ಕಾಣುತ್ತದೆ.
ನಾವು ಅದನ್ನು ಕಾನ್ಸುಲ್ಗೆ ಕಳುಹಿಸುತ್ತೇವೆ, 2,5 ಸೆಕೆಂಡುಗಳು ನಿರೀಕ್ಷಿಸಿ ಮತ್ತು ಅದು ಮುಗಿದಿದೆ. ಕಾನ್ಸುಲ್ P2P ಮೂಲಕ ತ್ವರಿತವಾಗಿ ವಿತರಿಸುವುದರಿಂದ, ಇದು ಪ್ರಪಂಚದ ಯಾವುದೇ ಭಾಗದಲ್ಲಿ ಎಲ್ಲೆಡೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಒಮ್ಮೆ ನಾನು ಫೈರ್‌ವಾಲ್‌ನೊಂದಿಗೆ ತಪ್ಪಾಗಿ WOT ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸಿದೆ. rules_allow - ಇದು ಅಂತಹ ಪ್ರಕರಣಗಳ ವಿರುದ್ಧ ನಮ್ಮ ವಿಮೆಯಾಗಿದೆ. ಫೈರ್‌ವಾಲ್‌ನೊಂದಿಗೆ ನಾವು ಎಲ್ಲೋ ತಪ್ಪು ಮಾಡಿದರೆ, ಎಲ್ಲೋ ಏನೋ ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ, ನಾವು ಯಾವಾಗಲೂ ಷರತ್ತುಬದ್ಧವಾಗಿ ಕಳುಹಿಸಬಹುದು 0.0/0ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲು. ನಂತರ ನಾವು ಎಲ್ಲವನ್ನೂ ಕೈಯಿಂದ ಸರಿಪಡಿಸುತ್ತೇವೆ.
ಇತರ ಸೆಟ್‌ಗಳು
ನೀವು ಬಾಹ್ಯಾಕಾಶದಲ್ಲಿ ಯಾವುದೇ ಇತರ ಸೆಟ್ಗಳನ್ನು ಸೇರಿಸಬಹುದು $IPSETS$.
ಯಾವುದಕ್ಕಾಗಿ? ಕೆಲವೊಮ್ಮೆ ಯಾರಿಗಾದರೂ ipset ಅಗತ್ಯವಿರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಕ್ಲಸ್ಟರ್ನ ಕೆಲವು ಭಾಗದ ಸ್ಥಗಿತವನ್ನು ಅನುಕರಿಸಲು. ಯಾರಾದರೂ ಯಾವುದೇ ಸೆಟ್ಗಳನ್ನು ತರಬಹುದು, ಅವುಗಳನ್ನು ಹೆಸರಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಕಾನ್ಸುಲ್‌ನಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸೆಟ್‌ಗಳು iptables ನಿಯಮಗಳಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು ಅಥವಾ ತಂಡವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು NOOP: ಸ್ಥಿರತೆಯನ್ನು ಡೀಮನ್ ನಿರ್ವಹಿಸುತ್ತದೆ.
ಬಳಕೆದಾರರು
ಹಿಂದೆ, ಇದು ಹೀಗಿತ್ತು: ಬಳಕೆದಾರರು ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದ್ದಾರೆ ಮತ್ತು ಡೊಮೇನ್ ಮೂಲಕ ನಿಯತಾಂಕಗಳನ್ನು ಪಡೆದರು. ಹೊಸ ಪೀಳಿಗೆಯ ಫೈರ್‌ವಾಲ್‌ಗಳ ಆಗಮನದ ಮೊದಲು, ಬಳಕೆದಾರರು ಎಲ್ಲಿದ್ದಾರೆ ಮತ್ತು ಐಪಿ ಎಲ್ಲಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂದು ಸಿಸ್ಕೋಗೆ ತಿಳಿದಿರಲಿಲ್ಲ. ಆದ್ದರಿಂದ, ಯಂತ್ರದ ಹೋಸ್ಟ್ ಹೆಸರಿನ ಮೂಲಕ ಮಾತ್ರ ಪ್ರವೇಶವನ್ನು ನೀಡಲಾಯಿತು.
ನಾವೇನು ಮಾಡಿದೆವು? ನಾವು ವಿಳಾಸವನ್ನು ಸ್ವೀಕರಿಸಿದ ಕ್ಷಣದಲ್ಲಿ ನಾವು ಸಿಲುಕಿಕೊಂಡೆವು. ಸಾಮಾನ್ಯವಾಗಿ ಇದು dot1x, Wi-Fi ಅಥವಾ VPN - ಎಲ್ಲವೂ RADIUS ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ, ನಾವು ಬಳಕೆದಾರಹೆಸರಿನಿಂದ ಗುಂಪನ್ನು ರಚಿಸುತ್ತೇವೆ ಮತ್ತು ಅದರ dhcp.lease ಗೆ ಸಮಾನವಾದ TTL ನೊಂದಿಗೆ IP ಅನ್ನು ಇರಿಸುತ್ತೇವೆ - ಅದು ಅವಧಿ ಮುಗಿದ ತಕ್ಷಣ, ನಿಯಮವು ಕಣ್ಮರೆಯಾಗುತ್ತದೆ.
ಈಗ ನಾವು ಇತರ ಗುಂಪುಗಳಂತೆ ಬಳಕೆದಾರಹೆಸರಿನ ಮೂಲಕ ಸೇವೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ತೆರೆಯಬಹುದು. ಹೋಸ್ಟ್‌ಹೆಸರುಗಳು ಬದಲಾದಾಗ ನಾವು ನೋವನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಇನ್ನು ಮುಂದೆ ಸಿಸ್ಕೋ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ ನಾವು ಹೊರೆಯನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ. ಈಗ ಎಂಜಿನಿಯರ್‌ಗಳು ತಮ್ಮ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಪ್ರವೇಶವನ್ನು ನೋಂದಾಯಿಸುತ್ತಾರೆ.
ನಿರೋಧನ
ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ನಿರೋಧನವನ್ನು ಕೆಡವಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಸೇವಾ ನಿರ್ವಾಹಕರು ದಾಸ್ತಾನು ತೆಗೆದುಕೊಂಡರು ಮತ್ತು ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ. ಅವುಗಳನ್ನು ಒಂದೇ ಗುಂಪುಗಳಾಗಿ ವಿಭಜಿಸೋಣ ಮತ್ತು ಅಗತ್ಯ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಗುಂಪುಗಳನ್ನು ಸೇರಿಸಲಾಯಿತು, ಉದಾಹರಣೆಗೆ, ನಿರಾಕರಿಸಲು. ಈಗ ಅದೇ ಹಂತದ ಪ್ರತ್ಯೇಕತೆಯು ಉತ್ಪಾದನೆಯ ನಿಯಮಗಳು_ನಿರಾಕರಣೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅಲ್ಲ.
ಯೋಜನೆಯು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಸರಳವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ನಾವು ಸರ್ವರ್‌ಗಳಿಂದ ಎಲ್ಲಾ ACL ಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇವೆ, ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಅನ್‌ಲೋಡ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾದ VLAN ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತೇವೆ.
ಸಮಗ್ರತೆಯ ನಿಯಂತ್ರಣ
ಹಿಂದೆ, ಯಾರಾದರೂ ಫೈರ್ವಾಲ್ ನಿಯಮವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಬದಲಾಯಿಸಿದಾಗ ನಾವು ವಿಶೇಷ ಪ್ರಚೋದಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ನಾನು ದೊಡ್ಡ ಲಿಂಟರ್ ಅನ್ನು ಬರೆಯುತ್ತಿದ್ದೆ, ಅದು ಕಷ್ಟಕರವಾಗಿತ್ತು. ಸಮಗ್ರತೆಯನ್ನು ಈಗ BEFW ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಅವರು ಮಾಡುವ ನಿಯಮಗಳು ಬದಲಾಗುವುದಿಲ್ಲ ಎಂದು ಅವರು ಉತ್ಸಾಹದಿಂದ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತಾರೆ. ಯಾರಾದರೂ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಅದು ಎಲ್ಲವನ್ನೂ ಮತ್ತೆ ಬದಲಾಯಿಸುತ್ತದೆ. "ನಾನು ತ್ವರಿತವಾಗಿ ಪ್ರಾಕ್ಸಿಯನ್ನು ಹೊಂದಿಸಿದ್ದೇನೆ ಆದ್ದರಿಂದ ನಾನು ಮನೆಯಿಂದಲೇ ಕೆಲಸ ಮಾಡಬಲ್ಲೆ"-ಇಂತಹ ಯಾವುದೇ ಆಯ್ಕೆಗಳಿಲ್ಲ.
BEFW ಸರಪಳಿಯಲ್ಲಿನ ಸೇವೆಗಳ ನಿಯಮಗಳಾದ befw.conf ನಲ್ಲಿ ಸೇವೆಗಳು ಮತ್ತು ಪಟ್ಟಿಯಿಂದ ipset ಅನ್ನು BEFW ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಇತರ ಸರಪಳಿಗಳು ಮತ್ತು ನಿಯಮಗಳು ಮತ್ತು ಇತರ ಇಪ್ಸೆಟ್ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದಿಲ್ಲ.
ಕ್ರ್ಯಾಶ್ ರಕ್ಷಣೆ
BEFW ಯಾವಾಗಲೂ ರಾಜ್ಯ.ಬಿನ್ ಬೈನರಿ ರಚನೆಯಲ್ಲಿ ಕೊನೆಯದಾಗಿ ತಿಳಿದಿರುವ ಉತ್ತಮ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಏನಾದರೂ ತಪ್ಪಾದಲ್ಲಿ, ಅದು ಯಾವಾಗಲೂ ಈ ಸ್ಟೇಟ್.ಬಿನ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ.
ಇದು ಅಸ್ಥಿರ ಕಾನ್ಸಲ್ ಕಾರ್ಯಾಚರಣೆಯ ವಿರುದ್ಧ ವಿಮೆಯಾಗಿದೆ, ಅದು ಡೇಟಾವನ್ನು ಕಳುಹಿಸದಿದ್ದಾಗ ಅಥವಾ ಯಾರಾದರೂ ತಪ್ಪು ಮಾಡಿದಾಗ ಮತ್ತು ಅನ್ವಯಿಸಲಾಗದ ನಿಯಮಗಳನ್ನು ಬಳಸಿದಾಗ. ನಾವು ಫೈರ್ವಾಲ್ ಇಲ್ಲದೆ ಉಳಿದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಯಾವುದೇ ಹಂತದಲ್ಲಿ ದೋಷ ಸಂಭವಿಸಿದಲ್ಲಿ BEFW ಇತ್ತೀಚಿನ ಸ್ಥಿತಿಗೆ ಹಿಂತಿರುಗುತ್ತದೆ.
ನಿರ್ಣಾಯಕ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಾವು ಕೆಲಸ ಮಾಡುವ ಫೈರ್‌ವಾಲ್‌ನೊಂದಿಗೆ ಉಳಿಯುತ್ತೇವೆ ಎಂಬ ಭರವಸೆ ಇದು. ನಿರ್ವಾಹಕರು ಬಂದು ಸರಿಪಡಿಸುತ್ತಾರೆ ಎಂಬ ಭರವಸೆಯಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ಬೂದು ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ತೆರೆಯುತ್ತೇವೆ. ಒಂದು ದಿನ ನಾನು ಇದನ್ನು ಕಾನ್ಫಿಗರ್‌ಗಳಲ್ಲಿ ಹಾಕುತ್ತೇನೆ, ಆದರೆ ಈಗ ನಾವು ಕೇವಲ ಮೂರು ಬೂದು ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: 10/8, 172/12 ಮತ್ತು 192.168/16. ನಮ್ಮ ಕಾನ್ಸುಲ್ನಲ್ಲಿ, ಇದು ನಮಗೆ ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸಹಾಯ ಮಾಡುವ ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.
ಡೆಮೊ: ವರದಿಯ ಸಮಯದಲ್ಲಿ, ಇವಾನ್ BEFW ನ ಡೆಮೊ ಮೋಡ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತಾನೆ. ಪ್ರದರ್ಶನವನ್ನು ವೀಕ್ಷಿಸಲು ಇದು ಸುಲಭವಾಗಿದೆ . ಡೆಮೊ ಮೂಲ ಕೋಡ್ ಲಭ್ಯವಿದೆ .
ಮೋಸಗಳು
ನಾವು ಎದುರಿಸಿದ ದೋಷಗಳ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ipset ಆಡ್ ಸೆಟ್ 0.0.0.0/0. ನೀವು ipset ಗೆ 0.0.0.0/0 ಅನ್ನು ಸೇರಿಸಿದರೆ ಏನಾಗುತ್ತದೆ? ಎಲ್ಲಾ ಐಪಿಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆಯೇ? ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶ ಲಭ್ಯವಾಗುತ್ತದೆಯೇ?
ಇಲ್ಲ, ನಮಗೆ ಎರಡು ಗಂಟೆಗಳ ಅಲಭ್ಯತೆಯನ್ನು ಉಂಟುಮಾಡುವ ದೋಷವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಇದಲ್ಲದೆ, ದೋಷವು 2016 ರಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸಲಿಲ್ಲ, ಇದು #1297092 ಸಂಖ್ಯೆಯ ಅಡಿಯಲ್ಲಿ RedHat ಬಗ್ಜಿಲ್ಲಾದಲ್ಲಿದೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ಕಂಡುಕೊಂಡಿದ್ದೇವೆ - ಡೆವಲಪರ್ ವರದಿಯಿಂದ.
ಇದು ಈಗ BEFW ನಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಮವಾಗಿದೆ 0.0.0.0/0 ಎರಡು ವಿಳಾಸಗಳಾಗಿ ಬದಲಾಗುತ್ತದೆ: 0.0.0.0/1 и 128.0.0.0/1.
ipset ಮರುಸ್ಥಾಪನೆ ಸೆಟ್ < ಫೈಲ್. ನೀವು ಅದನ್ನು ಹೇಳಿದಾಗ ipset ಏನು ಮಾಡುತ್ತದೆ restore? ಇದು iptables ನಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಾ? ಇದು ಡೇಟಾವನ್ನು ಮರುಪಡೆಯುತ್ತದೆಯೇ?
ಅಂತಹ ಏನೂ ಇಲ್ಲ - ಇದು ವಿಲೀನಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ ವಿಳಾಸಗಳು ಎಲ್ಲಿಯೂ ಹೋಗುವುದಿಲ್ಲ, ನೀವು ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ.
ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ ನಾವು ದೋಷವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಈಗ ಬದಲಿಗೆ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆ ಇದೆ - ಬದಲಿಗೆ restore ನಡೆಸಲಾಗುತ್ತದೆ create tempನಂತರ restore flush temp и restore temp. ಸ್ವಾಪ್ನ ಕೊನೆಯಲ್ಲಿ: ಪರಮಾಣುತ್ವಕ್ಕಾಗಿ, ಏಕೆಂದರೆ ನೀವು ಅದನ್ನು ಮೊದಲು ಮಾಡಿದರೆ flush ಮತ್ತು ಈ ಕ್ಷಣದಲ್ಲಿ ಕೆಲವು ಪ್ಯಾಕೆಟ್ ಬರುತ್ತದೆ, ಅದನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಏನಾದರೂ ತಪ್ಪಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಅಲ್ಲಿ ಸ್ವಲ್ಪ ಮ್ಯಾಜಿಕ್ ಇದೆ.
ಕಾನ್ಸಲ್ ಕೆವಿ ಪಡೆಯಿರಿ -ಡೇಟಾಸೆಂಟರ್=ಇತರ. ನಾನು ಹೇಳಿದಂತೆ, ನಾವು ಕೆಲವು ಡೇಟಾವನ್ನು ಕೇಳುತ್ತಿದ್ದೇವೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ, ಆದರೆ ನಾವು ಡೇಟಾ ಅಥವಾ ದೋಷವನ್ನು ಪಡೆಯುತ್ತೇವೆ. ನಾವು ಇದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಕಾನ್ಸುಲ್ ಮೂಲಕ ಮಾಡಬಹುದು, ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಎರಡೂ ಫ್ರೀಜ್ ಆಗುತ್ತವೆ.
ಸ್ಥಳೀಯ ಕಾನ್ಸುಲ್ ಕ್ಲೈಂಟ್ HTTP API ಮೇಲೆ ರ್ಯಾಪರ್ ಆಗಿದೆ. ಆದರೆ ಅದು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು Ctrl+C, ಅಥವಾ Ctrl+Z, ಅಥವಾ ಯಾವುದಕ್ಕೂ ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ, ಮಾತ್ರ kill -9 ಮುಂದಿನ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ. ನಾವು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ಮಿಸುವಾಗ ನಾವು ಇದನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ಆದರೆ ನಮ್ಮಲ್ಲಿ ಇನ್ನೂ ಪರಿಹಾರವಿಲ್ಲ; ಕಾನ್ಸುಲ್ನಲ್ಲಿ ಈ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲು ನಾವು ತಯಾರಿ ನಡೆಸುತ್ತಿದ್ದೇವೆ.
ಕಾನ್ಸುಲ್ ನಾಯಕ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿಲ್ಲ. ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ನಮ್ಮ ಮಾಸ್ಟರ್ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿಲ್ಲ, ನಾವು ಯೋಚಿಸುತ್ತೇವೆ: "ಬಹುಶಃ ಮರು ಆಯ್ಕೆ ಅಲ್ಗಾರಿದಮ್ ಈಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ?"
ಇಲ್ಲ, ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯು ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ: ಬದ್ಧತೆಯ ಸೂಚ್ಯಂಕವಿದೆ ಎಂದು ಕಾನ್ಸುಲ್ ಹೇಳುತ್ತಾರೆ, ಒಬ್ಬ ನಾಯಕ ಕಂಡುಬಂದಿದ್ದಾನೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.
ನಾವು ಇದನ್ನು ಹೇಗೆ ಎದುರಿಸುತ್ತೇವೆ? service consul restart ಪ್ರತಿ ಗಂಟೆಗೆ ಕ್ರಾನ್‌ನಲ್ಲಿ. ನೀವು 50 ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ದೊಡ್ಡ ವಿಷಯವಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ 16 ಇದ್ದಾಗ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಿರಿ.
ತೀರ್ಮಾನಕ್ಕೆ
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ ಅನುಕೂಲಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:
- ಎಲ್ಲಾ Linux ಯಂತ್ರಗಳ 100% ಕವರೇಜ್.
- ವೇಗ
- ಆಟೋಮೇಷನ್.
- ನಾವು ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಗುಲಾಮಗಿರಿಯಿಂದ ಮುಕ್ತಗೊಳಿಸಿದ್ದೇವೆ.
- ಏಕೀಕರಣದ ಸಾಧ್ಯತೆಗಳು ಬಹುತೇಕ ಅಪರಿಮಿತವಾಗಿವೆ: ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ, ಅನ್ಸಿಬಲ್‌ನೊಂದಿಗೆ, ಪೈಥಾನ್‌ನೊಂದಿಗೆ ಸಹ.
ಮಿನುಸು: ಕಾನ್ಸುಲ್, ನಾವು ಈಗ ವಾಸಿಸಲು ಹೊಂದಿರುವ, ಮತ್ತು ದೋಷದ ಅತ್ಯಂತ ಹೆಚ್ಚಿನ ವೆಚ್ಚ. ಉದಾಹರಣೆಗೆ, ಒಮ್ಮೆ ಸಂಜೆ 6 ಗಂಟೆಗೆ (ರಷ್ಯಾದಲ್ಲಿ ಪ್ರಧಾನ ಸಮಯ) ನಾನು ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಪಟ್ಟಿಗಳಲ್ಲಿ ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುತ್ತಿದ್ದೆ. ನಾವು ಆ ಸಮಯದಲ್ಲಿ BEFW ನಲ್ಲಿ ನಿರೋಧನವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೆವು. ನಾನು ಎಲ್ಲೋ ತಪ್ಪು ಮಾಡಿದೆ, ನಾನು ತಪ್ಪು ಮುಖವಾಡವನ್ನು ಸೂಚಿಸಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಎಲ್ಲವೂ ಎರಡು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಬಿದ್ದವು. ಮಾನಿಟರಿಂಗ್ ಬೆಳಗುತ್ತದೆ, ಕರ್ತವ್ಯದಲ್ಲಿರುವ ಬೆಂಬಲಿಗ ವ್ಯಕ್ತಿ ಓಡಿ ಬರುತ್ತಾನೆ: "ನಮ್ಮಲ್ಲಿ ಎಲ್ಲವೂ ಇದೆ!" ಇದು ಏಕೆ ಸಂಭವಿಸಿತು ಎಂದು ವ್ಯವಹಾರಕ್ಕೆ ವಿವರಿಸಿದಾಗ ವಿಭಾಗದ ಮುಖ್ಯಸ್ಥರು ಬೂದು ಬಣ್ಣಕ್ಕೆ ತಿರುಗಿದರು.
ದೋಷದ ವೆಚ್ಚವು ತುಂಬಾ ಹೆಚ್ಚಿದ್ದು, ನಾವು ನಮ್ಮದೇ ಆದ ಸಂಕೀರ್ಣ ತಡೆಗಟ್ಟುವ ಕಾರ್ಯವಿಧಾನದೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ. ನೀವು ಇದನ್ನು ದೊಡ್ಡ ಉತ್ಪಾದನಾ ಸೈಟ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ, ನೀವು ಎಲ್ಲರಿಗೂ ಕಾನ್ಸುಲ್ ಮೇಲೆ ಮಾಸ್ಟರ್ ಟೋಕನ್ ನೀಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ಕೆಟ್ಟದಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
ವೆಚ್ಚ ನಾನು ಬರೋಬ್ಬರಿ 400 ಗಂಟೆಗಳ ಕಾಲ ಕೋಡ್ ಬರೆದಿದ್ದೇನೆ. 4 ಜನರ ನನ್ನ ತಂಡವು ಎಲ್ಲರಿಗೂ ಬೆಂಬಲಕ್ಕಾಗಿ ತಿಂಗಳಿಗೆ 10 ಗಂಟೆಗಳ ಕಾಲ ಕಳೆಯುತ್ತದೆ. ಯಾವುದೇ ಹೊಸ ಪೀಳಿಗೆಯ ಫೈರ್‌ವಾಲ್‌ನ ಬೆಲೆಗೆ ಹೋಲಿಸಿದರೆ, ಇದು ಉಚಿತವಾಗಿದೆ.
ಯೋಜನೆಗಳು. ಕಾನ್ಸುಲ್ ಅನ್ನು ಬದಲಿಸಲು ಅಥವಾ ಪೂರಕವಾಗಿ ಪರ್ಯಾಯ ಸಾರಿಗೆಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ದೀರ್ಘಾವಧಿಯ ಯೋಜನೆಯಾಗಿದೆ. ಬಹುಶಃ ಅದು ಕಾಫ್ಕಾ ಅಥವಾ ಅದೇ ರೀತಿಯದ್ದಾಗಿರಬಹುದು. ಆದರೆ ಮುಂಬರುವ ವರ್ಷಗಳಲ್ಲಿ ನಾವು ಕಾನ್ಸುಲ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತೇವೆ.
ತಕ್ಷಣದ ಯೋಜನೆಗಳು: Fail2ban ಜೊತೆ ಏಕೀಕರಣ, ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ, nftables ಜೊತೆಗೆ, ಬಹುಶಃ ಇತರ ವಿತರಣೆಗಳು, ಮೆಟ್ರಿಕ್‌ಗಳು, ಸುಧಾರಿತ ಮೇಲ್ವಿಚಾರಣೆ, ಆಪ್ಟಿಮೈಸೇಶನ್. ಕುಬರ್ನೆಟ್ಸ್ ಬೆಂಬಲವು ಯೋಜನೆಗಳಲ್ಲಿ ಎಲ್ಲೋ ಇದೆ, ಏಕೆಂದರೆ ಈಗ ನಾವು ಹಲವಾರು ಸಮೂಹಗಳನ್ನು ಮತ್ತು ಬಯಕೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಯೋಜನೆಗಳಿಂದ ಇನ್ನಷ್ಟು:
- ಸಂಚಾರದಲ್ಲಿನ ವೈಪರೀತ್ಯಗಳಿಗಾಗಿ ಹುಡುಕಿ;
- ನೆಟ್ವರ್ಕ್ ಮ್ಯಾಪ್ ನಿರ್ವಹಣೆ;
- ಕುಬರ್ನೆಟ್ಸ್ ಬೆಂಬಲ;
- ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಪ್ಯಾಕೇಜುಗಳನ್ನು ಜೋಡಿಸುವುದು;
- ವೆಬ್-ಯುಐ.
ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ವಿಸ್ತರಿಸಲು, ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲು ನಿರಂತರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ.
ಯೋಜನೆಗೆ ಸೇರಿಕೊಳ್ಳಿ. ಯೋಜನೆಯು ತಂಪಾಗಿದೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಇನ್ನೂ ಒಬ್ಬ ವ್ಯಕ್ತಿಯ ಯೋಜನೆಯಾಗಿದೆ. ಗೆ ಬನ್ನಿ ಮತ್ತು ಏನನ್ನಾದರೂ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ: ಬದ್ಧತೆ, ಪರೀಕ್ಷೆ, ಏನನ್ನಾದರೂ ಸೂಚಿಸಿ, ನಿಮ್ಮ ಮೌಲ್ಯಮಾಪನವನ್ನು ನೀಡಿ.
ಅಷ್ಟರಲ್ಲಿ ನಾವು ತಯಾರಿ ನಡೆಸುತ್ತಿದ್ದೇವೆ , ಇದು ಏಪ್ರಿಲ್ 6 ಮತ್ತು 7 ರಂದು ಸೇಂಟ್ ಪೀಟರ್ಸ್ಬರ್ಗ್ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ ಮತ್ತು ನಾವು ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸಿಸ್ಟಮ್ಗಳ ಡೆವಲಪರ್ಗಳನ್ನು ಆಹ್ವಾನಿಸುತ್ತೇವೆ . ಅನುಭವಿ ಸ್ಪೀಕರ್‌ಗಳು ಈಗಾಗಲೇ ಏನು ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿದ್ದಾರೆ, ಆದರೆ ಹೊಸದಾಗಿ ಮಾತನಾಡುವವರಿಗೆ ನಾವು ಕನಿಷ್ಠ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ . ಭಾಷಣಕಾರರಾಗಿ ಸಮ್ಮೇಳನದಲ್ಲಿ ಭಾಗವಹಿಸುವುದರಿಂದ ಹಲವಾರು ಅನುಕೂಲಗಳಿವೆ. ಯಾವುದನ್ನು ನೀವು ಓದಬಹುದು, ಉದಾಹರಣೆಗೆ, ಕೊನೆಯಲ್ಲಿ .
ಮೂಲ: www.habr.com