أنماط التطبيق واستراتيجيات التطوير لـ SQL Server على الأجهزة الظاهرية Azure

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

ملاحظة

لدى Azure نموذجان مختلفان للاستخدام لإنشاء الموارد والعمل معها: Resource Manager والكلاسيكي. تغطي هذه المقالة باستخدام كلا النموذجين، ولكن توصي Microsoft أن معظم عمليات التوزيع الجديدة تستخدم نموذج Resource Manager.

الملخص:

تحديد نمط أو أنماط التطبيق التي سيتم استخدامها للتطبيقات المستندة إلى SQL Server في بيئة Azure هو قرار تصميم هام ويتطلب فهمًا جيدًا لكيفية عمل SQL Server وكل مكون من مكونات البنية الأساسية لـ Azure معًا. باستخدام SQL Server في خدمات البنية الأساسية Azure، يمكنك بسهولة ترحيل تطبيقات SQL Server الموجودة لديك والمبنية على Windows Server إلى الأجهزة الظاهرية (VMs) في Azure بالإضافة إلى صيانتها ومراقبتها.

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

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

المساهمون التقنيون: لويس كارلوس فارجاس هيرينج، مادهان أروموجام راماكريشنان

المراجعون التقنيون: كوري ساندرز، درو مكدانيل، نارايان أنامالي، نير ماشكوفسكي، سانجاي ميشرا، سيلفانو كورياني، ستيفان شاكو، تيم هيكي، تيم ويمان، شين جين

مقدمة

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

يتضمن تطبيق n-tier النموذجي مستوى العرض التقديمي، وفئة العمل، وفئة البيانات:

المستوى	الوصف
عرض تقديمي	طبقة العرض التقديمي (طبقة الويب، الطبقة الأمامية) هي الطبقة التي يتفاعل فيها المستخدمون مع التطبيق.
الأعمال	طبقة الأعمال (الطبقة الوسطى) هي الطبقة التي يستخدمها مستوى العرض التقديمي وطبقة البيانات للاتصال ببعضهما البعض ويتضمن الوظائف الأساسية للنظام.
البيانات	طبقة البيانات هي أساسًا الخادم الذي يخزن بيانات التطبيق (على سبيل المثال، خادم يعمل على SQL Server).

تصف طبقات التطبيق التجميعات المنطقية للوظائف والمكونات في التطبيق؛ في حين تصف الطبقات التوزيع الفعلي للوظائف والمكونات على خوادم فعلية منفصلة أو أجهزة كمبيوتر أو شبكات أو مواقع بعيدة. قد تتواجد طبقات التطبيق على نفس الكمبيوتر الفعلي (نفس الطبقة) أو قد يتم توزيعها على أجهزة كمبيوتر منفصلة (n-tier)، وتتصل المكونات في كل طبقة بالمكونات في الطبقات الأخرى من خلال واجهات محددة جيدًا. يمكنك التفكير في طبقة المصطلح كإشارة إلى أنماط التوزيع الفعلية مثل طبقتين ثلاثة طبقات و n-tier. يحتوي نمط التطبيق من طبقتين على طبقتين للتطبيق: خادم التطبيق وخادم قاعدة البيانات. يحدث الاتصال المباشر بين خادم التطبيق وخادم قاعدة البيانات. يحتوي خادم التطبيق على مكونات طبقة الويب وطبقة الأعمال. في نمط تطبيق 3 طبقات "3-tier" ، هناك ثلاثة طبقات التطبيق: خادم ويب، خادم التطبيق، الذي يحتوي على الطبقة المنطقية للأعمال و/أو مكونات الوصول إلى بيانات طبقة الأعمال وخادم قاعدة البيانات. يحدث الاتصال بين خادم الويب وخادم قاعدة البيانات عبر خادم التطبيق. للحصول على معلومات مفصلة حول طبقات التطبيق والمستويات، راجع دليل هندسة تطبيقات Microsoft.

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

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

اختر SQL Server على الأجهزة الظاهرية Azure، عندما:

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

• تحتاج إلى توافق كامل مع SQL Server وتريد نقل التطبيقات الموجودة إلى Azure كما هي.

• تريد الاستفادة من قدرات بيئة Azure ولكن لا تدعم قاعدة بيانات Azure SQL كافة الميزات التي يتطلبها التطبيق الخاص بك. يمكن أن يشمل ذلك المجالات التالية:

  • حجم قاعدة البيانات: في الوقت الذي تم تحديث هذه المقالة فيه، تدعم قاعدة بيانات SQL قاعدة بيانات تصل إلى 1 تيرابايت من البيانات. إذا تطلب التطبيق أكثر من 1 تيرابايت من البيانات ولم تكن تريد تطبيق حلول القطع المخصصة، فيوصى باستخدام SQL Server في جهاز ظاهري Azure. للحصول على أحدث المعلومات، راجع توسيع قاعدة بيانات Azure SQL، وونموذج الشراء المستند إلى وحدة DTU ونموذج الشراء المستند إلى vCore(معاينة).
  • توافق HIPAA: قد يختار عملاء الرعاية الصحية وموردي البرامج المستقلة (ISVs) SQL Server على الأجهزة الظاهرية Azure بدلاً من قاعدة بيانات Azure SQL لأنه يتم تغطية SQL Server على الأجهزة الظاهرية Azure باتفاقية مشارك الأعمال HIPAA (BAA). للحصول على معلومات حول التوافق، راجع مركز توثيق Microsoft Azure: التوافق.
  • ميزات مستوى المثيل: في هذا الوقت، لا تدعم قاعدة بيانات SQL الميزات التي تكون موجودة خارج قاعدة البيانات (مثل الخوادم المرتبطة، وظائف الوكيل، FileStream، وسيط الخدمة، إلخ). لمزيد من المعلومات، راجع إرشادات وقيود قاعدة بيانات Azure SQL.

1-الطبقة (بسيط): جهاز ظاهري واحد

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

نمط التطبيق هذا يكون مفيدًا عندما:

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

يوضح الرسم التخطيطي التالي سيناريو محليًا بسيطًا عن كيفية نشر الحل الممكن للسحابة في جهاز ظاهري واحد في Azure.

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

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

تطبيق من 3 طبقات (بسيط): أجهزة ظاهرية متعددة

في نمط التطبيق بسيطا، يمكنك نشر تطبيق من 3 طبقات في Azure عن طريق وضع كل طبقة تطبيق في جهاز ظاهري مختلف. وهذا يوفر بيئة مرنة لسيناريوهات سهلة لتوسيع النطاق. عندما يحتوي جهاز ظاهري واحد على تطبيق العميل/الويب، يستضيف الجهاز الآخر مكونات العمل الخاصة بك، بينما يستضيف الجهاز الآخر خادم قاعدة البيانات.

نمط التطبيق هذا يكون مفيدًا عندما:

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

يوضح الرسم التخطيطي التالي كيفية وضع تطبيق بسيط من 3 طبقات في Azure عن طريق وضع كل طبقة تطبيق في جهاز ظاهري مختلف.

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

في الرسم التخطيطي، يمكن أن تكون بروتوكولات الإنترنت TCP أو UDP أو HTTP أو HTTPS.

ملاحظة

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

تطبيقات من طبقتين و3 طبقات مع توسيع نطاق مستوى العرض التقديمي

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

نمط التطبيق هذا يكون مفيدًا عندما:

• تريد نقل تطبيقات المؤسسة من الأنظمة الأساسية الظاهرية المحلية إلى الأجهزة الظاهرية Azure.
• تريد توسيع نطاق طبقة العرض التقديمي بسبب زيادة حجم طلبات العملاء الواردة.
• تريد توفير بيئات التطوير والاختبار بسرعة لفترات قصيرة من الزمن.
• كنت ترغب في إجراء اختبار الإجهاد لمستويات حمل العمل متفاوتة ولكن في الوقت نفسه كنت لا تريد امتلاك والحفاظ على العديد من الآلات المادية في كل وقت.
• تريد امتلاك بيئة البنية الأساسية التي يمكن أن تتوسع وتنخفض عند الطلب.

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

أفضل الممارسات لأنماط من طبقتين أو 3 طبقات أو طبقة n تحتوي على عدة أجهزة ظاهرية في طبقة واحد

يوصى بوضع الأجهزة الظاهرية التي تنتمي إلى نفس الطبقة في نفس الخدمة السحابية وفي نفس مجموعة التوفر. على سبيل المثال، ضع مجموعة من خوادم الويب في CloudService1 و AvailabilitySet1 ومجموعة من خوادم قاعدة البيانات في CloudService2 و AvailabilitySet2. تتيح لك مجموعة التوفر في Azure وضع عُقد التوفر العالي في مجالات أخطاء منفصلة وترقية المجالات.

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

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

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

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

أنماط من طبقتين و3 طبقات مع توسيع نطاق طبقة الأعمال

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

نمط التطبيق هذا يكون مفيدًا عندما:

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

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

أنماط من طبقتين أو 3 طبقات مع توسيع نطاق العرض التقديمي والأعمال و HADR

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

نمط التطبيق هذا يكون مفيدًا عندما:

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

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

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

أفضل الممارسات لأنماط التطبيق التي تتطلب SQL HADR

عند إعداد التوفر العالي لـ SQL Server وحلول مواجهة الكوارث في الأجهزة الظاهرية Azure، يلزم إعداد شبكة ظاهرية للأجهزة الظاهرية باستخدام شبكة Azure الظاهرية. سيكون للأجهزة الظاهرية داخل الشبكة الظاهرية عنوان IP خاص مستقر حتى بعد توقف الخدمة، وبالتالي يمكنك تجنب وقت التحديث المطلوب لحل اسم DNS. بالإضافة إلى ذلك، تسمح لك الشبكة الظاهرية بتوسيع الشبكة الداخلية إلى Azure وإنشاء حد أمان موثوق به. على سبيل المثال، إذا كان التطبيق الخاص بك لديه قيود مجال للشركة (مثل مصادقة Windows Active Directory) ، فإن إعداد شبكة Azure الظاهرية ضرورياً.

يحتفظ معظم العملاء الذين يقومون بتشغيل تعليمات برمجية للإنتاج على Azure بالنسخ المتماثلة الأساسية والثانوية في Azure.

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

أنماط من طبقتين و3 طبقات باستخدام الأجهزة الظاهرية Azure والخدمات السحابية

في نمط التطبيق هذا، يمكنك نشر تطبيق من طبقتين أو 3 طبقات إلى Azure باستخدام كلٍ من خدمات Azure السحابية (أدوار الويب والعاملين - النظام الأساسي كخدمة (PaaS)) ووأجهزة Azure الظاهرية (البنية الأساسية كخدمة (IaaS)). استخدام خدمات Azure السحابية لطبقة العرض التقديمي/طبقة الأعمال و SQL Server في الأجهزة الظاهرية Azure لطبقة البيانات مفيداً لمعظم التطبيقات التي تعمل على Azure. والسبب هو أن وجود مثيل حساب يعمل على خدمات السحابة يوفر إدارة سهلة للنشر والمراقبة والتوسيع.

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

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

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

نمط التطبيق هذا يكون مفيدًا عندما:

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

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

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

أسلوب آخر لتطبيق نمط التطبيق هذا هو استخدام دور ويب الموحد الذي يحتوي على كلٍ من طبقة العرض التقديمي ومكونات طبقة الأعمال كما هو موضح في الرسم التخطيطي التالي. يُعد نمط التطبيق هذا مفيدًا للتطبيقات التي تتطلب تصميم stateful. نظرا لأن Azure يوفر عقد حساب عديم الحالة على أدوار ويب والعامل، نوصي بتطبيق منطق لتخزين حالة جلسة العمل باستخدام إحدى التقنيات التالية: التخزين المؤقت لـ Azureأو مخزن جدول Azure أو قاعدة بيانات Azure SQL.

نمط مع الأجهزة الظاهرية Azure وقاعدة بيانات Azure SQL وخدمة تطبيقات Azure (تطبيقات ويب)

الهدف الأساسي من نمط التطبيق هذا هو إظهار كيفية دمج البنية الأساسية Azure كمكونات خدمة (IaaS) مع مكونات النظام الأساسي كخدمة Azure (PaaS) في الحل الخاص بك. يركز هذا النمط على قاعدة بيانات Azure SQL لتخزين البيانات العلائقية. لا تتضمن SQL Server في جهاز ظاهري Azure، والذي يُعد جزءاً من البنية الأساسية لـ Azure كتقديم للخدمة.

في نمط التطبيق هذا، يمكنك نشر تطبيق قاعدة بيانات إلى Azure عن طريق وضع العرض التقديمي وطبقة الأعمال في نفس الجهاز الظاهري والوصول إلى قاعدة بيانات في خوادم قاعدة بيانات Azure SQL (قاعدة بيانات SQL). يمكنك تطبيق طبقة العرض التقديمي باستخدام حلول ويب التقليدية المستندة إلى IIS. أو يمكنك تنفيذ العرض التقديمي المُجمع وطبقة الأعمال باستخدام خدمة التطبيقات Azure App Service.

نمط التطبيق هذا يكون مفيدًا عندما:

• لديك بالفعل خادم قاعدة بيانات SQL موجود تم تكوينه في Azure وتريد اختبار التطبيق الخاص بك بسرعة.
• تريد اختبار قدرات بيئة Azure.
• تريد توفير بيئات التطوير والاختبار بسرعة لفترات قصيرة من الزمن.
• يمكن أن يكون منطق العمل ومكونات الوصول إلى البيانات مكتفياً ذاتياً داخل تطبيق ويب.

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

إذا اخترت تنفيذ طبقة تطبيق وويب مدمجة باستخدام Azure Web Apps، نوصي بالاحتفاظ بالطبقة المتوسطة أو طبقة التطبيقات كمكتبات ارتباط ديناميكية (DLLs) في سياق تطبيق الويب.

بالإضافة إلى ذلك، راجع التوصيات الواردة في قسم مقارنة استراتيجيات تطوير الويب في Azure في نهاية هذه المقالة لمعرفة المزيد حول تقنيات البرمجة.

نمط تطبيق مختلط للطبقة N

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

يُعد نمط التطبيق المختلط هذا مفيداً عندما:

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

يوضح الرسم التخطيطي التالي نمط التطبيق المختلط للطبقة n الذي يمتد عبر الأجهزة المحلية و Azure. كما هو موضح في الرسم التخطيطي، البنية الأساسية المحلية تتضمن وحدة تحكم مجال خدمات مجال Active Directory لدعم مصادقة المستخدم والتخويل. لاحظ أن الرسم التخطيطي يوضح سيناريو، حيث توجد بعض أجزاء طبقة البيانات في مركز بيانات محلي بينما توجد بعض أجزاء طبقة البيانات في Azure. اعتماداً على احتياجات التطبيق الخاص بك، يمكنك تنفيذ العديد من السيناريوهات المختلطة الأخرى. على سبيل المثال، قد تحتفظ بطبقة العرض التقديمي وفئة العمل في بيئة محلية ولكن لطبقة البيانات في Azure.

في Azure، يمكنك استخدام Active Directory كدليل سحابي مستقل لمؤسستك، أو يمكنك أيضاً دمج Active Directory المحلي الحالي مع Azure Active Directory. كما هو الحال في الرسم التخطيطي، يمكن لمكونات طبقة الأعمال الوصول إلى مصادر بيانات متعددة، مثل SQL Server في Azure عبر عنوان IP داخلي خاص، أو SQL Server المحلي عبر شبكة Azure الظاهرية أو قاعدة بيانات SQL باستخدام تقنيات موفر البيانات .NET Framework. في هذا الرسم التخطيطي، تُعد قاعدة بيانات Azure SQL عي خدمة تخزين بيانات اختيارية.

في نمط تطبيق مختلط للطبقة n، يمكنك تنفيذ سير العمل التالي بالترتيب المحدد:

1. تحديد تطبيقات قاعدة بيانات المؤسسة التي تحتاج إلى نقلها إلى السحابة باستخدام مجموعة أدوات التقييم والتخطيط (MAP) من Microsoft. تجمع مجموعة أدوات التقييم والتخطيط (MAP) بيانات الجرد والأداء من أجهزة الكمبيوتر التي تفكر في استخدامها في المحاكاة الافتراضية وتقدم توصيات حول القدرة وتخطيط التقييم.

2. تخطيط الموارد والتكوين المطلوب في النظام الأساسي Azure، مثل حسابات التخزين والأجهزة الظاهرية.

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

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

   2. إنشاء اتصال بين الجهاز المحلي و Azure عبر نفق شبكة Azure الظاهرية (VPN) الخاصة. يسمح لك هذا الأسلوب بتوسيع نهج المجال إلى جهاز ظاهري في Azure. بالإضافة إلى ذلك، يمكنك إعداد قواعد جدار الحماية واستخدام مصادقة Windows في الجهاز الظاهري الخاص بك. حاليا، يدعم Azure اتصالات VPN الآمنة من موقع إلى موقع واتصالات VPN من نقطة إلى موقع:

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

      للحصول على معلومات حول كيفية اتصال SQL Server في Azure، راجع الاتصال إلى جهاز ظاهري SQL Server على Azure.

4. إعداد المهام المجدولة والتنبيهات التي تقوم بعمل نسخة احتياطية من البيانات المحلية في قرص الجهاز الظاهري في Azure. لمزيد من المعلومات، راجع SQL Server Backup and Restore مع Azure Blob Storage والنسخ الاحتياطي والاستعادة لـSQL Server على Azure Virtual Machines.

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

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

مقارنة استراتيجيات تطوير الويب في Azure

لتطبيق ونشر تطبيق متعدد الطبقات يستند إلى SQL Server في Azure، يمكنك استخدام إحدى طريقتي البرمجة التاليتين:

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

يوفر الجدول التالي مقارنة بين تطوير الويب التقليدي وخدمات Azure Cloud وتطبيقات Azure Web Apps فيما يتعلق بـ SQL Server على الأجهزة الظاهرية Azure. يتضمن الجدول Azure Web Apps حيث أنه من الممكن استخدام SQL Server في الجهاز الظاهري Azure كمصدر بيانات لتطبيقات ويب Azure عبر عنوان IP الظاهري العام أو اسم DNS الخاص به.

	تطوير الويب التقليدي في الأجهزة الظاهرية Azure	الخدمات السحابية في Azure	استضافة الويب مع تطبيقات Azure Web Apps
ترحيل الطلبات من الأجهزة المحلية	التطبيقات الموجودة كما هي.	تحتاج التطبيقات إلى أدوار الويب والعامل.	التطبيقات الموجودة كما هي ولكنها مناسبة لتطبيقات الويب وخدمات الويب المكتفية ذاتياً والتي تتطلب قابلية التوسع السريع.
التطوير والنشر	تطبيقات Visual Studio، WebMatrix، Visual Web Developer، WebDeploy، FTP، TFS، IIS Manager، PowerShell.	Visual Studio، Azure SDK، TFS، PowerShell. تحتوي كل خدمة سحابية على بيئتين يمكنك منهما نشر حزمة الخدمة والتكوين: التدريج والإنتاج. يمكنك نشر خدمة سحابية إلى بيئة التجهيز لاختبارها قبل ترقيتها إلى الإنتاج.	تطبيقات Visual Studio، WebMatrix، Visual Web Developer، FTP، GIT، BitBucket، CodePlex، DropBox، GitHub، Mercurial، TFS، Web Deploy، PowerShell.
الإدارة والإعداد	أنت المسؤول عن المهام الإدارية على التطبيق والبيانات وقواعد جدار الحماية والشبكة الظاهرية ونظام التشغيل.	أنت المسؤول عن المهام الإدارية على التطبيق والبيانات وقواعد جدار الحماية والشبكة الظاهرية.	أنت المسؤول عن المهام الإدارية على التطبيق والبيانات فقط.
التوفر العالي ومواجهة الكوارث (HADR)	نوصي بوضع الأجهزة الظاهرية في نفس مجموعة التوفر وفي نفس الخدمة السحابية. يسمح الاحتفاظ بالأجهزة الظاهرية في نفس مجموعة التوفر لـ Azure بوضع عُقد التوفر العالي في مجالات أخطاء منفصلة وترقية المجالات. وبالمثل، فإن الاحتفاظ بالأجهزة الظاهرية في نفس الخدمة السحابية يمكن من موازنة التحميل ويمكن للأجهزة الظاهرية الاتصال مباشرةً مع بعضها البعض عبر الشبكة المحلية داخل مركز بيانات Azure. أنت المسؤول عن تنفيذ حل توفر عالي ومواجهة الكوارث لـ SQL Server على الأجهزة الظاهرية Azure لتجنب أي وقت توقف. للحصول على تقنيات HADR المدعومة، راجع التوفر العالي ومواجهة الكوارث للحصول على SQL Server على الأجهزة الظاهرية Azure. أنت المسؤول عن النسخ الاحتياطي للبيانات الخاصة بك والتطبيق. يمكن لـ Azure نقل الأجهزة الظاهرية إذا فشل الجهاز المضيف في مركز البيانات بسبب مشاكل في الأجهزة. بالإضافة إلى ذلك، قد يكون هناك وقت توقف مخطط للجهاز الظاهري عند تحديث الجهاز المضيف للحصول على تحديثات الأمان أو البرامج. لذلك، نوصي بالاحتفاظ على الأقل بجهازين ظاهرين في كل طبقة للتطبيقات لضمان التوفر المستمر. لا يوفر Azure ميزة SLA لجهاز ظاهري واحد.	يُدير Azure حالات الفشل الناتجة عن الأجهزة الأساسية أو برامج نظام التشغيل. نوصي بتطبيق مثيلات متعددة من دور ويب أو عامل لضمان توفر التطبيق الخاص بك. للحصول على معلومات، راجع الخدمات السحابية والأجهزة الظاهرية واتفاقية مستوى خدمة الشبكة الظاهرية. أنت المسؤول عن النسخ الاحتياطي للبيانات الخاصة بك والتطبيق. لقواعد البيانات الموجودة في قاعدة بيانات SQL Server في الجهاز الظاهري Azure، تكون مسؤولاً عن تنفيذ حل التوفر العالي ومواجهة الكوارث لتجنب أي وقت تعطل. للحصول على تقنيات HDAR المعتمدة، راجع التوفر العالي ومواجهة الكوارث للحصول على SQL Server على الأجهزة الظاهرية Azure. النسخ المتطابق لقاعدة البيانات SQL Server: الاستخدام مع خدمات Azure Cloud (أدوار الويب/العامل). يمكن أن يكون للأجهزة الظاهرية SQL Server ومشروع الخدمة السحابية في نفس الشبكة الظاهرية Azure. إذا لم يكن الجهاز الظاهري SQL Server في نفس الشبكة الظاهرية، تحتاج إلى إنشاء اسم مستعار SQL Server لتوجيه الاتصال إلى مثيل SQL Server. بالإضافة إلى ذلك، يجب أن يتطابق الاسم المستعار مع اسم SQL Server.	يتم توريث التوفر العالي من أدوار العامل Azure ومخزن البيانات الثنائية الكبيرة لـ Azure وقاعدة بيانات Azure SQL. على سبيل المثال، يحتفظ مخزن Azure بثلاث نسخ متماثلة من كافة البيانات الثنائية الكبيرة والجدول وقائمة الانتظار. في أي وقت، تحتفظ قاعدة البيانات Azure SQL بثلاث نسخ متماثلة من البيانات قيد التشغيل- نسخة متماثلة أساسية واحدة ونسختين متماثلتين ثانويتين. لمزيد من المعلومات، راجع تخزين Azure ووقاعدة بيانات Azure SQL. عند استخدام SQL Server في الجهاز الظاهري Azure كمصدر بيانات لتطبيقات ويب Azure، ضع في اعتبارك أن Azure Web Apps لا يدعم الشبكة الظاهرية لـ Azure . وبعبارة أخرى، يجب أن تمر جميع الاتصالات من تطبيقات Azure Web Apps إلى الأجهزة الظاهرية لـ SQL Server في Azure عبر نقاط النهاية العامة للأجهزة الظاهرية. قد يؤدي هذا إلى بعض القيود على التوفر العالي وسيناريوهات مواجهة الكوارث. على سبيل المثال، لن يتمكن تطبيق العميل على تطبيقات Azure Web Apps المتصلة بالجهاز الظاهري لـ SQL Server مع النسخ المتطابق لقاعدة البيانات من الاتصال بالخادم الأساسي الجديد حيث يتطلب نسخ قاعدة البيانات المتطابقة إعداد شبكة Azure الظاهرية بين الأجهزة الظاهرية لمضيف SQL Server في Azure. لذلك، استخدام النسخ المتطابق لقاعدة البياناتSQL Server مع تطبيقات Azure Web Apps غير مدعوم حالياً. مجموعات التوفر قيد التشغيل دوماً لـ SQL Server: يمكنك إعداد مجموعات التوفر دومًا عند استخدام تطبيقات Azure Web Apps مع الأجهزة الظاهرية SQL Server في Azure. ولكن تحتاج إلى تكوين "وحدة إصغاء مجموعة التوفر قيد التشغيل دومًا" لتوجيه الاتصال إلى النسخة المتماثلة الأساسية عبر نقاط النهاية العمومية المتوازنة التحميل.
الاتصال في أماكن متعددة	يمكنك استخدام شبكة Azure الظاهرية للاتصال بشبكة محلية.	يمكنك استخدام شبكة Azure الظاهرية للاتصال بشبكة محلية.	شبكة Azure الظاهرية مدعومة. لمزيد من المعلومات، راجع تكامل الشبكة الظاهرية لتطبيقات ويب.
قابلية التوسع	يتوفر توسيع النطاق عن طريق زيادة أحجام الجهاز الظاهري أو إضافة المزيد من الأقراص. لمزيد من المعلومات حول أحجام الجهاز الظاهري، راجع أحجام الجهاز الظاهري لـ Azure. لخادم قاعدة البيانات: ميزة التوسيع متاحة عبر تقنيات تقسيم قاعدة البيانات ومجموعات التوفر قيد التشغيل دوماً لـ SQL Server. لأحمال عمل القراءة الكثيفة، يمكنك استخدام مجموعات التوفر قيد التشغيل دومًا على عُقد ثانوية متعددة بالإضافة إلى النسخ المتماثل لـ SQL Server. لأحمال عمل الكتابة الكثيفة، يمكنك تطبيق بيانات التقسيم الأفقي عبر خوادم فعلية متعددة لتوفير توسيع التطبيق. بالإضافة إلى ذلك، يمكنك تطبيق التوسيع باستخدام SQL Server مع توجيه البيانات التابعة. مع توجيه البيانات التابعة (DDR) ، تحتاج إلى تنفيذ آلية التقسيم في تطبيق العميل، عادةً يكون في طبقة الأعمال لتوجيه طلبات قاعدة البيانات إلى عُقد SQL Server المتعددة. تحتوي طبقة الأعمال على تعيينات لكيفية تقسيم البيانات والعقدة التي تحتوي على البيانات. يمكنك تغيير حجم التطبيقات التي تقوم بتشغيل الأجهزة الظاهرية عليها. لمزيد من المعلومات، راجع كيفية تغيير حجم تطبيق. ملاحظة هامة: تتيح لك ميزة AutoScale في Azure زيادة أو تقليل حجم الأجهزة الظاهرية التي يستخدمها التطبيق تلقائياً. تضمن هذه الميزة أن تجربة المستخدم النهائي لا تتأثر سلباً أثناء فترات الذروة، ويتم إيقاف تشغيل الأجهزة الظاهرية عندما يكون الطلب منخفضاً. يوصى بعدم تعيين خيار "AutoScale" للخدمة السحابية إذا كان يتضمن الأجهزة الظاهرية SQL Server. والسبب هو أن ميزة AutoScale تُتيح Azure تشغيل جهاز ظاهري عند استخدام المعالج CPU في الجهاز الظاهري هذا أكبر من بعض الحدود، وإيقاف تشغيل جهاز ظاهري عند استخدام معالج CPU يكون أقل منه. ميزة AutoScale مفيدة للتطبيقات عديمة الحالة، مثل خوادم الويب، حيث يمكن لأي جهاز ظاهري إدارة حمل العمل دون أي إشارات إلى أي حالة سابقة. ومع ذلك، ميزة AutoScale غير مفيدة لتطبيقات stateful مثل SQL Server حيث يسمح مثيل واحد فقط بالكتابة في قاعدة البيانات.	تتوفر ميزة التوسيع باستخدام أدوار الويب والعامل المتعددة. لمزيد من المعلومات حول أحجام الجهاز الظاهري لأدوار الويب وأدوار العامل، راجع تكوين أحجام الخدمات السحابية. عند استخدام الخدمات السحابية، يمكنك تحديد أدوار متعددة لتوزيع المعالجة وتحقيق زيادة مرنة في التطبيق. تتضمن كل خدمة سحابية دوراً واحداً أو أكثر على الويب و/أو أدوار العامل، ولكل منها ملفات التطبيقات وتكوينها الخاص. يمكنك توسيع الخدمة السحابية عن طريق زيادة عدد مثيلات الأدوار (الأجهزة الظاهرية) المنشورة لدور وتحجيم الخدمة السحابية عن طريق تقليل عدد مثيلات الدور. للحصول على معلومات مفصلة، راجع نماذج تنفيذ Azure. يتوفر التوسع التدريجي عبر دعم التوفر العالي لـ Azure المضمن من خلال الخدمات السحابية والآلات الظاهرية واتفاقية مستوى خدمة الشبكة الظاهرية وموازنة التحميل. لتطبيق متعدد المستويات، نوصي بتوصيل تطبيق أدوار الويب/العامل بخادم قاعدة بيانات الأجهزة الظاهرية عبر شبكة Azure الظاهرية. بالإضافة إلى ذلك، يوفر Azure موازنة التحميل للأجهزة الظاهرية في نفس الخدمة السحابية، ونشر طلبات المستخدمين عبرها. يمكن للأجهزة الظاهرية المتصلة بهذه الطريقة الاتصال مباشرةً مع بعضها البعض عبر الشبكة المحلية داخل مركز بيانات Azure. يمكنك إعداد AutoScale في مدخل Azure بالإضافة إلى أوقات الجدولة. لمزيد من المعلومات، راجع كيفية تكوين التحجيم التلقائي للخدمة السحابية في المدخل.	توسيع نطاق زيادة/تقليل: يمكنك زيادة / تقليل حجم المثيل للجهاز الظاهري المحجوز لموقع الويب الخاص بك. التوسيع: يمكنك إضافة مثيلات أكثر للأجهزة الظاهرية المحجوزة لموقع الويب الخاص بك. يمكنك إعداد AutoScale في المدخل بالإضافة إلى أوقات الجدولة. لمزيد من المعلومات، راجع كيفية توسيع تطبيقات الويب.

لمزيد من المعلومات حول الاختيار بين أساليب البرمجة هذه، راجع Azure Web Apps، والخدمات السحابية، والأجهزة الظاهرية: عند استخدام أي منها.

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

لمزيد من المعلومات حول تشغيل SQL Server على الأجهزة الظاهرية Azure، راجع SQL Server نظرة عامة على الأجهزة الظاهرية Azure.