الأسئلة المتداولة (FAQ) حول Azure Files
تقدم Azure Files مشاركات الملفات المُدارة بالكامل في السحابة والتي يمكن الوصول إليها عبر معيار الصناعة بروتوكول Server Message Block (SMB) أو بروتوكول نظام ملفات الشبكة (NFS). يمكنك تحميل عمليات نشر Azure File بشكل متزامن على السحابة أو عمليات التوزيع Windows و Linux و macOS. يمكنك أيضا تخزين أسهم Azure File مؤقتا على أجهزة Windows Server باستخدام Azure File Sync للوصول السريع إلى مكان استخدام البيانات.
Azure File Sync
هل يمكنني الحصول على خوادم منضمة إلى المجال وغير مرتبطة بالمجال في نفس مجموعة المزامنة؟
نعم. يُمكن أن تحتوي مجموعة المزامنة على نقاط نهاية خادم لها عضويات Active Directory مختلفة، حتى إذا لم تكن مرتبطة بالمجال. على الرغم من أن هذا التكوين يعمل تقنيا، إلا أننا لا نوصي بذلك على أنه تكوين نموذجي لأن قوائم التحكم في الوصول (ACLs) التي تم تعريفها للملفات والمجلدات على خادم واحد قد لا تتمكن من فرضها بواسطة خوادم أخرى في مجموعة المزامنة. للحصول على أفضل النتائج، نوصي بالمزامنة بين الخوادم الموجودة في مجموعة غابة Active Directory نفسها، أو بين الخوادم الموجودة في غابات Active Directory المختلفة ولكن التي أنشأت علاقات ثقة، أو بين الخوادم غير الموجودة في مجال. نوصي بعدم استخدام مزيج من هذه التكوينات.إذا قمت بإنشاء ملف مباشرة في مشاركة Azure File عبر SMB أو من خلال البوابة الإلكترونية، فكم من الوقت يستغرق الملف للمزامنة مع الخوادم في مجموعة المزامنة؟
لا يتم الكشف عن التغييرات التي تم إجراؤها على مشاركة Azure File باستخدام مدخل Microsoft Azure أو SMB على الفور ونسخها مثل التغييرات التي تطرأ على نقطة نهاية الخادم. لا يحتوي Azure Files حتى الآن على إخطارات تغيير أو يوميات، لذلك لا توجد طريقة لبدء جلسة مزامنة تلقائيا عند تغيير الملفات. على Windows Server، تستخدم Azure File Sync دفتر يومية Windows USN لبدء جلسة عَمل مزامنة تلقائيًا عند تغيير الملفات.
للكشف عن التغييرات التي تطرأ على مشاركة Azure File، يحتوي Azure File Sync على مهمة مجدولة تسمى مهمة اكتشاف التغييرات. تقوم مهمة الكشف عن التغيير بتعداد كل ملف في مشاركة الملف، ثم تقوم بمقارنته بإصدار المزامنة لهذا الملف. عندما تحدد مهمة الكشف عن التغيير أن الملفات قد تغيرت، يبدأ Azure File Sync جلسة مزامنة. تبدأ مهمة اكتشاف التغيير كل 24 ساعة. نظرا لأن مهمة الكشف عن التغيير تعمل عن طريق تعداد كل ملف في مشاركة Azure File، يستغرق اكتشاف التغيير وقتا أطول في مساحات الأسماء الأكبر منه في مساحات الأسماء الأصغر. بالنسبة إلى مساحات الأسماء الكبيرة، قد يستغرق الأمر وقتا أطول من مرة كل 24 ساعة لتحديد الملفات التي تم تغييرها.
لمزامنة الملفات التي تم تغييرها في مشاركة Azure File على الفور، يمكن استخدام cmdlet PowerShell للكشف عن استدعاء AzStorageSyncChangeDetection لبدء الكشف عن التغييرات في مشاركة Azure File يدويا. تم تصميم cmdlet هذا للسيناريوهات التي يقوم فيها نوع من العمليات التلقائية بإجراء تغييرات في مشاركة Azure File أو يتم إجراء التغييرات بواسطة مسؤول (مثل نقل الملفات والدلائل إلى المشاركة). بالنسبة لتغييرات المستخدم النهائي، تتمثل التوصية في تثبيت عامل Azure File Sync في جهاز ظاهري IaaS وتمكين المستخدمين النهائيين من الوصول إلى مشاركة الملفات من خلال الجهاز الظاهري IaaS. بهذه الطريقة سوف تتم مزامنة جميع التغييرات بسرعة مع وكلاء آخرين دون الحاجة إلى استخدام Invoke-AzStorageSyncChangeDetection cmdlet. لمعرفة المَزيد، راجع وثائق Invoke-AzStorageSyncChangeDetection.
ملاحظة
يمكن لـ cmdlet استدعاء AzStorageSyncChangeDetection PowerShell الكشف عن 10000 عنصر كحد أقصى. للحصول على قيود أخرى، راجع وثائق استدعاء AzStorageSyncChangeDetect.
ملاحظة
لا تؤدي التغييرات التي تم إجراؤها على مشاركة Azure File باستخدام REST إلى تحديث آخر وقت تم تعديله بواسطة SMB ولن يتم عرضها على أنها تغيير عن طريق المزامنة.
نحن نستكشف إضافة اكتشاف التغيير لمشاركة Azure File مشابهة لـ USN لوحدات التخزين على خادم Windows. ساعدنا على تحديد أولوية هذه الميزة من أجل التطوير المستقبلي من خلال التصويت لها في Azure Community Feedback.
إذا تم تغيير نفس الملف على خادمين في نفس الوقت تقريبا، فماذا يحدث؟
يستخدم Azure File Sync استراتيجية بسيطة لحل التعارض: نَحتفظ بكلا التغييرين على الملفات التي يتم تغييرها في نقطتي نهاية في نفس الوقت. يحافظ أحدث تغيير مكتوب على اسم الملف الأصلي. يَحتوي الملف الأقدم (الذي تم تحديده بواسطة LastWriteTime) على اسم نقطة النهاية ورقم التعارض الملحق باسم الملف. بالنسبة لنقاط نهاية الخادم، يكون اسم نقطة النهاية هو نفس اسم الخادم. بالنسبة لنِقاط نهاية السحابة، يكون اسم نقطة النهاية هو Cloud. يتبع الاسم هذا التصنيف:<FileNameWithoutExtension>-<اسم نقطة النهاية>[-#].<ext>
على سبيل المثال، يصبح التعارض الأول CompanyReport.docx CompanyReport-CentralServer.docx إذا كان CentralServer هو المكان الذي حدثت فيه الكتابة القديمة. أما التعارض الثاني فسيطلق عليه اسم CompanyReport-CentralServer-1.docx. يدعم Azure File Sync 100 مَلف تعارض لكل ملف. عند الوصول إلى الحد الأقصى لعدد ملفات التعارض، ستفشل مزامنة الملف حتى يصبح عدد ملفات التعارض أقل من 100.
لقد تم تعطيل الطبقات السحابية، لماذا توجد ملفات متدرجة في موقع نقطة نهاية الخادم؟
يوجد سببان لاحتمال وجود ملفات متدرجة في موقع نقطة نهاية الخادم:عند إضافة نقطة نهاية خادم جديدة إلى مجموعة مزامنة موجودة، إذا اخترت الخيار الأول لاستدعاء مساحة الاسم أو خيار استدعاء مساحة الاسم فقط لوضع التنزيل الأولي، سوف تظهر الملفات على أنها متدرجة حتى يتم تنزيلها محليا. لكي تتجنب ذلك، حدد الخيار تجنب الملفات المتدرجة لوضع التنزيل الأولي. لاستدعاء الملفات يدويا، استخدم cmdlet استدعاء StorageSyncFileRecall.
إذا تم تمكين الطبقات السحابية على نقطة نهاية الخادم ثم تم تعطيلها، فسوف تظل الملفات متدرجة حتى يتم الوصول إليها.
لماذا لا تعرض ملفاتي المتدرجة صورا مصغرة أو معاينات في Windows Explorer؟
بالنسبة للملفات المتدرجة، لن تكون الصور المصغرة والمعاينات مرئية عند نقطة نهاية الخادم. مِن المتوقع حدوث هذا السلوك نظرا لأن ميزة ذاكرة التخزين المؤقت للصور المصغرة في Windows يتخطى عمدا قراءة الملفات باستخدام السمة غير متصل. مع تمكين Cloud Tiering، ستتسبب القراءة من خلال الملفات المتدرجة في تنزيلها (استرجاعها).هذا السلوك غير خاص ب Azure File Sync، Windows يعرض المستكشف "X رمادي" لأي ملفات تحتوي على مجموعة السمات دون اتصال. سوف ترى رمز X عند الوصول إلى الملفات عبر SMB. لكي تحصل على شرح مفصل لهذا السلوك، راجع لماذا لا أحصل على صور مصغرة للملفات التي تم وضع علامة عليها في وضع عدم الاتصال؟
لكي تحصل على أسئلة حول كيفية إدارة الملفات المتدرجة، يرجى الاطلاع علىكيفية إدارة الملفات المتدرجة.
لماذا توجد الملفات المتدرجة خارج مساحة اسم نقطة نهاية الخادم؟
قبل الإصدار 3 من وكيل Azure File Sync، قام Azure File Sync بحظر نقل الملفات المتدرجة خارج نقطة نهاية الخادم ولكن على نَفس وحدة التخزين مثل نقطة نهاية الخادم. لم تتأثر عمليات النَسخ وتحركات الملفات غير المتدرجة وعمليات نقل الملفات المتدرجة إلى وحدات التخزين الأخرى. كان السبب في هذا السلوك هو الافتراض الضمني بأن مُستكشف الملفات وواجهات برمجة التطبيقات Windows الأخرى لديها عمليات نقل على نفس وحدة التخزين هي (تقريبا) عمليات إعادة تسمية فورية. وهذا يعني أن التحركات سوف تجعل مستكشف الملفات أو طرق النقل الأخرى (مثل سطر الأوامر أو PowerShell) تبدو غير مستجيبة بينما يقوم Azure File Sync باستدعاء البيانات من السحابة. بدءا من الإصدار 3.0.12.0 من وكيل Azure File Sync، سوف يسمح لك Azure File Sync بنقل ملف متدرج خارج نقطة نهاية الخادم. نتجنب الآثار السلبية المذكورة من قبل من خلال السماح للملف المتدرج بالوجود كملف متدرج خارج نقطة نهاية الخادم ثم استدعاء الملف في الخلفية. هذا يعني أن التحركات على نفس وحدة التخزين فورية، ونقوم بكل العمل لاستدعاء الملف إلى القرص بعد اكتمال النقل.أواجه مشكلة في Azure File Sync على الخادم الخاص بي (المزامنة، والطبقات السحابية، وما إلى ذلك). هل يجب علي إزالة نقطة نهاية الخادم وإعادة إنشائها؟
لا: إزالة نقطة نهاية الخادم ليست كإعادة تشغيل خادم! لا تعد إزالة نقطة نهاية الخادم وإعادة إنشائها حلا مناسبا لإصلاح المشكلات المتعلقة بالمزامنة أو الطبقات السحابية أو الجوانب الأخرى ل Azure File Sync. تعد إزالة نقطة نهاية الخادم عملية مدمرة. قد يؤدي ذلك إلى فقد البيانات في حالة وجود ملفات متدرجة خارج مساحة اسم نقطة نهاية الخادم. للمزيد من المعلومات، راجع سبب وجود الملفات المتدرجة خارج مساحة اسم نقطة نهاية الخادم لمزيد من المعلومات. أو يمكن أن يؤدي إلى ملفات يتعذر الوصول إليها للملفات المتدرجة الموجودة داخل مساحة اسم نقطة نهاية الخادم. لن يتم حل هذه المُشكلات عند إعادة إنشاء نقطة نهاية الخادم. قد توجد الملفات المتدرجة داخل مساحة اسم نقطة نهاية الخادم حتى إذا لم يتم تمكين طبقات السحابة مطلقا. لهذا السبب نُوصي بعدم إزالة نقطة نهاية الخادم إلا إذا كنت ترغب في التوقف عن استخدام Azure File Sync مع هذا المجلد المحدد أو إذا تلقيت تعليمات صريحة للقيام بذلك من قبل مهندس Microsoft. لمزيد من المعلومات حول إزالة نقاط نهاية الخادم، راجع إزالة نقطة نهاية خادم.
هل يمكنني نقل خدمة مزامنة التخزين و/أو حساب التخزين إلى مجموعة موارد أو اشتراك أو مستأجر Microsoft Azure Active Directory مختلف؟
نعم، يمكن نقل خدمة مزامنة التخزين و/أو حساب التخزين إلى مجموعة موارد أو اشتراك أو مستأجر Microsoft Azure Active Directory مختلف. بَعد نقل خدمة مزامنة التخزين أو حساب التخزين، تحتاج إلى منح تطبيق Microsoft.StorageSync حق الوصول إلى حساب التخزين (راجع التأكد من أن Azure File Sync لديه حق الوصول إلى حساب التخزين).ملاحظة
عند إنشاء نقطة نهاية السحابة، يجب أن تكون خدمة مزامنة التخزين وحساب التخزين في نفس مستأجر Microsoft Azure Active Directory. بمجرد إنشاء نقطة نهاية السحابة، يمكن نقل خدمة مزامنة التخزين وحساب التخزين إلى مستأجرين مختلفين في Microsoft Azure Active Directory.
هل تحتفظ Azure File Sync بقوائم التحكم في الوصول NTFS على مستوى الدليل/الملف إلى جانب البيانات المخزنة في Azure Files؟
اعتبارا من 24 فبراير 2020، ستستمر قوائم التحكم في الوصول الجديدة والحالية المتدرجة بواسطة مزامنة Azure Files بتنسيق NTFS، وستتم مزامنة تعديلات قوائم التحكم في الوصول التي تم إجراؤها مباشرة على مشاركة Azure Files مع جميع الخوادم في مجموعة المزامنة. ستتم مزامنة أي تغييرات على قوائم التحكم في الوصول التي تم إجراؤها على Azure Files عبر مزامنة Azure Files. عند نسخ البيانات إلى Azure Files، تأكد من استخدام أداة نسخ تدعم "الدقة" اللازمة لنسخ السمات والطوابع الزمنية وقوائم التحكم في الوصول إلى مشاركة Azure Files - إما عبر SMB أو REST. عند استخدام أدوات نَسخ Azure، مثل AzCopy، من المهم استخدام أحدث إصدار. تحقق من جدول أدوات نسخ الملفات للحصول على نظرة عامة حول أدوات نسخ Azure للتأكد من أنه يمكنك نسخ جميع بيانات التعريف المهمة للملف.
إذا قمت بتمكين Azure Backup على مشاركات الملفات المُدارة لمزامنة الملفات، فيمكن متابعة استعادة قوائم التحكم في الوصول للملفات كجزء من سير عمل استعادة النسخ الاحتياطي. يَعمل هذا إما للمشاركة بأكملها أو الملفات / الدلائل الفردية.
إذا كنت تستخدم لقطات كجزء من حل النسخ الاحتياطي المدار ذاتيا لمشاركات الملفات المدارة بواسطة مُزامنة الملفات، فقد لا تتم استعادة قوائم التحكم في الوصول بشكل صحيح إلى قوائم التحكم في الوصول NTFS إذا تم التقاط اللقطات قبل 24 فبراير 2020. عند حدوث ذلك، فكر في الاتصال بدعم Azure.
هل يقوم Azure File Sync بمزامنة LastWriteTime للدلائل؟
لا، لا يقوم Azure File Sync بمزامنة LastWriteTime للدلائل.
الأمان والمُصادقة والتحكم في الوصول
كيف يمكنني تدقيق الوصول إلى الملفات والتغييرات في Azure Files؟
هناك خياران يوفران وظيفة التدقيق لـ Azure File:
- إذا كان المستخدمون يصلون إلى مشاركة Azure File مباشرة، فيمكن استخدام سجلات تخزين Azure لتعقب تغييرات الملفات ووصول المستخدم. يُمكن استخدام هذه السجلات لأغراض استكشاف الأخطاء وإصلاحها ويتم تسجيل الطلبات على أساس أفضل جهد.
- إذا كان المستخدمون يصلون إلى مشاركة Azure File عبر خادم Windows مثبت عليه عامل Azure File Sync، فاستخدم نهج تدقيق أو منتج جهة خارجية لتعقب تغييرات الملفات ووصول المستخدم على خادم Windows.
مصادقة خدمات مجال Active Directory&خدمات مجال Microsoft Azure Active Directory
هل يدعم Azure خدمات مجال Active Directory (Azure AD DS) وصول SMB باستخدام بيانات اعتماد Microsoft Azure Active Directory من الأجهزة المنضمة إلى Microsoft Azure Active Directory أو المسجلة بها؟
لا، هذا السيناريو غير مدعوم.
هل يمكنني الوصول إلى مشاركات Azure File باستخدام بيانات اعتماد Microsoft Azure Active Directory من جهاز ظاهري ضمن اشتراك مختلف؟
إذا كان الاشتراك الذي يتم نشر مشاركة الملف بموجبه مقترنا بنفس مستأجر Microsoft Azure Active Directory مثل توزيع خدمات مجال Microsoft Azure Active Directory الذي تم ضم الجهاز الظاهري إليه بالمجال، فيمكنك بعد ذلك الوصول إلى مشاركات Azure File باستخدام بيانات اعتماد Microsoft Azure Active Directory نفسها. لا يتم فرض القيد على الاشتراك ولكن على مستأجر Microsoft Azure Active Directory المقترن.
هل يمكنني تمكين مصادقة خدمات مجال Microsoft Azure Active Directory أو مصادقة خدمات مجال Active Directory المحلية لمشاركات Azure File باستخدام مستأجر Microsoft Azure Active Directory يختلف عن المستأجر الأساسي لمشاركة Azure File؟
لا، تدعم Azure Files فقط تكامل خدمات مجال Microsoft Azure Active Directory أو خدمات مجال Active Directory المحلي مع مستأجر Microsoft Azure Active Directory موجود في نفس الاشتراك مثل مشاركة الملف. يمكن إقران اشتراك واحد فقط بمستأجر Microsoft Azure Active Directory. ينطبق هذا القيد على كل من أساليب مصادقة خدمات مجال Microsoft Azure Active Directory وخدمات مجال Active Directory المحلية. عند استخدام خدمات مجال Active Directory المحلي للمصادقة، يجب مزامنة بيانات اعتماد خدمات مجال Active Directory مع Microsoft Azure Active Directory المقترن بحساب التخزين.
هل تدعم مصادقة خدمات مجال Active Directory المحلية لمشاركات Azure File التكامل مع بيئة خدمات مجال Active Directory باستخدام مجموعات غابات متعددة؟
تتكامل مصادقة خدمات مجال Active Directory المحلية ل Azure Files فقط مع مجموعة غابات خدمة المجال التي تم تسجيل حساب التخزين فيها. لدعم المُصادقة من غابة أخرى، يجب أن تحتوي بيئتك على صندوق تأميني للغابات تم تكوينه بشكل صحيح. الطريقة التي تسجل بها Azure Files في خدمات مجال Active Directory تقريبا نفس طريقة تسجيل خادم الملفات العادي، حيث تقوم بإنشاء هوية (حساب تسجيل دخول الكمبيوتر أو الخدمة) في Azure File للمصادقة. الفرق الوحيد هو أن SPN المُسجل لحساب التخزين ينتهي ب "file.core.windows.net" الذي لا يتطابق مع لاحقة المجال. استشر مسؤول نطاقك لمعرفة ما إذا كان هناك حاجة إلى أي تحديث لسياسة توجيه اللاحقة لتمكين مصادقة الغابات المتعددة بسبب لاحقة النطاق المختلفة. نقدم مثالا أدناه لتكوين نهج تحويل اللاحقة.
مثال: عندما يرغب المستخدمون في النطاق A في الوصول إلى مشاركة ملف مع حساب التخزين المسجل مقابل مجال في الغابة B، لن يعمل ذلك تلقائيا لأن كيان الخدمة لحساب التخزين لا يحتوي على لاحقة مطابقة للاحقة أي مجال في الغابة A. يمكننا معالجة هذه المشكلة عن طريق تكوين قاعدة تحويل لاحقة يدويا من الغابة A إلى الغابة B للاحقة مخصصة ل "file.core.windows.net". أولا، يجب عليك إضافة لاحقة مخصصة جديدة على الغابة B. تأكد من أن لديك الأذونات الإدارية المناسبة لتغيير التكوين، ثم اتبع الخطوات التالية:
- تَسجيل الدخول إلى مجال جهاز متصل بالغابة B
- افتح وحدة التحكم "مجالات وثِقة Active Directory"
- انقر بزر الماوس الأيمن على "مجالات وثقة Active Directory"
- انقر فوق "الخصائص"
- انقر فوق «إضافة»
- أضف "file.core.windows.net" كلاحقات UPN
- انقر فوق "تطبيق"، ثم "موافق" لإغلاق المعالج
بعد ذلك، أضف قاعدة تحويل اللاحقة على الغابة A، بحيث تعيد التوجيه إلى الغابة B.
- تسجيل الدخول إلى مجال جهاز متصل بالغابة A
- افتح وحدة التحكم "مجالات وثِقة Active Directory"
- انقر بزر الماوس الأيمن على المجال الذي تريد الوصول إلى مشاركة الملف، ثم انقر فوق علامة التبويب "الثقة" وحدد نطاق الغابة B من الصناديق الاستئمانية الصادرة. إذا لم تقم بتكوين الثقة بين الغابتين، فستحتاج إلى إعداد الثقة أولا
- انقر على "خصائص..." ثم "توجيه لاحقة الاسم"
- تأكد إذا كانت اللاحقة "*.file.core.windows.net" تظهر. إذا لم يكن الأمر كذلك، انقر فوق "تحديث"
- حدد "*.file.core.windows.net"، ثم انقر فوق "تمكين" و "تطبيق"
هل هناك أي اختلاف في إنشاء حساب كمبيوتر أو حساب تسجيل دخول خدمة لتمثيل حساب التخزين الخاص بي في AD؟
لا يختلف إنشاء حساب كمبيوتر (افتراضي) أو حساب تسجيل دخول خدمة حول كيفية عمل المصادقة مع Azure Files. يُمكنك الاختيار بنفسك حول كيفية تمثيل حساب التخزين كهوية في بيئة AD الخاصة بك. التَعيين الافتراضي DomainAccountType في Join-AzStorageAccountForAuth cmdlet هو حساب الكمبيوتر. ومَع ذلك، يمكن أن يختلف عمر انتهاء صلاحية كلمة المرور الذي تم تكوينه في بيئة AD الخاصة بك عن حساب تسجيل الدخول إلى الكمبيوتر أو الخدمة، وتحتاج إلى أخذ ذلك في الاعتبار لتحديث كلمة مرور هوية حساب التخزين الخاص بك في AD.
كيفية إزالة بيانات الاعتماد المخزنة مؤقتا باستخدام مفتاح حساب التخزين وحذف اتصالات SMB الموجودة قبل تهيئة اتصال جديد باستخدام بيانات اعتماد Microsoft Azure Active Directory أو AD؟
يُمكنك اتباع العملية المكونة من خطوتين أدناه لإزالة بيانات الاعتماد المحفوظة المقترنة بمفتاح حساب التخزين وإزالة اتصال SMB:
شغل cmdlet أدناه في Windows Cmd.exe لإزالة بيانات الاعتماد. إذا لم تتمكن من العثور على واحد، فهذا يعني أنك لم تستمر في بيانات الاعتماد ويمكنك تخطي هذه الخطوة.
cmdkey/delete:Domain:target=storage-account-name.file.core.windows.net
حذف الاتصال الموجود في مشاركة الملف. يمكنك تحديد مسار التحميل إما كحرف محرك الأقراص المثبت أو كمسار storage-account-name.file.core.windows.net.
صافي الاستخدام <محرك الأقراص-الرسالة/مشاركة المسار> /حذف
نظام ملفات الشبكة (NFS v4.1)
متى ينبغي أن أستخدم Azure Files NFS؟
راجع مشاركات NFS.
كيف يمكنني الاحتفاظ بنسخة احتياطية من البيانات المخزنة في مشاركات NFS؟
يمكن تنسيق النسخ الاحتياطي لبياناتك على مشاركات NFS باستخدام أدوات مألوفة مثل rsync أو منتجات من أحد شركاء النسخ الاحتياطي التابعين لجهات خارجية. العديد من شركاء النسخ الاحتياطي بما في ذلك Commvault و Veeam و Veritas وقاموا بتوسيع حلولهم للعمل مع SMB 3.x و NFS 4.1 لملفات Azure.
هل يمكنني ترحيل البيانات الموجودة إلى مشاركة NFS؟
داخل المنطقة، يمكنك استخدام أدوات قياسية مثل scp أو rsync أو SSHFS لنقل بياناتك. نظرا لأنه يمكن الوصول إلى Azure Files NFS من مثيلات حوسبة متعددة في وقت واحد، بإمكانك تحسين سرعات النسخ باستخدام عمليات التحميل المتوازية. إذا كنت ترغب في جلب البيانات من خارج منطقة ما، فاستخدم VPN أو Expressroute للتحميل على نظام ملفاتك من مركز البيانات المحلي.
هل بإمكانك تشغيل IBM MQ (بما في ذلك المثيل المتعدد) على Azure Files NFS؟
- تفي مشاركات ملفات Azure NFS v4.1 بالمتطلبات الثلاثة التي يحددها IBM MQ
- https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-requirements-shared-file-systems
- تكامل كتابة البيانات
- وصول حصري مضمون للملفات
- إصدار الأقفال عند الفشل
- https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-requirements-shared-file-systems
- يتم تشغيل حالات الاختبار التالية بنجاح
- تفي مشاركات ملفات Azure NFS v4.1 بالمتطلبات الثلاثة التي يحددها IBM MQ
لقطات مشاركة
إنشاء لقطات مشاركة
- هل لقطات مشاركتي زائدة عن الحاجة جغرافيا؟
تحتوي لقطات المشاركة على نفس التكرار مثل مشاركة Azure File التي تم التقاطها من أجلها. إذا قمت بتحديد مساحة تخزين زائدة عن الحاجة جغرافيا لحسابك، يتم أيضا تخزين لقطة المشاركة بشكل متكرر في المنطقة المقترنة.
تنظيف لقطات المُشاركة
- هل يمكنني حذف مشاركتي دون حذف لقطات المشاركة الخاصة بي؟
إذا كانت لديك لقطات مشاركة نشطة على مشاركتك، فلا يمكنك حذفها. يمكنك استخدام واجهة برمجة التطبيقات لحذف لقطات المشاركة، بجانب المشاركة. يمكنك أيضا حذف كل من لقطات المشاركة والمشاركة في مدخل Microsoft Azure.
الفواتير والأسعار
- كم تبلغ التكلفة لمشاركة اللقطات؟
لقطات المشاركة تزايدية بطبيعتها. لقطة المشاركة الأساسية هي نفسها المشاركة. جميع لقطات المشاركة اللاحقة تزايدية وتخزن فقط الفرق عن لقطة المشاركة السابقة لها. تتم محاسبتك فقط على المحتوى الذي يتم تغييره. إذا كانت لديك مشاركة مع 100 جيجابايت من البيانات ولكن تم تغيير 5 جيجابايت فقط منذ آخر لقطة مشاركة، فإن لقطة المشاركة تستهلك 5 جيجابايت إضافية فقط، وسيتم محاسبتك على 105 جيجابايت بايت. لمزيد من المعلومات عن رسوم المعاملات والخروج القياسية، راجع صفحة الأسعار.