Azure Arc مقابل Azure Local: توضيح مصطلحات البنية التحتية الهجينة لدى Microsoft

By Mirko Peters · 2026-08-22

Automatically translated with AI from the original post. Read the English original

Titelbild: Azure Arc vs Azure Local: Clarifying Microsoft's Hybrid Infrastructure Terminology

أهلاً بعودتكم إلى البودكاست! إذا كنتم تتابعون حلقاتنا الأخيرة حول بنية تقنية المعلومات المؤسسية الحديثة، فأنتم تعلمون أننا نقضي وقتاً طويلاً في الحديث عن استراتيجيات السحابة الهجينة. وقد تلقيتُ مؤخراً رسالة بريد إلكتروني رائعة من مستمع اسمه Marcus من شيكاغو. كتب Marcus يقول: "أحاول تصميم البنية التحتية من الجيل التالي لشركتنا، لكن في كل مرة أقرأ فيها ورقة بيضاء من Microsoft، أضيع وسط المصطلحات الرنانة. ما الفرق الفعلي بين Azure Arc وAzure Local؟ هل هما منتجان متنافسان؟ وهل أحتاج إلى كليهما؟"

Marcus، أنت بالتأكيد لست وحدك. تمتلك Microsoft واحداً من أشمل النظم البيئية الهجينة في السوق اليوم، but مع هذا الاتساع يأتي كم هائل من المصطلحات. تُعاد تسمية المصطلحات، وتتغير الاختصارات، وفجأةً يجد مسؤولو تقنية المعلومات ومهندسو السحابة أنفسهم في حيرة حول الأداة التي تقوم بكل وظيفة. ولهذا تحديداً أردتُ تخصيص هذه المدونة لتفكيك هذين الركنين الأساسيين في استراتيجية Microsoft الهجينة. بنهاية هذه المقالة، ستمتلكون وضوحاً تاماً حول ماهية Azure Arc، وماهية Azure Local، وكيف يختلفان، والأهم من ذلك، كيف يمكن أن يعملا معاً لرفع كفاءة بنيتكم التحتية إلى أقصى حد.

مقدمة في تطوّر Microsoft الهجين

لفهم موقع Azure Arc وAzure Local اليوم، علينا العودة بالزمن إلى الوراء قليلاً. لعقود، كانت تقنية المعلومات المؤسسية ثنائية: إما أن تعيش أحمالك على خوادمك المادية في مركز بيانات محلي، أو في مركز بيانات لدى طرف آخر. ثم جاءت ثورة السحابة العامة بقيادة Microsoft Azure وAmazon Web Services وGoogle Cloud Platform. وفجأةً، سارعت المؤسسات إلى نقل كل شيء إلى السحابة، واعدةً بقابلية توسع لا حدود لها وخفض للنفقات الرأسمالية.

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

أشعل هذا الإدراك عصر السحابة الهجينة. أدركت Microsoft مبكراً أن المستقبل ليس السحابة العامة وحدها، بل سلسلة متصلة من الحافة إلى مركز البيانات إلى السحابة. وعلى مر السنين، طوّرت Microsoft أدوات متعددة لسدّ هذه الفجوة. صُممت بعض الأدوات لإدارة العتاد القائم، بينما صُممت أخرى لتحديث ذلك العتاد بالكامل. وهذا يقودنا إلى موضوعينا الرئيسيين اليوم: Azure Arc، الذي يتولى الإدارة والتحكم، وAzure Local، الذي يوفر أساس البنية التحتية فائقة التقارب فعلياً.

تفكيك المصطلحات: ما هو Azure Arc؟

لنبدأ بالنظر إلى Azure Arc. إذا أخذتم جملة واحدة فقط من هذا القسم، فاجعلوها هذه: Azure Arc هي مستوى تحكم، وليست منتجاً للبنية التحتية.

فكّروا في Azure Arc كعصا سحرية تمدّ مستوى التحكم في Azure، وهو الواجهة نفسها التي تستخدمونها لإدارة الأجهزة الافتراضية وقواعد البيانات وعناقيد Kubernetes في السحابة العامة لـ Azure، لتصل إلى مراكز بياناتكم ومواقع الحافة لديكم، بل وحتى إلى السحابات المنافسة مثل AWS وGoogle Cloud Platform.

كيف تعمل Azure Arc من الداخل

في جوهرها، تعمل Azure Arc عبر تثبيت وكلاء خفيفة الوزن على مواردكم الحالية أينما وُجدت. سواء كان لديكم خادم Linux فعلي يعمل في رف في فرانكفورت، أو جهاز افتراضي VMware في مكتبكم المحلي في شيكاغو، أو مثيل Amazon EC2، فإن Azure Arc تربط ذلك المورد بـ Azure. وبمجرد الربط، يُعرض المورد الخارجي ضمن Azure Resource Manager (ARM). وفجأةً، تظهر خوادمكم غير التابعة لـ Azure إلى جانب أجهزتكم الافتراضية الأصلية في Azure ضمن مدخل Azure.

يفتح هذا العرض مجموعة ضخمة من قدرات السحابة الأصلية لبنية تحتية لا تتصل فعلياً بالسحابة Azure أبداً:

الحوكمة والامتثال الموحدان: يمكنك تطبيق Azure Policy على الخوادم المحلية لديك لضمان بقاء التهيئات متوافقة عبر كامل بيئتك.
أمان متقدم: يمكن توسيع نطاق Microsoft Defender for Cloud ليشمل مراقبة التهديدات ونقاط الضعف على الخوادم غير الموجودة في Azure وعلى مجموعات Kubernetes.
المراقبة الأصلية للسحابة: يمكن لـ Azure Monitor جمع السجلات والمقاييس من البنية التحتية المحلية لديك، مما يمنحك لوحة عرض واحدة لمراقبة الأداء والحالة.
الخدمات المفعّلة بواسطة Arc: يمكنك حتى تشغيل Azure SQL Managed Instance وAzure PostgreSQL على البنية التحتية المحلية لديك، مع إدارتهما بالكامل من خلال مستوى التحكم في Azure.

والأهم من ذلك أن Azure Arc لا يهتم بنوع المضيف الافتراضي (Hypervisor) الذي تعمل عليه. فهو لا يحل محل VMware أو Hyper-V أو الإعداد المادي المباشر على الخادم. بل يضيف طبقة إدارة ذكية فوق ما لديك بالفعل.

فهم المصطلحات: ما هو Azure Local؟

بعد أن فهمنا Azure Arc بوصفه طبقة الإدارة، دعونا ننتقل إلى جانب البنية التحتية: Azure Local. إذا كان Azure Arc هو مستوى التحكم المعرّف بالبرمجيات الذي يصل إلى كل مكان، فإن Azure Local هو حل بنية تحتية فائقة التقارب (HCI) مصمم لتشغيل أحمال العمل محليًا في مركز البيانات أو على الحافة (Edge).

ربما تعرف هذه التقنية باسمها السابق: Azure Stack HCI. أعادت Microsoft مؤخرًا تسمية هذا العرض وتبسيطه تحت مظلة Azure Local بما يتوافق بشكل أفضل مع رسالتها الأساسية. يوفر Azure Local منصة حوسبة وتخزين وشبكات حديثة معرّفة بالبرمجيات، تُشغَّل على أجهزة معتمدة موجودة في مقراتك.

هندسة Azure Local

يجمع Azure Local بين تقنيات Windows Server وبرمجيات فائقة التقارب المتقدمة لتقديم إمكانات افتراضية وتخزين بمستوى المؤسسات. ويستخدم Hyper-V للافتراضية وStorage Spaces Direct للتخزين عالي الأداء المعرّف بالبرمجيات.

ما يجعل Azure Local فريدًا حقًا هو تكامله العميق والأصيل مع السحابة العامة من Azure منذ البداية. فبينما تحتاج منصات الافتراضية التقليدية إلى أدوات تابعة لجهات خارجية للاتصال بالسحابة، صُمم Azure Local ليكون متصلًا بالسحابة افتراضيًا. فهو يتيح لك تشغيل أجهزة Windows وLinux الافتراضية المألوفة، وكذلك مجموعات Azure Kubernetes Service (AKS)، محليًا على أجهزة تملكها وتديرها فعليًا.

تشمل الميزات الرئيسية لـ Azure Local ما يلي:

التوافر العالي والمرونة: يضمن التجميع المدمج وتكرار التخزين استمرار تشغيل أحمال العمل المحلية حتى في حال تعطل الأجهزة.
أشكال مادية مرنة: من عقد الحافة المقاومة للظروف القاسية المنشورة في المتاجر أو المصانع، إلى مجموعات متعددة العقد ضخمة في مراكز البيانات المؤسسية، يتكيف Azure Local مع المساحة المادية المتاحة لديك.
افتراضية مألوفة: إذا كان فريقك يعرف Hyper-V أو مفاهيم الافتراضية العامة، فإن اعتماد Azure Local يتطلب منحنى تعلم سلسًا للغاية.

الفروقات الرئيسية بين الإدارة والبنية التحتية

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

دعونا نفصّل الفروقات الجوهرية عبر عدة أبعاد رئيسية:

1. طبقة المكدس

يعمل Azure Arc بالكامل على مستوى طبقة الإدارة والتحكم. وهو خدمة سحابية تتيح لك تنظيم الموارد وحوكمتها وتأمينها. أما Azure Local فيعمل على مستوى طبقة البنية التحتية والحوسبة. وهو نظام تشغيل ومنصة فائقة التقارب توفر موارد الحوسبة والتخزين المادية والافتراضية التي تُنفَّذ فوقها تطبيقاتك فعليًا.

2. الاعتماد على الأجهزة

لأن Azure Arc أداة إدارة قائمة على الوكلاء، فهي لا تعتمد تقريباً على أي أجهزة محددة. يمكنك تثبيت وكيل Arc على خادم Dell عمره خمس سنوات يعمل بنسخة قديمة من Linux، أو على خادم HPE جديد يعمل بنظام Windows، أو حتى على جهاز افتراضي مستضاف في AWS. أما Azure Local فيتطلب أجهزة محددة ومعتمدة من شركاء الأجهزة لدى Microsoft. لا يمكنك ببساطة تثبيت Azure Local على أي جهاز عشوائي موجود في غرفة الخوادم لديك؛ إذ يتطلب عقد مجموعة معتمدة لضمان الأداء والموثوقية وقابلية الدعم.

3. الغرض الأساسي

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

متى تستخدم Azure Arc مقابل Azure Local

بعد أن حددنا ما تقدمه كل أداة، دعنا نتحدث عن اتخاذ القرار. في جلسات تخطيط البنية لديكم، كيف تعرفون متى تلجأون إلى Azure Arc ومتى تنشرون Azure Local؟

متى تستخدم Azure Arc

ينبغي عليك نشر Azure Arc عندما ترغب في جلب إمكانات إدارة Azure إلى بنية تحتية تملكها بالفعل ولا تخطط لاستبدالها في الوقت الحالي. على سبيل المثال:

لديك استثمار كبير في خوادم VMware أو خوادم Linux على الأجهزة المادية عبر مراكز بيانات عالمية متعددة، وتريد لوحة عرض واحدة في بوابة Azure لإدارة الامتثال ومراقبة السجلات وتطبيق النُهج.
تشغّل مجموعات Kubernetes على AWS أو Google Cloud، وتريد استخدام Azure GitOps وAzure Policy لإدارة عمليات النشر عبر كل هذه السحب في آن واحد.
تريد تشغيل خدمات بيانات Azure، مثل Azure SQL Managed Instance، محلياً دون ترحيل مكدس الافتراضية الأساسي بالكامل.

متى تستخدم Azure Local

ينبغي عليك نشر Azure Local عندما تسعى إلى تجديد البنية التحتية المحلية المتقادمة أو بناء بيئة حوسبة حافة جديدة، وترغب في أن تبدو هذه البنية المحلية وتعمل كامتداد لسحابة Azure:

أصبحت شبكة SAN التقليدية ومكدس الافتراضية لديك على وشك انتهاء عمرهما الافتراضي، وتريد استبدالهما ببنية HCI حديثة معرّفة بالبرمجيات تتكامل بشكل أصيل مع النسخ الاحتياطي للسحابة والتعافي من الكوارث والمراقبة في Azure.
تحتاج إلى حوسبة وتخزين منخفضي زمن الاستجابة في موقع حافة، مثل مستشفى أو متجر تجزئة أو مصنع، حيث يجب معالجة البيانات محلياً، لكنك تريد إدارة أحمال العمل تلك مركزياً من سحابة Azure.
تريد تشغيل Azure Kubernetes Service (AKS) محلياً مع دعم كامل وتكامل سلس مع خطوط عمليات النشر السحابية الحالية لديك.

كيف تعملان معاً في استراتيجية هجينة

وهنا يتحقق السحر فعلاً. فرغم أن Azure Arc وAzure Local منتجان مستقلان، فقد صممتهما Microsoft للعمل معاً بشكل أفضل. والواقع أن مجموعات Azure Local تُفعَّل تلقائياً مع Azure Arc افتراضياً!

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

دعنا نلقي نظرة على سيناريو هجين واقعي لنرى كيف يتجلى هذا التآزر عملياً. تخيل شركة لوجستية عالمية كبيرة:

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

في هذه البنية، يوفّر Azure Local الأساس المرن وعالي الأداء على الحافة، بينما يوفّر Azure Arc طبقة الحوكمة والتحكم الشاملة التي تربط البيئة الهجينة بأكملها ببعضها.

الخاتمة: تبسيط رحلتكم نحو السحابة الهجينة

قد يبدو التنقل في منظومة السحابة الهجينة لدى Microsoft مربكًا في البداية، لكن بمجرد ربط المصطلحات بطبقات البنية المعمارية المحددة، تتضح الصورة كاملة. تذكّروا القاعدة الذهبية: Azure Arc هو مستوى التحكم الإداري لكل شيء في كل مكان، بينما Azure Local هو البنية التحتية الحديثة فائقة التقارب للأحمال المحلية وأحمال الحافة.

عند تخطيط بنية المؤسسة للعام المقبل، لا تنظروا إلى هذه التقنيات على أنها خيار إما هذه أو تلك. بل انظروا إلى كيفية تكاملها. استخدموا Azure Arc لتوحيد استثماراتكم القائمة في تكنولوجيا المعلومات المتنوعة وحوكمتها، واستفيدوا من Azure Local عندما تحتاجون إلى تحديث البنية التحتية المحلية والحافة بمرونة النهج السحابي الأصيل.

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