استرداد SharePoint Server 2013 بعد الكوارث في Microsoft Azure
باستخدام Azure، يمكنك إنشاء بيئة استرداد بعد كارثة لمزرعة SharePoint المحلية. تصف هذه المقالة كيفية تصميم هذا الحل وتنفيذه.
شاهد فيديو نظرة عامة على SharePoint Server 2013 للتعافي من الكوارث
عندما تهجم كارثة على بيئتك SharePoint المحلية، فإن أولويتك القصوى هي تشغيل النظام مرة أخرى بسرعة. يعد التعافي من الكوارث باستخدام SharePoint أسرع وأسهل عندما يكون لديك بيئة نسخ احتياطي قيد التشغيل بالفعل في Microsoft Azure. يشرح هذا الفيديو المفاهيم الرئيسية لبيئة تجاوز الفشل SharePoint الدافئة ويكمل التفاصيل الكاملة المتوفرة في هذه المقالة.
استخدم هذه المقالة مع نموذج الحل التالي: SharePoint Disaster Recovery في 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 log shipping مع النسخ المتماثل لنظام الملفات الموزعة (DFSR) لنسخ النسخ الاحتياطية لقاعدة البيانات وسجلات المعاملات إلى مزرعة الاسترداد في Azure:
يقوم DFSR بنقل السجلات من بيئة الإنتاج إلى بيئة الاسترداد. في سيناريو WAN، يكون DFSR أكثر كفاءة من شحن السجلات مباشرة إلى الخادم الثانوي في Azure.
تتم إعادة تشغيل السجلات إلى SQL Server في بيئة الاسترداد في Azure.
لا تقوم بإرفاق قواعد بيانات المحتوى التي تم شحنها SharePoint السجل في بيئة الاسترداد حتى يتم تنفيذ تمرين الاسترداد.
نفذ الخطوات التالية لاسترداد المزرعة:
إيقاف شحن السجل.
إيقاف قبول نسبة استخدام الشبكة إلى المزرعة الأساسية.
إعادة تشغيل سجلات المعاملات النهائية.
إرفاق قواعد بيانات المحتوى بالمزرعة.
استعادة تطبيقات الخدمة من قواعد بيانات الخدمات المنسوخة نسخا متماثلا.
تحديث سجلات نظام أسماء المجالات (DNS) للإشارة إلى مزرعة الاسترداد.
بدء تتبع ارتباطات كامل.
نوصي بالتدرب على هذه الخطوات بانتظام وتوثيقها للمساعدة في ضمان تشغيل الاسترداد المباشر بسلاسة. قد يستغرق إرفاق قواعد بيانات المحتوى واستعادة تطبيقات الخدمة بعض الوقت ويتضمن عادة بعض التكوين اليدوي.
بعد إجراء الاسترداد، يوفر هذا الحل العناصر المدرجة في الجدول التالي.
الجدول: أهداف استرداد الحلول
| البند | الوصف |
|---|---|
| المواقع والمحتوى | تتوفر المواقع والمحتوى في بيئة الاسترداد. |
| مثيل جديد للبحث | في حل الاستعداد الدافئ هذا، لا تتم استعادة البحث من قواعد بيانات البحث. يتم تكوين مكونات البحث في مزرعة الاسترداد بشكل مماثل قدر الإمكان لمزرعة الإنتاج. بعد استعادة المواقع والمحتوى، يتم بدء تتبع ارتباطات كامل لإعادة إنشاء فهرس البحث. لا تحتاج إلى انتظار اكتمال تتبع الارتباطات لتوفير المواقع والمحتوى. |
| خدمات | تتم استعادة الخدمات التي تخزن البيانات في قواعد البيانات من قواعد البيانات التي تم شحنها من السجل. يتم ببساطة بدء الخدمات التي لا تخزن البيانات في قواعد البيانات. لا تحتاج جميع الخدمات ذات قواعد البيانات إلى الاستعادة. لا تحتاج الخدمات التالية إلى استعادتها من قواعد البيانات ويمكن البدء ببساطة بعد تجاوز الفشل: الاستخدام وجمع البيانات الصحية خدمة الحالة أتمتة Word أي خدمة أخرى لا تستخدم قاعدة بيانات |
يمكنك العمل مع خدمات Microsoft الاستشارية (MCS) أو شريك لمعالجة أهداف الاسترداد الأكثر تعقيدا. يتم تلخيصها في الجدول التالي.
الجدول: العناصر الأخرى التي يمكن معالجتها بواسطة MCS أو شريك
| البند | الوصف |
|---|---|
| مزامنة حلول المزرعة المخصصة | من الناحية المثالية، يكون تكوين مزرعة الاسترداد مطابقا لمزرعة الإنتاج. يمكنك العمل مع مستشار أو شريك لتقييم ما إذا كان يتم نسخ حلول المزرعة المخصصة وما إذا كانت العملية في مكانها للحفاظ على مزامنة البيئتين. |
| الاتصالات بمصادر البيانات المحلية | قد لا يكون من العملي نسخ الاتصالات إلى أنظمة البيانات الخلفية، مثل اتصالات وحدة تحكم مجال النسخ الاحتياطي (BDC) ومصادر محتوى البحث. |
| سيناريوهات استعادة البحث | نظرا لأن عمليات نشر البحث في المؤسسات تميل إلى أن تكون فريدة ومعقدة إلى حد ما، فإن استعادة البحث من قواعد البيانات تتطلب استثمارا أكبر. يمكنك العمل مع مستشار أو شريك لتحديد وتنفيذ سيناريوهات استعادة البحث التي قد تتطلبها مؤسستك. |
تفترض الإرشادات الواردة في هذه المقالة أن المزرعة المحلية مصممة بالفعل وموزعة.
بنية مفصلة
من الناحية المثالية، يكون تكوين مزرعة الاسترداد في Azure مطابقا لمزرعة الإنتاج المحلية، بما في ذلك ما يلي:
التمثيل نفسه لأدوار الخادم
نفس تكوين التخصيصات
التكوين نفسه لمكونات البحث
يمكن أن تكون البيئة في Azure إصدارا أصغر من مزرعة الإنتاج. إذا كنت تخطط لتوسيع نطاق مزرعة الاسترداد بعد تجاوز الفشل، فمن المهم أن يتم تمثيل كل نوع من دور الخادم في البداية.
قد لا تكون بعض التكوينات عملية للنسخ المتماثل في بيئة تجاوز الفشل. تأكد من اختبار إجراءات تجاوز الفشل والبيئة للمساعدة في التأكد من أن مزرعة تجاوز الفشل توفر مستوى الخدمة المتوقع.
لا يعمل هذا الحل على تخطيط محدد لمزرعة SharePoint. ينصب تركيز هذا الحل على استخدام Azure لمزرعة تجاوز الفشل وتنفيذ شحن السجل وDFSR بين البيئتين.
بيئات الاستعداد الدافئة
في بيئة الاستعداد الدافئة، يتم تشغيل جميع الأجهزة الظاهرية في بيئة Azure. البيئة جاهزة لممارسة تجاوز الفشل أو حدث.
يوضح الشكل التالي حل التعافي من الكوارث من مزرعة SharePoint محلية إلى مزرعة SharePoint مستندة إلى Azure تم تكوينها كبيئة احتياطية دافئة.
الشكل: الطبولوجيا والعناصر الرئيسية لمزرعة إنتاج ومزرعة استرداد في وضع الاستعداد الدافئ
في هذا الرسم التخطيطي:
يتم توضيح بيئتين جنبا إلى جنب: مزرعة SharePoint المحلية والمزرعة الاحتياطية الدافئة في Azure.
تتضمن كل بيئة مشاركة ملف.
تتضمن كل مزرعة أربعة مستويات. لتحقيق قابلية وصول عالية، يتضمن كل مستوى خادمين أو جهازين ظاهريين تم تكوينهما بشكل مماثل لدور معين، مثل خدمات الواجهة الأمامية وذاكرة التخزين المؤقت الموزعة والخدمات الخلفية وقواعد البيانات. ليس من المهم في هذا الرسم التوضيحي استدعاء مكونات معينة. يتم تكوين المزرعتين بشكل مماثل.
المستوى الرابع هو مستوى قاعدة البيانات. يتم استخدام Log shipping لنسخ السجلات من خادم قاعدة البيانات الثانوي في البيئة المحلية إلى مشاركة الملف في نفس البيئة.
DFSR ينسخ الملفات من مشاركة الملف في البيئة المحلية إلى مشاركة الملف في بيئة Azure.
يعيد Log shipping تشغيل السجلات من مشاركة الملف في بيئة Azure إلى النسخة المتماثلة الأساسية في مجموعة توفر SQL Server AlwaysOn في بيئة الاسترداد.
بيئات الاستعداد الباردة
في بيئة الاستعداد الباردة، يمكن إيقاف تشغيل معظم الأجهزة الظاهرية لمزرعة SharePoint. (نوصي أحيانا ببدء تشغيل الأجهزة الظاهرية، مثل كل أسبوعين أو مرة واحدة في الشهر، بحيث يمكن مزامنة كل جهاز ظاهري مع المجال.) يجب أن تظل الأجهزة الظاهرية التالية في بيئة استرداد Azure قيد التشغيل للمساعدة في ضمان العمليات المستمرة لشحن السجل وDFSR:
مشاركة الملف
خادم قاعدة البيانات الأساسي
جهاز ظاهري واحد على الأقل يعمل خدمات مجال Active Directory خادم Windows وDNS
يوضح الشكل التالي بيئة تجاوز فشل Azure حيث يقوم الملف بمشاركة الجهاز الظاهري والجهاز الظاهري لقاعدة البيانات SharePoint الأساسية قيد التشغيل. يتم إيقاف جميع الأجهزة الظاهرية SharePoint الأخرى. لا يظهر الجهاز الظاهري الذي يعمل Windows Server Active Directory وDNS.
الشكل: مزرعة الاسترداد الاحتياطية الباردة مع تشغيل الأجهزة الظاهرية
بعد تجاوز الفشل إلى بيئة الاستعداد الباردة، يتم بدء تشغيل جميع الأجهزة الظاهرية، ويجب تكوين أسلوب تحقيق قابلية وصول عالية لخوادم قاعدة البيانات، مثل SQL Server مجموعات توفر AlwaysOn.
إذا تم تنفيذ مجموعات تخزين متعددة (يتم نشر قواعد البيانات عبر أكثر من SQL Server مجموعة قابلية وصول عالية)، يجب تشغيل قاعدة البيانات الأساسية لكل مجموعة تخزين لقبول السجلات المقترنة بمجموعة التخزين الخاصة بها.
المهارات والخبرة
يتم استخدام تقنيات متعددة في حل التعافي من الكوارث هذا. للمساعدة في ضمان تفاعل هذه التقنيات كما هو متوقع، يجب تثبيت كل مكون في البيئة المحلية وبيئة Azure وتكوينه بشكل صحيح. نوصي بأن يكون لدى الشخص أو الفريق الذي يقوم بإعداد هذا الحل معرفة قوية بالعمل والمهارات العملية باستخدام التقنيات الموضحة في المقالات التالية:
وأخيرا، نوصي بمهارات البرمجة النصية التي يمكنك استخدامها لأتمتة المهام المرتبطة بهذه التقنيات. من الممكن استخدام واجهات المستخدم المتوفرة لإكمال جميع المهام الموضحة في هذا الحل. ومع ذلك، يمكن أن يستغرق النهج اليدوي وقتا طويلا وعرضة للخطأ ويقدم نتائج غير متناسقة.
بالإضافة إلى Windows PowerShell، هناك أيضا مكتبات Windows PowerShell SQL Server وخادم SharePoint وAzure. لا تنس SQL T، والتي يمكن أن تساعد أيضا في تقليل الوقت لتكوين بيئة التعافي من الكوارث والحفاظ عليها.
خارطة طريق التعافي من الكوارث
تفترض هذه الخريطة أن لديك بالفعل مزرعة SharePoint Server 2013 تم نشرها في الإنتاج.
الجدول: مخطط الإصلاح بعد الكارثة
| المرحله | الوصف |
|---|---|
| المرحلة 1 | تصميم بيئة التعافي من الكوارث. |
| المرحلة 2 | إنشاء شبكة Azure الظاهرية واتصال VPN. |
| المرحلة 3 | نشر Windows Active Directory وخدمات أسماء المجالات إلى شبكة Azure الظاهرية. |
| المرحلة 4 | نشر مزرعة استرداد SharePoint في Azure. |
| المرحلة 5 | إعداد DFSR بين المزارع. |
| المرحلة 6 | إعداد شحن السجل إلى مزرعة الاسترداد. |
| المرحلة 7 | التحقق من صحة حلول تجاوز الفشل والاسترداد. ويشمل ذلك الإجراءات والتقنيات التالية: إيقاف شحن السجل. استعادة النسخ الاحتياطية. تتبع ارتباطات المحتوى. استرداد الخدمات. إدارة سجلات DNS. |
المرحلة 1: تصميم بيئة التعافي من الكوارث
استخدم الإرشادات الواردة في Microsoft Azure Architectures ل SharePoint 2013 لتصميم بيئة الاسترداد بعد الكوارث، بما في ذلك مزرعة استرداد SharePoint. يمكنك استخدام الرسومات في SharePoint Disaster Recovery Solution في ملف Azure Visio لبدء عملية التصميم. نوصي بتصميم البيئة بأكملها قبل البدء في أي عمل في بيئة Azure.
بالإضافة إلى الإرشادات المتوفرة في Microsoft Azure Architectures ل SharePoint 2013 لتصميم الشبكة الظاهرية واتصال VPN وActive Directory ومزرعة SharePoint، تأكد من إضافة دور مشاركة ملف إلى بيئة Azure.
لدعم سجل الشحن في حل استرداد البيانات بعد الكوارث، تتم إضافة جهاز ظاهري لمشاركة الملفات إلى الشبكة الفرعية حيث توجد أدوار قاعدة البيانات. تعمل مشاركة الملف أيضا كعقدة ثالثة من Node Majority لمجموعة توفر SQL Server AlwaysOn. هذا هو التكوين الموصى به لمزرعة SharePoint قياسية تستخدم مجموعات توفر SQL Server AlwaysOn.
ملاحظة
من المهم مراجعة المتطلبات الأساسية لقاعدة البيانات للمشاركة في مجموعة توفر alwaysOn SQL Server. لمزيد من المعلومات، راجع المتطلبات الأساسية والقيود التوصيات لمجموعات قابلية وصول عالية التوفر 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 Virtual Networks.
قبل هذه المرحلة، لم تقم بنشر الأجهزة الظاهرية إلى الشبكة الظاهرية. من المحتمل ألا تكون الأجهزة الظاهرية لاستضافة Active Directory وDNS أكبر الأجهزة الظاهرية التي تحتاجها للحل. قبل نشر هذه الأجهزة الظاهرية، قم أولا بإنشاء أكبر جهاز ظاهري تخطط لاستخدامه في شبكتك الظاهرية. يساعد هذا على ضمان وصول الحل الخاص بك إلى علامة في Azure تسمح بأكبر حجم تحتاجه. لا تحتاج إلى تكوين هذا الجهاز الظاهري في هذا الوقت. ما عليك سوى إنشائه، وتعيينه جانبا. إذا لم تقم بذلك، فقد يتم تقييدك عند محاولة إنشاء أجهزة ظاهرية أكبر لاحقا، والتي كانت مشكلة في وقت كتابة هذه المقالة.
المرحلة 4: نشر مزرعة استرداد SharePoint في Azure
نشر مزرعة SharePoint في الشبكة الظاهرية وفقا لخطط التصميم الخاصة بك. قد يكون من المفيد مراجعة التخطيط SharePoint 2013 على Azure Infrastructure Services قبل نشر أدوار SharePoint في Azure.
ضع في اعتبارك الممارسات التالية التي تعلمناها من خلال بناء بيئة إثبات المفهوم لدينا:
إنشاء أجهزة ظاهرية باستخدام مدخل Azure أو PowerShell.
لا يدعم Azure و Hyper-V الذاكرة الديناميكية. تأكد من أن هذا يتم احتسابه في خطط الأداء والسعة الخاصة بك.
أعد تشغيل الأجهزة الظاهرية من خلال واجهة Azure، وليس من تسجيل الدخول إلى الجهاز الظاهري نفسه. يعمل استخدام واجهة Azure بشكل أفضل وأكثر قابلية للتنبؤ.
إذا كنت ترغب في إيقاف تشغيل جهاز ظاهري لتوفير التكاليف، فاستخدم واجهة Azure. إذا قمت بإيقاف التشغيل من تسجيل الدخول إلى الجهاز الظاهري، فستستمر الرسوم في التراكم.
استخدام اصطلاح تسمية للأجهزة الظاهرية.
انتبه إلى موقع مركز البيانات الذي يتم نشر الأجهزة الظاهرية فيه.
ميزة التحجيم التلقائي في Azure غير مدعومة لأدوار SharePoint.
لا تقم بتكوين العناصر في المزرعة التي سيتم استعادتها، مثل مجموعات المواقع المشتركة.
المرحلة 5: إعداد DFSR بين المزارع
لإعداد النسخ المتماثل للملفات باستخدام DFSR، استخدم الأداة الإضافية DNS Management. ومع ذلك، قبل إعداد DFSR، سجل الدخول إلى خادم الملفات المحلي وخادم ملفات Azure وتمكين الخدمة في Windows.
من لوحة معلومات Server Manager، أكمل الخطوات التالية:
تكوين الخادم المحلي.
ابدأ تشغيل معالج إضافة الأدوار والميزات.
افتح عقدة File and Storage Services .
حدد مساحات أسماء DFS والنسخ المتماثل ل DFS.
انقر فوق "التالي " لإنهاء خطوات المعالج.
يوفر الجدول التالي ارتباطات إلى المقالات المرجعية ل DFSR ومنشورات المدونة.
الجدول: المقالات المرجعية ل DFSR
| عنوان | الوصف |
|---|---|
| النسخ المتماثل | موضوع DFS Management TechNet مع ارتباطات للنسخ المتماثل |
| النسخ المتماثل ل DFS: دليل البقاء على قيد الحياة | Wiki مع ارتباطات إلى معلومات DFS |
| النسخ المتماثل ل DFS: الأسئلة المتداولة | موضوع TechNet للنسخ المتماثل لنظام DFS |
| مدونة باهت | مدونة كتبها مدير برنامج رئيسي في فريق خادم الملفات في Microsoft |
| فريق التخزين في Microsoft - مدونة خزانة الملفات | مدونة حول خدمات الملفات وميزات التخزين في Windows Server |
المرحلة 6: إعداد شحن السجل إلى مزرعة الاسترداد
يعد Log shipping المكون الهام لإعداد التعافي من الكوارث في هذه البيئة. يمكنك استخدام سجل الشحن لإرسال ملفات سجل المعاملات لقواعد البيانات تلقائيا من مثيل خادم قاعدة بيانات أساسي إلى مثيل خادم قاعدة بيانات ثانوي. لإعداد شحن السجل، راجع تكوين شحن السجل في 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، وأشر إلى TasksRestore > ، ثم انقر فوق سجل المعاملات (إذا لم تقم باستعادة النسخة الاحتياطية الكاملة، فهذا غير متوفر). لمزيد من المعلومات، راجعRestore نسخة احتياطية لسجل المعاملات (SQL Server).
تتبع ارتباطات مصدر المحتوى
يجب بدء تتبع ارتباطات كامل لكل مصدر محتوى لاستعادة خدمة البحث. لاحظ أنك تفقد بعض معلومات التحليلات من المزرعة المحلية، مثل توصيات البحث. قبل بدء عمليات تتبع الارتباطات الكاملة، استخدم Windows PowerShell cmdlet Restore-SPEnterpriseSearchServiceApplication وحدد قاعدة بيانات إدارة البحث التي تم شحنها والنسخ المتماثل ، Search_Service__DB_<GUID>. يعطي cmdlet هذا تكوين البحث والمخطط والخصائص المدارة والقواعد والمصادر وينشئ مجموعة افتراضية من المكونات الأخرى.
لبدء تتبع ارتباطات كامل، أكمل الخطوات التالية:
في الإدارة المركزية SharePoint 2013، انتقل إلى تطبيقات خدمة Application ManagementService > ApplicationsManage > ، ثم انقر فوق تطبيق خدمة البحث الذي تريد تتبع ارتباطاته.
في الصفحة "إدارة البحث "، انقر فوق "مصادر المحتوى"، وأشر إلى مصدر المحتوى الذي تريده، وانقر فوق السهم، ثم انقر فوق "بدء تتبع الارتباطات الكامل".
استرداد خدمات المزرعة
يوضح الجدول التالي كيفية استرداد الخدمات التي تحتوي على قواعد بيانات تم شحنها بواسطة السجل، والخدمات التي تحتوي على قواعد بيانات ولكن لا يوصى باستعادةها مع شحن السجل، والخدمات التي لا تحتوي على قواعد بيانات.
هام
استعادة قاعدة بيانات 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 Manager في 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 الداخلية والخارجية للإشارة إلى مزرعة SharePoint Azure. مرة أخرى، لاحظ أن نشر سجل 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 | تم تكوين الخادم مع دور خدمة التوجيه والوصول عن بعد (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 | خوادم قاعدة البيانات، التي تم تكوينها مع مجموعات توفر SQL Server 2012 AlwaysOn لتوفير قابلية وصول عالية. يستخدم هذا التكوين SP-SQL-HA1 و SP-SQL-HA2 كنسختين متماثلتين أساسيتين وثانوية. | أربعة معالجات 2-16 غيغابايت من ذاكرة الوصول العشوائي |
يصف الجدول التالي تكوينات محرك الأقراص لأجهزة Hyper-V الظاهرية التي أنشأناها وقمنا بتكوينها للويب الأمامية وخوادم التطبيقات لبيئة الاختبار المحلية.
الجدول: متطلبات محرك أقراص الجهاز الظاهري لخوادم الويب والتطبيقات الأمامية للاختبار المحلي
| حرف محرك الأقراص | حجم | اسم الدليل | مسار |
|---|---|---|---|
| ج | 80 | محرك أقراص النظام | <DriveLetter>:\Program Files\ Microsoft SQL Server\ |
| ه | 80 | محرك أقراص السجل (40 غيغابايت) | <DriveLetter>:\Program Files\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| و | 80 | صفحة (36 غيغابايت) | <DriveLetter>:\Program Files\ Microsoft SQL Server\ MSSQLDATA\ |
يصف الجدول التالي تكوينات محرك الأقراص لأجهزة Hyper-V الظاهرية التي تم إنشاؤها وتكوينها لتكون بمثابة خوادم قاعدة البيانات المحلية. في صفحة "تكوين محرك قاعدة البيانات "، قم بالوصول إلى علامة التبويب "دلائل البيانات " لتعيين الإعدادات الموضحة في الجدول التالي وتأكيدها.
الجدول: متطلبات محرك أقراص الجهاز الظاهري لخادم قاعدة البيانات للاختبار المحلي
| حرف محرك الأقراص | حجم | اسم الدليل | مسار |
|---|---|---|---|
| ج | 80 | دليل جذر البيانات | <DriveLetter>:\Program Files\ Microsoft SQL Server\ |
| ه | 500 | دليل قاعدة بيانات المستخدم | <DriveLetter>:\Program Files\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| و | 500 | دليل سجل قاعدة بيانات المستخدم | <DriveLetter>:\Program Files\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| ز | 500 | دليل Temp DB | <DriveLetter>:\Program Files\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| ح | 500 | دليل سجل Temp DB | <DriveLetter>:\Program Files\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
إعداد بيئة الاختبار
خلال مراحل النشر المختلفة، عمل فريق الاختبار عادة على البنية المحلية أولا ثم على بيئة Azure المقابلة. وهذا يعكس الحالات العامة في العالم الحقيقي حيث تعمل مزارع الإنتاج الداخلية بالفعل. ما هو أكثر أهمية هو أنه يجب أن تعرف حمل العمل الإنتاجي الحالي، والقدرة الإنتاجية، والأداء النموذجي. بالإضافة إلى إنشاء نموذج استرداد بعد كارثة يمكنه تلبية متطلبات العمل، يجب عليك تغيير حجم خوادم مزرعة الاسترداد لتقديم الحد الأدنى من الخدمة. في بيئة الاستعداد الباردة أو الدافئة، عادة ما تكون مزرعة الاسترداد أصغر من مزرعة الإنتاج. بعد أن تكون مزرعة الاسترداد مستقرة وفي الإنتاج، يمكن توسيع نطاق المزرعة وتقليصها لتلبية متطلبات حمل العمل.
نشرنا بيئة الاختبار الخاصة بنا في المراحل الثلاث التالية:
إعداد البنية الأساسية المختلطة
توفير الخوادم
توزيع مزارع SharePoint
إعداد البنية الأساسية المختلطة
تتضمن هذه المرحلة إعداد بيئة مجال للمزرعة المحلية ومزرعة الاسترداد في Azure. بالإضافة إلى المهام العادية المرتبطة بتكوين Active Directory، نفذ فريق الاختبار حل توجيه واتصال VPN بين البيئتين.
توفير الخوادم
بالإضافة إلى خوادم المزرعة، كان من الضروري توفير خوادم لوحدات التحكم بالمجال وتكوين خادم للتعامل مع RRAS بالإضافة إلى VPN من موقع إلى موقع. تم توفير خادمي ملفات لخدمة DFSR، وتم توفير العديد من أجهزة الكمبيوتر العميلة للمختبرين.
توزيع مزارع SharePoint
تم توزيع مزارع SharePoint على مرحلتين من أجل تبسيط استقرار البيئة واستكشاف الأخطاء وإصلاحها، إذا لزم الأمر. في أثناء المرحلة الأولى، تم نشر كل مزرعة على الحد الأدنى لعدد الخوادم لكل مستوى من الطوبولوجيا لدعم الوظائف المطلوبة.
أنشأنا خوادم قاعدة البيانات مع تثبيت SQL Server قبل إنشاء خوادم SharePoint 2013. نظرا لأن هذا كان نشرا جديدا، أنشأنا مجموعات التوفر قبل نشر SharePoint. أنشأنا ثلاث مجموعات استنادا إلى إرشادات أفضل ممارسات MCS.
ملاحظة
إنشاء قواعد بيانات العناصر النائبة بحيث يمكنك إنشاء مجموعات توفر قبل تثبيت SharePoint. لمزيد من المعلومات، راجع تكوين SQL Server 2012 AlwaysOn Availability Groups for 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 | 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 | DATA_SET |
عمليات
بعد تثبيت فريق الاختبار لبيئات المزرعة وإكمال الاختبار الوظيفي، بدئوا مهام العمليات التالية المطلوبة لتكوين بيئة الاسترداد المحلية:
تكوين النسخ الاحتياطية الكاملة والتفاضلية.
تكوين DFSR على خوادم الملفات التي تنقل سجلات المعاملات بين البيئة المحلية وبيئة Azure.
تكوين شحن السجل على خادم قاعدة البيانات الأساسي.
تثبيت شحن السجل والتحقق من صحته واستكشاف الأخطاء فيه وإصلاحها، كما هو مطلوب. وشمل ذلك تحديد وتوثيق أي سلوك قد يسبب مشاكل، مثل زمن انتقال الشبكة، مما قد يتسبب في فشل شحن السجل أو فشل مزامنة ملفات DFSR.
قواعد البيانات
تتضمن اختبارات تجاوز الفشل قواعد البيانات التالية:
WSS_Content
ManagedMetadata
ملف التعريف DB
مزامنة DB
قاعدة بيانات اجتماعية
مركز نوع المحتوى (قاعدة بيانات لمركز مشاركة نوع محتوى مخصص)
تلميحات استكشاف الأخطاء وإصلاحها
يشرح القسم المشاكل التي واجهناها أثناء اختبارنا وحلولها.
أدى استخدام أداة إدارة مخزن المصطلحات إلى حدوث الخطأ، "مخزن بيانات التعريف المدارة أو الاتصال غير متوفر حاليا."
تأكد من أن حساب تجمع التطبيقات المستخدم من قبل تطبيق الويب لديه إذن "الوصول للقراءة إلى مخزن المصطلحات".
مجموعات المصطلحات المخصصة غير متوفرة في مجموعة المواقع المشتركة
تحقق من وجود اقتران تطبيق خدمة مفقود بين مجموعة المواقع المشتركة للمحتوى ومركز نوع المحتوى. بالإضافة إلى ذلك، ضمن شاشة بيانات التعريف المدارة - <site collection name> خصائص الاتصال ، تأكد من تمكين هذا الخيار: تطبيق الخدمة هذا هو موقع التخزين الافتراضي لمجموعات المصطلحات الخاصة بالعمود.
ينشئ الأمر 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' على '<server name>'
تأكد من أن كلا العقدتين من مجموعة تجاوز الفشل الخاصة بك في الحالة "لأعلى" وليس "متوقف مؤقتا" أو "متوقف".
SQL Server فشل مهمة شحن السجل مع خطأ في رفض الوصول أثناء محاولة الاتصال بمشاركة الملف
تأكد من تشغيل عامل SQL Server الخاص بك ضمن بيانات اعتماد الشبكة، بدلا من بيانات الاعتماد الافتراضية.
SQL Server مهمة شحن السجل تشير إلى النجاح، ولكن لا يتم نسخ أي ملفات
يحدث هذا لأن تفضيل النسخ الاحتياطي الافتراضي لمجموعة توفر هو "تفضيل ثانوي". تأكد من تشغيل مهمة شحن السجل من الخادم الثانوي لمجموعة التوفر بدلا من الأساسي؛ وإلا، ستفشل المهمة بصمت.
تفشل خدمة بيانات التعريف المدارة (أو خدمة SharePoint الأخرى) في البدء تلقائيا بعد التثبيت
قد تستغرق الخدمات عدة دقائق للبدء، اعتمادا على الأداء والتحميل الحالي لخادم SharePoint. انقر يدويا فوق "ابدأ " للخدمة وتوفير وقت كاف لبدء التشغيل أثناء تحديث "الخدمات" على شاشة "الخادم" من وقت لآخر لمراقبة حالتها. في حالة بقاء الخدمة متوقفة، قم بتمكين SharePoint التسجيل التشخيصي، وحاول بدء تشغيل الخدمة مرة أخرى، ثم تحقق من السجل بحثا عن الأخطاء. لمزيد من المعلومات، راجع تكوين التسجيل التشخيصي في SharePoint 2013
بعد تغيير DNS إلى بيئة تجاوز الفشل Azure، تستمر مستعرضات العميل في استخدام عنوان IP القديم لموقع SharePoint
قد لا يكون تغيير DNS مرئيا لجميع العملاء على الفور. على عميل اختبار، نفذ الأمر التالي من موجه أوامر غير مقيد وحاول الوصول إلى الموقع مرة أخرى.
Ipconfig /flushdns
موارد إضافية
خيارات التوفر العالي والتعافي من الكوارث المعتمدة لقواعد بيانات SharePoint
تكوين SQL Server 2012 AlwaysOn Availability Groups for SharePoint 2013
انظر أيضاً
الملاحظات
إرسال الملاحظات وعرضها المتعلقة بـ