ফেইলওভার পরীক্ষা: প্রতিষ্ঠিত TCP স্ট্রিম কি টিকে থাকে?

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

দুটি ফলাফল যা একটিমাত্র সাফল্যের মতো দেখায়

ভাবুন, 10.90.0.42-এ একটি ক্লায়েন্টের 198.51.100.20:443-এ সংযোগ আছে। প্রাথমিক এক্সিট এটিকে একটি পাবলিক ঠিকানা ও পোর্টে রূপান্তর করে, আর ব্যাকআপ এক্সিট এটিকে অন্য একটিতে রূপান্তর করে। ক্লায়েন্টের অভ্যন্তরীণ ঠিকানা কখনো বদলায় না, তাই মানুষ আশা করে সংযোগটি টিকে থাকবে।

সার্ভার অভ্যন্তরীণ ঠিকানা দেখে না। এটি রূপান্তরিত প্রান্তবিন্দু দেখে, এবং সুইচের পরে সেই প্রান্তবিন্দু আলাদা।

তাই পুরোনো স্ট্রিম সময় শেষ হয়ে যায়, অথচ একই সেবায় নতুন সংযোগ সঙ্গে সঙ্গে কাজ করে। দুটি পর্যবেক্ষণই একসঙ্গে সত্য।

এক্সিট বদলালে সার্ভার কী দেখে

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

স্টেটফুল ফেইলওভার ঠিক এই পরিস্থিতি এড়াতে আছে, এবং এটি ফরওয়ার্ডিং ডিভাইসগুলোর মধ্যে রূপান্তর ও সংযোগের স্টেট বিনিময় করে কাজ করে। এটি জোড়ার বৈশিষ্ট্য, টানেলের নয়, এবং ধরে নেওয়ার বদলে এটিকে ডিজাইন ও পরীক্ষা করতে হয়।

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

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

একই পাবলিক ঠিকানা কেন যথেষ্ট নয়

দুই পথে একটি পাবলিক ঠিকানা রাখা ভালো শুরু, কারণ তখন সার্ভার একই উৎস প্রান্তবিন্দু দেখে। তবে একা এটি যথেষ্ট নয়। ফরওয়ার্ডিং ডিভাইসের এখনো রূপান্তর স্টেট, ফায়ারওয়াল স্টেট এবং ব্যবহারযোগ্য ফিরতি পথ দরকার, এবং সুইচের পরে যে ডিভাইস ট্রাফিক বহন করে সেখানেই সেগুলো থাকতে হবে।

RFC 3022 ঠিকানা রূপান্তর বর্ণনা করে এবং রূপান্তরকারী ডিভাইসগুলোর মধ্যে স্টেট বিনিময়কে ব্যাকআপ ডিজাইনের অংশ হিসেবে ধরে। ভাসমান ঠিকানা বা কপি করা প্রোফাইল কনফিগারেশন সরায়, কিন্তু স্টেট সরায় না।

তাই যে পরীক্ষা কেবল ব্যাকআপ দিয়ে পিং করে, তা খুব কমই প্রমাণ করে। পিংয়ের হারানোর মতো কোনো সংযোগ স্টেট নেই।

প্রয়োজনটি কতটা কঠিন তা ঠিক করুন

ব্যবহারকারীরা ব্যর্থতার পরে আবার সংযোগ করতে পারলে ডিজাইনটি পুনরুদ্ধার ডিজাইন এবং গ্রহণযোগ্যতা পরীক্ষা একটি নতুন অনুরোধ। ফাইল স্থানান্তর টিকে থাকতে হলে ডিজাইনে স্টেট সিঙ্ক্রোনাইজেশন এবং আরও সতর্ক পরীক্ষা দরকার। দূরবর্তী সেশন টিকে থাকতে হলে প্রয়োজন আরও কঠিন এবং নেটওয়ার্ক-স্তরের বদলে অ্যাপ্লিকেশন-স্তরের যন্ত্র লাগতে পারে।

প্রয়োজনটি মাপা যায় এমন ফলাফলসহ একটি বাক্য হিসেবে লিখুন, যেমন আপলোড পুনরায় শুরু ছাড়াই শেষ হয় বা অপারেটর এক মিনিটের মধ্যে আবার সংযোগ করেন। তারপর সেটি মেটায় এমন সবচেয়ে সস্তা যন্ত্র বাছুন, আর সেটি প্রায়ই পুনরুদ্ধার ডিজাইন।

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

পুরোনো স্ট্রিম ও নতুন অনুরোধ পরীক্ষা করুন

প্রাথমিক পথ দিয়ে নিরীহ দীর্ঘস্থায়ী স্থানান্তর শুরু করুন, তারপর একই সেবায় আলাদা নতুন অনুরোধ। অ্যাপ্লিকেশন প্রসঙ্গ, পর্যবেক্ষিত এক্সিট ঠিকানা ও সময় লিখে রাখুন। অনুমোদিত উপায়ে প্রাথমিক পথ ভাঙুন এবং ব্যাকআপ দিয়ে নতুন অনুরোধ পাঠানোর সময় মূল স্থানান্তরটি দেখতে থাকুন।

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

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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