انتخاب HPE ProLiant ML30 فقط به کوچک یا متوسط بودن کسب‌ و کار بستگی ندارد؛ معیار اصلی این است که Workload مورد نظر تا چه اندازه با ظرفیت یک سرور Tower تک‌ سوکت هماهنگ است. تعداد کاربران هم‌ زمان، تعداد Core مورد نیاز، حجم Working Set در RAM، میزان IOPS و Latency مورد نیاز Storage، تعداد Driveها، پهنای باند شبکه و برنامه توسعه زیرساخت، همگی تعیین می‌کنند که ML30 انتخاب مناسبی باشد یا خیلی زود به محدودیت سخت‌ افزاری برسد. برای مثال، یک File Server با 30 کاربر، یک SQL Server با 30 کاربر و یک Host مجازی‌ سازی با چند VM، اگر چه تعداد کاربران مشابهی دارند، فشار کاملاً متفاوتی روی CPU، Memory و Storage ایجاد می‌کنند.

به همین دلیل، در ارزیابی ML30 نباید فقط به مشخصاتی مثل ظرفیت RAM یا مدل پردازنده نگاه کرد. باید مشخص شود CPU و Memory برای بار پردازشی کافی هستند یا نه، Storage Configuration چه IOPS و سطح Redundancy فراهم می‌کند، RAID Controller با نوع Workload سازگار است یا نه و پلتفرم چه فضایی برای ارتقای آینده دارد. در ادامه، کاربرد ML30 را برای سناریوهایی مانند حسابداری و ERP، File Server، Database، Backup و مجازی‌ سازی بررسی می‌کنیم و مشخص می‌کنیم برای هر کدام چه Configurationی منطقی است و در چه شرایطی بهتر است به‌ جای ML30 سراغ پلتفرم قدرتمندتری بروید.

سرور ML30 برای چه Workload و چه مقیاس کسب‌ و کاری مناسب است؟

سرور HPE ProLiant ML30 بیشتر برای محیط‌هایی مناسب است که به یک سرور مستقل برای اجرای سرویس‌های سازمانی نیاز دارند، اما حجم پردازش آنها به سطح سرورهای دو پردازنده‌ای و زیرساخت‌های Enterprise نرسیده است. بنابراین صرفاً «کوچک یا متوسط بودن شرکت» معیار مناسبی برای انتخاب سرور HP ML نیست؛ ممکن است یک شرکت 20 نفره Database سنگینی داشته باشد که ML30 برای آن محدود شود، در حالی ‌که مجموعه‌ای با کاربران بیشتر فقط از File Sharing و چند سرویس سبک استفاده کند و همین پلتفرم پاسخ‌ گوی نیاز آن باشد.

برای مشخص‌ کردن محدوده کاری ML30، ابتدا باید بار هم‌ زمان (Concurrent Load) بررسی شود. تعداد کل کاربران اطلاعات کافی نمی‌دهد؛ مهم این است که در ساعات شلوغ چند کاربر هم‌ زمان به Application، Database یا فایل‌های شبکه دسترسی دارند و این درخواست‌ها چه میزان CPU، RAM و Storage I/O مصرف می‌کنند. اگر در Peak Load پردازنده دائماً نزدیک اشباع باشد، Working Set نرم‌ افزار یا Database در RAM جا نشود یا Storage نتواند IOPS مورد نیاز را با Latency مناسب تأمین کند، افزایش تعداد کاربران می‌تواند مستقیماً باعث افت Performance شود.

از نظر نوع Workload، ML30 را می‌توان برای این سناریوها بررسی کرد:

  • File Server: برای اشتراک فایل در شبکه داخلی؛ به شرط انتخاب ظرفیت Drive، RAID و پهنای باند شبکه متناسب با تعداد کاربران و حجم انتقال اطلاعات.
  • Accounting و ERP: برای نرم‌ افزارهای مالی و سازمانی سبک تا متوسط، مشروط به اینکه CPU، RAM و مخصوصاً Storage براساس Database و تعداد کاربران هم‌ زمان انتخاب شوند.
  • Domain Services: اجرای سرویس‌هایی مانند Active Directory، DNS و DHCP که معمولاً نسبت به Databaseهای سنگین منابع کمتری مصرف می‌کنند.
  • Application Server: میزبانی نرم‌ افزارهای داخلی شرکت، به شرط مشخص‌ بودن میزان پردازش و Memory مصرفی Application.
  • Backup Server: برای نگهداری Backup، در صورتی ‌که ظرفیت قابل‌ استفاده پس از RAID، نرخ رشد Data و سرعت Backup/Restore از ابتدا محاسبه شوند.
  • Database سبک تا متوسط: در این سناریو علاوه بر CPU و RAM، Random I/O و Latency Storage اهمیت زیادی دارد؛ بنابراین انتخاب SSD و RAID مناسب می‌تواند تعیین ‌کننده باشد.
  • سرویس شعب: برای شعب یک سازمان که به File، Application، Authentication یا سرویس‌های محلی نیاز دارند، بدون اینکه در هر شعبه زیرساخت Rack گسترده‌ای ایجاد شود.
  • Virtualization محدود: برای اجرای چند VM با مصرف کنترل‌ شده قابل بررسی است؛ اما تعداد VM معیار کافی نیست و مجموع vCPU، RAM، Storage IOPS و Network Load ماشین‌ها باید محاسبه شود.

دو معیار دیگر نیز نباید نادیده گرفته شوند: رشد Data و Availability. اگر حجم اطلاعات سالانه به‌ سرعت افزایش پیدا می‌کند، باید از ابتدا ظرفیت Drive Bay، Storage و امکان ارتقای سرور بررسی شود. از طرف دیگر، اگر سرویس به‌ قدری حیاتی است که حتی چند دقیقه Downtime قابل ‌قبول نیست، مسئله فقط قدرت ML30 نیست؛ ممکن است معماری تک‌ سرور اساساً پاسخ‌ گوی سطح Availability مورد نیاز نباشد و به Redundancy، چند Host یا Cluster نیاز باشد.

در نتیجه، ML30 زمانی انتخاب منطقی‌تری است که CPU Load، Memory Requirement، Storage IOPS، ظرفیت Data و تعداد سرویس‌های هم‌ زمان در محدوده منابع قابل ارائه و قابل ارتقای این پلتفرم باقی بمانند. به همین دلیل بهتر است قبل از انتخاب Configuration، Workload واقعی اندازه ‌گیری یا حداقل تخمین زده شود؛ نه اینکه سرور صرفاً براساس تعداد کارمندان شرکت انتخاب شود.

ML30 برای حسابداری، ERP و Database تا چه سطحی پاسخ‌گو است؟

سرور ML30 برای اجرای نرم‌ افزارهای حسابداری، ERP و Database در مقیاس سبک تا متوسط قابل استفاده است، اما ظرفیت واقعی آن را باید براساس تعداد کاربران هم‌ زمان و حجم Transaction تعیین کرد، نه صرفاً نام نرم‌ افزار. در انتخاب سرور hp برای حسابداری چهار بخش بیشترین تأثیر را روی Performance دارند:

  • CPU: هر چه تعداد Transactionها، Queryهای هم‌ زمان و پردازش‌های گزارش ‌گیری بیشتر باشد، بار پردازنده افزایش پیدا می‌کند. بنابراین تعداد Core به‌ تنهایی معیار کافی نیست و فرکانس CPU و نوع پردازش Database نیز اهمیت دارند.
  • RAM: بخشی از داده‌های پرتکرار Database در Memory Cache نگهداری می‌شوند. اگر Working Set در RAM جا نشود، سیستم بیشتر به Storage مراجعه می‌کند و Response Time افزایش پیدا می‌کند؛ بنابراین در SQL/ERP کمبود RAM می‌تواند مستقیماً Performance را محدود کند.
  • Storage: Database فعال معمولاً با Random Read/Write سر و کار دارد؛ در نتیجه IOPS و Latency مهم‌تر از ظرفیت اسمی Drive هستند. استفاده از HDD پر ظرفیت ممکن است فضای کافی ایجاد کند، اما الزاماً پاسخ‌ گویی سریع Database را تضمین نمی‌کند. SSD به همراه RAID و Controller مناسب برای Workloadهای تراکنشی انتخاب منطقی‌تری است.
  • Network: اگر کاربران از طریق شبکه به Application یا Database متصل می‌شوند، پهنای باند و Latency شبکه نیز باید متناسب با تعداد Clientهای هم‌ زمان و حجم تبادل اطلاعات باشد.

در مجموعه‌های کوچک می‌توان Application و Database را روی یک ML30 اجرا کرد، به شرطی که مجموع مصرف CPU، RAM و Storage I/O هر دو سرویس ظرفیت کافی داشته باشد. اما با افزایش کاربران یا سنگین‌ شدن Database، تفکیک Application و Database روی VMهای مجزا یا Serverهای جدا امکان تخصیص مستقل منابع، کنترل بهتر Performance و توسعه ساده‌تر زیر ساخت را فراهم می‌کند.

بنابراین ML30 برای نرم‌ افزار مالی یا ERP زمانی مناسب است که Peak Load، حجم Database و نرخ رشد آن در محدوده منابع سرور باقی بماند؛ برای Databaseهای پرتراکنش، Queryهای سنگین یا تعداد زیاد کاربران هم‌ زمان، باید Sizing دقیق انجام شود و صرفاً به عنوان «سرور حسابداری» بودن ML30 اکتفا نشود.

‏ML30 برای File Server، Storage و Backup چه Configuration نیاز دارد؟

ML30 برای File Server، Storage و Backup چه Configuration نیاز دارد؟

اگر ML30 قرار است به‌ عنوان File Server یا Backup Server استفاده شود، Configuration بخش Storage باید براساس نوع دسترسی به داده، ظرفیت قابل‌ استفاده و سطح تحمل خرابی طراحی شود. برای آرشیو و Backup که بیشتر با انتقال Sequential فایل‌های حجیم سر و کار دارند، HDDهای LFF با ظرفیت بالا می‌توانند اقتصادی‌تر باشند؛ اما برای Shared Folderهایی با تعداد زیاد فایل کوچک و در خواست‌های هم‌ زمان، تعداد IOPS و Latency اهمیت بیشتری پیدا می‌کند و استفاده از SSD یا ترکیب مناسب‌تری از Driveها قابل بررسی است. در زمان خرید هارد سرور HP نیز باید فرم‌ فاکتور SFF/LFF، Backplane و Controller نصب‌ شده روی همان Configuration بررسی شوند.

ظرفیت مورد نیاز را هم نباید با مجموع ظرفیت اسمی Driveها یا Raw Capacity اشتباه گرفت. ظرفیت واقعی یا Usable Capacity بعد از اعمال RAID کمتر می‌شود و مقدار آن به تعداد و ظرفیت Driveها و RAID Level بستگی دارد. انتخاب RAID نیز باید براساس هدف Storage انجام شود:

  • RAID 1: مناسب زمانی که دو Drive داریم و Redundancy ساده با Mirror شدن اطلاعات نیاز است.
  • RAID 5: ظرفیت قابل‌ استفاده بیشتری ارائه می‌دهد، اما Write Penalty و مدت Rebuild به‌خصوص با Driveهای حجیم باید در نظر گرفته شود.
  • RAID 6: تحمل خرابی هم‌ زمان دو Drive را فراهم می‌کند، ولی Parity بیشتر هزینه نوشتن و ظرفیت بیشتری دارد.
  • RAID 10: برای Workloadهایی که Performance نوشتن و Rebuild سریع‌تر اهمیت دارد مناسب‌تر است، اما تقریباً نیمی از ظرفیت Raw صرف Mirroring می‌شود.

خود Storage Controller نیز باید توانایی پشتیبانی از RAID Level، تعداد و نوع Driveهای مورد نظر را داشته باشد. هنگام خرابی یک Drive، فقط قابلیت تعویض آن مهم نیست؛ Array تا پایان Rebuild در وضعیت آسیب‌ پذیر یا Degraded قرار می‌گیرد و ظرفیت Drive، سرعت دیسک و حجم فعالیت Storage می‌توانند روی مدت Rebuild اثر بگذارند.

در نهایت Performance فقط به Drive وابسته نیست. اگر Storage بتواند Throughput بالایی ایجاد کند ولی ارتباط شبکه محدود باشد، کاربران File Server از تمام توان Storage استفاده نمی‌کنند. به همین دلیل Storage Controller و Network Throughput باید متناسب با عملکرد مجموعه Driveها انتخاب شوند. همچنین RAID را نباید Backup محسوب کرد؛ RAID دسترس‌ پذیری سرویس را هنگام خرابی Drive افزایش می‌دهد، اما در برابر حذف اشتباه فایل، خرابی منطقی داده، بد افزار یا ازبین‌ رفتن کل سرور نسخه بازیابی مستقلی ایجاد نمی‌کند.

ML30 برای مجازی‌ سازی چند VM مناسب است و محدودیت اصلی آن چیست؟

برای ML30 نمی‌توان عدد ثابتی مانند «5 یا 10 ماشین مجازی» تعیین کرد، زیرا تعداد VM به‌ تنهایی نشان‌ دهنده بار واقعی Host نیست. دو VM شامل SQL Server و Application سنگین ممکن است منابع بیشتری از چندین VM سبک مصرف کنند. بنابراین ظرفیت Virtualization باید از روی مجموع Resource Requirement ماشین‌های مجازی محاسبه شود.

در طراحی سرور hp برای مجازی سازی روی ML30، این موارد تعیین‌ کننده‌اند:

  • vCPU Allocation: مجموع vCPUهای تخصیص‌ یافته باید با توان پردازشی Host و میزان استفاده هم‌ زمان VMها سنجیده شود. تخصیص vCPU بیشتر الزاماً VM را سریع‌تر نمی‌کند.
  • CPU Overcommit: Hypervisor می‌تواند vCPU بیشتری نسبت به Coreهای فیزیکی تخصیص دهد، اما نسبت قابل‌قبول Overcommit ثابت نیست. در VMهای CPU-intensive، Overcommit زیاد می‌تواند CPU Contention و افزایش CPU Ready/Wait ایجاد کند.
  • RAM Allocation: مجموع Memory ماشین‌ها، مصرف Hypervisor و سایر Overheadها باید در ظرفیت فیزیکی RAM جا بگیرد. وابستگی دائمی به Memory Ballooning یا Swapping نشانه کمبود منابع Host است.
  • Memory Headroom: تمام RAM نباید از ابتدا بین VMها توزیع شود؛ بخشی از ظرفیت باید برای Peak Load و توسعه ماشین‌های فعلی یا ایجاد VMهای جدید باقی بماند.
  • Datastore Performance: چند VM روی یک Datastore می‌توانند هم‌ زمان I/O ایجاد کنند؛ بنابراین Average IOPS یک VM کافی نیست و باید Aggregate IOPS و Peak Latency کل VMها بررسی شود.
  • Network: ترافیک VMها، Management، Backup و در صورت استفاده Storage Traffic ممکن است از یک مسیر مشترک عبور کنند؛ بنابراین NIC و تفکیک منطقی ترافیک باید متناسب با طراحی زیرساخت باشند.

محدودیت مهم‌تر ML30 در پروژه‌های رو ‌به‌ رشد، ماهیت Single-Socket این پلتفرم است. وقتی نیاز پردازشی VMها از ظرفیت CPU نصب‌ شده عبور کند، امکان اضافه‌ کردن CPU دوم وجود ندارد و توسعه باید در محدوده همان Platform انجام شود.

همچنین یک ML30 مستقل، صرفاً با نصب VMware، Hyper-V یا Proxmox به زیر ساخت High Availability تبدیل نمی‌شود. اگر تمام VMهای حیاتی روی یک Host قرار داشته باشند، خرابی خود Host می‌تواند همه آنها را هم‌ زمان از دسترس خارج کند؛ برای HA واقعی معمولاً به چند Host و طراحی مناسب Shared/Distributed Storage و Cluster نیاز است.

بنابراین ML30 می‌تواند برای Consolidation چند سرویس سبک و Virtualization کنترل‌ شده مناسب باشد، اما ظرفیت آن باید از مسیر CPU Demand → Memory Demand → Datastore Load → Network → Growth Headroom محاسبه شود، نه براساس تعداد اسمی VMها.

CPU، RAM و Storage سرور ML30 را بر اساس Workload چگونه انتخاب کنیم؟

برای کانفیگ ML30 نباید CPU، RAM و Storage را مستقل از یکدیگر انتخاب کرد. ابتدا باید منبع غالب در Workload مشخص شود و سپس سایر قطعات متناسب با آن تنظیم شوند؛ هدف این است که هیچ بخش سخت ‌افزاری زودتر از بقیه به Bottleneck تبدیل نشود.

  • CPU را براساس نوع پردازش انتخاب کنید: تعداد Core بیشتر برای پردازش‌های موازی مفید است، در حالی ‌که برخی Applicationها بیشتر به Performance هر Core وابسته‌اند. بنابراین مدل پردازنده باید براساس Threading نرم‌ افزار و بار پردازشی مورد انتظار انتخاب شود، نه صرفاً بالاترین تعداد Core.
  • ظرفیت RAM را همراه با مسیر ارتقا ببینید: مقدار حافظه فقط باید نیاز فعلی را پوشش ندهد؛ نحوه استفاده از DIMM Slotها نیز مهم است. هنگام خرید رم سرور HP، انتخاب DIMMهای بسیار کم‌ ظرفیت که تمام Slotها را پر کنند می‌تواند ارتقای آینده را پر هزینه کند، زیرا برای افزایش ظرفیت مجبور به تعویض ماژول‌های موجود خواهید شد.
  • Storage را با معیار Capacity یا Performance تفکیک کنید: اگر اولویت نگهداری حجم زیادی از اطلاعات است، ظرفیت Drive اهمیت بیشتری دارد؛ اما در Workloadهای حساس به زمان پاسخ، Latency و توان I/O مهم‌تر می‌شوند. بنابراین دو ML30 با ظرفیت Storage یکسان می‌توانند Performance کاملاً متفاوتی داشته باشند.
  • فضای رشد را از ابتدا رزرو کنید: کانفیگی که در زمان خرید تقریباً تمام ظرفیت CPU، DIMM Slotها یا فضای توسعه Storage را مصرف کرده باشد، حاشیه کمی برای افزایش Workload خواهد داشت. بهتر است Configuration اولیه بخشی از ظرفیت توسعه پلتفرم را برای نیازهای آینده آزاد نگه دارد.

در نهایت Balance مهم‌تر از حداکثرکردن مشخصات یک قطعه است. CPU قدرتمند نمی‌تواند کمبود Performance در مسیر Storage را جبران کند و افزایش RAM نیز زمانی که محدودیت اصلی در بخش دیگری از سیستم قرار دارد، الزاماً باعث افزایش سرعت نمی‌شود. کانفیگ مناسب ML30 ترکیبی است که منابع آن متناسب با رفتار Workload انتخاب شده باشند و مسیر ارتقای منطقی نیز باقی بماند.

چه زمانی ML30 کافی نیست و باید سراغ سرور رده بالاتر برویم؟

ML30 زمانی انتخاب مناسبی است که نیازهای کسب‌ و کار داخل محدوده یک پلتفرم Tower تک‌ سوکت باقی بماند. بنابراین مرز عبور از ML30 را نباید صرفاً با تعداد کاربر یا بزرگ ‌شدن شرکت تعیین کرد؛ زمانی باید پلتفرم بالاتر بررسی شود که Resource Requirement فعلی یا رشد پیش ‌بینی‌ شده به محدودیت‌های معماری ML30 نزدیک شود.

نشانه‌های مهم برای عبور از ML30 عبارت‌اند از:

  • نیاز پردازشی از ظرفیت Single-Socket فراتر می‌رود: اگر Workload به تعداد Core یا توان پردازشی بیشتری نسبت به پردازنده‌های قابل پشتیبانی ML30 نیاز داشته باشد، ارتقای CPU دیگر مسیر توسعه کافی نیست و پلتفرم دارای ظرفیت پردازشی بالاتر منطقی‌تر می‌شود.
  • نیاز Memory به سقف پلتفرم نزدیک است: اگر ظرفیت موردنیاز RAM بخش زیادی از حداکثر قابل پشتیبانی را مصرف کند، فضای کمی برای توسعه بعدی باقی می‌ماند. این موضوع مخصوصاً برای زیرساخت‌هایی که مصرف Memory آنها به‌ مرور افزایش پیدا می‌کند مهم است.
  • محیط Virtualization دائماً در حال گسترش است: اضافه‌شدن مستمر VMها فقط ظرفیت فعلی را مصرف نمی‌کند، بلکه Headroom لازم برای Peak Load و VMهای آینده را نیز کاهش می‌دهد. در چنین پروژه‌ای باید از ابتدا ظرفیت Hostهای قوی‌تر یا معماری چند Host بررسی شود.
  • Storage به توسعه گسترده نیاز دارد: تعداد زیاد Drive، حجم بالای عملیات Storage یا نیاز به Controller و تجهیزات ذخیره‌ سازی بیشتر می‌تواند ML30 را از نظر Bay و Expansion محدود کند.
  • چند کارت توسعه نیاز دارید: اگر قرار است NICهای پرسرعت، HBA، RAID Controller یا سایر PCIe Adapterها هم‌ زمان نصب شوند، تعداد Slot و Laneهای در دسترس به یک معیار تعیین‌ کننده تبدیل می‌شود.
  • Downtime سرویس قابل‌ قبول نیست: برای سرویس‌های Critical که باید در برابر خرابی یک Host نیز در دسترس باقی بمانند، تکیه بر یک ML30 مستقل کافی نیست و باید Redundancy، چند Host، Cluster و معماری HA در سطح زیرساخت بررسی شود.
  • رشد Workload از قبل قابل پیش‌ بینی است: اگر برآورد ظرفیت نشان دهد ML30 در آینده نزدیک به سقف منابع می‌رسد، خرید آن فقط هزینه مهاجرت بعدی را جلو می‌اندازد.

در چنین شرایطی انتخاب مدل جایگزین نیز باید براساس همان محدودیت انجام شود. برای مثال، اگر همچنان فرم Tower مناسب است اما Expansion و ظرفیت بالاتری نیاز دارید، بررسی خانواده‌هایی مانند ML110 یا ML350 منطقی است. اگر Rack Density، توسعه دیتاسنتری یا زیرساخت گسترده‌تر مطرح باشد، مدل‌هایی مانند DL360 و DL380 می‌توانند در ارزیابی قرار گیرند.

بنابراین هنگام خرید سرور فیزیکی نباید از ML30 صرفاً به‌ دلیل «قوی‌تر بودن» یک مدل دیگر عبور کرد؛ باید دقیقاً مشخص شود کدام Resource Requirement از محدوده ML30 خارج شده و پلتفرم بعدی چگونه آن محدودیت را برطرف می‌کند.

قبل از خرید ML30 چگونه ظرفیت مورد نیاز کسب‌ و کار را محاسبه کنیم؟

Sizing سرور ML30 باید قبل از انتخاب مدل CPU، ظرفیت RAM یا تعداد Drive انجام شود. برای این کار بهتر است به‌ جای تخمین‌هایی مثل «این سرور برای شرکت ما کافی است»، داده‌های مصرف واقعی یا حداقل برآورد قابل ‌اندازه‌ گیری Workload جمع‌ آوری شوند.

قبل از درخواست کانفیگ یا استعلام قیمت سرور hp این چک‌ لیست را تکمیل کنید:

1. CPU

  • Peak CPU Utilization فعلی چقدر است؟
  • چند سرویس قرار است هم‌ زمان روی سرور اجرا شوند؟
  • چه تعداد Concurrent User داریم؟
  • آیا بار پردازشی در ساعات خاصی به‌ طور محسوسی افزایش پیدا می‌کند؟

مبنای Sizing باید Peakهای واقعی و تکرار شونده باشد، نه فقط Average Usage.

2. RAM

ظرفیت مورد نیاز را می‌توان به ‌صورت کلی از این اجزا برآورد کرد:

Current Requirement + Peak Demand + Growth Headroom + Virtualization Overhead

اگر سرور Host مجازی‌ سازی است، Memory مورد نیاز Hypervisor و VMها نیز باید در محاسبه ظرفیت نهایی لحاظ شود.

3. Storage Capacity

ابتدا میزان داده فعلی و نرخ رشد آن را مشخص کنید. سپس فضای مورد نیاز سیستم‌ عامل، Applicationها و داده‌ها را در کنار ظرفیت لازم برای آینده محاسبه کنید. در نهایت باید اثر RAID نیز در نظر گرفته شود، زیرا مجموع ظرفیت اسمی Driveها همان Usable Capacity نهایی نیست.

4. Storage Performance

ظرفیت به‌ تنهایی برای Sizing کافی نیست. باید مشخص شود Workload چه مقدار IOPS، Throughput و Latency نیاز دارد. این اطلاعات تعیین می‌کنند HDD، SSD یا ترکیب دیگری از Drive و Controller برای سرور منطقی‌تر است.

5. Network

حجم ترافیک Clientها، انتقال فایل، ارتباط Applicationها و ترافیک Backup باید مشخص شود. اگر حجم انتقال از ظرفیت NIC و شبکه بیشتر باشد، حتی Storage سریع‌تر نیز نمی‌تواند Throughput مورد انتظار کاربران را فراهم کند.

6. Availability

باید از ابتدا مشخص شود کسب ‌و کار چه میزان Downtime را تحمل می‌کند. اگر توقف سرویس برای چند ساعت قابل ‌قبول نیست، Sizing تنها مسئله انتخاب CPU و RAM نیست و باید Redundancy، Backup، Recovery و احتمالاً معماری چند سروری نیز وارد طراحی شوند.

7. Growth

Sizing را فقط برای روز خرید انجام ندهید. تعداد کاربران، حجم داده، VMها و سرویس‌های احتمالی طی دو تا سه سال آینده را نیز برآورد کنید. سپس مشخص کنید ML30 بعد از این رشد همچنان Headroom کافی خواهد داشت یا به سقف پلتفرم نزدیک می‌شود.

خروجی این بررسی باید یک Requirement مشخص باشد؛ یعنی قبل از خرید بدانید چه سطحی از CPU، چه ظرفیت RAM، چه تعداد و نوع Drive، چه RAID Controller، چه Network Interface و کدام Generation از ML30 پاسخ‌ گوی نیاز است. به این ترتیب ابتدا Workload اندازه‌ گیری می‌شود و بعد سخت ‌افزار انتخاب می‌شود، نه برعکس.

جمع‌ بندی

HPE ProLiant ML30 برای کسب‌ و کارهایی انتخاب مناسبی است که به یک سرور Tower برای سرویس‌هایی مانند حسابداری و ERP، File Server، Backup، Application Server یا مجازی‌ سازی محدود نیاز دارند، اما مناسب ‌بودن آن را نمی‌توان فقط از روی تعداد کاربران مشخص کرد. نوع Workload، ظرفیت و Performance مورد نیاز Storage، منابع مورد نیاز سرویس‌ها، سطح Availability و رشد آینده باید در کنار یکدیگر بررسی شوند. مهم‌تر از انتخاب قوی‌ترین CPU یا بیشترین RAM، ساختن یک Configuration متعادل و داشتن Headroom کافی برای توسعه است. اگر Sizing نشان دهد نیازهای آینده به سقف پردازش، Memory، Storage یا Expansion پلتفرم نزدیک می‌شود یا سرویس به معماری HA نیاز دارد، بهتر است از ابتدا سرور رده بالاتری بررسی شود تا کسب ‌و کار در مدت کوتاهی مجبور به تعویض پلتفرم نشود.

سوالات متداول

۱_ آیا ML30 برای کارکرد 24 ساعته مناسب است؟

بله، ML30 یک سرور سازمانی است و می‌تواند برای سرویس‌های دائمی استفاده شود؛ اما پایداری عملی آن به کانفیگ صحیح، شرایط Cooling، سلامت قطعات، طراحی Storage و تأمین برق مناسب نیز وابسته است.

۲_ آیا می‌توان بعداً کانفیگ ML30 را ارتقا داد؟

بله، اما دامنه ارتقا نامحدود نیست. Generation سرور، تعداد DIMM Slot، Drive Bay، PCIe Slot، Controller و محدودیت Single-Socket مشخص می‌کنند تا چه سطحی امکان توسعه وجود دارد. به همین دلیل مسیر ارتقا بهتر است هنگام خرید اولیه مشخص شود.

۳_ برای ML30 مدل Gen10 Plus بهتر است یا Gen11؟

انتخاب فقط به جدیدتر بودن نسل بستگی ندارد. باید پردازنده‌های قابل پشتیبانی، نوع Memory، امکانات I/O و PCIe، کانفیگ Storage، بودجه و طول عمر مورد انتظار زیرساخت مقایسه شوند. برای خرید جدید با برنامه توسعه چند ساله، مزیت‌های پلتفرم جدیدتر اهمیت بیشتری پیدا می‌کنند.

۴_ آیا ML30 برای نگهداری اطلاعات مهم به‌ تنهایی کافی است؟

وجود RAID یا Driveهای Enterprise به‌ تنهایی حفاظت کامل از اطلاعات ایجاد نمی‌کند. برای داده‌های مهم باید Backup مستقل و قابل‌ بازیابی وجود داشته باشد و براساس اهمیت سرویس، محل نگهداری نسخه پشتیبان و Recovery Plan نیز مشخص شود.