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 ક્વોરમ તરફ નહીં.

કામ કરતી વિન્ડોનું કેપ્ચર રાખો, કારણ કે તેની તૂટેલા સાથે સરખામણી કૉન્ફિગ ફરી વાંચવા કરતાં ઝડપી છે.