مروری بر معماری TOR و EOR در شبکه

این مقاله بررسی و مقایسه دقیقی را از طراحی دیتاسنتر Top of Rack و End of Row، دو طرح فیزیکی معروف در دیتاسنترها، ارائه می‌دهد. همچنین یک طرح جایگزین دیگر با استفاده از Fabric Extender بررسی می‌شود.

طراحی دیتاسنتر Top of Rack

طراحی دیتاسنتر ToR

شکل 1 – طراحی دیتاسنتر ToR

در طراحی دیتاسنتر Top of Rack، سرورها به یک یا دو سوییچ اترنتِ نصب شده درون هر rack، متصل می‌شوند. عبارت “Top of Rack” در حالی برای این طراحی برگزیده شده است که عملا نیازی به انتخابِ مکان فیزیکی سوییچ در بالای rack نیست. مکان قرارگیری سوییچ می‌تواند پایین یا در میانه ی rack باشد. اگرچه قرارگیری در بالای rack رایج ترین وضعیت است، چرا که دسترس‌پذیری و مدیریت کابل آسان تر خواهد بود. در برخی مواقع این طراحی دیتاسنتر را “In-Rack” هم می‌نامند.

سوییچ ToR اغلب جایگیری فضای اندکی (1RU-2RU) دارد و fixed configuration است. مشخصه‌های کلیدی و جاذبه‌ی طرح ToR در این است که تمامی کابل‌بندی مسی برای سرورها درون rack قرار می‌گیرد، به طوری که از patch cable های کوتاه RJ45 برای ارتباط سرور تا سوییچِ درون rack استفاه می‌شود. سوییچ اترنت از طریق فیبر، rack را به شبکه دیتاسنتر پیوند می‌دهد، فیبری که مستقیما میان rack تا ناحیه aggregation مشترک دایر است.

همانطور که گفته شد، هر rack از طریق فیبر به دیتاسنتر متصل می‌شود. بنابراین نیازی به زیرساخت‌های جاگیر و پرهزینه برای دایر کردنِ کابل‌بندی مسی میان rack ها و دیتاسنتر نیست. حجم بالای کابل‌های مسی به عنوان باری اضافی بر تجهیزات دیتاسنتر به شمار می‌آیند. علاوه بر این کابل‌های مسیِ جاگیر تعیین مسیر را سخت خواهد کرد، جریان هوا را مسدود می‌کند و به طور کلی به تخصیص تعداد rack ها و زیرساخت‌های بیشتری برای مدیریت کابل و patching نیاز دارد. پیاده سازیِ مسافتی طولانی از کابل‌های مسی twisted pair همچنین می‌تواند محدودیت‌هایی را بر روی سرعت دسترسیِ سرور و تکنولوژی شبکه قرار دهد. طراحیِ دیتاسنتریِ ToR از ایجاد این مسائل جلوگیری می‌کند چرا که هیچ نیازی به زیرساخت کابل‌بندیِ مسی بسیار نیست. این اغلب فاکتوری کلیدی در انتخاب طراحی دیتاسنتر ToR در مقابل EoR به شمار می‌آید.

هر rack همچون یک واحد ماژولار و مجزا درون دیتاسنتر در نظر گرفته و مدیریت می‌شود. بنابراین نیازی به زیرساخت پر هزینه و اضافی برای اجرای کابل‌بندی میان rack ها و دیتاسنتر نیست. هر بهبودی در شبکه یا مشکلات پیش آمده برای سوییچ‌های rack تنها بر روی سرورهای موجود در همان rack تاثیر می‌گذارد و تاثیری بر ردیف سرورها در rack های مختلف نخواهد داشت. با توجه به اینکه ارتباطات سرور درون rack، با کابل‌های مسی خیلی کوتاهی برقرار می‌شود، در نتیجه در این مورد که از چه کابلی و با چه سرعتی استفاده نماید، انتخاب‌ها و انعطاف‌پذیری بیشتری برایش وجود دارد . به طور مثال کابل مسی 10GBASE-CX1 برای پشتیبانی از اتصال‌های سرور با سرعت 10G و مصرف توان و هزینه‌ای کمتر استفاده می‌شود. کابل 10GBASE-CX1 حداکثر مسافتی به اندازه 7 متر را پشتیبانی می‌کند که به خوبی برای طراحی دیتاسنتر ToR کارایی دارد.

از آنجایی که فیبر قابلیت منحصری در حمل سیگنال‌های با پهنای باند بیشتر در مسافت‌هایی طولانی‌تر دارد، بنابراین انعطاف‌پذیری بهتر و سرمایه‌گذاریِ حمایت شده‌تری را برای هر rack نسبت به کابل مسی فراهم می‌کند. اتصالات شبکه با سرعت‌های 40G و 100G به راحتی در زیرساخت‌های فیبر پشتیبانی می‌شود.

طراحی دیتاسنتر ToR به همراه blade server

شکل 2 – طراحی دیتاسنتر ToR به همراه blade server

دراثر بکارگیری سرورهای blade به همراه ماژول‌های سوییچِ یکپارچه‌شده و با انتقال مفهوم ToR به درون blade enclosure، فیبر به‌ محبوبیت بیشتری دست‌یافت. یک انکلوژر blade server ممکن است 2، 4 یا بیشتر از ماژول‌های سوییچینگ و چندین سوییچ FC را دارا باشد. این منجر به افزایش تعداد سوییچ‌هایی می‌شود که باید مدیریت شوند.

یکی از مهمترین پیامدها در طراحی دیتاسنتر ToR، افزایش دامنه مدیریت است. چرا که هر سوییچ در rack یک control plane مجزا دارد که باید مدیریت شود. در یک مرکز داده بزرگ با تعداد rack های بالا، به هنگام افزایش تعداد سوییچ های با پنل مدیریتی مجزا درون دیتاسنتر، طراحی دیتاسنتر ToR سریعا به یک سربار مدیریتی تبدیل می‌شود.

دیتاسنتری را در نظر بگیرید که حاوی 40 عدد rack و 2 عدد سوییچِ ToR در هر rack است. درنتیجه 80 عدد سوییچ تنها برای فراهمسازی اتصالات دسترسی به سرورها (علاوه بر سوییچ‌های core و distribution موجود) استفاده می‌شود. به این معناست که 80 کپی از نرم افزار سوییچ را در اختیار دارید که به بروزرسانی نیاز دارند. 80 عدد از فایل‌های کانفیگ که باید ایجاد شوند. 80 عدد سوییچ مختلف که در فرآیند STP در لایه 2 شرکت دارند. و در نهایت 80 مکان مختلف برای configuration که می‌تواند منجر به خطا شود.

هنگامی که یک سوییچ ToR دچار خطا شود، سوییچ جایگزین به اطلاعاتی در رابطه با چگونگی دسترسی صحیح نیاز دارد. همچنین تنظیمات موجود در سوییچ پیشین باید در آن جایگزین شوند (با فرض اینکه آخرین archive موجود صحیح باشد). درنتیجه ممکن است نیاز به اجرای آزمایش‌های درستی‌سنجی و عیب‌یابی داشته باشد.

طرح ToR اغلب به تراکم پورت بالاتری در سوییچ‌های aggregation نیاز دارد. به مثال 80 عدد سوییچ باز می‌گردیم. باتوجه به اینکه هر سوییچ یک اتصال به سوییچ aggregation دارد، هر سوییچ aggregation نیاز به 80عدد پورت خواهد داشت. هرچه تعداد پورت‌های بیشتری بر روی سوییچ aggregation وجود داشته باشد، احتمال رویارویی با محدودیت‌های مقیاس‌پذیری بیشتر خواهد شد.

یکی از این محدودیت‌ها ممکن است در پورت‌های منطقی STP رخ دهد که مجموعی از پورت‌های aggregation و VLANها است. به فرض، اگر نیاز به پشتیبانی از 100 عدد VLAN در یک دامنه‌ی L2 واحد از طریق PVST 1 بر روی تمامیِ 80 پورت از سوییچ‌های aggregation باشد، می‌تواند منجر به ایجاد 8000 پورت منطقیِ STP به ازای هر سوییچ aggregation شود. اغلب سوییچ‌های ماژولار قوی این مقدار را می‌توانند مدیریت کنند.

برای مثال، کاتالیست 6500 در مجموع از 10000 پورت PVST و 1800 پورت به ازای هر line card پشتیبانی می‌کند. همچنین سوییچ Nexus 7000 در مجموع از 16000 پورت PVST بدون هیچ محدودیتی به ازای هر line card پشتیبانی می‌کند. این مسئله چیزی است که به هنگام رشد دیتاسنتر از لحاظ تعداد پورت‌ها و VLANها، باید به آن توجه شود. محدودیت ممکن دیگر، درتعداد پورت‌های فیزیکی است، آیا سوییچِ aggregation ظرفیت کافی برای پشتیبانی از تمامیِ سوییچ‌های ToR را داراست؟ از لحاظ پشتیبانی از اتصالات 10G برای هر سوییچ ToR چطور؟ سوییچ aggregation چگونه برای پورت‌های 10G مقیاس‌دهی را انجام می‌دهد؟

خلاصه‌ای از مزایای طرح ToR:

  • به زیرساخت کابل‌بندی مسی زیادی نیاز ندارد
  • هزینه‌های کابل‌بندیِ کمتری دارد. زیرساخت‌های کمتری برای کابل‌بندی و patching تخصیص داده می‌شود. مدیریت کابل بهتری دارد.
  • ارائه معماریِ ماژولار و قابل انعطاف به ازای هر rack. ارائه بروزرسانی ها/تغییرات آسانتر به ازای هر rack
  • پشتیبانی از زیرساخت فیبر
  • طول کابل‌های مسی کمتر که منجر به مصرف توان و هزینه کمتر می‌شود

خلاصه‌ای از نقاط ضعف در طرح ToR:

  • سوییچ‌های بیشتری برای مدیریت کردن وجود دارد. در سوییچ aggregation به پورت‌های بیشتری نیاز است
  • وجود نگرانی‌هایی در رابطه با مقیاس‌پذیری (تراکم پورت در سوییچ aggregation، پورت‌های منطقی STP)
  • افزایش ترافیک‌های لایه 2ای server-to-server در aggregation
  • Rackها در لایه 2 با یکدیگر ارتباط برقرار می‌کنند. نیاز به نمونه‌های STP بیشتر برای مدیریت است
  • Control plane مجزا به ازای هر سوییچ (هر 48 پورت). نیاز به مجموعه مهارت‌های برتری برای جایگزینیِ سوییچ

طراحی دیتاسنتر End of Row

طراحی دیتاسنتر EoR

شکل 3 – طراحی دیتاسنتر EoR

قفسه‌های سرور (یا همان rackها) اغلب در یک ردیف، کنار یکدیگر تنظیم می‌شوند. هر ردیف ممکن است شامل، به طور مثال 12 عدد rack باشد. عبارت “End of Row” برای توصیف یک rack یا قفسه‌ای به کار می‌رود که به منظور فراهم‌نمودن اتصال شبکه برای سرورهای درون آن ردیف، در یکی از دو انتهای ردیف سرورها قرار دارد. هر قفسه‌ای از سرورها در این طرح دسته‌ای از کابل‌های مسی twisted pair (اغلب cat6 یا 6A) دارد. این دسته کابل‌ها، شامل 48 عدد یا بیشتر از کابل‌های مجزایی هستند که به سمت قفسه‌های EoR مسیریابی می‌شوند. Rackهای EoR در شبکه، ضرورتا نیازی ندارند که در انتهای ردیف قرار گیرند. امکان طرح‌هایی که در آنها شمار کمی از rack های شبکه در ردیف‌های کوچکی قرار گیرند، وجود دارد. تا اتصال مسی “End of Row” را برای بیش از یک ردیف از سرورها تامین کنند.

در طرحی دیگر ممکن است بیش از دو دسته از کابل‌های مسی برای هر rack وجود داشته باشد. درون قفسه‌ی سرورها دسته‌ای از کابل‌های مسی، اغلب به یک یا بیشتر از patch panelهای fixed دربالای rack متصل شده‌اند. هر سرور از patch cable مسیِ RJ45 کوتاه برای اتصالِ خود به patch panel موجود در rack استفاده می کند. دسته کابل‌های مسی از هر rack به‌واسطه‌ی ladderهایی دربالای ردیف که حامل این دسته‌ها هستند، به‌سمت EoR rack مسیردهی می‌شوند. همچنین دسته کابل‌های مسی می‌توانند از زیر کف اطاق به همراه هزینه‌ای برای ایجاد جریان هوای خنک، مسیردهی شوند.

در طرح بالا، با توجه به مقدار کابل‌ مسی مورد نیاز، رایج است که یک rack را برای patching کابل‌های مسی تخصیص می‌دهند. این rack در مجاورت rack ای قرار می‌گیرد که شامل سوییچ EoR است. بنابراین امکان دارد دو rack شبکه در هر EoR وجود داشته باشد. یک rack برای patching و rack دیگر برای سوییچ شبکه استفاده می‌شود. بازهم برای اتصال یک پورت از سوییچ شبکه به پورت متناظرش در patch panel از RJ45 patch cable استفاده می‌شود. پورتِ متناظر بر روی patch panel است که اتصال به سرور را برقرار می‌کند. وجود حجم بالایی از RJ45 patch cableها در طرح EoR، می‌تواند منجر به ایجاد مشکل در مدیریت کابل‌ها شود. و نبود یک طراحی دقیق، سریعا منجر به یک فضای آشفته و غیر قابل مدیریت می‌شود.

نوع دیگری از این طرح را به نام “Middle of Row” می‌شناسند. این طرح شاملِ تعیین مسیر کابل مسی از هر server rack به جفتی از EoR rack است. که در کنار یکدیگر و در میانه‌ی ردیف قرار می‌گیرند. این روش طول کابل‌ها به سمت rack های انتهایی را به شدت کاهش می‌دهد. اما در صورت رخداد حادثه‌ای در میانه‌ی ردیفِ rackها (مانند چکه‌کردن آب از سقف)، این پتانسیل وجود دارد که کل ردیف از بروز آن متاثر شود. این حادثه می‌تواند منجر به اختلالِ همزمان هر دو سوییچ‌های دسترسی به سرورها در جفت rack میانی شود.

طراحی دیتاسنتر Middle of Row

شکل 4 – طراحی دیتاسنتر Middle of Row

سوییچ در شبکه EoR اغلب یک پلتفرم مبتنی بر شاسیِ ماژولار است که از هزاران اتصال سرور پشتیبانی می‌کند. معمولا برای supervisor engine و منابع تغذیه امکان افزونگی وجود دارد. و درمجموع از مشخصه‌های HA بهتری نسبت به یک سوییچ در طرح ToR برخوردارند. سوییچ EoR ماژولار باید طول عمر زیادی، حداقل 5 تا 7 سال (یا حتی بیشتر از این) داشته باشد. معمولا رایج نیست که یک سوییچ EoR پی در پی تعویض شود، یک بار درون rack قرار داده می‌شود و هر بروزرسانی اضافی، معمولا در سطح بروزرسانیِ اجزای آن همچون یک line card یا supervisor engine جدید است.

سوییچ EoR اتصال را برای صدها سرور در یک ردیف برقرار می‌سازد. بنابراین برخلاف طرح ToR که در آن هر rack یک واحد مدیریت مجزای خود را دارد، در طرح EoR کل ردیف سرورها همچون یک واحد همبسته یا “Pod” درون دیتاسنتر تلقی می‌شوند. بروزرسانی‌ها یا تعمیر مشکلات پیش‌آمده در شبکه برای یک سوییچ EoR، می‌تواند بر کل ردیف سرورها تاثیر گذارد. شبکه دیتاسنتر موجود در این طرح به جای “به ازای هر rack”در طرح ToR، “به ازای هر ردیف” مدیریت می‌شود.

طرح ToR توپولوژی لایه 2 را از سوییچ aggregation تا هر rack مجزا تعمیم می‌دهد. این منجر به افزایش فضای لایه 2 و در نتیجه اجرای یک فرآیند STP بزرگتر می‌شود. از سویی دیگر، طرح EoR توپولوژیِ کابل‌بندی در لایه 1 را از سوییچ EoR تا هر rack تعمیم می‌دهد. این منجر به ایجاد فضای کمتری برای لایه 2 و در نتیجه قابلیت مدیریت بیشتر در آن می‌شود. و همچنین نودهای STP کمتری در این توپولوژی به وجود می‌آیند.

طرح EoR از لحاظ کابل‌بندیِ دیتاسنتر، یک مدل مدیریتیِ به ازای هر ردیف (per row) است. همانطور که گفته شد دو سوییچ ماژولار به ازای هر ردیف از سرورها وجود دارد، که در مقایسه با طرح ToR سوییچ‌های کمتری باید مدیریت شوند. در مثال پیشین 40 عدد rack در نظر گرفته شده بود، حال فرض می‌کنیم که 10 عدد rack در هر ردیف وجود دارد. در نتیجه 4 ردیف خواهیم داشت که هر کدام دو سوییچ EoR در اختیار دارند. در نتیجه به جای 80 عدد سوییچ موجود در طرح ToR تنها 8 عدد سوییچ باید مدیریت شوند. همانطورکه می‌بینید، از لحاظ تعداد سوییچ‌های مجزایِ نیازمند به مدیریت، طرح EoR امتیاز مهمتری نسبت به ToR در اختیار دارد. این اغلب یک فاکتور کلیدی برای انتخاب EoR نسبت به ToR به شمار می‌آید.

با وجود اینکه طرح EoR تعداد سوییچ‌های کمتری را در زیرساخت خود بکار می‌برد، این ضرورتا به معنای هزینه‌ی سرمایه‌گذاری کمتر برای شبکه نیست. به طور مثال، هزینه‌ی یک line card با 48 عدد پورت در یک سوییچِ ماژولارِ EoR اگر هم‌قیمت نباشد، تنها اندکی کمتر از هزینه لازم برای یک سوییچ ToR با 48 عدد پورت مشابه است. هرچند هزینه قرارداد نگهداری در طرح EoR به دلیل وجود تعداد کمتری از سوییچ‌های مجزا، اغلب کمتر خواهد بود.

خلاصه‌ای از مزایای طرح EoR:

  • نیاز به سوییچ‌های کمتر برای مدیریت. دارای پتانسیلی برای بهره‌مندی از هزینه‌ی سوییچ و نگهداری کمتر
  • پورت‌های کمتر مورد نیاز در aggregation
  • Rackها در لایه 1 به یکدیگر متصل می‌شوند. وجود پورت‌های STP کمتر برای مدیریت (به ازای هر ردیف، به جای هر rack).
  • پلتفرمی ماژولار با دسترس‌پذیری بالاتر و طول عمر بیشتر برای دسترسی به سرور
  • برخورداری از control plane واحد به ازای صدها پورت (به ازای هر سوییچ ماژولار)
  • نیاز به مهارت کمتر برای جایگذاری یک line card با 48 پورت نسبت به جایگزینی با یک سوییچ 48 پورت

خلاصه‌ای ازنقاط ضعف در طرح EoR:

  • نیاز به زیرساختی پر هزینه
  • نیاز به زیرساخت بیشتر برای patching و مدیریت کابل
  • ارائه معماری‌ای با قابلیت انعطاف کمتر به ازای هر ردیف. تغییرات یا بروزرسانی‌ها بر کل ردیف تاثیر می‌گذارد

طراحی دیتاسنتر ToR Fabric Extender

استفاده از Fabric Extender برای طراحی دیتاسنتر

شکل 5 – استفاده از Fabric Extender برای طراحی دیتاسنتر

همچون یک line card در سوییچِ ماژولار، fabric extender تنها یک دستگاه data plane است که تمامی هوشمندی در سطح control plane خود را از سوییچِ master خود دریافت می‌کند. ارتباطِ میان یک fabric extender و سوییچ master آن مشابه با ارتباط میان line card و supervisor engine مرتبط با آن است، تنها با این تفاوت که fabric extender به سوییچ master خود از طریق اتصالات از راه دور فیبر متصل می‌شود. این به شما اجازه خواهد داد که line cardها را از سوییچ ماژولار EoR جدا کنید، بدون اینکه مدل مدیریتی در سوییچ EoR واحد را از دست بدهد. سوییچ master و تمامی fabric extenderهای متصل شده به آن از طریق یک سوییچ مدیریت می‌شوند. هر fabric extender به سادگی تعداد پورت‌های اضافیِ remote (همچون یک remote line card عمل می‌کنند) را برای یک سوییچ master واحد فراهم می‌کند.

برخلاف سوییچ ToR رایج، ToR fabric extender سوییچی نیست که به صورت مجزا قابل مدیریت باشد. هیچ فایل تنظیمات، آدرس IP و نرم‌افزاری برای fabric extender وجود ندارد که نیاز به مدیریت داشته باشد. علاوه بر این، هیچ توپولوژی لایه 2ای از fabric extender به سوییچ master آن وجود ندارد، همه چیز در لایه 1 است. بنابراین، هیچ توپولوژی STPای میان سوییچ master و fabric extenderهای آن وجود ندارد، همانطور که هیچ توپولوژیِ STP میان یک supervisor engine و line cardهای آن وجود ندارد. پروتکل لایه 2ای STP تنها میان سوییچ master و سوییچ aggregation متصل به آن در upstream وجود دارد.

طرح fabric extender از توپولوژی فیزیکی ToR در کنار توپولوژی منطقیِ EoR پشتیبانی می‌کند، بهترینِ هر دو طرح. در این طرح سوییچ‌های بسیار کمتری برای مدیریت کردن (همچون EoR)، بدون نیاز به زیرساخت کابل مسی بزرگ وجود دارد.

از لحاظ صرف هزینه نیز مزایایی وجود دارد. همانطورکه گفته شد، fabric extender به پردازنده، حافظه و flash storage برای اجرای control plane نیاز ندارد، مولفه‌های کمتری و در نتیجه هزینه‌های کمتری درکار است. Fabric extender به طور تقریبی 33 درصد ارزانتر از سوییچ ToR معادل آن است.

هنگامی که fabric extender دچار خطا شود، هیچ فایل کانفیگی وجود ندارد که نیاز به بازیابی و جایگزینیِ آن باشد. همچنین هیچ نرم‌افزاری نیست که نیاز به بارگذاری داشته باشد. Fabric extender از کار افتاده به سادگی خارج‌شده و دستگاهی جدید در مکان آن نصب‌شده و به همان کابل‌های پیشین متصل می‌شود. سطح مهارت مورد نیاز تنها به اندازه شخصی خواهد بود که از چگونگی استفاده از پیچ گوشتی مطلع باشد، بتواند کابل های موجود را بکشد و دوباره وصل کند و وضعیت سبز شدنِ چراغ‌ها را مشاهده نماید. Fabric extender جدید تنظیمات و نرم‌افزارش را از سوییچ masterی دریافت می‌کند که به آن متصل شده‌است.

طراحی دیتاسنتر ToR Fabric Extender

شکل 6 – طراحی دیتاسنتر ToR Fabric Extender

در طرح بالا، ToR fabric extenderها از فیبر برای اتصال میان rack تا سوییچ master خود (Nexus 5000)، جایی در ناحیه aggregation، استفاده می‌کنند. سوییچ Nexus 5000 همچون هر سوییچ EoR معمولی، به یک سوییچ aggregation وصل می‌شود.

توجه داشته باشید که حداکثر 12 عدد fabric extender توسط یک سوییچ master واحد (Nexus 5000) می‌توانند مدیریت شوند.

طراحی دیتاسنتر دیگری از ToR Fabric Extender

شکل 7 – طراحی دیگری از ToR Fabric Extender

در شکل بالا، ToR fabric extenderها از کابل فیبر میان rackهای دیگر تا EoR rack استفاده می‌کنند. این EoR rack شامل سوییچ master می‌شود. سوییچ master، در اینجا همان سوییچ Nexus 5000، اتصالات 10GE unified fabric (در برخی مدل‌ها از Nexus 5000 تا پهنای باند 40GE نیز پشتیبانی می‌شود) را برای دسترسی به سرور می‌تواند فراهم کند.

معمولا رایجتر آن است که کابل فیبر را از هر rack تا یک ناحیه aggregation مرکزی بکشند (همچون شکل 6). با این وجود در طرح نشان داده شده در شکل 7، کابل‌های فیبر به جای کشیده شدن به سمت ناحیه‌ی aggregation، به سمتِ EoR rack می روند. این نحوه کابل‌بندی منجر به دستیابی به استقرارهایی از fabric extender می‌شود که راهی برای حفظ گروه‌بندی منطقی ردیف‌ها است. به این وسیله که سوییچِ master به جای قرارگیری در ناحیه aggregation، درون ردیف جایگذاری می‌شود.

خلاصه‌ای از مزایای ToR fabric extender:

  • وجود سوییچ‌هایی کمتر برای مدیریت کردن. استفاده از پورت‌های مورد نیازِ کمتری در ناحیه EoR) aggregation)
  • rackها در لایه 1 از طریق فیبر متصل می‌شوند. وجود نمونه‌های STP کمتر برای مدیریت کردن (EoR)
  • استفاده از control plane واحد به ازای صدها پورت. مهارت مورد نیاز کمتر برای جایگزینی در صورت خرابی (EoR)
  • کابل‌های مسی درون rack باقی می‌مانند، نیاز به زیرساخت کمتر برای کابل‌های مسی است (ToR)
  • هزینه کابل‌بندیِ کمتر. تخصیص زیرساخت کمتری برای کابل‌بندی و patching. مدیریت آسانترِ کابل‌ها (ToR)
  • معماری ماژولار و انعطاف‌پذیر به ازای هر rack. تغییرات/بروزرسانی های آسان به ازای هر ToR) rack)
  • کابل‌بندی مسیِ کوتاه تر به سمت سرورها، اجازه مصرف توان و هزینه کمتری را خواهد داد.

استقرار طرح‌های دیتاسنتر درون Podها

انتخاب طراحی دیتاسنتر ToR یا EoR تمام آنچه که می‌تواند باشد، نیست. یکی از مواردی که همه‌ی طرح‌های بالا در آن مشترک هستند، اتصال هر یک از آنها به یک ناحیه‌ی aggregation از طریق فیبر است. این ناحیه aggregation به ناحیه EoR pod همانگونه خدمات می‌دهد که به ناحیه ToR pod خواهد داد. هنگامی که دیتاسنتر از طریق طراحی podها (podها واحدهایی ماژولار، مجزا و مشابه از عناصر دیتاسنتر هستند) رشد می‌کند، این امر انعطاف‌پذیری را در انتخاب طرح ممکن می‌سازد. برخی از podها ممکن است طرح EoR copper cabling را به کار بندند در حالی که pod دیگری طرح ToR fiber را استفاده می‌کند و هر pod از طریق فیبر به ناحیه aggregation مشترکی متصل می‌شود.

استفاده از podها در طراحی دیتاسنتر

شکل 8 – استفاده از podها در طراحی دیتاسنتر

نتیجه‌گیری

نمونه‌هایی از طراحی دیتاسنتر که در اینجا مورد بررسی قرار گرفتند، استقرارهایی رایج برای معماری دیتاسنتر به شمار می‌آیند. با توجه به اینکه هر نوع دارای مزایا و نقاط ضعف است، به سختی می‌توان گفت که کدام یک طرح بهتری است. به واقع، طرحی که با توجه به شرایط شما مناسب‌ترین است، برای شما بهترین به شمار می‌آید.

  1. یک پروتکل ارائه شده از سوی سیسکو است که به ازای هر VLAN مجزا، پروتکل STP را به اجرا در می آورد

آشنایی با پروتکل OSPF

پروتکل های مسیریابی link state نقشه راه کاملی را برای هر روتر اجرا کننده این پروتکل فراهم می کنند. روتری که از پروتکل link state بهره می برد به راحتی دچار تصمیم گیری نادرست در رابطه با مسیریابی نخواهد شد چرا که این روتر تصویر کاملی از شبکه در اختیار دارد.

در پروتکل های link state ، عبارت link از پروتکل نمایانگرِ اینترفیسِ روتر است در حالی که عبارت state چگونگی ارتباط آن با روترهای همسایه را نشان می دهد که شامل آدرس IP آن اینترفیس، mask و اطلاعات شبکه و … می شود.

روترهای link state اطلاعات دست اولی را از همه روترهای همتای خود (همه روتر هایی که پروتکل مسیریابی link state را اجرا می نمایند) خواهد داشت. هر روتر اطلاعاتی را درباره خودش، لینک هایی که مستقیما به آن متصلند و همچنین وضعیت این لینک ها ایجاد می کند. این اطلاعات از یک روتر به روتر دیگر عبور داده می شوند، هر روتر کپی از آن اطلاعات را در خود نگاه می دارد، اما تغییری در آن ایجاد نمی کند.

پروتکل های link state تحت عناوین shortest path first یا distributed database protocol نیز شناخته می شوند. از جمله پروتکل های مسیریابی link state می توان به موارد زیر اشاره نمود:

  • پروتکل OSPF) Open Shortest Path First) بر بستر IP
  • پروتکل IS-IS بر بستر IP و CLNS
  • پروتکل NLSP

پروتکل OSPF

پروتکل OSPF از محبوبترین پروتکل ها در خانواده IGP) Interior Gateway Protocol) به شمار می آید. هنگامی که پروتکل OSPF در شبکه کانفیگ شود، به همسایه های روتر گوش می سپارد و داده های link state در دسترس را گردآوری می کند تا نقشه توپولوژی ای از همه مسیرهای موجود در شبکه ایجاد نماید و سپس اطلاعات را در دیتابیس توپولوژی ،تحت عنوان LSDB ،ذخیره کند. با استفاده از اطلاعات جمع آوری شده، بهترین و کوتاه ترین مسیر ممکن به هر subnet یا network را از طریق الگوریتم SFP محاسبه می نماید.

در زیر به برخی از عباراتی اشاره شده است که به آشنایی با آنها برای ادامه بحث نیاز داریم:

  • Link State Advertisement) LSA): بروز رسانی در رابطه با وضعیت لینکِ روتر، LSA زمانی فرستاده می شود که یک لینک متصل شده ، قطع شده باشد یا تغییرات دیگری بر روی آن رخ داده باشد.
  • Topological database: جدولی در حافظه روتر است که اطلاعات لینک های همه روترهای شناخته شده را شامل می شود.
  • SPF algorithm: محاسبات ریاضیاتی است که از الگوریتم دایجکسترا استفاده می کند تا کوتاه ترین مسیر به مقصدها را بیابد. این الگوریتم در نوع خود بسیار پیچیده است
  • SPF tree: لیستی از همه مسیرهای موجود به هر مقصد به ترتیب اولویت

هر روتری که در یک ناحیهOSPF کانفیگ شده باشد، در فاصله های زمانی منظمی پیام های LSA را ارسال می کند. همه این اطلاعات در رابطه با وضعیت لینک ها در topological database ذخیره می شوند، سپس یک الگوریتم SPF بر روی داده های این پایگاه داده به کاربسته می شود.

این فرآیند یک SPf tree ایجاد می نماید که همه مسیرها به هر مقصد را به ترتیب اولویت لیست کرده است. سپس ترتیب مورد نظر در جدول مسیریابی ذخیره می شود و به روترها بهترین انتخاب برای مسیریابی به سمت مقصدهای شان داده می شود.

جداول موجود در پروتکل OSPF

پروتکل OSPF سه جدول زیر را برای ذخیره اطلاعات در روترها ایجاد می کند:

  • Neighbor Table: این جدول شامل همه همسایه های OSPF است به همراه اطلاعات مسیریابی که تغییر خواهد نمود.
  • Topology Table: شامل نقشه راه شبکه و همه روترهای OSPF موجود و بهترین مسیرهای محاسبه شده و مسیرهای جایگزین می شود.
  • Routing Table: شامل بهترین مسیرهای اجرایی فعلی می شود که برای انتقال ترافیک داده میان همسایه ها استفاده می شود.

الگوریتم SPF

همانطور که پیشتر گفته شد کوتاه ترین مسیر از طریق الگوریتم دایجکسترا محاسبه می شود. دایجکسترا الگوریتمی پیچیده به شمار می آید. در مراحل زیر به گام های مختلف الگوریتم در سطح بالا و به روشی تسهیل شده نگاه می شود:

  1. روتر به محض راه اندازی یا به علت هر تغییری در اطلاعات مسیریابی، یک LSA ایجاد می کند. این اعلان مجموعه ای از همه link-state ها را بر روی آن روتر نشان می دهد.
  2. همه روترها از طریق flooding وضعیت لینک ها را تغییر می دهند. هر روتر که یک بروزرسانی برای وضعیت لینک دریافت می کند، باید کپی آن را در LSDB خود ذخیره کند و سپس این بروزرسانی را به روترهای دیگر انتقال دهد.
  3. پس از این که پایگاه داده هر روتر تکمیل شد، روتر درخت کوتاه ترین مسیر (SPF tree) به همه مقصدها را محاسبه می کند. روتر از الگوریتم دایجکسترا برای محاسبه این درخت استفاده می کند. مقصدها، هزینه مربوطه و گام بعدی برای دستیابی به این مقصدها از جدول مسیریابی IP استخراج می شود.
  4. هنگامی که تغییری در شبکه OSPF همچون افزایش یا کاهش یافتنِ هزینه لینک یا شبکه رخ ندهد، پروتکل OSPF فعالیت کمی در شبکه خواهد داشت. هر تغییری که رخ دهد از طریق بسته های link-state انتقال داده می شود و الگوریتم دایجکسترا به منظور یافتنِ کوتاه ترین مسیر مجددا محاسبه می شود.

الگوریتم هر روتر را در ریشه (root) درخت قرار می دهد و بر مبنای هزینه تصاعدی که برای دستیابی به مقصد مورد نظر نیاز است، کوتاه ترین مسیر به هر مقصد را محاسبه می کند. با وجود اینکه همه روترها SPF tree را از طریق LSDB مشابهی ایجاد می کنند، هر روتر تصویر مختص به خود را از توپولوژی در اختیار خواهد داشت.

مفهوم هزینه در پروتکل OSPF

Cost یا همان هزینه یک اینترفیس (که metric هم نامیده می شود) در پروتکل OSPF دلالت دارد بر سرباری که برای ارسال بسته ها از طریق اینترفیسی معین مورد نیاز است. هزینه یک اینترفیس به طور معکوس با پهنای باند آن تناسب دارد. هر چه پهنای باند بیشتر باشد، نشان دهنده هزینه کمتری است. سربار بیشتر (هزینه بیشتر) و زمان تاخیر بیشتری در یک خط سریالِ 56k نسبت به یک خط اترنت 10M وجود دارد. فرمولی که برای محاسبه هزینه استفاده می شود، عبارت است از:

Cost = 100000000/bandwidth in bps

به طور مثال هزینه برای یک خط اترنت 10M برابر خواهد بود با:

Cost = 10^8/10^7 = 10

و برای یک خط T1 با پهنای باند 1.544Mbps این هزینه برابر خواهد بود با:

Cost = 10^8/1544000 = 64

SPF Tree (درخت پوشا)

فرض کنید درخت شبکه زیر را به همراه هزینه های نشان داده شده برای اینترفیس در اختیار دارید. به منظور ایجاد درخت پوشا برای روتر R1 ، باید روتر R1 را به عنوان ریشه درخت قرار داد و کمترین هزینه به هر مقصد را محاسبه نمود.

درخت پوشا

درخت پوشا

همانطور که در درخت پوشای روتر R1 دیده می شود کوتاه ترین مسیر لزوما مسیری با تعداد گام های کمتر نیست. برای مثال به مسیر R1 به R4 نگاه کنید. شاید به نظر بیاید که R1 مستقیم ترافیک را به R4 می فرستد بجای اینکه آن را به R3 و سپس به R4 ارسال نماید. درحالی که هزینه دستیابی مستقیم به R4 برابر با 22 است و بیشتر از هزینه دستیابی به R4 از طریق R3 خواهد بود که برابر با 17 است.

پس از اینکه روتر SPF tree را ایجاد نمود، بر طبق آن شروع به ایجادِ جدول مسیریابی خود می نماید. هزینه دستیابی به شبکه هایی که مستقیما به آن متصلند برابر با 0 است و هزینه دستیابی به شبکه های دیگر نیز بر طبق هزینه محاسبه شده در درخت پوشا خواهد بود.

Area border router

همانطور که پیشتر گفته شد، OSPF برای مبادله ی بروزرسانی های link-state در میان روترها از flooding استفاده می کند. هر تغییری در اطلاعاتِ مسیریابی به همه روترها در شبکه flood می شود. Area به منظور قرار دادن محدوده ای برای جلوگیری از رشد ناگهانی تعداد update های ارسالی استفاده می شود. با تعریف Area ، flooding و محاسباتِ الگوریتم دایجکسترا بر روی یک روتر به تغییراتِ درون همان Area محدود می شود.

همه روترهایِ درون یک Area پایگاه داده ی یکسانی را برای link-state در اختیار دارند. روترهایی که عضو چند Area هستند و این Area ها را به ناحیه backbone متصل می کنند، روترهای Area Border) ABR) نامیده می شوند. بنابراین روترهای ABR باید اطلاعاتی را که توصیف کننده ی نواحیِ backbone و دیگر نواحی هستند، نگهداری نمایند.

7039-spf2-300x189.gif

هنگامی که همه اینترفیس های روتر در یک ناحیه مشخص قرار داشته باشند، به آن روترِ داخلی (IR) می گویند. روتری که اینترفیس هایش در چند Area قرار داشته باشد، روتر ABR می گویند. روترهایی که به عنوان گذرگاه ها میان پروتکل OSPF و دیگر پروتکل های مسیریابی (IGRP ، EIGRP ، IS-IS ، RIP ، BGP ، Static) قرار می گیرند، روترهای Autonomous system boundary) ASBR) نامیده می شوند. هر روتری می تواند نقش ABR یا ASBR را ایفا نماید.

بسته های Link-State

انواع مختلفی از بسته های Link state وجود دارد. این بسته ها به دلایل مختلفی همچون تعیین روابط با روترهای مجاور، محاسبه ی هزینه و یافتن بهترین مسیر برای یک مقصد خاص و … طراحی شده اند. در زیر بسته هایی که در پروتکل OSPF استفاده می شوند را مشاهده می کنید:

  1. بسته Hello : بسته های Hello در طول دوره زمانی بر روی تمامیِ اینترفیس ها به منظور ایجاد و حفظ رابطه با روترهای همسایه ارسال می شود. از آدرس 224.0.0.5 برای ارسالِ multicast این بسته استفاده می شود.
  2. بسته DataBase Descriptor) DBD): در پروتکل های مسیریابیِ link-state نیاز است که پایگاه داده ی همه ی روترها هماهنگ با یکدیگر باقی بمانند. به محض اینکه همسایگی شروع می شود این بسته ها برای هماهنگ سازی مبادله می شوند. به هنگامِ مبادله ی بسته های DBD ، یک رابطه ی master/slave میان روترهای همسایه ایجاد می شود. روتری که شماره ID بالاتری دارد به عنوان Master خواهد بود و شروع به مبادله ی بسته های DBD می کند.
  3. بسته Link State Request: ممکن است روتر پس از مبادله ی بسته های DBD با روتر همسایه خود دریابد که بخش هایی از پایگاه داده اش منقضی شده است. بسته ی LSR را ارسال می کند تا به آن بخش هایی از پایگاه داده ی روتر همسایه که در وضعیت بروزتری از پایگاه داده خود قرار دارند، دست یابد. ممکن است نیاز به مبادله ی چندین بسته ی LSR شود.
  4. بسته Link State Update: flood کردنِ LSA ها از طریق این بسته ها پیاده سازی می شود. هر LSA شامل اطلاعاتِ مسیریابی، معیارها و توپولوژی می شود تا بخشی از شبکه OSPF را توصیف نماید. هر روتر مجموعه ای از LSA ها را درونِ بسته ی LSU به روترهای همسایه خود اعلان می کند. علاوه بر این، روتر بسته ی LSU را در پاسخ به بسته ی LSR دریافت شده ارسال می کند.
  5. بسته Link State Acknowledgment: پروتکل OSPF برای اطمینان حاصل نمودن از دریافتِ بسته های LSA ،نیاز به ارسال بسته های Acknowledgment از مقصد دارد. چندین بسته ی LSA می توانند از طریق تنها یک بسته ی LSAck اعلام وصول شوند.

Backbone و Area 0

هنگامی که چندین Area ایجاد شده باشد، پروتکل OSPF محدودیت های خاصی خواهد داشت. اگر بیش از یک Area کانفیگ شده باشد، یکی از آنها به عنوان Area 0 انتخاب می شود. Area 0 با نام backbone شناخته می شود.

ناحیه backbone باید در مرکز تمامیِ دیگر نواحی قرار گیرد. به طور مثال همه ی نواحی باید به صورت فیزیکی به ناحیه ی backbone متصل شده باشند. استدلال نهفته در پس آن این است که پروتکل OSPF از همه ی نواحی انتظار دارد که اطلاعات مسیریابی را به backbone وارد کنند و backbone به طور منظم آن اطلاعات را به دیگر نواحی منتشر کند. در تصویر زیر جریان اطلاعات در یک شبکه ی OSPF نشان داده شده است:

ospf-300x184.jpg

پروتکل OSPF

همانطور که در تصویر بالا می بینید، همه ی نواحی مستقیما به backbone متصل می شوند. در موقعیت هایی نادر که نا حیه ای جدید اضافه می شود که نمی تواند دسترسی فیزیکیِ مستقیم به backbone داشته باشد، باید یک لینک مجازی کانفیگ شود. در بخش بعدی به لینک های مجازی پرداخته می شود. با توجه به شکل انواع گوناگونِ اطلاعات مسیریابی را ملاحظه می کنید. مسیرهایی که درون یک ناحیه ایجاد می شوند (یعنی مقصد مسیر متعلق به همان ناحیه است)، مسیرهای intra-area نامیده می شوند. این مسیرها معمولا با حرف O در جدول IP routing نمایش داده می شوند. مسیرهایی که از یک ناحیه به ناحیه ای دیگر ایجاد می شوند، inter-area یا summary routes خوانده می شوند. علامت گذاری این مسیرها در جدولِ IP routing به صورت O IA است. مسیرهایی که میان نواحی ای با پروتکل های مسیریابی گوناگون (یا پروتکل OSPF گوناگون) ایجاد و به درون شبکه ی OSPF مشخصی وارد می شوند، external route نامیده می شوند. این مسیرها در جدول IP routing با استفاده از حروفِ O E1 یا O E2 نمایش داده می شوند. چندین مسیر به مقصدی یکسان به ترتیب زیر ترجیح داده می شوند:

Intra-area , Inter-area , external E1 , external E2

لینک مجازی

از لینک های مجازی به دو هدف استفاده می شود:

  • پیوند دادنِ ناحیه ای که اتصال فیزیکی به backbone ندارد
  • ترمیمِ backbone در موقعیت که عدم اتصال به area 0 رخ دهد

همانطور که گفته شد، از لینک مجازی زمانی استفاده می شود که اتصال فیزیکیِ یک ناحیه به Backbone وجود ندارد. لینک مجازی برای این ناحیه مسیری منطقی را به backbone فراهم می کند. لینک مجازی باید میان دو روتر ABR ایجاد شود که ناحیه مشترکی دارند و یکی از این روترها به ناحیه backbone متصل باشد. در شکل زیر این مسئله نمایش داده شده است:

virtual link

لینک مجازی در پروتکل OSPF

در تصویر بالا، Area 1 اتصال فیزیکیِ مستقیمی به Area 0 ندارد. یک لینک مجازی بین روترهای R1 و R2 باید کانفیگ شود. Area 2 باید به عنوان یک ناحیه ی ترانزیت استفاده شود و روتر R2 نقطه ی ورود به Area 0 باشد. با این روش، روتر R1 و Area 1 اتصالی منطقی به backbone خواهند داشت. به منظور کانفیگ کردنِ یک لینک مجازی در روتر سیسکو، از فرمان <area <area-id> virtual-link <RID بر روی هر دو روتر R1 و R2 استفاده می شود، در اینجا area-id همان ناحیه ترانزیت است که در شکل بالا همان ناحیه ی 2 است. RID همان router-id است. Router-id در پروتکل OSPF معمولا بزرگترین مقدار آدرس IP بر روی اینترفیس فیزیکیِ روتر یا بزرگترین مقدار آدرس loopback بر روی آن است. Router-id تنها در زمان boot یا هر زمانی که پروتکل OSPF شروع به کار می کند، محاسبه می شود. برای یافتنِ router-id از فرمان show ip ospf interface استفاده کنید.

مسیرهای خارجی E1 در برابر E2

مسیرهای خارجی در دو دسته بندیِ E1 و E2 قرار می گیرند. تفاوت میان این دو نوع در روشی است که معیار cost مسیر محاسبه می شود. هزینه ی E2 همیشه هزینه ی خارجی است، یعنی از هزینه های داخل ناحیه برای رسیدن به آن مسیر صرف نظر می شود. هزینه ی E1 مجموعِ هزینه داخلی و خارجی برای رسیدن به یک مسیر به حساب می آید. برای دستیابی به مقصدی یکسان یک مسیر E1 همیشه بر مسیر E2 ترجیح داده می شود.

روترهای همسایه

روترهایی که در ناحیه ای یکسان با یکدیگر مشترک اند، روترهای همسایه یکدیگر در آن ناحیه به شمار می آیند. روترهای همسایه از طریق پروتکل Hello انتخاب می شوند. بسته های Hello به صورت دوره ای با استفاده از آدرس multicast از هر اینترفیس به بیرون فرستاده می شوند. روترها به محض اینکه خود را در لیستِ بسته ی Hello از همسایه خود مشاهده کنند، تبدیل به روترهای همسایه خواهند شد. به این ترتیب ارتباطی دو طرفه تضمین می شود. مذاکرات میان روترهای همسایه تنها بر روی primary address انجام می شود.

در صورتِ موافقت بر روی موارد زیر، دو روتر با یکدیگر همسایه خواهند شد:

  • Area-id: دو روتر ناحیه ی مشترکی داشته باشند؛ یک اینترفیس از آنها در ناحیه ای یکسان قرار داشته باشد. البته اینترفیس ها باید متعلق به subnet یکسان باشند و آدرس mask مشابهی داشته باشند.
  • Authentication: پروتکل OSPF اجازه خواهد داد که بر روی ناحیه ای مشخص تنظیمات رمز عبور اعمال شود. روترهایی که قصد دارند با یکدیگر همسایه شوند، باید رمز عبور یکسانی را برای ناحیه ای مشخص مبادله کنند.
  • فاصله های زمانی بین Hello و Dead: پروتکل OSPF بسته های Hello را بر روی یک ناحیه رد و بدل می کند. این روشی است که برای زنده نگاه داشتن ارتباط میان روترها استفاده می شود تا از حضور همسایه خود در همان ناحیه آگاهی یابد و همچنین یک روتر برگزیده شده (DR) را انتخاب نماید. Hello interval فاصله ی زمانیِ (به ثانیه) میان بسته های hello را مشخص می کند که یک روتر بر روی اینترفیس OSPF خود می فرستد. Dead interval مدت زمانی سپری شده پیش از اعلام از دست دادن روتر موجود در OSPF است که در آن بسته های Hello توسط همسایه دیده نشده اند. در پروتکل OSPF ، این فواصل زمانی باید دقیقا میان دو همسایه یکسان تعریف شده باشد. اگر هر یک از این فاصله های زمانی متفاوت باشد، این روترها در ناحیه ای مشخص به عنوان روترهای همسایه به شمار نخواهند آمد. دستوراتی که برای تنظیم این تایمرها استفاده می شوند: ip ospf hello-interval seconds و ip ospf dead-interval seconds
  • Stub area flag: روترها برای اینکه با یکدیگر همسایه باشند باید بر روی stub area flag درون بسته های Hello به توافق برسند. تعریف stub area بر فرآیند انتخاب همسایه تاثیر می گذارد (پروتکل OSPF اجازه خواهد داد که نواحی معینی به عنوان stub area تنظیم شوند. به شبکه های خارجی اجازه داده نخواهد شد که درون ناحیه stub بسته ها را Flood کنند. مسیریابی از این ناحیه به خارج از آن مبتنی بر یک مسیر پیش فرض است. تنظیم ناحیه Stub سایز پایگاه داده مرتبط با توپولوژیِ درون یک ناحیه را کاهش می دهد).

Adjacency

پس از فرآیند انتخاب همسایه، گام بعدی Adjacency است. روترهای adjacent روترهایی هستند که از مبادله ی ساده بسته hello فراتر می روند و به سمت فرآیند مبادله ی پایگاه داده پیش می روند. به منظور کاستن از حجم مبادله ی اطلاعات در ناحیه ای خاص، پروتکل OSPF یک روتر را به عنوان Designated Router) DR) و روتر دیگری را به عنوان Backup Designated Router) BDR) انتخاب می کند. روتر BDR به عنوان مکانیزم پشتیبان به هنگام از دست دادن روتر DR استفاده می شود. ایده نهفته در پس این روش این است که روترها یک نقطه ارتباط مرکزی برای تبادل اطلاعات داشته باشند. به جای اینکه هر روتر با هر روتر دیگر در آن ناحیه دو به دو بروزرسانی ها را مبادله کنند، هر روتر اطلاعات را تنها با روتر DR و BDR مبادله می کند. روترهای DR و BDR این اطلاعات را به دیگران منتقل می کنند. از لحاظ ریاضی این روش باعث خواهد شد که هزینه مبادله ی اطلاعات از (O(n*n به (O(n کاهش یابد، در اینجا n تعداد روترهایی است که در این ناحیه قرار دارند.

روتر DR

روتر DR و BDR در پروتکل OSPF

در تصویر بالا همه ی روترها در یک ناحیه مشترک قرار گرفته اند. به علت مبادله ی بسته های Hello ، یک روتر به عنوان روتر DR و روتری دیگر به عنوان BDR انتخاب شده است. هر روتر در این ناحیه (که پیش از این همسایه روتری دیگر شده است) تلاش می کند که با روتر DR و DBR یک adjacency ایجاد کند.

انتخاب DR

انتخاب DR و BDR از طریق پروتکل hello انجام می شود. بسته های Hello از طریق بسته های multicast در هر ناحیه مبادله می شوند. روتری که بیشترین OSPF priority را در یک ناحیه دارد به عنوان روتر DR در آن ناحیه انتخاب می شود. فرآیند مشابهی نیز برای انتخاب روتر BDR تکرار می شود. در صورت تساویِ اولویت ها در روترها، روتری که بیشترین RID را دارد، پیروز خواهد شد. اولویت OSPF برای اینترفیس به صورت پیش فرض برابر با 1 است.

مقدار priority برابر با 0 ، نشان دهنده ی آن است که آن اینترفیس به عنوان DR یا BDR انتخاب نشده است. در تصویر زیر فرآیند انتخاب DR را مشاهده می کنید:

DR selection

انتخاب روتر DR در پروتکل OSPF

در تصویر بالا روترهای R1 و R2 اولویت های یکسانی دارند، اما RID مربوط به روتر R2 بیشتر است. در نتیجه در آن ناحیه روتر R2 به عنوان DR انتخاب می شود. روتر R3 نسبت به روتر R2 از اولویت بالاتری برخوردار است، در نتیجه در آن ناحیه روتر R3 به عنوان DR انتخاب می شود.

ایجاد Adjacency

فرآیند ایجاد Adjacency پس از اتمام چندین مرحله انجام می گیرد. روترهایی که در مجاورت (adjacent) یکدیگر قرار می گیرند، پایگاه داده ی یکسانی دارند. وضعیت هایی که یک اینترفیس می پیماید تا در مجاورت روتر دیگری قرار بگیرد، به طور خلاصه در زیر آورده شده است:

  • Down: هیچ اطلاعاتی از هیچ دستگاهی در آن ناحیه دریافت نمی شود.
  • Attempt: این وضعیت بیان می کند که اخیرا هیچ اطلاعاتی از روتر همسایه دریافت نشده است. باید با ارسال بسته های Hello برای برقراری ارتباط با روتر همسایه تلاش نماید.
  • Init: اینترفیس، یک بسته Hello ورودی از طرف همسایه را تشخیص داده است اما هنوز ارتباطی دو طرفه ایجاد نشده است.
  • Two-way: ارتباط دو طرفه با روتر همسایه برقرار است. در این زمان، روتر خود را در بسته های Hello ورودی از طرف همسایه مشاهده کرده است. در پایان این مرحله، انتخاب DR و BDR انجام شده است. در پایان مرحله ی 2way ،روترها تصمیم خواهند گرفت که یک Adjacency را ایجاد نمایند یا خیر. این تصمیم بر این اساس استوار است که کدام یک از روترها DR یا BDR است یا اینکه لینک point-to-point است یا virtual.
  • Exstart: روترها شماره هایی ترتیبی را برای بسته های مبادله اطلاعات ایجاد می کنند. این شماره های ترتیبی تضمین خواهد نمود که روترها همیشه بروزترین اطلاعات را در اختیار دارند. بک روتر به عنوان primary و روتر دیگر secondary خواهد شد. روتر primary از روتر secondary اطلاعات را جمع آوری می کند.
  • Exchange: روترها تمامیِ LSDB خود را از طریق ارسال بسته های DBD ترسیم می کنند. در این وضعیت بسته ها می توانند به اینترفیس های دیگر بر روی روتر flood شوند.
  • Loading: در این وضعیت، روترها در حال به پایان رساندن تبادل اطلاعات هستند. روترها یک درخواست link-state و یک لیست ارسال مجدد link-state را ایجاد می کنند. هر اطلاعاتی که ناقص یا منقضی به نظر برسد در لیست درخواست قرار می گیرد. هر بروزرسانی ای که ارسال شود تا زمانی که Ack مرتبط با آن دریافت شود، در لیست ارسال مجدد قرار می گیرد.
  • Full: در این وضعیت، Adjacency کامل شده است. روترهای همسایه با یکدیگر به طور کامل adjacent شده اند. روترهای Adjacent پایگاه داده link-state مشابهی خواهند داشت.

نکاتی برای طراحیِ پروتکل OSPF

در اسنادِ رسمی مرتبط با پروتکل OSPF خط مشی ای برای تعداد روترها در یک ناحیه یا تعداد همسایه ها در هر بخش داده نمی شود و یا گفته نمی شود که بهترین روش یرای طراحی معماری این شبکه چیست. افراد گوناگون رویکردهای متفاوتی به طراحی شبکه با پروتکل OSPF دارند. مهمترین چیزی که باید به خاطر سپرد این است که هر پروتکلی می تواند تحت فشارها به شکست بیانجامد. در ادامه لیستی از مسائلی که باید به آنها توجه نمود، آورده شده است.

تعداد روترها در هر ناحیه

حداکثر تعداد روترها در هر ناحیه به چندین فاکتور وابسته است، که شامل موارد زیر می شود:

  • چه نوعی از Area را در اختیار دارید؟
  • چه نوعی از توان CPU را در آن ناحیه در اختیار دارید؟
  • چه نوعی از مدیا استفاده می شود؟
  • آیا پروتکل OSPF در مود NBMA (در این مود بسته های Hello به روترهای همسایه broadcast نمی شوند، بلکه روتر این بسته ها را تنها به همسایه هایی که خواهان دریافت آن هستند، ارسال می کند) اجرا می شود؟
  • آیا شبکه NBMA شما مش بندی شده است؟
  • آیا تعداد LSA های خارجی زیادی در شبکه دارید؟
  • آیا مسیریابی میان نواحی به خوبی انجام می شود؟

تعداد همسایه ها

همچنین تعداد روترهایی که به شبکه ی lan یکسانی متصلند، از اهمیت بالایی برخوردار است. هر شبکه lan یک روترِ DR و BDR دارد که همسایگی را برای تمامی روترهای دیگر ایجاد می کنند. هر چه تعداد همسایگان کمتری بر روی LAN وجود داشته باشد، تعداد همسایگی های کمتری توسط رورترهای DR یا DBR باید ایجاد شود. این مسئله وابسته است به قدرتی که روتر شما دارد. شما همیشه تواناییِ تغییر OSPF priority را دارید تا به واسطه آن روتر DR را انتخاب نمایید. همچنین از داشتن بیش از یک روتر DR در یک ناحیه پرهیز کنید. اگر انتخاب روتر DR بر مبنای بیشترین مقدار RID باشد، درنتیجه به صورت تصادفی یک روتر باید به عنوان DR در سراسر نواحی ای که به آن متصل است، انتخاب شود. این روتر باید نسبت به دیگر روترهای بیکار، کار مضاعفی را انجام دهد.

تعداد نواحی به ازای هر روتر ABR

روتر ABR نسخه ای از پایگاه داده ی مربوط به تمامی نواحی که به آنها خدمات می دهد را ذخیره می کند. به طور مثال، اگر روتری به 5 ناحیه متصل باشد، باید لیستی از 5 پایگاه داده ی مختلف را در خود نگهداری نماید. تعداد ناحیه ها به ازای هر روتر ABR ، مقداری است که به فاکتورهای بسیاری وابستگی دارد که شامل نوع ناحیه (normal ، stub ، NSSA) ، قدرت CPU روتر ABR ،تعداد مسیرها به ازای هر ناحیه و تعداد مسیرهای خارجی به ازای هر ناحیه می شود. به همین علت تعداد نواحی دقیقی به ازای هر روتر ABR توصیه نمی شود.

جمع بندی

پروتکل OSPF ، پروتکلی متن باز با عملکرد بالا را در اختیار شما می گذارد که به چندین با vendor های گوناگون اجازه برقراری ارتباط از طریق پروتکل TCP/IP را می دهد. پروتکل OSPF پروتکل مسیریابیِ قوی و سریعی است که در صورتی که به درستی کانفیگ شود، با قدرت در شبکه های بزرگ عمل می نماید.

برخی از ویژگی های OSPF عبارتند از : سرعت، convergence، VLSM ، احراز هویت، بخش بخش سازی سلسله مراتبی و … که برای مدیریت شبکه های پیچیده و بزرگ به کار برده می شوند.

نقد و بررسی بازی Red Dead Redemption 2

بالاخره پس از هشت سال انتظار بعد عرضه‌ی Red Dead Redemption 1، نسخه‌ی دوم این بازی هم منتشر شد. Rockstar Games که در سال 2010 تونسته بود با RDR عنوان بهترین بازی سال رو بدست بیاره، حالا در سال 2018 هم همه‌ی دوست‌داران بازی رو به خودش خیره کرده.

Red Dead Redemption 2 از جهات بسیاری شبیه نسخه‌ی قبلی خودشه و ما رو یاد اون بازی میندازه که خب طبیعی هم هست؛ اما نکته‌ی قابل تحسین این سری بازی که اونو تبدیل به شاهکاری از راکستار کرده، بی‌شباهتیه اون‌ به هر بازی دیگه‌ایه.

red dead redemption 2

ما در RDR 2، بازی رو در نقش Arthur Morgan (بعد از تلاش برای دزدی) آغاز می‌کنیم و درحال فرار برای نجات جونمون از مناطق مختلف بازی و یافتن اعضای سرگردون گروهمون هستیم. با پیشرفت در بازی و بدنام شدن بیشترتون، شهرک‌ها و مکان‌های بیش‌تری باهاتون دشمن میشن؛ نتیجتا به مکان‌های جدیدتری میرین تا مکان امنی برای خلاف‌های دیگتون پیدا کنین! از اونجایی هم که بازی جهان باز (open world) هست، زمان زیادی رو می‌تونین صرف گشت و گذار در جاهای جدید و کشف بازی بکنین.

بازی Red Dead Redemption 1 با گشت و گذار و اکتشاف در نقشه‌ی عظیم و پرجزئیات و همچنین ماموریت‌های جانبی فراوان شناخته میشد و این بازی هم از این قاعده مستثنا نیست. (باوجود نزدیک به صد مرحله و تعداد بسیار زیادی مرحله‌ی جانبی که می‌تونن این بازیو به یکی از بزرگ‌ترین بازی‌های تاریخ تبدیل کنن.)

red dead redemption 2

ضعف‌های بازی

می‌خوایم همین اول به نکات منفی بازی که کمتر از حد انتظار ظاهر شدن بپردازیم؛ چون که از نکات مثبت بازی کمترن!

اول از همه چیزی که در نگاه اول به نظر میاد، کُند بودن بازیه؛ حرکات، سفرها و حتی مبارزات تفنگی بازی بنظر کُند میان. درواقع شما همیشه در این بازی درحال مانور دادن برای رسیدن به نقطه ای امن هستین و در عین حال بعضی وقتا هم به آرومی دشمنانتونو نشونه می‌گیرین.

اتفاقات شروع بازی بسیار کُندن و خب البته برای آشنا شدن بازی‌کن با مکانیزم‌های بازی، چیز طبیعی بنظر میاد. چند ساعتی طول میکشه تا شما ابزار و مهارت‌ کافی برای رفتن به دل غرب وحشی رو بدست بیارین و بتونین آزادانه در جهان بسیار بزرگ بازی وقت بگذرونین. این نکته ممکنه بعضی مخاطبارو که وقت کافی یا حوصله‌ی زیادی برای بازی کردن ندارن، از این بازی دلسرد کنه.

Red Dead Redemption 2 بازی‌کنایی رو که وقت کافی برای انجام بازی میذارن، به بهترین نحو پاداش می‌ده. البته سرعت پایین بازی به کنکاش بیش‌تر شما در بازی و پیدا کردن جزئیاتش کمک می‌کنه.

Red Dead Redemption 2 با دنیای open world خودش، احتمالا بزرگ‌ترین بازی ساخته شده توسط Rockstar Games رو ارائه کرده. هر شهر زیباشناسی خاص و مراحل متفاوت خودشو داره که باعث میشه شما هیچ دو شهری رو باهم اشتباه نگیرین.

بزرگ‌ترین نقطه ضعفی که به این جهان عظیم میشه گرفت، کمبود fast travel هاست. البته شما می‌تونین سفرهای خودتون بین شهرها رو با استفاده از قطارها و دلیجان‌ها و همچنین کمپ‌هایی که فعال می‌کنین انجام بدین؛ اما بازم کمبود گزینه‌های سفر سریع (fast travel) در بازی حس میشه.

با این وجود، ما متوجه منظور سازندگان از این اتفاق هستیم؛ اون ها میخوان که ما از سفرهای درون بازی و بین شهری هم لذت ببریم. Rockstar می‌خواد ما رو با تماشای شاهکارش مبهوت کنه تا به درک درستی از این سازه‌ی مجازی دست بشر (در فضاسازی و جزئیات بی‌نظیرش) برسیم و آفریدگاری خودش در این اثر هنریو به رخ بکشه. اما بنظر میرسه مخاطب عام کم حوصله‌ی امروز، فقط می‌خواد هرچه سریعتر مراحلو انجام بده و بازیو به اتمام برسونه و کمتر به درک هنری بازی میرسه.

red dead redemption 2

نکات مثبت

بعد از نقاط ضعف بازی، حالا به نقاط قوت پررنگ Red Dead Redemption 2 می‌رسیم.

ابتدا می‌خوایم به فیزیک خیره کننده‌ی بازی بپردازیم که حیرت انگیزه. اگر قبلا بازی‌های open world دیگه ای هم انجام دادید، با انجام RDR 2 این “حیرت انگیز” بودن موتور فیزیک بازی رو تایید می‌کنین؛ چون‌که احتمالا شما هم با بازی‌های جهان باز زیادی روبرو شدین که علاوه بر باگ‌های زیاد، به غیرطبیعی بودن و بی حرکت بودن بافت‌های دنیای بازی دچارن.

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

البته نبود قابلیت‌هایی هم مثل کنترل خودکار اسب در هنگام برخورد به دیوار (مثل اکثر بازی‌های مشابه)، به این طبیعی‌تر شدن کمک کرده. برای این‌که بدونین سازندگان چقدر به واقعی شدن فیزیک بازی در این شماره‌ی Red Dead Redemption توجه کردن، باید بگیم که به عنوان مثال اگر شما با سرعت بسیار زیاد (بر روی اسب) به مانعی برخورد کنین، نه تنها از اسب نمیفتین، بلکه متناسب با شدت برخودتون، علاوه بر آسیب دیدن یا حتی مردن اسبتون، خودتون هم ممکنه آسیب ببینین یا بمیرین.

ایده این اتفاقات در بازی، مطمئنا برای دادن آزادی عمل هرچه بیش‌تر به بازیکن‌هاس؛ اگه می‌خواید با اعمال خطرناکتون خودتونو به کشتن بدین، اشکالی نداره، بازی مانعتون نمی‌شه! اگه می‌خواین می‌تونین به ماهی‌گیری، سرقت بانک، شکار حیوانات یا کشتن و اسیر کردن مردم شهر مشغول بشین. RDR 2 اینجاست تا ابزارهای موردنیازتون برای انجام ماجراجویی‌های گوناگون توی غرب وحشیو فراهم کنه و به رویاهاتون رنگ واقعیت بده.

در آخر هم برای نقاط قوت باید به سه زاویه‌ی دید بازی اشاره کرد که کاری نوآورانه است.

red dead redemption 2

مدیریت؛ کلید اصلی بازی

چیزهای زیادی در Red Dead Redemption 2 برای مدیریت وجود داره:

اول از همه health یا همون جون خودمون؛ این پارامتر باعث می‌شه تا همیشه شما درحین بازی، حواستون به غذاخوردن و آب‌نوشیدن باشه. علاوه بر این، برای خوب نگه‌داشتن شرایط کاراکتر بازیتون، باید به طور منظم بخوابید. در واقع همیشه باید به سه نوار سنجش سلامت (health)، استقامت (stamina) و چشم مرگ (dead eye) توجه داشته باشین تا با شرایط نامساعد وارد نبردها نشین.

ما می‌تونیم در این بازی با پیدا کردن منابع اطرافتمون، آیتم‌های موردنیازمونو بسازیم. آیتم‌هایی که می‌سازیم، می‌تونن به ما در حفظ شرایط بدنی شخصیت بازیمون کمک کنن.

تنها چیزی که ما نیاز به مدیریت داریم، کاراکترمون نیست و باید عوامل دیگه‌ای مثل اسب و خونه‌مون رو هم مدیریت کنیم.

در پایان بحث مدیریت بازی هم باید بگیم که اگه به نحو احسن وقتمون رو صرف بازی و جستجوی موارد حاشیه‌ای Red Dead Redemption 2 کنیم، راکستار هم به بهترین شکل پاداشمونو میده.

red dead redemption 2

جمع‌بندی پایانی

احتمالا با گفته‌های بالا، شما هم متوجه شدین که به راحتی میشه این بازی رو به عنوان بهترین بازی سال، انتخاب کرد.

البته که هیچ بازی بدون نقص نیست و هر بازی مشکلاتی داره. هر گیمری می‌تونه راجع به هر بازی انتقاد کنه و نقاطی که اون بازی می‌تونسته درشون بهتر عمل کنه رو نام ببره؛ اما Red Dead Redemption 2 عنوانی در خور تحسین و نزدیک به “عالی”ه.

حتی RDR 2 رو میشه شونه به شونه‌ی GTA V، بهترین بازی تاریخ دونست. شاید واقعا پادشاه دنیای بازی‌های open world شرکت Rockstar باشه!

IPv6 چیست؟

IPv6 چیست؟

آدرس IP شناسه ای یکتا برای مشخص شدن یک device در یک شبکه می­ باشد. یکتا بودن آدرس IP بدین معناست که آدرس IP یک device داخل شبکه­ ای که در آن قرار دارد فقط به آن سیستم اختصاص دارد . تا زمانی که یک device آدرس IP نداشته باشد نمی ­تواند با device های دیگر ارتباط برقرار کند .

آدرس­ های IP به دو دسته تقسیم می­ شوند . دسته­ ی اول IPv4 می­ باشد که اکثر ما با آن برخورد داشته ایم و تا حدودی با آن آشنا هستیم. آدرس­  IP  ورژن 4  یک آدرس 32 بیتی است که به صورت 4 عدد در مبنای ده که با نقطه از هم جدا شده اند، نمایش داده می­ شود (مانند : 192.168.1.1 ). این ورژن از IP به تعداد 2 به توان 32 آدرس را ارائه می­ کند. در حال حاضر بیش از 90 درصد آدرس­ ها در جهان  ، IPv4 می­ باشد.

از آنجایی که استفاده از پروتکل TCP/IP در سال­ های اخیر بیش از حد انتظار بوده، در آدرس دهی IPv4 ، محدود هستیم و آدرس­ های IPv4 رو به اتمام است. این یکی از دلایلی است که TCP/IP یک ورژن جدید از آدرس­ های  IP را طراحی کرد که با نام IPv6 شناخته می­ شود.

بعضی از مزیت­ هایی که IPv6  دارد :

  • هزینه­ ی کمتر پردازشی : packet های IPv6 باز طراحی شده­ اند تا header های ساده ­تری را تولید و استفاده کنند که این موضوع فرایند پردازش packet ها توسط سیستم­ های فرستنده و گیرنده را بهبود می­ دهد.
  • آدرس­ های IP بیشتر : IPv6 از ساختار آدرس دهی 128 بیتی استفاده می ­کند در حالی که IPv4 از ساختار آدرس دهی 32 بیتی استفاده می کند . این تعداد آدرس IP این اطمینان را می­ دهد که حتی بیشتر از آدرس­ های مورد نیاز در سال های آینده ، آدرس موجود است.
  • Multicasting : در IPv6 از Multicasting به عنوان روش اصلی برقرار کردن ارتباط استفاده می شود. IPv6 بر خلاف IPv4 روش broadcast را ارائه نمی­ دهد. روش broadcast از پهنای باند شبکه به صورت غیر بهینه و نامناسب استفاده می­ کند.
  • IPSec: پروتکل Internet Protocol Security)IPSec) در درون IPv4 وجود نداشت اما IPv4 از آن پشتیبانی می­ کرد در حالی که IPv6 این پروتکل را به صورت built in در درون خود دارد و می ­تواند تمامی ارتباطات را رمز گذاری (encrypt) کند.

 

آدرس دهی در IPv6

در IPv6 تغییرات عمده ­ای نسبت به IPv4 وجود دارد. IPv4 از ساختار آدرس دهی 32 بیتی استفاده می­ کند در حالی که IPv6 از ساختار آدرس دهی 128 بیتی استفاده می کند. این تغییر می تواند 2 به توان 128 آدرس یکتا را ارائه دهد . این میزان آدرس IP، پیشرفت بسیار زیادی را نسبت به تعداد آدرس IP که IPv4 ارائه می کند(2 به توان 32) دارد.

 

آدرس IPv6 دیگر از 4 بخش 8 بیتی استفاده نمی کند. آدرس  IPv6 به 8 قسمت 16 بیتی که هر قسمت ارقامی در مبنای 16 هستند و با (:) از هم جدا می شوند تقسیم می­شود. مانند:

65b3:b834:45a3:0000:0000:762e:0270:5224

در مورد آدرس ­های IPv6  یک سری نکته­ هایی وجود دارد که باید آنها را بدانید:

  • این آدرس ها نسبت به بزگی حروف حساس نیستند
  • صفر های سمت چپ هر بخش را میتوان حذف کرد
  • بخش هایی که پشت سر هم صفر هستند را میتوان به صورت (::) خلاصه نویسی کرد (روی هر آدرس فقط یک بار می توان این کار را کرد)

مثال: آدرس loopback در IPv6 به صورت زیر است :

0000:0000:0000:0000:0000:0000:0000:0001

از آنجایی که می توان صفرهای سمت چپ هر بخش را حذف کرد آدرس را بازنویسی می کنیم :

0:0:0:0:0:0:0:1

بعد از حذف کردن صفرهای سمت چپ ، می توانیم صفرهای پشت سر هم را نیز خلاصه نویسی کنیم :

1::

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

0000:0000:45a3:0000:0000:0000:0270:5224

در این مثال دو سری صفر های پشت سر هم وجود دارد . اگر هر دو را خلاصه نویسی کنیم به صورت زیر می شود :

45a3::270:5224::

در این حالت مشخص نیست که هر سری چه تعداد صفر پشت سر هم داشته ایم ، پس بهتر است که آن سری که تعداد صفر های بیشتری پشت سر هم دارد را خلاصه نویسی کنید.

0:0:45a3::270:5224

 

ساختار آدرس دهی در IPv6 به کلی تغییر کرده است ، به طوری که 3 نوع آدرس وجود دارد :

  • Unicast: آدرس Unicast برای ارتباطات یک به یک استفاده می شود.
  • Multicast: آدرس Multicast برای ارسال data به سیستم های مختلف در یک لحظه استفاده می شود. آدرس های Multicast با پیشوند FF01 شروع می شوند. برای مثال FF01::1 برای ارسال اطلاعات به تمام node ها در شبکه استفاده می شود ، در حالی که FF01::2 برای ارسال اطلاعات به تمام روترهای داخل شبکه استفاده می شود.
  • Anycastآدرس Anycast برای گروهی از سیستم ها که سرویسی را ارائه می کنند استفاده می شود.

توجه کنید که آدرس broadcast در IPv6  وجود ندارد.

آدرس های Unicast خود به سه دسته تقسیم می شود :

  • Global unicastآدرس های Global unicast ، آدرس های public در IPv6 می­باشد و قابلیت مسیریابی در اینترنت دارد. این آدرس ها معادل آدرس های public در IPv4 می باشد.
  • Site-local unicastآدرس های Site-local unicast ، آدرس های private هستند و مشابه آدرس های private در IPv4 می باشند و فقط برای ارتباطات داخل شبکه ای استفاده می شوند. این آدرس ها همیشه با پیشوند FEC0 شروع می شوند.
  • Link-local unicast: آدرس های Link-local unicast مشابه APIPA در IPv4 هستند و فقط می توانند برای ارتباط با سیستمی که به آن متصل هستند ، استفاده شوند. این آدرس ها با پیشوند FE80 شروع می شود.

 

نکته دیگری که باید به آن اشاره کنیم ، IPv6 ازClassless Inter-Domain Routing (CIDR) که در سال های اخیر متداول شده اند( برای تغییر بخش net ID روی IPv4 )،استفاده می کند.برای مثال آدرس 2001:0db8:a385::1/48 بدین معناست که 48 بیت اول آدرس تشکیل دهنده ی net ID است.

IPv6 به 3 بخش تقسیم می شود:

  • Network ID: معمولا 48 بیت اول آدرس تشکیل دهنده ی net ID آن می باشد. در آدرس های global address ، net ID توسط ISP به سازمان شما اختصاص داده می شود.
  • Subnet ID: این بخش از 16 بیت تشکیل شده و با استفاده از آنها می توانید شبکه ی IPv6 خود را به subnet های مختلف تقسیم کنید. برای مثال شبکه ای با net ID 2001:ab34:cd56 /48 می تواند به دو زیرشبکه 2001:ab34:cd56:0001/64 و 2001:ab34:cd56:0002/64 تقسیم شود.
  • (Unique Identifier(EUI-64نیمه ی دوم آدرس (64 بیت آخر) را unique identifier می نامند، این بخش مشابه host ID در IPv4 است (یک سیستم را در شبکه مشخص می کند). این بخش تشکیل می شود از مک آدرس آن سیستم (48 بیت)که به دو قسمت تقسیم شده و عبارت FFFE که میان آن دو قسمت قرار می گیرد.

 

 

Auto configuration

یکی از مزیت های IPv6 قابلیت auto configuration است ، که در آن سیستم یک آدرس IPv6 برای خود انتخاب می کند ، سپس با ارسال پیام neighbor solicitation به آن آدرس بررسی میکند که این آدرس در شبکه برای سیستم دیگری استفاده نشده باشد. اگر این آدرس توسط سیستم دیگری استفاده شده باشد ،  به پیام جواب می دهد و سیستمی که قصد انتخاب آدرس را داشت متوجه می شود که از آن آدرس نمی تواند استفاده کند. قابل ذکر است احتمال اینکه یک آدرس به دو سیستم اختصاص داده شود خیلی کم است چون مک آدرس سیستم ها در آدرس دهی auto configuration استفاده می شود (مک آدرس یک آدرس یکتا است).

 

با توجه به تکنولوژی های پیش روی دنیای اطلاعات به  ویژه IOT یا اینترنت اشیاء که  به واسطه آن میتوان تعداد زیادی از اشیاء که در طول روز با آن ها سر و کار داریم (مانند سیستم های گرمایشی و سرمایشی، لوازم خانگی، ملزومات اداری و …)، که به صورت هوشمند کنترل می شوند را با یکدیگر در بستر اینترنت ارتباط خواهند داشت. این امر بدین معناست که به میلیاردها آدرس IP نیاز خواهیم داشت و ملزم به استفاده از IPv6 می باشیم .

مجازی سازی

Virtualization (مجازی سازی) فرایند ایجاد یک نسخه مجازی از چیزی مانند نرم افزار، سرور، استوریج و شبکه است. این فرایند موثرترین راه برای کاهش هزینه های دنیای فناوری اطلاعات است در حالی که در تمام سطوح کارایی و بهره وری آن را افزایش می دهد.

مزایای Virtualization

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

  • کاهش هزینه های عملیاتی
  • Downtime ها را کاهش داده و یا از بین برده
  • افزایش بهره وری، کارایی و پاسخگویی دنیای IT
  • آماده سازی سریعتر برنامه ها و منابع
  • تداوم کسب و کار و بهبود بازیابی اطلاعات
  • ساده سازی مدیریت دیتا سنتر

Virtualization چگونه کار می کند؟

با توجه به محدودیت های سرور های x86، سازمان ها باید سرورهای متعددی را تهیه کنند تا سرعتشان را در سطح نیازهای پردازشی و ذخیره سازی امروزه نگه دارند، در حالی که این سرورها از تمام ظرفیت های خود استفاده نمی کنند. نتیجه ی آن ناکارآمدی و صرف هزینه های زیاد است.

Virtualization از نرم افزار استفاده می کند تا عملکرد سخت افزار را شبیه سازی کند و یک سیستم کامپیوتر مجازی بسازد. این موضوع سازمان ها را قادر می سازد که در یک سرور بیش از یک سیستم کامپیوتر مجازی بسازند (که هر کدام می توانند سیستم عامل و نرم افزار های مختلفی را داشته باشند). مزایای آن عبارت اند از مقرون به صرفه بودن و بهره وری بهتر.

Virtual Machine

سیستم کامپیوتری مجازی که به نام ماشین مجازی (VM) شناخته می شود، یک محفظه ی نگهدارنده ی نرم افزار است که می تواند یک سیستم عامل و یا برنامه هایی را داخل خود داشته باشند. ماشین های مجازی کاملا از یک دیگر مستقل هستند. قرار دادن چندین VM در یک سیستم این اجازه را می دهد که سیستم عامل ها و برنامه های مختلفی را فقط در یک سرور فیزیکی و یا یک هاست اجرا کنیم.

یک لایه نازک از نرم افزار به نام “hypervisor” ماشین های مجازی را از هاستی که روی آن نصب شده اند جدا می کند. hypervisor متناسب با نیاز هر ماشین و به صورت پویا، منابع پردازشی را به ماشین ها اختصاص می دهد.

کلمات کلیدی مربوط به Virtual Machine

ماشین های مجازی مشخصات زیر  را دارند که هر کدام فواید مختلفی را ارائه می کنند.

Partitioning

  • اجرا کردن سیستم عامل های مختلف روی یک سرور
  • تقسیم کردن منابع سیستم بین ماشین های مجازی

Isolation

  • امنیت و بروز خطا برای هر ماشین مجازی در سطح سخت افزار ایزوله است
  • حفظ عملکرد ماشین ها با کنترل پیشرفته ی منابع پردازشی

Encapsulation

  • حالت کلی هر ماشین مجازی در فایل هایی ذخیره می شود
  • ماشین های مجازی به سادگی جابجایی فایل ها، انتقال می یابند

Hardware Independence

  • آماده سازی و جابجایی ماشین های مجازی به هر سروری

انواع مجازی سازی

مجازی سازی سرور

مجازی سازی سرور این امکان را می دهد که سیستم عامل های مختلفی را روی یک سرور به صورت ماشین های مجازی با بهره وری بالا، اجرا کنیم. فواید کلیدی آن به صورت زیر است:

  • کارایی بهتر
  • کاهش هزینه عملیاتی
  • انجام سریع کار های سنگین
  • بهبود عملکرد برنامه ها
  • در دسترس بودن بالای سرور
  • از بین بردن پیچیدگی سرور و جلوگیری از بی مصرف ماندن سرور

مجازی سازی شبکه

مجازی سازی شبکه ساخت دوباره ی یک شبکه فیزیکی به صورت کامل و منطقی است. مجازی سازی شبکه این امکان را می دهد که برنامه ها دقیقا به همان صورت که در شبکه ی فیزیکی اجرا می شوند در یک شبکه مجازی اجرا شوند که فواید عملیاتی بهتر و استقلال سخت افزاری موجود در مجازی سازی را به همراه دارد. مجازی سازی شبکه، دستگاه ها و سرویس های شبکه را به صورت منطقی ارائه می کند (مانند سوئیچ، روتر، فایروال و vpn)

مجازی سازی دسکتاپ

استقرار دسکتاپ به عنوان یک سرویس مدیریت شده مجازی سازی دسکتاپ این امکان را می دهد که سازمان های IT در مقابل تغییر نیاز ها و فرصت های در حال ظهور سریعتر پاسخ دهند. برنامه ها و Desktopهای مجازی را می توان به سرعت در دسترس کارکنان سازمان قرار داد در حالی که مکان این کارکنان میتواند در داخل سازمان و یا اینکه دور از سازمان باشد. این کارکنان حتی می توانند از ipad و تبلت های اندرویدی خود برای دسترسی به این برنامه ها و desktopها استفاده کنند.

مجازی سازی در مقابل CLOUD COMPUTING

اگرچه مجازی سازی و  Cloud Computing هر دو تکنولوژی های فوق العاده ای هستند اما نمی توان آن ها را به جای هم نام برد و استفاده کرد. مجازی سازی یک راهکار نرم افزاری است که محیط محاسبات پردازشی را از زیرساخت های فیزیکی مستقل می کند، در حالی که Cloud Computing سرویسی است که با دریافت تقاضا منابع محاسباتی به اشتراک گذاشته (مانند نرم افزار یا اطلاعات) را از طریق اینترنت در دسترس دریافت کننده ی سرویس قرار می دهد. به عنوان یک راه حل تکمیلی، سازمان ها می توانند با مجازی سازی سرور های خود شروع کنند، سپس به سمت استفاده از Cloud Computing حرکت کنند تا کارایی بهتر و سرویس بهینه تری را داشته باشند.

منبع : فاراد

آشنایی با پروتکل stp

Spanning Tree Protocol

سوئیچ های سیسکو با استفاده از پروتکل STP، از به وجود آمدن loop در شبکه جلوگیری می کنند. در یک LAN که دارای مسیر های redundant می باشد، اگر پروتکل STP فعال نباشد، باعث به وجود آمدن یک loop نامحدود در شبکه می شود. اگر در همان LAN پروتکل STP را فعال کنید، سوئیچ ها برخی از پورت ها را بلاک می کنند و اجازه نمی دهند اطلاعات از آن پورت ها عبور کنند.


پروتکل STP با توجه به دو معیار پورت ها را برای بلاک کردن انتخاب می کند:
• تمامی deviceهای موجود در LAN بتوانند با هم ارتباط برقرار کنند. درواقع STP تعداد پورت های کمی را بلاک می کند تا LAN به چند بخش که نمی توانند با هم ارتباط برقرار کنند، تقسیم نشود.
• Frame ها بعد از مدتی drop می شوند و به طور نامحدود در loop قرار نمی گیرند.
پروتکل STP تعادلی را در شبکه به وجود می آورد بطوریکه frame ها به هر کدام از device ها که لازم باشد می رسند بدون اینکه مشکلات loop به وجود آید.
پروتکل STP با چک کردن هر interface قبل از اینکه از طریق آن اطلاعات ارسال کند، از به وجود آمدن loop جلوگیری می کند. در این روند چک کردن اگر آن پورت داخل VLAN خود در وضعیت STP forwarding باشد، از آن پورت در حالت عادی استفاده می کند، اما اگر در وضعیت STP blocking باشد، ترافیک تمام کاربران را بلاک می کند و هیچ ترافیکی در آن VLAN را از آن پورت عبور نمی دهد.
توجه کنید که وضعیت STP یک پورت، اطلاعات دیگر مربوط به پورت را تغییر نمی دهد. برای مثال با تغییر وضعیت خود تغییری در وضعیت trunk/access و connected/notconnect ایجاد نمی کند. وضعیت STP یک مقدار جدا از وضعیت های قبلی دارد و اگر در حالت بلاک باشد پورت را از پایه غیر فعال می کند.

نیاز به پروتکل STP
پروتکل STP از وقوع سه مشکل رایج در LANهای Ethernet جلوگیری می کند. در نبود پروتکل STP ، بعضی از frame های Ethernet برای مدت زیادی (ساعت ها، روز ها و حتی برای همیشه اگر deviceهای LAN و لینک ها از کار نیوفتند) در یک loop داخل شبکه قرار می گیرند. سوئیچ های سیسکو به طور پیش فرض پروتکل STP را اجرا می کنند. توصیه می کنیم پروتکل STP را تا زمانی که تسلط کامل به آن ندارید، غیر فعال نکنید.

اگر یک frame درloop قرار بگیرد Broadcast storm به وجود می آید. Broadcast storm زمانی به وجود می آید که هر نوعی از frameهای Ethernet  (مانند multicast frame،broadcast frame و unicast frameهایی که مقصدشان مشخص نیست) در loop بی نهایت داخل LAN قرار بگیرند. Broadcast stormها می توانند لینک های شبکه را با کپی های به وجود آمده از یک frame اشباع کنند و باعث از بین رفتن frameهای مفید شوند، و نیز با توجه به بار پردازشی مورد نیاز برای پردازش broadcast frameها، تاثیر قابل ملاحظه ای روی عملکرد deviceهای کاربران دارند.
تصویر 1-2 یک مثال ساده از Broadcast storm را نشان می دهد که در آن سیستمی که Bob نام دارد یک broadcast frame ارسال می کند. خط چین ها نحوه ارسال frameها توسط سوئیچ ها را در نبود STP نمایش می دهند.

 

در تصویر 1-2، frameها در جهت های مختلفی می چرخند، برای ساده تر شدن مثال فقط در یک جهت آنها را نمایش داده ایم.

در مفاهیم سوئیچ، سوئیچ ها در ارسال کردن broadcast farmeها، frameها را به تمام پورت ها به جز پورت فرستنده آن frame، ارسال می کنند. در تصویر 1-2، سوئیچ SW3، frame را به سوئیچ SW2 ارسال می کند، سوئیچ SW2 آن را برای سوئیچ SW1 ارسال می کند، سوئیچ SW1 نیز آن را برای SW3 ارسال می کند و به همین ترتیب این frame به سوئیچ SW2 ارسال می شود و داخل یک loop می چرخد.
زمانی که یک Broadcast storm اتفاق می افتد، frame ها مانند مثال بالا به چرخیدن ادامه می دهند تا زمانی که تغییراتی به وجود آید (شخصی یکی از پورت ها را خاموش کند، سوئیچ را reload کند یا کاری کند که loop از بین برود).
Broadcast storm همچنین باعث به وجود آمدن مشکل نا محسوسی به نام MAC table instability یا ناپیوستگی جدول مک می شود. MAC table instability بدین معنا است که جدول مک آدرس پیوسته در حال تغییر کردن می باشد، و علت آن این است کهframe هایی با مک آدرس یکسان از پورت های مختلفی وارد سوئیچ ها می شوند. به مثال زیر توجه کنید:
در تصویر 1-2 در ابتدا سوئیچ SW3 مک آدرس باب را که از طریق پورت Fa0/13 وارد سوئیچ شده، به جدول مک آدرس خود اضافه می کند:
0200.3333.3333 Fa0/13 VLAN 1
حالا فرایند switch learning را در نظر بگیرید در زمانی که frame در حال چرخش از سوئیچSW3 به سوئیچ SW2 ، سپس به سوئیچ SW1 و بعد از آن از طریق پورت G0/1 وارد سوئیچ SW3 می شود. سوئیچ SW3 می بیند که مک آدرس مبداء 0200.3333.3333 می باشد و از پورت G0/1 وارد سوئیچ شده است، جدول مک آدرس خود را به روز می کند:
0200.3333.3333 G0/1 VLAN 1
در این مورد سوئیچ SW3 هم دیگر نمی تواند به درستی frameها را به مک آدرس باب برساند. اگر در این حالت یک frame (خارج از frameهایی که در داخل loop افتاده اند) به سوئیچ SW3 برسد که مقصد آن باب باشد، سوئیچ SW3 اشتباها frame را روی پورت G0/1 به سوئیچ SW1 ارسال می کند، که این موضوع ترافیک زیادی را به وجود می آورد.
سومین مشکلی که Frame های در حال چرخش در یک broadcast storm ایجاد می کنند این است که کپی های مختلفی از یک frame به دست گیرنده می رسد. در تصویر 1-2 فرض کنید که باب یک frame را برای لاری ارسال کند در حالی که هیچ کدام از سوئیچ ها مک آدرس لاری را نمی دانند. سوئیچ ها frameها را به صورت unicast هایی که مک آدرس مقصدشان مشخص نیست، ارسال می کنند. زمانی که باب یک frame که مک آدرس مقصدش لاری است را ارسال می کند، سوئیچSW3 یک کپی از آن را به سوئیچ های SW1 و SW2 ارسال می کند. سوئیچ های SW1 و SW2 نیز frame را broadcast می کنند، این کپی ها باعث می شود که آن frame در داخل یک loop قرار گیرد. سوئیچ SW1 همچنین یک کپی از frame را به پورت Fa0/11 برای لاری ارسال می کند. در نتیجه لاری کپی های مختلفی از آن frame را دریافت می کند، که می تواند باعث از کار افتادن برنامه ای در سیستم لاری و یا مشکلات شبکه ای شود.

جدول زیر خلاصه ای از سه مشکل اساسی در شبکه ای که دارای redundancy است و STP در آن اجرا نمی شود را نشان می دهد:

پروتکل (STP (IEEE 802.1D دقیقا چه کار می کند؟
پروتکلSTP با قرار دادن هر یک از پورت های سوئیچ در وضعیت های forwarding و blocking از به وجود آمدن loop جلوگیری می کند. پورت هایی که در وضعیت forwarding هستند به صورت عادی فعالیت می کنند، frameها را ارسال و دریافت می کنند. اما پورت هایی که در وضعیت blocking قرار دارند به جز پیام های مربوط به پروتکل STP (و برخی دیگر از پیام هایی که برای پروتکل ها استفاده می شوند) ، هیچ frame دیگری را پردازش نمی کنند. این پورت ها frameهای کاربران را ارسال نمی کنند، مک آدرس frameهای ورودی را ذخیره نمی کنند و frameهای دریافتی از کاربران را نیز پردازش نمی کنند.
تصویر 2-2 راه حل استفاده از پروتکل STP (قرار دادن یکی از پورت های سوئیچ SW3 در وضعیت blocking) در مثال پیشین را نمایش می دهد:

همانطور که در مراحل زیر نشان داده شده، زمانی که باب یک broadcast را ارسال می کند، دیگر loop به وجود نمی آید:
• مرحله اول: باب frame را به سوئیچ SW3 ارسال می کند.
• مرحله دوم: سوئیچ SW3 این frame را فقط به سوئیچ SW1 ارسال می کند، دیگر به سوئیچ SW2 ارسال نمی شود چون پورت G0/2 در وضعیت blocking قرار دارد.
• مرحله سوم: سوئیچ SW1 این frame را روی پورت های Fa0/12 و G0/1 ارسال می کند.
• مرحله چهارم: سوئیچ SW2 این frame را روی پورت های Fa0/12 و G0/1 ارسال می کند.
• مرحله پنجم: سوئیچ SW3 به صورت فیزیکی یک frame را دریافت می کند، اما frame دریافتی از SW2 را به دلیل اینکه پورت G0/2 در سوئیچ SW3 در وضعیت blocking قرار دارد، نادیده می گیرد.
با استفاده از توپولوژی STP در تصویر 2-2، سوئیچ ها از لینک موجود بین SW2 و SW3 برای انتقال ترافیک استفاده نمی کنند. با این حال، اگر لینک بین SW3 و SW1 دچار مشکل شود، پروتکل STP پورت G0/2 را از وضعیت blocking به وضعیت forwarding تغییر می دهد و سوئیچ ها می توانند از آن لینکredundant استفاده کنند. در این موقعیت ها پروتکل STP با انجام فرایند هایی متوجه تغییرات در توپولوژی شبکه می شود و تشخیص می دهد که پورت ها نیاز به تغییر در وضعیتشان دارند و وضعیت آن ها را تغییر می دهد.

سوالاتی که احتمالا زهن شما را نیز مشغول کرده: پروتکل STP چگونه پورت ها را برای تغییر وضعیت انتخاب می کند و چرا این کار را می کند؟ چگونه وضعیت blocking را برای بهره مندی از مزایای لینک های redundant، به وضعیت forwarding تغییر می دهد؟ در ادامه به این سوالات پاسخ خواهیم داد.
پروتکل STP چگونه کار می کند؟
الگوریتم STP یک درخت پوشا (spanning tree) از پورت هایی که frameها را ارسال می کنند تشکیل می دهد. این ساختار درختی، مسیرهایی را برای رسیدن لینک های ethernet به هم مشخص می کند. (مانند پیمودن یک درخت واقعی که از ریشه درخت شروع می شود و تا برگ ها ادامه دارد)
توجه: STP قبل از اینکه در سوئیچ های LAN استفاده شود، در Ethernet bridgeها به کار رفته بود.
STP از فرایندی که بعضا spanning-tree algorithm)STA) نامیده می شود، استفاده می کند که در آن پورت هایی که باید در وضعیت forwarding قرار بگیرند را انتخاب می کند. STP پورت هایی که برای forwarding انتخاب نشدند را در وضعیت blocking قرار می دهد. در واقع پروتکل STP پورت هایی که در ارسال کردن اطلاعات باید فعال باشند را انتخاب می کند و پورت های باقی مانده را در وضعیت blocking قرار می دهد.
پروتکل STP برای قرار دادن پورت ها در حالت forwarding از سه مرحله استفاده می کند:
• پروتکل STP یک سوئیچ را به عنوان root انتخاب می کند و تمام پورت های فعال در آن سوئیچ را در وضعیت forwarding قرار می دهد.
• در هر کدام از سوئیچ های nonroot (همه ی سوئیچ ها به جز root)، پورتی که کمترین هزینه را برای رسیدن به سوئیچ root دارد (root cost)، به عنوان root port(RP) انتخاب می کند و آن ها را در وضعیت forwarding قرار می دهد.
• تعداد زیادی سوئیچ می توانند به یک بخش از Ethernet متصل شوند، اما در شبکه های مدرن، معمولا دو سوئیچ به هر لینک (بخش) متصل می شوند. در بین سوئیچ هایی که به یک لینک مشترک متصل هستند، پورت سوئیچی که root cost کمتری دارد در وضعیت forwarding قرار می گیرد. این سوئیچ ها را designated switch می نامند و پورت هایی که در وضعیت forwarding قرار گرفته را designated port)DP) می نامند.
باقی پورت ها در وضعیت blocking قرار می گیرند.

خلاصه ای از علت قرار گرفتن پورت ها در وضعیت های blocking و forwarding توسط پورتکل STP

Bridge و Hello BPDU
فرایند STA با انتخاب یک سوئیچ به عنوان root شروع می شود. برای اینکه روند انتخاب را بهتر متوجه شوید، شما باید با مفهوم پیام هایی که بین سوئیچ ها تبادل می شود به خوبی آشنا شوید و با فرمت شناساگری که برای شناسایی هر سوئیچ استفاده می شود آشنا باشید.
(STP bridge ID (BID یک مقدار 8 بایتی برای شناسایی هر سوئیچ می باشد. Bridge ID به دو بخش 2 بایتی که مشخص کننده اولویت و حق تقدم است و 6 بایتی که system ID نامیده می شود و همان مک آدرس هر سوئیچ است، تقسیم می شود. استفاده از مک آدرس این اطمینان را می دهد که bridge ID هر سوئیچ یکتا خواهد بود.
پیام هایی که برای تبادل اطلاعات مربوط به پروتکل STP بین سوئیچ ها استفاده می شود، bridge protocol data units )BPDU) نام دارد. رایج ترین BPDU ، که hello BPDU نام دارد، تعدادی از اطلاعات که شامل BID سوئیچ ها نیز می شود را لیست می کند و ارسال می کند. با استفاده از BID درج شده روی هر پیام، سوئیچ ها می توانند تشخیص دهند که هر پیام Hello BPDU از طرف کدام سوئیچ است.
جدول زیر اطلاعات کلیدی مربوط به Hello BPDU را نشان می دهد:

انتخاب سوئیچ root
سوئیچ ها با استفاده از BIDهای موجود در پیام های BPDU، سوئیچ root را انتخاب می کنند. سوئیچی که عدد BID آن مقدار کمتری را داشته باشد به عنوان سوئیچ root انتخاب می شود. با توجه به اینکه بخش اول عدد BID مقدار اولویت می باشد، سوئیچی که مقدار اولویت پایین تری داشته باشد به عنوان سوئیچ root انتخاب می شود. برای مثال اگر سوئیچ های اول و دوم به ترتیب دارای اولویت های 4096 و 8192 باشند، بدون در نظر گرفتن مک آدرس سوئیچ ها که در به وجود آمدن BID هر سوئیچ موثر است، سوئیچ اول به عنوان سوئیچ root انتخاب خواهد شد.
اگر مقدار اولویت دو سوئیچ برابر شد، سوئیچی که مک آدرس آن مقدار کمتری را داشته باشد به عنوان سوئیچ root انتخاب می شود. در این حالت به علت یکتا بودن مک آدرس، حتما یک سوئیچ انتخاب خواهد شد. پس اگر مقدار اولویت دو سوئیچ برابر باشد و مک آدرس آنها 0200.0000.0000 و 0911.1111.1111 باشد، سوئیچی که دارای مک آدرس 0200.0000.0000 است، به عنوان سوئیچ root انتخاب می شود.
مقدار اولویت مضربی از 4096 است و به صورت پیش فرض برای همه ی سوئیچ ها مقدار 32768 را دارد. از آنجایی که مک آدرس سوئیچ ها معیار مناسبی برای انتخاب سوئیچ root نمی باشد بهتر است به صورت دستی مقدار اولویت را تغییر دهیم تا سوئیچی که می خواهیم به عنوان سوئیچ root انتخاب شود.
در فرایند انتخاب سوئیچ root، سوئیچ ها از طریق فرستادن پیام های Hello BPDU که BID خود را در این پیام ها به عنوان root BID قرار داده اند، سعی می کنند خود را به عنوان سوئیچ root به سوئیچ های مجاور خود معرفی کنند. اگر یک سوئیچ پیامی را دریافت کند که BID کمتری نسبت به BID خودش داشته باشد، آن سوئیچ دیگر خود را به عنوان سوئیچ root معرفی نمی کند، به جای آن شروع به ارسال پیام دریافتی که دارای BID بهتری است می کند (مانند رقابت های انتخاباتی که یک نامزد به نفع نامزد هم حزبش که موقعیت بهتری دارد، از رقابت در انتخابات خارج می شود). در نهایت تمامی سوئیچ ها به یک نظر نهایی می رسند که کدام سوئیچ BID کمتری دارد و همه آن سوئیچ را به عنوان سوئیچ root انتخاب می کنند.
توجه : در مقایسه دو پیام Hello با هم، پیامی که BID کمتری دارد، superior Hello و پیامی که BID بیشتری دارد، inferior Hello نام دارد.

تصویر 3-2 آغاز فرایند انتخاب سوئیچ root را نشان می دهد، در ابتدای این فرایند SW1 همانند باقی سوئیچ ها خود را به عنوان سوئیچ root معرفی می کند. SW2 پس از دریافت Hello مربوط به SW1 متوجه می شود که SW1 شرایط بهتری را برای root بودن دارد، پس شروع به ارسال Hello دریافتی از SW1 می کند. در این حالت سوئیچ SW1 خود را به عنوان root معرفی می کند و SW2 نیز با آن موافقت می کند اما سوئیچ SW3 هنوز سعی می کند که خود را به عنوان سوئیچ root معرفی کند و Hello BPDUهای خود را ارسال می کند.

دو نامزد هنوز باقی ماندند:SW1 و SW3. از آنجایی که SW1 مقدار BID کمتری دارد، SW3 پس از دریافت BPDU مربوط به SW1، SW1 را به عنوان سوئیچ root می پذیرد و به جای BPDU خود، BPDU دریافتی از SW1 را به سوئیچ های مجاور ارسال می کند.

پس از اینکه فرایند انتخاب تکمیل شد، فقط سوئیچ root به تولید پیام های Hello BPDU ادامه می دهد. سوئیچ های دیگر این پیام ها را دریافت می کنند و BID فرستنده و root costرا تغییر می دهند و به باقی پورت ها ارسال می کنند. در تصویر 4-2، در قدم اول سوئیچ SW1 پیام های Hello را ارسال می کند، در قدم دوم سوئیچ های SW2 و SW3 به صورت مستقل تغییرات را روی پیام های دریافتی اعمال می کنند و آن ها را روی پورت های خود ارسال می کنند.
برای اینکه بخواهیم مقایسه BID را خلاصه کنیم، BID را به بخش های تشکیل دهنده ان تقسیم می کنیم، سپس به صورت زیر مقایسه می کنیم:
• اولویتی که کمترین مقدار را دارد
• اگر مقدار اولویت آن ها برابر باشد، سوئیچی که مک ادرسش کمترین مقدار را دارد

انتخاب Root Port برای هر سوئیچ
در مرحله ی بعدی، پس از انتخاب سوئیچ root، پروتکل STP برای سوئیچ های nonroot (همه ی سوئیچ ها به جز سوئیچ root) یک root port )RP) انتخاب می کند. RP هر سوئیچ، پورتی است که کمترین هزینه را برای رسیدن به سوئیچ root دارد.
احتمالا عبارت هزینه برای همه ی ما در انتخاب مسیر بهتر، روشن و مشخص باشد. اگر به دیاگرام شبکه ای که در آن سوئیچ root و هزینه ارسال اطلاعات روی هر پورت مشخص باشد توجه کنید، می توانید هزینه برقراری ارتباط با سوئیچ root را برای هر پورت به دست آورید. توجه کنید که سوئیچ ها برای به دست آوردن هزینه برقراری ارتباط با سوئیچ root، از دیاگرام شبکه استفاده نمی کنند، صرفا استفاده از آن برای درک این موضوع به ما کمک می کند.
تصویر 5-2 همان سوئیچ های مثال پیشین که در آن سوئیچ root و هزینه ی رسیدن به سوئیچ root را برای پورت های سوئیچ SW3 نشان می دهد.

سوئیچ SW3 برای ارسال frameها به سوئیچ root، می تواند از دو مسیر استفاده کند: مسیر مستقیم که از پورت G0/1 خارج می شود و به سوئیچ root می رسد، و مسیر غیر مستقیمی که از پورت G0/2 خارج می شود و از طریق SW2 به سوئیچ root می رسد. برای هر یک از پورت ها، هزینه ی رسیدن به سوئیچ root برابر است با مجموع هزینه ی خروج از پورت هایی که frame ارسالی، برای رسیدن به سوئیچ root از آن ها عبور می کند (در این محاسبه، هزینه ورود آن frame به پورت ها حساب نمی شود). همانطور که مشاهده می کنید، مجموع هزینه ی مسیر مستقیم که از پورت G0/1 سوئیچ SW3 خارج می شود برابر 5 است، و مسیر دیگر دارای مجموع هزینه ی 8 می باشد. از آنجایی که پورت G0/1، بخشی از مسیری است که هزینه ی کمتری برای رسیدن به سوئیچ root دارد، سوئیچ SW3 این پورت را به عنوان root port انتخاب می کند.
سوئیچ ها با سپری کردن فرایندی متفاوت به همین نتیجه می رسند. آنها هزینه خروج از پورت خود را به root cost موجود در Hello BPDU ورودی از همان پورت اضافه می کنند و هزینه رسیدن به سوئیچ root از طریق آن پورت را به دست می آورند. هزینه خروج از هر پورت در پروتکل STP یک عدد صحیح (integer) می باشد که به هر پورت در هر VLAN اختصاص می یابد، تا پروتکل STP با استفاده از این مقیاس اندازه گیری بتواند تصمیم بگیرد که کدام پورت را به توپولوژی خود اضافه کند. در این فرایند سوئیچ ها، root cost سوئیچ های مجاور را که از طریق Hello BPDUهای دریافتی به دست می آورند، بررسی می کنند.

تصویر 6-2 یک مثالی از چگونگی محاسبه بهترین root cost و سپس انتخاب آن به عنوان root port را نشان می دهد. اگر به تصویر توجه کنید، خواهید دید که سوئیچ root پیام هایی(Hello) که root cost آن ها برابر صفر می باشد را ارسال می کند. هزینه رسیدن به سوئیچ root از طریق پورت های سوئیچ root برابر با صفر است.
در ادامه به سمت چپ تصویر توجه کنید که سوئیچ SW3، root cost دریافتی از طریق SW1 را (که برابر صفر است) با هزینه ی خروج از پورت G0/1 که آن Hello را دریافت کرده (5) جمع می کند و هزینه ارسال اطلاعات از طریق این پورت را به دست می آورد.
در سمت راست تصویر، سوئیچ SW2 متوجه شده که root cost آن برابر با 4 است. پس زمانی که SW2 یک Hello برای SW3 ارسال می کند، مقدار root cost آن را 4 قرار می دهد. در سمت دیگرهزینه ارسال اطلاعات از طریق پورت G0/2 در سوئیچ SW3 برابر 4 است، از اینرو سوئیچ SW3 این دو مقدار را با هم جمع می کند و به این نتیجه می رسد که هزینه ی رسیدن به سوئیچ root از طریق پورت G0/2 برابر 8 است.
با توجه به نتایج به دست آمده از آنجایی که پورت G0/1 نسبت به پورت G0/2 هزینه ی کمتری برای رسیدن به سوئیچ root دارد، پس سوئیچ SW3 پورت G0/1 را به عنوان RP انتخاب می کند. سوئیچ SW2 نیزبا گذراندن همین فرایند پورت G0/2 را به عنوان RP انتخاب می کند. سپس تمام سوئیچ ها، root port های خود را در وضعیت forwarding قرار می دهند.

 

انتخاب Designated Port در هر LAN segment (پورت کاندید)
پس از انتخاب سوئیچ root، در سوئیچ های nonroot، تمام root portها را مشخص کردیم و آنها را در وضعیت forwarding قرار دادیم. مرحله نهایی پروتکل STP برای تکمیل توپولوژی STP، انتخاب designated port در هر LAN segment است. در هر بخش(segment) از LAN، پورت سوئیچی که کمترین root cost را دارد و به آن بخش از LAN متصل است Designated port )DP) نامیده می شود. زمانی که یک سوئیچ nonroot می خواهد که یک Hello را ارسال کند، هزینه رسیدن به سوئیچ root را در root cost آن پیام قرار می دهد و ارسال می کند. دراینصورت پورت سوئیچی که کمترین هزینه را برای رسیدن به root دارد، در میان تمام سوئیچ هایی که به آن بخش متصل هستند، به عنوان DP در آن بخش شناخته می شود. در این مرحله اگر هزینه سوئیچ ها برای رسیدن به سوئیچ root برابر بود، پورت سوئیچی که BID کمتری دارد را به عنوان DP انتخاب می کنیم.
در تصویر 4-2 پورت G0/1 در سوئیچ SW2 که به سوئیچ SW3 متصل است، به عنوان DP انتخاب می شود.
پس از انتخاب DPها، تمام آن ها را در وضعیت forwarding قرار می دهیم.
مثالی که در تصاویر 3-2 تا 6-2 به نمایش گذاشته شد، تنها پورتی که نیازی ندارد تا در وضعیت forwarding قرار بگیرد، پورت G0/2 در سوئیچ SW3 است. درنهایت فرایند پروتکل STP کامل شد و جدول زیر وضعیت نهایی هر پورت و علت قرار گرفتن در آن وضعیت را نشان می دهد:

 

 

به صورت خلاصه اگر بخواهیم توضیح دهیم، در فرایند اجرای پروتکل STP:
• در قدم اول سوئیچ root انتخاب می شود که ابتدا تمام سوئیچ ها سعی می کنند خود را به عنوان root معرفی کنند، سپس سوئیچی که رقم BID آن مقدار کمتری را داشته باشد به عنوان سوئیچ root انتخاب خواهد شد.
• در قدم دوم برای هر سوئیچ، پورتی که کمترین هزینه برای رسیدن به سوئیچ root دارد را به عنوان root port انتخاب می شود. سپس همه ی root portها را در وضعیت forwarding قرار می گیرند.
• در قدم سوم پورت های کاندید انتخاب می شوند و در وضعیت forwarding قرار می گیرند. در نهایت پورت هایی که وضعیتشان مشخص نشده در وضعیت blocking قرار می گیرند.

بروزرسانی به vSphere 6.7

با  منتشر شدن vSphere 6.7 به عموم مردم، طبیعی است که بحث های زیادی در اطراف ارتقا به آن وجود دارد. چگونه می توانیم ارتقا دهیم یا حتی چرا باید ارتقاء دهیم از سوالات پرطرفدار اخیرا بوده است. در این پست من این سؤالات و همچنین ملاحظاتی را که باید قبل از ارتقاء vSphere بررسی شود را پوشش خواهم داد. این ارتقاء دادن یک کار ترسناک یا غم انگیز نیست .

چرا ؟

خب بیاید با چرا شروع کنیم . چرا باید به vSphere 6.7 ارتقاء دهیم ؟ با VMware vSphere 6.7 سرمایه گذاری خود را در VMware تقویت می کنید. از آنجا که vSphere در قلب SDDC VMware قرار دارد ، ارائه و بنیاد ساختار اساسی برای استراتژی cloud  شما ارائه میکند ، ارتقاء دادن باید اولویت اصلی ذهن شما باشد اما تنها پس از دقت و توجه به ویژگی ها و مزایا و اینکه چگونه آنها را به نیازهای کسب و کار بر گردانید. شاید تیم های امنیتی برای یکپارچگی دقیق تر برای هر دو سیستم Hypervisor و سیستم عامل مهمان درخواست کرده باشد بنابراین استفاده از vSphere 6.7 و پشتیبانی از Trusted Platform Module (TPM) 2.0 یا Virtual TPM 2.0 اکنون مورد نیاز است. اگر امنیت نباشد ، شاید انعطاف پذیری برنامه ای در vSphere 6.7 که آن پیشرفت های تکنولوژی NVIDIA GRID ™ vGPU ، اجازه می دهد تا مشتریان قبل از vMotion آنرا را متوقف کند و از VM های فعال شده با vGPU خلاص شوند. صرف نظر از خود ویژگی ها، مهم این است که اطمینان حاصل شود ویژگی های مورد نیاز به طور مناسب به شرایط کسب و کار برمی گردند.

چرا

یکی دیگر از دلایل اینکه چرا باید ارتقاء پیدا کنیم به علت پایان پشتیبانی محصول یا کار آن است. اگر قبلا شنیده باشید، VMware vSphere 5.5 به سرعت به پایان عمر خود نزدیک می شود. تاریخ دقیق پایان کلی پشتیبانی برای vSphere 5.5  در روز 19 سپتامبر 2018 است. با در نظر داشتن این موضوع، ارتقاء باید در خط مقدم طرح های شما باشد. اما خبر خوب در مورد پایان سافتن vSphere 5.5 ، این است که VMware پشتیبانی عمومی از vSphere 6.5 را تا پنج سال کامل از تاریخ انتشار آن تا تاریخ 15 نوامبر 2021 گسترش داده است. اگر شما از من بپرسید این نکته بسیار شگفت انگیزی است. نقطه عطف بعدی درک چگونگی به ارتقاء به vSphere 6.5 /6.7 است که مشتریان را قادر می سازد تا مزایای یک راه حل نرم افزاری SDDC که کارآمد و امن است را داشته باشند .

 

چگونه

خب اجازه دهید در مورد چگونگی صحبت کنیم. چگونه ارتقا دهیم؟ برای شروع ، VMware انواع بسیاری از مستندات را برای کمک به نصب یا ارتقاء VMware vSphere با استفاده از VMware Docs فراهم می کند. سایت VMware Docs به رابط بسیار ساده تر که شامل قابلیت جستجو بهتر در نسخه ها و همچنین یک گزینه برای ذخیره اسناد در MyLibrary برای دسترسی سریع برای بعد به روز شده است . vSphere Central یک مخزن غظیم از منابع vSphere است از جمله وبلاگ ها، KB ها، فیلم ها، و walkthroughs ها که برای کمک به مشتریان است تا به سرعت اطلاعات مورد نیاز خود را پیدا کنند. بعدا، هر گونه راه حل VMware که با محیط شما مرتبط  باشد را بررسی کنید ، مانند مدیریت بازیابی سایت SRM)، Horizon View Composer) ، یا VMware NSX . قبل از شروع ، همچنین تعیین کنید که آیا تنظیم فعلی شما از معماری جاسازی شده یا خارجی برای SSO / PSC استفاده می کند، به این دلیل که ممکن است مسیر ارتقا شما را تحت تاثیر قرار دهد.

یک عامل کلیدی در کمک به اینکه چگونه به ارتقاء محیط vSphere بپردازد، بررسی در محدوده سازگاری های نسخه میباشد . همه نسخه های vSphere قادر به ارتقا به vSphere 6.7 نیستند. به عنوان مثال، vSphere 5.5 یک مسیر ارتقاء مستقیم را به vSphere 6.7 ندارد. اگر شما در حال حاضر vSphere 5.5 را اجرا می کنید، قبل از ارتقا به vSphere 6.7 ابتدا باید به vSphere 6.0 یا vSphere 6.5 ارتقا دهید. بنابراین قبل از اینکه شما به نصب جدیدترین نسخه vSphere 6.7 ISO خود بپردازید ، یکبار مسیر خود را اینجا انجام دهید و هر محیطی را که ممکن است در نسخه پایین تر از vSphere 6.0 اجرا کنید در نظر داشته باشید. قبل از شروع ارتقاء vSphere 6.7 ، این محیط قدیمی را به یک نسخه سازگار vSphere ارتقا دهید. پس از بحث درباره چگونگی ارتقاء، ما باید به طور طبیعی در مورد برنامه ریزی ارتقاء صحبت کنیم.

یادآوری:روش های پشتیبانی شده برای ارتقاء میزبان های vSphere شما عبارتند از: با استفاده از ESXi Installer، دستور ESXCLI از داخل (ESXi Shell، vSphere Update Manager (VUM و Auto Deploy.

برنامه ریزی

راز ارتقاء موفق با شروع برنامه ریزی شده است. ما درباره نحوه شروع آماده سازی برای ارتقاء vSphere با درک چگونگی و چرایی آن بحث کرده ایم. گام های منطقی بعدی شروع برنامه ریزی است. این جایی است که شما خود را در حال بررسی یافته ها در محیط خود و همچنین جمع آوری فایل های نصب و راه اندازی آنها برای ارتقاء. آماده میکنید .   بسیار مهم است  که ترتیب و مراحل سایر محصولات VMware را مشخص کنید بنابراین شما کاملا درک می کنید که باید قبل یا بعد از vCenter Server و ESXi باید چه کنید.   ارتقاء برخی محصولات غیرمجاز ممکن است نتایج بدی داشته باشد که می تواند یک مشکل را در برنامه ارتقاء شما قرار دهد. برای مشاهده جزئیات بیشتر با بررسی vSphere 6.7 Update Sequence KB Article شروع کنید. در طول برنامه ریزی مشتریان باید تمام محصولات ، نسخه ها و واحدهای تجاری را در نظر بگیرند که ممکن است در طول و یا بعد از ارتقاء تحت تاثیر قرارگیرند. برنامه ریزی باید شامل تست آزمایشگاهی ارتقا باشد تا اطمینان حاصل شود که روند و نتایج را درک کنید. انجام یک بررسی سلامتی vSphere ممکن است بهترین پیشنهادی باشد که میتوانم بدهم . ارزیابی vSphere می تواند به کشف منابع هدر رفته، مشکلات محیطی و حتی مواردی ساده مانند تنظیم نادرست NTP یا DNS کمک کند. در نهایت تمام اطلاعات محاسباتی ، ذخیره سازی  ، شبکه ایی و بک آپ های vendors را برای سازگاری با vSphere 6.7 جمع آوری کنید. هیچ چیز بدتر از آن نیست که بعد از ارتقاء محیط خود متوجه شوید که یک rd party vendor3 نسخه سازگار با vSphere را ارائه نکرده باشد.

ملاحظات ارتقاء

برای کمک بیشتر به مشتریان در ارتقاء vSphere ، من مجموعه کاملی از ملاحظات ارتقا را برای کمک به شما در شروع برنامه ارتقاء به vSphere 6.7. جمع آوری کرده ام.

ملاحظات vSphere

از آنجا که vSphere پایه ای برای SDDC است، بسیار مهم است که قابلیت همکاری آن را با نسخه های فعلی نصب شده در پایگاه داده های شما بررسی شود .

  • An Upgrade from vSphere 5.5 to vSphere 6.7 GA directly is currently not supported
  • vSphere 6.0 will be the minimum version that can be upgraded to vSphere 6.7
  • vSphere 6.7 is the final release that requires customers to specify SSO sites.
  • In vSphere 6.7, only TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default.
  • Due to the changes done in VMFS6 metadata structures to make it 4K aligned, you cannot upgrade a VMFS5 datastore inline or offline to VMFS6, this stands true for vSphere 6.5 & vSphere 6.7. (See KB2147824)

ملاحظات سرور vCenter

(vCenter Server Appliance (VCSA  در حال حاضر به طور پیش فرض برای سرور vCenter استفاده می شود. vCenter Servers topology deployment   باید در مرکز برنامه ریزی ارتقاء vSphere شما باشد. چه از یک (external Platform Services Controller (PSC  یا embedded  استفاده کنید ، به یاد داشته باشید که توپولوژی را نمی توان در vSphere 6.0 یا 6.5 تغییر داد. اگر از vSphere 5.5 ارتقا می دهید ، تغییرات توپولوژی و ادغام SSO Domain Consolidation پشتیبانی می شود ، اما قبل از ارتقا به vSphere 6.x باید انجام شود.

  • The vSphere 6.7 release is the final release of vCenter Server for Windows. After this release, vCenter Server for Windows will not be available
  • vCenter Server 6.7 does not support host profiles with version less than 6.0 (See KB52932)
  • vCenter Server 6.7 supports Enhanced Linked Mode with an Embedded PSC (Greenfield deployments only)
  • If vCenter High Availability (VCHA) is in use within your vSphere 6.5 deployment, you must remove the VCHA configuration before attempting an upgrade.

 

معیارهای سازگاری محصولات VMware

گاهی اوقات با انتشار نرم افزارهای جدید، دیگر محصولاتی که بر پایه اجزای ارتقا یافته قرار دارند، ممکن است در روز از اول محصولات GA کاملا پشتیبانی نشوند یا سازگار نباشند. راهنمای سازگاری VMware باید یکی از اولین توقف های شما در طول  مسیر ارتقاء vSphere باشد. با استفاده از این راهنما ها مطمئن میشوید که اجزای شما و همچنین مسیر ارتقاء مورد نظر شما ، پشتیبانی می شود.

با این محصولات زیر در حال حاضر سازگار با vSphere 6.7 GA نیستند.

  • VMware Horizon
  • VMware NSX
  • VMware Integrated OpenStack (VIO)
  • VMware vSphere Integrated Containers (VIC)

ملاحظات سخت افزاری

ارتقاء vSphere نیز می تواند توسط سخت افزار ناسازگار متوقف شود . با توجه به این موضوع، قبل از ارتقاء ، بایستی BIOS سخت افزار و سازگاری پردازنده را بررسی و مشاهده کنید. برای مشاهده لیست کامل CPU های پشتیبانی نشده، مقالهvSphere 6.7 GA Release Notes  منتشر شده در بخشی تحت عنوان “Upgrades and Installations Disallowed for Unsupported CPUs“ را مرور کنید.

  • vSphere 6.7 no longer supports certain CPUs from AMD & Intel
  • These CPUs are currently supported in the vSphere 6.7 release, but they may not be supported in future vSphere releases;
    • Intel Xeon E3-1200 (SNB-DT)
    • Intel Xeon E7-2800/4800/8800 (WSM-EX)
  • Virtual machines that are compatible with ESX 3.x and later (hardware version 4) are supported with ESXi 6.7
  • Virtual machines that are compatible with ESX 2.x and later (hardware version 3) are not supported

سازگاری سخت افزار و نسخه hypervisor و سطح ماشین مجازی باید به عنوان بخشی از برنامه ریزی شما نیز در نظر گرفته شود. به یاد داشته باشید نسخه سخت افزاری VM اکنون به عنوان سازگاری VM شناخته می شود. توجه: ممکن است لازم باشد سازگاری ماشین مجازی را قبل از استفاده از آن در vSphere 6.7 ارتقا دهید.

 

جمع بندی

جهت یاد آوری باید خاطر نشان کنیم که بخش چرا و چگونه را با تمرکز و دقت بالا مطالعه کنید. بدون داشتن تمرکز بر اینکه چه چیزی ارتقاء را در شرایط رضایت بخش به ارمغان می آورد یا درک تمام مزایای یکپارچه، در حقیقت آنها به راحتی می توانند از بین بروند. برنامه ریزی بخش بسیار مهم در مسیر ارتقاء است و بدون برنامه ریزی ممگن است در سازگاری ورژن ها به مشکل بر بخورید. اجرا ؛ بدون داشتن تمرکز و درک ویژگی ها یا روش ها و همچنین برنامه ریزی پیاده سازی ارتقاء vSphere ، شما قادر نخواهید بود که با موفقیت این کار را انجام دهید.

پس به یاد داشته باشید : تمرکز، برنامه ریزی، اجرا !

منبع

Fault Tolerance چیست؟

FT یا Fault Tolerance قابلیتی است که به شما ویژگی های دسترس پذیری بالاتر و محافظت بیشتری از ماشین ها ، در مقایسه با زمانی که از قابلیت HA  استفاده میکنید ، ارائه میکند. از نکات منفی قابلیت HA زمان بر بودن بازگشت از Failover و داشتن Down Time است. FT از ورژن 4 معرفی شد اما تا ورژن 6 استفاده نمیشد.

نحوه کار FT

FT فقط برای ماشین هایی با درجه اهمیت بسیار بالا ، با ساختن یک ماشین یکسان دیگر از آن و دردسترس قرار دادن آن برای استفاده در زمان های Failover عمل میکند. به ماشینی که توسط این قابلیت محافظت میشود Primary و به ماشین دوم که یک  Mirror از آن است Secondary میگویند. این دو ماشین به طور متناوب وضعیت یکدیگر را زیرنظر میگیند . در زمانی که هاست ماشین Primary از دسترس خارج شود ، ماشین Secondary به سرعت فعال و جایگزین آن میشود و یک ماشین Secondary دیگر ایجاد و وضعیت FT به حالت طبیعی باز میگردد ، و زمانی که هاست ماشین Secondary از دسترس خارج شود یک ماشین Secondary دیگر جایگزین آن میشود. در هر دو حالت کاربر هیچ وقفه ایی در کار ماشین احساس نمیکند و دیتایی از بین نمیرود.

به منظور اطمینان از در دسترس بودن حداقل یکی از ماشین ها ، ماشین Primary و Secondary نمیتوانند هم زمان در یک هاست حضورداشته باشند . همچنین FT از فعال بودن هر دو ماشین در زمان برگشت از وضعیت Failover به منظور جلوگیری از “split-brain” محافظت میکند.

 

موارد استفاده Fault Tolerance

زمانی که ماشین Secondary فعال شده و نقش ماشین Primary را اجرا میکند ، وضعیت ماشین به طور کامل بازیابی میشود ، یعنی محتویات رم ، برنامه های در حال اجرا و وضعیت پردازشی بدون هیچ تاخیر و نیاز به Load مجدد .به عنوان مثال از این قابلیت برای زمانی که سرویسی داریم که نیاز داریم تمام مدت ، بدون هیچ تاخیری در حال اجرا باشد ، استفاده میشود.

 

نیازمندی ها و محدودیت های Fault Tolerance

CPU هاست ها باید با  V-motion و یا Enhanced V-motion سازگار باشد و از MMU پشتیبانی کند و حتما از شبکه 10G در بستر شبکه استفاده شود. در هر هاست حداکثر تا 4 ماشین را میتوان توسط FT محافظت کرد (هر دو Primary و Secondary شمارش میشوند) اما میتوان این محدودیت را از طریق Advanced Option افزایش داد.

تا آن زمان فقط ماشین هایی که یک هسته CPU داشتند را میتوانستید توسط FT محافظت کنید اما اکنون تا چهار هسته CPU را میتوان محافظت کرد .

در ورژن 6 به بعد ، دیسک ماشین Secondary میتواند روی LUN دیگری در Storage دیگر باشد زیرا دو ماشین در حال Sync شدن هستند . ماشین Secondary برای اپدیت شدن وضعیت اش باید محتویات Memory و CPU را سینک کند  ،   برای  اینکار  باید پورت Vm kernel network ایی داشته باشیم . به همین دلیل VMware توصیه میکند برای پورت فیزیکی از کارت 10G ستفاده شود.

 

قالبیت ها و Device هایی که با این ویژگی از دست خواهید داد:

  • از ماشینی که FT enabled میشود نمیتوان Snapshot گرفته و Snapshot های قبلی را باید حذف کرد.
  • ماشینی که FT enabled میشود نباید Linked clone باشد و نمیتوان از خود آن هم Linked clone گرفت.
  • قابلیت VMCP را برای ماشین نمیتوان فعال کرد.
  • I\O filters
  • Virtual Volume data store
  • Storage-based policy management
  • Physical Raw Disk mapping (RDM)
  • CD-ROM or floppy virtual devices
  • N Port ID Virtualization (NPIV)
  • USB and sound devices
  • NIC pass through
  • Hot-plugging devices
  • Serial or parallel ports
  • Video devices that have 3D enabled
  • Virtual EFI firmware
  • Virtual Machine Communication Interface (VMCI)
  • 2TB+ VMDK

 

نکته : به منظور افزایش Availability میتوانید از FT در کنار قابلیت DRS ، فقط زمانی که ویژگی EVC فعال شده باشد استفاده کنید.

  

قبل از فعال کردن FT مطمئن شوید که :

  • ماشین و هاست های شما شرایط لازم برای فعال کردن FT را دارند
  • وضعیت شبکه هر هاست را بررسی کنید
  • کارت شبکه V-motion بررسی شود
  • کلاستر HA ایجاد و فعال شود
  • CPU شما پشتیبانی شود
  • HV در تنظیمات BIOS هاست فعال باشد
  • فایل های ماشین ها در فضای Shared storage باشد
  • حداقل 3 هاست داشته باشید
  • حداکثر تا 4 هسته را میتوان FT کرد
  • ماشین هایی که FT enabled میشود Snapshot  نداشته باشد
  • VMware tools نصب باشد
  • EVC در صورت نیاز فعال باشد
  • هیچ گونه Removable Media نداشته باشد
  • FT دوبرابر شرایط معمول منابع مصرف میکند
  • توصیه میشود کارت شبکه 10G dedicated استفاده شود
  • CPU و Memory قابلیت Hot plug نداشته باشد
  • هر هاست نهایتا تا 8 هسته FT شده میتواند داشته باشد

برای مثال : با 3 هاست ، 3 ماشین 4 کور میتوانیم داشته باشیم (ماشین Secondary هم حساب میشود)

 

فعال کردن قالبیت FT :

ابتدا یک کارت شبکه اختصاصی میسازیم ، برای اینکار به تب VM kernel adapter رفته و کارت شبکه اضافه میکنیم ، سپس برروی ماشینی که میخواهیم محافظت شود راست کلیلک کرده و Fault tolerance را فعال میکنیم ، پس از آن پنجره ای باز میشود که از ما محل ماشین دوم ، محل دیسک و بعد هاست را انتخاب مکنید و در نهایت Finish را انتخاب میکنیم.

پس از فعال کردن FT رنگ آیکون ماشین به آبی تغیر رنگ میدهد. برای تست FT و اطمینان از عملکرد صحیح آن میتوانید از گزینه  Test Failover استفاده کنید.

vmware vapp چیست؟

Vapp یک Object  است که  اسمش ما را به یاد  Application Vitrtualization  می اندازد اما در اصل ارتباطی با آن ندارد . Vapp در واقع یک Resource Pool  است که feature های اضافه ایی را به ما میدهد . از مهم ترین این ویژگی ها میتوان به  Start up و  Shut down order اشاره کرد .

نکته : برای بهره مندی از این امکان ، باید در سطح کلاستر قابلیت DRS فعال شده باشد.

علت نام گذاری این ویژگی آن است که ، زمانی که ما چند ماشین مجازی داریم که آنها با ارتباط و همکاری یکدیگر سرویسی را ارائه میکنند که به عنوان یک اپلیکشن ارائه میشود ، به عنوان مثال چند ماشین داریم که سرویس اتوماسیون را ارائه میکنند . در نتیجه تنظیمات Resource آنها با یکدیگر مربوط و دستورات روشن یا خاموش شدن این ماشین ها در ارتباط با هم است. به این دلیل یک Vapp میسازیم و این ماشین ها را داخل آن قرار میدهیم . (برای ساخت Vapp میتوان از یک Vapp موجود هم Clone گرفت)

Vapp ها حالت Container دارند ، یعنی ماشین داخل آن اضافه میشوند .

همچنین میتوان یک Vapp را مانند یک ماشین معمولی روشن ، خاموش و یا ری استارت کرد.

تنظیماتی که میتوان با کمک Vapp  اعمال کرد شامل : کنترل ترتیب روشن یا خاموش شدن ماشین ها  و تنظیمات  Resource Pool  و قابلیت   IP Allocation میباشد.

Vapp ها در سطح Host and Clusters view و Template view نمایش داده میشوند.

نکته : اولویت خاموش شدن ماشین ها ، برعکس اولویت روشن شدنی است که تنظیم کرده اید !

نکته : در صورت حذف کردن Vapp ، اگر داخل آن ماشینی  وجود داشته باشد ، آن ماشین ها نیز حذف خواهند شد . (Delete From Disk)

همانطور که بیان شد Vapp در سناریوهای بازگشت از حادثه (disaster recovery scenarios) ، زمانی که میخواهید به صورت خودکار و سریع تعداد زیادی ماشین وابسته به یکدیگر را با یک کلیک یا دستور روشن کنید ، کارآمد هستند.

DRS چیست ؟

Distributed Resource Scheduler یا به اختصار DRS ابزاری است که وضعیت هاست های فیزیکی ما را از نظر میزان منابع زیر نظر میگیرد و براساس آن ماشین های مجازی را به نحوی در بین هاست ها جابجا میکند تا منابع تمام هاست به طور بهینه و یکسان مورد استفاده قرار گیرد و چنانچه ماشین های مجازی یک هاست با کمبود منابع مواجه شوند با انتخاب بهترین هاست از نظر منابع کافی ، ماشین را به آن هاست منتقل میکند.

همانطور که قبلا اشاره شد ، اینFeather  یکی از ویژگی های Cluster است و برای فعال کردن آن باید Cluster داشته باشیم.

ویژگی های کلاستر :

  • HA
  • DRS
  • EVC
  • VSAN
  • FT

DRS:

این ویژگی هاست های ما را از نظر میزان مصرف RAM و CPU ، و در ورژن 6.5 از نظر Network ، Load balance میکند . معمولا این Feather را در کنار گزینه های دیگر مانند HA و یا FT ، به منظور بهره وری هرچه بیشتر از قابلیت های vSphere فعال میکنند.

این ویژگی از طریق V-motion عمل مکیند و در دو زمان بخصوص اعمال میشود:

  • زمانی که یک ماشین درحال روشن شدن است ، بهترین هاست برای روشن شدن ماشین در آن را انتخاب میکند
  • زمانی که Load هاست های ما به هم میریزد

با انتخاب گزینه Manual ، چه در زمان روشن شدن ماشین و چه در زمان بهم ریخت Load هاست ها ، به ما فقط Recommends میدهد و خود ما باید دستور جابجایی ماشین ها را صادر کنیم.

با انتخاب گزینه Fully automated  در هر دو حالت به صورت خودکار جابجایی اعمل میشود .

و با انتخاب گزینه Partially automated ، در زمان روشن شدن ماشین جابجایی به صورت خودکار انجام میشود ، اما زمانی که Load  هاست ها بهم میریزد ، به ما Recommend میدهد و خود ما باید دستور جابجایی ماشین ها را صادر کنیم.

شما میتوانید Role هایی تنظیم کنید تا به عنوان مثال دو ماشین (DC) که سرویس های Parallel ارائه میکنند هم زمان در یک هاست نباشند و یا نرم افزاری که Database ایی دارد که باید درکنار ماشین خودش باشد ، در یک هاست قرار بگیرد و یا ماشینی که دانگل دارد و باید در یک هاست بخصوصی باشد .

در این Role ها 4 حالت به تفکیک ذیل داریم :

  • Must
  • Must not
  • Should
  • Should not

نکته : گزینهShould  به عنوان توصیه و گزینه Must حالت اجبار دارد.

Predictive DRS:

اگر شما نرم افزار vRealize را داشته باشید ، این نرم افزار طبق گزارشات خود اطلاع دارد که به عنوان مثال شنبه 8 صبح Domain Controller ، Load زیادی دارد پس وضعیت آنرا Normal در نظر میگیرد. Predictive DRS از اطلاعات Historical این نرم افزار استفاده میکند و زمان هایی که میداند الگوی Load هاست به زودی تغییر می کند ، قبل از رسیدن به آن زمان مشخص ، در صورت نیاز ماشین را جابجا میکند تا دچار Bottleneck نشود.

EVC:

قابلیت Enhanced vMotion Compatibility یا EVC ، پردازشگر های هم برند اما غیر هم خانواده را با هم Compatible میکند تا بتوانیم V-motion و FT را فعال کنیم. این گزینه یک لایه نرم افزاری یا Mask را بین VCPU و PCPU  اعمال میکند. (در سری سرورهای G8 و G9 نیازی به فعال کردن این گزینه ندارید)

نکته: زمان روشن بودن ماشین ها نمیتوانید این گزینه را فعال کنید . بهتر است هنگام راه اندازی بستر این گزینه فعال شود.

 

از طریق لینک زیر میتوانید لیست خانواده CPU هایی که با یکدیگر سازگاری دارند را مشاهده کنید :

https://www.vmware.com/resources/compatibility/search.php?deviceCategory=cpu