مطالب فصل
Traffic Shaping
Traffic shaping
در این قسمت قصد داریم بحث مربوط به Traffic shaping را بررسی نماییم.
Traffic shaping را نیز همانند بقیه مباحث میتوان در هر دو سطح Port group و vSwitch انجام داد. اگر برای VM ها بیش از یک vSwitch نداشته باشیم، بی معنی است که بحث Traffic shaping را در سطح VSS انجام دهیم، چون ما تنظیمات مربوط به Traffic shaping را برای یک سری از VM هایی انجام میدهیم تا پهنای باند بهتر یا کنترل شدهای داشته باشند؛ به طور مثال مشخص کنیم VM های DC، Test و VM های مربوط به Developer ها پهنای باند کمتری داشته باشند ولی VM های Production که شامل Web server، Database و VM هایی که برای سرویسدهی به سازمان ایجاد شدهاند، بهتر است نسبت به VM های دیگر پهنای باند بیشتر یا کنترل شدهای داشته باشند.
ما در این آموزش قصد داریم Traffic shaping را در سطح PG راهاندازی نماییم، البته راهاندازی آن در سطح vSwitch نیز قابل انجام است و به این معنی نیست که اصلا به درد نمیخورد. شما میتوانید در بحثهای مختلف با استفاده از سوئیچ های مختلف بحث Traffic shaping را در سطح سوئیچ انجام دهید، هر چند از لحاظ Configuration و Option هیچ تفاوتی باهم ندارند. شما میتوانید با انتخاب سوئیچ مورد نظر و با کلیک بر روی Edit settings و از قسمت Traffic shaping وضعیت آن را Enabled یا Disabled کرده و مقادیر مورد نظر را وارد نمایید.
در سطح PG نیز به این صورت میباشد که PG مورد نظر را انتخاب کرده و بر روی Edit settings کلیک کنید و از قسمت Status آن را از حالت Inherit from vSwitch (ارث بری از vSwitch) خارج کرده و در یکی از حالت های Enabled یا Disabled قرار داده و مقادیر را وارد نمایید.
در دنیای واقعی، ما چه زمانی به Traffic shaping نیاز خواهیم داشت؟ ما زمانی از Traffic shaping استفاده میکنیم که Egress port پهنای باند محدودی داشته باشد و ما با استفاده از Traffic shaping، پهنای باند VM ها و Component های داخل شبکه را طوری shape کنیم که بیشتر از پهنای باند خروجی یا همان Egress port نشود. مثلا فرض کنید همانند شکل زیر، چندین Router به یک Main router یا Firewall متصل شدهاند، که هر کدام از این Router ها پهنای باند متفاوتی دارند اما Main router ما فقط یک Interface خروجی دارد. در این مرحله زمانی که بسته میخواهد از Router های همسایه خارج شود، باید Traffic shaping را انجام دهیم تا مقدار پهنای باند مصرفی را تعیین کنیم. فقط به خاطر داشته باشید، در سطح VSS ها، ما فقط به Egress یا همان Upload دسترسی داریم تا مقدار پهنای باند مصرفی را مشخص کنیم. (در اینجا منظور از Egress همان ترافیک خروجی از VM به سمت Network میباشد نه ترافیک وارد شده به VM را Ingress. پس ما در اینجا میخواهیم پهنای باند تمام ترافیک های خروجی VM را کنترل کنیم ولی در سطح VDS میتوانیم هر دو آن ها را یعنی Egress و Ingress را کنترل نماییم.
خب ما تنظیمات Traffic shaping را در Main router انجام میدهیم تا در آن هیچ congestion ای اتفاق نیفتد. خب این یعنی چی؟ یعنی هیچ بسته ای به طور اتفاقی یا اجباری drop نشود، در واقع به اندازه ای که Main router میتواند پهنای باند در اختیار ما بگذارد، ما پهنای باند مشخص شده را به اندازه مساوی بین هر سه Router تقسیم کنیم.
حال فرض کنید Router ها نقش PG ها را بازی میکنند که VM ها به آنها متصل هستند و Main router در نقش VSS و در انتها پورت های سرور قرار دارند که قصد داریم پهنای باند هر کدام از PG ها را کنترل کنیم تا پهنای باند بهتری داشته باشند.
قبل از آشنایی با تنظیمات Traffic shaping، بهتر است با دو مفهوم آشنا شویم که حتما قبلا به گوشتان خورده و همیشه خواسته یا ناخواسته با آن درگیر هستیم ولی زیاد به آن توجهی نداریم.
مفهوم CIR و MIR
مفهوم CIR و MIR
زمانی که شما از یک ISP (پارس آنلاین، صبانت، ایرانسل، همراه اول، مخابرات و ...) اینترنت خریداری میکنید، یک قرارداد مابین شما و ISP بسته میشود که در آن قرارداد ذکر شده است به اندازه CIR یا همان Committed Information Rate برای شما پهنای باند در نظر گرفته میشود و هم چنین ذکر شده است اگر به عبارتی سر ISP خلوت بود، ISP میتواند به اندازه MIR یا همان Maximum Information Rate پهنای باند در اختیار شما قرار دهد.
حال دقیقا همین مفاهیم در Traffic shaping PG ها نیز وجود دارند، که در این تنظیمات CIR همان Average bandwidth و MIR همان Peak bandwidth میباشند و مقدار پهنای باندی که برای Average bandwidth تعیین میشود حتما قابل ارائه خواهد بود ولی در مورد مقدار پهنای باندی که برای Peak bandwidth مشخص میکنیم، نمیتوانیم قولی بدهیم که آیا میتوانیم این مقدار را به VM ارائه دهیم یا نه! اگه تونستیم به روی چشم!!! واحد کمیت این مقادیر نیز برحسب kb/s میباشد.
سوال: اگر VM بخواهد بسته هایی با اندازه بزرگتر از مقداری که در Average bandwidth مشخص کردیم ارسال کند، چه اتفاقی میافتد؟
PG اصلا نمیتواند بسته های اضافی را تشخیص دهد و قطعا آنها را drop میکند و VM مجبور میشود آنها را Retransmit کند. پس حتما به این مورد توجه کنید که VM ها به چه مقدار پهنای باندی نیاز دارند.
زمانی که برای VM مقدار پهنای باندی که در Peak bandwidth مشخص کردیم، قابل ارائه شد، نمیتواند که تا همیشه در این مقدار باقی بماند، پس ما باید یک Value ای مشخص کنیم که اگر به این مقدار رسید دوباره به مقدار پهنای باند مشخص شده در Average bandwidth برگردد که ما این Value را از قسمت Burst size مشخص میکنیم.
خب پس چی شد؟!! ما همیشه در حالت Average bandwidth هستیم، اگر PG یا سوئیچ این قابلیت را داشت که بتواند پهنای باند بیشتری ارائه دهد به مقدار Peak bandwidth میرسد ولی تا ابد در این مقدار نمیماند، اینکه نمیتواند تا ابد در این مقدار را بماند را Burst size مشخص میکند، به این صورت که تا چقدر اجازه دارم در پهنای باند Peak bandwidth پیش بروم. مثلا اگر مقدار Average bandwidth را 1Mb، مقدار Peak bandwidth را 10Mb و Burst size را 500kb در نظر بگیریم، VM همیشه مقدار 1Mb را دارد، در شرایط خوب میتواند به 10Mb برسد ولی فقط اجازه دارد 500kb دیتا رد و بدل کند که تمامی این موارد در جهت ترافیک خروجی VM انجام میگیرد؛ در واقع هنگام Upload ترافیک تاثیر دارد نه هنگام Download(ورود ترافیک).
نکته:
Traffic shaping را معمولا بر روی PG ها اعمال میکنیم و معنی ندارد بر روی VSS این کار را انجام دهیم. به راحتی میتوانید VM ها را به PG ها متصل کرده و در سطح PG بر روی VM ها Traffic shaping را اعمال نمایید.
فیلم آموزشی
فیلم آموزشی
برای ثبت نظر ابتدا وارد حساب کاربری خود شوید
ورود به حساب کاربریهیچ نظری ارسال نشده است! اولین نظر را شما ارسال کنید...