اگر قرار باشد برای SQL Server یک سرور جدید تهیه کنید، از کجا مطمئن می‌شوید پردازنده‌ای که انتخاب کرده‌اید واقعاً برای Workload شما مناسب است؟ آیا 256 گیگابایت RAM کافی است یا باید به 512GB و بیشتر فکر کنید؟ برای دیتابیس پرتراکنش، SSD Enterprise جواب می‌دهد یا NVMe ارزش هزینه بیشتر را دارد؟ و مهم‌تر از همه، آیا DL360 برای پروژه شما کافی است یا باید سراغ DL380 و فضای توسعه بیشتر بروید؟
انتخاب سرور اچ پی مناسب SQL Server فقط به خرید قوی‌ترین CPU یا بیشترین مقدار RAM خلاصه نمی‌شود. در یک دیتابیس سازمانی، نوع Queryها، تعداد تراکنش‌های هم‌زمان، حجم Active Dataset، سرعت Storage، Latency، IOPS، RAID، معماری حافظه و حتی SQL Server Edition می‌توانند تعیین کنند سرور در ساعات Peak روان کار کند یا به نقطه Bottleneck برسد.
برای مثال، ممکن است یک سرور با دو پردازنده پرهسته و صدها گیگابایت RAM همچنان در اجرای Queryها کند باشد؛ چون Transaction Log یا TempDB روی Storage مناسبی قرار نگرفته است. از طرف دیگر، یک کانفیگ متعادل با CPU مناسب، RAM کافی و Enterprise SSD می‌تواند برای یک ERP یا سیستم مالی سازمانی نتیجه بسیار بهتری ایجاد کند.
پس قبل از اینکه بین G10، G11 یا G12، DL360 یا DL380 و SSD یا NVMe تصمیم بگیریم، باید یک سؤال مهم را پاسخ دهیم: SQL Server شما دقیقاً چه نوع Workloadی را قرار است پردازش کند؟
در این راهنما قدم‌به‌قدم بررسی می‌کنیم CPU مناسب SQL Server چگونه انتخاب می‌شود، چه مقدار RAM واقعاً نیاز دارید، چه Storage و RAIDی برای Data، Log و TempDB منطقی‌تر است و در نهایت چگونه براساس حجم دیتابیس، تعداد کاربران هم‌زمان و سطح پردازش، یک سرور HP مناسب SQL Server انتخاب و کانفیگ کنیم.
سرور مناسب SQL Server چه ویژگی‌هایی باید داشته باشد؟
در عمل سه محور بیشترین اثر را دارند: CPU متناسب با نوع Query، RAM کافی برای Buffer Pool و Storage با Latency و IOPS مناسب. در کنار آن، RAID Controller، شبکه، ECC و Redundancy باید متناسب با اهمیت سرویس انتخاب شوند. هدف، توازن منابع است؛ نه بیشینه‌کردن یک قطعه.
سرور مناسب SQL Server باید CPU مناسب، RAM کافی و Storage کمLatency داشته باشد. ECC، RAID مناسب و امکان ارتقا نیز مهم‌اند.
| مؤلفه | نقش در SQL Server | اولویت |
|---|---|---|
| CPU | اجرای Query، تراکنش و پردازش محاسباتی | بسیار زیاد |
| RAM | Buffer Pool و کاهش Disk I/O | بسیار زیاد |
| Storage | IOPS، Latency و Throughput | بسیار زیاد |
| RAID Controller | Cache، Redundancy و مدیریت دیسک | زیاد |
| Network | ارتباط Application، Cluster و Backup | متوسط تا زیاد |
| PSU | پایداری و Redundancy | زیاد |
قبل از انتخاب سرور SQL باید Workload دیتابیس را بشناسیم
برای Sizing، فقط عبارت دیتابیس سنگین یا تعداد کاربران کافی نیست. حجم Active Dataset، تعداد کاربران هم‌زمان، TPS، نسبت Read/Write، Queryهای سنگین و رشد داده مشخص می‌کنند فشار اصلی روی CPU، RAM یا Storage است.
دیتابیس سنگین برای Sizing کافی نیست؛ Query، TPS، Read/Write، Concurrent User و Active Dataset مشخص می‌کنند فشار اصلی روی کدام منبع است.
دیتابیس OLTP چیست؟
OLTP تراکنش‌های کوچک و پرتعداد مانند ERP، حسابداری و CRM را پردازش می‌کند؛ Latency پایین، IOPS بالا و Transaction Log سریع در آن مهم است.
دیتابیس OLAP و Data Warehouse چیست؟
OLAP و Data Warehouse Queryهای حجیم و تحلیلی دارند؛ RAM بالا، CPU مناسب Parallelism و Storage با Throughput مطلوب مهم‌تر می‌شوند.
Mixed Workload چیست؟
در Mixed Workload، ERP، گزارش‌گیری و Jobهای Batch هم‌زمان اجرا می‌شوند؛ بنابراین منابع باید متعادل و با حاشیه امن انتخاب شوند.
| Workload | CPU | RAM | Storage | فاکتور اصلی |
|---|---|---|---|---|
| OLTP | بالا | بالا | بسیار سریع | Latency |
| OLAP | بسیار بالا | بسیار بالا | سریع | CPU/RAM |
| Data Warehouse | بالا | بسیار بالا | ظرفیت + Throughput | RAM/Storage |
| ERP | متوسط تا بالا | بالا | سریع | تعادل منابع |
| Mixed | بسیار بالا | بسیار بالا | بسیار سریع | Balance |
- حجم فعلی Database و Active Dataset
- Concurrent User و Transactions Per Second
- Queryهای سنگین و نسبت Read/Write
- مصرف CPU و RAM در ساعات Peak
- Latency، IOPS و Throughput Storage
- رشد ماهانه/سالانه، TempDB، Log و Backup Window
CPU مناسب SQL Server چگونه انتخاب می‌شود؟
CPU مناسب باید براساس نوع Workload، فرکانس، IPC، تعداد Core، NUMA و قابلیت Parallelism انتخاب شود. OLTP معمولاً از عملکرد قوی هر Core سود می‌برد و Workloadهای تحلیلی می‌توانند از Core بیشتر استفاده کنند. تعداد Core بالا به‌تنهایی معیار برتری نیست.
CPU سرور باید با Workload، Edition و Licensing هماهنگ باشد. Core زیاد با فرکانس پایین همیشه انتخاب بهتری نیست.
تعداد Core مهم‌تر است یا فرکانس CPU؟
برای SQL Server ترکیب فرکانس، IPC و Core کافی مهم است. OLTP به قدرت هر Core و Workloadهای تحلیلی به Core بیشتر حساس‌ترند؛ داده Performance واقعی بهترین مبنای انتخاب است.
NUMA در SQL Server چیست و چرا اهمیت دارد؟
در سرور چندسوکتی، هر CPU به RAM محلی خود سریع‌تر دسترسی دارد. چیدمان نامتوازن DIMM یا vCPU می‌تواند Latency ایجاد کند؛ Memory Population باید مطابق راهنمای HPE باشد.
یک CPU یا دو CPU برای SQL Server؟
برای دیتابیس متوسط، یک CPU قوی می‌تواند اقتصادی‌تر باشد. Dual CPU زمانی ارزش دارد که Core، Memory Bandwidth یا RAM بیشتری واقعاً لازم باشد و Edition/Licensing آن را توجیه کند.
مشاهده کانفیگ های پیشنهادی
تأثیر SQL Server Edition بر انتخاب CPU
Edition می‌تواند استفاده از Core و Memory را محدود کند؛ بنابراین قبل از خرید CPU پرهسته، محدودیت نسخه فعلی SQL Server را از مستندات رسمی Microsoft بررسی کنید.
Licensing چه ارتباطی با تعداد Core دارد؟
در مدل‌های Core-based، افزایش هسته می‌تواند هزینه لایسنس را بالا ببرد. برای برخی Workloadها CPU با Core کمتر و Performance قوی‌تر در هر Core از نظر Cost/Performance منطقی‌تر است.
- انتخاب فقط براساس Core Count
- نادیده گرفتن Clock، IPC و NUMA
- نصب CPU دوم بدون نیاز واقعی
- بی‌توجهی به Edition و Licensing
- خرید CPU قوی در کنار Storage ضعیف
SQL Server به چه مقدار RAM نیاز دارد؟
SQL Server داده و Indexهای پرتکرار را در Buffer Pool نگه می‌دارد؛ بنابراین رم سرور کافی می‌تواند Physical I/O را کاهش دهد. با این حال مقدار RAM به Working Set، Query Pattern و هم‌زمانی کاربران وابسته است و حجم کل دیتابیس به‌تنهایی معیار مناسبی نیست.
RAM به Database Size، Working Set، Query Type و Concurrent User وابسته است. در پروژه‌های سازمانی 128، 256، 512GB یا 1TB و بیشتر قابل بررسی است، اما هیچ عدد ثابتی برای تعداد کاربر وجود ندارد.
چرا RAM برای SQL Server اهمیت زیادی دارد؟
Buffer Pool داده و Indexهای پرتکرار را Cache می‌کند و Physical I/O را کاهش می‌دهد. Queryها نیز برای Sort، Hash و Memory Grant به RAM نیاز دارند.
آیا RAM بیشتر همیشه باعث افزایش سرعت SQL Server می‌شود؟
خیر. اگر Working Set از قبل در حافظه باشد یا Bottleneck اصلی CPU/Storage باشد، افزایش RAM ممکن است اثر کمی داشته باشد. Memory Pressure و Physical Reads باید پیش از ارتقا بررسی شوند.
64، 128، 256، 512 گیگ یا 1 ترابایت RAM؟
| سطح استفاده | RAM پیشنهادی اولیه |
|---|---|
| SQL سبک / تست | 32–64GB |
| شرکت کوچک | 64–128GB |
| ERP و دیتابیس متوسط | 128–256GB |
| دیتابیس سازمانی | 256–512GB |
| دیتابیس سنگین | 512GB–1TB |
| Enterprise / BI سنگین | 1TB و بیشتر |
تنظیم Max Server Memory در SQL Server
تمام RAM فیزیکی نباید بدون محدودیت در اختیار Database Engine قرار گیرد. برای Windows Server، Backup Agent، Monitoring و سایر سرویس‌ها باید حافظه رزرو شود و max server memory براساس مصرف واقعی تنظیم شود.
Storage؛ مهم‌ترین بخش در سرورهای دیتابیس پرتراکنش
Storage باید علاوه بر ظرفیت، از نظر IOPS، Latency و Throughput سنجیده شود. Data File به IOPS و ظرفیت مناسب، Transaction Log به Write Latency پایین و TempDB در Workloadهای سنگین به Storage سریع نیاز دارد. جداسازی منطقی این بخش‌ها زمانی مهم است که روی یک Storage برای I/O رقابت ایجاد شود.
در SQL Server، Latency، IOPS و Throughput به اندازه ظرفیت اهمیت دارند و باید با الگوی I/O هماهنگ شوند.
IOPS، Latency و Throughput چه تفاوتی دارند؟
IOPS تعداد عملیات در ثانیه، Latency زمان پاسخ هر عملیات و Throughput حجم انتقال داده است. OLTP بیشتر به IOPS/Latency و Data Warehouse به Throughput حساس است.
HDD یا SSD برای SQL Server؟
برای Production و دیتابیس پرتراکنش، Enterprise SSD معمولاً انتخاب منطقی‌تری است. HDD را بیشتر برای Backup، Archive، Cold Data یا ظرفیت حجیم کم‌هزینه در نظر بگیرید.
SATA SSD یا SAS SSD؟
| ویژگی | SATA SSD | SAS SSD |
|---|---|---|
| Performance | خوب | بالاتر |
| Enterprise Workload | متوسط تا خوب | مناسب‌تر |
| Redundancy Path | محدودتر | بهتر |
| قیمت | پایین‌تر | بالاتر |
| SQL سنگین | قابل استفاده | مناسب‌تر |
NVMe برای SQL Server چه مزیتی دارد؟
NVMe Latency پایین و Parallelism بالایی دارد و برای OLTP بسیار سنگین، TempDB پرترافیک، BI و Data Warehouse ارزشمند است؛ اما تنها زمانی توجیه دارد که Storage واقعاً Bottleneck باشد.
Data File، Transaction Log و TempDB را روی چه Storage قرار دهیم؟
OS، Data، Log، TempDB و Backup الگوی I/O متفاوت دارند. در سیستم‌های سنگین بهتر است رقابت I/O میان آن‌ها با جداسازی منطقی یا فیزیکی و انتخاب RAID مناسب کنترل شود.
بهترین RAID برای SQL Server چیست؟
RAID 10 برای بسیاری از OLTPهای پرتراکنش انتخاب رایجی است. RAID 5/6 برای سناریوهای ظرفیت‌محور قابل بررسی‌اند، اما Write Penalty باید لحاظ شود.
RAID 1 برای SQL Server
RAID 1 ساده، قابل اتکا و دارای ظرفیت مفید حدود 50 درصد است و برای OS یا Volumeهای کوچک و در برخی طراحی‌ها Log مناسب است.
RAID 5 برای SQL Server
RAID 5 ظرفیت مفید بیشتری ارائه می‌دهد و خرابی یک Drive را تحمل می‌کند، اما Parity باعث Write Penalty می‌شود؛ بنابراین برای OLTP Write-intensive باید با احتیاط انتخاب شود.
RAID 6 برای SQL Server
RAID 6 دو Drive خرابی را تحمل می‌کند و برای ظرفیت و Redundancy بالا مناسب است، اما هزینه Write بیشتری نسبت به RAID 5 دارد.
RAID 10 برای SQL Server
RAID 10 با ترکیب Mirroring و Striping، Write Performance و Latency مناسبی فراهم می‌کند و برای OLTP و دیتابیس‌های Write-heavy گزینه متداولی است؛ هزینه آن مصرف تقریباً نیمی از ظرفیت خام است.
مقایسه RAID 1، RAID 5، RAID 6 و RAID 10
| RAID | Performance | تحمل خرابی | ظرفیت مفید | کاربرد |
|---|---|---|---|---|
| RAID 1 | خوب | خوب | حدود 50٪ | OS/Log |
| RAID 5 | متوسط | 1 Drive | بالا | Read-heavy |
| RAID 6 | متوسط | 2 Drive | بالا | Capacity |
| RAID 10 | بسیار خوب | بالا | حدود 50٪ | OLTP/DB |
RAID Controller در سرور SQL چه اهمیتی دارد؟
RAID Controller روی Cache، صف I/O و پردازش RAID اثر دارد. در سرورهای HPE، Smart Array با Cache محافظت‌شده مانند FBWC می‌تواند برای Workloadهای Write-intensive مفید باشد؛ اما انتخاب Controller باید همراه با نوع Drive و RAID Level انجام شود.
RAID Controller روی مدیریت Array، Cache، Queue و برخی عملیات RAID اثر دارد. در HPE، خانواده Smart Array برای کانفیگ‌های Enterprise رایج است و انتخاب مدل باید با نوع Drive و حجم I/O هماهنگ شود.
SQL Server چه مقدار Storage نیاز دارد؟
ظرفیت باید Database فعلی، رشد، Index، TempDB، Log، Maintenance و حاشیه اطمینان را پوشش دهد.
نرخ رشد دیتابیس را چگونه محاسبه کنیم؟
رشد ماهانه و سالانه Database، Retention، Index، Backup Policy و پروژه‌های آینده را ثبت کنید و برای سه تا پنج سال Capacity Planning داشته باشید.
انتخاب سرور HP مناسب SQL Server
HPE ProLiant DL با Xeon، ECC، Smart Array، Hot-Plug Drive، Redundant PSU و iLO برای دیتابیس سازمانی مناسب است؛ Performance نهایی به کانفیگ وابسته است.
HPE ProLiant DL360 برای SQL Server
DL360 با Form Factor یک یونیت برای Rack متراکم و SQL سبک تا سنگین با Storage داخلی محدود یا متوسط مناسب است. مزیت اصلی آن تراکم بالا و اشغال فضای کمتر است.
مشاهده کانفیگ‌های پیشنهادی
HPE ProLiant DL380 برای SQL Server
DL380 دو یونیت فضای بیشتری برای Drive، PCIe و Expansion دارد و برای دیتابیس Storage-intensive، Data Warehouse و رشد بلندمدت انعطاف بیشتری ارائه می‌دهد.
DL360 یا DL380؛ کدام برای SQL Server بهتر است؟
DL360 برای محدودیت Rack و نیاز Storage متوسط جذاب است؛ DL380 برای Drive و Expansion بیشتر. DL380 ذاتاً سریع‌تر نیست و CPU، RAM و Storage کانفیگ واقعی تعیین‌کننده‌اند.
| معیار | DL360 | DL380 |
|---|---|---|
| Form Factor | 1U | 2U |
| فضای Rack | کمتر | بیشتر |
| توسعه Storage | محدودتر | بیشتر |
| Expansion | خوب | بیشتر |
| SQL متوسط | بسیار مناسب | بسیار مناسب |
| SQL سنگین | مناسب با کانفیگ درست | بسیار مناسب |
| رشد آینده | متوسط تا خوب | بیشتر |
G10، G11 یا G12؛ کدام نسل برای SQL Server مناسب‌تر است؟
G10 برای بودجه و Cost/Performance، G11 برای پلتفرم جدیدتر و G12 برای زیرساخت تازه و چرخه عمر طولانی‌تر قابل بررسی‌اند. تصمیم باید بر مبنای کانفیگ و نیاز واقعی باشد.
سرور HP G10 برای SQL Server
G10 استوک می‌تواند با RAM و SSD بیشتر در بودجه مشابه، ارزش بالایی برای ERP و SQL سازمانی ایجاد کند. سلامت قطعات، Firmware و Driveها باید بررسی شود.
سرور HP G11 برای SQL Server
G11 برای زیرساخت جدید، Memory/I/O جدیدتر، NVMe و توسعه آینده مناسب است و در ERP سنگین، BI و Virtualization قابل بررسی است.
سرور HP G12 برای SQL Server
G12 برای پروژه‌های جدید با Lifecycle طولانی، CPU و I/O نسل جدید و برنامه توسعه بلندمدت مطرح است. مقایسه عددی باید براساس دیتاشیت و کانفیگ مدل واقعی انجام شود.
| نیاز | نسل قابل بررسی |
|---|---|
| بودجه محدود / Cost-Performance | G10 |
| سرور استوک Enterprise قوی | G10 |
| زیرساخت جدید و توسعه آینده | G11 |
| NVMe و I/O جدیدتر | G11 / G12 |
| پروژه بلندمدت | G11 / G12 |
| دیتاسنتر کاملاً جدید | G12 |
کانفیگ پیشنهادی سرور SQL Server براساس سطح Workload
کانفیگ‌های زیر فقط نقطه شروع‌اند و باید با Database Size، TPS، Query Pattern، Concurrent User و IOPS تطبیق داده شوند.
کانفیگ SQL Server برای شرکت کوچک
- 1× Xeon با فرکانس مناسب
- 64–128GB RAM
- Enterprise SSD
- RAID 10 یا متناسب با Workload
- 1/10GbE و Redundant PSU
کانفیگ SQL Server متوسط
- 1 یا 2 CPU
- 128–256GB RAM
- چند Enterprise SSD
- RAID 10 و Controller دارای Cache
- 10GbE و Dual PSU
کانفیگ SQL Server سازمانی سنگین
- Dual Xeon
- 256–512GB RAM
- Enterprise SSD یا NVMe
- تفکیک Data/Log/TempDB در صورت نیاز
- 10/25GbE و Dual PSU
کانفیگ SQL Server بسیار سنگین، BI و Data Warehouse
- Dual CPU High-end
- 512GB–1TB+ RAM
- NVMe / Enterprise SSD
- Storage با Throughput بالا
- 25GbE در صورت نیاز و HA/Cluster
مشاهده کانفیگ‌های پیشنهادی
جدول انتخاب سریع سرور SQL Server
این جدول فقط نقطه شروع است. تعداد کاربر به‌تنهایی معیار Sizing نیست؛ Concurrent User، TPS، Query Complexity، رشد داده و فضای ارتقای RAM/Storage باید در تصمیم نهایی لحاظ شوند.
| سناریو | CPU | RAM | Storage | مدل |
|---|---|---|---|---|
| حسابداری کوچک | 1 CPU | 64–128GB | SSD | DL360 |
| ERP متوسط | 1–2 CPU | 128–256GB | SSD RAID10 | DL360/DL380 |
| SQL سازمانی | 2 CPU | 256–512GB | SAS SSD/NVMe | DL380 |
| دیتابیس سنگین | 2 CPU | 512GB+ | NVMe/SSD RAID10 | DL380 |
| BI/Data Warehouse | 2 CPU قدرتمند | 512GB–1TB+ | NVMe | DL380 |
این مقادیر فقط نقطه شروع‌اند و انتخاب نهایی باید براساس حجم Database، Query Pattern، Concurrent User، TPS، نرخ رشد، Latency و IOPS انجام شود.
Bottleneck سرور SQL را چگونه تشخیص دهیم؟
قبل از ارتقا مشخص کنید SQL Server کجا زمان از دست می‌دهد؛ خرید CPU یا NVMe بدون تشخیص Bottleneck ممکن است بی‌اثر باشد.
CPU Bottleneck در SQL Server
CPU Usage مداوم بالا، Queryهای CPU-intensive و Parallelism می‌توانند نشانه باشند؛ اما Query Plan و Index نامناسب نیز CPU را بالا می‌برند، پس ابتدا Query Tuning را بررسی کنید.
Memory Bottleneck در SQL Server
Memory Pressure، Physical Reads و Memory Grant مشکل‌دار را بررسی کنید. اگر Bottleneck واقعی RAM باشد، افزایش حافظه می‌تواند Disk I/O را کاهش دهد.
Storage Bottleneck در SQL Server
Disk Latency، IOPS، Throughput و Queue را بسنجید. راه‌حل می‌تواند SSD/NVMe، RAID بهتر، Controller قوی‌تر، RAM بیشتر یا تفکیک I/O باشد.
Network Bottleneck در SQL Server
در معماری Application/Database جدا، Cluster، Backup و Storage Network باید پهنای باند و Latency شبکه نیز بررسی شود.
آیا برای SQL Server حتماً SSD لازم است؟
برای Production و OLTP، Enterprise SSD معمولاً انتخاب منطقی‌تری از HDD است. SATA SSD برای بسیاری از Workloadهای متوسط کافی است و SAS SSD در محیط‌های Enterprise از نظر Endurance و مسیرهای ارتباطی مزیت دارد. HDD بیشتر برای Backup، Archive و Cold Data مناسب است.
SSD الزام فنی نیست، اما برای Production و OLTP معمولاً Latency را کاهش می‌دهد؛ HDD بیشتر برای Backup، Archive و Cold Data مناسب است.
آیا NVMe برای SQL Server ارزش دارد؟
NVMe زمانی ارزش واقعی ایجاد می‌کند که Storage Bottleneck باشد؛ مانند OLTP بسیار سنگین، TempDB پرترافیک یا Data Warehouse با نیاز Throughput بالا. اگر محدودیت اصلی CPU یا RAM باشد، مهاجرت از Enterprise SSD به NVMe لزوماً بهبود محسوسی ایجاد نمی‌کند.
NVMe زمانی ارزش دارد که Storage Bottleneck باشد یا IOPS و Latency بسیار پایین لازم باشد؛ در SQL متوسط ممکن است بازده اقتصادی کمی داشته باشد.
شبکه مناسب سرور دیتابیس
1GbE برای محیط‌های سبک قابل استفاده است، اما 10GbE برای بسیاری از دیتابیس‌های سازمانی نقطه شروع مناسب‌تری است. 25GbE بیشتر در Cluster، Virtualization سنگین، Storage Network و Backup حجیم ارزش دارد.
شبکه در معماری‌های چندسروری اهمیت بیشتری پیدا می‌کند. سرعت مناسب باید با ترافیک Application، Backup، Cluster و Storage هماهنگ شود.
SQL Server را روی سرور فیزیکی نصب کنیم یا ماشین مجازی؟
Bare Metal دسترسی مستقیم و Performance قابل پیش‌بینی‌تری می‌دهد؛ Virtualization انعطاف، HA و مدیریت منابع را ساده‌تر می‌کند. انتخاب به Workload و معماری دیتاسنتر وابسته است.
SQL Server روی Bare Metal
برای Workload بسیار سنگین و حساس به Latency مناسب است؛ کنترل NUMA و Storage نیز ساده‌تر است.
SQL Server روی VMware یا Hyper-V
برای مدیریت، Resource Allocation و HA مناسب است، اما Overcommit، vNUMA، vCPU و Storage Layout باید اصولی طراحی شوند.
SQL Server روی Proxmox
قابل اجراست؛ vCPU، RAM، Storage Latency، Backup و HA باید مانند هر Hypervisor دیگری براساس Workload تنظیم شوند و از Overcommit سنگین پرهیز شود.
High Availability در SQL Server
در دیتابیس حیاتی، Performance بدون Availability کافی نیست. معماری HA باید براساس RPO/RTO، بودجه و زیرساخت طراحی شود.
Always On Availability Groups
برای ایجاد Replica و کاهش Downtime در سناریوهای مناسب استفاده می‌شود و نیازمند طراحی صحیح Network، Storage و Licensing است.
Failover Cluster
چند Node برای Failover سرویس استفاده می‌شوند. Storage، Network و Quorum باید به‌صورت تخصصی طراحی شوند.
Backup Strategy
Full، Differential و Transaction Log Backup، Retention، نسخه Offsite و Restore Test باید تعریف شوند. RAID و HA جایگزین Backup نیستند.
اشتباهات رایج هنگام خرید سرور برای SQL Server
- انتخاب CPU فقط براساس تعداد Core
- خرید RAM کم یا چیدمان نامتوازن
- استفاده از HDD برای دیتابیس پرتراکنش
- انتخاب RAID بدون توجه به Write Penalty و Controller
- قرار دادن OS، Data، Log و TempDB روی Storage ضعیف
- نادیده گرفتن رشد Database و IOPS
- بی‌توجهی به SQL Server Edition و Licensing
- Single PSU در سیستم Mission Critical
- نداشتن Backup و فضای ارتقا
- انتخاب سرور فقط براساس تعداد کاربران
چک‌لیست خرید سرور مناسب SQL Server
- حجم فعلی Database را مشخص کنید.
- نرخ رشد را برای سه تا پنج سال محاسبه کنید.
- Concurrent User و TPS را بررسی کنید.
- نوع Workload را مشخص کنید.
- مصرف CPU و RAM در Peak را اندازه‌گیری کنید.
- IOPS و Latency Storage را بررسی کنید.
- Data، Log و TempDB را جداگانه ارزیابی کنید.
- RAID و RAID Controller مناسب انتخاب کنید.
- نیاز به HA و Backup را تعیین کنید.
- Edition و Licensing را بررسی کنید.
- فضای ارتقای RAM، Drive و Network را نگه دارید.
- سپس مدل و نسل سرور را انتخاب کنید.
سرور نو یا سرور استوک برای SQL Server؟
انتخاب نو یا استوک به بودجه، عمر پروژه و نیاز فناوری جدید بستگی دارد. G10 استوک با RAM/SSD بیشتر می‌تواند از نسل جدید با کانفیگ محدود ارزش بالاتری ایجاد کند.
چه زمانی سرور استوک منطقی است؟
وقتی بودجه محدود، Cost/Performance مهم و Workload با G10 قابل پاسخ است. سلامت Drive، Controller، PSU و Firmware باید بررسی شوند.
چه زمانی نسل جدید مناسب‌تر است؟
برای دیتاسنتر جدید، Lifecycle طولانی، NVMe/I/O جدیدتر، CPUهای تازه و پروژه‌های بلندمدت G11 یا G12 منطقی‌تر است.
هزینه سرور SQL Server به چه عواملی بستگی دارد؟
هزینه نهایی فقط قیمت شاسی نیست؛ CPU و تعداد Core، RAM، نوع و تعداد SSD/NVMe، RAID Controller، NIC، Redundancy، نسل سرور و SQL Server Licensing همگی مؤثرند. در مدل‌های Core-based، افزایش Core می‌تواند هزینه نرم‌افزار را نیز بالا ببرد.
قیمت نهایی از CPU و تعداد Core، RAM، نوع و تعداد SSD/NVMe، RAID Controller، NIC، PSU، نسل، نو/استوک بودن، HA و SQL Server Licensing تشکیل می‌شود. هزینه کل راهکار را ببینید، نه فقط قیمت شاسی.
چگونه بهترین کانفیگ SQL Server را انتخاب کنیم؟
مسیر تصمیم‌گیری بهتر این است: Workload ← CPU ← RAM ← Storage ← RAID ← Network ← مدل و نسل سرور. دو سازمان با تعداد کاربر یکسان ممکن است کانفیگ کاملاً متفاوتی بخواهند.
اگر قصد خرید سرور HP برای SQL Server دارید، ابتدا حجم دیتابیس، TPS، Query Pattern، Memory Usage و Storage Performance را مشخص کنید و سپس کانفیگ را براساس بودجه و رشد آینده ببندید.
جمع‌بندی؛ برای SQL Server چه سروری بخریم؟
برای OLTP، CPU پاسخ‌گو و Storage کمLatency مهم‌اند؛ برای BI/Data Warehouse، RAM، Core و Throughput پررنگ‌تر می‌شوند. DL360 برای تراکم و DL380 برای Expansion مزیت دارد.
SQL سبک: DL360 + RAM متوسط + Enterprise SSD. SQL سازمانی: DL360/DL380 + RAM بالا + SSD RAID 10. SQL بسیار سنگین: DL380 + Dual CPU + RAM بالا + NVMe/Enterprise SSD. این‌ها نقطه شروع‌اند، نه Sizing قطعی.
سوالات متداول
برای SQL Server چه سروری مناسب است؟
سروری با CPU متناسب با Workload، RAM کافی، Storage کمLatency و RAID مناسب. حجم دیتابیس، TPS و Query Pattern کانفیگ دقیق را تعیین می‌کنند.
SQL Server به چه مقدار RAM نیاز دارد؟
SQL Server داده و Indexهای پرتکرار را در Buffer Pool نگه می‌دارد؛ بنابراین RAM کافی می‌تواند Physical I/O را کاهش دهد. با این حال مقدار RAM به Working Set، Query Pattern و هم‌زمانی کاربران وابسته است و حجم کل دیتابیس به‌تنهایی معیار مناسبی نیست.
به Working Set، حجم داده فعال و Queryها بستگی دارد. در سازمان‌ها از 128 و 256GB تا 512GB، 1TB و بیشتر قابل بررسی است.
بهترین RAID برای SQL Server چیست؟
RAID 10 برای بسیاری از OLTPهای پرتراکنش رایج است، اما RAID نهایی باید براساس Read/Write، Drive و Controller انتخاب شود.
SSD یا HDD برای SQL Server بهتر است؟
برای Production، Enterprise SSD معمولاً مناسب‌تر است؛ HDD بیشتر برای Backup، Archive و Cold Data کاربرد دارد.
آیا NVMe برای SQL Server ضروری است؟
خیر. زمانی ارزش بیشتری دارد که Storage Bottleneck باشد یا IOPS و Latency بسیار پایین نیاز باشد.
DL360 یا DL380 برای SQL Server بهتر است؟
DL360 فضای Rack کمتری می‌گیرد؛ DL380 فضای Storage و Expansion بیشتری دارد. Performance به کانفیگ بستگی دارد.
آیا سرور HP G10 برای SQL Server مناسب است؟
بله، اگر کانفیگ متناسب باشد؛ مخصوصاً وقتی Cost/Performance و سرور استوک Enterprise مهم است.
برای دیتابیس سنگین چه مقدار RAM مناسب است؟
256GB، 512GB و بالاتر قابل بررسی است، اما Working Set و Memory Pressure باید مبنا باشند.
آیا تعداد کاربران برای انتخاب سرور SQL کافی است؟
خیر. Concurrent User، TPS، Query Complexity و Active Dataset معیارهای دقیق‌تری هستند.
برای SQL Server یک CPU بهتر است یا دو CPU؟
به Workload، Edition و Licensing بستگی دارد. SQL متوسط ممکن است با یک CPU قوی کافی باشد و Enterprise به Dual CPU نیاز پیدا کند.
SQL Server روی سرور فیزیکی بهتر است یا مجازی؟
هر دو مناسب‌اند. Bare Metal قابل پیش‌بینی‌تر است؛ Virtualization انعطاف و HA بیشتری می‌دهد.
برای SQL Server چه سرعت شبکه‌ای مناسب است؟
10GbE برای بسیاری از سازمان‌ها نقطه شروع خوبی است؛ Cluster، Storage Network یا Backup سنگین ممکن است 25GbE بخواهد.
انتخاب تجهیزات مناسب، تنها به خرید یک مدل خاص محدود نمی‌شود؛ بلکه به انتخاب کانفیگی متناسب با نیاز واقعی سازمان بستگی دارد. در ماهان شبکه ایرانیان، کارشناسان فنی با بررسی تعداد کاربران، نوع نرم‌افزارهای سازمانی، نیازهای پردازشی و بودجه شما، مناسب‌ترین مدل و کانفیگ را پیشنهاد می‌دهند. اگر برای خرید سرور اچ پی یا سایر تجهیزات شبکه جهت ارتقاء زیرساخت خود به راهنمایی نیاز دارید، پیش از تصمیم‌گیری با کارشناسان ما مشورت کنید تا با اطمینان، راهکاری متناسب با نیاز امروز و توسعه آینده کسب‌وکار خود انتخاب کنید.
