مشاركة عبر

حدود Azure Data Box Heavy

  • مقالة

ضع في اعتبارك هذه الحدود عند توزيع Azure Data Box Heavy وتشغيله. يوضع الجدول التالي هذه الحدود لـ Data Box.

حدود خدمة Data Box Heavy

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

حدود Data Box Heavy

  • يمكن أن يخزِّن جهاز Data Box Heavy مليار ملف لكل عقدة كحد أقصى.
  • يدعم Data Box Heavy ‏512 حاوية أو مشاركة كحد أقصى لكل عقدة في السحابة. تصبح الدلائل عالية المستوى داخل مشاركة المستخدم حاويات أو مشاركات ملفات Azure في السحابة.

حدود تخزين Azure

يصف هذا القسم حدود خدمة Azure Storage، واصطلاحات التسمية المطلوبة لملفات Azure، ونقاط كتلة Azure الكبيرة، وكتل صفحات Azure، حسبما ينطبق على خدمة Data Box. راجع حدود التخزين بعناية واتبع جميع التوصيات.

للحصول على أحدث المعلومات حول حدود خدمة تخزين Azure وأفضل الممارسات لتسمية المشاركات والحاويات والملفات، انتقل إلى:

هام

إذا كانت هناك أي ملفات أو أدلة تتجاوز حدود خدمة Azure Storage، أو لا تتوافق مع اصطلاحات تسمية Azure Files/Blob، فلن يتم استيعاب هذه الملفات أو الدلائل في Azure Storage عبر خدمة Data Box.

محاذير تحميل البيانات

  • الحاويات والمشاركات والمجلدات:
    • لا تنسخ الملفات مباشرة إلى أي من المشاركات التي تم إنشاؤها مسبقا. تحتاج إلى إنشاء مجلد ضمن المشاركة ثم نسخ الملفات إلى هذا المجلد.
    • المجلد ضمن StorageAccount_BlockBlob StorageAccount_PageBlob هو حاوية. على سبيل المثال، يتم إنشاء الحاويات ك StorageAccount_BlockBlob/حاوية StorageAccount_PageBlob /حاوية.
    • تتم ترجمة كل مجلد تم إنشاؤه مباشرة ضمن StorageAccount_AzFile إلى مشاركة ملف Azure.
    • لا يدعم Azure Blob Storage الدلائل. إذا قمت بإنشاء مجلد ضمن المجلد StorageAccount_BlockBlob ، إنشاء المجلدات الظاهرية في اسم الكائن الثنائي كبير الحجم. بالنسبة إلى Azure Files، يتم الاحتفاظ ببنية الدليل الفعلي.
  • دمج محتويات المجلد:
    • يتم تحميل كل ملف مكتوب في StorageAccount_BlockBlob ومشاركات StorageAccount_PageBlob ككائن ثنائي كبير الحجم للكتلة وكائن ثنائي كبير الحجم للصفحة على التوالي.
    • إذا كان للمجلد نفس اسم حاوية موجودة، يتم دمج محتويات المجلد مع محتويات الحاوية. تتم إضافة الملفات أو النقاط غير الموجودة بالفعل في السحابة إلى الحاوية. إذا كان الملف أو blob يحمل نفس اسم ملف أو blob موجود بالفعل في الحاوية، فسيتم استبدال الملف أو blob الموجود.
    • سيفشل التحميل إلى كائن ثنائي كبير الحجم في طبقة الأرشيف إذا كانت الحاوية تحتوي على كائن ثنائي كبير الحجم مؤرشف موجود بنفس الاسم. في أثناء وجود الكائن الثنائي كبير الحجم في الطبقة الأرشيفية، لا يمكن قراءتها أو تعديلها. إذا كنت بحاجة إلى الكتابة فوق كائن ثنائي كبير الحجم، فتأكد من عدم تعيين الكائن الثنائي كبير الحجم على الأرشيف. لمزيد من المعلومات، راجع طبقة الوصول إلى الأرشيف.
    • لا يتم تحميل أي تسلسل هرمي فارغ للدليل (بدون أي ملفات) تم إنشاؤه ضمن StorageAccount_BlockBlob ومجلدات StorageAccount_PageBlob.
  • استيراد البيانات إلى مشاركات ملفات NFS Azure غير مدعوم من قبل Azure Data Box. يؤدي نسخ البيانات من Data Box إلى مشاركة ملف NFS Azure موجود باسم متطابق حيث يؤدي المجلد المصدر إلى حدوث تعارض. لحل هذا التعارض، يعيد Data Box تسمية مشاركة databox-<GUID> المصدر إلى ويحملها إلى حساب التخزين الهدف كمشاركة ملف SMB Azure.
  • إذا كنت تستخدم بروتوكولي SMB وNFS لنسخ البيانات، نوصي بما يلي:
    • استخدم حسابات تخزين مختلفة ل SMB وNFS.
    • لا تنسخ نفس البيانات إلى نفس الوجهة النهائية في Azure باستخدام كل من SMB وNFS. في هذه الحالات، لا يمكن تحديد النتيجة النهائية.
    • على الرغم من أن النسخ عبر كل من SMB وNFS بالتوازي يمكن أن يعمل، لا نوصي بالقيام بذلك لأنه عرضة للخطأ البشري. انتظر حتى تكتمل نسخة بيانات SMB قبل بدء نسخة بيانات NFS.
  • إدارة التحميل:
    • في حالة وجود أي أخطاء عند تحميل البيانات إلى Azure، يتم إنشاء سجل أخطاء في حساب التخزين الهدف. يتوفر المسار إلى سجل الأخطاء هذا عند اكتمال التحميل، ويمكنك مراجعة السجل لاتخاذ إجراء تصحيحي. لا تحذف البيانات من المصدر دون التحقق من البيانات التي تم تحميلها.
    • يمكن الاحتفاظ ببيانات تعريف الملف وأذونات NTFS عند تحميل البيانات إلى Azure Files باستخدام إرشادات في الاحتفاظ بقوائم التحكم في الوصول إلى الملفات والسمات والطوابع الزمنية باستخدام Azure Data Box.
    • يتم الاحتفاظ بالتسلسل الهرمي للملفات أثناء التحميل إلى السحابة لكل من الكائنات الثنائية كبيرة الحجم وملفات Azure. على سبيل المثال، قمت بنسخ ملف في هذا المسار: <container folder>\A\B\C.txt. يتم تحميل هذا الملف إلى نفس المسار في السحابة.
    • إذا تجاوز الحقل CreateTime أو LastWriteTime لملف الحجم المسموح به أثناء التحميل، فإن "الجمعة، 31 ديسمبر 9999 23:59:59" يحل محل التاريخ الأصلي في خاصية ملف Azure. ينجح تحميل الملف، ولا يتم رفع أي خطأ.

حدود حجم حساب تخزين Azure

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

حجم البيانات المنسخة في حساب تخزين Azure الحد الافتراضي
كتلة blob وpage blob الحد الأقصى هو نفس حد التخزين المحدد لاشتراك Azure ويتضمن بيانات من جميع المصادر بما في ذلك Data Box.
ملفات Azure يدعم Data Box مشاركات ملفات Azure المتميزة، والتي تسمح بإجمالي 100 تيرابايت لجميع المشاركات في حساب التخزين. الحد الأقصى للسعة القابلة للاستخدام أقل قليلا بسبب المساحة التي تستخدمها سجلات النسخ وسجلات التدقيق. يتم حجز 100 غيغابايت كحد أدنى لكل من سجل النسخ وسجل التدقيق. لمزيد من المعلومات، راجع سجلات التدقيق ل Azure Data Box وAzure Data Box Heavy. يجب أن تتبع كافة المجلدات ضمن StorageAccount_AzFile هذا الحد. لمزيد من المعلومات، راجع إنشاء مشاركة ملف Azure.

حدود حجم كائن Azure

فيما يلي أحجام كائنات Azure التي يمكن كتابتها. تأكد من أن جميع الملفات التي يتم تحميلها تتوافق مع هذه الحدود.

نوع كائن Azure الحد الافتراضي
Block blob 14 تيرابايت
Page blob 4 تيرابايت
يجب أن يكون كل ملف تم تحميله بتنسيق blob للصفحة محاذاته 512 بايت (مضاعف متكامل)، وإلا فشل التحميل.
تتم محاذاة VHD وVHDX بمقدار 512 بايت.
ملفات Azure 4 تيرا بايت
مقابل الأقراص المُدارة 4 تيرابايت
لمزيد من المعلومات حول الحجم والحدود، راجع:
  • أهداف قابلية التوسع ل SSDs القياسية
  • أهداف قابلية التوسع ل Premium SSDs
  • أهداف قابلية التوسع لأقراص HDD القياسية
  • تسعير الأقراص المدارة والفوترة
    		•

    الكتلة كبيرة الحجم من Azure، وصفحة الكتلة كبيرة الحجم، واصطلاحات تسمية الملفات

    الكيان الاصطلاحات
    أسماء الحاويات للكتلة كبيرة الحجم من Azure وصفحة الكتلة كبيرة الحجم يجب أن يكون اسم DNS صالحاً ويتراوح طوله بين 3 و63 حرفاً.
    يجب أن تبدأ بحرف أو رقم.
    يمكن أن تحتوي فقط على أحرف صغيرة، وأرقام، وواصلة (-).
    يجب أن يسبق كل واصلة (-) مباشرة ويتبعها حرف أو رقم.
    لا يسمح بالواصلات المتتالية في الأسماء.
    مشاركة الأسماء لملفات Azure نفس ما سبق
    أسماء الملفات والدليل لملفات Azure
  • محافظة على حالة الأحرف، وغير حساسة لحالة الأحرف، ويجب ألا يتجاوز طولها 255 حرفاً.
  • لا يمكن أن ينتهي بشرطة مائلة إلى الأمام (/).
  • إذا تم توفيره، فستتم إزالته تلقائياً.
  • الأحرف التالية غير مسموح بها: " \ / : | < > * ?
  • يجب تخطي أحرف URL المحجوزة بشكل صحيح.
  • لا يسمح بأحرف مسار URL غير القانونية. نقاط التعليمات البرمجية مثل \uE000 ليست أحرف Unicode صالحة. بعض أحرف ASCII أو Unicode، مثل أحرف التحكم (0x00 إلى 0x1F و\u0081 وما إلى ذلك)، غير مسموح بها أيضا. لمعرفة القواعد التي تحكم سلاسل Unicode في HTTP/1.1، راجع RFC 2616، القسم 2.2: القواعد الأساسية وRFC 3987.
  • لا يسمح بأسماء الملفات التالية: LPT1 وLPT2 وLPT3 وLPT4 وLPT5 وLPT6 وLPT7 وLPT8 وLPT9 و COM1 و COM2 و COM3 و COM4 و COM4 و COM5 و COM6 و COM7 و COM8 و COM9 و PRN و AUX و NUL و CON و CLOCK$و dot character (.) وحرفين من النقاط (..).
    		•
    أسماء الكتلة كبيرة الحجم، الصفحة كبيرة الحجم
  • تعتبر أسماء البيانات الثنائية الكبيرة حساسة لحالة الأحرف، ويمكن أن تحتوي على أي مجموعة من الأحرف.
  • يجب أن يتراوح طول اسم البيانات الثنائية الكبيرة بين 1 و1024 حرفاً.
  • يجب تخطي أحرف URL المحجوزة بشكل صحيح.
  • لا يمكن أن يتجاوز عدد مقاطع المسار التي تشتمل على اسم النقطة 254. مقطع المسار هو السلسلة بين أحرف المحدد المتتالية (على سبيل المثال، الشرطة المائلة إلى الأمام '/') التي تتوافق مع اسم الدليل الظاهري.
    		•