AWS একক-টানেল বিজ্ঞপ্তি: আসলে কখন এটি গুরুত্বপূর্ণ

একটি টানেল ডাউন বলে AWS Health বিজ্ঞপ্তি সাধারণত তখন আসে যখন কিছুই ভাঙা মনে হয় না। ঠিক সেই কারণেই এটি উপেক্ষিত হয়। বিজ্ঞপ্তিটি কোনো বিভ্রাট বর্ণনা করছে না; এটি এমন একটি রিডান্ডেন্সি অবস্থা বর্ণনা করছে যা AWS-এর পর্যবেক্ষণ উইন্ডো ছাড়িয়ে চলেছে। আপনি ব্যবস্থা নেবেন কি না তা নির্ভর করে আপনার ডিজাইন কী সহ্য করতে পারে তার উপর, ড্যাশবোর্ড কেমন মনে হচ্ছে তার উপর নয়।

বিজ্ঞপ্তিটি আসলে কী মাপল

প্রতিটি Site-to-Site সংযোগে দুইটি টানেল থাকে, যা ভিন্ন AWS এন্ডপয়েন্টে সমাপ্ত হয়। AWS-এর মনিটরিং ডকুমেন্টেশন রিডান্ডেন্সির জন্য দুটিই কনফিগার করার পরামর্শ দেয় এবং একটি নথিভুক্ত সময়কাল ধরে ডাউন থাকলে বিজ্ঞপ্তি তোলে। সেই সময়কাল গুরুত্বপূর্ণ, কারণ একটি ক্ষণিক ওঠানামা এবং স্থায়ী ক্ষতি একই গ্রাফে একই রকম দেখায়।

সংযোগের সামগ্রিক অবস্থার বদলে প্রতি-টানেল টেলিমেট্রি পড়ুন। aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' প্রতিটি টানেলের জন্য একটি স্ট্যাটাস ও বার্তা ফেরত দেয়, এবং বিজ্ঞপ্তিটি যে প্রমাণের উপর ভিত্তি করে তা এটিই।

আপনার প্রতিক্রিয়া নির্ধারণ করে এমন তিনটি শর্ত

এটি একটি টিকিট নাকি উপেক্ষা, তা সিদ্ধান্ত নেওয়ার আগে তিনটি শর্ত দেখে নিন।

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

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

স্ট্যান্ডবাই পিয়ার কী প্রমাণ করে না

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

দুইটি ভৌত রাউটারও বিপরীত ক্ষেত্রটি সমাধান করে না। যখন দুইটি টানেলই একটি ডিভাইসে সমাপ্ত হয় বা একটি আপলিংক দিয়ে বের হয়, তখন রিডান্ডেন্সি কেবল কাগজে থাকে।

পরিবর্তনকে তার প্রভাবের পরিধির সাথে মেলান

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

একক টানেলে অপশন পরিবর্তন হলো নিজস্ব ঘোষিত প্রভাবসহ তৃতীয় কেস: সেই টানেলটি তার নিজের আপডেটের সময় অনুপলব্ধ থাকে এবং অন্যটি চলতে থাকে।

প্রয়োজনের আগেই বিকল্পটি প্রমাণ করুন

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

বিজ্ঞপ্তি, টেলিমেট্রি আউটপুট এবং পরিবর্তন পরিকল্পনা এক রেকর্ডে রাখুন। সেই রেকর্ড পরের প্রান্তিকের বিজ্ঞপ্তিকে কেউ কখনো ব্যাকআপ পরীক্ষা করেছে কিনা এই বিতর্কের বদলে দুই মিনিটের পর্যালোচনায় পরিণত করে।