Microsoft Azure Architectures for SharePoint 2013
Azure هي بيئة جيدة لاستضافة حل SharePoint Server 2013. في معظم الحالات، نوصي Microsoft 365، ولكن يمكن أن تكون مزرعة SharePoint Server المستضافة في Azure خيارا جيدا لحلول محددة. تصف هذه المقالة كيفية تصميم حلول SharePoint بحيث تكون مناسبة تماما في نظام Azure الأساسي. يتم استخدام الحلين المحددين التاليين كمثالين:
استرداد SharePoint Server 2013 بعد الكوارث في Microsoft Azure
مواقع الإنترنت في Microsoft Azure باستخدام SharePoint Server 2013
حلول SharePoint الموصى بها لخدمات البنية الأساسية ل Azure
تعد خدمات البنية الأساسية ل Azure خيارا مقنعا لاستضافة حلول SharePoint. بعض الحلول مناسبة لهذا النظام الأساسي بشكل أفضل من غيرها. يعرض الجدول التالي الحلول الموصى بها.
| الحل | لماذا يوصى بهذا الحل ل Azure |
|---|---|
| بيئات التطوير والاختبار |
من السهل إنشاء هذه البيئات وإدارتها. |
| التعافي من الكوارث لمزارع SharePoint المحلية إلى Azure |
مركز بيانات ثانوي مستضاف استخدم Azure بدلا من الاستثمار في مركز بيانات ثانوي في منطقة مختلفة. بيئات الإصلاح بعد كارثة منخفضة التكلفة الحفاظ على موارد أقل من بيئة التعافي من الكوارث المحلية ودفع ثمنها. يعتمد عدد الموارد على بيئة التعافي من الكوارث التي تختارها: الاستعداد البارد أو الاستعداد الدافئ أو الاستعداد السريع. نظام أساسي أكثر مرونة في حالة حدوث كارثة، قم بسهولة بتوسيع نطاق مزرعة SharePoint الاسترداد لتلبية متطلبات التحميل. تحجيم عندما لم تعد بحاجة إلى الموارد. راجع SharePoint Server 2013 Disaster Recovery في Microsoft Azure. |
| المواقع التي تواجه الإنترنت والتي تستخدم الميزات والتحجيم غير متوفرة في Microsoft 365 |
تركيز جهودك ركز على بناء موقع رائع بدلا من بناء البنية الأساسية. الاستفادة من المرونة في Azure قم بتحجيم المزرعة للطلب عن طريق إضافة خوادم جديدة، وادفع فقط مقابل الموارد التي تحتاج إليها. تخصيص الجهاز الديناميكي غير معتمد (تغيير الحجم التلقائي). استخدام Azure Active Directory (AD) الاستفادة من Azure AD لحسابات العملاء. إضافة وظائف SharePoint غير متوفرة في Microsoft 365 إضافة تقارير عميقة وتحليلات الويب. راجع مواقع الإنترنت في Microsoft Azure باستخدام SharePoint Server 2013. |
| مزارع التطبيقات لدعم Microsoft 365 أو البيئات المحلية |
إنشاء التطبيقات واختبارها واستضافتها في Azure لدعم كل من البيئات المحلية والسحابية. قم باستضافة هذا الدور في Azure بدلا من شراء أجهزة جديدة للبيئات المحلية. |
بالنسبة إلى حلول وأحمال عمل الإنترانت والتعاون، ضع في اعتبارك الخيارات التالية:
تحديد ما إذا كانت Microsoft 365 تفي بمتطلبات عملك أو يمكن أن تكون جزءا من الحل. يوفر Microsoft 365 مجموعة ميزات غنية محدثة دائما.
إذا لم يستوف Microsoft 365 جميع متطلبات عملك، ففكر في تنفيذ قياسي SharePoint 2013 محليا من خدمات Microsoft الاستشارية (MCS). يمكن أن تكون البنية القياسية حلا أسرع وأرخص وأسهل لدعمه من الحل المخصص.
إذا لم يفي التنفيذ القياسي بمتطلبات عملك، ففكر في حل محلي مخصص.
إذا كان استخدام النظام الأساسي السحابي مهما لمتطلبات عملك، ففكر في تنفيذ قياسي أو مخصص SharePoint 2013 المستضاف في خدمات البنية الأساسية ل Azure. SharePoint الحلول أسهل بكثير في دعمها في Azure من الأنظمة الأساسية السحابية العامة الأخرى غير الأصلية ل Microsoft.
قبل تصميم بيئة Azure
بينما تستخدم هذه المقالة مثالا SharePoint طبولوجيا، يمكنك استخدام مفاهيم التصميم هذه مع أي طوبولوجيا مزرعة SharePoint. قبل تصميم بيئة Azure، استخدم إرشادات الطبولوجيا والبنية والسعة والأداء التالية لتصميم مزرعة SharePoint:
تحديد نوع مجال Active Directory
تعتمد كل مزرعة SharePoint Server على Active Directory لتوفير حسابات إدارية لإعداد المزرعة. في هذا الوقت، هناك خياران للحلول SharePoint في Azure. يتم وصفها في الجدول التالي.
| الخيار | الوصف |
|---|---|
| مجال مخصص |
يمكنك نشر مجال Active Directory مخصص ومعزول إلى Azure لدعم مزرعة SharePoint. يعد هذا خيارا جيدا لمواقع الإنترنت ذات الواجهة العامة. |
| توسيع المجال المحلي من خلال اتصال داخلي |
عند توسيع المجال المحلي من خلال اتصال داخلي، يصل المستخدمون إلى مزرعة SharePoint عبر إنترانت كما لو كانت مستضافة محليا. يمكنك الاستفادة من تنفيذ Active Directory محلي وDNS. مطلوب اتصال عبر أماكن العمل لبناء بيئة استرداد البيانات بعد الكوارث في Azure للفشل من المزرعة المحلية الخاصة بك. |
تتضمن هذه المقالة مفاهيم التصميم لتوسيع المجال المحلي من خلال اتصال داخلي. إذا كان الحل الخاص بك يستخدم مجالا مخصصا، فلن تحتاج إلى اتصال داخلي.
تصميم الشبكة الظاهرية
تحتاج أولا إلى شبكة ظاهرية في Azure، والتي تتضمن الشبكات الفرعية التي ستضع عليها أجهزتك الظاهرية. تحتاج الشبكة الظاهرية إلى مساحة عنوان IP خاصة، والتي تقوم بتعيين أجزاء منها إلى الشبكات الفرعية.
إذا كنت تقوم بتوسيع شبكتك المحلية إلى Azure من خلال اتصال داخلي (مطلوب لبيئة استرداد البيانات بعد الكوارث)، يجب اختيار مساحة عنوان خاصة غير مستخدمة بالفعل في مكان آخر في شبكة مؤسستك، والتي يمكن أن تتضمن البيئة المحلية وشبكات Azure الظاهرية الأخرى.
الشكل 1: البيئة المحلية مع شبكة ظاهرية في Azure
في هذا الرسم التخطيطي:
يتم توضيح شبكة ظاهرية في Azure جنبا إلى جنب مع البيئة المحلية. لم يتم بعد توصيل البيئتين باتصال داخلي، والذي يمكن أن يكون اتصال VPN من موقع إلى موقع أو ExpressRoute.
في هذه المرحلة، تتضمن الشبكة الظاهرية فقط الشبكات الفرعية ولا تتضمن أي عناصر معمارية أخرى. ستستضيف إحدى الشبكات الفرعية بوابة Azure وتستضيف الشبكات الفرعية الأخرى مستويات مزرعة SharePoint، مع شبكة فرعية إضافية ل Active Directory وDNS.
إضافة اتصال عبر أماكن العمل
خطوة النشر التالية هي إنشاء اتصال داخلي (إذا كان هذا ينطبق على الحل الخاص بك). بالنسبة إلى الاتصالات الداخلية، توجد بوابة Azure في شبكة فرعية منفصلة للبوابة، والتي يجب عليك إنشاؤها وتعيين مساحة عنوان لها.
عند التخطيط لاتصال داخلي، يمكنك تحديد وإنشاء بوابة Azure والاتصال بجهاز بوابة محلي.
الشكل 2: استخدام بوابة Azure وجهاز بوابة محلي لتوفير اتصال من موقع إلى موقع بين البيئة المحلية وAzure
في هذا الرسم التخطيطي:
إضافة إلى الرسم التخطيطي السابق، يتم توصيل البيئة المحلية بشبكة Azure الظاهرية من خلال اتصال داخلي، والذي يمكن أن يكون اتصال VPN من موقع إلى موقع أو ExpressRoute.
توجد بوابة Azure على شبكة فرعية للبوابة.
تتضمن البيئة المحلية جهاز بوابة، مثل جهاز توجيه أو خادم VPN.
للحصول على معلومات إضافية للتخطيط لشبكة ظاهرية مشتركة وإنشاءها، راجع الاتصال شبكة محلية إلى شبكة Microsoft Azure الظاهرية.
إضافة خدمات مجال Active Directory (AD DS) وDNS
للتعافي من الكوارث في Azure، يمكنك نشر Windows Server AD وDNS في سيناريو مختلط حيث يتم نشر Windows Server AD في كل من الأجهزة الظاهرية المحلية وعلى أجهزة Azure الظاهرية.
الشكل 3: تكوين مجال Hybrid Active Directory
يعتمد هذا الرسم التخطيطي على الرسومات التخطيطية السابقة عن طريق إضافة جهازين ظاهريين إلى Windows Server AD والشبكة الفرعية DNS. هذه الأجهزة الظاهرية هي وحدات تحكم مجال النسخ المتماثلة وخوادم DNS. وهي امتداد لبيئة Windows Server AD المحلية.
يوفر الجدول التالي توصيات التكوين لهذه الأجهزة الظاهرية في Azure. استخدم هذه كنقطة بداية لتصميم بيئتك الخاصة — حتى بالنسبة إلى مجال مخصص حيث لا تتواصل بيئة Azure الخاصة بك مع البيئة المحلية الخاصة بك.
| البند | التكوين |
|---|---|
| حجم الجهاز الظاهري في Azure |
حجم A1 أو A2 في المستوى القياسي |
| نظام التشغيل |
Windows Server 2012 R2 |
| دور Active Directory |
وحدة تحكم مجال AD DS المعينة كخادم كتالوج عمومي. يقلل هذا التكوين من نسبة استخدام الشبكة الصادرة عبر الاتصال الداخلي. في بيئة متعددة المجالات ذات معدلات تغيير عالية (هذا غير شائع)، قم بتكوين وحدات التحكم بالمجال محليا لعدم المزامنة مع خوادم الكتالوج العمومية في Azure، لتقليل نسبة استخدام الشبكة للنسخ المتماثل. |
| دور DNS |
تثبيت وتكوين خدمة خادم DNS على وحدات التحكم بالمجال. |
| أقراص البيانات |
ضع قاعدة بيانات Active Directory والسجلات وSYSVOL على أقراص بيانات Azure إضافية. لا تضعها على قرص نظام التشغيل أو الأقراص المؤقتة التي يوفرها Azure. |
| عناوين IP |
استخدم عناوين IP الثابتة وقم بتكوين الشبكة الظاهرية لتعيين هذه العناوين إلى الأجهزة الظاهرية في الشبكة الظاهرية بعد تكوين وحدات التحكم بالمجال. |
هام
قبل نشر Active Directory في Azure، اقرأ إرشادات نشر Windows Server Active Directory على أجهزة Azure الظاهرية. تساعدك هذه في تحديد ما إذا كانت هناك حاجة إلى بنية مختلفة أو إعدادات تكوين مختلفة للحل الخاص بك.
إضافة مزرعة SharePoint
ضع الأجهزة الظاهرية لمزرعة SharePoint في طبقات على الشبكات الفرعية المناسبة.
الشكل 4: وضع الأجهزة الظاهرية SharePoint
يعتمد هذا الرسم التخطيطي على الرسومات التخطيطية السابقة عن طريق إضافة أدوار خادم المزرعة SharePoint في مستوياتها الخاصة.
جهازان ظاهريان لقاعدة البيانات يعملان SQL Server إنشاء مستوى قاعدة البيانات.
جهازان ظاهريان يعملان SharePoint Server 2013 لكل مستوى من المستويات التالية: خوادم الواجهة الأمامية وخوادم ذاكرة التخزين المؤقت الموزعة والخوادم الخلفية.
تصميم أدوار الخادم وضبطها لمجموعات التوفر ومجالات الخطأ
مجال الخطأ هو تجميع الأجهزة التي تعمل فيها مثيلات الدور. يمكن تحديث الأجهزة الظاهرية داخل نفس مجال الخطأ بواسطة البنية الأساسية ل Azure في نفس الوقت. أو، يمكن أن تفشل في نفس الوقت لأنها تشترك في نفس الرف. لتجنب خطر وجود جهازين ظاهريين على نفس مجال الخطأ، يمكنك تكوين الأجهزة الظاهرية كمجموعة توفر، ما يضمن أن كل جهاز ظاهري في مجال خطأ مختلف. إذا تم تكوين ثلاثة أجهزة ظاهرية كمجموعة توفر، يضمن Azure عدم وجود أكثر من جهازين ظاهريين في نفس مجال الخطأ.
عند تصميم بنية Azure لمزرعة SharePoint، قم بتكوين أدوار خادم متطابقة لتكون جزءا من مجموعة توفر. وهذا يضمن انتشار أجهزتك الظاهرية عبر مجالات خطأ متعددة.
الشكل 5: استخدام مجموعات توفر Azure لتوفير قابلية وصول عالية لمستويات مزرعة SharePoint
يستدعي هذا الرسم التخطيطي تكوين مجموعات التوفر داخل البنية الأساسية ل Azure. يشترك كل من الأدوار التالية في مجموعة توفر منفصلة:
Active Directory وDNS
Database
النهاية الخلفية
توزيع ذاكرة التخزين المؤقت
الواجهة الأمامية
قد تحتاج مزرعة SharePoint إلى ضبطها بدقة في النظام الأساسي ل Azure. لضمان قابلية وصول عالية لجميع المكونات، تأكد من تكوين جميع أدوار الخادم بشكل متطابق.
فيما يلي مثال يوضح بنية مواقع إنترنت القياسية التي تلبي أهداف أداء وسعة محددة. يظهر هذا المثال في نموذج البنية التالي: بنيات البحث في مواقع الإنترنت لخادم SharePoint 2013.
الشكل 6: مثال التخطيط لأهداف السعة والأداء في مزرعة من ثلاثة مستويات
في هذا الرسم التخطيطي:
يتم تمثيل مزرعة ثلاثية المستويات: خوادم الويب وخوادم التطبيقات وخوادم قواعد البيانات.
يتم تكوين خوادم الويب الثلاثة بشكل متطابق مع مكونات متعددة.
يتم تكوين خادمي قاعدة البيانات بشكل مماثل.
لم يتم تكوين خوادم التطبيقات الثلاثة بشكل مماثل. تتطلب أدوار الخادم هذه ضبطا دقيقا لمجموعات التوفر في Azure.
لنلق نظرة فاحصة على مستوى خادم التطبيق.
الشكل 7: مستوى خادم التطبيق قبل الضبط الدقيق
في هذا الرسم التخطيطي:
يتم تضمين ثلاثة خوادم في مستوى التطبيق.
يتضمن الخادم الأول أربعة مكونات.
يتضمن الخادم الثاني ثلاثة مكونات.
يتضمن الخادم الثالث مكونين.
يمكنك تحديد عدد المكونات حسب أهداف الأداء والسعة للمزرعة. لتكييف هذه البنية ل Azure، سنقوم بنسخ المكونات الأربعة عبر جميع الخوادم الثلاثة. وهذا يزيد من عدد المكونات التي تتجاوز ما هو ضروري للأداء والقدرة. المفاضلة هي أن هذا التصميم يضمن قابلية وصول عالية لجميع المكونات الأربعة في النظام الأساسي ل Azure عند تعيين هذه الأجهزة الظاهرية الثلاثة إلى مجموعة توفر.
الشكل 8: مستوى خادم التطبيق بعد الضبط الدقيق
يوضح هذا الرسم التخطيطي كافة خوادم التطبيقات الثلاثة التي تم تكوينها بشكل متطابق مع المكونات الأربعة نفسها.
عندما نضيف مجموعات التوفر إلى مستويات مزرعة SharePoint، يكتمل التنفيذ.
الشكل 9: مزرعة SharePoint المكتملة في خدمات البنية الأساسية ل Azure
يوضح هذا الرسم التخطيطي مزرعة SharePoint التي تم تنفيذها في خدمات البنية الأساسية ل Azure، مع مجموعات التوفر لتوفير مجالات الخطأ للخوادم في كل مستوى.
انظر أيضاً
مركز الحلول والهندسة من Microsoft 365
مواقع الإنترنت في Microsoft Azure باستخدام SharePoint Server 2013
استرداد SharePoint Server 2013 بعد الكوارث في Microsoft Azure
الملاحظات
إرسال الملاحظات وعرضها المتعلقة بـ