الفصل : 14
الجزء : 3
العنوان : ال Hyper-V
ال Hyper-V console و Remote Desktop Protocol (RDP) أو PowerShell
في حين أن التعديلات على الأجهزة للـ VMs تحتاج إلى أن تتم من خلال Hyper-V Manager، فإن تفاعلك اليومي مع هذه الـ VMs التي تعمل كخوادم في بيئتك لا يعني بالضرورة أنك يجب أن تسجل الدخول إلى خادم Hyper-V الخاص بك. إذا كنت داخل Hyper-V Manager على أي حال، يمكنك بسهولة وسرعة استخدام وظيفة Connect للتفاعل مع وحدة التحكم في خوادمك، من خلال استخدام أداة Hyper-V console. يكون الوصول إلى خوادمك بهذه الطريقة مفيدًا إذا كنت بحاجة إلى رؤية شيء في BIOS، أو غير ذلك خارج نظام التشغيل Windows الذي يعمل على هذا الـ VM، ولكن ليس غالبًا ما تحتاج إلى هذا المستوى من الوصول إلى وحدة التحكم.
عندما يكون لديك خوادم Windows تعمل كـ VMs، من الشائع أكثر التفاعل مع هذه الخوادم بنفس الطريقة التي تتفاعل بها مع الخوادم الفعلية على شبكتك. بينما كنت أستخدم Hyper-V console للوصول إلى خادم WEB3 في هذا الفصل، الآن بعد أن قمت بتثبيت Windows Server 2022 على WEB3 وقمت بتمكين قدرات RDP عليه، لا يوجد سبب يمنعني من استخدام MSTSC لتسجيل الدخول إلى WEB3 بهذه الطريقة، مباشرة من سطح مكتب محطة العمل الخاصة بي:
ينطبق نفس الأمر على PowerShell أو أي طريقة تقليدية أخرى للوصول عن بُعد إلى الخدمات على أي خادم آخر. نظرًا لأن هذا الـ VM متصل تمامًا ولديه نظام تشغيل الخادم مثبت، يمكنني استخدام PowerShell remoting للتلاعب بخادم WEB3 الخاص بي أيضًا، من خادم آخر أو من جهاز الكمبيوتر المكتبي الخاص بي. بمجرد الانتهاء من بناء الأجهزة وتثبيت نظام التشغيل على VM، نادرًا ما تحتاج فعليًا إلى استخدام Hyper-V console للتفاعل مع ذلك الخادم. الأسباب الرئيسية لفتح Hyper-V Manager للوصول إلى VM هي إجراء تغييرات على مستوى الأجهزة على ذلك الخادم، مثل إضافة قرص صلب، أو تعديل RAM، أو نقل اتصال الشبكة من virtual switch إلى آخر.
ال Windows Admin Center (WAC)
لقد رأينا WAC منتشرًا في جميع أنحاء هذا الكتاب ولسبب وجيه. WAC هو الأداة الجديدة الفائقة التي تريد Microsoft من مديري الخوادم البدء في استخدامها للتفاعل مع وإدارة كل خادم من خوادمهم تقريبًا. خوادم VM المستضافة في Hyper-V ليست استثناء؛ يمكنك استخدام مجموعة أدوات WAC لإدارة الخوادم التي تعمل على مضيفات Hyper-V الخاصة بك واستخدام WAC لإدارة خوادم المضيف نفسها.
ال Shielded VMs
إذا لم يكن عملك اليومي يشمل العمل مع Hyper-V، فمن المحتمل أنك لم تسمع أبدًا عن Shielded VMs. الاسم يشرح هذه التقنية بشكل جيد على مستوى أساسي. إذا كان الـ VM هو آلة افتراضية، فإن Shielded VM يجب أن تكون آلة افتراضية محمية أو مؤمنة بطريقة ما، صحيح؟ Shielded VM هي في الأساس VM مشفرة. بالأحرى، ملف القرص الصلب نفسه (VHDX) مشفر باستخدام BitLocker. يبدو الأمر بسيطًا، ولكن هناك بعض المتطلبات الجيدة لتحقيق ذلك. لكي تعمل تشفير BitLocker بشكل صحيح، يتم حقن VM بشريحة Trusted Platform Module (TPM) افتراضية. تصبح TPMs شائعة بسرعة على مستوى الأجهزة، ولكن استخدامهم لا يزال غامضًا للعديد من المديرين. يمكن أيضًا قفل Shielded VMs بحيث يمكن تشغيلها فقط على الخوادم المضيفة الصحية والمعتمدة، وهي ميزة مذهلة لأولئك الذين يهتمون بالأمان بيننا. يتم توفير هذه القدرة من خلال بعض خيارات attestation المختلفة، والتي سنناقشها قريبًا.
لشرح الفوائد التي تقدمها Shielded VMs، سننظر في مثال لما يحدث عندما لا تكون الـ VMs محمية. ضع في اعتبارك أن فكرة Shielded VMs تصبح أكثر أهمية عندما تفكر في سياق الخوادم المستضافة في السحابة حيث لا يكون لديك أي وصول إلى الجزء الخلفي، أو مستضافة بواسطة قسم آخر داخل شركتك، مثل داخل السحابة الخاصة. ما لم تكن قد خصصت الوقت لنشر جميع Shielded VMs في بيئتك، ما سأعرضه عليك حاليًا ممكن على أي من الـ VMs الحالية لديك.
أنت تعلم بالفعل أنني أشغل خادم Hyper-V، وعلى هذا الخادم لدي آلة افتراضية تسمى WEB3. الآن، دعنا نتظاهر بأنني مزود استضافة سحابية وأن WEB3 هو خادم ويب ينتمي إلى أحد مستأجري. لقد قدمت لمستأجري مفتاحًا افتراضيًا خاصًا للشبكة حتى يتمكن من إدارة شبكة ذلك الخادم، وليس لدي وصول إلى ذلك الـ VM على مستوى الشبكة. أيضًا، من الحقائق أن هذا الخادم WEB3 متصل بمجال وشبكة مستأجري، وليس لدي، كمضيف سحابي، أي وصول إلى بيانات الاعتماد الخاصة بالمجال، أو أي وسائل أخرى يمكنني استخدامها لتسجيل الدخول فعليًا إلى ذلك الخادم.
يبدو الأمر جيدًا حتى الآن، أليس كذلك؟ بالتأكيد، كمستأجر، لن ترغب في أن يتمكن مزود السحابة من التجسس داخل آلاتك الافتراضية التي يتم استضافتها على تلك السحابة. كما أنك لن ترغب في أن يتمكن أي مستأجرين آخرين قد يكون لديهم VMs تعمل على نفس المضيف السحابي من رؤية خوادمك بأي طريقة. تنطبق نفس العقلية في السحب الخاصة أيضًا. إذا كنت تستضيف سحابة خاصة وتسمح لشركات مختلفة أو أقسام من شركة أن يكون لديها VMs منفصلة تعمل في نفس البنية التحتية، سترغب في التأكد من أن تلك الأقسام لديها طبقات أمان حقيقية بين الـ VMs، وبين الـ VMs والمضيف.
الآن، دعنا نستمتع قليلًا ونتحول إلى الأشرار. أنا موظف مستضيف سحابي غير صالح، وقررت أن أسبب بعض الأضرار قبل مغادرة الوظيفة. سيكون من السهل بالنسبة لي القضاء تمامًا على ذلك الخادم WEB3 لأن لدي وصول إلى وحدة التحكم الإدارية للمضيف. ومع ذلك، من المحتمل أن يشير هذا إلى مشكلة في مكان ما، وسيقوم المستأجر ببساطة بإنشاء خادم ويب جديد أو استعادته من النسخة الاحتياطية. لذا، من الأفضل من كسر الـ VM، سأبقيه قيد التشغيل ثم أغير محتوى الموقع نفسه. دعنا نعطي عملاء هذه الشركة شيئًا يتحدثون عنه!
للتلاعب بموقع الويب الخاص بمستأجري الذي يعمل على WEB3، لا أحتاج إلى أي وصول حقيقي إلى الـ VM نفسه لأن لدي وصول مباشر إلى ملف القرص الصلب الافتراضي. كل ما أحتاجه هو الوصول إلى ملف القرص الصلب الافتراضي، تعديل الموقع، ويمكنني جعل الموقع يعرض أي معلومات أريدها.
أولاً، أسجل الدخول إلى خادم Hyper-V (تذكر، هذا مملوك لي لأنني المضيف)، وأتصفح إلى موقع ملف VHD الذي يستخدمه WEB3. كل هذا يحدث في الخلفية، لذلك لا أحتاج إلى بيانات اعتماد المستأجر للوصول إلى هنا. علاوة على ذلك، لا يتم تسجيل أي شيء من هذه الإجراءات ولن يعرف المستأجر أنني أفعل ذلك. ببساطة أنقر بزر الماوس الأيمن على ذلك VHD وأختار Mount:
الآن بعد أن تم تثبيت VHD على نظام تشغيل الخادم المضيف مباشرة، يمكنني تصفح القرص الصلب لذلك الـ VM كما لو كان أحد أقراصي الخاصة. التنقل إلى مجلد wwwroot للعثور على ملفات الموقع، وتغيير الصفحة الافتراضية لعرض أي شيء تريده:
عند الانتهاء من اللعب بالموقع، يمكنني فتح Disk Management، والنقر بزر الماوس الأيمن على ذلك القرص المثبت، واختيار Detach VHD لتغطية آثاري:
ثم، لمجرد المتعة، أنسخ ملف VHD بالكامل على وحدة تخزين USB حتى أتمكن من العبث به أكثر لاحقًا.
هذا المثال يقطع إلى جوهر سبب تردد العديد من الشركات بشأن منصات استضافة الخوادم وهو بالضبط سبب بدء Microsoft في تصميم شيء يعرف بـ Shielded VMs.
تشفير VHDs
فكرة الآلات الافتراضية المحمية (shielded VMs) بسيطة جدًا. مايكروسوفت لديها بالفعل تقنية تشفير الأقراص الممتازة، تسمى BitLocker. الآلات الافتراضية المحمية هي Hyper-V VMs التي تحتوي على تشفير BitLocker للأقراص. عندما يكون ملف VHD بالكامل محميًا ومشفرًا بـ BitLocker، لن يتمكن أحد من الوصول إلى ذلك القرص عبر طرق غير شرعية. محاولة تركيب (mount) ملف VHD كما فعلنا سابقًا ستؤدي إلى ظهور رسالة خطأ، ولن يحدث شيء أكثر من ذلك.
الأفضل من ذلك هو أنه عند إعداد البنية التحتية لدعم الآلات الافتراضية المحمية، يتم أيضًا حظر الوصول إلى وحدة التحكم (console) للآلات الافتراضية المحمية عبر Hyper-V. بينما لا يعد هذا بقدر أهمية تشفير القرص، فإنه لا يزال مهمًا بما يكفي للإشارة إليه. إذا كان لدى شخص ما وصول إلى خادم Hyper-V وفتح Hyper-V Manager، فسيكون لديه عمومًا القدرة على استخدام وظيفة الاتصال (Connect) على الآلات الافتراضية التابعة لعرض ما هو موجود حاليًا على وحدة التحكم. غالبًا، سيجدون أنفسهم ينظرون إلى شاشة تسجيل الدخول التي، نأمل، لن يتمكنوا من اختراقها. ولكن إذا كانت وحدة تحكم الآلة الافتراضية قد تُركت في حالة تسجيل دخول، فسيكون لديهم وصول فوري للتلاعب بالآلة الافتراضية، حتى لو كان القرص مشفرًا.
لذا عند إنشاء آلة افتراضية محمية، لا يتم فقط تشفير ملف VHD باستخدام تقنية BitLocker، بل يتم أيضًا حظر جميع الوصول إلى وحدة التحكم للآلة الافتراضية من Hyper-V Manager.
متطلبات البنية التحتية للآلات الافتراضية المحمية
هناك بعض الأجزاء المهمة في هذا اللغز التي تحتاج إلى معرفتها إذا كنت مهتمًا بتشغيل الآلات الافتراضية المحمية.
الخوادم المحمية
ستحتاج إلى تشغيل خادم أو أكثر محمي لاستضافة الآلات الافتراضية المحمية الخاصة بك. الخوادم المحمية هي في الأساس Hyper-V Servers محسنة. ستستضيف الآلات الافتراضية مثل أي خادم Hyper-V آخر، لكنها مصممة ومُعَدّة خصيصًا لاستضافة هذه الآلات الافتراضية المشفرة والمحمية ولتصديق صحتها كجزء من استراتيجية الأمان الشاملة هذه.
يجب أن تكون الخوادم المحمية تعمل بنظام Server 2016 أو 2019 أو 2022 Datacenter، وعادة ما تريدها أن تقلع باستخدام UEFI وتحتوي على شريحة TPM 2.0. في حين أن TPM 2.0 ليست شرطًا صارمًا، إلا أنها موصى بها بالتأكيد. تحل هذه الخوادم المحمية محل خوادم Hyper-V التقليدية. وظيفتها هي استضافة الآلات الافتراضية المحمية.
خدمة Host Guardian Service (HGS)
ال HGS هي خدمة تعمل على خادم، أو عادة، مجموعة من ثلاثة خوادم، وتتعامل مع تصديق الخوادم المحمية. عندما تحاول آلة افتراضية محمية بدء التشغيل على خادم محمي، يجب على ذلك الخادم الوصول إلى HGS والتأكد من أنه آمن ومأمون. فقط عندما يجتاز الخادم تصديق HGS واختبارات الصحة، ستتمكن الآلة الافتراضية المحمية من البدء.
الHGS أمر بالغ الأهمية لجعل بنية الحماية تعمل. إذا توقفت HGS، لن تتمكن أي من الآلات الافتراضية المحمية من البدء!
هناك متطلبات مختلفة لـ HGS، بناءً على وضع التصديق الذي ستستخدمه الخوادم المحمية. سنتعلم عن هذه الأوضاع في القسم التالي من هذا الفصل. يجب أن تعمل HGS على Server 2016 أو 2019 أو 2022، وعادة ما تفضل استخدام خوادم فيزيائية تعمل في مجموعة من ثلاثة عقد لهذه الخدمة.
أريد أيضًا أن أشير إلى ميزة حديثة متعلقة بـ HGS التي جاءت عبر Windows Server 2019: HGS cache. كانت هناك قيود سابقة على الآلات الافتراضية المحمية في Server 2016 حيث كان يجب الاتصال بـ HGS في كل مرة يرغب فيها أي خادم محمي في تشغيل أي آلة افتراضية محمية. يمكن أن تصبح هذه مشكلة إذا كانت HGS غير متاحة لأي سبب مؤقت. الجديد في Server 2019 هو HGS cache لمفاتيح الآلات الافتراضية حتى يتمكن الخادم المحمي من تشغيل الآلات الافتراضية المعتمدة بناءً على المفاتيح في ذاكرة التخزين المؤقت، بدلاً من الحاجة دائمًا للتحقق من HGS مباشر.
يمكن أن يكون هذا مفيدًا إذا كانت HGS غير متصلة (على الرغم من أن عدم اتصال HGS تمامًا يعني على الأرجح أنك تواجه مشاكل كبيرة)، ولكن HGS cache لديه حالة استخدام أكثر صحة في سيناريوهات الفروع حيث قد يكون للخادم المحمي اتصال شبكة ضعيف بـ HGS.
تصديقات الخوادم
تصديق الخوادم المحمية هو السر في استخدام الآلات الافتراضية المحمية. هذه هي الأساس الأمني في الرغبة في المضي قدمًا مع هذا الحل في بيئتك الخاصة. قدرة الخوادم الخاصة بك على تصديق صحتها وهويتها تمنحك راحة البال بمعرفة أن تلك الخوادم لم يتم تعديلها أو التلاعب بها دون علمك، وتضمن أن موظفًا ضارًا لن يتمكن من نسخ جميع ملفات القرص الصلب للآلات الافتراضية الخاصة بك على USB، وإحضارها إلى المنزل، وتشغيلها. تلك الآلات الافتراضية المحمية لن تبدأ إلا على الخوادم المحمية في بيئتك، ولن تبدأ في أي مكان آخر.
تصديقات موثوقة TPM
هذه هي الطريقة الأفضل! شرائح TPM هي شرائح مادية مثبتة على اللوحة الأم للخادم الخاص بك تحتوي على معلومات فريدة. والأهم من ذلك، أن هذه المعلومات لا يمكن تعديلها أو اختراقها من داخل نظام التشغيل Windows. عندما تكون الخوادم المحمية الخاصة بك مزودة بشرائح TPM 2.0، يفتح هذا الباب للقيام ببعض تصديقات الخوادم القوية للغاية. يستخدم الخادم الإقلاع الآمن (Secure Boot) وبعض فحوصات تكامل الشفرة المخزنة داخل TPM للتحقق من أنه صحي ولم يتم تعديله. ثم يقوم HGS بفحص المعلومات التي يتم تقديمها من TPM مع المعلومات التي يعرفها عند تكوين الخادم المحمي في البداية، للتأكد من أن الخادم الطالبة هو بالفعل أحد الخوادم المحمية المعتمدة الخاصة بك ولم يتم العبث به. إذا كنت تقوم بتكوين خوادم Hyper-V جديدة، تأكد من أنها تحتوي على شرائح TPM 2.0 حتى تتمكن من الاستفادة من هذه الميزات.
تصديقات المفتاح المضيف
إذا كانت شرائح TPM ليست ما تفضله أو تتجاوز قدرات أجهزتك، يمكننا القيام بتصديق المفتاح المضيف الأبسط. قدرة الخوادم المحمية الخاصة بك على إنشاء مفتاح مضيف يمكن معرفته والتحقق منه من قبل HGS هي جديدة منذ Windows Server 2019. يستخدم هذا تكنولوجيا زوج المفاتيح غير المتماثلة للتحقق من الخوادم المحمية. بشكل أساسي، ستقوم بإنشاء زوج مفتاح مضيف جديد أو استخدام شهادة موجودة ثم إرسال الجزء العام من هذا المفتاح أو الشهادة إلى HGS. عندما ترغب الخوادم المحمية في تشغيل آلة افتراضية محمية، فإنها تتصل لتصديق مع HGS، ويتم الموافقة على هذا التصديق أو رفضه بناءً على زوج المفاتيح هذا. هذا بالتأكيد طريقة أسرع وأسهل لجعل الآلات الافتراضية المحمية حقيقة في شبكتك ولكنه ليس آمنًا مثل تصديق موثوق TPM.
تصديق موثوق من المسؤول – لم يعد مدعومًا في 2019
إذا كانت بيئتك حديثة وتستند إلى Server 2019 أو 2022، فلا تهتم بهذا الخيار. ومع ذلك، هناك أشخاص يقومون بتشغيل الآلات الافتراضية المحمية داخل بنية Windows Server 2016، وفي هذه الحالة كان هناك خيار إضافي للتصديق.
المعروف بشكل شائع بتصديق موثوق من المسؤول، كان هذا طريقة بسيطة جدًا (وغير آمنة جدًا) لتصديق الخوادم إلى HGS بأنها معتمدة. بشكل أساسي، قمت بإنشاء مجموعة أمان Active Directory (AD)، وأضفت الخوادم المحمية الخاصة بك إلى تلك المجموعة، ثم اعتبرت HGS أي خادم جزء من تلك المجموعة محميًا ومعتمدًا لتشغيل الآلات الافتراضية المحمية.
مستقبل الآلات الافتراضية المحمية
ال HGS، أوضاع التصديق، والآلات الافتراضية المحمية هي تقنيات موجودة في Windows Server 2022، وتم تحديث وثائق Microsoft لتعكس دعم Server 2022 لاستخدام الآلات الافتراضية المحمية. ومع ذلك...
أعلنت Microsoft أيضًا أن Guarded Fabric والآلات الافتراضية المحمية مدرجة رسميًا في قائمة "الميزات التي لم نعد نطورها." هذا لا يعني أنها لم تعد قابلة للتطبيق، لأنها ستستمر في دعم استخدام الآلات الافتراضية المحمية، بما في ذلك على Server 2022، ولكنها تتوقف عن تخصيص موارد التطوير لهذه التقنية الداخلية.
التكامل مع Linux
تستخدم العديد من الشركات نظام Linux بطريقة أو بأخرى. قد يكون استخدام Linux جاهزًا للدخول بشكل أكبر في عالم Windows Server الآن مع توفر مستوى أعلى من التكامل داخل Windows Server 2022. هناك طرق يمكن من خلالها استخدام Server 2022 للتفاعل مع VMs بنظام Linux:
- **التشغيل في Hyper-V:** كانت الأجهزة الافتراضية المستضافة على Hyper-V Server تقتصر على أنظمة التشغيل المستندة إلى Windows. لم يعد هذا هو الحال. تم توسيع نطاق مضيف Hyper-V virtualization الآن ليشمل تشغيل الأجهزة الافتراضية المستندة إلى Linux في Hyper-V Manager. وهناك تكامل جيد حتى مع لوحة المفاتيح والماوس!
- **الأجهزة الافتراضية المحمية بنظام Linux:** الآن تعرف كيفية تشغيل الأجهزة الافتراضية المحمية في Hyper-V، وتعرف أيضًا كيفية تشغيل الأجهزة الافتراضية المستندة إلى Linux داخل Hyper-V. هل يعني ذلك أنه يمكننا الجمع بين هاتين الفكرتين وتشغيل جهاز افتراضي بنظام Linux يكون محميًا أيضًا؟ نعم، يمكننا بالتأكيد. تم تقديم هذه القدرة في إصدار SAC من Windows Server 1709 وتوجد أيضًا في أحدث إصدار LTSC من Windows Server 2022.
- **التشغيل في الحاويات:** بينما لن يكون معظم مسؤولي الخوادم وHyper-V متحمسين لتثبيت Linux على أنظمتهم لأنه ليس لديهم سبب للقيام بذلك، بالتأكيد سيكون هناك الكثير من الحديث عن Linux من أي شخص في قسم DevOps في مجال تكنولوجيا المعلومات. عند بناء تطبيقات قابلة للتوسع وحديثة مخصصة للسحابة، غالبًا ما نتحدث عن تشغيل هذه التطبيقات داخل الحاويات. في الماضي، كان استضافة الحاويات على خادم Windows يعني أن الحاوية نفسها يجب أن تعمل بنظام Windows، لكن لم يعد هذا الحال. يمكنك الآن استضافة الحاويات المستندة إلى Linux على خادم Windows Server 2022. هذا يوفر مرونة كبيرة في عملية تطوير التطبيقات وسيكون اعتبارًا مهمًا لمستقبل الحاويات.
إزالة التكرار في ReFS
في حين أن الملفات ونظام deduplication هي تقنيات قد لا تتوقع مناقشتها عند الحديث عن Hyper-V، فإن التحسينات في Server 2019 و2022 المتعلقة بـ ReFS وdeduplication تحمل بعض المزايا الكبيرة لخوادم Hyper-V. إذا كانت هذه المصطلحات غير مألوفة، فلنأخذ دقيقة لتوضيح ReFS وdeduplication.
ال ReFS
أي شخص عمل على أجهزة الكمبيوتر لفترة من الوقت سيتعرف على FAT، FAT32، وNTFS. هذه هي أنظمة الملفات التي يمكن استخدامها عند تهيئة الأقراص الصلبة. تختلف إصدارات أنظمة الملفات في القدرات المختلفة لكيفية استخدامك لتلك الأقراص الصلبة. لعدد من السنوات، كان NTFS هو المعيار الفعلي لجميع الأقراص الصلبة المتصلة بأجهزة Windows.
هذا حتى جاء Windows Server 2016. لدينا الآن خيار جديد لنظام الملفات يسمى ReFS. حتى إذا كنت تعمل في قسم تكنولوجيا المعلومات يوميًا، قد لا تكون سمعت عن ReFS لأنه حتى الآن لا يتم استخدامه كثيرًا. يتم استخدامه بشكل أساسي في الخوادم التي تشارك في Storage Spaces Direct (S2D). إذا كان هو أحدث وأفضل نظام ملفات من Microsoft، فلماذا لا يتم استخدامه كخيار افتراضي في أي نظام جديد؟ أساسًا لأن ReFS ليس نظام ملفات قابل للإقلاع. هذا يلغي على الفور قدرة الأنظمة ذات القرص الصلب الواحد على تشغيل ReFS على القرص بالكامل. ما يعنيه ذلك هو أن ReFS مخصص للأقراص الثانوية على الخوادم، وربما الأقراص المخصصة لتخزين كميات كبيرة من البيانات.
في تلك الحالات التي تقوم فيها بتهيئة قرص ثانوي ليكون ReFS وتخزين البيانات عليه، هناك بعض المزايا الكبيرة في المرونة والأداء لاستخدام ReFS بدلاً من NTFS. تم تصميم هذه المزايا لجعل تنفيذات S2D تعمل بشكل أفضل.
إزالة التكرار في البيانات
إزالة التكرار في البيانات هي ببساطة قدرة النظام الحاسوبي على اكتشاف الأجزاء المتعددة من البيانات على القرص التي تكون متطابقة وتنظيفها. إذا كان هناك ست نسخ من نفس الملف على النظام، يمكن أن تحذف عملية إزالة التكرار خمسًا منها، مع الاحتفاظ بواحدة لغرض استخدام المواقع الستة جميعًا. هذه الفكرة تمكن من توفير مساحة كبيرة. إزالة التكرار في البيانات ليست جديدة؛ تم تقديم بعض القدرات في هذا المجال منذ Server 2012.
يعد Windows Server 2019 أول منصة يمكن فيها تمكين إزالة التكرار في البيانات على قرص مهيأ عبر ReFS.
لماذا هذا مهم لـ Hyper-V؟
يمكن أن تكون إزالة التكرار في البيانات مفيدة للغاية على قرص يخزن ملفات Hyper-V VM hard drive لأنك، كما يمكنك أن تتخيل، سيكون هناك الكثير من المعلومات المكررة مرارًا وتكرارًا عندما تكون هناك عشرات الأجهزة الافتراضية قيد التشغيل. فكر في جميع ملفات نظام التشغيل Windows التي ستكون متطابقة بين جميع الأجهزة الافتراضية التي تعمل على مضيف Hyper-V. من الواضح أنه سيكون من المفيد تمكين إزالة التكرار في البيانات على قرص يخزن ملفات VHDX. يتمتع ReFS ببعض المزايا الكبيرة في المرونة والأداء على NTFS، لذا من الواضح أيضًا أن ملفات VHDX ستكون في أفضل حالاتها عند تخزينها على قرص ReFS.
يعد Windows Server 2019 و2022 أولى المنصات التي يمكنك فيها الاستفادة من قدرات ReFS وتفعيل إزالة التكرار في البيانات على نفس القرص.
خادم Hyper-V...2019؟
من السهل جدًا أن تتحمس بشأن الافتراضية. قم ببناء بعض الأجهزة، تثبيت Windows Server 2022، تنفيذ دور Hyper-V، وبام! أنت جاهز لبدء طرح مئات الأجهزة الافتراضية في بيئتك... أليس كذلك؟
ليس بالضرورة. لم نتحدث بعد عن الترخيص، وغالبًا ما تكون براعتنا التكنولوجية محدودة بمتطلبات الترخيص. ينطبق نفس الشيء على Hyper-V. كل جهاز افتراضي تقوم بإنشائه يحتاج إلى ترخيص نظام تشغيل خاص به، بالطبع. هذا المتطلب منطقي. ما ليس واضحًا، مع ذلك، هو حقيقة أنك تستطيع تشغيل عدد معين من الأجهزة الافتراضية فقط على خادم Hyper-V الخاص بك، اعتمادًا على SKU الذي تستخدمه لنظام التشغيل المضيف.
أكبر عائق هو أن استخدام إصدار Windows Server 2022 Standard كخادم Hyper-V سينتج عنه القدرة على تشغيل جهازي افتراضيين فقط. هذا كل شيء، لا أكثر. ستتمكن من إطلاق بضع أجهزة افتراضية ثم ستتم منع تشغيل المزيد. من الواضح أن إصدار Standard SKU ليس مصممًا ليتم استخدامه كخادم Hyper-V.
هذا يتركك مع إصدار Windows Server 2022 Datacenter. لحسن الحظ، يسمح لك Datacenter بتشغيل عدد غير محدود من الأجهزة الافتراضية! هذه أخبار رائعة! باستثناء شيء واحد - إصدار Datacenter عادة ما يكلف آلاف الدولارات. هذا عامل مقيد للغاية لتطبيقات خوادم Hyper-V.
كل هذا الحديث عن الترخيص وكيف يمكن أن يكون فوضويًا أو مكلفًا يؤدي إلى نقطة واحدة: خادم Hyper-V. انتظر لحظة، ماذا تتحدث عنه، جوردان؟ أليس هذا ما يدور حوله هذا الفصل كله؟ أليس هذا مجرد Windows Server 2022 مع تثبيت دور Hyper-V؟ لا، ليس كذلك على الإطلاق. "Hyper-V Server" هو كائن خاص به. لديه مثبت خاص به وواجهة مستخدم مختلفة تمامًا عن الخادم التقليدي. تثبيت Hyper-V Server على قطعة من الأجهزة سينتج عنه خادم يمكنه استضافة عدد غير محدود من الأجهزة الافتراضية Hyper-V، ولكن لا شيء آخر. لا يمكنك استخدام هذا كخادم للأغراض العامة لاستضافة أدوار أو خدمات أخرى. لا يحتوي Hyper-V Server أيضًا على واجهة مستخدم رسومية.
يتمتع Hyper-V Server 2019 بفائدة كبيرة: إنه مجاني. ما زلت مسؤولاً عن التراخيص على كل جهاز افتراضي، بالطبع، ولكن للحصول على نظام تشغيل مضيف مجاني يمكنه تشغيل عدد غير محدود من الأجهزة الافتراضية، هذا شيء يمكن لمحفظتي حقًا أن تدعمه.
ارجع للوراء. هل نسيت تحديث "2019" في الفقرة السابقة لتقول "2022"؟ لا. نحن نتحدث هنا عن Hyper-V Server 2019 لأن، للأسف، هذه ستكون آخر نسخة تُصدر لهذا النوع الخاص من Hyper-V Server. كانت Microsoft تصدر هذا المثبت الخاص بـ Hyper-V Server بجانب إصدارات Windows Server لسنوات عديدة، ولكن بدءًا من Windows Server 2022، لم يعد يتم إنشاء Hyper-V Server. مرة أخرى، هذا لا علاقة له بتثبيت Windows Server 2022 ثم تثبيت دور Hyper-V عليه، وهو بالطبع لا يزال ملائمًا تمامًا وهو ما كنا نتحدث عنه طوال هذا الفصل.
تركز هذه الجزء الخاص من الفصل على طريقة التثبيت البديلة تحديدًا لـ "Hyper-V Server 2019"، حيث لا يوجد "Hyper-V Server 2022". هذا أمر مؤسف، وتوصية Microsoft لأولئك الذين يبحثون عن المثبت الخاص بـ Hyper-V Server هي الاستمرار في استخدام Hyper-V Server 2019 أو تجربة Azure Stack HCI، ولكن ذلك يأتي بتكلفة. لذلك سنتقدم بالخيار الأول، حيث سيظل Hyper-V Server 2019 قابلًا للاستخدام ومدعومًا حتى عام 2029، وسنستخدمه هنا اليوم. أتوقع أن هذا هو النهج الذي سيت
بعه معظم المسؤولين. إذا كنت تتابع هذه المواضيع داخل مختبرك أو شبكتك، هنا صفحة هبوط لتحميل مثبت Hyper-V Server 2019:
[رابط التحميل](https://www.microsoft.com/en-us/evalcenter/download-hyper-v-server-2019)
لقد حرقت مثبت ISO لـ Hyper-V Server 2019 على DVD (لحسن الحظ أن هذا واحد صغير بما يكفي ليتناسب!)، وأنهيت للتو تثبيته على أجهزتي. كان تثبيت نظام التشغيل نفسه مألوفًا تمامًا: جميع شاشات التثبيت والخيارات كانت نفسها كما لو كنت أقوم بتثبيت النسخة الكاملة من Windows Server 2019. ولكن الآن بعد أن انتهى المثبت وأعدت تشغيل نظام التشغيل الخاص بـ Hyper-V Server 2019، كل شيء يبدو مختلفًا تمامًا:
نحن نقدم فقط موجه الأوامر، وداخل هذا الموجه، تم تشغيل أداة التكوين SConfig تلقائيًا. باستخدام لوحة المفاتيح هنا، يمكنني القيام بأشياء مثل تعيين اسم الخادم، والانضمام إلى نطاق، وتغيير إعدادات الشبكة. بمجرد الانتهاء من استخدام هذا CLI لتعيين المتطلبات الأساسية على الخادم وجعله يتواصل مع الشبكة، لن تحتاج حقًا للوصول إلى وحدة التحكم الخاصة بهذا Hyper-V Server مرة أخرى، إلا إذا كنت بحاجة إلى العودة إلى شاشة التكوين هذه لتغيير شيء ما. بدلاً من ذلك، بعد تكوين Hyper-V Server، تستخدم ببساطة Hyper-V Manager، أو PowerShell، على خادم آخر أو سطح مكتب داخل شبكتك، للاتصال عن بُعد بإدارة الأجهزة الافتراضية التي تعمل على هذا Hyper-V Server.
في الشكل 14.40، يمكنك أن ترى أنني أطلقت Hyper-V Manager. أنا أدير هذا المثيل من Hyper-V Manager من جهازي Windows 10 حيث لدي دور Hyper-V مثبت. من هنا، أنقر بزر الماوس الأيمن على Hyper-V Manager وأختار Connect to Server.... ثم أدخل اسم Hyper-V Server الجديد الخاص بي، وينشئ وحدة التحكم اتصالًا عن بُعد. من هذا الاتصال البعيد، يمكنني الآن استخدام جميع الوظائف داخل Hyper-V Manager في Windows 10 كما لو كنت مسجل دخول مباشرة إلى Hyper-V Server الجديد:
على غرار الطريقة التي يتم بها التعامل مع معظم المهام المنفذة على Server Core عن بُعد - من خلال استخدام وحدات التحكم البعيدة أو PowerShell - نجعل جميع الصيانة والإدارة المستمرة لهذا Hyper-V Server تتم من وحدة التحكم Hyper-V Manager البعيدة.
يمنحك Hyper-V Server فوائد الأمان لواجهة خالية من GUI، إلى جانب الفوائد المرونة لاستضافة عدد غير محدود من الأجهزة الافتراضية، بسعر لا يمكن الجدال فيه!
ملخص
ليس لدي أرقام رسمية، لكنني سأخاطر وأقول إن هناك اليوم المزيد من الخوادم الافتراضية قيد التشغيل أكثر من الخوادم الفعلية للحفاظ على استمرار عمل عالمنا عبر الإنترنت. بينما يستمر الجدال حول أي منصة hypervisor هي الأفضل - عادة ما يكون النقاش مقسمًا بين Hyper-V أو VMware - لا يمكنك تجاهل حقيقة أن الافتراضية هي مستقبل التكنولوجيا.
تضع Microsoft كميات كبيرة من الوقت والموارد لضمان أن Hyper-V يبقى دائمًا في مقدمة المنافسة ويقدم المزيد والمزيد من الميزات مع كل إصدار حتى تتمكن من الحفاظ على بنيتك التحتية الافتراضية وتعمل بشكل مثالي طوال الوقت. هل قدرة الافتراضية السحابية أكثر قوة من Hyper-V على الخوادم المحلية؟ سأقول نعم لأن البنية التحتية الموجودة لدى مزود الخدمة السحابية ستكون مثل "Oz العظيم" مقارنة بما يمكن أن تقدمه شركة واحدة في مركز البيانات الخاص بها. هل يعني ذلك أنه يمكنك نسيان Hyper-V تمامًا واستخدام الخوادم المقدمة من السحابة فقط؟ ربما في يوم ما، لكن معظم الناس ليسوا مستعدين لأخذ تلك القفزة حتى الآن. لا يزال الحاجة للخوادم والخدمات المحلية ضخمة، وبعض الصناعات ببساطة لن تسمح بأن يتم استضافة بياناتها وتطبيقاتها من قبل طرف ثالث. في بعض الحالات، ستتخذ أسباب الامتثال التنظيمي القرار نيابة عنك. فهم قدرات Hyper-V والقدرة على بناء هذه البنية التحتية من الصفر سيمنحك ميزة كبيرة عند البحث عن وظيفة تقنية في منظمة تركز على Microsoft.
النهاية
نكون هنا انتهينا من الجزء 3 من الفصل 14 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
