سرورهای کلاستر

سرورهای کلاستر ( قسمت دوم )

سرورهای کلاستر بیشتر برای برنامه هایی به کار میرود که مدت زمان زیادی را در حافظه می مانند و یاتعویض داده ی بیشتری را انجام می دهند که به آنها State Full Applications گفته می شود که می توان سرورهای بانک اطلاعاتی نظیر Microsoft SQL رانام برد

در کلاسترینگ سرورهاNode  نیز نامیده می شوند و همگی Node ها از یک سری برنامه و داده خاص ودیگر امکانات شبکه استفاده می کنند. لذا هر کدام از Node ها می توانند درخواستهای Client  را انجام دهند، تنظیم کردن Node که بتواند فعال یا غیر فعال باشد و برای موارد ضروری فعال شود در اختیار خود شماست.

برای مثال یک سرویس دهنده کلاستر ساده می تواند شامل دو Node باشد که هر دو باید ویندوز Server 2008 R2 , Microsoft SQL,Datacenter یا Enterprise  را در حالت اجرا داشته باشد و هر دو به NAS  ( محل ذخیره سازی متصل شده به شبکه ) دسترسی داشته باشند که اطلاعات مربوط به بانک داده را درون خودش ذخیره کرده است. یکی از Node ها باید فعال و دیگری باید غیر فعال باشد.

در حالت معمول Node فعال به صورت عادی به کار خود ادامه داده و به درخواست  Clientها پاسخ می دهند و اطلاعات را ارسال یا دریافت می کنند اما اگر Node فعال به هر دلیلی از سرویس خارج شد Node غیر فعال به سرعت از سرویس خارج شدن Node فعال را تشخیص می دهد و خود فعال می شود و به در خواست Client  ها رسیدگی می کند.

البته این روش ( Active/Passive )  یک مشکل عمده دارد و آن اینکه همیشه یکی از سرورها بیکار می باشد و تا زمانی که سرور اول از سرویس خارج نشود کاری انجام نمی دهد.

اما بسته به نوع برنامه می توان سرور کلاسترها را طوری طراحی  کرد که بتوانند کارهای مربوط به برنامه و وظایف را بین یکدیگر تقسیم کنند و بازدهی سرویس را بالا ببرند.

یک سرویس دهنده کلاستر جدای از Node های در حال اجرا، پروتکل و نام اختصاصی خود را دارد، بنابراین اگر سیستمی با خطا مواجه شود تغییر در عملکرد سرور برای آن Client  که درخواست خود را صادر کرده است احساس نمی شود و Client در خواست خود را به همان مقصد ارسال می کند، در چنین موقعی سرور غیر فعال در خواست را گرفته و رسیدگی می کند.

بنابراین کاهشی در کارایی و اجرای دستورالعمل ها وجود ندارد، نکته ای که باید در نظر داشت این است که نوع ویندوز هایی که کامپیوتر های یک کلاستر اجرا می کنند باید یکسان باشد.

در قسمت بعدی راجع به متعادل کردن بار شبکه   ( NLB  )  توضیح خواهیم داد .

سوئیچ توزیع شده در ESXi

سوئیچ توزیع شده در ESXi

مرکز داده ای را در نظر بگیرید که در آن از تعداد بالایی میزبان جهت تأمین منابع محاسباتی ماشینهای مجازی استفاده شده بنحویکه هر میزبان سوئیچ استاندارد مخصوص بخود را دارا باشد، تنظیم این تعداد سوئیچ و اطمینان از اینکه تمامی آنها دارای عملکرد و تنظیمات یکسانی باشند نیازمند دقت بالا و درنتیجه افزایش هزینه نیروی انسانی خواهد بود. علاوه بر این امکانات سوئیچ استاندارد نیز بسیار کم و محدود بوده و قادر نیست تمامی نیازهای شبکه را تأمین نماید. برای حل این مشکلات VMware سوئیچ دیگر را تحت نام Virtual Distributed Switch یا DVS معرفی کرده است که در ادامه معماری این سوئیچ مورد بررسی قرار می گیرد:

با نتکو در سرور حرفه ای شوید  www.netco.biz

Control Plane:

سوئیچهای VDS موجود بر روی هر میزبان از طریق سرور VCenter مدیریت شده و وظیفه ساختن، تغییر دادن و حذف کردن هر VDS نیز بر عهده آن می باشد، در نتیجه هر سوئیچ VDS یکبار توسط VCenter ساخته شده و سپس به هر میزبان که احتیاج است اختصاص داده می شود. مفهموم VDS مشابه مفهوم کلاستر می باشد به این مفهوم که میتوان یک کلاستر را ساخته و تنظیمات HA و DRS نیز برای آن انجام داد ولی تا زمانی که میزبانی به آن کلاستر اختصاص داده نشود، نمیتوان خاصیت یا عملکردی نیز از آن انتظار داشت.

برای هر سویئچ DVS میتوان تعدادی Uplink را بصورت منطقی مشخص کرد که در حالت پیش فرض یا dvUplink نمایش داده می شود. پس از اضافه نمودن DVS به یک میزبان ESXi، میبایست Mapping میان Uplinkهای منطقی و Uplinkهای فیزیکی صورت بگیرد. بنابراین بهتر است نام Uplink را از حالت پیش فرض به نامی قابل فهم تر تغییر داد تا در صورت رفع مشکل از طریق پروتکلهایی نظیر LLDP و CDP بتوان پورتهای نظیر به نظیر با پورت سوئیچ فیزیکی را تشخیص دهیم. بعنوان مثال در صورت رعایت افزونگی نامهای TOR-A و TOR-B مشخص کننده مسیرهای متفاوت برای Uplink سوئیچ DVS خواهد بود.

شاید بنظر برسد که در صورت از مدار خارج شدن سرور VCenter، سوئیچ DVS نیز از کار بافتد، ولی واقعیت آن است که هر میزبان ESXi یک نسخه مجزا از این سوئیچ را در حافظه Cache خود (در مسیر /etc/vmware/dvsdata.db) نگهداری کرده و هر ۵ دقیقه تنظیمات آنرا در ارتباط با VCenter بروزرسانی می نماید. در صورتیکه VCenter پاسخگو نباشد، میزبان از نسخه Cache شده موجود DVS جهت سوئیچینگ بسته ها استفاده می کند و در صورت ارتباط مجدد تنظیمات سوئیچ DVS را بروزرسانی می نماید.

با نتکو در سرور حرفه ای شوید  www.netco.biz

Data Plane:

همانند سوئیچ استاندارد، در سوئیچ DVS نیز کلیه عملیات مربوط به Data Plane در لایه میزبان ESXi انجام می شود، بعبارات دیگر Vcenter تنها نقش کنترلر را ایفا نموده و داده ها مستقیماً توسط خود میزبان سوئیچ و ارسال می شوند.در ادامه به بررسی امکانات ارائه شده توسط سوئیچVDS می پردازیم:

با نتکو در سرور حرفه ای شوید  www.netco.biz

1. Distributed Port Groups:

بعلت اینکه چندین میزبان ESXi از یک سوئیچ DVS استفاده می کنند، Port Group ها هم باید میان میزبانها بصورت توزیع شده باشند. بعبارت دیگر هیچ میزبانی دیگر مالک سوئیچ مجازی و تنظیمات آن نخواهد بود و این تنها VCenter است که قادر به ایجاد VDS و اعمال تنظیمات آن برای تمامی کلاسترهای زیر مجموعه خود می باشد و محدوده عملکرد یک سوئیچ DVS حداکثر Datacenter Container خواهد بود. هر Port Group توزیع شده به تمامی Uplinkهایی که به سوئیچ DVS مرتبط هستند دسترسی خواهد داشت و تنظیمات و پالیسیهایی نظیر Teaming و Security مستقیماً از طریق Port Group مشخص می گردد، بنابراین بهتر است برای هر دسته پورت مجازی که به پالیسی متفاوتی جهت ارسال ترافیک احتیاج دارند، Port Group متفاوتی نیز ساخته شود. بعنوان مثال در Port Group اول تمامی Uplinkها در وضعیت Active قرار گرفته و از VLAN=100 جهت ارسال ترافیک ارسال نمایند و در Port Group دوم Uplinkها در وضعیت Active/Standby قرار گرفته و از VLAN=200 جهت ارسال ترافیک ارسال نمایند.

با نتکو در سرور حرفه ای شوید  www.netco.biz

VMkernel Ports

پورتهای مجازی از نوع VMkernel دارای یک تفاوت با پورتهای ماشین های مجازی هستند و آن اینکه این پورتها برای هر میزبان بصورت یکتا تعریف می شود و دارای تنظیمات IP Addressing و شماره ترتیب vmk منحصر بفرد است. بهمبن علت در تعریف پورتهای مجازی توزیع شده از نوع VMKernel، تنظیمات سخت افزاری و پالیسیهای مختلف از سوئیچ VDS استخراج می شود ولی تنظیمات منحصر بفرد نظیر IP Addressing، MTU توسط میزبان تعریف می گردد.

نکته مهم دیگری که در این رابطه وجود دارد مربوط به انتقال پورتهای از نوع VMkernel که برای مدیریت ESXi مورد استفاده قرار گرفته از سوئیچ استاندارد به سوئیچ VDS می باشد، چراکه هر گونه اشتباهی ممکن است موجب قطع شدن ارتباط مدیریتی میزبان ESXi به سرور VCenter گردد، برای این منظور دو راه پیشنهاد می گردد که صحت آن از قبل می بایست در محیط آزمایشگاه مورد بررسی قرار بگیرد:

1. انتقال یکی از Upli

nkهای مربوط به VMkernel به سوئیچ جدید، سپس انتقال پورت VMkernel به سوئیچ VDS و درنهایت انتقال Uplink باقیمانده به سوئیچ VDS.

2. انتقال همزمان Uplinkها و پورتهای VMkernel به سوئیچ VDS.

Virtual Machines

ارتباط پورتهای  ماشینهای مجازی از طریق Port Group های تعریف شده بر روی سوئیچ VDS برقرار می گردد بنابراین بهتر است برای هر دسته از ماشینهای مجازی که دارای خواص مشترکی (مثلاً VLAN های مشترک)هستند، Port Group بصورت مجزا تعریف شود و از قوانین نامگذاری مناسبی نیز جهت تفکیک Port Group های مختلف استفاده شود. یکی دیگر از بهبودهای بدست آمده از پورتهای توزیع شده، در عملیات VMotion و انتقال ماشینهای مجازی از یک میزبان به میزبانهای دیگر است چراکه تنظیمات سوئیچ VDS برای تمامی میزبانها یکسان می باشد و اختلالی در ارتباط شبکه ناشی از جابجایی ماشینها بوجود نخواهد آمد.

2. Monitoring:

سوئیچ VDS از هر دو پروتکل معمول برای مانیتورینگ سوئیچهای بالادست یعنی LLDP و CDP پشتیبانی می نماید:

۲٫۱٫ CDP:

بر روی سوئیچ VDS علاوه بر اینکه روش مانیتورینگ را میتوان CDP و یا LLDP انتخاب کرد، میتوان حالت مانیتورینگ را بر اساس یکی گزینه های زیر مشخص نمود:

ListenAdvertiseBoth (Listen And Advertise)

۲٫۲٫ LLDP:

پروتکل LLDP نسخه استاندارد و غیر انحصاری پروتکل CDP می باشد که از سوئیچهای تولید شده توسط سازندگان غیر سیسکویی نیز پشتیبانی می نماید. نکته قابل توجه اینکه سوئیچهای سیسکو نیز در حال حاضر از این پروتکل پشتیبانی می کنند، بنابراین انتخاب آن نسبت به CDP عاقلانه تر خواهد بود.

با نتکو در سرور حرفه ای شوید  www.netco.biz

۲٫۳٫ NetFlow:

یکی از امکانات افزوده شده در سوئیچ VDS نسبت به سوئیچ استاندارد قابلیت NetFlow می باشد. این پروتکل که توسط شرکت سیسکو توسعه داده شده است، جهت آنالیز ترافیک عبوری از سوئیچ مورد استفاده قرار می گیرد. در یک محیط مجازی سوئیچینگ ترافیک مابین دو میزبان که بر روی یک هاست و VLAN قرار گرفته اند توسط سوئیچ مجازی انجام می شود که به آن اصطلاحاً Dark Traffic می گویند. با استفاده از NetFlow میتوان چنین ترافیکی را آنالیز و توسط سرورهای NetFlow Collector مانیتور نمود.

سوئیچ VDS از نسخه IPFIX پروتکل NetFlow که منطبق بر نسخه ۹ استاندارد IETF می باشد پشتیبانی می نماید. جهت انجام مانیتورینگ توسط NetFlow لازم است تنظیمات در دو مرحله صورت بگیرد. مرحله اول تنظیمات خود NetFlow را در بر می گیرد و شامل مراحل زیر می باشد:

IP Address: آدرس سرور NetFlow Collector که اطلاعات ترافیکی به آن ارسال می شود در این قسمت وارد می گردد.

Port: شماره پورتی که توسط NetFlow Collector مورد استفاده قرار می گیرد در این قسمت وارد می گردد.

Switch IP Address: این قسمت بعنوان یک Identifier توسط NetFlow Collector جهت ایجاد تمایز میان ارسال کنندگان مختلف اطلاعات ترافیک مورد استفاده قرار می گیرد و لازم نیست حتماً یک آدرس قابل مسیریابی باشد. برای VDS میتوان آدرس Management را برای این منظور استفاده کرد.

Active flow export timeout in seconds: بازه زمانی است که سوئیچ اطلاعات مربوط به Flowهای فعال را جمع آوری و به سمت NetFlow Collector ار سال می نماید. با استفاده از این گزینه برای ارسال نتایج آنالیز یک Flow طولانی، میتوان آنرا در فواصل زمانی کوتاهتری ارسال کرد.

Idle flow export timeout in seconds: بازه زمانی است که سوئیچ اطلاعات مربوط به Flowهای غیر فعال را جمع آوری کرده و به سمت NetFlow Collector ارسال می نماید.

Sampling rate: نرخ نمونه گیری از ترافیک توسط این گزینه مشخص می گردد. مقدار پیش فرض ۰ می باشد به این معنی که تمامی ترافیک مورد آنالیز قرار می گیرد، برای مقادیر N، به ازای هر N فریم، یک فریم آنالیز شده و نتیجه آن به NetFlow Collector ارسال می گردد.

Process internal flows only: با استفاده از این گزینه میتوان عملیات آنالیز ترافیک را تنها به ترافیک داخلی سوئیچ VDS یا همان Dark Traffic محدود نمود.

گام دوم در تنظیمات فعال نمودن NetFlow بر روی پروتهای مختلف است که در VDS عملیات فعالسازی بازای هر Port Group (بر روی پورتهای متعلق به Port Group) قابل انجام می باشد:

۲٫۴٫ Port Mirroring:

قابلیت Port Mirroring این امکان را بوجود می آورد که از ترافیک خاصی بر حسب پورت یا VLAN یک Clone یا کپی دقیق ساخته شده و به مقصد خاصی ارسال گردد. از این کار دو هذف دنبال می شود: مانیتورینگ و Capture نمودن ترافیک. با استفاده از مانیتورینگ ترافیک جمع آوری شده  را آنالیز نموده و از صحت تنظیمات و برآورده شدن مقادیر SLA اطمینان حاصل می کنیم. Capture نمودن اطلاعات عموماً درکاربردهایی نظیر IP Telephony که در آن برخی مکالمات در Call Center ضبط می شوند، مورد استفاده قرار می گیرد.

در دنیای سوئیچهای فیزیکی از Port Mirroring یا SPAN جهت Clone

گرفتن از ترافیک پورت مربوط به یک سرور فیزیکی استفاده می گردد. با بوجود آمدن محیطهای مجازی، ترافیک پورت فیزیکی به سرورهای متعددی مرتبط بوده و امکان جداسازی آنها از یکدیگر وجود نداشت تا اینکه در نسخه vSphere 5.0 امکان Clone گرفتن از ترافیک بر حسب VLAN یا پورتهای مختلف بوجود آمد. در حال حاضر VDS از چهار مدل Port Mirroring بر حسب نوع نشست پشتیبانی می نماید:

با نتکو در سرور حرفه ای شوید  www.netco.biz

Distributed Port Mirroring: در این حالت بسته های Mirror با مبدأ هر تعداد پورت به مقصد هر تعداد پورت تنها بر روی یک میزبان ESXi قابل ارسال است. بنابراین چنانچه مبدأ و مقصد بسته های Mirror بر روی میزبانهای متفاوت باشد، این روش قابل اجرا نمی باشد.

Remote Mirroring Source: در این حالت بسته های Mirror مربوط به تعدادی از پورتهای مجازی به سمت پورتهای فیزیکی از نوع Uplink قابل ارسال است.

Remote Mirroring Destination: در این حالت بسته های Mirror مربوط به یک VLAN به سمت تعدادی از پورتهای مجازی قابل ارسال است.

Encapsulated Remote Mirroring (L3) Source: در این حالت بسته های Mirror مربوط به ماشینهای مجازی به سمت آدرس یک سیستم راه دور از طریق IP Tunnel قابل ارسال است. این روش مشابه RSPAN می باشد.

پورت مبدأ یک نشست Port Mirror میتواند یک یا چند پورت مجازی و یا رنجی از پورتها را شامل گردد. این پورتها می توانند از نوع VM یا VMkernel باشند. هر پورت با یک Port id نمایش داده می شود که مشخص کننده میزبان مرتبط با پورت، نوع پورت (Connectee) و جهت ارسال ترافیک می باشد. تنها استثنا در حالت Port Mirror نوع سوم است که یک یا چند VLAN می توانند بعنوان مبدأ ترافیک مورد استفاده قرار بگیرند.

مقصد یک نشست Port Mirror به نوع نشست وابسته است و یکی از موارد زیر را شامل می گردد:

نوع اول-Distributed Port Mirroring: پورتهای مجازی

نوع دوم-Remote Mirroring Source: پورتهای Uplink

نوع سوم-Remote Mirroring Destination: پورتهای مجازی

نوع چهارم-Encapsulated Remote Mirroring (L3) Source: آدرس IP

گزینه های استاندارد تنظیمات که برای انواع Port Mirroring یکسان است شامل موارد زیر می باشد:

Name: نام مشخص کننده یک نشست Port Mirroring می باشد.

Status: مشخص کننده وضعیت یک نشست Port Mirroring می باشد و امکان فعال سازی نشست را در هر زمان ممکن می سازد.

Session Type: مشخص کننده یکی از چهار حالت Port Mirroring می باشد.

Encapsulation VLAN ID: این شماره VLAN است که جهت ارسال بسته های Mirror به سمت Uplink مورد استفاده قرار می گیرد. در صورتیکه لازم باشد VLAN مبدأ بسته مورد استفاده قرار بگیرد باید گزینه Preserve Original VLAN فعال گردد.

گزینه های پیشرفته تنظیمات که به نوع Port Mirroring وابسته است شامل موارد زیر می گردد:

Normal I/O on destination ports: برای یک پورت که مقصد Port Mirroring می باشد این گزینه مشخص کننده این است که این پورت تنها میتواند دریافت کنند ترافیک باشد و تنها در عملیات Port Mirroring شرکت نماید (گزینه Disallowed) و یا امکان ارسال ترافیک نیز توسط آن وجود دارد.

Mirror packet length (Bytes): با استفاده از این گزینه میتوان سایز بسته های Mirror دریافتی را بر حسب نرم افزار مورد استفاده در مقصد بسته ها، تنظیم نمود. در صورت مواجهه با فریمهای با طول بیشتر، این فریمها شکسته شده و با اندازه مجاز ارسال خواهند شد.

با نتکو در سرور حرفه ای شوید  www.netco.biz

Sampling rate: نرخ نمونه گیری از داده جهت ارسال توسط این گزینه مشخص می گردد که مقدار ۱ پیش فرض بوده و تمامی بسته ها را در بر می گیرد. مقدار N مشخص می کند که از هر N بسته یک بسته کپی و ارسال شود.

Description: در این قسمت میتوان شرحی را از عملیات Port Mirroring وارد نمود.

با نتکو در سرور حرفه ای شوید  www.netco.biz

3. Private VLANs:

گاهی اوقات استفاده صرف از VLAN جوابگوی نیازهای شبکه ما نخواهد بود مثلاً تعداد VLAN های قابل استفاده محدود و حداکثر ۴۰۹۶ عدد می باشد در ضمن مکانیزمی جهت ایجاد امنیت در داخل یک VLAN وجود ندارد. جهت پاسخگویی به این نیازهای میتوان از Private VLAN استفاده کرد. Private VLAN را میتوان به مثابه یک خانه در نظر گرفت که افراد مختلف میتوانند در اتاقهای مجزا مستقر باشند. در ادامه به بیان مفاهیم مربوط به Private VLAN می پردازیم:

Primary VLAN: ساختار Private VLAN در داخل یک VLAN از نوع Primary شکل می گیرد.

Promiscuous VLAN: یک Primary VLAN میتواند از طریق یک یا چند VLAN از نوع Promiscuous VLAN یا P-Port به زیرساخت شبکه موجود متصل شود. بنابراین هر Private VLAN به یک Primary VLAN که دارای یک P-Port است احتیاج دارد تا با جهان خارج ارتباط برقرار نماید.

Secondary VLANs: تمامی VLANهای از نوع Secondary در داخل یک Primary VLAN قرار می گیرند و می توانند از شماره VLANهایی که در سایر نقاط شبکه وجود دارد نیز استفاده نمایند. جهت خ

روج ترافیک، شماره Tagهای مربوط به Secondary VLAN با شماره Tag مربوط به Primary VLAN جایگذین می شود. Secondary VLAN میتواند یک از سه نوع Promiscuous، Community و Isolated باشد.

Community VLANs: ماشینهای داخل این نوع VLAN قادر هستند با یکدیگر و همچنین با اعضای Promiscuous VLAN ارتباط داشته باشند در ضمن امکان انتقال ترافیک به Community VLANهای دیگر یا Isolated VLAN ها وجود ندارد.

Isolated VLAN: ماشینهای داخل این نوع VLAN کاملاً ایزوله بوده و ارتباط تنها میتواند با اعضای Promiscuous VLAN برقرار شود.

با نتکو در سرور حرفه ای شوید  www.netco.biz

v4. Traffic Shaping

منطق و مفاهیم مورد استفاده جهت کنترل ترافیک و ایجاد محدودیت بر روی پهنای باند در سوئیچ VDS مشابه با مفاهیم گفته شده برای سوئیچ استاندارد می باشد. تنها تفاوت موجود در این است که برای سوئیچ VDS علاوه بر ایجاد محدودیت بر روی ترافیک ورودی به سوئیچ که در سوئیچهای استاندارد نیز وجود دارد، میتوان بر ترافیک خارج شده از سوئیچ نیز محدودیت اعمال کرد. ترافیک خارج شده از سوئیچ می تواند به سمت پورت ماشینهای مجازی یا VM و یا بسمت پورتهای از نوع VMkernel باشد. بعنوان یکی از کاربردهای مهم محدودیت بر روی ترافیک خروجی، میتوان به سناریوهای مبتنی Multi-NIC vMotion اشاره کرد که در آن چندین میزبان اقدام به انتقال ماشینهای خود به سمت یک میزبان می نمایند. در این حالت تنها راه جلوگیری از پر شدن پهنای باند، کنترل نمودن ترافیک خروجی سوئیچ به سمت میزبان مقصد است.

با نتکو در سرور حرفه ای شوید  www.netco.biz

5. Load Balancing

یکی از قابلیتهای اضافه شده در VDS نسبت به سوئیچ استاندارد امکان توازن در بار مصرفی Uplinkها در سناریوهای مبتنی بر NIC-Teaming می باشد. در روشهای مورد استفاده در سوئیچ استاندارد نحوه استفاده پورتهای مجازی از Uplinkها غیرقابل تغییر بوده و ترافیک هر پورت تنها از یکی از پورتهای Uplink خارج می گردید. در سوئیچ VDS از روشی پویا تحت عنوان Load Based Teaming یا LBT استفاده می شود.

در سناریوی زیر از روش route based on originating virtual port ID جهت توازن بار استفاده شده که در نتیجه آن ترافیک ماشینهای ۱، ۲ و ۳ بر روی Uplink1 و ترافیک ماشینهای ۴و۵ بر روی Uplink2 قرار گرفته است، در این حالت چناچه ماشین شماره ۱ ترافیکی بیش از اندازه خود مصرف نماید ترافیک ماشینهای دیگر را نیز دچار اختلال می نماید:

برای حل این مشکل LBT ترافیک ماشینها را بر روی Uplinkهای مختلف مانیتور می نماید، چنانچه ترافیک یکی از Uplinkها در طی مدت ۳۰ ثانیه، از مقدار ۷۵درصد فراتر رود، LBT مطابق با شکل، ماشینهای با ترافیک کمتر را به Uplinkهای فعال دیگر منتقل می کند:

استفاده از LBT با محدودیتهای زیر مواجه است:

– یک پورت مجازی قادر نخواهد بود که از چندین Uplink بصورت همزمان استفاده کند بلکه ترافیک آن تنها از Uplink شلوغ به Uplink خلوت تر منتقل می شود.

– چنانچه ترافیکی از نوع Burst برای مدت زمان کمتر از ۳۰ ثانیه به پورتهای Uplink تحمیل گردد، LBT هیچگونه عکس العملی از خود نشان نخواهد داد.

با توجه به توصیفات ارائه شده بهترین حالت استفاده از LBT تعریف آن برای تعدادی ماشین مجازی خاص که دارای نیازهای ترافیکی و اولویتی متفاوتی هستند می باشد. بعنوان مثال میتوان دو Port Group یکی برنگ سبز با روش LBT برای ماشینهای حساس و دیگری برنگ نارجی با روش پیش فرض یرای سایر ماشینهای تعریف نمود، در این حالت انتقال Uplink تنها برای Port Group سبز رنگ اتفاق می افتد:

با نتکو در سرور حرفه ای شوید  www.netco.biz

6. Network I/O Control

با استفاده از قابلیت Network I/O Control یا NIOC میتوان کنترل بیشتری بر روی ترافیک مصرفی شبکه فراهم نمود. برای این منظور گروههای منابع شبکه یا Network Resource Pool ایجاد می شوند و ترافیک شبکه بر اساس اولویت کلاس بندی شده و به این منابع مرتبط می گردد. در ادامه میتوان برای این منابع محدودیت ترافیک، Tagهای QOS و همچنین مقادیر اشتراک ترافیک (Traffic Share) تعریف کرد.

برخی از تنظیمات قابل مشاهده شامل موارد زیر می گردد:

Physical Network Adapters: این گزینه تعداد Uplinkهای که توسط VDS مورد استفاده قرار گرفته را نشان می دهد، بعنوان مثال برای ۳ میزبان که هر یک دارای ۲ Uplink هستند مقدار نمایش داده شده برابر با ۶ خواهد بود.

Bandwidth capacity: مقدار سرعت تجمیع شده کلیه Uplinkهای متصل شده به DVS نمایش داده می شود. بعنوان مثال برای ۳ میزبان که هر یک دارای ۲ Uplink با سرعت ۱Gbps باشند، مقدار نمایش داده شده برای با ۶Gbps خواهد بود.

Network I/O Control: وضعیت فعال بودن قابلیت NIOC را نمایش می دهد که بصورت پیش فرض غیرفعال است.

Network Resource Pools

در NIOC بصورت پیش فرض تعداد ۸ گروه از پیش تعریف شده شامل موارد زیر وجود دارد:

• vMotion Traffic
• Fault Tolerance (FT) Traffic
• vSphere Replication (VR) Traffic
• iSCSI Traffic
• Management

Traffic

• NFS Traffic
• Virtual Machine Traffic
• vSphere SAN Traffic

برای هر یک از این منابع تنظیمات زیر قابل انجام می باشد:

Host Limit (Mbps): مقدار محدودیت پهنای باندی است که برای هر گروه بر حسب Mbps قابل اعمال می باشد. این محدودیت به ازای هر Uplink بصورت مجزا اعمال می گردد، بعنوان مثال چنانچه مقدار محدودیت برای یکی از گروهها ۲۰۰۰Mbps تعریف شده باشد و این گروه از Uplinkهای متعددی جهت خروج ترافیک استفاده نماید،  محدودیت اعمال شده به ازای هر Uplink، مقدار ۲۰۰۰Mbps خواهد بود!

Physical Adapter Shares: این تنظیمات جهت محاسبه اینکه هر گروه چند درصد از منابع شبکه یا Uplink را می توانند مطالبه و بصورت مشترک استفاده نمایند بکار می رود. مقادیر قابل تعریف شامل مقدار High (با مقدار Share حداکثر یا ۱۰۰)، مقدار Normal (با مقدار Share برابر با ۵۰)، مقدار Low (با مقدار Share برابر با ۲۵) و مقدار Custom (با مقدار Share قابل تنظیم) می باشد.

Shares Value: مقادیر Share برای انواع گروههای منابع را مشخص می نماید.

QoS Priority Tag: با استفاده از این فیلد میتوان مقادیر Tag مربوط به ۸۰۲٫۱p که برای QOS استفاده می شود را مشخص کرد. حداقل مقدار قابل تنظیم ۰ و حداکثر آن ۷ می باشد.

Shares

مقادیر Shares، نسبی بوده و مشخص کننده مقدار ترافیک نیستند، در ضمن تنها در زمانی مورد استفاده قرار می گیرند که پورتهای Uplink اشباع شده باشند. زمانیکه پورتهای Uplink اشباع شوند، دو موضوع توسط NIOC مورد بررسی قرار می گیرد:اول اینکه مقادیر Shares چگوننه تنظیم شده و دوم اینکه کدام گروه منابع شبکه برای هر Uplink مورد استفاده قرار گرفته است. بعنوان مثال در شکل زیر، NIOC برای هر دو Uplink فعال شده و Uplink1 بعنوان Active Uplink برای Port Groupهای FT و Mgmt و Uplink2 بعنوان Active Uplink برای Port Groupهای VMs و vMotion تعریف گردیده اند:

چنانچه Uplink1 اشباع شده باشد NIOC با بررسی متوجه می شود که Uplink1 دارای پهنای باند ۱Gbps بوده و بعنوان Active Uplink برای دو Port-group یعنی  FT و Mgmt تعریف شده است. مجموع Sharesهای این دو گروه برابر با ۱۰۰بوده و هر گروه ۵۰ درصد از پهنای باند یعنی ۵۰۰Mbps را از آن خود خواهند کرد.

چنانچه Uplink2 اشباع شده باشد NIOC با بررسی متوجه می شود که Uplink1 دارای پهنای باند ۱Gbps بوده و بعنوان Active Uplink ببرای دو Port-group یعنی VMs و vMotion تعریف شده است. مجموع Sharesهای این دو گروه برابر با ۱۵۰ بوده بنابراین ۶۶٫۷ درصد از پهنای باند (۶۶۷Mbps) به گروه VMs و ۳۳٫۳ درصد از پهنای باند (۳۳۷Mbps) به گروه vMotion اختصاص داده خواهد شد. تکته قابل توجه اینکه تسهیم ترافیک تنها در صورتی صورت می گیرد که هر دو گروه فعلانه جهت بدست آوردن پهنای باند با یکدیگر رقابت نمایند، بعبارت دیگر چنانچه گروه vMotios مصرفی برای پهنای باند نداشته باشد، گروه VMs قادر خواهد بود از ۱۰۰ درصد پهنای باند موجود استفاده نماید.

User-Defined Network Resource Pools

گروهای منابع پیش فرض را نمیتوان حذف کرد، ولی امکان تعریف یک گروه جدید برای Port Group های موجود نیز وجود دارد. بعنوان مثال چنانچه یک گروه جدید برای یک Port Group مربوط به ماشینهای مجازی تعریف شود، محدودیت ترافیک مطابق با تنظیمات آن گروه صورت خواهد گرفت. از طرف دیگر چنانچه پورتهای یک ماشین مجازی در گروه تعریف شده قرار نداشته باشند نحوه مصرف ترافیک مطابق با گروه پیش فرض VMs خواهد بود.

با نتکو در سرور حرفه ای شوید  www.netco.biz

7. Other Features:

امکانات ذکر شده قابلیتهای عمده ای بود که با استفاده از سوئیچ DVS بدست می آید. در ادامه به برخی از بهبودهای دیگر که در نتیجه استقاده از DVS حاصل می گردد، اشاره شده است:

VLAN Tags

سوئیچ استاندارد و VDS در ESXi از هر سه مدل تگ یعنی EST، VST و VGT پشتیبانی می کنند، تنها تفاوت موجود در نحوه پشتیبانی این سوئیچها برای حالت VGT می باشد. چناچه در مستند مربوط به سوئیچنگ مجازی توضیح داده شده در حالت VGT، تگ مربوط به VLAN از طریق کارت شبکه ماشین مجازی مستقر در میزبان ESXi ایجاد می شود و سوئیچ مجازی امکان عبور فریمهای دارای تگ را به سوئیچ فیزیکی فراهم می نماید. در سوئیچ استاندارد با تنظیم VLAN id=4095 امکان عبور فریمهای حالت VGT فراهم می شود و سوئیچ مجازی تنها نظاره گر ارتباط خواهد بود. این در حالیست که در سوئیچ VDS گزینه ای مجزا جهت فعالسازی حالت VGT وجود دارد علاوه بر آن امکان مشخص نمودن VLANهایی که اجازه عبور دارند نیز میسر می باشد.

LACP

در سوئیچ استاندارد ساختن Port-Channel تنها بصورت ایستا یا ON Mode امکان پذیر می باشد، هر گونه اشتباه در تنظیمات بر روی سوئیچ فیزیکی یا مجازی ممکن است پروسه STP و درنتیجه ارتباطات شبکه را دچار اختلال نماید، این درحالیست که در سوئیچ DVS امکان انجام مذاکره مابین دو سوئیچ با استفاده از پ

روتکل LACP قبل از ساختن Port-Channel وجود دارد، لذا یا Port-Channel تشکیل می شود و یا پورتها بصورت عادی در پروسه STP مشارکت خواهند کرد. نکته دیگر اینکه در LACP امکان تعریف روش Load-Balancing بر اساس معیارهای پیچیده تر نظیر آدرسهای MAC، IP و Port نیز وجود دارد.

Per Port policy setting

در سوئیچ استاندارد امکان اعمال پالیسی در سطح سوئیچ و Port Group وجود دارد، در سوئیج VDS علاوه بر موارد ذکر شده امکان اعمال پالیسی در سطح پورت نیز وجود دارد.

Multicast Snooping

در سوئیچ VDS امکان فعال سازی IGMP Snooping در IPv4 و یا MLD Snooping در IPv6 جهت هدایت بسته های از نوع Multicast به پورتها بر اساس گروه IGMP/MLD وجود دارد.در این حالت امکان دریافت ترافیک از ۱۰ منبع یا ۲۵۶ گروه مختلف توسط ماشین مجازی وجود خواهد داشت.