مشاركة عبر


الموثوقية في Azure Bastion

Azure Bastion هو نظام أساسي مدار بالكامل كخدمة (PaaS) تقوم بتوفيره لتوفير اتصالات عالية الأمان للأجهزة الظاهرية عبر عنوان IP خاص. يوفر اتصال RDP/SSH سلسا بالأجهزة الظاهرية مباشرة عبر TLS من مدخل Microsoft Azure، أو عبر عميل SSH أو RDP الأصلي المثبت بالفعل على الكمبيوتر المحلي. عند الاتصال عبر Azure Bastion، لا تحتاج أجهزتك الظاهرية إلى عنوان IP عام أو وكيل أو برنامج عميل خاص.

عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.

توضح هذه المقالة كيفية جعل Azure Bastion مرنا لمجموعة متنوعة من الانقطاعات والمشاكل المحتملة، بما في ذلك الأخطاء العابرة وانقطاع منطقة التوفر وانقطاع التيار الكهربائي في المنطقة. يسلط الضوء على بعض المعلومات الأساسية حول اتفاقية مستوى خدمة Azure Bastion (SLA).

هام

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

توصيات نشر الإنتاج للموثوقية

بالنسبة لأحمال عمل الإنتاج، نوصي بما يلي:

نظرة عامة على بنية الموثوقية

عند استخدام Azure Bastion، يجب عليك نشر مضيف معقل إلى شبكة فرعية تلبي متطلبات Azure Bastion.

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

يدعم SKU الأساسي مثيلين بالضبط. تدعم وحدات SKU القياسية والمتميزة تحجيم المضيف، حيث يمكنك تكوين عدد المثيلات، بمثيلين على الأقل. عند إضافة المزيد من المثيلات، يمكن لمضيف المقطع السفلي استيعاب اتصالات عميل متزامنة إضافية.

المرونة في مواجهة الأعطال العابرة

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

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

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

المرونة في مواجهة حالات فشل منطقة التوفر

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

يدعم Azure Bastion مناطق التوفر في كل من تكوينات المنطقة الزائدة عن الحاجة والمناطق:

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

    يوضح الرسم التخطيطي التالي مضيف معقل متكرر في المنطقة، مع انتشار مثيلاته عبر ثلاث مناطق:

    رسم تخطيطي يوضح Azure Bastion مع ثلاثة مثيلات موزعة عبر ثلاث مناطق توفر لتوضيح التوزيع المتكرر في المنطقة.

    إذا حددت مناطق توفر أكثر مما لديك من مثيلات، فإن Azure Bastion ينشر المثيلات عبر أكبر عدد ممكن من المناطق.

  • المنطقة: يوجد مضيف معقل المنطقة وجميع مثيلاته في منطقة توفر واحدة تحددها.

    هام

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

المتطلبات

  • دعم المنطقة: يمكن نشر مضيفي المعقل المتكرر في المناطق والمنطقة في المناطق التالية:

    الأمريكتان ‏‏أوروبا الشرق الأوسط أفريقيا آسيا/المحيط الهادئ
    وسط كندا أوروبا الشمالية قطر الوسطى جنوب أفريقيا شرق أستراليا
    وسط الولايات المتحدة منطقة السويد الوسطى إسرائيل الوسطى وسط كوريا
    شرق الولايات المتحدة جنوب المملكة المتحدة
    شرق الولايات المتحدة 2 أوروبا الغربية
    غرب الولايات المتحدة 2 شرق النرويج
    شرق الولايات المتحدة 2 EUAP منطقة شمال إيطاليا
    وسط المكسيك وسط إسبانيا
  • سكو: لتكوين مضيفي المقطع السفلي لتكون زائدة عن الحاجة في المنطقة أو المنطقة، يجب عليك النشر باستخدام وحدات SKU الأساسية أو القياسية أو المتميزة.

  • عنوان IP العام: يتطلب Azure Bastion عنوان IP عام احتياطي لمنطقة SKU قياسي.

التكلفة

لا توجد تكلفة إضافية لاستخدام دعم منطقة التوفر ل Azure Bastion. تستند الرسوم إلى رمز التخزين التعريفي لمضيف المعقل وعدد المثيلات التي يستخدمها. للحصول على معلومات، راجع تسعير Azure Bastion.

تكوين دعم منطقة التوفر

  • انشر مضيف معقل معقل جديد مع دعم منطقة التوفر: عند نشر مضيف مقطع سقي جديد في منطقة تدعم مناطق التوفر، فإنك تحدد المناطق المحددة التي تريد النشر فيها.

    لتكرار المنطقة، يجب تحديد مناطق متعددة.

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

  • مضيفو المعقل الحاليون: لا يمكن تغيير تكوين منطقة التوفر لمضيف معقل موجود بدلا من ذلك ، تحتاج إلى إنشاء مضيف معقل بالتكوين الجديد وحذف التكوين القديم.

السلوك عندما تكون جميع المناطق صحية

يصف هذا القسم ما يمكن توقعه عند تكوين مضيفي المقطع السفلي لدعم منطقة التوفر وتشغيل جميع مناطق التوفر.

  • توجيه نسبة استخدام الشبكة بين المناطق: عند بدء جلسة SSH أو RDP، يمكن توجيهها إلى مثيل Azure Bastion في أي من مناطق التوفر التي حددتها.

    إذا قمت بتكوين تكرار المنطقة على مضيف المقطع المتحرك، فقد يتم إرسال جلسة عمل إلى مثيل مقطع في منطقة توفر مختلفة عن الجهاز الظاهري الذي تتصل به. في الرسم التخطيطي التالي، يتم إرسال طلب من المستخدم إلى مثيل Azure Bastion في المنطقة 2، على الرغم من أن الجهاز الظاهري في المنطقة 1:

    رسم تخطيطي يوضح Azure Bastion بثلاثة مثيلات. ينتقل طلب المستخدم إلى مثيل Azure Bastion في المنطقة 2 ويتم إرساله إلى جهاز ظاهري في المنطقة 1.

    تلميح

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

  • النسخ المتماثل للبيانات بين المناطق: نظرا لأن Azure Bastion لا يخزن الحالة، فلا توجد بيانات للنسخ المتماثل بين المناطق.

السلوك أثناء فشل المنطقة

يصف هذا القسم ما يمكن توقعه عند تكوين مضيفي المقطع السفلي لدعم منطقة التوفر وهناك انقطاع في منطقة التوفر.

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

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

  • الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام Azure Service Health لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
  • الطلبات النشطة: عندما تكون منطقة التوفر غير متوفرة، يتم إنهاء أي اتصالات RDP أو SSH قيد التقدم تستخدم مثيل Azure Bastion في منطقة التوفر المعيبة وتحتاج إلى إعادة المحاولة.

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

  • التوقف عن العمل المتوقع: يعتمد وقت التوقف المتوقع على تكوين منطقة التوفر التي يستخدمها مضيف المقطع السفلي.

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

    • المنطقة: المثيل الخاص بك غير متاح حتى يتم استرداد منطقة توافر الخدمات.

  • فقدان البيانات المتوقع: نظرا لأن Azure Bastion لا يخزن الحالة، فلا يتوقع فقدان البيانات أثناء فشل المنطقة.

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

استعادة المنطقة

عند استرداد منطقة التوفر، يقوم Azure Bastion تلقائيا باستعادة المثيلات في منطقة التوفر، وإعادة توجيه نسبة استخدام الشبكة بين مثيلاتك كالمعتاد.

اختبار فشل المنطقة

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

القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة

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

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

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

اتفاقية مستوى الخدمة

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