بررسی انواع معماری Hypervisor – قسمت دوم
در قسمت اول از سری مقالات آشنایی با معماری Hypervisor، با تعریف و کاربرد Hypervisor، تاریخچه Hypervisor و نیز انواع Hypervisor آشنا شدیم. در این قسمت از سری مقالات آشنایی با معماری Hypervisor، در ابتدا به تشریح برخی از اصطلاحات، تعاریف و تکنولوژی ها که اساسا مربوط به سیستم عامل می باشند پرداخته و سپس به تشریح انواع معماری بکار رفته در ساخت Hypervisor و نحوه تعامل آن ها با سخت افزار می پردازیم. لازم به ذکر است که بسیاری از اصطلاحات و تکنولوژی های موجود در این مقاله، خود شامل چندین فصل از کتاب ها و مستندات مربوطه توضیح می باشند که از حوصله این مقالات خارج هستند. لذا در این مقاله صرفا بمنظور یادآوری و درک هرچه بهتر مطالب بصورت جزئی به تشریح این اصطلاحات و تکنولوژی های فنی پرداخته و شما خواننده محترم در صورت نیاز به کسب دانش عمیق تر در هر یک از این تعاریف و تکنولوژی ها می بایستی جداگانه اقدام به مطالعه بفرمایید.
بخش اول – تعاریف و تکنولوژی های Hypervisor
کرنل – kernel
کرنل (Kernel) اولین برنامه ای است که در بخش محافظت شده ی حافظه (Protected Memory Area) در هنگام فرایند (Boot) بارگذاری (Load) می شود و مادامی که سیستم روشن است در این بخش باقی می ماند. به منظور ارسال دستورات به کامپیوتر جهت پردازش، سیستم عامل یک رابط کاربری گرافیکی را در اختیار کاربران قرار می دهد تا از طریق آن دستورات به کامپیوتر ارسال شوند، اما در این حالت سیستم توانایی فهم و پردازش این دستورات را ندارد. برای انکه سیستم بتواند این دستورات را بفهمد لازم است تا این دستورات و کدها در ابتدا به باینری (Binary) ترجمه و سپس پردازش شوند. ترجمه این کدها به باینری (Binary) بر عهده کرنل (Kernel) می باشد. در واقع کاربر (User) با پایین ترین لایه کرنل (Kernel) ارتباط برقرار می نماید و سپس کرنل (Kernel) با سیستم ارتباط برقرار می کند. به عبارت دیگر، کرنل (Kernel) ماژول مرکزی و یا هسته سیستم عامل بوده و مانند پلی بین برنامه های کاربردی (Application) و سخت افزار (Hardware) عمل می کند. بسیاری از کارشناسان حوزه فناوری اطلاعات به اشتباه بر این باورند که کرنل (Kernel) همان سیستم عامل (OS) می باشد. در پاسخ به این دوستان خاطرنشان می شود که کرنل (Kernel) ماژول مرکزی سیستم عامل (OS) بوده و خود بخشی از سیستم عامل (OS) می باشد که نقش واسط را میان نرم افزارهای کاربردی (Application) و سخت افزار (Hardware) ایفا می کند. اما سیستم عامل (OS) در واقع رابط میان کاربر (User) و سخت افزار (Hardware) می باشد.
Address Space
Address Space در واقع فضایی از حافظه (Memory) می باشد که یک برنامه (Software) و یا یک پردازش (Process) می تواند به آن دسترسی داشته باشد و دستورالعملهای خود را در آن اجرا نماید. (Address Space) ها می تواند Physical و یا Virtual باشد.
Kernel Space & User Space
حافظه سیستم (System Memory) به دو قسمت (Kernel Space) و (User Space) تقسیم می شود.
Kernel Space: به آن قسمت از حافظه (Memory) که کرنل (Kernel) سرویس هایی مانند مدیریت پردازش (Process Management)، مدیریت حافظه (Memory Management)، مدیریت تجهیزات (Device Management) و مدیریت ورودی/خروجی (I/O Management) را اجرا و ارائه می نماید در اصطلاح Kernel Space گویند. به طور کلی در داخل Kernel Space سرویس های زیر قرار دارند:
- Inter-process communication
- Basic scheduler
- Basic memory management
User Space: آن قسمت از حافظه (Memory) که هر چیزی به غیر از پردازش های مربوط به کرنل (Kernel) که در اصطلاح به آنها (User Process) گویند در آنجا اجرا می شوند را User Space گویند. لازم به ذکر می باشد که یکی از وظایف اصلی کرنل (kernel) در واقع مدیریت (User Process) جهت جلوگیری از تداخل کارکرد آنها با یکدیگر در (User Space) می باشد. به طور کلی در داخل User Space سرویس های زیر قرار دارند:
- Device Drivers
- File system
- Network stack
- Memory management scheduler
User Mode & Kernel Mode
هر سیستم عاملی برای حفاظت و امنیت سیستم به منظور جلوگیری از دسترسی غیرمجاز لازم است که دارای دو مد عملیاتی باشد.
Kernel Mode: نام دیگر آن Privileged mode می باشد. در این مد فقط دستورالعمل هایی اجرا می شوند که مخصوص این مد می باشند. به این دستورالعمل ها در اصطلاح Privileged instruction می گویند.
این دستورالعمل ها مانند:
- ۳/D instruction & half instruction
- Turn off all Interrupts
- Context switching
- Set the timer
User Mode: نام دیگر آن Non-privileged mode می باشد. در این مد فقط دستورالعمل هایی اجرا می شوند که مخصوص اجرا در User mode هستند. به چنین دستورالعمل هایی در اصطلاح Non-privileged instruction می گویند. لازم به ذکر است که دستورالعملهای مخصوص User Mode در Kernel Mode و بالعکس اجرا نمی شوند.
این دستورالعمل ها مانند:
- Reading the status of CPU
- Reading the system time
- Generate any trap instruction
System Call
تنها راه ورودی به کرنل (kernel) در واقع (System Call) می باشد. وقتی یک برنامه کامپیوتری بخواهد با سیستم ارتباط برقرار کند، در ابتدا می بایستی با کرنل (kernel) ارتباط برقرار کند و سپس کرنل (kernel) با سیستم ارتباط برقرار می کند. برای آنکه آن برنامه کامپیوتری با کرنل (Kernel) ارتباط برقرار کند می بایستی یک (System Call) بسازد و از طریق آن با کرنل (Kernel) ارتباط برقرار کند. در واقع (System Call) روش برنامه ای است که طی آن برنامه ی کامپیوتری از Kernel درخواست اجرای یک سرویس را می دهد. به عبارت دیگر، دستورالعملهای کاربر (user operations) به منظور تعامل با سیستم از (System Call) استفاده می نمایند، (System Call) سپس کرنل (kernel) را باخبر می نماید و کرنل (kernel) دستورالعمل های کاربر (user operations) را اجرا می نماید.
Inter-process communication
IPC مکانیزمی است که این قابلیت را برای سیستم عامل فراهم مینماید تا اجازه برقراری ارتباط میان پردازش های مختلف را داشته باشد. پردازش هایی (Processes) که بصورت همزمان در سیستم عامل (OS) اجرا می شوند دو مدل می باشند:
- Independent Processes
- Cooperating Processes
Independent Processes: پردازش هایی (Processes) هستند که بمنظور اجرا شدن احتیاج به همکاری و یا به اشتراک گذاری اطلاعات با پردازش های (Processes) دیگر ندارند. در واقع این پردازش ها بر روی دیگر پردازش ها هیچگونه تاثیری نمی گذارند و نیز از دیگر پردازش ها هیچگونه تاثیری نمی پذیرند.
Cooperating Processes: پردازش هایی (Processes) هستند که بمنظور اجرا شدن احتیاج به برقراری ارتباط و به اشتراک گذاری اطلاعات با دیگر پردازش ها (Processes) دارند. در واقع این پردازش ها بر روی دیگر پردازش ها تاثیرگذار خواهند بود و نیز نسبت به دیگر پردازش ها تاثیر پذیر می باشند. پس بطور کلی هر پردازشی که با دیگر پردازش ها اطلاعات به اشتراک بگذارد در واقع Cooperating Process می باشد. بالا رفتن سرعت انجام عملیات محاسباتی یکی از بزرگترین مزایای مدل Cooperating Processes میباشد. برای مثال اگر یک Task داشته باشیم که قرار باشد فقط از طریق یک پردازش (Process) کارش انجام شود سرعت انجام عملیات محاسباتی و پردازش بسیار کمتر خواهد بود نسبت به زمانی که آن (Task) به چندیدن پردازش کوچکتر (Sub-Process) تقسیم شود و همه آن پردازش ها با یکدیگر از طریق IPC در ارتباط باشند و نهایتا انجام عملیات آن Task به پایان برسد.
همانطور که گفته شد در Cooperating Processes احتیاج به برقراری ارتباط میان پردازش های مختلف (Processes) می باشد. Inter-Process Communication (IPC) در واقع مکانیزمی است که ارتباط میان پردازش ها (Processes) را امکان پذیر می نماید.
Inter-Process Communication (IPC) می تواند به چندین مدل در سیستم عامل طراحی و پیاده سازی گردد که به توضیح دو مدل از مهمترین آنها می پردازیم:
- Shared Memory
- Message-Passing
IPC – Shared Memory: در این مدل، پردازش هایی (Processes) که قرار است با یکدیگر ارتباط برقرار کنند در ابتدا یک فضای به اشتراک گذاشته شده در حافظه (Shared Memory) می سازند و سپس از طریق آن فضای به اشتراک گذاشته شده با یکدیگر ارتباط برقرار می کنند. در مدل IPC – Shared Memory آن فضای به اشتراک گذاشته شده در حافظه که در اصطلاح (Shared Memory) می نامیم در قسمت (User Space) قرار دارد. از مزایای این مدل پیاده سازی، سرعت بسیار بالای آن می باشد چرا که بمنظور ارتباط میان پردازش ها (Processes) احتیاجی به ساخت (System Call) نمی باشد که این امر سبب میشود تا این مدل از پیاده سازی IPC دارای (Overhead) کمتر و کارایی (Performance) بیشتر شود. اما از طرفی این مدل میتواند بشدت دچار خطا (Error) شود و برای جلوگیری از بوجود آمدن خطا (Error) می بایستی پردازش ها (Processes) با یکدیگر (Sync) شوند.
IPC – Message-Passing: در این مدل، پردازش هایی (Processes) که قرار است با یکدیگر ارتباط برقرار کنند در ابتدا یک فضای به اشتراک گذاشته شده در حافظه (Memory) می سازند و سپس از طریق آن فضای به اشتراک گذاشته شده با یکدیگر ارتباط برقرار می کنند. در حالت IPC – Message-Passing آن فضای به اشتراک گذاشته شده در قسمت (Kernel Space) قرار دارد.
در این مدل از پیاده سازی، احتیاج به دو مدل (System Call) (Send) و (System Call) (Receive) بمنظور برقراری ارتباط میان پردازش ها (Processes) خواهیم داشت.
این روش از سرعت کمتری نسبت به IPC – Shared Memory برخوردار است چرا که برای ارتباط از (System Call) استفاده می نماید در نتیجه از (Overhead) بیشتر و کارایی کمتر (Performance) برخوردار می باشد. اما از طرفی کمتر دچار Error می شود و آن هم بدلیل استفاده از (System Call) می باشد.
Process Scheduling – زمانبندی پردازش
وظایف مربوط به Process Scheduling از طریق Schedulers ها انجام میشوند. انتخاب اینکه کدام (Job ها) برای پردازش به سیستم ارسال شوند و تصمیم گیری اینکه کدام پردازش می بایستی اجرا شود وظیفه اصلی Scheduler ها می باشد. سه مدل Scheduler داریم:
- Long-Term Scheduler (Job Scheduler)
- Short-term Scheduler (CPU Scheduler/Dispatcher)
- Medium-Term Scheduler
Long-Term: نام دیگر آن Job Scheduler می باشد. مشخص کردن اینکه کدام برنامه ها برای پردازش در سیستم پذیرفته می شوند بر عهده Job Scheduler می باشد. در واقع پردازش ها را از صف ( Queue) انتخاب می کند و آنها را به منظور اجرا شدن در حافظه قرار می دهد. توجه داشته باشید که در سیستم عامل های Time-Sharing، مکانیزم Job Scheduler وجود ندارد.
Short-term: نام دیگر آن CPU Scheduler می باشد. هدف اصلی آن افزایش کارایی (Performing) سیستم بر اساس یکسری معیار می باشد. در واقع تغییر وضعیت پردازش از Ready به Running می باشد. انتخاب یک پردازش از میان پردازش هایی که آماده (Ready) اجرا شدن می باشد و سپس تخصیص CPU به آن پردازش از وظایف CPU Scheduler است. CPU Scheduler همچنین به عنوان Dispatcher شناخته می شود، یعنی یکی دیگر از وظایفش تصمیم گیری و مشخص کردن پردازش بعدی که می خواهد اجرا شود می باشد. سرعت CPU Scheduler به مراتب سریعتر از Job Scheduler است.
Medium-Term: نام دیگر آن Process Swapping Scheduler می باشد و در واقع بخشی از عملیات Swapping می باشد. حذف پردازش ها از حافظه(Memory) بر عهده Medium-Term می باشد. زمانی که یک پردازش در حال اجرا درخواست I/O می کند، آن پردازش وارد حالت معلق Suspend می شود. پردازش های معلق شده (Suspended Process) نمی توانند پیشرفتی در جهت تکمیل فرایند پردازش داشته باشند. در چنین شرایطی به منظور حذف پردازش مورد نظر از حافظه (memory) و ایجاد فضای خالی در حافظه (memory) برای دیگر پردازش ها، آن پردازش معلق شده به یک فضای ثانویه (Secondary Storage) منتقل می گردد. نام این فرایند Swapping می باشد و در اصطلاح Swapped Out و یا Rolled Out می گویند.
Process Control Block
هنگامی که Scheduler، پردازنده (CPU) را از اجرای یک پردازش برای اجرای پردازشی دیگر مجبور به سوییچ کردن میکند، شرایط حال حاضر پردازش در حال اجرا را در PCB نگهداری می کند.
Context Switch
Context Switch مکانیزمی است که شرایط CPU را در PCB نگهداری می کند (Store) و یا از PCB بازگردانی (Restore) می کند، بدین ترتیب اجرای پردازش می تواند مجددا از همان جای قبلی اجرا شود. با استفاده از این تکنیک قابلیت اینکه چندین پردازش یک CPU را به اشتراک بگذارید از طریق Contest Switcher فراهم می شود.
تاکنون با برخی از اصطلاحات مربوط به سیستم عامل (Operating System) بصورت کلی آشنا شدیم. لازم به ذکر است که مطالعه دقیق تر و آشنایی بیشتر شما عزیزان در مورد مفاهیم فوق کمک به درک بهتر انواع معماری (Kernel) خواهد نمود. در ادامه به تشریح انواع معماری (Kernel) خواهیم نمود.
بر اساس معماری و طراحی Kernel، سه نوع Kernel ساخته شده است:
- Monolithic Kernel
- Microkernelized Kernel
- Hybrid Kernel
Monolithic Kernel: در معماری Monolithic تمامی User services و Kernel Services بصورت یک برنامه تک کد و یا یک پردازش بزرگ (Single Large Process) در داخل Kernel Space بارگذاری (load) می شود. تمامی سرویس ها مانند Scheduler, Network Stack, File System, Memory Management, Process Management و Device Drivers در داخل (Kernel Space) قرار می گیرند و از طریق System call وظایفشان انجام می شود، که این امر سبب کاهش زمان دسترسی (Access-Time) و در نتیجه افزایش کارایی (performance) می شود. اما از آنجایی که تمامی سرویس های فوق در داخل (Kernel Space) قرار می گیرند، در نتیجه کد Monolithic Kernel دارای سایز بزرگی نسبت به سایر معماری های Kernel می شود. از آنجایی که تمامی (Driver)ها در داخل (kernel) بارگذاری می شوند لذا در صورت خرابی (Driver) در این نوع از معماری کرنل یعنی (Monolithic Kernel)، کل کرنل (Kernel) نیز تحت تاثیر قرار گرفته و در برخی موارد باعث (PSOD) می شود. این امر به عنوان یکی از معایب معماری (Monolithic Kernel) شناخته می شود. از این رو برخی از کارشناسان معتقدند که این نوع معماری اهمیت کمتری نسبت به سایر معماری ها دارد. از لحاظ قدمت معماری Monolithic نسبت به سایر معماری های kernel بسیار قدیمی تر می باشد. در این نوع معماری به منظور اجرای IPC از Signals و sockets استفاده می شود.
یکی از بزرگترین تفاوت های معماری Monolithic Kernel با سایر معماری های kernel بحث انعطاف پذیری (Flexibility) از لحاظ اضافه کردن قابلیت های جدید می باشد، در معماری (Monolithic) به منظور اضافه کردن قابلیت جدید می بایستی کل (kernel) مجددا Compile شود و یا در (Kernel) های Modular بخشی از (kernel) می بایستی مجددا Compile شود.
یکی از بزرگترین مزایای (Monolithic Kernel) این است که تمامی Kernel Services و User Services از طریق (System Call) انجام می شوند و از (IPC) استفاده نمی نماید که خود باعث افزایش Performance می شود. همچنین طراحی Monolithic Kernel احتیاج به کدنویسی کمتری دارد که در نتیجه (Bug) کمتری هم وجود خواهد داشت. از طرفی در این مدل از معماری زمان Initialize شدن Kernel طولانی تر از سایر معماری هایkernel می باشد.
Microkernelized: در معماری Microkernelized در واقع User service و Kernel service در داخل Kernel space در کنار یکدیگر قرار نمی گیرند. معماری Microkernelized از لحاظ قدمت نسبت به معماری Monolithic جدیدتر می باشد. در این نوع از معماریUser services و Kernel services هر کدام در Address space های جداگانه ای قرار دارند. User services در واقع در user space قرار دارد و Kernel services در Kernel space قرار دارد. به علت جداسازی این دو نوع سرویس حجم Kernel کاهش پیدا می کند، که معمولا Kernel در CPU L1 cache قرار می گیرد. ارتباط میان برنامه های کاربردی (Application) کاربران با سرویس های در حال اجرا در user space از طریق message passing انجام می شود که این امر سبب کاهش سرعت معماری Microkernelized نسبت به معماری Monolithic می شود. از آنجایی که User services از Kernel services جدا شده است لذا در صورت خرابی هر سرویسی که در user space قرار گرفته است روی کارکرد Kernel services تداخل ایجاد نمی کند که این امر یکی از مزایای این معماری می باشد.
یکی از مزایای بزرگ این معماری توسعه پذیر(extendable) بودن آن است. یعنی اگر قابلیت یا سرویس جدیدی قرار باشد اضافه شود، آن قابلیت یا سرویس جدید به user space اضافه می شود و بنابراین لازم نیست Kernel space تغییر کند. از آنجایی که Device Drivers در داخل user space قرار دارند، لذا خرابی Device Drivers بر روی Kernel تاثیری نمی گذارد و از این لحاظ برخی کارشناسان معتقدند که معماری Microkernelized از امنیت بیشتری نسبت به سایر معماری ها برخوردار است. در نسل اول Microkernel، (IPC) به درستی طراحو پیاده سازی نشده بود و همچنین در عملیات Context switch بسیار کند بود، بنابراین این معماری بسیار کند بود.
این معماری به منظور اجرای IPC ، Memory Management و Thread Management در واقع از روش system call استفاده می نماید. در معماری Microkernelized مفهومی به نام Server وجود دارد که در واقع kernel به پردازش های مختلفی خورد می شود که در اصطلاح به آن ها servers می گویند. برخی از این server ها در kernel space اجرا می شوند و برخی دیگر در User Space اجرا می شوند. در واقع server ها توسط ICP-message passing سرویس های یکدیگر را فراخوانی میکنند و به یاد داشته باشید هر Server چه در Kernel Space باشد و چه در User Space باشد دارای Address space مربوط به خود می باشد.
این نوع از معماری به منظور کنترل درخواست های Server از مکانیزم IPC – Message Passing استفاده می نماید و همانگونه که پیش تر توضیح داده شد در این معماری عملیات IPC از طریق System Call صورت می گیرد. وقتی تعداد System Call زیاد می شود زمان زیادی برای عملیات Context Switching صرف می شود که باعث کندی معماری Microkernelized، کمتر مفید واقع شدن و نیز کمتر مورد استفاده قرار گرفتن می شود. این در حالی است که در معماری Monolithic سرویس ها مستقیما از طریق Shared Kernel Memory – System Call در خواست می شوند که این امر موجب افزایش کارایی معماری Monolithic نسبت به معماری Microkernelized می شود. یکی از دلایلی که این ساختار کند می باشد آن است که وقتی یک Server می خواهد با یک Server دیگر ارتباط برقرار کند می بایستی از طریق ICP-Message Passing این کار انجام شود که این امر احتیاج به دریافت Kernel’s Permission دارد، در نتیجه باعث افزایش زمان دسترسی (Access-time)، کاهش کارایی (Performance) و افزایش Overhead سیستم می شود. لذا برخی از متخصصین بر این باورند که معماری Microkernelized مناسب برای سیستم با پردازش های کوچک است چرا که پیچیدگی کمتری برای مدیریت پردازش ها خواهند داشت.
برخی از مشکلات معماری Microkernelized عبارتند از:
- به دلیل نحوه ی ارتباط (Server) ها با یکدیگر احتیاج به Memory بیشتر می باشد.
- مشکلات و ایرادات (Bugs) مربوط به Message Passing به آسانی برطرف نمی شود.
- مدیریت پردازش (Process Management) بسیار پیچیده می باشد.
در قسمت بعدی از سری مقالات برسی انواع معماری (Hypervisor) در مورد اینکه VMware و Hyper-V از کدام معماری استفاده میکنند صحبت خواهیم نمود.
با ما در ارتباط باشید