مدل خط‌مشی ACI Tenant (ساختارهای منطقی ACI)

Cisco ACI یک fabric مبتنی بر خط مشی (policy) است. این بدان معناست که محیط کامل بر اساس اشیاء مدل سازی شده است. اگر به راهنمای اصول ACI در سایت شرکت Cisco نگاه کنید، مراحل مدل توضیح داده شده است. این مطلب مدل خط مشی Tenant را پوشش می‌دهد. مدل خط مشی Tenant بخشی از مدل کلی است که مستقیما در زیر ریشه مدل قرار دارد. این نشان می‌دهد که مدل خط مشی Tenant یکی از مهم‌ترین بخش‌های ACI است. هنگام کار با ACI fabric، مدل خط مشی Tenant بخشی از fabric است که بیشترین مواجهه را با آن خواهید داشت. تصویر زیر مربوط به اصطلاحات ACI است.

متأسفانه، اگرچه تصویر بالا برای توضیح مدل خط مشی Tenant کمک می‌کند، اما ناقص است. مدلی که در راهنمای اصول ACI شرکت Cisco نشان داده شده است نیز کاملا صحیح نیست. در سند Cisco امکان پیکربندی زیرشبکه تحت EPG وجود ندارد به همین دلیل با انجام یک اصلاح کوچک در مدل، تصویر زیر بدست می‌آید. در ادامه به توضیح اصطلاحات می‌پردازیم.

مقاله پیشنهادی ” Cisco ACI چیست؟ | آشنایی با اجزای ACI و نحوه کارکرد آن (قسمت اول)”

Tenants

هر دو نمودار Tenant را به عنوان بالاترین سطح نشان می‌دهند. در ACI شما حداقل سه Tenant دارید، اما بدون Tenant چهارم fabric عمدتا بی استفاده است. این به این دلیل است که شما سه مورد اول را به صورت رایگان دریافت می‌کنید:

• common: Tenant common یا مشترک معمولا به عنوان Tenant خدمات مشترک استفاده می‌شود. اشیاء ایجاد شده در داخل Tenant مشترک در دسترس سایر Tenantین است.
• Infra: Tenant infra برای گسترش زیرساخت استفاده می‌شود. fabric‌های Multi-Pod و Multi-Site از Tenant infra برای اتصال پادها یا سایت‌ها به یکدیگر استفاده می‌کنند.
• mgmt: بیشتر پیکربندی مدیریت در Tenant mgmt یا مدیریت انجام می‌شود. در اینجا آدرس‌های IP مدیریتی را به سوئیچ‌ها اختصاص می‌دهید و قراردادهایی را پیکربندی می‌کنید که دسترسی به رابط‌های مدیریت fabric را محدود می‌کند.

احتمالا می‌خواهید یک Tenant اضافی برای محیط خود ایجاد کنید. Tenant در ACI یک مرز اجرایی است نه یک مرز فنی. این بدان معنی است که هیچ ساختار شبکه واقعی که با Tenant مطابقت داشته باشد وجود ندارد. Tenantها عمدتا برای ایجاد دامنه‌هایی برای کنترل دسترسی (با استفاده از RBAC) استفاده می‌شوند، اما شما می‌توانید Tenantهایی ایجاد کنید تا fabric را به شیوه‌ای منطقی (برای شما) سازماندهی کنند.

اگر از انضمام Kubernetes استفاده می‌کنید ACI یک Tenant جداگانه برای هر محیط Kubernetes ایجاد می‌کند. اگر مدیریت تمام Tenantان به عهده خود شماست، هیچ دلیلی برای ایجاد تعداد زیادی Tenant وجود ندارد. با این حال، برخی از شرکت‌ها دوست دارند محیط‌های Test، QA و Production را جدا کنند و می‌توان از Tenantین برای این منظور استفاده کرد. هنگامی که این Tenantین نیاز به برقراری ارتباط با یکدیگر دارند، می‌توانید قراردادها را صادر کنید تا آن‌ها را قادر به انجام این کار کنید، اما این کار پیچیدگی بسیار زیادی ایجاد می‌کند.

زمینه‌ها (Contexts)

در هر Tenant حداقل به یک Context یا زمینه (که VRF هم نامیده می‌شود) نیاز دارید که شامل دامنه‌های لایه ۳ باشد. زمینه به طور مستقیم به مفهوم VRF (lite) در شبکه‌های کلاسیک نگاشت می‌شود. این بدان معنی است که یک Context یک دامنه جداگانه لایه ۳ است. همچنین به این معنی است که IPهای درون VRF باید منحصر به فرد باشند، اما بین دو VRF ممکن است همپوشانی داشته باشند.

در شبکه‌های کلاسیک از VRF‌ها اغلب برای جداسازی دامنه‌های امنیتی در یک دستگاه استفاده می‌شود. VRF از دسترسی ترافیک IP به یکدیگر بدون استفاده از تکنیک‌های پل زدن مانند نشت مسیر (route leaking) یا فایروال که دو VRF را به هم ارتباط می‌دهد، جلوگیری می‌کند. در ACI نیازی به استفاده از VRF نیست چون به طور پیش فرض ACI یک شبکه بسته است (default deny). این بدان معناست که دستگاه‌های گروه‌های مختلف (بگذارید فعلا آن گروه‌ها را vlan در نظر بگیریم) نمی‌توانند با یکدیگر ارتباط داشته باشند، مگر اینکه به طور خاص چنین اجازه‌ای صادر شود. بنابراین دیگر نیازی به قرار دادن دو گروه در VRF‌های مختلف برای جلوگیری از برقراری ارتباط آن‌ها با یکدیگر نیست. معمولا دو دلیل برای پیاده سازی VRF‌های مختلف در یک محیط ACI وجود دارد:

• به فضاهای IP دارای همپوشانی نیاز دارید.
• می‌خواهید شبکه موجود را با استفاده از فایروال به ACI بازتاب دهید تا VRF‌ها را به هم بچسبانید.

 Bridge Domains

Bridge Domain یا دامنه پل مفهومی است که در سوئیچینگ کلاسیک وجود ندارد و بر نحوه مدیریت ترافیک در شبکه تأثیر می‌گذارد. (Tenantها هم در شبکه‌های کلاسیک وجود ندارند، اما Tenant فقط یک مرز اجرایی است). Bridge Domains ، دامنه لایه ۲ در ACI است. همه چیز در یک Bridge Domains (BD) مجاور لایه ۲ است. یک Bridge Domains عضوی از VRF است، حتی اگر هیچ پیکربندی IP در Bridge Domains وجود نداشته باشد. (به آن subnet گفته می‌شود که در پاراگراف بعدی مورد بحث قرار گرفته است)

پیکربندی یک BD تأثیر زیادی بر نحوه رفتار شبکه و نحوه یادگیری نقاط پایانی دارد. می‌توانید یک BD را طوری پیکربندی کنید که انگار یک vlan معمولی در یک زیرساخت سوئیچینگ کلاسیک است. از طرف دیگر شما همچنین می‌توانید یک BD را طوری پیکربندی کنید که به روش خاص ACI رفتار کند. این باعث می‌شود BD مدیریت ترافیک را بهبود ببخشد که باعث می‌شود ترافیک BUM تأثیر کمتری بر شبکه داشته باشد.

زیرشبکه‌ها (Subnets)

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

• خصوصی: این زیرشبکه‌ها محلی برای VRF هستند و خارج از fabric اعلان نمی‌شوند.
• عمومی: این زیرشبکه‌ها برای اعلان خارج از fabric در دسترس هستند.
• اشتراک گذاری شده: این زیرشبکه‌ها بین VRF‌های داخل fabric به اشتراک گذاشته می‌شوند.

می توانید گزینه Shared subnet را با زیرشبکه‌های خصوصی یا عمومی ترکیب کنید. با این حال، زیرشبکه‌های خصوصی و عمومی نمی‌توانند با هم ترکیب شوند. زیرشبکه‌ها اغلب به عنوان بخشی از BD دیده می‌شوند. که یک راه منطقی برای نگاه کردن به آن‌ها است. با این حال، پیکربندی زیرشبکه‌ها به طور مستقیم در سطح EPG نیز امکان پذیر است. این کار برای اعلان زیرشبکه بین VRF‌ها ضروری است.

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

 گروه نقاط پایانی (EPG)

EPG مهمترین سازه در ACI است. تقریبا هر چیزی یک EPG است، اما EPG چیست؟ EPG مخفف End Point Group به معنای گروه نقاط پایانی است. تعریف نقطه پایانی خود می‌تواند نسبتا گسترده باشد. در واقع این می‌تواند هر چیزی باشد که در شبکه ارتباط برقرار می‌کند.

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

قراردادها (Contracts)

Contract یا قرارداد شیئی است که برای برقراری ارتباط بین دو EPG استفاده می‌شود. از این نظر مانند ACL است. در حالی که به طور پیش فرض EPG‌ها نمی توانند با یکدیگر ارتباط برقرار کنند، قراردادها انواع خاصی از ترافیک را فعال می‌کنند. اما بر خلاف ACL به طور کلی برای EPG اعمال می‌شود. شما نمی توانید آدرس‌های IP خاصی را به عنوان منبع و مقصد مشخص کنید. یک قرارداد باید توسط یک EPG ارائه شود و توسط EPG دیگری مصرف شود تا امکان ترافیک فراهم شود.

هنگامی که یک EPG قراردادی را ارائه می‌دهد به این معنی است که خدمات مشخص شده در قرارداد (با استفاده از موضوعات و فیلترها) توسط EPG ارائه می‌شود. فرض کنید یک وب سرور در یک EPG دارید. ما این EPG را WEB می‌نامیم. این سرور دو سرویس HTTP و HTTPS را ارائه می‌دهد. یعنی ما قراردادی را تعریف خواهیم کرد که این خدمات را مشخص کند. سپس EPG WEB این قرارداد را فراهم می‌کند.

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

برای اینکه یک قرارداد کار کند باید دارای موضوع و فیلترهایی باشد. اینها نوع ترافیک مجاز (یا غیرمجاز در هنگام استفاده از قراردادهای Taboo) را مشخص می‌کنند. علاوه بر این، قرارداد باید توسط یک EPG ارائه شود و باید توسط EPG دیگری مصرف شود. در این مورد EPG که قرارداد را ارائه می‌دهد خدمات را هم ارائه می‌دهد. به عنوان مثال، فرض کنید یک وب سرور و یک مشتری دارید. هر دو در EPG مربوط به خود هستند. سرور EPG باید همانی باشد که قرارداد وب را ارائه می‌کند. مشتری EPG باید این قرارداد را مصرف کند.

قراردادها برای بیش از اجازه دادن صرف به ترافیک بین EPG استفاده می‌شوند. آن‌ها برای ادغام خدمات L4-L7 در fabric و محدود کردن دامنه نشت مسیر بین Contextها هم استفاده می‌شوند.

فیلترها (Filters)

فیلتر مجموعه‌ای از قوانین است که تطبیق ترافیک را مشخص می‌کند. یک فیلتر می‌تواند شامل یک یا چند ورودی باشد، اما توصیه می‌شود تا حد امکان آن‌ها را ساده نگه دارید (آن‌ها را روی یک پروتکل متمرکز نگه دارید). به عنوان مثال، DNS از پورت ۵۳ در هر دو TCP و UDP استفاده می‌کند. ایجاد فیلتری که حاوی پورت ۵۳ TCP و UDP باشد، عالی خواهد بود. ورودی‌های فیلتر را می‌توان به گونه‌ای پیکربندی کرد که به وضعیت بستگی داشته باشند. این بدان معناست که fabric با نظارت بر ۳-way handshake در جلسات TCP برای ایجاد فیلتر صحیح و تنظیم جلسه اقدام می‌کند.

موضوعات (Subjects)

Subjects یا موضوعات لایه دیگری از مفهوم موجود در ACI برای ساخت قراردادهای پیچیده هستند. موضوعات به شما این امکان را می‌دهند که فیلترها را اعمال و انتخاب کنید که آیا آن‌ها را در هر دو جهت اعمال شوند یا خیر، DSCP را پیکربندی کنید و موارد دیگر.

شبکه‌های خارجی (External Networks)

همانطور که قبلا هم اشاره شد همه EPG‌ها باید بخشی از یک Bridge Domain باشند. این موضوع همیشه درست است، مگر در این مورد خاص. External Networks یا شبکه‌های خارجی در واقع نوعی EPG هستند، اما بخشی از BD نیستند. شبکه‌های خارجی همان چیزی است که شما به عنوان EPG در یک شبکه L3out تعریف می‌کنید. وقتی ACI را طوری پیکربندی می‌کنید که بتوانید با استفاده از اتصال لایه ۳ با دنیای خارج ارتباط برقرار کنید، یک L3out ایجاد می‌کنید. در این L3out باید شبکه‌های خارجی را تعریف کنید.

مقاله پیشنهادی ” آیا ACI Multi-Site راه حل مناسب مرکز داده است؟”

Application Profile

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

ایده پشت این کار این است که همه اجزای برنامه را در یک Application Profile با هم گروه بندی کنید. این به شما (و ACI fabric) امکان می‌دهد تا بر سلامت اجزای مختلفی که بخشی از برنامه هستند نظارت کنید. همچنین می‌توانید خط‌مشی‌های نظارتی خاص یا خط‌مشی‌های QoS را برای هر Application Profile تعریف کنید. این کار به شما امکان می‌دهد خط مشی نظارتی بسیار دقیق‌تری روی برنامه‌های کاربردی حیاتی کسب و کار خود داشته باشید، در حالی که برنامه‌های کاربردی پشتیبانی نیاز به نظارت کمتری خواهند داشت.

منبع