اصولا وقتی کارفرما و بطور کلی متخصصین شبکه با راهکار Cisco ACI آشنا می شوند، اجزا و آبجکت های کلی مانند Tenant، VRF، Bridge Domain و EPG را می شناسند و به عبارتی آماده طراحی زیرساخت در این فناوری هستند، با یک چالش مهم و بنیادین روبرو می گردند؛ روش طراحی و پیاده سازی!

تا پیش از  این یک کارشناس شبکه با مفهوم VLAN، VRF و IP سر و کار داشته است. آنچه امروز در ACI می بیند، Application-Profile، EPG و Bridge Domain در کنار VRF و IP است و اکنون مهم است اینها چطور با شبکه سنتی معادل سازی می شوند؟!

از سوی دیگر، تا پیش از این به احتمال خیلی زیاد، default gateway کلیه سرورها و سرویس ها فایروال بوده است و سوئیچ های Core شبکه بصورت لایه دو پیاده سازی شده بودند. طراحی شبکه شامل بلاک های لاجیکال با عنوان DC و DMZ بودند که یا بصورت VRF و VDOM یا حتی با رویکرد سختگیرانه تر؛ استفاده از تجهیزات مستقل، از یکدیگر مجزا بودند و خیالمان آسوده بود روی زیرساخت DC اساسا default gateway اینترنتی وجود ندارد. بعلاوه، احتمال خیلی زیاد روی WAF یا Load Balancer برای برگشت ترافیک SNAT داشتیم.

سوالی که در ذهن شکل می گیرد، این تجهیزات لایه 4 تا 7 حالا روی ACI Fabric چطور پیاده سازی می شوند؟؟ یا اساسا کدام تجهیزات قرار است روی ACI پیاده سازی شوند؟؟ مثلا آیا WAF ما داخل ACI است یا بیرون از آن؟؟

بطور کلی برای طراحی و پیاده سازی ACI Fabric دو متد کلی وجود دارد که با عناوین زیر شناخته می شوند:

“Network-Centric” vs “Application-Centric”

همینجا تاکید می کنم: فضا را اینگونه تصور نکنید!! که یک پنجره Wizard مقابل شماست که در یک مرحله به نام “روش طراحی”، دو radio button قرار دارد، در ابتدای پروژه لازم است یکی را انتخاب می کنید، دکمه Next را میزنید و دیگر راه برگشتی نیست! خیر این روش ها درواقع، استانداردهای طراحی اصولی روی کاغذ محسوب می شوند اما به لطف flexibility بالای ACI، از منظر hands-on operation عملا محدودیت فنی پیچیده ای وجود ندارد و شما می توانید تا آنجا که دستتان باز است، اینها را باهم ترکیب کنید، از قابلیت های ACI بهره مند باشید و به اجبار، چالش های موجود در زیرساخت traditional خود را عینا در ACI کپی نکنید!.

با این مفروضات اولیه، این روش ها را تعریف می کنم:

روش Network-Centric

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

در اینجا منظور از کلید واژه “همه چیز” یعنی:

1. عدم ورود به شناخت سرویس و معماری اپلیکیشن ها؛ عدم وابستگی به اطلاعاتی که تا پیش از این هم نیاز به آنها نداشتیم.
2. عدم تغییر در مدل استقرار فایروال و تجهیزات مشابه که اساسا طراحی شبکه را متحول می کند؛ زمان پروژه را extend می کند و نیاز به درک عمیقتر از ACI و دستکم یکبار تجربه مفید پیاده سازی دارد.
3. و نهایتا عدم تغییر در نحوه تعامل و کار با تیم های سرور و مجازی سازی و DevOps است؛ به عبارت ساده تر، تعریف پروژه در چارچوب تیم شبکه و بس!

نکته: برخی افراد تفاوت میان Net-Centric و App-Centric را تنها در بند a می دانند که صحیح نیست! دقت کنید استاندارد روش Net-Centric این است که کارفرما بتواند با دانش اولیه و در بازه زمانی محدود سرویس ها را روی بستر ACI راه اندازی کند و سپس زمان کافی برای کسب تجربه و دانش بیشتر در اختیار داشته باشد ضمن اینکه نهایتا درگیر تغییر مناسبات همکاری بین تیمی نیز نشود! به عبارتی هر سه گزینه باهم.

نکته: ما همیشه نیاز داریم یک تعریف استاندارد و مشخص از Network-Centric داشته باشیم بگونه ای که scale پروژه از دید کارفرما و پیمانکار یکسان باشد اما همانطور که قبلا اشاره کردم، از منظر تکنیکال موارد انجام شدنی زیادی در این فناوری وجود دارد، به عنوان مثال: اگر شما همزمان owner تجهیزات شبکه و فایروال و WAF هستید و تجربه و دانش کافی در حوزه ACI در اختیار دارید، می توانید بند b را نادیده بگیرید؛ اما این به معنای App-Centric شدن پروژه نیست.

با یک مثال فنی، داستان را ساده کنم:

من در شبکه سنتی دو عدد VLAN و یک VRF پیشفرض دارم که gateway همه جا فایروال است. قرار نیست این ساختار در ACI عوض شود. لذا در نگاه ساده اولیه، در ACI نیاز به یک Tenant دارم و یک VRF. حالا چه بر سر VLAN ها می آید؟!

در شبکه های سنتی، هر VLAN دارای دو رویکرد Network و Security است.

VLAN :: Networking {Layer 2 broadcast domain and Interface VLAN (if needed)}

VLAN :: Security {Services component segmentation}

اما در ACI Fabric برای معادل مفهوم VLAN، دو object وجود دارد و این یکی از تفاوت های fundamental میان ACI و شبکه های سنتی است که پایه و اساس zero-trust networking را در این فناوری شکل می دهد.

بنابراین در زیرساخت ACI این مفاهیم به صورت زیر است:

Bridge Domain (BD) :: Networking {Layer 2 domain and subnet (if needed)}

EPG / ESG :: Security {Services component segmentation}

نتیجه اینکه معادل هر VLAN روی سوئیچ Core لایه دو مرکز داده آنچه در ACI خواهیم داشت:

در تصویر فوق، BD ها بدون subnet و بصورت legacy mode هستند.

پرسش: چرا صرفا یک tenant داریم؟

پاسخ: تعریف Tenant در ACI مستقل از تعریف VRF در زیرساخت سنتی است.

در این روش، پیاده سازی فایروال و تجهیزات لایه 4 تا 7 در ACI به چه صورت است؟؟

در زیرساخت سنتی، فایروال به ازای هر VLAN یک VLAN Interface در ارتباط با سوئیچ core لایه دو دارد که در نقش default gateway محسوب می شود. برای اینکه معادل این شرایط را در ACI ایجاد کنیم، لازم است اینترفیس فایروال مانند یک Endpoint در هر EPG قرار گیرد. مانند زیر

به این روش استقرار فایروال در ACI اصولا EPG-mode گفته می شود که با حداقل دانش تخصصی قابل پیاده سازی است.

در این روش، تعامل ACI با زیرساخت سرور و مجازی سازی چگونه است؟

بدون integration خاص و صرفا مبتنی بر physical domain.

مزایای متد Net-Centric چیست و چه زمانی مورد استفاده است؟

این روش نیاز به حداقل دانش روی ACI دارد و همه چیز سریع و ارزان قیمت جمع می شود!

1. اگر دانش فنی و تجربه کافی در پروژه نیست (مسئولیت اجرا بر عهده خود کارفرما؛ بدون مشاور و مجری با تجربه) از سوی دیگر، حساسیت سرویس ها زیاد و ریسک پذیری خیلی کم است.
2. اگر به هیچ شکل امکان تعامل با تیم های امنیت (فایروال و تجهیزات امنیتی)، سرور و مجازی سازی برای شما وجود ندارد.
3. اگر به اطلاعات مربوط به معماری و اجزاء سرویس ها دسترسی ندارید و نمی توانید در این موضوع ورود کنید.
4. زمان در اختیار پروژه خیلی کم است؛ چنانچه این زیرساخت باید به قید فوریت عملیاتی گردد.

این سوالات برای انتخاب متد طراحی و پیاده سازی کلیدی و مهم هستند. در خصوص شناخت اجزای سرویس البته راهکارها و ابزارهای کاربردی وجود دارد که می توان بدون اتکا به داده های (شاید حتی نه چندان دقیق!) تیم نرم افزار آنها را جمع آوری کرد اما نیازمند زمان است و در فازهای اولیه نمی توان روی آن حساب کرد. روی هم رفته، اگر با چالش های فوق دست به گریبان هستید، روش Network-Centric برای شما انتخاب بهتر و منطقی است. نگران نباشید؛ این انتخاب استاندارد است.

توجه کنید: اگر همه شروط فوق دست در دست هم، بطور مطلق شما را به سوی Net-Centric هدایت نمی کنند؛ جای بحث و جلسه و توجیه فنی هست؛ خصوصا اگر از حضور مشاور یا افراد با تجربه در این حوزه بهره مند هستید، پیشنهاد می کنم: بیس کار را روی شرایط Application-Centric بگذارید و تا هر آنچه می توانید روی این متد پیش بروید. افراد با تجربه روی ACI می دانند که این ابزار بسیار flexible است و چنین امکانی بخوبی فراهم است.

روش Network-Centric چه دستاوردی برای زیرساخت دارد؟

در نگاه اول، با پیروی از این روش شما تقریبا از هیچ قابلیت و feature مهم ACI استفاده نکرده اید. باید بگویم این فرض  چندان دقیق و درست نیست!. یک زیرساخت ACI در متد Net-Centric را می توان معادل یک VXLAN Fabric در نظر گرفت که بصورت automated اجرا شده و شما درگیر هیچ لایه ای از پیکربندی و maintenance خود VXLAN نیستید. حتی در این متد پیاده سازی، سلوشن های ACI Muli-Pod و Multi-Site کماکان می توانند از بهترین راهکارها برای توسعه زیرساخت شما به مراکزداده دوم و سوم باشند. علاوه بر این، دستکم در مسیری قدم گذاشته اید که می دانید امکانات فوق العاده ای پیش روی شما هستند که اگرچه امروز استفاده از آنها برایتان میسر نبوده، اما می توانند در برنامه توسعه فردا قرار بگیرند.

اما از سوی دیگر، باید این را بدانید که مهاجرت از زیرساخت Net-Centric که بصورت توضیحات من پیاده سازی شده باشد، به زیرساخت App-Centric معادل یک پروژه کامل، پیچیده و حساس است.

روش Application-Centric

این روش یعنی همان چیزی که از ACI (Application-Centric Infrastructure) مطابق نام آن انتظار داریم. مجموعه ای از قابلیت ها و تحولات که در حقیقت ویترین زیبای این فناوری هستند و طراحی و پیاده سازی زیرساخت مرکزداده را بطور کامل دگرگون می سازند. این تحولات اما در جهت ساده سازی و رفع چالش هایی هستند که تا به امروز با آنها درگیر بوده ایم. بنابراین در ACI با show off روبرو نیستیم. واقعیت امر این است که سیسکو در هدفگذاری این فناوری کاملا رویکردی بلند پروازانه داشته و شاید یکی از دلایل اصلی اینکه نام انتخابی برای این فناوری برگرفته از دنیای network نیست همین باشد. توجه کنید دو سلوشن دیگر SDN سیسکو با نام های SD-WAN و SD-Access شناخته می شوند که نام آنها با شبکه های هدف خود تطابق دارد.

زمانی که راهکار ACI برای Data Center Fabric انتخاب می شود، انتظار می رود چشم انداز توسعه زیرساخت بر پایه قابلیت های App-Centric باشد؛ شاید طی یک یا دو فاز عملیاتی یا تعداد فازهای بیشتر نسبت به نوع پروژه، دیتای موجود، نحوه مهاجرت و حساسیت سرویس ها.

پرسش: چطور بفهمیم متد App-Centric برای شرایط ما مناسب هست یا خیر؟

پاسخ به همان سوالاتی که در بخش Net-Centric مطرح شد تعیین کننده هستند. برای اینکه مجبور نباشید scroll کنید، یکبار دیگر اینجا مطرح می کنم.

1. امکان شناخت اجزاء سرویس ها و تعامل با تیم نرم افزاری به چه میزان برای شما وجود دارد؟
2. آیا امکان تعامل با تیم ادمین فایروال و تجهیزات امنیتی، تیم زیرساخت و مجازی سازی برای شما وجود دارد؟
3. در زمانبندی پروژه محدودیت ندارید؟؟ (برای یک سایت از یک بانک بزرگ دولتی باید بین 12 تا 18 ماه زمان نصب و راه اندازی کامل در نظر بگیرید)
4. آیا تجربه کافی و موفق قبلی همراه شما هست؟

بند 1: شناخت اجزای سرویس و تعامل با تیم های نرم افزاری

معمولا سخت ترین شرایط در ارتباط با بند شماره 1 است؛ خصوصا که خود شما هم با ابهامات زیادی درباره آن مواجه هستید. شما تیم network هستید، تا امروز صرفا با IP و VLAN درگیر بوده اید و احتمال زیاد روی اجزاء یک سرویس در زیرساخت ورود نداشتید. در این مقطع چند چالش اساسی وجود دارد که فقط، تجربه پیاده سازی ACI در این متد می تواند پاسخگوی شما باشد نه صرفا دانش به تنهایی!. بگذارید رک و صادق باشم. فرد با دانش خوب در ACI اما بدون تجربه حتی نمی تواند چالش های زیر را در ارتباط با نیازهای سرویس بدرستی برای شما لیست کند. چه برسد به ارائه راهکار برای آنها. چرا که اساسا با آنها مواجه نشده است. این موارد عبارت است از:

• اصولا چقدر اطلاعات در خصوص یک سرویس مورد نیاز است؟؟ (شاید بتوان deal کرد شاید هم نه.)
• این اطلاعات با چه ساز و کاری باید از تیم سرویس و یا پیمانکاران آنها دریافت شود؟ (یک نشست برگزار می کنیم اما مهم است چه می خواهیم و چطور. نمی توانیم با سعی و خطا درخواست جلسات مداوم داشته باشیم)
• در چه زمان و فازی از پروژه باید این دیتا جمع آوری شود؟ (برنامه های کاربردی و سرویس ها دائما در حال توسعه و ارتقاء هستند. پس زمان ورود به آنها بسیار مهم است.)
• همه Firewall policy که تا امروز داشتیم بر اساس VLAN هاست. از سوی دیگر، طراحی EPG ها مبتنی بر اجزا سرویس ها، قطعا با تعریف VLAN شبکه همخوانی نخواهد داشت و معادل نیست. تکلیف رول های فایروال که نداریم و نمی دانیم و برای شروع پروژه نمی توانیم بدانیم چیست؟؟
• بطور کلی EPG ها بر چه مبنایی طراحی می شوند؟ یک دیتابیس بزرگ که برای دستکم 5 سرویس ما مشترک استفاده می شود، جز کدام سرویس خواهد بود؟؟ آیا Frontend و Backend حتما باید در EPG های مجزا باشند؟؟

بدیهی است هرچقدر طراحی VLAN ها در شبکه Legacy بیشتر به ساختار سرویس ها نزدیک باشد، کار راحت تر است.

اما بطور کلی آنچه در این مقاله می توانم عنوان کنم، با تشکر از قابلیت های ACI و انعطاف پذیری این ابزار، اطلاعاتی که برای شروع پروژه در خصوص سرویس ها نیاز داریم حداقلی است و طبق تجربه من چالش خاصی ندارد. روی فایروال پالیسی هم دغدغه نداشته باشید و فعلا همه چیز مطابق VLAN ها پیش می رود. اما طبعا این پاسخ اینجا چندان قانع کننده نیست لذا اگر روی این فاز، تعامل با تیم developer و پیمانکاران آنها برای ACI سوال و ابهام دارید، می توانم همه چیز از نحوه data gathering، شناسنامه اطلاعات سرویس و زمان و نحوه مهاجرت سرویس ها را قالب جلسات فنی کاملا رایگان روی سناریوهای واقعی برای شما تشریح کنم. لذا پیشنهاد می کنم حتما با من در ارتباط باشید.

توجه کنید: موضوع ورود به شناخت اجزاء سرویس عملا به سرفصل امنیتی zero-trust networking به عنوان یک دستاورد مهم راه اندازی ACI گره خورده است و حائز اهمیت است.

امنیت و zero-trust networking

موضوع policy enforcement و segmentation در ACI اگرچه می تواند خیلی گسترده باشد اما با deep inspection همراه نیست. به عبارت ساده تر، استفاده از ACI به این معنا نیست که شما می توانید فایروال ها را کنار بگذارید و همه چیز در دل آن قرار گرفته است. به عقیده من، سیسکو در طراحی ACI نگاه ماژولار و functional داشته؛ به این معنا که ACI Fabric در نقش body کلی است و قابلیت های پیشرفته امنیتی بصورت function های مجزا از راهکارهای گوناگون و برندهای مختلف در ارتباط با آن خواهند بود. این سناریو در بحث zero-trust networking نیز صادق است. زیرساخت ACI در شرایط طراحی app-centric و معیار قرار دادن معماری سرویس ها بخوبی می تواند فونداسیون این رویکرد امنیتی را برای یک زیرساخت دیتاسنتری فراهم سازد؛ هرچند برای رسیدن به الگوی zero-trust workload باید از ابزارها و function های جانبی مانند ISE، SIEM و Secure workload سیسکو یا مشابه آن استفاده کرد.

بند 2: تعامل با تجهیزات امنیتی و بطور کلی لایه 4 تا 7 در متد App-Centric

در این خصوص باید تاکید کنم، مدل استقرار این تجهیزات در ACI app-centric کاملا روشن و صریح در مستندات whitepaper سیسکو که بصورت public در اختیار عموم است ذکر شده است. البته غیر از این، مستندات cisco live نیز به وفور درباره آنها پیدا می شود. اما طبق مشاهدات و مذاکرات بنده با برخی از کارفرمایان عزیز، متاسفانه این مستندات از سوی تعداد معدودی از مشاورین و مجریان بزرگوار اساسا مطالعه نشده و نمی شود!

بطور کلی در طراحی app-centric موارد زیر در ارتباط با L4-7 service insertion باید در نظر گرفته شود:

1. برخلاف دیزاین legacy، در زیرساخت ACI لایه بندی و مفاهیم DC و DMZ نخواهیم داشت. این تعاریف برگرفته از رویکرد network-centric هستند و روی بستر یک شبکه سنتی ایجاد شده اند که بصورت implicit همه دسترسی ها در آن وجود دارد. این در حالیست که:

بر خلاف VXLAN که به یک BIG Logical Switch تعبیر می شود، سلوشن ACI را باید یک BIG Logical Firewall در نظر گرفت که کل server farm در دل آن پیکربندی شده است. تکرار می کنم، کل server farm شما که روی ACI Fabric پیاده سازی می گردد، درون یک فایروال بزرگ قرار دارد. اگرچه پیکربندی route در لایه شبکه آن انجام شده اما بدون تعریف و الحاق contract مشخص (تعریف پالیسی امنیتی)، هیچ ارتباطی برقرار نخواهد بود. اگر باز بخواهید حساسیت های امنیتی بیشتری به خرج دهید هیچ اشکالی ندارد! باید بدانید شما در ACI ابزارها و قابلیت های مهمی در اختیار دارید که چالش های گذشته را به شکلی ساده تر و بهتر حل می کنند و لذا نیاز است هر آنچه از گذشته در ذهن دارید روی این زیرساخت منتقل کنید. به عنوان مثال: سناریوهای زیر را در نظر بگیرید که اجزاء frontend و Db (در مدل سنتی، جزئی از DMZ و DC) مربوط به یک سرویس در یک VRF مشترک قرار دارند که از طریق L3Out یک default route به بیرون دارد.

در وهله نخست، اصولا یک شرط اصلی و اساسی در برقراری ارتباط روی ACI میان EPG ها، تعریف Contract است که عملا در شرایط production ترافیک را به یک فایروال شرقی – غربی یا شمالی – جنوبی منتقل می کند. اما به عنوان دو گزینه و راهکار افزونه امنیتی که بتواند دسترسی به دیتابیس ها را سخت تر و امن تر از شرایط پیشفرض کند و خیال شما آسوده تر باشد، Case A و Case B هستند.

در Case A شما می توانید یک External EPG اختصاصی روی L3Out تعریف کنید بگونه ای که دسترسی به EPG دیتابیس از خارج از محیط ACI صرفا از مبدا آی پی رنج management وجود داشته باشد. داخل ACI Fabric اما تفاوتی نمی کند و ارتباطات east. West می تواند از طریق contract vzAny و دسترسی فایروال برقرار باشد. در این کیس، رنج دیتابیس به بیرون از ACI Fabric یاد داده می شود اما حتی اگر به هر دلیل، فایروال را هم از روی contract آن بردارید بازهم از مسیر production دسترسی به آن وجود ندارد. در این مقطع می توانید روی neighbor بیرونی (دیوایسی که با ACI ارتباط روتینگ دارد؛ اصولا یک سوئیچ Core بیرونی) برای management یک vrf مستقل بسازید و آنجا همچیز را جدا کرده باشید. اما کماکان روی ACI تنها یک VRF داریم و طراحی سنتی حاکم نیست.

در Case B که متداول تر هست، اصولا EPG دیتابیس می تواند هیچ Contract ای به بیرون از محیط ACI (ارتباط شمالی – جنوبی) نداشته باشد. در این شرایط برای دسترسی مدیریتی به دیتابیس ها مانند Management studio یا SSH و غیره، می توان از ماشین های مجازی Jump host و یا از PAM استفاده کرد.

نکته مهم اینجاست: در این مدل ذاتا رنج دیتابیس به بیرون از ACI یاد داده نمی شود؛ امنیت بیشتر اما کماکان حفظ رویکرد طراحی مدرن روی ACI.

• بر اساس آنچه توضیح داده شد، زیرساخت ACI به عنوان یک بلاک منطقی (logical) تحت عنوان Server Farm واحد تعریف می شود که البته می تواند شامل یک یا بیشتر Tenant باشد. در خصوص Multi-tenancy یک مقاله مجزا ارائه خواهم کرد.
• در متد ACI App-Centric فایروال های north-south و انواع سناریوهای WAF روی ACI Fabric قرار می گیرند و پیاده سازی می شوند که از منظر طراحی، لایه دوم فایروال هستند. اولین لایه از فایروال، بیرون از ACI خواهد بود که کار DNAT و SNAT اینترنتی را انجام می دهد.
• بدیهی است فایروال east-west روی زیرساخت ACI پیاده سازی می گردد. در نظر داشته باشید، WAF طبق تعاریف و الزامات امنیتی می تواند سر راه ترافیک شمالی – جنوبی و البته در مواردی میان ارتباطات east-west نیز پیاده سازی شود و این موضوع هیچ چالشی در ACI نخواهد بود.
• روش vzAny Contract برای راه اندازی فایروال east-west بسیار مهم و کلیدی است.

کاری که من در جلسات مشاوره در خصوص این حوزه انجام می دهم، ترسیم یک Big Picture و طرح High-Level از مرکزداده است که شامل بلاک ACI، بلاک Core و بلاک های لبه سایت است که مطابق با نیاز و شرایط زیرساختی کارفرمایان انجام می گردد. در صورت نیاز یا علاقه مندی، با من در ارتباط باشید.

بند 2: تعامل با زیرساخت سرور، مجازی سازی و DevOps

در متد app-centric پیشفرض ارتباط با زیرساخت مجازی سازی مبتنی بر integration و استفاده از vmm domain خواهد بود؛ مگر آنکه در compatibility نسخه ها مشکل وجود داشته باشد یا به هرشکل هیچگونه تعاملی میان تیم شبکه و زیرساخت سرور و مجازی سازی وجود نداشته باشد.

آنچه که ادمین های حوزه VMware در این ارتباط باید بدانند:

اصولا ارتباط میان ACI و vCenter مبتنی بر Rest API است و لذا از نصب هر گونه پلاگین یا اعمال هرگونه تغییر زیرساختی خبری نخواهد بود. آنچه ACI می خواهد، دسترسی برای ساخت VDS به هر تعداد مورد نیاز شماست که می توانند در کلاستر یا دیتاسنترهای گوناگون قرار بگیرند. شرح این دسترسی ها مشخص است و نیاز به استفاده از یوزر ادمین نخواهد بود. همچنین این یوزر توسط تیم ادمین سرور و مجازی سازی روی پنل ACI وارد می شود و رمز عبور آن هیچوقت توسط ادمین ACI قابل مشاهده نخواهد بود.

• ساخت VDS از طریق ACI
• اگر آپلینک ها LACP است، ساخت Lag و تنظیمات Active uplinks توسط ACI.
• ساخت Port group ها و تخصیص VLAN آنها بر عهده ACI.
• جا به جایی یک هاست فیزیکی در رک ها نیاز به حداقل پیکربندی دارد؛ کمترین زمان

نهایتا بعد از add شدن هاست ها به VDS کافیست Network adapter ماشین به port group ها assign شود. اگر تنظیمات IP بدرستی انجام شده باشد، بلافاصله ping gateway در دسترس است.

جمع بندی اینکه: مجموعه تسک ها و عملیاتی که در ارتباط با networking روی زیرساخت مجازی سازی انجام می دهید، توسط ACI و با Rest API انجام می شود و تیم زیرساخت هیچ کاری با VLAN رنج نخواهد داشت. اگر از ابزار HPE OneView و یا Cisco UCS استفاده می کنید، یک مرحله کار بیشتر برای انجام دادن وجود خواهد داشت.

یک چالش مهم اما: پاک کردن EPG ها توسط ادمین ACI بدون هماهنگی با زیرساخت است. اصولا حذف یک EPG بصورت اشتباه یک failure بزرگ است که صرف نظر از مدل تعامل با زیرساخت مجازی سازی منجر به قطعی و fail شدن سرویس می گردد. اما اگرچه شما روی vCenter GUI نمی توانید یک port group که در حال حاضر used هست را پاک کنید، اما از طریق Rest API متاسفانه امکان پذیر است و لذا مجموعه ای از error ها را در سمت VMware شاهد خواهیم بود. حذف یک EPG باید مطابق با یک workflow هماهنگ با تیم زیرساخت و مجازی سازی باشد.

یک نکته مهم دیگر: چنانچه در زیرساخت دارای HPE Synergy هستید، گزینه های Mapped (tagged) network یا Tunnel network روی virtual connect نیاز به بررسی دارد چرا که در طراحی و پیکربندی ACI تاثیر گذار هستند.

در خصوص تعامل ACI و NSX گفتنی ها زیاد است. شخصا تجربه integration میان ACI و NSX را داشتم و به خوبی از روال صفر تا صد آن آگاه هستم. بحث پیرامون آن در این مقاله نمی گنجد و بطور اختصاصی به تشریح آن خواهم پرداخت. اما آنچه به این مقاله مرتبط می شود این است که اگر به موضوع Micro-segmentation فکر می کنید و از نظر compatibility version میان ACI و NSX چالش ندارید، حتما integration میان آنها را بررسی نمایید. سناریو ترکیبی میان آنها جالب توجه و کاربردی است.

در خصوص نحوه تعامل ACI با کلاسترهای Kubernetes و OpenShift مجدد بحث گسترده ای وجود دارد که منوط به نوع CNI مورد استفاده است. سناریوهای بسیار خوبی در این زمینه می توان پیاده کرد و ACI قابلیت های منحصر به فردی برای تعامل با این زیرساخت در اختیار دارد. این مبحث را در یک مقاله مجزا بررسی خواهم کرد.

بند 3: زمانبندی پروژه

باید در نظر داشت، طراحی و راه اندازی زیرساخت ACI مبتنی بر متد app-centric نیازمند زمان بیشتر است. برای یک پروژه بانکی روی تنها یک مرکزداده، باید زمانی بین 12 الی 18 ماه متصور بود. اگر فورس زمانی دارید حتما باید شرایط بررسی گردد. هرچند اگر مارکت ACI ایران را بگردید، پروژه هایی وجود دارند که تا همین لحظه زمان بیشتری صرف آنها شده در حالیکه دستاورد مهمی در پی نداشته اند و کارفرمایان با چالش مواجه هستند 🙂

بند 4: تجربه موفق قبلی

قطعا توصیه می شود برای اینکه اتفاقات ناخوشایندی رخ ندهد که بی جهت از ACI متنفر یا مایوس شوید، بهتر است یا از مشاور و پیمانکاران باتجربه در این زمینه بهره مند باشید و یا بتوانید بخشی از زیرساخت پروژه را تبدیل به یک lab خوب کرده و با صرف زمان بیشتر، به R&D در این زمینه بپردازید. در غیر این صورت، روی Network-centric متمرکز باشید. از سوی دیگر، اگر تیم مستعد و علاقه مند در اختیار داشته باشید که صرفا در پی یادگیری قبل مهاجرت نباشند، دوره های آموزشی ACI روی لب سخت افزاری می توانند خیلی موثر باشند. چنانچه در خصوص شرایط دوره ها، ساعات و مدل برگزاری و طراحی لابراتوار ACI نیاز به مشاوره دارید، با من در ارتباط باشید.

مهاجرت به زیرساخت ACI App-Centric

نخستین و مهمترین پرسش این است که مدل راه اندازی پروژه به صورت Greenfield است یا Brownfield؟

پروژه Greenfield

 همه چیز در یک سایت جدید با IP Plan متفاوت و تجهیزات مستقل طراحی و راه اندازی می گردد. اگر شرایط توضیح داده شده قبلی بصورت نسبی وجود داشته باشد، این پروژه به خوبی مستعد استارت از پایه app-centric است.  لذا پیشنهاد میکنم اگر سایت های دوم و سوم در اختیار دارید که منابع سرور، استوریج و تجهیزات امنیتی موجود در آنها reliable و معادل سایت اصلی هست، ارتباطات مخابراتی و اینترنتی مناسبی دارد، 99.99 بهترین گزینه برای شروع پروژه هستند. دلیل تاکید من سه چیز است:

• خود IP Plan معمولا یکی از عناصر نسبتا خراب بسیاری از زیرساخت هاست و با توجه به تفاوت های بنیادی بین VLAN با BD و EPG که در ابتدای مقاله توضیح دادم، می توان یک IP Plan خیلی خوب و استاندارد app-centric طراحی و پروژه را بر اساس آن لانچ کرد.
• در این مکانیسم، نیاز به ارتباط لایه دو میان سایت ها و جا به جایی در اصطلاح درون VLAN ای نداریم. در توضیح شرایط brownfield به آن اشاره می کنم.
• تیم های عملیاتی این فرصت را در اختیار دارند که بدون تحت تاثیر قراردادن زیرساخت زیر بار فعلی، همه اصول و مبانی طراحی app-centric را بدون استرس تجربه کنند و با آن آشنا شوند.

پروژه Brownfield

این مهاجرت طبعا استرس بیشتر و لذا حتما نیاز به مجزی و مشاور با تجربه دارد. اگر شرایط توضیح داده شده در سازمان شما وجود دارد، کماکان می توان از پایه طراحی و پیاده سازی را app-centric در نظر گرفت اما با ملاحظات زیر:

• لازم است یک مستند دقیق از منابع اولیه مورد نیاز در اختیار کارفرما و تیم های عملیاتی قرار گیرد. برای آغاز مهاجرت به فضای اولیه استوریج خالی، ظرفیت compute خالی و تجهیزات لایه 4 تا 7 با پورت خالی و VDOM خالی (با در نظر گرفتن فورتی گیت) نیاز خواهیم داشت. فراهم شدن این موارد برای کاهش ریسک پروژه الزام آور است. اینکه میزان ظرفیت خالی compute و استوریج چقدر باشد، در سرعت اولیه مهاجرت تاثیر خواهد داشت.
• یک زیرساخت ارتباطی لایه 2 و 3 موقت میان ACI و شبکه Legacy راه اندازی می گردد که تا انتهای پروژه مورد نیاز می باشد و برای مهاجرت از آن استفاده می گردد.
• برای جا به جایی ماشین ها و سرورهای درون یک VLAN بطور کامل به ACI نیازمند پیکربندی BD و EPG بصورت net-centric خواهیم بود. این موضوع برای کاهش ریسک و سادگی مهاجرت الزامی است اما قرار نیست روی متد net-centric سرویس دهی انجام شود. به محض تخلیه کامل آن VLAN، موارد پیکربندی شده فوق از ACI حذف می گردند.

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