فهم البنية التحتية للسطح الافتراضي (VDI)

أصبحت البنية التحتية للسطح الافتراضي (VDI) حديث مجالس تقنية المعلومات في السنوات الأخيرة. فبمجرد أن أصبحت افتراضية الخوادم هي القاعدة، كان النظر إلى أجهزة سطح المكتب باعتبارها الحدود التالية للافتراضية أمراً طبيعياً. غير أن أجهزة سطح المكتب، خلافاً للخوادم، تتأثر بعدة عوامل رئيسية يجب معالجتها والنظر فيها قبل القفز إلى عربة VDI. تقنية VDI رائعة وممتازة، لكنها مثل أي تقنية، لها مكانها المناسب وتستدعي التفكير الدقيق.

أولاً يجب أن ننظر في مفهوم مهم يؤثر على VDI، وهو فكرة الحوسبة المشتركة. مع الخوادم نفترض بطبيعة الحال أن الخوادم والخدمات التي تقدمها ليست للاستهلاك الفردي بل ستستخدمها مستخدمون متعددون. هذا المفهوم موجود وكان دائماً موجوداً في عالم أجهزة سطح المكتب، ويُعرف في أغلب الأحيان بخدمات الطرفيات. خوادم الطرفيات هي الإجابة من عالم الخوادم على الحاجة إلى موارد سطح المكتب المركزية وكانت معيارية منذ ما قبل وجود أجهزة سطح المكتب حرفياً.

ثمة جانب مثير للاهتمام في تاريخ الحوسبة يوضح كيفية تعامل عالم Windows مع مفهوم خوادم الطرفيات. معظم أنظمة التشغيل، وتقريباً جميع التي لا تزال مستخدمة اليوم، صُممت من الألف إلى الياء، وكانت دائماً كذلك، كأنظمة متعددة المستخدمين. فكرة أن يجلس مستخدم واحد أمام الحاسوب بوصفه المستخدم "الرئيسي" وأن يكون الآخرون مواطنين من الدرجة الثانية أو لا وجود لهم، لم تكن موجودة أصلاً وكان جميع المستخدمين يُعتبرون متساوين. Windows، على النقيض من عائلة UNIX مثلاً، جاء من عالم الأنظمة ذات المستخدم الواحد التي بدأت مع DOS وDOS/Windows، التي لم تكن متعددة المستخدمين، وحين طُوّر Windows NT كنظام متعدد المستخدمين، تعامل كثير من مطوري البرمجيات معه كما اعتادوا دائماً، فصنعوا برمجيات لا تعمل بكفاءة أو في كثير من الأحيان لا تعمل أبداً في وضع المستخدمين المتعددين.

هذا النظام البيئي البرمجي الفريد في Windows (الذي لا يمكن فعلياً أن يوجد على Linux مثلاً، لأن مثل هذه البرمجيات ستُعدّ ببساطة معطوبة نظراً لطبيعة النظام البيئي وعمليات النشر) خلق مشكلة مثيرة للاهتمام، إذ جعل بعض البرامج والمهام قابلة للتعامل بسهولة عبر خوادم الطرفيات تماماً كما تتعامل معها أي نظام UNIX، بينما لا يمكن معالجة تطبيقات أخرى كثيرة باستخدام خادم طرفيات وتستلزم مثيل نظام تشغيل مخصصاً لكل مستخدم.

بسبب هذا العامل التاريخي الذي أفضى إلى اختلاف جوهري في النظم البيئية البرمجية نشأت الحاجة الأساسية لـ VDI، ويُفسّر ذلك لماذا ظهر VDI كظاهرة فريدة في عالم Windows ولا يزال، من جميع النواحي العملية، حكراً عليه. لذا، من المهم جداً أن نفهم أن VDI نشأ مفهومياً كوسيلة لمعالجة حاجة لم تنشأ إلا بسبب قصور في تطبيقات الأطراف الثالثة، وليس بسبب طبيعة Windows ذاتها في شكلها الحالي أو لأن VDI كان النهج الأفضل لافتراضية أو استضافة خدمات سطح المكتب للمستخدم النهائي. في الواقع، يمكننا حتى النظر إلى VDI باعتباره حلاً ترقيعياً مؤسفاً لا يُحتاج إليه إلا في حالات نريد فيها افتراضة أو مركزة موارد سطح المكتب وحيث بعض البرامج المطلوبة للتشغيل على تلك الأنظمة لا تعمل في وضع المستخدمين المتعددين. VDI هو آلية احتياطية للحالات الخاصة وليس النهج المثالي لخدمات سطح المكتب الافتراضية أو المركزية للمستخدم النهائي.

من المهم الإشارة إلى أن الاستخدام الواسع لـ VDI وضرورته أدّيا إلى استثمارات في تقنيات الدعم المحيطة به مما أتاح الاحتمال بأن VDI قد يتفوق في الأداء فعلياً على خوادم الطرفيات في كثير من الحالات رغم أن ذلك يبدو مستحيلاً تقريباً من الناحية المعمارية. يحدث هذا أساساً لأن القدر الهائل من البحث والتطوير الذي يضخ في طبقة المشغل الافتراضي (Hypervisor) قد يتجاوز المكونات المماثلة في نظام التشغيل ذاته مما يؤدي إلى إدارة محتملة أفضل لوحدة المعالجة المركزية والذاكرة ومشاركة الموارد. هذا يعتمد كلياً على الوضع الفريد بالطبع، إذ يختلف كل نظام تشغيل وكل مشغل افتراضي وكل مجموعة أدوات VDI، فضلاً عن أعباء العمل التي تختبر، فتتباين النتائج بشكل كبير.

اعتبار جدير بالاهتمام أيضاً هو الترخيص، نظراً للطبيعة المتمحورة حول Windows لمفهوم VDI المذكورة آنفاً. لو نظرنا إلى VDI من منظور Linux لكانت لدينا مخاوف ترخيص ضئيلة أو معدومة وكان VDI سيتنافس مع خدمات الطرفيات التقليدية على أسس تقنية بحتة، لكن هذا لا يحدث فعلياً أبداً. أكبر عامل واحد في اتخاذ قرارات VDI هو ترخيص Microsoft.

ترخيص VDI مكلف ومعقد في الوقت ذاته. على الشركات الراغبة في النظر في افتراضية موارد سطح مكتب Windows أن تزن بعناية الفوائد مقابل التكلفة الكبيرة للترخيص المناسب، وأيضاً مقابل التكاليف الضخمة المحتملة لإدارة التراخيص. الانتقال إلى VDI سيعني على الأرجح الكثير من وقت تقنية المعلومات المكلف المخصص لبحث التراخيص ومراقبتها والتدريب عليها، وهو جانب كثيراً ما يُغفل من تكاليف الترخيص.

VDI مفهوم يصعب نوعاً ما الحديث عنه بشكل عام لأنه موضوع غير محدد المعالم قليلاً. إذا افترضنا سطح مكتب، هل يصبح خادماً؟ إذا استخدمنا نظام تشغيل مخصصاً لاستخدام الخادم، هل يُغيّر ذلك ما هو VDI وما ليس كذلك؟ هل يرتكز VDI على حالات الاستخدام أم الترخيص أم فئات المنتجات؟

تكمن الإجابة الحقيقية في أن VDI للصناعة هو شيء من الناحية التقنية، لكن من الناحية العملية بالنسبة لـ Microsoft، وهي اللاعب الوحيد في مجال الترخيص، يعني شيئاً مختلفاً نوعاً ما. VDI من الناحية التقنية هو افتراضية مثيلات "سطح مكتب رسومي للمستخدم النهائي" بنسبة واحد لواحد، أي آلة افتراضية واحدة يستخدمها مستخدم واحد تماماً كما يُستخدم سطح مكتب أو لابتوب تقليدي. أما بالنسبة لـ Microsoft، التي تختلف اهتماماتها قليلاً عن اهتمامات الصناعة، فإن المصطلح يشير إلى افتراضية أنظمة تشغيل Windows "من فئة سطح المكتب". إذا قمت بافتراضية أنظمة تشغيل Windows "من فئة الخادم"، لا تعتبر Microsoft أنك تقوم بـ VDI. لذا يجب أن نفهم هاتين النظرتين للمفهوم حتى لا نصاب بالارتباك. في الواقع، أصبح استخدام أنظمة تشغيل Windows Server للتحايل على احتياجات ترخيص VDI من أجهزة سطح مكتب Windows أمراً شائعاً وقياسياً. غير أن علينا تذكر الطبيعة الترقيعية لـ VDI، وبينما يحل هذا مشكلة الفشل في كتابة برمجيات متعددة المستخدمين بطبيعتها، إلا أنه لا يعالج الاحتمال الحقيقي أن البرمجيات كُتبت بتوقعات خاصة بأنظمة تشغيل من فئة سطح المكتب، ومن المرجح نسبياً أن نجد برمجيات للمستخدم النهائي مقيدة (عن قصد أو دون قصد) بأنظمة تشغيل سطح المكتب فحسب أو مرخصة على تلك المنصات فقط.

آخر اعتبار رئيسي في اتخاذ قرارات VDI هو أنه خلافاً للخوادم التي تُفرّض بشكل كامل عند افتراضتها، لا يمكن التعامل مع سطح المكتب بالطريقة ذاتها لأن له دائماً مكوناً مادياً. سيحتاج المستخدم النهائي دائماً إلى شاشة للنظر فيها، ولوحة مفاتيح للكتابة عليها، ومكبرات صوت للاستماع إليها، وهكذا. لذا عند النظر في الانتقال إلى VDI يجب أن نحرص على عدم إغفال حقيقة أننا لا نُلغي الحاجة إلى شراء أجهزة سطح المكتب وصيانتها، بل نحن نقوم فقط بنقل مكان إقامة نظام التشغيل. قد نُعيد توظيف الأجهزة القديمة لاستخدامها في الوصول عن بُعد، أو ننتقل إلى العملاء النحيلة أو العملاء الصفرية ذات المسمى الجديد الذي يفتقر إلى معنى محدد إلى حد ما، أو نستخدم "العملاء الكاملة" الحالية لتقوم بدور مزدوج بمعالجة كل من الأنشطة كعميل وصول عن بُعد وتقديم خدمات سطح مكتبها الخاصة.

بالتأكيد تُتيح افتراضية سطح المكتب فرصاً عظيمة وقيمة كبيرة إذا كنا نفعل ذلك للأسباب الصحيحة ونفهم أسئلة الكيف والسبب والمتى لـ VDI. للأسف، كثير من الاتجاهات التقنية الأخرى، أصبح الرغبة في الانتقال إلى VDI ردة فعل تلقائية دون إجراء تقييمات مناسبة ودون تطوير صورة واضحة حول كيفية ملاءمة VDI لبيئاتنا الخاصة. إذا افتقرنا إلى سبب واضح لاختيار VDI، فمن غير المرجح أن نودعه بطريقة إيجابية.

أخيراً، من المهم جداً أن ننظر في مجموعات المهارات الضرورية المطلوبة للانتقال السليم إلى VDI. من الناحية التقنية البحتة، وضع آلة افتراضية Windows 10 على Hyper-V يُعدّ VDI، لكن من الناحية العملية هذا ليس كيف سيُصمَّم VDI الفعّال. لا يستلزم VDI فحسب معرفة الترخيص الخاصة التي ذكرتها آنفاً، بل سيتضمن عادةً معرفة متخصصة تقنية نوعاً ما لمجموعات وأدوات VDI الحديثة والمتخصصة جداً، والتخزين المشترك بما ينطبق على VDI، وبروتوكولات الوصول عن بُعد، والعملاء النحيلة أو الصفرية، وغير ذلك. تميل عمليات نشر VDI إلى أن تكون من المكونات التقنية والفريدة في البنية التحتية مما يؤدي إلى عدد كبير من المجاهيل والتحديات لأي مؤسسة.