استرداد SharePoint Server 2013 بعد الكوارث في Microsoft Azure
باستخدام Azure، يمكنك إنشاء بيئة الإصلاح بعد كارثة لمزرعة SharePoint المحلية. توضح هذه المقالة كيفية تصميم هذا الحل وتنفيذه.
شاهد فيديو نظرة عامة على الإصلاح بعد كارثة ل SharePoint Server 2013
عندما تصيب الكوارث بيئة SharePoint المحلية، فإن أولويتك القصوى هي تشغيل النظام مرة أخرى بسرعة. يكون الإصلاح بعد كارثة باستخدام SharePoint أسرع وأسهل عندما يكون لديك بيئة نسخ احتياطي قيد التشغيل بالفعل في Microsoft Azure. يشرح هذا الفيديو المفاهيم الرئيسية لبيئة تجاوز الفشل الدافئ ل SharePoint ويكمل التفاصيل الكاملة المتوفرة في هذه المقالة.
استخدم هذه المقالة مع نموذج الحل التالي: الإصلاح بعد كارثة ل SharePoint في Microsoft Azure.
استخدام خدمات البنية الأساسية ل Azure للإصلاح بعد كارثة
لا تمتلك العديد من المؤسسات بيئة الإصلاح بعد كارثة ل SharePoint، والتي قد تكون مكلفة في الإنشاء والصيانة محليا. توفر Azure Infrastructure Services خيارات مقنعة لبيئات الإصلاح بعد كارثة الأكثر مرونة وأقل تكلفة من البدائل المحلية.
تتضمن مزايا استخدام Azure Infrastructure Services ما يلي:
موارد أقل تكلفة الحفاظ على موارد أقل من بيئات الإصلاح بعد كارثة المحلية ودفع ثمنها. يعتمد عدد الموارد على بيئة التعافي من الكوارث التي تختارها: الاستعداد البارد أو الاستعداد الدافئ أو الاستعداد السريع.
مرونة أفضل في الموارد في حالة حدوث كارثة، يمكنك بسهولة توسيع نطاق مزرعة SharePoint للاسترداد لتلبية متطلبات التحميل. قم بتوسيع النطاق عندما لم تعد بحاجة إلى الموارد.
التزام أقل لمركز البيانات استخدم Azure Infrastructure Services بدلا من الاستثمار في مركز بيانات ثانوي في منطقة مختلفة.
هناك خيارات أقل تعقيدا للمؤسسات التي بدأت للتو في الإصلاح بعد كارثة وخيارات متقدمة للمؤسسات ذات المتطلبات عالية المرونة. تختلف تعريفات بيئات الاستعداد الباردة والحارة والساخنة قليلا عند استضافة البيئة على نظام أساسي سحابي. يصف الجدول التالي هذه البيئات لإنشاء مزرعة استرداد SharePoint في Azure.
الجدول: بيئات الاسترداد
| نوع بيئة الاسترداد | الوصف |
|---|---|
| الساخنه | يتم توفير مزرعة بحجم كامل وتحديثها وتشغيلها في وضع الاستعداد. |
| الدافئه | تم إنشاء المزرعة ويتم تشغيل الأجهزة الظاهرية وتحديثها. يتضمن الاسترداد إرفاق قواعد بيانات المحتوى، وتوفير تطبيقات الخدمة، ومحتوى تتبع الارتباطات. يمكن أن تكون المزرعة نسخة أصغر من مزرعة الإنتاج ثم يتم توسيع نطاقها لخدمة قاعدة المستخدمين الكاملة. |
| البارده | تم بناء المزرعة بالكامل، ولكن يتم إيقاف الأجهزة الظاهرية. يتضمن الحفاظ على البيئة بدء تشغيل الأجهزة الظاهرية من وقت لآخر، وتصحيح البيئة وتحديثها والتحقق منها. ابدأ البيئة الكاملة في حالة وقوع كارثة. |
من المهم تقييم أهداف وقت الاسترداد (RTOs) وأهداف نقطة الاسترداد (RPOs) الخاصة بمؤسستك. تحدد هذه المتطلبات البيئة الأنسب لمؤسستك.
توضح الإرشادات الواردة في هذه المقالة كيفية تنفيذ بيئة الاستعداد الدافئة. يمكنك أيضا تكييفه مع بيئة الاستعداد الباردة، على الرغم من أنك بحاجة إلى اتباع إجراءات إضافية لدعم هذا النوع من البيئة. لا تصف هذه المقالة كيفية تنفيذ بيئة الاستعداد السريع.
لمزيد من المعلومات حول حلول الإصلاح بعد كارثة، راجع مفاهيم قابلية الوصول العالية والإصلاح بعد كارثة في SharePoint 2013واختر استراتيجية الإصلاح بعد كارثة ل SharePoint 2013.
وصف الحل
يتطلب حل التعافي من الكوارث في وضع الاستعداد الدافئ البيئة التالية:
مزرعة إنتاج SharePoint محلية
مزرعة SharePoint للاسترداد في Azure
اتصال VPN من موقع إلى موقع بين البيئتين
يوضح الشكل التالي هذه العناصر الثلاثة.
الشكل: عناصر حل الاستعداد الدافئ في Azure
SQL Server يتم استخدام شحن السجل باستخدام النسخ المتماثل لنظام الملفات الموزعة (DFSR) لنسخ النسخ الاحتياطية لقاعدة البيانات وسجلات المعاملات إلى مزرعة الاسترداد في Azure:
ينقل DFSR السجلات من بيئة الإنتاج إلى بيئة الاسترداد. في سيناريو WAN، يكون DFSR أكثر كفاءة من شحن السجلات مباشرة إلى الخادم الثانوي في Azure.
تتم إعادة تشغيل السجلات إلى SQL Server في بيئة الاسترداد في Azure.
لا تقوم بإرفاق قواعد بيانات محتوى SharePoint المشحونة بالسجل في بيئة الاسترداد حتى يتم تنفيذ تمرين الاسترداد.
نفذ الخطوات التالية لاسترداد المزرعة:
إيقاف شحن السجل.
توقف عن قبول نسبة استخدام الشبكة إلى المزرعة الأساسية.
أعد تشغيل سجلات المعاملات النهائية.
إرفاق قواعد بيانات المحتوى بالمزرعة.
استعادة تطبيقات الخدمة من قواعد بيانات الخدمات المنسوخة نسخا متماثلا.
تحديث سجلات نظام أسماء المجالات (DNS) للإشارة إلى مزرعة الاسترداد.
بدء تتبع ارتباطات كامل.
نوصيك بالتمرين على هذه الخطوات بانتظام وتوثيقها للمساعدة في ضمان تشغيل الاسترداد المباشر بسلاسة. قد يستغرق إرفاق قواعد بيانات المحتوى واستعادة تطبيقات الخدمة بعض الوقت ويتضمن عادة بعض التكوين اليدوي.
بعد إجراء الاسترداد، يوفر هذا الحل العناصر المدرجة في الجدول التالي.
الجدول: أهداف استرداد الحل
| البند | الوصف |
|---|---|
| المواقع والمحتوى | تتوفر المواقع والمحتوى في بيئة الاسترداد. |
| مثيل جديد للبحث | في حل الاستعداد الدافئ هذا، لا تتم استعادة البحث من قواعد بيانات البحث. يتم تكوين مكونات البحث في مزرعة الاسترداد بنفس الطريقة الممكنة لمزرعة الإنتاج. بعد استعادة المواقع والمحتوى، يتم بدء تتبع ارتباطات كامل لإعادة إنشاء فهرس البحث. لا تحتاج إلى الانتظار حتى يكتمل التسجيل في الفهرس لتوفير المواقع والمحتوى. |
| خدمات | تتم استعادة الخدمات التي تخزن البيانات في قواعد البيانات من قواعد البيانات المشحونة بالسجل. يتم ببساطة بدء تشغيل الخدمات التي لا تخزن البيانات في قواعد البيانات. لا يلزم استعادة جميع الخدمات التي لها قواعد بيانات. لا تحتاج الخدمات التالية إلى استعادتها من قواعد البيانات ويمكن ببساطة البدء بعد تجاوز الفشل: جمع بيانات الاستخدام والصحة خدمة الحالة أتمتة Word أي خدمة أخرى لا تستخدم قاعدة بيانات |
يمكنك العمل مع Microsoft Consulting Services (MCS) أو شريك لمعالجة أهداف الاسترداد الأكثر تعقيدا. يتم تلخيصها في الجدول التالي.
الجدول: العناصر الأخرى التي يمكن معالجتها بواسطة MCS أو شريك
| البند | الوصف |
|---|---|
| مزامنة حلول المزرعة المخصصة | من الناحية المثالية، يكون تكوين مزرعة الاسترداد مطابقا لمزرعة الإنتاج. يمكنك العمل مع مستشار أو شريك لتقييم ما إذا كان يتم نسخ حلول المزرعة المخصصة وما إذا كانت العملية في مكانها للحفاظ على مزامنة البيئتين. |
| الاتصالات بمصادر البيانات المحلية | قد لا يكون من العملي نسخ الاتصالات نسخا متماثلا إلى أنظمة البيانات الخلفية، مثل اتصالات وحدة تحكم مجال النسخ الاحتياطي (BDC) ومصادر محتوى البحث. |
| سيناريوهات استعادة البحث | نظرا لأن عمليات توزيع البحث في المؤسسة تميل إلى أن تكون فريدة ومعقدة إلى حد ما، فإن استعادة البحث من قواعد البيانات تتطلب استثمارا أكبر. يمكنك العمل مع مستشار أو شريك لتحديد وتنفيذ سيناريوهات استعادة البحث التي قد تتطلبها مؤسستك. |
تفترض الإرشادات الواردة في هذه المقالة أن المزرعة المحلية قد تم تصميمها ونشرها بالفعل.
بنية مفصلة
من الناحية المثالية، يكون تكوين مزرعة الاسترداد في Azure مطابقا لمزرعة الإنتاج المحلية، بما في ذلك ما يلي:
نفس تمثيل أدوار الخادم
نفس تكوين التخصيصات
نفس تكوين مكونات البحث
يمكن أن تكون البيئة في Azure إصدارا أصغر من مزرعة الإنتاج. إذا كنت تخطط لتوسيع نطاق مزرعة الاسترداد بعد تجاوز الفشل، فمن المهم أن يتم تمثيل كل نوع من أنواع دور الخادم في البداية.
قد لا تكون بعض التكوينات عملية للنسخ المتماثل في بيئة تجاوز الفشل. تأكد من اختبار إجراءات تجاوز الفشل والبيئة للمساعدة في التأكد من أن مزرعة تجاوز الفشل توفر مستوى الخدمة المتوقع.
لا يصف هذا الحل طبولوجيا معينة لمزرعة SharePoint. ينصب تركيز هذا الحل على استخدام Azure لمزرعة تجاوز الفشل وتنفيذ شحن السجل وDFSR بين البيئتين.
بيئات الاستعداد الدافئة
في بيئة الاستعداد الدافئة، يتم تشغيل جميع الأجهزة الظاهرية في بيئة Azure. البيئة جاهزة لتمرين أو حدث تجاوز الفشل.
يوضح الشكل التالي حل الإصلاح بعد كارثة من مزرعة SharePoint محلية إلى مزرعة SharePoint مستندة إلى Azure تم تكوينها كبيئة الاستعداد الدافئة.
الشكل: الطوبولوجيا والعناصر الرئيسية لمزرعة إنتاج ومزرعة استرداد احتياطية دافئة
في هذا الرسم التخطيطي:
يتم توضيح بيئتين جنبا إلى جنب: مزرعة SharePoint المحلية ومزرعة الاستعداد الدافئة في Azure.
تتضمن كل بيئة مشاركة ملف.
تتضمن كل مزرعة أربعة مستويات. لتحقيق قابلية وصول عالية، يتضمن كل مستوى خادمين أو جهازين ظاهريين تم تكوينهما بشكل متطابق لدور معين، مثل خدمات الواجهة الأمامية وذاكرة التخزين المؤقت الموزعة والخدمات الخلفية وقواعد البيانات. ليس من المهم في هذا الرسم التوضيحي استدعاء مكونات محددة. يتم تكوين المزرعةين بشكل متطابق.
الطبقة الرابعة هي طبقة قاعدة البيانات. يتم استخدام شحن السجل لنسخ السجلات من خادم قاعدة البيانات الثانوي في البيئة المحلية إلى مشاركة الملف في نفس البيئة.
ينسخ DFSR الملفات من مشاركة الملف في البيئة المحلية إلى مشاركة الملف في بيئة Azure.
يعيد شحن السجل تشغيل السجلات من مشاركة الملف في بيئة Azure إلى النسخة المتماثلة الأساسية في مجموعة توفر SQL Server AlwaysOn في بيئة الاسترداد.
بيئات الاستعداد الباردة
في بيئة الاستعداد الباردة، يمكن إيقاف تشغيل معظم الأجهزة الظاهرية لمزرعة SharePoint. (نوصي أحيانا ببدء تشغيل الأجهزة الظاهرية، مثل كل أسبوعين أو مرة واحدة في الشهر، بحيث يمكن لكل جهاز ظاهري المزامنة مع المجال.) يجب أن تظل الأجهزة الظاهرية التالية في بيئة استرداد Azure قيد التشغيل للمساعدة في ضمان العمليات المستمرة لشحن السجل وDFSR:
مشاركة الملف
خادم قاعدة البيانات الأساسي
جهاز ظاهري واحد على الأقل يقوم بتشغيل Windows Server خدمات مجال Active Directory وDNS
يوضح الشكل التالي بيئة تجاوز فشل Azure التي يتم فيها تشغيل الجهاز الظاهري لمشاركة الملف والجهاز الظاهري الأساسي لقاعدة بيانات SharePoint. يتم إيقاف جميع أجهزة SharePoint الظاهرية الأخرى. لا يظهر الجهاز الظاهري الذي يقوم بتشغيل Windows Server Active Directory وDNS.
الشكل: مزرعة استرداد الاستعداد البارد مع الأجهزة الظاهرية قيد التشغيل
بعد تجاوز الفشل إلى بيئة الاستعداد الباردة، يتم بدء تشغيل جميع الأجهزة الظاهرية، ويجب تكوين أسلوب تحقيق قابلية وصول عالية لخوادم قاعدة البيانات، مثل SQL Server مجموعات قابلية وصول عالية التوفر AlwaysOn.
إذا تم تنفيذ مجموعات تخزين متعددة (تنتشر قواعد البيانات عبر أكثر من SQL Server مجموعة قابلية وصول عالية)، يجب تشغيل قاعدة البيانات الأساسية لكل مجموعة تخزين لقبول السجلات المقترنة بمجموعة التخزين الخاصة بها.
المهارات والخبرة
يتم استخدام تقنيات متعددة في حل الإصلاح بعد كارثة هذا. للمساعدة في ضمان تفاعل هذه التقنيات كما هو متوقع، يجب تثبيت كل مكون في البيئة المحلية وبيئة Azure وتكوينه بشكل صحيح. نوصي بأن يتمتع الشخص أو الفريق الذي يقوم بإعداد هذا الحل بمعرفة عملية قوية ومهارات عملية باستخدام التقنيات الموضحة في المقالات التالية:
وأخيرا، نوصي بمهارات البرمجة النصية التي يمكنك استخدامها لأتمتة المهام المرتبطة بهذه التقنيات. من الممكن استخدام واجهات المستخدم المتوفرة لإكمال جميع المهام الموضحة في هذا الحل. ومع ذلك، يمكن أن يستغرق النهج اليدوي وقتا طويلا وعرضة للخطأ ويقدم نتائج غير متسقة.
بالإضافة إلى Windows PowerShell، هناك أيضا مكتبات Windows PowerShell SQL Server وSharePoint Server وAzure. لا تنس T-SQL، والتي يمكن أن تساعد أيضا في تقليل الوقت لتكوين بيئة الإصلاح بعد كارثة وصيانتها.
مخطط الإصلاح بعد كارثة
تفترض خارطة الطريق هذه أن لديك بالفعل مزرعة SharePoint Server 2013 تم نشرها في الإنتاج.
جدول: خارطة طريق للإصلاح بعد كارثة
| المرحله | الوصف |
|---|---|
| المرحلة الأولى | تصميم بيئة الإصلاح بعد كارثة. |
| المرحلة 2 | إنشاء شبكة Azure الظاهرية واتصال VPN. |
| المرحلة الثالثة | توزيع Windows Active Directory وخدمات اسم المجال إلى شبكة Azure الظاهرية. |
| المرحلة الرابعة | نشر مزرعة استرداد SharePoint في Azure. |
| المرحلة 5 | إعداد DFSR بين المزارع. |
| المرحلة السادسة | إعداد شحن السجل إلى مزرعة الاسترداد. |
| المرحلة السابعة | التحقق من صحة حلول تجاوز الفشل والاسترداد. ويشمل ذلك الإجراءات والتقنيات التالية: إيقاف شحن السجل. استعادة النسخ الاحتياطية. محتوى تتبع الارتباطات. خدمات الاسترداد. إدارة سجلات DNS. |
المرحلة 1: تصميم بيئة التعافي من الكوارث
استخدم الإرشادات الواردة في Microsoft Azure Architectures ل SharePoint 2013 لتصميم بيئة الإصلاح بعد كارثة، بما في ذلك مزرعة استرداد SharePoint. يمكنك استخدام الرسومات في حل الإصلاح بعد كارثة ل SharePoint في ملف Azure Visio لبدء عملية التصميم. نوصي بتصميم البيئة بأكملها قبل بدء أي عمل في بيئة Azure.
بالإضافة إلى الإرشادات المتوفرة في Microsoft Azure Architectures ل SharePoint 2013 لتصميم الشبكة الظاهرية واتصال VPN وActive Directory ومزرعة SharePoint، تأكد من إضافة دور مشاركة ملف إلى بيئة Azure.
لدعم شحن السجل في حل الإصلاح بعد كارثة، تتم إضافة جهاز ظاهري لمشاركة الملفات إلى الشبكة الفرعية حيث توجد أدوار قاعدة البيانات. تعمل مشاركة الملف أيضا كعقدة ثالثة من Node Majority لمجموعة توفر SQL Server AlwaysOn. هذا هو التكوين الموصى به لمزرعة SharePoint قياسية تستخدم مجموعات توفر SQL Server AlwaysOn.
ملاحظة
من المهم مراجعة المتطلبات الأساسية لقاعدة البيانات للمشاركة في مجموعة توفر SQL Server AlwaysOn. لمزيد من المعلومات، راجع المتطلبات الأساسية والقيود والتوصيات لمجموعات قابلية وصول عالية التوفر AlwaysOn.
الشكل: موضع خادم ملفات يستخدم لحل الإصلاح بعد كارثة
في هذا الرسم التخطيطي، تتم إضافة جهاز ظاهري لمشاركة ملف إلى نفس الشبكة الفرعية في Azure التي تحتوي على أدوار خادم قاعدة البيانات. لا تقم بإضافة الجهاز الظاهري لمشاركة الملف إلى مجموعة توفر مع أدوار الخادم الأخرى، مثل أدوار SQL Server.
إذا كنت قلقا بشأن قابلية الوصول العالية للسجلات، ففكر في اتباع نهج مختلف باستخدام SQL Server النسخ الاحتياطي والاستعادة باستخدام Azure Blob Storage Service. هذه ميزة جديدة في Azure تحفظ السجلات مباشرة إلى عنوان URL لتخزين كائن ثنائي كبير الحجم. لا يتضمن هذا الحل إرشادات حول استخدام هذه الميزة.
عند تصميم مزرعة الاسترداد، ضع في اعتبارك أن بيئة الإصلاح بعد كارثة الناجحة تعكس بدقة مزرعة الإنتاج التي تريد استردادها. حجم مزرعة الاسترداد ليس أهم شيء في تصميم مزرعة الاسترداد ونشرها واختبارها. يختلف نطاق المزرعة من مؤسسة إلى أخرى بناء على متطلبات العمل. قد يكون من الممكن استخدام مزرعة متدرجة لفترة انقطاع قصيرة أو حتى تتطلب منك متطلبات الأداء والسعة توسيع نطاق المزرعة.
قم بتكوين مزرعة الاسترداد بشكل مماثل قدر الإمكان لمزرعة الإنتاج بحيث تفي بمتطلبات اتفاقية مستوى الخدمة (SLA) وتوفر الوظائف التي تحتاجها لدعم عملك. عند تصميم بيئة الإصلاح بعد كارثة، انظر أيضا إلى عملية إدارة التغيير لبيئة الإنتاج الخاصة بك. نوصي بتوسيع عملية إدارة التغيير إلى بيئة الاسترداد عن طريق تحديث بيئة الاسترداد في نفس الفاصل الزمني مثل بيئة الإنتاج. كجزء من عملية إدارة التغيير، نوصي بالاحتفاظ بمخزون مفصل لتكوين المزرعة والتطبيقات والمستخدمين.
المرحلة 2: إنشاء شبكة Azure الظاهرية واتصال VPN
يوضح لك توصيل شبكة محلية بشبكة ظاهرية من Microsoft Azure كيفية تخطيط الشبكة الظاهرية ونشرها في Azure وكيفية إنشاء اتصال VPN. اتبع الإرشادات الواردة في الموضوع لإكمال الإجراءات التالية:
تخطيط مساحة عنوان IP الخاصة للشبكة الظاهرية.
تخطيط تغييرات البنية الأساسية للتوجيه للشبكة الظاهرية.
تخطيط قواعد جدار الحماية لنسبة استخدام الشبكة من وإلى جهاز VPN المحلي.
إنشاء الشبكة الظاهرية متعددة المباني في Azure.
تكوين التوجيه بين الشبكة المحلية والشبكة الظاهرية.
المرحلة 3: نشر خدمات Active Directory واسم المجال إلى شبكة Azure الظاهرية
تتضمن هذه المرحلة نشر كل من Windows Server Active Directory وDNS إلى الشبكة الظاهرية في سيناريو مختلط كما هو موضح في Microsoft Azure Architectures ل SharePoint 2013 وكما هو موضح في الشكل التالي.
الشكل: تكوين مجال Hybrid Active Directory
في الرسم التوضيحي، يتم توزيع جهازين ظاهريين على نفس الشبكة الفرعية. تستضيف كل من هذه الأجهزة الظاهرية دورين: Active Directory وDNS.
قبل نشر Active Directory في Azure، اقرأ إرشادات نشر Windows Server Active Directory على أجهزة Azure الظاهرية. تساعدك هذه الإرشادات في تحديد ما إذا كنت بحاجة إلى بنية مختلفة أو إعدادات تكوين مختلفة للحل الخاص بك.
للحصول على إرشادات مفصلة حول إعداد وحدة تحكم مجال في Azure، راجع تثبيت وحدة تحكم مجال Active Directory للنسخة المتماثلة في شبكات Azure الظاهرية.
قبل هذه المرحلة، لم تقم بنشر الأجهزة الظاهرية إلى الشبكة الظاهرية. من المحتمل ألا تكون الأجهزة الظاهرية لاستضافة Active Directory وDNS أكبر الأجهزة الظاهرية التي تحتاجها للحل. قبل نشر هذه الأجهزة الظاهرية، قم أولا بإنشاء أكبر جهاز ظاهري تخطط لاستخدامه في شبكتك الظاهرية. يساعد هذا في التأكد من أن الحل الخاص بك يهبط على علامة في Azure تسمح بأكبر حجم تحتاجه. لا تحتاج إلى تكوين هذا الجهاز الظاهري في الوقت الحالي. ما عليك سوى إنشائه، ووضعه جانبا. إذا لم تقم بذلك، فقد تواجه قيدا عند محاولة إنشاء أجهزة ظاهرية أكبر لاحقا، والتي كانت مشكلة في وقت كتابة هذه المقالة.
المرحلة 4: نشر مزرعة استرداد SharePoint في Azure
نشر مزرعة SharePoint في الشبكة الظاهرية وفقا لخطط التصميم الخاصة بك. قد يكون من المفيد مراجعة التخطيط ل SharePoint 2013 على Azure Infrastructure Services قبل نشر أدوار SharePoint في Azure.
ضع في اعتبارك الممارسات التالية التي تعلمناها من خلال بناء بيئة إثبات المفهوم لدينا:
إنشاء أجهزة ظاهرية باستخدام مدخل Microsoft Azure أو PowerShell.
لا يدعم Azure وHyper-V الذاكرة الديناميكية. تأكد من أن هذا يتم أخذه في الاعتبار في خطط الأداء والسعة.
أعد تشغيل الأجهزة الظاهرية من خلال واجهة Azure، وليس من تسجيل دخول الجهاز الظاهري نفسه. يعمل استخدام واجهة Azure بشكل أفضل ويمكن التنبؤ به بشكل أكبر.
إذا كنت تريد إيقاف تشغيل جهاز ظاهري لتوفير التكاليف، فاستخدم واجهة Azure. إذا قمت بإيقاف التشغيل من تسجيل دخول الجهاز الظاهري، تستمر الرسوم في التراكم.
استخدم اصطلاح تسمية للأجهزة الظاهرية.
انتبه إلى موقع مركز البيانات الذي يتم نشر الأجهزة الظاهرية فيه.
ميزة التحجيم التلقائي في Azure غير مدعومة لأدوار SharePoint.
لا تقم بتكوين العناصر في المزرعة التي ستتم استعادتها، مثل مجموعات المواقع المشتركة.
المرحلة الخامسة: إعداد DFSR بين المزارع
لإعداد النسخ المتماثل للملف باستخدام DFSR، استخدم الأداة الإضافية إدارة DNS. ومع ذلك، قبل إعداد DFSR، سجل الدخول إلى خادم الملفات المحلي وخادم ملفات Azure وقم بتمكين الخدمة في Windows.
من لوحة معلومات Server Manager، أكمل الخطوات التالية:
تكوين الخادم المحلي.
ابدأ تشغيل معالج إضافة أدوار وميزات.
افتح عقدة خدمات الملفات والتخزين .
حدد مساحات أسماء DFSوالنسخ المتماثل ل DFS.
انقر فوق التالي لإنهاء خطوات المعالج.
يوفر الجدول التالي ارتباطات إلى المقالات المرجعية ل DFSR ومنشورات المدونة.
الجدول: مقالات مرجعية ل DFSR
| عنوان | الوصف |
|---|---|
| النسخ المتماثل | موضوع DFS Management TechNet مع ارتباطات للنسخ المتماثل |
| النسخ المتماثل ل DFS: دليل البقاء على قيد الحياة | Wiki مع ارتباطات إلى معلومات DFS |
| النسخ المتماثل ل DFS: الأسئلة المتداولة | موضوع DFS Replication TechNet |
| مدونة خوسيه باريتو | مدونة كتبها مدير البرنامج الأساسي في فريق خادم الملفات في Microsoft |
| فريق التخزين في Microsoft - مدونة خزانة الملفات | مدونة حول خدمات الملفات وميزات التخزين في Windows Server |
المرحلة 6: إعداد شحن السجل إلى مزرعة الاسترداد
يعد شحن السجل هو المكون الهام لإعداد الإصلاح بعد كارثة في هذه البيئة. يمكنك استخدام شحن السجل لإرسال ملفات سجل المعاملات تلقائيا لقواعد البيانات من مثيل خادم قاعدة بيانات أساسي إلى مثيل خادم قاعدة بيانات ثانوي. لإعداد شحن السجل، راجع تكوين شحن السجل في SharePoint 2013.
هام
يقتصر دعم شحن السجل في SharePoint Server على قواعد بيانات معينة. لمزيد من المعلومات، راجع خيارات قابلية الوصول العالية المدعومة والإصلاح بعد كارثة لقواعد بيانات SharePoint (SharePoint 2013).
المرحلة 7: التحقق من صحة تجاوز الفشل والاسترداد
الهدف من هذه المرحلة النهائية هو التحقق من أن حل الإصلاح بعد كارثة يعمل كما هو مخطط له. للقيام بذلك، قم بإنشاء حدث تجاوز الفشل الذي يقوم بإيقاف تشغيل مزرعة الإنتاج وبدء تشغيل مزرعة الاسترداد كبديل. يمكنك بدء سيناريو تجاوز الفشل يدويا أو باستخدام البرامج النصية.
الخطوة الأولى هي إيقاف طلبات المستخدم الواردة لخدمات المزرعة أو المحتوى. يمكنك القيام بذلك عن طريق تعطيل إدخالات DNS أو عن طريق إيقاف تشغيل خوادم الويب الأمامية. بعد أن تكون المزرعة "معطلة"، يمكنك تجاوز الفشل في مزرعة الاسترداد.
إيقاف شحن السجل
يجب إيقاف شحن السجل قبل استرداد المزرعة. أوقف شحن السجل على الخادم الثانوي في Azure أولا، ثم أوقفه على الخادم الأساسي المحلي. استخدم البرنامج النصي التالي لإيقاف شحن السجل على الخادم الثانوي أولا ثم على الخادم الأساسي. قد تختلف أسماء قاعدة البيانات في البرنامج النصي، اعتمادا على بيئتك.
-- This script removes log shipping from the server.
-- Commands must be executed on the secondary server first and then on the primary server.
SET NOCOUNT ON
DECLARE @PriDB nvarchar(max)
,@SecDB nvarchar(250)
,@PriSrv nvarchar(250)
,@SecSrv nvarchar(250)
Set @PriDB= ''
SET @PriDB = UPPER(@PriDB)
SET @PriDB = REPLACE(@PriDB, ' ', '')
SET @PriDB = '''' + REPLACE(@PriDB, ',', ''', ''') + ''''
Set @SecDB = @PriDB
Exec ( 'Select ''exec master..sp_delete_log_shipping_secondary_database '' + '''''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_primary_secondary '' + '''''''' + prm.Primary_Database + '''''', '''''' + sec.Secondary_Server + '''''', '''''' + sec.Secondary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_primary_database '' + '''''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_secondary_primary '' + '''''''' + prm.primary_server + '''''', '''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
استعادة النسخ الاحتياطية
يجب استعادة النسخ الاحتياطية بالترتيب الذي تم إنشاؤها به. قبل أن تتمكن من استعادة نسخة احتياطية معينة من سجل المعاملات، يجب أولا استعادة النسخ الاحتياطية السابقة التالية دون التراجع عن المعاملات غير الملتزم بها (أي باستخدام WITH NORECOVERY):
النسخ الاحتياطي الكامل لقاعدة البيانات وآخر نسخة احتياطية تفاضلية - قم باستعادة هذه النسخ الاحتياطية، إن وجدت، التي تم أخذها قبل النسخ الاحتياطي لسجل المعاملات المعين. قبل إنشاء أحدث نسخة احتياطية كاملة أو تفاضلية لقاعدة البيانات، كانت قاعدة البيانات تستخدم نموذج الاسترداد الكامل أو نموذج الاسترداد الذي تم تسجيله بشكل مجمع.
جميع النسخ الاحتياطية لسجل المعاملات - استعادة أي نسخ احتياطية لسجل المعاملات التي تم التقاطها بعد النسخ الاحتياطي الكامل لقاعدة البيانات أو النسخ الاحتياطي التفاضلي (إذا قمت باستعادة واحدة) وقبل النسخ الاحتياطي لسجل المعاملات المحدد. يجب تطبيق النسخ الاحتياطية للسجل في التسلسل الذي تم إنشاؤها فيه، دون أي ثغرات في سلسلة السجل.
لاسترداد قاعدة بيانات المحتوى على الخادم الثانوي بحيث تعرض المواقع، قم بإزالة كافة اتصالات قاعدة البيانات قبل الاسترداد. لاستعادة قاعدة البيانات، قم بتشغيل عبارة SQL التالية.
restore database WSS_Content with recovery
هام
عند استخدام T-SQL بشكل صريح، حدد إما WITH NORECOVERY أو WITH RECOVERY في كل عبارة RESTORE لإزالة الغموض - وهذا أمر مهم جدا عند كتابة البرامج النصية. بعد استعادة النسخ الاحتياطية الكاملة والتفاضلية، يمكن استعادة سجلات المعاملات في SQL Server Management Studio. أيضا، نظرا لأن شحن السجل متوقف بالفعل، فإن قاعدة بيانات المحتوى في حالة الاستعداد، لذلك يجب تغيير الحالة إلى الوصول الكامل.
في SQL Server Management Studio، انقر بزر الماوس الأيمن فوق قاعدة بيانات WSS_Content، وأشر إلىاستعادةالمهام>، ثم انقر فوق سجل المعاملات (إذا لم تقم باستعادة النسخة الاحتياطية الكاملة، فهذا غير متوفر). لمزيد من المعلومات، راجعاستعادة النسخ الاحتياطي لسجل المعاملات (SQL Server).
تتبع ارتباطات مصدر المحتوى
يجب بدء تتبع ارتباطات كامل لكل مصدر محتوى لاستعادة خدمة البحث. لاحظ أنك تفقد بعض معلومات التحليلات من المزرعة المحلية، مثل توصيات البحث. قبل بدء عمليات تتبع الارتباطات الكاملة، استخدم Windows PowerShell cmdlet Restore-SPEnterpriseSearchServiceApplication وحدد قاعدة بيانات إدارة البحث التي تم شحنها ونسخها نسخا متماثلا، Search_Service__DB_<GUID>. يوفر cmdlet هذا تكوين البحث والمخطط والخصائص المدارة والقواعد والمصادر وينشئ مجموعة افتراضية من المكونات الأخرى.
لبدء تتبع ارتباطات كامل، أكمل الخطوات التالية:
في إدارة SharePoint 2013 المركزية، انتقل إلىتطبيقات> خدمة إدارة> التطبيقاتإدارة تطبيقات الخدمة، ثم انقر فوق تطبيق خدمة البحث الذي تريد تتبع ارتباطاته.
في صفحة إدارة البحث ، انقر فوق مصادر المحتوى، وأشر إلى مصدر المحتوى الذي تريده، وانقر فوق السهم، ثم انقر فوق بدء تتبع الارتباطات الكامل.
استرداد خدمات المزرعة
يوضح الجدول التالي كيفية استرداد الخدمات التي تحتوي على قواعد بيانات تم شحنها بواسطة السجل، والخدمات التي تحتوي على قواعد بيانات ولكن لا يوصى بالاستعادة باستخدام شحن السجل، والخدمات التي لا تحتوي على قواعد بيانات.
هام
لن تؤدي استعادة قاعدة بيانات SharePoint محلية إلى بيئة Azure إلى استرداد أي خدمات SharePoint لم تقم بتثبيتها بالفعل في Azure يدويا.
الجدول: مرجع قاعدة بيانات تطبيق الخدمة
| استعادة هذه الخدمات من قواعد البيانات المشحونة بالسجل | تحتوي هذه الخدمات على قواعد بيانات، ولكن نوصي ببدء تشغيل هذه الخدمات دون استعادة قواعد البيانات الخاصة بها | لا تخزن هذه الخدمات البيانات في قواعد البيانات؛ بدء تشغيل هذه الخدمات بعد تجاوز الفشل |
|---|---|---|
| خدمة الترجمة الآلية خدمة بيانات التعريف المدارة خدمة التخزين الآمن ملف تعريف المستخدم. (يتم دعم قواعد بيانات ملف التعريف ووضع العلامات الاجتماعية فقط. قاعدة بيانات المزامنة غير مدعومة.) خدمة إعدادات اشتراك Microsoft SharePoint Foundation |
جمع بيانات الاستخدام والصحة خدمة الحالة أتمتة Word |
Excel Services PerformancePoint Services تحويل PowerPoint Visio Graphics Service إدارة العمل |
يوضح المثال التالي كيفية استعادة خدمة بيانات التعريف المدارة من قاعدة بيانات.
يستخدم هذا قاعدة بيانات Managed_Metadata_DB الموجودة. يتم شحن قاعدة البيانات هذه، ولكن لا يوجد تطبيق خدمة نشط على المزرعة الثانوية، لذلك يجب توصيلها بعد تطبيق الخدمة في مكانه.
أولا، استخدم New-SPMetadataServiceApplication، وحدد DatabaseName المفتاح باسم قاعدة البيانات المستعادة.
بعد ذلك، قم بتكوين تطبيق خدمة بيانات التعريف المدارة الجديد على الخادم الثانوي، كما يلي:
الاسم: خدمة بيانات التعريف المدارة
خادم قاعدة البيانات: اسم قاعدة البيانات من سجل المعاملات المشحون
اسم قاعدة البيانات: Managed_Metadata_DB
تجمع التطبيقات: تطبيقات خدمة SharePoint
إدارة سجلات DNS
يجب إنشاء سجلات DNS يدويا للإشارة إلى مزرعة SharePoint.
في معظم الحالات التي يكون لديك فيها العديد من خوادم الويب الأمامية، من المنطقي الاستفادة من ميزة موازنة تحميل الشبكة في Windows Server 2012 أو موازن تحميل الأجهزة لتوزيع الطلبات بين خوادم واجهة الويب الأمامية في المزرعة الخاصة بك. يمكن أن تساعد موازنة تحميل الشبكة أيضا في تقليل المخاطر عن طريق توزيع الطلبات على الخوادم الأخرى إذا فشل أحد خوادم واجهة الويب الأمامية.
عادة، عند إعداد موازنة تحميل الشبكة، يتم تعيين عنوان IP واحد لنظام المجموعة الخاص بك. ثم تقوم بإنشاء سجل مضيف DNS في موفر DNS لشبكتك التي تشير إلى نظام المجموعة. (بالنسبة لهذا المشروع، وضعنا خادم DNS في Azure للمرونة في حالة فشل مركز البيانات المحلي.) على سبيل المثال، يمكنك إنشاء سجل DNS، في إدارة DNS في Active Directory، على سبيل المثال، يسمى https://sharepoint.contoso.com، الذي يشير إلى عنوان IP لنظام المجموعة متوازن التحميل.
للوصول الخارجي إلى مزرعة SharePoint، يمكنك إنشاء سجل مضيف على خادم DNS خارجي بنفس عنوان URL الذي يستخدمه العملاء على الإنترانت (على سبيل المثال، https://sharepoint.contoso.com) يشير إلى عنوان IP خارجي في جدار الحماية الخاص بك. (من أفضل الممارسات، باستخدام هذا المثال، إعداد DNS المقسم بحيث يكون خادم DNS الداخلي موثوقا contoso.com به ويوجه الطلبات مباشرة إلى مجموعة مزرعة SharePoint، بدلا من توجيه طلبات DNS إلى خادم DNS الخارجي.) يمكنك بعد ذلك تعيين عنوان IP الخارجي إلى عنوان IP الداخلي للمجموعة المحلية بحيث يجد العملاء الموارد التي يبحثون عنها.
من هنا، قد تواجه اثنين من سيناريوهات الإصلاح بعد كارثة المختلفة:
مثال على السيناريو: مزرعة SharePoint المحلية غير متوفرة بسبب فشل الأجهزة في مزرعة SharePoint المحلية. في هذه الحالة، بعد إكمال خطوات تجاوز الفشل إلى مزرعة Azure SharePoint، يمكنك تكوين موازنة تحميل الشبكة على خوادم واجهة الويب الأمامية لمزرعة SharePoint للاسترداد، بنفس الطريقة التي قمت بها مع المزرعة المحلية. يمكنك بعد ذلك إعادة توجيه سجل المضيف في موفر DNS الداخلي للإشارة إلى عنوان IP لنظام مجموعة مزرعة الاسترداد. لاحظ أن الأمر قد يستغرق بعض الوقت قبل تحديث سجلات DNS المخزنة مؤقتا على العملاء والإشارة إلى مزرعة الاسترداد.
مثال على السيناريو: يتم فقدان مركز البيانات المحلي تماما. قد يحدث هذا السيناريو بسبب كارثة طبيعية، مثل الحريق أو الفيضانات. في هذه الحالة، بالنسبة للمؤسسة، من المحتمل أن يكون لديك مركز بيانات ثانوي مستضاف في منطقة أخرى بالإضافة إلى شبكة Azure الفرعية التي تحتوي على خدمات الدليل الخاصة بها وDNS. كما هو الحال في سيناريو الكارثة السابق، يمكنك إعادة توجيه سجلات DNS الداخلية والخارجية للإشارة إلى مزرعة Azure SharePoint. مرة أخرى، لاحظ أن نشر سجل DNS قد يستغرق بعض الوقت.
إذا كنت تستخدم مجموعات المواقع المشتركة المسماة بالمضيف، كما هو مستحسن في بنية مجموعة المواقع المشتركة المسماة بالمضيف ونشرها (SharePoint 2013)، فقد يكون لديك العديد من مجموعات المواقع المشتركة التي يستضيفها تطبيق الويب نفسه في مزرعة SharePoint، مع أسماء DNS فريدة (على سبيل المثال، https://sales.contoso.com و https://marketing.contoso.com). في هذه الحالة، يمكنك إنشاء سجلات DNS لكل مجموعة مواقع مشتركة تشير إلى عنوان IP للمجموعة. بعد وصول الطلب إلى خوادم SharePoint الأمامية على الويب، فإنها تتعامل مع توجيه كل طلب إلى مجموعة المواقع المشتركة المناسبة.
بيئة إثبات المفهوم من Microsoft
لقد صممنا واختبرنا بيئة إثبات المفهوم لهذا الحل. كان هدف التصميم لبيئة الاختبار لدينا هو نشر مزرعة SharePoint التي قد نجدها في بيئة العملاء واستردادها. لقد قمنا بالعديد من الافتراضات، لكننا كنا نعلم أن المزرعة تحتاج إلى توفير جميع الوظائف الجاهزة دون أي تخصيصات. تم تصميم المخطط لقابلية الوصول العالية باستخدام إرشادات أفضل الممارسات من الحقل ومجموعة المنتجات.
يصف الجدول التالي الأجهزة الظاهرية Hyper-V التي أنشأناها وقمنا بتكوينها لبيئة الاختبار المحلية.
الجدول: الأجهزة الظاهرية للاختبار المحلي
| اسم الخادم | دور | التكوين |
|---|---|---|
| DC1 | وحدة تحكم المجال مع Active Directory. | معالجان من 512 ميغابايت إلى 4 غيغابايت من ذاكرة الوصول العشوائي قرص ثابت 1 × 127 غيغابايت |
| Rras | تم تكوين الخادم مع دور Routing و Remote Access Service (RRAS). | معالجان 2-8 غيغابايت من ذاكرة الوصول العشوائي قرص ثابت 1 × 127 غيغابايت |
| FS1 | خادم الملفات مع مشاركات للنسخ الاحتياطية ونقطة نهاية ل DFSR. | أربعة معالجات 2-12 غيغابايت من ذاكرة الوصول العشوائي قرص ثابت 1 × 127 غيغابايت قرص ثابت 1 × 1 تيرابايت (SAN) قرص ثابت 1 × 750 غيغابايت |
| SP-WFE1، SP-WFE2 | خوادم الويب الأمامية. | أربعة معالجات 16 غيغابايت من ذاكرة الوصول العشوائي |
| SP-APP1، SP-APP2، SP-APP3 | خوادم التطبيقات. | أربعة معالجات 2-16 غيغابايت من ذاكرة الوصول العشوائي |
| SP-SQL-HA1، SP-SQL-HA2 | خوادم قاعدة البيانات، التي تم تكوينها باستخدام مجموعات توفر AlwaysOn SQL Server 2012 لتوفير قابلية وصول عالية. يستخدم هذا التكوين SP-SQL-HA1 وSP-SQL-HA2 كنسخ متماثلة أساسية وثانوية. | أربعة معالجات 2-16 غيغابايت من ذاكرة الوصول العشوائي |
يصف الجدول التالي تكوينات محرك الأقراص لأجهزة Hyper-V الظاهرية التي أنشأناها وقمنا بتكوينها لخوادم الويب والتطبيقات الأمامية لبيئة الاختبار المحلية.
الجدول: متطلبات محرك أقراص الجهاز الظاهري لخوادم Front End Web وApplication للاختبار المحلي
| حرف محرك الأقراص | حجم | اسم الدليل | مسار |
|---|---|---|---|
| ج | 80 | محرك أقراص النظام | <DriveLetter>:\Program Files\Microsoft SQL Server\ |
| ه | 80 | محرك أقراص السجل (40 غيغابايت) | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| و | 80 | الصفحة (36 غيغابايت) | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL\DATA |
يصف الجدول التالي تكوينات محرك الأقراص لأجهزة Hyper-V الظاهرية التي تم إنشاؤها وتكوينها لتكون بمثابة خوادم قاعدة البيانات المحلية. في صفحة تكوين محرك قاعدة البيانات ، قم بالوصول إلى علامة التبويب دلائل البيانات لتعيين الإعدادات الموضحة في الجدول التالي وتأكيدها.
جدول: متطلبات محرك أقراص الجهاز الظاهري لخادم قاعدة البيانات للاختبار المحلي
| حرف محرك الأقراص | حجم | اسم الدليل | مسار |
|---|---|---|---|
| ج | 80 | دليل جذر البيانات | <DriveLetter>:\Program Files\Microsoft SQL Server\ |
| ه | 500 | دليل قاعدة بيانات المستخدم | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| و | 500 | دليل سجل قاعدة بيانات المستخدم | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| ز | 500 | دليل Temp DB | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| ح | 500 | دليل سجل Temp DB | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
إعداد بيئة الاختبار
أثناء مراحل التوزيع المختلفة، عمل فريق الاختبار عادة على البنية المحلية أولا ثم على بيئة Azure المقابلة. وهذا يعكس الحالات العامة في العالم الحقيقي حيث توجد بالفعل مزارع إنتاج داخلية قيد التشغيل. ما هو أكثر أهمية هو أنه يجب أن تعرف حمل العمل الإنتاجي الحالي والسعة والأداء النموذجي. بالإضافة إلى إنشاء نموذج الإصلاح بعد كارثة يمكنه تلبية متطلبات العمل، يجب عليك تغيير حجم خوادم مزرعة الاسترداد لتقديم الحد الأدنى من مستوى الخدمة. في بيئة الاستعداد الباردة أو الدافئة، عادة ما تكون مزرعة الاسترداد أصغر من مزرعة الإنتاج. بعد أن تكون مزرعة الاسترداد مستقرة وفي الإنتاج، يمكن توسيع نطاق المزرعة وخارجها لتلبية متطلبات حمل العمل.
نشرنا بيئة الاختبار الخاصة بنا في المراحل الثلاث التالية:
إعداد البنية الأساسية المختلطة
توفير الخوادم
توزيع مزارع SharePoint
إعداد البنية الأساسية المختلطة
تضمنت هذه المرحلة إعداد بيئة مجال للمزرعة المحلية ولمزرعة الاسترداد في Azure. بالإضافة إلى المهام العادية المرتبطة بتكوين Active Directory، قام فريق الاختبار بتنفيذ حل توجيه واتصال VPN بين البيئتين.
توفير الخوادم
بالإضافة إلى خوادم المزرعة، كان من الضروري توفير خوادم لوحدات التحكم بالمجال وتكوين خادم للتعامل مع RRAS بالإضافة إلى VPN من موقع إلى موقع. تم توفير خادمي ملفات لخدمة DFSR، وتم توفير العديد من أجهزة الكمبيوتر العميلة للمختبرين.
توزيع مزارع SharePoint
تم نشر مزارع SharePoint على مرحلتين لتبسيط استقرار البيئة واستكشاف الأخطاء وإصلاحها، إذا لزم الأمر. خلال المرحلة الأولى، تم نشر كل مزرعة على الحد الأدنى لعدد الخوادم لكل طبقة من المخطط لدعم الوظائف المطلوبة.
أنشأنا خوادم قاعدة البيانات مع تثبيت SQL Server قبل إنشاء خوادم SharePoint 2013. نظرا لأن هذا كان توزيعا جديدا، فقد أنشأنا مجموعات التوفر قبل نشر SharePoint. أنشأنا ثلاث مجموعات استنادا إلى إرشادات أفضل ممارسات MCS.
ملاحظة
قم بإنشاء قواعد بيانات العناصر النائبة بحيث يمكنك إنشاء مجموعات قابلية وصول عالية التوفر قبل تثبيت SharePoint. لمزيد من المعلومات، راجع تكوين مجموعات توفر AlwaysOn SQL Server 2012 ل SharePoint 2013
أنشأنا المزرعة وانضممنا إلى خوادم إضافية بالترتيب التالي:
توفير SP-SQL-HA1 وSP-SQL-HA2.
قم بتكوين AlwaysOn وإنشاء مجموعات التوفر الثلاث للمزرعة.
توفير SP-APP1 لاستضافة الإدارة المركزية.
توفير SP-WFE1 وSP-WFE2 لاستضافة ذاكرة التخزين المؤقت الموزعة.
استخدمنا المعلمة skipRegisterAsDistributedCachehost عند تشغيل psconfig.exe في سطر الأوامر. لمزيد من المعلومات، راجع التخطيط للموجزات وخدمة ذاكرة التخزين المؤقت الموزعة في SharePoint Server 2013.
كررنا الخطوات التالية في بيئة الاسترداد:
توفير AZ-SQL-HA1 وAZ-SQL-HA2.
قم بتكوين AlwaysOn وإنشاء مجموعات التوفر الثلاث للمزرعة.
توفير AZ-APP1 لاستضافة الإدارة المركزية.
توفير AZ-WFE1 وAZ-WFE2 لاستضافة ذاكرة التخزين المؤقت الموزعة.
بعد تكوين ذاكرة التخزين المؤقت الموزعة وإضافة مستخدمي الاختبار ومحتوى الاختبار، بدأنا المرحلة الثانية من التوزيع. وهذا يتطلب توسيع نطاق المستويات وتكوين خوادم المزرعة لدعم تخطيط الشبكة عالي التوفر الموضح في بنية المزرعة.
يصف الجدول التالي الأجهزة الظاهرية والشبكات الفرعية ومجموعات التوفر التي قمنا بإعدادها لمزرعة الاسترداد الخاصة بنا.
الجدول: البنية الأساسية لمزرعة الاسترداد
| اسم الخادم | دور | التكوين | الشبكه الفرعيه | مجموعة التوفر |
|---|---|---|---|---|
| spDRAD | وحدة تحكم المجال مع Active Directory | معالجان من 512 ميغابايت إلى 4 غيغابايت من ذاكرة الوصول العشوائي قرص ثابت 1 × 127 غيغابايت |
sp-ADservers | |
| AZ-SP-FS | خادم الملفات مع مشاركات للنسخ الاحتياطية ونقطة نهاية ل DFSR | تكوين A5: معالجان 14 غيغابايت من ذاكرة الوصول العشوائي قرص ثابت 1 × 127 غيغابايت قرص ثابت 1 × 135 غيغابايت قرص ثابت 1 × 127 غيغابايت قرص ثابت 1 × 150 غيغابايت |
sp-databaseservers | DATA_SET |
| AZ-WFE1، AZ -WFE2 | خوادم الويب الأمامية | تكوين A5: معالجان 14 غيغابايت من ذاكرة الوصول العشوائي قرص ثابت 1 × 127 غيغابايت |
sp-webservers | WFE_SET |
| AZ -APP1، AZ -APP2، AZ -APP3 | خوادم التطبيقات | تكوين A5: معالجان 14 غيغابايت من ذاكرة الوصول العشوائي قرص ثابت 1 × 127 غيغابايت |
sp-applicationservers | APP_SET |
| AZ -SQL-HA1، AZ -SQL-HA2 | خوادم قاعدة البيانات والنسخ المتماثلة الأساسية والثانوية لمجموعات توفر AlwaysOn | تكوين A5: معالجان 14 غيغابايت من ذاكرة الوصول العشوائي |
sp-databaseservers | DATA_SET |
عمليات
بعد استقرار فريق الاختبار في بيئات المزرعة وإكمال الاختبار الوظيفي، بدأوا مهام العمليات التالية المطلوبة لتكوين بيئة الاسترداد المحلية:
تكوين النسخ الاحتياطية الكاملة والتفاضلية.
تكوين DFSR على خوادم الملفات التي تنقل سجلات المعاملات بين البيئة المحلية وبيئة Azure.
تكوين شحن السجل على خادم قاعدة البيانات الأساسي.
تثبيت شحن السجل والتحقق من صحته واستكشاف الأخطاء وإصلاحها، كما هو مطلوب. تضمن ذلك تحديد وتوثيق أي سلوك قد يسبب مشكلات، مثل زمن انتقال الشبكة، مما قد يتسبب في فشل مزامنة ملف DFSR أو شحن السجل.
قواعد البيانات
تضمنت اختبارات تجاوز الفشل قواعد البيانات التالية:
WSS_Content
ManagedMetadata
قاعدة بيانات ملف التعريف
مزامنة DB
قاعدة بيانات اجتماعية
مركز نوع المحتوى (قاعدة بيانات لمركز تجميع نوع المحتوى المخصص)
تلميحات حول استكشاف الأخطاء وإصلاحها
يشرح القسم المشاكل التي واجهناها أثناء اختبارنا وحلولها.
تسبب استخدام أداة إدارة مخزن المصطلحات في حدوث الخطأ، "مخزن بيانات التعريف المدارة أو الاتصال غير متوفر حاليا."
تأكد من أن حساب تجمع التطبيقات الذي يستخدمه تطبيق الويب لديه إذن Read Access to Term Store.
مجموعات المصطلحات المخصصة غير متوفرة في مجموعة المواقع المشتركة
تحقق من وجود اقتران تطبيق خدمة مفقود بين مجموعة مواقع المحتوى المشتركة ومركز نوع المحتوى. بالإضافة إلى ذلك، ضمن شاشة Managed Metadata - <اسم> مجموعة المواقع المشتركة خصائص الاتصال ، تأكد من تمكين هذا الخيار: تطبيق الخدمة هذا هو موقع التخزين الافتراضي لمجموعات المصطلحات الخاصة بالعمود.
ينشئ الأمر Get-ADForest Windows PowerShell الخطأ ، "لم يتم التعرف على مصطلح "Get-ADForest" كاسم cmdlet أو دالة أو ملف برنامج نصي أو برنامج قابل للتشغيل."
عند إعداد ملفات تعريف المستخدمين، تحتاج إلى اسم مجموعة تفرعات Active Directory. في معالج إضافة أدوار وميزات، تأكد من تمكين وحدة Active Directory النمطية Windows PowerShell (ضمن قسم أدوات إدارة دور أدوات>إدارة>الخادم البعيد AD DS وأدوات AD LDS). بالإضافة إلى ذلك، قم بتشغيل الأوامر التالية قبل استخدام Get-ADForest للمساعدة في ضمان تحميل تبعيات البرنامج.
Import-Module ServerManager
Import-Module ActiveDirectory
فشل إنشاء مجموعة التوفر في بدء جلسة XEvent "AlwaysOn_health" على "<اسم> الخادم"
تأكد من أن كلتا العقدتين من نظام مجموعة تجاوز الفشل في الحالة "لأعلى" وليس "متوقف مؤقتا" أو "متوقف".
فشل مهمة شحن سجل SQL Server مع خطأ رفض الوصول أثناء محاولة الاتصال بمشاركة الملف
تأكد من تشغيل عامل SQL Server الخاص بك ضمن بيانات اعتماد الشبكة، بدلا من بيانات الاعتماد الافتراضية.
تشير مهمة شحن سجل SQL Server إلى النجاح، ولكن لا يتم نسخ أي ملفات
يحدث هذا لأن تفضيل النسخ الاحتياطي الافتراضي لمجموعة قابلية وصول عالية التوفر هو Prefer Secondary. تأكد من تشغيل مهمة شحن السجل من الخادم الثانوي لمجموعة التوفر بدلا من الأساسي؛ وإلا، ستفشل المهمة بصمت.
فشل بدء تشغيل خدمة بيانات التعريف المدارة (أو خدمة SharePoint الأخرى) تلقائيا بعد التثبيت
قد تستغرق الخدمات عدة دقائق للبدء، اعتمادا على الأداء والحمل الحالي لخادم SharePoint. انقر يدويا فوق البدء للخدمة وتوفير وقت كاف لبدء التشغيل أثناء تحديث شاشة الخدمات على الخادم أحيانا لمراقبة حالتها. في حالة استمرار إيقاف الخدمة، قم بتمكين التسجيل التشخيصي ل SharePoint، وحاول بدء تشغيل الخدمة مرة أخرى، ثم تحقق من السجل بحثا عن الأخطاء. لمزيد من المعلومات، راجع تكوين التسجيل التشخيصي في SharePoint 2013
بعد تغيير DNS إلى بيئة تجاوز فشل Azure، تستمر مستعرضات العميل في استخدام عنوان IP القديم لموقع SharePoint
قد لا يكون تغيير DNS مرئيا لجميع العملاء على الفور. على عميل اختبار، قم بتنفيذ الأمر التالي من موجه أوامر غير مقيد وحاول الوصول إلى الموقع مرة أخرى.
Ipconfig /flushdns
موارد إضافية
خيارات قابلية الوصول العالية المدعومة والإصلاح بعد كارثة لقواعد بيانات SharePoint
تكوين مجموعات توفر AlwaysOn SQL Server 2012 ل SharePoint 2013
انظر أيضاً
الملاحظات
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجع https://aka.ms/ContentUserFeedback.
إرسال الملاحظات وعرضها المتعلقة بـ