سرور مناسب حسابداری؛ چه کانفیگی برای 10 تا 100 کاربر بخریم؟
فرض کنید یک مجموعه ۱۰ کاربره و یک شرکت ۱۰۰ کاربره هر دو از نرم‌افزار حسابداری و پایگاه داده استفاده می‌کنند؛ آیا می‌توان برای هر دو یک کانفیگ سرور پیشنهاد داد؟ طبیعتاً خیر. با افزایش تعداد کاربران همزمان، حجم دیتابیس و تعداد تراکنش‌ها، فشار بیشتری به پردازنده، RAM و فضای ذخیره‌سازی وارد می‌شود و انتخاب نادرست هرکدام از این قطعات می‌تواند مستقیماً روی سرعت نرم‌افزار حسابداری تأثیر بگذارد.
از طرف دیگر، خرید قوی‌ترین سرور موجود هم الزاماً تصمیم درستی نیست. یک مجموعه ۱۰ یا ۲۰ کاربره ممکن است با یک کانفیگ اقتصادی و اصولی نیاز خود را به‌خوبی پوشش دهد، درحالی‌که یک سازمان ۵۰ یا ۱۰۰ کاربره باید علاوه بر قدرت پردازشی، سرعت Storage، نوع RAID، امکان ارتقا و رشد آینده دیتابیس را نیز جدی‌تر در نظر بگیرد. در این راهنما بررسی می‌کنیم سرور مناسب حسابداری چه مشخصاتی باید داشته باشد و برای ۱۰، ۲۰، ۳۰، ۵۰ و ۱۰۰ کاربر چه سطحی از کانفیگ منطقی‌تر است.
سرور مناسب حسابداری چه مشخصاتی باید داشته باشد؟
سرور مناسب حسابداری باید پردازنده‌ای متناسب با بار کاری نرم‌افزار و دیتابیس، RAM کافی، فضای ذخیره‌سازی سریع و مطمئن و RAID مناسب داشته باشد. بااین‌حال، نمی‌توان یک کانفیگ ثابت را برای تمام شرکت‌ها پیشنهاد کرد؛ زیرا تعداد کاربران همزمان، حجم دیتابیس، تعداد تراکنش‌ها و سرویس‌های دیگری که روی سرور اجرا می‌شوند، منابع موردنیاز را تغییر می‌دهند.
بنابراین اگر برای مثال گفته شود «برای ۳۰ کاربر ۶۴ گیگابایت RAM کافی است»، این عدد را باید یک نقطه شروع برای انتخاب کانفیگ در نظر گرفت، نه یک قانون ثابت.
ممکن است شرکتی ۳۰ کاربر تعریف‌شده داشته باشد، اما در ساعات کاری فقط ۱۰ تا ۱۵ نفر به‌صورت همزمان از نرم‌افزار حسابداری استفاده کنند. در مقابل، مجموعه دیگری با همان ۳۰ کاربر ممکن است تعداد زیادی تراکنش روزانه، گزارش‌های سنگین و یک دیتابیس حجیم داشته باشد. طبیعی است که نیاز سخت‌افزاری این دو مجموعه یکسان نیست.
به همین دلیل برای انتخاب دقیق‌تر سرور حسابداری باید چهار بخش اصلی را جداگانه بررسی کنیم: CPU، RAM، Storage و RAID
CPU مناسب سرور حسابداری
پردازنده را می‌توان یکی از مهم‌ترین اجزای کانفیگ سرور حسابداری دانست، اما انتخاب CPU صرفاً بر اساس تعداد هسته‌ها می‌تواند گمراه‌کننده باشد.
در محیط‌هایی که نرم‌افزار حسابداری به SQL Server یا یک Database Engine متکی است، نوع پردازش‌های انجام‌شده روی دیتابیس اهمیت زیادی دارد. ثبت اسناد، جست‌وجو در اطلاعات، تهیه گزارش، محاسبات مالی و اجرای Queryهای مختلف می‌توانند الگوهای متفاوتی از مصرف CPU ایجاد کنند.
برای یک مجموعه کوچک با تعداد محدود کاربران همزمان، الزاماً نیازی به پردازنده‌ای با تعداد بسیار زیاد Core نیست. در بسیاری از این سناریوها، یک پردازنده متناسب با Workload و فرکانس مناسب می‌تواند عملکرد مطلوبی ارائه دهد.
اما با افزایش کاربران همزمان، گزارش‌های سنگین، حجم تراکنش‌ها و سرویس‌های جانبی، نیاز پردازشی نیز افزایش پیدا می‌کند. در چنین شرایطی باید تعادل مناسبی میان تعداد هسته، فرکانس پردازنده و نسل CPU برقرار شود.
نکته مهم دیگر این است که اگر قرار باشد علاوه بر نرم‌افزار حسابداری، سرویس‌هایی مانند File Server، ماشین مجازی یا نرم‌افزارهای سازمانی دیگری نیز روی همان سرور اجرا شوند، پردازنده باید بر اساس مجموع این بارهای کاری انتخاب شود، نه فقط نرم‌افزار حسابداری.
تعداد هسته مهم‌تر است یا فرکانس پردازنده؟
پاسخ کوتاه این است: هیچ‌کدام به‌تنهایی معیار مناسبی نیستند.
تعداد Core بیشتر به سرور اجازه می‌دهد پردازش‌های بیشتری را به‌صورت همزمان مدیریت کند؛ درحالی‌که فرکانس بالاتر می‌تواند در Workloadهایی که عملکرد یک یا تعداد محدودی از هسته‌ها اهمیت بیشتری دارد، مؤثر باشد.
برای مثال، خرید یک CPU با تعداد بسیار زیاد هسته اما فرکانس پایین، الزاماً باعث افزایش محسوس سرعت نرم‌افزار حسابداری نمی‌شود. از طرف دیگر، در محیطی با تعداد زیادی کاربر همزمان و چند سرویس فعال، محدود کردن سرور به تعداد کمی Core نیز می‌تواند به گلوگاه پردازشی منجر شود.
بنابراین هنگام انتخاب CPU سرور حسابداری بهتر است این موارد همزمان بررسی شوند:
– تعداد کاربران همزمان نرم‌افزار– حجم و پیچیدگی عملیات دیتابیس– تعداد و نوع گزارش‌ها– سرویس‌های جانبی در حال اجرا– نیاز به مجازی‌سازی– برنامه توسعه مجموعه در آینده
هدف این نیست که قوی‌ترین CPU ممکن را انتخاب کنیم؛ هدف انتخاب پردازنده‌ای است که بدون ایجاد گلوگاه، بار کاری فعلی را مدیریت کند و فضای منطقی برای رشد آینده نیز داشته باشد.
چه مقدار RAM برای سرور حسابداری نیاز داریم؟
RAM یکی دیگر از بخش‌های بسیار مهم در کانفیگ سرور حسابداری است؛ به‌خصوص زمانی که نرم‌افزار از SQL Server یا پایگاه داده مشابهی استفاده می‌کند.
پایگاه داده می‌تواند بخشی از اطلاعات موردنیاز خود را در حافظه نگه دارد تا برای دسترسی مجدد مجبور نباشد دائماً اطلاعات را از Storage فراخوانی کند. به همین دلیل، کمبود RAM در بعضی Workloadهای دیتابیسی می‌تواند باعث افزایش عملیات خواندن از Storage و افت Performance شود.
اما این موضوع به این معنا نیست که هرچه RAM بیشتری روی سرور نصب کنیم، نرم‌افزار حسابداری الزاماً سریع‌تر خواهد شد.
مقدار RAM موردنیاز باید با توجه به چند عامل تعیین شود:
– تعداد کاربران همزمان– اندازه دیتابیس– رشد دیتابیس– نسخه و تنظیمات Database Engine– سیستم‌عامل– سرویس‌های جانبی– تعداد ماشین‌های مجازی در صورت استفاده از Virtualization
برای مثال، در یک مجموعه کوچک ممکن است ۳۲ گیگابایت RAM نقطه شروع مناسبی باشد؛ اما در سناریوهای متوسط، ۶۴ گیگابایت و در محیط‌های سنگین‌تر ۱۲۸ گیگابایت یا بیشتر منطقی‌تر خواهد بود.
این اعداد حداقل رسمی برای تمام نرم‌افزارهای حسابداری نیستند و باید بر اساس Workload واقعی بررسی شوند.
نکته مهم دیگر، قابلیت ارتقا است. اگر در حال حاضر ۳۲ یا ۶۴ گیگابایت RAM برای مجموعه کافی است اما انتظار دارید تعداد کاربران و حجم دیتابیس طی دو یا سه سال آینده افزایش پیدا کند، بهتر است سروری انتخاب شود که امکان ارتقای حافظه را بدون تغییر کل زیرساخت فراهم کند.
SSD یا HDD؛ کدام برای دیتابیس حسابداری بهتر است؟
اگر قرار باشد میان بخش‌های مختلف سرور برای یک Workload دیتابیسی اولویت‌بندی کنیم، Storage یکی از قسمت‌هایی است که نباید نادیده گرفته شود.
دیتابیس حسابداری دائماً در حال خواندن و نوشتن اطلاعات است. ثبت فاکتور، سند حسابداری، گزارش‌گیری، جست‌وجوی اطلاعات و پردازش Queryها می‌توانند عملیات I/O زیادی ایجاد کنند. در چنین شرایطی سرعت و Latency فضای ذخیره‌سازی روی تجربه کاربران تأثیر می‌گذارد.
به همین دلیل استفاده از SSD مناسب سرور برای Database معمولاً انتخاب بهتری نسبت به قرار دادن دیتابیس پرتراکنش روی HDDهای کند است.
البته HDD همچنان می‌تواند کاربرد داشته باشد. برای مثال، اگر حجم زیادی از اطلاعات آرشیوی یا Backup نگهداری می‌شود که نیاز به دسترسی بسیار سریع ندارد، استفاده از HDD در یک Storage مناسب می‌تواند از نظر هزینه به‌صرفه‌تر باشد.
نوع داده
Storage پیشنهادی
دلیل
سیستم‌عامل
SSD
سرعت Boot و اجرای سرویس‌ها
SQL Database
Enterprise SSD
IOPS و Latency بهتر
فایل‌های عمومی
SSD/HDD
وابسته به حجم و بار
Backup
HDD / Storage مجزا
ظرفیت بیشتر و هزینه کمتر
نکته مهم این است که Backup نباید صرفاً نسخه دیگری از اطلاعات روی همان Storage اصلی سرور باشد. خرابی RAID Controller، خطای انسانی، بدافزار یا آسیب گسترده به Storage می‌تواند نسخه اصلی و Backup را همزمان تحت تأثیر قرار دهد.
RAID مناسب سرور حسابداری چیست؟
استفاده از چند SSD یا HDD بدون طراحی صحیح RAID نمی‌تواند به‌تنهایی امنیت و Performance مناسبی برای اطلاعات حسابداری ایجاد کند.
RAID با توجه به سطح مورد استفاده می‌تواند برای افزونگی، Performance یا ترکیبی از هر دو مورد استفاده قرار گیرد. در سرورهای حسابداری معمولاً RAID 1 و RAID 10 از گزینه‌های مهم هستند و در بعضی سناریوها RAID 5 نیز مورد بررسی قرار می‌گیرد.
RAID 1 اطلاعات را به‌صورت Mirror روی دو Drive نگهداری می‌کند. این ساختار ساده است و می‌تواند برای سیستم‌عامل یا بعضی Workloadهای سبک گزینه مناسبی باشد.
RAID 5 با حداقل سه Drive امکان تحمل خرابی یک Drive را فراهم می‌کند و ظرفیت قابل استفاده بیشتری نسبت به برخی ساختارهای Mirror ارائه می‌دهد؛ اما به دلیل نحوه محاسبه و ثبت Parity، به‌خصوص در عملیات Write، باید Performance موردنیاز Workload پیش از انتخاب آن بررسی شود.
RAID 10 ترکیبی از Mirroring و Striping است و حداقل به چهار Drive نیاز دارد. این ساختار در بسیاری از Workloadهای دیتابیسی که Performance نوشتن و Redundancy اهمیت بالایی دارند، گزینه قابل‌توجهی محسوب می‌شود؛ البته هزینه آن از نظر تعداد Drive و ظرفیت قابل استفاده بیشتر است.
در انتخاب RAID برای سرور حسابداری فقط نباید به ظرفیت نهایی توجه کرد. تعداد کاربران همزمان، میزان عملیات Read/Write، اهمیت Performance و مدت زمان قابل‌تحمل برای بازیابی سیستم نیز باید بررسی شوند.
همچنین RAID جای Backup را نمی‌گیرد. RAID می‌تواند در برابر خرابی برخی Driveها از دسترس‌پذیری سیستم محافظت کند، اما در برابر حذف اشتباه اطلاعات، خراب شدن Database، باج‌افزار یا بسیاری از سناریوهای Disaster Recovery، جایگزین یک استراتژی Backup اصولی نیست.
در نتیجه، انتخاب سرور حسابداری را نباید به یک مشخصه مانند «RAM بالا» یا «CPU قوی» محدود کرد. CPU، RAM، Storage و RAID باید در کنار یکدیگر و متناسب با Workload انتخاب شوند. حالا سؤال مهم‌تر مطرح می‌شود: این مشخصات برای یک شرکت ۱۰ کاربره تا یک مجموعه ۱۰۰ کاربره دقیقاً چگونه تغییر می‌کنند؟
برای 10 تا 100 کاربر چه کانفیگ سرور حسابداری بخریم؟
برای انتخاب سرور مناسب حسابداری نمی‌توان فقط تعداد کاربران را در نظر گرفت؛ اما تعداد کاربران همزمان نقطه شروع خوبی برای تخمین منابع موردنیاز است. به‌طور کلی، با افزایش کاربران باید ظرفیت پردازشی، RAM و توان I/O فضای ذخیره‌سازی نیز متناسب با حجم دیتابیس و تعداد تراکنش‌ها افزایش پیدا کند.
جدول زیر یک دید اولیه برای انتخاب کانفیگ ارائه می‌دهد. این اعداد برای یک محیط حسابداری متعارف در نظر گرفته شده‌اند و ممکن است براساس نرم‌افزار مورد استفاده، حجم Database، تعداد کاربران همزمان و سرویس‌های جانبی نیاز به تغییر داشته باشند.
نکته: این جدول برای Shortlist اولیه است. اگر مثلاً ۵۰ حساب کاربری در نرم‌افزار تعریف شده اما تنها ۱۵ نفر همزمان از سیستم استفاده می‌کنند، نیاز سخت‌افزاری می‌تواند با شرکتی که ۵۰ کاربر همزمان دارد کاملاً متفاوت باشد.
کانفیگ سرور حسابداری برای 10 کاربر
برای یک شرکت کوچک با حدود ۱۰ کاربر، دیتابیس نسبتاً کم‌حجم و تعداد تراکنش‌های روزانه معمول، نیازی نیست از همان ابتدا سراغ یک کانفیگ بسیار سنگین برویم.
در چنین سناریویی، یک پردازنده Xeon مناسب در کنار ۳۲ گیگابایت RAM می‌تواند نقطه شروع منطقی باشد. برای Storage نیز استفاده از دو SSD سازمانی در RAID 1 می‌تواند ترکیبی از سرعت و Redundancy را فراهم کند.
یک کانفیگ پایه می‌تواند چنین ساختاری داشته باشد:
– CPU: یک پردازنده Xeon متناسب با Workload– RAM: 32GB– Storage: حداقل 2× Enterprise SSD– RAID: RAID 1– Network: حداقل 1GbE در شبکه‌های معمول– Power: ترجیحاً Redundant PSU– قابلیت ارتقا: امکان افزایش RAM و Drive در آینده
اگر Database کوچک است و نرم‌افزار حسابداری تنها سرویس اصلی سرور محسوب می‌شود، این سطح از سخت‌افزار می‌تواند نقطه شروع مناسبی باشد.
اما حتی برای ۱۰ کاربر نیز باید به رشد آینده توجه کرد. اگر مجموعه قرار است طی یک یا دو سال تعداد نیروها، شعب یا حجم اطلاعات خود را افزایش دهد، خرید سروری که تقریباً تمام ظرفیت ارتقای آن از روز اول مصرف شده باشد، تصمیم مناسبی نیست.
از طرف دیگر، خرید دو پردازنده قدرتمند، صدها گیگابایت RAM و تعداد زیادی SSD برای یک مجموعه کوچک صرفاً با تصور «آینده‌نگری» می‌تواند هزینه اولیه را بدون ایجاد مزیت عملی متناسب افزایش دهد.
کانفیگ سرور حسابداری برای 20 کاربر
در یک مجموعه ۲۰ کاربره، شرایط کمی متفاوت می‌شود. احتمال افزایش تعداد اتصال‌های همزمان، تراکنش‌ها و درخواست‌های Database بیشتر است و ممکن است در کنار نرم‌افزار حسابداری، سرویس‌های دیگری نیز روی سرور اجرا شوند.
برای چنین مجموعه‌ای می‌توان ۳۲ تا ۶۴ گیگابایت RAM را به‌عنوان بازه اولیه بررسی کرد. اگر دیتابیس در حال رشد است، کاربران همزمان زیادی دارید یا SQL Server درگیر گزارش‌های متعدد است، حرکت به سمت ۶۴ گیگابایت RAM می‌تواند فضای بیشتری برای Workload فراهم کند.
کانفیگ پایه پیشنهادی:
– CPU: Xeon رده متوسط متناسب با تعداد کاربران همزمان– RAM: 32GB تا 64GB– Storage: Enterprise SSD– RAID: RAID 1 برای سناریوهای سبک یا RAID 10 در صورت نیاز به I/O بیشتر– RAID Controller: کنترلر سخت‌افزاری متناسب با آرایه– Network: 1GbE یا بالاتر براساس زیرساخت شبکه– PSU: ترجیحاً Redundant
در این سطح بهتر است وضعیت Storage با دقت بیشتری بررسی شود. اگر نرم‌افزار حسابداری دائماً با Database درگیر است و چندین کاربر به‌صورت همزمان گزارش می‌گیرند، صرفاً افزایش RAM بدون توجه به Storage نمی‌تواند تمام مشکلات Performance را برطرف کند.
همچنین اگر File Server، Domain Controller یا سرویس‌های دیگری قرار است روی همین سخت‌افزار اجرا شوند، منابع موردنیاز آن‌ها نیز باید جداگانه در محاسبات لحاظ شود.
کانفیگ سرور حسابداری برای 30 کاربر
در محدوده ۳۰ کاربر، انتخاب کانفیگ باید جدی‌تر و بیشتر بر اساس Concurrent User انجام شود.
فرض کنید یک شرکت ۳۰ کارمند دارد اما تنها ۱۰ نفر از آن‌ها به‌طور همزمان در نرم‌افزار حسابداری فعال هستند. این سناریو با شرکتی که تقریباً تمام ۳۰ کاربر در ساعات اوج کاری به‌صورت همزمان فاکتور ثبت می‌کنند، گزارش می‌گیرند یا اطلاعات مالی را پردازش می‌کنند، یکسان نیست.
برای یک Workload متعارف ۳۰ کاربره، ۶۴ گیگابایت RAM می‌تواند نقطه شروع مناسبی باشد. در بخش Storage نیز استفاده از SSDهای Enterprise و در بارهای دیتابیسی جدی‌تر، RAID 10 ارزش بررسی بیشتری پیدا می‌کند.
کانفیگ پایه:
– CPU: Xeon رده متوسط با تعادل مناسب Core و Frequency– RAM: حدود 64GB با امکان ارتقا– Storage: Enterprise SSD– RAID: ترجیحاً RAID 10 برای Databaseهای دارای I/O قابل‌توجه– RAID Controller: کنترلر سخت‌افزاری مناسب– Network: حداقل 1GbE؛ متناسب با معماری شبکه قابل ارتقا– PSU: Redundant– Backup: مستقل از Storage اصلی سرور
در این سطح، انتخاب تعداد و ظرفیت SSDها نیز باید با توجه به حجم فعلی Database و رشد آینده انجام شود.
برای مثال اگر Database فعلی چندصد گیگابایت است اما حجم اطلاعات سالانه با سرعت زیادی افزایش پیدا می‌کند، نباید Storage را فقط براساس فضای مصرف‌شده امروز انتخاب کرد. علاوه بر ظرفیت، باید فضای لازم برای رشد Database، Logها، سیستم‌عامل و عملیات نگهداری نیز در نظر گرفته شود.
کانفیگ سرور حسابداری برای 50 کاربر
وقتی تعداد کاربران به حدود ۵۰ نفر می‌رسد، دیگر نمی‌توان انتخاب سرور را فقط به عبارت‌هایی مانند «CPU قوی و RAM بالا» محدود کرد. در این سطح، نحوه استفاده کاربران از Database اهمیت زیادی پیدا می‌کند.
برای مثال، ۵۰ کاربری که عملیات ساده ثبت اطلاعات انجام می‌دهند الزاماً همان منابعی را مصرف نمی‌کنند که ۵۰ کاربر با گزارش‌گیری گسترده، Queryهای پیچیده و تراکنش‌های پرتعداد نیاز دارند.
برای یک محیط متوسط تا نسبتاً سنگین، می‌توان ۶۴ تا ۱۲۸ گیگابایت RAM را به‌عنوان نقطه شروع بررسی کرد. انتخاب CPU نیز باید با توجه به بار SQL و سرویس‌های جانبی انجام شود.
کانفیگ پایه:
– CPU: Xeon رده متوسط رو به بالا، متناسب با Workload– RAM: 64GB تا 128GB– Storage: چند Enterprise SSD– RAID: RAID 10 در Workloadهای دیتابیسی با I/O بالا– RAID Controller: مدل متناسب با تعداد Drive و Performance موردنیاز– Network: متناسب با حجم ترافیک و معماری شبکه– PSU: Redundant– Backup: سیستم Backup مستقل و برنامه‌ریزی‌شده– توسعه‌پذیری: فضای کافی برای RAM، Drive و ارتقای آینده
در چنین محیطی یکی از اشتباهات رایج این است که هنگام مشاهده کندی نرم‌افزار، بدون بررسی علت فقط RAM بیشتری به سرور اضافه شود.
اگر گلوگاه اصلی Storage باشد، افزایش RAM ممکن است مشکل را به‌طور کامل حل نکند. همین موضوع درباره CPU و شبکه نیز صادق است. برای تشخیص دقیق باید مصرف CPU، Memory، Disk Latency، IOPS و وضعیت Database بررسی شود.
بنابراین در یک مجموعه ۵۰ کاربره، توازن قطعات مهم‌تر از بزرگ بودن اعداد روی کاغذ است.
کانفیگ سرور حسابداری برای 100 کاربر
برای حدود ۱۰۰ کاربر، انتخاب سرور باید بر اساس Workload واقعی انجام شود و ارائه یک کانفیگ ثابت برای تمام سازمان‌ها منطقی نیست. تعداد کاربران همزمان، حجم Database، میزان تراکنش‌ها، Reporting، سرویس‌های جانبی و حتی معماری نرم‌افزار می‌توانند منابع موردنیاز را به شکل محسوسی تغییر دهند.
در چنین محیطی ۱۲۸ گیگابایت RAM یا بیشتر می‌تواند نقطه شروع بررسی باشد، اما تعیین مقدار نهایی بدون شناخت Database و سرویس‌های در حال اجرا دقیق نیست.
در بخش CPU نیز به‌جای انتخاب پردازنده صرفاً بر اساس تعداد Core، باید تعادل میان Core Count، Frequency، نسل پردازنده و نوع Workload بررسی شود.
کانفیگ پایه برای بررسی اولیه:
– CPU: Xeon رده بالاتر متناسب با SQL Workload– RAM: 128GB به بالا با ظرفیت ارتقای مناسب– Storage: چند Enterprise SSD با Performance مناسب– RAID: RAID 10 یا معماری Storage متناسب با Workload– RAID Controller: کنترلر قدرتمند متناسب با Array– Network: بررسی 1GbE در برابر 10GbE بر اساس معماری و ترافیک واقعی– PSU: Redundant– Backup: مستقل از Storage اصلی– Monitoring: پایش CPU، RAM، Storage و Database– توسعه‌پذیری: یکی از معیارهای اصلی انتخاب سرور
در یک مجموعه ۱۰۰ کاربره، سؤال مهم این نیست که فقط «چه مقدار RAM بخریم؟» بلکه باید مشخص شود این ۱۰۰ کاربر دقیقاً چه کاری با سرور انجام می‌دهند.
فرض کنید در سناریوی اول ۱۰۰ حساب کاربری تعریف شده، اما فقط ۳۰ نفر به‌طور همزمان فعال هستند و بیشتر عملیات نیز شامل ثبت اطلاعات ساده است.
در سناریوی دوم ۷۰ تا ۸۰ نفر همزمان فعال هستند، گزارش‌های مدیریتی سنگین اجرا می‌شود، Database حجم بالایی دارد و سرویس‌های دیگری نیز از همان سرور استفاده می‌کنند.
تعداد کاربران اسمی در هر دو محیط تقریباً مشابه است، اما نیاز سخت‌افزاری آن‌ها می‌تواند تفاوت قابل‌توجهی داشته باشد.
به همین دلیل برای سازمان‌های نزدیک به ۱۰۰ کاربر، بهتر است پیش از خرید نهایی حداقل این موارد اندازه‌گیری یا مشخص شوند:
1. تعداد کاربران همزمان در ساعات اوج2. حجم فعلی Database3. نرخ رشد سالانه Database4. تعداد تراکنش‌ها و نوع عملیات کاربران5. میزان و پیچیدگی گزارش‌گیری6. سرویس‌های دیگری که روی سرور اجرا می‌شوند7. نیاز یا عدم نیاز به Virtualization8. ظرفیت موردنیاز برای رشد چند سال آینده
جدول مقایسه کانفیگ سرور حسابداری از 10 تا 100 کاربر
اگر بخواهیم پیشنهادهای بالا را برای تصمیم‌گیری اولیه کنار یکدیگر قرار دهیم، می‌توان از جدول زیر استفاده کرد:
این اعداد را نباید به‌عنوان Minimum Requirement رسمی نرم‌افزارهای حسابداری در نظر گرفت. هدف جدول این است که هنگام انتخاب اولیه کانفیگ سرور حسابداری بدانیم از چه سطحی بررسی را شروع کنیم.
برای مثال، اگر یک مجموعه ۲۰ کاربره Database بسیار سنگینی دارد، ممکن است به کانفیگی قوی‌تر از یک شرکت ۳۰ کاربره با استفاده سبک نیاز داشته باشد. به همین دلیل مرحله بعدی انتخاب سرور، بررسی عواملی است که فراتر از تعداد کاربران روی سخت‌افزار موردنیاز تأثیر می‌گذارند.
تعداد کاربر تنها معیار انتخاب سرور حسابداری نیست
یکی از اشتباهات متداول هنگام خرید سرور این است که سؤال را فقط به این شکل مطرح کنیم: «برای ۳۰ کاربر چه سروری بخرم؟»
تعداد کاربران اطلاعات مفیدی در اختیار ما قرار می‌دهد، اما برای تعیین دقیق کانفیگ کافی نیست.
دو شرکت را در نظر بگیرید که هرکدام ۳۰ کاربر دارند. شرکت اول روزانه تعداد محدودی تراکنش ثبت می‌کند، Database نسبتاً کوچکی دارد و در ساعات کاری حداکثر ۱۰ نفر همزمان از نرم‌افزار استفاده می‌کنند.
در شرکت دوم تقریباً تمام کاربران همزمان فعال هستند، Database طی چند سال رشد زیادی کرده، گزارش‌های مالی سنگین اجرا می‌شود و چند سرویس جانبی نیز روی همان سرور قرار دارند.
با وجود یکسان بودن تعداد کاربران، انتخاب یک کانفیگ برای هر دو مجموعه منطقی نیست.
تعداد کاربران همزمان
Concurrent User به کاربرانی گفته می‌شود که در یک بازه زمانی به‌صورت همزمان از نرم‌افزار یا منابع سرور استفاده می‌کنند.
اگر یک شرکت ۵۰ کاربر تعریف‌شده داشته باشد اما در ساعات اوج فقط ۱۵ نفر همزمان فعال باشند، رفتار Workload آن با مجموعه‌ای که ۴۵ تا ۵۰ کاربر همزمان دارد متفاوت خواهد بود.
به همین دلیل هنگام استعلام سرور برای نرم‌افزار حسابداری بهتر است علاوه بر تعداد کل کاربران، تعداد کاربران همزمان در ساعات پرترافیک نیز مشخص شود.
حجم و رشد دیتابیس
فقط حجم امروز Database را در نظر نگیرید.
اگر دیتابیس فعلی ۲۰۰ گیگابایت است اما هر سال حجم قابل‌توجهی به آن اضافه می‌شود، Storage باید علاوه بر نیاز فعلی، فضای رشد آینده را نیز پوشش دهد.
در این محاسبه باید Database، Transaction Logها، سیستم‌عامل، فایل‌های نرم‌افزار و فضای لازم برای عملیات مدیریتی را نیز در نظر گرفت.
انتخاب ظرفیت Storage دقیقاً برابر با اطلاعات فعلی، ممکن است باعث شود سرور خیلی زود به ارتقا نیاز پیدا کند.
نوع نرم‌افزار حسابداری
تمام نرم‌افزارهای حسابداری معماری یکسانی ندارند.
نوع Database Engine، نسخه نرم‌افزار، نحوه پردازش اطلاعات و حتی برخی ماژول‌های مورد استفاده می‌توانند روی منابع موردنیاز تأثیر بگذارند.
به همین دلیل اگر سازنده نرم‌افزار حسابداری برای نسخه مشخصی از محصول خود Hardware Requirement یا Recommendation منتشر کرده است، آن مستندات باید در کنار تحلیل Workload بررسی شوند.
در واقع، پیشنهاد عمومی بر اساس تعداد کاربران نباید جایگزین الزامات رسمی نرم‌افزار شود.
سرویس‌های دیگری که روی سرور اجرا می‌شوند
گاهی سروری که با عنوان «سرور حسابداری» خریداری می‌شود، در عمل فقط میزبان نرم‌افزار حسابداری نیست.
ممکن است همین سخت‌افزار برای اجرای موارد زیر نیز استفاده شود:
اگر چنین برنامه‌ای وجود دارد، CPU، RAM و Storage باید بر اساس مجموع Workloadها انتخاب شوند.
برای مثال، ۶۴ گیگابایت RAM که برای اجرای نرم‌افزار حسابداری و Database کافی به نظر می‌رسد، الزاماً برای همان سرور در شرایطی که چند Virtual Machine نیز روی آن اجرا می‌شود کافی نخواهد بود.
بنابراین قبل از انتخاب نهایی، باید مشخص کنیم سرور قرار است فقط میزبان نرم‌افزار حسابداری باشد یا قرار است بخشی بزرگ‌تر از زیرساخت IT مجموعه را نیز میزبانی کند.
سرور HP مناسب حسابداری؛ DL360 بخریم یا DL380؟
وقتی CPU، RAM و Storage موردنیاز مشخص شد، سؤال بعدی این است که این کانفیگ را روی چه پلتفرمی پیاده کنیم؟ در میان سرورهای رک‌مونت HPE ProLiant، دو خانواده DL360 و DL380 از گزینه‌هایی هستند که برای بسیاری از زیرساخت‌های سازمانی مورد توجه قرار می‌گیرند.
تفاوت اصلی را نباید صرفاً در قدرت پردازشی جست‌وجو کرد. هر دو خانواده بسته به نسل و کانفیگ می‌توانند سخت‌افزار قدرتمندی در اختیار شما قرار دهند. تفاوت مهم‌تر در Form Factor، ظرفیت توسعه، تعداد و نوع Driveهای قابل پشتیبانی در شاسی انتخابی، اسلات‌های توسعه و انعطاف در طراحی آینده است.
به زبان ساده، اگر فضای رک و تراکم تجهیزات اهمیت زیادی دارد، DL360 به دلیل طراحی 1U می‌تواند جذاب باشد. اگر توسعه Storage و انعطاف بیشتر برای آینده اولویت بالاتری دارد، DL380 با شاسی 2U ارزش بررسی بیشتری خواهد داشت.
HPE ProLiant DL360 برای حسابداری
HPE ProLiant DL360 یک سرور رک‌مونت 1U است. ارتفاع کمتر این خانواده باعث می‌شود بتوان تعداد بیشتری سرور را در فضای مشخصی از رک مستقر کرد؛ موضوعی که در دیتاسنترها و رک‌هایی با محدودیت فضا اهمیت پیدا می‌کند.
برای یک شرکت که قصد دارد نرم‌افزار حسابداری، SQL Server و تعداد محدودی سرویس سازمانی را روی یک سرور اجرا کند، DL360 می‌تواند یکی از گزینه‌های قابل بررسی باشد؛ البته نسل و کانفیگ دقیق آن باید متناسب با Workload انتخاب شود.
مزیت مهم DL360 برای چنین سناریویی، امکان دستیابی به قدرت پردازشی و ظرفیت RAM مناسب در یک Form Factor فشرده است.
برای مثال، اگر یک مجموعه ۲۰ تا ۵۰ کاربر دارد، Database آن در سطح معمول تا متوسط قرار دارد و به تعداد بسیار زیادی Drive نیاز ندارد، الزاماً استفاده از شاسی بزرگ‌تر مزیت محسوسی ایجاد نمی‌کند.
بااین‌حال، باید قبل از خرید به نوع شاسی و Drive Cage همان دستگاه توجه شود. صرف دیدن نام DL360 برای تعیین ظرفیت Storage کافی نیست؛ تعداد و نوع Driveهای قابل نصب می‌تواند با توجه به نسل و پیکربندی شاسی متفاوت باشد.
DL360 زمانی گزینه قابل‌توجهی است که:
– فضای رک محدود باشد؛– نیاز Storage در محدوده قابل مدیریت قرار داشته باشد؛– قدرت پردازشی و RAM مناسب در فضای 1U نیاز باشد؛– برنامه توسعه آینده با ظرفیت شاسی انتخابی سازگار باشد.
HPE ProLiant DL380 برای حسابداری
HPE ProLiant DL380 از شاسی 2U استفاده می‌کند و معمولاً فضای بیشتری برای توسعه سخت‌افزار در اختیار مدیر شبکه قرار می‌دهد.
اگر سرور حسابداری قرار است علاوه بر Database، وظایف دیگری نیز بر عهده داشته باشد یا انتظار می‌رود حجم اطلاعات و نیازهای مجموعه طی چند سال آینده افزایش پیدا کند، انعطاف بالاتر DL380 می‌تواند اهمیت بیشتری پیدا کند.
برای مثال، سازمانی را تصور کنید که اکنون ۵۰ کاربر دارد اما قرار است تعداد کاربران افزایش پیدا کند، Database به‌طور مداوم رشد می‌کند و احتمال دارد در آینده چند سرویس یا ماشین مجازی نیز به زیرساخت اضافه شوند. در چنین شرایطی، توسعه‌پذیری بیشتر می‌تواند ارزش بالاتری از صرفه‌جویی در فضای رک داشته باشد.
DL380 را می‌توان زمانی جدی‌تر بررسی کرد که:
– به تعداد Drive بیشتری نیاز داریم؛– رشد Storage در آینده محتمل است؛– چند Workload روی یک سرور اجرا می‌شوند؛– توسعه سخت‌افزار در سال‌های آینده اهمیت دارد؛– محدودیت 1U بودن شاسی برای مجموعه مزیت خاصی ایجاد نمی‌کند.
البته این به معنای آن نیست که DL380 همیشه انتخاب بهتری برای حسابداری است. برای بسیاری از شرکت‌های کوچک و متوسط، ظرفیت‌های اضافه آن ممکن است هیچ‌گاه استفاده نشوند.
بنابراین خرید DL380 صرفاً به دلیل بزرگ‌تر بودن شاسی یا تصور «قوی‌تر بودن» تصمیم دقیقی نیست.
مقایسه DL360 و DL380 برای نرم‌افزار حسابداری
برای انتخاب میان این دو خانواده ابتدا باید مشخص کنید چه مقدار Storage، چه سطحی از توسعه‌پذیری و چه فضای رکی در اختیار دارید.
معیار
HPE DL360
HPE DL380
Form Factor
1U
2U
فضای اشغال‌شده در رک
کمتر
بیشتر
تراکم استقرار
بالاتر
پایین‌تر نسبت به 1U
انعطاف Storage
مناسب؛ وابسته به شاسی
معمولاً بیشتر
فضای توسعه
محدودتر از 2U
معمولاً بیشتر
مناسب برای
محیط‌های متراکم و کانفیگ‌های جمع‌وجور
محیط‌های نیازمند توسعه بیشتر
استفاده حسابداری
سبک تا سنگین براساس کانفیگ
سبک تا سنگین براساس کانفیگ
بنابراین سؤال «DL360 بهتر است یا DL380؟» به‌تنهایی پاسخ دقیقی ندارد.
اگر فضای رک محدود است و نیاز Storage شما با شاسی DL360 پوشش داده می‌شود، DL360 می‌تواند انتخاب منطقی‌تری باشد. اگر توسعه Storage و انعطاف سخت‌افزاری آینده اهمیت بیشتری دارد، DL380 ارزش بررسی بیشتری خواهد داشت.
مهم‌تر از نام مدل، کانفیگی است که داخل سرور قرار می‌گیرد. یک DL380 با کانفیگ نامناسب الزاماً عملکرد بهتری از یک DL360 با CPU، RAM و Storage متناسب با Workload حسابداری نخواهد داشت.
سرور G9، G10 یا G11 برای حسابداری؟
بعد از انتخاب خانواده سرور، مسئله نسل مطرح می‌شود. در بازار سرور HP، به‌خصوص هنگام بررسی سرورهای استوک، ممکن است میان HPE ProLiant Gen9 ، Gen10 و Gen11 مردد باشید.
نسل جدیدتر معمولاً پلتفرم سخت‌افزاری جدیدتری در اختیار شما قرار می‌دهد، اما این به معنای آن نیست که برای تمام مجموعه‌های حسابداری باید جدیدترین نسل خریداری شود.
بودجه، حجم Workload، مدت زمانی که قرار است از سرور استفاده شود، مسیر ارتقا و قیمت کل کانفیگ باید در کنار نسل سرور بررسی شوند.
چه زمانی HPE Gen9 انتخاب اقتصادی است؟
سرورهای HPE Gen9 همچنان ممکن است در برخی پروژه‌هایی که بودجه محدود مهم‌ترین عامل تصمیم‌گیری است مورد توجه قرار بگیرند.
اگر مجموعه تعداد کاربران محدودی دارد، Workload سبک تا متوسط است و قرار نیست سرویس‌های بسیار سنگین یا زیرساخت گسترده‌ای روی سرور ایجاد شود، یک Gen9 با کانفیگ صحیح می‌تواند از نظر هزینه اولیه قابل بررسی باشد.
برای مثال، در یک مجموعه کوچک حسابداری، ممکن است یک DL360 Gen9 یا DL380 Gen9 با CPU متناسب، RAM کافی و SSD سازمانی بتواند نیاز فعلی را پوشش دهد.
اما قیمت پایین‌تر نباید تنها معیار تصمیم‌گیری باشد.
در زمان خرید Gen9 باید به موارد زیر توجه بیشتری داشت:
– عمر پلتفرم– وضعیت سلامت قطعات– ظرفیت ارتقای آینده– نسل پردازنده و حافظه– دسترسی به قطعات موردنیاز– مصرف انرژی نسبت به پلتفرم‌های جدیدتر– مدت زمانی که قرار است سرور در سازمان باقی بماند
اگر قرار است زیرساخت برای چند سال آینده توسعه قابل‌توجهی داشته باشد، ممکن است صرفه‌جویی اولیه در خرید یک نسل قدیمی‌تر در بلندمدت مزیت کمتری ایجاد کند.
چرا HPE Gen10 می‌تواند گزینه متعادلی باشد؟
برای بسیاری از کسب‌وکارهایی که قصد خرید **سرور HP استوک برای حسابداری** دارند، خانواده Gen10 می‌تواند از نظر تعادل میان توان سخت‌افزاری، قابلیت توسعه و هزینه خرید ارزش بررسی داشته باشد.
این نسل امکان استفاده از خانواده پردازنده‌ها و حافظه متناسب با پلتفرم خود را فراهم می‌کند و می‌توان کانفیگ‌های بسیار متفاوتی روی آن پیاده کرد؛ از سرورهای نسبتاً اقتصادی برای شرکت‌های کوچک تا کانفیگ‌های قدرتمندتر برای Database و Virtualization.
برای مثال، اگر یک شرکت ۳۰ تا ۵۰ کاربر دارد و قصد دارد علاوه بر نرم‌افزار حسابداری، SQL Server و چند سرویس جانبی را نیز اجرا کند، یک DL360 Gen10 یا DL380 Gen10 با کانفیگ اصولی می‌تواند در فهرست گزینه‌ها قرار گیرد.
مزیت مهم در اینجا خود عبارت «Gen10» نیست؛ بلکه امکان ساخت کانفیگی است که بتواند میان هزینه خرید، Performance و قابلیت ارتقا تعادل ایجاد کند.
اگر قصد خرید Gen10 دارید، بهتر است به‌جای پرسیدن «قیمت سرور G10 چقدر است؟» ابتدا این موارد مشخص شوند:
– مدل دقیق CPU– تعداد CPU– ظرفیت و چیدمان RAM– نوع و تعداد SSD/HDD– RAID Controller– نوع شاسی– Power Supply– کارت شبکه– فضای موردنیاز برای توسعه آینده
دو سرور DL380 Gen10 می‌توانند از نظر قیمت و Performance تفاوت بسیار زیادی داشته باشند؛ زیرا نسل و مدل شاسی به‌تنهایی کانفیگ نهایی را مشخص نمی‌کند.
چه زمانی سراغ HPE Gen11 برویم؟
HPE Gen11 پلتفرم جدیدتری نسبت به Gen9 و Gen10 است و برای مجموعه‌هایی که قصد دارند زیرساخت جدیدتری ایجاد کنند و بودجه بیشتری در اختیار دارند، می‌تواند گزینه مناسبی برای بررسی باشد.
در یک سازمان بزرگ‌تر که تعداد کاربران زیاد است، Workloadهای بیشتری روی سرور اجرا می‌شوند یا برنامه توسعه چندساله وجود دارد، استفاده از پلتفرم جدیدتر می‌تواند مزایای بیشتری ایجاد کند.
Gen11 را می‌توان جدی‌تر بررسی کرد اگر:
– بودجه اولیه محدودیت اصلی پروژه نیست؛– زیرساخت برای استفاده بلندمدت طراحی می‌شود؛– Performance بالاتر موردنیاز است؛– ظرفیت توسعه آینده اهمیت زیادی دارد؛– قرار است علاوه بر حسابداری، Workloadهای سازمانی دیگری نیز اجرا شوند.
اما برای یک شرکت ۱۰ کاربره با Database کوچک، خرید Gen11 الزاماً ضروری نیست. اگر یک کانفیگ اقتصادی‌تر تمام نیازهای واقعی مجموعه را پوشش دهد، هزینه بیشتر باید با مزیت قابل‌اندازه‌گیری توجیه شود.
مقایسه G9، G10 و G11 برای سرور حسابداری
معیار
Gen9
Gen10
Gen11
عمر پلتفرم
قدیمی‌تر
میانی
جدیدتر
هزینه خرید
معمولاً اقتصادی‌تر در بازار استوک
متعادل‌تر
معمولاً بالاتر
مناسب برای بودجه محدود
بیشتر
مناسب
کمتر
فضای توسعه بلندمدت
محدودتر نسبت به نسل‌های جدید
مناسب
بیشتر
سناریوی پیشنهادی
پروژه اقتصادی و Workload سبک‌تر
بسیاری از کسب‌وکارهای کوچک و متوسط
زیرساخت جدیدتر و توسعه بلندمدت
نکته مهم
سلامت و عمر قطعات
تعادل هزینه و توان
بررسی توجیه هزینه بالاتر
در نتیجه، اگر هدف اصلی کاهش هزینه خرید است و Workload سنگینی ندارید، Gen9 می‌تواند بررسی شود. اگر به‌دنبال تعادل میان هزینه، Performance و امکان توسعه هستید، Gen10 یکی از گزینه‌هایی است که ارزش مقایسه دارد. Gen11 نیز زمانی جذاب‌تر می‌شود که پلتفرم جدیدتر و برنامه توسعه بلندمدت برای سازمان اهمیت بیشتری داشته باشد.
بااین‌حال، هیچ‌کدام از این نسل‌ها را نباید صرفاً بر اساس نام نسل انتخاب کرد. یک Gen11 با RAM یا Storage نامتناسب می‌تواند انتخاب بدتری از یک Gen10 باشد که دقیقاً براساس Workload مجموعه کانفیگ شده است.
بنابراین هنگام انتخاب بهترین سرور برای حسابداری بهتر است ترتیب تصمیم‌گیری این باشد:
Workload و تعداد کاربران همزمان ← CPU و RAM موردنیاز ← Storage و RAID ← ظرفیت توسعه ← انتخاب DL360 یا DL380 ← انتخاب نسل مناسب با بودجه
با این روش، ابتدا نیاز واقعی مجموعه مشخص می‌شود و سپس سرور متناسب با آن انتخاب خواهد شد؛ نه اینکه ابتدا یک مدل سرور خریداری کنیم و بعد تلاش کنیم نیاز نرم‌افزار حسابداری را با آن تطبیق دهیم.
آیا سرور استوک برای حسابداری مناسب است؟
بله، سرور HP استوک می‌تواند برای اجرای نرم‌افزارهای حسابداری و دیتابیس مناسب باشد؛ به شرط آنکه کانفیگ متناسب با Workload انتخاب شود و سلامت قطعات، Storage، RAID Controller، پاورها و سایر اجزای سرور قبل از خرید بررسی شده باشند.
در واقع، استوک بودن به‌تنهایی مشخص نمی‌کند یک سرور برای حسابداری مناسب است یا خیر. یک سرور استوک سالم با کانفیگ اصولی ممکن است نیاز یک شرکت را به‌خوبی پوشش دهد، درحالی‌که خرید یک سرور جدید با CPU، RAM یا Storage نامتناسب الزاماً نتیجه بهتری ایجاد نمی‌کند.
مزیت مهم سرورهای استوک برای برخی کسب‌وکارها، امکان دستیابی به سخت‌افزار Enterprise با هزینه اولیه کمتر است. این موضوع به‌خصوص برای شرکت‌های کوچک و متوسطی اهمیت دارد که به قابلیت‌هایی مانند ECC Memory، RAID سخت‌افزاری، مدیریت از راه دور، پاور Redundant و امکان ارتقای سخت‌افزار نیاز دارند اما نمی‌خواهند هزینه یک سرور نسل جدید را پرداخت کنند.
بااین‌حال، اطلاعات حسابداری از مهم‌ترین داده‌های یک مجموعه هستند. بنابراین خرید سرور استوک صرفاً بر اساس قیمت پایین، بدون بررسی وضعیت سخت‌افزار، می‌تواند ریسک ایجاد کند.
هنگام خرید سرور HP استوک برای حسابداری چه چیزهایی را بررسی کنیم؟
اگر قصد خرید سرور HP استوک برای حسابداری را دارید، قبل از تصمیم نهایی حداقل موارد زیر را بررسی کنید:
1. سلامت CPU و RAM2. وضعیت SSD و HDD3. مدل و وضعیت RAID Controller4. وضعیت Power Supplyها5. سلامت فن‌ها و سیستم خنک‌کننده6. وضعیت iLO و گزارش‌های سخت‌افزاری7. Firmware و سازگاری قطعات8. امکان ارتقای RAM و Storage9. نوع و تعداد پورت‌های شبکه10. شرایط تست و گارانتی فروشنده
در ادامه مهم‌ترین موارد را دقیق‌تر بررسی می‌کنیم.
سلامت SSD و HDD را جدی بگیرید
در سروری که قرار است Database حسابداری روی آن قرار بگیرد، وضعیت Storage اهمیت زیادی دارد.
در زمان خرید سرور استوک باید نوع Drive، وضعیت سلامت آن و سازگاری با سرور و RAID Controller بررسی شود. صرف اینکه یک SSD هنگام تست اولیه کار می‌کند، برای ارزیابی کامل آن کافی نیست.
همچنین بهتر است Storage مربوط به Database بر اساس Performance و Reliability موردنیاز انتخاب شود و صرفاً ظرفیت بالا معیار خرید نباشد.
برای مثال، استفاده از یک HDD با ظرفیت زیاد الزاماً انتخاب بهتری از چند SSD با ظرفیت کمتر برای یک Database پرتراکنش نیست.
RAID Controller را متناسب با آرایه انتخاب کنید
اگر قرار است Database روی RAID 10 یا آرایه دیگری قرار گیرد، RAID Controller نیز باید با تعداد Drive، نوع Drive و Performance موردنیاز هماهنگ باشد.
وجود RAID Controller به‌تنهایی کافی نیست. مدل کنترلر، قابلیت‌های آن و سازگاری با طراحی Storage باید بررسی شوند.
در سرورهای استوک ممکن است دو دستگاه ظاهراً مشابه با دو RAID Controller متفاوت عرضه شوند؛ بنابراین بهتر است مدل دقیق کنترلر در مشخصات کانفیگ ذکر شود.
Redundant Power Supply چه اهمیتی دارد؟
در یک سیستم حسابداری سازمانی، Downtime می‌تواند فعالیت بخش مالی، فروش یا انبار را مختل کند.
استفاده از دو Power Supply در پیکربندی Redundant می‌تواند در برابر خرابی یکی از پاورها سطح بیشتری از دسترس‌پذیری ایجاد کند؛ البته به شرط آنکه زیرساخت برق نیز به‌درستی طراحی شده باشد.
برای مجموعه‌هایی که نرم‌افزار حسابداری بخش حیاتی عملیات روزانه آن‌هاست، بهتر است علاوه بر Redundant PSU، استفاده از UPS مناسب نیز در طراحی زیرساخت در نظر گرفته شود.
iLO و وضعیت سخت‌افزار را بررسی کنید
یکی از مزایای سرورهای HPE ProLiant، قابلیت مدیریت و پایش از طریق iLO است.
پیش از خرید سرور استوک، بررسی وضعیت سخت‌افزاری و خطاهای ثبت‌شده می‌تواند اطلاعات مفیدی درباره شرایط دستگاه ارائه دهد. پس از راه‌اندازی سرور نیز استفاده از ابزارهای Monitoring و قابلیت‌های مدیریتی سرور کمک می‌کند مشکلات احتمالی زودتر شناسایی شوند.
امکان ارتقا را فراموش نکنید
یکی از اشتباهات رایج این است که سرور فقط براساس نیاز امروز خریداری شود.
فرض کنید در حال حاضر ۲۰ کاربر دارید و ۳۲ گیگابایت RAM برای Workload شما کافی است. اگر طی دو سال آینده تعداد کاربران به ۴۰ یا ۵۰ نفر برسد، آیا سرور امکان افزایش RAM، Storage یا Network را دارد؟
سروری که امروز ارزان‌تر خریداری می‌شود اما برای کوچک‌ترین توسعه به تعویض اساسی قطعات یا کل دستگاه نیاز دارد، ممکن است در بلندمدت انتخاب اقتصادی نباشد.
اشتباهات رایج هنگام خرید سرور برای حسابداری
انتخاب سرور مناسب حسابداری فقط به پیدا کردن یک مدل HP و نصب نرم‌افزار روی آن محدود نمی‌شود. بعضی اشتباهات در مرحله انتخاب کانفیگ می‌توانند باعث شوند سروری که روی کاغذ قدرتمند به نظر می‌رسد، در استفاده واقعی عملکرد مورد انتظار را ارائه ندهد.
1. انتخاب سرور فقط براساس تعداد کاربران
اینکه یک شرکت ۳۰ کاربر دارد اطلاعات مفیدی است، اما برای انتخاب کانفیگ کافی نیست.
باید مشخص شود چند نفر به‌صورت همزمان فعال هستند، حجم Database چقدر است، چه تعداد تراکنش انجام می‌شود و کاربران چه نوع عملیاتی روی سیستم انجام می‌دهند.
۳۰ کاربر سبک ممکن است منابع کمتری از ۱۵ کاربر با Queryها و گزارش‌های سنگین مصرف کنند.
بنابراین تعداد کاربران را نقطه شروع تحلیل بدانید، نه پاسخ نهایی.
2. خرید CPU فقط براساس تعداد Core
پردازنده‌ای با Core بیشتر همیشه سریع‌ترین انتخاب برای نرم‌افزار حسابداری نیست.
نوع Workload، فرکانس CPU، تعداد کاربران همزمان و نحوه استفاده نرم‌افزار از پردازنده باید در کنار Core Count بررسی شوند.
خرید یک CPU گران‌قیمت با تعداد زیادی Core بدون شناخت Workload می‌تواند فقط هزینه کانفیگ را افزایش دهد، بدون اینکه به همان نسبت Performance بیشتری ایجاد کند.
3. انتخاب RAM ناکافی برای Database
اگر RAM سرور کمتر از نیاز واقعی باشد، سیستم و Database ممکن است بیشتر به Storage وابسته شوند و Performance تحت فشار قرار گیرد.
در مقابل، نصب حجم بسیار زیادی RAM بدون اینکه Workload به آن نیاز داشته باشد نیز هزینه غیرضروری ایجاد می‌کند.
به همین دلیل بهتر است مقدار RAM با توجه به حجم Database، تعداد کاربران، سرویس‌های فعال و امکان توسعه آینده تعیین شود.
4. استفاده از Storage کند برای دیتابیس
ممکن است سروری CPU قدرتمند و RAM زیادی داشته باشد، اما Database روی Storage نامناسب قرار گرفته باشد.
در این حالت Storage می‌تواند به گلوگاه اصلی سیستم تبدیل شود.
برای Workloadهای دیتابیسی، فقط ظرفیت Drive مهم نیست؛ **IOPS، Latency، نوع Drive و معماری RAID** نیز باید بررسی شوند.
به همین دلیل در بسیاری از سناریوهای حسابداری، استفاده از Enterprise SSD برای Database ارزش بررسی دارد.
5. انتخاب RAID بدون توجه به Workload
RAID را نباید صرفاً براساس بیشترین ظرفیت قابل استفاده انتخاب کرد.
برای مثال، RAID 5 می‌تواند ظرفیت قابل استفاده بیشتری ارائه دهد، اما در Workloadهای Write-intensive باید هزینه Parity و شرایط Rebuild نیز در نظر گرفته شود.
در مقابل، RAID 10 ظرفیت بیشتری را صرف Redundancy می‌کند اما می‌تواند برای بسیاری از Workloadهای دیتابیسی پرتراکنش گزینه مناسبی باشد.
انتخاب RAID باید براساس Performance، ظرفیت، Redundancy و بودجه انجام شود.
6. تصور اینکه RAID همان Backup است
یکی از مهم‌ترین اشتباهات در زیرساخت حسابداری این است که تصور کنیم چون Driveها RAID شده‌اند، دیگر نیازی به Backup نداریم.
RAID جایگزین Backup نیست.
اگر یک Drive خراب شود، برخی ساختارهای RAID می‌توانند به حفظ دسترس‌پذیری کمک کنند؛ اما RAID الزاماً شما را در برابر حذف اشتباه اطلاعات، خرابی منطقی Database، باج‌افزار یا سایر حوادث محافظت نمی‌کند.
برای اطلاعات مالی باید Backup جداگانه و قابل بازیابی طراحی شود و فرآیند Restore نیز به‌صورت دوره‌ای آزمایش شود.
7. خرید سرور بدون در نظر گرفتن رشد آینده
کانفیگی که دقیقاً نیاز امروز را پوشش می‌دهد ممکن است خیلی زود محدود شود.
اگر تعداد کاربران، حجم Database یا تعداد سرویس‌ها در حال افزایش است، بهتر است مقداری Headroom منطقی برای توسعه در نظر گرفته شود.
البته Headroom با Overprovisioning تفاوت دارد. هدف این نیست که برای ۱۰ کاربر، سروری مناسب صدها کاربر خریداری کنیم؛ بلکه باید مسیر ارتقای منطقی وجود داشته باشد.
8. اجرای تعداد زیادی سرویس روی یک کانفیگ ضعیف
گاهی مجموعه یک سرور خریداری می‌کند و به‌مرور سرویس‌های مختلفی به آن اضافه می‌شود:
SQL Server، نرم‌افزار حسابداری، File Server، Domain Controller، Backup Software و چند Virtual Machine.
اگر منابع این سرویس‌ها از ابتدا محاسبه نشده باشند، سرور ممکن است خیلی زود با کمبود CPU، RAM یا I/O مواجه شود.
پیش از خرید باید مشخص شود **سرور دقیقاً قرار است میزبان چه سرویس‌هایی باشد.**
9. بی‌توجهی به Power Redundancy و UPS
Performance تنها معیار یک سرور مناسب نیست؛ Availability نیز اهمیت دارد.
اگر نرم‌افزار حسابداری برای فعالیت روزانه شرکت حیاتی است، خرابی Power Supply یا مشکل برق می‌تواند باعث توقف کار کاربران شود.
بنابراین استفاده از Redundant PSU و UPS متناسب با زیرساخت می‌تواند بخشی از طراحی صحیح سیستم باشد.
10. خرید سرور بسیار قوی بدون نیاز واقعی
آخرین اشتباه دقیقاً در نقطه مقابل خرید کانفیگ ضعیف قرار دارد: Overkill
برای یک مجموعه ۱۰ کاربره با Database کوچک، الزاماً نیازی به دو پردازنده رده‌بالا، چندصد گیگابایت RAM و تعداد زیادی SSD وجود ندارد.
بودجه‌ای که بدون نیاز واقعی صرف افزایش CPU و RAM می‌شود، شاید بهتر باشد برای Storage مناسب، Backup، UPS، شبکه یا سایر بخش‌های زیرساخت هزینه شود.
بنابراین بهترین سرور حسابداری الزاماً گران‌ترین سرور نیست؛ بلکه سروری است که **با کمترین هزینه غیرضروری، Performance، پایداری و ظرفیت توسعه موردنیاز مجموعه را تأمین کند.**
قبل از خرید سرور حسابداری این 7 سؤال را پاسخ دهید
اگر تا اینجا بین چند کانفیگ مختلف مردد هستید، قبل از بررسی قیمت یا انتخاب مدل سرور، هفت سؤال زیر را پاسخ دهید. پاسخ به این سؤال‌ها کمک می‌کند مشخص شود واقعاً به چه مقدار CPU، RAM و Storage نیاز دارید و آیا باید از ابتدا فضای بیشتری برای توسعه در نظر بگیرید.
1. چند کاربر از نرم‌افزار حسابداری استفاده می‌کنند؟
اول تعداد کل کاربران را مشخص کنید. ۱۰، ۲۰، ۳۰، ۵۰ یا نزدیک به ۱۰۰ کاربر؟
این عدد اولین معیار برای تخمین سطح کانفیگ است، اما نباید به‌تنهایی مبنای خرید قرار گیرد.
2. چند کاربر به‌صورت همزمان متصل می‌شوند؟
این سؤال حتی از تعداد کل کاربران مهم‌تر است.
اگر ۵۰ حساب کاربری دارید اما حداکثر ۱۵ نفر به‌صورت همزمان از نرم‌افزار استفاده می‌کنند، Workload با شرکتی که ۴۰ تا ۵۰ کاربر همزمان فعال دارد یکسان نیست.
بنابراین بهتر است تعداد Concurrent Userها را در **ساعات اوج کاری** مشخص کنید.
3. از چه نرم‌افزار حسابداری و Database استفاده می‌کنید؟
نام و نسخه نرم‌افزار، Database Engine و الزامات اعلام‌شده توسط سازنده باید مشخص باشند.
اگر نرم‌افزار از SQL Server استفاده می‌کند، نسخه SQL Server و نحوه استفاده از Database نیز می‌تواند روی طراحی منابع اثر بگذارد.
در این مرحله بهتر است Requirementهای رسمی نرم‌افزار نیز بررسی شوند تا کانفیگ پیشنهادی با محدودیت‌ها یا نیازهای نرم‌افزاری تضاد نداشته باشد.
4. حجم فعلی دیتابیس چقدر است؟
ظرفیت Database فعلی یکی از داده‌های مهم برای طراحی Storage است.
اما فقط حجم امروز را یادداشت نکنید. اگر اطلاعات چند سال گذشته در دسترس است، میزان رشد Database را نیز بررسی کنید.
برای مثال، اگر Database طی یک سال از ۲۰۰ به ۳۵۰ گیگابایت رسیده، انتخاب Storage با تنها چند گیگابایت فضای آزاد تصمیم مناسبی برای سال‌های آینده نخواهد بود.
5. دیتابیس و تعداد کاربران در آینده چقدر رشد می‌کنند؟
سرور معمولاً برای چند ماه خریداری نمی‌شود. بنابراین باید دید طی دو یا سه سال آینده چه تغییری در کسب‌وکار ایجاد خواهد شد.
آیا شعبه جدید اضافه می‌شود؟
تعداد کاربران افزایش پیدا می‌کند؟
حجم تراکنش‌ها بیشتر خواهد شد؟
نرم‌افزارهای دیگری روی سرور قرار می‌گیرند؟
اگر پاسخ مثبت است، کانفیگ باید امکان ارتقا داشته باشد.
6. چه سرویس‌های دیگری روی سرور اجرا خواهند شد؟
قبل از خرید، فهرست کامل سرویس‌ها را مشخص کنید.
ممکن است سرور علاوه بر نرم‌افزار حسابداری میزبان SQL Server، File Server، Domain Controller یا ماشین‌های مجازی باشد. هرکدام از این سرویس‌ها بخشی از CPU، RAM، Storage و Network را مصرف می‌کنند.
بنابراین اگر سرور قرار است چندمنظوره باشد، کانفیگ باید براساس مجموع Workloadها طراحی شود.
7. بودجه شما چقدر است و چه مقدار توسعه نیاز دارید؟
بودجه اهمیت دارد، اما بهتر است به‌جای انتخاب ارزان‌ترین یا گران‌ترین سرور، هزینه را در برابر نیاز واقعی قرار دهید.
برای مثال، ممکن است به‌جای خرید یک نسل جدید با کانفیگ حداقلی، یک سرور استوک نسل مناسب با RAM، SSD و RAID بهتر برای Workload شما انتخاب قابل‌بررسی‌تری باشد. در مقابل، اگر زیرساخت برای استفاده طولانی‌مدت و توسعه گسترده طراحی می‌شود، سرمایه‌گذاری روی پلتفرم جدیدتر می‌تواند منطقی باشد.
در نهایت باید میان چهار عامل تعادل برقرار شود:Performance + پایداری + قابلیت ارتقا + بودجه
چگونه کانفیگ دقیق سرور حسابداری را انتخاب کنیم؟
برای انتخاب کانفیگ دقیق، بهتر است از خرید بر اساس نام مدل شروع نکنید.
اینکه ابتدا تصمیم بگیرید «DL380 می‌خواهم» یا «حتماً G11 می‌خرم» و سپس قطعات را انتخاب کنید، همیشه بهترین مسیر نیست. ابتدا Workload را مشخص کنید و سپس پلتفرمی را پیدا کنید که بتواند آن Workload را با هزینه منطقی اجرا کند.
مسیر انتخاب را می‌توان به شکل زیر خلاصه کرد:
تعداد کاربران → کاربران همزمان → نرم‌افزار و Database → حجم و رشد اطلاعات → CPU و RAM → Storage و RAID → توسعه آینده → انتخاب نسل و مدل سرور
مرحله اول: تعداد کاربران همزمان را مشخص کنید
اگر ۳۰ کاربر دارید اما تنها ۱۲ نفر همزمان فعال هستند، این عدد را در تحلیل Workload لحاظ کنید.
اگر تقریباً تمام کاربران به‌صورت همزمان فعال هستند، سناریو را براساس ساعات اوج مصرف طراحی کنید.
مرحله دوم: Workload نرم‌افزار و Database را بررسی کنید
مشخص کنید کاربران چه کاری انجام می‌دهند.
آیا بیشتر فعالیت آن‌ها ثبت ساده اطلاعات است یا گزارش‌های پیچیده و پردازش‌های سنگین نیز انجام می‌شود؟
هرچه Database پرتراکنش‌تر باشد، اهمیت CPU و به‌خصوص Storage مناسب بیشتر می‌شود.
مرحله سوم: RAM را براساس نیاز فعلی و آینده انتخاب کنید
RAM باید برای سیستم‌عامل، Database و سایر سرویس‌ها ظرفیت کافی داشته باشد.
اما تمام ظرفیت سرور را از روز اول پر نکنید. اگر احتمال رشد وجود دارد، امکان اضافه کردن RAM در آینده یک مزیت مهم محسوب می‌شود.
مرحله چهارم: Storage و RAID را طراحی کنید
ظرفیت تنها معیار نیست.
برای Database باید Performance، IOPS، Latency، Redundancy و رشد آینده در کنار یکدیگر بررسی شوند.
در Workloadهای دیتابیسی پرتراکنش، Enterprise SSD و RAID 10 می‌توانند از گزینه‌های قابل بررسی باشند؛ درحالی‌که برای سیستم‌عامل یا سناریوهای سبک‌تر ممکن است معماری متفاوتی کافی باشد.
مرحله پنجم: مدل و نسل سرور را انتخاب کنید
حالا می‌توان بررسی کرد که کانفیگ موردنظر روی DL360 یا DL380 و روی کدام نسل بهتر پیاده می‌شود.
برای مثال، اگر به Storage گسترده نیاز ندارید و فضای رک اهمیت دارد، DL360 می‌تواند گزینه مناسبی باشد. اگر توسعه Storage و انعطاف بیشتر اولویت دارد، DL380 ارزش بررسی بیشتری خواهد داشت.
در مرحله انتخاب نسل نیز بودجه و طول عمر مورد انتظار زیرساخت تعیین‌کننده هستند.
مرحله ششم: Backup و Availability را جزئی از کانفیگ بدانید
سرور حسابداری فقط مجموعه‌ای از CPU و RAM نیست.
اطلاعات مالی معمولاً جزو داده‌های حیاتی کسب‌وکار هستند؛ بنابراین Backup، امکان Restore، UPS، Redundant PSU و Monitoring باید از ابتدا در طراحی زیرساخت دیده شوند، نه اینکه بعد از خرید سرور به آن‌ها فکر شود.
مرحله هفتم: قبل از خرید، کانفیگ را براساس سناریوی واقعی بررسی کنید
اگر بین چند کانفیگ مردد هستید، به‌جای مقایسه صرف مشخصات فنی، هر کانفیگ را با سناریوی واقعی مجموعه تطبیق دهید.
برای مثال:
۳۰ کاربر + ۲۰ کاربر همزمان + SQL Server + Database متوسط + رشد سالانه اطلاعات
اطلاعات بسیار مفیدتری نسبت به جمله «یک سرور برای ۳۰ کاربر می‌خواهم» در اختیار کارشناس قرار می‌دهد.
اگر تعداد کاربران، نوع کاربری و نیاز مجموعه خود را می‌دانید، می‌توانید به‌جای انتخاب دستی تک‌تک قطعات، از مسیر **ساخت کانفیگ سرور HP** استفاده کنید و کانفیگ را متناسب با سناریوی حسابداری مجموعه بررسی کنید.
ساخت کانفیگ سرور HP ← همین الان کانفیگ مورد نیازتو بساز
کلام آخر؛ بالاخره چه سروری برای حسابداری بخریم؟
اگر بخواهیم تمام این راهنما را در یک اصل خلاصه کنیم، سرور مناسب حسابداری سروری نیست که بیشترین CPU یا RAM را داشته باشد؛ بلکه سروری است که منابع آن با تعداد کاربران همزمان، حجم Database و نوع Workload متناسب باشد.
برای مجموعه‌های کوچک با حدود ۱۰ کاربر، معمولاً می‌توان بررسی را از کانفیگ‌های اقتصادی‌تر با حدود ۳۲ گیگابایت RAM و SSD مناسب آغاز کرد. با رسیدن به ۲۰ یا ۳۰ کاربر، تعداد کاربران همزمان و فشار Database اهمیت بیشتری پیدا می‌کند و ممکن است ۶۴ گیگابایت RAM، Enterprise SSD و معماری Storage قدرتمندتر موردنیاز باشد.
در مجموعه‌های ۵۰ کاربره، باید علاوه بر CPU و RAM، به Performance Storage، RAID Controller و توسعه آینده توجه بیشتری داشت. برای محیط‌های نزدیک به ۱۰۰ کاربر نیز دیگر انتخاب صرفاً براساس یک جدول عمومی توصیه نمی‌شود و بهتر است Workload واقعی، Database و ساعات اوج مصرف بررسی شوند.
در انتخاب مدل سرور نیز DL360 یا DL380 بودن به‌تنهایی تعیین‌کننده Performance نیست. DL360 برای سناریوهایی که تراکم رک و Form Factor کوچک‌تر اهمیت دارد گزینه قابل‌بررسی است؛ درحالی‌که DL380 معمولاً انعطاف بیشتری برای توسعه سخت‌افزاری و Storage فراهم می‌کند.
در مورد نسل سرور نیز همین اصل برقرار است. Gen9 می‌تواند برای برخی پروژه‌های اقتصادی بررسی شود، Gen10 در بسیاری از سناریوها تعادل مناسبی میان هزینه و توان سخت‌افزاری ایجاد می‌کند و Gen11 برای مجموعه‌هایی که پلتفرم جدیدتر و مسیر توسعه بلندمدت می‌خواهند، ارزش بررسی دارد.
در نهایت قبل از خرید سرور حسابداری این پنج مورد را روی کاغذ بنویسید:
تعداد کاربران همزمان، نرم‌افزار و Database، حجم اطلاعات، سرویس‌های جانبی و رشد دو تا سه سال آینده.با مشخص شدن این اطلاعات، انتخاب CPU، RAM، SSD، RAID و حتی مدل سرور بسیار دقیق‌تر خواهد شد و احتمال اینکه برای سخت‌افزار غیرضروری هزینه کنید یا چند ماه بعد با کمبود منابع مواجه شوید، کاهش پیدا می‌کند.
تعداد کاربران
CPU
RAM
Storage
RAID پیشنهادی
سطح استفاده
تا 10
Entry/Mid-range Xeon
32GB
SSD
RAID 1
سبک
10 تا 20
Xeon مناسب دیتابیس
32–64GB
Enterprise SSD
RAID 1/10
سبک تا متوسط
20 تا 30
Xeon Mid-range
64GB
Enterprise SSD
RAID 10
متوسط
30 تا 50
Xeon با توان پردازشی بالاتر
64–128GB
چند SSD
RAID 10
متوسط تا سنگین
50 تا 100
کانفیگ High-performance متناسب با Workload
128GB+
Enterprise SSD Array
RAID 10
سنگین
سوالات متداول درباره سرور مناسب حسابداری
برای 10 کاربر چه سروری مناسب حسابداری است؟
برای یک مجموعه حدود ۱۰ کاربره با دیتابیس کوچک تا متوسط، می‌توان بررسی را از یک پردازنده Xeon متناسب با Workload، حدود ۳۲ گیگابایت RAM و Enterprise SSD آغاز کرد. در سناریوهای ساده، RAID 1 نیز قابل بررسی است. بااین‌حال، نوع نرم‌افزار، تعداد کاربران همزمان و حجم دیتابیس باید قبل از انتخاب نهایی مشخص شوند.
برای 20 کاربر چقدر RAM نیاز داریم؟
برای حدود ۲۰ کاربر، ۳۲ تا ۶۴ گیگابایت RAM می‌تواند نقطه شروع مناسبی برای بررسی باشد. اگر تعداد کاربران همزمان زیاد است، دیتابیس حجم بالایی دارد یا سرویس‌های دیگری نیز روی سرور اجرا می‌شوند، نیاز به RAM می‌تواند افزایش پیدا کند.
برای 30 کاربر چه کانفیگ سروری مناسب است؟
برای یک محیط متعارف ۳۰ کاربره می‌توان کانفیگی با **Xeon رده متوسط، حدود ۶۴ گیگابایت RAM، Enterprise SSD و RAID متناسب با Workload** را بررسی کرد. در دیتابیس‌های دارای I/O بالاتر، RAID 10 نیز یکی از گزینه‌های قابل بررسی است. تعداد کاربران همزمان و حجم دیتابیس باید در انتخاب نهایی لحاظ شوند.
برای 50 کاربر چه سرور حسابداری بخریم؟
برای حدود ۵۰ کاربر می‌توان بررسی را از یک Xeon رده متوسط رو به بالا، ۶۴ تا ۱۲۸ گیگابایت RAM و چند Enterprise SSD آغاز کرد. اگر دیتابیس پرتراکنش است، Performance Storage، RAID Controller و قابلیت ارتقای سرور اهمیت بیشتری پیدا می‌کنند.
برای 100 کاربر چه سروری مناسب است؟
برای حدود ۱۰۰ کاربر بهتر است کانفیگ براساس Workload واقعی طراحی شود. ۱۲۸ گیگابایت RAM یا بیشتر می‌تواند نقطه شروع بررسی باشد، اما تعداد کاربران همزمان، حجم دیتابیس، گزارش‌های سنگین، سرویس‌های جانبی و میزان تراکنش‌ها باید پیش از انتخاب CPU و Storage مشخص شوند.
برای نرم‌افزار حسابداری چقدر RAM لازم است؟
مقدار RAM به تعداد کاربران همزمان، حجم دیتابیس، Database Engine و سرویس‌های دیگری که روی سرور اجرا می‌شوند بستگی دارد. برای محیط‌های کوچک ممکن است ۳۲ گیگابایت کافی باشد، درحالی‌که مجموعه‌های متوسط و بزرگ می‌توانند به ۶۴، ۱۲۸ گیگابایت یا بیشتر نیاز داشته باشند.
برای حسابداری SSD بهتر است یا HDD؟
برای Database حسابداری، Enterprise SSD معمولاً به دلیل IOPS بالاتر و Latency کمتر گزینه مناسب‌تری برای بررسی است. HDD همچنان می‌تواند برای آرشیو، Backup یا اطلاعاتی که حساسیت کمتری به سرعت دارند مورد استفاده قرار گیرد.
RAID مناسب سرور حسابداری چیست؟
RAID مناسب به نوع Workload بستگی دارد. RAID 1 می‌تواند برای سیستم‌عامل و سناریوهای سبک مناسب باشد و RAID 10 در بسیاری از Workloadهای دیتابیسی پرتراکنش به دلیل ترکیب Performance و Redundancy مورد توجه قرار می‌گیرد. RAID جایگزین Backup نیست.
DL360 برای حسابداری بهتر است یا DL380؟
هیچ‌کدام به‌صورت مطلق بهتر نیستند. DL360 با Form Factor یک یونیت برای محیط‌هایی که فضای رک اهمیت دارد مناسب است، درحالی‌که DL380 با شاسی دو یونیت معمولاً انعطاف بیشتری برای Storage و توسعه سخت‌افزاری فراهم می‌کند. انتخاب نهایی باید براساس کانفیگ و برنامه توسعه مجموعه انجام شود.
G9، G10 یا G11 برای سرور حسابداری مناسب‌تر است؟
انتخاب نسل به بودجه و Workload بستگی دارد. Gen9 می‌تواند برای برخی پروژه‌های اقتصادی بررسی شود، Gen10 در بسیاری از سناریوها تعادل مناسبی میان هزینه و توان سخت‌افزاری ایجاد می‌کند و Gen11 برای مجموعه‌هایی که پلتفرم جدیدتر و برنامه توسعه بلندمدت دارند، قابل بررسی است.
آیا سرور HP استوک برای نرم‌افزار حسابداری مناسب است؟
بله. یک سرور HP استوک در صورت سلامت سخت‌افزار و انتخاب کانفیگ صحیح می‌تواند برای نرم‌افزار حسابداری مناسب باشد. پیش از خرید باید سلامت CPU، RAM، SSD/HDD، RAID Controller، پاورها، iLO، قابلیت ارتقا و شرایط تست و گارانتی بررسی شود.
آیا برای سرور حسابداری حتماً به دو CPU نیاز داریم؟
خیر. تعداد CPU باید براساس Workload انتخاب شود و دو پردازنده بودن سرور به‌تنهایی به معنای Performance بهتر برای نرم‌افزار حسابداری نیست. در بسیاری از محیط‌های کوچک و متوسط، یک CPU مناسب می‌تواند نیاز سیستم را تأمین کند و امکان ارتقای آینده نیز حفظ شود.
آیا RAID می‌تواند جای Backup اطلاعات حسابداری را بگیرد؟
خیر. RAID و Backup دو هدف متفاوت دارند. RAID برای افزایش دسترس‌پذیری و تحمل برخی خرابی‌های Drive استفاده می‌شود، اما از اطلاعات در برابر مواردی مانند حذف اشتباه، خرابی منطقی دیتابیس یا باج‌افزار به‌طور کامل محافظت نمی‌کند. اطلاعات مالی باید Backup مستقل و قابل بازیابی داشته باشند.
از انتشار این مطلب تشکر می‌کنم. پرداختن به چنین موضوعاتی با زبان ساده و قابل فهم برای خوانندگان ارزشمند است. ترتیب ارائه مطالب را دوست داشتم و مطالعه آن باعث شد برای بررسی جزئیات بیشتر کنجکاو شوم. منتظر نوشته‌های بعدی شما هستم.
چند اطلاعات کوتاه ثبت کنید، نوع استفاده را مشخص کنید و کارشناس موردنظر را انتخاب کنید. اگر داخل کانفیگساز انتخابی داشته باشید، همان مشخصات هم همراه درخواست ارسال می‌شود.
مشاوره تخصصی خرید سرور HPنیازتان را ثبت کنید و در مرحله انتخاب کارشناس، مشاور موردنظر را انتخاب کنید.
آنلاین
ثبت درخواست در کمتر از ۱ دقیقهراهنمایی مستقیم توسط کارشناس سرور
نکته: این جدول برای Shortlist اولیه است. اگر مثلاً ۵۰ حساب کاربری در نرم‌افزار تعریف شده اما تنها ۱۵ نفر همزمان از سیستم استفاده می‌کنند، نیاز سخت‌افزاری می‌تواند با شرکتی که ۵۰ کاربر همزمان دارد کاملاً متفاوت باشد.
از انتشار این مطلب تشکر می‌کنم. پرداختن به چنین موضوعاتی با زبان ساده و قابل فهم برای خوانندگان ارزشمند است. ترتیب ارائه مطالب را دوست داشتم و مطالعه آن باعث شد برای بررسی جزئیات بیشتر کنجکاو شوم. منتظر نوشته‌های بعدی شما هستم.