Windows Server Failover Cluster مع خادم SQL من Windows على VMs Azure

ينطبق على: Microsoft SQL Server على Azure VM

توضح هذه المقالة الاختلافات عند استخدام ميزة "نظام كتلة تجاوز الفشل ل Windows Server" مع SQL Server على أجهزة افتراضية من Azure لإتاحة إمكانية توفر عالية واستعادة البيانات بعد الكوارث (HADR)، مثل مجموعات التوفر (AG) أو مثيلات نظام الكتلة لتجاوز الفشل (FCI).

لمعرفة المزيد حول ميزة Windows نفسها، راجع وثائق نظام كتلة تجاوز الفشل ل Windows Server ⁦⁩.

نظرة عامة

تعتمد حلول SQL Server ذات التوفر العالي على نظام التشغيل Windows، مثل مجموعات التوفر دوماً (AG) أو مثيلات مجموعة تجاوز الفشل (FCI) على خدمة كتلة تجاوز الفشل لWindows Server (WSFC) الأساسية.

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

مراقبة صحة الكتلة

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

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

هناك إستراتيجيتان للمراقبة:

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

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

نبضات قلب الكتلة

الإعدادات الأساسية التي تؤثر على نبض قلب نظام الكتلة واكتشاف الحالة الصحية بين العقد:

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

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

الحصة

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

من الناحية الفنية، يمكن أن يتحمل نظام الكتلة المكون من ثلاث عقد خسارة لعقدة واحدة (حتى عقدتين) بدون مورد الحصص. ولكن بعد انخفاض نظام الكتلة إلى عقدتين، قد يؤدي ذلك إلى قطع اتصال الموارد المجمعة لمنع حدوث سيناريو split-brain في حالة فقدان إحدى العقد أو حدوث فشل في الاتصال بين العقد. سيتيح تكوين مورد الحصص لموارد نظام الكتلة البقاء على اتصال مع وجود عقدة واحدة فقط عبر الإنترنت.

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

يسرد الجدول التالي خيارات الحصة المتوفرة لـ SQL Server على Azure VMs:

	مراقب سحابي	مراقب القرص	مراقب مشاركة الملف
نظام التشغيل المعتمد	Windows Server 2016+	الكل	الكل
الوصف	شاهد السحابة هو نوع من شاهد الحصص لنظام كتلة تجاوز الفشل يستخدم Microsoft Azure لتوفير التصويت على الحصص النسبية لنظام الكتلة. الحجم الافتراضي هو حوالي 1 ميغابايت ويحتوي فقط على ختم الوقت. يعتبر شاهد السحابة مثالي لعمليات النشر في مواقع متعددة ومناطق متعددة ومناطق متعددة. استخدم شاهد السحابة كلما أمكن ذلك، ما لم يكن لديك حل كتلة لتجاوز الفشل مع وحدة تخزين مشتركة.	شاهد القرص عبارة عن قرص صغير مجمع في مجموعة تخزين نظام الكتلة المتاح. هذا القرص متوفر بدرجة كبيرة وقد يتعرض للفشل بين العقد. يحتوي على نسخة من قاعدة بيانات الكتلة، بحجم افتراضي أقل من 1 غيغابايت. شاهد القرص هي خيار الحصص المفضل لأي كتلة تستخدم أقراص Azure المشتركة (أو أي حل قرص مشترك مثل SCSI أو iSCSI أو القناة الليفية SAN). يتعذر استخدام وحدة تخزين مشتركة مجمعة كشاهد للقرص. تكوين قرص مشترك من Azure كشاهد للقرص.	شاهد مشاركة الملف هو مشاركة ملف SMB التي يتم تكوينها عادة على خادم ملفات يعمل على Windows Server. يحافظ على معلومات التجميع في ملف Witness.log، ولكنه لا يخزن نسخة من قاعدة بيانات نظام الكتلة. في Azure، يمكنك تكوين مشاركة ملفات على جهاز ظاهري منفصل داخل نفس الشبكة الظاهرية. استخدم شاهد مشاركة ملف إذا كان شاهد القرص أو شاهد السحابة غير متوفر في البيئة الخاصة بك.

للبدء، راجع ⁦⁩تكوين الحصص لنظام الكتلة⁦⁩.

اسم الشبكة الظاهرية (VNN)

لمطابقة التجربة المحلية للاتصال بوحدة استماع مجموعة قابلية وصول عالية أو مثيل مجموعة تجاوز الفشل، قم بتوزيع أجهزة Microsoft SQL Server الظاهرية الخاص بك إلى شبكات فرعية متعددة داخل نفس الشبكة الظاهرية. إن وجود شبكات فرعية متعددة يلغي الحاجة إلى التبعية الإضافية على Azure Load Balancer لتوجيه نسبة استخدام الشبكة إلى حل HADR الخاص بك. لمعرفة المزيد، راجع مجموعة قابلية الوصول (AG) متعددة الشبكات الفرعية ونظام مجموعة تجاوز فشل (FCI) متعدد الشبكات الفرعية.

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

على الأجهزة الظاهرية Azure Virtual Machine في شبكة فرعية واحدة، من الضروري وجود مكون إضافي لتوجيه نسبة استخدام الشبكة من العميل إلى اسم الشبكة الظاهرية لمورد نظام المجموعة (مثيل نظام مجموعة تجاوز الفشل، أو وحدة استماع مجموعة قابلية وصول عالية التوفر). في Azure، يحتوي موازن التحميل على عنوان IP الخاص بشبكة VNN التي تعتمد عليها موارد SQL Server المجمعة وهي ضرورية لتوجيه حركة مرور البيانات إلى الهدف المناسب عالي التوفر. كما يكتشف موازن التحميل حالات الفشل في مكونات الشبكة وينقل العنوان إلى مضيف جديد.

يقوم "موازن التحميل" بتوزيع التدفقات الواردة التي تصل إلى الطرف الأمامي، ثم يقوم بتوصيل حركة مرور البيانات إلى المثيلات المحددة بواسطة تجمع الطرف الخلفي. يمكنك تكوين تدفق حركة مرور البيانات باستخدام قواعد موازنة الأحمال والتحقيقات الصحية. باستخدام SQL Server FCI، تكون مثيلات المجموعة الخلفية هي الأجهزة الافتراضية Azure التي تقوم بتشغيل SQL Server، ومع مجموعات التوافر، يكون التجمع الخلفي هو المستمع. هناك تأخير طفيف في تجاوز الفشل عند استخدام موازن التحميل، لأن المسبار الصحي يجري فحوصات حية كل 10 ثوان بشكل افتراضي.

للبدء، تعرف على كيفية تكوين موازن تحميل Azure لمثيل كتلة تجاوز الفشل أو مجموعة توفر.

نظام التشغيل المدعوم: الكل
نسخة SQL المدعومة: الكل
حل HADR المدعم: مثيل كتلة تجاوز الفشل، ومجموعة التوفر

قد يكون تكوين VNN مرهقاً، فهو مصدر إضافي للفشل، وقد يتسبب في تأخير اكتشاف الأعطال، كما أن هناك مصروفات عامة وتكلفة مرتبطة بإدارة المورد الإضافي. لمعالجة بعض هذه القيود، قدم Microsoft SQL Server دعماً لميزة اسم الشبكة الموزَّعة.

اسم الشبكة الموزعة (DNN)

لمطابقة التجربة المحلية للاتصال بوحدة استماع مجموعة قابلية وصول عالية أو مثيل مجموعة تجاوز الفشل، قم بتوزيع أجهزة Microsoft SQL Server الظاهرية الخاص بك إلى شبكات فرعية متعددة داخل نفس الشبكة الظاهرية. إن وجود شبكات فرعية متعددة يلغي الحاجة إلى التبعية الإضافية على DNN لتوجيه نسبة استخدام الشبكة إلى حل HADR الخاص بك. لمعرفة المزيد، راجع مجموعة قابلية الوصول (AG) متعددة الشبكات الفرعية ونظام مجموعة تجاوز فشل (FCI) متعدد الشبكات الفرعية.

بالنسبة لأجهزة Microsoft SQL Server الظاهرية التي تم توزيعها في شبكة فرعية مفردة، توفر ميزة اسم الشبكة الموزَّعة طريقة بديلة لعملاء Microsoft SQL Server للاتصال بمثيل مجموعة تجاوز فشل SQL Server أو وحدة استماع مجموعة قابلية وصول عالية التوفر دون استخدام موازن تحميل. تتوفر ميزة DNN بدءاً من Microsoft SQL Server 2016 SP3 وMicrosoft SQL Server 2017 CU25 وMicrosoft SQL Server 2019 CU8على Windows Server 2016 والإصدارات الأحدث.

عند إنشاء مورد DNN، يقوم نظام الكتلة بربط اسم DNS بعناوين IP لجميع العقد في نظام الكتلة. سيحاول العميل الاتصال بكل عنوان IP في هذه القائمة للعثور على المورد المطلوب الاتصال به. يمكنك تسريع هذه العملية بتحديد ⁦MultiSubnetFailover=True⁩ في سلسلة الاتصال. يطلب هذا الإعداد من الموفر محاولة جميع عناوين IP بالتوازي، حتى يتمكن العميل من الاتصال ب FCI أو المستمع على الفور.

يوصى باستخدام اسم شبكة موزع على موازن تحميل عندما يكون ذلك ممكناً بسبب:

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

تعمل معظم ميزات SQL Server بشفافية مع FCI ومجموعات التوفر عند استخدام DNN، ولكن هناك ميزات معينة قد تتطلب اعتباراً خاصاً.

نظام التشغيل المدعوم: Windows Server 2016 والإصدارات الأحدث منه
النسخة SQL المدعمة: SQL Server CU2 2019 (FCI) وSQL Server 2019 CU8 (AG)
حل HADR المدعم: مثيل كتلة تجاوز الفشل، ومجموعة التوفر

للبدء، تعلم تكوين مورد اسم شبكة موزع لمثيل كتلة تجاوز الفشل أو مجموعة توفر.

توجد اعتبارات إضافية عند استخدام DNN مع ميزات SQL Server أخرى. انظر ⁦⁩FCI وDNN للتشغيل المتبادل⁦⁩ و⁦⁩AG وDNN للتشغيل المتبادل⁦ ⁩للتعلم أكثر.

إجراءات الاسترداد

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

على سبيل المثال، تأتي مجموعة توفر إعادة التشغيل عبر الإنترنت حسب التسلسل التالي:

1. IP الخاص بالمستمع يأتي عبر الإنترنت
2. اسم شبكة المستمع يأتي عبر الإنترنت
3. تأتي مجموعة التوفر عبر الإنترنت
4. يتم إسترداد قواعد البيانات الفردية، والتي قد تستغرق بعض الوقت اعتماداً على عدد من العوامل، مثل طول سجل الإعادة. يتم توجيه الاتصالات بواسطة المستمع فقط بمجرد استرداد قاعدة البيانات بالكامل. لمعرفة المزيد، راجع ⁦⁩تقدير وقت تجاوز الفشل (RTO)⁦⁩.

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

لضبط إعدادات العتبة، راجع ⁦أفضل الممارسات للكتلة⁦⁩ لمزيد من التفاصيل.

موقع العقدة

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

حدود الموارد

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

قد تؤدي عمليات الإدخال/الإخراج المكثفة في SQL أو عمليات الصيانة مثل النسخ الاحتياطية أو الفهرس أو صيانة الإحصائيات إلى وصول VM أو القرص إلى حدود معدل النقل ⁦⁩IOPS⁦⁩ أو ⁦⁩MBPS⁦⁩، ما قد يجعل SQL Server غير مستجيب لفحص⁩IsAlive/LooksAlive⁦⁩.

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

صيانة النظام الأساسي Azure

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

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

تعمل صيانة الحفاظ على الذاكرة لأكثر من 90 بالمائة من الأجهزة الافتراضية من Azure. لا تعمل مع سلاسل G وM وN وH. يستخدم Azure بشكل متزايد تقنيات الترحيل المباشر ويحسن آليات صيانة الحفاظ على الذاكرة لتقليل فترات التوقف المؤقت. عندما يتم ترحيل الجهاز الافتراضي مباشرة إلى مضيف آخر، قد تظهر بعض أحمال العمل الحساسة مثل SQL Server انخفاضاً طفيفاً في الأداء في الدقائق القليلة التي أدت إلى إيقاف تشغيل الجهاز الافتراضي مؤقتاً.

قد يؤدي اختناق الموارد أثناء صيانة النظام الأساسي إلى ظهور AG أو FCI أسفل خدمة نظام الكتلة. راجع القسم ⁦⁩ حدود الموارد⁦⁩ من هذه المقالة لمعرفة المزيد.

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

التقييدات

ضع في اعتبارك القيود التالية عند التعامل مع FCI أو مجموعات التوفر وSQL Server على الأجهزة الافتراضية Azure.

MSDTC

تدعم أجهزة Azure الظاهرية منسق العمليات الموزعة (MSDTC) من Microsoft على Windows Server 2019 مع التخزين على وحدات التخزين المشتركة المجمعة (CSV) وموازن التحميل القياسي Azure أو على SQL Server VMs التي تستخدم أقراص Azure المشتركة.

في أجهزة Azure الظاهرية، لا يتم دعم MSDTC لنظام التشغيل Windows Server 2016 أو الإصدارات الأقدم مع وحدات التخزين المشتركة المجمعة للأسباب التالية:

• لا يمكن تكوين مورد MSDTC مجمع لاستخدام التخزين المشترك. في Windows Server إصدار2016، إذا قمت بإنشاء مورد MSDTC، فلن يعرض أي تخزين مشترك متاح للاستخدام، حتى إذا كان التخزين متوفراً. تم إصلاح هذه المشكلة في Windows Server 2019.
• موازن التحميل الأساسي لا يعالج منافذ RPC.

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

الآن بعد أن تعرفت على الاختلافات عند استخدام نظام كتلة Windows لتجاوز الفشل مع SQL Server على الأجهزة الافتراضية VMs ل Azure، تعرف على ميزات التوفر العالي ⁦ ⁩ مجموعات التوفر⁦⁩ أو ⁦⁩مثيلات نظام الكتلة لتجاوز الفشل⁦ ⁩. إذا كنت مستعداً للبدء، فتأكد من مراجعة ⁦⁩أفضل الممارسات⁦⁩ لتوصيات التكوين.