آموزش cisco aci – راهنمای ساده و سریع

cisco aci مخفف application centric infrastructure سیسکو بوده که به معنای زیرساخت متمرکز بر برنامه است. در آموزش cisco aci، به بیان این مفهوم و چگونگی کار با آن پرداخته‌ایم. آموزش aci سیسکو به شما کمک می‌کند تا نیازهای خود برای شبکه را بهتر و دقیق‌تر تعریف نمایید.

زیرساخت متمرکز بر برنامه (ACI) چیست؟

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

کنترلر زیرساخت سیاست برنامه (APIC)

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

کاملترین مرجع آموزش تخصصی سیسکو در ایران + اعطای گواهینامه معتبر بازار کار

کلیک کنید

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

API کنترلر زیرساخت سیاست برنامه (APIC) سیسکو به برنامه‌ها اجازه می‌دهد تا به طور مستقیم با یک مجموعه منابع مشترک و امن با عملکرد بالا که شامل قابلیت‌های شبکه، محاسبات و ذخیره‌سازی است، ارتباط برقرار کنند.

پیشنهاد مطالعه: آموزش انسیبل سیسکو به زبان ساده و گام به گام

آموزش cisco aci – آشنایی با شبکه فابریک ACI

شبکه فابریک زیرساخت متمرکز بر برنامه (ACI) سیسکو شامل سوئیچ‌های سری Nexus 9000 سیسکو با APIC است که در حالت شبکه فابریک ACI برگ/ستون اجرا می‌شود. این سوئیچ‌ها با اتصال هر گره برگ به هر گره ستون یک شبکه fat- tree تشکیل می‌دهند؛ نیز سایر دستگاه‌ها به گره‌های برگ متصل خواهند شد. APIC شبکه فابریک ACI را مدیریت می‌کند.

شبکه فابریک ACI انتقال با تأخیر کم و یکنواختی را در لینک‌های پهن‌باند (40 گیگابیت بر ثانیه، با قابلیت آینده 100 گیگابیت بر ثانیه) فراهم می‌کند. ترافیکی که منبع و مقصد آن روی همان سوئیچ برگ قرار دارد به صورت محلی پردازش شده و سایر ترافیک از برگ ورودی به برگ خروجی از طریق سوئیچ ستون عبور می‌کند. اگرچه این معماری از نظر فیزیکی به صورت دو هاب ظاهر می‌شود، در واقع یک هاب لایه 3 واحد است زیرا شبکه فابریک به عنوان یک سوئیچ لایه 3 واحد عمل می‌کند.

سیستم عامل شیءگرا (OS) شبکه فابریک ACI روی هر گره سری Nexus 9000 سیسکو اجرا می‌شود. این سیستم برنامه‌ریزی اشیاء برای هر عنصر قابل تنظیم سیستم را امکان‌پذیر می‌کند. سیستم عامل شبکه فابریک ACI سیاست‌ها را از APIC به یک مدل فیزیکی تبدیل کرده که در زیرساخت فیزیکی اجرا می‌شود. مدل فیزیکی مانند نرم‌افزار کامپایل شده است؛ این شکل از مدل است که سیستم عامل سوئیچ می‌تواند اجرا کند.

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

APIC مسئول فعال‌سازی شبکه فابریک، مدیریت نرم‌افزار سوئیچ، پیکربندی سیاست شبکه و پیاده‌سازی است. در حالی که APIC به عنوان موتور مدیریت سیاست و شبکه مرکزی برای شبکه فابریک عمل می‌کند، به طور کامل از مسیر داده، از جمله توپولوژی ارسال جدا شده است. بنابراین، شبکه فابریک می‌تواند حتی زمانی که ارتباط با APIC از دست می‌رود، ترافیک را ارسال کند.

آموزش cisco aci برای استفاده از ماژول‌های ACI

ماژول‌های ACI انسیبل یک رابط کاربری آسان برای مدیریت محیط ACI شما با استفاده از playbookهای انسیبل فراهم می‌کنند. به عنوان مثال، برای اطمینان از اینکه یک tenant خاص وجود دارد، از task انسیبل زیر با استفاده از ماژول aci_tenant استفاده می‌شود:

لیست کاملی از ماژول‌های موجود ACI برای آخرین نسخه پایدار در لیست ماژول‌های شبکه موجود است. همچنین می‌توانید نسخه توسعه فعلی را مشاهده کنید.

اگر می‌خواهید یاد بگیرید که چگونه ماژول‌های ACI خود را بنویسید تا به توسعه کمک کنید، مطالب مربوط به Developing Cisco ACI modules را مشاهده کنید.

پرس و جو و کوئری از تنظیمات ACI

یک ماژول می‌تواند برای پرس و جو از یک شیء خاص نیز استفاده شود.

یا همه اشیاء را پرس‌وجو کنید. تصویر زیر را ببینید.

پس از ثبت مقادیر بازگشتی از task aci_tenant همانطور که در بالا نشان داده شده است، می‌توانید به تمام اطلاعات tenant از متغیر all_tenants دسترسی پیدا کنید.

اجرای محلی روی کنترلر در آموزش cisco aci

طبق طراحی اصلی، ماژول‌های انسیبل به هدف‌های راه دور ارسال و اجرا می‌شوند، اما ماژول‌های ACI (مانند اکثر ماژول‌های مربوط به شبکه) روی دستگاه‌های شبکه یا کنترلر (در اینجا APIC) اجرا نخواهند شد؛ بلکه مستقیماً با رابط REST APIC صحبت می‌کنند. به همین دلیل، ماژول‌ها باید روی کنترلر محلی انسیبل اجرا شوند (یا به سیستمی دیگر که می‌تواند به APIC متصل شود، واگذار شوند).

جمع‌آوری اطلاعات یا Gathering Facts

از آن‌جایی که ما ماژول‌ها را روی کنترلر انسیبل اجرا می‌کنیم، Gathering Facts کار نخواهد کرد. به همین دلیل هنگام استفاده از این ماژول‌های ACI اجباری است که Gathering Facts را غیرفعال کنید. می‌توانید این کار را به صورت جهانی در ansible.cfg خود یا با اضافه کردن gather_facts: no به هر play انجام دهید.

واگذاری به localhost

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

یک راه برای تنظیم این است که به هر task دستورالعمل زیر را اضافه کنید: delegate_to: localhost.

اگر کسی این دستورالعمل را اضافه نکند، انسیبل تلاش خواهد کرد به APIC با استفاده از SSH متصل شده و ماژول را کپی و به صورت راه دور اجرا کند. این کار با یک خطای واضح شکست خواهد خورد، اما ممکن است برای برخی گیج کننده باشد.

استفاده از روش اتصال محلی

گزینه‌ی دیگری که به طور مکرر استفاده می‌شود، بستن روش اتصال محلی به این هدف است به طوری که هر task بعدی برای این هدف از روش اتصال محلی استفاده کند (بنابراین آن را محلی اجرا می‌کند، به جای استفاده از SSH). در این حالت موجودی ممکن است به این صورت باشد:

اما taskهای استفاده شده نیاز به هیچ چیز خاصی ندارند.

* نکته: برای وضوح بیشتر، ما delegate_to: localhost را به همه مثال‌ها در مستندات ماژول اضافه کرده‌ایم. این به کاربران مبتدی کمک می‌کند تا بتوانند به راحتی قسمت‌ها را کپی و پیست کرده و با کمترین میزان تلاش آن‌ها را عملیاتی کنند.

پارامترهای عمومی

هر ماژول ACI انسیبل پارامترهای زیر را می‌پذیرد که ارتباط ماژول با APIC REST API را تحت تاثیر قرار می‌دهند:

آموزش CCNA مدرک دستیار شبکه سیسکو

کلیک کنید

• host: نام میزبان یا آدرس IP APIC.
• port: پورتی که برای ارتباط استفاده می‌شود. (به‌طور پیش‌فرض 443 برای HTTPS، و 80 برای HTTP)
• username: نام کاربری برای ورود به APIC. (پیش‌فرض admin)
• password: رمز عبور برای نام کاربری جهت ورود به APIC با استفاده از احراز هویت مبتنی بر رمز عبور.
• private_key: کلید خصوصی برای نام کاربری جهت ورود به APIC با استفاده از احراز هویت مبتنی بر امضا. این می‌تواند یا محتوای خام کلید خصوصی (شامل هدر/فوتر) باشد یا یک فایل که محتوای کلید را ذخیره می‌کند. (جدید در نسخه 2.5)
• certificate_name: نام گواهینامه در رابط کاربری وب ACI. (این پیش‌فرض یا به مقدار نام کاربری یا نام فایل کلید خصوصی است). (جدید در نسخه 2.5)
• timeout: مقدار زمان انتظار برای ارتباط در سطح سوکت.
• use_proxy: استفاده از تنظیمات پروکسی سیستم. (پیش‌فرض بله)
• use_ssl: استفاده از HTTPS یا HTTP برای ارتباط REST APIC. (پیش‌فرض بله)
• validate_certs: اعتبارسنجی گواهینامه هنگام استفاده از ارتباط HTTPS. (پیش‌فرض بله)
• output_level: سطح جزئیات بازگشتی توسط ماژول‌های ACI را تحت تأثیر قرار می‌دهد. (یکی از normal، info یا debug) (جدید در نسخه 2.5)

پیشنهاد مطالعه: آموزش روتینگ سیسکو – راهنمای ساده و جامع

پشتیبانی از پروکسی

به طور پیش‌فرض، اگر یک متغیر محیطی <protocol>_proxy روی میزبان هدف تنظیم شده باشد، درخواست‌ها از طریق آن پروکسی ارسال می‌شوند. این رفتار می‌تواند با تنظیم یک متغیر برای این task (به بخش Setting the Environment (and Working With Proxies) مراجعه کنید)، یا با استفاده از پارامتر use_proxy تغییر داده شود.

تغییر مسیرهای HTTP می‌توانند از HTTP به HTTPS تغییر مسیر دهند، بنابراین اطمینان حاصل کنید که محیط پروکسی برای هر دو پروتکل به درستی پیکربندی شده است.

اگر پشتیبانی از پروکسی مورد نیاز نیست، اما ممکن است سیستم همچنان آن را پیکربندی کرده باشد، از پارامتر use_proxy: no استفاده کنید تا از استفاده تصادفی پروکسی سیستم جلوگیری شود.

* نکته: پشتیبانی انتخابی پروکسی با استفاده از متغیر محیطی no_proxy نیز پشتیبانی می‌شود.

مقادیر بازگشتی

این ویژگی در نسخه 2.5 و جدید افزوده شده است.

مقادیر زیر همیشه بازگشت داده می‌شوند:

• current: وضعیت فعلی شیء مدیریت شده، یا نتایج پرس و جوی شما.

مقادیر زیر زمانی که output_level: info است بازگشت داده می‌شوند:

• previous: وضعیت اصلی شیء مدیریت شده (قبل از هرگونه تغییر).
• proposed: payload پیکربندی پیشنهادی، بر اساس مقادیر کاربر ارائه شده.
• sent: payload پیکربندی ارسال شده، بر اساس مقادیر کاربر ارائه شده و پیکربندی موجود.

مقادیر زیر زمانی که output_level: debug یا ANSIBLE_DEBUG=1 است بازگشت داده می‌شوند:

• filter_string: فیلتری که برای پرس و جوهای خاص APIC استفاده شده است.
• method: روش HTTP استفاده شده برای payload ارسال شده. (یا GET برای پرس و جوها، DELETE یا POST برای تغییرات)
• response: پاسخ HTTP از APIC.
• status: کد وضعیت HTTP برای درخواست.
• url: URL استفاده شده برای درخواست.

* نکته: مقادیر بازگشتی ماژول به طور کامل به عنوان بخشی از مستندات هر ماژول مستند شده‌اند.

احراز هویت ACI

در این بخش به آموزش cisco aci برای احراز هویت در ACI پرداخته‌ایم.

احراز هویت مبتنی بر رمز عبور:

در صورتی که می‌خواهید با استفاده از نام کاربری و رمز عبور وارد شوید، می‌توانید از پارامترهای زیر با ماژول‌های ACI خود استفاده کنید:

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

* توجه: احراز هویت مبتنی بر رمز عبور ممکن است اقدامات ضد DoS در ACI نسخه 3.1+ را فعال کند که منجر به محدود کردن جلسات و خطاهای HTTP 503 و عدم موفقیت در ورود می‌شود.

* هشدار: هرگز رمزهای عبور را به صورت متن ساده ذخیره نکنید. قابلیت Vault در Ansible به شما اجازه می‌دهد تا داده‌های حساس مانند رمزهای عبور یا کلیدها را در فایل‌های رمزگذاری شده نگه دارید، به جای اینکه به صورت متن ساده در playbookها یا roleهای خود ذخیره کنید. این فایل‌های vault را می‌توان توزیع کرد یا در کنترل منبع قرار داد.

احراز هویت مبتنی بر امضا با استفاده از گواهینامه‌ها:

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

تولید گواهینامه و کلید خصوصی:

احراز هویت مبتنی بر امضا به یک گواهینامه X.509 (خود امضا شده) با کلید خصوصی و یک مرحله پیکربندی برای کاربر AAA شما در ACI نیاز دارد. برای تولید یک گواهینامه X.509 و کلید خصوصی، از روش زیر استفاده کنید:

پیکربندی کاربر محلی شما

مراحل زیر را انجام دهید:

• افزودن گواهینامه X.509 به کاربر AAA محلی شما در ADMIN » AAA
• کلیک بر روی AAA Authentication
• اطمینان حاصل کنید که در فیلد Authentication، فیلد Realm مقدار Local را نمایش می‌دهد
• گسترش Security Management » Local Users
• کلیک بر روی نام کاربری که می‌خواهید به آن گواهینامه اضافه کنید در بخش User Certificates
• کلیک بر روی علامت + و وارد کردن نام گواهینامه در فیلد Name در Create X509 Certificate
• اگر در اینجا از نام پایه کلید خصوصی خود استفاده کنید، نیازی به وارد کردن certificate_name در Ansible ندارید
• کپی و جای‌گذاری گواهینامه X.509 خود در فیلد Data
• می‌توانید این کار را با استفاده از وظیفه زیر در Ansible خودکار کنید:

* توجه: احراز هویت مبتنی بر امضا فقط با کاربران محلی کار می‌کند.

استفاده از احراز هویت مبتنی بر امضا با Ansible

برای کارکردن این روش، نیاز به پارامترهای زیر با ماژول(های) ACI خود دارید:

یا این‌که می‌توانید از محتوای کلید خصوصی استفاده کنید:

* نکته: اگر از نام گواهینامه‌ای در ACI استفاده کنید که با نام پایه کلید خصوصی شما مطابقت دارد، می‌توانید پارامتر certificate_name را مانند مثال بالا حذف کنید.

استفاده از Ansible Vault برای رمزگذاری کلید خصوصی

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

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

گواهینامه رمزگذاری شده جدید را به عنوان یک متغیر جدید در playbook خود کپی و جای‌گذاری کنید.

از متغیر جدید برای کلید خصوصی استفاده کنید:

هنگام اجرای playbook، از –ask-vault-pass برای رمزگشایی کلید خصوصی استفاده کنید.

استفاده از ACI REST با Ansible

در حالی که تعداد زیادی ماژول ACI در توزیع Ansible موجود است و معمول‌ترین اقدامات را می‌توان با این ماژول‌ها انجام داد، همیشه ممکن است کاری وجود داشته باشد که با ماژول‌های موجود قابل انجام نباشد.

دوره جامع آموزش CCNA

کلیک کنید

ماژول aci_rest به شما امکان می‌دهد به API REST APIC به طور مستقیم دسترسی پیدا کرده و هر کاری را که با ماژول‌های موجود پوشش داده نشده است، انجام دهید. این ممکن است که این امر پیچیده به نظر برسد، اما می‌توانید payload REST مورد نیاز برای هر عملی را که در رابط وب ACI انجام می‌شود به راحتی تولید کنید.

قابلیت‌های داخلی idempotency در آموزش cisco aci

به دلیل اینکه API REST APIC ذاتاً idempotent است و می‌تواند گزارش دهد که آیا تغییری انجام شده است یا خیر، ماژول aci_rest به طور خودکار هر دو قابلیت را به ارث برده و یک راه حل عالی برای خودکارسازی زیرساخت ACI شما است. بنابراین، کاربران که نیاز به دسترسی قدرتمندتر به سطح پایین به زیرساخت ACI خود دارند و هنگامی که از ماژول aci_rest استفاده می‌کنند، نیازی به انصراف از idempotency ندارند و هم‌چنین نیازی به حدس زدن ندارند که آیا تغییری انجام شده است یا خیر.

پیشنهاد مطالعه: آموزش bgp سیسکو – معرفی و پیکربندی بی جی پی سیسکو

استفاده از ماژول aci_rest

ماژول aci_rest payloadهای XML و JSON بومی را می‌پذیرد، اما همچنین payload YAML خطی (ساختار یافته مانند JSON) را نیز می‌پذیرد. payload XML نیاز دارد که از مسیری با پایان .xml استفاده کنید در حالی که JSON یا YAML نیاز دارند که مسیر با .json به پایان برسد. وقتی در حال انجام تغییرات هستید، می‌توانید از روش POST یا DELETE استفاده کنید، در حالی که انجام فقط کوئری‌ها نیاز به روش GET دارد.

به عنوان مثال، اگر می‌خواهید اطمینان حاصل کنید که یک tenant خاص در ACI وجود دارد، چهار مثال زیر به صورت عملکردی یکسان هستند:

• XML (Native ACI REST)
• JSON (Native ACI REST)

• YAML (Ansible-style REST)

• Ansible task (Dedicated module)

* نکته: فرمت XML زمانی که نیاز به قالب‌بندی بارگذاری REST به صورت داخلی وجود دارد، عملی‌تر است، اما فرمت YAML برای نگهداری زیرساخت به عنوان کد مناسب‌تر است و به طور طبیعی با پلن‌بوک‌های Ansible بیشتر سازگار است. ماژول‌های اختصاصی تجربه‌ای ساده‌تر، انتزاعی‌تر اما محدودتر را ارائه می‌دهند. از آنچه که برای مورد استفاده شما مناسب‌تر است، استفاده کنید.

مثال‌های عملی

در اینجا مرور کوچکی از وظایف عملی مفید برای استفاده مجدد در پلن‌بوک‌های شما آورده شده است. به راحتی می‌توانید بخش‌های مفید بیشتری را اضافه کنید.

منتظر ماندن برای آماده شدن همه کنترلرها

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

منتظر ماندن برای کامل شدن خوشه

مثال زیر صبر می‌کند تا خوشه به طور کامل آماده شود. در این مثال تعداد APICهای خوشه را می‌دانید و بررسی می‌کنید که هر APIC وضعیت «کاملاً مناسب» را گزارش دهد.

آموزش پیام‌های خطای APIC

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

خطای APIC 122:

unknown managed object class ‘polUni’

در صورتی که این خطا را دریافت کنید و مطمئن هستید که بارگذاری aci_rest و کلاس‌های شی صحیح به نظر می‌رسند، ممکن است مشکل این باشد که بارگذاری شما در واقع JSON صحیح نیست (مثلاً بارگذاری ارسال شده از نقل قول‌های تکی به جای دوتایی استفاده می‌کند) و به همین دلیل APIC نتوانسته است کلاس‌های شی شما را به درستی تجزیه کند. یکی از راه‌های جلوگیری از این مشکل استفاده از بارگذاری به فرمت YAML یا XML است که ساخت آن‌ها صحیح‌تر و ویرایش آن‌ها آسان‌تر است.

خطای APIC 400:

invalid data at line ‘1’. Attributes are missing, tag ‘attributes’ must be specified first, before any other tag

اگرچه مشخصات JSON عناصر بدون ترتیب را مجاز می‌داند، API REST APIC نیاز دارد که عنصر ویژگی‌های JSON قبل از آرایه‌های فرزندان یا عناصر دیگر بیفتد. بنابراین، باید اطمینان حاصل کنید که بارگذاری شما با این الزامات سازگار است. مرتب کردن کلیدهای دیکشنری شما کار را به درستی انجام می‌دهد. اگر ویژگی‌هایی ندارید، ممکن است لازم باشد که: attributes: {} را اضافه کنید زیرا APIC انتظار دارد که این ورودی قبل از هر کودک دیگری بیفتد.

خطای APIC 801:

property descr of uni/tn-TENANT/ap-AP failed validation for value ‘A “legacy” network’

برخی از مقادیر در APIC دارای قوانین فرمت سختگیرانه‌ای برای رعایت هستند و بررسی اعتبارسنجی داخلی APIC برای مقدار ارائه شده شکست خورده است. در این مورد، پارامتر توصیف (که به طور داخلی به عنوان descr شناخته می‌شود) تنها مقادیری را می‌پذیرد که با Regex: [a-zA-Z0-9!#$%()*,-./:;@ _{|}~?&+]+ سازگار باشد و به طور کلی نباید شامل نقل قول‌ها یا براکت‌های مربع باشد.

مشکلات شناخته شده

ماژول aci_rest یک لایه روی API REST APIC است. به همین دلیل، هرگونه مشکل مربوط به APIC در استفاده از این ماژول منعکس خواهد شد. تمام مشکلات زیر یا به فروشنده گزارش شده است و اکثر آن‌ها به راحتی قابل اجتناب هستند.

Too many consecutive API calls may result in connection throttling

با شروع از ACI v3.1، APIC به طور فعال نرخ‌های اتصال احراز هویت شده با استفاده از رمز عبور را بیش از حد مشخص شده محدود می‌کند. این به عنوان بخشی از اقدام ضد-DDOS است، اما می‌تواند زمانی که از Ansible با ACI و احراز هویت بر اساس رمز عبور استفاده می‌کنید، مشکل ساز شود. در حال حاضر، یک راه‌حل افزایش این آستانه در تنظیمات nginx است، اما استفاده از احراز هویت مبتنی بر امضاء توصیه می‌شود.

* نکته: توصیه می‌شود از احراز هویت مبتنی بر امضاء با ACI استفاده کنید، زیرا این نه تنها از محدودیت اتصال جلوگیری می‌کند، بلکه عملکرد کلی را نیز هنگام استفاده از ماژول‌های ACI بهبود می‌بخشد.

Specific requests may not reflect changes correctly (#35401)

یک مشکل شناخته شده وجود دارد که در آن درخواست‌های خاص به APIC تغییرات را به درستی در خروجی نهایی منعکس نمی‌کنند، حتی زمانی که ما این تغییرات را به طور صریح از APIC درخواست می‌کنیم. در یک مورد، استفاده از مسیر api/node/mo/uni/infra.xml شکست می‌خورد، در حالی که api/node/mo/uni/infra/.xml به درستی کار می‌کند.

* نکته: یک راه‌حل این است که مقادیر بازگشتی وظیفه را ثبت کنید (مانند: register: this) و تاثیر بگذارید که وظیفه چه زمانی باید تغییر را گزارش دهد با اضافه کردن: changed_when: this.imdata != [].

Specific requests are known to not be idempotent (#35050)

رفتار APIC در استفاده از status=created و status=deleted ناهماهنگ است. نتیجه این است که هنگامی که از status=created در بارگذاری خود استفاده می‌کنید، وظایف حاصل غیر ایپیدنت هستند و ایجاد در صورتی که شیء قبلاً ایجاد شده باشد شکست خواهد خورد. اما این مورد با status=deleted صادق نیست که چنین تماس به شیء غیر موجود هیچ گونه خطایی ایجاد نمی‌کند.

* نکته: یک راه‌حل عدم استفاده از status=created و به‌جای آن به کار بردن status=modified زمانی که ایپیدنتی ضروری است، خواهد بود.

Setting user password is not idempotent (#35544)

به دلیل ناهماهنگی در API REST APIC، یک وظیفه که رمز عبور یک کاربر محلی را تنظیم می‌کند، ایپیدنت نیست. APIC با پیام بررسی تاریخچه رمز عبور، کاربر dag نباید از 5 رمز عبور قبلی استفاده کند شکایت می‌کند.

* نکته: متأسفانه هیچ راه‌حلی برای رفع این مشکل وجود ندارد.

جمع بندی

در این مطلب به آموزش application centric infrastructure سیسکو پرداختیم. برای آموزش cisco aci، ابتدا به بیان مفهوم زیرساخت متمرکز بر برنامه یا aci پرداخته و سپس شیوه‌ی استفاده از ماژول‌های آن را بیان کردیم. هم‌چنین به شما نشان دادیم که خطاهای رایج در این زمینه کدامند و چطور می‌توان آن‌ها را برطرف نمود.

آموزش سیسکو مکتب خونه

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

کاملترین مرجع آموزش شبکه در ایران + اعطای گواهینامه بازار کار

کلیک کنید