إنشاء وتكوين وإدارة الوظائف المرنة (معاينة)

مقالة
01/28/2024

ينطبق على: قاعدة بيانات Azure SQL

في هذه المقالة، ستتعلم كيفية إنشاء وتكوين وإدارة الوظائف المرنة.

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

إنشاء وتكوين الوكيل

إنشاء أو تحديد قاعدة بيانات فارغة S0 أو أعلى. سيتم استخدام قاعدة البيانات هذه باعتبارها قاعدة بيانات الوظائف في أثناء إنشاء وكيل Elastic Job.
أنشئ وكيل Elastic Job في البوابة أو باستخدام PowerShell .

إنشاء الوظائف وتشغيلها وإدارتها

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

أوراق اعتماد لتشغيل الوظائف

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

قد يكون إعداد بيانات الاعتماد المناسبة لتشغيل وظيفة أمرًا مربكًا بعض الشيء، لذا ضع في اعتبارك النقاط التالية:

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

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

Elastic Jobs credentials

أفضل ممارسات الأمان

بعض اعتبارات أفضل الممارسات للعمل مع Elastic Jobs:

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

أداء وقدرة وقيود الوكيل

تستخدم الوظائف المرنة الحد الأدنى من موارد الحوسبة في أثناء انتظار إكمال المهام طويلة المدى.

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

منع المهام من تقليل أداء قاعدة البيانات الهدف

لضمان عدم إثقال الموارد عند تشغيل المهام مقابل قواعد البيانات في تجمع SQL المرن، يمكن تكوين الوظائف للحد من عدد قواعد البيانات التي يمكن أن تعمل عليها الوظيفة في نفس الوقت.

قم بتعيين عدد قواعد البيانات المتزامنة التي يتم تشغيل المهمة عليها عن طريق تعيين معلمة sp_add_jobstep الإجراء المخزن @max_parallelism في T-SQL.

القيود المعروفة

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

مشكلة	الوصف
يجب إعادة إنشاء عامل الوظيفة المرنة والبدء في المنطقة الجديدة بعد تجاوز الفشل/الانتقال إلى منطقة Azure جديدة.	تخزن خدمة وظائف مرنة جميع وكلاء الوظائف وبيانات التعريف للوظائف في قاعدة بيانات الوظائف. سيؤدي أي تجاوز فشل أو نقل لموارد Azure إلى منطقة Azure جديدة إلى نقل قاعدة بيانات الوظائف وعامل الوظائف وبيانات تعريف الوظائف إلى منطقة Azure الجديدة. ومع ذلك، فإن عامل الوظيفة المرنة هو مورد حساب فقط ويحتاج إلى إعادة إنشائه بشكل صريح وبدء تشغيله في المنطقة الجديدة قبل أن تبدأ الوظائف في التنفيذ مرة أخرى في المنطقة الجديدة. بمجرد البدء، سيستأنف عامل Elastic Job تنفيذ الوظائف في المنطقة الجديدة وفقاً لجدول الوظائف المحدد مسبقاً.
حد الوظائف المتزامنة.	في الوقت الحالي، تقتصر المعاينة على 100 وظيفة متزامنة.
سجلات التدقيق المفرطة من قاعدة بيانات "الوظائف"	يعمل وكيل Elastic Job عن طريق استطلاع قاعدة بيانات الوظيفة باستمرار للتحقق من وصول وظائف جديدة وعمليات CRUD الأخرى. إذا تم تمكين التدقيق على الخادم الذي يضم قاعدة بيانات الوظائف، فقد يتم إنشاء كمية كبيرة من سجلات التدقيق بواسطة قاعدة بيانات "الوظائف". يمكن التخفيف من هذا عن طريق تصفية سجلات التدقيق هذه باستخدام الأمر `Set-AzSqlServerAudit` مع تعبير أصلي. على سبيل المثال: `Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "database_principal_name <> '##MS_JobAccount##'"` سيتولى هذا الأمر تصفية "وكيل الوظيفة" إلى سجلات تدقيق قاعدة بيانات "الوظائف" فقط، وليس "وكيل الوظيفة" إلى أي سجلات تدقيق خاصة بقواعد البيانات المستهدفة.

أفضل الممارسات لخلق الوظائف

ضع في اعتبارك أفضل الممارسات التالية عند العمل مع وظائف قاعدة بيانات مرنة:

نصوص عديمة الجدوى

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

التكتيك البسيط هو اختبار وجود كائن قبل إنشائه. يتم عرض مثال افتراضي أدناه:

IF NOT EXISTS (SELECT * FROM sys.objects WHERE [name] = N'some_object')
    print 'Object does not exist'
    -- Create the object
ELSE
    print 'Object exists'
    -- If it exists, drop the object before recreating it.

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

Share via