یکی از رایج‌ترین واکنش‌ها به کندی یک سرور مجازی این است: «چند هسته و چند گیگ رم دیگر بدهیم.» گاهی جواب می‌دهد، اما اغلب نه؛ و گاهی حتی اوضاع را بدتر می‌کند. تخصیص درست منابع یعنی هر ماشین به اندازه نیاز واقعی‌اش منابع بگیرد و میزبان هم برای همه ماشین‌ها و روزهای اوج بار جا داشته باشد.
پردازنده: بیشتر لزوماً بهتر نیست
هسته‌های مجازی (vCPU) روی هسته‌های فیزیکی میزبان زمان‌بندی می‌شوند. اینکه مجموع vCPUهای ماشین‌ها از هسته‌های فیزیکی بیشتر باشد (Overcommit) طبیعی است، چون همه ماشین‌ها هم‌زمان تمام توان را نمی‌خواهند. اما دو نکته را فراموش نکنید:
- ماشینی که vCPU زیادی دارد، ممکن است برای گرفتن نوبت پردازش منتظر بماند و این انتظار در شلوغی میزبان بیشتر هم می‌شود. با تعداد کم شروع کنید و بر اساس پایش افزایش دهید.
- تعداد vCPU یک ماشین را از هسته‌های یک پردازنده فیزیکی (یک گره NUMA) بیشتر نکنید، مگر اینکه واقعاً لازم باشد و بستر شما آن را درست مدیریت کند.
برخی نرم‌افزارها، مثل ویندوز سرور و SQL Server، بر اساس تعداد هسته لایسنس می‌شوند؛ هسته اضافه ممکن است هزینه لایسنس هم داشته باشد.
حافظه: نه خساست، نه ولخرجی
کمبود رم باعث می‌شود سیستم‌عامل از دیسک به‌جای حافظه استفاده کند و همه‌چیز به‌شدت کند شود. از طرف دیگر، رم اضافه‌ای که ماشین استفاده نمی‌کند، از ظرفیت میزبان کم می‌کند.
- برای سرورهای دیتابیس و سرویس‌های حساس، رم را ثابت و تضمین‌شده تخصیص دهید و روی Overcommit حافظه حساب نکنید.
- قابلیت‌هایی مثل Dynamic Memory در Hyper-V یا Ballooning در Proxmox و VMware برای ماشین‌های کم‌اهمیت‌تر مفیدند، اما همه برنامه‌ها با تغییر حافظه سازگار نیستند.
- در SQL Server سقف حافظه (
max server memory) را تنظیم کنید تا برای سیستم‌عامل جا بماند.
دیسک: سرعت مهم‌تر از ظرفیت
کندی بسیاری از سرورهای مجازی از دیسک است، نه پردازنده. ده ماشین روی یک آرایه کند، همه با هم کند می‌شوند.
- نوع تخصیص: دیسک Thin فقط به اندازه داده واقعی فضا می‌گیرد و انعطاف‌پذیر است؛ اما اگر مجموع دیسک‌های Thin از فضای واقعی بیشتر باشد و ذخیره‌ساز پر شود، ماشین‌ها متوقف می‌شوند. اگر از Thin استفاده می‌کنید، فضای آزاد را جدی پایش کنید.
- جداسازی: برای سرورهای دیتابیس، دیسک سیستم‌عامل، داده و لاگ را جدا کنید تا مدیریت ساده‌تر شود و در صورت نیاز هر کدام روی ذخیره‌ساز مناسب خودش قرار گیرد.
- کنترلر و درایور مناسب: از کنترلرهای پاراویرچوال، مثل VirtIO SCSI در Proxmox یا PVSCSI در VMware، به‌جای کنترلرهای شبیه‌سازی‌شده قدیمی استفاده کنید.
پیش از افزایش منابع، ببینید گلوگاه واقعی کجاست. پردازنده‌ای که مداوم در سقف است، رمی که کم آمده و دیسکی که تأخیرش بالاست، هر کدام راه‌حل متفاوتی دارند.
ظرفیت میزبان و روزهای اوج
مجموع منابع تخصیص‌یافته را با ظرفیت میزبان مقایسه کنید و برای رشد و اوج بار، مثلاً پایان ماه یا بستن حساب‌ها در نرم‌افزار مالی، جا بگذارید. اگر چند میزبان در خوشه دارید، ظرفیت باید طوری باشد که با خاموش شدن یک میزبان، بقیه بار را تحمل کنند. خود میزبان هم برای سیستم‌عامل و سرویس‌هایش، مثل ZFS یا Ceph در Proxmox، به رم نیاز دارد.
چک‌لیست
- منابع هر ماشین بر اساس پایش واقعی تعیین شده است، نه حدس.
- ماشین‌ها vCPU بیش از نیاز ندارند.
- سرورهای دیتابیس رم تضمین‌شده و سقف حافظه تنظیم‌شده دارند.
- فضای آزاد ذخیره‌ساز با وجود دیسک‌های Thin پایش می‌شود.
- از کنترلرها و درایورهای پاراویرچوال استفاده می‌شود.
- ظرفیت کافی برای خرابی یک میزبان و اوج بار وجود دارد.
تخصیص منابع کاری یک‌باره نیست و با رشد سرویس‌ها باید بازبینی شود. کارشناسان ITPlus724 می‌توانند منابع ماشین‌های مجازی و میزبان‌های شما را بررسی و برای کارایی بهتر تنظیم کنند.