با سلام در ادامه مقالات Networking مربوط به Standard Switch بخش اول نوبت به بررسی NIC Teaming and Failover میرسه که قرار است در این مقاله بصورت کامل به بررسی این موضوع بپردازیم. این موضوع قطعا برای کسانی که خیلی با مباحث Virtualization هم آشنا نیستند خیلی مفهوم غربیه ای نیست، چونکه این ویژگی یا بهتر بگم این امکان در تمام جنبه شبکه بوده و فقط مربوط به مجازی سازی نمیباشد. به ترکیب چندین کارت شبکه NIC reaming میگویند، که برای دو دلیل اصلی از این امکان ما استفاده میکنیم :
Redundancy
به این معنی که اگر یکی از کارت شبکه های سرور از کار بیوفتد بلافاصله ترافیک های ارسالی و دریافتی از کارت شبکه های دیگر منتقل شوند، که یکجور تحمل خطا میباشد.
Load Balancing
به این مفهوم که یک load distributed اتفاق بیوفتد و ارسال و دریافت ترافیک بین کارت شبکه ها پخش شود که باعث میشد در یک کارت شبکه Bottleneck اتفاق نیوفتد.
این، دو دلیل استفاده از گروه کردن چندین کارت شبکه با هم بوده که VMware هم از این امکان در سوییچ های خودش استفاده میکند که شامل چندین نوع بوده که در ادامه به بررسی آن ها خواهیم پرداخت.
برای انجام تنظیمات مربوط به NIC teaming and failover وارد تنظیمات Switch شده و سپس منوی Teaming and failover را انتخاب میکنیم.
اولین بخش Load balancing بوده، که شما 4 انتخاب دارید. نکته مهم در سوییچ های از نوع Distributed شما یک انتخاب بیشتر دارید که در مباحث Distributed Switch با هم بررسی خواهیم کرد.
Route based on the originating port ID
این گزینه به عنوان انتخاب پیش فرض بود و پیاده سازی بسیار ساده ای داشته و نیاز به تغییر در Device های فیزیکی نیست. هر ماشین مجازی و VMKernel برای متصل شدن به سوییچ نیاز به یک port دارد که هر پورت یک ID داشته که این اختصاص دادن port در standard switch ها بر عهده esxi بوده. وقتی یک پورت به یک ماشین مجازی اختصاص داده شد و برای بار اول یک ترافیک از سمت ان port به سمت switch ارسال شد یک Uplink به این port id اختصاص داده میشود و ترافیک ها فقط از این Uplink ارسال خواهد شد. Uplink انتخاب شده تغییر نخواهد کرد مگر اینکه آن Uplink به هر دلیلی fail شود یا ماشین بر روی یک سرور دیگر Migrate شود و حتی با خاموش و روشن شدن ماشین هم امکان تغییر Uplink باشد.
برای درک بهتر فرض کنید بر روی سرور شما دو عدد Uplink بوده و 3 تا ماشین مجازی و هر دو تا Uplink به vSwitch0 متصل شده است و هر سه ماشین هم به همین سوییچ. ( اتفاقی که میوفتد این بوده که ترافیک ماشین اول ("میره سمت Uplink یک" ته جمله رو نبسته بودی، بهتره از این عبارت استفاده کنی"به سمت uplink شماره یک میرود") به سمت uplink شماره یک میرود، ترافیک ماشین دوم ("میره سمت Uplink دوم" جایگزین با "به سمت uplink شماره دو میرود") به سمت uplink شماره دو میرود، ترافیک ماشین سوم مجدد به سمت uplink شماره یک میرود، و به همین شکل ادامه خواهد یافت.
Route based on IP hash
روش سوم که بر اساس Source و Destination آی پی آدرس کار میکند یک جورایی Load distributed بهتری را برای ما پیاده سازی میکن اما نیاز به پردازش بیشتر دارد چون عمل Hash را انجام میدهد. بر خلاف موارد اول و دوم برای پیاده سازی نیاز به تغییر Device فیزیکی بوده باید از Etherchannel در سوییچ های فیزیکی استفاده کرد اما خوب Distributed بهتری را در اختیار ما قرار میدهد.
Use explicit failover order
این گزینه عمل Distributed را برای ما انجام نمیدهد بلکه فقط Failover را برای ما پیاده سازی میکند آن هم بصورت Active/Standby. برای مثال فرض کنید سرور شما دو تا کارت شبکه دارید کاری که شما انجام میدهید در این سناریو یکی از Uplink ها را در حالت Active و دیگری را در حالت Standby قرار داده تا در زمانی که Uplink اول از کار افتاد، بلافاصله دومی در حالت Active قرار گرفته و شروع به ارسال و دریافت ترافیک خواهد کرد.
بعد از بررسی موارد مربوط به load balancing سراغ بخش دوم که شامل دو انتخاب بوده میرویم که در ادامه با هم بررسی خواهیم کرد.
Network Failover Detection
شامل دو انتخاب بوده :
Link Status only
بوسیله این گزینه شما فقط امکان Detect کردن خطاهای در سطح لایه یک را خواهید داشت، خطاهایی از قبیل قطع شدن کابل شبکه همچنین از کار افتادن سوییچ متصل به سوییچ مجازی. اما شما قادر نخواهید بود تا خطاهای مربوط به اشتباه کانفیگ مانند Vlan و موارد دیگر را Detect کنید. یا حتی قادر نخواهید بود که خراب شدن سوییچ ها بالا دستی را تشخیص دهید. مثلا فرض کنید که شما یک بسته اطلاعاتی ارسال میکنید، بسته اطلاعاتی شما به سوییچی که به صورت مستقیم به Standard Switch متصل است ارسال میشود اما بسته شما از سوییچ دومی عبور نخواهد کرد چون پورتی که سوییچ اول را به سوییچ دوم متصل کرده در حالت Shutdown بوده اما Standard Switch این مشکل را Detect نخواهد کرد چون سوییچ اول از لحاظ لایه اول مشکلی نداشته و Standard Switch فکر میکند همه چیز بدون مشکل در حال کار بوده.
Beacon Probing
برای حل مشکل Link Status only میتوانیم از Beacon Probing استفاده کنیم.نحوه کار به اینصورت بوده که یک پیام از نوع Beacon probing از طریق Uplink ها ارسال میشود و اگر پیام جواب از Uplink های دیگر دریافت شد به این نتیجه میرسیم که مشکلی برای Uplink اتفاق افتاده چون جواب پیام Beacon probing توسط Uplink های دیگر دریافت نشد. نکته مهم این بوده که این روش تمام ضعف های روش اول را پوشش داده و خطاهای Configuration و سوییچ های بعدی را تشخیص خواهد داد. برای پیاده سازی Beacon probing به حداقل سه uplink نیاز است.در ادامه به بررسی موارد باقی مانده خواهیم پرداخت.
Notify Switches
بوسیله این قابلیت شما میتوانید مواردی مانند متصل شدن یک ماشین به سوییچ همچنین اضافه شدن کارت شبکه ای به ماشین مجازی و حتی غیر فعال شدن Uplink های سرور را به سوییچ های فیزیکی Notify کنید.
Failback
اگر شما از حالت Active/Standby استفاده میکنید و Uplink شما که در حالت Active بود به هر دلیلی از کار افتاد Uplink موجود در بخش Standby جایگزین آن خواهد شد. با قرار دادن Yes برای این گزینه اتفاقی که میوفتد این است که، بعد از دوباره فعال شدن Uplink که قبلا در حالت Active بوده بلافاصله دوباره به حالت Active در اماده و Uplink دومی دوباره به حالت Standby در خواهد افتاد.
Failover Order
اخرین انتخاب در بخش Load Balancing مربوط به Use explicit failover order که در حالت Active/Standby کار میکند. در این بخش مشخص میکنید که کدام Uplink در کدام حالت قرار خواهد گرفت که در ادامه سه حالت را بررسی خواهیم کرد.
Active Adapters
Uplink ها در این حالت در حالت فعال بوده و برای input/output ترافیک استفاده میشود.
Standby Adapters
Uplink ها در این بخش در حالت Standby بوده تا اینکه Active Adaptor ها به هر دلیلی از کار بیوفتند.
Unused Adapters
Uplink ها در این بخش در حالت غیر فعال بوده.
امیدوارم مفید واقع شده باشد.
Redundancy
به این معنی که اگر یکی از کارت شبکه های سرور از کار بیوفتد بلافاصله ترافیک های ارسالی و دریافتی از کارت شبکه های دیگر منتقل شوند، که یکجور تحمل خطا میباشد.
Load Balancing
به این مفهوم که یک load distributed اتفاق بیوفتد و ارسال و دریافت ترافیک بین کارت شبکه ها پخش شود که باعث میشد در یک کارت شبکه Bottleneck اتفاق نیوفتد.
این، دو دلیل استفاده از گروه کردن چندین کارت شبکه با هم بوده که VMware هم از این امکان در سوییچ های خودش استفاده میکند که شامل چندین نوع بوده که در ادامه به بررسی آن ها خواهیم پرداخت.
برای انجام تنظیمات مربوط به NIC teaming and failover وارد تنظیمات Switch شده و سپس منوی Teaming and failover را انتخاب میکنیم.
اولین بخش Load balancing بوده، که شما 4 انتخاب دارید. نکته مهم در سوییچ های از نوع Distributed شما یک انتخاب بیشتر دارید که در مباحث Distributed Switch با هم بررسی خواهیم کرد.
Route based on the originating port ID
این گزینه به عنوان انتخاب پیش فرض بود و پیاده سازی بسیار ساده ای داشته و نیاز به تغییر در Device های فیزیکی نیست. هر ماشین مجازی و VMKernel برای متصل شدن به سوییچ نیاز به یک port دارد که هر پورت یک ID داشته که این اختصاص دادن port در standard switch ها بر عهده esxi بوده. وقتی یک پورت به یک ماشین مجازی اختصاص داده شد و برای بار اول یک ترافیک از سمت ان port به سمت switch ارسال شد یک Uplink به این port id اختصاص داده میشود و ترافیک ها فقط از این Uplink ارسال خواهد شد. Uplink انتخاب شده تغییر نخواهد کرد مگر اینکه آن Uplink به هر دلیلی fail شود یا ماشین بر روی یک سرور دیگر Migrate شود و حتی با خاموش و روشن شدن ماشین هم امکان تغییر Uplink باشد.
برای درک بهتر فرض کنید بر روی سرور شما دو عدد Uplink بوده و 3 تا ماشین مجازی و هر دو تا Uplink به vSwitch0 متصل شده است و هر سه ماشین هم به همین سوییچ. ( اتفاقی که میوفتد این بوده که ترافیک ماشین اول ("میره سمت Uplink یک" ته جمله رو نبسته بودی، بهتره از این عبارت استفاده کنی"به سمت uplink شماره یک میرود") به سمت uplink شماره یک میرود، ترافیک ماشین دوم ("میره سمت Uplink دوم" جایگزین با "به سمت uplink شماره دو میرود") به سمت uplink شماره دو میرود، ترافیک ماشین سوم مجدد به سمت uplink شماره یک میرود، و به همین شکل ادامه خواهد یافت.
Route based on IP hash
روش سوم که بر اساس Source و Destination آی پی آدرس کار میکند یک جورایی Load distributed بهتری را برای ما پیاده سازی میکن اما نیاز به پردازش بیشتر دارد چون عمل Hash را انجام میدهد. بر خلاف موارد اول و دوم برای پیاده سازی نیاز به تغییر Device فیزیکی بوده باید از Etherchannel در سوییچ های فیزیکی استفاده کرد اما خوب Distributed بهتری را در اختیار ما قرار میدهد.
Use explicit failover order
این گزینه عمل Distributed را برای ما انجام نمیدهد بلکه فقط Failover را برای ما پیاده سازی میکند آن هم بصورت Active/Standby. برای مثال فرض کنید سرور شما دو تا کارت شبکه دارید کاری که شما انجام میدهید در این سناریو یکی از Uplink ها را در حالت Active و دیگری را در حالت Standby قرار داده تا در زمانی که Uplink اول از کار افتاد، بلافاصله دومی در حالت Active قرار گرفته و شروع به ارسال و دریافت ترافیک خواهد کرد.
بعد از بررسی موارد مربوط به load balancing سراغ بخش دوم که شامل دو انتخاب بوده میرویم که در ادامه با هم بررسی خواهیم کرد.
Network Failover Detection
شامل دو انتخاب بوده :
Link Status only
بوسیله این گزینه شما فقط امکان Detect کردن خطاهای در سطح لایه یک را خواهید داشت، خطاهایی از قبیل قطع شدن کابل شبکه همچنین از کار افتادن سوییچ متصل به سوییچ مجازی. اما شما قادر نخواهید بود تا خطاهای مربوط به اشتباه کانفیگ مانند Vlan و موارد دیگر را Detect کنید. یا حتی قادر نخواهید بود که خراب شدن سوییچ ها بالا دستی را تشخیص دهید. مثلا فرض کنید که شما یک بسته اطلاعاتی ارسال میکنید، بسته اطلاعاتی شما به سوییچی که به صورت مستقیم به Standard Switch متصل است ارسال میشود اما بسته شما از سوییچ دومی عبور نخواهد کرد چون پورتی که سوییچ اول را به سوییچ دوم متصل کرده در حالت Shutdown بوده اما Standard Switch این مشکل را Detect نخواهد کرد چون سوییچ اول از لحاظ لایه اول مشکلی نداشته و Standard Switch فکر میکند همه چیز بدون مشکل در حال کار بوده.
Beacon Probing
برای حل مشکل Link Status only میتوانیم از Beacon Probing استفاده کنیم.نحوه کار به اینصورت بوده که یک پیام از نوع Beacon probing از طریق Uplink ها ارسال میشود و اگر پیام جواب از Uplink های دیگر دریافت شد به این نتیجه میرسیم که مشکلی برای Uplink اتفاق افتاده چون جواب پیام Beacon probing توسط Uplink های دیگر دریافت نشد. نکته مهم این بوده که این روش تمام ضعف های روش اول را پوشش داده و خطاهای Configuration و سوییچ های بعدی را تشخیص خواهد داد. برای پیاده سازی Beacon probing به حداقل سه uplink نیاز است.در ادامه به بررسی موارد باقی مانده خواهیم پرداخت.
Notify Switches
بوسیله این قابلیت شما میتوانید مواردی مانند متصل شدن یک ماشین به سوییچ همچنین اضافه شدن کارت شبکه ای به ماشین مجازی و حتی غیر فعال شدن Uplink های سرور را به سوییچ های فیزیکی Notify کنید.
Failback
اگر شما از حالت Active/Standby استفاده میکنید و Uplink شما که در حالت Active بود به هر دلیلی از کار افتاد Uplink موجود در بخش Standby جایگزین آن خواهد شد. با قرار دادن Yes برای این گزینه اتفاقی که میوفتد این است که، بعد از دوباره فعال شدن Uplink که قبلا در حالت Active بوده بلافاصله دوباره به حالت Active در اماده و Uplink دومی دوباره به حالت Standby در خواهد افتاد.
Failover Order
اخرین انتخاب در بخش Load Balancing مربوط به Use explicit failover order که در حالت Active/Standby کار میکند. در این بخش مشخص میکنید که کدام Uplink در کدام حالت قرار خواهد گرفت که در ادامه سه حالت را بررسی خواهیم کرد.
Active Adapters
Uplink ها در این حالت در حالت فعال بوده و برای input/output ترافیک استفاده میشود.
Standby Adapters
Uplink ها در این بخش در حالت Standby بوده تا اینکه Active Adaptor ها به هر دلیلی از کار بیوفتند.
Unused Adapters
Uplink ها در این بخش در حالت غیر فعال بوده.
امیدوارم مفید واقع شده باشد.