شبكة الطيف الاخبارية - 5/4/2026 11:39:48 AM - GMT (+3 )
أصبحت التطبيقات السحابية الأصلية أو الموجودة في حاويات هي الآن السائدة. ما يصل إلى 82% من المؤسسات لديها الآن نظام Kubernetes قيد الإنتاج، وفقًا لمنتدى الحوسبة السحابية الأصلية (CNCF). وهذا يمثل ارتفاعًا من 66% في عام 2023. وتقول هيئة الصناعة إن 98% من المؤسسات لديها على الأقل بعض التطبيقات السحابية الأصلية.
لكن نقل التطبيقات إلى البيئات السحابية الأصلية لا يعني فقط إنشاء تعليمات برمجية جديدة. ويعني ذلك أيضًا تكييف البنية التحتية. تحتاج أجهزة الحوسبة والشبكات وتخزين البيانات جميعها إلى العمل مع بيئات الحاويات. لا يمكن لجميع الأنظمة بأي حال من الأحوال القيام بذلك خارج الصندوق، خاصة عندما يتعلق الأمر بالأجهزة الموجودة داخل الشركة.
وفي الوقت نفسه، يحتاج مهندسو تكنولوجيا المعلومات في المؤسسات إلى مراعاة متطلبات التطبيقات القديمة والأجهزة الافتراضية (VMs) التي لم يتم تحديثها. وسترغب المؤسسات في تحقيق أقصى استفادة من أجهزة التخزين الخاصة بها، بغض النظر عن بيئات التطبيقات الخاصة بها.
يعني الانتقال إلى الحاويات تكييف تقنية لم تكن مصممة للتخزين المستمر للتعامل مع البيانات المهمة للأعمال.
بدأت التطبيقات المعبأة في حاويات باعتبارها عديمة الجنسية أو سريعة الزوال. لم يقصد المصممون أبدًا أن تحتوي الحاويات على بيانات ثابتة. لقد توقعوا أن الخدمات الصغيرة أو التطبيقات المعبأة في حاويات لن تستخدم أي تخزين غير متطاير وتتجاهل محتويات الذاكرة، وحتى إعداداتها، بمجرد الانتهاء من مهامها.
بدلاً من ذلك، تعتمد التطبيقات الموجودة في حاويات على مخزن بيانات خارجي، عادةً ما يكون قاعدة بيانات أو ذاكرة تخزين مؤقت.
هناك مزايا لهذا النهج. ويتضمن ذلك نشرًا أبسط، وقياسًا أسهل، والتسامح مع الأخطاء والاسترداد، وإمكانية نقل التطبيق. لكن معظم تطبيقات الأعمال، إن لم يكن الأغلبية، تحتاج إلى بيانات مستمرة.
يقول دان سيرولي، نائب الرئيس والمدير العام للسحابة الأصلية في Nutanix: “تتطلب معظم تطبيقات الأعمال التخزين. في الواقع، ما لم تقم بتحويل فهرنهايت إلى درجة مئوية والعودة، فإنك تخزن شيئًا ما في مكان ما”.
وتعد الحاجة إلى العمل مع البيانات المستمرة أكثر أهمية، حيث تتطلع المؤسسات إلى الحاويات كبديل للأجهزة الافتراضية التقليدية.
ولكن هذا يعني إعادة التفكير في طريقة عمل التطبيقات. ويتطلب الأمر من مهندسي تكنولوجيا المعلومات تحديث أنظمة التخزين الخاصة بهم لدعم التطبيقات السحابية الأصلية الحديثة. يمكن أن يكون ذلك بشكل مباشر، حيث يدعم مصنعو المصفوفات الحاويات، أو من خلال مستوى التحكم مثل Nutanix أو Everpure’s Portworx.
من المؤكد تقريبًا أن التغييرات مدفوعة بالذكاء الاصطناعي، حيث تتطلع المؤسسات إلى دعم أعباء العمل كثيفة البيانات في البيئات السحابية الحديثة. ولكن هناك محركات أخرى أيضًا، بما في ذلك الاتجاه نحو نقل التطبيقات الافتراضية إلى الحاويات والحاجة إلى التحكم في التكلفة.
“قد يكون عمر Kubernetes أكثر من عقد من الزمن، لكنه مستمر في التطور حيث يغير الذكاء الاصطناعي الطريقة التي نتعامل بها مع البيانات. وبالفعل، تجاوز Kubernetes الأيام التي تم تصميمه فيها فقط للتطبيقات المؤقتة عديمة الحالة،” كما يقول مايكل كيد، كبير مسؤولي التكنولوجيا الميدانيين العالميين في Veeam Software.
“اليوم، يتم الآن التعامل مع التطبيقات ذات الحالة مثل قواعد البيانات وخطوط التعلم الآلي وأنظمة البث كمواطنين من الدرجة الأولى [in containerised environments] وقد تم إعطاؤهم الأدوات المتخصصة التي يحتاجونها لتحقيق النجاح.
ومع ذلك، يعتمد توصيل وحدة التخزين بـ Kubernetes على الدعم المقدم من مطوري التطبيقات وموردي الأجهزة.
الطريقة الرئيسية لتوصيل التخزين ببيئات الحاويات هي من خلال واجهة تخزين الحاويات (CSI). يحتاج CSI إلى الدعم مباشرة من قبل موفر التخزين، سواء كان ذلك الشركة المصنعة للأجهزة، أو خدمة سحابية، أو مورد تخزين محدد بالبرمجيات (SDS).
وكما تشير صفحة Kubernetes الخاصة بـ CNCF: “تم تطوير CSI كمعيار لكشف أنظمة تخزين الملفات والكتلة العشوائية لأحمال العمل الموجودة في حاويات على أنظمة تنسيق الحاويات مثل Kubernetes.” يسمح CSI لموفري التخزين التابعين لجهات خارجية بكتابة ونشر المكونات الإضافية للتخزين دون تغيير كود Kubernetes الأساسي.
تستخدم تقنيات SDS، من جانبها، أيضًا برامج تشغيل CSI، ولكنها تعمل على أجهزة سلعية بدلاً من مصفوفات التخزين المخصصة، فضلاً عن البنية التحتية شديدة التقارب. ويتضمن أيضًا خيارات مفتوحة المصدر، مثل OpenEBS وLonghorn وCeph.
يقول نايجل بولتون، المؤلف والخبير المستقل في Kubernetes والحاويات: “تحتاج كل بيئة إلى واجهة تخزين خلفية، مع برنامج تشغيل CSI يربطها بـ Kubernetes. والأمر متروك لموفر التخزين لتوفير برنامج تشغيل CSI”.
ويضيف: “تقوم معظم برامج تشغيل CSI بإنشاء فئة تخزين واحدة على الأقل يتم تعيينها إلى طبقة التخزين وإمكانياتها. على سبيل المثال، قد يقوم برنامج تشغيل CSI بإنشاء فئة تخزين تسمى “النسخ المتماثل السريع” والتي يتم تعيينها لتخزين فلاش عالي السرعة والنسخ المتماثل تلقائيًا إلى موقع بعيد. ويحصل أي تطبيق يستخدم هذه الفئة تلقائيًا على تلك الطبقة ومجموعة الإمكانات”.
يعد هذا المستوى من التجريد مفيدًا للغاية لمطوري التطبيقات، حيث لم يعد عليهم القلق بشأن القدرات المادية لنظام التخزين. يتم التعامل مع ذلك بواسطة برامج تشغيل CSI.
“تمكننا برامج تشغيل CSI من منح حق الوصول إلى التخزين من التطبيق الموجود في حاوية، ولكن [for firms to] يقول سيرولي من شركة Nutanix: “لا يزالون يديرون التخزين بنفس الطريقة التي يقومون بها بالتخزين الذي يتم تشغيله ضمن الأجهزة الافتراضية الخاصة بهم. وهذه ميزة كبيرة”. ويرى أيضًا أن العملاء يقومون بتثبيت Kubernetes على مجموعات معدنية مجردة.
ويحافظ هذا أيضًا على الفصل بين أحمال عمل Kubernetes وأجهزة التخزين الأساسية. على الورق على الأقل، يمكن للمؤسسات نقل تطبيقاتها المعبأة في حاويات إلى منصة أو مورد مختلف، أو إلى أجهزة تخزين جديدة، دون إعادة كتابة التعليمات البرمجية وبأقل قدر من التعطيل.
من الناحية العملية، لا تزال عمليات النقل واسعة النطاق لتطبيقات Kubernetes بين الأنظمة الأساسية نادرة نسبيًا. تميل الشركات إلى تطوير التطبيقات للتشغيل على Amazon Web Services (AWS) أو Google Cloud Platform (GCP) أو Microsoft Azure أو الأجهزة المحلية، اعتمادًا على متطلبات أعمالها.
تعد قابلية نقل التطبيقات، المدعومة بـ CSI، بمثابة تأمين مفيد، حتى لو كانت هناك اختلافات كافية بين الأنظمة الأساسية لاقتراح الحذر.
“نحن حقًا لا نحتاج إلى أن نصبح خبراء في كيفية عمل EBS [Elastic Block Store] يعمل مقابل قرص Azure أو SSD المحلي [solid-state drives] يقول جريج موسكاريلا، المدير العام لشركة Portworx في Everpure: “وكيف يعمل ذلك. إذا كان عليك إدارة هذه الأشياء، يصبح الأمر معقدًا إلى حد ما. تميل الشركات إلى التركيز على بيئة سحابية واحدة.
ويشير إلى أن عدداً قليلاً من المؤسسات لديها تعليمات برمجية يمكنها من خلالها “الضغط على زر ونقله إلى سحابة مختلفة”، لأسباب ليس أقلها الاختلافات بين بنيات التخزين من موردي الأجهزة ومقدمي الخدمات السحابية. ومع ذلك، تقوم الشركات بنقل المزيد من التطبيقات إلى البيئات السحابية الأصلية. ويشمل هذا بشكل متزايد قواعد البيانات والتطبيقات التي كانت تعمل سابقًا في الأجهزة الافتراضية التقليدية.
أحد أهم الاتجاهات في تحديث التطبيقات هو نقل كل من الأجهزة الافتراضية والتطبيقات المستندة إلى قواعد البيانات إلى الحاويات. التكلفة، وتجنب تقييد الموردين، والحاجة إلى الدمج على عدد أقل من المنصات، كلها عوامل محركة.
“الخط الفاصل بين “المحتويات” و”الافتراضي” أصبح غير واضح”، كما يقترح Veeam’s Cade. “لفترة طويلة، كان يُنظر إلى الحاويات والأجهزة الافتراضية على أنها صومعتان منفصلتان. ولكن مع تطور التطبيقات ذات الحالة، وبما أن الأجهزة الافتراضية هي في الأساس عبء عمل نموذجي، فإننا نشهد ارتفاعًا كبيرًا في الشركات التي تديرها مباشرة داخل Kubernetes باستخدام منصات مثل Red Hat OpenShift Virtualization.”
يوافق بولتون. وهو يرى أن المزيد من المؤسسات تنقل أعباء العمل الافتراضية إلى الحاويات، عبر أدوات مثل KubeVirt. ولكن، على الرغم من أن المؤسسات تقوم بالتنقل عبر التطبيقات الافتراضية وقواعد البيانات، إلا أن مهندسي تكنولوجيا المعلومات بحاجة إلى التأكد من استيفاء جميع متطلبات التطبيق بواسطة طبقة التخزين.
ويحذر من أن “قواعد البيانات لديها متطلبات أكثر تطلبًا، بما في ذلك بدء التشغيل المطلوب، والنسخ المتماثل، وتجاوز الفشل الآلي، والنسخ الاحتياطي”. “أكبر تغييرين هما ضمان وجود برنامج تشغيل CSI لنظام التخزين واحتمال نشر مشغل.”
يوفر مشغل Kubernetes تفاصيل حول المتطلبات المحددة لقاعدة البيانات، وأحيانًا التخزين أيضًا. يعد دعم المشغل أمرًا ضروريًا للسماح لقواعد البيانات بتقديم أعباء عمل المؤسسة عبر Kubernetes. مرة أخرى، يدعم المشغل هدف التطبيق الحديث المتمثل في فصل التعليمات البرمجية عن مصفوفة التخزين أو خدمة التخزين السحابية.
توفر شركة Percona، على سبيل المثال، مشغلي MySQL وPostgreSQL وMongoDB، بالإضافة إلى Everest. تقول كيت أوبييديخاتا، المدير العام للشركة السحابية الأصلية: “إن المشغلين هم في الأساس من يغيرون قواعد اللعبة”. “إنهم يقومون بتشفير معرفة DBA البشرية في البرنامج، ويكون لديك كل مكونات المرونة الأكثر أهمية، والنسخ الاحتياطي، وتجاوز الفشل، والنسخ المتماثل، والترقيات تلقائيًا.”
وتضيف أن المشغلين يساعدون المؤسسات على اعتماد بنيات هجينة أو استراتيجيات متعددة السحابات، مما يسمح بإمكانية نقل البيانات دون الحاجة إلى إعادة كتابة التطبيقات. لكن أعباء العمل التي تعمل على الأجهزة الافتراضية لن تعمل تلقائيًا على الحاويات، كما تقول. ستحتاج الشركات إلى التخطيط لعمليات النشر الخاصة بها واختبارها بعناية.
يقول أوبيديخاتا: “هناك قواعد تشغيل محددة يجب عليك تطبيقها ومنهجيات تختلف بشكل واضح عن إعداد قاعدة البيانات الكلاسيكية على الأجهزة الافتراضية”. “لكن كل ذلك ممكن التنفيذ، وتقوم العديد من الشركات الآن بتشغيل قواعد البيانات هذه على Kubernetes. لديهم قواعد لعب مختلفة للتخفيف من هذه المشكلات.”
تحتاج الشركات أيضًا إلى مراعاة كيفية تشغيل تطبيقاتها المنقولة في الإنتاج. ومن المفهوم أن التنمية تجتذب الكثير من الاهتمام. ولكن كيفية تشغيل الأنظمة من “اليوم الثاني” فصاعدا أمر بالغ الأهمية. يتضمن ذلك توفير مساحة التخزين وتقسيمها إلى مستويات، بالإضافة إلى النسخ الاحتياطي والاسترداد والأمان.
تتولى برامج تشغيل CSI الكثير من العمل الشاق، ولكن من المرجح أن تتطلع المؤسسات إلى الاستثمار في أجهزة جديدة، أو حتى التخزين من الموردين الذين يركزون على البيئات السحابية الأصلية، لتسهيل الترحيل إلى الحاويات.
يقول بولتون: “يتم ذلك عادةً من خلال نشر بنيات تخزين جديدة، إما عبر منتجات تخزين جديدة من البائعين الحاليين، ولكن بشكل متزايد من خلال التعامل مع البائعين الجدد”. ويضيف أن الشركات ربما لا تزال تستخدم أنظمة أجهزة قديمة، لكن من غير المرجح أن تستخدمها في نظام Kubernetes.
إقرأ المزيد