الأجهزة الافتراضية والأنظمة الموزعة
تغطي هذه الوحدة تقنيات الأجهزة الافتراضية، أنواع الـ Hypervisors، إدارة مكونات نظام التشغيل في بيئة افتراضية، بالإضافة إلى مفاهيم الأنظمة الموزعة وأنظمة الملفات الموزعة (DFS).
Virtual Machines and Distributed Systems
This module covers virtual machine technologies, hypervisor types, OS component management in virtualized environments, as well as distributed systems and distributed file systems (DFS) concepts.
أهداف التعلم
- تحديد فوائد الأجهزة الافتراضية والأنظمة الموزعة.
- شرح تقنيات الأجهزة الافتراضية المختلفة.
- وصف الطرق المستخدمة لتنفيذ المحاكاة الافتراضية.
- تقييم ميزات الأجهزة التي تدعم المحاكاة الافتراضية وكيفية استخدامها بواسطة وحدات نظام التشغيل.
- تحديد أدوار وأنواع الأنظمة الموزعة المستخدمة اليوم.
- وصف المشكلات المتعلقة بتصميم أنظمة الملفات الموزعة.
- Define benefits of virtual machines and distributed systems.
- Explain the various virtual machine technologies.
- Describe the methods used to implement virtualization.
- Evaluate hardware features that support virtualization and explain how they are used by operating-system modules.
- Define the roles and types of distributed systems in use today.
- Describe issues concerning the design of distributed file systems.
1 الأجهزة الافتراضية وأنواع الـ Hypervisors
1 Virtual Machines and Hypervisor Types
الـ Hypervisor (أو VMM) هو الطبقة التي تدير الأجهزة الافتراضية، وتأتي في ثلاثة أنواع رئيسية: 0 (مدمج في العتاد)، 1 (نظام تشغيل مخصص)، و 2 (تطبيق يعمل فوق نظام تشغيل مضيف).
A Hypervisor (VMM) manages VMs and comes in three main types: Type 0 (hardware/firmware), Type 1 (bare-metal/OS-like), and Type 2 (runs on a host OS).
تتنوع تطبيقات إدارة الأجهزة الافتراضية (VMMs):
النوع 0 (Type 0): حلول تعتمد على الأجهزة توفر دعماً لإنشاء وإدارة الأجهزة الافتراضية عبر البرامج الثابتة (Firmware). كل ضيف يحصل على عتاد مخصص (مثل IBM LPARs).
النوع 1 (Type 1): برمجيات تشبه نظام التشغيل تُبنى لتوفير المحاكاة الافتراضية (مثل VMware ESX). تعمل في وضع النواة (Kernel mode) وتدير أنظمة التشغيل الضيفة. يمكن أن تكون أيضاً أنظمة تشغيل عامة توفر وظائف VMM (مثل Windows مع Hyper-V).
النوع 2 (Type 2): تطبيقات تعمل على أنظمة تشغيل قياسية وتوفر ميزات VMM للضيوف. أداؤها أقل لأنها لا تستفيد من بعض ميزات العتاد، لكنها لا تتطلب تغييرات في نظام التشغيل المضيف.
VMM implementations vary greatly:
Type 0: Hardware-based solutions providing VM creation via firmware. Each guest has dedicated HW (e.g., IBM LPARs).
Type 1: OS-like software built to provide virtualization (e.g., VMware ESX). Runs in kernel mode. Can also be general-purpose OSes providing VMM functions (e.g., Windows with Hyper-V).
Type 2: Applications running on standard OSes providing VMM features. Tend to have poorer performance due to lack of HW feature utilization, but require no changes to the host OS.
الفرق الجوهري يكمن في مستوى الوصول إلى العتاد.
النوع 1 يوفر أداءً أعلى بكثير لأنه يتخاطب مباشرة مع العتاد، مما يجعله المعيار في مراكز البيانات (Datacenters). بينما النوع 2 يعتمد على نظام التشغيل المضيف لجدولة الموارد، مما يضيف طبقة من التأخير (Overhead).
The core difference lies in hardware access level.
Type 1 offers significantly higher performance by communicating directly with hardware, making it the standard for datacenters. Type 2 relies on the host OS for resource scheduling, adding overhead.
| Type 0 | Type 1 | Type 2 | |
|---|---|---|---|
| مستوى التنفيذExecution Level | البرامج الثابتة (Firmware) / العتادFirmware / Hardware | مباشرة على العتاد (Bare-metal) / وضع النواةBare-metal / Kernel mode | كتطبيق فوق نظام تشغيل مضيفApplication on host OS |
| الأداءPerformance | عالي جداً (موارد مخصصة)Very High (Dedicated resources) | عالي (وصول مباشر للعتاد)High (Direct HW access) | أقل (بسبب طبقة نظام التشغيل المضيف)Lower (Overhead from host OS) |
لماذا يُعتبر النوع 1 من الـ Hypervisors بمثابة 'نظام تشغيل لمركز البيانات'؟ Why is a Type 1 Hypervisor considered a 'datacenter operating system'?
لأنه يدير العتاد مباشرة ويتحكم في أنظمة تشغيل متعددة، مما يسمح بدمج الخوادم، موازنة الأحمال، ونقل الأجهزة الافتراضية بين الخوادم المادية بكفاءة عالية.
Because it manages hardware directly and controls multiple OSes, allowing for server consolidation, load balancing, and efficient migration of VMs across physical servers.
2 تقنيات المحاكاة الافتراضية البديلة
2 Alternative Virtualization Techniques
ليست كل المحاكاة الافتراضية تكراراً تاماً للعتاد؛ تشمل البدائل المحاكاة شبه الافتراضية (Paravirtualization)، المحاكاة (Emulation)، واحتواء التطبيقات (Application Containment).
Not all virtualization is an exact hardware duplication; alternatives include Paravirtualization, Emulation, and Application Containment.
المحاكاة شبه الافتراضية (Paravirtualization): يتم تعديل نظام التشغيل الضيف ليعمل بالتعاون مع VMM لتحسين الأداء (مثل Xen). يستخدم مخازن مؤقتة دائرية مشتركة (Circular buffers) للإدخال/الإخراج الفعال.
المحاكاة (Emulation): تترجم التعليمات من معالج الضيف إلى معالج المضيف. مفيدة لتشغيل أنظمة مصممة لبنية مختلفة، لكنها أبطأ بكثير.
احتواء التطبيقات (Application Containment): لا توفر محاكاة افتراضية كاملة، بل تعزل التطبيقات عن نظام التشغيل (مثل Oracle Solaris Zones). تعمل نواة واحدة فقط (نظام المضيف)، وتُقسم الموارد بين 'المناطق' (Zones).
Paravirtualization: Guest OS is modified to cooperate with the VMM to optimize performance (e.g., Xen). Uses shared circular buffers for efficient I/O.
Emulation: Translates guest instructions from guest CPU to native CPU. Useful for running OSes compiled for different architectures, but significantly slower.
Application Containment: Not full virtualization; segregates applications from the OS (e.g., Oracle Solaris Zones). Only one kernel runs (host OS), and resources are divided between zones.
مع تطور دعم العتاد للمحاكاة الافتراضية في المعالجات الحديثة، تراجعت الحاجة إلى المحاكاة شبه الافتراضية (Paravirtualization) لأن العتاد أصبح يتعامل مع التعليمات المعقدة بكفاءة دون الحاجة لتعديل نظام التشغيل الضيف.
As hardware support for virtualization has grown in modern CPUs, the need for Paravirtualization has decreased because the hardware now handles complex instructions efficiently without requiring guest OS modifications.
متى يكون استخدام 'احتواء التطبيقات' (Application Containment) أفضل من الأجهزة الافتراضية الكاملة؟ When is using 'Application Containment' better than full virtual machines?
عندما تكون جميع التطبيقات مصممة للعمل على نفس نظام التشغيل المضيف، ونحتاج فقط إلى العزل وإدارة الموارد بأقل قدر من استهلاك الموارد (Overhead) وبدون الحاجة لتشغيل أنظمة تشغيل كاملة متعددة.
When all applications are compiled for the host OS, and we only need segregation and resource management with minimal overhead, without the need to run multiple full guest OSes.
3 مكونات نظام التشغيل في المحاكاة الافتراضية
3 OS Components in Virtualization
يجب على VMM إدارة جدولة وحدة المعالجة المركزية (CPU)، الإدخال/الإخراج (I/O)، التخزين، وتوفير ميزات متقدمة مثل الترحيل الحي (Live Migration).
The VMM must manage CPU scheduling, I/O, storage, and provide advanced features like Live Migration.
جدولة CPU: غالباً ما يكون هناك التزام زائد (Overcommitment) بوحدات المعالجة المركزية، مما يؤدي إلى 'سرقة الدورات' (Cycle stealing) وتأخير استجابة الضيف. قد تصبح ساعات النظام غير دقيقة.
الإدخال/الإخراج (I/O): معقد بالنسبة لـ VMM. يشمل الحلول: الوصول المباشر للأجهزة، تمرير DMA، وترجمة عناوين الشبكة (NAT).
التخزين: يوفر VMM أقراص إقلاع وبيانات للضيوف، غالباً كملفات صور (Disk images) في نظام ملفات المضيف (النوع 2) أو نظام ملفات VMM (النوع 1).
الترحيل الحي (Live Migration): نقل جهاز افتراضي قيد التشغيل من خادم مادي إلى آخر دون مقاطعة المستخدم. يتم ذلك عبر إرسال صفحات الذاكرة للقراءة فقط، ثم صفحات القراءة/الكتابة، وتكرار إرسال الصفحات المعدلة (Dirty pages) حتى تصبح الدورة قصيرة جداً، فيتم تجميد الضيف ونقل الحالة النهائية.
CPU Scheduling: Often involves CPU overcommitment, leading to cycle stealing and poor guest response times. Time-of-day clocks may become incorrect.
I/O: Complicated for VMMs. Solutions include direct device access, DMA pass-through, and Network Address Translation (NAT).
Storage: VMM provides boot and data disks, often as disk image files in the host OS (Type 2) or VMM file system (Type 1).
Live Migration: Moving a running VM between physical servers without interrupting user access. Done by sending read-only memory pages, then read-write pages, and iteratively sending modified (dirty) pages until the cycle is very short, at which point the guest is frozen and final state is transferred.
الترحيل الحي يعتمد بشكل كبير على مفهوم 'الصفحات المتسخة' (Dirty Pages).
التحدي الأكبر هو سرعة تغيير الذاكرة بواسطة الضيف مقارنة بسرعة نقل الشبكة. إذا كان الضيف يكتب على الذاكرة أسرع من سرعة الشبكة، فلن يكتمل الترحيل أبداً دون إيقاف الضيف لفترة أطول.
Live migration heavily relies on tracking 'Dirty Pages'.
The biggest challenge is the memory dirtying rate vs. network bandwidth. If the guest modifies memory faster than the network can transfer it, the migration will never converge without a longer freeze time.
كيف يؤثر الالتزام الزائد (Overcommitment) لوحدة المعالجة المركزية على دقة الوقت داخل الجهاز الافتراضي؟ How does CPU overcommitment affect time accuracy inside a virtual machine?
عندما يقوم VMM بسرقة دورات المعالجة (Cycle stealing)، فإن نظام التشغيل الضيف يتوقع أن الوقت يمر بشكل طبيعي بناءً على المقاطعات، لكنه في الواقع يكون متوقفاً مؤقتاً، مما يؤدي إلى تأخر ساعة النظام (Time-of-day clock) عن الوقت الحقيقي.
When the VMM steals cycles, the guest OS expects time to pass normally based on interrupts, but it is actually paused. This causes the guest's time-of-day clock to drift and become incorrect.
4 نظرة عامة على الأنظمة الموزعة وقضايا التصميم
4 Distributed Systems Overview and Design Issues
النظام الموزع هو مجموعة من العقد (Nodes) المترابطة بشكل فضفاض عبر شبكة، تهدف إلى مشاركة الموارد، تسريع الحوسبة، وزيادة الموثوقية.
A distributed system is a collection of loosely coupled nodes interconnected by a network, aiming for resource sharing, computation speedup, and reliability.
أسباب استخدام الأنظمة الموزعة: مشاركة الموارد (ملفات، طابعات، قواعد بيانات)، تسريع الحوسبة (توزيع العمليات الفرعية)، موازنة الأحمال، والموثوقية (اكتشاف الفشل والتعافي منه).
قضايا التصميم:
- المتانة (Robustness): قدرة النظام على تحمل الأعطال. يتطلب اكتشاف الفشل (عبر بروتوكول نبض القلب Heartbeat)، إعادة التكوين، والتعافي.
- الشفافية (Transparency): يجب أن يبدو النظام للمستخدم كنظام مركزي تقليدي (مثل إخفاء موقع الملفات).
- قابلية التوسع (Scalability): قدرة النظام على استيعاب إضافة موارد جديدة بسلاسة عند زيادة الطلب.
Reasons for Distributed Systems: Resource sharing (files, printers, databases), computation speedup (distributing subcomputations), load balancing, and reliability (detecting and recovering from site failure).
Design Issues:
- Robustness: Ability to withstand failures. Involves failure detection (via heartbeat protocol), reconfiguration, and recovery.
- Transparency: The system should appear as a conventional, centralized system to the user (e.g., hiding file locations).
- Scalability: The system should easily accept the addition of new resources to accommodate increased demand gracefully.
اكتشاف الفشل في الأنظمة الموزعة معقد جداً.
إذا لم تتلق العقدة (أ) رداً من العقدة (ب)، فلا يمكنها تحديد ما إذا كانت (ب) قد تعطلت، أم أن الرابط المباشر تعطل، أم أن الرسالة فُقدت في الشبكة. هذا يتطلب خوارزميات إجماع (Consensus) وبروتوكولات معقدة لإعادة التكوين.
Failure detection in distributed systems is inherently ambiguous.
If Node A doesn't receive a reply from Node B, it cannot definitively know if Node B crashed, the link failed, or the message was lost. This ambiguity necessitates complex consensus algorithms and reconfiguration protocols.
لماذا تعتبر 'الشفافية' سيفاً ذو حدين في الأنظمة الموزعة؟ Why is 'Transparency' a double-edged sword in distributed systems?
لأنها تسهل الاستخدام على المستخدم النهائي، لكنها قد تخفي مشاكل الأداء أو أعطال الشبكة، مما يجعل من الصعب على المطورين أو مديري النظام استكشاف الأخطاء وإصلاحها (Troubleshooting) عند حدوث بطء في الوصول للموارد البعيدة.
While it makes the system easy for end-users, it can hide performance issues or network failures, making it difficult for developers or admins to troubleshoot when remote resource access becomes slow.
5 أنظمة الملفات الموزعة (DFS)
5 Distributed File Systems (DFS)
نظام الملفات الموزع (DFS) يخزن الملفات عبر أجهزة متعددة في الشبكة ولكنه يظهر للمستخدم كنظام ملفات محلي واحد.
A Distributed File System (DFS) stores files across multiple machines in a network but appears to the user as a single local file system.
نماذج DFS:
- نموذج الخادم والعميل (Client-Server): يخزن الخادم الملفات والبيانات الوصفية (Metadata). يتصل العملاء بالخادم لطلب الملفات. يعاني من نقطة فشل واحدة (Single point of failure) وعنق زجاجة في الأداء (مثل NFS).
- النموذج القائم على الكتلة (Cluster-based): أكثر متانة وقابلية للتوسع (مثل GFS و HDFS). يتصل العملاء بخادم بيانات وصفية رئيسي (Master metadata server) وعدة خوادم بيانات تحتفظ بـ 'أجزاء' (Chunks) من الملفات. يتم نسخ الأجزاء عدة مرات لضمان الموثوقية.
DFS Models:
- Client-Server Model: Server stores files and metadata. Clients contact the server to request files. Suffers from a single point of failure and bottleneck issues (e.g., NFS).
- Cluster-Based Model: Built to be more fault-tolerant and scalable (e.g., GFS, HDFS). Clients connect to a master metadata server and several data servers holding file 'chunks'. Chunks are replicated n times for reliability.
تم تصميم GFS بناءً على ملاحظة أن فشل العتاد هو القاعدة وليس الاستثناء، وأن الملفات كبيرة جداً، وغالباً ما يتم تعديلها بإلحاق البيانات (Appending) بدلاً من الكتابة الفوقية (Overwriting).
هذا أدى إلى تصميم يتخلى عن معايير POSIX الصارمة لصالح الأداء وقابلية التوسع.
GFS was designed on the observation that hardware failures are the norm, files are huge, and mutations are mostly appends rather than overwrites.
This led to a design that sacrifices strict POSIX compliance in favor of massive scalability and performance for specific workloads.
| Client-Server DFS | Cluster-Based DFS | |
|---|---|---|
| نقطة الفشلPoint of Failure | نقطة فشل واحدة (الخادم)Single point of failure (Server) | متسامح مع الأخطاء (نسخ متعددة للأجزاء)Fault-tolerant (Replicated chunks) |
| قابلية التوسعScalability | محدودة (عنق زجاجة في الخادم)Limited (Server bottleneck) | عالية جداً (توزيع البيانات على خوادم متعددة)Very High (Data distributed across servers) |
لماذا يعتبر نموذج Cluster-based أفضل من Client-Server في التعامل مع البيانات الضخمة (Big Data)؟ Why is the Cluster-based model better than Client-Server for handling Big Data?
لأنه يوزع حمل الإدخال/الإخراج عبر خوادم بيانات متعددة، ويتجنب عنق الزجاجة الموجود في الخادم الواحد، كما يوفر تكراراً (Replication) مدمجاً للأجزاء لتحمل أعطال العتاد الشائعة في الأنظمة الضخمة.
Because it distributes I/O load across multiple data servers, avoiding the single-server bottleneck, and provides built-in chunk replication to tolerate hardware failures common in massive systems.
6 التخزين المؤقت والاتساق في أنظمة الملفات الموزعة
6 DFS Caching and Consistency
يقلل التخزين المؤقت (Caching) من حركة مرور الشبكة، لكنه يخلق تحدياً في الحفاظ على اتساق (Consistency) النسخ المخبأة مع الملف الأصلي.
Caching reduces network traffic but creates the challenge of keeping cached copies consistent with the master file.
موقع التخزين المؤقت: يمكن أن يكون في القرص (أكثر موثوقية، يبقى بعد التعافي) أو في الذاكرة الرئيسية (أسرع، يسمح بمحطات عمل بدون أقراص).
سياسات التحديث:
- Write-through: كتابة البيانات للقرص فوراً (موثوق لكن أداؤه ضعيف).
- Delayed-write (Write-back): التعديلات تُكتب في الذاكرة المؤقتة وتُنقل للخادم لاحقاً (سريع لكن موثوقيته ضعيفة إذا تعطل الجهاز).
- Write-on-close: تُكتب البيانات للخادم عند إغلاق الملف.
الاتساق (Consistency):
- بمبادرة العميل (Client-initiated): العميل يتحقق من صحة البيانات.
- بمبادرة الخادم (Server-initiated): الخادم يسجل من يمتلك النسخ ويتفاعل عند اكتشاف عدم اتساق.
Cache Location: Can be on Disk (more reliable, survives recovery) or Main Memory (faster, permits diskless workstations).
Update Policies:
- Write-through: Write data to disk immediately (reliable, poor performance).
- Delayed-write (Write-back): Modifications written to cache and sent to server later (fast, poor reliability on crash).
- Write-on-close: Writes data back to server when file is closed.
Consistency:
- Client-initiated: Client initiates validity check.
- Server-initiated: Server records which clients cache files and reacts to potential inconsistencies.
في الأنظمة القائمة على الكتل (Cluster-based)، تصبح مشكلة الاتساق أكثر تعقيداً بسبب وجود خادم بيانات وصفية وأجزاء ملفات منسوخة.
HDFS يبسط ذلك بالسماح بعمليات الكتابة الإلحاقية فقط (Append-only) وكاتب واحد للملف، بينما GFS يسمح بالكتابة العشوائية مع كتاب متزامنين، مما يعقد ضمانات الاتساق.
In cluster-based DFS, consistency is complicated by metadata servers and replicated chunks.
HDFS simplifies this by allowing only append-only writes and a single file writer. GFS allows random writes with concurrent writers, which significantly complicates write consistency guarantees.
| Write-through | Delayed-write (Write-back) | |
|---|---|---|
| الموثوقيةReliability | عالية (البيانات آمنة على القرص فوراً)High (Data safe on disk immediately) | ضعيفة (قد تفقد البيانات عند التعطل)Poor (Data lost on crash) |
| الأداءPerformance | ضعيف (ينتظر الكتابة على القرص)Poor (Waits for disk write) | سريع (يكتب في الذاكرة المؤقتة فقط)Fast (Writes to cache only) |
لماذا اختار مصممو HDFS تقييد الكتابة لتكون 'إلحاقية فقط' (Append-only)؟ Why did HDFS designers choose to restrict writes to 'append-only'?
لتبسيط إدارة الاتساق (Consistency) بشكل كبير في بيئة موزعة ضخمة. الكتابة العشوائية من عدة عملاء تتطلب أقفالاً معقدة وتزامناً يقلل من الأداء، بينما الإلحاق يضمن عدم تعارض البيانات المكتوبة مسبقاً.
To drastically simplify consistency management in a massive distributed environment. Random writes from multiple clients require complex locking and synchronization that degrade performance, whereas appends ensure previously written data is never conflicted.