آموزش Standard vSwitch در Vmware Vsphere – بخش سوم
برای مطالعه بخش دوم آموزش Standard vSwitch در Vmware Vsphere اینجا کلیک کنید.
در این قسمت ادامه ی تنظیمات Standard Switch ها را جلو خواهیم برد. در ادامه ی مطالب قبل به بخش Teaming and Failover رسیدیم.
در این قسمت شما میتوانید برای یک سوییچ بیش از یک Uplink داشته باشید. دلیل اینکه برای سوییچ مان بیشتر از یک Uplink داشته باشیم مشخص است. ما نمیخواهیم Single Point of Failure داشته باشیم که اگر یکی از Uplink های ما به هردلیلی Fail شد Uplink دیگر باشد و ترافیک از طریق آن به بیرون ارسال شود و دچار قطعی نشویم. در هر زمینه ای باید Redundancy وجود داشته باشد. همانطور که در تصویر زیر مشاهده میکنید vSwitch1 ما یک Uplink بیشتر ندارد و اگر این یک Uplink قطع شود عملا ترافیک Networking ای به بیرون دچار مشکل میشود:
ما درابتدا برای این سوییچ یک Uplink دیگر در نظر میگیریم و سپس دوباره به قسمت Teaming and Failover برمیگردیم و تنظیمات را بررسی میکنیم. چون تمام تنظیمات این قسمت به همین قضیه برمیگردد. به ESX میرویم و یک کارت شبکه ی دیگر اضافه میکنیم.
سیستم را Restart میکنیم تا این کارت شبکه را شناسایی کند. همانطور که در تصویر زیر مشاهده میکنید کارت شبکه ی سوم اضافه شده است. روی ESX دیگر همین کار را انجام میدهیم و یک کارت شبکه ی دیگر اضافه میکنیم:
ما حالا میخواهیم این vmnic2 که اضافه شده است به عنوان یک Uplink دوم برای vSwitch1 داشته باشیم. این کار را مطابق با تصویر زیر انجام میدهیم:
یک کارت شبکه ی موجود که Uplink هست را میبینیم و روی + کلیک میکنیم و دومی هم اضافه میکنیم.
حالا همانطور که میبینید شد دوتا Uplink:
حالا دوباره به بخش تنظیمات برمیگردیم و همانطور که مشاهده میکنید در قسمت Active Adapter دوتا کارت شبکه داریم. مفهوم آن این است که تمامی ترافیک هایی که قرار است از این سوییچ به بیرون ارسال شود میتواند از vmnic1 یا از vmnic2 به بیرون ارسال شود.
وقتی قرار است ترافیک از هر دو کارت شبکه به بیرون ارسال شود اینکار بر چه اساسی انجام میشود؟Load Balancing بر چه اساسی انجام میشود؟ پس از Dropdown Menu ی اول که مربوط به Load Balancing است شروع میکنیم.
به طور کلی بخش Teaming and Failover برای زمانی است که ما بیش از یک کارت شبکه Uplink داریم. اولین مورد که به صورت Default هم Load Balancing روی همان قرار دارد Route Based on Originate virtual port است. خب هر سوییچ مجازی تعدادی پورت دارد و هر VM ای که به آن وصل میشود در حقیقت به یکی از پورت های آن متصل میشود. این گزینه تعیین میکند بر اساس پورت های مجازی ای که روی سوییچ هست Load Balancing انجام دهد. مثلا VM هایی که به پورت های زوج متصل شده اند را از Uplink ئه vmnic1 خارج کند و آنهایی که به پورت های فرد متصل شده است از vmnic2. یعنی بر اساس شماره ی پورت این کارها را انجام دهد.
گزینه ی دیگر Route Based on Source MAC hash است.
فرض کنید که 10 تا VM به این سوییچ متصل هستند. هر کدام از این VM ها هم یک MAC دارند. در زمانی که شما برای سوییچ خود دوتا Uplink داشته باشید این روش Source MAC سیستم را در نظر میگیرد و یک بیت آخر برایش مهم میشود. یک بیت خودش میتواند دو حالت داشته باشد: صفر یا یک. حالا این روش بیت آخر Source MAC را در نظر میگیرد، اگر صفر بود از Uplink1 و اگر یک بود از Uplink2 ترافیک را بیرون میفرستد. اگر دقیق بیان کنیم از XOR بیت آخر Uplink ها تصمیم میگیرد که از کدام پورت بفرستد بیرون.حالا مثلا اگر تعداد Uplink ها بیشتر شدند مثلا به جای 2 تا 4 تا داشتیم. به جای یک بیت دو بیت را در نظر میگیرد. پس بسته به تعداد Uplink ها تعداد بیت های آخر مهم میشود.
چه در این حالت چه در حالت قبل یکی از vmnic1 بیرون میرود و یکی از vmnic2 و فقط متد آن فرق میکند. اما یک متد دیگر وجود دارد که بهترین حالت است:
این حالت Route Based on IP hash است. این متد یک حالتی را محاسبه میکند که VM شما با توجه به این که قرار است با چه IP Address ای در Destination ارتباط برقرار کند Uplink اش متفاوت باشد. این بهترین حالت Load Balancing است.
اما نکته ای که وجود دارد این است وقتی این گزینه را انتخاب میکنیم علامت Warning ظاهر میشود:
نکته این است که اگر شما این گزینه را انتخاب میکنید باید توجه داشته باشید که این Uplink ها که به سوییچ فیزیکی خورده، روی سوییچ فیزیکی آن پورت ها باید EtherChannel بشوند. یعنی اگر سمت سوییچ فیزیکی را Etherchannel نکنیم دچار مشکل میشویم. چرا؟ همانطور که میدانید سوییچ نمیتواند روی دوتا پورت یک MAC را Learn کند زیرا در این شرایط MAC Flapping رخ میدهد. اینجا هم همین قضیه پیش می آید، وقتی ما این گزینه را انتخاب میکنیم یک VM امکانش هست که یک سری ترافیکش را از یک پورت بیرون بفرستد (vmnic1) و یک سری ترافیکش را از پورت دیگر (vmnic2).آن وقت سوییچ فیزیکی روی دوتا پورت یک MAC را میبیند. مثلا VM ئه File Server ما یک سری ترافیک را از vmnic1 به بیرون ارسال میکند و سوییچ این را Learn میکند که مثلا پشت vmnic1، File Server نشسته است و سپس VM ئه File Server یک سری ترافیک را از vmnic2 به بیرون ارسال میکند که در اینجا برای سوییچ MAC Flapping رخ میدهد، زیرا سوییچ فیزیکی روی پورت دوم دوباره همان MAC ئه File Server را Learn کرده است. برای اینکه جلوی این مشکل گرفته شود باید روی پورت های سوییچ فیزیکی Etherchannel را راه اندازی کنیم. حالا Warning ای هم که در بالا نمایش میدهد همین را میگوید که روی سوییچ فیزیکی Etherchannel را فعال کنید:
اما آخرین موردی که میخواهیم بررسی کنیم :
اگر ما vSwitch را روی این حالت قرار دهیم دیگر Load Balancing نخواهیم داشت. این حالت این را که همه ی ترافیک را از vmnic1 بیرون بفرست و اگر vmnic1 ، Down شد از vmnic2 بیرون بفرست. اگر vmnic2 هم Down شد از vmnic3 بفرست بیرون و به همین صورت تا آخر میرود. همچنین با استفاده از فلش هایی که بالای Active Adapter هست میتوانیم تقدم و تاخیرشان را مشخص کنیم.
تمام ترافیک از vmnic2 بیرون برود و اگر نبود از vminc1. اما این حالت را معمولا استفاده نمیکنیم و معمولا یکی از سه حالت قبل را استفاده میکنیم و در بهترین شرایط هم IP hash را استفاده میکنیم.
اما نکته ی آخر این است که از بین دو مورد زیر کدام بهتر است؟
حالت Source MAC hash بهتر است زیرا کمی داینامیکتر خواهد بود. اما این را هم باید در نظر داشته باشید که این حالت کمی سیکل CPU سیستم را بالا خواهد برد.اما بخش بعدی که میخواهیم بررسی کنیم Network Failure detection میباشد.
در این قسمت میخواهیم تکنیکی را انتخاب کنیم که VMware از طریق آن بفهمد که از کدام یکی از این Uplink هایی که اینجا هستند میشود استفاده کرد.
یعنی vSwitch ئه VMware باید همواره چک کند که این Uplink ها همواره در دسترس و UP هستند که بتواند ترافیک را از آن ها بیرون بفرستد. برای اینکار دوتا تکنیک وجود دارد:
حتما تا به حال دیده اید وقتی کابل شبکه را به پشت کارت شبکه وصل میکنید یک چراغی پشت کارت شبکه روشن میشود. در حقیقت به این صورت است که وقتی شما کارت شبکه را وصل میکنید یک سیگنالی روی خط به اسم Carrier Signal به وجود می آید که ولتاژ خیلی پایینی هم دارد که کارت شبکه را روشن میکند. وقتی شما این حالت را انتخاب میکنید اگر سیگنال Carrier روی خط هست پس خط وصل است. اگر هم بفهمد که سیگنال Carrier وجود ندارد Detect میکند که ارتباط کارت شبکه قطع شده است و دیگر ترافیک را از آن به بیرون ارسال نمیکند و سعی میکند این کار را از طریق باقی vmnic ها انجام دهد. اما این حالت خیلی ساده است زیرا شرایطی پیش می آید که ممکن است چراغ Link Status روشن باشد اما در حقیقت ارتباط قطع باشد. برای مثال ممکن است شرایط زیر یا مشابه شرایط زیر رخ دهد:
این درسته که ارتباط vmnic0 با سوییچ اول UP است اما ارتباط سوییچ اول با سوییچ دوم، Down شده و در کل این Link از VM تا مقصد قطع است. یعنی ارسال ترافیک از این Uplink ئه vmnic0 بیهوده است. در این حالت دیگر Link Status Only نمیتواند Detect کند. اگر شما میخواهید کل مسیر را چک کنید که ارتباط برقرار است یا نه باید حالت Beacon probing را انتخاب کنید:
پس این روش بهتری است که وضعیت خط را چک کنیم. فقط نکته ی مهمی که وجود دارد این است که برای راه اندازی Beacon Probing شما به حداقل سه تا Uplink نیاز دارید. مثلا یکی باید نقش witness را داشته باشد . به سراغ بخش بعدی یعنی Notify Switches میرویم:
تصور کنید که ما ترافیک ها را از vmnic1 و vmnic2 به بیرون ارسال میکردیم. فرض کنید به هر دلیلی ما یکی از این کارت شبکه ها را Move Down کنیم و آن را Unuse کنیم و به سوییچ بگوییم برای ارسال دیگر از این vmnic استفاده نکند:
سناریو زیر را نگاه کنید:
اتفاقی که می افتد به این ترتیب است که این سوییچ یک سری MAC ها را از پورتی که به vmnic2 وصل بوده Learn کرده است. یعنی یک سری از VM ها که ترافیکشان از vmnic2 خارج میشده MAC شان روی پورت fa0/2 سوییچ Learn شده است.حالا تعیین کردید پورت vmnic2 دیگر استفاده نشود. اتفاقی که می افتد این است که سوییچ فیزیکی زیر پورت vmnic2 یک سری MAC را Learn کرده و قرار است که از این به بعد vSwitch این ترافیک ها را از vmnic1 بیرون بفرستد و سوییچ هم آن ها را روی پورت fa0/1 دریافت کند. از طرفی هم میدانیم که سوییچ زیر دو پورت نمیتواند یک MAC را Learn کند. پس دوباره به مشکل MAC Flapping رسیدیم.
این گزینه ی Notify Switches اگر روی حالت Yes باشد یعنی اینکه وقتی یک Uplink، Unuse میشود برو به سوییچ فیزیکی اعلام کن که هرچیزی زیر این پورت vmnic2 که حالا unuse شده یاد گرفتی Flush کن. یعنی از حافظه پاک کن.
بدین ترتیب دیگر سوییچ دچار MAC Flapping نخواهد شد. اما مورد آخر Failback است. فرض کنید که vSwitch را روی حالات زیر تنظیم کرده اید:
این حالتی است که میگوید ترافیک ها از vmnic1 بیرون برود و اگر قطع شد از vmnic2. حالا تصور کنید که vmnic1، Down میشود و ترافیک ها از vmnic2 به بیرون میروند. اما بعد از مدتی ما مشکل vmnic1 را حل کرده ایم و vSwitch میتواند از طریق vmnic1 دوباره همه ی ترافیک را به بیرون ارسال کند. Failback میگوید میخواهید بعد از UP شدن مجدد vmnic1 میخواهید دوباره همه ی ترافیک را روی vmnic1 بندازم و دوباره vmnic2 را standby نگه دارم که اگر vmnic1 قطع شد از آن استفاده کنم؟ اگر Failback روی Yes باشد دقیقا همین اتفاق می افتد. اما اگر روی No باشد دیگر از vmnic1 استفاده نمیکند و از vmnic2 استفاده میکند. چون شما احتمالا بر یک اساسی Order های vmnic هایتان را تعریف کرده اید بهتر است این حالت روی Yes باشد. در کل هم روی این مورد Failback خیلی بحث نمیکنیم چون معمولا از این نوع متد Load Balancing استفاده نمیکنیم و دوست داریم همه کارت شبکه هامون درگیر باشند.
به عنوان آخرین نکته در این پارت میگوییم که میتوانید برای هر vSwitch میتوانید تا 8 تا Uplink داشته باشید.
نویسنده:مهندس محمد آجورلو
pingback آموزش راه اندازی SAN و ارتباط با ESXi بخش اول - گروه آموزشی AdminPro
pingback آموزش راه اندازی NAS و ارتباط با ESXi بخش اول - گروه آموزشی AdminPro
pingback آموزش مفاهیم اولیه Storage - گروه آموزشی AdminPro