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 ਕੋਰਮ ਵੱਲ ਨਹੀਂ।

ਚੱਲਦੀ ਵਿੰਡੋ ਦਾ ਕੈਪਚਰ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਸਦੀ ਟੁੱਟੀ ਹੋਈ ਨਾਲ ਤੁਲਨਾ ਕਾਨਫਿਗ ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ।