Azure Virtual Desktop disaster recovery
للحفاظ على أمان بيانات مؤسستك، قد تحتاج إلى اعتماد استراتيجية استمرارية الأعمال والتعافي من الكوارث (BCDR). تحافظ استراتيجية غرفة البحرين لتسوية المنازعات السليمة على تشغيل تطبيقاتك وعبء العمل أثناء الخدمة المخطط لها وغير المخطط لها أو انقطاع Azure.
يوفر Azure Virtual Desktop غرفة البحرين لتسوية المنازعات لخدمة Azure Virtual Desktop للحفاظ على بيانات تعريف العملاء أثناء انقطاع التيار الكهربائي. عند حدوث انقطاع في منطقة ما، ستفشل مكونات البنية التحتية للخدمة إلى الموقع الثانوي وتستمر في العمل كالمعتاد. لا يزال بإمكانك الوصول إلى البيانات الوصفية المتعلقة بالخدمة، ولا يزال بإمكان المستخدمين الاتصال بالمضيفين المتاحين. ستبقى اتصالات المستخدم النهائي متصلة بالإنترنت طالما ظل المضيفون متاحين.
للتأكد من استمرار إمكانية اتصال المستخدمين أثناء انقطاع المنطقة، تحتاج إلى نسخ أجهزتهم الظاهرية (VMs) في موقع مختلف. أثناء انقطاع التيار الكهربائي، يفشل الموقع الأساسي في الوصول إلى الأجهزة الظاهرية المكررة في الموقع الثانوي. يمكن للمستخدمين متابعة الوصول إلى التطبيقات من الموقع الثانوي دون حدوث انقطاع. علاوة على النسخ المتماثل للجهاز الظاهري ، ستحتاج إلى الحفاظ على هويات المستخدمين قابلة للوصول في الموقع الثانوي. إذا كنت تستخدم حاويات ملف التعريف، فستحتاج أيضا إلى نسخها المتماثلة. وأخيرا، تأكد من أن تطبيقات نشاطك التجاري التي تعتمد على البيانات في الموقع الأساسي يمكن أن تفشل مع بقية البيانات.
للتلخيص، للحفاظ على اتصال المستخدمين أثناء انقطاع التيار الكهربائي، ستحتاج إلى القيام بالأمور التالية بهذا الترتيب:
- نسخ الأجهزة الظاهرية في موقع ثانوي.
- إذا كنت تستخدم حاويات ملف التعريف، فقم بإعداد النسخ المتماثل للبيانات في الموقع الثانوي.
- تأكد من توفر هويات المستخدمين التي قمت بإعدادها في الموقع الأساسي في الموقع الثانوي.
- تأكد من فشل أي تطبيقات خط عمل تعتمد على البيانات الموجودة في موقعك الأساسي إلى الموقع الثانوي.
النسخ المتماثل VM
أولا ، ستحتاج إلى نسخ الأجهزة الظاهرية إلى الموقع الثانوي. تعتمد خياراتك لإجراء ذلك على كيفية تكوين أجهزتك الظاهرية:
- يمكنك تكوين كافة أجهزتك الظاهرية لكلٍ من تجمعات المضيفين الجماعية والشخصية مع Azure Site Recovery. باستخدام هذا الأسلوب، ستحتاج فقط إلى إعداد تجمع مضيف واحد ومجموعات التطبيقات ومساحات العمل المرتبطة به.
- يمكنك إنشاء تجمع مضيف جديد في منطقة تجاوز الفشل مع إيقاف تشغيل كافة الموارد في موقع تجاوز الفشل. بالنسبة لهذه الطريقة، ستحتاج إلى إعداد مجموعات تطبيقات ومساحات عمل جديدة في منطقة تجاوز الفشل. يمكنك بعد ذلك استخدام خطة استرداد موقع Azure لتشغيل تجمعات المضيفين.
- يمكنك إنشاء تجمع مضيف يجري ملؤه بواسطة أجهزة ظاهرية مدمجة في كل من المناطق الأساسية ومناطق تجاوز الفشل مع الإبقاء على الأجهزة الظاهرية في منطقة تجاوز الفشل مغلقة. في هذه الحالة ، ما عليك سوى إعداد تجمع مضيف واحد ومجموعات التطبيقات ومساحات العمل ذات الصلة. يمكنك استخدام خطة Azure Site Recovery لتشغيل تجمعات المضيفين باستخدام هذا الأسلوب.
نوصي باستخدام Azure Site Recovery لإدارة النسخ المتماثل للأجهزة الظاهرية في مواقع Azure الأخرى، كما هو موضح في بنية التعافي من الكوارث من Azure إلى Azure. نوصي بشكل خاص باستخدام Azure Site Recovery لتجمعات المضيفين الشخصية، لأن Azure Site Recovery يدعم كل من وحدات SKU المستندة إلى الخادم والمستندة إلى العميل.
إذا كنت تستخدم Azure Site Recovery، فلن تحتاج إلى تسجيل هذه الأجهزة الظاهرية يدويا. سيستخدم عامل Azure Virtual Desktop في الجهاز الظاهري الثانوي تلقائياً أحدث رمز مميز للاتصال بمثيل الخدمة الأقرب إليه. الجهاز الظاهري (مضيف جلسة العمل) في الموقع الثانوي سيصبح تلقائياً جزءاً من تجمع المضيف. سيتعين على المستخدم النهائي إعادة الاتصال أثناء العملية ، ولكن بصرف النظر عن ذلك ، لا توجد عمليات يدوية أخرى.
إذا كانت هناك اتصالات مستخدم موجودة أثناء الانقطاع، فقبل أن يتمكن المسؤول من بدء تجاوز الفشل إلى المنطقة الثانوية، فأنت بحاجة إلى إنهاء اتصالات المستخدم في المنطقة الحالية.
لقطع اتصال المستخدمين في Azure Virtual Desktop (كلاسيكي)، قم بتشغيل cmdlet هذا:
Invoke-RdsUserSessionLogoff
لقطع اتصال المستخدمين في الإصدار المتكامل من Azure Virtual Desktop، قم بتشغيل cmdlet هذا:
Remove-AzWvdUserSession
بمجرد تسجيل الخروج لكافة المستخدمين في المنطقة الأساسية، يمكنك تجاوز فشل الأجهزة الظاهرية في المنطقة الأساسية والسماح للمستخدمين بالاتصال بالأجهزة الظاهرية في المنطقة الثانوية. لمزيد من المعلومات حول كيفية عمل هذه العملية، راجع نسخ الأجهزة الظاهرية Azure إلى منطقة Azure أخرى.
شبكة ظاهرية
بعد ذلك ، ضع في اعتبارك اتصال الشبكة أثناء الانقطاع. ستحتاج إلى التأكد من إعداد شبكة افتراضية (VNET) في منطقتك الثانوية. إذا كان المستخدمون بحاجة إلى الوصول إلى الموارد المحلية، فستحتاج إلى تكوين شبكة VNET هذه للوصول إليها. يمكنك إنشاء اتصالات محلية باستخدام VPN أو ExpressRoute أو شبكة WAN افتراضية.
نوصي باستخدام Azure Site Recovery لإعداد VNET في منطقة تجاوز الفشل لأنه يحافظ على إعدادات شبكتك الأساسية ولا يحتاج إلى نظير.
هويات المستخدم
بعد ذلك، تأكد من توفر وحدة تحكم المجال في الموقع الثانوي.
هناك ثلاث طرق للحفاظ على وحدة تحكم المجال متوفرة:
- لديك وحدة تحكم مجال Active Directory في موقع ثانوي
- استخدام وحدة تحكم مجال Active Directory محلي
- النسخ المتماثل لوحدة تحكم مجال Active Directory باستخدام استرداد موقع Azure
بيانات المستخدم والتطبيق
إذا كنت تستخدم حاويات ملف التعريف، فإن الخطوة التالية هي إعداد النسخ المتماثل للبيانات في الموقع الثانوي. لديك خمسة خيارات لتخزين ملفات تعريف FSLogix:
- مساحات التخزين المباشرة (S2D)
- محركات أقراص الشبكة (جهاز ظاهري مع محركات أقراص إضافية)
- ملفات Azure
- ملفات Azure NetApp
- ذاكرة التخزين المؤقت السحابية للنسخ المتماثل
لمزيد من المعلومات، راجع خيارات التخزين لحاويات ملف تعريف FSLogix في سطح مكتب Azure الظاهري.
إذا كنت تقوم بإعداد التعافي من الكوارث للملفات الشخصية، فهذه هي خياراتك:
إعداد النسخ المتماثل ل Azure الأصلي (على سبيل المثال، النسخ المتماثل لحساب التخزين القياسي لملفات Azure أو النسخ المتماثل لملفات Azure NetApp أو مزامنة ملفات Azure لخوادم الملفات).
ملاحظة
يتم نسخ NetApp المتماثل تلقائيا بعد إعداده لأول مرة. باستخدام خطط Azure Site Recovery، يمكنك إضافة برامج نصية مسبقة ونصوص ما بعد البرامج النصية للفشل في نسخ موارد تخزين Azure غير التابعة للجهاز الظاهري.
قم بإعداد FSLogix Cloud Cache لكل من بيانات التطبيق والمستخدم.
قم بإعداد التعافي من الكوارث لبيانات التطبيق فقط لضمان الوصول إلى البيانات المهمة للأعمال في جميع الأوقات. باستخدام هذه الطريقة ، يمكنك استرداد بيانات المستخدم بعد انتهاء الانقطاع.
دعونا نلقي نظرة على كيفية تكوين FSLogix لإعداد التعافي من الكوارث لكل خيار.
تكوين FSLogix
يمكن أن يعتمد عامل FSLogix مواقع ملفات تعريف متعددة إذا كوَّنت إدخالات السجل لـ FSLogix.
لتكوين إدخالات السجل:
افتح Registry Editor.
انتقل إلى الكمبيوتر>HKEY_LOCAL_MACHINE>SOFTWAREFSLogixProfiles>>.
انقر بزر الفأرة الأيمن على VHDLocations وحدد Edit Multi-String.
في الحقل Value Data، أدخِل المواقع التي تريد استخدامها.
عندما تنتهي، حدد OK.
إذا كان الموقع الأول غير متوفر، سيُبدل عامل FSLogix تلقائيا إلى الثاني، وهكذا.
نوصي بتكوين عامل FSLogix مع مسار إلى الموقع الثانوي في المنطقة الرئيسية. بمجرد إيقاف تشغيل الموقع الأساسي، سيُنسخ عامل FLogix نسخاً متماثلاً باعتباره جزءاً من النسخ المتماثل لـ Azure Site Recovery للجهاز الظاهري. بمجرد أن تكون الأجهزة الظاهرية المنسوخة نسخاً متماثلاً جاهزة، سيحاول العامل تلقائياً تغيير المسار إلى المنطقة الثانوية.
على سبيل المثال، لنفترض أن الأجهزة الظاهرية لمضيف الجلسة الأساسية موجودة في منطقة وسط الولايات المتحدة، ولكن حاوية ملف التعريف الخاص بك موجودة في منطقة وسط الولايات المتحدة لأسباب تتعلق بالأداء.
في هذه الحالة، يمكنك تكوين عامل FSLogix مع مسار إلى التخزين في وسط الولايات المتحدة. يمكنك تكوين أجهزة ظاهرية لمضيف الجلسة لنسخها نسخاً متماثلاً في غرب الولايات المتحدة. وبمجرد فشل المسار إلى وسط الولايات المتحدة، سيحاول العامل إنشاء مسار جديد للتخزين في غرب الولايات المتحدة بدلاً من ذلك.
S2D
نظرا لأن S2D يعالج النسخ المتماثل عبر المناطق داخلياً، فلن تحتاج إلى إعداد المسار الثانوي يدوياً.
محركات أقراص الشبكة (جهاز ظاهري مع محركات أقراص إضافية)
إذا نسخت الأجهزة الظاهرية الخاصة بتخزين الشبكة باستخدام Azure Site Recovery مثل الأجهزة الظاهرية لمضيف الجلسة، فإن الاسترداد يحتفظ بنفس المسار، مما يعني أنك لست بحاجة إلى إعادة تكوين FSlogix.
ملفات Azure
تدعم ملفات Azure النسخ المتماثل غير المتزامن عبر المنطقة التي يمكنك تحديدها عند إنشاء حساب التخزين. إذا كانت الطبيعة غير المتزامنة لملفات Azure تغطي بالفعل أهداف الإصلاح بعد كارثة خاصتك، فلن تحتاج إلى إجراء تكوين إضافي.
إذا كنت بحاجة إلى إجراء نسخ متماثل متزامن لتقليل فقد البيانات، فإننا نوصيك باستخدام FSLogix Cloud Cache بدلاً من ذلك.
ملاحظة
لا يغطي هذا القسم آلية مصادقة تجاوز الفشل لملفات Azure.
ملفات Azure NetApp
تعرف على المزيد حول ملفات Azure NetApp في إنشاء نسخ متماثل نظير لملفات Azure NetApp.
تبعيات التطبيق
وأخيرا، تأكد من أن أي تطبيقات أعمال تعتمد على البيانات الموجودة في المنطقة الأساسية يمكن أن تفشل في الموقع الثانوي. تأكد أيضا من تكوين الإعدادات التي تحتاجها التطبيقات للعمل في الموقع الجديد. على سبيل المثال، إذا كان أحد التطبيقات يعتمد على الواجهة الخلفية SQL، فتأكد من نسخ SQL في الموقع الثانوي. يجب عليك تكوين التطبيق لاستخدام الموقع الثانوي إما كجزء من عملية تجاوز الفشل أو كتكوين افتراضي له. يمكنك نمذجة تبعيات التطبيق على خطط استرداد موقع Azure. لمعرفة المزيد، راجع حول خطط الاسترداد.
اختبار استرداد البيانات بعد الكوارث
بعد الانتهاء من إعداد التعافي من الكوارث، ستحتاج إلى اختبار خطتك للتأكد من أنها تعمل.
فيما يلي بعض الاقتراحات حول كيفية اختبار خطتك:
- إذا كانت الأجهزة الظاهرية التجريبية لديها إمكانية الوصول إلى الإنترنت، فستستحوذ على أي مضيف جلسة عمل موجود للاتصالات الجديدة، ولكن ستظل جميع الاتصالات الموجودة بمضيف الجلسة الأصلي نشطة. تأكد من أن المسؤول الذي يقوم بتشغيل الاختبار يقوم بتسجيل خروج جميع المستخدمين النشطين قبل اختبار الخطة.
- يجب عليك فقط إجراء اختبارات التعافي الكامل من الكوارث أثناء نافذة الصيانة لعدم تعطيل المستخدمين. يمكنك أيضا استخدام تجمع مضيف في بيئة التحقق من الصحة للاختبار.
- تأكد من أن اختبارك يغطي جميع التطبيقات المهمة للأعمال.
- نوصيك فقط بتجاوز الفشل حتى 100 جهاز ظاهري في المرة الواحدة. إذا كان لديك أجهزة ظاهرية أكثر من ذلك ، فإننا نوصيك بفشلها على دفعات بفارق 10 دقائق.
الخطوات التالية
إذا كانت لديك أسئلة حول كيفية الحفاظ على أمان بياناتك بالإضافة إلى التخطيط لانقطاع التيار الكهربائي، فراجع دليل الأمان الخاص بنا.