خرید سرور سازمانی معمولاً با یک سؤال ساده شروع میشود: «چه سروری بخریم؟» اما اگر اولین تصمیم شما انتخاب مدل، تعداد هسته پردازنده یا ظرفیت RAM باشد، یک مرحله مهم را نادیده گرفتهاید.
در یک پروژه حرفهای، انتخاب سرور از Workload یا بار کاری شروع میشود؛ یعنی ابتدا باید مشخص شود چه نرمافزارهایی قرار است اجرا شوند، چند کاربر همزمان از آنها استفاده میکنند، حجم و نرخ رشد داده چقدر است، چه میزان Downtime قابل قبول است و سازمان در سه تا پنج سال آینده چه برنامهای دارد. بعد از آن میتوان درباره CPU ،RAM، Storage ،RAID ،Network، Form Factor و حتی تعداد سرورها تصمیم گرفت.
اهمیت این موضوع با تحولات جدید بازار بیشتر شده است. طبق دادههای IDC، درآمد جهانی بازار Server در سهماهه اول سال ۲۰۲۶ به حدود ۱۲۲٫۶ میلیارد دلار رسیده و بیش از ۳۰ درصد نسبت به سال قبل رشد کرده است. یکی از محرکهای اصلی این رشد، توسعه زیرساختهای AI بوده است. این روند نشان میدهد سرورهای جدید فقط برای File Server و Database ساخته نمیشوند؛ معماریهای جدید باید مجازیسازی، پردازش داده، GPU ،AI، شبکههای سریعتر و حجم بیشتری از حافظه را نیز پوشش دهند.
اما برای بیشتر سازمانها، قدرتمندترین سرور بازار بهترین سرور نیست. بهترین انتخاب، سیستمی است که با Performance، Availability ،Security ،Scalability و TCO موردنیاز سازمان تطابق داشته باشد. در این راهنما مسیر انتخاب یک سرور سازمانی را از نیازسنجی تا طراحی کانفیگ بررسی میکنیم.
فهرست مطالب
برای مشاوره رایگان با متخصصان رسام تماس بگیرید
گفتوگو در واتساپ
سرور سازمانی دقیقاً چه تفاوتی با یک کامپیوتر قدرتمند دارد؟
ممکن است یک Workstation از نظر CPU ،RAM یا GPU بسیار قدرتمند باشد؛ اما Server فقط مجموعهای از قطعات سریعتر نیست.
سرورهای Enterprise برای کار مداوم، مدیریت از راه دور، توسعهپذیری و کاهش Single Point of Failure طراحی میشوند. ویژگیهایی مانند ECC Memory، منابع تغذیه Redundant ،Hot-Plug Drive ،Remote Management، چند Network Interface ،RAID/HBA ،Firmware Management و قابلیت تعویض برخی قطعات بدون خاموشکردن سیستم، بخشی از همین معماری هستند؛ بنابراین هنگام انتخاب سرور، سؤال نباید فقط این باشد:
«این سیستم چقدر سریع است؟»
باید پرسید:
«اگر یک Disk، Power Supply، Fan یا Network Path خراب شود، چه اتفاقی برای سرویس سازمان میافتد؟»
قبل از انتخاب سرور، Workload را مشخص کنید
مهمترین مرحله Sizing سرور، تهیه فهرستی از Workloadهاست؛ برای مثال دو شرکت هر دو ممکن است ۱۵۰ کاربر داشته باشند؛ اما شرکت اول فقط File Server، Active Directory و نرمافزار حسابداری اجرا کند و شرکت دوم ERP، SQL Server، نرمافزار BI و ۳۰ ماشین مجازی داشته باشد. تعداد کاربر این دو شرکت تقریباً یکسان است؛ اما نیاز سختافزاری آنها کاملاً متفاوت خواهد بود.
یک چارچوب اولیه میتواند به شکل زیر باشد:
| Workload | عامل مهمتر |
|---|---|
| Active Directory و DNS | پایداری و Redundancy |
| File Server | ظرفیت، IOPS و شبکه |
| SQL / Database | Latency، RAM و CPU |
| ERP | CPU، RAM، Database Performance |
| Virtualization | Core، RAM، Network و Redundancy |
| VDI | CPU، RAM و در برخی موارد GPU |
| Backup Server | ظرفیت، Throughput و شبکه |
| AI / Inference | GPU، PCIe، RAM، برق و Cooling |
| CCTV / Archive | ظرفیت، Write Throughput و Retention |
این جدول یک Rule ثابت نیست؛ زیرا رفتار خود نرمافزار و تعداد تراکنشها میتواند نتیجه را تغییر دهد.
به همین دلیل در پروژههای موجود، بهترین منبع برای Sizing معمولاً Monitoring واقعی سیستم فعلی است، نه حدس.
هنگام خرید سرور به Average نگاه نکنید؛ Peak Load مهمتر است
یکی از اشتباهات رایج هنگام ارتقای سرور این است که مدیر IT متوسط مصرف CPU یا RAM را بررسی کند.
فرض کنید CPU Server در طول روز بهطور متوسط ۲۵ درصد مصرف دارد؛ اما بین ساعت ۹ تا ۱۱ صبح بار پردازشی مرتباً به ۹۰ درصد میرسد. Average پایین در این حالت میتواند گمراهکننده باشد.
برای Workloadهای مهم بهتر است دادههایی مانندPeak Usage ،P95/P99 Latency ،IOPS ،Throughput Memory Working Set و Concurrent Users بررسی شوند؛ برای مثال P95 یعنی ۹۵ درصد اندازهگیریها کمتر از آن مقدار بودهاند. چنین شاخصی تصویر واقعیتری از وضعیت سیستم نسبت به Average ارائه میدهد.
در یک پروژه Migration، بهتر است حداقل چند هفته Performance سیستم فعلی ثبت شود تا مشخص شود گلوگاه واقعی CPU است، RAM است، Storage است یا Network.
چه نوع سروری برای سازمان مناسب است؟
Serverها را میتوان از چند زاویه دستهبندی کرد؛ برای مثال بر اساس Form Factor به Tower، Rack و Blade و بر اساس نوع کاربرد به File Server، Database Server، Virtualization Host، Backup Server و سایر گروهها تقسیم میشوند.
در اغلب شرکتهای کوچک، یک یا چند Tower Server ممکن است کافی باشد. در دیتاسنتر یا Server Room مجهز، Rack Server معمولاً امکان تراکم، کابلکشی و مدیریت بهتری ارائه میدهد. Blade و معماریهای Dense نیز برای محیطهایی با تراکم بالاتر کاربرد دارند؛ اما Form Factor بهتنهایی Performance را تعیین نمیکند. برای مثال HPE ProLiant ML350 Gen11 یک Tower دوپردازندهای است که قابلیت تبدیل به Rack را نیز دارد؛ بنابراین Tower لزوماً مترادف سرور ضعیف یا ابتدایی نیست.
Rack یا Tower؛ انتخاب فقط به اندازه شرکت وابسته نیست
قاعده رایج «شرکت کوچک = Tower و شرکت بزرگ = Rack» بیش از حد ساده است. Tower Server زمانی منطقی است که سازمان رک استاندارد ندارد، تعداد سرورها محدود است یا توسعه زیرساخت در مقیاس کوچک انجام میشود.
Rack Server زمانی مزیت بیشتری پیدا میکند که چند Server، Switch، Storage و UPS باید بهشکل استاندارد مدیریت شوند. کابلکشی، Power Distribution، Airflow و افزایش تعداد Nodeها نیز در Rack سادهتر است؛ اما پیش از خرید Rack Server باید هزینه زیرساخت جانبی آنکه شامل موارد زیر است نیز دیده شود:
رک، PDU، UPS، Cooling، کابلکشی، Switch و فضای فیزیکی بخشی از TCO هستند. برای نمونه، HPE DL380 Gen12 یک سرور ۲U است که تا دو Intel Xeon 6، تا ۸ ترابایت Memory و PCIe Gen5 را پشتیبانی میکند. این مشخصات نشان میدهد Form Factor دو یونیتی هنوز یکی از طراحیهای اصلی برای Workloadهای Enterprise است.
CPU سرور را چگونه انتخاب کنیم؟
در انتخاب Processor فقط به تعداد Core نگاه نکنید؛ پارامترهای تعداد هسته، فرکانس، Cache، تعداد Socket، Memory Channel، PCIe Lane، توان حرارتی و رفتار واقعی نرمافزار هم اهمیت زیادی دارند. برای مثال یک Database ممکن است از CPU با تعداد Core کمتر اما فرکانس بالاتر نتیجه بهتری بگیرد؛ درحالیکه Virtualization Host معمولاً از Coreهای بیشتر استفاده مؤثرتری میکند.
در نسلهای جدید این تفاوت بیشتر شده است. Intel در فوریه ۲۰۲۵ خانواده Xeon 6 سری ۶۷۰۰P و ۶۵۰۰P را معرفی کرد که علاوه بر افزایش تعداد Core، پهنای باند Memory بیشتری نسبت به نسل قبلی ارائه میکنند. خانواده AMD EPYC 9005 نیز در مدلهای بالاتر تا ۱۹۲ Core و ۱۲ کانال DDR5 ارائه میشود و از PCIe Gen5 و CXL پشتیبانی میکند.
این اعداد جذاب هستند؛ اما برای همه سازمانها لازم نیستند. گاهی یک CPU بیستوچند هستهای متناسب با Workload، انتخاب منطقیتری از یک CPU سرور صد هستهای است.
نکتهای که در خرید CPU معمولاً فراموش میشود
CPU فقط هزینه Hardware ایجاد نمیکند. برخی نرمافزارهای Enterprise براساس تعداد Core لایسنس میشوند.
در Windows Server 2025، اگر Licensing بر مبنای Physical Core انجام شود، تمام Coreهای فیزیکی باید لایسنس شوند؛ با حداقل ۸ Core برای هر Processor و ۱۶ Core برای هر Server. SQL Server نیز در مدل Per-Core هزینه لایسنس را به تعداد Core مرتبط میکند و برای Licensing فیزیکی حداقل چهار Core برای هر Physical Processor اعمال میشود.
ممکن است اختلاف هزینه نرمافزار طی چند سال بسیار بیشتر از اختلاف قیمت CPU باشد. در Workloadهایی که Licensing بر اساس Core انجام میشود، گاهی تعداد Core کمتر و Performance هر Core بالاتر TCO بهتری ایجاد میکند. این موضوع باید قبل از سفارش Hardware محاسبه شود؛ نه بعد از خرید سرور.
RAM سرور؛ ظرفیت بیشتر همیشه کافی نیست
در بسیاری از پروژههای Virtualization، RAM زودتر از CPU به گلوگاه تبدیل میشود؛ اما انتخاب RAM فقط تعیین ظرفیت ۱۲۸، ۲۵۶ یا ۵۱۲ گیگابایت نیست و باید مواردی مانند نوع DIMM ،ECC، تعداد Channel، Memory Population Rule، سرعت، تعداد DIMM موجود و ظرفیت توسعه آینده بررسی شوند.
یک اشتباه رایج این است که برای رسیدن به ظرفیت فعلی، تمام Slotهای Memory پر شوند. برای مثال ممکن است دو Configuration هر دو ۲۵۶GB RAM داشته باشند؛ اما یکی تمام Slotهای قابل استفاده را اشغال کرده باشد و دیگری امکان ارتقای سادهتری داشته باشد. اگر سازمان یک سال بعد به ۵۱۲GB نیاز پیدا کند، در گزینه اول شاید مجبور به تعویض DIMMهای موجود شوید.
در محیط مجازیسازی نیز باید مجموع RAM ماشینهای مجازی، حافظه موردنیاز Hypervisor و Headroom برای Failover در نظر گرفته شود.
Microsoft برای Hyper-V تأکید میکند که حافظه کافی باید هم برای Host و هم برای تمام VMهای همزمان در نظر گرفته شود؛ یعنی Minimum Requirement سیستمعامل نباید مبنای Sizing یک Virtualization Host باشد.
Storage را براساس ظرفیت انتخاب نکنید
جمله «ما ۱۰ ترابایت فضا لازم داریم» برای انتخاب Storage کافی نیست. دو Workload ممکن است هر دو ۱۰TB ظرفیت بخواهند، اما Performance آنها کاملاً متفاوت باشد.
برای Storage حداقل باید چهار پارامتر زیر مشخص شود:
- Capacity
- IOPS
- Throughput
- Latency
Database تراکنشی ممکن است Latency پایین و IOPS بالا بخواهد؛ درحالیکه Archive ویدئو بیشتر به Capacity و Sequential Throughput حساس است.
نوع Drive نیز باید براساس Workload انتخاب شود. HDD برای Capacity بالا همچنان کاربرد دارد؛ اما SSD و NVMe در Workloadهای I/O Intensive اختلاف Performance زیادی ایجاد میکنند.
درایو Boot سیستمعامل نیز بهتر است از Data Driveها جدا طراحی شود تا Failure Domain و عملیات Maintenance سادهتر شود.
RAID Controller را قبل از مشخصشدن معماری Storage انتخاب نکنید
RAID Controller در بسیاری از سرورهای سنتی نقش مهمی در Redundancy و Performance Storage دارد؛ اما انتخاب آن باید بعد از تعیین معماری انجام شود. برای مثال در یک File Server سنتی ممکن است Hardware RAID کاملاً مناسب باشد؛ اما در معماریهای Software-Defined Storage، شرایط میتواند متفاوت باشد.
Microsoft در مستندات Storage Spaces Direct برای Windows Server 2025 تأکید میکند Driveها باید Direct-Attached باشند و HBA یا Controller باید امکان Pass-through مناسب را فراهم کند؛ RAID Controllerهایی که چنین دسترسی مستقیمی نمیدهند برای این معماری پشتیبانی نمیشوند.
این مثال نشان میدهد که RAID Controller را نباید صرفاً چون «سرور حرفهای باید RAID داشته باشد» انتخاب کرد. ابتدا باید مشخص شود Storage توسط چه Software Stackی مدیریت خواهد شد.
یک نکته حیاتی این است که RAID جای Backup نیست. RAID میتواند Availability را در برابر برخی خرابیهای Drive افزایش دهد؛ اما از حذف اشتباه، Ransomware یا Disaster محافظت کامل ایجاد نمیکند.
مجازیسازی چگونه انتخاب سرور را تغییر میدهد؟
در گذشته برای هر سرویس ممکن بود یک Physical Server جدا خریداری شود. امروز بسیاری از سازمانها چندین Workload را روی تعداد کمتری Virtualization Host Consolidate میکنند. در این حالت سرور دیگر برای یک Application انتخاب نمیشود؛ باید مجموع نیاز چندین VM را تحمل کند. این موضوع انتخاب Hardware را تغییر میدهد.
CPU باید Virtualization Extension مناسب داشته باشد، RAM ظرفیت بیشتری نیاز دارد، Network باید ترافیک VMها، Management، Storage و Migration را پوشش دهد و Availability نیز معمولاً نیازمند چند Host است.
Windows Server 2025 Hyper-V برای Virtualization به پردازنده ۶۴ بیتی دارای SLAT، قابلیتهای Virtualization سختافزاری و حافظه کافی برای Host و Guestها نیاز دارد.
اما مهمتر از Minimum Requirement، طراحی Failover است. اگر سازمان ۳۰ VM را روی یک Server قدرتمند Consolidate کند، خرابی همان Server میتواند ۳۰ سرویس را همزمان متوقف کند؛ پس Consolidation باید در کنار Cluster، Shared/Distributed Storage، Backup و High Availability طراحی شود.
یک سرور بسیار قدرتمند یا دو سرور متوسط؟
این سؤال در بسیاری از خریدها نادیده گرفته میشود. فرض کنید تمام Workload سازمان روی یک Server بسیار قوی قرار میگیرد. از نظر Performance ممکن است مشکلی وجود نداشته باشد؛ اما اگر Motherboard، CPU یا Firmware همان Host دچار مشکل شود، چه اتفاقی میافتد؟
در سرویسهای Critical گاهی دو یا سه Host با ظرفیت مناسب، Cluster و Failover بهتر از یک Host بسیار قدرتمند هستند.
در طراحی N+1، زیرساخت باید بتواند در صورت خارجشدن یک Node، Workloadهای حیاتی را روی Nodeهای باقیمانده اجرا کند؛ بنابراین هنگام Sizing Virtualization Cluster نباید فرض شود صد درصد Capacity تمام Hostها همیشه در دسترس خواهد بود.
Availability Requirement میتواند تعداد سرورها را تعیین کند، نه فقط Performance Requirement.
Network سرور را دستکم نگیرید
خرید CPU و NVMe سریع در کنار Network کند میتواند کل سیستم را محدود کند. برای File Server، Backup، Virtualization Migration، Software-Defined Storage و Storage over Ethernet، پهنای باند Network باید جداگانه محاسبه شود. در برخی معماریهای Hyperconverged این موضوع حیاتی است.
Microsoft برای Storage Spaces Direct در Clusterهای کوچک حداقل ۱۰GbE را مطرح میکند و برای محیطهای Performance-oriented و Clusterهای بزرگتر، ۲۵GbE یا سریعتر و RDMA را توصیه میکند؛ بنابراین NIC را نباید به گزینهای که «در Config پیشفرض وجود دارد» محدود کرد. تعداد Portها، Speed، Redundancy، OCP/PCIe Slot و Switch Infrastructure باید همزمان طراحی شوند.
برق، خنکسازی و رک بخشی از Sizing سرور هستند
Server قدرتمندتر معمولاً Heat و Power بیشتری تولید میکند در نسل جدید CPUها، TDP برخی پردازندهها چندصد وات است. اضافهشدن GPU، NVMe و کارتهای پرسرعت نیز Power Density رک را بالا میبرد؛ در نتیجه قبل از خرید باید ظرفیت UPS، PDU، Feed برق، Cooling و Rack بررسی شود.
این موضوع در سرورهای جدید آنقدر جدی شده که Direct Liquid Cooling از دنیای Supercomputer وارد برخی Enterprise Serverها شده است. HPE برای بخشی از خانواده ProLiant Gen12 امکان Direct Liquid Cooling ارائه کرده است. این شرکت در مقایسههای داخلی خود برای Gen12 نسبت به سیستمهای قدیمی Enterprise نیز تا ۴۱ درصد Performance-per-Watt بهتر را گزارش میکند؛ این اعداد Vendor-specific هستند و باید برای Configuration واقعی سازمان جداگانه اعتبارسنجی شوند.
برای بیشتر شرکتها هنوز Air Cooling کافی است؛ اما Power Budget باید قبل از Purchase Order کنترل شود.
امنیت سختافزاری سرور در سال ۲۰۲۶
Security دیگر از زمان نصب سیستمعامل شروع نمیشود. در انتخاب Server Enterprise جدید بهتر است قابلیتهایی مانند Secure Boot، TPM 2.0، Firmware Signing، Hardware Root of Trust، Secure Management و Firmware Update Lifecycle بررسی شوند. برای مثال HPE در نسل ProLiant Gen12 همچنان Silicon Root of Trust و iLO را بهعنوان بخشی از معماری امنیت و مدیریت Server ارائه میکند. DL380 Gen12 همچنین از iLO 7 برای Remote Management استفاده میکند.
Remote Management Interface نیز باید روی Management Network جدا قرار گیرد و دسترسی آن محدود شود. قرار دادن Interfaceهایی مانند iLO یا iDRAC بدون کنترل مناسب در معرض Internet، ریسک غیرضروری ایجاد میکند. در خرید Server استوک نیز Firmware Lifecycle و وجود Updateهای امنیتی باید بررسی شود.
سرور نو، نسل قبلی یا استوک؟
این سؤال بهخصوص در بازار ایران اهمیت زیادی دارد. یک Server نسل قبلی ممکن است از نظر قیمت اولیه جذاب باشد و برای بسیاری از Workloadهای کمریسک نیز کاملاً کافی باشد؛ اما مقایسه فقط براساس قیمت خرید میتواند اشتباه باشد.
قبل از خرید باید Support Lifecycle، Firmware Update، سازگاری سیستمعامل و Hypervisor، مصرف برق، نسل PCIe، نوع RAM، امکان تهیه قطعه و عمر باقیمانده Platform بررسی شود.
برای یک Lab، Archive یا سرویس غیرحیاتی، سختافزار قدیمیتر میتواند اقتصادی باشد؛ اما برای ERP اصلی سازمان، Virtualization Cluster یا Database Mission-Critical، هزینه Downtime ممکن است چندین برابر صرفهجویی اولیه باشد.
معیار تصمیم باید Risk–adjusted TCO باشد؛ یعنی هزینه خرید، انرژی، Support، لایسنس، احتمال خرابی و هزینه توقف سرویس با هم سنجیده شوند.
ظرفیت سرور را چگونه پیشبینی کنیم؟
خرید سرور فقط برای نیاز امروز، معمولاً باعث Upgrade زودهنگام میشود. از طرف دیگر Oversizing شدید نیز سرمایه سازمان را بلااستفاده نگه میدارد. بهتر است Growth Rate واقعی دادهها و Workload اندازهگیری شود.
اگر سازمان امروز ۱۰TB داده دارد و حجم داده هر سال ۲۵ درصد رشد میکند، ظرفیت سه سال بعد تقریباً برایر با مقدار زیر خواهد بود:
۱۰ × ۱٫۲۵³ ≈ ۱۹٫۵ TB
؛نه ۱۷٫۵TB. این تفاوت به دلیل Compound Growth است.
همین منطق برای تعداد VM، RAM، Storage Throughput و تعداد کاربران نیز قابل استفاده است.
در کنار Capacity باید امکان Physical Expansion نیز بررسی شود:Drive Bay ،DIMM Slot ،PCIe Slot CPU Socket ،PSU Capacity و Network Expansion.
یک سناریوی واقعی برای انتخاب سرور سازمانی
فرض کنیم شرکتی با ۱۲۰ کاربر میخواهد زیرساخت قدیمی خود را نوسازی کند. Workloadها شامل Active Directory، File Server، ERP، SQL Server، نرمافزار حسابداری، Backup و حدود ۱۵ ماشین مجازی هستند.
روش اشتباه این است که مستقیماً گفته شود برای ۱۲۰ کاربر فلان مدل Server با ۲۵۶GB RAM مناسب است. روش حرفهای ابتدا این سؤالها را پاسخ میدهد:
| معیار | اطلاعات موردنیاز |
|---|---|
| CPU | Peak Utilization و نیاز نرمافزار |
| RAM | مصرف واقعی VMها + Growth |
| Storage | Usable Capacity، IOPS و Latency |
| Network | ترافیک کاربران، Backup و VM |
| Availability | RTO و Downtime قابل قبول |
| Virtualization | تعداد VM و Growth |
| Backup | RPO، Retention و Recovery |
| Software | Licensing و Compatibility |
| Infrastructure | Rack، Power، UPS، Cooling |
| Lifecycle | افق استفاده ۳ تا ۵ سال |
ممکن است نتیجه Analysis نشان دهد دو Virtualization Host متوسط با Storage مناسب و Backup مستقل، انتخاب بهتری از یک Server بسیار بزرگ هستند.
یا ممکن است برای سازمان کوچکتر یک Tower Server با Redundant PSU و ظرفیت توسعه کافی اقتصادیتر باشد.
Sizing نتیجه Analysis است، نه نقطه شروع آن.
چکلیست نهایی انتخاب سرور سازمانی
قبل از Purchase Order، پاسخ این موارد باید روشن باشد:
| سؤال | چرا مهم است؟ |
|---|---|
| Workload دقیق چیست؟ | مبنای تمام Sizing |
| Peak Load چقدر است؟ | جلوگیری از Under-sizing |
| رشد ۳ تا ۵ ساله چقدر است؟ | جلوگیری از Upgrade زودهنگام |
| RTO/RPO چیست؟ | تعیین Availability و Backup |
| Rack یا Tower؟ | تعیین زیرساخت فیزیکی |
| CPU چند Core و چه Frequency؟ | Performance و Licensing |
| RAM چقدر و با چه مسیر Upgrade؟ | Performance و Scalability |
| Storage چه IOPS/Latency میخواهد؟ | جلوگیری از گلوگاه |
| RAID یا HBA؟ | وابسته به Storage Architecture |
| چند NIC و با چه Speed؟ | Performance و Redundancy |
| Single یا Multi-Host؟ | Availability |
| Power و Cooling کافی است؟ | امکان بهرهبرداری واقعی |
| Hardware روی HCL نرمافزار هست؟ | Compatibility |
| TCO چندساله چقدر است؟ | تصمیم اقتصادی صحیح |
برای تبدیل این چارچوب به یک فرایند گامبهگام Sizing و Purchase، مقاله کلاستر «چگونه سرور مناسب انتخاب کنیم؟» باید چکلیست اجراییتر و مثالهای Config نهایی را ارائه دهد.
سرورهای سازمانی در سال ۲۰۲۶ به کدام سمت میروند؟
سه تغییر مهم در حال شکلدادن بازار هستند:
اول، تراکم Compute و Memory بهسرعت افزایش یافته است. پردازندههای Server جدید تعداد Core بسیار بیشتری ارائه میکنند و Serverهای Mainstream به چندین ترابایت RAM رسیدهاند. برای نمونه DL380 Gen12 در یک Form Factor دو یونیتی تا ۸TB Memory را پشتیبانی میکند.
دوم، AI وارد Server Room سازمانی شده است. تمام شرکتها به GPU Server نیاز ندارند، اما Inference محلی، تحلیل تصویر، مدلهای خصوصی و AI Applicationها باعث شدهاند پشتیبانی GPU، PCIe Gen5، Power و Cooling به معیارهای مهمتری در Procurement تبدیل شوند. IDC گزارش کرده است هزینه جهانی زیرساخت AI در سال ۲۰۲۵ به حدود ۳۱۸ میلیارد دلار رسیده که بیش از دو برابر سال ۲۰۲۴ بوده است.
سوم، مرز میان Compute، Storage و Cloud در حال کمرنگشدن است. Hyperconverged Infrastructure و Hybrid Cloud باعث شدهاند یک Server علاوه بر Compute، بخشی از Storage Fabric و Cloud Management Architecture نیز باشد.
با توجه به تغییراتی که گفتیم، خرید Server در سال ۲۰۲۶ فقط Hardware Procurement نیست؛ تصمیمی درباره معماری چند سال آینده سازمان است.
هیچ مدل یا Configuration واحدی را نمیتوان بهعنوان «بهترین سرور سازمانی» برای همه شرکتها معرفی کرد. سرور مناسب سیستمی است که منابع آن با Workload واقعی، سطح Availability، میزان رشد، محدودیتهای فیزیکی و بودجه سازمان هماهنگ باشد.
انتخاب حرفهای از CPU شروع نمیشود. ابتدا باید مشخص کنید چه سرویسهایی قرار است اجرا شوند، Peak Load آنها چقدر است، چه میزان Downtime قابل قبول است و سازمان در سه تا پنج سال آینده به چه ظرفیتی نیاز خواهد داشت. بعد از این مرحله میتوان درباره Rack یا Tower، CPU، RAM، Storage، RAID/HBA، NIC، Power Supply و تعداد Hostها تصمیم گرفت.
در Serverهای جدید، چند نکته بیش از گذشته اهمیت پیدا کردهاند. تعداد Core بالاتر لزوماً اقتصادیتر نیست؛ زیرا Licensing برخی نرمافزارها به Core وابسته است. RAM باید علاوه بر ظرفیت، با توجه به Memory Channel و مسیر Upgrade طراحی شود. Storage را نیز نباید فقط برحسب ترابایت مقایسه کرد؛ IOPS، Latency و Throughput ممکن است مهمتر باشند.
در محیط Virtualization نیز Consolidation بدون High Availability میتواند Failure Domain بزرگی ایجاد کند. گاهی دو Host متعادل از یک Server بسیار قدرتمند انتخاب مطمئنتری هستند. از طرف دیگر، Security، Remote Management، Firmware Lifecycle، برق، Cooling و Compatibility با OS و Hypervisor باید پیش از خرید بررسی شوند؛ نه زمانی که Server وارد سازمان شده است.
در نهایت میتوان فرایند صحیح را در این مسیر خلاصه کرد:
Workload → Performance Requirement → SLA → Growth → Architecture → Hardware → Licensing → TCO
اگر این ترتیب رعایت شود، احتمال خرید Server بیش از نیاز، کمبود زودهنگام منابع یا هزینههای پیشبینینشده بهطور محسوسی کاهش پیدا میکند.
کارشناسان رسام با بررسی Workload، Performance فعلی، تعداد کاربران، ساختار مجازیسازی، ظرفیت Storage، RPO/RTO، رشد آینده و محدودیت بودجه، کانفیگ سرور متناسب با نیاز واقعی سازمان را طراحی و پیشنهاد میکنند.
برای انتخاب سرور سازمانی باید از کجا شروع کنیم؟
انتخاب سرور سازمانی باید با بررسی Workload، تعداد کاربران، نرمافزارهای مورد استفاده، میزان رشد داده، نیازهای دسترسپذیری و بودجه سازمان شروع شود.
برای یک سازمان کوچک چه نوع سروری مناسب است؟
برای سازمانهای کوچک معمولاً سرورهای Tower یا Rack با پیکربندی متناسب با سرویسهای موردنیاز انتخاب میشوند. معیار اصلی انتخاب، نیاز واقعی سازمان است نه فقط تعداد کاربران.
چگونه CPU مناسب برای سرور انتخاب کنیم؟
انتخاب CPU سرور باید براساس نوع Workload، تعداد ماشینهای مجازی، نیاز نرمافزارها، تعداد Core، فرکانس، Cache و هزینه لایسنس انجام شود.
آیا RAM بیشتر همیشه باعث عملکرد بهتر سرور میشود؟
خیر. ظرفیت RAM باید براساس مصرف واقعی سرویسها، تعداد VMها، میزان رشد آینده و معماری Memory انتخاب شود.
Rack Server بهتر است یا Tower Server؟
هیچکدام همیشه بهتر نیستند. Rack Server برای محیطهای دیتاسنتری و Tower Server برای بسیاری از سازمانهای کوچک با فضای محدود مناسبتر است.
آیا RAID جای Backup را میگیرد؟
خیر. RAID فقط از خرابی برخی دیسکها جلوگیری میکند و جایگزین Backup برای مقابله با حذف اطلاعات، باجافزار یا Disaster نیست.
آیا برای مجازیسازی به سرور قدرتمند نیاز داریم؟
سرور مجازیسازی باید براساس تعداد VMها، مصرف CPU و RAM، Storage، شبکه و سطح دسترسپذیری طراحی شود.
