ينطبق هذا السيناريو المثال على أي صناعة تحتاج إلى توزيع تطبيقات مرنة متعددة الأطياف مصممة لقابلية الوصول العالية والإصلاح بعد الكوارث. في هذا السيناريو، يتكون التطبيق من ثلاث طبقات.
- طبقة الويب: الطبقة العليا، بما في ذلك واجهة المستخدم. تقوم هذه الطبقة بتحليل تفاعلات المستخدم وتمرير الإجراءات إلى الطبقة التالية للمعالجة.
- مستوى الأعمال: يعالج تفاعلات المستخدم ويتخذ قرارات منطقية حول الخطوات التالية. تربط هذه الطبقة طبقة الويب وطبقة البيانات.
- طبقة البيانات: تخزن بيانات التطبيق. عادة ما يتم استخدام قاعدة بيانات أو تخزين كائن أو تخزين ملف.
تتضمن سيناريوهات التطبيق الشائعة أي تطبيق مهم يعمل على Windows أو Linux. يمكن أن يكون هذا تطبيقا غير جاهز مثل SAP و SharePoint أو تطبيق خط عمل مخصص.
حالات الاستخدام المحتملة
وتشمل حالات الاستخدام الأخرى ذات الصلة ما يلي:
- توزيع تطبيقات مرنة للغاية مثل SAP و SharePoint
- تصميم خطة لاستمرارية الأعمال والإصلاح بعد الكوارث لتطبيقات خط الأعمال
- تكوين الإصلاح بعد الكوارث وإجراء التدريبات ذات الصلة لأغراض التوافق
البنية
قم بتنزيل ملف Visio لهذه البنية.
سير العمل
- توزيع الأجهزة الظاهرية في كل مستوى عبر منطقتين للتوفر في المناطق التي تدعم المناطق. في مناطق أخرى، وزع الأجهزة الظاهرية في كل مستوى ضمن مجموعة توفر واحدة.
- يمكن تكوين طبقة قاعدة البيانات لاستخدام مجموعات قابلية وصول عالية التوفر AlwaysOn. باستخدام تكوين SQL Server هذا، يتم تكوين نسخة متماثلة أساسية للقراءة/الكتابة داخل مجموعة توفر مع ما يصل إلى ثماني نسخ متماثلة ثانوية للقراءة فقط. إذا حدثت مشكلة في النسخة المتماثلة الأساسية، تفشل مجموعة التوفر عبر نشاط القراءة/الكتابة الأساسي إلى إحدى النسخ المتماثلة الثانوية، ما يسمح للتطبيق بالبقاء متوفرا. لمزيد من المعلومات، راجع نظرة عامة على مجموعات قابلية وصول عالية التوفر Always On SQL Server.
- بالنسبة لسيناريوهات الإصلاح بعد الكوارث، يمكنك تكوين SQL النسخ المتماثل الأصلي غير المتزامن Always On إلى المنطقة المستهدفة المستخدمة للإصلاح بعد الكوارث. يمكنك أيضا تكوين النسخ المتماثل لـ Azure Site Recovery إلى المنطقة المستهدفة إذا كان معدل تغيير البيانات ضمن الحدود المدعومة من Azure Site Recovery.
- يصل المستخدمون إلى طبقة الويب ASP.NET الأمامية عبر نقطة نهاية مدير حركة المرور.
- يعيد مدير نسبة استخدام الشبكة توجيه نسبة استخدام الشبكة إلى نقطة نهاية IP العامة الأساسية في منطقة المصدر الأساسي.
- يعيد IP العام توجيه الاستدعاء إلى أحد مثيلات الجهاز الظاهري لمستوى الويب من خلال موازن تحميل عام. جميع مثيلات الأجهزة الظاهرية على مستوى الويب موجودة في شبكة فرعية واحدة.
- من الجهاز الظاهري لطبقة الويب، يتم توجيه كل استدعاء إلى أحد مثيلات الجهاز الظاهري في طبقة الأعمال من خلال موازن تحميل داخلي للمعالجة. جميع الأجهزة الظاهرية لمستوى الأعمال موجودة في شبكة فرعية منفصلة.
- تتم معالجة العملية في طبقة الأعمال ويتصل تطبيق ASP.NET بمجموعة Microsoft SQL Server في طبقة خلفية عبر موازن تحميل داخلي Azure. توجد هذه المثيلات SQL Server الخلفية في شبكة فرعية منفصلة.
- يتم تكوين نقطة النهاية الثانوية لمدير نسبة استخدام الشبكة ك IP عام في المنطقة المستهدفة المستخدمة للإصلاح بعد الكوارث.
- في حالة تعطيل المنطقة الأساسية، يمكنك استدعاء تجاوز فشل Azure Site Recovery ويصبح التطبيق نشطا في المنطقة المستهدفة.
- تعيد نقطة نهاية إدارة نسبة استخدام الشبكة توجيه نسبة استخدام الشبكة للعميل تلقائيا إلى عنوان IP العام في المنطقة المستهدفة.
المكونات
- Availability sets التأكد من أن VMs التي تُنشر على Azure موزعة عبر عدة عقد أجهزة معزولة في مجموعة. في حالة حدوث عطل في الأجهزة أو البرامج داخل Azure، ستتأثر مجموعة فرعية فقط من الأجهزة الظاهرية، وسيظل الحل بأكمله متاحاً وعاملاً.
- تعمل مناطق التوفر على حماية تطبيقاتك وبياناتك من أعطال مركز البيانات. مناطق التوفر هي مواقع فعلية فريدة داخل منطقة Azure. تحتوي كل منطقة على مركز بيانات واحد أو أكثر من مركز مزوداً بطاقة مستقلة وتبريد وشبكات.
- يسمح لك Azure Site Recovery بنسخ الأجهزة الظاهرية إلى منطقة Azure أخرى لتلبية احتياجات استمرارية الأعمال والإصلاح بعد الكوارث. يمكنك إجراء تدريبات دورية للإصلاح بعد الكوارث لضمان تلبية احتياجات التوافق. سيتم نسخ الجهاز الظاهري مع الإعدادات المحددة إلى المنطقة المحددة بحيث يمكنك استرداد التطبيقات الخاصة بك في حالة انقطاع التيار الكهربائي في منطقة المصدر.
- يعد Azure Traffic Manager عبارة عن موازن تحميل نسبة استخدام الشبكة ويستند إلى DNS والذي يمكنك من توزيع نسبة استخدام الشبكة على النحو الأمثل على الخدمات عبر مناطق Azure العامة مع توفير استجابة وقابلية وصول عالية التوفر.
- يوزع موازن تحميل Azure نسبة استخدام الشبكة الواردة، وفقاً لقواعد محددة وفحوصات السلامة. يوفر موازن التحميل زمن انتقال منخفض ومعدل نقل مرتفع ويصل إلى ملايين التدفقات لجميع تطبيقات TCP وUDP. يتم استخدام موازن تحميل عام في هذا السيناريو، لتوزيع نسبة استخدام الشبكة للعميل الواردة إلى طبقة الويب. يتم استخدام موازن تحميل داخلي في هذا السيناريو، لتوزيع نسبة استخدام الشبكة من طبقة الأعمال إلى نظام مجموعة SQL Server للخلفية.
البدائل
- يمكن استبدال Windows بأنظمة تشغيل أخرى لأن لا شيء في البنية الأساسية يعتمد على نظام التشغيل.
- يمكن أن يحل SQL Server لنظام Linux محل مخزن البيانات الخلفي.
- يمكن استبدال قاعدة البيانات بأي تطبيق قاعدة بيانات قياسي متوفر.
تفاصيل السيناريو
يوضح هذا السيناريو تطبيقا متعدد المستويات يستخدم ASP.NET Microsoft SQL Server. في مناطق Azure التي تدعم مناطق التوفر، يمكنك توزيع أجهزتك الظاهرية (VMs) في منطقة مصدر عبر مناطق التوفر ونسخ الأجهزة الظاهرية نسخا متماثلا إلى المنطقة المستهدفة المستخدمة للإصلاح بعد الكوارث. في مناطق Azure التي لا تدعم مناطق التوفر، يمكنك نشر الأجهزة الظاهرية ضمن مجموعة توفر ونسخ الأجهزة الظاهرية نسخا متماثلا إلى المنطقة المستهدفة.
لتوجيه نسبة استخدام الشبكة بين المناطق، تحتاج إلى موازن تحميل عمومي. هناك عرضان رئيسيان لـ Azure:
- الواجهة الأمامية لـ Azure
- مدير حركة بيانات Azure
عند اختيار موازن تحميل، ضع في اعتبارك متطلباتك ومجموعة الميزات الخاصة بالعرضين. ما مدى سرعة تجاوز الفشل؟ هل يمكنك تحمل النفقات العامة لإدارة TLS؟ هل هناك أي قيود على التكلفة التنظيمية؟
يوفر Front Door إمكانات الطبقة السابعة لتطبيقك مثل تفريغ SSL، والتوجيه القائم على المسار، وتجاوز الفشل السريع، والتخزين المؤقت وما إلى ذلك لتحسين الأداء وقابلية الوصول العالية لتطبيقاتك. قد تواجه أوقات سفر أسرع للحزمة لأن البنية الأساسية يتم إلحاقها على شبكة Azure في وقت أقرب.
نظرا لأن Front Door يضيف قفزة جديدة، فهناك عمليات أمان إضافية. إذا كانت البنية متوافقة مع المتطلبات التنظيمية، فقد تكون هناك قيود حول نقطة إنهاء TLS الإضافية لنسبة استخدام الشبكة. يجب أن تلبي مجموعات تشفير TLS المحددة بواسطة Front Door شريط الأمان الخاص بمؤسستك. كما يتوقع Front Door أن تستخدم خدمات الواجهة الخلفية الشهادات التي تستخدمها Microsoft.
وهناك اعتبار آخر هو التكلفة. يجب أن تستفيد البنية من مجموعة الميزات الشاملة (وليس تجاوز الفشل فقط) لتبرير التكلفة المضافة.
Azure Traffic Manager هي خدمة عمومية لموازنة التحميل، تعتمد على DNS. يوازن ويفشل فقط على مستوى DNS. لهذا السبب، لا يحدث تجاوز الفشل بنفس سرعة الـ Front Door، بسبب التحديات الشائعة حول التخزين المؤقت لنظام أسماء المجالات والأنظمة التي لا تخدم DNS TTLs.
يمكنك الجمع بين موازنات التحميل، إذا لزم الأمر. على سبيل المثال، تريد تجاوز الفشل المستند إلى DNS ولكنك تريد إضافة تجربة POP أمام البنية الأساسية المدارة بنسبة استخدام الشبكة.
تستخدم هذه البنية Traffic Manager لأنها خفيفة الوزن. توقيت تجاوز الفشل كاف لأغراض توضيحية.
الاعتبارات
قابلية التوسع
يمكنك إضافة أجهزة ظاهرية أو إزالتها في كل مستوى استنادا إلى متطلبات التحجيم الخاصة بك. نظرا لأن هذا السيناريو يستخدم موازنات التحميل، يمكنك إضافة المزيد من الأجهزة الظاهرية إلى مستوى دون التأثير على وقت تشغيل التطبيق.
للحصول على مواضيع قابلية التوسع الأخرى، راجع قائمة التحقق من كفاءة الأداء في مركز هندسة Azure.
الأمان
جميع حركة مرور الشبكة الظاهرية في طبقة التطبيق الأمامي محمية بواسطة مجموعات أمان الشبكة. تحد القواعد من تدفق نسبة استخدام الشبكة بحيث يمكن فقط لمثيلات الجهاز الظاهري لمستوى التطبيق الأمامي الوصول إلى طبقة قاعدة البيانات الخلفية. لا يسمح بنسبة استخدام الشبكة الصادرة عبر الإنترنت من مستوى العمل أو طبقة قاعدة البيانات. لتقليل بصمة الهجوم، لا توجد منافذ إدارة مباشرة عن بعد مفتوحة. للحصول على مزيد من المعلومات، راجع أمان مجموعات شبكة Azure.
للحصول على إرشادات عامة حول تصميم سيناريوهات آمنة، راجع وثائق أمان Azure.
التسعير
سيؤدي تكوين الإصلاح بعد الكوارث لأجهزة Azure الظاهرية باستخدام Azure Site Recovery إلى تحمل الرسوم التالية على أساس مستمر.
- تكلفة ترخيص Azure Site Recovery لكل جهاز ظاهري.
- تكاليف خروج الشبكة لنسخ تغييرات البيانات من أقراص الجهاز الظاهري المصدر إلى منطقة Azure أخرى. يستخدم Azure Site Recovery الضغط المضمن لتقليل متطلبات نقل البيانات بنسبة 50٪ تقريبا.
- تكاليف التخزين على موقع الاسترداد. عادة ما يكون هذا هو نفس تخزين منطقة المصدر بالإضافة إلى أي تخزين إضافي مطلوب للحفاظ على نقاط الاسترداد كلقطات للاسترداد.
لقد قدمنا حاسبة تكلفة نموذجية لتكوين التعافي من الكوارث لتطبيق من ثلاثة مستويات باستخدام ستة أجهزة ظاهرية. تم تكوين جميع الخدمات مسبقا في حاسبة التكلفة. لمعرفة كيف سيتغير التسعير لحالة الاستخدام الخاصة بك، قم بتغيير المتغيرات المناسبة لتقدير التكلفة.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- سوجاي تالاسيلا | العميل المتوقع للمنتج الأساسي
الخطوات التالية
الموارد ذات الصلة
للحصول على بنى مرجعية إضافية عالية التوفر والإصلاح بعد الكوارث، راجع:
- تطبيق متعدد المناطق من الطبقة N
- موازنة التحميل متعددة المناطق
- [تطبيق متعدد المناطق مع قاعدة بيانات خاصة] [متعدد المناطق التطبيق مع قاعدة بيانات خاصة]
- الإصلاح بعد الكوارث على مستوى المؤسسة