طراحی زیرساخت پردازشی

توضیحات

طراحی و بازطراحی معماری زیرساخت پردازشی

Compute Infrastructure Architecture Design & Redesign

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

این خدمت صرفاً به انتخاب مدل و تعداد سرورها محدود نیست؛ بلکه تمام اجزای معماری Compute، از لایه سخت‌افزار و مجازی‌سازی تا مدیریت منابع، افزونگی، امنیت، مانیتورینگ، توسعه‌پذیری و نقشه گذار از وضعیت موجود به وضعیت هدف را پوشش می‌دهد.

خروجی این خدمت مشخص می‌کند:

• معماری پردازشی هدف باید چه ساختاری داشته باشد؛
• چه ظرفیت پردازشی برای بارهای کاری فعلی و آتی لازم است؛
• چه نوع و چه تعداد سرور و مؤلفه سخت‌افزاری موردنیاز است؛
• کلاسترها و منابع مجازی‌سازی چگونه طراحی شوند؛
• چه سطحی از افزونگی و ظرفیت رزرو در نظر گرفته شود؛
• تجهیزات و لایسنس‌های موردنیاز در قالب LOM/BOM چیست؛
• گذار از معماری موجود به معماری هدف چگونه انجام شود.

پیش‌نیازها و ورودی‌های طراحی

طراحی معماری باید بر پایه اطلاعات معتبر و قابل‌اندازه‌گیری انجام شود. ورودی‌های اصلی این خدمت عبارت‌اند از:

• گزارش ارزیابی و تحلیل زیرساخت پردازشی موجود؛
• اطلاعات مصرف واقعی CPU، RAM، شبکه و I/O؛
• فهرست بارهای کاری، ماشین‌های مجازی و سرویس‌های سازمان؛
• طبقه‌بندی سرویس‌ها بر اساس اهمیت و حساسیت؛
• پیش‌بینی رشد کاربران، سرویس‌ها و بارهای کاری؛
• الزامات دسترس‌پذیری، کارایی، امنیت و تداوم خدمت؛
• محدودیت‌های فضای رک، برق، سرمایش و ارتباطات؛
• وضعیت قراردادهای پشتیبانی، لایسنس‌ها و چرخه عمر تجهیزات؛
• محدودیت‌های بودجه، زمان‌بندی و سیاست‌های تأمین سازمان؛
• استانداردها و فناوری‌های مورد تأیید کارفرما.

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

مراحل اجرای خدمت

۱. تعیین اهداف، الزامات و دامنه معماری

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

فعالیت‌های این مرحله شامل موارد زیر است:

• تعیین دامنه طراحی شامل دیتاسنترها، سایت‌ها، سرورها، کلاسترها و بارهای کاری؛
• شناسایی سرویس‌های حیاتی و وابستگی آن‌ها به زیرساخت پردازشی؛
• تعیین اهداف ظرفیت، کارایی، دسترس‌پذیری و مقیاس‌پذیری؛
• تعیین افق زمانی طراحی، معمولاً برای سه تا پنج سال؛
• مشخص‌کردن محدودیت‌های بودجه‌ای، فنی، اجرایی و تأمین؛
• تعیین سیاست سازمان درباره برند، پلتفرم و فناوری‌های مجاز؛
• شناسایی الزامات مربوط به مجازی‌سازی، کانتینر، پردازش ابری یا Bare Metal؛
• تعیین الزامات امنیتی، انطباقی و عملیاتی؛
• تعیین شاخص‌های پذیرش معماری نهایی.

نتیجه این مرحله: سند الزامات معماری و معیارهای طراحی که مبنای تصمیم‌گیری در مراحل بعدی خواهد بود.

۲. تدوین مدل ظرفیت و Sizing زیرساخت

در این مرحله، اطلاعات حاصل از ارزیابی و ظرفیت‌سنجی به نیازهای فنی معماری هدف تبدیل می‌شود.

فعالیت‌های این مرحله عبارت‌اند از:

• تعیین نیاز پردازشی هر گروه از بارهای کاری؛
• محاسبه مجموع ظرفیت CPU، RAM و I/O موردنیاز؛
• تعیین نسبت منطقی vCPU-to-pCPU متناسب با نوع Workload؛
• تعیین سیاست مجاز برای CPU و Memory Overcommitment؛
• محاسبه ظرفیت موردنیاز در شرایط عادی و ساعات اوج مصرف؛
• لحاظ‌کردن نرخ رشد بارهای کاری در افق طراحی؛
• تعیین ظرفیت رزرو برای توسعه سرویس‌های جدید؛
• تعیین ظرفیت لازم برای عملیات نگهداری و Failover؛
• محاسبه Headroom موردنیاز برای جلوگیری از اشباع منابع؛
• تحلیل نیازهای پردازشی ویژه مانند GPU، حافظه بالا یا Low Latency؛
• بررسی الزامات لایسنسینگ وابسته به تعداد CPU، Socket یا Core.

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

نتیجه این مرحله: مدل Sizing و ماتریس ظرفیت موردنیاز برای معماری هدف.

۳. طراحی معماری منطقی زیرساخت پردازشی

در این مرحله، ساختار منطقی معماری Compute مستقل از مدل دقیق تجهیزات طراحی می‌شود.

این طراحی شامل موارد زیر است:

• تعیین تعداد و نوع کلاسترهای پردازشی؛
• تفکیک کلاسترها بر اساس محیط‌های Production، Test، Development و Management؛
• تفکیک بارهای کاری عمومی، حیاتی یا دارای الزامات خاص؛
• تعیین معماری Scale-up، Scale-out یا ترکیبی؛
• تعیین تعداد Hostهای هر کلاستر؛
• طراحی Fault Domainها در سطح Host، Chassis، Rack و Site؛
• تعریف سیاست قرارگیری و توزیع ماشین‌های مجازی؛
• تعیین Affinity و Anti-Affinity Ruleهای موردنیاز؛
• طراحی Resource Poolها و روش تخصیص منابع؛
• تعریف سیاست Reservation، Limit و Share؛
• تعیین ساختار شبکه‌های مدیریتی، سرویس، Migration و Storage؛
• تعیین نقاط اتصال لایه Compute به Storage و Network؛
• طراحی جداسازی منطقی بارهای کاری حساس؛
• تعیین روش توسعه ظرفیت کلاستر در آینده.

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

نتیجه این مرحله: سند High-Level Design یا HLD معماری پردازشی.

۴. طراحی معماری فیزیکی سرورها و تجهیزات

پس از تثبیت معماری منطقی، پیکربندی فیزیکی سرورها و مؤلفه‌های مرتبط تعیین می‌شود.

فعالیت‌های این مرحله شامل موارد زیر است:

• انتخاب پلتفرم سرور
• بررسی و انتخاب Rack، Blade، Modular یا سایر معماری‌های مناسب؛
• تعیین تعداد سرورها بر اساس ظرفیت، افزونگی و توسعه‌پذیری؛
• بررسی تناسب پلتفرم با فضای رک، برق و سرمایش؛
• بررسی قابلیت توسعه CPU، RAM، PCIe و Storage؛
• ارزیابی قابلیت‌های مدیریتی و پشتیبانی سازنده.

طراحی پردازنده

• تعیین خانواده، نسل و معماری پردازنده؛
• تعیین تعداد Socket و Core موردنیاز؛
• بررسی تناسب فرکانس، تعداد Core و Cache با Workload؛
• توجه به ساختار NUMA و تأثیر آن بر ماشین‌های مجازی بزرگ؛
• بررسی الزامات لایسنسینگ مبتنی بر Core؛
• تعیین نیاز به پردازنده‌های ویژه یا شتاب‌دهنده‌ها.

طراحی حافظه

• تعیین ظرفیت RAM هر Host؛
• انتخاب نوع و سرعت DIMM؛
• طراحی نحوه توزیع DIMMها بین Memory Channelها؛
• حفظ تعادل بین ظرفیت حافظه، پهنای باند و قابلیت توسعه؛
• پیش‌بینی Slotهای آزاد برای افزایش ظرفیت آینده؛
• بررسی نیاز به Memory Persistent یا ظرفیت‌های بسیار بالا.

طراحی Boot و ذخیره‌سازی محلی

• تعیین روش Boot سیستم‌عامل یا Hypervisor؛
• طراحی افزونگی دیسک‌های Boot؛
• تعیین نیاز به SSD یا NVMe محلی؛
• طراحی RAID برای بارهای کاری Local Storage؛
• بررسی نیاز به Cache یا Tier پردازشی محلی؛
• تفکیک ذخیره‌سازی سیستم‌عامل از Data در صورت نیاز.

طراحی اتصالات و کارت‌های توسعه

• تعیین تعداد و سرعت کارت‌های شبکه؛
• تعیین تعداد HBAها یا Storage Adapterها؛
• طراحی اتصال افزونه به SAN Fabric و شبکه دیتاسنتر؛
• بررسی تعداد و نسل PCIe Laneها؛
• تعیین نیاز به GPU، DPU یا سایر Acceleratorها؛
• پیش‌بینی پورت و Slot کافی برای توسعه آتی.

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

۵. طراحی معماری مجازی‌سازی و مدیریت منابع

در این مرحله، لایه Hypervisor، ساختار کلاستر و سیاست‌های مدیریت منابع طراحی می‌شود.

فعالیت‌های اصلی عبارت‌اند از:

• انتخاب یا تثبیت پلتفرم مجازی‌سازی؛
• تعیین نسخه و Edition مناسب Hypervisor؛
• طراحی ساختار Management Plane؛
• تعیین تعداد و اندازه کلاسترهای مجازی‌سازی؛
• طراحی HA و Host Failure Response؛
• طراحی Admission Control و ظرفیت Failover؛
• طراحی DRS یا سازوکار توزیع خودکار بار؛
• تعریف سیاست Live Migration؛
• طراحی Resource Poolها؛
• تعیین سیاست CPU و Memory Reservation؛
• تعیین حدود Overcommitment برای گروه‌های مختلف Workload؛
• تعریف سیاست Ballooning، Swapping و Memory Reclamation؛
• طراحی Affinity و Anti-Affinity Ruleها؛
• طراحی Templateها و استاندارد پیکربندی ماشین‌های مجازی؛
• تعیین اندازه استاندارد VMها در قالب T-Shirt Sizing؛
• طراحی دسترسی مدیریتی و تفکیک نقش‌ها؛
• بررسی سازگاری Hypervisor با Compute، Network و Storage.

برای هر سیاست باید علت، دامنه کاربرد و استثناهای آن مشخص شود تا معماری در مرحله بهره‌برداری به تنظیمات پراکنده و غیرقابل‌کنترل تبدیل نشود.

نتیجه این مرحله: طراحی تفصیلی لایه مجازی‌سازی و سیاست‌های تخصیص و مدیریت منابع.

۶. طراحی پایداری، افزونگی و دسترس‌پذیری

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

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

• شناسایی Fault Domainهای معماری؛
• انتخاب مدل افزونگی N+1، N+2 یا N+N؛
• محاسبه ظرفیت قابل‌استفاده پس از خرابی یک یا چند Host؛
• طراحی توزیع Hostها میان رک‌ها یا Chassisهای مختلف؛
• طراحی اتصال سرورها به مسیرهای برق مستقل؛
• پیش‌بینی منبع تغذیه افزونه برای هر سرور؛
• طراحی NIC Teaming یا Bonding؛
• طراحی اتصال افزونه به Switchهای شبکه؛
• طراحی Dual HBA و Multipathing برای اتصال Storage؛
• تعیین رفتار کلاستر در خرابی Host، شبکه یا مسیر Storage؛
• تعیین Restart Priority برای ماشین‌های مجازی؛
• طراحی ظرفیت لازم برای Maintenance Mode؛
• تعیین نحوه مدیریت خرابی هم‌زمان چند مؤلفه؛
• بررسی انطباق معماری با RTO سرویس‌های سازمان؛
• طراحی سناریوهای Failover و بازگشت به شرایط عادی.

در این مرحله باید تفاوت میان High Availability و Disaster Recovery حفظ شود. افزونگی داخل یک کلاستر یا دیتاسنتر جایگزین طراحی DR بین سایت‌ها نیست، اما باید با معماری DR سازمان هماهنگ باشد.

نتیجه این مرحله: سند معماری Resilience، ماتریس تحمل خرابی و سناریوهای Failover.

۷. طراحی یکپارچگی Compute با شبکه و ذخیره‌سازی

زیرساخت پردازشی بدون هماهنگی با لایه‌های Network و Storage قابل طراحی نیست. در این مرحله، الزامات اتصال و تعامل این لایه‌ها مشخص می‌شود.

فعالیت‌های اصلی عبارت‌اند از:

• تعیین تعداد و سرعت Uplinkهای هر Host؛
• طراحی تفکیک ترافیک‌های Management، VM، Migration، Backup و Storage؛
• تعیین نیاز به VLAN، Trunk، MTU و Jumbo Frame؛
• طراحی افزونگی اتصالات شبکه‌ای؛
• تعیین نیازمندی‌های East-West و North-South Traffic؛
• تعیین تعداد HBA و پورت‌های Fibre Channel؛
• تعیین سرعت اتصال به SAN Fabric؛
• مشخص‌کردن الزامات Multipathing؛
• تعیین نیازمندی‌های Datastore، LUN یا Volume در سطح Compute؛
• بررسی تناسب IOPS، Throughput و Latency ذخیره‌سازی با Workload؛
• طراحی اتصال به Backup Infrastructure؛
• بررسی سازگاری Firmware، Driver و Adapterها با Network و Storage؛
• تعیین وابستگی‌های بین‌تیمی برای پیاده‌سازی معماری.

طراحی تفصیلی SAN، LAN و Storage می‌تواند در دامنه خدمات تخصصی مربوط به همان حوزه‌ها انجام شود؛ اما نیازمندی‌های آن‌ها باید در سند معماری Compute به‌صورت روشن مشخص شود.

نتیجه این مرحله: ماتریس اتصالات و الزامات یکپارچه‌سازی Compute با Network و Storage.

۸. طراحی مدیریت، مانیتورینگ و عملیات زیرساخت

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

این مرحله شامل موارد زیر است:

• طراحی شبکه و بستر Out-of-Band Management؛
• تعیین روش مدیریت BMC، iLO، iDRAC یا پلتفرم‌های مشابه؛
• طراحی دسترسی‌های مدیریتی و نقش‌های عملیاتی؛
• تعیین ابزارهای مدیریت متمرکز سخت‌افزار و Hypervisor؛
• تعریف شاخص‌های مانیتورینگ CPU، RAM، Network، Power و Temperature؛
• تعیین شاخص‌هایی مانند CPU Ready، Memory Pressure و Host Contention؛
• طراحی Thresholdها و سیاست‌های هشدار؛
• طراحی ارسال رویدادها به سامانه مانیتورینگ یا SIEM؛
• تعیین الزامات ثبت و نگهداری Logها؛
• طراحی سیاست Patch Management؛
• طراحی چرخه به‌روزرسانی Firmware، Driver و Hypervisor؛
• تعیین Maintenance Window و روش کاهش اختلال؛
• طراحی Backup از تنظیمات مدیریتی؛
• تدوین Baseline پیکربندی و روش کنترل تغییرات؛
• تعیین نیازمندی‌های اتوماسیون و Infrastructure as Code.

نتیجه این مرحله: معماری مدیریت و مانیتورینگ و الزامات عملیاتی زیرساخت جدید.

۹. طراحی امنیت و سخت‌سازی زیرساخت پردازشی

در این مرحله، کنترل‌های امنیتی مرتبط با سرورها، Hypervisor و سامانه‌های مدیریتی در معماری لحاظ می‌شوند.

فعالیت‌های این مرحله عبارت‌اند از:

• طراحی تفکیک شبکه مدیریت از شبکه سرویس؛
• محدودسازی دسترسی به Management Plane؛
• طراحی Role-Based Access Control؛
• تعیین الزامات احراز هویت متمرکز و چندمرحله‌ای؛
• تعیین سیاست حساب‌های محلی و اضطراری؛
• طراحی ثبت، نگهداری و پایش رویدادهای مدیریتی؛
• تعیین Baseline سخت‌سازی سرورها و Hypervisor؛
• غیرفعال‌سازی سرویس‌ها و پروتکل‌های غیرضروری؛
• طراحی Secure Boot و TPM در صورت نیاز؛
• تدوین سیاست مدیریت رمز عبور و Secret؛
• تعیین سیاست Patch و اصلاح آسیب‌پذیری‌ها؛
• طراحی دسترسی امن پیمانکاران و تیم‌های پشتیبانی؛
• بررسی الزامات امنیتی کنسول‌های Out-of-Band؛
• تطبیق معماری با استانداردها و سیاست‌های امنیتی سازمان.

نتیجه این مرحله: الزامات امنیتی و Hardening Baseline زیرساخت پردازشی.

۱۰. تحلیل گزینه‌ها و انتخاب سناریوی معماری

در پروژه‌هایی که بیش از یک راهکار قابل‌اجرا وجود دارد، گزینه‌های معماری طراحی و با یکدیگر مقایسه می‌شوند.

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

• توسعه معماری موجود؛
• جایگزینی کامل سرورهای قدیمی؛
• معماری Rack در برابر Blade یا Modular؛
• معماری سه‌لایه در برابر HCI؛
• تمرکز کلاسترها در برابر تفکیک آن‌ها؛
• استفاده از پلتفرم مجازی‌سازی موجود یا مهاجرت به پلتفرم دیگر؛
• معماری On-Premises، Hybrid یا Cloud-Integrated؛
• خرید یک‌مرحله‌ای در برابر توسعه فازبندی‌شده.

هر گزینه بر اساس معیارهای زیر ارزیابی می‌شود:

• انطباق با نیازهای فنی؛
• ظرفیت و مقیاس‌پذیری؛
• دسترس‌پذیری و تحمل خرابی؛
• پیچیدگی پیاده‌سازی و بهره‌برداری؛
• ریسک مهاجرت؛
• هزینه سرمایه‌ای و عملیاتی؛
• هزینه لایسنس و پشتیبانی؛
• امکان تأمین و پشتیبانی تجهیزات؛
• وابستگی به سازنده؛
• طول عمر و قابلیت توسعه آینده.

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

۱۱. تهیه LOM/BOM و مشخصات فنی

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

این مرحله شامل موارد زیر است:

• تعیین تعداد و مشخصات سرورها؛
• تعیین CPU, RAM و Storage داخلی هر سرور؛
• تعیین NIC, HBA, GPU یا کارت‌های توسعه؛
• تعیین Power Supply, Cable و Transceiverهای موردنیاز؛
• تعیین تجهیزات یا ماژول‌های مدیریتی؛
• تعیین لایسنس‌های Hypervisor و Management Platform؛
• تعیین لایسنس‌های وابسته به Core، Socket یا Host؛
• تعیین خدمات نصب، پشتیبانی و Warranty؛
• تعیین اقلام Spare در صورت نیاز؛
• بررسی سازگاری فنی تمامی Part Numberها؛
• تعیین اقلام اختیاری برای توسعه آینده؛
• تفکیک اقلام ضروری، پیشنهادی و توسعه‌ای؛
• تهیه مشخصات فنی Vendor-Neutral برای فرایند استعلام یا مناقصه.

برای حفظ استقلال طراحی، بهتر است دو سطح خروجی تهیه شود:

• LOM: فهرست منطقی اقلام و ظرفیت‌های موردنیاز، بدون وابستگی غیرضروری به برند؛
• BOM: فهرست دقیق تجهیزات و Part Numberها بر اساس سازنده یا راهکار منتخب.

نتیجه این مرحله: LOM/BOM، مشخصات فنی خرید و ماتریس پیکربندی تجهیزات.

۱۲. تدوین نقشه راه پیاده‌سازی یا گذار

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

فعالیت‌های این مرحله عبارت‌اند از:

• تعیین فازهای تأمین، نصب، پیکربندی و انتقال؛
• مشخص‌کردن ترتیب ورود تجهیزات جدید به مدار؛
• طراحی Pilot یا Proof of Concept در صورت نیاز؛
• طراحی سناریوی انتقال Workloadها؛
• تعیین روش Live Migration یا Cold Migration؛
• برنامه‌ریزی برای تخلیه Hostهای قدیمی؛
• تعیین Maintenance Windowها؛
• شناسایی وابستگی‌های Compute، Storage و Network؛
• تعریف پیش‌نیازهای هر فاز؛
• تدوین Rollback Plan؛
• تعیین آزمون‌های پذیرش فنی؛
• تعریف معیارهای Go/No-Go؛
• برنامه‌ریزی خروج تجهیزات قدیمی از مدار؛
• تعیین نیازهای آموزشی و انتقال دانش؛
• اولویت‌بندی اقدامات بر اساس ریسک و اهمیت سرویس.

نتیجه این مرحله: نقشه راه اجرایی و برنامه گذار از معماری موجود به معماری هدف.

۱۳. اعتبارسنجی و بازبینی نهایی معماری

پیش از تحویل نهایی، معماری پیشنهادی از نظر فنی، عملیاتی و اجرایی اعتبارسنجی می‌شود.

این مرحله شامل موارد زیر است:

• بازبینی انطباق طراحی با نیازمندی‌های اولیه؛
• کنترل مجدد محاسبات ظرفیت؛
• بررسی ظرفیت معماری در سناریوی خرابی؛
• کنترل سازگاری سخت‌افزار، Firmware، Driver و Hypervisor؛
• بررسی محدودیت‌های برق، رک و سرمایش؛
• بازبینی الزامات شبکه و ذخیره‌سازی؛
• کنترل لایسنس‌ها و قراردادهای پشتیبانی؛
• بررسی قابلیت توسعه در افق طراحی؛
• مرور سناریوهای مهاجرت و Rollback؛
• برگزاری جلسه Design Review با ذی‌نفعان؛
• ثبت تصمیم‌ها، فرضیات و استثناهای معماری؛
• اعمال اصلاحات و اخذ تأیید نهایی کارفرما.

نتیجه این مرحله: نسخه نهایی و تأییدشده معماری پردازشی.

خروجی‌ها و تحویل‌دادنی‌ها

خروجی‌های این خدمت، متناسب با دامنه پروژه، شامل موارد زیر است:

• سند نیازمندی‌ها و معیارهای طراحی؛
• سند معماری سطح بالا HLD؛
• سند طراحی تفصیلی LLD؛
• مدل Sizing و ظرفیت موردنیاز؛
• ماتریس تخصیص CPU، RAM و منابع؛
• توپولوژی منطقی و فیزیکی زیرساخت؛
• ماتریس پیکربندی سرورها؛
• طراحی کلاسترها و سیاست‌های مجازی‌سازی؛
• طراحی HA, DRS و Admission Control؛
• ماتریس تحمل خرابی و ظرفیت Failover؛
• الزامات اتصال به شبکه و ذخیره‌سازی؛
• معماری مدیریت، مانیتورینگ و Logging؛
• الزامات امنیتی و Hardening؛
• ماتریس مقایسه سناریوهای پیشنهادی؛
• فهرست منطقی تجهیزات LOM؛
• فهرست دقیق تجهیزات BOM؛
• مشخصات فنی خرید یا اسناد فنی مناقصه؛
• نقشه راه پیاده‌سازی و مهاجرت؛
• برنامه آزمون و معیارهای پذیرش؛
• فهرست فرضیات، محدودیت‌ها و ریسک‌های طراحی.