اعتبارات شبكة اتصال Azure مزامنة الملفات

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

يمكنك الاتصال بمشاركة ملف Azure بطريقتين:

• الوصول إلى المشاركة مباشرة عبر بروتوكولات SMB أو FileREST. يتم استخدام نمط الوصول هذا بشكل أساسي عند إزالة أكبر عدد ممكن من الخوادم المحلية.
• إنشاء ذاكرة تخزين مؤقت من مشاركة ملف Azure على خادم محلي (أو على Azure VM) مع Azure File Sync، والوصول إلى بيانات مشاركة الملف من الخادم المحلي باستخدام البروتوكول الذي تختاره (SMB، NFS، FTPS، إلخ) لحالة الاستخدام الخاصة بك. نمط الوصول هذا يعتبر سهل الاستخدام لأنه يجمع بين كل من أفضل خدمات أداء داخلي وcloud scale والخدمات القابلة للإرفاق بدون خادم، مثل النسخ الاحتياطي في Azure.

تركز هذه المقالة على كيفية تكوين شبكة الاتصال عندما تستدعي حالة الاستخدام استخدام Azure File Sync لتخزين الملفات في الموقع بدلا من تحميل مشاركة ملف Azure عبر SMB مباشرة. لمزيد من المعلومات حول اعتبارات شبكة الاتصال لنشر Azure Files، راجع اعتبارات شبكة ملفات Azure.

يمتد تكوين شبكة اتصال لمزامنة ملف Azure كائنين مختلفين Azure: خدمة مزامنة التخزين وحساب تخزين Azure. حساب التخزين هو بناء إدارة تمثل مجموعة مشتركة من التخزين حيث يمكنك نشر مشاركات ملفات متعددة، بالإضافة إلى موارد تخزين أخرى، مثل حاويات الكائن الثنائي كبير الحجم وقوائم الانتظار. خدمة مزامنة التخزين هي بنية إدارة تمثل الملقمات المسجلة، والتي Windows خوادم الملفات مع علاقة ثقة راسخة مع Azure File Sync، ومجموعات المزامنة، التي تحدد طوبولوجيا علاقة المزامنة.

هام

لا يعتمد Azure File Sync توجيه الإنترنت. خيار توجيه الشبكة الافتراضي، «توجيه Microsoft»، مدعوم من Azure File Sync.

توصيل خادم ملف Windows ب Azure باستخدام مزامنة ملف Azure

لإعداد واستخدام Azure Files و Azure File Sync مع خادم ملفات Windows محلي، لا يلزم وجود شبكة خاصة إلى Azure تتجاوز اتصال إنترنت أساسي. لنشر Azure File Sync، يمكنك تثبيت عامل مزامنة الملفات Azure على خادم الملفات Windows الذي ترغب في مزامنته مع Azure. يحقق عامل مزامنة ملف Azure المزامنة مع مشاركة ملف Azure عبر قناتين:

• بروتوكول FileREST، وهو بروتوكول يستند إلى HTTPS للوصول إلى مشاركة ملف Azure. لأن بروتوكول FileREST يستخدم HTTPS القياسية لنقل البيانات، يجب أن يكون المنفذ 443 فقط الصادرة الوصول. لا تستخدم Azure File Sync بروتوكول SMB لنقل البيانات من خوادم Windows المحلية إلى مشاركة ملف Azure.
• بروتوكول مزامنة Azure File Sync، وهو بروتوكول يستند إلى HTTPS لتبادل المعرفة بالمزامنة، أي معلومات الإصدار حول الملفات والمجلدات في البيئة الخاصة بك، بين نقاط النهاية في البيئة الخاصة بك. يستخدم هذا البروتوكول أيضا لتبادل بيانات التعريف حول الملفات والمجلدات في البيئة الخاصة بك، مثل الطوابع الزمنية وقوائم التحكم بالوصول (ACLs).

نظرا لأن ملفات Azure توفر وصول بروتوكول SMB مباشرة على مشاركات الملفات Azure، غالبا ما يتساءل العملاء عما إذا كانوا بحاجة إلى تكوين شبكات خاصة لتحميل مشاركات ملف Azure مع SMB من أجل وصول عامل مزامنة الملفات Azure. هذا ليس مطلوبا فحسب ، بل يتم تثبيطه أيضا ، باستثناء سيناريوهات المسؤول ، نظرا لعدم وجود اكتشاف سريع للتغييرات على التغييرات التي تم إجراؤها مباشرة على مشاركة ملف Azure (قد لا يتم اكتشاف التغييرات لأكثر من 24 ساعة اعتمادا على حجم وعدد العناصر في مشاركة ملف Azure). إذا كنت ترغب في استخدام مشاركة ملف Azure مباشرة، أي عدم استخدام Azure File Sync لتخزين الملفات مؤقتا محليا، فيمكنك معرفة المزيد حول اعتبارات الشبكة للوصول المباشر من خلال الرجوع إلى نظرة عامة على شبكة Azure Files.

على الرغم من أن Azure File Sync لا يتطلب أي تكوين خاص للشبكة، فقد يرغب بعض العملاء في تكوين إعدادات الشبكة المتقدمة لتمكين السيناريوهات التالية:

• التشغيل المتداخل مع تكوين الملقم الوكيل للمؤسسة.
• افتح جدار الحماية الداخلي للمؤسسة لخدمات Azure Files و Azure File Sync.
• نفق Azure الملفات و Azure مزامنة الملفات عبر ExpressRoute أو اتصال VPN.

تكوين خوادم البروكسي

تستخدم العديد من المؤسسات خادم وكيل كوسيط بين الموارد داخل الشبكة المحلية والموارد خارج شبكتها، كما هو الحال في Azure. خوادم الوكيل مفيدة للعديد من التطبيقات مثل عزل الشبكة والأمان، والمراقبة وتسجيل الدخول. يمكن مزامنة ملف Azure التشغيل المتداخل بشكل كامل مع ملقم وكيل، ولكن يجب تكوين إعدادات نقطة النهاية الوكيل للبيئة مع Azure مزامنة الملفات يدويا. يجب أن يتم ذلك عبر PowerShell باستخدام cmdlets خادم مزامنة الملفات Azure.

لمزيد من المعلومات حول كيفية تكوين Azure File Sync مع ملقم وكيل، راجع تكوين Azure File Sync مع خادم وكيل.

تكوين جدران الحماية وعلامات الخدمة

يمكنك عزل خوادم الملفات عن معظم مواقع الإنترنت لأغراض أمنية. لاستخدام Azure File Sync في البيئة الخاصة بك، تحتاج إلى ضبط جدار الحماية لفتحه لتحديد خدمات Azure. يمكنك القيام بذلك عن طريق استرداد نطاقات عناوين IP للخدمات التي تحتاجها من خلال آلية تسمى علامات الخدمة.

يتطلب Azure File Sync نطاقات عناوين IP للخدمات التالية، كما هو محدد من خلال علامات الخدمة الخاصة بهم:

الخدمة	الوصف	علامة الخدمة
Azure File Sync	خدمة مزامنة الملفات Azure، كما يمثلها كائن "خدمة مزامنة التخزين"، مسؤولة عن النشاط الأساسي لمزامنة البيانات بين مشاركة ملف Azure وخادم ملف Windows.	StorageSyncService
ملفات Azure	تخزين كافة البيانات المتزامنة عبر Azure File Sync في مشاركة ملف Azure. نسخ الملفات التي تم تغييرها على خوادم الملفات Windows إلى مشاركة ملف Azure، ويتم تنزيل الملفات المتدرجة على خادم الملفات المحلي بسلاسة عند طلب المستخدم لها.	Storage
Azure Resource Manager	إن Azure Resource Manager هي واجهة الإدارة ل Azure. إجراء كافة مكالمات الإدارة، بما في ذلك تسجيل خادم Azure File Sync ومهام خادم المزامنة المستمرة، من خلال إدارة موارد Azure.	AzureResourceManager
Azure Active Directory	يحتوي Azure Active Directory أو Azure AD على أساسيات المستخدم المطلوبة لتخويل تسجيل الخادم مقابل خدمة مزامنة التخزين، و أساسيات الخدمة المطلوبة لمزامنة ملفات Azure ليتم تفويضها للوصول إلى موارد السحابة الخاصة بك.	AzureActiveDirectory

إذا كنت تستخدم Azure File Sync داخل Azure، حتى إذا كانت منطقة مختلفة، يمكنك استخدام اسم علامة الخدمة مباشرة في مجموعة أمان الشبكة للسماح بحركة المرور إلى تلك الخدمة. لمعرفة المزيد حول طريقة القيام بذلك، راجع مجموعات أمان الشبكة.

إذا كنت تستخدم Azure File Sync محليًا، فيمكنك استخدام واجهة برمجة التطبيقات الخاصة بعلامة الخدمة للحصول على نطاقات عناوين IP محددة لقائمة السماح لجدار الحماية الخاص بك. هناك طريقتان للحصول على هذه المعلومات:

• نشر القائمة الحالية لنطاقات عناوين IP لكافة خدمات Azure التي تدعم علامات الخدمة أسبوعيًا على مركز تحميل Microsoft في شكل مستند JSON. تحتوي كل سحابة Azure على مستند JSON خاص بها مع نطاقات عناوين IP ذات الصلة بهذه السحابة:
  • Azure public
  • Azure حكومة الولايات المتحدة
  • Azure الصين:
  • Azure ألمانيا
• يسمح اكتشاف علامة الخدمة API (معاينة) استرداد برمجي للقائمة الحالية من علامات الخدمة. في المعاينة، قد تقوم API لاكتشاف علامة الخدمة بإرجاع معلومات أقل حداثة من المعلومات التي تم إرجاعها من مستندات JSON المنشورة على مركز التنزيل لـMicrosoft. يمكنك استخدام سطح واجهة برمجة التطبيقات استنادًا إلى تفضيلات التشغيل التلقائي:
  • REST API
  • Azure PowerShell
  • Azure CLI

لمعرفة المزيد حول كيفية استخدام علامة الخدمة API لاسترداد عناوين الخدمات، راجع السماح بقائمة عناوين IP لمزامنة ملفات Azure.

المرور النفقي عبر شبكة خاصة ظاهرية أو ExpressRoute

تتطلب بعض المؤسسات الاتصال مع Azure للانتقال عبر نفق شبكة اتصال، مثل شبكة خاصة ظاهرية (VPN) أو ExpressRoute، للحصول على طبقة إضافية من الأمان أو لضمان أن يتبع الاتصال مع Azure مسارا محددا.

عندما تنشئ نفق شبكة بين شبكتك المحلية وAzure، فإنك تتناظر مع شبكتك المحلية باستخدام واحدة أو أكثر من الشبكات الظاهرية في Azure. تشبه الشبكة الافتراضية، أو VNet، الشبكة التقليدية التي تشغلها محليًا. مثل حساب تخزين Azure H أو Azure VM، تعتبر VNet مورد Azure يتم نشرها في مجموعة موارد.

تدعم Azure الملفات ومزامنة الملفات الآليات التالية لحركة مرور النفق بين الملقمات المحلية و Azure:

• Azure VPN Gateway: VPN Gateway هي نوع معين من بوابة الشبكة الافتراضية التي تُستخدم لإرسال حركة مرور مشفرة بين شبكة Azure الظاهرية وموقع بديل (مثل الموقع الداخلي) عبر الإنترنت. Azure VPN Gateway هي مورد Azure يمكن نشرها في مجموعة موارد جنبًا إلى جنب مع حساب تخزين أو موارد Azure أخرى. نظرا لأن Azure File Sync مخصص للاستخدام مع خادم ملفات Windows محلي، فإنك عادة ما تستخدم VPN من موقع إلى موقع (S2S)،على الرغم من أنه من الممكن تقنيا استخدام VPN من نقطة إلى موقع (P2S).

  تربط اتصالات VPN من موقع إلى موقع (S2S) شبكة Azure الظاهرية وشبكة مؤسستك الداخلية. يتيح لك اتصال S2S VPN تهيئة اتصال VPN مرة واحدة، لخادم VPN أو جهاز مستضاف على شبكة مؤسستك، بدلًا من القيام به لكل جهاز عميل يحتاج إلى الوصول إلى مشاركة ملف Azure. لتبسيط نشر اتصال S2S VPN، راجع تهيئة Site-to-Site (S2S) VPN لاستخدامه مع ملفات Azure.

• ExpressRoute، الذي يتيح لك إنشاء مسار محدد بين Azure والشبكة المحلية التي لا تعبر الإنترنت. نظرًا إلى أن ExpressRoute توفر مسارًا مخصصًا بين مركز البيانات المحلي وAzure، قد تكون ExpressRoute مفيدة عندما يكون أداء الشبكة أحد الاعتبارات. يعد ExpressRoute أيضًا خيارًا جيدًا عندما تتطلب سياسة مؤسستك أو متطلباتها التنظيمية مسارًا محددًا إلى مواردك في السحابة.

نقاط النهاية الخاصة

بالإضافة إلى نقاط النهاية العامة الافتراضية ملفات Azure ومزامنة الملفات توفير من خلال حساب التخزين وخدمة مزامنة التخزين، ملفات Azure ومزامنة الملفات يوفر الخيار أن يكون نقطة نهاية خاصة واحدة أو أكثر لكل مورد. عند إنشاء نقطة نهاية خاصة لمورد Azure، فإنه يحصل على عنوان IP خاص من داخل مساحة العنوان للشبكة الظاهرية، مثل كيفية خادم الملفات Windows المحلي الخاص بك يحتوي على عنوان IP ضمن مساحة العنوان المخصصة لشبكة الاتصال المحلية.

هام

لاستخدام نقاط النهاية الخاصة على مورد خدمة مزامنة التخزين، يجب استخدام الإصدار 10.1 أو أكبر من عامل مزامنة الملفات Azure. إصدارات عامل قبل 10.1 لا تعتمد نقاط النهاية الخاصة على خدمة مزامنة التخزين. تدعم كافة إصدارات الوكيل السابقة نقاط النهاية الخاصة على مورد حساب التخزين.

تقترن نقطة نهاية خاصة فردية بشبكة فرعية محددة لشبكة Azure الظاهرية. يكون لحسابات التخزين وخدمات مزامنة التخزين نقاط نهاية خاصة في أكثر من شبكة ظاهرية واحدة.

يتيح لك استخدام نقاط النهاية الخاصة ما يلي:

• الاتصال بموارد Azure بشكل آمن من الشبكات المحلية باستخدام اتصال VPN أو ExpressRoute مع نظير خاص.
• تأمين موارد Azure عن طريق تعطيل نقاط النهاية العامة لملفات Azure ومزامنة الملفات. بشكل افتراضي، إنشاء نقطة نهاية خاصة لا يمنع الاتصالات إلى نقطة النهاية العامة.
• زيادة الأمان للشبكة الظاهرية من خلال تمكينك من منع تسرب البيانات من الشبكة الظاهرية (وحدود التناظر).

لإنشاء نقطة نهاية خاصة، راجع تكوين نقاط نهاية خاصة لمزامنة Azure File.

نقاط النهاية الخاصة وDNS

عند إنشاء نقطة نهاية خاصة، فإننا نقوم أيضًا بشكل افتراضي بإنشاء (أو تحديث منطقة DNS خاصة موجودة) مطابقة privatelink للمجال الفرعي. بالنسبة لمناطق السحابة العامة، تكون مناطق DNS هذه privatelink.file.core.windows.net لملفات Azure privatelink.afs.azure.net ومزامنة Azure File.

ملاحظة

تستخدم هذه المقالة لاحقة DNS لحساب التخزين لمناطق Azure العامة core.windows.net. ينطبق هذا التعليق أيضًا على Azure Sovereign clouds مثل Azure US Government cloud وAzure China cloud - فقط استبدل اللاحقات المناسبة لبيئة عملك.

عند إنشاء نقاط نهاية خاصة لحساب تخزين وخدمة مزامنة تخزين، فإننا نقوم بإنشاء سجلات لها في مناطق DNS الخاصة بها. نقوم أيضا بتحديث إدخال DNS العام بحيث تكون أسماء النطاقات المؤهلة بالكامل العادية هي CNAMEs لاسم الارتباط الخاص ذي الصلة. وهذا يمكن أسماء المجال المؤهلة بالكامل للإشارة إلى عنوان IP نقطة النهاية الخاصة (es) عندما يكون الطالب داخل الشبكة الظاهرية و للإشارة إلى عنوان IP (es) نقطة النهاية العامة عندما يكون الطالب خارج الشبكة الظاهرية.

بالنسبة إلى Azure Files، تحتوي كل نقطة نهاية خاصة على اسم مجال واحد مؤهل بالكامل، يتبع النمط storageaccount.privatelink.file.core.windows.net ، الذي تم تعيينه إلى عنوان IP خاص واحد لنقطة النهاية الخاصة. بالنسبة لمزامنة Azure File، تحتوي كل نقطة نهاية خاصة على أربعة أسماء مجالات مؤهلة بالكامل، لنقاط النهاية الأربع المختلفة التي تعرضها Azure File Sync: الإدارة والمزامنة (الأساسي) والمزامنة (الثانوية) والمراقبة. أسماء المجالات المؤهلة بالكامل لنقاط النهاية هذه عادة اتبع اسم خدمة مزامنة التخزين ما لم يكن الاسم يحتوي على أحرف غير ASCII. على سبيل المثال، إذا كان اسم خدمة مزامنة التخزين mysyncservice في منطقة غرب الولايات المتحدة 2، ستكون نقاط النهاية mysyncservicemanagement.westus2.afs.azure.net المكافئة و و و mysyncservicesyncp.westus2.afs.azure.netmysyncservicesyncs.westus2.afs.azure.netmysyncservicemonitoring.westus2.afs.azure.net . ستحتوي كل نقطة نهاية خاصة لخدمة مزامنة التخزين على 4 عناوين IP مميزة.

نظرًا إلى أن منطقة DNS الخاصة بـ Azure متصلة بالشبكة الظاهرية التي تحتوي على نقطة النهاية الخاصة، يمكنك مراقبة تهيئة DNS عند استدعاء Resolve-DnsName cmdlet من PowerShell في Azure VM (بالتناوب nslookup في نظامي التشغيل Windows وLinux):

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

في هذا المثال، يتحول حساب التخزين storageaccount.file.core.windows.net إلى عنوان IP الخاص لنقطة النهاية الخاصة، وهو ما يحدث 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

إذا قمت بتشغيل الأمر نفسه من الداخل، سترى أن نفس اسم حساب التخزين يتحول إلى عنوان IP العام لحساب التخزين بدلاً من ذلك storageaccount.file.core.windows.net هو سجل CNAME لـ storageaccount.privatelink.file.core.windows.net، والذي بدوره هو سجل CNAME لمجموعة تخزين Azure التي تستضيف حساب التخزين:

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

وهذا يعكس حقيقة أن ملفات Azure و Azure File Sync يمكن أن تكشف كل من نقاط النهاية العامة الخاصة بهم ونقطة نهاية خاصة أو أكثر لكل مورد. للتأكد من أن أسماء المجالات المؤهلة بالكامل للموارد الخاصة بك حل إلى نقاط النهاية الخاصة عناوين IP الخاصة يجب تغيير التكوين على ملقمات DNS المحلية. ويمكن تحقيق ذلك بعدة طرق:

• تعديل ملف المضيفين على العملاء لجعل أسماء النطاقات المؤهلة بالكامل لحسابات التخزين وخدمات مزامنة التخزين الخاصة بك حل لعناوين IP الخاصة المطلوبة. لا يشجع هذا الأمر على بيئات الإنتاج، حيث ستحتاج إلى إجراء هذه التغييرات على كل عميل يحتاج إلى الوصول إلى نقاط النهاية الخاصة بك. لن تتم معالجة التغييرات التي يتم إدخالها على نقاط النهاية/الموارد الخاصة بك (الحذف والتعديلات وما إلى ذلك) تلقائيا.
• إنشاء مناطق DNS على الملقمات المحلية الخاصة بك من أجل privatelink.file.core.windows.netprivatelink.afs.azure.net ومع سجلات موارد Azure. يتمتع هذا بميزة أن العملاء في البيئة المحلية الخاصة بك سوف تكون قادرة على تحويل حساب التخزين تلقائيًا دون الحاجة إلى تهيئة كل عميل، ولكن هذا الحل غير مجدٍ أيضًا في تعديل ملف المضيفين لعدم انعكاس التغييرات. على الرغم من أن هذا الحل غير مجدٍ، قد يكون الخيار الأفضل لبعض البيئات.
• إعادة توجيه core.windows.net المناطق من خوادم DNS المحلية إلى منطقة DNS الخاصة afs.azure.net Azure. يمكن الوصول إلى مضيف DNS الخاص بـ Azure من خلال عنوان IP خاص ( 168.63.129.16 ) الذي يمكن الوصول إليه فقط داخل الشبكات الظاهرية المرتبطة بمنطقة DNS الخاصة بـ Azure. إلى الحل هذا القيد، يمكنك تشغيل ملقمات DNS إضافية ضمن شبكة الاتصال الظاهرية التي سيتم إعادة توجيه core.windows.netafs.azure.net وإلى مناطق DNS Azure الخاصة المكافئة. لتبسيط هذا الإعداد، قدمنا PowerShell cmdlets التي ستقوم بنشر خوادم DNS تلقائيًا في الشبكة الظاهرية لـ Azure الخاصة بك وتهيئتها حسب الرغبة. لمعرفة كيفية إعداد إعادة توجيه DNS، راجع تهيئة DNS باستخدام ملفات Azure.

التشفير المتنقل

يتم تشفير الاتصالات التي تتم من عامل مزامنة ملفات Azure إلى مشاركة ملف Azure أو خدمة مزامنة التخزين دائما. على الرغم من أن حسابات التخزين Azure لديها إعداد لتعطيل تتطلب التشفير أثناء النقل للاتصالات إلى ملفات Azure (وخدمات التخزين Azure الأخرى التي تتم إدارتها من حساب التخزين)، تعطيل هذا الإعداد لن يؤثر على تشفير Azure File Sync عند الاتصال مع ملفات Azure. بشكل افتراضي، يتم تمكين التشفير أثناء النقل لجميع حسابات تخزين Azure.

لمزيد من المعلومات حول التشفير أثناء النقل، راجع طلب النقل الآمن في تخزين Azure .

راجع أيضًا

• ⁧⁩التخطيط لتوزيع "Azure File Sync"⁩
• ⁧⁩توزيع "Azure File Sync"⁧⁩