TCP হ্যান্ডশেকের পর আটকে যাওয়া কোয়েরি রাউটিং সমস্যা নয়। রাউটের ত্রুটি হ্যান্ডশেক ব্যর্থ করে, তাই যে সেশন প্রতিষ্ঠিত হয়ে চুপ হয়ে যায় তা পথের ভেতরের দিকে ইঙ্গিত করে: নিরীক্ষা, MTU, বা টানেলের UDP প্যাকেট যেভাবে আসে তা। আপনার সামনের সিদ্ধান্ত হলো এই পথটি সারাবেন, নাকি টানেলটি TCP-তে সরাবেন। তিনটি শর্ত এটি ঠিক করে, আর এর একটিও ডেটাবেস নিয়ে নয়।

টানেলকে দোষ দেওয়ার আগে আটকে যাওয়াটি শ্রেণিবদ্ধ করুন

চারটি ফলাফল ব্যবহারকারীর কাছে একই রকম দেখায়, কিন্তু প্রকৌশলীর কাছে সম্পূর্ণ আলাদা অর্থ বহন করে।

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

শুধু শেষ দুই সারিই টানেলে সময় ব্যয় করা ন্যায্য করে। VPN-এর ওপর প্রত্যাখ্যাত সংযোগ সাধারণত ডেটাবেসটি শুধু loopback-এ শুনছে তা বোঝায়, যা লিসেনার সমস্যা, আর হ্যান্ডশেকের আগে টাইমআউট মানে ফিল্টার বা রুট। এনক্যাপসুলেশন বদলে কোনোটিই ভালো হয় না।

প্রথমে টিকেটে শ্রেণিবিন্যাসটি লিখুন। এটি সবচেয়ে কম খরচের ধাপ এবং অনুসন্ধানের বেশিরভাগ পরিসর সরিয়ে দেয়।

UDP বনাম TCP নির্ধারণ করে এমন তিনটি শর্ত

এনক্যাপসুলেটেড IPsec ট্রাফিক UDP-তে চলে, আর UDP পথকে কাউকে না জানিয়ে পুনর্বিন্যাস ও ড্রপ করার স্বাধীনতা দেয়। যখন পুনর্বিন্যাস প্যাকেটগুলোকে টানেলের অ্যান্টি-রিপ্লে উইন্ডোর বাইরে ঠেলে দেয়, তখন সেগুলো নীরবে বাদ পড়ে এবং ভেতরের TCP সেশন শুধু অপেক্ষা করে। সফল হ্যান্ডশেক আর কখনো না ফেরা কোয়েরির পেছনের প্রক্রিয়া এটাই।

পথ সারানো বা TCP-তে ফেরা তিনটি বিষয়ের ওপর নির্ভর করে। প্রথমত, পথে সত্যিকারের প্যাকেট লস আছে, না শুধু পুনর্বিন্যাস? দ্বিতীয়ত, নিরীক্ষা কোথায় হয় তা আপনি বদলাতে পারেন, নাকি এই টানেলটিকে পুনর্বিন্যাসকারী উপাদান থেকে বাদ দিতে পারেন? তৃতীয়ত, ওয়ার্কলোডটি কি আটকে যাওয়ার ধরনের প্রতি সংবেদনশীল, যেমন একটি লিঙ্ক শেয়ার করা অনেক মাল্টিপ্লেক্স সেশন?

প্রথম উত্তর লস আর দ্বিতীয়টি না হলে,443-এ TCP-ই বাস্তবসম্মত বিকল্প। দ্বিতীয় উত্তর হ্যাঁ হলে, পথ সারিয়ে UDP-তেই থাকুন।

অ্যাপ্লিকেশনের ত্রুটি নয়, ফায়ারওয়ালের রেকর্ড পড়ুন

অ্যাপ্লিকেশন টাইমআউট জানায়, যা কারণ সম্পর্কে কিছুই বলে না। ফায়ারওয়ালের নিজের লগই সেই জায়গা যেখানে ড্রপ বা ব্লক প্রকাশ পায়, তাই ডেটাবেস ও অ্যাপ্লিকেশনের ঠিকানা দিয়ে ফিল্টার করুন এবং গ্রহণের পাশাপাশি বাদ পড়াও খুঁজুন।থ্রেট-প্রিভেনশন ব্লেড অ্যাপ্লিকেশন স্তরের ত্রুটি না তৈরি করেই প্যাকেট বাদ দিতে পারে, আর এটাই আটকে যাওয়া কোয়েরির ঠিক চেহারা। লগে নীরবতাও তথ্য: এটি এমন কিছুকে ইঙ্গিত করে যা লগ করে না, যেমন পুনর্বিন্যাস।

ক্লাস্টারও দেখুন। ভুলভাবে কনফিগার করা ক্লাস্টার একটি সদস্যের স্টেট টেবিলে সেশন ধরে রাখতে পারে, অথচ প্যাকেট যায় অন্য সদস্যের পথে, ফলে উত্তর আসে যেখানে কোনো স্টেট নেই। এসব আটকে যাওয়া এলোমেলো দেখায় এবং লোডের সঙ্গে সম্পর্ক রাখে না।

কিছু বদলানোর আগে দুই প্রান্তই তুলনা করুন, আর প্যাকেট সংখ্যা নয়, আগমনের ক্রম তুলনা করুন:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

443-এ TCP আসলে আপনার কী খরচ করায়

টানেল TCP-তে সরালে পুনর্বিন্যাসের উপসর্গ চলে যায়, কারণ মিডলবক্স এখন ক্রমানুসারে সাজানো স্ট্রিম দেখে। এটি TCP-over-TCP-ও তৈরি করে। বাইরের সংযোগ যা ভেতরের সংযোগ ইতিমধ্যে পুনঃপ্রেরণ করেছে তা আবার পাঠায়, আর একটি মাত্র লস একসঙ্গে সব মাল্টিপ্লেক্স সেশন আটকে দিতে পারে। পরিচ্ছন্ন পথে এটি অদৃশ্য। লসযুক্ত পথে প্রতিকারটি উপসর্গের চেয়েও খারাপ।

বিকল্পটি যখন সংযোগহীনতা, তখন এই বিনিময় গ্রহণযোগ্য, এবং এটি স্বাভাবিক হিসেবে শুষে না নিয়ে মালিকসহ একটি ব্যতিক্রম হিসেবে নথিভুক্ত করা উচিত।

পরিবহন, পোর্ট, একটি নমুনা কোয়েরি ও মাপা ফলাফল, এবং তারিখ লিখে রাখুন। সেই রেকর্ড ছাড়া পরবর্তী প্রকৌশলী পরীক্ষাটি আবার করেন, আর ব্যতিক্রমটি চুপচাপ স্থাপত্যে পরিণত হয়।

সিদ্ধান্তটি পুনর্বিবেচনাযোগ্য রাখুন

পথের রোগনির্ণয় দ্রুত পুরোনো হয়ে যায়। মিডলবক্স বদলানো হয়, ব্লেডের কনফিগারেশন বদলায়, লিঙ্ক আপগ্রেড হয়, আর 443-এ TCP-র কারণ হারিয়ে যায় অথচ কনফিগারেশন থেকে যায়। ব্যতিক্রমটির ওপর একটি পুনর্যালোচনার তারিখ দিন এবং এমন শর্তের নাম দিন যা আপনাকে UDP-তে ফিরতে দেবে।

ছোট কোয়েরি এবং বড় ফলাফল সেট—দুই পরিবহনই পরীক্ষা করুন। পুনর্বিন্যাস আকার-নির্ভর আটকে যাওয়া হিসেবে দেখা যায়, আর লিসেনারের ত্রুটি দুই আকারকেই সমানভাবে থামায়।

সম্পর্কিত নিবন্ধ