Network Failure Detection
Network Failure Detection
در این قسمت از آموزش قصد داریم به چگونگی موارد زیر بپردازیم:
• اینکه VSS به چه صورت خراب یا fail شدن یکی از کارت شبکه های فیزیکی (pNIC ها) را تشخیص می‌دهد و با چه روش هایی می‌توان این را تشخیص داد.
• و اینکه اگر زمانی کارت شبکه فیزیکی از بین رفت، MAC table سوئیچ فیزیکی (pSwitch) در چه شرایطی قرار می‌گیرد، آیا VSS از بابت اینکه کدام vNIC پشت کدام یک از pNIC ها قرار گرفته، به سوئیچ فیزیکی اطلاعی می‌دهد یا نه؟!
در ابتدا نگاهی گذرا به تنظیمات مربوط به Network Failure Detection کرده و سپس به توضیحات آن می‌پردازیم. برای این منظور وارد ESXI شده و بر روی یکی از VSS های مورد نظر Edit settings را می‌زنیم.
سپس از بخش NIC teaming، می‌توان تنظیمات مربوط به Network failover detection را مشاهده کرد که شامل دو گزینه link status only و Beacon only می‌باشد.
می‌خواهیم موارد استفاده از این گزینه ها و اینکه چه مواقعی باید آن ها را در حالت on یا off قرار دهیم را یاد بگیریم، به خصوص زمانی که در داخل سوئیچ از چندین کارت شبکه فیزیکی استفاده می‌کنیم (بحث teaming). (البته فرقی ندارد که گزینه load balancing بر روی کدام یک از حالت های Port-ID، MAC و IP hash باشد.)
Link status only
حالت Link status only
اولین حالتی که برای گزینه Network Failure Detection وجود دارد، link status only است. با قرار دادن در این حالت ، هر کدام از کارت شبکه های فیزیکی که لینک (کابل) یا پورت آن ها از بین رفته باشد و هیچ سیگنالی رد و بدل نشود، آن کارت شبکه را fail می‌داند. ممکن است سمت سوئیچ فیزیکی اتفاقی افتاده باشد و پورت در حالت shutdown قرار گرفته باشد، در این صورت VSS آن را در حالت fail قرار داده و از تیم اخراج می‌کند.
سوال:
با fail شدن کارت شبکه، چه بلایی سر VM هایی که به این vmnic ها assign شده بودن میاد؟ خب بریم ببینیم چی به سرشون میاد!
همانطور که در شکل زیر می‌بینید، VM ها از طریق vNIC ها با شبکه فیزیکی ارتباط می‌گیرند. فارغ از اینکه load balancing در کدام حالت قرار گرفته (مثلا در حالت Port-ID می‌باشد؛ یعنی Port-ID ها به صورت static بر روی کارت شبکه های فیزیکی یا pNIC ها assign می‌شوند.)، ما فرض را بر آن می‌گیریم که vNIC مربوط به VM-1 به pNIC-1 ( vmnic0 یا uplink-1) متصل شده است و به خوبی کار می‌کند، ولی طی شرایطی کارت شبکه فیزیکی fail می‌شود (ممکن است لینک آن قطع شود، کابل آن خراب شود و یا پورت آن از بین برود و یا به هر دلیل دیگر) که این باعث می‌شود این کارت شبکه از دید VSS، fail به نظر بیاید و از تیم اخراج گردد یا به عبارتی unused شود و تمام VM هایی که مربوط به این کارت شبکه هستند به pNIC-2 انتقال یابند (یا اگر pNIC-2، fail شده بود به pNIC-3 انتقال یابند).
در نگاه اول همه چیز عالی است چون این کار را به صورت اتوماتیک انجام می‌دهد؛ اما آیا فقط این کار را انجام می‌دهد؟ معلومه که نه!!!
ما می‌دانیم که سوئیچ ها دارای MAC table و روترها دارای Routing table مخصوص به خود هستند. مثلا در MAC table سوئیچ، MAC address-A برای Port-1 و MAC address-B برای Port-2 ثبت شده است و این را نیز می‌دانیم MAC table به سرعت پاک نمی‌شود و تغییر نمی‌کند مگر اینکه بسته های جدید به MAC table اضافه شده و MAC address ها update شوند، پس نمی‌توانیم منتظر بمانیم تا سوئیچ کاری انجام دهد چون خیلی طول می‌کشد. VMware با استفاده از تیک گزینه Notify switches این مشکل را حل می‌کند، به چه صورت؟ به این صورت که مثلا VM-1 با MAC address-A از طریق vNIC-A به Port-ID 9 متصل شده و Port-ID از طریق pNIC-1 یا vmnic0 با دنیای فیزیکی در ارتباط است. حال طی شرایطی، ممکن است کابل خراب شود یا پورت از بین برود؛ که البته اگر پورت از بین برود، MAC table ای که اطلاعات پورت از بین رفته را دارد، Refresh می‌شود ( یا به عبارتی پاک می‌کند) تا زمانی که مشکل پورت حل شود و بتواند اطلاعات جدید را در آن ثبت کند. فرض کنیم طوری fail شده است که سوئیچ MAC address ها را تا یک تایم خاصی در خود نگه می‌دارد، در این شرایط، VSS برای اینکه VM نیاز دارد تا با دنیای فیزیکی ارتباط داشته باشد یک کارت شبکه دیگر به آن assign می‌کند. از pNIC-1 لینک ارتباطی را قطع کرده و به pNIC-2 که با pNIC-1 در یک تیم هستند، متصل می‌کند. سپس با استفاده از Source MAC address VM-1 یا VM هایی که به pNIC-1 (fail شده) متصل بودند، عمل Reverse ARP (RARP) را انجام می‌دهد تا بتواند MAC table سوئیچ فیزیکی را با شرایط جدید update کند.
کاربرد پروتکل ARP (Address Resolution Protocol) چیست؟ در واقع پروتکل ARP با استفاده از IP مقصد، MAC address مقصد را پیدا می‌کند. اما در پروتکل Reverse ARP، کاری با IP نداریم و MAC address را هم می‌دانیم فقط می‌خواهیم MAC table سوئیچ را update کنیم. اگر بخواهیم این مکانیزم را ساده تر بیان کنیم، می‌توان گفت VSS یک سری بسته یا packet های fake با Source MAC address، VM هایی که عضو pNIC، fail شده بودند ایجاد کرده و به سمت سوئیچ ارسال می‌کند تا سوئیچ فیزیکی MAC table در حال حاضر را update کند و خود را با شرایط جدید وفق دهد.
درکنار گزینه Notify switches، گزینه دیگری به نام Failback داریم.
Failback چه کمکی به ما می‌کند؟ خب Port-ID 9 به pNIC-1 متصل بود، حال طی شرایطی لینک ارتباطی کارت شبکه فیزیکی سرور و سوئیچ از بین رفته است یا به هر دلیلی pNIC-1 از این تیم حذف شده است، VM هایی که به این pNIC، assign شده بودند به یک pNIC دیگر assign شده و بحث Reverse ARP و ایجاد بسته های fake انجام می‌شود. البته ما pNIC-1 را به حال خود رها نمی‌کنیم، در این حالت گزینه Failback را فعال می‌کنیم که اگر چنین شرایطی پیش آمد و پس از مدتی pNIC-1 بدون هیچ مشکلی به این تیم دوباره بازگشت، دوباره بتواند همان VM های قبلی را به pNIC-1 بازگرداند اما اگر Failback را فعال نکنیم، پس از بازگشت pNIC-1، VM ها هم چنان در pNIC-2 قرار دارند و ممکن است بار اضافی بر روی آن باشد. در این شرایط ممکن است ترافیک های pNIC های 2 و 3 نسبت به pNIC-1، unbalance باشند، بنابراین گزینه Failback را فعال می‌کنیم که اگر pNIC-1 از بین رفت و Port-ID های 9، 10 و 11 که بر روی آن assign بودند، به pNIC-2 انتقال یافتند، پس از برگشت دوباره pNIC-1 به حالت قبلی (سلامتی کامل)، Port-ID های ذکر شده دوباره به کارت شبکه اول خود (pNIC-1) برگردند تا pNIC-2 در شرایط unbalance قرار نگیرد.
نکته 1: حتما گزینه های Notify switches و Failback را فعال نمایید. (مخصوصا گزینه Failback)
نکته 2: در حالت Failback، بار دیگر بحث Reverse ARP و ایجاد بسته های fake اتفاق می‌افتد؛ چون دو بار Port-ID ها از یک pNIC به pNIC دیگر انتقال داده می‌شوند، به همین دلیل عملیات مربوط به Reverse ARP و ایجاد بسته های fake بار دیگر اتفاق می‌افتد. (در واقع این عملیات یکبار هنگام رفت از pNIC-1 به pNIC-2 و بار دیگر هنگام برگشت از pNIC-2 به pNIC-1 اتفاق می‌افتد.)
با عرض پوزش ، دسترسی کامل به محتوای فصل ، فقط برای کاربرانی که فصل رو خریداری کرده اند ، امکان پذیر می باشد.
برای ثبت نظر ابتدا وارد حساب کاربری خود شوید
ورود به حساب کاربریهیچ نظری ارسال نشده است! اولین نظر را شما ارسال کنید...