التخطيط لتوزيع Azure File Sync
Azure File Sync هي خدمة تسمح لك بتخزين مشاركات ملفات Azure متعددة مؤقتًا على Windows Server محلي أو جهاز ظاهري على السحابة.
تقدم لك هذه المقالة مفاهيم ومميزات Azure File Sync. بمجرد أن تكون على دراية ب Azure File Sync، ضع في اعتبارك اتباع دليل نشر Azure File Sync لتجربة هذه الخدمة.
سيتم تخزين الملفات على السحابة في «مشاركات ملفات Azure». يمكن استخدام «مشاركات ملفات Azure» بطريقتين: عن طريق إدخال «مشاركات ملفات Azure» (SMB) بدون خادم بشكل مباشر أو عن طريق التخزين المؤقت لـ«مشاركات ملفات Azure» محليا باستخدام Azure File Sync. يغير خيار النشر الذي تختاره الجوانب التي تحتاج إلى مراعاتها أثناء التخطيط للنشر.
التحميل المباشر لمشاركة ملف Azure: نظرا لأن Azure Files توفر الوصول إلى SMB، يمكنك تحميل مشاركات ملفات Azure محليا أو في السحابة باستخدام عميل SMB القياسي المتوفر في Windows وmacOS وLinux. نظرا لأن مشاركات ملفات Azure بلا خادم، فإن النشر لسيناريوهات الإنتاج لا يتطلب إدارة خادم ملفات أو جهاز NAS. وهذا يعني أنك لست بحاجة لتطبيق تصحيحات البرامج أو تبديل الأقراص الفعلية.
مشاركة ملف Azure في ذاكرة التخزين المؤقت محليًا باستخدام Azure File Sync: يتيح لك Azure File Sync تجميع مشاركات ملفات مؤسستك في Azure Files، مع الحفاظ على المرونة والأداء والتوافق لخادم الملفات المحلي. تقوم Azure File Sync بتحويل خادم Windows محلي (أو سحابي) إلى ذاكرة تخزين مؤقت سريعة لمشاركة ملف Azure.
مفاهيم إدارة
يحتوي Azure File Sync deployment على ثلاثة كائنات إدارة أساسية:
- Azure file share: Azure file share هي مشاركة ملفات سحابية بدون خادم، والتي توفر نقطة النهاية السحابية لعلاقة مزامنة Azure File Synce. يمكن الوصول إلى الملفات الموجودة في Azure file share مباشرة باستخدام بروتوكول SMB أو بروتوكول FileREST، على الرغم من أننا نشجعك على الوصول إلى الملفات بشكل أساسي من خلال ذاكرة التخزين المؤقت لـWindows Server عند استخدام Azure file share مع Azure File Sync. وذلك لأن Azure Files اليوم يفتقر إلى آلية فعالة للكشف عن التغيير كالتي يمتلكهاWindows Server، لذا فإن التغييرات التي تطرأ على Azure file share مباشرة ستستغرق وقتا طويلا للانتشار مرة أخرى إلى نقاط نهاية الخادم.
- نقطة نهاية الخادم: هي المسار الموجود على خادم Windows Server الذي تتم مزامنته ملفات Azure تتم مشاركتها. يمكن أن يكون هذا مجلدا محددا على وحدة تخزين أو على جذر وحدة التخزين. يمكن أن توجد نقاط نهاية خادم متعددة على نفس وحدة التخزين إذا لم تتداخل مساحات الأسماء الخاصة بها.
- مجموعة المزامنة: العنصر الذي يحدد علاقة المزامنة بين نقطة نهاية سحابية أو ملفات Azure تتم مشاركتها مع نقطة نهاية خادم. يتم الاحتفاظ بنقاط النهاية ضمن مجموعة المزامنة في تزامن مع بعضها البعض. على سبيل المثال، إذا كان لديك مجموعتين متميزتين من الملفات التي تريد إدارتها باستخدام Azure File Sync، ستحتاج إلى إنشاء مجموعتي مزامنة وإضافة نقاط نهاية مختلفة لكل مجموعة مزامنة.
مفاهيم الإدارة لمشاركة الملفات في Azure
يتم نشر مشاركات ملفات Azure في حسابات التخزين، وهي كائنات ذات مستوى أعلى تمثل مجموعة تخزين مشتركة. يمكن استخدام مجموعة التخزين هذه لنشر مشاركات ملفات متعددة، بالإضافة إلى موارد التخزين الأخرى مثل حاويات الكائنات الثنائية كبيرة الحجم أو قوائم الانتظار أو الجداول. تشترك جميع موارد التخزين التي توزع في حساب التخزين في الحدود التي تنطبق على حساب التخزين هذا. لمعرفة حدود حساب التخزين الحالية، راجع قابلية التوسع في ملفات Azure وأهداف الأداء .
يوجد نوعان رئيسيان من حسابات التخزين ستستخدمهما لعمليات توزيع ملفات Azure:
- حسابات التخزين للأغراض العامة الإصدار 2 (GPv2) (GPv2) : تسمح لك حسابات تخزين GPv2 بنشر مشاركات ملفات Azure على الأجهزة القياسية/المستندة إلى القرص الثابت (المستندة إلى محرك الأقراص الثابتة). بالإضافة إلى تخزين مشاركات ملفات Azure، يمكن لحسابات تخزين GPv2 تخزين موارد التخزين الأخرى مثل قوائم الانتظار أو الجداول أو حاويات الكائنات الثنائية كبيرة الحجم.
- حسابات تخزين FileStorage: تتيح لك حسابات تخزين FileStorage نشر مشاركات ملفات Azure على أجهزة مستندة إلى قرص ذي حالة صلبة/مميزة (يستند إلى SSD). لا يمكن استخدام حسابات FileStorage إلا لتخزين مشاركات ملفات Azure؛ ولا يمكن توزيع أي موارد تخزين أخرى، على سبيل المثال، (قوائم الانتظار والجداول وحاويات الكائنات الثنائية كبيرة الحجم وما إلى ذلك) في حساب FileStorage. يمكن فقط لحسابات FileStorage نشر مشاركات ملفات كل من SMB وNFS.
هناك العديد من أنواع حسابات التخزين الأخرى التي قد تصادفها في مدخل Microsoft Azure أو PowerShell أو CLI. لا يمكن أن يحتوي نوعان من حسابات التخزين، وهما BlockBlobStorage وBlobStorage، على مشاركات ملفات Azure. النوعان الآخران من حسابات التخزين التي قد تراها هما الإصدار 1 للأغراض العامة (GPv1) وحسابات التخزين الكلاسيكية، وكلاهما يمكن أن يحتوي على مشاركات ملفات Azure. على الرغم من أن GPv1 وحسابات التخزين الكلاسيكية قد تحتوي على مشاركات ملفات Azure، فإن معظم الميزات الجديدة لملفات Azure متاحة فقط في حسابات تخزين GPv2 وFileStorage. لذلك نوصي باستخدام حسابات تخزين GPv2 و FileStorage لعمليات التوزيع الجديدة، ولترقية GPv1 وحسابات التخزين الكلاسيكية إذا كانت موجودة بالفعل في بيئتك.
مفاهيم إدارة Azure File Sync
يتم نشر مجموعات المزامنة في Storage Sync Services، وهي عناصر من المستوى الأعلى تقوم بتسجيل الخوادم للاستخدام مع Azure File Sync وتحتوي على علاقات مجموعة المزامنة. إن مورد Storage Sync Service هو نظير لمورد حساب التخزين، ويمكن نشره بطريقة مماثلة في مجموعات موارد Azure. يمكن لخدمة Storage Sync Service إنشاء مجموعات مزامنة تحتوي على مشاركات لملفات Azure عبر حسابات تخزين متعددة وخوادم Windows Servers مسجلة متعددة.
قبل أن تتمكن من إنشاء مجموعة مزامنة في خدمة Storage Sync Service، يجب عليك أولا تسجيل خادم Windows Server مع خدمة Storage Sync Service. يؤدي هذا إلى إنشاء عنصر خادم مسجل، والذي يمثل علاقة ثقة بين الخادم أو مجموعة أجهزة كمبيوتر و Storage Sync Service. لتسجيل خدمة Storage Sync Service، يجب أولا تثبيت عامل Storage Sync Service على الخادم. يمكن تسجيل خادم مفرد أو مجموعة أجهزة كمبيوتر باستخدام Storage Sync Service واحدة فقط في كل مرة.
تحتوي مجموعة المزامنة على نقطة نهاية سحابية واحدة، أو مشاركة لملف Azure، مع نقطة نهاية خادم واحدة على الأقل. يحتوي عنصر نقطة نهاية الخادم على الإعدادات التي تقوم بضبط إمكانية التدرج السحابي، والتي توفر إمكانية التخزين المؤقت لـ Azure File Sync. للمزامنة مع مشاركة لملف Azure، يجب أن يكون حساب التخزين الذي يحتوي على مشاركة لملف Azure في نفس منطقة Azure مثل Storage Sync Service.
هام
يمكنك إجراء تغييرات على مساحة اسم أي نقطة نهاية سحابية أو نقطة نهاية خادم في مجموعة المزامنة وكذلك مزامنة ملفاتك مع نقاط النهاية الأخرى في مجموعة المزامنة. إذا قمت بإجراء تغيير على نقطة النهاية السحابية (مشاركة ملف Azure) مباشرةً، فيجب أولاً اكتشاف التغييرات من خلال مهمة اكتشاف تغيير مزامنة الملفات Azure. يتم بدء وظيفة اكتشاف التغيير لنقطة نهاية سحابية مرة واحدة فقط كل 24 ساعة. لمزيد من المعلومات، راجع الأسئلة المتداولة حول ملفات Azure .
ضع في اعتبارك عدد Storage Sync Services المطلوبة
تمت مناقشة المورد الأساسي لتكوين Azure File Sync: «خدمة مزامنة التخزين»في قسم سابق. يمكن لـWindows Server التخزين فقط في «خدمة مزامنة تخزين واحدة». لذلك غالبا ما يكون من الأفضل نشر خدمة مزامنة تخزين واحدة فقط وتسجيل جميع الخوادم عليها.
لا تنشئ خدمات مزامنة تخزين متعددة إلا إن كان لديك:
- مجموعات مختلفة من الخوادم التي يجب ألا تتبادل البيانات مع بعضها البعض. في هذه الحالة، ستحتاج لتصميم النظام لاستبعاد مجموعات معينة من الخوادم لمزامنتها مع «مشاركة لملف Azure» قيد الاستخدام بالفعل كنقطة نهاية سحابية في مجموعة مزامنة في «خدمة مزامنة تخزين مختلفة». هناك طريقة أخرى للنظر إلى ذلك وهي أن Windows Servers المسجلة في خدمة «مزامنة تخزين» مختلفة لا يمكنها المزامنة مع نفس المشاركة لملف Azure.
- الحاجة إلى وجود خوادم مسجلة أو مجموعات مزامنة أكثر مما يمكن أن تدعمه خدمة Storage Sync Service واحدة. راجع أهداف مقياس Azure File Sync للحصول على المزيد من التفاصيل.
التخطيط لطبولوجيا المزامنة المتوازنة
قبل نشر أي موارد، من المهم التخطيط لما ستقوم بمزامنته على خادم محلي، والذي تشارك معه ملف Azure. سيساعدك وضع خطة على تحديد عدد حسابات التخزين، مشاركات ملفات Azure، وموارد المزامنة التي ستحتاجها. لا تزال هذه الاعتبارات ذات صلة، حتى إذا كانت بياناتك لا توجد حاليا على خادم Windows Server أو الخادم الذي تريد استخدامه على المدى الطويل. يمكن أن يساعد قسم الترحيل في تحديد مسارات الترحيل المناسبة لموقفك.
في هذه الخطوة، ستحدد عدد المشاركات لملفات Azure التي تحتاجها. يُمكن لمثيل Windows Server واحد (أو مجموعة) مزامنة ما يصل إلى 30 مشاركة ملف Azure.
من الممكن أن يكون لديك المزيد من المجلدات على وحدات التخزين التي تشاركها محليًا في الوقت الحالي كمشاركات SMB للمستخدمين والتطبيقات. تتمثل أسهل طريقة لتصور هذا السيناريو في تصور مشاركة محلية تقوم بتعيين 1:1 إلى مشاركة ملف Azure. إذا كان لديك عدد قليل بما يكفي من المشاركات، أقل من 30 لمثيل Windows Server واحد، فنوصيك بتعيين 1:1.
إن كان لديك أكثر من 30 مشاركة، فإن تعيين مشاركة محلية بنسبة 1:1 إلى مشاركة ملف Azure غالبًا ما يكون غير ضروري. ضع في اعتبارك الخيارات التالية.
مُشاركة التجميع
على سبيل المثال، إذا كان قسم الموارد البشرية لديك يمتلك 15 مشاركة، فقد تفكر في تخزين جميع بيانات الموارد البشرية في مشاركة ملف Azure واحدة. لا يمنعك تخزين مشاركات محلية متعددة في مشاركة ملف Azure واحدة من إنشاء مشاركات SMB الـ 15 المعتادة على مثيل Windows Server المحلي. ويعني هذا فقط أنك تقوم بتنظيم المجلدات الجذر لهذه المشاركات الـ 15 كمجلدات فرعية ضمن مجلد شائع. ثم تزامن بعد ذلك هذا المجلد المشترك مع مشاركة ملف Azure. بهذه الطريقة، لا يتعين سوى مشاركة ملف Azure واحد في السحابة لهذه المجموعة من المشاركات المحلية.
مُزامنة وحدة التخزين
يُدعم Azure File Sync مزامنة جذر وحدة التخزين مع مشاركة ملف Azure. إذا أجريت مزامنة جذر وحدة التخزين، فستنتقل جميع المجلدات الفرعية والملفات إلى نفس مشاركة ملف Azure.
لا تكون مزامنة جذر وحدة التخزين دائمًا هي الخيار الأفضل. توجد فوائد لمزامنة مواقع متعددة. على سبيل المثال، يساعد إجراء ذلك في تقليل عدد العناصر لكل نطاق مزامنة. نختبر مشاركات ملفات Azure وAzure File Sync مع 100 مليون عنصر (ملفات ومجلدات) لكل مشاركة. لكن أفضل الممارسات تتمثل في محاولة إبقاء الرقم أقل من 20 مليونًا أو 30 مليونًا في المشاركة الواحدة. لا يعد إعداد مزامنة ملفات Azure بعدد أقل من العناصر مفيدًا فقط لمزامنة الملفات. يستفيد عدد أقل من العناصر أيضًا من سيناريوهات مثل هذه:
- يمكن أن يكتمل الفحص الأولي لمحتوى السحابة بشكل أسرع، مما يؤدي بدوره إلى تقليل فترة انتظار ظهور مساحة الاسم على خادم تم تمكينه لـ Azure File Sync.
- ستكون استعادة السحابة من لقطة مشاركة ملف Azure أسرع.
- يُمكن أن تسرع عملية الإصلاح بعد الكارثة للخادم المحلي بشكل كبير.
- يُمكن الكشف عن التغييرات التي تم إجراؤها مباشرةً في مشاركة ملف Azure (خارج المزامنة) ومزامنتها بشكل أسرع.
تلميح
إذا لم تكن على دراية بعدد الملفات والمجلدات لديك، فراجع أداة TreeSize من JAM Software GmbH.
نهج منظم لمخطط التوزيع
قبل توزيع التخزين على السحابة في خطوة لاحقة، من المهم إنشاء مخطط بين المجلدات المحلية ومشاركات ملفات Azure. سيوضح هذا المخطط عدد موارد مجموعة مزامنة Azure File Sync التي ستوفرها وأي منها. تعمل مجموعة المزامنة على ربط مشاركة ملف Azure والمجلد الموجود على الخادم معًا، وإنشاء اتصال مزامنة.
لتحديد عدد مُشاركات ملف Azure التي تحتاجها، راجع الحدود وأفضل الممارسات التالية. سيساعدك القيام بذلك في تحسين مخططك.
يُمكن للخادم الذي تم تثبيت عامل Azure File Sync عليه المزامنة مع ما يصِل إلى 30 مشاركة ملفات Azure.
يتم توزيع مشاركة ملف Azure في حساب تخزين. يجعل هذا الترتيب حساب التخزين هدفًا مقياسًا لأرقام الأداء، مثل عمليات الإدخال والإخراج في الثانية ومعدل النقل.
انتبه إلى قيود IOPS الخاصة بحساب التخزين عند نشر مشاركات ملفات Azure. من الناحية المثالية، يجب تعيين مشاركات الملفات 1:1 مع حسابات التخزين. ومع ذلك، قد لا يكون هذا ممكنا دائما بسبب حدود وقيود مختلفة، سواء من مؤسستك أو من Azure. عندما لا يكون من الممكن نشر مشاركة ملف واحدة فقط في حساب تخزين واحد، ضع في اعتبارك المشاركات التي ستكون نشطة للغاية والمشاركات الأقل نشاطا لضمان عدم وضع مشاركات الملفات الأكثر سخونة في نفس حساب التخزين معا.
إذا كنت تخطط لرفع تطبيق يستخدم مشاركة ملف Azure أصلاً إلى Azure، فقد تحتاج إلى مزيد من الأداء من مشاركتك لملف Azure. إذا كان هذا النوع من الاستخدام محتملاً، حتى في المستقبل، فمن الأفضل إنشاء مشاركة ملف Azure قياسية واحدة في حساب التخزين لديك.
يوجد حد 250 حساب تخزين لكل اشتراك لكل منطقة Azure.
تلميح
بالنظر إلى هذه المعلومات، غالبًا ما يصبح من الضروري تجميع مجلدات متعددة من المستوى الأعلى على وحدات التخزين لديك في دليل جذر مشترك جديد. يُمكنك بعد ذلك مزامنة هذا الدليل الجذر الجديد، وجميع المجلدات التي جمعتها فيه، إلى مشاركة ملف Azure واحدة. تسمح تلك التقنية لك بالبقاء في حدود 30 مزامنة لمشاركة ملف Azure لكل خادم.
لا يؤثر التجميع تحت جذر مشترك على الوصول إلى بياناتك. تبقى قوائم التحكم بالوصول كما هي. تحتاج فقط إلى ضبط أي مسارات مشاركة (مثل مشاركات SMB أو NFS) قد تكون لديك على مجلدات الخادم المحلي التي غيرتها الآن إلى جذر مشترك. لا يتغيّر شيء آخر.
هام
إن أهم خط متجه لـ Azure File Sync هو عدد العناصر (الملفات والمجلدات) التي يجب مزامنتها. راجع أهداف مقياس Azure File Sync للحصول على المزيد من التفاصيل.
من أفضل الممارسات الحفاظ على عدد العناصر لكل نطاق مزامنة منخفضًا. هذا عامل مهم يجب مراعاته عند تعيين المجلدات لمشاركات ملفات Azure. اختُبرَت Azure File Sync مع 100 مليون عنصر (ملفات ومجلدات) لكل مشاركة. ولكن غالبًا ما يكون من الأفضل إبقاء عدد العناصر أقل من 20 مليونًا أو 30 مليونًا في مشاركة واحدة. قم بتقسيم مساحة الاسم إلى مشاركات متعددة إذا بدأت في تخطي هذه الأرقام. يمكنك الاستمرار في تجميع مشاركات محلية متعددة في نفس مشاركة ملف Azure إن بقيت أقل من هذه الأرقام تقريبًا. ستوفّر لك هذه الممارسة مساحة للنمو.
من الممكن، في حالتك، مزامنة مجموعة من المجلدات منطقيًا مع نفس مشاركة ملف Azure (باستخدام نهج المجلد الجذر الشائع الجديد المذكور سابقًا). ولكن قد لا يزال من الأفضل إعادة تجميع المجلدات بحيث تتم مزامنتها مع اثنين بدلاً من مشاركة ملف Azure واحدة. يمكنك استخدام ذلك الأسلوب للحفاظ على توازن عدد الملفات والمجلدات لكل مشاركة ملف عبر الخادم. يمكنك أيضًا تقسيم مشاركاتك المحلية ومزامنتها عبر المزيد من الخوادم المحلية، مما يضيف القدرة على المزامنة مع 30 مشاركة ملفات Azure أخرى لكل خادم إضافي.
سيناريوهات واعتبارات مزامنة الملفات الشائعة
| # | سيناريو المزامنة | مدعوم | الاعتبارات (أو القيود) | الحل (أو الحل البديل) |
|---|---|---|---|---|
| 1 | خادم الملفات مع أقراص/وحدات تخزين متعددة ومشاركات متعددة لنفس مشاركة ملف Azure الهدف (الدمج) | لا | تدعم مشاركة ملف Azure الهدف (نقطة نهاية السحابة) المزامنة مع مجموعة مزامنة واحدة فقط. تدعم مجموعة المزامنة نقطة نهاية خادم واحدة فقط لكل خادم مسجل. |
1) ابدأ بمزامنة قرص واحد (وحدة التخزين الجذر الخاصة به) لاستهداف مشاركة ملف Azure. سيساعد البدء بأكبر قرص/وحدة تخزين في متطلبات التخزين المحلية. تكوين ترتيب السحابة لتصنيف جميع البيانات إلى السحابة، وبالتالي تحرير مساحة على قرص خادم الملفات. نقل البيانات من وحدات التخزين/المشاركات الأخرى إلى وحدة التخزين الحالية التي تتم مزامنتها. تابع الخطوات واحدا تلو الآخر حتى يتم ترتيب جميع البيانات حتى السحابة/الترحيل. 2) استهداف وحدة تخزين جذر واحد (قرص) في كل مرة. استخدم ترتيب السحابة لتصنيف جميع البيانات لاستهداف مشاركة ملف Azure. قم بإزالة نقطة نهاية الخادم من مجموعة المزامنة، وأعد إنشاء نقطة النهاية باستخدام وحدة التخزين/القرص الجذر التالي، وقم بالمزامنة، وكرر العملية. ملاحظة: قد تكون إعادة تثبيت العامل مطلوبة. 3) التوصية باستخدام مشاركات ملفات Azure الهدف المتعددة (نفس حساب التخزين أو حساب تخزين مختلف بناء على متطلبات الأداء) |
| 2 | خادم الملفات مع وحدة تخزين واحدة ومشاركات متعددة لنفس مشاركة ملف Azure المستهدفة (الدمج) | نعم | لا يمكن أن يكون لديك نقاط نهاية خادم متعددة لكل خادم مسجل يتزامن مع نفس مشاركة ملف Azure الهدف (كما هو موضح أعلاه) | مزامنة جذر وحدة التخزين التي تحمل مشاركات متعددة أو مجلدات المستوى الأعلى. راجع مفهوم تجميع المشاركة ومزامنة وحدة التخزين للحصول على مزيد من المعلومات. |
| 3 | خادم الملفات مع مشاركات و/أو وحدات تخزين متعددة لمشاركات ملفات Azure متعددة ضمن حساب تخزين واحد (تعيين مشاركة 1:1) | نعم | يُمكن لمثيل Windows Server واحد (أو مجموعة) مزامنة ما يصل إلى 30 مشاركة ملف Azure. حساب التخزين هو هدف مقياس للأداء. تتم مشاركة IOPS ومعدل النقل عبر مشاركات الملفات. احتفظ بعدد العناصر لكل مجموعة مزامنة ضمن 100 مليون عنصر (ملفات ومجلدات) لكل مشاركة. من الناحية المثالية، من الأفضل أن تبقى أقل من 20 أو 30 مليونا لكل مشاركة. |
1) استخدام مجموعات مزامنة متعددة (عدد مجموعات المزامنة = عدد مشاركات ملفات Azure للمزامنة إليها). 2) يمكن مزامنة 30 مشاركة فقط في هذا السيناريو في كل مرة. إذا كان لديك أكثر من 30 مشاركة على خادم الملفات هذا، فاستخدم مفهوم تجميع المشاركة ومزامنةوحدة التخزين لتقليل عدد مجلدات الجذر أو المستوى الأعلى في المصدر. 3) استخدام خوادم مزامنة الملفات الإضافية في الموقع وتقسيم/نقل البيانات إلى هذه الخوادم للتغلب على القيود المفروضة على خادم Windows المصدر. |
| 4 | خادم الملفات مع مشاركات و/أو وحدات تخزين متعددة لمشاركات ملفات Azure متعددة ضمن حساب تخزين مختلف (تعيين مشاركة 1:1) | نعم | يمكن لمثيل Windows Server واحد (أو نظام مجموعة) مزامنة ما يصل إلى 30 مشاركة ملف Azure (نفس حساب التخزين أو حساب تخزين مختلف). احتفظ بعدد العناصر لكل مجموعة مزامنة ضمن 100 مليون عنصر (ملفات ومجلدات) لكل مشاركة. من الناحية المثالية، من الأفضل أن تبقى أقل من 20 أو 30 مليونا لكل مشاركة. |
النهج نفسه كما هو موضح أعلاه |
| 5 | خوادم ملفات متعددة مع واحد (وحدة تخزين الجذر أو مشاركة) لنفس مشاركة ملف Azure الهدف (الدمج) | لا | لا يمكن لمجموعة المزامنة استخدام نقطة نهاية السحابة (مشاركة ملف Azure) التي تم تكوينها بالفعل في مجموعة مزامنة أخرى. على الرغم من أن مجموعة المزامنة يمكن أن تحتوي على نقاط نهاية خادم على خوادم ملفات مختلفة، لا يمكن أن تكون الملفات مميزة. |
اتبع الإرشادات الواردة في السيناريو رقم 1 أعلاه مع مراعاة إضافية لاستهداف خادم ملفات واحد في كل مرة. |
إنشاء جدول المخططات
استخدم المعلومات السابقة لتحديد عدد مشاركات ملف Azure التي تحتاجها، وأي أجزاء من بياناتك الحالية ستنتهي في أي مشاركة ملف Azure.
أنشئ جدولاً لتسجيل أفكارك حتى تتمكن من الرجوع إليه عندما تحتاج إلى ذلك. يعد البقاء منظمًا أمرًا مهمًا لأنه قد يكون من السهل فقدان تفاصيل خطة التعيين عند توفير العديد من موارد Azure في وقت واحد. نزِّل ملف Excel التالي لاستخدامه كقالب للمساعدة في إنشاء التعيين.
|
تنزيل قالب تعيين مساحة الاسم. |
اعتبارات خادم ملفات Windows
لتفعيل إمكانية المزامنة على خادم Windows Server، يجب تثبيت عامل Azure File Sync القابل للتنزيل. يوفر عامل Azure File Sync مكونين رئيسيين: FileSyncSvc.exe، خدمة Windows الخلفية المسؤولة عن مراقبة التغييرات على نقاط نهاية الخادم وبدء جلسات المزامنة، و، وعامل StorageSync.sysتصفية نظام الملفات الذي يمكن ترتيب السحابة والتعافي السريع من الكوارث.
متطلبات نظام التشغيل
يتم دعم Azure File Sync مع الإصدارات التالية من خوادم Windows Server:
| إصدار | وحدات SKU المدعومة | خيارات التوزيع المدعومة |
|---|---|---|
| Windows Server 2022 | Azure وDatacenter و Essentials وStandard وIoT | الذاكرة الكاملة والأساسية |
| Windows Server 2019 | مركز البيانات والأساسيات والقياسية وIoT | الذاكرة الكاملة والأساسية |
| Windows Server 2016 | مركز البيانات والأساسيات والقياسية وخادم التخزين | الذاكرة الكاملة والأساسية |
| Windows Server 2012 R2* | مركز البيانات والأساسيات والقياسية وخادم التخزين | الذاكرة الكاملة والأساسية |
*يتطلب تنزيل وتثبيت إطار عمل إدارة Windows (WMF) 5.1. الحزمة المناسبة للتنزيل والتثبيت لنظام التشغيل Windows Server 2012 R 2 هي Win8.1AndW2K12R2-KB ******-x64.msu.
ستضاف الإصدارات المستقبلية من Windows Server عند إصدارها.
هام
نوصي بتحديث كافة الخوادم التي تستخدمها مع Azure File Sync بآخر التحديثات من Windows Update.
الحد الأدنى من موارد النظام
تتطلب Azure File Sync خادماً، إما مادياً أو ظاهرياً، مع وحدة CPU واحدة على الأقل، وذاكرة 2 غيغابايت كحد أدنى، ووحدة تخزين مرفقة محلياً منسقة بنظام ملفات NTFS.
هام
إذا كان الخادم قيد التشغيل في جهاز ظاهري مع تمكين الذاكرة الديناميكية، يجب تكوين الجهاز الظاهري بحد أدنى 2048 مبيبايت من الذاكرة.
بالنسبة لمعظم أحمال عمل الإنتاج، لا نوصي بتكوين خادم مزامنة Azure File Sync مع الحد الأدنى من المتطلبات فقط. للحصول على مزيد من المعلومات راجع موارد النظام الموصى بها.
الموارد الموصى بها لللنظام
تماما مثل أي ميزة أو تطبيق للخادم، يتم تحديد متطلبات موارد النظام لـAzure File Sync حسب مقياس النشر؛ حيث تتطلب عمليات النشر الأكبر حجما على الخادم موارد أكبر للنظام. بالنسبة إلى Azure File Sync، يتم تحديد المقياس من خلال عدد العناصر عبر نقاط نهاية الخادم والزحام الموجود على مجموعة البيانات. يمكن أن يحتوي خادم واحد على نقاط نهاية خادم في مجموعات مزامنة متعددة وعدد العناصر المدرجة في الجدول التالي يمثل مساحة الاسم الكاملة التي يتم إرفاق الخادم بها.
على سبيل المثال، نقطة نهاية الخادم A مع 10 ملايين عنصر + نقطة نهاية الخادم B مع 10 ملايين عنصر = 20 مليون عنصر. بالنسبة لنشر هذا المثال، نوصي بـ8 وحدات CPU، و 16 جيجابايت من الذاكرة للحالة الثابتة، و(إن أمكن) 48 جيبي بايت من الذاكرة للترحيل الأولي.
تخزن بيانات مساحة الاسم في الذاكرة لأسباب تتعلق بالأداء. ولهذا السبب، تتطلب مساحات الأسماء الأكبر حجما المزيد من الذاكرة للحفاظ على الأداء الجيد، ويتطلب المزيد من الاضطرابات مزيدًا من وحدات CPU للمعالجة.
في الجدول التالي، قدمنا كلا من حجم مساحة الاسم بالإضافة إلى تحويل إلى سعة لمشاركات ملفات الأغراض العامة النموذجية، حيث يبلغ متوسط حجم الملف 512 KiB. إذا كانت أحجام ملفاتك أصغر، ففكر في إضافة ذاكرة إضافية بنفس مقدار السعة. أسس تكوين الذاكرة حسب حجم مساحة الاسم.
| حجم مساحة الاسم - الملفات والدلائل (الملايين) | السعة النموذجية (بالتيبي بايت) | ذاكرة CPU الأساسية | الذاكرة الموصى بها (بالجيبي بايت) |
|---|---|---|---|
| 3 | 1.4 | 2 | 8 (مزامنة البيانات الأولية)/ 2 (الاضطراب النموذجي) |
| 5 | 2.3 | 2 | 16 (مزامنة البيانات الأولية)/4 (الاضطراب النموذجي) |
| 10 | 4.7 | 4 | 32 (مزامنة البيانات الأولية)/ 8 (الاضطراب النموذجي) |
| 30 | 14.0 | 8 | 48 (مزامنة البيانات الأولية)/ 16 (الاضطراب النموذجي) |
| 50 | 23.3 | 16 | 64 (مزامنة البيانات الأولية)/32 (الاضطراب النموذجي) |
| 100* | 46.6 | 32 | 128 (مزامنة البيانات الأولية)/32 (الاضطراب النموذجي) |
*لا ينصح بمزامنة أكثر من 100 مليون ملف ودلائل. هذا حد ضعيف يعتمد على حدودنا المختبرة. لمزيد من المعلومات، راجع أهداف مغير سعة Azure File Sync.
تلميح
تعد المزامنة الأولية لمساحة الاسم عملية مكثفة، ونوصي بتخصيص المزيد من الذاكرة حتى اكتمال المزامنة الأولية. هذا غير مطلوب ولكن قد يؤدي إلى تسريع المزامنة الأولية.
الاضطراب االنموذجي هو 0.5% من مساحة الاسم تتغير يوميا. للحصول على مستويات أعلى من الاضطراب، فكر في إضافة المزيد من وحدات CPU.
تقييم cmdlet
قبل نشر Azure File Sync، يجب تقييم ما إذا كان متوافقا مع النظام الخاص بك باستخدام الأمر cmdlet لتقييم Azure File Sync. يتحقق cmdlet هذا من المشكلات المحتملة في نظام الملفات ومجموعة البيانات، مثل الأحرف غير المدعومة أو الإصدار غير المدعوم لنظام التشغيل. تغطي هذه الفحوصات معظم الميزات المذكورة أدناه وليس جميعها؛ نوصيك بقراءة بقية هذا القسم بعناية للتأكد من أن عملية التوزيع الخاصة بك تسير بسلاسة.
يمكن تثبيت تقييم cmdlet عن طريق تثبيت وحدة Az PowerShell، والتي يمكن تثبيتها باتباع التعليمات هنا: تثبيت وتهيئة Azure PowerShell.
الاستخدام
يمكنك استدعاء أداة التقييم بعدة طرق مختلفة: يمكنك إجراء فحوصات النظام أو فحوصات مجموعة البيانات أو كليهما. لإجراء كل من فحص النظام ومجموعة البيانات:
Invoke-AzStorageSyncCompatibilityCheck -Path <path>
للقيام باختبار مجموعة البيانات الخاصة بك فقط:
Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks
للقيام باختبار متطلبات النظام فقط:
Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks
لعرض مجموعة النتائج في ملف CSV:
$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8
توافق نظام الملفات
Azure File Sync مدعوم فقط على وحدات تخزين NTFS المرفقة مباشرة. يعني التخزين المباشر المتصل، أو DAS، على Windows Server أن نظام تشغيل Windows Server يمتلك نظام الملفات. يمكن توفير DAS من خلال إرفاق الأقراص فعليا بخادم الملفات، أو إرفاق الأقراص الظاهرية بجهاز ظاهري لخادم الملفات (مثل جهاز ظاهري مستضاف بواسطة Hyper-V)، أو حتى من خلال iSCSI.
يتم دعم وحدات تخزين NTFS فقط؛ ReFS و FAT و FAT32 وأنظمة الملفات الأخرى غير مدعومة.
يوضح الجدول الآتي حالة التداخل لميزات نظام ملفات NTFS:
| ميزة | حالة دعم | ملاحظات |
|---|---|---|
| قوائم التحكم بالوصول (ACLs) | مدعوم بالكامل | يتم الاحتفاظ بقوائم التحكم في الوصول التقديرية على نمط Windows بواسطة Azure File Sync، ويتم فرضها بواسطة Windows Server على نقاط نهاية الخادم. يمكن أيضا فرض قوائم التحكم في الوصول عند إدخال مشاركة ملف Azure مباشرة، ولكن هذا يتطلب تكوينا إضافيا. راجع قسم الهوية للحصول على المزيد من المعلومات. |
| ارتباطات ثابته | تم التخطي | |
| ارتباطات رمزية | تم التخطي | |
| نقاط تركيب | مدعوم جزئياً | قد تكون نقاط التركيب هي جذر نقطة نهاية الخادم، ولكن يتم تخطيها إذا كانت مضمنة في مساحة اسم نقطة نهاية الخادم. |
| التقاطعات | تم التخطي | على سبيل المثال، نظام الملفات الموزعة DfrsrPrivate والمجلدات DFSRoots. |
| إعادة توزيع النقاط | تم التخطي | |
| ضغط NTFS | مدعوم جزئياً | لا تدعم Azure File Sync نقاط نهاية الخادم الموجودة على وحدة تخزين تحتوي على دليل معلومات وحدة تخزين النظام (SVI). |
| ملفات متباعدة | مدعوم بالكامل | مزامنة الملفات المتفرقة (لا يتم حظرها)، ولكنها تتم مزامنتها مع السحابة كملف كامل. إذا تغيرت محتويات الملف على السحابة (أو على خادم آخر)، فإن الملف لم يعد متفرقًًا عند تنزيل التغيير. |
| تدفقات البيانات البديلة (ADS) | محفوظة، ولكنها غير متزامنة | على سبيل المثال، لا تتم مزامنة علامات التصنيف التي تم إنشاؤها بواسطة البنية الأساسية لتصنيف الملفات. تُترك علامات التصنيف الموجودة على الملفات الموجودة على كل نقطة من نقاط نهاية الخادم كما هي. |
سيتخطى Azure File Sync أيضا بعض الملفات المؤقتة ومجلدات النظام:
| ملف/ مجلد | إشعار |
|---|---|
| pagefile.sys | ملف مخصص للنظام |
| Desktop.ini | ملف مخصص للنظام |
| thumbs.db | ملف مؤقت خاص بالصور المصغرة |
| ehthumbs.db | ملف مؤقت خاص بالصور المصغرة للوسائط |
| ~$*.* | ملف مؤقت خاص بـOffice |
| *.tmp | ملف مؤقت |
| *.laccdb | الوصول إلى ملف تأمين قاعدة البيانات |
| 635D02A9D91C401B97884B82B3BCDAEA.* | ملف المزامنة الداخلية |
| \معلومات وحدة تخزين النظام | مجلد مخصص لوحدة التخزين |
| $RECYCLE.BIN | مجلد |
| \SyncShareState | مجلد للمزامنة |
| . SystemShareInformation | مجلد للمزامنة في مشاركة ملف Azure |
إشعار
بينما تدعم Azure File Sync مزامنة ملفات قاعدة البيانات، فإن قواعد البيانات ليست حمل عمل جيد لحلول المزامنة (بما في ذلك Azure File Sync) لأن ملفات السجل وقواعد البيانات تحتاج إلى المزامنة معا، ويمكنها الخروج من المزامنة لأسباب مختلفة قد تؤدي إلى تلف قاعدة البيانات.
ضع في اعتبارك مقدار المساحة الخالية التي تحتاجها على القرص المحلي لديك
عند التخطيط لاستخدام Azure File Sync، ضع في اعتبارك مقدار المساحة الفارغة التي تحتاجها على القرص المحلي الذي تخطط للحصول على نقطة نهاية خادم عليه.
باستخدام Azure File Sync، ستحتاج إلى حساب ما يشغل مساحة على القرص المحلي فيما يلي:
عند تمكين مستويات السحابة:
- نقاط إعادة التوزيع الخاصة بالملفات المتدرجة
- قاعدة البيانات الخاصة ببيانات تعريف Azure File Sync
- مخزن حرارة Azure File Sync
- الملفات التي تم تنزيلها بالكامل في ذاكرة التخزين المؤقت النشطة (إن وجدت)
- متطلبات نهج مساحة وحدات التخزين الخالية
عند تعطيل مستويات السحابة:
- الملفات المنزلة بالكامل
- مخزن حرارة Azure File Sync
- قاعدة البيانات الخاصة ببيانات تعريف Azure File Sync
سنستخدم مثالا لتوضيح كيفية تقدير حجم المساحة الفارغة التي ستحتاجها على القرص المحلي. لنفترض أنك قمت بتثبيت عامل Azure File Sync على جهاز Azure Windows الظاهري، وتخطط لإنشاء نقطة نهاية خادم على القرص F. لديك مليون ملف وترغب في وضع كل منها في طبقات، و100,000 دليل، وحجم مجموعة أقراص 4 كيبيبايت. حجم القرص هو 1000 جيبي بايت. تريد تمكين مستويات السحابة وتعيين ضبط المساحة الخالية من وحدات التخزين إلى 20%.
- يخصص NTFS حجم مقطع تخزين لكل ملف من الملفات المتدرجة. 1 مليون ملف * حجم مجموعة 4 كيبيبايت = 4,000,000 KiB (4 غيغابايت)
إشعار
للاستفادة الكاملة من ترتيب السحابة، يوصى باستخدام أحجام نظام مجموعة NTFS أصغر (أقل من 64KiB) نظرا لأن كل ملف متدرج يشغل نظام مجموعة. أيضا، يتم تخصيص المساحة التي تشغلها الملفات المتدرجة بواسطة NTFS. لذلك، لن يظهر في أي واجهة مستخدم.
- تشغل بيانات تعريف المزامنة حجم نظام المجموعة لكل عنصر. (1 مليون ملف + 100,000 دليل) * حجم مجموعة 4 KiB = 4,400,000 KiB (4.4 غيغابايت)
- يشغل مخزن حرارة Azure File Sync 1.1 كيبيبايت لكل ملف. 1 مليون ملف * 1.1 كيبيبايت = 1,100,000 كيبيبايت (1.1 غيغابايت)
- سياسة المساحة الخالية من وحدة التخزين هي 20٪. 1000 جيبي بايت * 0.2 = 200 جيبي بايت
في هذه الحالة، سيحتاج Azure File Sync إلى مساحة حوالي 209,500,000 KiB (209.5 جيبي بايت) من مساحة الاسم هذه. أضف هذا القدر إلى أي مساحة خالية إضافية مطلوبة لمعرفة مقدار المساحة الخالية المطلوبة لهذا القرص.
تجاوز الفشل للمجموعات
- يتم دعم نظام تجاوز فشل Windows Server للمجموعات بواسطة Azure File Sync لخيار النشر "خادم الملفات للاستخدام العام". لمزيد من المعلومات حول كيفية تكوين دور "خادم الملفات للاستخدام العام" على نظام مجموعة تجاوز الفشل، راجع توزيع خادم ملفات متفاوت المسافات مكون من عقدتين.
- السيناريو الوحيد المدعوم من Azure File Sync هو نظام تجاوز فشل Windows Server للمجموعات مع الأقراص المجمعة
- لا يتم دعم تجاوز الفشل للمجموعات على "خادم ملفات توسيع النطاق لبيانات التطبيق" (SOFS) أو على وحدات التخزين المشتركة المجمعة (CSVs) أو الأقراص المحلية.
إشعار
يجب تثبيت عامل Azure File Sync على كل عقدة في نظام تجاوز الفشل للمجموعات حتى تعمل المزامنة بشكل صحيح.
إلغاء تكرار البيانات
Windows Server 2022، و Windows Server 2019، و Windows Server 2016
يتم دعم إلغاء تكرار البيانات بغض النظر عما إذا تم تمكين مستويات السحابة أو تعطيلها على نقطة نهاية خادم واحدة أو أكثر على وحدة التخزين لنظام Windows Server 2016، وWindows Server 2019، وWindows Server 2022. تفعيل Data Deduplication على وحدة تخزين مع تمكين مستويات السحابة يتيح لك التخزين المؤقت لمزيد من الملفات محليا دون تزويد المزيد من مواقع تخزين.
عند تمكين Data Deduplication على وحدة تخزين مع تمكين مستويات السحابة، سيتم تقسيم الملفات المحسنة من Dedup داخل موقع نقطة نهاية الخادم إلى طبقات مماثلة لملف عادي استنادا إلى إعدادات نهج مستويات السحابة. بمجرد أن يتم تدريج ملفات Dedup المحسنة، سيتم تشغيل مهمة جمع البيانات المهملة لإلغاء التكرار تلقائيا لاستعادة مساحة القرص عن طريق إزالة الأجزاء غير الضرورية التي لم تعد تشير إليها الملفات الأخرى الموجودة على وحدة التخزين.
لاحظ أن وفورات وحدة التخزين تنطبق فقط على الخادم؛ لن يتم إلغاء نسخ بياناتك في مشاركة ملف Azure.
إشعار
لدعم إلغاء البيانات المكررة على وحدات التخزين مع تمكين طبقات السحاب على Windows Server 2019، يجب تثبيت تحديث Windows KB4520062 - أكتوبر 2019 أو مجموعة التحديثات الشهرية لاحقا.
Windows Server 2012 R2
لا تدعم Azure File Sync إلغاء تكرار البيانات وتدرج السحابة على وحدة التخزين نفسها على Windows Server 2012 R2. إذا تم تمكين Data Deduplication على وحدة تخزين، فيجب تعطيل مستويات السحابة.
ملاحظات
إذا تم تثبيت Data Deduplication قبل تثبيت عامل Azure File Sync، فسيلزم إعادة التشغيل لدعم Data Deduplication ومستويات السحابة على وحدة التخزين نفسها.
إذا تم تمكين Data Deduplication على وحدة تخزين بعد تمكين مستويات السحابة، فستقوم مهمة تحسين إلغاء التكرار الأولية بتحسين الملفات الموجودة على وحدة التخزين غير المتدرجة بالفعل وسيكون لها التأثير التالي على مستويات السحابة:
- سيستمر نهج المساحة الحرة في تدريج الملفات وفقا للمساحة الخالية على وحدة التخزين باستخدام خريطة التمثيل اللوني.
- سيتخطى نهج التاريخ تدرج الملفات التي ربما كانت مؤهلة للتدرج في طبقات بسبب مهمة تحسين إلغاء التكرار التي تصل إلى الملفات.
بالنسبة إلى مهام تحسين Deduplication المستمرة، سيتم تأخير ترتيب السحابة مع نهج التاريخ بواسطة إعداد Data Deduplication MinimumFileAgeDays ، إذا لم يكن الملف متدرجا بالفعل.
- مثال: إذا كان إعداد MinimumFileAgeDays سبعة أيام ونهج تاريخ مستويات السحابة هو 30 يوما، فسيقوم نهج التاريخ بتدريج الملفات بعد 37 يوما.
- ملاحظة: بمجرد تدريج الملف بواسطة Azure File Sync، ستتخطى مهمة تحسين إلغاء التكرار الملف.
إذا تمت ترقية خادم يقوم بتشغيل Windows Server 2012 R2 مع تثبيت عامل Azure File Sync إلى Windows Server 2016 أو Windows Server 2019، أو Windows Server 2022، فيجب تنفيذ الخطوات التالية لدعم إلغاء تكرار البيانات ومستويات السحابة على نفس وحدة التخزين:
- قم بإلغاء تثبيت عامل Azure File Sync لـWindows Server 2012 R2 وأعد تشغيل الخادم.
- نزل عامل Azure File Sync لإصدار نظام تشغيل الخادم الجديد (Windows Server 2016 أو Windows Server 2019 أو Windows Server 2022).
- ثبت عامل Azure File Sync وأعد تشغيل الخادم.
ملحوظة: يتم الاحتفاظ بإعدادات تكوين Azure File Sync على الخادم عند إلغاء تثبيت العامل وإعادة تثبيته.
نظام الملفات الموزعة (DFS)
يدعم Azure File Sync التشغيل المتداخل مع مساحات أسماء DFS (DFS-N) والنسخ المتماثل لـDFS (DFS-R).
مساحات أسماء DFS (DFS-N):مزامنة ملفات Azure مدعومة بالكامل مع تنفيذ DFS-N. يمكنك تثبيت عامل Azure File Sync على خادم ملف واحد أو أكثر لمزامنة البيانات بين نقاط نهاية الخادم ونقطة نهاية السحابة، ثم استخدام DFS-N لتوفير خدمة مساحة الاسم. لمزيد من المعلومات، راجع نظرة عامة على مساحات أسماء DFS ومساحات أسماء DFS مع ملفات Azure.
DFS Replication (DFS-R): نظرا لأن DFS-R وAzure File Sync هما حلان للنسخ المتماثل، فإننا نوصي في معظم الحالات باستبدال DFS-R ب Azure File Sync. ومع ذلك، هناك العديد من السيناريوهات التي تريد فيها استخدام DFS-R وAzure File Sync معا:
- تقوم بالترحيل من توزيع DFS-R إلى توزيع Azure File Sync. لمزيد من المعلومات، راجع ترحيل DFS Replication (DFS-R) إلى Azure File Sync.
- لا يمكن توصيل جميع الخوادم المحلية التي تحتاج إلى نسخة من بيانات ملفك مباشرة بالإنترنت.
- تدمج خوادم الفروع البيانات في خادم موزع واحد، والذي قد ترغب في استخدام Azure File Sync بفضله.
لكي يعمل Azure File Sync وDFS-R جنبًا إلى جنب:
- يجب تعطيل مستويات سحابة Azure File Sync على وحدات التخزين التي تحتوي على مجلدات DFS-R المنسوخة.
- لا يجب تكوين نقاط نهاية الخادم على مجلدات النسخ المتماثل للقراءة فقط في DFS-R.
- يسمح بتداخل نقطة نهاية خادم واحدة فقط مع موقع DFS-R. قد تؤدي نقاط نهاية الخادم المتعددة المتداخلة مع مواقع DFS-R النشطة الأخرى إلى تعارضات.
للحصول على مزيد من المعلومات، راجع نظرة عامةعلى DFS Replicatio.
Sysprep
استخدام sysprep على خادم مثبت عليه عامل Azure File Sync غير مدعوم ويمكن أن يؤدي إلى نتائج غير متوقعة. يجب أن يجري تثبيت العامل وتسجيل الخادم بعد نشر صورة الخادم وإكمال الإعداد المصغر لنظام sysprep.
Windows Search
إذا تم تمكين ترتيب السحابة على نقطة نهاية الخادم، يتم تخطي الملفات التي تم ترتيبها ولا تتم فهرستها بواسطة Windows Search. تتم فهرسة الملفات غير المتدرجة بشكل مناسب.
إشعار
سيسبب عملاء Windows عمليات استدعاء عند البحث في مشاركة الملف إذا تم تمكين إعداد «البحث دائمًا عن أسماء الملفات محتوياتها» على جهاز العميل. يكون هذا الإعداد معطل بشكل افتراضي.
حلول Hierarchical Storage Management (HSM) الأخري
ينبغي عدم استخدام أي حلول HSM أخرى مع Azure File Sync.
الأداء والقابلية للتوسع
نظرا لأن عامل Azure File Sync يعمل على جهاز Windows Server يتصل بمشاركات ملفات Azure، يعتمد أداء المزامنة الفعال على عدد من العوامل في البنية الأساسية: Windows Server وتكوين القرص الأساسي، وعرض النطاق الترددي للشبكة بين الخادم ووحدة تخزين Azure، وحجم الملف، والحجم الإجمالي لمجموعة البيانات، والنشاط على مجموعة البيانات. نظرا لأن Azure File Sync يعمل على مستوى الملف، فإن خصائص أداء الحل المستندة إلى Azure File Sync يتم قياسها بشكل أفضل في عدد العناصر (الملفات والدلائل) التي تتم معالجتها في الثانية الواحدة.
لا يتم الكشف عن التغييرات التي تم إجراؤها على مشاركة ملف Azure باستخدام مدخل Microsoft Azure أو SMB على الفور ونسخها نسخا متماثلا مثل التغييرات التي تم إجراؤها على نقطة نهاية الخادم. لا تحتوي ملفات Azure على إعلامات تغيير أو دفتر يومية، لذلك لا توجد طريقة لبدء جلسة مزامنة تلقائيا عند تغيير الملفات. على Windows Server، تستخدم Azure File Sync دفتر يومية Windows USN لبدء جلسة عَمل مزامنة تلقائيًا عند تغيير الملفات.
للكشف عن التغييرات التي تطرأ على مشاركة Azure File، يحتوي Azure File Sync على مهمة مجدولة تسمى مهمة اكتشاف التغييرات. تعدد «وظيفة الكشف عن التغيير» كل ملف في مشاركة الملف، ثم تقارنه بإصدار المزامنة لهذا الملف. عندما تحدد مهمة الكشف عن التغيير أن الملفات قد تغيرت، يبدأ Azure File Sync جلسة مزامنة. تبدأ مهمة اكتشاف التغيير كل 24 ساعة. نظرا لأن مهمة الكشف عن التغيير تعمل عن طريق تعداد كل ملف في مشاركة Azure File، يستغرق اكتشاف التغيير وقتا أطول في مساحات الأسماء الأكبر منه في مساحات الأسماء الأصغر. بالنسبة إلى مساحات الأسماء الكبيرة، قد يستغرق الأمر وقتا أطول من مرة كل 24 ساعة لتحديد الملفات التي تم تغييرها.
لمزيد من المعلومات، راجع مقاييس أداء Azure File Syncوأهداف مقياس Azure File Sync
الهوية
تعمل Azure File Sync مع هويتك القياسية المستندة إلى AD دون أي إعداد خاص يتجاوز إعداد المزامنة. عند استخدام Azure File Sync، فإن التوقع العام هو أن معظم عمليات الوصول تمر عبر خوادم التخزين المؤقت ل Azure File Sync، بدلا من مشاركة ملف Azure. نظرا لأن نقاط نهاية الخادم موجودة على Windows Server، ولأن Windows Server دعم قوائم التحكم في الوصول على غرار AD وقوائم التحكم في الوصول على غرار Windows لفترة طويلة، فلا حاجة إلى أي شيء بخلاف ضمان انضمام خوادم ملفات Windows المسجلة في Storage Sync Service إلى المجال. سيخزن Azure File Sync قوائم التحكم في الوصول على الملفات الموجودة في مشاركة ملف Azure، وسيقوم بنسخها إلى جميع نقاط نهاية الخادم.
على الرغم من أن التغييرات التي تم إجراؤها مباشرة على مشاركة ملف Azure ستستغرق وقتا أطول للمزامنة مع نقاط نهاية الخادم في مجموعة المزامنة، فقد تحتاج أيضا إلى التأكد من أنه يمكنك فرض أذونات AD على مشاركة الملف مباشرة في السحابة أيضا. للقيام بذلك، يجب أن ينضم المجال إلى حساب التخزين الخاص بك إلى AD المحلي، تمامًا مثل كيفية انضمام خوادم ملفات Windows إلى المجال. لمعرفة المزيد حول انضمام المجال إلى حساب التخزين إلى Active Directory مملوك للعميل، راجع نظرة عامة Azure Files Active Directory .
هام
المجال الذي ينضم إلى حساب التخزين الخاص بك إلى Active Directory غير مطلوب لنشر Azure File Sync بنجاح. هذه خطوة اختيارية بدقة تسمح لمشاركة ملف Azure بفرض قوائم التحكم في الوصول المحلية عندما يقوم المستخدمون بتحميل مشاركة ملف Azure مباشرة.
الشبكات
يتصل عامل Azure File Sync بخدمة Storage Sync Service ومشاركة ملفت Azure باستخدام بروتوكول Azure File Sync REST وبروتوكول FileREST، وكلاهما يستخدم دائما HTTPS عبر المنفذ 443. لا يستخدم بروتوكول SMB مطلقا لتحميل البيانات أو تنزيلها بين Windows Server ومشاركة ملف Azure. نظرا لأن معظم المؤسسات تسمح بنسبة استخدام الشبكة HTTPS عبر المنفذ 443، كمطلب لزيارة معظم مواقع الويب، لا يلزم عادة تكوين الشبكات الخاص لنشر Azure File Sync.
هام
لا تدعم "مزامنة ملف Azure" توجيه الإنترنت. خيار توجيه الشبكة الافتراضي، «توجيه Microsoft»، مدعوم من Azure File Sync.
استنادا إلى نهج مؤسستك أو المتطلبات التنظيمية الفريدة، قد تحتاج إلى اتصال أكثر تقييدا مع Azure، وبالتالي توفر Azure File Sync العديد من الآليات لتكوين الشبكات. وفقًا لمتطلباتك، يمكنك القيام بالتالي:
- مزامنة النفق و حركة سير تحميل/تنزيل الملفات عبر ExpressRoute أو Azure VPN.
- استخدم ميزات Azure Files وAzure Networking كنقاط تقديم الخدمة ونقاط النهاية الخاصة.
- قم بتكوين Azure File Sync لدعم الوكيل في بيئتك.
- تقييد نشاط الشبكة من Azure File Sync.
تلميح
إذا كنت تريد الاتصال بمشاركة ملف Azure عبر بروتوكول Server Message Block ولكن تم حظر المنفذ 445، ففكر في استخدام SMB عبر QUIC، والذي يوفر تكوينا صفريا "SMB VPN" للوصول إلى SMB إلى مشاركات ملفات Azure باستخدام بروتوكول نقل QUIC عبر المنفذ 443. على الرغم من أن Azure Files لا تدعم SMB مباشرة عبر QUIC، يمكنك إنشاء ذاكرة تخزين مؤقت خفيفة الوزن لمشاركات ملفات Azure على جهاز ظاهري ل Windows Server 2022 Azure Edition باستخدام Azure File Sync. لمعرفة المزيد حول هذا الخيار، راجع SMB عبر QUIC باستخدام Azure File Sync.
لمعرفة المزيد حول Azure File Sync والربط الشبكي راجع اعتبارات شبكة Azure File Sync.
التشفير
عند استخدام Azure File Sync، هناك ثلاث طبقات مختلفة من التشفير يجب مراعاتها: التشفير على التخزين في وضع السكون لـWindows Server، والتشفير أثناء النقل بين عاملAzure File Sync وAzure، والتشفير في بقية بياناتك في مشاركة ملف Azure.
تشفير Windows Server في وضع السكون
توجد استراتيجيتان لتشفير البيانات على Windows Server يعملان بشكل عام مع Azure File Sync: التشفير أسفل نظام الملفات بحيث يتم تشفير نظام الملفات وجميع البيانات المكتوبة إليه، والتشفير داخل تنسيق الملف نفسه. هذه الأساليب ليست حصرية بشكل متبادل؛ يمكن استخدامها معا إذا رغبت في ذلك لأن الغرض من التشفير مختلف.
لتوفير التشفير أسفل نظام الملفات، يوفر Windows Server صندوق وارد BitLocker. BitLocker شفاف تماما ل Azure File Sync. السبب الأساسي لاستخدام آلية تشفير مثل BitLocker هو منع النقل غير المصرح به للبيانات من مركز البيانات المحلي من قبل شخص يسرق الأقراص، ومنع التحميل الجانبي لنظام تشغيل غير مصرح به لإجراء عمليات قراءة/كتابة غير مصرح بها لبياناتك. لمعرفة المزيد حول BitLocker، راجعلمحة عامة عن BitLocker.
يجب أن تعمل منتجات الجهات الخارجية التي تعمل بشكل مشابه لـBitLocker، من حيث أنها تقع أسفل وحدة تخزين NTFS، بشكل مشابه تمامًا مع Azure File Sync.
الطريقة الرئيسية الأخرى لتشفير البيانات هي تشفير دفق بيانات الملف عند حفظ التطبيق للملف. قد تقوم بعض التطبيقات بذلك في الأصل، ولكن عادة ما لا يكون الأمر كذلك. مثال على طريقة لتشفير دفق بيانات الملف هو حماية البيانات في Microsoft Azure (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. السبب الرئيسي لاستخدام آلية تشفير مثل AIP/RMS هو منع النقل الغير مصرّح للبيانات من مشاركة الملف الخاص بك من قبل الأشخاص الذين يقومون بنسخها إلى مواقع بديلة، مثل محرك أقراص USB محمول، أو إرسالها بالبريد الإلكتروني إلى شخص غير مصرح له. عند تشفير دفق بيانات الملف كجزء من تنسيق الملف، سيستمر تشفير هذا الملف على مشاركة ملف Azure.
لا تتداخل Azure File Sync مع نظام الملفات المشفرة NTFS (NTFS EFS) أو حلول تشفير الجهات الخارجية التي تقع فوق نظام الملفات ولكن أسفل دفق بيانات الملف.
التشفير أثناء النقل
إشعار
أزالت خدمة Azure File Sync الدعم ل TLS1.0 و1.1 في 1 أغسطس 2020. تستخدم جميع إصدارات عامل Azure File Sync المدعومة TLS1.2 افتراضيًا. قد يتم استخدام إصدار سابق من TLS إذا تم تعطيل TLS1.2 على الخادم الخاص بك أو تم استخدام وكيل. إذا كنت تستخدم وكيلا، نوصيك بفحص تكوين الوكيل. تدعم مناطق خدمة Azure File Sync التي تمت إضافتها بعد 5/1/2020 TLS1.2 فقط. راجع دليل الكشف عن الأخطاء وإصلاحها لمزيد من المعلومات.
يتصل عامل Azure File Sync بخدمة Storage Sync Service ومشاركة ملفت Azure باستخدام بروتوكول Azure File Sync REST وبروتوكول FileREST، وكلاهما يستخدم دائما HTTPS عبر المنفذ 443. لا ترسل Azure File Sync طلبات غير مشفرة عبر HTTP.
تمتاز حسابات تخزين Azure بمفتاح تبديل لطلب التشفير أثناء النقل، والذي يتم تمكينه افتراضيا. حتى إذا تم تعطيل مفتاح التبديل على مستوى حساب التخزين، مما يعني أن الاتصالات غير المشفرة إلى مشاركات ملفات Azure ممكنة، فإن Azure File Sync سيظل يستخدم القنوات المشفرة فقط للوصول إلى مشاركة الملفات الخاصة بك.
السبب الرئيسي لتعطيل التشفير أثناء النقل لحساب التخزين هو دعم تطبيق قديم يجب تشغيله على نظام تشغيل قديم، مثل Windows Server 2008 R2 أو توزيع Linux أقدم، والانتقال إلى مشاركة ملف Azure مباشرة. إذا توصل التطبيق القديم إلى ذاكرة التخزين المؤقت Windows Server لمشاركة الملف، فلن يكون لتبديل هذا الإعداد أي تأثير.
نوصي بشدة بضمان تمكين تشفير البيانات عند النقل.
لمزيد من المعلومات حول التشفير أثناء النقل، راجع طلب النقل الآمن في تخزين Azure .
تشفير مشاركة ملف Azure في وضع السكون
يتم تشفير جميع البيانات المخزنة في Azure Files في وضع السكون Azure storage service encryption (SSE). يعمل تشفير خدمة التخزين بشكل مشابه لـBitLocker على Windows: يتم تشفير البيانات تحت مستوى نظام الملفات. نظرًا لأن البيانات مشفرة أسفل نظام ملفات مشاركة ملفات Azure، نظرًا لأنها مشفرة على القرص، فلن تحتاج إلى الوصول إلى المفتاح الأساسي على العميل لقراءة مشاركة ملف Azure أو الكتابة إليها. ينطبق التشفير المتنقل على كل من بروتوكولات SMB وNFS.
بشكل افتراضي، يتم تشفير البيانات المخزنة في Azure Files باستخدام مفاتيح مدارة من Microsoft. باستخدام المفاتيح التي تديرها Microsoft، تحتفظ Microsoft بمفاتيح تشفير / فك تشفير البيانات، وهي مسؤولة عن تدويرها بشكل منتظم. يمكنك أيضًا اختيار إدارة المفاتيح الخاصة بك، مما يمنحك التحكم في عملية التدوير. إذا اخترت تشفير مشاركات الملفات باستخدام المفاتيح التي يديرها العميل، فإن Azure Files مفوض للوصول إلى المفاتيح الخاصة بك لتلبية طلبات القراءة والكتابة من عملائك. باستخدام المفاتيح التي يديرها العميل، يمكنك إبطال هذا التفويض في أي وقت، ولكن هذا يعني أن مشاركة ملف Azure الخاصة بك لن يكون من الممكن الوصول إليها عبر SMB أو FileREST API.
تستخدمAzure Files نفس نظام التشفير مثل خدمات تخزين Azure الأخرى مثل تخزين Azure Blob. لمعرفة المزيد حول Azure storage service encryption (SSE)، راجع Azure storage encryption للبيانات الثابتة.
طبقات التخزين
تقدم Azure Files مستويين مختلفين من الوسائط للتخزين، SSD وHDD، مما يسمح لك بتخصيص مشاركاتك وفقا لمتطلبات الأداء والسعر للسيناريو الخاص بك:
SSD (Premium): تستخدم مشاركات الملفات المتميزة من قبل محركات الأقراص ذات الحالة الصلبة (SSD) وتوفر أداء عاليا ثابتا وزمن انتقال منخفضا، ضمن ميلي ثانية مكونة من رقم واحد لمعظم عمليات الإدخال والإخراج، لأحمال العمل كثيفة الإدخال والإخراج. تعد مشاركات الملفات المميزة مناسبة لمجموعة متنوعة من أحمال العمل مثل قواعد البيانات واستضافة مواقع الويب وبيئات التطوير. يمكن استخدام مشاركات الملفات المتميزة مع بروتوكولات Server Message Block (SMB) ونظام ملفات الشبكة (NFS). يتم نشر مشاركات الملفات المميزة في نوع حساب تخزين FileStorage ولا تتوفر إلا في نموذج فوترة متوفر. لمزيد من المعلومات حول نموذج الفوترة المخصص لمشاركات الملفات المتميزة، راجع فهم التوفير لمشاركات الملفات المتميزة. تقدم مشاركات الملفات المتميزة اتفاقية مستوى خدمة ذات قابلية وصول أعلى من مشاركات الملفات القياسية (راجع "Azure Files Premium Tier").
HDD (قياسي): تستخدم مشاركات الملفات القياسية محركات الأقراص الثابتة (HDDs) وتوفر خيار تخزين فعال من حيث التكلفة لمشاركات الملفات للأغراض العامة. يتم نشر مشاركات الملفات القياسية في نوع حساب التخزين للأغراض العامة الإصدار 2 (GPv2). للحصول على معلومات حول اتفاقية مستوى الخدمة، راجع صفحة اتفاقيات مستوى الخدمة Azure (راجع "حسابات التخزين"). تستخدم مشاركات الملفات القياسية نموذج الدفع أولا بأول الذي يوفر التسعير المستند إلى الاستخدام. تمكنك طبقة الوصول لمشاركة الملف من ضبط تكاليف التخزين مقابل تكلفة IOPS لتحسين فاتورتك الإجمالية:
- تقدم مشاركات الملفات المحسنة للمعاملات أسعار المعاملات الأقل تكلفة لأحمال العمل الثقيلة للمعاملات التي لا تحتاج إلى زمن انتقال منخفض تقدمه مشاركات الملفات المتميزة. يوصى به أثناء ترحيل البيانات إلى Azure Files.
- تقدم مشاركات الملفات الساخنة تخزينا متوازنا وتسعير المعاملات لأحمال العمل التي لها مقياس جيد لكليهما.
- تقدم مشاركات الملفات الباردة أسعار التخزين الأكثر كفاءة من حيث التكلفة لأحمال العمل كثيفة التخزين.
عند تحديد مستوى وسائط لحمل العمل الخاص بك، ضع في اعتبارك متطلبات الأداء والاستخدام. إذا كان حمل العمل يتطلب زمن انتقال مكونا من رقم واحد، أو كنت تستخدم وسائط تخزين SSD محليا، فمن المحتمل أن يكون المستوى المتميز هو الأنسب. إذا لم يكن وقت الاستجابة البطيء مصدر قلق كبير، على سبيل المثال مع مشاركات الفريق المثبتة محليًا من Azure أو المخزنة مؤقتًا في أماكن العمل باستخدام Azure File Sync، فقد يكون التخزين القياسي مناسبًا بشكل أفضل من منظور التكلفة.
بمجرد إنشاء مشاركة ملف في حساب تخزين، لا يمكنك نقلها إلى مستويات حصرية إلى أنواع مختلفة من حسابات التخزين. على سبيل المثال، لنقل مشاركة ملف محسّنة للمعاملة إلى الطبقة المميزة، يجب عليك إنشاء مشاركة ملف جديدة في حساب تخزين FileStorage ونسخ البيانات من مشاركتك الأصلية إلى مشاركة ملف جديدة في حساب FileStorage. نوصي باستخدام AzCopy لنسخ البيانات بين مشاركات ملفات Azure، ولكن يمكنك أيضًا استخدام أدوات مثل robocopy على Windows أو rsync لنظامي التشغيل macOS و Linux.
راجع فهم فوترة ملفات Azure لمزيد من المعلومات.
التوفر الإقليمي
حاليا، تحتوي مشاركات الملفات القياسية مع مشاركة الملفات الكبيرة الممكنة (حتى سعة 100 تيرابايت) على قيود معينة.
- يتم دعم حسابات التخزين المتكرر محليا (LRS) والتخزين المتكرر للمنطقة (ZRS) فقط.
- بمجرد تمكين مشاركات الملفات الكبيرة على حساب تخزين، لا يمكنك تحويل حساب التخزين لاستخدام التخزين المتكرر جغرافيا (GRS) أو التخزين المتكرر للمنطقة الجغرافية (GZRS).
- بمجرد تمكين مشاركات الملفات الكبيرة، لا يمكنك تعطيلها.
إذا كنت ترغب في استخدام GRS أو GZRS مع مشاركات ملفات SMB Azure القياسية، فشاهد التكرار الجغرافي لملفات Azure لمعاينة مشاركات الملفات الكبيرة.
توفر منطقة مزامنة ملف Azure
لمعرفة التوافر الإقليمي، راجع المنتجات المتوفرة وفق المنطقة.
تتطلب المناطق التالية طلب الوصول إلى Azure Storage قبل أن تتمكن من استخدام Azure File Sync معها:
- جنوب فرنسا
- جنوب غرب أفريقيا
- الإمارات العربية المتحدة، الوسط
اتبع العملية الواردة في هذا المستند لطلب الوصول لهذه المناطق.
التكرار
لحماية البيانات في مشاركات ملفات Azure من فقدان البيانات أو تلفها، تخزن Azure Files نسخا متعددة من كل ملف كما هي مكتوبة. اعتمادا على متطلباتك، يمكنك تحديد درجات مختلفة من التكرار. تدعمAzure Files حاليًا خيارات تكرار البيانات التالية:
- تخزين مكرر محليًا (LRS) : باستخدام LRS، يتم تخزين كل ملف ثلاث مرات داخل مجموعة تخزين Azure. يحمي هذا من فقدان البيانات بسبب أخطاء الأجهزة، مثل محرك أقراص غير جيد. ومع ذلك، إذا حدثت كارثة مثل الحريق أو الفيضانات داخل مركز البيانات، فقد تفقد جميع النسخ المتماثلة لحساب التخزين باستخدام LRS أو لا يمكن استردادها.
- التخزين المتكرر للمنطقة (ZRS): مع ZRS، يتم تخزين ثلاث نسخ من كل ملف. ومع ذلك، يتم عزل هذه النسخ فعليا في ثلاث مجموعات تخزين مميزة في مناطق توفر Azure مختلفة. مناطق التوفر هي مواقع مادية فريدة داخل منطقة Azure. تتكون كل منطقة من مركز بيانات واحد أو أكثر مزود بشبكات وتبريد ومصدر طاقة مستقل. لا يتم قبول الكتابة إلى التخزين حتى تتم كتابتها إلى مجموعات التخزين في جميع مناطق التوفر الثلاث.
- التخزين المتكرر جغرافيا (GRS): باستخدام GRS، لديك منطقتين، منطقة أساسية ومنطقة ثانوية. يتم تخزين الملفات ثلاث مرات داخل نظام مجموعة تخزين Azure في المنطقة الأساسية. يتم نسخ عمليات الكتابة على نحوٍ غير متزامن إلى منطقة ثانوية تحددها Microsoft. يوفر GRS ست نسخ من بياناتك الموزعة بين منطقتي Azure. في حالة حدوث كارثة كبرى مثل الخسارة الدائمة لمنطقة Azure بسبب كارثة طبيعية أو حدث مشابه آخر، ستقوم Microsoft بإجراء تجاوز الفشل. في هذه الحالة، يصبح الثانوي الأساسي، ويخدم جميع العمليات. نظرا لأن النسخ المتماثل بين المناطق الأساسية والثانوية غير متزامن، في حالة حدوث كارثة كبرى، سيتم فقدان البيانات التي لم يتم نسخها نسخا متماثلا بعد إلى المنطقة الثانوية. يمكنك أيضًا إجراء تجاوز فشل يدوي لحساب تخزين متكرر جغرافيًا.
- التخزين المتكرر للمنطقة الجغرافية (GZRS): يمكنك التفكير في GZRS على أنه ZRS، ولكن مع التكرار الجغرافي. باستخدام تخزين GZRS، تُخزَّن الملفات ثلاث مرات عبر ثلاث نُظم مجموعات تخزين مميزة في المنطقة الأساسية. ثم يتم نسخ جميع عمليات الكتابة بشكل غير متزامن إلى منطقة ثانوية تحددها Microsoft. تعمل عملية تجاوز الفشل لـGZRS بنفس طريقة GRS.
تدعم مشاركات ملفات Azure القياسية ما يصل إلى 5 تيرابايت جميع أنواع التكرار الأربعة. تدعم مشاركات الملفات القياسية التي يزيد حجمها عن 5 تيرابايت LRS وZRS فقط. تدعم مشاركات ملف Azure Premium LRS وZRS فقط.
توفر حسابات تخزين الإصدار 2 للأغراض العامة (GPv2) خيارين آخرين للتكرار لا تدعمهما Azure Files: قراءة التخزين المتكرر جغرافيا (RA-GRS) الذي يمكن الوصول إليه وقراءة التخزين المتكرر للمنطقة الجغرافية (RA-GZRS). يمكنك توفير مشاركات ملفات Azure في حسابات التخزين مع تعيين هذه الخيارات، ولكن ملفات Azure لا تدعم القراءة من المنطقة الثانوية. تتم فوترة مشاركات ملفات Azure المنشورة في حسابات تخزين RA-GRS أو RA-GZRS ك GRS أو GZRS، على التوالي.
هام
التخزين المتكرر جغرافيا والمكرر للمنطقة الجغرافية لديه القدرة على تجاوز الفشل يدويا في التخزين إلى المنطقة الثانوية. نوصي بعدم القيام بذلك خارج الكارثة عند استخدام Azure File Sync بسبب زيادة احتمال فقدان البيانات. في حالة حدوث كارثة حيث ترغب في بدء تجاوز فشل يدوي للتخزين، ستحتاج إلى فتح حالة دعم مع Microsoft للحصول على Azure File Sync لاستئناف المزامنة مع نقطة النهاية الثانوية.
الترحيل
إذا كان لديك Windows file server 2012R2 موجود أو أحدث، فيمكن تثبيت Azure File Sync مباشرة في مكانه، دون الحاجة إلى نقل البيانات إلى خادم جديد. إذا كنت تخطط للترحيل إلى خادم ملفات Windows جديد كجزء من اعتماد Azure File Sync، أو إذا كانت بياناتك موجودة حاليا على التخزين المرفق بالشبكة (NAS)، فهناك العديد من أساليب الترحيل المحتملة لاستخدام Azure File Sync مع هذه البيانات. يعتمد نهج الترحيل الذي يجب عليك اختياره على مكان تواجد بياناتك حاليا.
راجع مقالة نظرة عامة على ترحيل مشاركة ملف Azure ومزامنة ملفات Azure للحصول على إرشادات مفصلة.
برنامج حماية من الفيروسات
نظرا لأن برنامج الحماية من الفيروسات يعمل عن طريق فحص الملفات بحثا عن تعليمات برمجية ضارة معروفة، فقد يتسبب منتج مكافحة الفيروسات في استدعاء الملفات المتدرجة، مما يؤدي إلى ارتفاع رسوم الخروج. تحتوي الملفات المتدرجة على مجموعة سمات FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS Windows الآمنة، ونوصي بالتشاور مع بائع البرامج لمعرفة كيفية تكوين حلها لتخطي قراءة الملفات باستخدام مجموعة السمات هذه (يقوم العديد منها بذلك تلقائيا).
حلول Microsoft لمكافحة الفيروسات الداخلية، Windows Defender وSystem Center Endpoint Protection (SCEP)، كلاهما يتخطى تلقائيا قراءة الملفات التي تحتوي على هذه المجموعة من السمات. لقد اختبرناها وحددنا مشكلة واحدة بسيطة: عندما تضيف خادمًا إلى مجموعة مزامنة حالية، يتم استرجاع (تنزيل) الملفات الأصغر من 800 بايت على الخادم الجديد. ستبقى هذه الملفات على الخادم الجديد ولن يتم ترتيبها لأنها لا تفي بمتطلبات حجم الطبقات (>64 كيلوبايت).
إشعار
يمكن لموردي برامج الحماية من الفيروسات التحقق من التوافق بين منتجاتهم وAzure File Sync باستخدام Azure File Sync Antivirus Compatibility Test Suite، المتوفرة للتنزيل على Microsoft Download Center.
نسخة احتياطية
إذا تم تمكين ترتيب السحابة، فلن يتم استخدام الحلول التي تقوم مباشرة بنسخ نقطة نهاية الخادم أو الجهاز الظاهري الذي توجد عليه نقطة نهاية الخادم. تؤدي مستويات السحابة إلى تخزين مجموعة فرعية فقط من بياناتك على نقطة نهاية الخادم، مع وجود مجموعة البيانات الكاملة في مشاركة ملف Azure. اعتمادا على حل النسخ الاحتياطي المستخدم، سيتم إما تخطي الملفات المتدرجة وعدم نسخها احتياطيا (لأنها تحتوي FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS على مجموعة السمات)، أو سيتم استدعائها إلى القرص، ما يؤدي إلى رسوم خروج عالية. نوصي باستخدام حل النسخ الاحتياطي السحابي لإجراء نسخ احتياطي لمشاركة ملفات Azure بشكل مباشر. لمزيد من المعلومات، راجع حول النسخ الاحتياطي لمشاركة ملفات Azure أو تواصل مع موفر النسخ الاحتياطي لمعرفة ما إذا كان يدعم النسخ الاحتياطي لمشاركات ملفات Azure.
إذا كنت تفضل استخدام حل نسخ احتياطي محلي، يجب إجراء النسخ الاحتياطية على خادم في مجموعة المزامنة التي تم تعطيل ترتيب السحابة فيها وتأكد من عدم وجود ملفات متدرجة. عند القيام بعملية استعادة، استخدم خيارات الاستعادة على مستوى وحدة التخزين أو على مستوى الملف. ستتم مزامنة الملفات المستعادة باستخدام خيار الاستعادة على مستوى الملف إلى جميع نقاط النهاية في مجموعة المزامنة، وسيتم استبدال الملفات الموجودة بالإصدار المستعاد من النسخة الاحتياطية. لن تحل عمليات الاستعادة على مستوى وحدة التخزين محل إصدارات الملفات الأحدث في مشاركة ملف Azure أو نقاط نهاية الخادم الأخرى.
إشعار
يمكن أن تؤدي استعادة جهاز بلا نظام تشغيل (BMR) واستعادة الجهاز الظاهري واستعادة النظام (استعادة نظام التشغيل المضمن في Windows) واستعادة مستوى الملف مع إصداره المتدرج (يحدث هذا عندما يقوم برنامج النسخ الاحتياطي بنسخ ملف متدرج احتياطيا بدلا من ملف كامل) إلى نتائج غير متوقعة ولا يتم دعمه حاليا عند تمكين ترتيب السحابة. يتم دعم لقطات خدمة نُسخ الظل الاحتياطية لوحدات التخزين (بما في ذلك علامة التبويب الإصدارات السابقة) على وحدات التخزين التي تم تمكين مستويات السحابة عليها. ومع ذلك، ينبغي تمكين توافق الإصدار السابق من خلال PowerShell. تعرف على الكيفية.
Data Classification
إذا كان لديك برنامج تصنيف بيانات مثبت، فقد يؤدي تمكين ترتيب السحابة إلى زيادة التكلفة لسببين:
مع تمكين ترتيب السحابة، يتم تخزين ملفاتك الأكثر سخونة مؤقتا محليا، ويتم ترتيب ملفاتك الأكثر روعة إلى مشاركة ملف Azure في السحابة. إذا كان تصنيف البيانات الخاص بك يقوم بمسح جميع الملفات في مشاركة الملفات بانتظام، فيجب استرجاع الملفات المتدرجة إلى السحابة عند فحصها.
إذا كان برنامج تصنيف البيانات يستخدم بيانات التعريف في دفق البيانات الخاص بالملف، فيجب استرجاع الملف بالكامل حتى يتمكن البرنامج من التعرف على التصنيف.
هذه الزيادات في كل من عدد عمليات الاسترجاع وقدر البيانات التي يتم استرجاعها يمكن أن تزيد من التكاليف.
نهج تحديث عامل Azure File Sync
يتم تحديث عامل Azure File Sync بانتظام لإضافة وظائف جديدة ومعالجة المشكلات. نوصي بتحديث عامل Azure File Sync حيث تتوفر إصدارات جديدة.
إصدارات العامل الرئيسية مقابل إصدارات العامل الثانوية
- غالبا ما تحتوي إصدارات العامل الرئيسية على ميزات جديدة ولها عدد متزايد كجزء أول من رقم الإصدار. على سبيل المثال: 14.0.0.0
- تسمى إصدارات العامل الثانوية أيضا "تصحيحات" ويتم إصدارها بشكل متكرر أكثر من الإصدارات الرئيسية. غالبا ما تحتوي على إصلاحات للأخطاء وتحسينات أصغر ولكن لا توفر ميزات جديدة. على سبيل المثال: 14.1.0.0
ترقية مسارات
توجد خمس طرق معتمدة ومختبرة لتثبيت تحديثات عامل Azure File Sync.
- استخدام ميزة الترقية التلقائية لعامل Azure File Sync لتثبيت تحديثات العامل. سيقوم عامل Azure File Sync بالترقية التلقائية. يمكنك التحديد لتثبيت أحدث إصدار من العامل عند توفره أو التحديث عند اقتراب انتهاء صلاحية العامل المثبت حالياً. لمعرفة المزيد، راجع إدارة دورة حياة العامل التلقائي.
- تكوين Microsoft Update لتنزيل تحديثات العامل وتثبيتها تلقائياً. نوصي بتثبيت كل تحديث من تحديثات Azure File Sync للتأكد من أن لديك حق الوصول إلى أحدث الإصلاحات لعامل الخادم. يجعل Microsoft Update هذه العملية سلسة من خلال تنزيل التحديثات وتثبيتها تلقائيا لك.
- استخدم AfsUpdater.exe لتنزيل تحديثات العامل وتثبيتها. تتواجد AfsUpdater.exe في دليل تثبيت العامل. انقر نقرا مزدوجا فوق الملف القابل للتنفيذ لتنزيل تحديثات العامل وتثبيتها. اعتمادا على إصدار الإصدار، قد تحتاج إلى إعادة تشغيل الخادم.
- صحح عامل Azure File Sync موجود باستخدام ملف تصحيح Microsoft Update أو ملف .msp قابل للتنفيذ. يمكن تنزيل أحدث حزمة لتحديث Azure File Sync من كاتالوج Microsoft Update. سيؤدي تشغيل ملف .msp قابل للتنفيذ إلى ترقية تثبيت Azure File Sync بنفس الطريقة المستخدمة تلقائيا بواسطة Microsoft Update. سيعمل تطبيق تصحيح Microsoft Update على إجراء ترقية موضعية لتثبيت Azure File Sync.
- قم بتنزيل أحدث مثبت عامل Azure File Sync من مركز تنزيل Microsoft. لترقية تثبيت عامل Azure File Sync موجود، قم بإزالة تثبيت الإصدار الأقدم ثم ثبت أحدث إصدار من المثبت الذي تم تنزيله. يحتفظ مثبت Azure File Sync بتسجيل الخادم ومجموعات المزامنة وأي إعدادات أخرى.
إشعار
لا يتم دعم الرجوع إلى إصدار أدنى من عامل Azure File Sync. غالبا ما تتضمن الإصدارات الجديدة تغييرات فاصلة عند مقارنتها بالإصدارات القديمة، ما يجعل عملية الرجوع إلى إصدار أقدم غير مدعومة. في حالة مواجهة أي مشاكل مع إصدار الوكيل الحالي، تواصل مع الدعم أو الترقية إلى أحدث إصدار متوفر.
إدارة دورة حياة العامل بشكل تلقائي
سيقوم عامل Azure File Sync بالترقية التلقائية. بإمكانك تحديد أي من الوضعين وتحديد نافذة صيانة تتم فيها محاولة الترقية على الخادم. تم تصميم هذه الميزة لمساعدتك في إدارة دورة حياة العامل إما عن طريق توفير حاجز حماية يمنع العامل من انتهاء الصلاحية أو السماح بإعداد دائم بدون متاعب.
- سيعمل الإعداد الافتراضي على منع انتهاء صلاحية العامل. في غضون 21 يوما من تاريخ انتهاء الصلاحية المنشور للعامل، سيحاول العامل الترقية الذاتية. سيبدأ في محاولة الترقية مرة واحدة في الأسبوع في غضون 21 يوما قبل انتهاء الصلاحية وفي نافذة الصيانة المحددة. لا يلغي هذا الخيار الحاجة إلى أخذ تصحيحات Microsoft Update العادية.
- يمكنك تحديد أن العامل سيقوم تلقائيا بترقية نفسه بمجرد توفر إصدار عامل جديد بشكل اختياري (لا ينطبق على الخوادم المجمعة في الوقت الحالي). سيحدث هذا التحديث أثناء فترة الصيانة المحددة ويسمح للخادم بالاستفادة من الميزات والتحسينات الجديدة بمجرد توفرها بشكل عام. هذا هو الإعداد الموصى به والخالي من مسببات القلق والذي سيوفر إصدارات العامل الرئيسية بالإضافة إلى تصحيحات التحديث المنتظمة لخادمك. كل عامل يتم إصداره هو بجودة GA. إذا قمت بتحديد هذا الخيار، فستقوم Microsoft بإرسال أحدث إصدار من العامل إليك. تستبعد الخوادم المجمعة. بمجرد اكتمال الإرسال، سيصبح العامل متاحا أيضا على Microsoft Download Center aka.ms/AFS/agent.
تغيير إعداد الترقية تلقائيًا
توضح الإرشادات الآتية كيفية تغيير الإعدادات بعد إكمال المثبت، إذا كنت بحاجة إلى إجراء تغييرات.
افتح وحدة تحكم PowerShell وانتقل إلى الدليل حيث قمت بتثبيت عامل المزامنة، ثم قم باستيراد أوامر cmdlets للخادم. سيبدو هذا شيئا من هذا القبيل بشكل افتراضي:
cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll
يمكنك تشغيل Get-StorageSyncAgentAutoUpdatePolicy للتحقق من إعداد النهج الحالي وتحديد ما إذا كنت ترغب بتغييره أم لا.
لتغيير إعداد النهج الحالي إلى مسار التحديث المؤجل، يمكنك استخدام:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration
لتغيير إعداد النهج الحالي إلى مسار التحديث الفوري، يمكنك استخدام:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>
ضمانات إدارة التغيير ودورة حياة العامل
Azure File Sync هي خدمة سحابية تقدم باستمرار ميزات وتحسينات جديدة. وهذا يعني أنه لا يمكن دعم إصدار معين من عامل Azure File Sync إلا لفترة محدودة. لتسهيل عملية النشر، تضمن لك القواعد الآتية أن يكون لديك ما يكفي من الوقت والإخطارات لاستيعاب تحديثات/ترقيات العامل في عملية إدارة التغيير:
- يتم دعم إصدارات العامل الرئيسية لمدة ستة أشهر على الأقل من تاريخ الإصدار الأولي.
- نحن نضمن وجود تداخل لمدة ثلاثة أشهر على الأقل بين دعم إصدارات العامل الرئيسية.
- يتم إصدار تحذيرات للخوادم المسجلة التي تستخدم عامل قريبا من انتهاء الصلاحية قبل ثلاثة أشهر على الأقل من انتهاء الصلاحية. يمكنك التحقق مما إذا كان الخادم المسجل يستخدم إصدارا قديما من العامل ضمن قسم الخوادم المسجلة في Storage Sync Service.
- ترتبط مدة بقاء إصدار عامل ثانوي بالإصدار الرئيسي المقترن. على سبيل المثال، عند تعيين إصدار العامل 14.0.0.0 على انتهاء الصلاحية، سيتم تعيين إصدارات العامل 14.*.*.* لتنتهي صلاحيتها معا.
إشعار
تثبيت إصدار عامل مع تحذير انتهاء الصلاحية سيعرض تحذيرًا ولكنه ينجح. محاولة التثبيت أو الاتصال بإصدار عامل منتهية الصلاحية غير مدعومة وسيتم حظرها.