VPN ಮೇಲೆ Docker Swarm: ಕಾರ್ಯಗಳು ಚಲಿಸುತ್ತವೆ, ಸೇವಾ ಕರೆಗಳು ವಿಫಲವಾಗುತ್ತವೆ

ಎರಡು ಸೈಟ್‌ಗಳಲ್ಲಿ ಮೂರು ಮ್ಯಾನೇಜರ್‌ಗಳು ಮತ್ತು ಐದು ವರ್ಕರ್‌ಗಳು, ಒಂದು ಸುರಂಗದಿಂದ ಸೇರಿಸಲಾಗಿದೆ, ಮತ್ತು docker service ls ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಚಲಿಸುತ್ತಿರುವ ಕಾರ್ಯಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಸೇವೆಗಳ ನಡುವಿನ ಕರೆಗಳು ಸಮಯ ಮೀರುತ್ತವೆ. Swarm ಲಾಗ್‌ಗಳಲ್ಲಿ ಏನೂ ತಪ್ಪಾಗಿ ಕಾಣುತ್ತಿಲ್ಲ. ಆ ಸಂಯೋಜನೆ ಡೇಟಾ ಪ್ಲೇನ್ ಸಮಸ್ಯೆಯ ಸಹಿ: ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ನೋಡ್‌ಗಳನ್ನು ಕಂಡುಕೊಂಡಿತು, ಮತ್ತು ಸುತ್ತುವರಿದ ಫ್ರೇಮ್‌ಗಳು ಎಂದಿಗೂ ಪ್ರಯಾಣ ಮಾಡಲಿಲ್ಲ.

overlay ಗಿಂತ ಮೊದಲು mesh ಇರಬೇಕು

Swarm ನ overlay ಸುತ್ತುವರಿದ ಫ್ರೇಮ್‌ಗಳನ್ನು ನೇರವಾಗಿ ನೋಡ್ ವಿಳಾಸಗಳ ನಡುವೆ ತಳ್ಳುತ್ತದೆ, ಅಂದರೆ ಪ್ರತಿ ನೋಡ್‌ಗೆ ಪ್ರತಿ ಇತರ ನೋಡ್ ಅನುವಾದವಿಲ್ಲದೆ ತಲುಪಬಹುದಾದ ವಿಳಾಸ ಬೇಕು, ಸುರಂಗ ಒದಗಿಸುವ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ. ಕೇವಲ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪ್ರಕಟಿತ ಪೋರ್ಟ್‌ಗೆ ಕೊಂಡೊಯ್ಯುವ ಸುರಂಗ ಸಾಕಾಗುವುದಿಲ್ಲ. ಕೆಳಗಿನ ಪದರವು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ನೋಡ್‌ನಿಂದ ನೋಡ್‌ಗೆ ರೂಟ್ ಮಾಡಬೇಕು.

Swarm ಗೆ ಮುಟ್ಟುವ ಮೊದಲು ಇದನ್ನು ಪರೀಕ್ಷಿಸಿ. ಪ್ರತಿ ನೋಡ್‌ನಿಂದ ಸಹವರ್ತಿಯ ಸುರಂಗ ವಿಳಾಸಕ್ಕೆ ರೂಟ್ ಪರಿಶೀಲಿಸಿ, ಅದಕ್ಕೆ ping ಮಾಡಿ, ನಂತರ ನಿಯಂತ್ರಣ ಪೋರ್ಟ್ ಪರೀಕ್ಷಿಸಿ. ping ಕೆಲಸ ಮಾಡಿ ಪೋರ್ಟ್ ಮಾಡದಿದ್ದರೆ, ಸುರಂಗ ಸರಿಯಾಗಿದೆ ಮತ್ತು ದಾರಿಯಲ್ಲಿ ಒಂದು ಫಿಲ್ಟರ್ ಇದೆ.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

ರೂಟ್ tun0 ಅಥವಾ wg0 ಬದಲು ಭೌತಿಕ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ತೋರಿಸಿದರೆ, overlay ದೂರದ ಸೈಟ್ ತಲುಪಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಸುತ್ತುವರಿಯುತ್ತದೆ, ಮತ್ತು ಲಕ್ಷಣ ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಂತೆ ಕಾಣುತ್ತದೆ.

ಪ್ರತಿ ನೋಡ್ ಯಾವ ವಿಳಾಸವನ್ನು ಘೋಷಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಡೀಮನ್ ಒಂದು ವಿಳಾಸವನ್ನು ಘೋಷಿಸುತ್ತದೆ, ಮತ್ತು ಸಹವರ್ತಿಗಳು ಅದನ್ನು ಡೇಟಾ ಪ್ಲೇನ್‌ಗೆ ಬಳಸುತ್ತವೆ. ಬಹು ನೆಟ್‌ವರ್ಕ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಸುರಂಗ ಬೇರೆ ಏನನ್ನೋ ಸಾಗಿಸುತ್ತಿರುವಾಗ LAN ಅಥವಾ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ಘೋಷಿಸುವುದು ಸುಲಭ. ಊಹಿಸುವ ಬದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಡಿಫಾಲ್ಟ್ ತಪ್ಪಾಗಿದ್ದರೆ ಸೇರುವಾಗ --advertise-addr ನೊಂದಿಗೆ ಅದನ್ನು ಪಿನ್ ಮಾಡಿ. ತಾನು ಮಾತ್ರ ತಲುಪಬಹುದಾದ ವಿಳಾಸವನ್ನು ಘೋಷಿಸುವ ನೋಡ್ ಸಹ swarm ಗೆ ಸೇರುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯ ನಂತರ ಸೈಟ್‌ಗಳ ನಡುವೆ ಮಾತನಾಡಲಾಗದ ಸೇವೆಗಳಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಘೋಷಿತ ವಿಳಾಸವನ್ನು ನಂತರ ಬದಲಿಸುವುದು ಕಾನ್ಫಿಗ್ ಸಂಪಾದನೆ ಅಲ್ಲ, ಏಕೆಂದರೆ ನೋಡ್ ಹೊರಟು ಮತ್ತೆ ಸೇರಬೇಕು.

ಪ್ರತಿ ನೋಡ್‌ನ ಘೋಷಿತ ವಿಳಾಸವನ್ನು ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಅದು ಹೆಚ್ಚಿನ ಅಸಮಮಿತ ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

Masquerade ಸಾಮಾನ್ಯ ಅಪರಾಧಿ

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

overlay ನ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಗೇಟ್‌ವೇ ಮೂಲಕ ರೂಟ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಅನುವಾದಿಸದೆ ಬಿಡಿ. ಬೇರೆ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಅನುವಾದ ನಿಜವಾಗಿ ಬೇಕಿದ್ದರೆ, ಅಲ್ಲಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು overlay ಬಳಸುವ ಶ್ರೇಣಿಗೆ ಎಂದಿಗೂ ಅಲ್ಲ.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

ನಿಯಮಗಳ ಕ್ರಮ ಮತ್ತು ಪಠ್ಯ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಸರಪಳಿಯಲ್ಲಿ ಮೊದಲಿಗೆ ಇರುವ ಅಗಲವಾದ MASQUERADE ನಂತರದ ಸಂಕುಚಿತ ಅಪವಾದವನ್ನು ಸೋಲಿಸುತ್ತದೆ.

VXLAN ಗೆ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಜಾಗ ಬೇಕು

VXLAN ತಾನು ಸಾಗಿಸುವ ಫ್ರೇಮ್‌ಗಳಿಗೆ 50 ಬೈಟ್ ಸೇರಿಸುತ್ತದೆ. 1500 ಬೈಟ್‌ನ ಕೆಳ ಪದರವು 1500 ಬೈಟ್‌ನ ಒಳಗಿನ ಫ್ರೇಮ್ ಸಾಗಿಸಿದಾಗ ಯಾವ ಮಾರ್ಗವೂ ತಲುಪಿಸದ ಸುತ್ತುವರಿದ ಪ್ಯಾಕೆಟ್ ಉಂಟಾಗುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯ ಗಾತ್ರದ ಸಮಸ್ಯೆಯಂತೆ ಅಲ್ಲ, ಮಧ್ಯಂತರ ಸೇವಾ ಶೋಧದಂತೆ ಕಾಣುತ್ತದೆ. ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಸುರಂಗದ MTU ಕಡಿಮೆ ಮಾಡಿ ಅಥವಾ overlay ನ MTU ಅನ್ನು ಡ್ರೈವರ್ ಹೊಂದಿಕೊಳ್ಳುವ ಪೇಲೋಡ್ ಘೋಷಿಸುವಂತೆ ಹೊಂದಿಸಿ.

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

ingress ನೆಟ್‌ವರ್ಕ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚನೆಯಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಬದಲಿಸುವುದು ಎಂದರೆ ಸ್ಥಳದಲ್ಲೇ ಸಂಪಾದಿಸುವುದಲ್ಲ, ತೆಗೆದು ಮತ್ತೆ ರಚಿಸುವುದು.

ಸುರಂಗದ ಒಂದು ಬದಿಯನ್ನು ಮಾತ್ರ ಸರಿಪಡಿಸಿದರೆ, ಚಿಕ್ಕ MTU ಇನ್ನೂ ಮುಖ್ಯವಾದದ್ದೇ ಆಗಿರುತ್ತದೆ.

ಲಾಗ್ ಅಲ್ಲ, ಡೇಟಾ ಪ್ಲೇನ್ ನೋಡಿ

ಎರಡೂ ತುದಿಗಳಲ್ಲಿ VXLAN ಪೋರ್ಟ್ ಸೆರೆಹಿಡಿಯಿರಿ. ಒಂದು ಬದಿಯಿಂದ ಹೊರಟು ಇನ್ನೊಂದು ಬದಿಗೆ ತಲುಪುವ ಫ್ರೇಮ್‌ಗಳು ಕೆಳ ಪದರ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಸಮಸ್ಯೆ overlay ಒಳಗಿದೆ ಎಂದರ್ಥ. ಹೊರಟು ಎಂದಿಗೂ ತಲುಪದ ಫ್ರೇಮ್‌ಗಳು ಮಾರ್ಗ ಅಥವಾ ಫಿಲ್ಟರ್ ಎಂದರ್ಥ. ಸ್ವಲ್ಪವೂ ಹೊರಡದ ಫ್ರೇಮ್‌ಗಳು ಮೂಲ ವಿಳಾಸ ತಪ್ಪಾಗಿದೆ ಎಂದರ್ಥ.

ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ಮಾಯವಾಗುವ ಸೇವಾ ಶೋಧ ವೈಫಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ಯಾಕೆಟ್ ಬಜೆಟ್ ಅಥವಾ ಅಸ್ಥಿರ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತವೆ, raft ಕ್ವೋರಮ್ ಅನ್ನಲ್ಲ.

ಕೆಲಸ ಮಾಡುವ ವಿಂಡೋದ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಇರಿಸಿ, ಏಕೆಂದರೆ ಅದನ್ನು ಮುರಿದದ್ದಕ್ಕೆ ಹೋಲಿಸುವುದು ಕಾನ್ಫಿಗ್ ಮತ್ತೆ ಓದುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿದೆ.