استمرارية الأعمال والإصلاح بعد الكوارث لـ Azure Logic Apps
للمساعدة في تقليل التأثير والتأثيرات التي تحدثها الأحداث غير المتوقعة على عملك وعملائك، تأكد من وجود حل الإصلاح بعد كارثة (الإصلاح بعد كارثة) حتى يمكنك حماية البيانات، واستعادة الموارد التي تدعم وظائف الأعمال الهامة بسرعة، والحفاظ على تشغيل العمليات للحفاظ على استمرارية الأعمال (استمرارية الأعمال). على سبيل المثال، يمكن أن تشمل الاضطرابات الانقطاعات أو الخسائر في البنية التحتية أو المكونات مثل التخزين أو الشبكة أو موارد الحوسبة أو فشل التطبيقات غير القابلة للاسترداد أو حتى فقدان مركز البيانات الكامل. من خلال تجهيز حل استمرارية الأعمال والإصلاح بعد كارثة (BCDR)، يمكن لمؤسستك أو منظمتك الاستجابة بسرعة أكبر للمقاطعات، المخطط لها أو غير المخطط لها، وتقليل وقت التعطل لعملائك.
تقدم هذه المقالة إرشادات واستراتيجيات استمرارية الأعمال والإصلاح بعد كارثة التي يمكنك تطبيقها عند إنشاء مهام سير عمل تلقائية باستخدام Azure Logic Apps. تساعدك مهام سير عمل Logic app على دمج البيانات وتنسيقها بسهولة أكبر بين التطبيقات والخدمات السحابية والأنظمة المحلية عبر تقليل مقدار التعليمات البرمجية التي يجب عليك كتابتها. عند التخطيط لاستمرارية الأعمال والإصلاح بعد كارثة، تأكد من أنك لا تفكر في تطبيقات المنطق الخاصة بك فحسب، لكن أيضًا موارد Azure هذه التي تستخدمها مع تطبيقات المنطق الخاصة بك:
الاتصالات التي تقوم بإنشائها من مهام سير عمل تطبيق المنطق إلى التطبيقات والخدمات والأنظمة الأخرى. لمزيد من المعلومات، راجع الاتصالات بالموارد في وقت لاحق في هذا الموضوع.
بوابات البيانات المحلية التي هي موارد Azure التي تقوم بإنشائها واستخدامها في تطبيقات المنطق خاصتك للوصول إلى البيانات في الأنظمة المحلية. يمثل كل مورد بوابة تثبيت بوابة بيانات منفصلة على جهاز محلي. للمزيد من المعلومات، راجع بوابات البيانات المحلية في وقت لاحق في هذا الموضوع.
حسابات التكامل، إذ تقوم بتعريف وتخزين البيانات الاصطناعية التي تستخدمها تطبيقات المنطق لسيناريوهات تكامل المؤسسة بين الشركات (B2B) . على سبيل المثال، بإمكانك إعداد الإصلاح بعد كارثة عبر المناطق لحسابات التكامل.
بيئات خدمة التكامل ، إذ تقوم بإنشاء تطبيقات منطقية تعمل في مثيل وقت تشغيل Logic Apps معزول داخل شبكة Azure الظاهرية. بعد ذلك يمكن لتطبيقات المنطق هذه الوصول إلى الموارد المحمية خلف جدار حماية في تلك الشبكة الظاهرية.
المواقع الرئيسة والمواقع الثانوية
يحتاج كل تطبيق منطقي إلى تحديد الموقع الذي ترغب في استخدامه للنشر. يكون هذا الموقع إما منطقة عامة في Azure العالمية متعددة المستأجرين، مثل «غرب الولايات المتحدة»، أو بيئة خدمة تكامل (ISE) التي قمت بإنشائها ونشرها مسبقًا في شبكة Azure الظاهرية. يشبه تشغيل تطبيقات المنطق في بيئة خدمة تكامل تشغيل تطبيقات المنطق في منطقة Azure عالمية، مما يعني أن استراتيجية الإصلاح بعد كارثة الخاصة بك يمكن أن تنطبق على كلا السيناريوهين. مع ذلك، لدى بيئات خدمة التكامل اعتبارات أخرى مثل تكوين الوصول إلى الموارد المتوفرة لبيئات خدمة التكامل فحسب.
ملاحظة
في حال كان تطبيق المنطق الخاص بك يعمل أيضًا مع بيانات تكامل التجارة الإلكترونية بين الشركات الاصطناعية، مثل الشركاء التجاريين والاتفاقيات والمخططات والخرائط والشهادات، والتي يتم تخزينها في حساب تكامل، فيجب أن يحدد كل من حساب التكامل والتطبيقات المنطقية نفس الموقع.
تركز استراتيجية الإصلاح بعد كارثة هذه على إعداد تطبيق المنطق الأساس لتجاوز الفشل في تطبيق منطق الاستعداد أو النسخ الاحتياطي في موقع بديل حيث تتوفر Azure Logic Apps أيضا. بهذه الطريقة، في حال عانى الرئيس من خسائر أو اضطرابات أو فشل، يمكن أن يقوم الثانوي بالعمل. تتطلب هذه الاستراتيجية نشر تطبيق المنطق الثانوي والموارد التابعة بالفعل وأن تكون جاهزة في الموقع البديل.
إذا اتبعت ممارسات DevOps الجيدة، فأنت تستخدم بالفعل قوالب Azure Resource Manager لتحديد تطبيقات المنطق ومواردها التابعة ونشرها. تمنحك Resource Manager القوالب القدرة على استخدام تعريف نشر واحد ثم استخدام ملفات المعلمات لتوفير قيم التكوين لاستخدامها لكل وجهة نشر. تعني هذه الإمكانية أنه بإمكانك نشر نفس تطبيق المنطق في بيئات مختلفة، على سبيل المثال، التطوير والاختبار والإنتاج. بإمكانك أيضا نشر نفس تطبيق المنطق إلى مناطق Azure أو بيئات خدمة التكامل مختلفة، والتي تدعم استراتيجيات الإصلاح بعد كارثة التي تستخدم المناطق المقترنة.
بالنسبة لاستراتيجية تجاوز الفشل، لابد أن تفي تطبيقاتك ومواقعك المنطقية بهذه المتطلبات:
يحظى مثيل تطبيق المنطق الثانوي بالوصول إلى نفس التطبيقات والخدمات والأنظمة مثل مثيل تطبيق المنطق الأساس.
تمتلك كل مثيلات تطبيق المنطق نفس نوع المضيف. بناء على ذلك، إما أن يتم نشر كلا المثيلين إلى مناطق في Azure متعددة المستأجرين العمومية، أو يتم نشر كلا المثيلين إلى بيئات خدمة التكامل، ما يتيح لتطبيقاتك المنطقية الوصول مباشرة إلى الموارد في شبكة Azure الظاهرية. للحصول على أفضل الممارسات والمزيد من المعلومات حول المناطق المقترنة لاستمرارية الأعمال والإصلاح بعد كارثة، راجع النسخ المتماثل عبر المناطق في Azure: استمرارية الأعمال والإصلاح بعد كارثة.
على سبيل المثال، يجب أن يكون الموقعان الأساس والثانوي عبارة عن بيئات خدمة التكامل عند تشغيل تطبيق المنطق الأساس في بيئة خدمة التكامل واستخدام الموصلات التي تم إصدارها من بيئة خدمة التكامل أو إجراءات HTTP لاستدعاء الموارد في شبكة Azure الظاهرية أو كليهما. في هذا السيناريو، لابد أن يحتوي تطبيق المنطق الثانوي أيضًا على إعداد مشابه في الموقع الثانوي مثل تطبيق المنطق الأساس.
ملاحظة
للحصول على سيناريوهات أكثر تقدمًا، بإمكانك مزج كل من Azure متعدد المستأجرين وبيئة خدمة التكامل كمواقع. مع ذلك، يرجي التأكد من مراعاة وفهم الاختلافات بين طريقة تشغيل تطبيقات المنطق في بيئة خدمة التكامل مقابل Azure متعدد المستأجرين.
في حال كنت تستخدم بيئات خدمة التكامل، فتأكد من توسيع نطاقها أو أن لديها سعة كافية للتعامل مع الحمل.
مثال: Azure متعدد المستأجرين
يوضح هذا المثال مثيلات تطبيق المنطق الأساس والثانوي، والتي تنشر على مناطق منفصلة في Azure العالمي متعدد المستأجرين لهذا السيناريو. يحدد قالب Resource Manager واحد كلا من مثيلات التطبيق المنطقي والموارد التابعة والتي تتطلبها تطبيقات المنطق هذه. تحدد ملفات المعلمات المنفصلة قيم التكوين التي يمكن استخدامها لكل موقع نشر:
مثال: بيئات خدمة التكامل
يوضح هذا المثال مثيلات تطبيق المنطق الرئيسة والثانوية السابقة ولكن تم نشرها لفصل بيئات خدمات التكامل. يحدد قالب Resource Manager واحد كلا من مثيلات التطبيق المنطقي والموارد التابعة والتي تتطلبها تطبيقات المنطق هذه، وبيئات خدمات التكامل كمواقع نشر. يتم تحديد قيم التكوين لاستخدامها للنشر في كل موقع من قبل ملفات المعلمات المنفصلة:
الاتصالات بالموارد
توفر Azure Logic Apps العديد من مئات عمليات الموصل التي يمكن أن يستخدمها سير عمل تطبيق المنطق للعمل مع التطبيقات والخدمات والأنظمة والموارد الأخرى الأخرى، مثل حسابات Azure Storage وقواعد بيانات SQL Server وحسابات البريد الإلكتروني للعمل أو المؤسسة التعليمية وما إلى ذلك. في حال كان تطبيق المنطق يحتاج إلى الوصول إلى هذه الموارد، فيمكنك إنشاء اتصالات تصادق الوصول إلى هذه الموارد. يعتبر كل اتصال مورد Azure منفصل موجود في موقع معين ولا يمكن استخدامه من الموارد في مواقع أخرى.
بالنسبة إلى استراتيجية الإصلاح بعد كارثة، ضع في اعتبارك المواقع التي توجد فيها الموارد التابعة بالنسبة إلى مثيلات تطبيق المنطق الخاص بك:
يوجد المثيل الأساس والموارد التابعة الخاصين بك في مواقع مختلفة. في هذه الحالة، يمكن لمثيلك الثانوي الاتصال بنفس الموارد التابعة أو نقاط النهاية. مع ذلك، يجب إنشاء اتصالات خاصة بالمثيل الثانوي الخاص بك. بهذه الطريقة، إذا أصبح موقعك الأساس غير متوفر، فلن تتأثر اتصالات الثانوية.
على سبيل المثال، افترض أن تطبيق المنطق الأساس يتصل بخدمة خارجية مثل Salesforce. يكون عادة توفر الخدمة الخارجية وموقعها مستقلين عن توفر تطبيق المنطق الخاص بك. في هذه الحالة، يمكن للمثيل الثانوي الاتصال بنفس الخدمة ولكن يجب أن يكون له اتصاله الخاص.
كما يوجد المثيل الأساس والموارد التابعة الخاصين بك في مواقع مختلفة. في هذه الحالة، يجب أن تحتوي الموارد التابعة على نسخ احتياطية أو إصدارات منسوخة نسخًا متماثلًا في موقع مختلف حتى لا يزال بإمكان المثيل الثانوي الوصول إلى هذه الموارد.
على سبيل المثال، افترض أن تطبيق المنطق الأساس يتصل بخدمة في نفس الموقع أو المنطقة، على سبيل المثال، قاعدة بيانات Azure SQL. في حال أصبحت هذه المنطقة بأكملها غير متوفرة، فمن المحتمل أن تكون خدمة قاعدة بيانات Azure SQL في تلك المنطقة غير متوفرة أيضًا. في هذه الحالة، تريد أن يستخدم المثيل الثانوي قاعدة بيانات منسوخة نسخًا متماثلًا أو نسخًا احتياطيًا مع اتصال منفصل بقاعدة البيانات هذه.
بوابات البيانات المحلية
في حال كان تطبيق المنطق يعمل في Azure متعدد المستأجرين ويحتاج إلى الوصول إلى الموارد المحلية مثل قواعد البيانات SQL Server، فأنت بحاجة إلى تثبيت بوابة البيانات المحلية على كمبيوتر محلي. بإمكانك بعد ذلك إنشاء مورد بوابة بيانات في مدخل Microsoft Azure حتى يمكن لتطبيق المنطق الخاص بك استخدام البوابة عند إنشاء اتصال بالمورد.
يرتبط مورد بوابة البيانات بموقع أو منطقة Azure، بالضبط مثل مورد تطبيق المنطق الخاص بك. في استراتيجية الإصلاح بعد كارثة، تأكد من أن بوابة البيانات تظل متاحة لتطبيق المنطق الخاص بك لاستخدامها. بإمكانك تمكين قابلية الوصول العالية للبوابة الخاصة بك عندما يكون لديك عمليات تثبيت بوابة متعددة.
ملاحظة
في حال كان تطبيق المنطق يعمل في بيئة خدمة تكامل ويستخدم فحسب الموصلات التي تم إصدارها من بيئة خدمة التكامل لمصادر البيانات المحلية، فلن تحتاج إلى بوابة البيانات لأن موصلات بيئة خدمة التكامل توفر وصولًا مباشرًا إلى المورد المحلي.
في حال لم يتوفر موصل بإصدار بيئة خدمة التكامل للمورد المحلي الذي تريده، فلا يزال بإمكان تطبيق المنطق الخاص بك إنشاء الاتصال باستخدام موصل غير بيئة خدمة التكامل، والذي يعمل في Azure متعدد المستأجرين العمومي، وليس بيئة خدمة التكامل الخاصة بك. مع ذلك، يتطلب هذا الاتصال بوابة البيانات المحلية.
أدوار النشط-النشط مقابل النشط-الخامل
بإمكانك إعداد مواقعك الرئيسة والثانوية حتى يمكن لمثيلات تطبيق المنطق في هذه المواقع تشغيل هذه الأدوار:
| أدوار أساسية/ ثانوية | الوصف |
|---|---|
| نشط-نشط | تعالج مثيلات تطبيق المنطق الأساس والثانوي في كلا الموقعين الطلبات بنشاط باتباع واحد من هذين النمطين: - موازنة التحميل: يمكن أن يكون كلا المثيلين يستمعان إلى نقطة نهاية ونسبة استخدام شبكة موازنة التحميل لكل مثيل حسب الضرورة. - المستهلكون المتنافسون: يمكن أن يكون كلا المثيلين بمثابة مستهلكين متنافسين، إذ تتنافس المثيلات على الرسائل من قائمة انتظار. في حال فشل مثيل واحد، فإن المثيل الآخر يتولى حمل العمل. |
| نشط-سلبي | يتعامل مثيل تطبيق المنطق الأساس بنشاط مع حمل العمل بأكمله، بينما يكون المثيل الثانوي سلبي (معطل أو غير نشط). ينتظر التطبيق الثانوي إشارة إلى أن الأساس غير متوفر أو لا يعمل بسبب التعطيل أو الفشل ويأخذ حمل العمل كمثيل نشط. |
| التركيب | تلعب بعض تطبيقات المنطق الدور النشط-النشط، بينما تلعب تطبيقات المنطق الأخرى الدور النشط-السلبي. |
أمثلة أدوار نشط-نشط
تظهر هذه الأمثلة الإعداد النشط-النشط، إذ يتعامل كل من مثيلات تطبيق المنطق بنشاط مع الطلبات أو الرسائل. توزع بعض الأنظمة الأخرى أو الخدمة الطلبات أو الرسائل بين المثيلات، على سبيل المثال، أحد الخيارات التالية:
موازن تحميل «فعلي»، مثل قطعة من الأجهزة التي توجه نسبة استخدام الشبكة
موازن تحميل «مرن» مثل Azure Load Balancer أو Azure APIM. باستخدام APIM، يمكنك تحديد النهج التي تحدد طريقة موازنة تحميل نسبة استخدام الشبكة الواردة. أو بإمكانك استخدام خدمة تدعم تعقب الحالة، على سبيل المثال، Azure Service Bus.
على الرغم من أن هذا المثال يوضح بشكل أساسي Azure Load Balancer، يمكنك استخدام الخيار الذي يناسب احتياجات السيناريو الخاص بك:
يعمل كل مثيل تطبيق منطق كمستهلك ويتنافس كلا المثيلين على الرسائل من قائمة انتظار:
أمثلة أدوار نشط-سلبي
يظهر هذا المثال الإعداد النشط-السلبي، إذ يكون مثيل تطبيق المنطق الأساس نشطًا في موقع واحد، بينما يظل المثيل الثانوي غير نشط في موقع آخر. في حال واجه التطبيق الأساس تعطيلًا أو فشلًا، يمكن أن يكون لديك عامل تشغيل برنامج نصي ينشط الثانوي لتولي حمل العمل.
تركيبة باستخدام نشط-نشط ونشط-سلبي
يظهر هذا المثال إعدادًا مجمعًا، إذ يحتوي الموقع الأساس على مثيلي تطبيق المنطق النشطين، بينما يحتوي الموقع الثانوي على مثيلات تطبيق منطق نشط-سلبي. في حال كان الموقع الأساس يواجه تعطيلًا أو فشلًا، يمكن لتطبيق المنطق النشط في الموقع الثانوي، والذي يعالج بالفعل حمل عمل جزئيًا، أن يتولى حمل العمل بأكمله.
في الموقع الأساس، يستمع تطبيق المنطق النشط إلى قائمة انتظار Azure Service Bus للرسائل، بينما يتحقق تطبيق منطق نشط آخر من رسائل البريد الإلكتروني باستخدام مشغل التحقق من Office 365 Outlook.
في الموقع الثانوي، يعمل تطبيق المنطق النشط مع تطبيق المنطق في الموقع الأساس عبر الاستماع والتنافس على الرسائل من نفس قائمة انتظار ناقل خدمة Microsoft Azure. في الوقت ذاته، ينتظر تطبيق المنطق غير النشط في وضع الاستعداد للتحقق من وجود رسائل البريد الإلكتروني عندما يصبح الموقع الأساس غير متوفر، لكنه معطل لتجنب إعادة قراءة رسائل البريد الإلكتروني.
حالة التطبيق المنطقي وتاريخها
عند تشغيل تطبيق المنطق الخاص بك وبدء تشغيله، تُخزن حالة التطبيق في نفس الموقع الذي بدأ فيه التطبيق ولا يمكن نقله إلى موقع آخر. في حال حدث فشل أو تعطيل، يتم التخلي عن أي مثيلات سير عمل قيد التقدم. عندما يصبح لديك مواقع رئيسة وثانوية تم إعدادها، تبدأ مثيلات سير العمل الجديدة في التشغيل في الموقع الثانوي.
تقليل المثيلات المهجورة قيد التقدم
لتصغير عدد مثيلات سير العمل قيد التقدم المهجورة، يمكنك الاختيار من بين أنماط الرسائل المختلفة التي يمكنك تنفيذها، على سبيل المثال:
-
نمط رسالة المؤسسة هذا الذي يقوم بتقسيم عملية الأعمال إلى مراحل أصغر. لكل مرحلة، بإمكانك إعداد تطبيق منطقي يعالج حمل العمل لتلك المرحلة. لربطها بعضها البعض، تستخدم تطبيقات المنطق بروتوكول مراسلة غير متزامن مثل قوائم الانتظار أو موضوعات ناقل خدمة Microsoft Azure. عند تقسيم عملية إلى مراحل أصغر، فأنت تقوم بتقليل عدد العمليات التجارية التي قد تتعثر في مثيل تطبيق المنطق الفاشل. للمزيد من المعلومات العامة حول هذا النمط، راجع أنماط تكامل المؤسسة - انزلاق التوجيه.
يشرح هذا المثال نمط انزلاق التوجيه، إذ يمثل كل تطبيق منطقي مرحلة ويستخدم قائمة انتظار ناقل خدمة Microsoft Azure للتواصل مع تطبيق المنطق التالي في العملية.
في حال كانت مثيلات تطبيق المنطق الأساس والثانوي تتبع نفس نمط انزلاق التوجيه في مواقعها، بإمكانك تنفيذ نمط المستهلكين المتنافسين عن طريق إعداد الأدوار النشطة-النشطة لتلك المثيلات.
الوصول إلى المشغل وتشغيل السجل
لمزيد من المعلومات حول عمليات تنفيذ سير العمل السابقة لتطبيق المنطق، يمكنك مراجعة مشغل التطبيق وسجل التشغيل. يتم تخزين محفوظات تنفيذ تطبيق المنطق في نفس الموقع أو المنطقة التي تم تشغيل تطبيق المنطق فيها، ما يعني أنه لا يمكنك ترحيل هذه المحفوظات إلى موقع مختلف. في حال فشل المثيل الأساس الخاص بك إلى مثيل ثانوي، يمكنك فحسب الوصول إلى مشغل كل مثيل وتشغيل السجل في المواقع المعنية في الموقع الذي تم فيه تشغيل هذه المثيلات. مع ذلك، يمكنك الحصول على معلومات غير محددة الموقع حول سجل تطبيق المنطق الخاص بك عن طريق إعداد تطبيقات المنطق لإرسال أحداث التشخيص إلى مساحة عمل Azure Log Analytics. بإمكانك بعد ذلك مراجعة السلامة والسجل عبر تطبيقات المنطق التي تعمل في مواقع متعددة.
إرشادات نوع المشغل
يحدد نوع المشغل الذي تستخدمه في تطبيقات المنطق خياراتك لكيفية إعداد تطبيقات المنطق عبر المواقع في استراتيجية الإصلاح بعد كارثة. فيما يلي أنواع المشغلات المتوفرة التي بإمكانك استخدامها في تطبيقات المنطق:
مشغل التكرار
مشغل التكرار مستقل عن أي خدمة أو نقطة نهاية محددة، ولا يطلق سوى جدولًا محددًا كما أنه لا يستند إلى معايير أخرى، على سبيل المثال:
- تردد ثابت وفاصل زمني، حوالي كل 10 دقائق
- جدول زمني أكثر تقدمًا، مثل آخر يوم اثنين من كل شهر في تمام الساعة 5:00 مساءً
عندما يبدأ تطبيق المنطق بمشغل التكرار، تحتاج إلى إعداد مثيلات تطبيق المنطق الأساس والثانوي مع الأدوار نشط-سلبي. لتقليل هدف وقت الاسترداد، الذي يشير إلى المدة المستهدفة لاستعادة عملية عمل بعد انقطاع أو كارثة، يمكنك إعداد مثيلات تطبيق المنطق الخاص بك مع مجموعة من الأدوار نشط-سلبيوالأدوار نشط-سلبي. في هذا الإعداد، بإمكانك تقسيم الجدول الزمني عبر المواقع.
على سبيل المثال، افترض أن لديك تطبيقًا منطقيًا يجب تشغيله كل 10 دقائق. بإمكانك إعداد التطبيقات والمواقع المنطقية وفي حين إذا أصبح الموقع الأساس غير متوفر، يمكن أن يتولى الموقع الثانوي العمل:
في الموقع الأساس، قم بإعداد أدوار نشط-سلبي لهذه التطبيقات المنطقية:
بالنسبة إلى تطبيق المنطق النشط الممكن، عين مشغل التكرار للبدء في أعلى الساعة وكرر كل 20 دقيقة، على سبيل المثال، 9:00 صباحًا، 9:20 صباحًا، وهكذا.
بالنسبة إلى تطبيق المنطق السلبي المعطل، قم بتعيين مشغل التكرار إلى نفس الجدول ولكن ابدأ في 10 دقائق بعد الساعة وكرر كل 20 دقيقة، على سبيل المثال، 9:10 صباحًا، 9:30 صباحًا، وهكذا.
في الموقع الثانوي، قم بإعداد سلبي-نشط لهذه التطبيقات المنطقية:
بالنسبة إلى تطبيق المنطق السلبي المعطل، قم بتعيين مشغل التكرار إلى نفس الجدول الزمني مثل تطبيق المنطق النشط في الموقع الأساس، ويتواجد بأعلى الساعة ويكرر كل 20 دقيقة، على سبيل المثال، 9:00 صباحًا، 9:10 صباحًا، وهكذا.
بالنسبة إلى تطبيق المنطق النشط الممكن، قم بتعيين مشغل التكرار إلى نفس الجدول الزمني مثل تطبيق المنطق النشط في الموقع الأساس، ويبدأ في 10 دقائق بعد الساعة ويكرر كل 20 دقيقة، على سبيل المثال، 9:10 صباحًا، و9:20 صباحًا، وهكذا.
الآن، في حال وقوع حدث تخريبي في الموقع الأساس، فنشط تطبيق المنطق السلبي في الموقع البديل. بهذه الطريقة، إذا استغرق العثور على الفشل وقتًا، فإن هذا الإعداد يحد من عدد التكرارات الفائتة أثناء هذا التأخير.
مشغل التحقق
للتحقق بانتظام مما إذا كانت البيانات الجديدة للمعالجة متوفرة من خدمة أو نقطة نهاية معينة، يمكن لتطبيق المنطق استخدام مشغل تحقق يستدعي الخدمة أو نقطة النهاية بصورة متكررة استنادًا إلى جدول تكرار ثابت. قد تحتوي البيانات التي توفرها الخدمة أو نقطة النهاية على أي من هذين النوعين:
- البيانات الثابتة، والتي تصف البيانات المتوفرة دائما للقراءة
- البيانات المتنقلة، التي تصف البيانات التي لم تعد متوفرة بعد القراءة
لتجنب قراءة نفس البيانات بصورة متكررة، يحتاج تطبيق المنطق إلى تذكر البيانات التي تمت قراءتها مسبقًا عن طريق الحفاظ على الحالة إما على جانب العميل أو على جانب الخادم أو الخدمة أو النظام.
تستخدم تطبيقات المنطق التي تعمل مع حالة العميل مشغلات بإمكانها الحفاظ على الحالة.
على سبيل المثال، يتطلب المشغل الذي يقرأ رسالة جديدة من صندوق وارد البريد الإلكتروني أن يتذكر المشغل أحدث رسالة تمت قراءتها. بهذه الطريقة، يبدأ المشغل التطبيق المنطقي عند وصول الرسالة غير المقروءة التالية فحسب.
تستخدم تطبيقات المنطق التي تعمل مع الخادم أو الخدمة أو الحالة من جانب النظام الإعدادات أو قيم الخصائص الموجودة على جانب الخادم أو الخدمة أو النظام.
على سبيل المثال، يتطلب المشغل المستند إلى الاستعلام الذي يقرأ صفا من قاعدة بيانات أن يحتوي الصف على عمود
isReadتم تعيينه إلىFALSE. في كل مرة يقرأ فيها المشغل صفًا، يحدث تطبيق المنطق هذا الصف عن طريق تغيير العمودisReadمنFALSEإلىTRUE.يعمل هذا النهج من جانب الخادم على نحو مماثل لقوائم انتظار ناقل خدمة Microsoft Azure أو الموضوعات التي تحتوي على دلالات قائمة الانتظار حتى يمكن للمشغل قراءة رسالة وتأمينها أثناء معالجة تطبيق المنطق للرسالة. عندما ينتهي تطبيق المنطق من المعالجة، يقوم المشغل بحذف الرسالة من قائمة الانتظار أو الموضوع.
من منظور الإصلاح بعد كارثة، عند إعداد مثيلات التطبيق المنطقي الرئيسة والثانوية، تأكد من حساب هذه السلوكيات استنادًا إلى ما إذا كان تطبيق المنطق الخاص بك يتعقب الحالة على جانب العميل أو على جانب الخادم:
فيما يتعلق بتطبيق منطق يعمل مع حالة العميل، تأكد من أن تطبيق المنطق الخاص بك لا يقرأ نفس الرسالة أكثر من مرة واحدة. كما يمكن أن يحتوي موقع واحد فقط على مثيل تطبيق منطق نشط في أي وقت محدد. يرجي التأكد من أن مثيل تطبيق المنطق في الموقع البديل غير نشط أو معطل حتى يفشل المثيل الأساس إلى الموقع البديل.
على سبيل المثال، يحافظ مشغل Office 365 Outlook على حالة العميل ويتعقب الطابع الزمني للبريد الإلكتروني الذي تمت قراءته مؤخرًا لتجنب قراءة تكرار.
بالنسبة لتطبيق منطقي يعمل مع الحالة من جانب الخادم، فيمكنك إعداد مثيلات تطبيق المنطق لتشغيل أدوار نشط-نشط حتى تعمل كمستهلكين متنافسين أو أدوار نشط-سلبي، إذ ينتظر المثيل البديل حتى يفشل المثيل الأساس إلى الموقع البديل.
على سبيل المثال، تستخدم القراءة من قائمة انتظار الرسائل، مثل قائمة انتظار ناقل خدمة Azure، الحالة من جانب الخادم لأن خدمة الانتظار تحتفظ بتأمين الرسائل لمنع العملاء الآخرين من قراءة الرسائل نفسها.
ملاحظة
في حال كان تطبيق المنطق يحتاج إلى قراءة الرسائل بترتيب معين، على سبيل المثال، من قائمة انتظار ناقل خدمة Microsoft Azure، فيمكنك استخدام نمط المستهلك المتنافس ولكن عند دمجه مع جلسات ناقل خدمة Microsoft Azure فحسب، والذي يعرف أيضًا باسم نمط القافلة المتسلسلة. وإلا، ينبغي عليك إعداد مثيلات تطبيق المنطق مع الأدوار نشط-سلبي.
مشغل الطلب
يجعل مشغل الطلب تطبيق المنطق الخاص بك قابلًا للاستدعاء من التطبيقات والخدمات والأنظمة الأخرى ويستخدم عادة لتوفير هذه الإمكانات:
واجهة برمجة تطبيقات REST مباشرة لتطبيق المنطق الخاص بك الذي يمكن للآخرين الاتصال به
على سبيل المثال، استخدم مشغل الطلب لبدء تطبيق المنطق الخاص بك حتى تتمكن تطبيقات المنطق الأخرى من استدعاء المشغل باستخدام إجراء سير عمل الاستدعاء - Logic Apps.
إخطار على الويب أو آلية رد الاتصال لتطبيق المنطق الخاص بك
طريقة تمكنك من تشغيل عمليات المستخدم أو الإجراءات الروتينية يدويًا لاستدعاء تطبيق المنطق الخاص بك، على سبيل المثال، باستخدام برنامج نصي PowerShell يقوم بتنفيذ مهمة معينة
من منظور الإصلاح بعد كارثة، مشغل الطلب هو جهاز استقبال سلبي لأن تطبيق المنطق لا يقوم بأي عمل وينتظر حتى تستدعي بعض الخدمة أو النظام الآخر المشغل بشكل صريح. كنقطة نهاية سلبية، يمكنك إعداد المثيلات الرئيسة والثانوية الخاصة بك بهذه الطرق:
نشط-نشط: يعالج كلا المثيلين الطلبات أو الاستدعاءات بنشاط. يقوم المستدعي أو الموجه بموازنة نسبة استخدام الشبكة بين هذه المثيلات أو نشرها.
Active-passive: المثيل الأساس نشط فحسب ويعالج كل العمل، في حين ينتظر المثيل الثانوي حتى يتعرض المثيل الثانوي للتعطيل أو الفشل. يحدد المتصل أو الموجه وقت استدعاء المثيل الثانوي.
كبنية موصى بها، يمكنك استخدام APIM كوكيل لتطبيقات المنطق التي تستخدم مشغلات الطلب. توفر APIM مرونة مضمنة عبر المناطق والقدرة على توجيه نسبة استخدام الشبكة عبر نقاط نهاية متعددة.
مشغل الإخطار على الويب
يوفر مشغل الإخطار على الويب إمكانية اشتراك تطبيق المنطق الخاص بك في خدمة عن طريق تمرير عنوان موقع ويب لرد الاتصال إلى تلك الخدمة. يمكن لتطبيق المنطق الخاص بك بعد ذلك الاستماع والانتظار حتى وقوع حدث معين في نقطة نهاية الخدمة هذه. عند حدوث الحدث، تستدعي الخدمة مشغل خطاف الويب باستخدام عنوان موقع ويب لرد الاتصال، والذي يقوم بعد ذلك بتشغيل تطبيق المنطق. عند التمكين، يشترك مشغل إخطار على الويب في الخدمة. عند تعطيله، يلغي المشغل الاشتراك من الخدمة.
من منظور الإصلاح بعد كارثة، قم بإعداد المثيلات الرئيسة والثانوية التي تستخدم مشغلات خطاف الويب للعب أدوار نشطة-سلبية لأنه يجب أن يتلقى مثيل واحد فقط الأحداث أو الرسائل من نقطة النهاية المشتركة.
تقييم سلامة المثيل الأساس
لكي تعمل استراتيجية الإصلاح بعد كارثة، يحتاج الحل الخاص بك إلى طرق لتنفيذ هذه المهام:
يصف هذا القسم حلًا واحدًا بإمكانك استخدامه مباشرة أو كأساس لتصميمك الخاص. إليك نظرة عامة مرئية عالية المستوى لهذا الحل:
التحقق من توفر المثيل الأساس
لتحديد ما إذا كان المثيل الأساس متوفرًا ومشغلًا وقادرًا على العمل، يمكنك إنشاء تطبيق منطقي «فحص السلامة» في نفس موقع المثيل الأساس. بإمكانك بعد ذلك استدعاء تطبيق التحقق من الصحة هذا من موقع بديل. في حال استجاب تطبيق التحقق من الصحة بنجاح، فإن البنية الرئيسة لخدمة Azure Logic Apps في تلك المنطقة متاحة وتعمل. في حال فشل تطبيق التحقق من الصحة في الاستجابة، فيمكنك افتراض أن الموقع لم يعد سليمًا.
بالنسبة إلى هذه المهمة، أنشئ تطبيق منطق أساس للتحقق من الصحة يقوم بتنفيذ هذه المهام:
يتلقى استدعاءً من تطبيق مراقب عن طريق مشغل الطلب.
الاستجابة بحالة تشير إلى إذا كان تطبيق المنطق المحدد لا يزال يعمل عن طريق إجراء الاستجابة.
هام
يجب أن يستخدم تطبيق منطق التحقق من الصحة إجراء استجابة حتى يستجيب التطبيق على نحو متزامن، وليس بشكل غير متزامن.
اختياريًا، لتحديد ما إذا كان الموقع الأساس سليمًا، بإمكانك مراعاة صحة أي خدمات أخرى تتفاعل مع تطبيق المنطق الهدف في هذا الموقع. ليس عليك سوى توسيع تطبيق منطق التحقق من الصحة لتقييم صحة هذه الخدمات الأخرى أيضًا.
إنشاء تطبيق منطق مراقبة
لمراقبة صحة المثيل الأساس واستدعاء تطبيق منطق التحقق من الصحة، قم بإنشاء تطبيق منطق مراقبة في موقع بديل. على سبيل المثال، بإمكانك إعداد تطبيق منطق المراقبة حتى إذا فشل استدعاء منطق التحقق من الصحة، يمكن لمجموعة المراقبة إرسال تنبيه إلى فريق العمليات حتى يمكنهم التحقيق في الفشل ولماذا لا يستجيب المثيل الأساس.
هام
يرجي التأكد من أن تطبيق منطق المراقبة في موقع يختلف عن الموقع الأساس. إذا واجهت Azure Logic Apps في الموقع الأساسي مشكلات، فقد لا يتم تشغيل سير عمل تطبيق منطق المراقبة.
لهذه المهمة، في الموقع الثانوي، أنشئ تطبيق منطق مراقبة ينفذ هذه المهام التالية:
التشغيل استنادًا إلى تكرار ثابت أو مجدول باستخدام مشغل التكرار.
بإمكانك تعيين التكرار إلى قيمة أقل من مستوى التسامح لهدف وقت الاسترداد (RTO).
استدعاء سير عمل تطبيق منطق التحقق من الصحة في الموقع الأساسي باستخدام إجراء HTTP.
يمكنك أيضا إنشاء تطبيق منطق مراقبة أكثر تعقيدا، والذي بعد عدد من حالات الفشل، يستدعي تطبيق منطق آخر يتعامل تلقائيا مع التبديل إلى الموقع الثانوي عند فشل الأساسي.
تنشيط المثيل الثانوي الخاص بك
لتنشيط المثيل الثانوي تلقائيًا، بإمكانك إنشاء تطبيق منطقي يستدعي واجهة برمجة تطبيقات الإدارة مثل موصل Resource Manager Azure لتنشيط تطبيقات المنطق المناسبة في الموقع الثانوي. بإمكانك توسيع تطبيق المراقبة الخاص بك لاستدعاء تطبيق منطق التنشيط هذا بعد حدوث عدد معين من حالات الفشل.
تكرار المنطقة باستخدام مناطق التوفر
في كل منطقة Azure، مناطق التوافرهي مواقع منفصلة فعليًا داخل كل منطقة Azure متسامحة مع حالات الفشل المحلية. قد تتراوح هذه الإخفاقات من فشل البرامج والأجهزة إلى أحداث مثل الزلازل والفيضانات والحرائق. تحقق هذه المناطق التسامح عبر التكرار والعزل المنطقي لخدمات Azure.
لتوفير المرونة والتوفر الموزع، ثمة ثلاث مناطق توفر منفصلة على الأقل في أي منطقة Azure تدعم التكرار في المنطقة وتمكنه. يوزع النظام الأساس Azure Logic Apps هذه المناطق وأحمال عمل تطبيق المنطق عبر هذه المناطق. تعد هذه الإمكانية مطلبًا رئيسًا لتمكين البنيات المرنة وتوفير قابلية وصول عالية في حالة حدوث فشل في مركز البيانات في منطقة ما.
حاليًا، تعد هذه الإمكانية معاينة ومتاحة لتطبيقات منطق الاستهلاك الجديدة في مناطق معينة. لمزيد من المعلومات، راجع الوثائق التالية:
جمع بيانات التشخيص
بإمكانك إعداد التسجيل لتشغيل تطبيق المنطق وإرسال البيانات التشخيصية الناتجة إلى خدمات مثل Azure Storage ومراكز الأحداث وAzure Log Analytics لمزيد من المعالجة.
في حال كنت ترغب في استخدام هذه البيانات مع Azure Log Analytics، بإمكانك إتاحة البيانات لكل من المواقع الرئيسة والثانوية عن طريق إعداد إعدادات التشخيص لتطبيق المنطق وإرسال البيانات إلى مساحات عمل Log Analytics متعددة. لمزيد من المعلومات، راجعإعداد سجلات Azure Monitor وجمع بيانات التشخيص Azure Logic Apps.
في حال كنت تريد إرسال البيانات إلى Azure Storage أو مراكز الأحداث، فيمكنك توفير البيانات لكل من المواقع الرئيسة والثانوية عن طريق إعداد التكرار الجغرافي. لمزيد من المعلومات، راجع هذه المقالات: