إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
Azure File Sync هي خدمة يمكنك استخدامها لتخزين العديد من مشاركات ملفات Azure مؤقتا على مثيل Windows Server محلي أو جهاز ظاهري سحابي (VM).
تقدم لك هذه المقالة مفاهيم ومميزات Azure File Sync. بعد أن تكون على دراية ب Azure File Sync، ضع في اعتبارك اتباع دليل توزيع Azure File Sync لتجربة هذه الخدمة.
يتم تخزين الملفات في السحابة في مشاركات ملفات Azure. يمكنك استخدام مشاركات ملفات Azure بطريقتين التاليتين. يغير خيار النشر الذي تختاره الجوانب التي تحتاج إلى مراعاتها أثناء التخطيط للنشر.
تحميل مشاركة ملف Azure مباشرة باستخدام بروتوكول Server Message Block (SMB): نظرا لأن Azure Files يوفر الوصول إلى SMB، يمكنك تحميل مشاركات ملفات Azure محليا أو في السحابة باستخدام عميل SMB القياسي المتوفر في Windows وmacOS وLinux. نظرا لأن مشاركات ملفات Azure بلا خادم، فإن النشر لسيناريوهات الإنتاج لا يتطلب إدارة خادم ملفات أو جهاز تخزين متصل بالشبكة (NAS). يعني هذا الاختيار أنك لست مضطرا إلى تطبيق تصحيحات البرامج أو تبديل الأقراص الفعلية.
تخزين مشاركة ملف Azure مؤقتا محليا باستخدام Azure File Sync: باستخدام Azure File Sync، يمكنك مركزية مشاركات ملفات مؤسستك في Azure Files مع الحفاظ على مرونة خادم الملفات المحلي وأدائه وتوافقه. يقوم Azure File Sync بتحويل مثيل Windows Server محلي (أو سحابي) إلى ذاكرة تخزين مؤقت سريعة لمشاركة ملف Azure.
مفاهيم الإدارة
في Azure، المورد هو عنصر يمكن إدارته تقوم بإنشائه وتكوينه داخل اشتراكات Azure ومجموعات الموارد. يتم تقديم الموارد من قبل موفري الموارد ، وهي خدمات إدارية تقدم أنواعا معينة من الموارد. لنشر Azure File Sync، ستعمل مع موردين رئيسيين:
حسابات التخزين، التي يقدمها
Microsoft.Storageموفر الموارد. حسابات التخزين هي موارد ذات مستوى أعلى تمثل مجموعة مشتركة من التخزين وIOPS ومعدل النقل حيث يمكنك نشر مشاركات الملفات الكلاسيكية أو موارد التخزين الأخرى، اعتمادا على نوع حساب التخزين. تشترك جميع موارد التخزين التي توزع في حساب التخزين في الحدود التي تنطبق على حساب التخزين هذا. تدعم مشاركات الملفات الكلاسيكية كلا من بروتوكولات مشاركة ملفات SMB وNFS، ولكن يمكنك فقط استخدام Azure File Sync مع مشاركات ملفات SMB.Note
تدعم Azure Files أيضا نشر مشاركات الملفات كمورد Azure عالي المستوى من خلال موفر الموارد
Microsoft.FileShares. ومع ذلك، نظرا لأن مشاركات الملفات هذه تدعم حاليا بروتوكول NFS فقط، فإنها غير مدعومة من قبل Azure File Sync.خدمات مزامنة التخزين، التي يقدمها
Microsoft.StorageSyncموفر الموارد. تعمل خدمات مزامنة التخزين كحاويات إدارة تمكنك من تسجيل خوادم ملفات Windows وتحديد علاقات المزامنة ل Azure File Sync.
مفاهيم إدارة مشاركة ملفات Azure
تعد مشاركات الملفات الكلاسيكية، أو مشاركات الملفات المنشورة في حسابات التخزين، الطريقة التقليدية لنشر مشاركات الملفات لملفات Azure. إنها تدعم جميع الميزات الرئيسية التي تدعمها Azure Files بما في ذلك SMB وNFS ومستويات وسائط SSD وHDD وكل نوع تكرار وفي كل منطقة. لمعرفة المزيد حول مشاركات الملفات الكلاسيكية، يرجى الاطلاع على مشاركات الملفات الكلاسيكية.
هناك نوعان رئيسيان من حسابات التخزين المستخدمة لعمليات نشر مشاركة الملفات الكلاسيكية:
-
حسابات التخزين المخصصة: يتم تمييز حسابات التخزين المتوفرة باستخدام نوع حساب التخزين
FileStorage. تسمح لك حسابات التخزين المتوفرة بنشر مشاركات الملفات الكلاسيكية المتوفرة على الأجهزة المستندة إلى SSD أو HDD. لا يمكن استخدام حسابات التخزين المتوفرة إلا لتخزين مشاركات الملفات الكلاسيكية ولا يمكن استخدامها لتخزين موارد التخزين الأخرى مثل حاويات الكائن الثنائي كبير الحجم وقوائم الانتظار والجداول. نوصي باستخدام حسابات التخزين المتوفرة لجميع عمليات نشر مشاركة الملفات الكلاسيكية الجديدة. -
حسابات تخزين الدفع أولا بأول: يتم تمييز حسابات تخزين الدفع أولا بأول باستخدام نوع حساب التخزين
StorageV2. تتيح لك حسابات تخزين الدفع أولا بأول نشر مشاركات ملفات الدفع أولا بأول على الأجهزة المستندة إلى محرك الأقراص الثابتة. يمكن استخدام حسابات تخزين الدفع أولا بأول لتخزين مشاركات الملفات الكلاسيكية وموارد التخزين الأخرى مثل حاويات الكائن الثنائي كبير الحجم أو قوائم الانتظار أو الجداول.
مفاهيم إدارة Azure File Sync
ضمن خدمة مزامنة التخزين، يمكنك نشر:
الخوادم المسجلة، والتي تمثل خادم ملفات Windows مع علاقة ثقة مع خدمة مزامنة التخزين. يمكن أن تكون الخوادم المسجلة إما خادما فرديا أو نظام مجموعة، ولكن لا يمكن تسجيل الخادم/نظام المجموعة إلا باستخدام خدمة مزامنة التخزين واحدة فقط في كل مرة.
مجموعات المزامنة، التي تحدد علاقة المزامنة بين نقطة نهاية سحابية ونقطة نهاية خادم واحدة أو أكثر. يتم الاحتفاظ بنقاط النهاية ضمن مجموعة المزامنة في تزامن مع بعضها البعض. على سبيل المثال، إذا كان لديك مجموعتان متميزتان من الملفات التي تريد إدارتها باستخدام Azure File Sync، فيمكنك إنشاء مجموعتي مزامنة وإضافة نقاط نهاية مختلفة إلى كل مجموعة مزامنة.
- نقاط نهاية السحابة، التي تمثل مشاركات ملفات Azure.
- نقاط نهاية الخادم، التي تمثل المسارات على الخوادم المسجلة التي تتم مزامنتها مع Azure Files. يمكن أن يحتوي الخادم المسجل على نقاط نهاية خادم متعددة إذا لم تتداخل مساحات الأسماء الخاصة بها.
Important
يمكنك إجراء تغييرات على مساحة اسم أي نقطة نهاية سحابية أو نقطة نهاية خادم في مجموعة المزامنة وكذلك مزامنة ملفاتك مع نقاط النهاية الأخرى في مجموعة المزامنة. إذا قمت بإجراء تغيير على نقطة نهاية السحابة (مشاركة ملف Azure) مباشرة، فيجب أولا على مهمة الكشف عن تغيير Azure File Sync اكتشاف التغييرات. تبدأ مهمة الكشف عن التغيير لنقطة نهاية سحابية مرة واحدة فقط كل 24 ساعة. لمزيد من المعلومات، راجع الأسئلة المتداولة حول Azure Files وAzure File Sync.
عدد خدمات مزامنة التخزين المطلوبة
خدمة مزامنة التخزين هي مورد Azure Resource Manager الجذر ل Azure File Sync. يدير علاقات المزامنة بين عمليات تثبيت Windows Server ومشاركات ملفات Azure. يمكن أن تحتوي كل خدمة مزامنة تخزين على مجموعات مزامنة متعددة وخوادم مسجلة متعددة.
يمكن تسجيل كل مثيل Windows Server في خدمة مزامنة تخزين واحدة فقط. بعد التسجيل، يمكن للخادم المشاركة في مجموعات مزامنة متعددة داخل خدمة مزامنة التخزين هذه باستخدام كيان Resource Manager لإنشاء نقاط نهاية الخادم على الخادم.
عند تصميم طبولوجيا Azure File Sync، تأكد من عزل البيانات بوضوح على مستوى خدمة مزامنة التخزين. على سبيل المثال، إذا كانت مؤسستك تتطلب بيئات Azure File Sync منفصلة لوحدتي عمل متميزتين، وتحتاج إلى عزل صارم للبيانات بين هذه المجموعات، فيجب عليك إنشاء خدمة مزامنة تخزين مخصصة لكل مجموعة. تجنب وضع مجموعات المزامنة لكلتا مجموعتي الأعمال ضمن نفس خدمة مزامنة التخزين، لأن هذا التكوين لن يضمن العزل الكامل.
لمزيد من الإرشادات حول عزل البيانات باستخدام اشتراكات منفصلة أو مجموعات موارد في Azure، راجع موفري موارد Azure وأنواعها.
التخطيط لطبولوجيا المزامنة المتوازنة
قبل نشر أي موارد، من المهم تخطيط ما ستفعله على خادم محلي ومشاركة ملف 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 (خارج المزامنة) ومزامنتها بشكل أسرع.
Tip
إذا كنت لا تعرف عدد الملفات والمجلدات لديك ، فتحقق من أداة TreeSize من JAM Software.
نهج منظم لخريطة التوزيع
قبل توزيع التخزين على السحابة في خطوة لاحقة، من المهم إنشاء مخطط بين المجلدات المحلية ومشاركات ملفات Azure. يعلم هذا التعيين بعدد موارد مجموعة مزامنة Azure File Sync التي ستقوم بتوفيرها ومواردها. تعمل مجموعة المزامنة على ربط مشاركة ملف Azure والمجلد الموجود على الخادم معًا، وإنشاء اتصال مزامنة.
لتحسين الخريطة وتحديد عدد مشاركات ملفات Azure التي تحتاجها، راجع الحدود وأفضل الممارسات التالية:
يُمكن للخادم الذي تم تثبيت عامل Azure File Sync عليه المزامنة مع ما يصِل إلى 30 مشاركة ملفات Azure.
يتم توزيع مشاركة ملف Azure في حساب تخزين. يجعل هذا الترتيب حساب التخزين هدفًا مقياسًا لأرقام الأداء، مثل عمليات الإدخال والإخراج في الثانية ومعدل النقل.
انتبه إلى قيود IOPS لحساب التخزين عند نشر مشاركات ملفات Azure. من الناحية المثالية، يجب تعيين مشاركات الملفات 1:1 مع حسابات التخزين. ومع ذلك، قد لا يكون هذا التعيين ممكنا دائما بسبب القيود والقيود المختلفة، سواء من مؤسستك أو من Azure. عندما يتعذر عليك نشر مشاركة ملف واحدة فقط في حساب تخزين واحد، ضع في اعتبارك المشاركات التي ستكون نشطة للغاية والمشاركات التي ستكون أقل نشاطا. لا تضع مشاركات الملفات الأكثر سخونة معا في حساب التخزين نفسه.
إذا كنت تخطط لرفع تطبيق يستخدم مشاركة ملف Azure أصلاً إلى Azure، فقد تحتاج إلى مزيد من الأداء من مشاركتك لملف Azure. إذا كان هذا النوع من الاستخدام محتملاً، حتى في المستقبل، فمن الأفضل إنشاء مشاركة ملف Azure قياسية واحدة في حساب التخزين لديك.
يوجد حد 250 حساب تخزين لكل اشتراك لكل منطقة Azure.
Tip
بناء على هذه المعلومات، غالبا ما يصبح من الضروري تجميع مجلدات متعددة من المستوى الأعلى على وحدات التخزين الخاصة بك في دليل جذر مشترك جديد. يمكنك بعد ذلك مزامنة هذا الدليل الجذر الجديد، وجميع المجلدات التي قمت بتجميعها فيه، مع مشاركة ملف Azure واحدة. تسمح تلك التقنية لك بالبقاء في حدود 30 مزامنة لمشاركة ملف Azure لكل خادم.
لا يؤثر التجميع تحت جذر مشترك على الوصول إلى بياناتك. تبقى قوائم التحكم بالوصول كما هي. ما عليك سوى ضبط أي مسارات مشاركة (مثل مشاركات SMB أو NFS) قد تكون موجودة في مجلدات الخادم المحلي التي قمت بتغييرها الآن إلى جذر مشترك. لا يتغيّر شيء آخر.
Important
إن أهم خط متجه لـ Azure File Sync هو عدد العناصر (الملفات والمجلدات) التي يجب مزامنتها. راجع أهداف مقياس Azure File Sync لمزيد من التفاصيل.
من الممكن، في حالتك، أن تتم مزامنة مجموعة من المجلدات منطقيا مع نفس مشاركة ملف Azure (باستخدام نهج الجذر المشترك المذكور سابقا). ولكن قد يكون من الأفضل إعادة تجميع المجلدات بحيث تتم مزامنتها مع مشاركتين لملفات Azure بدلا من واحدة. يمكنك استخدام ذلك الأسلوب للحفاظ على توازن عدد الملفات والمجلدات لكل مشاركة ملف عبر الخادم. يمكنك أيضا تقسيم مشاركاتك المحلية والمزامنة عبر المزيد من الخوادم المحلية، لإضافة القدرة على المزامنة مع 30 مشاركة ملفات Azure إضافية لكل خادم إضافي.
Important
إن أهم خط متجه لـ Azure File Sync هو عدد العناصر (الملفات والمجلدات) التي يجب مزامنتها. لمزيد من التفاصيل، راجع أهداف مقياس Azure File Sync.
سيناريوهات واعتبارات مزامنة الملفات الشائعة
| سيناريو المزامنة | Supported | الاعتبارات (أو القيود) | الحل (أو الحل البديل) |
|---|---|---|---|
| خادم ملفات مع أقراص/وحدات تخزين متعددة ومشاركات متعددة لنفس مشاركة ملف Azure الهدف (الدمج) | No | تدعم مشاركة ملف Azure المستهدفة (نقطة نهاية السحابة) المزامنة مع مجموعة مزامنة واحدة فقط. تدعم مجموعة المزامنة نقطة نهاية خادم واحدة فقط لكل خادم مسجل. |
1) ابدأ بمزامنة قرص واحد (وحدة التخزين الجذر الخاصة به) مع مشاركة ملف Azure المستهدفة. سيساعد البدء بأكبر قرص/وحدة تخزين في تلبية متطلبات التخزين محليا. قم بتكوين طبقات السحابة لترتيب جميع البيانات في طبقة إلى السحابة، بحيث يمكنك تحرير مساحة على قرص خادم الملفات. انقل البيانات من وحدات التخزين/المشاركات الأخرى إلى وحدة التخزين الحالية التي تتم مزامنتها. تابع الخطوات واحدة تلو الأخرى حتى يتم ترتيب جميع البيانات إلى السحابة أو ترحيلها. 2) استهداف وحدة تخزين جذر واحد (قرص) في كل مرة. استخدم طبقات السحابة لترتيب جميع البيانات في طبقات إلى مشاركة ملف Azure المستهدفة. قم بإزالة نقطة نهاية الخادم من مجموعة المزامنة، وأعد إنشاء نقطة النهاية باستخدام وحدة التخزين/القرص الجذر التالي، وقم بالمزامنة، ثم كرر العملية. لاحظ أنك قد تحتاج إلى إعادة تثبيت العامل. 3) التوصية باستخدام مشاركات ملفات Azure المستهدفة المتعددة (نفس حساب التخزين أو حساب تخزين مختلف، استنادا إلى متطلبات الأداء). |
| خادم الملفات بوحدة تخزين واحدة ومشاركات متعددة لنفس مشاركة ملف Azure الهدف (الدمج) | Yes | لا يمكن أن يكون لديك نقاط نهاية خادم متعددة لكل خادم مسجل تتم مزامنتها مع نفس مشاركة ملف Azure الهدف (مثل السيناريو السابق). | قم بمزامنة جذر وحدة التخزين التي تحتوي على مشاركات متعددة أو مجلدات المستوى الأعلى. |
| خادم الملفات الذي يحتوي على مشاركات و/أو وحدات تخزين متعددة لمشاركات ملفات Azure متعددة ضمن حساب تخزين واحد (تعيين مشاركة 1:1) | Yes | يُمكن لمثيل Windows Server واحد (أو مجموعة) مزامنة ما يصل إلى 30 مشاركة ملف Azure. حساب التخزين هو هدف مقياس للأداء. تتم مشاركة عمليات الإدخال والإخراج في الثانية ومعدل النقل عبر مشاركات الملفات. احتفظ بعدد العناصر لكل مجموعة مزامنة في حدود 100 مليون عنصر (ملفات ومجلدات) لكل مشاركة. من الأفضل البقاء أقل من 20 أو 30 مليونا للسهم الواحد. |
1) استخدام مجموعات مزامنة متعددة (عدد مجموعات المزامنة = عدد مشاركات ملفات Azure للمزامنة إليها). 2) يمكن مزامنة 30 مشاركة فقط في المرة الواحدة في هذا السيناريو. إذا كان لديك أكثر من 30 مشاركة على خادم الملفات هذا، فاستخدم تجميع المشاركة ومزامنة وحدة التخزين لتقليل عدد مجلدات الجذر أو المستوى الأعلى في المصدر. 3) استخدم خوادم Azure File Sync الإضافية محليا، وقم بتقسيم البيانات أو نقلها إلى هذه الخوادم للتغلب على القيود المفروضة على مثيل Windows Server المصدر. |
| خادم الملفات مع مشاركات و/أو وحدات تخزين متعددة لمشاركات ملفات Azure متعددة ضمن حساب تخزين مختلف (تعيين مشاركة 1:1) | Yes | يمكن لمثيل Windows Server واحد (أو نظام مجموعة) مزامنة ما يصل إلى 30 مشاركة ملف Azure (نفس حساب التخزين أو حساب تخزين مختلف). احتفظ بعدد العناصر لكل مجموعة مزامنة في حدود 100 مليون عنصر (ملفات ومجلدات) لكل مشاركة. من الأفضل البقاء أقل من 20 أو 30 مليونا للسهم الواحد. |
نفس النهج السابق. |
| خوادم ملفات متعددة بوحدة تخزين جذر واحدة أو مشاركتها في نفس مشاركة ملف Azure الهدف (الدمج) | No | لا يمكن لمجموعة المزامنة استخدام نقطة نهاية سحابية (مشاركة ملف Azure) تم تكوينها بالفعل في مجموعة مزامنة أخرى. على الرغم من أن مجموعة المزامنة يمكن أن تحتوي على نقاط نهاية خادم على خوادم ملفات مختلفة، لا يمكن أن تكون الملفات مميزة. |
اتبع الإرشادات الواردة في السيناريو الأول، مع مراعاة إضافية لاستهداف خادم ملفات واحد في كل مرة. |
| المخطط عبر المستأجرين (باستخدام الهوية المدارة عبر المستأجرين) | No | يجب أن تكون خدمة مزامنة التخزين ومورد الخادم (الخادم الذي يدعم Azure Arc أو جهاز Azure الظاهري) والهوية المدارة وتعيينات RBAC على حساب التخزين كلها في نفس مستأجر Microsoft Entra. الطبولوجيا عبر المستأجرين غير مدعومة. | تفشل الإعدادات عبر المستأجرين في المصادقة والتفويض، ولا يمكن للخادم الاتصال. للمتابعة، تأكد من إنشاء جميع الموارد (خدمة المزامنة والخادم والهوية المدارة وتعيينات RBAC) في نفس مستأجر Microsoft Entra. |
إنشاء جدول المخططات
استخدم المعلومات السابقة لتحديد عدد مشاركات ملف Azure التي تحتاجها، وأي أجزاء من بياناتك الحالية ستنتهي في أي مشاركة ملف Azure.
قم بإنشاء جدول يسجل أفكارك بحيث يمكنك الرجوع إليه عند الحاجة. يعد البقاء منظما أمرا مهما، لأن فقدان تفاصيل خطة التعيين يمكن أن يحدث بسهولة عند توفير العديد من موارد Azure في وقت واحد. نزِّل ملف Excel التالي لاستخدامه كقالب للمساعدة في إنشاء التعيين.
|
تنزيل قالب تعيين مساحة الاسم. |
اعتبارات خوادم ملفات Windows
لتفعيل إمكانية المزامنة على خادم Windows Server، يجب تثبيت عامل Azure File Sync القابل للتنزيل. يوفر عامل Azure File Sync مكونين رئيسيين:
-
FileSyncSvc.exe، وخدمة Windows الخلفية المسؤولة عن مراقبة التغييرات على نقاط نهاية الخادم وبدء جلسات المزامنة -
StorageSync.sys، عامل تصفية نظام الملفات الذي يتيح طبقات السحابة والتعافي السريع من الكوارث
متطلبات نظام التشغيل
يتم دعم Azure File Sync مع الإصدارات التالية من خوادم Windows Server:
| Version | إصدار RTM | الإصدارات المدعومة | خيارات التوزيع المدعومة |
|---|---|---|---|
| ويندوز سيرفر 2025 | 26100 | Azure وDatacenter و Essentials وStandard وIoT | الذاكرة الكاملة والأساسية |
| ويندوز سيرفر 2022 | 20348 | Azure وDatacenter و Essentials وStandard وIoT | الذاكرة الكاملة والأساسية |
| ويندوز سيرفر 2019 | 17763 | مركز البيانات والأساسيات والقياسية وIoT | الذاكرة الكاملة والأساسية |
| Windows Server 2016 | 14393 | مركز البيانات والأساسيات والقياسية وخادم التخزين | الذاكرة الكاملة والأساسية |
نوصي بتحديث كافة الخوادم التي تستخدمها مع Azure File Sync بآخر التحديثات من Windows Update.
الحد الأدنى من موارد النظام
يتطلب Azure File Sync خادما، إما فعليا أو افتراضيا، مع كل هذه السمات:
- وحدة معالجة مركزية واحدة على الأقل.
- ما لا يقل عن 2 جيجا بايت من الذاكرة. إذا كان الخادم يعمل في جهاز ظاهري مع تمكين الذاكرة الديناميكية، فقم بتكوين الجهاز الظاهري بحد أدنى 2,048 ميجابايت من الذاكرة.
- وحدة تخزين مرفقة محليا منسقة بنظام ملفات NTFS.
بالنسبة لمعظم أحمال عمل الإنتاج، لا نوصي بتكوين خادم مزامنة في Azure File Sync مع الحد الأدنى من المتطلبات فقط.
الموارد الموصى بها لللنظام
تماما مثل أي ميزة أو تطبيق خادم، يحدد مقياس التوزيع متطلبات موارد النظام ل Azure File Sync. تتطلب عمليات النشر الأكبر على الخادم موارد نظام أكبر.
بالنسبة إلى Azure File Sync، يحدد عدد الكائنات عبر نقاط نهاية الخادم والاضطراب على مجموعة البيانات المقياس. يمكن أن يحتوي خادم واحد على نقاط نهاية خادم في مجموعات مزامنة متعددة. عدد الكائنات المدرجة في الجدول التالي يمثل مساحة الاسم الكاملة التي يتم إرفاق الخادم بها.
على سبيل المثال، نقطة نهاية الخادم A مع 10 ملايين عنصر + نقطة نهاية الخادم B مع 10 ملايين عنصر = 20 مليون عنصر. بالنسبة لنشر هذا المثال، نوصي بـ8 وحدات CPU، و 16 جيجابايت من الذاكرة للحالة الثابتة، و(إن أمكن) 48 جيبي بايت من الذاكرة للترحيل الأولي.
تخزن بيانات مساحة الاسم في الذاكرة لأسباب تتعلق بالأداء. بسبب هذا التكوين ، تتطلب مساحات الأسماء الأكبر مزيدا من الذاكرة للحفاظ على الأداء الجيد. يتطلب المزيد من الاضطراب المزيد من وحدات المعالجة المركزية للمعالجة.
يوفر الجدول التالي كلا من حجم مساحة الاسم والتحويل إلى السعة لمشاركات الملفات للأغراض العامة النموذجية، حيث يبلغ متوسط حجم الملف 512 كيلوبايت. إذا كانت أحجام الملفات أصغر، ففكر في إضافة المزيد من الذاكرة لنفس القدر من السعة. أسس تكوين الذاكرة حسب حجم مساحة الاسم.
| حجم مساحة الاسم - الملفات والدلائل (بالملايين) | السعة النموذجية (بالتيبي بايت) | وحدة المعالجة المركزية | الذاكرة الموصى بها (بالجيبي بايت) |
|---|---|---|---|
| 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.
Tip
المزامنة الأولية لمساحة الاسم هي عملية مكثفة. نوصي بتخصيص المزيد من الذاكرة حتى تكتمل المزامنة الأولية. هذا الأسلوب غير مطلوب ولكنه قد يسرع المزامنة الأولية.
الاضطراب االنموذجي هو 0.5% من مساحة الاسم تتغير يوميا. للحصول على مستويات أعلى من الاضطراب ، ضع في اعتبارك إضافة المزيد من وحدات المعالجة المركزية.
cmdlet التقييم
قبل نشر Azure File Sync، يجب عليك تقييم ما إذا كان متوافقا مع نظامك باستخدام Azure File Sync تقييم cmdlet. يتحقق cmdlet هذا من المشكلات المحتملة في نظام الملفات ومجموعة البيانات الخاصة بك، مثل الأحرف غير المدعومة أو إصدار نظام التشغيل غير المدعوم. تغطي هذه الفحوصات معظم (وليس كل) الميزات المذكورة في هذه المقالة. نوصي بقراءة بقية هذا القسم بعناية للتأكد من أن النشر يسير بسلاسة.
يمكنك تثبيت cmdlet للتقييم عن طريق تثبيت الوحدة النمطية Az PowerShell. للحصول على الإرشادات، راجع تثبيت Azure PowerShell.
Usage
يمكنك استدعاء أداة التقييم عن طريق إجراء فحوصات النظام أو فحوصات مجموعة البيانات أو كليهما. لإجراء فحوصات النظام ومجموعة البيانات:
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:
| Feature | حالة الدعم | Notes |
|---|---|---|
| قوائم التحكم بالوصول (ACLs) | مدعوم بالكامل | يحتفظ Azure File Sync بقوائم التحكم في الوصول التقديرية على غرار Windows. يفرض Windows Server قوائم التحكم في الوصول هذه على نقاط نهاية الخادم. يمكنك أيضا فرض قوائم التحكم في الوصول عند تحميل مشاركة ملف Azure مباشرة، ولكن هذه الطريقة تتطلب تكوينا إضافيا. لمزيد من المعلومات، راجع قسم الهوية لاحقا في هذه المقالة. |
| ارتباطات ثابته | Skipped | |
| ارتباطات رمزية | Skipped | |
| نقاط التثبيت | مدعوم جزئيا | قد تكون نقاط التحميل هي جذر نقطة نهاية الخادم، ولكن يتم تخطيها إذا كانت مساحة اسم نقطة نهاية الخادم تحتوي عليها. |
| Junctions | Skipped | ومن الأمثلة على ذلك نظام الملفات الموزعة (DFS) DfrsrPrivate والمجلدات DFSRoots . |
| إعادة النقاط | Skipped | |
| ضغط NTFS | مدعوم جزئيا | لا يدعم Azure File Sync نقاط نهاية الخادم الموجودة على وحدة تخزين تضغط دليل معلومات وحدة تخزين النظام (SVI). |
| ملفات متفرقة | مدعوم بالكامل | تتم مزامنة الملفات المتفرقة (غير محظورة)، ولكنها تتم مزامنتها مع السحابة كملف كامل. إذا تغيرت محتويات الملف على السحابة (أو على خادم آخر)، فإن الملف لم يعد متفرقًًا عند تنزيل التغيير. |
| تدفقات البيانات البديلة (ADS) | محفوظة، ولكنها غير متزامنة | على سبيل المثال، لا تتم مزامنة علامات التصنيف التي تنشئها البنية الأساسية لتصنيف الملفات. لم يتم المساس بعلامات التصنيف الموجودة على الملفات الموجودة على كل نقطة من نقاط نهاية الخادم. |
Note
ضغط NTFS مع طبقات السحابة
يمكن أن يؤدي استخدام ضغط NTFS على الملفات المتدرجة إلى تأثير كبير على الأداء. يوصى بعدم استخدام طبقات السحابة مع الملفات المضغوطة.
إذا كانت الملفات المضغوطة قد تم تصنيفها بالفعل في طبقات، فيجب فك ضغطها بعد استدعاء البيانات من السحابة عن طريق تشغيل:
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>
يمكن أن يؤدي استخدام ضغط NTFS على الملفات المتدرجة إلى تأثير كبير على الأداء. يوصى بعدم استخدام طبقات السحابة مع الملفات المضغوطة.
يمكنك فك ضغط الملفات باستخدام أمر المضغوط .
في Windows Server 2019 أو الإصدارات الأحدث، يتخطى الأمر المضغوط الملفات المتدرجة، لذلك يجب عليك استدعاء الملف أولا قبل فك ضغطه.
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>
إذا أدى استدعاء الملفات إلى مشاكل في مساحة القرص المنخفض، يجب أن تنتظر حتى يبدأ التصنيف الخلفي ثم إعادة الترتيب قبل استدعاء المزيد من الملفات أو إعادة الترتيب بعد فك الضغط عن طريق تشغيل cmdlet
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncCloudTiering -Path <path>
يتخطى Azure File Sync أيضا بعض الملفات المؤقتة ومجلدات النظام:
| File/folder | Note |
|---|---|
pagefile.sys |
ملف خاص بالنظام |
Desktop.ini |
ملف خاص بالنظام |
thumbs.db |
ملف مؤقت خاص بالصور المصغرة |
ehthumbs.db |
ملف مؤقت خاص بالصور المصغرة للوسائط |
~$*.* |
ملف مؤقت خاص بـOffice |
*.tmp |
ملف مؤقت |
*.laccdb |
ملف تأمين قاعدة بيانات الوصول |
635D02A9D91C401B97884B82B3BCDAEA.* |
ملف المزامنة الداخلية |
\System Volume Information |
مجلد خاص بوحدة تخزين |
$RECYCLE.BIN |
Folder |
\SyncShareState |
مجلد للمزامنة |
.SystemShareInformation |
مجلد للمزامنة في مشاركة ملف Azure |
Note
على الرغم من أن 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. لديك 1 مليون ملف (وتريد تصنيفها جميعا) ، و 100,000 دليل ، وحجم مجموعة أقراص يبلغ 4 كيلو بايت. حجم القرص 1,000 جيجا بايت. تريد تمكين طبقات السحابة وتعيين سياسة المساحة الخالية من وحدة التخزين إلى 20%.
يخصص NTFS حجم نظام مجموعة لكل ملف من الملفات المتدرجة:
1 مليون ملف * حجم مجموعة 4 كيلوبايت = 4,000,000 كيلوبايت (4 جيجابايت)
للاستفادة الكاملة من طبقات السحابة، نوصي باستخدام أحجام نظام مجموعة NTFS أصغر (أقل من 64 كيلوبايت) لأن كل ملف متدرج يشغل نظام مجموعة. أيضا ، يخصص NTFS المساحة التي تشغلها الملفات المتدرجة. لا تظهر هذه المساحة في أي واجهة مستخدم.
تشغل بيانات تعريف المزامنة حجم نظام المجموعة لكل عنصر:
(1 مليون ملف + 100,000 دليل) * حجم مجموعة 4 كيلوبايت = 4,400,000 كيلوبايت (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 جيبي بايت) من مساحة الاسم هذه. أضف هذا المبلغ إلى أي مساحة خالية تعتقد أنك قد تحتاجها لهذا القرص.
تجميع تجاوز الفشل
يدعم Azure File Sync تجميع تجاوز فشل Windows Server لخيار نشر File Server للاستخدام العام . لمزيد من المعلومات حول كيفية تكوين خادم الملفات لدور الاستخدام العام على نظام مجموعة تجاوز الفشل، راجع نشر خادم ملفات متفاوت المسافات مكون من عقدتين.
السيناريو الوحيد الذي يدعمه Azure File Sync هو مجموعة تجاوز فشل Windows Server مع أقراص مجمعة. لا يتم دعم تجميع تجاوز الفشل على خادم الملفات Scale-Out أو وحدات التخزين المشتركة لنظام المجموعة (CSVs) أو الأقراص المحلية.
لكي تعمل المزامنة بشكل صحيح، يجب تثبيت عامل Azure File Sync على كل عقدة في مجموعة تجاوز الفشل.
إلغاء البيانات المكررة
Windows Server 2025 و Windows Server 2022 و Windows Server 2019 و Windows Server 2016
يتم دعم إلغاء البيانات المكررة سواء تم تمكين طبقات السحابة أو تعطيلها على نقطة نهاية خادم واحدة أو أكثر على وحدة التخزين ل Windows Server 2025 وWindows Server 2022 وWindows Server 2019 وWindows Server 2016. تفعيل Data Deduplication على وحدة تخزين مع تمكين مستويات السحابة يتيح لك التخزين المؤقت لمزيد من الملفات محليا دون تزويد المزيد من مواقع تخزين.
عند تمكين إلغاء البيانات المكررة على وحدة تخزين مع تمكين طبقات السحابة، يتم تصنيف الملفات المحسنة لإلغاء البيانات المكررة داخل موقع نقطة نهاية الخادم بشكل مشابه للملف العادي، استنادا إلى إعدادات النهج لطبقات السحابة. بعد ترتيب الملفات المحسنة لإلغاء البيانات المكررة، يتم تشغيل مهمة تجميع البيانات المكرلة تلقائيا. يستعيد مساحة القرص عن طريق إزالة الأجزاء غير الضرورية التي لم تعد الملفات الأخرى الموجودة على وحدة التخزين تشير إليها.
في بعض الحالات التي يتم فيها تثبيت إلغاء البيانات المكررة، يمكن أن تزيد مساحة وحدة التخزين المتوفرة أكثر من المتوقع بعد تشغيل تجميع البيانات المهملة لإلغاء البيانات المكررة. يصف المثال التالي كيفية عمل مساحة وحدة التخزين:
- تم تعيين نهج المساحة الحرة لطبقات السحابة إلى 20%.
- يتم إعلام Azure File Sync عندما تكون المساحة الخالية منخفضة (دعنا نقول 19%).
- يحدد الترتيب في طبقات أنه يجب تحرير مساحة واحدة% إضافية ، لكنك تريد 5% إضافية ، لذلك يمكنك وضع طبقة تصل إلى 25% (على سبيل المثال ، 30 جيجابايت).
- يتم تقسيم الملفات إلى طبقات حتى تصل إلى 30 غيغابايت.
- كجزء من قابلية التشغيل البيني مع إلغاء البيانات المكررة، يبدأ Azure File Sync جمع البيانات المهملة في نهاية جلسة الترتيب في المستويات.
تنطبق وفورات وحدة التخزين على الخادم فقط. لا يتم إلغاء تكرار بياناتك في مشاركة ملف Azure.
Note
لدعم إلغاء البيانات المكررة على وحدات التخزين مع تمكين طبقات السحابة على Windows Server 2019، يجب تثبيت Windows update KB4520062 - أكتوبر 2019 أو تحديث مجموعة التحديثات الشهرية اللاحقة.
ويندوز سيرفر 2012 R2
لا تدعم Azure File Sync إلغاء تكرار البيانات وتدرج السحابة على وحدة التخزين نفسها على Windows Server 2012 R2. إذا قمت بتمكين إلغاء البيانات المكررة على وحدة تخزين، فيجب عليك تعطيل طبقات السحابة.
Notes
إذا قمت بتثبيت إلغاء البيانات المكررة قبل تثبيت عامل Azure File Sync، فستكون إعادة التشغيل مطلوبة لدعم إلغاء البيانات المكررة وطبقات السحابة على نفس وحدة التخزين.
إذا قمت بتمكين إلغاء البيانات المكررة على وحدة تخزين بعد تمكين طبقات السحابة، فإن مهمة تحسين إلغاء البيانات المكررة الأولية تعمل على تحسين الملفات الموجودة على وحدة التخزين غير المتدرجة بالفعل. هذه الوظيفة لها التأثير التالي على طبقات السحابة:
- تستمر سياسة المساحة الحرة في ترتيب الملفات وفقا للمساحة الخالية على وحدة التخزين باستخدام خريطة التمثيل اللوني.
- يتخطى نهج التاريخ طبقات الملفات التي قد تكون مؤهلة لترتيب الطبقات لأن مهمة تحسين إلغاء البيانات المكررة تصل إلى الملفات.
بالنسبة لمهام تحسين إلغاء البيانات المكررة المستمرة، يؤخر إعداد Data Dedduplication MinimumFileAgeDays طبقات السحابة مع نهج البيانات، إذا لم يكن الملف متدرجة بالفعل.
- على سبيل المثال، إذا كان الإعداد
MinimumFileAgeDays7 أيام وكان نهج البيانات لطبقات السحابة 30 يوما، فإن نهج التاريخ يضع الملفات بعد 37 يوما. - بعد أن يقوم Azure File Sync بترتيب ملف، تتخطى مهمة تحسين إلغاء البيانات المكررة الملف.
- على سبيل المثال، إذا كان الإعداد
إذا تمت ترقية خادم يعمل بنظام التشغيل Windows Server 2012 R2 مع تثبيت عامل Azure File Sync إلى Windows Server 2025 أو Windows Server 2022 أو Windows Server 2019 أو Windows Server 2016، فيجب عليك تنفيذ الخطوات التالية لدعم إلغاء البيانات المكررة وطبقات السحابة على نفس وحدة التخزين:
- قم بإلغاء تثبيت عامل Azure File Sync لـWindows Server 2012 R2 وأعد تشغيل الخادم.
- قم بتنزيل عامل Azure File Sync لإصدار نظام تشغيل الخادم الجديد (Windows Server 2025 أو Windows Server 2022 أو Windows Server 2019 أو Windows Server 2016).
- ثبت عامل Azure File Sync وأعد تشغيل الخادم.
يحتفظ الخادم بإعدادات تكوين Azure File Sync عند إلغاء تثبيت العامل وإعادة تثبيته.
نظام الملفات الموزعة
يدعم Azure File Sync إمكانية التشغيل البيني مع مساحات أسماء DFS (DFS-N) والنسخ المتماثل DFS (DFS-R).
DFS-N
Azure File Sync مدعوم بالكامل مع تنفيذ DFS-N. يمكنك تثبيت عامل Azure File Sync على خادم ملف واحد أو أكثر لمزامنة البيانات بين نقاط نهاية الخادم ونقطة نهاية السحابة، ثم استخدام DFS-N لتوفير خدمة مساحة الاسم. لمزيد من المعلومات، راجع نظرة عامة على مساحات أسماء DFS ومساحات أسماء DFS مع ملفات Azure.
DFS-R
نظرا لأن DFS-R وAzure File Sync كلاهما حلان للنسخ المتماثل، فإننا نوصي باستبدال DFS-R ب Azure File Sync في معظم الحالات. ولكن يجب عليك استخدام DFS-R وAzure File Sync معا في السيناريوهات التالية:
- تقوم بالترحيل من توزيع DFS-R إلى توزيع Azure File Sync. لمزيد من المعلومات، راجع ترحيل توزيع 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 والنسخ المتماثل ل DFS.
Sysprep
استخدام Sysprep على خادم مثبت عليه عامل Azure File Sync غير مدعوم ويمكن أن يؤدي إلى نتائج غير متوقعة. يجب أن يحدث تثبيت العامل وتسجيل الخادم بعد نشر صورة الخادم وإكمال الإعداد المصغر ل Sysprep.
Windows Search
إذا تم تمكين طبقات السحابة على نقطة نهاية الخادم، يتخطى Windows Search الملفات المتدرجة ولا يفهرستها. يقوم Windows Search بفهرسة الملفات غير المتدرجة بشكل صحيح.
يتسبب عملاء Windows في عمليات سحب عند البحث في مشاركة الملف إذا تم تمكين إعداد البحث دائما عن أسماء الملفات ومحتوياتها على جهاز العميل. يكون هذا الإعداد معطل بشكل افتراضي.
حلول HSM الأخرى
يجب عدم استخدام أي حلول أخرى لإدارة التخزين الهرمي (HSM) مع Azure File Sync.
الأداء وقابلية التوسع
نظرا لأن عامل Azure File Sync يعمل على جهاز Windows Server يتصل بمشاركات ملفات Azure، فإن أداء المزامنة الفعال يعتمد على هذه العوامل في البنية الأساسية الخاصة بك:
- Windows Server وتكوين القرص الأساسي
- النطاق الترددي للشبكة بين الخادم وتخزين Azure
- حجم الملف
- إجمالي حجم مجموعة البيانات
- النشاط على مجموعة البيانات
يعمل Azure File Sync على مستوى الملف. يتم قياس خصائص أداء الحل المستند إلى Azure File Sync بشكل أفضل في عدد الكائنات (الملفات والدلائل) التي تتم معالجتها في الثانية.
لمزيد من المعلومات، راجع مقاييس أداء Azure File Syncوأهداف مقياس Azure File Sync
Identity
يجب أن يكون المسؤول الذي يسجل الخادم وينشئ نقطة نهاية السحابة عضوا في دور الإدارة مسؤول Azure File Sync أو المالك أو المساهم لخدمة مزامنة التخزين. يمكنك تكوين هذا الدور ضمن التحكم في الوصول (IAM) في صفحة مدخل Microsoft Azure لخدمة مزامنة التخزين.
عند تعيين دور مسؤول مزامنة ملفات Azure، اتبع هذه الخطوات لضمان أقل امتياز.
ضمن علامة التبويب الشروط، حدد السماح للمستخدمين بتعيين أدوار محددة للمديرين المحددين فقط (امتيازات أقل).
انقر فوق Select Roles and Principals ثم حدد Add Action ضمن Condition #1.
حدد إنشاء تعيين دور، ثم انقر فوق تحديد.
حدد إضافة تعبير، ثم حدد طلب.
ضمن مصدر السمة، حدد معرف تعريف الدور ضمن السمة، ثم حدد ForAnyOfAnyValues:GuidEquals ضمن عامل التشغيل.
حدد إضافة أدوار. أضف أدوار القارئ والوصول إلى البيانات والمساهم المتميز لبيانات ملف التخزين والمساهم في حساب التخزين ، ثم حدد حفظ.
يعمل Azure File Sync مع الهوية القياسية المستندة إلى Active Directory دون أي إعداد خاص يتجاوز إعداد المزامنة. عند استخدام Azure File Sync، فإن التوقع العام هو أن معظم عمليات الوصول تمر عبر خوادم التخزين المؤقت ل Azure File Sync، بدلا من مشاركة ملف Azure. نظرا لأن نقاط نهاية الخادم موجودة على Windows Server، ويدعم Windows Server قوائم التحكم في الوصول (ACL) على غرار Windows، فلن تحتاج إلى أي شيء بخلاف التأكد من أن خوادم ملفات Windows المسجلة في خدمة مزامنة التخزين مرتبطة بالمجال. يخزن Azure File Sync قوائم التحكم في الوصول على الملفات الموجودة في مشاركة ملف Azure، ويقوم بنسخ قوائم التحكم في الوصول هذه إلى جميع نقاط نهاية الخادم.
على الرغم من أن التغييرات التي تم إجراؤها مباشرة على مشاركة ملف Azure تستغرق وقتا أطول للمزامنة مع نقاط نهاية الخادم في مجموعة المزامنة، فقد ترغب أيضا في التأكد من أنه يمكنك فرض أذونات Active Directory على مشاركة الملفات مباشرة في السحابة. لإجراء هذا التكوين، يجب أن ينضم المجال إلى حساب التخزين الخاص بك إلى مثيل Active Directory المحلي، تماما مثل كيفية ضم مشروعات ملفات Windows إلى المجال. لمعرفة المزيد حول المجال الذي ينضم إلى حساب التخزين الخاص بك إلى مثيل Active Directory مملوك للعميل، راجع نظرة عامة على المصادقة المستندة إلى هوية Azure Files للوصول إلى SMB.
Important
لا يلزم ضم المجال إلى حساب التخزين الخاص بك إلى Active Directory لنشر Azure File Sync بنجاح. إنها خطوة اختيارية تسمح لمشاركة ملف Azure بفرض قوائم التحكم في الوصول المحلية عندما يقوم المستخدمون بتحميل مشاركة ملف Azure مباشرة.
الشبكات
يتصل عامل Azure File Sync بخدمة مزامنة التخزين ومشاركة ملف Azure باستخدام بروتوكول Azure File Sync REST وبروتوكول FileREST. يستخدم كلا البروتوكولين دائما HTTPS عبر المنفذ 443. لا يتم استخدام SMB أبدا لتحميل البيانات أو تنزيلها بين مثيل Windows Server ومشاركة ملف Azure. نظرا لأن معظم المؤسسات تسمح بحركة مرور HTTPS عبر المنفذ 443 كشرط لزيارة معظم مواقع الويب، عادة ما لا يكون تكوين شبكة خاص مطلوبا لنشر Azure File Sync.
Important
لا تدعم "مزامنة ملف Azure" توجيه الإنترنت. يدعم Azure File Sync خيار توجيه الشبكة الافتراضي، توجيه Microsoft.
استنادا إلى نهج مؤسستك أو المتطلبات التنظيمية الفريدة، قد تحتاج إلى اتصال أكثر تقييدا مع Azure. يوفر Azure File Sync العديد من الآليات لتكوين الشبكات. وفقًا لمتطلباتك، يمكنك القيام بالتالي:
- مزامنة النفق وتحميل / تنزيل نسبة استخدام الشبكة للملفات عبر Azure ExpressRoute أو شبكة Azure الخاصة الظاهرية (VPN).
- استفد من ميزات Azure Files وشبكة Azure، مثل نقاط نهاية الخدمة ونقاط النهاية الخاصة.
- قم بتكوين Azure File Sync لدعم الوكيل في بيئتك.
- تقييد نشاط الشبكة من Azure File Sync.
إذا كنت ترغب في الاتصال بمشاركة ملف Azure عبر SMB ولكن المنفذ 445 محظور، ففكر في استخدام SMB عبر QUIC. توفر هذه الطريقة شبكة VPN ذات تكوين صفري للوصول إلى SMB إلى مشاركات ملفات Azure من خلال بروتوكول نقل QUIC عبر المنفذ 443. على الرغم من أن Azure Files لا تدعم SMB عبر QUIC بشكل مباشر، يمكنك إنشاء ذاكرة تخزين مؤقت خفيفة الوزن لمشاركات ملفات Azure على جهاز Windows Server 2022 Azure Edition VM باستخدام Azure File Sync. لمعرفة المزيد حول هذا الخيار، راجع SMB عبر QUIC.
لمعرفة المزيد حول Azure File Sync والشبكات، راجع اعتبارات الشبكات ل Azure File Sync.
Encryption
يوفر 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، من حيث أنها تقع أسفل وحدة تخزين NTFS، بشكل كامل وشفاف مع Azure File Sync.
الطريقة الرئيسية الأخرى لتشفير البيانات هي تشفير دفق بيانات الملف عند حفظ التطبيق للملف. قد تقوم بعض التطبيقات بهذه المهمة أصلا ، لكنها لا تفعل ذلك عادة.
أمثلة على طرق تشفير دفق بيانات الملف هي حماية البيانات في Azure وإدارة حقوق Azure (Azure RMS) وخدمات إدارة حقوق Active Directory. السبب الرئيسي لاستخدام آلية تشفير مثل Azure Information Protection أو Azure RMS هو منع تسلل البيانات من مشاركة الملفات الخاصة بك بواسطة الأشخاص الذين ينسخونها إلى مواقع بديلة (مثل محرك أقراص محمول) أو إرسالها بالبريد الإلكتروني إلى شخص غير مصرح له. عندما يتم تشفير دفق بيانات الملف كجزء من تنسيق الملف، يستمر تشفير هذا الملف على مشاركة ملف Azure.
لا يتفاعل Azure File Sync مع نظام الملفات المشفرة NTFS أو حلول تشفير الشريك التي تقع فوق نظام الملفات ولكن أسفل دفق بيانات الملف.
التشفير أثناء النقل
يتصل عامل Azure File Sync بخدمة مزامنة التخزين ومشاركة ملف Azure باستخدام بروتوكول Azure File Sync REST وبروتوكول FileREST. يستخدم كلا البروتوكولين دائما HTTPS عبر المنفذ 443. لا ترسل Azure File Sync طلبات غير مشفرة عبر HTTP.
تحتوي حسابات تخزين Azure على محول لطلب التشفير أثناء النقل. يتم تمكين هذا المفتاح افتراضيا. حتى إذا تم تعطيل المحول على مستوى حساب التخزين وكانت الاتصالات غير المشفرة بمشاركات ملفات Azure ممكنة، فلا يزال Azure File Sync يستخدم القنوات المشفرة فقط للوصول إلى مشاركة الملفات.
السبب الرئيسي لتعطيل التشفير أثناء النقل لحساب التخزين هو دعم تطبيق قديم يتصل مباشرة بمشاركة ملف Azure. يجب تشغيل هذا التطبيق على نظام تشغيل قديم ، مثل Windows Server 2008 R2 أو توزيعة Linux قديمة. إذا كان التطبيق القديم يتصل بذاكرة التخزين المؤقت ل Windows Server لمشاركة الملفات، فلن يكون لتغيير هذا الإعداد أي تأثير.
نوصي بشدة بتمكين تشفير البيانات أثناء النقل. لمزيد من المعلومات حول التشفير أثناء النقل، راجع طلب النقل الآمن لضمان الاتصالات الآمنة.
Note
أزالت خدمة Azure File Sync دعم TLS 1.0 و1.1 في 1 أغسطس 2020. تستخدم جميع إصدارات عامل Azure File Sync المدعومة بالفعل TLS 1.2 بشكل افتراضي. ربما تستخدم إصدارا سابقا من طبقة النقل الآمنة إذا عطلت طبقة النقل الآمنة 1.2 على الخادم أو إذا كنت تستخدم وكيلا
إذا كنت تستخدم وكيلا ، فإننا نوصيك بالتحقق من تكوين الوكيل. مناطق خدمة Azure File Sync التي تمت إضافتها بعد 1 مايو 2020، تدعم TLS 1.2 فقط. لمزيد من المعلومات، راجع دليل استكشاف الأخطاء وإصلاحها.
تشفير مشاركة ملف Azure في وضع السكون
يتم تشفير جميع البيانات المخزنة في Azure Files في حالة السكون من خلال التشفير من جانب خدمة Azure Storage (SSE). يعمل SSE بشكل مشابه ل BitLocker على Windows: يتم تشفير البيانات أسفل مستوى نظام الملفات.
نظرا لأن البيانات مشفرة أسفل نظام ملفات مشاركة ملف Azure، حيث يتم ترميزها على القرص، فلن تحتاج إلى الوصول إلى المفتاح الأساسي على العميل للقراءة أو الكتابة إلى مشاركة ملف Azure. ينطبق التشفير المتنقل على كل من بروتوكولات SMB وNFS.
بشكل افتراضي، يتم تشفير البيانات المخزنة في Azure Files باستخدام مفاتيح مدارة من Microsoft. باستخدام المفاتيح التي تديرها Microsoft، تحتفظ Microsoft بالمفاتيح لتشفير البيانات وفك تشفيرها. Microsoft مسؤولة عن تدوير هذه المفاتيح بانتظام.
يمكنك أيضًا اختيار إدارة المفاتيح الخاصة بك، مما يمنحك التحكم في عملية التدوير. إذا اخترت تشفير مشاركات الملفات باستخدام المفاتيح التي يديرها العميل، فإن Azure Files مفوض للوصول إلى المفاتيح الخاصة بك لتلبية طلبات القراءة والكتابة من عملائك. باستخدام المفاتيح التي يديرها العميل، يمكنك إبطال هذا التفويض في أي وقت. ولكن بدون هذا التفويض، لم يعد من الممكن الوصول إلى مشاركة ملف Azure عبر SMB أو واجهة برمجة تطبيقات FileREST.
تستخدم Azure Files نفس مخطط التشفير مثل خدمات Azure Storage الأخرى، مثل Azure Blob Storage. لمعرفة المزيد حول Azure Storage SSE، راجع تشفير Azure Storage للبيانات الثابتة.
طبقات التخزين
توفر Azure Files مستويين من الوسائط: قرص الحالة الصلبة (SSD) ومحرك الأقراص الثابتة (HDD). تسمح لك هذه المستويات بتخصيص أسهمك وفقا لمتطلبات الأداء والسعر للسيناريو الخاص بك:
SSD (متميز): توفر مشاركات ملفات SSD أداء عاليا متسقا وزمن انتقال منخفض، في غضون مللي ثانية من رقم واحد لمعظم عمليات الإدخال/الإخراج، لأحمال العمل كثيفة الإدخال/الإخراج. تعد مشاركات ملفات SSD مناسبة لمجموعة متنوعة من أحمال العمل ، مثل قواعد البيانات واستضافة مواقع الويب وبيئات التطوير.
يمكنك استخدام مشاركات ملفات SSD مع كل من بروتوكولات SMB و NFS. تتوفر مشاركات ملفات SSD في نماذج الفوترة v2 و v1 المتوفرة . توفر مشاركات ملفات SSD اتفاقية مستوى خدمة قابلية وصول أعلى من مشاركات ملفات HDD.
محرك الأقراص الثابتة (قياسي): توفر مشاركات ملفات محرك الأقراص الثابتة خيار تخزين موفر للتكلفة لمشاركات الملفات للأغراض العامة. تتوفر مشاركات ملفات HDD مع نماذج الفوترة v2 والدفع أولا بأولالمقدمة، على الرغم من أننا نوصي بنموذج v2 المقدم لعمليات النشر الجديدة لمشاركات الملفات. للحصول على معلومات حول اتفاقية مستوى الخدمة، راجع صفحة اتفاقية مستوى الخدمة Azure للخدمات عبر الإنترنت.
عند تحديد طبقة وسائط لحمل العمل الخاص بك، ضع في اعتبارك متطلبات الأداء والاستخدام. إذا كان حمل العمل يتطلب زمن انتقال مكون من رقم واحد، أو كنت تستخدم وسائط تخزين SSD محليا، فمن المحتمل أن تكون مشاركات ملفات SSD هي الأنسب. إذا لم يكن زمن الوصول المنخفض مصدر قلق كبير ، فقد تكون مشاركات ملفات HDD مناسبة بشكل أفضل من منظور التكلفة. على سبيل المثال، قد يكون زمن الوصول المنخفض أقل إثارة للقلق مع مشاركات الفريق المثبتة محليا من Azure أو المخزنة مؤقتا محليا من خلال Azure File Sync.
بعد إنشاء مشاركة ملف في حساب تخزين، لا يمكنك نقلها مباشرة إلى طبقة وسائط مختلفة. على سبيل المثال، لنقل مشاركة ملف HDD إلى طبقة وسائط SSD، يجب عليك إنشاء مشاركة ملف SSD جديدة ونسخ البيانات من مشاركتك الأصلية إلى مشاركة الملف الجديدة.
يمكنك العثور على مزيد من المعلومات حول مستويات وسائط SSD وHDD في فهم نماذج فوترة ملفات Azureوفهم أداء مشاركة ملفات Azure وتحسينه.
توفر منطقة Azure File Sync
للاطلاع على التوفر الإقليمي، راجع توفر المنتج حسب المنطقة وابحث عن حسابات التخزين.
تتطلب المناطق التالية طلب الوصول إلى Azure Storage قبل أن تتمكن من استخدام Azure File Sync:
- France South
- جنوب غرب أفريقيا
- UAE Central
لطلب الوصول إلى هذه المناطق، اتبع العملية الواردة في هذه المقالة.
Redundancy
للمساعدة في حماية البيانات في مشاركات ملفات Azure من فقدان البيانات أو تلفها، تخزن Azure Files نسخا متعددة من كل ملف أثناء كتابتها. بناء على متطلباتك ، يمكنك تحديد درجات التكرار. تدعم Azure Files حاليا الخيارات التالية لتكرار البيانات:
التخزين المتكرر محليا (LRS): مع التكرار المحلي، يتم تخزين كل ملف ثلاث مرات في مجموعة تخزين Azure. يساعد هذا الأسلوب في الحماية من فقدان البيانات بسبب أعطال الأجهزة ، مثل محرك الأقراص التالف. ومع ذلك، في حالة حدوث كارثة مثل الحريق أو الفيضانات في مركز البيانات، فقد تفقد جميع النسخ المتماثلة لحساب التخزين الذي يستخدم LRS أو لا يمكن استردادها.
التخزين المتكرر للمنطقة (ZRS):مع تكرار المنطقة، يتم تخزين ثلاث نسخ من كل ملف. ومع ذلك، يتم عزل هذه النسخ فعليا في ثلاث مجموعات تخزين مميزة في مناطق توفر Azure. مناطق التوفر هي مواقع فعلية فريدة في منطقة Azure. تحتوي كل منطقة على مركز بيانات واحد أو أكثر من مركز مزوداً بطاقة مستقلة وتبريد وشبكات. لا يتم قبول الكتابة إلى التخزين حتى تتم كتابتها إلى مجموعات التخزين في جميع مناطق التوفر الثلاث.
التخزين المتكرر جغرافيا (GRS): مع التكرار الجغرافي، يكون لديك منطقة أساسية ومنطقة ثانوية. يتم تخزين الملفات ثلاث مرات في مجموعة تخزين Azure في المنطقة الأساسية. يتم نسخ عمليات الكتابة على نحوٍ غير متزامن إلى منطقة ثانوية تحددها Microsoft.
يوفر التكرار الجغرافي ست نسخ من البيانات المنتشرة بين منطقتي Azure. في حالة حدوث كارثة كبرى، مثل الخسارة الدائمة لمنطقة Azure بسبب كارثة طبيعية أو حدث آخر مشابه، تقوم Microsoft بإجراء تجاوز الفشل. في هذه الحالة ، يصبح الثانوي هو الأساسي ويخدم جميع العمليات.
نظرا لأن النسخ المتماثل بين المناطق الأولية والثانوية غير متزامن ، في حالة حدوث كارثة كبيرة ، يتم فقد البيانات التي لم يتم نسخها بعد إلى المنطقة الثانوية. يمكنك أيضًا إجراء تجاوز فشل يدوي لحساب تخزين متكرر جغرافيًا.
التخزين المتكرر للمنطقة الجغرافية (GZRS): مع التكرار في المنطقة الجغرافية، يتم تخزين الملفات ثلاث مرات عبر ثلاث مجموعات تخزين مميزة في المنطقة الأساسية. ثم يتم نسخ جميع عمليات الكتابة بشكل غير متزامن إلى منطقة ثانوية تحددها Microsoft. تعمل عملية تجاوز الفشل لتكرار المنطقة الجغرافية بنفس الطريقة التي تعمل بها مع التكرار الجغرافي.
تدعم مشاركات ملفات HDD جميع أنواع التكرار الأربعة. تدعم مشاركات ملفات SSD LRS و ZRS فقط.
توفر حسابات تخزين الدفع أولا بأول خيارين آخرين للتكرار لا تدعمهما Azure Files: التخزين المتكرر جغرافيا للوصول للقراءة (RA-GRS) والتخزين المتكرر في المنطقة الجغرافية للوصول للقراءة (RA-GZRS). يمكنك توفير مشاركات ملفات Azure في حسابات التخزين مع مجموعة الخيارات هذه، لكن Azure Files لا تدعم القراءة من المنطقة الثانوية. تتم فوترة مشاركات ملفات Azure المنشورة في حسابات تخزين RA-GRS أو RA-GZRS على أنها زائدة عن الحاجة جغرافيا أو زائدة عن الحاجة في المنطقة الجغرافية، على التوالي.
Important
يمكن أن يفشل التخزين المتكرر جغرافيا والمتكرر في المنطقة الجغرافية يدويا عبر التخزين إلى المنطقة الثانوية. لا نوصي بهذا الأسلوب (خارج الكارثة) عند استخدام Azure File Sync بسبب زيادة احتمالية فقدان البيانات. في حالة حدوث كارثة وكنت ترغب في بدء تجاوز الفشل اليدوي للتخزين، فأنت بحاجة إلى فتح حالة دعم مع Microsoft للحصول على Azure File Sync لاستئناف المزامنة مع نقطة النهاية الثانوية.
Migration
إذا كان لديك خادم ملفات موجود في Windows Server 2012 R2 أو أحدث، فيمكنك تثبيت Azure File Sync مباشرة في مكانه. لا تحتاج إلى نقل البيانات إلى خادم جديد.
إذا كنت تخطط للترحيل إلى خادم ملفات Windows جديد كجزء من اعتماد Azure File Sync، أو إذا كانت بياناتك موجودة حاليا على NAS، فهناك العديد من أساليب الترحيل الممكنة لاستخدام Azure File Sync مع هذه البيانات. يعتمد نهج الترحيل الذي يجب عليك اختياره على مكان تواجد بياناتك حاليا.
للحصول على إرشادات مفصلة، راجع الترحيل إلى مشاركات ملفات SMB Azure.
Antivirus
نظرا لأن برنامج مكافحة الفيروسات يعمل عن طريق فحص الملفات بحثا عن التعليمات البرمجية الضارة المعروفة ، فقد يتسبب منتج مكافحة الفيروسات في استدعاء الملفات المتدرجة ورسوم الخروج العالية. تحتوي الملفات المتدرجة على مجموعة سمات FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS Windows الآمنة. نوصي بالتشاور مع مورد البرنامج لمعرفة كيفية تكوين الحل الخاص به لتخطي قراءة الملفات التي تحتوي على مجموعة السمات هذه. كثيرون يفعلون ذلك تلقائيا.
أثناء عمليات الفحص عند الطلب، تتخطى حلول مكافحة الفيروسات Microsoft Defender وSystem Center Endpoint Protection تلقائيا قراءة الملفات التي تحتوي على هذه السمة. اختبرناها وحددنا مشكلة ثانوية واحدة: عند إضافة خادم إلى مجموعة مزامنة موجودة ، يتم استدعاء الملفات التي يقل حجمها عن 800 بايت (تنزيلها) على الخادم الجديد. تظل هذه الملفات على الخادم الجديد وليست متدرجة لأنها لا تفي بمتطلبات حجم الطبقات (أكثر من 64 كيلوبايت).
Note
يتخطى Microsoft Defender وSystem Center Endpoint Protection القراءة فقط أثناء عمليات الفحص عند الطلب. لا ينطبق هذا على الحماية في الوقت الفعلي (RTP).
يمكن لبائعي برامج الحماية من الفيروسات التحقق من التوافق بين منتجاتهم وAzure File Sync باستخدام Azure File Sync Antivirus Compatibility Test Suite في مركز تنزيل Microsoft.
Backup
إذا قمت بتمكين طبقات السحابة، فلا تستخدم الحلول التي تقوم بعمل نسخة احتياطية مباشرة من نقطة نهاية الخادم أو الجهاز الظاهري الذي يحتوي على نقطة نهاية الخادم.
يتسبب ترتيب طبقات السحابة في تخزين مجموعة فرعية فقط من بياناتك على نقطة نهاية الخادم. توجد مجموعة البيانات الكاملة في مشاركة ملف Azure. اعتمادا على حل النسخ الاحتياطي الذي تستخدمه، تكون الملفات المتدرجة إما:
- تم تخطيها ولم يتم نسخها احتياطيا، لأن لديهم مجموعة
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESSالسمات - تم استدعاؤه إلى القرص، مما يؤدي إلى شحنات خروج عالية
نوصي باستخدام حل النسخ الاحتياطي السحابي لإجراء نسخ احتياطي لمشاركة ملفات Azure بشكل مباشر. لمزيد من المعلومات، راجع حول النسخ الاحتياطي لملفات Azure. أو اسأل موفر النسخ الاحتياطي عما إذا كان يدعم النسخ الاحتياطي لمشاركات ملفات Azure.
إذا كنت تفضل استخدام حل نسخ احتياطي محلي، فقم بإجراء النسخ الاحتياطية على خادم في مجموعة المزامنة التي تم تعطيل طبقات السحابة بها. تأكد من عدم وجود ملفات متدرجة.
عند إجراء استعادة، استخدم خيار الاستعادة على مستوى وحدة التخزين أو مستوى الملف. تتم مزامنة الملفات التي تمت استعادتها من خلال خيار الاستعادة على مستوى الملف مع جميع نقاط النهاية في مجموعة المزامنة. يتم استبدال الملفات الموجودة بالإصدار الذي تمت استعادته من النسخة الاحتياطية. لا تحل عمليات الاستعادة على مستوى وحدة التخزين محل إصدارات الملفات الأحدث في مشاركة ملف Azure أو نقاط نهاية الخادم الأخرى.
Note
يمكن أن تتسبب استعادة المعادن العارية واستعادة الجهاز الظاهري واستعادة النظام (استعادة نظام التشغيل المدمج في Windows) والاستعادة على مستوى الملف بإصداره المتدرج في حدوث نتائج غير متوقعة. (تحدث الاستعادة على مستوى الملف عندما يقوم برنامج النسخ الاحتياطي بعمل نسخة احتياطية من ملف متدرج بدلا من ملف كامل.) وهي غير مدعومة حاليا عند تمكين طبقات السحابة.
يتم دعم لقطات خدمة النسخ الاحتياطي لوحدة التخزين (VSS)، بما في ذلك علامة التبويب الإصدارات السابقة ، على وحدات التخزين التي تم تمكين طبقات السحابة بها. ومع ذلك، يجب تمكين توافق الإصدار السابق من خلال PowerShell. تعرف على كيفية القيام بذلك.
تصنيف البيانات
إذا كان لديك برنامج لتصنيف البيانات مثبتا، فإن تمكين طبقات السحابة يزيد من التكاليف لسببين:
- مع تمكين طبقات السحابة ، يتم تخزين أهم ملفاتك مؤقتا محليا. يتم تصنيف أروع ملفاتك في طبقات إلى مشاركة ملف Azure في السحابة. إذا كان تصنيف البيانات الخاص بك يفحص بانتظام جميع الملفات الموجودة في مشاركة الملفات، فيجب استدعاء الملفات المتدرجة إلى السحابة كلما تم مسحها ضوئيا.
- إذا كان برنامج تصنيف البيانات يستخدم بيانات التعريف في دفق بيانات الملف ، فيجب استدعاء الملف بالكامل حتى يتمكن البرنامج من اكتشاف التصنيف.
يمكن أن تؤدي هذه الزيادات ، في كل من عدد عمليات الاستدعاء وكمية البيانات التي يتم استرجاعها ، إلى زيادة التكاليف.
نهج تحديث عامل Azure File Sync
يتم تحديث عامل Azure File Sync بانتظام لإضافة وظائف جديدة ومعالجة المشكلات. نوصي بتحديث عامل Azure File Sync حيث تتوفر إصدارات جديدة.
إصدارات العامل الرئيسية مقابل إصدارات العامل الثانوية
- غالبا ما تحتوي إصدارات العامل الرئيسية على ميزات جديدة ولها عدد متزايد كجزء أول من رقم الإصدار. على سبيل المثال: 18.0.0.0.
- تسمى إصدارات العامل الثانوي أيضا التصحيحات ويتم إصدارها بشكل متكرر أكثر من الإصدارات الرئيسية. غالبا ما تحتوي على إصلاحات للأخطاء وتحسينات أصغر ولكن لا توفر ميزات جديدة. على سبيل المثال: 18.2.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.
Note
لا يتم دعم الرجوع إلى إصدار أدنى من عامل Azure File Sync. غالبا ما تتضمن الإصدارات الجديدة تغييرات عاجلة عند مقارنتها بالإصدارات القديمة، مما يجعل عملية الرجوع إلى إصدار أقدم غير مدعومة. إذا واجهت أي مشكلات في إصدار الوكيل الحالي، فاتصل بالدعم أو قم بالتحديث إلى أحدث إصدار متاح.
الإدارة التلقائية لدورة حياة الوكيل
يتم تحديث عامل Azure File Sync تلقائيا. يمكنك تحديد أي من الوضعين التاليين وتحديد نافذة صيانة تتم فيها محاولة التحديث على الخادم. تم تصميم هذه الميزة لمساعدتك في إدارة دورة حياة الوكيل إما من خلال توفير درابزين حماية يمنع وكيلك من انتهاء الصلاحية أو السماح بإعداد بدون متاعب والبقاء محدثا.
يحاول الإعداد الافتراضي منع انتهاء صلاحية العامل. في غضون 21 يوما من تاريخ انتهاء الصلاحية المنشور للوكيل، يحاول الوكيل التحديث الذاتي. يبدأ محاولة التحديث مرة واحدة في الأسبوع في غضون 21 يوما قبل انتهاء الصلاحية وفي نافذة الصيانة المحددة. لاحظ أن هذا الخيار لا يلغي الحاجة إلى أخذ تصحيحات Microsoft Update العادية.
يمكنك تحديد أن يقوم العامل بتحديث نفسه تلقائيا بمجرد توفر إصدار وكيل جديد. لا تنطبق هذه القدرة حاليا على الخوادم المجمعة.
يحدث هذا التحديث أثناء نافذة الصيانة المحددة ويسمح للخادم الخاص بك للاستفادة من الميزات والتحسينات الجديدة بمجرد توفرها بشكل عام. يوفر هذا الإعداد الموصى به الخالي من القلق إصدارات الوكيل الرئيسية وتصحيحات التحديث المنتظمة للخادم الخاص بك. كل عامل يتم إصداره هو بجودة GA.
إذا قمت بتحديد هذا الخيار، فإن Microsoft تنقل إليك أحدث إصدار من الوكيل. تستبعد الخوادم المجمعة. بعد اكتمال الرحلة، يصبح العامل متاحا أيضا في Microsoft Update ومركز تنزيل Microsoft.
تغيير إعداد التحديث التلقائي
توضح الإرشادات التالية كيفية تغيير الإعدادات بعد إكمال برنامج التثبيت، إذا كنت بحاجة إلى إجراء تغييرات.
افتح وحدة تحكم 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>
Note
إذا اكتمل الطيران بالفعل لأحدث إصدار من الوكيل وتم تغيير نهج التحديث التلقائي للوكيل إلى InstallLatest، فلن يتم تحديث الوكيل تلقائيا حتى يتم نقل إصدار الوكيل التالي. للتحديث إلى إصدار وكيل انتهى من الرحلة، استخدم Microsoft Update أو AfsUpdater.exe. للتحقق مما إذا كان إصدار الوكيل قيد الطيران حاليا، تحقق من قسم الإصدارات المدعومة في ملاحظات الإصدار.
ضمانات إدارة التغيير ودورة حياة العامل
Azure File Sync هي خدمة سحابية تقدم باستمرار ميزات وتحسينات جديدة. يمكن دعم إصدار عامل Azure File Sync معين لفترة محدودة فقط. لتسهيل النشر الخاص بك، تضمن القواعد التالية أن لديك ما يكفي من الوقت والإخطار لاستيعاب تحديثات الوكيل في عملية إدارة التغيير:
- يتم دعم إصدارات العامل الرئيسي لمدة 12 شهرا على الأقل من تاريخ الإصدار الأولي.
- هناك تداخل لا يقل عن 3 أشهر بين دعم إصدارات الوكيل الرئيسية.
- يتم إصدار التحذيرات للخوادم المسجلة من خلال وكيل منتهي الصلاحية قريباto-be قبل 3 أشهر على الأقل من انتهاء الصلاحية. يمكنك التحقق مما إذا كان الخادم المسجل يستخدم إصدارا قديما من العامل في القسم الخاص بالخوادم المسجلة في خدمة مزامنة التخزين.
- ترتبط مدة بقاء إصدار عامل ثانوي بالإصدار الرئيسي المقترن. على سبيل المثال، عند تعيين إصدار العامل 18.0.0.0 على انتهاء صلاحية، تنتهي صلاحية جميع إصدارات العامل 18.*.*.* معا.
Note
يعرض تثبيت إصدار عامل منتهي الصلاحية تحذيرا ولكنه ينجح. محاولة تثبيت إصدار عامل منتهي الصلاحية أو الاتصال به غير مدعومة ويتم حظرها.