في منشور سابق ناقشت حاويات / مناطق سولاريس ولماذا كانت فكرة جيدة. يحتوي Solaris على طبقة أخرى من المحاكاة الافتراضية تسمى المجالات المنطقية أو LDOMS. قامت Oracle بتغيير علامتها التجارية إلى 'Oracle VM Server for SPARC' ولكن في معظم الأسباب يكون من الأسهل تسميتها بـ LDOMs. يكفي عن التسمية بالرغم من ذلك. ما هذه بالضبط ولماذا تحتاج إلى طبقة أخرى من المحاكاة الافتراضية؟
تشبه وحدات LDOM الخاصة بـ Solaris المحاكاة الافتراضية بالطريقة التي يوفرها بها برنامج VMware. لديك حاويات فريدة ومجزأة بالكامل. يمكن لهذه الأنظمة تشغيل أنظمة تشغيل أو إصدارات مختلفة تمامًا من Solaris. إذا كنت تتذكر من مقالة مناطق سولاريس ، فإن المناطق غير العالمية (NGZ) تشترك في نفس نواة المنطقة العالمية (GZ) التي تستضيفها. يمكنك تشغيل إصدار قديم من NGZ على GZ ولكن يتم ذلك من خلال مكتبة توافق تحاكيها. يتيح لك LDOM الحصول على مثيل فريد.
يتطلب LDOM أن يدعم المعالج المحاكاة الافتراضية. بالنسبة لـ SPARC ، تعتمد هذه المعالجات بشكل أساسي على بنية sunv4. من السهل تذكر / تحديد معالجات Sparc T ، سواء كانت T1-T7 على الرغم من وجود معالجات أخرى تدعم ذلك. لـ x86 / x64. بدأت Solaris ، في الإصدارات الأخيرة ، في دعم هذه التقنية لـ x86 / x64 أيضًا ، لكننا سنركز على معالجات SPARC لهذه المقالة.
في هذه المرحلة ، ربما تسأل نفسك ، هذا رائع ولكن لماذا نحتاج إلى طبقات متعددة من المحاكاة الافتراضية؟ تعد LDOMs رائعة إذا كنت بحاجة إلى بيئة معزولة حقًا. ربما لديك إصدارات محددة من Solaris تحتاجها لأغراض محددة؟ على سبيل المثال ، إذا كان لديك مكدس إنتاج يتطلب Solaris 11.1 لقاعدة البيانات و Solaris 10 للتطبيق ، فيمكنك بسهولة إعداد نطاق ضيف LDOM لكل منها حتى تتمكن من تشغيل تلك الإصدارات المحددة. ربما يكون تطبيقك عبارة عن 5-6 تطبيقات مختلفة تحتاج إلى طبقة معينة من التقسيم لأنها لا يمكن أن تتواجد في نفس مثيل نظام التشغيل. يمكنك إعداد كل واحدة في منطقة منفصلة لتحقيق ذلك.
كما هو موضح أعلاه ، هناك حالة استخدام أخرى لعمليات الترحيل. عندما يحين وقت إهمال الأجهزة القديمة ولكنك لا تزال بحاجة إلى إصدارات Solaris الأقدم لأن تطبيقك لن يعمل على إصدار أحدث أو ربما يكون غير مدعوم / غير معتمد في الإصدار الأحدث ولا ترغب في التعامل مع هذا السيناريو. يعد تدوير LDOMs والمناطق طريقة سهلة وخفيفة الوزن لتحقيق ذلك نظرًا لأن قوة المعالجة وذاكرة الوصول العشوائي عادة ما تكون زائدة.
لتحقيق ذلك ، هناك 5 أدوار رئيسية لـ LDOM. مجال التحكم ومجال الخدمة ومجال الإدخال / الإخراج ومجال الجذر ومجال الضيف. مجال التحكم مسؤول عن إدارة LDOMs المستضافة على الخادم الفعلي. عادة ما يتم دمجه مع مجال الخدمة المسؤول عن تقديم موارد معينة إلى مجال الضيف مثل الأقراص. مجال الضيف هو نظام تشغيل Virtual Server Guest Guest قيد التشغيل. هذا يترك المجال الجذر ومجال I / O. عادةً ما يتم دمج هذين النوعين في مجال التحكم أيضًا. هم مسؤولون عن توفير الوصول إلى حافلات PCI / PCIe. من المهم ملاحظة أن Guest Domain عادةً ما يكون المكان الوحيد الذي تريد تثبيت تطبيقات عملك لتقسيم البيئة بشكل صحيح.
مثل الكثير من برامج Hypervisors الأخرى ، يمكن ترحيل LDOMs مباشرة من خادم فعلي إلى آخر طالما أن لديهم مساحة تخزين مشتركة ويمكن لكل خادم رؤية نفس أجهزة التخزين. يمكن أن يكون هذا مفيدًا للغاية إذا كان لديك LDOM الذي يمضغ من خلال الموارد وتحتاج إلى التوازن. عند إعداد LDOMs ، يمكنك أيضًا إعداد أي حدود تريدها لكل منها من حيث ذاكرة الوصول العشوائي ووحدة المعالجة المركزية وما إلى ذلك.
تأتي بعض الدوافع الرئيسية لاستخدام كل من طبقات المحاكاة الافتراضية هذه في قوة المعالجة وسعة ذاكرة الوصول العشوائي التي تفوق احتياجات التطبيق الفعلية. على سبيل المثال ، شاركت في عملية ترحيل مكثفة لمركز بيانات Solaris حيث تمكنوا من استبدال 30 رفًا من خوادم SPARC وشبكات SAN ومفاتيح الشبكة وصولاً إلى 6 رفوف من المعدات و 5 خوادم SPARC الإجمالية. مع خوادم SPARC الخمسة هذه ، يتم استضافة بضع مئات من المناطق من خلال عشرات LDOMs. الإدارة أكثر بساطة نظرًا لوجود 5 خوادم فعلية فقط لإدارتها. إذا احتاجت منطقة أو LDOM إلى الارتداد ، فإن أوامر zoneadm أو ldm تكون في متناول اليد بسهولة دون الحاجة إلى إرسال شخص ما إلى أرضية مركز البيانات أو تذكر تفاصيل اتصال ILOM.
يمكن أن ترتبط إدارة LDOMs بالتحكم في الوصول المستند إلى الدور (RBAC). ربما تريد منح بعض المسؤولين حق الوصول لتعديل LDOMs ولكن مع مسؤولي المستوى الأدنى إلى مجالات / مناطق الضيف. سهل التنفيذ ومهم حتى تتمكن من تقييد من لديه حق الوصول لإحداث تغييرات في التكوين على نطاق واسع.
3 دقائق للقراءة
