پس از معرفی راهکار Cisco ACI توسط شرکت سیسکو به عنوان تکنولوژی SDN در مراکز داده و دیتاسنترها، این راهکار مورد استقبال سازمان­‌های مختلف قرار گرفت. این استقبال روزافزون موجب شد تا شرکت سیسکو در نسخه‌های جدید Cisco ACI قابلیت‌های بیشتری را به خصوص در زمینه ارتباطات بین مرکز داده‌ها در نقاط مختلف جغرافیایی ایجاد کند.
همانگونه که در دیاگرام زیر مشخص شده است، ACI Multi-Pod و ACI Multi-Site دو معماری و مدل پیاده‌سازی ارتباط بین مراکز داده است. با توجه به شباهت‌های زیاد این دو مدل پیاده‌سازی، در این مقاله به توضیح و مقایسه این دو قابلیت در راهکار Cisco ACI خواهیم پرداخت.

لغت‌شناسی

به منظور مقایسه و شناخت درست این دو قابلیت در راهکار Cisco ACI، لازم است درک درستی از اصطلاحات موجود در این راهکار ایجاد شود؛ به همین منظور در ادامه برخی از این اصطلاحات شرح داده شده است.

• اصطلاح Pod در Cisco ACI: به مجموعه‌ای از تجهیزات زیرساختی Leaf و Spine که دارای یک Control Plane هستند Pod گفته می‌شود. مفهوم Control Plane مشترک شامل تمامی پروتکل‌های ISIS ،MP-BGP و COOP و... است.
• اصطلاح Fabric در Cisco ACI: به مجموعه­‌ای از سوئیچ‌های Spine و Leaf و تمامی تجهیزاتی که توسط یک کلاستر از کنترلر­های APIC مدیریت می‌شوند یک Fabric گفته می‌شود. هر Fabric می‌تواند دارای چندین Pod به صورت مجزا باشد.
• اصطلاح Site در Cisco ACI: به هر Fabric که توسط کلاستر کنترلر APIC منحصر خود مدیریت می­شود یک Site گفته می‌شود، در واقع مفهوم Fabric و Site هم‌ارز یکدیگر هستند.

Cisco ACI Multi-Pod چیست؟

معماری Cisco ACI Multi-Pod به قابلیت گسترش Fabric موجود بدون نیاز به ایجاد Fabric جدید گفته می‌شود. یک ACI Fabric در وضعیت Multi-Pod می‌تواند شامل 2 تا 12 Pod باشد که با استفاده از یک بستر ارتباطی Inter-Pod Network متصل بوده و تحت مدیریت یک کلاستر از کنترلرهای APIC قرار دارند.

قابل ذکر است در نسخه‌های قبلی تکنولوژی Cisco ACI، معماری‌ای به نام Stretched Fabric موجود است، که در آن امکان ارتباط توپولوژی دیگری از Spine-Leaf را که در نقطه جغرافیایی متفاوتی قرار دارد با استفاده از سوئیچی به نام Transit Leaf فراهم می‌کند. اگرچه در بررسی به نظر می‌آید این مدل از طراحی نیز شبیه به معماری Multi-Pod است، ولی در حقیقت این مدل از طراحی دارای محدودیت‌های بسیاری در مقایسه با Cisco ACI Multi-Pod می‌باشد.

معماری و قابلیت‌های Cisco ACI Multi-Pod

معماری Multi-Pod باعث ایجاد قابلیت­ انعطاف‌پذیری در لایه شبکه برای سازمان‌ها می‌شود. این معماری با ایجاد Podهای مختلف که از لحاظ مدیریتی همچنان تحت مدیریت یک Fabric قرار دارند موجب می‌شود تا سازمان‌ها راهکار و روشی آسان برای گسترش مراکز داده و دیتاسنتر­های خود با کمترین بار کاری مدیریتی را داشته باشند.

بررسی ارتباطات در معماری ACI Multi-Pod

تمامی Podهای موجود در یک Fabric می‌بایست با استفاده از یک بستر IP Routed که به آن Inter-Pod Network و یا IPN گفته می‌شود متصل باشند. این شبکه IPN توسط کنترلر­های APIC مدیریت نمی‌شود و لازم است تا به صورت مستقیم توسط کاربر پیکربندی شود. محل اتصال ارتباطی این شبکه، سوئیچ‌های Spine هستند.

اگرچه پیشنهاد می‌شود به منظور افزایش پهنای باند بین دو Pod، ارتباطات IPN توسط تمامی سوئیچ‌های Spine برقرار شود، اما امکان برقراری ارتباط از طریق تنها یک Spine هم فراهم است. تمامی ترافیک‌های بین Pod با استفاده از پروتکل VXLAN کپسوله شده و با توجه به استفاده از پروتکل Multicast برای ارسال برخی از داده‌ها لازم است بستر انتخاب‌شده برای IPN از PIM Bidirectional پشتیبانی کند.

بیشتر بخوانید: معرفی پروتکل VXLAN در تکنولوژی Cisco ACI

اطلاعات مربوط به Control-Plane شامل تبادل اطلاعات مربوط به کاربران نهایی در هر Pod که امکان برقراری ارتباط بین Endpointها در Podهای مختلف را فراهم می‌سازد توسط پروتکل MP-BGP کنترل و مدیریت می‌شود. در دیاگرام زیر نحوه چگونگی این ارتباطات نمایش داده شده است.

سادگی در مدیریت

همانگونه که در ابتدا گفته شد، در معماری Cisco ACI Multi-Pod تمامی Podهای ایجاد شده تحت مدیریت یک کلاستر از کنترلر­های APIC قرار دارند و این موضوع به معنای وجود یک دامنه مدیریتی واحد است. این امر علاوه بر سادگی در مدیریت، موجب شده تا امکان پراکنده شدن کنترلرهای APIC موجود در کلاستر در Podهای مختلف فراهم شود، در نتیجه یک کلاستر APIC می‌تواند دارای کنترلرهایی در مناطق مختلف جغرافیایی باشد.

یکی از مثال‌های خوب برای مدیریت آسان در این معماری، امکان ایجاد یک EPG در هریک از Podها و استفاده از آن در سایر Podها است. این قابلیت باعث می‌شود تا انعطاف زیادی در راه‌اندازی ماشین‌های مجازی، Containerها و... در اختیار مدیران شبکه قرار گیرد. همچنین ایجاد محدودیت برای دامنه پیکربندی‌ها (برای مثال ایجاد تغییرات فقط در یک Pod) نیز فراهم است.

تحمل خطا

درست است که معماری Cisco ACI Multi-Pod به روی یک Fabric ایجاد می‌شود، ولی با توجه به اینکه هر یک از Podها دارای Control-Plane مجزا هستند، بنابراین در صورت بروز خطا در وضعیت Control-Plane یکی از Podها، مشکلی برای ارتباطات در سایر Podها ایجاد نخواهد شد.

موارد استفاده از معماری Cisco ACI Multi-Pod

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

شرکت‌های تأمین‌کننده سرویس نیز می‌توانند از این معماری در شکل‌های مختلف استفاده کنند. به طور مثال، یک Pod برای مصارف داخلی سازمان و یک Pod برای ارائه به مشتریان در نظر گرفته شود. در اینصورت نیاز به ایجاد بستر فیزیکی مجزا برای این دو نیست و علاوه بر آن از یک مدیریت واحد بهره خواهند برد.

بسیاری از سازمان‌ها به منظور راه‌اندازی مرکز داده پشتیبان با چالش مدیریتی پس از راه‌اندازی دو مرکز داده روبرو هستند. استفاده از این معماری برای سازمان‌هایی که نیاز به دیتاسنتر پشتیبان دارند موجب می‌شود با استفاده از امکان مدیریت واحد و کاهش تداخل پیکربندی در تیم‌های مختلف، شاخص‌های Disaster Recovery همچون RTO و RPO را به میزان قابل توجهی کاهش دهند.

Cisco ACI Multi-Site چیست؟

معماری Multi-Site شامل دو یا تعدادی بیشتر Fabric است که هر یک از این Fabricها دارای کلاستر کنترلر APIC مجزا هستند و همگی با استفاده از Cisco ACI Multi-Site Orchestrator مدیریت می‌شوند. هر یک از سایت‌های ACI دارای توپولوژی Spine-Leaf منحصر به فرد و کلاستر کنترلر APIC منحصر هستند.

معماری Cisco ACI Multi-Site در پاسخ به نیاز ایزوله شدن کامل در لایه شبکه و Tenant ایجاد و طراحی شد. این مدل طراحی دارای معماری و موارد استفاده منحصر به فردی نسبت به مدل Multi-Pod است.

معماری و قابلیت‌های Cisco ACI Multi-Site

در توپولوژی Multi-Site هر سایت یا Fabric به عنوان یک Availability Zone در نظر گرفته می‌شود. تمامی این Availability Zone توسط مدیریت منسجم یک Multi-Site Orchestrator قرار خواهند داشت.

اساس این معماری بر این اصل استوار است که در صورت اتفاق هر رویدادی چه در سطح شبکه و سرویس، بر روی هریک از Availability Zoneها هیچ تأثیری نخواهد گذاشت. این اصل تداوم سرویس را در سازمان‌ها تضمین می‌کند.

بررسی ارتباطات در معماری ACI Multi-Site

ارتباطات میان سایت‌های مختلف از طریق لینک‌های Routed متصل به سوئیچ‌های Spine که در اصطلاح Inter-Site Network یا ISN است برقرار می‌شود. همانند معماری Multi-Pod تمامی ترافیک‌ها توسط پروتکل VXLAN کپسوله شده و با استفاده از MP-BGP ارتباطات کنترل می‌گردد. یکی از تفاوت‌های این معماری با معماری Cisco ACI Multi-Site عدم نیاز به پشتیبانی از ارتباطات Multicast است.

نظارت کلی با نرم‌افزار Cisco Orchestration

یکی از اجزای جدید اضافه‌شده در معماری Cisco ACI Multi-Site، پلتفرم Multi-Site Orchestration است. این پلتفرم که به اختصار MSO نامیده می‌شود، کلاستری از ماشین‌های مجازی است که به روی زیرساخت Docker راه‌اندازی شده است. وظیفه اصلی این پلتفرم ایجاد نقطه مرکزی جهت مانیتورینگ و پایش سلامت سایت‌های موجود ACI و انجام پیکربندی به روی چندین سایت به صورت همزمان است. یکی از قابلیت‌های قابل توجه این پلتفرم، امکان پیاده‌سازی آن به روی بسترهای ابری عمومی مانند Azure و AWS است.

پلتفرم MSO به منظور اجرای پیکربندی‌های مختلف در Cisco ACI می‌تواند قالب‌های پیش‌فرض استفاده کند. این نوع پیکربندی باعث می‌شود تا فعالیت‌هایی نظیر ایجاد اشیا مشابه در تمامی سایت‌ها با صرف زمان و بار مدیریتی کمتری انجام شود.

موارد استفاده از معماری Cisco ACI Multi-Site

با توجه به توضیحات ارائه‌شده در خصوص این معماری و قابلیت‌های آن، می‌توان یکی از اصلی‌ترین کاربرد­های آن را استفاده در دیتاسنتر­های Active-Active نام برد. همچنین در مواردی که سازمان‌ها نیازدارند مراکز داده‌ای با دامنه مدیریتی کاملاً مجزا ایجاد کنند، معماری Multi-Site می‌تواند بهترین گزینه باشد.
لازم به ذکر است، استفاده از معماری ACI Multi-Site امکان راه‌اندازی راهکار­های Disaster Recovery که نیازمند قابلیت IP Mobility است را به خوبی فراهم می‌کند.

در نهایت کدام معماری را انتخاب کنیم؟

تعیین و انتخاب معماری بین دو حالت Multi-Site و Multi-Pod به شرایط و امکانات موجود در هر سازمان بستگی دارد. نیازمندی‌های مدیریتی، لینک‌های ارتباطی موجود و سناریوهای DR از جمله عوامل تأثیرگذار در انتخاب معماری است. به طور مثال، در معماری Multi-Pod ارتباط بین Podهای مختلف می‌بایست با تأخیر کمتر از 50 میلی ثانیه باشد. در مواردی که ارتباطات نزدیک یا بیشتر از این عدد باشد لازم است از معماری Multi-Site استفاده شود.

قابلیت گسترش‌پذیری نیز یکی از عوامل تأثیرگذار بر انتخاب مدل معماری است. در معماری Multi-Pod حداکثر امکان راه‌اندازی 12 Pod و به صورت کلی 200 عدد سوئیچ Leaf فراهم است. اگر تعداد سوئیچ‌های زیرساختی نزدیک به این عدد باشد لازم است از معماری Multi-Site استفاده شود.

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