اثنين من المزالق التي تواجه المؤسسات التي تطبق المحاكاة الافتراضية للخادم

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

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

المأزق 1: اختيار منصة التخزين الخاطئة

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

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

شبكة منطقة تخزين القنوات الليفية

باستخدام شبكات SAN للقنوات الليفية، لا يحتاج المستخدمون فقط إلى تبرير التكاليف الإضافية لتخزين القنوات الليفية والتبديل والإدارة، ولكنهم يحتاجون أيضًا إلى تكوين محولات الناقل المضيف باهظة الثمن لكل خادم يتصلون بشبكة SAN. سوف تواجه تلك الشركات التي تتبنى شبكات منطقة تخزين القنوات الليفية الحالية بعض العقبات. لجني الفوائد الكبيرة للمحاكاة الافتراضية للخادم، تحتاج هذه البنية التحتية الكاملة للقناة الليفية (بما في ذلك المحولات ومحولات الناقل المضيف) إلى دعم بروتوكول NPIV (المحاكاة الافتراضية لمعرف N-Port). معظم المنتجات حاليًا لا تحتوي على NPIV.

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

تحسين حلول التخزين للبيئات الافتراضية

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

بالإضافة إلى ذلك، تتمتع أنظمة تخزين LAN للتخزين عبر iSCSI بمزايا واضحة لشبكة WAN مقارنة بشبكات LAN للتخزين عبر القنوات الليفية. يتطلب النسخ المتماثل لشبكة WAN الخاصة بتخزين القنوات الليفية شراء بوابات FCIP (قناة ليفية عبر IP) باهظة الثمن. لا يتطلب النسخ المتماثل للشبكة الواسعة (WAN) للتخزين عبر بروتوكول iSCSI شراء أنظمة إضافية وتنفيذها وتشغيلها وإدارتها. iSCSI هو بروتوكول TCP/IP يعمل أصلاً عبر شبكة WAN. يمكن أن يتسبب النسخ المتماثل للقناة الليفية وiSCSI WAN في تدهور الإنتاجية أو فقدان الحزمة عبر مسافات طويلة. يمكن للأجهزة المحسنة لشبكة WAN أو TCP/IP لتخزين شبكة LAN عبر بروتوكول iSCSI أن تخفف من هذه المشكلة. ليس لجهاز تحسين WAN أو TCP/IP هذا أي تأثير على بوابات FCIP أو تأثيره ضئيل.

الفخ الثاني: معضلة الإفراط في التزويد

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

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

وبما أن البنية التحتية للتخزين كانت ممتدة بالفعل، فقد أصبحت الصراعات مشكلة، وحدثت اختناقات وتجاوزات في المخزن المؤقت. ومما يزيد الأمور تعقيدًا بالنسبة للمسؤولين هو أن مشكلات التعارض هذه يمكن أن تحدث على مستويات متعددة من البنية التحتية للتخزين.

على مستوى محرك الأقراص الفردي، ستزداد قائمة انتظار طلبات الإدخال/الإخراج. ستكون هذه المشكلة أكثر وضوحًا عند تكوين محركات الأقراص الثابتة SATA الأبطأ. في محركات الأقراص الثابتة SATA، يكون عمق قائمة الانتظار عمومًا من 0 إلى 32 طلبًا، بينما في محركات الأقراص الصلبة SAS (Serial Attached SCSI) أو القنوات الليفية، يكون عمق قائمة الانتظار من 256 إلى 512 طلبًا. وهذا يعني أن المؤسسات التي تتطلع إلى تنفيذ بنية تحتية افتراضية تحتاج إلى حل شبكة منطقة التخزين (SAN) الذي لا يحد من اختيارها لمحركات الأقراص الخلفية.

في طبقة LUN (رقم الوحدة المنطقية)، يقوم برنامج Hypervisor نفسه عمومًا بتقسيم تجمع تخزين فعلي أو LUN إلى عدة LUNs افتراضية، ثم يتم تخصيص LUNs هذه لتطبيقات ضيف افتراضية مختلفة. لا يمكن لوحدات LUN الفعلية هذه التمييز بين تطبيقات العميل هذه. يمكن أن تؤدي تعارضات الموارد المفرطة إلى تقليل أداء التخزين.

وبالمثل، يمكن أن يؤدي التوفير الزائد على مستوى برنامج Hypervisor إلى حدوث مشكلات على مستوى البنية التحتية لشبكة SAN مع محولات الناقل المضيف والبادئات والمنافذ والمحولات. غالبًا ما يتم توفير هذه الموارد بشكل زائد بنسبة 8:1 أو تتجاوز تكوين شبكة منطقة التخزين نفسها. إن التأثير المضاعف لهذا التوفير الزائد المزدوج لا يؤدي إلى انخفاض الأداء فحسب، بل يتسبب أيضًا في انتهاء مهلات الطلب وتعطل التطبيق.

حل التعارضات المفرطة باستخدام شبكة التخزين الافتراضية

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

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

في الواقع، يمكن أيضًا استخدام شبكة منطقة تخزين افتراضية لنشر وحدة LUN واحدة عبر موارد تخزين متعددة، مما يزيد من تخفيف تعارض الموارد. توفر شبكات منطقة التخزين الافتراضية أداء شبكات منطقة التخزين مع بساطة التخزين المتصل بالشبكة.