در فصل سوم با عنوان «هدف شبکه چیست؟» توضیح می دهیم که هر طراح شبکه باید پیش از هر چیز هدف اصلی شبکه را درک کند؛ زیرا طراحی درست بدون شناخت مقصد و مأموریت شبکه ممکن نیست. هدف فنی شبکه انتقال داده از نقطه A به نقطه B در زمان مناسب است، اما از دید طراحی باید یک گام جلوتر رفت و پرسید چرا این داده‌ها منتقل می‌شوند؟ پاسخ در رسیدن به اهداف و نتایج تجاری (business outcomes and objectives) است. امروزه شبکه‌ها و سرویس‌های مرتبط با آن چنان برای سازمان‌ها حیاتی شده‌اند که باید با سطح اطمینان بسیار بالا طراحی شوند، درست مانند شبکه‌های تلفن سنتی (POTS). تحول جدید، حرکت به سوی Service-Focused Network (شبکه متمرکز بر سرویس) است، جایی که طراحی حول محور applications، service models، cloud و data انجام می‌شود.
Business Applications (کاربردهای تجاری)
شبکه بزرگراه اطلاعاتی برای کاربردهای تجاری (business applications) امروزی است. برای موفقیت یک کسب‌وکار، این برنامه‌ها باید بتوانند همان‌طور که مورد نیاز است، بین کاربران، دستگاه‌ها، داده‌ها، پایگاه‌های داده و سایر مؤلفه‌های برنامه (application components) به‌درستی ارتباط برقرار کنند.
Application Models (مدل‌های برنامه)
طراحان شبکه باید درک کنند که یک برنامه (application) چگونه ساخته شده تا بتوانند شبکه‌ای طراحی کنند که به‌درستی از آن برنامه پشتیبانی کند. در زیر مدل‌های مختلف برنامه که امروزه مورد استفاده هستند و المان‌های طراحی شبکه مرتبط با هرکدام آمده است.
1. Single-server model (مدل تک‌سرور)
ساده‌ترین مدل برنامه است و معادل اجرای یک برنامه روی یک کامپیوتر شخصی است. تمام اجزای لازم برای اجرای برنامه روی یک application یا server واحد اجرا می‌شوند.
2. 2-tier model (مدل دو لایه‌ای)
این مدل شبیه client/server architecture است، که در آن ارتباط بین کلاینت و سرور برقرار می‌شود. در این مدل، لایه presentation یا user interface در سمت کلاینت اجرا می‌شود، در حالی که لایه داده (data layer) روی سرور اجرا و ذخیره می‌شود. هیچ لایهٔ میانی (application layer) بین کلاینت و سرور وجود ندارد.
3. 3-tier model (مدل سه لایه‌ای)
این مدل در حال حاضر رایج‌ترین مدل است و از سه لایه تشکیل شده است:
Presentation (لایه ارائه)
این بخش جلویی برنامه است که کاربر نهایی آن را می‌بیند و با آن تعامل دارد. این بخش معمولاً به عنوان web tier یا GUI tier شناخته می‌شود. وظیفهٔ اصلی آن ترجمهٔ وظایف و نتایج به قالبی است که کاربر نهایی درک کند.
Intermediate (لایه میانی)
در این لایه تمام توابع و منطق برنامه انجام می‌شود. دستورات و محاسبات اینجا انجام شده و داده بین لایه‌های presentation (web/GUI) و database جابجا می‌شود. این لایه معمولاً به عنوان application یا logic layer شناخته می‌شود.
Database (لایه پایگاه داده)
در این لایه، اطلاعات ذخیره و بازیابی می‌شود و سپس نتایج به لایهٔ میانی بازگردانده می‌شود تا از آنجا به کاربر نهایی برسد.
جدول 3-2 – المان‌های طراحی شبکه در مدل سه‌لایه (3-Tier Application Model Network Design Elements)
| Tier | Traffic Pattern | Network Design Elements | Questions to Ask |
|---|---|---|---|
| Web tier | فقط دسترسی کاربر نهایی و لایهٔ برنامه | به لایه دیتابیس دسترسی ندارد. باید به‌صورت global برای کاربران نهایی در دسترس باشد. معمولاً در DMZ قرار دارد. | کاربران نهایی چطور به web tier دسترسی دارند؟ آدرس‌های IP و مسیرها چگونه مدیریت می‌شوند؟ معماری high-availability (مثل active/active، active/standby، anycast) چیست؟ |
| Application tier | فقط دسترسی وب و دیتابیس. کاربر نهایی هرگز نباید مستقیماً به این لایه دسترسی داشته باشد. | فقط به‌صورت داخلی (internally) قابل دسترسی است. Load balancing باید پیاده‌سازی شود (بسته به ارتباط با سایر لایه‌ها مثل SNAT، NAT، Sticky). معمولاً پشت چندین لایه امنیتی قرار دارد. | ارتباط web tier با application tier چگونه است؟ دیتابیس چگونه با application tier ارتباط دارد؟ |
| Database tier | فقط لایه application دسترسی دارد. نه web tier و نه کاربر نهایی نباید دسترسی داشته باشند. | فقط به‌صورت داخلی قابل دسترسی است، بدون external routing. معمولاً درون چندین لایه امنیتی قرار دارد. | Replication بین دیتابیس‌ها چگونه انجام می‌شود؟ دیتابیس‌ها چطور همگام (synchronized) می‌مانند، مخصوصاً در چند data center مختلف؟ |
Application Constraints and Requirements (محدودیت‌ها و الزامات برنامه‌ها)
در طراحی شبکه، باید برخی محدودیت‌ها و نیازمندی‌های مشترک برنامه‌ها را بشناسید، از جمله:
Multicast
معمولاً برای هماهنگ نگه داشتن داده‌ها بین مجموعه‌ای از سرورها (مثل backend database replication یا data streaming applications نظیر IPTV یا بروزرسانی بازار سهام لحظه‌ای) استفاده می‌شود. در چنین مواردی، نبود multicast باعث اختلال در عملکرد برنامه می‌شود.
Layer 2 Extension
یکی از رایج‌ترین نیازمندی‌های طراحی شبکه پس از استقرار برنامه‌هاست. معمولاً در مدل‌های 3-tier، سرورها در Layer 2 یکسان نیستند و نیاز به ارتباط cross-L2 پیدا می‌شود. طراح شبکه باید راهکارهایی برای گسترش Layer 2 ارائه دهد (مثلاً با استفاده از overlay technologies) تا در عین حفظ عملکرد، قابلیت اطمینان نیز تضمین شود.
Hardcoded Items
در گذشته رایج‌تر بود، اما هنوز هم اتفاق می‌افتد. منظور آیتم‌هایی است که مثل IP address، hostname، username یا password مستقیماً در کد نوشته می‌شوند. این کار باعث ریسک امنیتی و ناسازگاری با سیاست‌های امنیتی می‌شود. بهترین راه این است که از آن جلوگیری شود، و در صورت وجود، باید از روش‌هایی مثل NAT، traffic engineering، source routing برای کاهش آسیب استفاده کرد.
High Availability (دردسترس‌بودن بالا)
طراحی High Availability نقش کلیدی در موفقیت برنامه دارد، مخصوصاً در برنامه‌هایی که در چند data center یا موقعیت جغرافیایی اجرا می‌شوند. سؤالات کلیدی در این حوزه شامل موارد زیر است:
- داده‌ها بین موقعیت‌ها چگونه همگام می‌شوند؟
- کاربران از کدام مکان به سیستم متصل می‌شوند (active/active یا active/standby)؟
- آیا از DNS load balancing یا physical load balancer استفاده شده؟
- آیا نیاز به SNAT بین لایه‌های مختلف وجود دارد؟
در طراحی شبکه‌ای که هدف آن موفقیت برنامه است، توجه به هم‌تکاملی application و network ضروری است. بسیاری از راهکارهای موقتی مثل Layer 2 extension یا hardcoded IPs در بلندمدت مشکل‌ساز می‌شوند.
نقش طراح شبکه در فرآیند توسعه
برای جلوگیری از مشکلات فوق، طراح شبکه باید از ابتدای فرآیند توسعه در کنار تیم توسعه باشد تا بتواند:
- توضیح دهد چرا نباید از Layer 2 extension استفاده کرد،
- چرا نباید آی‌پی یا رمز در کد hardcode شود،
- و چرا باید کنترل‌های امنیتی از همان ابتدا پیاده‌سازی شوند.
در نهایت، همه چیز به تصمیمات تجاری و مصالح مرتبط با آن‌ها بازمی‌گردد.
Service Models (مدل‌های سرویس)
در بخش‌های قبلی، مدل‌های مختلفی از application models را دیدیم که نشان می‌داد چگونه یک برنامه می‌تواند ساخته شود. در این بخش، بحث یک گام جلوتر می‌رود و مدل‌های سرویس (Service Models) مختلفی را پوشش می‌دهد که می‌توان برای اجرای برنامه‌ها از آن‌ها استفاده کرد.
این مدل‌های سرویس تعیین می‌کنند که برنامه کجا میزبانی می‌شود و کدام اجزای آن توسط کسب‌وکار مدیریت یا مالکیت می‌شود. در زیر، رایج‌ترین مدل‌های سرویس توضیح داده شده‌اند:
توجه:
مدل‌های دیگری نیز وجود دارند که در این بخش پوشش داده نشده‌اند، مانند:
- Database as a Service (DBaaS)
- Compliance as a Service (CaaS)
- Security as a Service (SECaaS)
مدل‌هایی که در اینجا معرفی می‌شوند، رایج‌ترین مدل‌های سرویس در زمان نگارش این مطلب هستند.
1. On-premises (در محل / محلی)
در این مدل، کسب‌وکار مالک و مدیر تمام زیرساخت‌ها برای اجرای برنامه است. کسب‌وکار تمامی تجهیزات و منابع لازم برای اجرای سرویس را تأمین می‌کند و سپس به‌طور کامل آن را مدیریت، نگهداری و بهره‌برداری می‌نماید. در برخی موارد ممکن است عملیات نگهداری برون‌سپاری شود، اما زیرساخت همچنان متعلق به خود سازمان است.
2. Software as a Service (SaaS)
در مدل SaaS، فروشنده نرم‌افزار خود را در اختیار کاربران قرار می‌دهد معمولاً از طریق اشتراک ماهانه یا سالانه. کاربران به نرم‌افزار از طریق اینترنت دسترسی دارند و نیازی به نصب یا نگهداری محلی ندارند.
3. Platform as a Service (PaaS)
در این مدل، فروشنده ابزارها و محیط‌های نرم‌افزاری لازم برای توسعهٔ برنامه‌ها را فراهم می‌کند. کاربران (که معمولاً توسعه‌دهندگان هستند) از این ابزارها برای ساخت و تست نرم‌افزارهای خود استفاده می‌کنند، بدون نیاز به مدیریت زیرساخت.
4. Infrastructure as a Service (IaaS)
مدل IaaS یک سرویس pay-as-you-go (پرداخت به‌ازای استفاده) است که شامل storage، شبکه، و مجازی‌سازی (virtualization) می‌شود. در این مدل، کسب‌وکار می‌تواند از زیرساخت ابری (cloud-based infrastructure) استفاده کند تا از هزینه‌های بالای سرمایه‌گذاری در تجهیزات فیزیکی اجتناب نماید.
جدول 3-3: مقایسه مدل‌های سرویس (Service Model Comparison)
| Service Model | Characteristics (ویژگی‌ها) | Advantages (مزایا) | When to Use (زمان استفاده) |
|---|---|---|---|
| On-premises | – تحت مالکیت و مدیریت سازمان- در محیط سرورهای داخلی کسب‌وکار اجرا می‌شود | کنترل کامل بر تمام اجزای برنامه | وقتی کسب‌وکار نیاز به کنترل کامل دارد، مثلاً برای امنیت (security compliance) یا طبقه‌بندی انبوه داده‌ها (data classification) |
| SaaS | – قابل‌دسترسی از طریق اینترنت- میزبانی شده در سرور ارائه‌دهنده شخص ثالث- مقیاس‌پذیر (scalable) بر اساس نیاز | – نیازی به نصب یا نگهداری نرم‌افزار نیست- همه‌چیز از طریق اینترنت در دسترس است- کاربر می‌تواند از هر دستگاه و در هر زمان به آن دسترسی داشته باشد | زمانی که کسب‌وکار می‌خواهد برنامه‌ای با دسترسی آسان و بدون دردسر نگهداری در اختیار کاربران قرار دهد |
| PaaS | – قابل‌دسترسی توسط چندین کاربر- مقیاس‌پذیر و مبتنی بر فناوری مجازی‌سازی (virtualization)- نیاز اندک به دانش IT | – مناسب برای توسعه‌دهندگان نرم‌افزار- توسعه‌دهندگان لازم نیست از صفر شروع کنند | زمانی که کسب‌وکار می‌خواهد برنامه‌ای منحصربه‌فرد توسعه دهد، بدون صرف هزینه زیاد یا درگیری با مدیریت زیرساخت |
| IaaS | – بسیار انعطاف‌پذیر و مقیاس‌پذیر- مناسب برای چند کاربر- مقرون‌به‌صرفه (cost-effective) | – اجتناب از هزینه‌های زیرساخت فیزیکی- کسب‌وکار کنترل کامل بر زیرساخت دارد | زمانی که کسب‌وکار می‌خواهد کنترل کامل بر زیرساخت IT خود داشته باشد و در عین حال به‌صورت پرداخت به‌ازای استفاده (pay-as-you-go) عمل کند |
The Cloud (ابر)
وقتی یک کسب‌وکار قصد دارد از Cloud در هر شکل و مدلی استفاده کند، سه مورد کاربردی (use case) وجود دارد که طراحان شبکه باید در طول فرآیند طراحی آن را در نظر بگیرند:
1. Securely extending a private network to a single or multiple public cloud environments (گسترش ایمن شبکه خصوصی به یک یا چند محیط ابر عمومی)
- شامل چندین cloud (برای مثال: Amazon Web Services (AWS) و Microsoft Azure)
- شامل چندین region در یک cloud یا چندین VPC در یک cloud
- پشتیبانی از VPN، ارتباطات multi-cloud و multi-VPC
- Scaling و بهینه‌سازی عملکرد در transit VPC
- همچنین پشتیبانی از گسترش دیتاسنترها به داخل cloud و فعال‌سازی ارتباط مستقیم branch-to-cloud
2. Optimizing data center and branch connectivity performance to cloud IaaS and SaaS (بهینه‌سازی عملکرد ارتباط دیتاسنتر و شعب با ابرهای IaaS و SaaS)
- شامل پیدا کردن بهترین مسیر به مقصد، segmentation شبکه، مانیتورینگ برای اطمینان از بهترین عملکرد
- نظارت بر ترافیک به‌سمت برنامه‌ها (applications)
- استفاده از Traffic Shaping و Quality of Service (QoS)
- همچنین پشتیبانی از گسترش دیتاسنترها به داخل cloud و فراهم‌سازی ارتباط مستقیم branch-to-cloud
3. Securing access to the Internet and SaaS from the branch (ایمن‌سازی دسترسی از شعب به اینترنت و سرویس‌های SaaS)
- شامل اتصال و محافظت از کاربران دفاتر شعبه (branch offices) به محیط multi-cloud
- از طریق Direct Internet Access (DIA) و اطمینان از ایمن بودن این اتصالات انجام می‌شود
Cloud Connectivity Models (مدل‌های اتصال به ابر)
وقتی یک کسب‌وکار قصد دارد از cloud استفاده کند چه public، private، hybrid یا multi-cloud باید تصمیم بگیرد چگونه به محیط cloud متصل شود. گزینه‌های مختلفی وجود دارد، هرکدام با مزایا و معایب خاص خود.
Direct Cloud Access (دسترسی مستقیم به ابر)
Direct Cloud Access (DCA) به سایت‌های راه‌دور اجازه می‌دهد تا مستقیماً به برنامه‌های SaaS از طریق اینترنت و یا لینک‌های اختصاصی متصل شوند. در این مدل، تنها ترافیک مشخص‌شده برای برنامه‌ها از طریق مسیر مستقیم اینترنتی (DIA) عبور می‌کند و سایر ترافیک‌های اینترنتی از مسیرهای معمول مانند:
- regional hub
- data center
- یا carrier-neutral facility (CNF)
عبور می‌کنند. این قابلیت باعث می‌شود سایت‌های راه‌دور بدون نیاز به تونل‌سازی ترافیک اینترنتی به سمت دیتاسنتر مرکزی، به شکل مستقیم به سرویس‌های SaaS متصل شوند و performance connectivity بهبود پیدا کند. این ویژگی معمولاً با عنوان Direct Internet Access (DIA) شناخته می‌شود.
Edge router مسیر اینترنتی بهینه را برای هر برنامه به‌صورت جداگانه انتخاب می‌کند. اگر مسیر انتخابی در دسترس نباشد یا عملکرد آن پایین بیاید، از لیست مسیرهای فعال حذف می‌شود.
Cloud Access Through a Gateway (دسترسی به ابر از طریق درگاه)
همچنین شناخته‌شده با عنوان Cloud Access Point (CAP)
بسیاری از سازمان‌ها از DIA در سطح شعب استفاده نمی‌کنند، زیرا:
- اتصال آن‌ها از طریق ارائه‌دهندگان خصوصی (مثل MPLS یا VPLS) انجام می‌شود،
- یا به دلیل سیاست‌های امنیتی متمرکز، استفاده از اتصال مستقیم اینترنت مجاز نیست.
در این حالت، شرکت‌ها از data centers، regional hubs یا CNFها برای دسترسی به اینترنت استفاده می‌کنند. در این سناریو، ترافیک SaaS از طریق تونل (مانند IPSec) به بهترین Gateway Site ارسال می‌شود و از آنجا وارد اینترنت و سپس به سرویس SaaS متصل می‌شود.
نکته:
سایت‌های مختلف و برنامه‌های مختلف ممکن است از Gateway Siteها و مسیرهای متفاوتی استفاده کنند. انتخاب مسیر به عملکرد برنامه و ارزیابی عملکرد شبکه بستگی دارد. سایت‌های راه‌دور که از Gateway برای دسترسی به اینترنت استفاده می‌کنند، به عنوان Client Sites شناخته می‌شوند.
Hybrid Approach (رویکرد ترکیبی)
در بسیاری از سازمان‌ها، از هر دو روش DIA و Gateway به‌صورت هم‌زمان استفاده می‌شود. برنامه‌های SaaS می‌توانند از طریق خروجی اینترنت در سایت راه‌دور (DIA Site) یا از طریق Gateway Site ترافیک خود را عبور دهند، بسته به اینکه کدام مسیر عملکرد بهتری دارد. در واقع، سایت‌های DIA نوعی Client Site خاص هستند که دسترسی اینترنتی در همان محل انجام می‌شود و نیاز به ارسال ترافیک به Gateway مرکزی ندارند.
Cloud Types (انواع ابر)
هنگام انتخاب یک راه‌حل Cloud، انواع مختلفی از مدل‌ها وجود دارد که هر کدام مزایا و محدودیت‌های خاص خود را دارند.
1. Private Cloud (ابر خصوصی)
ابر خصوصی شامل منابع محاسبات ابری است که فقط توسط یک سازمان استفاده می‌شود. این محیط می‌تواند در دیتاسنتر داخلی سازمان قرار گیرد یا توسط یک Cloud Service Provider (CSP) میزبانی شود. در این مدل، منابع، برنامه‌ها، سرویس‌ها، داده‌ها و زیرساخت‌ها همیشه در شبکه‌ای خصوصی نگهداری می‌شوند و تمام دستگاه‌ها مختص همان سازمان هستند.
2. Public Cloud (ابر عمومی)
ابر عمومی رایج‌ترین نوع Cloud است. در این مدل، تمام منابع محاسباتی متعلق به CSP است و همان ارائه‌دهنده نیز زیرساخت و سرویس‌ها را مدیریت می‌کند. در محیط ابر عمومی، چندین کسب‌وکار به‌صورت اشتراکی از همان سخت‌افزار، ذخیره‌سازی (storage)، مجازی‌سازی (virtualization) و تجهیزات شبکه استفاده می‌کنند.
3. Hybrid Cloud (ابر ترکیبی)
در این مدل، از ترکیب ابر خصوصی و ابر عمومی استفاده می‌شود تا کسب‌وکار بتواند از مزایای هر دو بهره‌مند شود و در عین حال اثرات منفی آن‌ها را به حداقل برساند.
4. Multi-Cloud (چند-ابر)
مدل Multi-Cloud از دو یا چند CSP استفاده می‌کند و این امکان را فراهم می‌سازد که workloadها (بارهای کاری) بین محیط‌های ابری مختلف به‌صورت real-time جابجا شوند، بسته به نیاز کسب‌وکار.
Table 3-4: Cloud Types Detailed Comparison (مقایسهٔ دقیق انواع ابر)
| Cloud Type | Control | Maintenance | Flexibility | Scalability | Migration | Cost |
|---|---|---|---|---|---|---|
| Private Cloud | بیشترین کنترل | زیاد | کمترین انعطاف | مقیاس‌پذیری بالا | مهاجرت سخت | هزینه بالا |
| Public Cloud | کمترین کنترل | بدون نیاز به نگهداری | منعطف | مقیاس‌پذیری بالا | مهاجرت سخت | کم‌هزینه‌ترین |
| Hybrid Cloud | ترکیب هر دو | متوسط | منعطف | کمترین مقیاس‌پذیری | مهاجرت آسان‌تر | هزینه بالا |
| Multi-Cloud | کمترین کنترل | بدون نیاز به نگهداری برای هر CSP ولی هزینهٔ کلی بالا | بیشترین انعطاف | بیشترین مقیاس‌پذیری | دشوارترین مهاجرت | بالاترین هزینه |
Cloud-Agnostic Architecture (معماری مستقل از ارائه‌دهنده ابر)
معماری Cloud-Agnostic زمانی استفاده می‌شود که هیچ ویژگی یا عملکرد خاصی وابسته به یک فروشنده (vendor) نباشد. هدف این معماری، استفاده از قابلیت‌های مشترک میان ارائه‌دهندگان مختلف Cloud بدون وابستگی به یک برند خاص است. هنگام انتخاب cloud providers و مهاجرت برنامه‌ها به ابر، سه اصل کلیدی باید در نظر گرفته شود:
1. Portability (قابلیت انتقال)
انتقال به ابر به‌طور طبیعی مقداری قابلیت انتقال فراهم می‌کند، اما اگر طراحی به‌درستی انجام نشود، برنامه‌ها ممکن است در CSP خاصی قفل شوند (Vendor Lock-In). Portability یعنی بتوان برنامه‌ها را به‌راحتی بین ارائه‌دهندگان مختلف Cloud جابجا کرد، با استفاده از لایهٔ abstraction مناسب.
2. Abstraction (لایهٔ انتزاعی)
استفاده از لایه abstraction در معماری Cloud باعث می‌شود وابستگی به ویژگی‌های خاص پلتفرم از بین برود و در نتیجه:
- هزینه‌ها کاهش یابد،
- انعطاف‌پذیری افزایش یابد.
مثلاً با استفاده از این لایه می‌توان همان قابلیت را از دو Cloud Provider مختلف به‌صورت یکسان فراخوانی کرد. این کار باعث می‌شود حتی اگر مکانیزم‌های داخلی متفاوت باشند، عملکرد برنامه ثابت بماند.
3. Interoperability (هم‌کنش‌پذیری)
برنامه‌ها و سرویس‌ها باید طوری طراحی شوند که بتوانند با پلتفرم‌های مختلف Cloud بدون تغییر زیاد کار کنند. این امر باعث می‌شود سیستم‌ها بتوانند از قابلیت‌های چند پلتفرم مختلف بهره‌مند شوند، بدون نیاز به بازطراحی یا بازنویسی مجدد.
راهکارهای دستیابی به Cloud-Agnostic Architecture
Decoupling (جداسازی)
دو دیدگاه در مورد Decoupling وجود دارد:
- تمام برنامه‌ها باید به‌صورت ذاتی از پلتفرم زیرین خود جدا طراحی شوند.
این کار معمولاً با استفاده از Service-Oriented Architecture (SOA) انجام می‌شود. - تمام اجزای Cloud باید از برنامه‌هایی که از آن‌ها استفاده می‌کنند جدا شوند تا وابستگی حذف گردد.
Containerization (کانتینرسازی)
تمام برنامه‌ها باید از معماری مبتنی بر Container استفاده کنند. این موضوع هم برای برنامه‌های Cloud-native و هم برای برنامه‌های دیتاسنتری اهمیت دارد. فناوری Container باعث می‌شود برنامه‌ها از محیط زیرین خود جدا شوند و بتوانند به‌راحتی بین فروشندگان مختلف Cloud جابجا شوند. این روش Portability را افزایش می‌دهد و وابستگی به CSP خاص را از بین میبرد.
Agnostic vs Proprietary Cloud Services (مقایسهٔ سرویس‌های مستقل و اختصاصی Cloud)
هر Cloud Service Provider مجموعه‌ای از سرویس‌های خاص خود را دارد. بنابراین لازم است میان سرویس‌های Agnostic (غیروابسته) و Proprietary (اختصاصی) تفاوت قائل شویم.
Service-Oriented Architecture (معماری سرویس‌گرا)
برای موفقیت در ایجاد یک معماری Cloud-Agnostic، به‌کارگیری Service-Oriented Architecture (SOA) حیاتی است. SOA یک سبک طراحی نرم‌افزار است که در آن سرویس‌ها به‌صورت مستقل ارائه می‌شوند و از طریق پروتکل‌های شبکه‌ای با یکدیگر ارتباط دارند.
ویژگی‌ها و مزایای کلیدی SOA عبارت‌اند از:
- قابلیت استفاده مجدد از کد (Reusable Code): باعث کاهش زمان توسعه می‌شود.
- پشتیبانی از زبان‌های برنامه‌نویسی متعدد: با استفاده از رابط مرکزی (central interface)، انعطاف و مقیاس‌پذیری در چرخه توسعه نرم‌افزار افزایش می‌یابد.
- ایجاد فرآیند ارتباط استاندارد: که سیستم‌ها را قادر می‌سازد مستقل عمل کنند اما بتوانند با یکدیگر تعامل مؤثر داشته باشند.
- افزایش مقیاس‌پذیری (Scalability): به دلیل کاهش تعامل مستقیم client-server و بهبود کارایی کلی.
Cloud Containerized Architecture (معماری ابری مبتنی بر کانتینر)
Containerization بخش مهمی از یک معماری Cloud-Agnostic است. شکل 3-4 روند تکامل از استقرار سنتی (Traditional Deployment) تا استقرار کانتینری (Containerized Deployment) را نشان می‌دهد.
Traditional Deployment Architecture (معماری استقرار سنتی)
در مدل سنتی، سازمان‌ها برنامه‌ها را روی سرورهای فیزیکی اجرا می‌کردند. امکان اجرای چند برنامه روی یک سرور وجود داشت، اما هیچ راهی برای مدیریت دقیق منابع یا اعمال محدودیت‌های کنترلی وجود نداشت. به همین دلیل، مشکلاتی مانند:
- تخصیص نادرست منابع،
- کاهش کارایی (performance issues)،
- و تداخل بین برنامه‌ها
به‌وجود می‌آمد. اغلب، هر سرور فیزیکی تنها به یک برنامه اختصاص داده می‌شد تا از این مشکلات جلوگیری شود که در نتیجه باعث افزایش هزینه و مصرف منابع و کاهش مقیاس‌پذیری (scalability) می‌شد.
Virtualization Deployment Architecture (معماری استقرار مجازی‌سازی)
Virtualization امکان اجرای چندین ماشین مجازی (VM) را روی یک سرور فیزیکی فراهم می‌کند. هر VM به‌طور کامل از سایر برنامه‌ها جدا است و منابع و کنترل امنیتی مختص خود را دارد. این روش باعث بهبود استفاده از منابع (resource utilization) و مقیاس‌پذیری بیشتر می‌شود.
هر VM شامل تمام اجزایی است که یک سرور فیزیکی نیاز دارد، از جمله: سیستم‌عامل (Operating System)، برنامه (Application) و کتابخانه‌ها (Libraries). با توجه به نیاز، می‌توان VMها را اضافه یا حذف کرد تا منابع بهینه شوند.
Container Deployment Architecture (معماری استقرار کانتینری)
Containers مشابه VMs هستند، اما با میزان جداسازی (isolation) کمتر و کارایی بالاتر. در کانتینرها، چند برنامه می‌توانند سیستم‌عامل مشترکی داشته باشند، در حالی که همچنان سبک (lightweight) و مستقل باقی می‌مانند. هر کانتینر دارای فایل‌سیستم، CPU، حافظه و فضای فرآیند مخصوص خود است. از آنجا که کانتینرها از زیرساخت جدا هستند، می‌توان آن‌ها را به‌راحتی بین محیط‌های مختلف (different fabrics) جابجا کرد، بسته به نیازهای تجاری.
مزایای Containerization
- ایجاد و استقرار چابک برنامه‌ها (Agile CI/CD)
- تفکیک وظایف توسعه (development) و عملیات (operations)
- تحلیل سلامت برنامه در زمان واقعی (Real-time health analytics)
- استانداردسازی در تمام محیط‌ها و دامنه‌ها (Standardization & Consistency)
- توزیع بلادرنگ (Real-time distribution) با قابلیت انتقال به سیستم‌عامل‌ها و مکان‌های دیگر
- پیش‌بینی‌پذیری بالاتر عملکرد برنامه (Predictability)
- افزایش کارایی منابع (Resource Efficiency)
Cloud Application Strategy (استراتژی برنامه‌های ابری)
وقتی سازمان‌ها آماده می‌شوند تا برنامه‌های خود را به ابر منتقل کنند (Cloud Migration)، توصیه می‌شود که یک فرآیند ارزیابی به نام Application Assessment Process ایجاد شود. در این فرآیند، تیمی تحت عنوان Application Assessment Team با نقش‌ها و مسئولیت‌های زیر تشکیل می‌شود:
1. Line of Business Owner (مالک خط تجاری)
نمایندهٔ کسب‌وکار است و مسئول درک نقش تجاری برنامه و تأثیر آن بر سازمان می‌باشد. او باید بداند این برنامه چگونه به اهداف تجاری کمک می‌کند و چه منابع و اولویت‌هایی نیاز دارد.
2. Security Specialist / Compliance Auditor (کارشناس امنیت یا ممیز انطباق)
این عضو از تیم امنیتی است و مسئول موارد زیر می‌باشد:
- کنترل‌های امنیتی (Security Controls)
- رعایت الزامات انطباق (Compliance Regulations)
- ممیزی کد و بررسی ریسک‌ها
این نقش‌ها تصمیم‌گیری‌ها را از منظر مدیریت ریسک (Risk Management) هدایت می‌کنند.
3. Application Owner / Application Developer (مالک یا توسعه‌دهنده برنامه)
مسئول طراحی، توسعه و نگهداری کد است. کارهای اصلی او شامل:
- ایجاد و به‌روزرسانی کد برنامه
- تطبیق برنامه با نیازهای فنی مشخص‌شده
- همکاری با سایر نقش‌ها برای اطمینان از سازگاری کد در محیط Cloud
4. Network Engineer / Network Designer / Network Architect (مهندس، طراح یا معمار شبکه)
این نقش مسئول فراهم‌سازی زیرساخت‌های شبکه است تا برنامه به‌درستی در محیط Cloud مستقر شود. او نیازهای شبکه را بر اساس ورودی از سایر نقش‌ها مانند امنیت و کسب‌وکار پیاده‌سازی می‌کند.
فرآیند ارزیابی و مستندسازی
هر برنامه نیازها و وابستگی‌های خاص خود را دارد. تیم ارزیابی باید شناسایی کند که برنامه:
- به چه سرویس‌ها و منابعی وابسته است،
- چه کنترل‌های امنیتی باید رعایت شود،
- و در چه مرحله‌ای از فرآیند مهاجرت به Cloud قرار دارد.
تمام یافته‌ها و تصمیمات باید در سندی به نام Application Binder یا Run Book ثبت شوند.
این سند شامل موارد زیر است:
- تمام الزامات و منبع هرکدام،
- کنترل‌های امنیتی و استانداردهای قانونی مورد نیاز،
- موقعیت فعلی برنامه در فرآیند مهاجرت،
- و اقداماتی که برای موفقیت مهاجرت لازم است.
Data Management (مدیریت داده)
داده (Data) حیاتی‌ترین منبعی است که تمام منابع دیگر بر پایهٔ آن عمل می‌کنند. ما باید داده‌ها را به‌صورت مؤثر، دقیق و ایمن مدیریت کنیم تا سایر منابع سازمان بتوانند از آن‌ها به‌درستی استفاده کنند. با اطمینان از integrity (یکپارچگی)، availability (دردسترس‌بودن) و confidentiality (محرمانگی). به‌صورت خلاصه، مدیریت داده پایه و اساس تحلیل داده (Data Analytics) است. بدون مدیریت صحیح داده، هیچ تحلیل داده‌ای وجود نخواهد داشت. مدیریت داده را می‌توان به ۱۱ ستون (Pillar) اصلی تقسیم کرد:
1. Data Governance (حاکمیت داده)
برنامه‌ریزی برای تمام جنبه‌های مدیریت داده، شامل:
- دسترس‌پذیری (availability)
- قابلیت استفاده (usability)
- سازگاری (consistency)
- یکپارچگی (integrity)
- امنیت داده‌ها در سراسر سازمان
2. Data Architecture (معماری داده)
ساختار کلی داده‌های سازمان و نحوهٔ قرارگیری آن در Enterprise Architecture (معماری سازمانی).
3. Data Modeling and Design (مدل‌سازی و طراحی داده)
فرآیند طراحی، ساخت، آزمایش و نگهداری مداوم سیستم‌های تحلیل داده (Data Analytics Systems).
4. Data Storage and Operations (ذخیره‌سازی و عملیات داده)
سخت‌افزار فیزیکی مورد استفاده برای ذخیره و مدیریت داده در درون سازمان.
5. Data Security (امنیت داده)
تمام کنترل‌ها، الزامات و مؤلفه‌هایی که اطمینان می‌دهند داده فقط توسط افراد مجاز قابل دسترسی است.
6. Data Integration and Interoperability (یکپارچه‌سازی و تعامل‌پذیری داده)
تبدیل داده‌ها از فرمت‌های مختلف به ساختارهای استاندارد تا بتوانند در سیستم‌ها و منابع مختلف مورد استفاده قرارگیرند.
7. Documents and Content (مستندات و محتوا)
مدیریت تمام داده‌های غیرساختاریافته (Unstructured Data) و فراهم کردن ابزار لازم برای دسترسی به آن‌ها در قالب Structured Databases.
8. Reference and Master Data (داده مرجع و اصلی)
مدیریت داده‌ها به‌گونه‌ای که منحصر به‌فرد، استاندارد و بدون خطا باشند و بتوان آن‌ها را با مقادیر مرجع استاندارد نرمال‌سازی کرد.
9. Data Warehousing and Business Intelligence (انبار داده و هوش تجاری)
مدیریت و استفاده از داده‌ها برای تحلیل‌ها و تصمیم‌گیری‌های تجاری (Business Decision-Making).
10. Metadata (فراداده)
شامل تمام فعالیت‌های ایجاد، جمع‌آوری، سازمان‌دهی و مدیریت فراداده (مانند داده‌هایی که داده‌های دیگر را توصیف می‌کنند مثلاً schema، owner، یا timestamps).
11. Data Quality (کیفیت داده)
پایش داده‌ها برای اطمینان از صحت و یکپارچگی داده‌های تحویلی. داده‌های کم‌کیفیت منجر به ریسک تحلیلی و تصمیمات اشتباه می‌شود.
جمع‌بندی مدیریت داده (Data Management Overview)
برای داشتن یک مدل مدیریت داده کامل، تمامی این ۱۱ ستون باید وجود داشته باشند. اگر یکی از این موارد نادیده گرفته شود، بخشی از مدیریت داده ناقص خواهد بود. به‌عنوان مثال، اگر سازمان راهکاری برای Metadata Management نداشته باشد، قابلیت طبقه‌بندی داده‌ها (Data Categorization) را از دست می‌دهد.
بدون Data Quality مناسب، تمام داده‌ها در معرض خطر خواهند بود و تحلیل‌های داده بی‌فایده یا گمراه‌کننده می‌شوند.
Summary (خلاصه)
هدف شبکه چیست؟ تضمین موفقیت کسب‌وکار (Business Success). این فصل به‌صورت عمیق بررسی کرد که یک Network Designer چگونه می‌تواند به این هدف برسد.
نکات کلیدی فصل:
- توضیح داده شد که چگونه کسب‌وکارها به شبکه و سرویس‌های مرتبط با آن تکیه دارند.
- ارتباط بین برنامه‌ها (Applications) و طراحی شبکه (Network Design) بررسی شد.
- مدل‌های مختلف Application Models و Service Models و تأثیر آن‌ها بر طراحی شبکه بیان شد.
- مزایا و ملاحظات مربوط به انواع Clouds (Public, Private, Hybrid, Multi-Cloud) تشریح شد.
- اهمیت طراحی Cloud-Agnostic Architecture برای جلوگیری از وابستگی به Vendor خاص توضیح داده شد.
- مفهوم Service-Oriented Architecture (SOA) و Containerization به‌عنوان رویکردهای مدرن طراحی معرفی شدند.
- در نهایت، Data Management به‌عنوان زیربنای موفقیت تمام این مؤلفه‌ها مطرح گردید.
نتیجه‌گیری کلی:
- موفقیت در طراحی شبکه به درک درست از نیازهای کسب‌وکار (Business Requirements) وابسته است.
- بدون امنیت، قابلیت اطمینان و در دسترس بودن داده‌ها، هیچ تصمیم درستی در سطح سازمان گرفته نخواهد شد.
- در واقع، داده ستون فقرات هر شبکه و تصمیم تجاری است؛ بدون آن، کسب‌وکار در مسیر تاریکی حرکت می‌کند.
