پارامترهایی که باید قبل از خرید سرور اچیپی در نظر بگیرید
اگر قرار است برای ۳ تا ۵ سال آینده روی یک زیرساخت پایدار حساب کنید، خرید سرورهای hp فقط انتخاب یک مدل نیست؛ انتخاب «ظرفیت پردازش»، «الگوی I/O»، «ریسک خرابی»، «چرخه پشتیبانی»، و حتی «قابلیت تأمین قطعه در زمان بحران» است. مهندسان زیرساخت معمولاً سرور را نه بر اساس کاتالوگ، بلکه بر اساس رفتار واقعی بار کاری (Workload) و الزامات بهرهبرداری انتخاب میکنند؛ دقیقاً همان جایی که بسیاری از خریدهای اشتباه در ایران و حتی پروژههای بزرگ جهانی اتفاق میافتد: مشخصات روی کاغذ خوب است، اما در عمل گلوگاه جای دیگری است.
1) از همه مهمتر: بار کاری را «اندازهگیری» کنید، نه «حدس»
1-1) پروفایل بار کاری (Workload Profile)
قبل از هر چیزی باید بدانید سرور قرار است چه کاری انجام دهد و فشار اصلی کجاست:
- مجازیسازی (VMware / Hyper-V / Proxmox): معمولاً RAM و IOPS تعیینکنندهاند، نه فقط CPU.
- دیتابیس (SQL Server / Oracle / PostgreSQL): تأخیر ذخیرهسازی و پهنای باند حافظه اهمیت حیاتی دارد.
- VDI: ترکیب سختِ CPU + RAM + Storage Latency؛ بهخصوص در ساعات لاگین صبحگاهی.
- فایلسرور و بکاپ: ظرفیت و Throughput (شبکه و دیسک) غالب است.
- اپلیکیشنهای دولتی با بار متناوب: پیکهای کوتاه ولی سنگین؛ نیازمند Headroom واقعی.
تجربه میدانی مهندسان: در چند پروژهی پرتعداد VM در ایران، “CPU Usage” متوسط زیر ۳۰٪ بود اما سیستم کند گزارش میشد؛ چون Storage زیر بار Random Read/Write خرد میشد و Latency بالا میرفت. نتیجه؟ ارتقای CPU هیچ اثر ملموسی نداشت؛ با اصلاح Tiering و انتخاب کنترلر/دیسک درست، مشکل حل شد.
1-2) شاخصهایی که باید از سیستم فعلی یا PoC بگیرید
حتی اگر فعلاً سرور ندارید، از محیط تست یا لاگهای نرمافزاری میشود تخمین واقعبینانه داشت:
- CPU: درصد استفاده، تعداد Threadهای فعال، طول صف پردازشی
- RAM: Peak، نرخ Page Fault، فشار Cache
- Storage: IOPS، Latency (میلیثانیه)، Queue Depth، نسبت Read/Write، Random/Sequential
- Network: Peak Throughput، تعداد کانکشنها، Packet Rate
2) انتخاب نسل و پلتفرم: فقط «جدیدتر» بودن کافی نیست
شاید بین نسلهای مختلف یا حتی بین مدلهای همنسل مردد باشید. مثلاً اگر در بازار ایران به دنبال یک پلتفرم جاافتاده هستید، بسیاری از سازمانها هنوز با ترکیبهای رایج مثل server hp g10 به هدف پایداری و قطعهپذیری رسیدهاند؛ چون اکوسیستم قطعات، Firmwareهای پایدار، و تجربهی عملیاتی بیشتری در دسترس است.
اما تصمیم درست این است که چرخه عمر (Lifecycle) را ببینید:
- سروری که از نظر Firmware و قطعات به پایان عمر نزدیک است، در پروژههای حساس ریسک میسازد.
- نسل جدیدتر ممکن است امکانات امنیتی/مدیریتی بهتری داشته باشد، ولی اگر زنجیره تأمین و قطعهپشتیبان آن در دسترس نیست، در زمان خرابی شما را زمینگیر میکند.
3) CPU: تعداد هسته مهم است، اما «نوع بار» مهمتر
3-1) فرکانس یا تعداد هسته؟
- اگر بار شما دیتابیس تراکنشی، اپلیکیشنهای تکهستهمحور، یا سرویسهایی با Thread کم است: فرکانس بالاتر و IPC بهتر اولویت دارد.
- اگر بار شما مجازیسازی متراکم، رندر، تحلیل داده یا سرویسهای موازی است: هسته بیشتر و ظرفیت Thread بالاتر بهتر جواب میدهد.
3-2) دام رایج در پروژهها
بعضی سازمانها فقط با نگاه به “Core Count” خرید میکنند و بعد در لایسنسها غافلگیر میشوند. در پروژههای VMware/SQL، گاهی هزینه لایسنس از خود سختافزار بیشتر میشود. بنابراین CPU را باید همزمان با مدل لایسنس نرمافزار انتخاب کنید، نه جدا از آن.
4) RAM: اشتباه رایج «کمبودن RAM» نیست؛ «طراحی اشتباه چینش RAM» است
در سرور، RAM فقط ظرفیت نیست؛ پهنای باند و تعداد کانالهای فعال هم هست. چند نکته عملی:
- چینش نامتقارن DIMMها میتواند پهنای باند حافظه را کاهش دهد.
- در مجازیسازی، کمبود RAM معمولاً با Ballooning/Swapping خودش را به شکل کندیهای عجیب نشان میدهد؛ نه فقط خطای واضح.
- برای دیتابیسها، RAM یعنی Cache. بسیاری از “کندی دیسک”ها در واقع “کمبود Cache” است.
تجربه واقعی: در یک پروژه مجازیسازی با ۲ سوکت CPU، تیم فقط روی یک CPU رم را پر کرده بود (بهخاطر موجودی بازار). نتیجه: کارایی پایینتر از انتظار. با متعادلسازی DIMMها بین دو سوکت و فعال شدن کانالها، بدون افزایش ظرفیت، عملکرد بهتر شد.
5) ذخیرهسازی: اینجاست که ۸۰٪ شکستهای پنهان رخ میدهد
5-1) SSD vs HDD: سوال درست این نیست
سوال درست این است: «Latency هدف شما چند میلیثانیه است؟»
برای اکثر Workloadهای سازمانی:
- HDD برای آرشیو/بکاپ و کارهای Sequential مناسب است.
- SSD برای VMها، دیتابیس، VDI و سرویسهای تراکنشی تقریباً اجتنابناپذیر است.
5-2) NVMe یا SAS/SATA؟
- NVMe: کمترین Latency و بیشترین IOPS؛ عالی برای دیتابیس/VDI/VM تراکم بالا.
- SAS SSD: پایدار، سازگار، در بسیاری از سناریوها کافی و اقتصادیتر.
- SATA SSD: برای برخی بارها قابل قبول، اما در محیطهای سنگین و پایدار باید با احتیاط.
5-3) ظرفیت را با «نسبت Overprovisioning و Write Amplification» ببینید
در بارهای نوشتنی (Write-heavy)، SSDها اگر فضای آزاد کافی نداشته باشند، افت عملکرد ناگهانی میدهند. این چیزی است که در کاتالوگ کمتر دیده میشود اما در عمل بسیار مهم است.
6) کنترلر RAID و HBA: تفاوت بین «روشن شدن سرور» و «پایدار ماندن سرویس»
دو تصمیم کلیدی:
- RAID Controller با Cache و باتری/سوپرکپ: برای نوشتنهای تراکنشی حیاتی است.
- HBA Passthrough: برای SDS و راهکارهایی مثل vSAN/Ceph یا ZFS معمولاً بهتر است.
اشتباه رایج: RAID5 روی SSD برای بار نوشتنی زیاد، یا RAID6 بدون توجه به هزینه CPU/Write Penalty. مهندسهای باتجربه معمولاً RAID را با توجه به RPO/RTO و الگوی نوشتن تعیین میکنند، نه صرفاً “امنتر بودن”.
7) شبکه: اگر امروز 1GbE دارید، فردا گلوگاه شما همینجاست
در بسیاری از سازمانها، سرور قوی خریده میشود اما شبکه همان طراحی قدیمی میماند. نتیجه: VMها، بکاپ، Replication و حتی دسترسی کاربران کند میشود.
- برای مجازیسازی و استوریج شبکهای: حداقل 10GbE (و در سناریوهای جدی 25GbE/40GbE) منطقی است.
- تعداد پورتها را با سناریوی Failover ببینید: LACP، تیمینگ، تفکیک شبکه مدیریت/Storage/VM.
8) پاور، خنکسازی و رک: جزئیات «غیر جذاب» اما تعیینکننده
خیلی از downtimeها از دیتاسنتر شروع میشود، نه از CPU.
- پاور Redundant واقعی + ظرفیت UPS متناسب
- طراحی airflow (بهخصوص در رکهای شلوغ)
- دمای اتاق و اختلاف دمای ورودی/خروجی
- کابلکشی استاندارد برای کاهش خطای انسانی
در پروژههای دولتی، یک قطعی کوتاه برق یا خطای کابلکشی میتواند سرویسهای حیاتی را از کار بیندازد. طراحی درست زیرساخت فیزیکی، مکمل انتخاب سرور است.
9) امنیت و مدیریت: iLO و Firmware را دستکم نگیرید
- دسترسی مدیریتی Out-of-band (مثل iLO) اگر درست امنسازی نشود، خودش یک ریسک است.
- سیاست Firmware: یک سرور با Firmware ناپایدار، حتی با سختافزار عالی، شما را وارد چرخه “عیبیابی بیپایان” میکند.
- لاگبرداری، مانیتورینگ سلامت دیسک/فن/پاور و پیشبینی خرابی (Predictive Failure) باید از روز اول فعال باشد.
10) سازگاری نرمافزاری و Driverها: همان جایی که پروژهها در روز Go-Live گیر میکنند
قبل از خرید، این موارد را چک کنید:
- نسخه دقیق Hypervisor/OS و سازگاری آن با درایورهای Storage و NIC
- پشتیبانی از HCL (خصوصاً برای VMware)
- نیازهای خاص دیتابیس یا اپلیکیشن (AVX، نسخه کرنل، ماژولهای خاص)
تجربه مهندسی: بارها دیده شده سازمان سرور را تحویل میگیرد اما در هفته نصب، به دلیل ناسازگاری Driver NIC یا کنترلر Storage با نسخه OS، مجبور به تغییر برنامه یا حتی تعویض قطعه میشود. این هزینه پنهان، معمولاً از اختلاف قیمت بین دو گزینه بیشتر است.
11) قطعه اصلی نیست؛ «زنجیره تأمین و قطعه جایگزین» اصل است
در ایران، مخصوصاً برای پروژههای حساس و دولتی، سؤال مهم این است:
- اگر پاور/فن/SSD/کنترلر امروز خراب شد، قطعه جایگزین دقیقاً چه زمانی میرسد؟
- قطعه، اصالت و سریال معتبر دارد یا ریسک Refurbished/ریمارک هست؟
- آیا تیمی هست که بتواند در پنجره زمانی محدود، تعویض و بازگردانی سرویس را انجام دهد؟
اینجاست که یک تأمینکننده/پیمانکار متخصص میتواند تفاوت ایجاد کند؛ چون انتخاب سرور بدون برنامه قطعه پشتیبان و SLA، در عمل یعنی پذیرش Downtime.
12) معیارهای انتخاب فروشنده/پیمانکار: از «قیمت» مهمتر، «مسئولیتپذیری عملیاتی» است
برای سازمانهایی که سرویس حیاتی دارند، بهتر است فروشنده صرفاً “فروشنده قطعه” نباشد؛ باید بتواند:
- قبل از خرید، سایزینگ و طراحی ارائه دهد (نه فقط پیشفاکتور)
- در زمان نصب، استاندارد کابلکشی، VLAN، RAID/HBA و Hardening را اجرا کند
- پس از تحویل، مانیتورینگ، Firmware Policy و برنامه نگهداری ارائه کند
- در زمان بحران، قطعه و نیروی اجرایی را سریع تأمین کند
در چنین چارچوبی، برندهایی مثل وینو سرور برای خیلی از تیمهای IT نقش «راهحل اجرایی» پیدا میکنند، نه صرفاً تامین کالا؛ چون پروژههای زیرساختی—بهخصوص در محیطهای دولتی—به تجربه عملیاتی، مستندسازی، و انضباط در تحویل نیاز دارد. اگر کاربر هنگام سرچ به یک تیم برسد که هم سختافزار را میشناسد و هم مسئولیت اجرای استاندارد را میپذیرد، احتمال انتخاب درست بالا میرود.
13) چکلیست فنی سریع قبل از خرید (برای جلوگیری از خریدهای اشتباه)
13-1) سوالات پایه
- Workload چیست و پیک واقعی چه زمانی رخ میدهد؟
- گلوگاه احتمالی CPU/RAM/Storage/Network کجاست؟
- سطح دسترسپذیری لازم (RTO/RPO) چیست؟
13-2) سوالات طراحی
- Storage: Latency هدف چند ms است؟ Random/Sequential چقدر است؟
- RAID/HBA: نیاز به Cache دارید یا Passthrough؟
- Network: حداقل 10GbE لازم است؟ چند uplink برای Redundancy؟
- Power/Cooling: رک و برق و UPS آماده است؟
13-3) سوالات بهرهبرداری
- قطعه یدکی حیاتی دارید؟ زمان تأمین چقدر است؟
- برنامه Firmware و Patch Management چیست؟
- چه کسی مسئول عیبیابی لایههای مختلف است (سرور/شبکه/استوریج/هایپروایزر)؟
جمعبندی: خرید سرور موفق یعنی مهندسیِ قبل از خرید
سرور مناسب، سروری است که با «داده واقعی بار کاری»، «طراحی ذخیرهسازی و شبکه»، و «برنامه پشتیبانی عملیاتی» انتخاب شود. اگر این سه ضلع درست بسته شود، حتی یک پلتفرم میانرده میتواند سالها پایدار بماند؛ و اگر هر کدام نادیده گرفته شود، بهترین کانفیگ روی کاغذ هم در روزهای شلوغ سازمان شما را غافلگیر میکند.