Hypervisor و Virtual Machine

Virtualization و اجزای اصلی

یک Server فیزیکی را تصور کن که CPU، RAM، Disk و چند کارت شبکه دارد. بدون Virtualization می‌توانی یک سیستم‌عامل روی آن نصب کنی و Server را برای یک یا چند سرویس استفاده کنی. Virtualization اجازه می‌دهد همان سخت‌افزار فیزیکی به چند محیط جدا تقسیم شود تا هر محیط مثل یک کامپیوتر مستقل رفتار کند. هرکدام می‌تواند سیستم‌عامل و Applicationهای خودش را داشته باشد و بدون نیاز به یک Server فیزیکی جدا اجرا شود.

خود دستگاه فیزیکی معمولاً Host نامیده می‌شود؛ Host یعنی میزبان. نرم‌افزاری که منابع سخت‌افزار را مدیریت می‌کند و این محیط‌های جدا را می‌سازد Hypervisor نام دارد. Hypervisor تصمیم می‌گیرد هر محیط چه مقدار CPU، RAM و Storage دریافت کند و دسترسی آن به تجهیزات مجازی مثل کارت شبکه چگونه باشد. محیطی که ساخته می‌شود Virtual Machine یا VM نام دارد؛ ماشین مجازی یعنی یک کامپیوتر نرم‌افزاری که رفتار بسیاری از اجزای یک کامپیوتر واقعی را شبیه‌سازی می‌کند.

داخل هر VM معمولاً یک سیستم‌عامل جدا نصب می‌شود. این سیستم‌عامل را Guest OS می‌نامند؛ Guest یعنی مهمان. اگر Host یک Server فیزیکی باشد، می‌توانی یک VM با Windows Server، یک VM با Linux و یک VM دیگر برای Application متفاوت داشته باشی. Restart کردن یکی از VMها لزوماً بقیه VMها را Restart نمی‌کند، چون هرکدام محیط جداگانه خودشان را دارند.

وقتی برای VM چهار vCPU و 8GB RAM تعریف می‌کنی، vCPU یعنی سهم پردازشی مجازی که Hypervisor از CPUهای فیزیکی در اختیار VM می‌گذارد. RAM هم بخشی از حافظه فیزیکی Host است که به VM تخصیص داده می‌شود. Disk مجازی معمولاً به شکل فایل یا Volume روی Storage نگهداری می‌شود. لازم نیست برای CCNA وارد Scheduler داخلی Hypervisor شوی؛ مهم است بفهمی منابع VM واقعی از سخت‌افزار Host می‌آیند و Hypervisor بین VMها مدیریتشان می‌کند.

Hypervisor و مدیریت منابع

Hypervisor دو مدل کلی دارد. در Type 1، Hypervisor مستقیم روی سخت‌افزار Server اجرا می‌شود و معمولاً در Data Centerها و محیط‌های سازمانی دیده می‌شود. VMware ESXi نمونه شناخته‌شده‌ای از این مدل است. در Type 2، یک سیستم‌عامل معمولی روی کامپیوتر نصب است و نرم‌افزار Virtualization روی همان سیستم‌عامل اجرا می‌شود؛ این مدل برای Lab و Desktop رایج‌تر است. برای CCNA لازم نیست فهرست محصولات را حفظ کنی؛ نقش Hypervisor مهم‌تر از نام محصول است.

Hypervisor فقط CPU و RAM تقسیم نمی‌کند. برای VMها سخت‌افزار مجازی هم ارائه می‌دهد. VM ممکن است یک یا چند Disk مجازی و یک یا چند کارت شبکه مجازی داشته باشد. این کارت شبکه مجازی را vNIC می‌نامند؛ حرف v یعنی virtual. از دید Windows یا Linux داخل VM، vNIC مثل یک کارت شبکه است و می‌توان روی آن IP Address، Subnet Mask یا Prefix، Default Gateway و DNS تنظیم کرد.

همین نقطه برای Network Engineer مهم می‌شود. اگر Server فیزیکی یک کابل شبکه سالم به Switch دارد ولی VM دسترسی ندارد، هنوز چند بخش مجازی بین VM و کابل وجود دارد. ممکن است vNIC VM Disconnect شده باشد، VM به شبکه مجازی اشتباه وصل شده باشد، VLAN اشتباه انتخاب شده باشد یا تنظیم IP داخل Guest OS مشکل داشته باشد. سالم بودن NIC فیزیکی Host همه این موارد را رد نمی‌کند.

منابع VM هم می‌توانند روی تجربه شبکه اثر غیرمستقیم داشته باشند. اگر Host شدیداً کمبود CPU یا RAM داشته باشد، Application داخل VM ممکن است کند پاسخ بدهد و کاربر آن را «کندی شبکه» تصور کند. Network Engineer باید قبل از تغییر Switch تشخیص دهد آیا Packet واقعاً در شبکه مشکل دارد یا Server مجازی به دلیل کمبود منابع دیر پاسخ می‌دهد. همین مرزبندی بین Compute و Network در محیط مجازی مهم است.

Virtual Switch و مسیر Traffic

حالا که VM و vNIC را می‌شناسیم می‌توانیم Virtual Switch را توضیح بدهیم. Virtual Switch یا vSwitch یک Switch نرم‌افزاری داخل محیط Virtualization است. vNICهای VMها می‌توانند به Portهای این Switch مجازی متصل شوند. مفهومش شبیه Switch فیزیکی است: چند Interface را به هم وصل می‌کند و Traffic را بین شبکه مجازی و در صورت نیاز شبکه فیزیکی جابه‌جا می‌کند. جزئیات پیاده‌سازی بین Hypervisorها فرق دارد، اما این تصویر برای CCNA پایه کافی است.

فرض کن VM1 و VM2 روی یک Host قرار دارند و هر دو به یک vSwitch وصل هستند. بسته به طراحی شبکه مجازی، Traffic بین آن‌ها ممکن است داخل خود Host جابه‌جا شود و اصلاً از کابل فیزیکی بیرون نرود. در نتیجه اگر روی Switch فیزیکی Counter Port را نگاه کنی، ممکن است تمام Traffic داخلی بین VMها را نبینی. این تفاوت یکی از دلایلی است که عیب‌یابی شبکه مجازی فقط با نگاه به Switch فیزیکی کامل نمی‌شود.

اگر VM بخواهد با دستگاهی بیرون Host ارتباط داشته باشد، مسیر ساده می‌تواند این شکل را داشته باشد: Application داخل VM داده را به Guest OS می‌دهد، Guest OS آن را از vNIC می‌فرستد، vNIC به vSwitch متصل است، vSwitch Traffic را به کارت شبکه فیزیکی Host می‌رساند و از آنجا Frame وارد Switch فیزیکی می‌شود. کارت شبکه فیزیکی Host را گاهی pNIC می‌نامند؛ p یعنی physical. لازم نیست اصطلاح pNIC را زیاد استفاده کنیم، اما اگر در مستندات دیدی منظور همان NIC واقعی Server است.

Application in VM
      ↓
Guest OS
      ↓
vNIC
      ↓
Virtual Switch
      ↓
Physical NIC of Host
      ↓
Physical Switch

هر نقطه در این مسیر می‌تواند محل خطا باشد. اگر vNIC Disconnect باشد، تغییر کابل فیزیکی مشکل را حل نمی‌کند. اگر NIC فیزیکی Host Down باشد، چند VM ممکن است هم‌زمان ارتباط بیرونی را از دست بدهند. اگر فقط یک VM مشکل دارد و بقیه VMهای همان Host سالم‌اند، احتمال خرابی کامل Uplink فیزیکی کمتر می‌شود و تمرکز روی همان VM و Port مجازی بیشتر می‌شود.

مزایا و محدودیت‌های Virtual Machine

یکی از مزیت‌های Virtual Machine استفاده بهتر از سخت‌افزار است. به‌جای اینکه برای هر سرویس یک Server فیزیکی کم‌استفاده داشته باشی، می‌توانی چند VM را روی Host مناسب اجرا کنی. هر VM سیستم‌عامل مستقل خودش را دارد و می‌توانی برای هرکدام منابع، شبکه و Policy جدا تعریف کنی. جابه‌جایی، Backup و ساخت نسخه جدید VM هم در بسیاری از Platformها ساده‌تر از تهیه Server فیزیکی جدید است.

این جداسازی کامل و بدون هزینه نیست. هر VM معمولاً یک Guest OS کامل دارد و برای RAM، CPU و Storage خودش منابع مصرف می‌کند. اگر تعداد VMها بیش از ظرفیت Host شود، Performance همه Workloadها می‌تواند افت کند. Workload یعنی نرم‌افزار یا سرویسی که روی زیرساخت اجرا می‌شود. برای مثال Domain Controller، Web Server یا Database هرکدام یک Workload هستند.

از دید شبکه، Virtualization تعداد نقاط پنهان را بیشتر می‌کند. قبلاً مسیر PC تا Server شاید فقط چند Switch و Router داشت. حالا ممکن است Server مقصد خودش یک VM باشد و قبل از رسیدن Packet به Guest OS، از NIC فیزیکی Host، vSwitch و vNIC عبور کند. این لایه‌ها دلیل خوبی هستند که مستندسازی Virtual Network، VLANها و Uplinkهای Host را جدی بگیری.

Virtualization همچنین خرابی Host را مهم‌تر می‌کند. اگر ده VM روی یک Host باشند و خود Host Power یا Hardware Problem پیدا کند، هر ده سرویس می‌توانند تحت تأثیر قرار بگیرند. محیط‌های حرفه‌ای برای این موضوع Redundancy و Cluster طراحی می‌کنند، اما جزئیات Cluster خارج از هدف این درس است. برای CCNA کافی است بفهمی چند Server منطقی ممکن است به یک سخت‌افزار فیزیکی مشترک وابسته باشند.

عیب‌یابی اتصال Virtual Machine

فرض کن یک VM به شبکه دسترسی ندارد ولی سه VM دیگر روی همان Host سالم‌اند. این اطلاعات Scope را کوچک می‌کند. اگر Uplink فیزیکی Host کاملاً قطع بود، معمولاً انتظار داری VMهای بیشتری تحت تأثیر باشند. اول داخل VM وضعیت vNIC و IP Configuration را می‌بینی. بعد در Hypervisor بررسی می‌کنی vNIC به شبکه یا Port Group مناسب متصل است. Port Group در بعضی Hypervisorها نام یک گروه تنظیمات شبکه مجازی است؛ فعلاً کافی است آن را شبکه‌ای در نظر بگیری که vNIC به آن وصل شده است.

اگر VM به VLAN خاصی نیاز دارد، باید مسیر VLAN از vSwitch تا Switch فیزیکی هم درست باشد. VLAN را در فصل Switching کامل یاد می‌گیریم. اینجا فقط بدان یک VM می‌تواند از نظر فیزیکی روی Host سالم باشد ولی به شبکه منطقی اشتباه متصل شده باشد. اگر VM IP مربوط به شبکه ۱۰ را دارد ولی vNIC به شبکه مجازی VLAN 20 متصل شده، Link مجازی ممکن است Connected باشد ولی ارتباط درست شکل نگیرد.

برای تست، از نزدیک‌ترین نقطه شروع کن. داخل Guest OS وضعیت Interface و IP را ببین. Gateway همان شبکه را Ping کن. اگر چند VM در همان شبکه مجازی هستند، مقایسه تنظیم VM سالم با VM خراب ارزش دارد. بعد Uplink Host و Switch فیزیکی را فقط در صورتی عمیق بررسی کن که شواهد به آن سمت بروند. این ترتیب از تغییر بی‌دلیل شبکه فیزیکی برای مشکلی که فقط داخل یک VM است جلوگیری می‌کند.

بعد از رفع مشکل، هم ارتباط VM و هم سرویس داخل آن را تست کن. ممکن است Ping درست شده باشد ولی Application به دلیل Firewall یا تنظیم خودش هنوز پاسخ ندهد. شبکه فقط یکی از اجزای مسیر سرویس است. تفکیک Guest OS، vNIC، vSwitch، NIC فیزیکی و Switch فیزیکی به تو کمک می‌کند هر علامت را در جای درست خودش بررسی کنی.