আপনি সম্ভবত একই অভিযোগ তিনটি ভিন্ন রূপে শুনেছেন।
একটি হোটেলে, অতিথিরা বলেন যে WiFi ব্যবহার অনুপযোগী, যদিও কাগজে-কলমে ইন্টারনেট সার্কিটটি যথেষ্ট শক্তিশালী মনে হয়। একটি হাসপাতালে, কোনো মোবাইল ডিভাইস সিঙ্ক হতে খুব বেশি সময় নিলে চিকিৎসকরা নেটওয়ার্ককে দায়ী করেন। একটি রিটেইল সেন্টারে, ভাড়াটেরা দাবি করেন যে শেয়ার্ড কানেকশনটিই মূল সমস্যা, যখন কার্ড পেমেন্ট, ইনভেন্টরি সিস্টেম এবং গেস্ট অ্যাক্সেস সবই একই আপলিংকের জন্য প্রতিযোগিতা করে।
ঠিক এখানেই বেশিরভাগ ব্যান্ডউইথ ম্যানেজমেন্টের পরামর্শগুলো ব্যর্থ হয়। এগুলো আপনাকে ট্রাফিক থ্রোটল, অগ্রাধিকার দেওয়া বা শেপ করার উপায় বলে, কিন্তু আরও গুরুত্বপূর্ণ প্রশ্নটি এড়িয়ে যায়। আপনার কি আদৌ নীতি পরিবর্তন করা উচিত? বাস্তব নেটওয়ার্কে, “ধীরগতির ইন্টারনেট” ভুল নীতি, একটি জনাকীর্ণ ওয়্যারলেস লেয়ার, একটি চাপের মুখে থাকা ব্যাকহল বা এই তিনটির সংমিশ্রণ থেকে হতে পারে। আপনি যদি প্রতিটি অভিযোগকে ব্যান্ডউইথের সমস্যা হিসেবে বিবেচনা করেন, তবে আপনি ভুল সমস্যা সমাধানের জন্য অর্থ এবং সময় নষ্ট করবেন।
'ধীরগতির WiFi' অভিযোগের বাইরে
একজন ভেন্যু ম্যানেজার সাধারণত প্যাকেট লস, চ্যানেল ব্যবহার বা আপলিংক প্রতিযোগিতার কথা রিপোর্ট করেন না। তারা লক্ষণগুলো রিপোর্ট করেন। ভিডিও কল আটকে যায়। চেক-ইন ট্যাবলেটগুলো ধীরগতির হয়ে যায়। গেস্ট স্ট্রিমিং বাফার করে। কার্ড মেশিনগুলো অসামঞ্জস্যপূর্ণ মনে হয়। কথাটি প্রায় সবসময় একই থাকে: “WiFi ধীরগতির”।
এই কথাটির পেছনে বেশ কয়েকটি ভিন্ন ত্রুটি লুকিয়ে থাকে। একটি নেটওয়ার্কে প্রচুর ইন্টারনেট ক্ষমতা থাকতে পারে এবং তবুও এটি খারাপ অভিজ্ঞতা দিতে পারে যদি অ্যাক্সেস পয়েন্টগুলো ওভারলোডেড থাকে, যদি খুব বেশি ডিভাইস একই রেডিও স্পেস শেয়ার করে, অথবা যদি কম-গুরুত্বপূর্ণ ট্রাফিককে ব্যবসায়িক-গুরুত্বপূর্ণ অ্যাপগুলোকে বাধা দেওয়ার অনুমতি দেওয়া হয়। Preseem বিষয়টি স্পষ্টভাবে তুলে ধরেছে: ট্রাফিক ম্যানেজমেন্ট কেবল তখনই অভিজ্ঞতার মান উন্নত করতে সাহায্য করে যখন অন্তর্নিহিত অ্যাক্সেস নেটওয়ার্কটি সুস্থ থাকে, এবং একটি ওভারলোডেড অ্যাক্সেস পয়েন্ট স্মার্ট কন্ট্রোল থাকা সত্ত্বেও খারাপ পারফর্ম করবে, বিশেষ করে হসপিটালিটি, হেলথকেয়ার এবং রিটেইল পরিবেশে যেখানে অভিযোগগুলো প্রায়শই কেবল নীতির চেয়ে আরএফ (RF) কনজেশন বা ব্যাকহল সীমার সাথে সম্পর্কিত থাকে ( ব্যান্ডউইথ ম্যানেজমেন্টের সেরা অনুশীলন সম্পর্কে Preseem )।
ক্ষমতা এবং অভিজ্ঞতা এক জিনিস নয়
আমি বহুমুখী ব্যবহারের ভেন্যুগুলোতে প্রায়শই এই ভুলটি দেখি। কেউ সার্কিট আপগ্রেড করে, অভিযোগগুলো সাময়িকভাবে কমে যায়, তারপর আবার ফিরে আসে। অলৌকিক কিছুই ঘটেনি। অতিরিক্ত হেডরুম কিছু সময়ের জন্য দুর্বল বরাদ্দকে আড়াল করেছিল, কিন্তু মূল সমস্যাটি রয়েই গেছে।
ব্যান্ডউইথ ম্যানেজমেন্ট সবচেয়ে ভালো কাজ করে যখন আপনি এটিকে শাস্তি হিসেবে নয়, বরং রিসোর্স কন্ট্রোল হিসেবে বিবেচনা করেন। আপনি সিদ্ধান্ত নিচ্ছেন কোন ট্রাফিকটি নির্বিঘ্নে পার হওয়া উচিত, কোন ট্রাফিকটি কিছুক্ষণ অপেক্ষা করতে পারে এবং কোন ট্রাফিকের একটি ন্যায্য কিন্তু সীমিত অংশ প্রয়োজন।
ধীরগতির WiFi-এর অভিযোগগুলো প্রায়শই ব্যবহারকারীর দৃষ্টিকোণ থেকে সঠিক হলেও কারণের দিক থেকে ভুল হয়ে থাকে।
ব্যবহারিক ক্ষেত্রে এই পার্থক্যটি গুরুত্বপূর্ণ:
- একটি হোটেলের অতিথির সমস্যাটি অপর্যাপ্ত ব্যান্ডউইথ নয়, বরং রুমের দুর্বল কভারেজ হতে পারে।
- একটি রিটেইল অপারেশনের সমস্যাটি পিক আওয়ারে অতিরিক্ত ভিড়ের সময় গেস্ট ট্রাফিক দ্বারা শেয়ার্ড আপলিংক ওভারলোডেড হওয়ার কারণে হতে পারে।
- একটি হাসপাতালের মোবিলিটি সমস্যাটি ইন্টারনেটের ক্ষমতার চেয়ে রোমিং, আরএফ (RF) ওভারল্যাপ বা অ্যাপ্লিকেশনের আচরণের কারণে হতে পারে।
আপনার প্রথম পদক্ষেপ যদি আরও ব্যান্ডউইথ কেনা হয়, তবে আপনি কারণটি প্রমাণ না করেই সাময়িকভাবে লক্ষণটি উপশম করতে পারেন। আপনার প্রথম পদক্ষেপ যদি সবকিছু থ্রোটল করা হয়, তবে আপনি ব্যবহারকারীর অভিজ্ঞতা আরও খারাপ করে আপলিংকটিকে রক্ষা করতে পারেন।
ভৌত অভিজ্ঞতা দিয়ে শুরু করুন
QoS নীতিগুলো স্পর্শ করার আগে, মৌলিক বিষয়গুলো যাচাই করুন। কভারেজের ঘাটতি, দুর্বল সিগন্যাল এবং দুর্বল অ্যাক্সেস পয়েন্ট প্লেসমেন্ট যেকোনো ইন্টারনেট কানেকশনকে অকেজো মনে করাতে পারে। ভেন্যুর পারফরম্যান্স ট্রাবলশুট করা টিমগুলোর জন্য, কীভাবে WiFi সিগন্যালের শক্তি উন্নত করা যায় সে সম্পর্কিত এই নির্দেশিকাটি একটি দরকারী অনুস্মারক যে প্রতিটি পারফরম্যান্সের অভিযোগ WAN এজ থেকে শুরু হয় না।
সঠিক মানসিকতা সহজ। প্রথমে রোগ নির্ণয় করুন। তারপর সিদ্ধান্ত নিন যে সমাধানটি নীতি, ওয়্যারলেস ডিজাইন নাকি সার্কিট প্ল্যানিংয়ের মধ্যে রয়েছে।
ব্যান্ডউইথ ম্যানেজমেন্টের চারটি স্তম্ভ
ব্যান্ডউইথ ম্যানেজমেন্ট কোনো একক নিয়ন্ত্রণ নয়। এটি বিভিন্ন কাজ সম্পন্নকারী নিয়ন্ত্রণের একটি সেট। টিমগুলো যখন এগুলোকে একসাথে গুলিয়ে ফেলে, তখন তারা সাধারণত এমন কিছু কঠোর নিয়ম তৈরি করে যা ব্যবহারকারীদের হতাশ করে এবং তবুও গুরুত্বপূর্ণ অ্যাপ্লিকেশনগুলোকে রক্ষা করতে ব্যর্থ হয়।
এই ভিজ্যুয়ালটি মূল মডেলটিকে সংক্ষেপে তুলে ধরেছে:
Ofcom-এর ডেটা হাইলাইট করে যে কেন সূক্ষ্ম পার্থক্যগুলো গুরুত্বপূর্ণ। যুক্তরাজ্যের গড় ফিক্সড-লাইন ডাউনলোড স্পিড ছিল 69.4 Mbit/s, যেখানে দ্রুততম ১০% ফুল-ফাইবার কানেকশন প্রায় 1.6 Gbit/s-এ পৌঁছেছে, যার অর্থ উপলব্ধ হেডরুম অ্যাক্সেস প্রযুক্তির ওপর ভিত্তি করে নাটকীয়ভাবে পরিবর্তিত হয় এবং যখন বাধাটি অ্যাক্সেস লেয়ারে থাকে তখন একটি সাধারণ “আরও ব্যান্ডউইথ কিনুন” প্রতিক্রিয়ার চেয়ে প্রতি-অ্যাপ্লিকেশন QoS এবং ট্রাফিক শেপিংকে আরও দরকারী করে তোলে ( ব্যান্ডউইথ ম্যানেজমেন্ট এবং যুক্তরাজ্যের অ্যাক্সেসের পার্থক্যের বিষয়ে ManageEngine-এর ব্যাখ্যা )।
ট্রাফিক শেপিং
ট্রাফিক শেপিং হলো প্রবাহ নিয়ন্ত্রণ করা, কেবল গতি কমানো নয়। এটি একটি ব্যস্ত মোটরওয়েতে যানবাহনের সংখ্যা নিয়ন্ত্রণ করার মতো যাতে পুরো রাস্তা সচল থাকে। নেটওয়ার্কের ভাষায়, শেপিং আকস্মিক বৃদ্ধিকে মসৃণ করে এবং একটি আকস্মিক স্পাইক অন্য সবকিছুকে বাধাগ্রস্ত করার সম্ভাবনা হ্রাস করে।
কোয়ালিটি অব সার্ভিস (QoS)
QoS হলো জরুরি লেন। এটি কিছু ট্রাফিককে অন্যগুলোর চেয়ে বেশি গুরুত্বপূর্ণ হিসেবে চিহ্নিত করে যাতে বিলম্ব-সংবেদনশীল অ্যাপ্লিকেশনগুলো প্রথমে অগ্রাধিকার পায়।
ব্যবহারিক নিয়ম: বিলম্বের কারণে ব্যর্থ হওয়া অ্যাপ্লিকেশনগুলোকে রক্ষা করতে QoS ব্যবহার করুন, যে টিম সবচেয়ে বেশি চিৎকার করে তাদের পুরস্কৃত করতে নয়।
ব্যান্ডউইথ বরাদ্দ
বরাদ্দ হলো ন্যায্যতা নিশ্চিত করার ইঞ্জিন। এটি সিদ্ধান্ত নেয় যে শেয়ার্ড রিসোর্সের কতটা অংশ একজন ব্যবহারকারী গ্রুপ, সার্ভিস ক্লাস বা ভাড়াটে গ্রুপের কাছে যাবে।
বরাদ্দ না থাকলে অনেক গেস্ট নেটওয়ার্ক ব্যর্থ হয়। বরাদ্দ ছাড়া, অল্প কয়েকজন ভারী ব্যবহারকারী একটি শেয়ার্ড সার্ভিসকে নিয়ন্ত্রণ করতে পারে। বুদ্ধিমান বরাদ্দের মাধ্যমে, স্টাফ, গেস্ট, ডিভাইস এবং ভাড়াটেরা প্রত্যেকে একটি নির্দিষ্ট অংশ পায় যা ব্যবসায়িক মূল্যকে প্রতিফলিত করে।
এটি চিন্তা করার একটি সহজ উপায়:
| স্তম্ভ | প্রধান কাজ | সেরা ব্যবহারের ক্ষেত্র |
|---|---|---|
| ট্রাফিক শেপিং | আকস্মিক বৃদ্ধি মসৃণ করা | আকস্মিক চাহিদার স্পাইকসহ ব্যস্ত সময় |
| QoS | সংবেদনশীল ট্রাফিক রক্ষা করা | ভয়েস, পেমেন্ট, ক্লিনিকাল অ্যাপস, অপারেশন |
| ব্যান্ডউইথ বরাদ্দ | শেয়ার্ড ক্ষমতা ন্যায্যভাবে ভাগ করা | মাল্টি-টেন্যান্ট, গেস্ট, স্টাফ, বহুমুখী ব্যবহারের ভেন্যু |
| অ্যাপ্লিকেশন অগ্রাধিকার নির্ধারণ | নির্দিষ্ট পরিষেবাগুলোর মান উন্নত করা | গুরুত্বপূর্ণ অ্যাপস যা অবশ্যই প্রতিক্রিয়াশীল থাকতে হবে |
অ্যাপ্লিকেশন অগ্রাধিকার নির্ধারণ
অ্যাপ্লিকেশন অগ্রাধিকার নির্ধারণ ব্যাপক QoS ক্লাসের চেয়ে আরও সুনির্দিষ্ট। এটি স্বীকৃত অ্যাপ্লিকেশনগুলোর ওপর ফোকাস করে এবং কার্যত বলে যে, এই কাজগুলো লাইনের প্রথমে যাবে।
বাস্তবে, এটি তখন দরকারী যখন বেশ কয়েকটি পরিষেবা একই নেটওয়ার্ক শেয়ার করে কিন্তু সমান আচরণের যোগ্য নয়। একটি প্রপার্টি ম্যানেজমেন্ট সিস্টেম, POS ট্রাফিক বা ক্লিনিকাল ওয়ার্কফ্লো বাল্ক মিডিয়া ডাউনলোড বা ব্যাকগ্রাউন্ড সিঙ্কের সাথে একই শর্তে প্রতিযোগিতা করা উচিত নয়।
উদ্দেশ্য প্রতিটি প্যাকেটকে অতিরিক্ত জটিল করা নয়। এটি হলো সবচেয়ে ছোট কন্ট্রোল সেটটি বেছে নেওয়া যা গুরুত্বপূর্ণ অভিজ্ঞতাকে রক্ষা করে。
আপনার ভেন্যুর জন্য স্মার্ট নীতি ডিজাইন করা
একটি ভালো ব্যান্ডউইথ নীতি ভেন্যুটি কীভাবে কাজ করে তা প্রতিফলিত করে। এটি “আমরা কী সীমাবদ্ধ করতে পারি?” দিয়ে শুরু হয় না। এটি শুরু হয় “কোনটি প্রতিবার কাজ করতে হবে?” দিয়ে।
এই কারণেই সবার জন্য প্রযোজ্য সাধারণ টেমপ্লেটগুলো সাধারণত ব্যর্থ হয়। একটি হোটেল অতিথিদের সন্তুষ্টি এবং ফ্রন্ট-ডেস্ক সিস্টেমের যত্ন নেয়। একটি হাসপাতাল ক্লিনিকাল নির্ভরযোগ্যতা এবং ডিভাইস পৃথকীকরণের যত্ন নেয়। একটি রিটেইল সেন্টারকে ব্যবহারযোগ্য গেস্ট অ্যাক্সেস দেওয়ার পাশাপাশি অপারেশনাল সিস্টেমগুলোকে রক্ষা করতে হয়। একটি আবাসিক ভবনে নেটওয়ার্কটিকে সবার জন্য উন্মুক্ত না করে অনেক ব্যবহারকারীর মধ্যে ন্যায্যতা বজায় রাখা প্রয়োজন।
নীতিটিকে বাস্তব-জগতের সীমাবদ্ধতাগুলোকেও সম্মান করতে হবে। ২০ মার্চ ২০২০ থেকে, যুক্তরাজ্যের ব্রডব্যান্ড ইউনিভার্সাল সার্ভিস অবলিগেশন যোগ্য প্রাঙ্গণগুলোকে আইনিভাবে 10 Mbit/s ডাউনলোড এবং 1 Mbit/s আপলোড অনুরোধ করার অধিকার দিয়েছে, যা বেসলাইন কানেক্টিভিটিকে একটি প্রযুক্তিগত বিষয়ের পাশাপাশি একটি নিয়ন্ত্রক এবং পরিষেবা-মানের বিষয়ে পরিণত করেছে, বিশেষ করে গ্রামীণ বা দুর্গম স্থানগুলোতে ( ব্যান্ডউইথ মনিটরিং এবং যুক্তরাজ্যের USO বেসলাইনের SearchInform ওভারভিউ )।
ডিভাইস নয়, ট্রাফিক ক্লাস দিয়ে শুরু করুন
many টিম হার্ডওয়্যারের তালিকা দিয়ে শুরু করে। এটি ভুল ক্রম। ট্রাফিক ক্লাস এবং ব্যবসায়িক ফলাফল দিয়ে শুরু করুন।
তিনটি প্রশ্ন ব্যবহার করুন:
- কোনটির মান কমে গেলে অপারেশন ব্যাহত হয়?
- কোনটি ভালোভাবে কাজ করা প্রয়োজন কিন্তু কিছুটা বিলম্ব সহ্য করতে পারে?
- কোনটিকে বাস্তব ক্ষতি না করে ন্যায্যভাবে ধীর করা যেতে পারে?
এটি প্রতিটি হ্যান্ডসেট, ল্যাপটপ, স্ক্যানার বা টিভির চারপাশে নীতি লেখার চেষ্টা করার চেয়ে আরও স্পষ্ট নিয়ম তৈরি করে।
খাত অনুযায়ী ব্যান্ডউইথ নীতি টেমপ্লেট
| খাত | উচ্চ অগ্রাধিকার ট্রাফিক | মাঝারি অগ্রাধিকার ট্রাফিক | নিম্ন অগ্রাধিকার / রেট-সীমিত ট্রাফিক |
|---|---|---|---|
| হোটেল | PMS, POS, স্টাফ যোগাযোগ, চেক-ইন সিস্টেম | গেস্ট ব্রাউজিং, মেসেজিং, রুটিন ব্যবসায়িক অ্যাপস | বড় গেস্ট ডাউনলোড, সফটওয়্যার আপডেট, ব্যাকগ্রাউন্ড সিঙ্ক |
| রিটেইল সেন্টার | পেমেন্ট, ইনভেন্টরি টুলস, ভাড়াটে অপারেশন, নিরাপত্তা-সম্পর্কিত পরিষেবা | গেস্ট ব্রাউজিং, লয়্যালটি অ্যাপস, ভাড়াটে অ্যাডমিন ট্রাফিক | স্ট্রিমিং, বাল্ক ডাউনলোড, অপ্রয়োজনীয় গেস্ট ট্রাফিক |
| হাসপাতাল | ক্লিনিকাল সিস্টেম, মেডিকেল ওয়ার্কফ্লো, স্টাফ আইডেন্টিটি পরিষেবা, অপারেশনাল যোগাযোগ | অ্যাডমিন প্ল্যাটফর্ম, পেশেন্ট পোর্টাল, স্ট্যান্ডার্ড অফিস অ্যাপস | গেস্ট বিনোদন ট্রাফিক, বাল্ক আপডেট, অ-জরুরি স্থানান্তর |
| আবাসিক বা BTR | বিল্ডিং অপারেশন, অ্যাক্সেস সিস্টেম, ম্যানেজমেন্ট টুলস | ভাড়াটে ব্রাউজিং, রিমোট ওয়ার্ক, কোলাবোরেশন অ্যাপস | পিয়ার-হেভি বাল্ক ট্রাফিক, আনম্যানেজড আপডেট, ব্যাকগ্রাউন্ড সিঙ্ক |
বাস্তবে স্মার্ট নীতি কেমন দেখায়
একটি হোটেলের প্রতিটি গেস্ট এবং প্রতিটি অপারেশনাল সিস্টেমকে একই লাইনে বাধ্য করা উচিত নয়। স্টাফ ডিভাইস, POS টার্মিনাল এবং প্রপার্টি সিস্টেমগুলোর বিনোদন ট্রাফিকের চেয়ে আরও স্পষ্ট হ্যান্ডলিং প্রয়োজন। অতিথিদের এখনও একটি ভালো অভিজ্ঞতার প্রয়োজন রয়েছে, তবে “ভালো” মানে সীমাহীন অগ্রাধিকার নয়।
রিটেইলে, সাধারণ ফাঁদটি হলো কেবল কর্পোরেট অফিসের ট্রাফিককে রক্ষা করা এবং ভাড়াটে, কিওস্ক এবং গেস্ট ব্যবহারকারীদের ভুলে যাওয়া। এটি প্রায়শই স্থানীয় কনজেশন প্যাটার্ন তৈরি করে যা আপনি ফাংশন অনুযায়ী বিভক্ত না করলে স্পষ্টভাবে প্রদর্শিত হয় না。
হাসপাতালগুলোর কঠোরতম শৃঙ্খলার প্রয়োজন। ক্লিনিকাল ওয়ার্কফ্লো যদি গেস্ট ট্রাফিকের মতো একই ব্যবহারিক অগ্রাধিকার শেয়ার করে, তবে গড় ব্যবহার গ্রহণযোগ্য মনে হলেও নীতিটি ভুল।
সেরা নীতিটি সাধারণত সেটিই যাতে সবচেয়ে কম ব্যতিক্রম থাকে। প্রতিটি ব্যতিক্রম আগামীকালের ট্রাবলশুটিংয়ের সমস্যায় পরিণত হয়।
আপনার বর্তমান ভেন্যুর জন্য তৈরি করুন
নীতির গুণমান ডিভাইস ডেনসিটি এবং কভারেজ সম্পর্কে বাস্তবসম্মত অনুমানের ওপর নির্ভর করে। আপনি যদি গেস্ট অ্যাক্সেস বা বহুমুখী ব্যবহারের ডেপ্লয়মেন্টের পরিকল্পনা করেন, তবে Purple-এর অ্যাক্সেস পয়েন্ট ক্যালকুলেটর হলো আপনার ওয়্যারলেস ডিজাইনটি আপনি যে নীতিটি কার্যকর করতে চান তা সমর্থন করতে পারে কিনা তা যাচাই করার একটি ব্যবহারিক উপায়।
কয়েকটি ডিজাইন নিয়ম সব খাতেই ভালো কাজ করে:
- প্রথমে লেনদেন সংক্রান্ত ট্রাফিক রক্ষা করুন: পেমেন্ট, চেক-ইন, ক্লিনিকাল ওয়ার্কফ্লো এবং স্টাফ আইডেন্টিটি পরিষেবাগুলো ঐচ্ছিক ব্যবহারের ওপরে থাকা উচিত।
- অতিথিদের একটি ন্যায্য বেসলাইন দিন: অতিথিদের সীমাহীন অ্যাক্সেসের প্রয়োজন নেই, তবে তাদের ধারাবাহিকতা প্রয়োজন।
- ব্যাকগ্রাউন্ড ট্রাফিকের সাথে কঠোর আচরণ করুন: আপডেট এবং সিঙ্ক কাজগুলোকে কখনই লাইভ অপারেশনগুলোকে ব্যাহত করার অনুমতি দেওয়া উচিত নয়।
- সম্ভব হলে ভূমিকা অনুযায়ী আলাদা করুন: স্টাফ, গেস্ট, ভাড়াটে এবং ডিভাইসের ট্রাফিক ভিন্নভাবে আচরণ করে। আপনার নীতিতে তা প্রতিফলিত হওয়া উচিত।
আপনি যদি কোনো অপারেশন ম্যানেজারকে সহজ ভাষায় নীতিটি বুঝিয়ে বলতে পারেন, তবে এটি সম্ভবত ব্যবহারযোগ্য। যদি কে কী পাবে তা বোঝার জন্য একটি ফ্লোচার্টের প্রয়োজন হয়, তবে এটি সম্ভবত খুব ভঙ্গুর।
নীতি থেকে অনুশীলনে বাস্তবায়ন এবং ইন্টিগ্রেশন
বেশিরভাগ ব্যান্ডউইথ নীতি হোয়াইটবোর্ডে বুদ্ধিমান মনে হয়। বাস্তবায়নের সময় এগুলো ভেঙে পড়ে কারণ নেটওয়ার্ক টিম উদ্দেশ্যকে কার্যকর নিয়ন্ত্রণে রূপান্তর করেনি। ব্যবধানটি সাধারণত তিনটি জায়গায় দেখা যায়: বর্তমান ট্রাফিকের দুর্বল দৃশ্যমানতা, অতিরিক্ত ব্যাপক নীতির পরিধি এবং ব্যবহারকারীদের সঠিক নিয়মের সাথে মেলানোর কোনো স্পষ্ট উপায় না থাকা।
রোলআউটটিকে বাস্তবসম্মত রাখতে এই প্রক্রিয়া ভিউটি একটি দরকারী উপায়:
কনফিগার করার আগে অডিট করুন
নেটওয়ার্কটিকে তার স্বাভাবিক অবস্থায় পর্যবেক্ষণ করে শুরু করুন। “স্ট্রিমিং সমস্যা” বা “অতিথিরা সমস্যা” এমন অনুমান দিয়ে শুরু করবেন না। আপলিংক কী ব্যবহার করছে, কখন পিক আওয়ার ঘটে এবং কোন অভিযোগগুলো সেই পিক আওয়ারের সাথে মিলে যায় তা বেসলাইন করুন।
তারপর ট্রাফিককে অপারেশনাল গ্রুপে ম্যাপ করুন:
- গুরুত্বপূর্ণ পরিষেবা: পেমেন্ট, ক্লিনিকাল ওয়ার্কফ্লো, স্টাফ অ্যাক্সেস, ভয়েস
- গুরুত্বপূর্ণ কিন্তু সহনশীল পরিষেবা: অফিস অ্যাপস, ব্রাউজিং, স্ট্যান্ডার্ড ব্যবসায়িক প্ল্যাটফর্ম
- নমনীয় বা স্থগিতযোগ্য পরিষেবা: আপডেট, মিডিয়া ডাউনলোড, ব্যাকগ্রাউন্ড সিঙ্ক
এটি আপনাকে একটি নীতি মডেল দেয় যা আপনি বেশিরভাগ এন্টারপ্রাইজ WiFi প্ল্যাটফর্ম এবং এজ অ্যাপ্লায়েন্সে ব্যবহার করতে পারেন।
যেখানে যুক্তিযুক্ত সেখানে নিয়মগুলো প্রয়োগ করুন
Meraki, Aruba, Ruckus, Mist এবং UniFi-এর মতো প্ল্যাটফর্মগুলোতে বাস্তবায়নের বিবরণ ভিন্ন হতে পারে, কিন্তু যুক্তি একই থাকে। ক্লাসগুলো সংজ্ঞায়িত করুন, যা অবশ্যই প্রতিক্রিয়াশীল থাকতে হবে সেগুলোতে অগ্রাধিকার প্রয়োগ করুন এবং যা নিরাপদে সীমাবদ্ধ করা যেতে পারে তা ক্যাপ করুন।
টিমগুলো যেখানে সমস্যায় পড়ে তা হলো পরিধি। আপনি যদি কেবল SSID দ্বারা নিয়মগুলো প্রয়োগ করেন, তবে আপনি প্রায়শই সেই নেটওয়ার্কের সমস্ত ব্যবহারকারীর সাথে একই আচরণ করবেন। এটি একটি ছোট সাইটে পরিচালনাযোগ্য। এটি একটি হোটেল, হাসপাতাল বা বহুমুখী ব্যবহারের প্রপার্টিতে জটিল হয়ে ওঠে যেখানে একটি SSID খুব ভিন্ন ট্রাফিক প্রোফাইল বহন করতে পারে।
শেয়ার্ড নীতির চেয়ে আইডেন্টিটি বেশি কার্যকর
আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং ঢালাও SSID-স্তরের শেপিংয়ের চেয়ে অনেক বেশি ব্যবহারিক। “এই নেটওয়ার্কের প্রত্যেকে একই আচরণ পাবে” বলার পরিবর্তে, আপনি ভূমিকা অনুযায়ী নীতি নির্ধারণ করতে পারেন। স্টাফরা একটি নিয়মের সেট পেতে পারে, গেস্টরা অন্যটি, ভাড়াটেরা আরেকটি এবং ম্যানেজড ডিভাইসগুলো অন্য একটি সেট পেতে পারে।
ঠিক এখানেই ইন্টিগ্রেশন গুরুত্বপূর্ণ। গেস্ট WiFi এবং আইডেন্টিটি-ভিত্তিক অ্যাক্সেসের জন্য Purple-এর বাস্তবায়ন পদ্ধতি -এর মতো একটি প্ল্যাটফর্ম এই মডেলের সাথে খাপ খায় কারণ এটি কেবল রেডিও অ্যাটাচমেন্ট পয়েন্টের পরিবর্তে ব্যবহারকারীর ধরণের সাথে অ্যাক্সেস নীতিগুলোকে যুক্ত করতে ভেন্ডর অবকাঠামো এবং ডিরেক্টরি সিস্টেমের সাথে কাজ করে। অপারেশনাল দিক থেকে, এর অর্থ হলো ব্যবহারকারীরা যখন যুক্ত হন, চলে যান বা ভূমিকা পরিবর্তন করেন তখন কম ম্যানুয়াল নীতি বিস্তার এবং আরও স্পষ্ট প্রয়োগ।
আপনার নীতি যদি প্রতিবার মানুষের সঠিক SSID-তে যুক্ত হওয়ার ওপর নির্ভর করে, তবে এটি কোনো শক্তিশালী নীতি নয়।
একটি ব্যবহারিক রোলআউট সিকোয়েন্স
একবারে বড় পরিবর্তনের পরিবর্তে ধাপে ধাপে ডেপ্লয়মেন্ট ব্যবহার করুন।
- একটি বেসলাইন নীতি সেট তৈরি করুন: অগ্রাধিকার, মাঝারি এবং সীমাবদ্ধ ক্লাসগুলো সংজ্ঞায়িত করুন।
- প্রথমে একটি সীমিত এলাকায় প্রয়োগ করুন: একটি একক ফ্লোর, ওয়ার্ড, ভাড়াটে জোন বা স্টোর ক্লাস্টারই যথেষ্ট।
- বাস্তব ওয়ার্কফ্লো দিয়ে পরীক্ষা করুন: স্টাফ লগইন, পেমেন্ট, ভয়েস, গেস্ট অনবোর্ডিং, ডিভাইস রোমিং।
- ব্যতিক্রমের চাপ পরীক্ষা করুন: যদি সবাই অবিলম্বে একটি বিশেষ নিয়মের জন্য অনুরোধ করে, তবে নীতি মডেলটি ভুল।
- কেবল যাচাইকরণের পরেই প্রসারিত করুন: অভিযোগের ধরণ উন্নত হলে এবং অপারেশন স্থিতিশীল থাকলে আরও বড় পরিসরে রোলআউট করুন।
কয়েকটি বাস্তবায়নগত ভুল এড়িয়ে চলা উচিত:
- ওভারল্যাপিং নিয়ম: যদি একাধিক নীতি একই ট্রাফিকের সাথে মিলে যেতে পারে, তবে শেষ পর্যন্ত কেউ না কেউ ভুলে যাবে যে কোনটি কার্যকর হবে।
- অ্যাপ্লিকেশন ব্লাইন্ড স্পট: আপনি যদি ট্রাফিক সঠিকভাবে সনাক্ত করতে না পারেন, তবে আপনার নীতিটি কেবল অনুমানের ওপর ভিত্তি করে হবে।
- আপস্ট্রিম আচরণ উপেক্ষা করা: অভ্যন্তরীণ QoS ট্যাগগুলো আপনার নিয়ন্ত্রণ সীমার বাইরে এন্ড-টু-এন্ড ট্রিটমেন্টের গ্যারান্টি দেয় না।
ব্যবহারিক উদ্দেশ্যটি চমৎকারতা নয়। এটি হলো পুনরাবৃত্তিযোগ্যতা। একটি ব্যান্ডউইথ ম্যানেজমেন্ট নীতি কেবল তখনই সাহায্য করে যখন নেটওয়ার্ক এটি ব্যবহারকারী, সাইট এবং সাপোর্ট টিমগুলোর মধ্যে ধারাবাহিকভাবে প্রয়োগ করতে পারে।
যা গুরুত্বপূর্ণ তা পরিমাপ করা: মনিটরিং এবং ডায়াগনস্টিকস
বেশিরভাগ ব্যান্ডউইথ ম্যানেজমেন্ট প্রকল্প একই উপায়ে ব্যর্থ হয়। টিম একটি নীতি পরিবর্তন করে, অভিযোগগুলো কিছুটা পরিবর্তিত হয়, এবং কেউ প্রমাণ করতে পারে না যে নেটওয়ার্কের উন্নতি হয়েছে নাকি ব্যবহারকারীরা এক সপ্তাহের জন্য টিকিট ওপেন করা বন্ধ করে দিয়েছে।
এই কারণেই টিউনিংয়ের চেয়ে মনিটরিং বেশি গুরুত্বপূর্ণ। তিনটি পৃথক প্রশ্নের উত্তর দেওয়ার জন্য আপনার পর্যাপ্ত দৃশ্যমানতা প্রয়োজন। কোন অ্যাপ্লিকেশনগুলো সীমিত রিসোর্স ব্যবহার করছে? কনজেশনটি কি স্থানীয় নাকি আপস্ট্রিম? নীতিটি কি ব্যবহারকারীর অভিজ্ঞতা উন্নত করেছে, নাকি কেবল ব্যবহারের গ্রাফ পরিবর্তন করেছে?
Creanord এমন একটি ব্যবধান হাইলাইট করে যা অনেক মূলধারার নির্দেশিকা মিস করে। উন্নত মনিটরিং লাইভ ট্রাফিককে প্রভাবিত না করেই উপলব্ধ ব্যান্ডউইথ সনাক্ত করতে পারে এবং প্রোঅ্যাক্টিভ ক্যাপাসিটি প্ল্যানিংকে সমর্থন করতে পারে, যা গুরুত্বপূর্ণ প্রশ্নটিকে “আমি কীভাবে ব্যান্ডউইথ सीमित করব?”-এর চেয়ে আরও বেশি “আমি নীতি পরিবর্তন করার বা আরও ব্যান্ডউইথ কেনার আগে কীভাবে কনজেশন সঠিকভাবে পরিমাপ করব?” করে তোলে ( কনজেশন পরিমাপ এবং প্রোঅ্যাক্টিভ ক্যাপাসিটি প্ল্যানিং সম্পর্কে Creanord )।
কেবল মোট ব্যবহারের পরিবর্তে কী দেখতে হবে
মোট ব্যবহার দরকারী, তবে এটি নিজেই একটি দুর্বল ডায়াগনস্টিক। একটি ব্যস্ত লিঙ্ক স্বয়ংক্রিয়ভাবে একটি ভাঙা লিঙ্ক নয়, এবং একটি কম ব্যবহৃত লিঙ্কও অত্যন্ত খারাপ ব্যবহারকারীর অভিজ্ঞতা তৈরি করতে পারে।
ব্যবহারকারীর প্রভাব প্রকাশ করে এমন সূচকগুলো ট্র্যাক করুন:
- অ্যাপ্লিকেশন লেটেন্সি: লেনদেন-ভারী অ্যাপস এবং ক্লাউড প্ল্যাটফর্মের জন্য গুরুত্বপূর্ণ।
- জিটার এবং ধারাবাহিকতা: ভয়েস এবং রিয়েল-টাইম কোলাবোরেশনের জন্য অপরিহার্য।
- প্রতি-ব্যবহারকারী থ্রুপুট: গেস্ট এবং ভাড়াটে পরিবেশে দরকারী যেখানে ন্যায্যতা গুরুত্বপূর্ণ।
- লোডের অধীনে কিউ (Queue) আচরণ: আপনার শেপিং এবং অগ্রাধিকার নির্ধারণ আপনি যা চেয়েছিলেন তা করছে কিনা তা দেখায়।
- অভিযোগের সাথে সময়ের সম্পর্ক: অপারেশনে সবচেয়ে অবমূল্যায়িত মেট্রিক।
কীভাবে নীতি, আরএফ (RF) এবং ব্যাকহল আলাদা করবেন
সব খারাপ পারফরম্যান্সকে নীতিগত সমস্যা হিসেবে বিবেচনা করা সময় নষ্ট করার দ্রুততম উপায়। সম্ভাব্য কারণগুলো আলাদা করতে লক্ষণের ধরণ ব্যবহার করুন।
| লক্ষণের ধরণ | অধিক সম্ভাব্য কারণ | প্রথমে কী পরীক্ষা করবেন |
|---|---|---|
| ব্যস্ত সময়ে কেবল নির্দিষ্ট অ্যাপ্লিকেশনগুলো ব্যর্থ হয় | নীতি বা শ্রেণীবিভাগের সমস্যা | ট্রাফিক ক্লাস ম্যাপিং, কিউ নিয়ম, অ্যাপ সনাক্তকরণ |
| একটি এলাকার ব্যবহারকারীরা অন্যদের চেয়ে বেশি অভিযোগ করেন | আরএফ (RF) বা অ্যাক্সেস পয়েন্ট প্রতিযোগিতা | কভারেজ, চ্যানেল ব্যবহার, AP প্লেসমেন্ট, ক্লায়েন্ট ডেনসিটি |
| প্রতিদিন একই সময়ে পুরো সাইট ধীরগতির হয়ে যায় | ব্যাকহল বা আপলিংক সীমাবদ্ধতা | WAN ব্যবহারের ধরণ, পিক পিরিয়ডের চাহিদা, সার্কিট হেডরুম |
| স্টাফ পরিষেবাগুলো কাজ করে কিন্তু গেস্ট অভিজ্ঞতা ভেঙে পড়ে | বরাদ্দ ইচ্ছাকৃত বা খুব কঠোর হতে পারে | গেস্ট ক্যাপ, ন্যায্যতা নিয়ম, প্রমাণীকরণ প্রবাহ |
| মাঝারি ব্যবহারের মধ্যেও সবকিছু অসামঞ্জস্যপূর্ণ মনে হয় | ওয়্যারলেস স্বাস্থ্য বা আপস্ট্রিম অস্থিরতা | AP লোড, রোমিং আচরণ, প্যাকেট লস, প্রদানকারীর পাথ কোয়ালিটি |
একটি ভালো ডায়াগনস্টিক ওয়ার্কফ্লো সাধারণত এইরকম দেখায়:
- অভিযোগটি কোথায় ঘটছে তা নিশ্চিত করুন: একটি এলাকা, একটি ব্যবহারকারী গ্রুপ, একটি অ্যাপ, নাকি পুরো সাইট।
- আপলিংকটি সীমাবদ্ধ কিনা তা পরীক্ষা করুন: অনুমান করবেন না।
- আক্রান্ত এলাকার ওয়্যারলেস স্বাস্থ্য পর্যালোচনা করুন: ক্লায়েন্ট ডেনসিটি এবং আরএফ (RF) পরিস্থিতি প্রায়শই স্থানীয় সমস্যা ব্যাখ্যা করে।
- অ্যাপ্লিকেশন শ্রেণীবিভাগ পরিদর্শন করুন: অ্যাপটি যদি আপনার ভাবা ক্লাসে না থাকে, তবে নীতিটি অপ্রাসঙ্গিক।
- একটি নিয়ন্ত্রিত নীতি পরিবর্তনের আগে এবং পরে তুলনা করুন: ব্যবহারকারীর অভিজ্ঞতা উন্নত না হলে, ত্রুটিটি অন্য কোথাও রয়েছে।
লিঙ্কটি পূর্ণ কিনা তা জিজ্ঞাসা করবেন না। জিজ্ঞাসা করুন চাহিদা যখন বিশৃঙ্খল থাকে তখন সঠিক ট্রাফিক নির্বিঘ্নে পার হচ্ছে কিনা।
অপারেশন টিমগুলো ব্যবহার করতে পারে এমন রিপোর্টিং
নেটওয়ার্ক টিমের প্রযুক্তিগত বিবরণের প্রয়োজন। ভেন্যু লিডারদের সিদ্ধান্তের প্রয়োজন। আপনার রিপোর্টিং উভয়কেই সমর্থন করা উচিত।
এর অর্থ হলো মনিটরিং-কে সহজ ফলাফলে রূপান্তর করা যেমন পিক সময়ে কোন পরিষেবাগুলো প্রতিক্রিয়াশীল ছিল, কোন জোনগুলো বারবার অভিযোগ তৈরি করেছে এবং অপারেশনাল ওয়ার্কফ্লোর ক্ষতি না করে গেস্ট ট্রাফিক নিয়ন্ত্রণ করা হয়েছিল কিনা। নেটওয়ার্ক দৃশ্যমানতার সাথে ভেন্যুর প্রেক্ষাপটকে একত্রিত করে এমন সরঞ্জামগুলো এখানে সাহায্য করতে পারে। Purple-এর গেস্ট WiFi অ্যানালিটিক্স হলো নেটওয়ার্ক টেলিমেট্রির পাশাপাশি ব্যবহারকারী এবং সেশন ডেটা কীভাবে সেই বৃহত্তর অপারেশনাল ভিউকে সমর্থন করতে পারে তার একটি উদাহরণ।
মনিটরিংয়ের একটি মূল মূল্য হলো আত্মবিশ্বাস। আপনি যখন প্রমাণ করতে পারেন যে ধীরগতি একটি উইংয়ে আরএফ (RF) প্রতিযোগিতার কারণে হয়েছিল, তখন আপনি QoS নীতিগুলো পুনর্লিখন করা বন্ধ করেন যা কখনই সমস্যা ছিল না।
সাধারণ ব্যান্ডউইথ ম্যানেজমেন্টের ফাঁদগুলো ট্রাবলশুট করা
এমনকি সুপরিকল্পিত ব্যান্ডউইথ ম্যানেজমেন্টও ভেঙে পড়ে যখন প্রয়োগের যুক্তি বিশৃঙ্খল হয়ে যায়। লক্ষণগুলো পরিচিত মনে হতে পারে। আটকে যাওয়া ভিডিও কল, অপ্রত্যাশিত গেস্ট অ্যাক্সেস, ধীরগতির ক্লাউড অ্যাপস, ব্যস্ত সময়ে ভাড়াটেদের অভিযোগ। কারণটি প্রায়শই প্রত্যাশার চেয়ে কম আকর্ষণীয় হয়।
যে ভুলগুলো বারবার ঘটে
কয়েকটি ত্রুটি বারবার সামনে আসে:
- কোনো ব্যবহারিক প্রভাব ছাড়াই QoS মার্কিং: আপনি আপনার নেটওয়ার্কের ভেতরে সুন্দরভাবে ট্রাফিক চিহ্নিত করতে পারেন এবং তবুও কোনো সুবিধা পাবেন না যদি সেই মার্কিংগুলো আপনার নিয়ন্ত্রিত অংশের বাইরে সম্মানিত না হয়।
- নীতি সংঘর্ষ: দুটি নিয়ম একই অ্যাপ্লিকেশন বা ব্যবহারকারী গ্রুপের সাথে মিলে যায়, এবং ফলাফলটি উদ্দেশ্যের চেয়ে প্রক্রিয়াকরণের ক্রমের ওপর নির্ভর করে।
- অতিরিক্ত শেপিং: টিম কন্ট্রোল নিয়ে খুব কঠোর হয়ে যায় এবং কেবল অপ্রয়োজনীয় ট্রাফিকই নয়, স্বাভাবিক কাজকেও বাধাগ্রস্ত করে ফেলে।
- ভুল শ্রেণীবিভাগ: অ্যাপ্লিকেশনটি ভুলভাবে সনাক্ত করা হয়েছে, এমনভাবে এনক্রিপ্ট করা হয়েছে যা আপনার টুলিং ব্যাখ্যা করতে পারে না, অথবা ভুল ক্লাসে গ্রুপ করা হয়েছে।
এই সমস্যাগুলোর কারণেই সহজ নীতিগুলো প্রায়শই জটিল নীতিগুলোর চেয়ে ভালো পারফর্ম করে। জটিলতা আপনাকে ঘোরানোর জন্য আরও বেশি নব (knob) দেয়। এটি আপনাকে ভুল হওয়ার আরও বেশি উপায়ও দেয়।
একটি দ্রুত ত্রুটি-পৃথকীকরণ চেকলিস্ট
যখন কেউ “ধীরগতির ভিডিও কল” বা “ত্রুটিপূর্ণ WiFi” রিপোর্ট করে, তখন এই ক্রমে লক্ষণটি পরীক্ষা করুন:
- প্রথমে অবস্থান: এটি কি একটি রুম, ফ্লোর, ওয়ার্ড বা রিটেইল ইউনিটে সীমাবদ্ধ?
- এরপর ব্যবহারকারী গ্রুপ: এটি কি গেস্ট, স্টাফ, ভাড়াটে নাকি সবাই?
- অ্যাপ্লিকেশন পরিধি: এটি কি একটি অ্যাপ নাকি সমস্ত ইন্টারেক্টিভ ট্রাফিক?
- সময়ের ধরণ: এটি কি কেবল অনুমানযোগ্য পিক সময়ে ঘটে?
- নীতি পরীক্ষা: আক্রান্ত ট্রাফিক ক্লাসটি কি সম্প্রতি পরিবর্তিত হয়েছে?
- ওয়্যারলেস সুস্থতা পরীক্ষা: সিগন্যাল কোয়ালিটি বা ক্লায়েন্ট ডেনসিটি কি আসল সমস্যা?
- ব্যাকহল পর্যালোচনা: অভিযোগের সময়ের মধ্যে আপলিংকটি কি সীমাবদ্ধ?
যদি একজন ব্যবহারকারী সব জায়গায় অভিযোগ করেন, তবে ডিভাইসটি পরীক্ষা করুন। যদি অনেক ব্যবহারকারী এক জায়গায় অভিযোগ করেন, তবে আরএফ (RF) পরিবেশ পরীক্ষা করুন। যদি সবাই একই সময়ে অভিযোগ করেন, তবে আপলিংকটি পরীক্ষা করুন।
একটি ব্যবহারিক ট্রাবলশুটিংয়ের অভ্যাস সাহায্য করে। একবারে একটি জিনিস পরিবর্তন করুন, ফলাফল রেকর্ড করুন এবং “ফিক্স বান্ডিল” এড়িয়ে চলুন যেখানে আপনি একটি রক্ষণাবেক্ষণের সময়ে শেপিং, AP সেটিংস এবং ইন্টারনেট রাউটিং পরিবর্তন করেন। যদি পারফরম্যান্স উন্নত হয়, তবে আপনি জানতে পারবেন না কেন। যদি এটি আরও খারাপ হয়, তবে আপনি জানতে পারবেন না কোথায় রোল ব্যাক করতে হবে।
ব্যান্ডউইথ ম্যানেজমেন্ট সম্পর্কে প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
ব্যান্ডউইথ ম্যানেজমেন্ট কি লেটেন্সি বাড়ায়?
খারাপভাবে করা হলে এটি হতে পারে। যেকোনো কিউইং (queueing) মেকানিজম বিলম্ব যোগ করতে পারে যদি আপনি অতিরিক্ত বড় কিউ তৈরি করেন বা একটি সীমাবদ্ধ ক্লাসে খুব বেশি ট্রাফিক পুশ করেন। সঠিকভাবে করা হলে, ব্যান্ডউইথ ম্যানেজমেন্ট প্রায়শই অনুভূত পারফরম্যান্স উন্নত করে কারণ এটি বিলম্ব-সংবেদনশীল ট্রাফিককে আকস্মিক বৃদ্ধি এবং প্রতিযোগিতা থেকে রক্ষা করে।
মূল বিষয় হলো বেছে বেছে অগ্রাধিকার দেওয়া। নেটওয়ার্কের অর্ধেক অংশকে “উচ্চ অগ্রাধিকার” বাকেটে রাখবেন না এবং পরিষ্কার ফলাফলের আশা করবেন না।
ব্রডব্যান্ডের গতি বাড়ার সাথে সাথে কি ব্যান্ডউইথ ম্যানেজমেন্ট এখনও প্রয়োজনীয়?
হ্যাঁ। যুক্তরাজ্যের গড় ফিক্সড ব্রডব্যান্ড ডাউনলোড স্পিড নভেম্বর ২০১৯-এ 54.2 Mbit/s থেকে নভেম্বর ২০২০-এ 69.4 Mbit/s-এ উন্নীত হয়েছে এবং একই সময়ে গড় আপলোড স্পিড 8.2 Mbit/s থেকে 17.2 Mbit/s-এ বৃদ্ধি পেয়েছে। এই বৃদ্ধি গুরুত্বপূর্ণ কারণ ভিডিও মিটিং, ক্লাউড ব্যাকআপ এবং কোলাবোরেটিভ টুলের মতো আপস্ট্রিম-ভারী ব্যবহার অগ্রাধিকার নির্ধারণ এবং মনিটরিং-কে আরও বেশি গুরুত্বপূর্ণ করে তোলে, কম নয় ( Ofcom ব্রডব্যান্ড গতির পরিবর্তন এবং ব্যান্ডউইথ পরিকল্পনার প্রেক্ষাপট সম্পর্কে Bandicoot Marketing-এর সারসংক্ষেপ )।
অতিরিক্ত ক্ষমতা সাহায্য করে। এটি গুরুত্বপূর্ণ এবং অ-গুরুত্বপূর্ণ ট্রাফিকের মধ্যে প্রতিযোগিতা দূর করে না।
আইডেন্টিটি-ভিত্তিক নীতি এবং MAC-ভিত্তিক নিয়মের মধ্যে পার্থক্য কী?
MAC-ভিত্তিক নিয়মগুলো ডিভাইস সনাক্ত করে। আইডেন্টিটি-ভিত্তিক নিয়মগুলো ব্যবহারকারী, গ্রুপ বা ভূমিকা সনাক্ত করে। এটি একটি বড় অপারেশনাল পার্থক্য।
পরিবর্তনশীল ডিভাইস, ব্যক্তিগত ডিভাইস, গেস্ট অনবোর্ডিং এবং শেয়ার্ড স্পেস রয়েছে এমন পরিবেশে MAC নিয়মগুলো ভঙ্গুর হয়। আইডেন্টিটি-ভিত্তিক নীতি স্টাফ, গেস্ট, ঠিকাদার, ভাড়াটে বা এন্টারপ্রাইজ ডিভাইসের মতো ব্যবসায়িক যুক্তির সাথে মেলানো সহজ।
ব্যান্ডউইথ ম্যানেজমেন্ট কীভাবে SD-WAN-এর সাথে সম্পর্কিত?
তারা ভিন্ন ভিন্ন সমস্যার সমাধান করে। SD-WAN সিদ্ধান্ত নেয় কীভাবে ট্রাফিক সাইট বা সার্কিট জুড়ে উপলব্ধ পথ এবং নীতিগুলো ব্যবহার করে। ব্যান্ডউইথ ম্যানেজমেন্ট সিদ্ধান্ত নেয় কীভাবে ট্রাফিক একটি নির্দিষ্ট পথ বা অংশে সীমিত রিসোর্স শেয়ার করে।
বাস্তবে, তারা একে অপরের পরিপূরক। SD-WAN বুদ্ধিমত্তার সাথে ট্রাফিক পরিচালনা করতে পারে, যখন ব্যান্ডউইথ ম্যানেজমেন্ট গুরুত্বপূর্ণ অ্যাপ্লিকেশনগুলোকে রক্ষা করে যখন ট্রাফিক কোনো সার্কিট বা স্থানীয় অ্যাক্সেস নেটওয়ার্কে পৌঁছায়।
ট্রাফিক যখন এনক্রিপ্ট করা এবং শ্রেণীবদ্ধ করা কঠিন হয় তখন আমার কী করা উচিত?
গভীর সনাক্তকরণের ওপর কম নির্ভর করুন এবং আপনার নিয়ন্ত্রিত প্ল্যাটফর্মগুলো থেকে ভূমিকা, গন্তব্যের ধরণ, নেটওয়ার্ক সেগমেন্ট এবং অ্যাপ্লিকেশন প্রসঙ্গের সংমিশ্রণের ওপর বেশি নির্ভর করুন। আপনি সবসময় এনক্রিপ্ট করা ট্রাফিকের নিখুঁত দৃশ্যমানতা পাবেন না, তাই শ্রেণীবিভাগ অসম্পূর্ণ থাকলেও নীতি ডিজাইনটিকে ব্যবহারিক রাখতে হবে।
এর অর্থ সাধারণত অতিরিক্ত উচ্চাভিলাষী মাইক্রো-নীতির চেয়ে স্পষ্ট ভূমিকা-ভিত্তিক নিয়মগুলোকে অগ্রাধিকার দেওয়া।
গেস্টদের কি সবসময় রেট-সীমিত করা উচিত?
সবসময় নয়। অতিথিদের একটি অনুমানযোগ্য অভিজ্ঞতার প্রয়োজন, বিশেষ করে হসপিটালিটি এবং প্রিমিয়াম রিটেইল পরিবেশে। লক্ষ্য হলো ন্যায্যতা এবং মূল পরিষেবাগুলোর সুরক্ষা, নির্বিচারে বঞ্চিত করা নয়।
একটি ভালো পদ্ধতি হলো পরিষেবার একটি স্থিতিশীল বেসলাইন বজায় রেখে গেস্ট ট্রাফিককে একটি উপযুক্ত ক্লাস এবং স্পষ্ট সিলিং দেওয়া।
ব্যান্ডউইথ নীতিগুলো কত ঘন ঘন পর্যালোচনা করা উচিত?
ভেন্যুটি উল্লেখযোগ্যভাবে পরিবর্তিত হলে এগুলো পর্যালোচনা করুন। একটি রিফিট, নতুন অ্যাপ রোলআউট, ক্লিনিকাল ওয়ার্কফ্লো পরিবর্তন, ভাড়াটেদের মিশ্রণে পরিবর্তন বা গেস্ট ব্যবহারের ধরণে পরিবর্তন সবই একটি পুরানো নীতিকে অপ্রচলিত করে তুলতে পারে। বড় পরিবর্তন ছাড়াই, একটি পর্যায়ক্রমিক পর্যালোচনা বুদ্ধিমানের কাজ কারণ ট্রাফিকের ধরণ খুব কমই স্থির থাকে।
একটি বহুমুখী ব্যবহারের ভেন্যুর জন্য সবচেয়ে সহজ দরকারী নীতি কোনটি?
তিনটি ক্লাস দিয়ে শুরু করুন। গুরুত্বপূর্ণ ব্যবসায়িক ট্রাফিক। সাধারণ ব্যবসায়িক এবং গেস্ট ট্রাফিক। ব্যাকগ্রাউন্ড বা বাল্ক ট্রাফিক। আপনি যদি সেই স্তরে নির্ভরযোগ্যভাবে শ্রেণীবদ্ধ করতে পারেন এবং ফলাফল পর্যবেক্ষণ করতে পারেন, তবে আপনি প্রায়শই এমন একটি বিস্তৃত শ্রেণীবিন্যাসের চেয়ে ভালো ফলাফল পাবেন যা কেউ বজায় রাখতে পারে না।
Purple আইটি টিমগুলোকে বিদ্যমান অবকাঠামোতে গেস্ট, স্টাফ এবং মাল্টি-টেন্যান্ট WiFi পরিবেশে আইডেন্টিটি-ভিত্তিক অ্যাক্সেস এবং নীতি নিয়ন্ত্রণ প্রয়োগ করার একটি ব্যবহারিক উপায় দেয়। আপনি যদি শেয়ার্ড পাসওয়ার্ড এবং কঠোর SSID-ব্যাপী নিয়মের বাইরে যেতে চান, তবে আপনার বর্তমান নেটওয়ার্ক স্ট্যাকের পাশাপাশি Purple মূল্যায়ন করার মতো।
