البنية المرجعية الأساسية ل Azure Stack HCI

Azure Stack HCI
Azure Arc
Azure Key Vault
Azure Blob Storage
Azure Monitor
Microsoft Defender for Cloud

توفر هذه البنية المرجعية الأساسية إرشادات وتوصيات غير محددة لحمل العمل لتكوين Azure Stack HCI 23H2 والبنية الأساسية الأحدث لضمان نظام أساسي موثوق يمكنه نشر وإدارة أحمال العمل الظاهرية والمضمنة في حاويات عالية التوفر. تصف هذه البنية مكونات الموارد وخيارات تصميم نظام المجموعة للعقد الفعلية التي توفر ميزات الحوسبة والتخزين والشبكات المحلية. كما يصف كيفية استخدام خدمات Azure لتبسيط وتبسيط الإدارة اليومية ل Azure Stack HCI.

لمزيد من المعلومات حول أنماط بنية حمل العمل التي تم تحسينها للتشغيل على Azure Stack HCI، راجع المحتوى الموجود في قائمة التنقل في أحمال عمل Azure Stack HCI.

هذه البنية هي نقطة بداية لكيفية استخدام تصميم الشبكة المبدل للتخزين لنشر نظام مجموعة Azure Stack HCI متعدد العقد. يجب تصميم تطبيقات حمل العمل المنشورة على مجموعة Azure Stack HCI بشكل جيد. يجب نشر تطبيقات حمل العمل المصممة تصميما جيدا باستخدام مثيلات متعددة أو توفر عال لأي خدمات مهمة لحمل العمل وأن يكون لديها ضوابط مناسبة لاستمرارية الأعمال والتعافي من الكوارث (BCDR). تتضمن عناصر تحكم BCDR هذه النسخ الاحتياطية المنتظمة وقدرات تجاوز الفشل للتعافي من الكوارث. للتركيز على النظام الأساسي للبنية الأساسية ل HCI، يتم استبعاد جوانب تصميم حمل العمل هذه عن قصد من هذه المقالة.

لمزيد من المعلومات حول الإرشادات والتوصيات للركائز الخمس لإطار عمل Azure Well-Architected، راجع دليل خدمة Azure Stack HCI Well-Architected Framework.

تخطيط المقالة

بناء الأنظمة قرارات التصميم نهج إطار عمل جيد التصميم
معمار
حالات الاستخدام المحتملة
تفاصيل السيناريو
موارد النظام الأساسي
موارد دعم النظام الأساسي
نشر هذا السيناريو
خيارات تصميم نظام المجموعة
محركات الأقراص الفعلية
تصميم الشبكة
رصد
إدارة التحديث
موثوقيه
أمن
تحسين التكلفة
التميز التشغيلي
كفاءة الأداء

تلميح

شعار GitHubيوضح التنفيذ المرجعي لنظام مجموعة Azure Stack HCI 23H2 كيفية استخدام قالب Azure Resource Management (قالب ARM) وملف المعلمة لنشر توزيع متعدد الخوادم تبديلا ل Azure Stack HCI. بدلا من ذلك، يوضح مثال Bicep كيفية استخدام قالب Bicep لنشر نظام مجموعة Azure Stack HCI وموارد المتطلبات الأساسية الخاصة به.

بناء الأنظمة

رسم تخطيطي يوضح بنية مرجعية لنظام مجموعة Azure Stack HCI متعددة العقد مع مفاتيح تبديل ثنائية أعلى الرف (ToR) للاتصال الخارجي بين الشمال والجنوب.

لمزيد من المعلومات، راجع الموارد ذات الصلة.

حالات الاستخدام المحتملة

تتضمن حالات الاستخدام النموذجية ل Azure Stack HCI القدرة على تشغيل أحمال العمل عالية التوفر (HA) في المواقع المحلية أو مواقع الحافة، ما يوفر حلا لتلبية متطلبات حمل العمل. يمكنك:

  • توفير حل سحابي مختلط يتم نشره محليا لمعالجة سيادة البيانات أو التنظيم والامتثال أو متطلبات زمن الانتقال.

  • توزيع وإدارة أحمال عمل الحافة الظاهرية أو المستندة إلى الحاوية التي يتم نشرها في موقع واحد أو في مواقع متعددة. تمكن هذه الاستراتيجية التطبيقات والخدمات المهمة للأعمال من العمل بطريقة مرنة وفعالة من حيث التكلفة وقابلة للتطوير.

  • خفض التكلفة الإجمالية للملكية (TCO) باستخدام الحلول المعتمدة من قبل Microsoft، والنشر المستند إلى السحابة، والإدارة المركزية، والمراقبة والتنبيه.

  • توفير إمكانية توفير مركزية باستخدام Azure وAzure Arc لنشر أحمال العمل عبر مواقع متعددة باستمرار وأمان. تستخدم أدوات مثل مدخل Azure أو Azure CLI أو البنية الأساسية كقوالب التعليمات البرمجية (IaC) Kubernetes للتعبئة في حاويات أو ظاهرية حمل العمل التقليدية لدفع الأتمتة وقابلية التكرار.

  • الالتزام بمتطلبات الأمان والتوافق والتدقيق الصارمة. يتم نشر Azure Stack HCI مع وضع أمان متصلب تم تكوينه افتراضيا، أو آمن بشكل افتراضي. يتضمن Azure Stack HCI الأجهزة المعتمدة، والتمهيد الآمن، والوحدة النمطية للنظام الأساسي الموثوق به (TPM)، والأمان المستند إلى الظاهرية (VBS)، و Credential Guard، وسياسات التحكم في تطبيق Windows Defender المفروضة. كما أنه يتكامل مع خدمات الأمان وإدارة التهديدات الحديثة المستندة إلى السحابة مثل Microsoft Defender for Cloud وMicrosoft Sentinel.

تفاصيل السيناريو

توفر الأقسام التالية المزيد من المعلومات حول السيناريوهات وحالات الاستخدام المحتملة لهذه البنية المرجعية. تتضمن هذه الأقسام قائمة بمزايا الأعمال وأنواع موارد حمل العمل المثال التي يمكنك نشرها على Azure Stack HCI.

استخدام Azure Arc مع Azure Stack HCI

يتكامل Azure Stack HCI مباشرة مع Azure باستخدام Azure Arc لخفض TCO والنفقات التشغيلية. يتم نشر Azure Stack HCI وإدارته من خلال Azure، والذي يوفر تكاملا مضمنا ل Azure Arc من خلال نشر مكون جسر موارد Azure Arc. يتم تثبيت هذا المكون أثناء عملية نشر نظام مجموعة HCI. يتم تسجيل عقد نظام مجموعة Azure Stack HCI مع Azure Arc للخوادم كشرط أساسي لبدء النشر المستند إلى السحابة للمجموعة. أثناء النشر، يتم تثبيت الملحقات الإلزامية على كل عقدة نظام مجموعة، مثل Lifecycle Manager وMicrosoft Edge إدارة الجهاز وبيانات تتبع الاستخدام والتشخيص. يمكنك استخدام Azure Monitor وLog Analytics لمراقبة نظام مجموعة HCI بعد النشر عن طريق تمكين Azure Stack HCI Insights. يتم إصدار تحديثات الميزات ل Azure Stack HCI بشكل دوري لتحسين تجربة العملاء. يتم التحكم في التحديثات وإدارتها من خلال Azure Update Manager.

يمكنك نشر موارد حمل العمل مثل أجهزة Azure Arc الظاهرية (VMs) وخدمة Azure Kubernetes Service التي تدعم Azure Arc ومضيفي جلسة Azure Virtual Desktop الذين يستخدمون مدخل Azure عن طريق تحديد موقع مخصص لنظام مجموعة Azure Stack HCI كهدف لنشر حمل العمل. توفر هذه المكونات إدارة وإدارة ودعما مركزيا. إذا كان لديك ضمان برنامج نشط على التراخيص الأساسية لمركز بيانات Windows Server الحالي، يمكنك تقليل التكاليف بشكل أكبر من خلال تطبيق Azure Hybrid Benefit على Azure Stack HCI وأجهزة Windows Server الظاهرية ومجموعات AKS. يساعد هذا التحسين في إدارة التكاليف بشكل فعال لهذه الخدمات.

يوسع تكامل Azure وAzure Arc إمكانات أحمال العمل الظاهرية والمضمنة في حاويات Azure Stack HCI لتشمل:

  • أجهزة Azure Arc الظاهرية للتطبيقات أو الخدمات التقليدية التي تعمل في الأجهزة الظاهرية على Azure Stack HCI.

  • AKS على Azure Stack HCI للتطبيقات أو الخدمات الحاوية التي تستفيد من استخدام Kubernetes كمنصة تنسيق.

  • Azure Virtual Desktop لنشر مضيفي الجلسة لأحمال عمل Azure Virtual Desktop على Azure Stack HCI (محلي). يمكنك استخدام وحدة التحكم والإدارة في Azure لبدء إنشاء تجمع المضيف وتكوينه.

  • خدمات البيانات التي تدعم Azure Arc لمثيل Azure SQL المدار في حاويات أو قاعدة بيانات Azure لخادم PostgreSQL الذي يستخدم AKS الممكن بواسطة Azure Arc المستضاف على Azure Stack HCI.

  • ملحق Azure Event Grid الذي يدعم Azure Arc ل Kubernetes لنشر وسيط شبكة الأحداث ومكونات مشغل شبكة الأحداث. يتيح هذا النشر قدرات مثل مواضيع شبكة الأحداث والاشتراكات لمعالجة الأحداث.

  • التعلم الآلي الممكن بواسطة Azure Arc مع مجموعة AKS التي تم نشرها على Azure Stack HCI كهدف حساب لتشغيل Azure التعلم الآلي. يمكنك استخدام هذا النهج لتدريب أو توزيع نماذج التعلم الآلي على الحافة.

توفر أحمال العمل المتصلة ب Azure Arc تناسقا وأتمتة محسنين ل Azure لتوزيع Azure Stack HCI، مثل أتمتة تكوين نظام التشغيل الضيف باستخدام ملحقات Azure Arc VM أو تقييم التوافق مع لوائح الصناعة أو معايير الشركة من خلال نهج Azure. يمكنك تنشيط نهج Azure من خلال مدخل Microsoft Azure أو أتمتة IaC.

الاستفادة من تكوين الأمان الافتراضي Azure Stack HCI

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

تضمن الأجهزة المعتمدة من Azure Stack HCI التمهيد الآمن المضمن وواجهة البرامج الثابتة الموسعة الموحدة (UEFI) ودعم TPM. استخدم هذه التقنيات مع VBS للمساعدة في حماية أحمال العمل الحساسة للأمان. يمكنك استخدام تشفير محرك BitLocker لتشفير وحدات تخزين قرص التمهيد ومساحات التخزين مباشرة وحدات التخزين الثابتة. يوفر تشفير Server Message Block (SMB) تشفيرا تلقائيا لنسبة استخدام الشبكة بين الخوادم في نظام المجموعة (على شبكة التخزين) وتوقيع حركة مرور SMB بين عقد نظام المجموعة والأنظمة الأخرى. يساعد تشفير SMB أيضا على منع هجمات الترحيل ويسهل الامتثال للمعايير التنظيمية.

يمكنك إلحاق أجهزة Azure Stack HCI الظاهرية في Defender for Cloud لتنشيط التحليلات السلوكية المستندة إلى السحابة، واكتشاف التهديدات ومعالجتها، والتنبيه، وإعداد التقارير. إدارة أجهزة Azure Stack HCI الظاهرية في Azure Arc بحيث يمكنك استخدام نهج Azure لتقييم امتثالها للوائح الصناعة ومعايير الشركة.

المكونات

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

موارد النظام الأساسي

تتطلب البنية الموارد والمكونات الإلزامية التالية:

  • Azure Stack HCI هو حل بنية أساسية شديدة التقارب (HCI) يتم نشره محليا أو في مواقع الحافة باستخدام أجهزة الخادم الفعلية والبنية الأساسية للشبكات. يوفر Azure Stack HCI نظاما أساسيا لنشر وإدارة أحمال العمل الظاهرية مثل الأجهزة الظاهرية ومجموعات Kubernetes والخدمات الأخرى التي يتم تمكينها بواسطة Azure Arc. يمكن توسيع نطاق مجموعات Azure Stack HCI من نشر عقدة واحدة إلى ستة عشر عقدة كحد أقصى باستخدام فئات الأجهزة المتحقق منها أو المتكاملة أو المتميزة التي يوفرها شركاء الشركة المصنعة للمعدات الأصلية (OEM).

  • Azure Arc هي خدمة مستندة إلى السحابة توسع نموذج الإدارة استنادا إلى Azure Resource Manager إلى Azure Stack HCI والمواقع الأخرى غير Azure. يستخدم Azure Arc Azure كلوحة التحكم والإدارة لتمكين إدارة الموارد المختلفة مثل الأجهزة الظاهرية ومجموعات Kubernetes والبيانات الحاوية وخدمات التعلم الآلي.

  • Azure Key Vault هي خدمة سحابية يمكنك استخدامها لتخزين الأسرار والوصول إليها بأمان. السر هو أي شيء تريد تقييد الوصول إليه بإحكام، مثل مفاتيح واجهة برمجة التطبيقات وكلمات المرور والشهادات ومفاتيح التشفير وبيانات اعتماد المسؤول المحلي ومفاتيح استرداد BitLocker.

  • مراقب السحابة هو ميزة من ميزات Azure Storage التي تعمل كحصة نظام مجموعة تجاوز الفشل. تستخدم عقد نظام مجموعة Azure Stack HCI هذه الحصة للتصويت، ما يضمن توفرا عاليا للمجموعة. يتم إنشاء حساب التخزين وتكوين الشاهد أثناء عملية نشر سحابة Azure Stack HCI.

  • Update Manager هي خدمة موحدة مصممة لإدارة التحديثات وإدارتها ل Azure Stack HCI. يمكنك استخدام Update Manager لإدارة أحمال العمل التي يتم نشرها على Azure Stack HCI، بما في ذلك توافق تحديث نظام التشغيل الضيف لأجهزة Windows وLinux الظاهرية. يبسط هذا النهج الموحد إدارة التصحيح عبر Azure والبيئات المحلية والأنظمة الأساسية السحابية الأخرى من خلال لوحة معلومات واحدة.

موارد دعم النظام الأساسي

تتضمن البنية خدمات الدعم الاختيارية التالية لتعزيز قدرات النظام الأساسي:

  • المراقبة هي خدمة مستندة إلى السحابة لجمع وتحليل والعمل على سجلات التشخيص وبيانات تتبع الاستخدام من السحابة وأحمال العمل المحلية. يمكنك استخدام Monitor لزيادة توفر التطبيقات والخدمات وأدائها إلى أقصى حد من خلال حل مراقبة شامل. نشر Azure Stack HCI Insights لتبسيط إنشاء قاعدة جمع بيانات المراقبة (DCR) وتمكين مراقبة مجموعات Azure Stack HCI بسرعة.

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

  • Defender for Cloud هو نظام شامل لإدارة أمان البنية الأساسية. فهو يعزز وضع الأمان لمراكز البيانات الخاصة بك ويقدم حماية متقدمة من التهديدات لأحمال العمل المختلطة، سواء كانت موجودة في Azure أو في أي مكان آخر، وعبر البيئات المحلية.

  • Azure Backup هي خدمة مستندة إلى السحابة توفر حلا بسيطا وآمنا وفعالا من حيث التكلفة لنسخ بياناتك احتياطيا واستردادها من Microsoft Cloud. يستخدم Azure Backup Server لأخذ نسخة احتياطية من الأجهزة الظاهرية التي يتم نشرها على Azure Stack HCI وتخزينها في خدمة النسخ الاحتياطي.

  • Site Recovery هي خدمة للتعافي من الكوارث توفر قدرات BCDR من خلال تمكين تطبيقات الأعمال وأحمال العمل من الفشل في حالة حدوث كارثة أو انقطاع. يدير Site Recovery النسخ المتماثل وتجاوز الفشل لأحمال العمل التي تعمل على الخوادم الفعلية والأجهزة الظاهرية بين موقعها الأساسي (المحلي) وموقع ثانوي (Azure).

خيارات تصميم نظام المجموعة

من المهم فهم أداء حمل العمل ومتطلبات المرونة عند تصميم نظام مجموعة Azure Stack HCI. تتضمن هذه المتطلبات هدف وقت الاسترداد (RTO) وأوقات هدف نقطة الاسترداد (RPO) والحوسبة (CPU) والذاكرة ومتطلبات التخزين لجميع أحمال العمل التي يتم نشرها على نظام مجموعة Azure Stack HCI. تؤثر العديد من خصائص حمل العمل على عملية صنع القرار وتشمل:

  • قدرات بنية وحدة المعالجة المركزية (CPU)، بما في ذلك ميزات تقنية أمان الأجهزة، وعدد وحدات المعالجة المركزية، وتردد GHz (السرعة) وعدد الذاكرات الأساسية لكل مأخذ توصيل وحدة المعالجة المركزية.

  • متطلبات وحدة معالجة الرسومات (GPU) لحمل العمل، مثل التعلم الذكاء الاصطناعي أو الآلي أو الاستدلال أو عرض الرسومات.

  • الذاكرة لكل عقدة، أو كمية الذاكرة الفعلية المطلوبة لتشغيل حمل العمل.

  • عدد العقد الفعلية في نظام المجموعة التي يتراوح حجمها من 1 إلى 16 عقدة. الحد الأقصى لعدد العقد هو ثلاث عقد عند استخدام بنية الشبكة بدون تبديل للتخزين.

    • للحفاظ على مرونة الحساب، تحتاج إلى حجز عقد N+1 على الأقل بقيمة السعة في نظام المجموعة. تمكن هذه الاستراتيجية استنزاف العقدة للتحديثات أو الاسترداد من الانقطاعات المفاجئة مثل انقطاع التيار الكهربائي أو فشل الأجهزة.

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

  • متطلبات مرونة التخزين وسعته وأدائه:

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

    • السعة: يتم أخذ إجمالي التخزين المطلوب القابل للاستخدام بعد التسامح مع الخطأ أو النسخ في الاعتبار. هذا الرقم هو حوالي 33٪ من مساحة التخزين الأولية لأقراص مستوى السعة عند استخدام النسخ المتطابق ثلاثي الاتجاه.

    • الأداء: عمليات الإدخال/الإخراج في الثانية (IOPS) للنظام الأساسي الذي يحدد قدرات معدل نقل التخزين لحمل العمل عند ضربها في حجم كتلة التطبيق.

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

يرشدك قسم تفضيلات أداة تغيير الحجم عبر الأسئلة التي تتعلق بنوع النظام (Premier أو Integrated System أو Validated Node) وخيارات عائلة وحدة المعالجة المركزية. كما يساعدك على تحديد متطلبات المرونة الخاصة بك لنظام المجموعة. تأكد من:

  • حجز ما لا يقل عن عقد N+1 بقيمة السعة، أو عقدة واحدة، عبر نظام المجموعة.

  • احجز عقد N+2 بقيمة السعة عبر نظام المجموعة للحصول على مرونة إضافية. يمكن هذا الخيار النظام من تحمل فشل عقدة أثناء تحديث أو حدث غير متوقع آخر يؤثر على عقدتين في وقت واحد. كما يضمن وجود سعة كافية في نظام المجموعة لتشغيل حمل العمل على العقد المتبقية عبر الإنترنت.

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

الإخراج من أداة تغيير حجم Azure Stack HCI هو قائمة بوحدات SKU لحل الأجهزة الموصى بها والتي يمكن أن توفر سعة حمل العمل المطلوبة ومتطلبات مرونة النظام الأساسي استنادا إلى قيم الإدخال في مشروع Sizer. لمزيد من المعلومات حول حلول شركاء أجهزة OEM المتوفرة، راجع كتالوج حلول Azure Stack HCI. للمساعدة في تعيين حقوق استخدام وحدات SKU للحلول لتلبية متطلباتك، اتصل بموفر حلول الأجهزة المفضل لديك أو شريك تكامل النظام (SI).

محركات الأقراص الفعلية

تدعم Storage Spaces Direct أنواع محركات أقراص القرص الفعلية المتعددة التي تختلف في الأداء والسعة. عند تصميم مجموعة Azure Stack HCI، اعمل مع شريك الشركة المصنعة للمعدات الأصلية (OEM) الذي اخترته لتحديد أنواع محركات الأقراص الفعلية الأكثر ملاءمة لتلبية متطلبات السعة والأداء لحمل العمل الخاص بك. تتضمن الأمثلة تثبيت محركات الأقراص الثابتة (HDDs) أو محركات أقراص الحالة الصلبة (SSD) ومحركات أقراص NVMe. غالبا ما تسمى محركات الأقراص هذه بمحركات الأقراص المحمولة أو تخزين الذاكرة الثابتة (PMem)، والذي يعرف باسم ذاكرة فئة التخزين (SCM).

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

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

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

توفر Storage Spaces Direct ذاكرة تخزين مؤقت مضمنة ومستمرة وفي الوقت الفعلي وقراءتها وكتابتها ومن جانب الخادم تزيد من أداء التخزين. يجب تغيير حجم ذاكرة التخزين المؤقت وتكوينها لاستيعاب مجموعة العمل للتطبيقات وأحمال العمل الخاصة بك. يتم استخدام الأقراص الظاهرية ل Storage Spaces Direct، أو وحدات التخزين، مع ذاكرة التخزين المؤقت للقراءة في الذاكرة المشتركة للمجموعة (CSV) لتحسين أداء Hyper-V، خاصة للوصول غير المخزن مؤقتا إلى القرص الثابت الظاهري لحمل العمل (VHD) أو ملفات القرص الثابت الظاهري v2 (VHDX).

تلميح

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

تصميم الشبكة

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

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

تتطلب هذه البنية عقدتين فعليتين أو أكثر وما يصل إلى 16 عقدة كحد أقصى على نطاق واسع. تتطلب كل عقدة أربعة منافذ محول شبكة متصلة بمفاتيح تبديل أعلى الرف (ToR). يجب أن تكون مفاتيح تبديل ToR مترابطة من خلال ارتباطات مجموعة تجميع الارتباطات متعددة الهيكل (MLAG). يجب أن يدعم منفذا محول الشبكة المستخدمان لحركة مرور هدف التخزين الوصول المباشر للذاكرة عن بعد (RDMA). تتطلب هذه المنافذ حدا أدنى من سرعة الارتباط تبلغ 10 جيجابت في الثانية، لكننا نوصي بسرعة 25 جيجابت في الثانية أو أعلى. يتم تقارب منفذي محول الشبكة المستخدمان لأغراض الإدارة والحوسبة باستخدام تقنية تبديل الفريق المضمن (SET). توفر تقنية SET قدرات تكرار الارتباط وموازنة التحميل. تتطلب هذه المنافذ حدا أدنى من سرعة الارتباط تبلغ 1 جيجابت في الثانية، ولكن نوصي بسرعة 10 جيجابت في الثانية أو أعلى.

مخطط الشبكة الفعلية

يظهر مخطط الشبكة الفعلية التالي الاتصالات الفعلية الفعلية بين العقد ومكونات الشبكات.

تحتاج إلى المكونات التالية عند تصميم توزيع Azure Stack HCI لتخزين متعدد العقد الذي يستخدم بنية الأساس هذه:

رسم تخطيطي يوضح مخطط الشبكات الفعلية لمجموعة Azure Stack HCI متعددة العقد التي تستخدم بنية تخزين مبدلة مع مفاتيح تبديل ToR مزدوجة.

  • مفاتيح التبديل ثنائية ال ToR:

    • مفاتيح تبديل الشبكة ثنائية ToR مطلوبة لمرونة الشبكة، والقدرة على خدمة تحديثات البرامج الثابتة أو تطبيقها، على مفاتيح التبديل دون تكبد وقت تعطل. تمنع هذه الاستراتيجية نقطة فشل واحدة (SPoF).

    • يتم استخدام مفاتيح تبديل ToR المزدوجة لتخزين حركة المرور، أو من الشرق إلى الغرب. تستخدم هذه المفاتيح منفذي Ethernet مخصصين يحتويان على شبكات منطقة محلية ظاهرية خاصة بالتخزين (VLANs) وفئات حركة مرور التحكم في التدفق ذات الأولوية (PFC) التي تم تعريفها لتوفير اتصال RDMA بدون فقدان.

    • تتصل هذه المفاتيح بالعقد من خلال كابلات Ethernet.

  • عقدتان فعليتان أو أكثر وما يصل إلى 16 عقدة كحد أقصى:

    • كل عقدة هي خادم فعلي يقوم بتشغيل نظام التشغيل Azure Stack HCI.

    • تتطلب كل عقدة أربعة منافذ لمحول الشبكة إجمالا: منفذان قادران على RDMA للتخزين ومنافذ محول شبكة للإدارة واحوسبة نسبة استخدام الشبكة.

    • يستخدم التخزين منفذي محول شبكة مخصصين قادرين على RDMA يتصلان بمسار واحد لكل من مفتاحي تبديل ToR. يوفر هذا الأسلوب تكرار مسار الارتباط وعرض النطاق الترددي المخصص ذي الأولوية لحركة مرور التخزين المباشر ل SMB.

    • تستخدم الإدارة والحوسبة منفذين لمحول الشبكة يوفران مسارا واحدا لكل من مفاتيح تبديل ToR لتكرار مسار الارتباط.

  • الاتصال الخارجي:

    • تتصل مفاتيح التبديل المزدوجة بالشبكات الخارجية، مثل الشبكة المحلية المحلية للشركات، لتوفير الوصول إلى عناوين URL الصادرة المطلوبة باستخدام جهاز شبكة حدود الحافة. يمكن أن يكون هذا الجهاز جدار حماية أو جهاز توجيه. تقوم هذه المفاتيح بتوجيه نسبة استخدام الشبكة التي تنتقل داخل وخارج نظام مجموعة Azure Stack HCI أو حركة المرور بين الشمال والجنوب.

    • يدعم الاتصال الخارجي لنسبة استخدام الشبكة بين الشمال والجنوب هدف إدارة نظام المجموعة ومقاصر الحوسبة. يتم تحقيق ذلك باستخدام منفذي تبديل ومنافذ محول شبكة اتصال لكل عقدة يتم تقاربها من خلال تبديل الفريق المضمن (SET) ومحول ظاهري داخل Hyper-V لضمان المرونة. تعمل هذه المكونات لتوفير اتصال خارجي لأجهزة Azure Arc الظاهرية وموارد حمل العمل الأخرى المنشورة داخل الشبكات المنطقية التي تم إنشاؤها في Resource Manager باستخدام مدخل Microsoft Azure أو CLI أو قوالب IaC.

طبولوجيا الشبكة المنطقية

يعرض مخطط الشبكة المنطقي نظرة عامة حول كيفية تدفق بيانات الشبكة بين الأجهزة، بغض النظر عن اتصالاتها الفعلية.

ملخص الإعداد المنطقي لبنية الأساس المحولة لتخزين العقد المتعددة ل Azure Stack HCI كما يلي:

رسم تخطيطي يوضح تخطيط الشبكة المنطقية لمجموعة Azure Stack HCI متعددة العقد باستخدام بنية التخزين المبدلة مع مفاتيح تبديل ToR مزدوجة.

  • مفاتيح التبديل ثنائية ال ToR:

    • قبل نشر نظام المجموعة، يجب تكوين مبدلي شبكة ToR باستخدام معرفات VLAN المطلوبة، والحد الأقصى لإعدادات وحدة الإرسال، وتكوين جسر مركز البيانات لمنافذ الإدارة والحوسبة والتخزين. لمزيد من المعلومات، راجع متطلبات الشبكة الفعلية ل Azure Stack HCI، أو اطلب من مورد أجهزة التبديل أو شريك SI المساعدة.
  • يستخدم Azure Stack HCI نهج ATC للشبكة لتطبيق أتمتة الشبكة وتكوين الشبكة المستندة إلى الهدف.

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

    • تبسط النهج المستندة إلى الهدف متطلبات تكوين الشبكة عن طريق أتمتة تكوين شبكة العقدة استنادا إلى مدخلات المعلمات المحددة كجزء من عملية نشر سحابة Azure Stack HCI.

  • الاتصال الخارجي:

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

    • عندما تعمل مفاتيح تبديل ToR كأجهزة من الطبقة 3، فإنها تتعامل مع التوجيه وتوفر اتصالا خارج نظام المجموعة بجهاز حدود الحافة، مثل جدار الحماية أو الموجه.

    • يستخدم هدف شبكة الإدارة الواجهة الظاهرية لفريق SET المتقاربة، والتي تمكن عنوان IP لإدارة نظام المجموعة وموارد وحدة التحكم من الاتصال خارجيا.

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

  • نسبة استخدام الشبكة للتخزين:

    • تتصل العقد الفعلية مع بعضها باستخدام منفذين مخصصين لمحول الشبكة المتصلين بمفاتيح تبديل ToR لتوفير عرض نطاق ترددي عال ومرونة لحركة مرور التخزين.

    • يتصل منفذا التخزين SMB1 وSMB2 بشبكتين منفصلتين غير قابلتين للتوجيه (أو الطبقة 2). تحتوي كل شبكة على معرف VLAN محدد تم تكوينه يجب أن يتطابق مع تكوين منافذ التبديل على معرفات VLAN للتخزين الافتراضي ل ToR: 711 و712.

    • لا توجد بوابة افتراضية تم تكوينها على منفذي محول شبكة هدف التخزين داخل نظام تشغيل عقدة Azure Stack HCI.

    • يمكن لكل عقدة الوصول إلى قدرات Storage Spaces Direct لنظام المجموعة، مثل الأقراص الفعلية البعيدة المستخدمة في تجمع التخزين والأقراص الظاهرية ووحدات التخزين. يتم تسهيل الوصول إلى هذه الإمكانات من خلال بروتوكول SMB-Direct RDMA عبر منفذي محول شبكة التخزين المخصصين المتوفرين في كل عقدة. يتم استخدام SMB Multichannel للمرونة.

    • يوفر هذا التكوين سرعة كافية لنقل البيانات للعمليات المتعلقة بالتخزين، مثل الاحتفاظ بنسخ متسقة من البيانات لوحدات التخزين المتطابقة.

متطلبات تبديل الشبكة

يجب أن تفي مفاتيح Ethernet بالمواصفات المختلفة المطلوبة من قبل Azure Stack HCI وتعيينها من قبل معهد معايير مهندسي الكهرباء والإلكترونيات (IEEE SA). على سبيل المثال، بالنسبة إلى عمليات التوزيع المبدلة للتخزين متعدد العقد، يتم استخدام شبكة التخزين ل RDMA عبر RoCE v2 أو iWARP. تتطلب هذه العملية IEEE 802.1Qbb PFC لضمان الاتصال بدون فقدان لفئة نسبة استخدام الشبكة للتخزين. يجب أن توفر مفاتيح تبديل ToR الدعم ل IEEE 802.1Q ل VLANs وIEEE 802.1AB لبروتوكول اكتشاف طبقة الارتباط.

إذا كنت تخطط لاستخدام مفاتيح الشبكة الموجودة لتوزيع Azure Stack HCI، فراجع قائمة معايير ومواصفات IEEE الإلزامية التي يجب أن توفرها مفاتيح الشبكة والتكوين. عند شراء مفاتيح تبديل شبكة جديدة، اتصل بمورد التبديل للتأكد من أن الأجهزة تفي بمتطلبات مواصفات Azure Stack HCI IEEE، أو راجع قائمة نماذج التبديل المعتمدة من مورد الأجهزة التي تدعم متطلبات شبكة Azure Stack HCI.

متطلبات عنوان IP

في نشر تبديل تخزين متعدد العقد، يزداد عدد عناوين IP المطلوبة مع إضافة كل عقدة فعلية، بحد أقصى 16 عقدة داخل مجموعة واحدة. على سبيل المثال، لنشر تكوين مخزن ثنائي العقدة تبديل من Azure Stack HCI، تتطلب البنية الأساسية لنظام المجموعة ما لا يقل عن 11 x عناوين IP ليتم تخصيصها. مطلوب المزيد من عناوين IP إذا كنت تستخدم التجزئة الدقيقة أو الشبكات المعرفة بالبرامج. لمزيد من المعلومات، راجع مراجعة متطلبات عنوان IP لنمط التخزين المكون من عقدتين ل Azure Stack HCI.

عند تصميم وتخطيط متطلبات عنوان IP ل Azure Stack HCI، تذكر حساب عناوين IP الإضافية أو نطاقات الشبكة المطلوبة لحمل العمل الخاص بك بخلاف تلك المطلوبة لمكونات نظام مجموعة البنية الأساسية وAzure Stack HCI. إذا كنت تخطط لنشر AKS على Azure Stack HCI، فشاهد AKS التي تم تمكينها بواسطة متطلبات شبكة Azure Arc.

مراقبة‬

لتحسين المراقبة والتنبيه، قم بتمكين Monitor Insights على Azure Stack HCI. يمكن للرؤى توسيع نطاقها لمراقبة وإدارة مجموعات محلية متعددة باستخدام تجربة متناسقة مع Azure. تستخدم نتائج التحليلات عدادات أداء نظام المجموعة وقنوات سجل الأحداث لمراقبة ميزات Azure Stack HCI الرئيسية. يتم تجميع السجلات بواسطة DCR الذي تم تكوينه من خلال Monitor وLog Analytics.

تم إنشاء Azure Stack HCI Insights باستخدام Monitor وLog Analytics، ما يضمن حلا محدثا وقابلا للتطوير قابلا للتخصيص بشكل كبير. توفر Insights الوصول إلى المصنفات الافتراضية باستخدام المقاييس الأساسية، إلى جانب المصنفات المتخصصة التي تم إنشاؤها لمراقبة الميزات الرئيسية ل Azure Stack HCI. توفر هذه المكونات حلا للمراقبة في الوقت الفعلي تقريبا وتمكن من إنشاء الرسوم البيانية وتخصيص المرئيات من خلال التجميع والتصفية وتكوين قواعد تنبيه صحة الموارد المخصصة.

إدارة التحديثات

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

تحديثات البنية الأساسية

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

Update Manager هي خدمة Azure يمكنك استخدامها لتطبيق التحديثات وعرضها وإدارتها ل Azure Stack HCI. توفر هذه الخدمة آلية لعرض جميع مجموعات Azure Stack HCI عبر البنية الأساسية بالكامل ومواقع الحافة باستخدام مدخل Microsoft Azure لتوفير تجربة إدارة مركزية. لمزيد من المعلومات، راجع الموارد التالية:

من المهم التحقق من وجود تحديثات برامج تشغيل وبرامج ثابتة جديدة بانتظام، مثل كل ثلاثة إلى ستة أشهر. إذا كنت تستخدم إصدار فئة حل Premier لأجهزة Azure Stack HCI، يتم دمج تحديثات حزمة ملحق منشئ الحلول مع Update Manager لتوفير تجربة تحديث مبسطة. إذا كنت تستخدم العقد التي تم التحقق من صحتها أو فئة نظام متكاملة، فقد يكون هناك شرط لتنزيل حزمة تحديث خاصة بالشركة المصنعة للمعدات الأصلية (OEM) التي تحتوي على تحديثات البرامج الثابتة وبرامج التشغيل لأجهزتك وتشغيلها. لتحديد كيفية توفير التحديثات لأجهزتك، اتصل بالشركة المصنعة للمعدات الأصلية (OEM) أو شريك SI.

تصحيح نظام تشغيل ضيف حمل العمل

يمكنك تسجيل أجهزة Azure Arc الظاهرية التي يتم نشرها على Azure Stack HCI باستخدام Azure Update Manager (AUM) لتوفير تجربة إدارة تصحيح موحدة باستخدام نفس الآلية المستخدمة لتحديث العقد الفعلية لنظام مجموعة Azure Stack HCI. يمكنك استخدام AUM لإنشاء تكوينات صيانة الضيف. تتحكم هذه التكوينات في الإعدادات مثل إعادة تشغيل إعداد إعادة التشغيل إذا لزم الأمر، والجدول الزمني (التواريخ والأوقات وخيارات التكرار)، وإما قائمة ديناميكية (اشتراك) أو قائمة ثابتة لأجهزة Azure Arc الظاهرية للنطاق. تتحكم هذه الإعدادات في التكوين عند تثبيت تصحيحات أمان نظام التشغيل داخل نظام التشغيل الضيف لعبء العمل الخاص ب VM.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الموثوقيه

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

تحديد نقاط الفشل المحتملة

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

المكون مخاطر الاحتمالية التأثير/التخفيف/الملاحظة انقطاع
انقطاع نظام مجموعة Azure Stack HCI فشل الطاقة أو الشبكة أو الأجهزة أو البرامج متوسط لمنع انقطاع التطبيق لفترة طويلة بسبب فشل مجموعة Azure Stack HCI لحالات الاستخدام الأعمال أو المهام الحرجة، يجب تصميم حمل العمل الخاص بك باستخدام مبادئ HA وDR. على سبيل المثال، يمكنك استخدام تقنيات النسخ المتماثل لبيانات حمل العمل القياسية في الصناعة للحفاظ على نسخ متعددة من بيانات الحالة الثابتة التي يتم نشرها باستخدام العديد من أجهزة Azure Arc الظاهرية أو مثيلات AKS التي يتم نشرها على مجموعات Azure Stack HCI منفصلة وفي مواقع فعلية منفصلة. الانقطاع المحتمل
انقطاع عقدة فعلية واحدة في Azure Stack HCI فشل الطاقة أو الأجهزة أو البرامج متوسط لمنع انقطاع التطبيق لفترة طويلة بسبب فشل عقدة Azure Stack HCI واحدة، يجب أن يحتوي نظام مجموعة Azure Stack HCI على عقد فعلية متعددة. تحدد متطلبات سعة حمل العمل أثناء مرحلة تصميم نظام المجموعة عدد العقد. نوصي بأن يكون لديك ثلاث عقد أو أكثر. نوصي أيضا باستخدام النسخ المتطابق ثلاثي الاتجاه، وهو وضع مرونة التخزين الافتراضي للمجموعات التي تحتوي على ثلاث عقد أو أكثر. لمنع SPoF وزيادة مرونة حمل العمل، انشر مثيلات متعددة من حمل العمل الخاص بك باستخدام اثنين أو أكثر من أجهزة Azure Arc الظاهرية أو حاويات الحاوية التي تعمل في عقد عامل AKS متعددة. إذا فشلت عقدة واحدة، تتم إعادة تشغيل أجهزة Azure Arc الظاهرية وأحمال العمل / خدمات التطبيق على العقد الفعلية المتبقية عبر الإنترنت في نظام المجموعة. الانقطاع المحتمل
Azure Arc VM أو عقدة عامل AKS (حمل العمل) خطأ في التكوين متوسط يتعذر على مستخدمي التطبيق تسجيل الدخول أو الوصول إلى التطبيق. يجب اكتشاف التكوينات الخاطئة أثناء النشر. إذا حدثت هذه الأخطاء أثناء تحديث التكوين، يجب على فريق DevOps التراجع عن التغييرات. يمكنك إعادة نشر الجهاز الظاهري إذا لزم الأمر. تستغرق إعادة التوزيع أقل من 10 دقائق للتوزيع ولكن يمكن أن تستغرق وقتا أطول وفقا لنوع التوزيع. الانقطاع المحتمل
الاتصال بـ Azure انقطاع الشبكة متوسط يحتاج نظام المجموعة إلى الوصول إلى مستوى التحكم في Azure بانتظام لإمكانيات الفوترة والإدارة والمراقبة. إذا فقدت المجموعة الاتصال ب Azure، فإنها تعمل في حالة متدهورة. على سبيل المثال، لن يكون من الممكن نشر أجهزة Azure Arc الظاهرية الجديدة أو مجموعات AKS إذا فقدت مجموعتك الاتصال ب Azure. يستمر تشغيل أحمال العمل الحالية التي تعمل على مجموعة HCI، ولكن يجب عليك استعادة الاتصال في غضون 48 إلى 72 ساعة لضمان التشغيل دون انقطاع. بلا

لمزيد من المعلومات، راجع توصيات إجراء تحليل وضع الفشل.

أهداف الموثوقية

يصف هذا القسم سيناريو مثال. يستخدم عميل وهمي يسمى Contoso Manufacturing هذه البنية المرجعية لنشر Azure Stack HCI. إنهم يريدون تلبية متطلباتهم ونشر وإدارة أحمال العمل المحلية. لدى شركة Contoso Manufacturing هدف داخلي على مستوى الخدمة (SLO) بنسبة 99.8٪ يتفق عليه أصحاب المصلحة في الأعمال والتطبيقات لخدماتهم.

  • ينتج عن SLO بنسبة 99.8٪ وقت التشغيل أو التوفر، في الفترات التالية من وقت التعطل المسموح به، أو عدم التوفر، للتطبيقات التي يتم نشرها باستخدام Azure Arc VMs التي تعمل على Azure Stack HCI:

    • أسبوعيا: 20 دقيقة و10 ثوان

    • شهريا: ساعة واحدة و26 دقيقة و56 ثانية

    • ربع سنوي: 4 ساعات و20 دقيقة و49 ثانية

    • سنويا: 17 ساعة و23 دقيقة و16 ثانية

  • للمساعدة في تلبية أهداف SLO، تنفذ شركة Contoso Manufacturing مبدأ الامتياز الأقل (PoLP) لتقييد عدد مسؤولي مجموعة Azure Stack HCI إلى مجموعة صغيرة من الأفراد الموثوق بهم والمؤهلين. يساعد هذا الأسلوب على منع التوقف عن العمل بسبب أي إجراءات غير مقصودة أو عرضية يتم تنفيذها على موارد الإنتاج. علاوة على ذلك، تتم مراقبة سجلات أحداث الأمان لوحدات تحكم المجال Active Directory محلي Domain Services (AD DS) للكشف عن أي تغييرات في عضوية مجموعة حساب المستخدم والإبلاغ عنها، والمعروفة باسم إضافة إجراءات وإزالتها، لمجموعة مسؤولي نظام مجموعة Azure Stack HCI باستخدام حل إدارة أحداث معلومات الأمان (SIEM). تزيد المراقبة من الموثوقية وتحسن أمان الحل.

    لمزيد من المعلومات، راجع توصيات إدارة الهوية والوصول.

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

    لمزيد من المعلومات، راجع توصيات ممارسات النشر الآمنة.

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

    لمزيد من المعلومات، راجع توصيات إنشاء أساس أمان.

  • تقوم شركة Contoso Manufacturing بتنفيذ النسخ الاحتياطية اليومية والأسبوعية والشهرية للاحتفاظ بآخر 6 × أيام من النسخ الاحتياطية اليومية (من الاثنين إلى السبت)، وآخر 3 × أسبوعيا (كل يوم أحد) و3 × نسخ احتياطية شهرية، مع الاحتفاظ كل أسبوع من أيام الأحد 4 لتصبح النسخ الاحتياطية للشهر 1 والشهر 2 والشهر 3 باستخدام جدول زمني مستند إلى تقويم متداول موثق وقابل للتدقيق. يلبي هذا النهج متطلبات تصنيع Contoso لتحقيق توازن كاف بين عدد نقاط استرداد البيانات المتاحة وتقليل تكاليف خدمة تخزين النسخ الاحتياطي خارج الموقع أو السحابة.

    لمزيد من المعلومات، راجع توصيات لتصميم استراتيجية التعافي من الكوارث.

  • يتم اختبار عمليات النسخ الاحتياطي والاسترداد للبيانات لكل نظام عمل كل ستة أشهر. توفر هذه الاستراتيجية ضمانا بأن عمليات BCDR صالحة وأن الأعمال محمية في حالة وقوع كارثة مركز بيانات أو حادث إلكتروني.

    لمزيد من المعلومات، راجع توصيات لتصميم استراتيجية اختبار الموثوقية.

  • تمكن العمليات والإجراءات التشغيلية الموضحة سابقا في المقالة، والتوصيات الواردة في دليل خدمة إطار العمل المصمم جيدا ل Azure Stack HCI، Contoso Manufacturing من تحقيق هدف SLO بنسبة 99.8٪ وتوسيع نطاق وإدارة Azure Stack HCI وتوزيع حمل العمل عبر مواقع تصنيع متعددة موزعة في جميع أنحاء العالم.

    لمزيد من المعلومات، راجع توصيات لتحديد أهداف الموثوقية.

التكرار

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

استخدم أنماط قياسية في الصناعة وعالية التوفر لأحمال العمل التي توفر النسخ المتماثل النشط/السلبي أو النسخ المتماثل المتزامن أو النسخ المتماثل غير المتزامن مثل SQL Server Always On. يمكنك أيضا استخدام تقنية موازنة تحميل الشبكة الخارجية (NLB) التي توجه طلبات المستخدم عبر مثيلات حمل العمل المتعددة التي تعمل على مجموعات Azure Stack HCI التي تقوم بنشرها في مواقع فعلية منفصلة. ضع في اعتبارك استخدام جهاز NLB خارجي لشريك. أو يمكنك تقييم خيارات موازنة التحميل التي تدعم توجيه نسبة استخدام الشبكة للخدمات المختلطة والأماكن المحلية، مثل مثيل Azure Application Gateway الذي يستخدم Azure ExpressRoute أو نفق VPN للاتصال بخدمة محلية.

لمزيد من المعلومات، راجع توصيات التصميم للتكرار.

الأمان

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

تشمل اعتبارات الأمان ما يلي:

  • أساس آمن للنظام الأساسي Azure Stack HCI: Azure Stack HCI هو منتج آمن بشكل افتراضي يستخدم مكونات الأجهزة التي تم التحقق من صحتها مع TPM وUEFI وSecure Boot لبناء أساس آمن للنظام الأساسي Azure Stack HCI وأمان حمل العمل. عند توزيعه مع إعدادات الأمان الافتراضية، يتم تمكين Azure Stack HCI التحكم في تطبيق Windows Defender و Credential Guard و BitLocker. لتبسيط أذونات التفويض باستخدام PoLP، استخدم أدوار التحكم في الوصول المستندة إلى الدور (RBAC) في Azure Stack HCI، مثل مسؤول Azure Stack HCI لمسؤولي النظام الأساسي وAzure Stack HCI VM Contributor أو Azure Stack HCI VM Reader لمشغلي حمل العمل.

  • إعدادات الأمان الافتراضية: يطبق الإعداد الافتراضي لأمان Azure Stack HCI إعدادات الأمان الافتراضية لنظام مجموعة Azure Stack HCI أثناء النشر ويمكن التحكم في الانجراف للحفاظ على العقد في حالة جيدة معروفة. يمكنك استخدام إعدادات الأمان الافتراضية لإدارة أمان نظام المجموعة والتحكم في الانجراف وإعدادات الخادم الأساسي الآمنة على نظام المجموعة.

  • سجلات أحداث الأمان: تتكامل إعادة توجيه سجل Syslog Azure Stack HCI مع حلول مراقبة الأمان عن طريق استرداد سجلات أحداث الأمان ذات الصلة لتجميع الأحداث وتخزينها للاحتفاظ بها في النظام الأساسي SIEM الخاص بك.

  • الحماية من التهديدات والثغرات الأمنية: يحمي Defender for Cloud مجموعات Azure Stack HCI من التهديدات والثغرات الأمنية المختلفة. تساعد هذه الخدمة على تحسين وضع الأمان لبيئة Azure Stack HCI ويمكنها الحماية من التهديدات الحالية والمتطورة.

  • الكشف عن التهديدات ومعالجتها: تكتشف Microsoft Advanced Threat Analytics التهديدات وتعيد معالجتها، مثل تلك التي تستهدف AD DS، والتي توفر خدمات المصادقة لعقد نظام مجموعة Azure Stack HCI وأحمال عمل الجهاز الظاهري ل Windows Server.

  • عزل الشبكة: عزل الشبكات إذا لزم الأمر. على سبيل المثال، يمكنك توفير شبكات منطقية متعددة تستخدم شبكات VLANs ونطاقات عناوين شبكة منفصلة. عند استخدام هذا الأسلوب، تأكد من أن شبكة الإدارة يمكنها الوصول إلى كل شبكة منطقية وVLAN بحيث يمكن لعقد نظام مجموعة Azure Stack HCI الاتصال بشبكات VLAN من خلال مفاتيح تبديل ToR أو البوابات. هذا التكوين مطلوب لإدارة حمل العمل، مثل السماح لوكلاء إدارة البنية التحتية بالاتصال بنظام التشغيل الضيف لحمل العمل.

    لمزيد من المعلومات، راجع توصيات بناء استراتيجية التجزئة.

تحسين التكلفة

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

تتضمن اعتبارات تحسين التكلفة ما يلي:

  • نموذج الفوترة على غرار السحابة للترخيص: يتبع تسعير Azure Stack HCI نموذج فوترة الاشتراك الشهري بمعدل ثابت لكل نواة معالج فعلي في مجموعة Azure Stack HCI. يتم تطبيق رسوم استخدام إضافية إذا كنت تستخدم خدمات Azure الأخرى. إذا كنت تملك تراخيص أساسية محلية لإصدار Windows Server Datacenter مع ضمان البرنامج النشط، فقد تختار تبادل هذه التراخيص لتنشيط نظام مجموعة Azure Stack HCI ورسوم اشتراك Windows Server VM.

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

  • دمج مراقبة التكلفة: لدمج تكاليف المراقبة، استخدم Azure Stack HCI Insights والتصحيح باستخدام Update Manager ل Azure Stack HCI. تستخدم نتائج التحليلات Monitor لتوفير مقاييس غنية وقدرات تنبيه. يتكامل مكون إدارة دورة حياة Azure Stack HCI مع Update Manager لتبسيط مهمة الحفاظ على تحديث أنظمة المجموعات الخاصة بك عن طريق دمج مهام سير عمل التحديث لمختلف المكونات في تجربة واحدة. استخدم Monitor and Update Manager لتحسين تخصيص الموارد والمساهمة في الكفاءة الإجمالية للتكلفة.

    لمزيد من المعلومات، راجع توصيات لتحسين وقت الموظفين.

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

    لمزيد من المعلومات، راجع توصيات لتحسين تكاليف المكونات.

تلميح

يمكنك توفير التكاليف باستخدام Azure Hybrid Benefit إذا كان لديك تراخيص Windows Server Datacenter مع ضمان البرنامج النشط. لمزيد من المعلومات، راجع Azure Hybrid Benefit ل Azure Stack HCI.

التميز التشغيلي

يغطي التميز التشغيلي عمليات التشغيل التي تحافظ على تشغيل التطبيق في الإنتاج. لمزيد من المعلومات، يرجى مراجعةنظرة عامة على ركيزة التميز التشغيلي.

تشمل اعتبارات التميز التشغيلي ما يلي:

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

  • قدرات التنفيذ التلقائي للأجهزة الظاهرية: يوفر Azure Stack HCI مجموعة واسعة من إمكانات التشغيل التلقائي لإدارة أحمال العمل، مثل Azure Arc VMs، مع النشر التلقائي لأجهزة Azure Arc الظاهرية باستخدام قالب Azure CLI أو ARM أو Bicep، مع تحديثات نظام تشغيل الجهاز الظاهري باستخدام ملحق Azure Arc للتحديثات وAzure Update Manager لتحديث كل مجموعة Azure Stack HCI. يوفر Azure Stack HCI أيضا دعما لإدارة Azure Arc VM باستخدام Azure CLI والأجهزة الظاهرية غير Azure Arc باستخدام Windows PowerShell. يمكنك تشغيل أوامر Azure CLI محليا من أحد خوادم Azure Stack HCI أو عن بعد من كمبيوتر إدارة. يسهل التكامل مع Azure Automation وAzure Arc مجموعة واسعة من سيناريوهات الأتمتة الإضافية لأحمال عمل الجهاز الظاهري من خلال ملحقات Azure Arc.

    لمزيد من المعلومات، راجع توصيات استخدام IaC.

  • قدرات التنفيذ التلقائي للحاويات على AKS: يوفر Azure Stack HCI مجموعة واسعة من قدرات التشغيل التلقائي لإدارة أحمال العمل، مثل الحاويات، على AKS. يمكنك أتمتة نشر مجموعات AKS باستخدام Azure CLI. تحديث مجموعات حمل عمل AKS باستخدام ملحق Azure Arc لتحديثات Kubernetes. يمكنك أيضا إدارة AKS التي تدعم Azure Arc باستخدام Azure CLI. يمكنك تشغيل أوامر Azure CLI محليا من أحد خوادم Azure Stack HCI أو عن بعد من كمبيوتر إدارة. التكامل مع Azure Arc لمجموعة واسعة من سيناريوهات التشغيل التلقائي الإضافية لأحمال العمل المعبأة في حاويات من خلال ملحقات Azure Arc.

    لمزيد من المعلومات، راجع توصيات لتمكين الأتمتة.

كفاءة الأداء

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

وتشمل اعتبارات كفاءة الأداء ما يلي:

  • أداء تخزين حمل العمل: ضع في اعتبارك استخدام أداة DiskSpd لاختبار قدرات أداء تخزين حمل العمل لمجموعة Azure Stack HCI. يمكنك استخدام أداة VMFleet لإنشاء تحميل وقياس أداء نظام فرعي للتخزين. تقييم ما إذا كان يجب عليك استخدام VMFleet لقياس أداء النظام الفرعي للتخزين.

    • نوصي بإنشاء أساس لأداء مجموعات Azure Stack HCI قبل نشر أحمال عمل الإنتاج. يستخدم DiskSpd معلمات سطر الأوامر المختلفة التي تمكن المسؤولين من اختبار أداء التخزين للمجموعة. تتمثل الوظيفة الرئيسية ل DiskSpd في إصدار عمليات القراءة والكتابة ومقاييس أداء الإخراج، مثل زمن الانتقال ومعدل النقل وIOPs.

      لمزيد من المعلومات، راجع توصيات اختبار الأداء.

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

    لمزيد من المعلومات، راجع توصيات تخطيط السعة.

  • تحسين أداء الشبكة: ضع في اعتبارك تحسين أداء الشبكة. كجزء من تصميمك، تأكد من تضمين تخصيص النطاق الترددي المتوقع لنسبة استخدام الشبكة عند تحديد التكوين الأمثل لأجهزة الشبكة.

    • لتحسين أداء الحساب في Azure Stack HCI، يمكنك استخدام تسريع GPU. يعد تسريع وحدة معالجة الرسومات مفيدا لأحمال عمل الذكاء الاصطناعي أو التعلم الآلي عالية الأداء التي تتضمن رؤى البيانات أو الاستدلال. تتطلب أحمال العمل هذه النشر في مواقع الحافة نظرا لاعتبارات مثل خطورة البيانات أو متطلبات الأمان. في التوزيع المختلط أو التوزيع المحلي، من المهم مراعاة متطلبات أداء حمل العمل، بما في ذلك وحدات معالجة الرسومات. يساعدك هذا الأسلوب على تحديد الخدمات المناسبة عند تصميم مجموعات Azure Stack HCI الخاصة بك وشراؤها.

      لمزيد من المعلومات، راجع توصيات لتحديد الخدمات المناسبة.

نشر هذا السيناريو

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

السيناريو: هناك مشروع أو شرط حالة استخدام لنشر حل سحابي مختلط في موقع محلي أو حافة لتوفير حساب محلي لقدرات معالجة البيانات والرغبة في استخدام تجارب إدارة وفوترة متسقة مع Azure. يتم وصف المزيد من التفاصيل في قسم حالات الاستخدام المحتملة من هذه المقالة. تفترض الخطوات المتبقية أن Azure Stack HCI هو حل النظام الأساسي للبنية الأساسية المختار للمشروع.

  1. جمع متطلبات حمل العمل وحالة الاستخدام من أصحاب المصلحة المعنيين. تمكن هذه الاستراتيجية المشروع من التأكد من أن ميزات وقدرات Azure Stack HCI تفي بمتطلبات مقياس حمل العمل والأداء والوظائف. يجب أن تتضمن عملية المراجعة هذه فهم حجم حمل العمل أو حجمه والميزات المطلوبة مثل Azure Arc VMs أو AKS أو Azure Virtual Desktop أو خدمات البيانات التي تدعم Azure Arc أو خدمة التعلم الآلي الممكنة من Azure Arc. يجب توثيق قيم RTO وRPO (الموثوقية) لحمل العمل والمتطلبات الأخرى غير الوظيفية (قابلية توسع الأداء/التحميل) كجزء من خطوة جمع المتطلبات هذه.

  2. راجع إخراج Azure Stack HCI sizer لحل شريك الأجهزة الموصى به. يتضمن هذا الإخراج تفاصيل تصميم ونموذج أجهزة الخادم الفعلية الموصى بها وعدد العقد الفعلية ومواصفات وحدة المعالجة المركزية والذاكرة وتكوين التخزين لكل عقدة فعلية مطلوبة لنشر وتشغيل أحمال العمل الخاصة بك.

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

  4. راجع إخراج Azure Stack HCI Sizer لحل شريك الأجهزة الموصى به. يتضمن هذا الحل تفاصيل أجهزة الخادم الفعلية الموصى بها (make and model) وعدد العقد الفعلية ومواصفات وحدة المعالجة المركزية والذاكرة وتكوين التخزين لكل عقدة فعلية مطلوبة لنشر وتشغيل أحمال العمل الخاصة بك.

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

  6. نشر مفتاحي تبديل ToR لتكامل الشبكة. بالنسبة لحلول قابلية الوصول العالية، تتطلب مجموعات HCI توزيع مفتاحي تبديل ToR. تتطلب كل عقدة فعلية أربعة NICs، اثنان منها يجب أن تكون قادرة على RDMA، والتي توفر ارتباطين من كل عقدة إلى مفتاحي تبديل ToR. يتم تقارب اثنين من NICs، أحدهما متصل بكل مفتاح تبديل، للاتصال الصادر بين الشمال والجنوب لشبكات الحوسبة والإدارة. يتم تخصيص بطاقات NIC الأخرى القادرة على RDMA لتخزين حركة المرور بين الشرق والغرب. إذا كنت تخطط لاستخدام مفاتيح تبديل الشبكة الموجودة، فتأكد من أن طراز ومفاتيح التبديل موجودة في القائمة المعتمدة لتبديلات الشبكة التي يدعمها Azure Stack HCI.

  7. العمل مع الشركة المصنعة للمعدات الأصلية (OEM) أو شريك SI لترتيب تسليم الأجهزة. ثم يطلب من شريك SI أو موظفيك دمج الأجهزة في مركز البيانات المحلي أو موقع الحافة، مثل رف وتكديس الأجهزة والشبكة الفعلية وكابلات وحدة تزويد الطاقة للعقد الفعلية.

  8. تنفيذ توزيع نظام مجموعة Azure Stack HCI. اعتمادا على إصدار الحل الذي اخترته (الحل الرئيسي أو النظام المتكامل أو العقد التي تم التحقق من صحتها)، يمكن لشريك الأجهزة أو شريك SI أو موظفيك نشر برنامج Azure Stack HCI. تبدأ هذه الخطوة بإلحاق العقد الفعلية Azure Stack HCI OS في خوادم Azure Arc الممكنة، ثم بدء عملية نشر سحابة Azure Stack HCI. يمكن للعملاء والشركاء رفع طلب دعم مباشرة مع Microsoft في مدخل Microsoft Azure عن طريق تحديد أيقونة الدعم + استكشاف الأخطاء وإصلاحها أو عن طريق الاتصال بالشركة المصنعة للمعدات الأصلية (OEM) أو شريك SI للأجهزة، اعتمادا على طبيعة الطلب وفئة حل الأجهزة.

    تلميح

    شعار GitHubيوضح التنفيذ المرجعي لنظام مجموعة Azure Stack HCI 23H2 كيفية توزيع خوادم متعددة تبديل ل Azure Stack HCI باستخدام قالب ARM وملف المعلمة. بدلا من ذلك، يوضح مثال Bicep كيفية استخدام قالب Bicep لنشر نظام مجموعة Azure Stack HCI، بما في ذلك موارد المتطلبات الأساسية الخاصة به.

  9. نشر أحمال العمل عالية التوفر على Azure Stack HCI باستخدام مدخل Azure أو CLI أو قوالب ARM + Azure Arc للأتمتة. استخدم مورد الموقع المخصص لمجموعة HCI الجديدة كمنطقة مستهدفة عند نشر موارد حمل العمل مثل أجهزة Azure Arc الظاهرية أو AKS أو مضيفي جلسة Azure Virtual Desktop أو الخدمات الأخرى الممكنة ل Azure Arc التي يمكنك تمكينها من خلال ملحقات AKS والتعبئة في حاويات على Azure Stack HCI.

  10. قم بتثبيت التحديثات الشهرية لتحسين أمان النظام الأساسي وموثوقيته. للحفاظ على مجموعات Azure Stack HCI محدثة، من المهم تثبيت تحديثات برامج Microsoft وتحديثات برامج تشغيل الشركة المصنعة للمعدات الأصلية (OEM) وتحديثات البرامج الثابتة. تعمل هذه التحديثات على تحسين أمان النظام الأساسي وموثوقيته. يطبق Update Manager التحديثات ويوفر حلا مركزيا وقابلا للتطوير لتثبيت التحديثات عبر مجموعة واحدة أو مجموعات متعددة. تحقق من شريك الشركة المصنعة للمعدات الأصلية (OEM) الخاص بالأجهزة لتحديد عملية تثبيت تحديثات برامج تشغيل الأجهزة والبرامج الثابتة لأن هذه العملية يمكن أن تختلف اعتمادا على نوع فئة حل الأجهزة الذي اخترته (الحل الرئيسي أو النظام المتكامل أو العقد التي تم التحقق من صحتها). لمزيد من المعلومات، راجع تحديثات البنية الأساسية.

الخطوات التالية

وثائق المنتج:

وثائق المنتج للحصول على تفاصيل حول خدمات Azure المحددة:

وحدات Microsoft Learn: