VPN-এ Docker Swarm: টাস্ক চলছে, সার্ভিস কল ব্যর্থ হচ্ছে

দুই সাইটে তিন ম্যানেজার আর পাঁচ ওয়ার্কার, মাঝে একটি টানেল, আর docker service ls দেখাচ্ছে দুই পাশেই টাস্ক চলছে, অথচ সার্ভিসগুলোর মধ্যে কল টাইম আউট হচ্ছে। Swarm লগে কিছুই ভুল দেখাচ্ছে না। এই সমন্বয়টাই ডেটা প্লেন সমস্যার স্বাক্ষর: কন্ট্রোল প্লেন নোডগুলো খুঁজে পেয়েছে, আর এনক্যাপসুলেটেড ফ্রেমগুলো কখনোই পথ পাড়ি দেয়নি।

overlay-এর আগে mesh-কে থাকতেই হবে

Swarm-এর overlay এনক্যাপসুলেটেড ফ্রেম সরাসরি নোড ঠিকানার মধ্যে পাঠায়, মানে প্রতিটি নোডের এমন ঠিকানা দরকার যেখানে অন্য প্রতিটি নোড অনুবাদ ছাড়াই পৌঁছাতে পারে, টানেল যে ইন্টারফেস দেয় তার উপর। যে টানেল কেবল ক্লায়েন্টদের একটি প্রকাশিত পোর্টে নিয়ে যায়, তা যথেষ্ট নয়। আন্ডারলে-কে দুই দিকেই নোড থেকে নোডে রুট করতে হবে।

Swarm-এ হাত দেওয়ার আগে এটা পরীক্ষা করুন। প্রতিটি নোড থেকে পিয়ারের টানেল ঠিকানার রুট দেখুন, পিং করুন, তারপর কন্ট্রোল পোর্ট পরীক্ষা করুন। পিং কাজ করলে কিন্তু পোর্ট না করলে, টানেল ঠিক আছে আর পথে একটি ফিল্টার আছে।

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 পিয়াররা একে অপরকে চিনতে পারে না। ফলাফল হলো হারানো বা একমুখী এনক্যাপসুলেটেড ট্রাফিক, অথচ সাধারণ পিং তখনো কাজ করে।

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 কোরামের দিকে নয়।

কাজ করা অবস্থার ক্যাপচার রেখে দিন, কারণ নষ্ট অবস্থার সঙ্গে তুলনা করা কনফিগ আবার পড়ার চেয়ে দ্রুত।