راهنمای انتخاب کانفیگ سرور HPE برای مجازیسازی، حسابداری و فایلسرور

دو شرکت را در نظر بگیرید که هر دو ۳۰ کاربر دارند. در شرکت اول، بیشتر کارها به فایلهای Word و Excel، پوشههای اشتراکی و یک نرمافزار اداری محدود میشود. شرکت دوم نرمافزار حسابداری مبتنی بر SQL دارد، چند ماشین مجازی اجرا میکند و بکاپ هم از طریق شبکه انجام میشود. تعداد کاربر در هر دو شرکت یکی است، اما سروری که برای آنها انتخاب میشود نباید یکسان باشد.
این همان جایی است که انتخاب سرور فقط بر اساس عبارتهایی مثل «سرور برای ۳۰ کاربر» دردسرساز میشود. تعداد کاربران برای شروع بررسی مفید است، ولی CPU، رم، ذخیرهسازی و شبکه باید بر اساس کاری که واقعاً روی سرور انجام میشود انتخاب شوند. اگر ابتدا مدل و قیمت را مقایسه کنید و بعد به سراغ بار کاری بروید، احتمال دارد بودجه در بخشی خرج شود که گلوگاه اصلی سیستم نیست.
برای شناخت خانوادههای رکمونت و ایستاده، راهنمای انتخاب و خرید سرور HP و HPE نقطه شروع مناسبی است.
قبل از انتخاب مدل، این چند مورد را مشخص کنید
پیش از گرفتن پیشفاکتور، یک برگه ساده برای نیازسنجی آماده کنید. نام نرمافزارها، نسخه آنها، تعداد کاربران همزمان، حجم فعلی اطلاعات و برنامه رشد مجموعه را بنویسید. اگر قرار است از مجازیسازی استفاده شود، هر ماشین مجازی را جدا ببینید؛ مثلاً یک VM برای حسابداری، یک VM برای فایلسرور و یک VM برای سرویسهای داخلی.
در سیستم فعلی، مصرف CPU و RAM را در ساعتهای شلوغ بررسی کنید. برای Storage هم فقط فضای اشغالشده مهم نیست؛ میزان خواندن و نوشتن و تأخیر دیسک کمک میکند گلوگاه را پیدا کنید.
دو سؤال دیگر هم باید جواب داشته باشند: اگر اطلاعات از بین رفت، از دست دادن چه مقدار داده قابل قبول است؟ اگر سرویس قطع شد، چه مدت فرصت دارید آن را برگردانید؟ این دو سؤال همان RPO و RTO هستند و روی بکاپ، RAID، قطعات یدکی و حتی نیاز به میزبان دوم اثر میگذارند.
پردازنده؛ تعداد هسته را به تنهایی نبینید
برای خیلی از خریداران، مقایسه CPU از تعداد Core شروع میشود. این معیار مهم است، اما کافی نیست. در مجازیسازی، هسته بیشتر اجازه میدهد vCPU بیشتری بین ماشینها توزیع شود، ولی همه VMها مصرف یکسانی ندارند. ممکن است فایلسرور مصرف کمی داشته باشد و SQL هنگام تهیه گزارش فشار اصلی را روی CPU ایجاد کند.
در نرمافزارهای حسابداری و پایگاه داده، فرکانس پردازنده و کارایی هر هسته هم مهم است. موضوع لایسنس را نیز فراموش نکنید. بعضی نرمافزارها بر اساس Core یا Socket قیمتگذاری میشوند و پردازندهای با هسته بیشتر ممکن است هزینه مجوز را بالا ببرد، بدون اینکه آن تعداد هسته واقعاً استفاده شود.
برای انتخاب CPU، بار فعلی و رشد آینده را ببینید. سازگاری پردازنده با نسل سرور، هیتسینک، پاور و شاسی را نیز در QuickSpecs همان مدل کنترل کنید.
برای ۳۰ کاربر چقدر رم لازم است؟
جواب به کاری بستگی دارد که این ۳۰ نفر انجام میدهند. یک فایلسرور ساده ممکن است با ۳۲ یا ۶۴ گیگابایت رم کار کند، در حالی که چند ماشین مجازی به همراه SQL میتوانند خیلی زود از این مقدار عبور کنند.
در مجازیسازی، رم مورد نیاز هر VM، سربار Hypervisor و ظرفیت آزاد برای رشد را با هم حساب کنید. برای پایگاه داده نیز بخشی از حافظه صرف Cache میشود و کمبود RAM میتواند مراجعه به Storage را بیشتر کند؛ چیزی که معمولاً به شکل کندیهای مقطعی دیده میشود.
در سرورهای HPE نوع ماژول، Rank، سرعت و نحوه پر کردن کانالهای حافظه روی کارایی اثر میگذارد. پر کردن همه اسلاتها با ماژولهای کمظرفیت میتواند ارتقای بعدی را سختتر کند.
برای بررسی مدلها میتوان از فهرست رم سرور HPE شروع کرد، ولی پارتنامبر و Memory Population Rules همان سرور باید قبل از خرید کنترل شود.
Storage؛ چهار ترابایت همیشه چهار ترابایت نیست
دو سرور ممکن است هر دو چهار ترابایت فضای مفید داشته باشند و عملکردشان کاملاً متفاوت باشد. نوع دیسک، تعداد Drive، RAID، کنترلر و الگوی دسترسی داده تعیین میکند Storage زیر بار واقعی چطور رفتار کند.
فایلسروری که بیشتر برای آرشیو و اسناد اداری استفاده میشود فشار متفاوتی نسبت به Datastore چند ماشین مجازی دارد. در VMها و پایگاه داده، IOPS و Latency اهمیت بیشتری پیدا میکنند. اگر Storage کند باشد، افزایش CPU یا RAM همیشه مشکل را حل نمیکند.
SSD معمولا پاسخگویی سریعتری دارد، اما رابط SAS، SATA یا NVMe، میزان Endurance و سازگاری Firmware باید با نوع استفاده هماهنگ باشد.
RAID 10 یا RAID 6؟
این انتخاب جواب ثابتی ندارد. RAID 10 در بارهای پرتراکنش که خواندن و نوشتن زیاد است، معمولاً ارزش بررسی دارد. برای آرشیوهای حجیم که ظرفیت مفید اولویت بیشتری دارد، RAID 6 ممکن است منطقیتر باشد. تعداد دیسکها، نرخ نوشتن و مدت Rebuild روی تصمیم اثر دارند.
RAID بکاپ نیست. اگر فایل اشتباهی حذف شود، دیتابیس خراب شود یا باجافزار فایلها را رمزگذاری کند، سالم بودن آرایه نسخه قبلی فایل را برنمیگرداند. نسخه پشتیبان باید جداگانه طراحی شود و بازیابی آن هم آزمایش شود.
شبکه؛ گلوگاهی که دیر دیده میشود
برای فایلسرور کوچک، یک لینک یک گیگابیتی ممکن است کافی باشد. اما اگر همان سرور بکاپ شبکهای بگیرد، چند VM را میزبانی کند و فایلهای حجیم در اختیار کاربران بگذارد، شبکه میتواند محدودیت ایجاد کند.
شاید در این شرایط 10GbE لازم باشد، اما خرید کارت شبکه ۱۰ گیگ بدون بررسی سوئیچ و کابلکشی فایدهای ندارد. کل مسیر باید از سرعت موردنظر پشتیبانی کند. در شبکههای بزرگتر نیز میتوان ترافیک کاربران، مدیریت، Storage و Backup را جدا کرد.
NIC Teaming یا Bonding نیز برای افزونگی یا توزیع ترافیک به کار میرود و باید با تنظیمات سوئیچ هماهنگ باشد.
iLO و دسترسی مدیریتی
iLO در سرورهای HPE امکان مدیریت سختافزار را خارج از سیستمعامل فراهم میکند. وقتی Windows یا Linux بالا نمیآید، مشاهده وضعیت سختافزار، رخدادها و کنترل توان از راه دور میتواند عیبیابی را سریعتر کند.
از ابتدا مشخص کنید iLO روی چه شبکهای قرار میگیرد و چه کسانی به آن دسترسی دارند. قرار دادن رابط مدیریت در دسترس عمومی اینترنت انتخاب مناسبی نیست.
پاور دوم همیشه به معنی افزونگی نیست
دو Power Supply زمانی مفید است که مسیر برق هم درست طراحی شده باشد. اگر هر دو پاور به یک چندراهی یا یک PDU وصل شوند، همان نقطه خرابی مشترک باقی میماند. در پروژههای حساس بهتر است تغذیه دو پاور تا حد ممکن از مسیرهای مستقل تأمین شود.
UPS نیز باید بر اساس مصرف واقعی تجهیزات و زمان پشتیبانی مورد انتظار انتخاب شود. سوئیچها و سایر تجهیزات رک هم در این محاسبه سهم دارند.

سه سناریوی رایج برای شروع بررسی
اعداد این بخش پیشنهاد خرید قطعی نیستند؛ فقط نقطه شروعی برای مقایسه پیشفاکتورها یا گفتوگو با کارشناس هستند.
فایلسرور برای ۱۵ تا ۳۰ کاربر: در پروژههای سبک میتوان بررسی را از ۶ تا ۸ هسته پردازشی و ۳۲ تا ۶۴ گیگابایت رم شروع کرد. ظرفیت دیسک و روش بکاپ در این سناریو معمولا از افزایش بیدلیل CPU مهمتر است.
حسابداری و SQL برای ۲۰ تا ۵۰ کاربر: ۸ تا ۱۲ هسته با فرکانس مناسب، ۶۴ تا ۱۲۸ گیگابایت رم و Storage سریع میتواند نقطه شروع باشد. اندازه دیتابیس، تعداد تراکنش و نوع گزارشها این اعداد را تغییر میدهد.
میزبان ۴ تا ۸ ماشین مجازی سبک تا متوسط: میتوان بررسی را از ۱۲ تا ۲۰ هسته و ۱۲۸ تا ۲۵۶ گیگابایت رم شروع کرد. در اینجا مجموع مصرف VMها، IOPS و ظرفیت توسعه باید دقیقتر محاسبه شود.
DL یا ML؛ کدام خانواده مناسبتر است؟
اگر رک استاندارد، تهویه مناسب و فضای مشخص برای تجهیزات دارید،از سرورهای شرکت HPE میتوان گفت مدلهای DL برای استقرار داخل رک انتخاب طبیعیتری هستند. در دفترهایی که رک دیتاسنتری ندارند، مدلهای ML به دلیل فرم Tower سادهتر نصب میشوند.
Tower بودن به معنی بینیازی از شرایط مناسب نیست. دما، گردوغبار، صدا و دسترسی فیزیکی همچنان باید کنترل شود. جدیدتر بودن نسل سرور هم بهتنهایی دلیل کافی برای خرید نیست. گاهی یک مدل نسل قبل با قطعات در دسترس و هزینه نگهداری کمتر برای پروژه انتخاب بهتری است.
قبل از گرفتن پیشفاکتور چه چیزهایی را آماده کنیم؟
نام نرمافزارها و نسخه آنها را بنویسید. تعداد کاربران همزمان را مشخص کنید، نه فقط تعداد پرسنل. اگر سیستم فعلی دارید، مصرف CPU، RAM و Disk را در ساعت شلوغ ثبت کنید. حجم داده و رشد سه تا پنج سال آینده، روش بکاپ و زمان مورد نیاز برای Restore را نیز مشخص کنید.
در پیشفاکتور بهتر است مدل دقیق پردازنده، تعداد و ظرفیت ماژولهای رم، نوع شاسی، کنترلر RAID، مدل دیسکها، کارت شبکه، پاور و ریلکیت مشخص باشد. عبارتهایی مثل «رم ۱۲۸ گیگ» یا «SSD یک ترابایت» برای یک سرور سازمانی اطلاعات کافی نیستند.
اگر مشخصات بار کاری را آماده کردهاید، از طریق استعلام کانفیگ سرور بر اساس نیاز پروژه میتوان اطلاعات را برای بررسی فنی ارسال کرد. پیشنهاد نهایی باید قابل توضیح باشد؛ یعنی روشن باشد چرا این CPU انتخاب شده، چرا این مقدار رم لازم است و Storage بر چه اساسی طراحی شده است.
سرور مناسب لزوما گرانترین کانفیگ نیست. باید زیر بار واقعی کم نیاورد، برای رشد آینده جا داشته باشد و در بخشهایی که استفاده نمیشوند بودجه را هدر ندهد. برای همین، سؤال «برای ۳۰ یا ۵۰ کاربر چه سروری بخریم؟» بهتر است با یک سؤال دیگر شروع شود: این کاربران دقیقا چه کاری با سرور انجام میدهند؟



