ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೂಕ್ತವಾದ ಗಾತ್ರವನ್ನು ನಿರ್ಧರಿಸಿ

ಸೂಚನೆ. ಅನುವಾದ.: ಈ ಲೇಖನದಲ್ಲಿ, ಬನ್ಝೈ ಕ್ಲೌಡ್ ತನ್ನ ಕಸ್ಟಮ್ ಪರಿಕರಗಳನ್ನು ಹೇಗೆ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಬಳಸಲು ಕಾಫ್ಕಾವನ್ನು ಸುಲಭಗೊಳಿಸಲು ಬಳಸಬಹುದು ಎಂಬುದಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ. ಕೆಳಗಿನ ಸೂಚನೆಗಳು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಸೂಕ್ತ ಗಾತ್ರವನ್ನು ಹೇಗೆ ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ಅಗತ್ಯವಿರುವ ಥ್ರೋಪುಟ್ ಅನ್ನು ಸಾಧಿಸಲು ಕಾಫ್ಕಾವನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಅಪಾಚೆ ಕಾಫ್ಕಾ ವಿಶ್ವಾಸಾರ್ಹ, ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ ನೈಜ-ಸಮಯದ ಸ್ಟ್ರೀಮಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ರಚಿಸಲು ವಿತರಿಸಿದ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಗಿದೆ. ಅದರ ಪ್ರಭಾವಶಾಲಿ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸಿ ವಿಸ್ತರಿಸಬಹುದು. ಇದಕ್ಕಾಗಿ ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಓಪನ್ ಸೋರ್ಸ್ ಕಾಫ್ಕಾ ಆಪರೇಟರ್ ಮತ್ತು ಎಂಬ ಉಪಕರಣ ಸೂಪರ್ಟ್ಯೂಬ್ಗಳು. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಕಾಫ್ಕಾವನ್ನು ಚಲಾಯಿಸಲು ಮತ್ತು ಬ್ರೋಕರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವುದು, ಮರುಸಮತೋಲನದೊಂದಿಗೆ ಮೆಟ್ರಿಕ್-ಆಧಾರಿತ ಸ್ಕೇಲಿಂಗ್, ರ್ಯಾಕ್ ಅರಿವು, "ಸಾಫ್ಟ್" ಮುಂತಾದ ಅದರ ವಿವಿಧ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸಲು ಅವು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ. (ಸುಲಲಿತ) ನವೀಕರಣಗಳನ್ನು ಹೊರತರುವುದು, ಇತ್ಯಾದಿ.

ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸೂಪರ್‌ಟ್ಯೂಬ್‌ಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿ:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ಅಥವಾ ಸಂಪರ್ಕಿಸಿ ದಸ್ತಾವೇಜನ್ನು. ಕಾಫ್ಕಾದ ಕೆಲವು ಸಾಮರ್ಥ್ಯಗಳ ಬಗ್ಗೆ ನೀವು ಓದಬಹುದು, ಅದರೊಂದಿಗೆ ಕೆಲಸವು ಸೂಪರ್‌ಟ್ಯೂಬ್‌ಗಳು ಮತ್ತು ಕಾಫ್ಕಾ ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ವಯಂಚಾಲಿತವಾಗಿರುತ್ತದೆ. ನಾವು ಈಗಾಗಲೇ ಅವರ ಬಗ್ಗೆ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಬರೆದಿದ್ದೇವೆ:

• ಅರೆರೆ! ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಮತ್ತೊಂದು ಕಾಫ್ಕಾ ಆಪರೇಟರ್;
• ಪ್ರಮೀತಿಯಸ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಕಾಫ್ಕಾವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ ಮತ್ತು ನಿರ್ವಹಿಸಿ;
• ಕುಬರ್ನೆಟ್ಸ್ ಕುರಿತು ಕಾಫ್ಕಾ ರ್ಯಾಕ್ ಜಾಗೃತಿ;
• ಇಸ್ಟಿಯೊ ಮೇಲೆ ಅಪಾಚೆ ಕಾಫ್ಕಾ ರನ್ನಿಂಗ್ - ಮಾನದಂಡ;
• ಕಾಫ್ಕಾ ಆಪರೇಟರ್‌ನೊಂದಿಗೆ ಬಳಕೆದಾರರು ದೃಢೀಕರಿಸಿದ ಮತ್ತು ನಿಯಂತ್ರಿತ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸಿ;
• ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಕಾಫ್ಕಾ ರೋಲಿಂಗ್ ಅಪ್‌ಗ್ರೇಡ್ ಮತ್ತು ಡೈನಾಮಿಕ್ ಕಾನ್ಫಿಗರೇಶನ್;
• ಕಾಫ್ಕಾಗಾಗಿ ಎನ್ವಾಯ್ ಪ್ರೋಟೋಕಾಲ್ ಫಿಲ್ಟರ್, ಮೆಶ್ಡ್.

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ನೀವು ನಿರ್ಧರಿಸಿದಾಗ, ಆಧಾರವಾಗಿರುವ ಮೂಲಸೌಕರ್ಯದ ಸೂಕ್ತ ಗಾತ್ರವನ್ನು ನಿರ್ಧರಿಸುವ ಸವಾಲನ್ನು ನೀವು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಥ್ರೋಪುಟ್ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲು ನಿಮ್ಮ ಕಾಫ್ಕಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ಅಗತ್ಯವನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ. ಮೆಮೊರಿ, ಪ್ರೊಸೆಸರ್, ಡಿಸ್ಕ್ ವೇಗ, ನೆಟ್‌ವರ್ಕ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಇತ್ಯಾದಿಗಳಂತಹ ಆಧಾರವಾಗಿರುವ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದ ಪ್ರತಿ ಬ್ರೋಕರ್‌ನ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.

ತಾತ್ತ್ವಿಕವಾಗಿ, ಬ್ರೋಕರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಎಲ್ಲಾ ಮೂಲಸೌಕರ್ಯ ಅಂಶಗಳನ್ನು ಅವುಗಳ ಗರಿಷ್ಟ ಸಾಮರ್ಥ್ಯಗಳಿಗೆ ಬಳಸಿಕೊಳ್ಳುವಂತೆ ಇರಬೇಕು. ಆದಾಗ್ಯೂ, ನಿಜ ಜೀವನದಲ್ಲಿ ಈ ಸೆಟಪ್ ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಬಳಕೆದಾರರು ಒಂದು ಅಥವಾ ಎರಡು ಘಟಕಗಳ (ಡಿಸ್ಕ್, ಮೆಮೊರಿ, ಅಥವಾ ಪ್ರೊಸೆಸರ್) ಬಳಕೆಯನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು ಬ್ರೋಕರ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅದರ ಸಂರಚನೆಯು ನಿಧಾನವಾದ ಘಟಕವನ್ನು ಅದರ ಪೂರ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ ಬಳಸಲು ಅನುಮತಿಸಿದಾಗ ಬ್ರೋಕರ್ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ ನಾವು ಒಬ್ಬ ಬ್ರೋಕರ್ ನಿಭಾಯಿಸಬಹುದಾದ ಲೋಡ್‌ನ ಸ್ಥೂಲ ಕಲ್ಪನೆಯನ್ನು ಪಡೆಯಬಹುದು.

ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ಕೊಟ್ಟಿರುವ ಲೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಅಗತ್ಯವಿರುವ ದಲ್ಲಾಳಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸಹ ನಾವು ಅಂದಾಜು ಮಾಡಬಹುದು. ಆದಾಗ್ಯೂ, ಪ್ರಾಯೋಗಿಕವಾಗಿ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಹಲವಾರು ಸಂರಚನಾ ಆಯ್ಕೆಗಳಿವೆ, ನಿರ್ದಿಷ್ಟ ಸಂರಚನೆಯ ಸಂಭಾವ್ಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ತುಂಬಾ ಕಷ್ಟ (ಅಸಾಧ್ಯವಲ್ಲದಿದ್ದರೆ). ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಆಧರಿಸಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಯೋಜಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ.

Supertubes ಬಳಕೆದಾರರಿಗೆ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಳಗಿನ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ: ನಾವು ಕೆಲವು ಕಾನ್ಫಿಗರೇಶನ್ (ಮೂಲಸೌಕರ್ಯ + ಸೆಟ್ಟಿಂಗ್‌ಗಳು) ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ, ನಂತರ ಅದರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯಿರಿ, ಬ್ರೋಕರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮತ್ತೆ ಪುನರಾವರ್ತಿಸಿ. ಮೂಲಭೂತ ಸೌಕರ್ಯದ ನಿಧಾನವಾದ ಘಟಕವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಿಕೊಳ್ಳುವವರೆಗೆ ಇದು ಸಂಭವಿಸುತ್ತದೆ.

ಈ ರೀತಿಯಾಗಿ, ಒಂದು ಕ್ಲಸ್ಟರ್‌ಗೆ ಎಷ್ಟು ದಲ್ಲಾಳಿಗಳು ನಿರ್ದಿಷ್ಟ ಲೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕು ಎಂಬ ಸ್ಪಷ್ಟ ಕಲ್ಪನೆಯನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ (ದಲ್ಲಾಳಿಗಳ ಸಂಖ್ಯೆಯು ಇತರ ಅಂಶಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಸಂದೇಶ ಪ್ರತಿಕೃತಿಗಳು, ವಿಭಜನೆಯ ಸಂಖ್ಯೆ. ನಾಯಕರು, ಇತ್ಯಾದಿ). ಹೆಚ್ಚುವರಿಯಾಗಿ, ಯಾವ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳಿಗೆ ಲಂಬ ಸ್ಕೇಲಿಂಗ್ ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಒಳನೋಟವನ್ನು ಪಡೆಯುತ್ತೇವೆ.

ಈ ಲೇಖನವು ಆರಂಭಿಕ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿನ ನಿಧಾನವಾದ ಘಟಕಗಳಿಂದ ಹೆಚ್ಚಿನದನ್ನು ಪಡೆಯಲು ಮತ್ತು ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನ ಥ್ರೋಪುಟ್ ಅನ್ನು ಅಳೆಯಲು ನಾವು ತೆಗೆದುಕೊಳ್ಳುವ ಹಂತಗಳ ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ. ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಸಂರಚನೆಗೆ ಕನಿಷ್ಠ ಮೂರು ರನ್ನಿಂಗ್ ಬ್ರೋಕರ್‌ಗಳ ಅಗತ್ಯವಿದೆ (min.insync.replicas=3), ಮೂರು ವಿಭಿನ್ನ ಪ್ರವೇಶ ವಲಯಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು, ಅಳೆಯಲು ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು, ನಾವು ಹೈಬ್ರಿಡ್ ಮೋಡಗಳಿಗಾಗಿ ನಮ್ಮದೇ ಕಂಟೇನರ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ - ಪೈಪ್ಲೈನ್. ಇದು ಆನ್-ಪ್ರಿಮೈಸ್ (ಬೇರ್ ಮೆಟಲ್, VMware) ಮತ್ತು ಐದು ವಿಧದ ಮೋಡಗಳನ್ನು (ಅಲಿಬಾಬಾ, AWS, Azure, Google, Oracle), ಹಾಗೆಯೇ ಅವುಗಳ ಯಾವುದೇ ಸಂಯೋಜನೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಸಂರಚನೆಯ ಕುರಿತು ಆಲೋಚನೆಗಳು

ಕೆಳಗಿನ ಉದಾಹರಣೆಗಳಿಗಾಗಿ, ನಾವು AWS ಅನ್ನು ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರಾಗಿ ಮತ್ತು EKS ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ವಿತರಣೆಯಾಗಿ ಆರಿಸಿದ್ದೇವೆ. ಇದೇ ರೀತಿಯ ಸಂರಚನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಪಿಕೆಇ - ಬಂಜಾಯ್ ಕ್ಲೌಡ್‌ನಿಂದ ಕುಬರ್ನೆಟ್ಸ್ ವಿತರಣೆ, CNCF ನಿಂದ ಪ್ರಮಾಣೀಕರಿಸಲ್ಪಟ್ಟಿದೆ.

ಡಿಸ್ಕ್

ಅಮೆಜಾನ್ ವಿವಿಧ ಕೊಡುಗೆಗಳನ್ನು ನೀಡುತ್ತದೆ ಇಬಿಎಸ್ ವಾಲ್ಯೂಮ್ ವಿಧಗಳು. ಕೋರ್ ನಲ್ಲಿ ಜಿಪಿ 2 и io1 ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಥ್ರೋಪುಟ್ ಅನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು SSD ಡ್ರೈವ್‌ಗಳಿವೆ ಜಿಪಿ 2 ಸಂಚಿತ ಸಾಲಗಳನ್ನು ಬಳಸುತ್ತದೆ (I/O ಕ್ರೆಡಿಟ್‌ಗಳು), ಆದ್ದರಿಂದ ನಾವು ಪ್ರಕಾರವನ್ನು ಆದ್ಯತೆ ನೀಡಿದ್ದೇವೆ io1, ಇದು ಸ್ಥಿರವಾದ ಹೆಚ್ಚಿನ ಥ್ರೋಪುಟ್ ಅನ್ನು ನೀಡುತ್ತದೆ.

ನಿದರ್ಶನದ ಪ್ರಕಾರಗಳು

ಕಾಫ್ಕಾ ಅವರ ಕಾರ್ಯನಿರ್ವಹಣೆಯು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಪುಟ ಸಂಗ್ರಹದ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಮಗೆ ದಲ್ಲಾಳಿಗಳಿಗೆ (JVM) ಮತ್ತು ಪುಟ ಸಂಗ್ರಹಕ್ಕಾಗಿ ಸಾಕಷ್ಟು ಮೆಮೊರಿಯೊಂದಿಗೆ ನಿದರ್ಶನಗಳು ಬೇಕಾಗುತ್ತವೆ. ನಿದರ್ಶನ c5.2x ದೊಡ್ಡದು - ಉತ್ತಮ ಆರಂಭ, ಏಕೆಂದರೆ ಇದು 16 GB ಮೆಮೊರಿ ಮತ್ತು EBS ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ. ಇದರ ಅನನುಕೂಲವೆಂದರೆ ಅದು ಪ್ರತಿ 30 ಗಂಟೆಗಳಿಗೊಮ್ಮೆ 24 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮಾತ್ರ ಒದಗಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ. ನಿಮ್ಮ ಕೆಲಸದ ಹೊರೆಯು ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ಇತರ ನಿದರ್ಶನ ಪ್ರಕಾರಗಳನ್ನು ಪರಿಗಣಿಸಲು ಬಯಸಬಹುದು. ಅದನ್ನೇ ನಾವು ನಿಲ್ಲಿಸಿದ್ದೇವೆ c5.4x ದೊಡ್ಡದು. ಇದು ಗರಿಷ್ಠ ಥ್ರೋಪುಟ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ 593,75 Mb/s. EBS ಪರಿಮಾಣದ ಗರಿಷ್ಠ ಥ್ರೋಪುಟ್ io1 ನಿದರ್ಶನಕ್ಕಿಂತ ಹೆಚ್ಚಿನದು c5.4x ದೊಡ್ಡದು, ಆದ್ದರಿಂದ ಮೂಲಸೌಕರ್ಯದ ನಿಧಾನವಾದ ಅಂಶವು ಈ ನಿದರ್ಶನ ಪ್ರಕಾರದ I/O ಥ್ರೋಪುಟ್ ಆಗಿರಬಹುದು (ಇದನ್ನು ನಮ್ಮ ಲೋಡ್ ಪರೀಕ್ಷೆಗಳು ಸಹ ದೃಢೀಕರಿಸಬೇಕು).

ನೆಟ್ವರ್ಕ್

VM ನಿದರ್ಶನ ಮತ್ತು ಡಿಸ್ಕ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಹೋಲಿಸಿದರೆ ನೆಟ್‌ವರ್ಕ್ ಥ್ರೋಪುಟ್ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ನೆಟ್‌ವರ್ಕ್ ಅಡಚಣೆಯಾಗುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ c5.4x ದೊಡ್ಡದು 10 Gb/s ವರೆಗಿನ ವೇಗವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಇದು VM ನಿದರ್ಶನದ I/O ಥ್ರೋಪುಟ್‌ಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ.

ಬ್ರೋಕರ್ ನಿಯೋಜನೆ

CPU, ಮೆಮೊರಿ, ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಡಿಸ್ಕ್ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಡೆಡಿಕೇಟೆಡ್ ನೋಡ್‌ಗಳಿಗೆ ಬ್ರೋಕರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಬೇಕು (ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ).

ಜಾವಾ ಆವೃತ್ತಿ

ತಾರ್ಕಿಕ ಆಯ್ಕೆಯು Java 11 ಆಗಿದೆ ಏಕೆಂದರೆ ಇದು ಡಾಕರ್‌ನೊಂದಿಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಬ್ರೋಕರ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗೆ ಲಭ್ಯವಿರುವ ಪ್ರೊಸೆಸರ್‌ಗಳು ಮತ್ತು ಮೆಮೊರಿಯನ್ನು JVM ಸರಿಯಾಗಿ ನಿರ್ಧರಿಸುತ್ತದೆ. CPU ಮಿತಿಗಳು ಮುಖ್ಯವೆಂದು ತಿಳಿದುಕೊಂಡು, JVM ಆಂತರಿಕವಾಗಿ ಮತ್ತು ಪಾರದರ್ಶಕವಾಗಿ GC ಥ್ರೆಡ್‌ಗಳು ಮತ್ತು JIT ಥ್ರೆಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ನಾವು ಕಾಫ್ಕಾ ಚಿತ್ರವನ್ನು ಬಳಸಿದ್ದೇವೆ banzaicloud/kafka:2.13-2.4.0, ಇದು ಜಾವಾ 2.4.0 ನಲ್ಲಿ ಕಾಫ್ಕಾ ಆವೃತ್ತಿ 2.13 (ಸ್ಕಲಾ 11) ಅನ್ನು ಒಳಗೊಂಡಿದೆ.

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಜಾವಾ/ಜೆವಿಎಂ ಕುರಿತು ನೀವು ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ನಮ್ಮ ಕೆಳಗಿನ ಪೋಸ್ಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ:

• ನನ್ನ ಜಾವಾ ಅಪ್ಲಿಕೇಶನ್ ಏಕೆ OOMKilled ಆಗಿದೆ;
• ಜಾವಾ 10 ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಕಂಟೇನರ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಗಾತ್ರ ಮಾಡುವುದು ಹೇಗೆ.

ಬ್ರೋಕರ್ ಮೆಮೊರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು

ಬ್ರೋಕರ್ ಮೆಮೊರಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಎರಡು ಪ್ರಮುಖ ಅಂಶಗಳಿವೆ: JVM ಗಾಗಿ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್‌ಗಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು. ಪಾಡ್‌ಗಾಗಿ ಹೊಂದಿಸಲಾದ ಮೆಮೊರಿ ಮಿತಿಯು ಗರಿಷ್ಠ ರಾಶಿ ಗಾತ್ರಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರಬೇಕು ಆದ್ದರಿಂದ JVM ತನ್ನದೇ ಆದ ಮೆಮೊರಿಯಲ್ಲಿ ನೆಲೆಸಿರುವ ಜಾವಾ ಮೆಟಾಸ್ಪೇಸ್‌ಗೆ ಮತ್ತು ಕಾಫ್ಕಾ ಸಕ್ರಿಯವಾಗಿ ಬಳಸುವ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಪುಟ ಸಂಗ್ರಹಕ್ಕಾಗಿ ಸ್ಥಳಾವಕಾಶವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ನಮ್ಮ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ನಾವು ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಕಾಫ್ಕಾ ಬ್ರೋಕರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ -Xmx4G -Xms2G, ಮತ್ತು ಪಾಡ್‌ಗೆ ಮೆಮೊರಿ ಮಿತಿ ಇತ್ತು 10 Gi. JVM ಗಾಗಿ ಮೆಮೊರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪಡೆಯಬಹುದು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ -XX:MaxRAMPercentage и -X:MinRAMPercentage, ಪಾಡ್‌ಗೆ ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ಆಧರಿಸಿ.

ಬ್ರೋಕರ್ ಪ್ರೊಸೆಸರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು

ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಕಾಫ್ಕಾ ಬಳಸುವ ಥ್ರೆಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಸಮಾನಾಂತರತೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ನೀವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು. ಕಾಫ್ಕಾಗೆ ಹೆಚ್ಚು ಪ್ರೊಸೆಸರ್‌ಗಳು ಲಭ್ಯವಿದ್ದರೆ ಉತ್ತಮ. ನಮ್ಮ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ನಾವು 6 ಪ್ರೊಸೆಸರ್‌ಗಳ ಮಿತಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಕ್ರಮೇಣ (ಪುನರಾವರ್ತನೆಯ ಮೂಲಕ) ಅವುಗಳ ಸಂಖ್ಯೆಯನ್ನು 15 ಕ್ಕೆ ಹೆಚ್ಚಿಸಿದ್ದೇವೆ. ಜೊತೆಗೆ, ನಾವು ಹೊಂದಿಸಿದ್ದೇವೆ. num.network.threads=12 ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವ ಮತ್ತು ಅದನ್ನು ಕಳುಹಿಸುವ ಥ್ರೆಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಬ್ರೋಕರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ. ಅನುಯಾಯಿ ದಲ್ಲಾಳಿಗಳು ಪ್ರತಿಕೃತಿಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ತಕ್ಷಣವೇ ಕಂಡುಹಿಡಿದರು, ಅವರು ಬೆಳೆದರು num.replica.fetchers 4 ಕ್ಕೆ ಅನುಸರಿಸುವ ದಲ್ಲಾಳಿಗಳು ನಾಯಕರಿಂದ ಸಂದೇಶಗಳನ್ನು ಪುನರಾವರ್ತಿಸುವ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲು.

ಲೋಡ್ ಜನರೇಷನ್ ಟೂಲ್

ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ (ಬೆಂಚ್‌ಮಾರ್ಕ್ ಮಾಡಲಾಗುತ್ತಿದೆ) ಅದರ ಗರಿಷ್ಠ ಲೋಡ್ ಅನ್ನು ತಲುಪುವ ಮೊದಲು ಆಯ್ಕೆಮಾಡಿದ ಲೋಡ್ ಜನರೇಟರ್ ಸಾಮರ್ಥ್ಯವು ಖಾಲಿಯಾಗುವುದಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಲೋಡ್ ಉತ್ಪಾದನಾ ಉಪಕರಣದ ಸಾಮರ್ಥ್ಯಗಳ ಪ್ರಾಥಮಿಕ ಮೌಲ್ಯಮಾಪನವನ್ನು ನಡೆಸುವುದು ಅವಶ್ಯಕವಾಗಿದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯ ಪ್ರೊಸೆಸರ್‌ಗಳು ಮತ್ತು ಮೆಮೊರಿಯೊಂದಿಗೆ ಅದಕ್ಕೆ ನಿದರ್ಶನ ಪ್ರಕಾರಗಳನ್ನು ಸಹ ಆಯ್ಕೆಮಾಡಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಮ್ಮ ಉಪಕರಣವು ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ನಿಭಾಯಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಲೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಅನೇಕ ಪ್ರಯೋಗಗಳ ನಂತರ, ನಾವು ಮೂರು ಪ್ರತಿಗಳಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ c5.4x ದೊಡ್ಡದು, ಪ್ರತಿಯೊಂದೂ ಜನರೇಟರ್ ಚಾಲನೆಯಲ್ಲಿದೆ.

ಬೆಂಚ್ಮಾರ್ಕಿಂಗ್

ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಾಪನವು ಈ ಕೆಳಗಿನ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪುನರಾವರ್ತಿತ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ:

• ಮೂಲಸೌಕರ್ಯವನ್ನು ಸ್ಥಾಪಿಸುವುದು (ಇಕೆಎಸ್ ಕ್ಲಸ್ಟರ್, ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್, ಲೋಡ್ ಜನರೇಷನ್ ಟೂಲ್, ಹಾಗೆಯೇ ಪ್ರಮೀತಿಯಸ್ ಮತ್ತು ಗ್ರಾಫಾನಾ);
• ಸಂಗ್ರಹಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆ ಸೂಚಕಗಳಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ವಿಚಲನಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ನಿರ್ದಿಷ್ಟ ಅವಧಿಗೆ ಲೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುವುದು;
• ಗಮನಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆ ಸೂಚಕಗಳ ಆಧಾರದ ಮೇಲೆ ಬ್ರೋಕರ್‌ನ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಸಂರಚನೆಯನ್ನು ಸರಿಹೊಂದಿಸುವುದು;
• ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ಥ್ರೋಪುಟ್‌ನ ಅಗತ್ಯ ಮಟ್ಟವನ್ನು ಸಾಧಿಸುವವರೆಗೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸುವುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ಸ್ಥಿರವಾಗಿ ಪುನರುತ್ಪಾದಿಸಲ್ಪಡಬೇಕು ಮತ್ತು ಥ್ರೋಪುಟ್ನಲ್ಲಿ ಕನಿಷ್ಠ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಪ್ರದರ್ಶಿಸಬೇಕು.

ಮುಂದಿನ ವಿಭಾಗವು ಪರೀಕ್ಷಾ ಕ್ಲಸ್ಟರ್ ಬೆಂಚ್‌ಮಾರ್ಕಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಿರ್ವಹಿಸಲಾದ ಹಂತಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಪರಿಕರಗಳು

ಬೇಸ್‌ಲೈನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ನಿಯೋಜಿಸಲು, ಲೋಡ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯಲು ಈ ಕೆಳಗಿನ ಸಾಧನಗಳನ್ನು ಬಳಸಲಾಗಿದೆ:

• ಬಂಝೈ ಕ್ಲೌಡ್ ಪೈಪ್ಲೈನ್ Amazon c ನಿಂದ EKS ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಘಟಿಸಲು ಪ್ರಮೀತಿಯಸ್ (ಕಾಫ್ಕಾ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು) ಮತ್ತು ಗ್ರಾಫಾನಾ (ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ದೃಶ್ಯೀಕರಿಸಲು). ನಾವು ಪ್ರಯೋಜನ ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ в ಪೈಪ್ಲೈನ್ ಫೆಡರೇಟೆಡ್ ಮಾನಿಟರಿಂಗ್, ಕೇಂದ್ರೀಕೃತ ಲಾಗ್ ಸಂಗ್ರಹಣೆ, ದುರ್ಬಲತೆ ಸ್ಕ್ಯಾನಿಂಗ್, ವಿಪತ್ತು ಚೇತರಿಕೆ, ಎಂಟರ್‌ಪ್ರೈಸ್ ದರ್ಜೆಯ ಭದ್ರತೆ ಮತ್ತು ಹೆಚ್ಚಿನದನ್ನು ಒದಗಿಸುವ ಸೇವೆಗಳು.
• ಸಂಗ್ರೆನೆಲ್ - ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಲೋಡ್ ಪರೀಕ್ಷೆಗೆ ಒಂದು ಸಾಧನ.
• ಕಾಫ್ಕಾ ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಮೂಲಸೌಕರ್ಯವನ್ನು ದೃಶ್ಯೀಕರಿಸಲು ಗ್ರಾಫನಾ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು: ಕುಬರ್ನೆಟ್ಸ್ ಕಾಫ್ಕಾ, ನೋಡ್ ರಫ್ತುದಾರ.
• ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗಕ್ಕಾಗಿ ಸೂಪರ್‌ಟ್ಯೂಬ್‌ಗಳು CLI. ಝೂಕೀಪರ್, ಕಾಫ್ಕಾ ಆಪರೇಟರ್, ಎನ್ವಾಯ್ ಮತ್ತು ಇತರ ಹಲವು ಘಟಕಗಳನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಉತ್ಪಾದನೆಗೆ ಸಿದ್ಧವಾಗಿರುವ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.
  • ಸ್ಥಾಪಿಸಲು ಸೂಪರ್ಟ್ಯೂಬ್ಗಳು CLI ಒದಗಿಸಿದ ಸೂಚನೆಗಳನ್ನು ಬಳಸಿ ಇಲ್ಲಿ.

ಇಕೆಎಸ್ ಕ್ಲಸ್ಟರ್

ಮೀಸಲಾದ ವರ್ಕರ್ ನೋಡ್‌ಗಳೊಂದಿಗೆ EKS ಕ್ಲಸ್ಟರ್ ಅನ್ನು ತಯಾರಿಸಿ c5.4x ದೊಡ್ಡದು ಕಾಫ್ಕಾ ಬ್ರೋಕರ್‌ಗಳೊಂದಿಗೆ ಪಾಡ್‌ಗಳಿಗಾಗಿ ವಿವಿಧ ಲಭ್ಯತೆಯ ವಲಯಗಳಲ್ಲಿ, ಹಾಗೆಯೇ ಲೋಡ್ ಜನರೇಟರ್ ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ ಮೀಸಲಾದ ನೋಡ್‌ಗಳು.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

ಒಮ್ಮೆ EKS ಕ್ಲಸ್ಟರ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಅದರ ಸಮಗ್ರತೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ ಮೇಲ್ವಿಚಾರಣಾ ಸೇವೆ - ಅವಳು ಪ್ರಮೀತಿಯಸ್ ಮತ್ತು ಗ್ರಾಫನಾರನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿಯೋಜಿಸುತ್ತಾಳೆ.

ಕಾಫ್ಕಾ ಸಿಸ್ಟಮ್ ಘಟಕಗಳು

ಸೂಪರ್‌ಟ್ಯೂಬ್‌ಗಳು CLI ಅನ್ನು ಬಳಸಿಕೊಂಡು EKS ನಲ್ಲಿ ಕಾಫ್ಕಾ ಸಿಸ್ಟಮ್ ಘಟಕಗಳನ್ನು (Zookeeper, kafka-operator) ಸ್ಥಾಪಿಸಿ:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, EKS ಪ್ರಕಾರದ EBS ಸಂಪುಟಗಳನ್ನು ಬಳಸುತ್ತದೆ ಜಿಪಿ 2, ಆದ್ದರಿಂದ ನೀವು ಸಂಪುಟಗಳ ಆಧಾರದ ಮೇಲೆ ಪ್ರತ್ಯೇಕ ಶೇಖರಣಾ ವರ್ಗವನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ io1 ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

ಬ್ರೋಕರ್‌ಗಳಿಗಾಗಿ ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿಸಿ min.insync.replicas=3 ಮತ್ತು ಮೂರು ವಿಭಿನ್ನ ಲಭ್ಯತೆಯ ವಲಯಗಳಲ್ಲಿ ನೋಡ್‌ಗಳಲ್ಲಿ ಬ್ರೋಕರ್ ಪಾಡ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

ವಿಷಯಗಳು

ನಾವು ಮೂರು ಲೋಡ್ ಜನರೇಟರ್ ನಿದರ್ಶನಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಸಿದ್ದೇವೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮದೇ ಆದ ವಿಷಯಕ್ಕೆ ಬರೆಯುತ್ತಾರೆ, ಅಂದರೆ, ನಮಗೆ ಒಟ್ಟು ಮೂರು ವಿಷಯಗಳು ಬೇಕಾಗುತ್ತವೆ:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

ಪ್ರತಿ ವಿಷಯಕ್ಕೆ, ಪುನರಾವರ್ತನೆಯ ಅಂಶವು 3 ಆಗಿದೆ-ಹೆಚ್ಚು ಲಭ್ಯವಿರುವ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಕನಿಷ್ಠ ಶಿಫಾರಸು ಮೌಲ್ಯ.

ಲೋಡ್ ಜನರೇಷನ್ ಟೂಲ್

ನಾವು ಲೋಡ್ ಜನರೇಟರ್ನ ಮೂರು ಪ್ರತಿಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ (ಪ್ರತಿಯೊಬ್ಬರೂ ಪ್ರತ್ಯೇಕ ವಿಷಯದಲ್ಲಿ ಬರೆದಿದ್ದಾರೆ). ಲೋಡ್ ಜನರೇಟರ್ ಪಾಡ್‌ಗಳಿಗಾಗಿ, ನೀವು ನೋಡ್ ಅಫಿನಿಟಿಯನ್ನು ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ ಇದರಿಂದ ಅವುಗಳಿಗೆ ನಿಗದಿಪಡಿಸಿದ ನೋಡ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

ಗಮನಿಸಬೇಕಾದ ಕೆಲವು ಅಂಶಗಳು:

• ಲೋಡ್ ಜನರೇಟರ್ ಉದ್ದದ 512 ಬೈಟ್‌ಗಳ ಸಂದೇಶಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು 500 ಸಂದೇಶಗಳ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಕಾಫ್ಕಾಗೆ ಪ್ರಕಟಿಸುತ್ತದೆ.
• ವಾದವನ್ನು ಬಳಸುವುದು -required-acks=all ಸಂದೇಶದ ಎಲ್ಲಾ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಮತ್ತು ಕಾಫ್ಕಾ ದಲ್ಲಾಳಿಗಳಿಂದ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಾಗ ಪ್ರಕಟಣೆಯು ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಇದರರ್ಥ ಮಾನದಂಡದಲ್ಲಿ ನಾವು ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ನಾಯಕರ ವೇಗವನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಅವರ ಅನುಯಾಯಿಗಳು ಸಂದೇಶಗಳನ್ನು ಪುನರಾವರ್ತಿಸುವ ವೇಗವನ್ನು ಅಳೆಯುತ್ತೇವೆ. ಈ ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶವು ಗ್ರಾಹಕರ ಓದುವ ವೇಗವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಅಲ್ಲ (ಗ್ರಾಹಕರು) OS ಪುಟದ ಸಂಗ್ರಹದಲ್ಲಿ ಇನ್ನೂ ಉಳಿದಿರುವ ಸಂದೇಶಗಳನ್ನು ಇತ್ತೀಚೆಗೆ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಸಂದೇಶಗಳ ಓದುವ ವೇಗದೊಂದಿಗೆ ಅದರ ಹೋಲಿಕೆ.
• ಲೋಡ್ ಜನರೇಟರ್ ಸಮಾನಾಂತರವಾಗಿ 20 ಕೆಲಸಗಾರರನ್ನು ನಡೆಸುತ್ತದೆ (-workers=20) ಪ್ರತಿ ಕೆಲಸಗಾರ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ಗೆ ಕಾರ್ಮಿಕರ ಸಂಪರ್ಕವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ 5 ಉತ್ಪಾದಕರನ್ನು ಒಳಗೊಂಡಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿ ಜನರೇಟರ್ 100 ಉತ್ಪಾದಕರನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅವರೆಲ್ಲರೂ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ.

ಕ್ಲಸ್ಟರ್ನ ಆರೋಗ್ಯದ ಮೇಲ್ವಿಚಾರಣೆ

ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನ ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಯಾವುದೇ ಪಾಡ್ ರೀಸ್ಟಾರ್ಟ್‌ಗಳು, ಸಿಂಕ್-ಆಫ್-ಸಿಂಕ್ ಪ್ರತಿಕೃತಿಗಳು ಮತ್ತು ಕನಿಷ್ಠ ಏರಿಳಿತಗಳೊಂದಿಗೆ ಗರಿಷ್ಠ ಥ್ರೋಪುಟ್ ಇಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಅದರ ಆರೋಗ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇವೆ:

• ಲೋಡ್ ಜನರೇಟರ್ ಪ್ರಕಟಿಸಿದ ಸಂದೇಶಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ದೋಷ ದರದ ಬಗ್ಗೆ ಪ್ರಮಾಣಿತ ಅಂಕಿಅಂಶಗಳನ್ನು ಬರೆಯುತ್ತದೆ. ದೋಷ ಪ್ರಮಾಣವು ಒಂದೇ ಆಗಿರಬೇಕು 0,00%.
• ಹಡಗು ನಿಯಂತ್ರಣ, ಕಾಫ್ಕಾ-ಆಪರೇಟರ್‌ನಿಂದ ನಿಯೋಜಿಸಲಾಗಿದೆ, ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ ಅಲ್ಲಿ ನಾವು ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು. ಈ ಫಲಕವನ್ನು ವೀಕ್ಷಿಸಲು ಹೀಗೆ ಮಾಡಿ:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISR ಮಟ್ಟ ("ಇನ್-ಸಿಂಕ್" ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆ) ಕುಗ್ಗುವಿಕೆ ಮತ್ತು ವಿಸ್ತರಣೆಯು 0 ಗೆ ಸಮಾನವಾಗಿರುತ್ತದೆ.

ಮಾಪನ ಫಲಿತಾಂಶಗಳು

3 ದಲ್ಲಾಳಿಗಳು, ಸಂದೇಶದ ಗಾತ್ರ - 512 ಬೈಟ್‌ಗಳು

ಮೂರು ದಲ್ಲಾಳಿಗಳಾದ್ಯಂತ ವಿಭಾಗಗಳನ್ನು ಸಮವಾಗಿ ವಿತರಿಸುವುದರೊಂದಿಗೆ, ನಾವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಯಿತು ~500 Mb/s (ಸೆಕೆಂಡಿಗೆ ಸರಿಸುಮಾರು 990 ಸಾವಿರ ಸಂದೇಶಗಳು):

JVM ವರ್ಚುವಲ್ ಯಂತ್ರದ ಮೆಮೊರಿ ಬಳಕೆ 2 GB ಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ:

ದಲ್ಲಾಳಿಗಳು ಚಾಲನೆಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಮೂರು ನಿದರ್ಶನಗಳಲ್ಲಿ ಡಿಸ್ಕ್ ಥ್ರೋಪುಟ್ ಗರಿಷ್ಠ I/O ನೋಡ್ ಥ್ರೋಪುಟ್ ಅನ್ನು ತಲುಪಿದೆ:

ನೋಡ್‌ಗಳ ಮೂಲಕ ಮೆಮೊರಿ ಬಳಕೆಯ ಡೇಟಾದಿಂದ, ಸಿಸ್ಟಮ್ ಬಫರಿಂಗ್ ಮತ್ತು ಕ್ಯಾಶಿಂಗ್ ~ 10-15 GB ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಅನುಸರಿಸುತ್ತದೆ:

3 ದಲ್ಲಾಳಿಗಳು, ಸಂದೇಶದ ಗಾತ್ರ - 100 ಬೈಟ್‌ಗಳು

ಸಂದೇಶದ ಗಾತ್ರವು ಕಡಿಮೆಯಾದಂತೆ, ಥ್ರೋಪುಟ್ ಸರಿಸುಮಾರು 15-20% ರಷ್ಟು ಇಳಿಯುತ್ತದೆ: ಪ್ರತಿ ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಸಮಯವು ಅದರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಜೊತೆಗೆ, ಪ್ರೊಸೆಸರ್ ಲೋಡ್ ಬಹುತೇಕ ದ್ವಿಗುಣಗೊಂಡಿದೆ.

ಬ್ರೋಕರ್ ನೋಡ್‌ಗಳು ಇನ್ನೂ ಬಳಕೆಯಾಗದ ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಕಾಫ್ಕಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು. ಇದು ಸುಲಭದ ಕೆಲಸವಲ್ಲ, ಆದ್ದರಿಂದ ಥ್ರೋಪುಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲು ದೊಡ್ಡ ಸಂದೇಶಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಉತ್ತಮ.

4 ದಲ್ಲಾಳಿಗಳು, ಸಂದೇಶದ ಗಾತ್ರ - 512 ಬೈಟ್‌ಗಳು

ಹೊಸ ಬ್ರೋಕರ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಮತ್ತು ವಿಭಾಗಗಳ ಸಮತೋಲನವನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ನೀವು ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಲಭವಾಗಿ ಹೆಚ್ಚಿಸಬಹುದು (ಇದು ದಲ್ಲಾಳಿಗಳ ನಡುವೆ ಲೋಡ್ ಅನ್ನು ಸಮವಾಗಿ ವಿತರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ). ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಬ್ರೋಕರ್ ಅನ್ನು ಸೇರಿಸಿದ ನಂತರ, ಕ್ಲಸ್ಟರ್ ಥ್ರೋಪುಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ ~580 Mb/s (ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ~1,1 ಮಿಲಿಯನ್ ಸಂದೇಶಗಳು). ಬೆಳವಣಿಗೆಯು ನಿರೀಕ್ಷೆಗಿಂತ ಕಡಿಮೆಯಾಗಿದೆ: ಇದು ಮುಖ್ಯವಾಗಿ ವಿಭಾಗಗಳ ಅಸಮತೋಲನದಿಂದ ವಿವರಿಸಲ್ಪಟ್ಟಿದೆ (ಎಲ್ಲಾ ದಲ್ಲಾಳಿಗಳು ತಮ್ಮ ಸಾಮರ್ಥ್ಯಗಳ ಉತ್ತುಂಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ).

JVM ಯಂತ್ರದ ಮೆಮೊರಿ ಬಳಕೆ 2 GB ಗಿಂತ ಕಡಿಮೆಯಿತ್ತು:

ಡ್ರೈವ್‌ಗಳೊಂದಿಗಿನ ಬ್ರೋಕರ್‌ಗಳ ಕೆಲಸವು ವಿಭಾಗಗಳ ಅಸಮತೋಲನದಿಂದ ಪ್ರಭಾವಿತವಾಗಿದೆ:

ಸಂಶೋಧನೆಗಳು

ನೂರಾರು ಗ್ರಾಹಕರು, ಮರುವಿಂಗಡಣೆ, ರೋಲಿಂಗ್ ನವೀಕರಣಗಳು, ಪಾಡ್ ಪುನರಾರಂಭಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಸನ್ನಿವೇಶಗಳನ್ನು ಒಳಗೊಳ್ಳಲು ಮೇಲೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಪುನರಾವರ್ತನೆಯ ವಿಧಾನವನ್ನು ವಿಸ್ತರಿಸಬಹುದು. ವಿವಿಧ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನ ಸಾಮರ್ಥ್ಯಗಳ ಮಿತಿಗಳನ್ನು ನಿರ್ಣಯಿಸಲು, ಅದರ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿನ ಅಡಚಣೆಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಎದುರಿಸುವ ಮಾರ್ಗಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಇವೆಲ್ಲವೂ ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಕ್ಲಸ್ಟರ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಸುಲಭವಾಗಿ ನಿಯೋಜಿಸಲು, ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು, ಬ್ರೋಕರ್‌ಗಳು ಮತ್ತು ವಿಷಯಗಳನ್ನು ಸೇರಿಸಲು/ತೆಗೆದುಹಾಕಲು, ಎಚ್ಚರಿಕೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳಲ್ಲಿ ಕಾಫ್ಕಾ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಸೂಪರ್‌ಟ್ಯೂಬ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದೇವೆ. ಮುಖ್ಯ ಕಾರ್ಯದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುವುದು ನಮ್ಮ ಗುರಿಯಾಗಿದೆ (ಕಾಫ್ಕಾ ಸಂದೇಶಗಳನ್ನು "ರಚಿಸಿ" ಮತ್ತು "ಸೇವಿಸುವುದು"), ಮತ್ತು ಎಲ್ಲಾ ಕಠಿಣ ಕೆಲಸವನ್ನು ಸೂಪರ್‌ಟ್ಯೂಬ್‌ಗಳು ಮತ್ತು ಕಾಫ್ಕಾ ಆಪರೇಟರ್‌ಗೆ ಬಿಟ್ಟುಬಿಡಿ.

ನೀವು Banzai ಕ್ಲೌಡ್ ತಂತ್ರಜ್ಞಾನಗಳು ಮತ್ತು ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ಕಂಪನಿಗೆ ಚಂದಾದಾರರಾಗಿ GitHub, ಸಂದೇಶ ಅಥವಾ ಟ್ವಿಟರ್.

ಅನುವಾದಕರಿಂದ PS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

• «K8s ನಲ್ಲಿ Redis ಆಪರೇಟರ್‌ನೊಂದಿಗೆ ಒಂದು ಕಥೆ ಮತ್ತು ಈ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಉಪಯುಕ್ತತೆಗಳ ಕಿರು-ವಿಮರ್ಶೆ";
• «Kubernetes ಗೆ RabbitMQ ನ ತಡೆರಹಿತ ವಲಸೆ";
• «CoreOS ನಿಂದ zetcd: ZooKeeper ಅನ್ನು...ಇತ್ಯಾದಿ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗುತ್ತಿದೆ».

ಮೂಲ: www.habr.com