اگر بخواهیم چند ماشین مجازی را روی یک سرور فیزیکی اجرا کنیم، به لایهای نیاز داریم که منابع سختافزاری سرور را میان آنها تقسیم کند، عملکرد هر ماشین را زیر نظر بگیرد و مانع تداخل سیستمعاملها با یکدیگر شود. این لایه همان Hypervisor یا هایپروایزر است.
Hypervisor یکی از اجزای اصلی زیرساخت مجازی محسوب میشود؛ اما وظیفه آن فقط ساخت ماشین مجازی نیست. مدیریت پردازنده، حافظه، فضای ذخیرهسازی، شبکه، کنترل دسترسی، جداسازی ماشینها و هماهنگی با قابلیتهای سختافزاری نیز بخشی از مسئولیتهای آن است.
در این مقاله میخواهیم ببینیم Hypervisor چیست، چگونه کار میکند، چه تفاوتی میان هایپروایزرهای Type 1 و Type 2 وجود دارد و هنگام انتخاب میان VMware ESX/ESXi، Microsoft Hyper-V، KVM، Xen و پلتفرمهایی مانند Proxmox VE باید چه معیارهایی را بررسی کنیم.
اگر هنوز با مفاهیم پایه این حوزه آشنا نیستید، پیشنهاد میکنیم ابتدا مقاله مجازیسازی چیست؟ را مطالعه کنید.
Hypervisor چیست؟
Hypervisor نرمافزار یا لایهای سیستمی است که امکان ساخت و اجرای چند ماشین مجازی مستقل روی یک سختافزار فیزیکی را فراهم میکند. این لایه میان سختافزار و ماشینهای مجازی قرار میگیرد و منابع فیزیکی سرور را به منابع مجازی قابل استفاده برای هر ماشین تبدیل میکند.
در یک سرور فیزیکی معمولاً منابعی مانند موارد زیر وجود دارند:
- پردازنده یا CPU
- حافظه RAM
- دیسکها و کنترلرهای ذخیرهسازی
- کارتهای شبکه
- کارت گرافیک و شتابدهندهها
- درگاهها و تجهیزات جانبی
Hypervisor این منابع را شناسایی میکند و بر اساس تنظیمات هر ماشین مجازی، بخشی از آنها را در قالب منابع مجازی در اختیار سیستمعامل مهمان قرار میدهد. برای مثال، یک ماشین مجازی ممکن است ۴ پردازنده مجازی، ۱۶ گیگابایت RAM، یک دیسک مجازی ۱۰۰ گیگابایتی و یک کارت شبکه مجازی داشته باشد.
سیستمعامل نصبشده در ماشین مجازی معمولاً تصور میکند روی یک سیستم واقعی اجرا شده است؛ درحالیکه تجهیزات مشاهدهشده توسط آن، نسخههای مجازیشده یا شبیهسازیشده منابع فیزیکی هستند.
ارتباط Hypervisor با ماشین مجازی
ماشین مجازی یا Virtual Machine محیطی نرمافزاری است که رفتار یک کامپیوتر مستقل را شبیهسازی میکند. هر ماشین مجازی میتواند سیستمعامل، نرمافزارها، تنظیمات شبکه و فضای ذخیرهسازی مخصوص خود را داشته باشد.
Hypervisor بستر اجرای این ماشینها را فراهم میکند. بدون وجود آن، ماشین مجازی نمیتواند بهشکل مدیریتشده از CPU، RAM، Storage و Network سرور فیزیکی استفاده کند.
به زبان ساده:
- سختافزار، منابع واقعی را فراهم میکند.
- Hypervisor منابع واقعی را مجازیسازی و مدیریت میکند.
- ماشین مجازی منابع مجازی را دریافت میکند.
- سیستمعامل مهمان داخل ماشین مجازی اجرا میشود.
Hypervisor چگونه کار میکند؟

نحوه عملکرد دقیق هر Hypervisor به معماری آن بستگی دارد؛ اما تمام هایپروایزرها باید چند وظیفه اساسی را انجام دهند:
- سختافزار را شناسایی کنند.
- ماشینهای مجازی را ایجاد و مدیریت کنند.
- منابع را میان ماشینها تخصیص دهند.
- دسترسی ماشینها به سختافزار را کنترل کنند.
- ماشینهای مجازی را از یکدیگر جدا نگه دارند.
- وضعیت مصرف منابع را پایش کنند.
- عملیاتهایی مانند روشنکردن، خاموشکردن، توقف و انتقال ماشین را انجام دهند.
وقتی ماشین مجازی روشن میشود، Hypervisor منابع تعریفشده برای آن را آماده میکند. سپس Firmware مجازی مانند BIOS یا UEFI اجرا شده و سیستمعامل مهمان از دیسک مجازی بوت میشود.
از نگاه سیستمعامل مهمان، فرآیند شبیه روشنشدن یک کامپیوتر فیزیکی است؛ اما تمام درخواستهای آن برای استفاده از پردازنده، حافظه، دیسک و شبکه تحت کنترل Hypervisor قرار دارند.
نقش Hardware-assisted Virtualization
در نسلهای قدیمی مجازیسازی، مدیریت دستورهای حساس پردازنده پیچیدهتر بود و بخشی از عملیات باید با روشهای نرمافزاری ترجمه میشد. پردازندههای جدید قابلیتهایی مانند Intel VT-x و AMD-V را در اختیار Hypervisor قرار میدهند تا اجرای ماشینهای مجازی با کارایی و امنیت بیشتری انجام شود.
قابلیتهایی مانند SLAT، Intel EPT و AMD NPT نیز مدیریت نگاشت حافظه مجازی به حافظه فیزیکی را بهینه میکنند. برای نمونه، Microsoft استفاده از پردازنده ۶۴ بیتی، قابلیت SLAT و فعالبودن Hardware-assisted Virtualization را از الزامات اصلی Hyper-V معرفی میکند. مستندات رسمی Microsoft
در بیشتر سرورها، این قابلیتها از طریق BIOS یا UEFI فعال میشوند. اگر غیرفعال باشند، ممکن است Hypervisor نصب نشود، ماشینهای مجازی اجرا نشوند یا بعضی امکانات پیشرفته در دسترس نباشند.
Hypervisor چگونه منابع سرور را مدیریت میکند؟
یکی از مهمترین مسئولیتهای Hypervisor، تخصیص بهینه منابع است. این تخصیص صرفاً تقسیم ثابت سختافزار نیست؛ بلکه Hypervisor باید بهصورت پیوسته درخواست ماشینها را دریافت، زمانبندی و کنترل کند.
مدیریت CPU و vCPU
پردازنده مجازی یا vCPU واحد پردازشی است که به ماشین مجازی اختصاص داده میشود. vCPU الزاماً معادل یک هسته فیزیکی اختصاصی نیست. Hypervisor زمان پردازشی هستههای فیزیکی را میان vCPUهای ماشینهای مختلف زمانبندی میکند.
برای مثال، ممکن است یک سرور ۳۲ هسته فیزیکی داشته باشد، اما مجموعاً ۶۴ یا تعداد بیشتری vCPU به ماشینها تخصیص داده شود. این کار CPU Overcommitment نام دارد.
Overcommitment درصورتیکه ماشینها همزمان به حداکثر توان پردازشی نیاز نداشته باشند، میتواند استفاده از سرور را بهینه کند. بااینحال، تخصیص بیشازحد vCPU باعث افزایش زمان انتظار پردازنده، کاهش کارایی و ایجاد تأخیر در Workloadهای حساس میشود.
افزایش تعداد vCPU همیشه به معنای افزایش سرعت ماشین مجازی نیست. اندازه نامناسب VM، ساختار NUMA، میزان استفاده واقعی پردازنده و نحوه زمانبندی Hypervisor همگی بر نتیجه اثر میگذارند.
مدیریت حافظه RAM
Hypervisor بخشی از حافظه فیزیکی سرور را در اختیار هر ماشین مجازی قرار میدهد. برخلاف CPU، حافظه معمولاً برای مدت مشخصی به ماشین اختصاص پیدا میکند؛ اما بسیاری از پلتفرمها قابلیتهایی برای بهینهسازی مصرف RAM دارند.
این قابلیتها بسته به Hypervisor میتوانند شامل موارد زیر باشند:
- Memory Overcommitment
- Ballooning
- Memory Compression
- Page Sharing
- Swapping
- Dynamic Memory
- تعیین Reservation و Limit
برای مثال، Ballooning به Hypervisor اجازه میدهد در شرایط کمبود حافظه، بخشی از RAM کماستفاده یک ماشین را پس بگیرد. Swapping نیز میتواند بخشی از دادههای حافظه را روی دیسک قرار دهد، اما معمولاً افت کارایی بیشتری ایجاد میکند.
در محیطهای عملیاتی، استفاده از Overcommitment حافظه باید با دقت انجام شود. کاهش شدید حافظه آزاد Host ممکن است به Ballooning، Compression یا Swap منجر شود و عملکرد چند ماشین را همزمان تحتتأثیر قرار دهد.
مدیریت Storage
Hypervisor فضای ذخیرهسازی فیزیکی را در قالب دیسکهای مجازی به ماشینها ارائه میدهد. این فضای فیزیکی ممکن است روی دیسک محلی، SAN، NAS، زیرساخت ذخیرهسازی نرمافزارمحور یا سرویس Cloud قرار داشته باشد.
هر ماشین مجازی معمولاً یک یا چند Virtual Disk دارد. این دیسکها میتوانند بهصورت فایل، Volume یا Object ذخیره شوند. سیستمعامل مهمان آنها را مشابه یک دیسک واقعی شناسایی میکند.
Hypervisor و پلتفرم مدیریت آن میتوانند قابلیتهایی مانند موارد زیر را ارائه دهند:
- Thin Provisioning
- Thick Provisioning
- Snapshot
- Clone
- Storage Migration
- Multipathing
- Storage Policy
- I/O Control
- Encryption
Thin Provisioning اجازه میدهد ظرفیت منطقی دیسک بزرگتر از فضای مصرفشده اولیه باشد؛ اما اگر ظرفیت واقعی Datastore کنترل نشود، احتمال پرشدن Storage و اختلال در ماشینها وجود دارد.
Snapshot نیز جایگزین Backup نیست. Snapshot معمولاً برای نگهداری موقت وضعیت ماشین پیش از یک تغییر استفاده میشود. باقیماندن طولانی Snapshotها میتواند مصرف Storage، پیچیدگی زنجیره دیسک و تأخیر عملیات I/O را افزایش دهد.
مدیریت Network
برای اتصال ماشینهای مجازی به یکدیگر و شبکه فیزیکی، Hypervisor اجزایی مانند کارت شبکه مجازی، سوییچ مجازی و Uplink ایجاد میکند.
هر ماشین مجازی میتواند یک یا چند vNIC داشته باشد. این کارتها به یک Virtual Switch یا ساختار شبکه نرمافزاری متصل میشوند. ترافیک سپس بر اساس تنظیمات VLAN، Port Group، Bridge، Policy یا شبکههای Overlay هدایت خواهد شد.
با استفاده از شبکه مجازی میتوان:
- ماشینهای یک Host را بدون خروج ترافیک از سرور به یکدیگر متصل کرد.
- شبکه مدیریت را از شبکه ماشینها جدا کرد.
- ترافیک Storage و Migration را تفکیک کرد.
- چند VLAN را روی Uplinkهای مشترک حمل کرد.
- برای هر گروه از ماشینها سیاست امنیتی تعریف کرد.
- افزونگی کارتهای شبکه را افزایش داد.
در معماریهای پیشرفته، راهکارهایی مانند VMware NSX میتوانند امکاناتی مانند Micro-segmentation، Distributed Firewall، شبکههای Overlay و مدیریت متمرکز امنیت شبکه را به زیرساخت مجازی اضافه کنند.
انواع Hypervisor کداماند؟
Hypervisorها معمولاً در دو گروه اصلی Type 1 و Type 2 قرار میگیرند. تفاوت اصلی این دو گروه، محل قرارگیری Hypervisor نسبت به سختافزار و سیستمعامل میزبان است.
Hypervisor نوع اول یا Type 1 چیست؟
Type 1 Hypervisor که با نام Bare-metal Hypervisor نیز شناخته میشود، مستقیماً روی سختافزار سرور اجرا میشود. در این معماری، یک سیستمعامل عمومی میزبان میان Hypervisor و سختافزار قرار ندارد.
نمونههای شناختهشده این گروه عبارتاند از:
- VMware ESX/ESXi
- Microsoft Hyper-V
- Xen
- XenServer
- KVM در معماریهای متداول سروری
Type 1 معمولاً برای دیتاسنتر، Cloud خصوصی، زیرساخت سازمانی، VDI و محیطهایی استفاده میشود که کارایی، دسترسپذیری، مقیاسپذیری و امنیت اهمیت زیادی دارند.
مزایای Type 1 Hypervisor
- سربار کمتر نسبت به معماریهای Hosted
- دسترسی مستقیمتر به منابع سختافزاری
- مناسب برای بارهای کاری عملیاتی
- جداسازی بهتر ماشینها
- امکان ساخت Cluster
- پشتیبانی از High Availability
- قابلیت Live Migration
- مدیریت متمرکز چند Host
- سازگاری با شبکه و Storage سازمانی
البته نصب یک Hypervisor نوع اول بهتنهایی تمام این امکانات را تضمین نمیکند. برخی ویژگیها توسط پلتفرم مدیریت، ابزارهای Cluster، نوع License و محصولات مکمل ارائه میشوند.
آیا Hyper-V واقعاً Type 1 است؟
ظاهر Hyper-V گاهی باعث ابهام میشود؛ زیرا بهعنوان یک Role در Windows Server یا Feature در برخی نسخههای Windows فعال میشود. بااینحال، پس از فعالشدن Hyper-V، Microsoft Hypervisor در سطح پایین معماری قرار میگیرد و Windows در Root Partition اجرا میشود.
بنابراین Hyper-V از نظر معماری Type 1 محسوب میشود، نه Type 2. Root Partition وظایف مدیریتی، دسترسی به تجهیزات I/O و ارائه سرویس به Child Partitionها را بر عهده دارد. معماری رسمی Hyper-V
Hypervisor نوع دوم یا Type 2 چیست؟
Type 2 Hypervisor مانند یک نرمافزار روی سیستمعامل میزبان نصب میشود. در این معماری، سیستمعامل میزبان ابتدا سختافزار را مدیریت میکند و Hypervisor از سرویسها و Driverهای آن استفاده میکند.
نمونههای شناختهشده عبارتاند از:
- VMware Workstation
- Oracle VirtualBox
- VMware Fusion
- Parallels Desktop
این نوع Hypervisor بیشتر برای آزمایشگاه، آموزش، توسعه نرمافزار، تست سیستمعامل و اجرای چند محیط روی کامپیوتر شخصی استفاده میشود.
برای مثال، میتوانید VMware Workstation را روی Windows نصب کرده و داخل آن چند ماشین Windows یا Linux ایجاد کنید. در این سناریو، Windows سیستمعامل میزبان است و Workstation بهعنوان Hypervisor نوع دوم عمل میکند.
مزایای Type 2 Hypervisor
- نصب و راهاندازی ساده
- مناسب برای لپتاپ و کامپیوتر شخصی
- نیاز نداشتن به سرور جداگانه
- مناسب برای آموزش و آزمایش
- امکان استفاده همزمان از نرمافزارهای سیستمعامل میزبان
- هزینه اولیه کمتر برای ساخت Lab
محدودیتهای Type 2 Hypervisor
- وابستگی به سیستمعامل میزبان
- سربار بیشتر
- سطح حمله گستردهتر
- مناسبنبودن برای بیشتر Workloadهای عملیاتی سازمانی
- محدودیت در Cluster، HA و مدیریت متمرکز
- احتمال تداخل با Driverها و قابلیتهای امنیتی سیستمعامل میزبان
مقایسه Hypervisor نوع اول و دوم
| معیار | Type 1 | Type 2 |
|---|---|---|
| محل اجرا | مستقیم روی سختافزار | روی سیستمعامل میزبان |
| کاربرد اصلی | دیتاسنتر و محیط عملیاتی | آموزش، توسعه و آزمایش |
| کارایی | معمولاً بالاتر | دارای سربار بیشتر |
| مدیریت متمرکز | گستردهتر | محدودتر |
| High Availability | معمولاً قابل ارائه | معمولاً وجود ندارد |
| Live Migration | در پلتفرمهای سازمانی موجود است | معمولاً در دسترس نیست |
| راهاندازی اولیه | تخصصیتر | سادهتر |
| تجهیزات موردنیاز | سرور یا سختافزار سازگار | کامپیوتر شخصی نیز کافی است |
| امنیت و جداسازی | مناسبتر برای سازمان | وابسته به امنیت Host OS |
| نمونه | ESX، Hyper-V، KVM و Xen | Workstation و VirtualBox |
انتخاب Type 1 یا Type 2 نباید فقط بر اساس «بهتر بودن» انجام شود. هرکدام برای سناریوی متفاوتی طراحی شدهاند. برای ساخت یک آزمایشگاه کوچک، Type 2 انتخابی منطقی است؛ اما برای اجرای سرویسهای حیاتی سازمان، استفاده از Type 1 و معماری Cluster ضرورت پیدا میکند.
روشهای اجرای سیستمعامل مهمان
علاوه بر تقسیمبندی Type 1 و Type 2، روش تعامل Hypervisor و سیستمعامل مهمان نیز اهمیت دارد.
Full Virtualization
در Full Virtualization، ماشین مجازی یک محیط سختافزاری کامل دریافت میکند و سیستمعامل مهمان معمولاً بدون تغییر اساسی اجرا میشود.
این روش امکان اجرای چند سیستمعامل متفاوت را روی یک Host فراهم میکند. برای نمونه، Windows Server و Linux میتوانند بهصورت همزمان روی یک سرور فیزیکی اجرا شوند.
Paravirtualization
در Paravirtualization، سیستمعامل مهمان یا Driverهای آن از مجازیبودن محیط آگاه هستند و برای بعضی عملیات مستقیماً با Hypervisor ارتباط برقرار میکنند.
امروزه بیشتر از اینکه کل سیستمعامل Paravirtualized باشد، از Driverهای بهینهشده استفاده میشود. VMware Tools، VirtIO Drivers و Integration Services نمونههایی از ابزارهایی هستند که کارایی Storage، Network و مدیریت ماشین را بهبود میدهند.
Hardware-assisted Virtualization
در این روش، Hypervisor از قابلیتهای مجازیسازی پردازنده و Chipset استفاده میکند. فناوریهایی مانند Intel VT-x، AMD-V، Intel EPT، AMD NPT و IOMMU اجرای دستورها، مدیریت حافظه و دسترسی کنترلشده به تجهیزات را بهینه میکنند.
بیشتر Hypervisorهای مدرن ترکیبی از Hardware-assisted Virtualization و Driverهای Paravirtualized را به کار میگیرند.
معرفی Hypervisorهای مهم
VMware ESX و ESXi
VMware ESXi یکی از شناختهشدهترین Hypervisorهای سازمانی است و در نسلهای مختلف VMware vSphere بهعنوان لایه اجرای ماشینهای مجازی استفاده شده است.
در مستندات رسمی VMware vSphere 9 نام این Hypervisor بهصورت VMware ESX نمایش داده میشود؛ درحالیکه در نسلهای قبلی، بهویژه vSphere 7 و 8، نام ESXi رایج است. به همین دلیل در منابع آموزشی و جستوجوهای کاربران همچنان هر دو نام ESX و ESXi مشاهده میشوند. مستندات رسمی VMware vSphere 9
خود Hypervisor روی هر سرور فیزیکی نصب میشود و اجرای VMها را مدیریت میکند. برای مدیریت متمرکز چند Host، معمولاً از VMware vCenter استفاده میشود.
ترکیب ESX/ESXi و vCenter امکاناتی مانند موارد زیر را فراهم میکند:
- مدیریت متمرکز Hostها و ماشینها
- ساخت Cluster
- vMotion
- Storage vMotion
- vSphere High Availability
- Distributed Resource Scheduler
- Template و Clone
- مدیریت Lifecycle
- اتصال به Storageهای سازمانی
- Distributed Virtual Switch
- یکپارچگی با vSAN، NSX و VCF
نقاط قوت اصلی VMware را میتوان بلوغ فنی، اکوسیستم گسترده، امکانات سازمانی، سازگاری با تجهیزات دیتاسنتری و تجربه مدیریتی یکپارچه دانست.
در مقابل، هزینه License، مدل عرضه محصولات، نیاز به بررسی دقیق سازگاری سختافزار و وابستگی بیشتر به اکوسیستم سازنده از معیارهایی هستند که پیش از انتخاب باید ارزیابی شوند.
Microsoft Hyper-V
Hyper-V فناوری مجازیسازی Microsoft است و در Windows Server و برخی نسخههای Windows ارائه میشود. این Hypervisor برای سازمانهایی که بخش بزرگی از زیرساخت آنها بر پایه محصولات Microsoft است، گزینهای قابلتوجه محسوب میشود.
Hyper-V از معماری Partition استفاده میکند. Root Partition وظایف مدیریتی و دسترسی به تجهیزات را بر عهده دارد و سیستمعاملهای مهمان در Child Partitionها اجرا میشوند.
برخی قابلیتهای مهم Hyper-V عبارتاند از:
- Hyper-V Manager
- PowerShell Management
- Failover Clustering
- Live Migration
- Storage Migration
- Hyper-V Replica
- Dynamic Memory
- Virtual Switch
- Shielded VM
- Integration Services
Hyper-V Replica میتواند نسخهای از ماشین مجازی را روی Host دیگری نگهداری کند تا در سناریوهای تداوم کسبوکار و Disaster Recovery استفاده شود. این قابلیت با Backup یکسان نیست، اما میتواند بخشی از راهکار BCDR باشد. معرفی Hyper-V Replica
مهمترین مزیت Hyper-V، هماهنگی آن با Windows Server، Active Directory، PowerShell و سایر فناوریهای Microsoft است. در مقابل، طراحی درست Cluster، Storage، Network و مدیریت Lifecycle همچنان به دانش تخصصی نیاز دارد.
KVM
KVM مخفف Kernel-based Virtual Machine است. KVM بخشی از Kernel لینوکس است و قابلیتهای لازم برای تبدیل Linux به بستری برای اجرای ماشینهای مجازی را فراهم میکند.
KVM بهتنهایی تمام اجزای موردنیاز یک پلتفرم مدیریت مجازیسازی را ارائه نمیدهد. معمولاً اجزای زیر در کنار هم استفاده میشوند:
- KVM برای مجازیسازی پردازنده و حافظه
- QEMU برای مدلسازی و ارائه تجهیزات مجازی
- libvirt برای مدیریت استاندارد ماشینها
- ابزارهایی مانند virsh یا virt-manager
- پلتفرمهای مدیریتی مانند Proxmox VE یا OpenStack
در معماری متداول KVM، ماشینهای مجازی بهصورت Processهای QEMU در فضای کاربر اجرا میشوند و از قابلیت KVM در Kernel استفاده میکنند. مستندات Red Hat نیز KVM را یک ماژول Kernel معرفی میکنند که با استفاده از Intel VT یا AMD-V، Full Virtualization را فراهم میکند. معماری KVM در مستندات Red Hat
مزایای مهم KVM عبارتاند از:
- متنباز بودن
- ادغام با Linux
- انعطافپذیری بالا
- اکوسیستم گسترده Cloud
- امکان خودکارسازی
- پشتیبانی از VirtIO
- قابلیت استفاده در معماریهای بزرگ
- مناسب برای پلتفرمهای سفارشی
KVM پایه بسیاری از راهکارهای مجازیسازی و Cloud است؛ اما کیفیت تجربه نهایی به Distribution، ابزار مدیریت، طراحی Cluster، Storage، Network و تیم پشتیبانی وابسته خواهد بود.
Xen و XenServer
Xen یک Hypervisor متنباز Type 1 است که مستقیماً روی سختافزار اجرا میشود. معماری Xen شامل Domainهایی است که وظایف مختلف را بر عهده دارند. معمولاً Domain 0 یا Dom0 دسترسی مدیریتی و Driverهای تجهیزات را فراهم میکند و ماشینهای مهمان در Domainهای دیگر اجرا میشوند.
Xen در Server Virtualization، Cloud، محیطهای امنیتمحور، تجهیزات Embedded و راهکارهای Desktop Virtualization استفاده شده است.
XenServer یکی از پلتفرمهای مبتنی بر Xen است که قبلاً با نام Citrix Hypervisor نیز شناخته میشد. براساس مستندات رسمی، Xen Hypervisor یک Bare-metal Hypervisor است و امکان اجرای چند سیستمعامل را بهصورت موازی فراهم میکند. Technical Overview رسمی XenServer
XenServer میتواند بهویژه در زیرساختهای Citrix Virtual Apps and Desktops و سناریوهای VDI موردتوجه قرار گیرد؛ اما مانند هر پلتفرم دیگری باید وضعیت License، پشتیبانی، سازگاری سختافزار و نیازهای عملیاتی آن بررسی شود.
آیا Proxmox یک Hypervisor است؟
در گفتوگوهای عمومی معمولاً Proxmox بهعنوان Hypervisor معرفی میشود؛ اما از نظر فنی، Proxmox Virtual Environment یا Proxmox VE یک پلتفرم مدیریت مجازیسازی است، نه یک Hypervisor مستقل.
Proxmox VE از فناوریهای زیر استفاده میکند:
- QEMU/KVM برای ماشینهای مجازی
- LXC برای Containerهای سیستمی
- Linux برای سیستمعامل پایه
- رابط وب برای مدیریت
- ابزارهای Cluster، Storage، Backup و Network
بنابراین وقتی یک ماشین مجازی در Proxmox ساخته میشود، بخش مجازیسازی سختافزاری آن عمدتاً توسط QEMU/KVM انجام میشود. Proxmox اجزای مختلف را در قالب یک پلتفرم مدیریتی یکپارچه ارائه میدهد. راهنمای رسمی Proxmox VE
Proxmox VE برای آزمایشگاههای تخصصی، شرکتهای کوچک و متوسط و حتی بعضی زیرساختهای سازمانی جذاب است؛ زیرا رابط مدیریتی مناسب، قابلیت Cluster، High Availability، Replication، Backup و پشتیبانی از Storageهای مختلف را ارائه میکند.
بااینحال، متنباز بودن به معنای بینیازی از طراحی، پشتیبانی یا هزینه نیست. سازمان باید توانایی تیم داخلی، Subscription، سازگاری تجهیزات، فرآیند بهروزرسانی و مسئولیت رفع اشکال را ارزیابی کند.
مقایسه ESX/ESXi، Hyper-V، KVM و Xen
| معیار | VMware ESX/ESXi | Microsoft Hyper-V | KVM | Xen |
|---|---|---|---|---|
| نوع معماری | Type 1 | Type 1 | مبتنی بر Kernel لینوکس | Type 1 |
| مدیریت رایج | vCenter و VCF | Hyper-V Manager، PowerShell و ابزارهای Microsoft | libvirt یا پلتفرمهای مبتنی بر KVM | ابزارها و پلتفرمهای مبتنی بر Xen |
| اکوسیستم اصلی | دیتاسنتر و Private Cloud | زیرساخت Microsoft | Linux، Cloud و پلتفرمهای متنباز | Cloud، VDI و پلتفرمهای Xen-based |
| سهولت راهاندازی | ساختاریافته و سازمانی | مناسب محیطهای Windows | وابسته به پلتفرم انتخابی | وابسته به محصول مبتنی بر Xen |
| انعطافپذیری | بالا در اکوسیستم VMware | بالا در اکوسیستم Microsoft | بسیار بالا | بالا |
| License | تجاری | وابسته به محصول و Licenseهای Microsoft | متنباز؛ پشتیبانی ممکن است تجاری باشد | متنباز یا تجاری بر اساس پلتفرم |
| گزینه مناسب برای | سازمانهای دارای زیرساخت VMware | سازمانهای Microsoft محور | Cloud و زیرساختهای Linux محور | برخی محیطهای Cloud و VDI |
هیچ Hypervisorی در تمام سناریوها بهترین گزینه نیست. انتخاب باید بر اساس کل پلتفرم انجام شود، نه فقط نام Hypervisor.
تفاوت Hypervisor و Container چیست؟
ماشین مجازی و Container هر دو برای جداسازی Workloadها استفاده میشوند، اما معماری متفاوتی دارند.
در مجازیسازی مبتنی بر Hypervisor، هر ماشین مجازی سیستمعامل و Kernel مخصوص خود را دارد. به همین دلیل میتوان روی یک Host، سیستمعاملهای مختلفی مانند Windows و Linux را همزمان اجرا کرد.
در Container، نمونهها معمولاً Kernel سیستمعامل میزبان را به اشتراک میگذارند. بنابراین Container سبکتر است، سریعتر ایجاد میشود و منابع کمتری مصرف میکند؛ اما سطح و مدل جداسازی آن با VM یکسان نیست.
| معیار | ماشین مجازی | Container |
|---|---|---|
| Kernel | مستقل برای هر VM | معمولاً مشترک با Host |
| سیستمعامل | کامل | محیط اجرایی و وابستگیها |
| زمان راهاندازی | بیشتر | بسیار سریع |
| مصرف منابع | بیشتر | کمتر |
| جداسازی | قویتر در بسیاری از معماریها | وابسته به Namespace و Isolation |
| اجرای سیستمعامل متفاوت | امکانپذیر | محدود به سازگاری Kernel |
| کاربرد | سرویسهای زیرساختی و Workloadهای متنوع | برنامههای Cloud-native و Microservice |
در بسیاری از دیتاسنترهای جدید، Container جایگزین کامل VM نشده است. Containerها معمولاً داخل ماشینهای مجازی اجرا میشوند تا مزایای هر دو معماری به دست آید: جداسازی و مدیریت زیرساخت در سطح VM و سرعت و انعطافپذیری در سطح Container.
معیارهای انتخاب Hypervisor
انتخاب Hypervisor یک تصمیم صرفاً فنی نیست. هزینه، مهارت تیم، پشتیبانی، مسیر توسعه سازمان و سازگاری نرمافزارها نیز بر آن اثر میگذارند.
سازگاری سختافزاری
پیش از انتخاب باید بررسی شود که سرور، پردازنده، کنترلر Storage، کارت شبکه، HBA و GPU در فهرست سازگاری پلتفرم قرار دارند یا خیر.
کارکردن یک قطعه در آزمایش اولیه به معنای پشتیبانی رسمی آن نیست. در محیط عملیاتی، استفاده از سختافزار خارج از HCL میتواند هنگام بهروزرسانی یا دریافت پشتیبانی مشکلساز شود.
پشتیبانی از سیستمعامل و نرمافزار
باید مشخص شود سیستمعاملهای مهمان، Databaseها، نرمافزارهای سازمانی، تجهیزات امنیتی و محصولات Backup از Hypervisor انتخابی پشتیبانی میکنند یا خیر.
گاهی یک نرمافزار روی ماشین اجرا میشود، اما سازنده آن فقط چند Hypervisor مشخص را برای محیط عملیاتی تأیید کرده است.
High Availability و Disaster Recovery
اگر سرویسهای سازمان حیاتی هستند، باید قابلیتهای زیر ارزیابی شوند:
- راهاندازی خودکار VM پس از خرابی Host
- Live Migration
- Storage Migration
- Replication
- Backup Integration
- Fault Domain
- Stretch Cluster
- Site Recovery
- Recovery Point Objective
- Recovery Time Objective
وجود نام یک قابلیت کافی نیست. محدودیتها، پیشنیازها، نوع License و رفتار آن در زمان خرابی واقعی باید بررسی شود.
مدیریت و خودکارسازی
در محیط کوچک شاید مدیریت چند Host بهصورت مستقل امکانپذیر باشد؛ اما با افزایش تعداد سرورها، مدیریت متمرکز ضروری میشود.
پلتفرم مناسب باید API، ابزار خط فرمان، Role-based Access Control، گزارشگیری، Monitoring، Template، Automation و Lifecycle Management مناسبی داشته باشد.
امنیت
Hypervisor بخشی بسیار حساس از زیرساخت است. دسترسی غیرمجاز به آن میتواند چندین ماشین و سرویس را همزمان در معرض خطر قرار دهد.
معیارهای امنیتی مهم عبارتاند از:
- جداسازی شبکه مدیریت
- استفاده از MFA در لایه مدیریت
- دسترسی مبتنی بر نقش
- ثبت و پایش رخدادها
- نصب Patchهای امنیتی
- Secure Boot
- TPM و Attestation
- رمزگذاری VM و Storage
- محدودکردن دسترسی مستقیم به Host
- تهیه Backup از تنظیمات
- غیرفعالکردن سرویسهای غیرضروری
هزینه واقعی مالکیت
مقایسه فقط بر اساس قیمت License میتواند گمراهکننده باشد. هزینه واقعی مالکیت یا TCO شامل موارد زیر است:
- License و Subscription
- پشتیبانی فنی
- سختافزار سازگار
- Backup و Monitoring
- آموزش تیم
- مهاجرت Workloadها
- زمان مدیریت
- هزینه توقف سرویس
- ابزارهای جانبی
- توسعه و نگهداری Automation
ممکن است یک Hypervisor متنباز هزینه License کمتری داشته باشد، اما به تیم متخصصتر یا پشتیبانی خارجی نیاز پیدا کند. در مقابل، یک راهکار تجاری نیز ممکن است به دلیل ابزارهای یکپارچهتر، بخشی از هزینههای عملیاتی را کاهش دهد.
مهارت تیم زیرساخت
بهترین پلتفرم روی کاغذ، اگر توسط تیم سازمان قابل مدیریت نباشد، انتخاب مناسبی نخواهد بود. توانایی نصب، عیبیابی، طراحی Cluster، مدیریت Storage، شبکه، امنیت، Backup و بهروزرسانی باید ارزیابی شود.
آموزش تیم نباید پس از خرید محصول آغاز شود. بهتر است پیش از تصمیم نهایی، یک محیط آزمایشی ساخته شده و سناریوهای واقعی در آن اجرا شوند.
اشتباهات رایج در استفاده از Hypervisor
تخصیص بیشازحد منابع
اختصاص vCPU و RAM بیشتر از نیاز واقعی، ظرفیت Cluster را کاهش میدهد و لزوماً عملکرد VM را بهتر نمیکند. Right-sizing باید بر اساس دادههای Monitoring انجام شود.
استفاده طولانی از Snapshot
Snapshot برای Backup دائمی طراحی نشده است. نگهداری طولانی آن میتواند مصرف Storage و پیچیدگی عملیات را افزایش دهد.
قراردادن همه ترافیکها روی یک شبکه
ترافیک مدیریت، ماشینهای مجازی، Storage، Backup و Migration باید بر اساس طراحی و سطح حساسیت تفکیک شوند.
نادیدهگرفتن Firmware و Driver
هماهنگی نسخه Hypervisor با Firmware، BIOS، Driver و ابزارهای مدیریت سرور اهمیت زیادی دارد. بهروزرسانی بدون بررسی Compatibility میتواند باعث ناپایداری شود.
نداشتن ظرفیت رزرو
اگر تمام ظرفیت Cluster در شرایط عادی مصرف شده باشد، هنگام خرابی یک Host فضای کافی برای اجرای ماشینهای آن روی سایر Hostها وجود نخواهد داشت.
انتخاب Hypervisor فقط بر اساس قیمت
قیمت مهم است، اما نباید تنها معیار باشد. سازگاری، پشتیبانی، امنیت، مهارت تیم و هزینه مهاجرت معمولاً تأثیر بیشتری بر موفقیت بلندمدت دارند.
کدام Hypervisor برای شما مناسبتر است؟
برای آموزش و آزمایشگاه شخصی
VMware Workstation، VirtualBox یا یک محیط Nested میتوانند گزینههای مناسبی باشند. اگر سیستم جداگانهای در اختیار دارید، Proxmox VE نیز برای آشنایی با Cluster، Storage و مدیریت VMها انتخاب جذابی است.
برای سازمانهای VMware محور
اگر سازمان از vSphere، vSAN، NSX، VMware Cloud Foundation یا ابزارهای مدیریتی VMware استفاده میکند، ESX/ESXi معمولاً مسیر طبیعیتری خواهد بود.
برای سازمانهای Microsoft محور
در محیطهایی که Windows Server، Active Directory، PowerShell و محصولات Microsoft نقش اصلی دارند، Hyper-V میتواند هماهنگی مناسبی با ساختار موجود ایجاد کند.
برای زیرساختهای Linux و Cloud
KVM به دلیل انعطافپذیری، ادغام با Linux و حضور گسترده در پلتفرمهای Cloud گزینه مهمی است. انتخاب ابزار مدیریت مناسب در این سناریو اهمیت زیادی دارد.
برای محیطهای Citrix و VDI
VMware، Hyper-V و XenServer میتوانند در سناریوهای VDI استفاده شوند. انتخاب نهایی باید بر اساس نسخه Citrix، قابلیتهای موردنیاز، پشتیبانی رسمی، GPU، Storage، License و تجربه تیم انجام شود.
جمعبندی
Hypervisor لایه اصلی اجرای ماشینهای مجازی است و مسئولیت مدیریت و جداسازی منابع CPU، RAM، Storage و Network را بر عهده دارد.
Hypervisorهای Type 1 مستقیماً در معماری زیرساخت قرار میگیرند و بیشتر برای دیتاسنتر و محیطهای عملیاتی استفاده میشوند. Type 2 روی سیستمعامل میزبان نصب میشود و برای آموزش، آزمایش و توسعه مناسبتر است.
VMware ESX/ESXi، Microsoft Hyper-V، KVM و Xen هرکدام معماری، اکوسیستم و کاربردهای خاص خود را دارند. Proxmox VE نیز یک پلتفرم مدیریت مجازیسازی مبتنی بر QEMU/KVM و LXC است و نباید آن را یک Hypervisor مستقل در نظر گرفت.
انتخاب راهکار مناسب باید بر اساس نیازهای فنی، سازگاری سختافزار، قابلیتهای HA و DR، امنیت، هزینه واقعی مالکیت، محصولات جانبی و مهارت تیم انجام شود. Hypervisor فقط یک نرمافزار نصبشده روی سرور نیست؛ پایهای است که بخش بزرگی از سرویسهای دیتاسنتر روی آن اجرا خواهند شد.
اگر میخواهید مفاهیم مجازیسازی را از پایه و با یک مسیر آموزشی منظم یاد بگیرید، میتوانید از مینیدوره دریچه ورود به دنیای مجازیسازی شروع کنید.
سؤالات متداول درباره Hypervisor
Hypervisor چیست؟
Hypervisor لایهای نرمافزاری یا سیستمی است که منابع یک سرور فیزیکی را میان چند ماشین مجازی تقسیم و اجرای آنها را مدیریت میکند.
تفاوت Hypervisor و ماشین مجازی چیست؟
Hypervisor بستر ایجاد و اجرای ماشینها است؛ اما ماشین مجازی محیط مستقلی است که سیستمعامل و نرمافزارها داخل آن اجرا میشوند.
Hypervisor نوع اول بهتر است یا نوع دوم؟
برای دیتاسنتر و سرویسهای عملیاتی معمولاً Type 1 مناسبتر است. Type 2 بیشتر برای آموزش، توسعه و آزمایش روی کامپیوتر شخصی استفاده میشود.
آیا Hyper-V یک Hypervisor نوع دوم است؟
خیر. Hyper-V از نظر معماری Type 1 است. پس از فعالشدن آن، Windows مدیریت را از طریق Root Partition انجام میدهد.
آیا Proxmox یک Hypervisor است؟
Proxmox VE یک پلتفرم مدیریت مجازیسازی است که برای اجرای ماشینها از QEMU/KVM و برای Containerها از LXC استفاده میکند.
تفاوت ESXi و ESX چیست؟
در نسلهای قبلی VMware vSphere، نام ESXi رایج است. در مستندات vSphere 9، Broadcom دوباره از نام ESX استفاده میکند. هر دو نام به Hypervisor سروری اکوسیستم VMware مربوطاند، اما نسخه و مستندات محصول باید در نظر گرفته شود.
آیا میتوان Hypervisor را داخل ماشین مجازی اجرا کرد؟
بله، این قابلیت Nested Virtualization نام دارد. از آن بیشتر برای آموزش، Lab، توسعه و آزمایش استفاده میشود. استفاده عملیاتی آن به پشتیبانی و محدودیتهای پلتفرم بستگی دارد.