تحرير

مشاركة عبر

تطبيق متعدد المناطق من الطبقة N

Azure Monitor
Azure Traffic Manager
Azure SQL Database
Azure Virtual Machines

يعرض التصميم المرجعي مجموعة من الممارسات لتشغيل تطبيق N-tier في مناطق Azure المتعددة لتحقيق التوفر وبنية أساسية قوية للإصلاح بعد الكوارث.

البنية

Highly available network architecture for Azure N-tier applications

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

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

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

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

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

  • مجموعات قابلية وصول عالية التوفر AlwaysOn من SQL Server. إذا كنت تستخدم SQL Server، نوصي بمجموعات قابلية وصول عالية التوفر ل SQL AlwaysOn. قم بإنشاء مجموعة قابلية وصول عالية التوفر واحدة تتضمن مثيلات SQL Server في كلا المنطقتين.

    إشعار

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

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

المكونات

  • Availability sets التأكد من أن VMs التي تُنشر على Azure موزعة عبر عدة عقد أجهزة معزولة في مجموعة. إذا حدث فشل في الأجهزة أو البرامج داخل Azure، تتأثر مجموعة فرعية فقط من الأجهزة الظاهرية الخاصة بك، ويظل الحل بأكمله متوفرا وتشغيليا.
  • تعمل مناطق التوفر على حماية تطبيقاتك وبياناتك من أعطال مركز البيانات. مناطق التوفر هي مواقع فعلية فريدة داخل منطقة Azure. تحتوي كل منطقة على مركز بيانات واحد أو أكثر من مركز مزوداً بطاقة مستقلة وتبريد وشبكات.
  • Azure Traffic Manager هو موازن تحميل نسبة استخدام الشبكة المستند إلى DNS الذي يوزع نسبة استخدام الشبكة على النحو الأمثل. ويوفر الخدمات عبر مناطق Azure العالمية، مع توفر واستجابة عالية.
  • يوزع موازن تحميل Azure نسبة استخدام الشبكة الواردة، وفقاً لقواعد محددة وفحوصات السلامة. يوفر موازن التحميل زمن انتقال منخفض ومعدل نقل مرتفع ويصل إلى ملايين التدفقات لجميع تطبيقات TCP وUDP. يتم استخدام موازن تحميل عام في هذا السيناريو، لتوزيع نسبة استخدام الشبكة للعميل الواردة إلى طبقة الويب. يتم استخدام موازن تحميل داخلي في هذا السيناريو، لتوزيع نسبة استخدام الشبكة من طبقة الأعمال إلى نظام مجموعة SQL Server للخلفية.
  • يوفر Azure Bastion اتصال RDP وSSH آمنا بجميع الأجهزة الظاهرية، في الشبكة الظاهرية التي يتم توفيرها فيها. يحمي استخدام Azure Bastion الأجهزة الظاهرية الخاصة بك من تعريض منافذ RDP/SSH إلى العالم الخارجي، مع الاستمرار في توفير الوصول الآمن باستخدام RDP/SSH.

التوصيات

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

هناك العديد من النُهج العامة لتحقيق قابلية الوصول العالية عبر المناطق:

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

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

الاقتران الإقليمي

يتم إقران كل منطقة من مناطق Azure بمنطقة أخرى داخل نفس المنطقة الجغرافية. بشكل عام، اختر المناطق من نفس الزوج الإقليمي (على سبيل المثال، شرق الولايات المتحدة 2 ووسط الولايات المتحدة). وتشمل ميزات إجراء ذلك ما يلي:

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

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

تكوين مدير نسبة استخدام الشبكة

مراعاة النقاط التالية عند تكوين Traffic Manager:

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

عندما يفشل Traffic Manager، هناك فترة زمنية لا يمكن فيها للعملاء الوصول إلى التطبيق. المدة تتأثر بالعوامل التالية:

  • يجب أن يكتشف فحص السلامة أن المنطقة الأساسية أصبحت غير قابلة للوصول.
  • يجب أن تقوم خوادم DNS بتحديث سجلات DNS المخزنة مؤقتاً لعنوان IP، والتي تعتمد على مدة البقاء لـ DNS (TTL). مدة البقاء الافتراضية هي 300 ثانية (5 دقائق)، ولكن يمكنك تكوين هذه القيمة عند إنشاء ملف تعريف Traffic Manager.

للحصول على التفاصيل، راجع حول مراقبة Traffic Manager.

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

فشل Traffic Manager تلقائيا مرة أخرى بشكل افتراضي. لمنع هذه المشكلة، خفض أولوية المنطقة الأساسية يدويا بعد حدث تجاوز الفشل. على سبيل المثال، افترض أن المنطقة الأساسية هي الأولوية 1 والمنطقة الثانوية هي الأولوية 2. بعد تجاوز الفشل، قم بتعيين المنطقة الأساسية إلى الأولوية 3، لمنع إرجاع الموارد التلقائي. عندما تكون مستعدا للتبديل مرة أخرى، قم بتحديث الأولوية إلى 1.

يحدث أمر Azure CLI التالي الأولوية:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --priority 3

نهج آخر هو تعطيل نقطة النهاية مؤقتا حتى تصبح جاهزا للفشل مرة أخرى:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --endpoint-status Disabled

اعتماداً على سبب تجاوز الفشل، قد تحتاج إلى إعادة توزيع الموارد داخل منطقة. قبل إرجاع الموارد، قم بإجراء اختبار الاستعداد التشغيلي. يجب أن يتحقق الاختبار من أشياء مثل:

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

تكوين مجموعات قابلية وصول عالية التوفر AlwaysOn لـ SQL Server

قبل Windows Server 2016، تتطلب مجموعات قابلية وصول عالية التوفر AlwaysOn لـ SQL Server وحدة تحكم بالمجال، ويجب أن تكون جميع العقد في مجموعة قابلية وصول عالية التوفر في نفس مجال Active Directory (AD).

لتكوين مجموعة قابلية وصول عالية التوفر:

  • كحد أدنى، ضع وحدتي التحكم بالمجال في كل منطقة.

  • امنح كل وحدة تحكم بالمجال عنوان IP ثابتاً.

  • قم بتناظر الشبكتين الظاهريتين لتمكين الاتصال بينهما.

  • لكل شبكة ظاهرية، أضف عناوين IP لوحدات التحكم بالمجال (من كلتا المنطقتين) إلى قائمة خوادم DNS. يمكنك استخدام أمر CLI التالي. للحصول على مزيدٍ من المعلومات، راجع تغيير خوادم DNS.

    az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"

  • إنشاء نظام مجموعة تجاوز الفشل للمجموعات لـ Windows Server (WSFC) الذي يتضمن مثيلات SQL Server في كلتا المنطقتين.

  • يمكنك إنشاء مجموعات قابلية وصول عالية التوفر AlwaysOn لـ SQL Server التي تتضمن مثيلات SQL Server في كل من المناطق الأساسية والثانوية. راجع توسيع مجموعة قابلية وصول عالية التوفر AlwaysOn إلى مركز بيانات Azure البعيد (PowerShell) للاطلاع على الخطوات.

    • ضع النسخة المتماثلة الأساسية في المنطقة الأساسية.

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

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

      إشعار

      لا تدعم النسخ المتماثلة غير المتزامنة للالتزام تجاوز الفشل التلقائي.

الاعتبارات

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

التوافر

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

Traffic Manager هي نقطة فشل محتملة في النظام. إذا فشلت خدمة Traffic Manager، فلن يتمكن العملاء من الوصول إلى التطبيق الخاص بك أثناء وقت التعطل. راجع اتفاقية على مستوى الخدمة لـ Traffic Manager، وحدد ما إذا كان استخدام Traffic Manager وحده يلبي متطلبات عملك للتوفر العالي أم لا. إذا لم يكن الأمر كذلك، ففكر في إضافة حل آخر لإدارة نسبة استخدام الشبكة كإرجاع موارد. إذا فشلت خدمة Azure Traffic Manager، فقم بتغيير سجلات CNAME في DNS للإشارة إلى خدمة إدارة نسبة استخدام الشبكة الأخرى. (يجب تنفيذ هذه الخطوة يدوياً، ولن يكون تطبيقك متوفراً حتى يتم نشر تغييرات DNS.)

بالنسبة لنظام مجموعة SQL Server، هناك سيناريوهان لتجاوز الفشل يجب مراعاتهما:

  • تفشل جميع النسخ المتماثلة لقاعدة بيانات SQL Server في المنطقة الأساسية. على سبيل المثال، قد يحدث هذا الفشل أثناء انقطاع إقليمي. في هذه الحالة، يجب أن تفشل يدوياً عبر مجموعة قابلية وصول عالية التوفر، على الرغم من فشل Traffic Manager تلقائياً على الواجهة الأمامية. اتبع الخطوات الواردة في تنفيذ تجاوز الفشل اليدوي المفروض لمجموعة قابلية وصول عالية التوفر لـ SQL Server، والتي تصف كيفية تنفيذ تجاوز الفشل المفروض باستخدام SQL Server Management Studio أو Transact-SQL أو PowerShell في SQL Server 2016.

    تحذير

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

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

    1. قم بتبديل نسخة متماثلة لقاعدة بيانات SQL Server مؤقتاً في المنطقة الثانوية إلى التثبيت المتزامن. تضمن هذه الخطوة عدم فقدان البيانات أثناء تجاوز الفشل.
    2. تجاوز الفشل إلى تلك النسخة المتماثلة.
    3. عند إرجاع الموارد إلى المنطقة الأساسية، قم باستعادة إعداد التثبيت غير المتزامن.

قَابلية الإدارة

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

اختبر مرونة النظام في حالات الفشل. فيما يلي بعض السيناريوهات الشائعة المطلوب اختبارها:

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

قم بقياس أوقات الاسترداد وتحقق من أنها تفي بمتطلبات عملك. يمكنك اختبار مجموعات أوضاع الفشل، أيضاً.

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

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

استخدم حاسبة أسعار Azure لتقدير التكاليف. فيما يلي بعض الاعتبارات الأخرى.

مجموعات توسيع الجهاز الظاهري

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

للحصول على خيارات أسعار أجهزة ظاهرية واحدة، راجع أسعار الأجهزة الظاهرية لـ Windows.

خادم SQL

إذا اخترت Azure SQL DBaas، يمكنك توفير التكلفة لأنه لا تحتاج إلى تكوين مجموعة قابلية وصول عالية التوفر AlwaysOn وأجهزة وحدة التحكم بالمجال. هناك العديد من خيارات التوزيع بدءاً من قاعدة بيانات واحدة وصولاً إلى المثيل المدار أو المجموعات المرنة. لمزيد من المعلومات، راجع أسعار Azure SQL.

للحصول على خيارات أسعار الأجهزة الظاهرية للخادم SQL، راجع أسعار الأجهزة الظاهرية SQL.

موازنة التحمل

يتم تحصيل رسوم منك فقط مقابل عدد قواعد موازنة التحميل والصادرة المكونة. قواعد NAT الواردة مجانية. لا توجد رسوم بالساعة لموازن التحميل القياسي عند عدم تكوين أي قواعد.

أسعار Traffic Manager

تعتمد فوترة Traffic Manager على عدد استعلامات DNS المستلمة، مع خصم للخدمات التي تتلقى أكثر من مليار استعلام شهرياً. كما يتم تحصيل رسوم منك مقابل كل نقطة نهاية مراقبة.

لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.

أسعار تناظر الشبكة الظاهرية

سيستفيد التوزيع عالي التوفر الذي يستخدم مناطق Azure متعددة من تناظر VNET. هناك رسوم مختلفة على تناظر الشبكة الظاهرية داخل نفس المنطقة وتناظر الشبكة الظاهرة العامة.

للحصول على المزيد من المعلومات، راجع أسعار الشبكة الظاهرية.

DevOps

استخدم قالب Azure Resource Manager واحد لتوفير موارد Azure وتبعياتها. استخدم نفس القالب لتوزيع الموارد في كل من المناطق الأساسية والثانوية. قم بتضمين جميع الموارد في نفس الشبكة الظاهرية بحيث يتم عزلها في نفس حمل العمل الأساسي. من خلال تضمين جميع الموارد، يمكنك تسهيل إقران الموارد المحددة لحمل العمل بفريق DevOps، بحيث يمكن للفريق إدارة جميع جوانب هذه الموارد بشكل مستقل. يمكّن هذا العزل خدمات وفريق DevOps من إجراء تكامل مستمر وتسليم مستمر (CI/CD).

أيضاً، يمكنك استخدام قوالب Azure Resource Manager المختلفة وتكاملها مع خدمات Azure DevOps لتوفير بيئات مختلفة في دقائق، على سبيل المثال لنسخ الإنتاج بشكل متماثل مثل السيناريوهات أو بيئات اختبار التحميل فقط عند الحاجة، مما يوفر التكلفة.

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

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

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

لمزيد من المعلومات، راجع قسم التميز التشغيلي في Microsoft Azure Well-Architected Framework.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

يستخدم التصميم التالي بعض التقنيات نفسها: