استمرارية الأعمال متعددة المستويات والتعافي من الكوارث (BCDR) ل Azure Virtual Desktop

Azure Virtual Desktop هي خدمة ظاهرية شاملة لسطح المكتب والتطبيق تعمل على Microsoft Azure. يساعد سطح المكتب الظاهري على تمكين تجربة سطح المكتب البعيد الآمنة التي تساعد المؤسسات على تعزيز مرونة الأعمال. يوفر إدارة مبسطة وWindows 10 و11 Enterprise متعدد الجلسات وتحسينات لتطبيقات Microsoft 365 للمؤسسات. باستخدام Virtual Desktop، يمكنك نشر أجهزة سطح المكتب والتطبيقات التي تعمل بنظام Windows وتوسيع نطاقها على Azure في دقائق، ما يوفر ميزات أمان وتوافق متكاملة للمساعدة في الحفاظ على أمان التطبيقات والبيانات.

بينما تستمر في تمكين العمل عن بعد لمؤسستك باستخدام Virtual Desktop، من المهم فهم قدرات الاسترداد بعد الكوارث (DR) وأفضل الممارسات. تعزز هذه الممارسات الموثوقية عبر المناطق للمساعدة في الحفاظ على أمان البيانات وإنتاجية الموظفين. توفر لك هذه المقالة اعتبارات حول متطلبات استمرارية الأعمال والتعافي من الكوارث (BCDR) وخطوات النشر وأفضل الممارسات. يمكنك التعرف على الخيارات والاستراتيجيات وإرشادات البنية. يمكنك المحتوى الموجود في هذا المستند من إعداد خطة BCDR ناجحة ويمكن أن يساعدك على تحقيق مرونة أكبر لأعمالك أثناء أحداث وقت التعطل المخطط لها وغير المخطط لها.

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

الأهداف والنطاق

أهداف هذا الدليل هي:

• ضمان أقصى قدر من التوفر والمرونة والقدرة على التعافي من الكوارث الجغرافية مع تقليل فقدان البيانات لبيانات المستخدم الهامة المحددة.
• تقليل وقت الاسترداد.

تعرف هذه الأهداف أيضا باسم هدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد (RTO).

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

لتقليل تأثير فشل منطقة توفر واحدة، استخدم المرونة لتحسين قابلية الوصول العالية:

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

اعتمادا على عدد مناطق التوفر التي تستخدمها، قم بتقييم الإفراط في توفير عدد مضيفي الجلسة للتعويض عن فقدان منطقة واحدة. على سبيل المثال، حتى مع توفر مناطق (n-1)، يمكنك التأكد من تجربة المستخدم وأدائه.

بسبب المجموعات المحتملة من الأنواع وخيارات النسخ المتماثل وقدرات الخدمة وقيود التوفر في بعض المناطق، يوصى باستخدام مكون Cloud Cache من FSLogix بدلا من آليات النسخ المتماثل الخاصة بالتخزين.

OneDrive غير مشمول في هذه المقالة. لمزيد من المعلومات حول التكرار وقابلية الوصول العالية، راجع مرونة بيانات SharePoint وOneDrive في Microsoft 365.

بالنسبة للفترة المتبقية من هذه المقالة، ستتعرف على الحلول لنوعي تجمع مضيفي Virtual Desktop المختلفين. هناك أيضا ملاحظات مقدمة بحيث يمكنك مقارنة هذه البنية مع الحلول الأخرى:

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

تتم مناقشة الآثار المترتبة على التكلفة، ولكن الهدف الأساسي هو توفير نشر فعال للتعافي من الكوارث الجغرافية بأقل قدر من فقدان البيانات. لمزيد من تفاصيل BCDR، راجع الموارد التالية:

• اعتبارات BCDR لسطح المكتب الظاهري
• التعافي من الكوارث لسطح المكتب الظاهري

المتطلبات الأساسية

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

• طبولوجيا شبكات Azure التقليدية
• طبولوجيا شبكة WAN الظاهرية (التي تديرها Microsoft)

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

يوفر المركز في النهاية اتصالا مختلطا بالموارد المحلية وخدمات جدار الحماية وموارد الهوية مثل وحدات تحكم مجال Active Directory وموارد الإدارة مثل Log Analytics.

يجب مراعاة أي تطبيقات لخط العمل وتوفر الموارد التابعة عند تجاوز الفشل إلى الموقع الثانوي.

استمرارية أعمال وحدة التحكم والتعافي من الكوارث

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

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

Active-Active مقابل Active-Passive

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

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

• نشط-نشط

  • لكل تجمع مضيف في المنطقة الأساسية، يمكنك نشر تجمع مضيف ثان في المنطقة الثانوية.

  • يوفر هذا التكوين تقريبا صفر RTO، وRPO له تكلفة إضافية.

  • لا تطلب من المسؤول التدخل أو تجاوز الفشل. أثناء العمليات العادية، يوفر تجمع المضيف الثانوي للمستخدم موارد سطح المكتب الظاهري.

  • يحتوي كل تجمع مضيف على حسابات التخزين الخاصة به (واحد على الأقل) لملفات تعريف المستخدمين الثابتة.

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

  • يتم تعيين المستخدمين لمجموعات تطبيقات مختلفة، مثل مجموعة تطبيقات سطح المكتب (DAG) ومجموعة تطبيقات RemoteApp (RAG)، في كل من تجمعات المضيف الأساسية والثانوية. في هذه الحالة، يرون إدخالات مكررة في موجز عميل سطح المكتب الظاهري الخاص بهم. لتجنب الارتباك، استخدم مساحات عمل سطح المكتب الظاهري المنفصلة بأسماء وتسميات واضحة تعكس الغرض من كل مورد. قم بإعلام المستخدمين باستخدام هذه الموارد.

    

  • إذا كنت بحاجة إلى التخزين لإدارة ملف تعريف FSLogix وحاويات ODFC بشكل منفصل، فاستخدم ذاكرة التخزين المؤقت السحابية لضمان عدم وجود RPO تقريبا.

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

• نشط-سلبي
  • مثل active-active، لكل تجمع مضيف في المنطقة الأساسية، يمكنك نشر تجمع مضيف ثان في المنطقة الثانوية.
  • يتم تقليل مقدار موارد الحوسبة النشطة في المنطقة الثانوية مقارنة بالمنطقة الأساسية، اعتمادا على الميزانية المتاحة. يمكنك استخدام التحجيم التلقائي لتوفير المزيد من سعة الحوسبة، ولكنه يتطلب مزيدا من الوقت، ولا يتم ضمان سعة Azure.
  • يوفر هذا التكوين RTO أعلى عند مقارنته بالنهج النشط-النشط، ولكنه أقل تكلفة.
  • تحتاج إلى تدخل المسؤول لتنفيذ إجراء تجاوز الفشل إذا كان هناك انقطاع في Azure. لا يوفر تجمع المضيف الثانوي عادة وصول المستخدم إلى موارد سطح المكتب الظاهري.
  • يحتوي كل تجمع مضيف على حسابات تخزين خاصة به لملفات تعريف المستخدمين الثابتة.
  • يتأثر المستخدمون الذين يستهلكون خدمات سطح المكتب الظاهري ذات زمن الانتقال والأداء الأمثل فقط إذا كان هناك انقطاع في Azure. يجب التحقق من صحة هذا السيناريو باستخدام أداة Azure Virtual Desktop Experience Estimator . يجب أن يكون الأداء مقبولا، حتى لو كان متدهورا، لبيئة التعافي من الكوارث الثانوية.
  • يتم تعيين المستخدمين لمجموعة واحدة فقط من مجموعات التطبيقات، مثل سطح المكتب والتطبيقات البعيدة. أثناء العمليات العادية، تكون هذه التطبيقات في تجمع المضيف الأساسي. أثناء الانقطاع، وبعد تجاوز الفشل، يتم تعيين المستخدمين إلى مجموعات التطبيقات في تجمع المضيف الثانوي. لا يتم عرض أي إدخالات مكررة في موجز عميل سطح المكتب الظاهري للمستخدم، ويمكنهم استخدام نفس مساحة العمل، وكل شيء شفاف بالنسبة لهم.
  • إذا كنت بحاجة إلى التخزين لإدارة ملف تعريف FSLogix وحاويات Office، فاستخدم Cloud Cache لضمان عدم وجود RPO تقريبا.
    • لتجنب تعارضات ملف التعريف، لا تسمح للمستخدمين بالوصول إلى تجمعي المضيفين في نفس الوقت. نظرا لأن هذا السيناريو نشط-سلبي، يمكن للمسؤولين فرض هذا السلوك على مستوى مجموعة التطبيقات. فقط بعد إجراء تجاوز الفشل يكون المستخدم قادرا على الوصول إلى كل مجموعة تطبيقات في تجمع المضيف الثانوي. يتم إبطال الوصول في مجموعة تطبيقات تجمع المضيف الأساسي وإعادة تعيينه إلى مجموعة تطبيقات في تجمع المضيف الثانوي.
    • تنفيذ تجاوز فشل لجميع مجموعات التطبيقات، وإلا فقد يتسبب المستخدمون الذين يستخدمون مجموعات تطبيقات مختلفة في تجمعات مضيفين مختلفة في تعارضات في ملف التعريف إذا لم تتم إدارتها بشكل فعال.
  • من الممكن السماح لمجموعة فرعية معينة من المستخدمين بالفشل بشكل انتقائي إلى تجمع المضيف الثانوي وتوفير سلوك نشط-نشط محدود واختبار إمكانية تجاوز الفشل. من الممكن أيضا تجاوز الفشل عبر مجموعات تطبيقات محددة، ولكن يجب تثقيف المستخدمين لعدم استخدام الموارد من تجمعات مضيفين مختلفة في نفس الوقت.

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

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

الاعتبارات والتوصيات

عام

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

• لإنشاء مجموعات تطبيقات مميزة جديدة والتطبيقات ذات الصلة لتجمع المضيف الجديد.
• لإبطال تعيينات المستخدم إلى تجمع المضيف الأساسي، ثم إعادة تعيينها يدويا إلى تجمع المضيف الجديد أثناء تجاوز الفشل.

راجع خيارات استمرارية الأعمال والتعافي من الكوارث ل FSLogix.

• لا تتم تغطية أي استرداد لملف التعريف في هذا المستند.
• يتم تضمين ذاكرة التخزين المؤقت السحابية (نشطة/سلبية) في هذا المستند ولكن يتم تطبيقها باستخدام نفس تجمع المضيف.
• يتم تغطية ذاكرة التخزين المؤقت السحابية (نشطة/نشطة) في الجزء المتبقي من هذا المستند.

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

بالنسبة للتشخيص والمراقبة، من الجيد استخدام نفس مساحة عمل Log Analytics لكل من تجمع المضيف الأساسي والثانوي. باستخدام هذا التكوين، تقدم Azure Virtual Desktop Insights عرضا موحدا للتوزيع في كلتا المنطقتين.

ومع ذلك، يمكن أن يؤدي استخدام وجهة سجل واحدة إلى حدوث مشاكل إذا كانت المنطقة الأساسية بأكملها غير متوفرة. لن تتمكن المنطقة الثانوية من استخدام مساحة عمل Log Analytics في المنطقة غير المتوفرة. وإذا كان هذا الوضع غير مقبول، يمكن اعتماد الحلول التالية:

• استخدم مساحة عمل Log Analytics منفصلة لكل منطقة، ثم أشر إلى مكونات سطح المكتب الظاهري لتسجيل الدخول نحو مساحة العمل المحلية الخاصة بها.
• اختبار ومراجعة قدرات النسخ المتماثل لمساحة عمل Logs Analytics وتجاوز الفشل.

Compute

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

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

  

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

  إنشاء تعريف صورة وإصدار صورة

  إنشاء إصدار az sig image-

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

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

• لا يضمن وجود مضيفي جلسة العمل في حالة غير متصلة أو غير متصلة بالإنترنت في المنطقة الثانوية توفر السعة في حالة حدوث كارثة أساسية على مستوى المنطقة. ينطبق أيضا إذا تم نشر مضيفي جلسة العمل الجدد عند الطلب عند الحاجة، ومع استخدام Site Recovery . يمكن ضمان سعة الحساب فقط إذا تم تخصيص الموارد ذات الصلة بالفعل ونشطة.

بالنسبة لسيناريوهات استخدام ذاكرة التخزين المؤقت السحابية، نوصي باستخدام المستوى المتميز للأقراص المدارة.

التخزين

في هذا الدليل، يمكنك استخدام حسابي تخزين منفصلين على الأقل لكل تجمع مضيف لسطح المكتب الظاهري. أحدهما لحاوية ملف تعريف FSLogix، والآخر لبيانات حاوية Office. تحتاج أيضا إلى حساب تخزين آخر لحزم MSIX . تنطبق الاعتبارات التالية:

• يمكنك استخدام مشاركة Azure Files وAzure NetApp Files كبدائل تخزين. لمقارنة الخيارات، راجع خيارات تخزين حاوية FSLogix.
• يمكن أن توفر مشاركة ملفات Azure مرونة المنطقة باستخدام خيار مرونة التخزين المنسوخ نسخا متماثلا للمنطقة (ZRS)، إذا كان متوفرا في المنطقة.
• لا يمكنك استخدام ميزة التخزين المتكرر جغرافيا في الحالات التالية:
  • تحتاج إلى منطقة لا تحتوي على زوج. يتم إصلاح أزواج المنطقة للتخزين المتكرر جغرافيا ولا يمكن تغييرها.
  • أنت تستخدم المستوى المتميز.
• RPO وRTO أعلى مقارنة بآلية FSLogix Cloud Cache.
• ليس من السهل اختبار تجاوز الفشل وإرجاع الموارد في بيئة الإنتاج.
• تتطلب Azure NetApp Files المزيد من الاعتبارات:
  • التكرار في المنطقة غير متوفر بعد. إذا كان متطلبات المرونة أكثر أهمية من الأداء، فاستخدم مشاركة ملفات Azure.
  • يمكن أن تكون Azure NetApp Files منطقة، أي يمكن للعملاء تحديد منطقة توفر Azure (واحدة) التي سيتم تخصيصها.
  • يمكن إنشاء النسخ المتماثل عبر المناطق على مستوى وحدة التخزين لتوفير مرونة المنطقة ولكن يحدث النسخ المتماثل غير متزامن ويتطلب تجاوز الفشل اليدوي. تتطلب هذه العملية هدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد (RTO) أكبر من الصفر. قبل استخدام هذه الميزة ، راجع المتطلبات والاعتبارات للنسخ المتماثل عبر المناطق.
  • يمكنك استخدام Azure NetApp Files مع بوابات VPN وExpressRoute المكررة في المنطقة، إذا تم استخدام ميزة الشبكات القياسية، والتي قد تستخدمها لمرونة الشبكات. لمزيد من المعلومات، راجع طبولوجيا الشبكة المدعومة.
  • يتم دعم Azure Virtual WAN عند استخدامه مع شبكة Azure NetApp Files القياسية. لمزيد من المعلومات، راجع طبولوجيا الشبكة المدعومة.
• تحتوي Azure NetApp Files على آلية النسخ المتماثل عبر المناطق. تنطبق الاعتبارات التالية:
  • لا يتوفر في جميع المناطق.
  • يمكن أن يختلف النسخ المتماثل عبر المناطق لأزواج مناطق وحدات تخزين Azure NetApp Files عن أزواج منطقة تخزين Azure.
  • لا يمكن استخدامه في نفس الوقت مع النسخ المتماثل عبر المناطق
  • تجاوز الفشل غير شفاف، ويتطلب إرجاع الموارد إعادة تكوين التخزين.
• حدود
  • هناك حدود في الحجم، وعمليات الإدخال/الإخراج في الثانية (IOPS)، وعرض النطاق الترددي MBps لكل من مشاركة ملفات Azure وحسابات تخزين ملفات Azure NetApp ووحدات التخزين. إذا لزم الأمر، فمن الممكن استخدام أكثر من واحد لنفس تجمع المضيف في سطح المكتب الظاهري باستخدام الإعدادات لكل مجموعة في FSLogix. ومع ذلك، يتطلب هذا التكوين المزيد من التخطيط والتكوين.

يجب أن يكون حساب التخزين الذي تستخدمه لحزم تطبيقات MSIX مميزا عن الحسابات الأخرى لملف التعريف وحاويات Office. تتوفر خيارات التعافي من الكوارث الجغرافية التالية:

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

FSLogix

توصي Microsoft باستخدام تكوين FSLogix والميزات التالية:

• إذا كان محتوى حاوية ملف التعريف يحتاج إلى إدارة BCDR منفصلة، ولديه متطلبات مختلفة مقارنة بحاوية Office، يجب تقسيمها.

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

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

  

• يجب تمكين Cloud Cache مرتين في سجل الجهاز الظاهري لمضيف الجلسة، مرة لحاوية ملف التعريف ومرة واحدة لحاوية Office. من الممكن عدم تمكين ذاكرة التخزين المؤقت السحابية لحاوية Office، ولكن عدم تمكينها قد يتسبب في عدم محاذاة البيانات بين منطقة التعافي من الكوارث الأساسية والثانوية إذا كان هناك تجاوز فشل وإرجاع الموارد. اختبر هذا السيناريو بعناية قبل استخدامه في الإنتاج.

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

• يتم إرجاع المعلمة CCDLocations المحددة في السجل لتجمع المضيف في منطقة التعافي من الكوارث الثانوية بالترتيب، مقارنة بالإعدادات في المنطقة الأساسية. لمزيد من المعلومات، راجع البرنامج التعليمي: تكوين ذاكرة التخزين المؤقت السحابية لإعادة توجيه حاويات ملف التعريف أو حاوية المكتب إلى موفرين متعددين.

  تلميح

  تركز هذه المقالة على سيناريو معين. يتم وصف سيناريوهات إضافية في خيارات قابلية الوصول العالية ل FSLogix وخيارات استمرارية الأعمال والتعافي من الكوارث ل FSLogix.

يوضح المثال التالي تكوين ذاكرة التخزين المؤقت السحابية ومفاتيح التسجيل ذات الصلة:

المنطقة الأساسية = شمال أوروبا

• عنوان URI لحساب تخزين حاوية ملف التعريف = \northeustg1\profiles

  • مسار مفتاح التسجيل = ملفات تعريف HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix >
  • قيمة CCDLocations = type=smb,connectionString=\northeustg1\profiles; type=smb,connectionString=\westeustg1\profiles

  إشعار

  إذا قمت بتنزيل قوالب FSLogix مسبقا، يمكنك إنجاز نفس التكوينات من خلال وحدة تحكم إدارة نهج مجموعة Active Directory. لمزيد من التفاصيل حول كيفية إعداد كائن نهج المجموعة ل FSLogix، راجع الدليل، استخدام ملفات قالب نهج مجموعة FSLogix.

  

• حساب تخزين حاوية Office URI = \northeustg2\odcf

  • مسار مفتاح التسجيل = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC

  • قيمة CCDLocations = type=smb,connectionString=\northeustg2\odfc; type=smb,connectionString=\westeustg2\odfc

    

المنطقة الثانوية = غرب أوروبا

• عنوان URI لحساب تخزين حاوية ملف التعريف = \westeustg1\profiles
  • مسار مفتاح التسجيل = ملفات تعريف HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix >
  • قيمة CCDLocations = type=smb,connectionString=\westeustg1\profiles; type=smb,connectionString=\northeustg1\profiles
• حساب تخزين حاوية Office URI = \westeustg2\odcf
  • مسار مفتاح التسجيل = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC
  • قيمة CCDLocations = type=smb,connectionString=\westeustg2\odfc; type=smb,connectionString=\northeustg2\odfc

النسخ المتماثل لذاكرة التخزين المؤقت السحابية

تضمن آليات تكوين ذاكرة التخزين المؤقت السحابية والنسخ المتماثل نسخ بيانات ملف التعريف المتماثل بين مناطق مختلفة بأقل قدر من فقدان البيانات. نظرا لأنه يمكن فتح ملف تعريف المستخدم نفسه في وضع ReadWrite من خلال عملية واحدة فقط، يجب تجنب الوصول المتزامن، وبالتالي يجب ألا يفتح المستخدمون اتصالا بكلا تجمعي المضيفين في نفس الوقت.

قم بتنزيل ملف Visio لهذه البنية.

تدفق البيانات

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

2. يسترد FSLogix ملف تعريف المستخدم وحاويات Office، ثم يقوم بتحميل التخزين الأساسي VHD/X من حساب التخزين الموجود في المنطقة الأساسية.

3. في الوقت نفسه، يقوم مكون Cloud Cache بتهيئة النسخ المتماثل بين الملفات في المنطقة الأساسية والملفات في المنطقة الثانوية. لهذه العملية، تحصل ذاكرة التخزين المؤقت السحابية في المنطقة الأساسية على تأمين حصري للقراءة والكتابة على هذه الملفات.

4. يريد مستخدم سطح المكتب الظاهري نفسه الآن تشغيل تطبيق منشور آخر تم تعيينه على تجمع مضيف المنطقة الثانوية.

5. يحاول مكون FSLogix الذي يعمل على مضيف جلسة عمل سطح المكتب الظاهري في المنطقة الثانوية تحميل ملفات VHD/X لملف تعريف المستخدم من حساب التخزين المحلي. ولكن فشل التحميل نظرا لأن هذه الملفات مؤمنة بواسطة مكون Cloud Cache الذي يعمل على مضيف جلسة عمل سطح المكتب الظاهري في المنطقة الأساسية.

6. في تكوين FSLogix وCloud Cache الافتراضي، لا يمكن للمستخدم تسجيل الدخول ويتم تعقب خطأ في سجلات تشخيص FSLogix، ERROR_LOCK_VIOLATION 33 (0x21).

   

الهوية

واحدة من أهم التبعيات لسطح المكتب الظاهري هو توفر هوية المستخدم. للوصول إلى أجهزة سطح المكتب الظاهرية البعيدة الكاملة والتطبيقات البعيدة من مضيفي الجلسة، يحتاج المستخدمون إلى أن يكونوا قادرين على المصادقة. معرف Microsoft Entra هو خدمة الهوية السحابية المركزية من Microsoft التي تمكن هذه الإمكانية. يتم استخدام معرف Microsoft Entra دائما لمصادقة المستخدمين لسطح المكتب الظاهري. يمكن ضم مضيفي الجلسة إلى نفس مستأجر Microsoft Entra، أو إلى مجال Active Directory باستخدام خدمات مجال Active Directory أو Microsoft Entra Domain Services، ما يوفر لك خيارا من خيارات التكوين المرنة.

• معرِّف Microsoft Entra

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

• خدمات مجال Active Directory

  • لكي تكون خدمات مجال Active Directory مرنة ومتاحة بشكل كبير، حتى إذا كانت هناك كارثة على مستوى المنطقة، يجب عليك نشر وحدتي تحكم بالمجال على الأقل (DCs) في منطقة Azure الأساسية. يجب أن تكون وحدات التحكم بالمجال هذه في مناطق توفر مختلفة إذا أمكن، ويجب عليك التأكد من النسخ المتماثل المناسب مع البنية الأساسية في المنطقة الثانوية وفي النهاية محليا. يجب إنشاء وحدة تحكم مجال أخرى واحدة على الأقل في المنطقة الثانوية مع الكتالوج العمومي وأدوار DNS. لمزيد من المعلومات، راجع نشر AD DS في شبكة Azure الظاهرية.

• Microsoft Entra Connect

  • إذا كنت تستخدم معرف Microsoft Entra مع خدمات مجال Active Directory، ثم Microsoft Entra Connect لمزامنة بيانات هوية المستخدم بين خدمات مجال Active Directory ومعرف Microsoft Entra، يجب مراعاة مرونة هذه الخدمة واستردادها للحماية من كارثة دائمة.

  • يمكنك توفير قابلية وصول عالية والتعافي من الكوارث عن طريق تثبيت مثيل ثان للخدمة في المنطقة الثانوية وتمكين وضع التقسيم المرحلي.

  • إذا كان هناك استرداد، يطلب من المسؤول ترقية المثيل الثانوي عن طريق إخراجه من وضع التقسيم المرحلي. يجب أن تتبع نفس الإجراء مثل وضع خادم في وضع التقسيم المرحلي. بيانات اعتماد Microsoft Entra Global Administrator مطلوبة لإجراء هذا التكوين.

    

• Microsoft Entra Domain Services

  • يمكنك استخدام Microsoft Entra Domain Services في بعض السيناريوهات كبديل خدمات مجال Active Directory.
  • وهو يوفر قابلية وصول عالية.
  • إذا كان التعافي من الكوارث الجغرافية في نطاق السيناريو الخاص بك، يجب نشر نسخة متماثلة أخرى في منطقة Azure الثانوية باستخدام مجموعة نسخ متماثلة. يمكنك أيضا استخدام هذه الميزة لزيادة قابلية الوصول العالية في المنطقة الأساسية.

الرسومات التخطيطية الهيكلية

تجمع المضيف الشخصي

قم بتنزيل ملف Visio لهذه البنية.

تجمع مضيف مجمع

قم بتنزيل ملف Visio لهذه البنية.

تجاوز الفشل وإرجاع الموارد

سيناريو تجمع المضيف الشخصي

يختلف تجاوز الفشل وإرجاع الموارد لتجمع مضيف شخصي، حيث لا توجد ذاكرة التخزين المؤقت السحابية والتخزين الخارجي المستخدم لحاويات ملف التعريف وOffice. لا يزال بإمكانك استخدام تقنية FSLogix لحفظ البيانات في حاوية من مضيف الجلسة. لا يوجد تجمع مضيف ثانوي في منطقة التعافي من الكوارث، لذلك ليست هناك حاجة لإنشاء المزيد من مساحات العمل وموارد سطح المكتب الظاهري للنسخ المتماثل والمحاذاة. يمكنك استخدام Site Recovery لنسخ الأجهزة الظاهرية لمضيف جلسة العمل.

يمكنك استخدام Site Recovery في عدة سيناريوهات مختلفة. بالنسبة لسطح المكتب الظاهري، استخدم بنية Azure للتعافي من الكوارث في Azure Site Recovery.

تنطبق الاعتبارات والتوصيات التالية:

• تجاوز فشل Site Recovery ليس تلقائيا - يجب على المسؤول تشغيله باستخدام مدخل Microsoft Azure أو Powershell/API.
• يمكنك برمجة وأتمتة تكوين Site Recovery بأكمله وعملياته باستخدام PowerShell.
• يحتوي Site Recovery على RTO معلن داخل اتفاقية مستوى الخدمة (SLA). في معظم الأحيان، يمكن أن يفشل Site Recovery عبر الأجهزة الظاهرية في غضون دقائق.
• يمكنك استخدام Site Recovery مع Azure Backup. لمزيد من المعلومات، راجع دعم استخدام Site Recovery مع Azure Backup.
• يجب تمكين Site Recovery على مستوى الجهاز الظاهري، حيث لا يوجد تكامل مباشر في تجربة مدخل Virtual Desktop. يجب عليك أيضا تشغيل تجاوز الفشل وإرجاع الموارد على مستوى الجهاز الظاهري الفردي.
• يوفر Site Recovery إمكانية اختبار تجاوز الفشل في شبكة فرعية منفصلة لأجهزة Azure الظاهرية العامة. لا تستخدم هذه الميزة للأجهزة الظاهرية لسطح المكتب الظاهري، حيث سيكون لديك مضيفان متطابقان لجلسة عمل سطح المكتب الظاهري يتصلان بلوحة التحكم بالخدمة في نفس الوقت.
• لا يحتفظ Site Recovery بملحقات الجهاز الظاهري أثناء النسخ المتماثل. إذا قمت بتمكين أي ملحقات مخصصة للأجهزة الظاهرية لمضيف جلسة عمل سطح المكتب الظاهري، يجب إعادة تمكين الملحقات بعد تجاوز الفشل أو إرجاع الموارد. يتم استخدام ملحقات سطح المكتب الظاهري المضمنة joindomain وMicrosoft.PowerShell.DSC فقط عند إنشاء جهاز ظاهري لمضيف جلسة العمل. من الآمن فقدانها بعد تجاوز الفشل الأول.
• تأكد من مراجعة مصفوفة الدعم لاسترداد Azure VM بعد عطل فادح بين مناطق Azure والتحقق من المتطلبات والقيود ومصفوفة التوافق لسيناريو استرداد الموقع من Azure إلى Azure للتعافي من الكوارث، خاصة إصدارات نظام التشغيل المدعومة.
• عند تجاوز الفشل عبر جهاز ظاهري من منطقة إلى أخرى، يبدأ الجهاز الظاهري في منطقة التعافي من الكوارث الهدف في حالة غير محمية. إرجاع الموارد ممكن، ولكن يجب على المستخدم إعادة حماية الأجهزة الظاهرية في المنطقة الثانوية، ثم تمكين النسخ المتماثل مرة أخرى إلى المنطقة الأساسية.
• تنفيذ الاختبار الدوري لإجراءات تجاوز الفشل وإرجاع الموارد. ثم قم توثيق قائمة دقيقة بالخطوات وإجراءات الاسترداد استنادا إلى بيئة سطح المكتب الظاهري المحددة.

سيناريو تجمع المضيف المجمع

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

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

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

فيما يلي الوضع الأولي وافتراضات التكوين:

• تتم محاذاة تجمعات المضيفين في المنطقة الأساسية ومناطق التعافي من الكوارث الثانوية أثناء التكوين، بما في ذلك ذاكرة التخزين المؤقت السحابية.
• في تجمعات المضيفين، يتم تقديم كل من سطح المكتب DAG1 ومجموعات تطبيقات التطبيقات البعيدة ل APPG2 وAPPG3 للمستخدمين.
• في تجمع المضيف في المنطقة الأساسية، يتم استخدام مجموعات مستخدمي Active Directory GRP1 و GRP2 و GRP3 لتعيين المستخدمين إلى DAG1 و APPG2 و APPG3. قد يكون لهذه المجموعات عضوية مستخدم متداخلة، ولكن نظرا لأن النموذج هنا يستخدم نشط-سلبي مع تجاوز الفشل الكامل، فإنه ليس مشكلة.

تصف الخطوات التالية وقت حدوث تجاوز الفشل، بعد التعافي من الكوارث المخطط له أو غير المخطط له.

1. في تجمع المضيف الأساسي، قم بإزالة تعيينات المستخدم بواسطة المجموعات GRP1 و GRP2 و GRP3 لمجموعات التطبيقات DAG1 و APPG2 و APPG3.
2. هناك قطع اتصال إجباري لجميع المستخدمين المتصلين من تجمع المضيف الأساسي.
3. في تجمع المضيف الثانوي، حيث يتم تكوين مجموعات التطبيقات نفسها، يجب منح المستخدم حق الوصول إلى DAG1 وAPPG2 وAPPG3 باستخدام المجموعات GRP1 و GRP2 و GRP3.
4. مراجعة سعة تجمع المضيف في المنطقة الثانوية وضبطها. هنا، قد تحتاج إلى الاعتماد على خطة مقياس تلقائي لتشغيل مضيفي جلسة العمل تلقائيا. يمكنك أيضا بدء تشغيل الموارد الضرورية يدويا.

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

من الممكن أيضا تنفيذ خطة اختبار تجاوز الفشل مع بعض تغييرات التكوين، دون التأثير على بيئة الإنتاج.

• إنشاء عدد قليل من حسابات المستخدمين الجديدة في Active Directory للإنتاج.
• إنشاء مجموعة Active Directory جديدة تسمى GRP-TEST وتعيين المستخدمين.
• تعيين الوصول إلى DAG1 وAPPG2 وAPPG3 باستخدام مجموعة GRP-TEST.
• إعطاء إرشادات للمستخدمين في مجموعة GRP-TEST لاختبار التطبيقات.
• اختبر إجراء تجاوز الفشل باستخدام مجموعة GRP-TEST لإزالة الوصول من تجمع المضيف الأساسي ومنح حق الوصول إلى تجمع التعافي من الكوارث الثانوي.

توصيات هامة:

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

نسخة احتياطية

الافتراض في هذا الدليل هو أن هناك تقسيم ملف التعريف وفصل البيانات بين حاويات ملف التعريف وحاويات Office. يسمح FSLogix بهذا التكوين واستخدام حسابات تخزين منفصلة. بمجرد أن تكون في حسابات تخزين منفصلة، يمكنك استخدام نهج نسخ احتياطي مختلفة.

• بالنسبة إلى حاوية ODFC، إذا كان المحتوى يمثل البيانات المخزنة مؤقتا فقط التي يمكن إعادة إنشائها من مخزن البيانات على الإنترنت مثل Office 365، فلا يلزم إجراء نسخ احتياطي للبيانات.

• إذا كان من الضروري إجراء نسخ احتياطي لبيانات حاوية Office، يمكنك استخدام مساحة تخزين أقل تكلفة أو تكرار نسخ احتياطي وفترة استبقاء مختلفة.

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

• إذا كنت تستخدم OneDrive وإعادة توجيه المجلد المعروف، فقد يختفي متطلبات حفظ البيانات داخل الحاوية.

  إشعار

  لا يتم النظر في النسخ الاحتياطي ل OneDrive في هذه المقالة والسيناريو.

• ما لم يكن هناك متطلبات أخرى، يجب أن يكون النسخ الاحتياطي للتخزين في المنطقة الأساسية كافيا. لا يتم استخدام النسخ الاحتياطي لبيئة التعافي من الكوارث عادة.

• لمشاركة ملفات Azure، استخدم Azure Backup.

  • بالنسبة لنوع مرونة المخزن، استخدم التخزين المتكرر في المنطقة إذا لم يكن تخزين النسخ الاحتياطي خارج الموقع أو المنطقة مطلوبا. إذا كانت هذه النسخ الاحتياطية مطلوبة، فاستخدم التخزين المتكرر جغرافيا.

• توفر Azure NetApp Files حل النسخ الاحتياطي المضمن الخاص بها.

  • تأكد من التحقق من توفر ميزة المنطقة، جنبا إلى جنب مع المتطلبات والقيود.

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

• بن مارتن باور | مهندس حلول السحابة
• إيغور باغلياي | FastTrack لمهندس Azure (FTA) الرئيسي

مساهمون آخرون:

• نيلسون ديل فيلار | مهندس حلول السحابة، البنية الأساسية ل Azure
• جيسون مارتينيز | كاتب تقني

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

• خطة التعافي من الكوارث لسطح المكتب الظاهري
• BCDR لسطح المكتب الظاهري - إطار عمل اعتماد السحابة
• ذاكرة التخزين المؤقت السحابية لإنشاء المرونة والتوافر

الموارد ذات الصلة

• تصميم تطبيقات Azure الموثوق بها
• يتم الوصول إلى ملفات Azure محلياً وتأمينها بواسطة خدمات مجال Active Directory
• سطح المكتب الظاهري للمؤسسة
• مشاركة ملف المؤسسة مع الإصلاح بعد كارثة
• أمثلة تكوين FSLogix