بررسی طراحی دیتاسنتر 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 را به اجرا در می آورد
0 پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *