ملاحظة
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
توفر هذه المقالة إرشادات حول تحديد نهج ترتيب السحابة وضبطها ل Azure File Sync. قبل قراءة هذه المقالة، تأكد من فهم كيفية عمل ترتيب السحابة. للحصول على أساسيات ترتيب السحابة، راجع فهم ترتيب سحابة Azure File Sync. للحصول على شرح متعمق لسياسات ترتيب السحابة مع أمثلة، راجع نهج ترتيب سحابة Azure File Sync.
القيود
ترتيب السحابة غير مدعوم على وحدة تخزين نظام Windows.
إذا كنت تستخدم File Server Resource Manager (FSRM) لإدارة الحصة النسبية على نقاط نهاية الخادم، نوصي بتطبيق الحصص النسبية على مستوى المجلد وليس على مستوى وحدة التخزين. لا يزال بإمكانك تمكين ترتيب السحابة إذا كان لديك حصة FSRM على مستوى وحدة التخزين. بمجرد تعيين حصة FSRM النسبية، تقوم واجهات برمجة تطبيقات استعلام المساحة الحرة التي يتم استدعاؤها تلقائيا بالإبلاغ عن المساحة الحرة على وحدة التخزين وفقا لإعداد الحصة النسبية. ومع ذلك، عندما تكون الحصة النسبية الثابتة موجودة على جذر وحدة التخزين، قد لا تكون المساحة الحرة الفعلية على وحدة التخزين والمساحة المقيدة للحصة النسبية على وحدة التخزين هي نفسها. قد يتسبب هذا في ترتيب لا نهاية له إذا كان Azure File Sync يعتقد أنه لا توجد مساحة خالية كافية من وحدة التخزين على نقطة نهاية الخادم.
الحد الأدنى لحجم الملف لملف إلى مستوى
يعتمد الحد الأدنى لحجم الملف لملف إلى مستوى على حجم نظام مجموعة نظام الملفات. يتم حساب الحد الأدنى لحجم الملف المؤهل للتدرج السحابي بمقدار 2x حجم نظام المجموعة وبحد أدنى 8 KiB. يوضح الجدول التالي الحد الأدنى لأحجام الملفات التي يمكن ترتيبها، استنادا إلى حجم مجموعة وحدة التخزين:
| حجم نظام مجموعة وحدة التخزين | يمكن ترتيب الملفات من هذا الحجم أو الأكبر |
|---|---|
| 4 كيبيبايت أو أصغر (4096 بايت) | 8 كيبيبايت |
| 8 كيبيبايت (8192 بايت) | 16 كيبيبايت |
| 16 كيبيبايت (16384 بايت) | 32 كيبيبايت |
| 32 كيبيبايت (32768 بايت) | 64 كيبيبايت |
| 64 كيبيبايت (65,536 بايت) | 128 كيبيبايت |
| 128 كيبيبايت (131,072 بايت) | 256 كيبيبايت |
| 256 كيبيبايت (262,144 بايت) | 512 كيبيبايت |
| 512 كيبيبايت (524,288 بايت) | 1 ميبي بايت |
| 1 ميبي بايت (1,048,576 بايت) | 2 ميبي بايت |
| 2 ميبي بايت (2,097,152 بايت) | 4 ميبي بايت |
يدعم Azure File Sync ترتيب السحابة على وحدات التخزين بأحجام نظام المجموعة التي تصل إلى 2 ميجابايت.
تنظم جميع أنظمة الملفات التي يستخدمها Windows القرص الثابت استنادا إلى حجم نظام المجموعة (المعروف أيضا بحجم وحدة التخصيص). يمثل حجم نظام المجموعة أصغر مقدار من مساحة القرص التي يمكن استخدامها للاحتفاظ بملف. عندما لا تخرج أحجام الملفات إلى مضاعف حتى لحجم نظام المجموعة، يجب استخدام مساحة إضافية للاحتفاظ بالملف - حتى المضاعف التالي لحجم نظام المجموعة.
يتم دعم Azure File Sync على وحدات تخزين NTFS مع Windows Server 2012 R2 وأحدث. يصف الجدول التالي أحجام نظام المجموعة الافتراضية عند إنشاء وحدة تخزين NTFS جديدة باستخدام Windows Server.
| حجم وحدة التخزين | Windows Server |
|---|---|
| 7 ميبي بايت – 16 تيبي بايت | 4 كيبيبايت |
| 16 تيبي بايت – 32 تيبي بايت | 8 كيبيبايت |
| 32 تيبي بايت – 64 تيبي بايت | 16 كيبيبايت |
من الممكن أنه عند إنشاء وحدة التخزين، قمت بتنسيق وحدة التخزين يدويا بحجم مجموعة مختلف. إذا كان مستوى الصوت الخاص بك ينبع من إصدار أقدم من Windows، فقد تختلف أحجام نظام المجموعة الافتراضية أيضا. حتى إذا اخترت حجم نظام مجموعة أصغر من 4 KiB، فلا يزال ينطبق حد 8 KiB كأصغر حجم ملف يمكن ترتيبه. (حتى لو كان حجم نظام المجموعة 2x تقنيا يساوي أقل من 8 كيبيبايت.)
ويرجع سبب الحد الأدنى المطلق إلى الطريقة التي يخزن بها NTFS الملفات الصغيرة للغاية - ملفات بحجم 1 KiB إلى 4 KiB. اعتمادا على معلمات أخرى من وحدة التخزين، من الممكن عدم تخزين الملفات الصغيرة في نظام مجموعة على القرص على الإطلاق. من المحتمل أن يكون تخزين هذه الملفات مباشرة في جدول الملفات الرئيسية أو "سجل MFT" في وحدة التخزين أكثر كفاءة. يتم تخزين نقطة إعادة توزيع ترتيب السحابة دائما على القرص وتأخذ مجموعة واحدة بالضبط. يمكن أن ينتهي ترتيب مثل هذه الملفات الصغيرة دون توفير مساحة. قد ينتهي الأمر بالحالات القصوى إلى استخدام مساحة أكبر مع تمكين ترتيب السحابة. للحماية من ذلك، أصغر حجم لملف ستتدرجه السحابة هو 8 KiB على 4 KiB أو حجم مجموعة أصغر.
تحديد النهج الأولية
بشكل عام، عند تمكين ترتيب السحابة على نقطة نهاية الخادم، يجب إنشاء محرك أقراص ظاهري محلي واحد لكل نقطة نهاية خادم فردية. يؤدي عزل نقطة نهاية الخادم إلى تسهيل فهم كيفية عمل ترتيب السحابة وضبط النهج وفقا لذلك. ومع ذلك، تعمل Azure File Sync حتى إذا كان لديك نقاط نهاية خادم متعددة على نفس محرك الأقراص، للحصول على تفاصيل راجع قسم نقاط نهاية خادم متعدد على وحدة التخزين المحلية . نوصي أيضا عند تمكين ترتيب السحابة لأول مرة، بالاحتفاظ بنهج التاريخ معطلا ونهج المساحة الخالية من وحدة التخزين في حوالي 10% إلى 20%. بالنسبة لمعظم وحدات تخزين خادم الملفات، عادة ما يكون 20% مساحة خالية من وحدة التخزين هو الخيار الأفضل.
إشعار
في بعض سيناريوهات الترحيل، إذا قمت بتوفير مساحة تخزين أقل على مثيل Windows Server مقارنة بالمصدر، يمكنك تعيين مساحة خالية من وحدة التخزين مؤقتا إلى 99% أثناء الترحيل إلى ملفات الطبقة إلى السحابة، ثم تعيينها إلى مستوى أكثر فائدة بعد اكتمال الترحيل.
للتبسيط ولفهم كيفية ترتيب العناصر بشكل واضح، نوصيك في المقام الأول بضبط نهج المساحة الخالية من مستوى الصوت والاحتفاظ بنهج التاريخ معطلا ما لم تكن هناك حاجة. نوصي بذلك لأن معظم العملاء يجدون أنه من القيمة ملء ذاكرة التخزين المؤقت المحلية بأكبر عدد ممكن من الملفات الساخنة وطبقة الباقي على السحابة. ومع ذلك، قد يكون نهج التاريخ مفيدا إذا كنت تريد تحرير مساحة على القرص المحلي بشكل استباقي وكنت تعرف أن الملفات الموجودة في نقطة نهاية الخادم التي تم الوصول إليها بعد عدد الأيام المحددة في نهج التاريخ لا تحتاج إلى الاحتفاظ بها محليا. يؤدي تعيين نهج التاريخ إلى تحرير سعة قرص محلية قيمة لنقاط النهاية الأخرى على وحدة التخزين نفسها لتخزين المزيد من ملفاتها مؤقتا.
بعد تعيين النهج الخاصة بك، قم بمراقبة الخروج وضبط كلا النهجين وفقا لذلك. نوصي بالنظر إلى حجم استدعاء ترتيب السحابةوحجم استدعاء ترتيب السحابة حسب مقاييس التطبيق في Azure Monitor. نوصي أيضا بمراقبة معدل الوصول إلى ذاكرة التخزين المؤقت لنقطة نهاية الخادم لتحديد النسبة المئوية للملفات المفتوحة الموجودة بالفعل في ذاكرة التخزين المؤقت المحلية. لمعرفة كيفية مراقبة الخروج، راجع مراقبة ترتيب السحابة.
ضبط النهج الخاصة بك
إذا كان عدد الملفات التي يتم استدعاؤها باستمرار من Azure أكبر مما تريد، فقد يكون لديك ملفات ساخنة أكثر مما لديك مساحة لحفظها على وحدة تخزين الخادم المحلي. قم بزيادة حجم وحدة التخزين المحلية إذا أمكن، و/أو تقليل النسبة المئوية لنهج المساحة الخالية من وحدة التخزين بزيادات صغيرة. يمكن أن يؤدي تقليل النسبة المئوية للمساحة الخالية من الحجم بشكل كبير إلى عواقب سلبية أيضا. يتطلب الارتفاع في مجموعة البيانات مساحة خالية أكبر - للملفات الجديدة واستدعاء الملفات "الباردة". يتم ترتيب المستويات مع تأخير يصل إلى ساعة واحدة ثم يحتاج إلى وقت المعالجة، وهذا هو السبب في أنه يجب أن يكون لديك دائما مساحة فارغة وافرة على وحدة التخزين الخاصة بك.
يعني الاحتفاظ بمزيد من البيانات المحلية انخفاض تكاليف الخروج حيث سيتم استدعاء عدد أقل من الملفات من Azure، ولكنه يتطلب أيضا قدرا أكبر من التخزين المحلي، والذي يأتي على تكلفته الخاصة.
عند ضبط نهج المساحة الخالية من وحدة التخزين، يتم تحديد كمية البيانات التي يجب الاحتفاظ بها محليا من خلال العوامل التالية: النطاق الترددي الخاص بك، ونمط الوصول إلى مجموعة البيانات، والميزانية. مع اتصال عرض النطاق الترددي المنخفض، قد تحتاج إلى مزيد من البيانات المحلية، لضمان الحد الأدنى من التأخير للمستخدمين. وإلا، يمكنك إسناده إلى معدل الهزال خلال فترة معينة. على سبيل المثال، إذا كنت تعرف أن 10% من مجموعة بيانات 1 تيرابايت تتغير أو يتم الوصول إليها بنشاط كل شهر، فقد تحتاج إلى الاحتفاظ ب 100 جيبي بايت محلي حتى لا تقوم باستدعاء الملفات بشكل متكرر. إذا كانت وحدة التخزين الخاصة بك 2 تيرابايت، فسترغب في الاحتفاظ ب 5% (أو 100 جيبي بايت) محلية، ما يعني أن 95% المتبقية هي النسبة المئوية لمساحة خالية من وحدة التخزين. ومع ذلك، يجب إضافة مخزن مؤقت لفترات من خسارة أعلى - بمعنى آخر، ابدأ بنسبة مساحة خالية أكبر من وحدة التخزين، ثم اضبطه إذا لزم الأمر لاحقا.
إجراءات التشغيل القياسية
- عند الترحيل لأول مرة إلى Azure Files عبر Azure File Sync، يعتمد ترتيب السحابة على التحميل الأولي
- يتحقق ترتيب السحابة من التوافق مع نهج المساحة الفارغة للحجم والتاريخ كل ستين دقيقة
- سيسمح استخدام مفتاح /LFSM على Robocopy عند ترحيل الملفات بمزامنة الملفات وتصنيف السحابة لتوفير مساحة أثناء التحميل الأولي
- إذا حدث ترتيب قبل تشكيل خريطة التمثيل اللوني، ترتيب الملفات حسب الطابع الزمني المعدل الأخير