مشاركة عبر

اعتبارات الشبكات ل Azure File Sync

  • مقالة

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

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

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

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

هام

لا تدعم "مزامنة ملف Azure" توجيه الإنترنت. خيار توجيه الشبكة الافتراضي، «توجيه 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، وهو بروتوكول يستند إلى HTTPS يستخدم لتبادل معرفة المزامنة، أي معلومات الإصدار حول الملفات والمجلدات بين نقاط النهاية في بيئتك. يستخدم هذا البروتوكول أيضا لتبادل بيانات التعريف حول الملفات والمجلدات، مثل الطوابع الزمنية وقوائم التحكم في الوصول (ACLs).

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

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

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

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

تستخدم العديد من المؤسسات خادم وكيل كوسيط بين الموارد داخل الشبكة المحلية والموارد خارج شبكتها، كما هو الحال في Azure. تعد الخوادم الوكيلة مفيدة للعديد من التطبيقات مثل عزل الشبكة والأمان والمراقبة والتسجيل. يمكن لـ "مزامنة ملف Azure" التوافق بشكل كامل مع خادم وكيل، ولكن يجب تكوين إعدادات نقطة نهاية الوكيل للبيئة يدوياً مع "مزامنة ملف Azure". يجب أن يتم ذلك عبر PowerShell باستخدام cmdlet لخادم "مزامنة ملف Azure" Set-StorageSyncProxyConfiguration.

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

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

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

يتطلب 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
Microsoft Entra ID يحتوي معرف Microsoft Entra (المعروف سابقا باسم Azure AD) على أساسيات المستخدم المطلوبة لتخويل تسجيل الخادم مقابل Storage Sync Service، وأساسيات الخدمة المطلوبة ل Azure File Sync ليتم تفويضها للوصول إلى موارد السحابة الخاصة بك. AzureActiveDirectory

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

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

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

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

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

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

عند إنشاء نفق شبكة بين شبكتك المحلية وAzure، فإنك تتناظر مع شبكتك المحلية مع شبكة ظاهرية واحدة أو أكثر في Azure. تشبه الشبكة الظاهرية أو VNET شبكة تقليدية تقوم بتشغيلها محليا. مثل حساب تخزين Azure أو جهاز Azure الظاهري، فإن VNET هو مورد Azure يتم نشره في مجموعة موارد.

تدعم "ملفات 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 Files وAzure File Sync من خلال حساب التخزين وخدمة مزامنة التخزين، فإنها توفر خيار الحصول على نقطة نهاية خاصة واحدة أو أكثر لكل مورد. يسمح لك هذا بالاتصال بشكل خاص وآمن بمشاركات ملفات Azure من أماكن العمل باستخدام VPN أو ExpressRoute ومن داخل Azure VNET. عند إنشاء نقطة نهاية خاصة لمورد Azure، فإنه يحصل على عنوان IP خاص من داخل مساحة العنوان للشبكة الظاهرية، مثل كيفية خادم الملفات Windows المحلي الخاص بك يحتوي على عنوان IP ضمن مساحة العنوان المخصصة لشبكة الاتصال المحلية.

هام

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

تقترن نقطة نهاية خاصة فردية بشبكة فرعية محددة لشبكة 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 السيادية مثل سحابة Azure US Government وMicrosoft Azure التي تشغلها سحابة 21Vianet - ما عليك سوى استبدال اللاحقات المناسبة بيئة عملك.

عند إنشاء نقاط نهاية خاصة لحساب تخزين وخدمة مزامنة تخزين، فإننا نقوم بإنشاء سجلات لها في مناطق DNS الخاصة بها. نُحدّث أيضاً إدخال DNS العام بحيث تكون أسماء المجالات المؤهلة بالكامل العادية هي CNAMEs لاسم privatelink ذي الصلة. وهذا يمكن أسماء المجال المؤهلة بالكامل للإشارة إلى عنوان 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 . ستحتوي كل نقطة نهاية خاصة لخدمة مزامنة التخزين على أربعة عناوين 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. هذا له ميزة أن العملاء في البيئة المحلية الخاصة بك سوف تكون قادرة على حل موارد Azure تلقائيا دون الحاجة إلى تكوين كل عميل. ومع ذلك، فإن هذا الحل هش بالمثل لتعديل ملف المضيفين لأن التغييرات لا تنعكس. على الرغم من أن هذا الحل هش، فقد يكون الخيار الأفضل لبعض البيئات.
  • إعادة توجيه core.windows.net المناطق من خوادم DNS المحلية إلى منطقة DNS الخاصة afs.azure.net Azure. يمكن الوصول إلى مضيف DNS الخاص بـ Azure من خلال عنوان IP خاص ( 168.63.129.16 ) الذي يمكن الوصول إليه فقط داخل الشبكات الظاهرية المرتبطة بمنطقة DNS الخاصة بـ Azure. للتغلب على هذا القصور، يمكنك تشغيل خوادم DNS إضافية ضمن شبكة ظاهرية ستعيد توجيه core.windows.net وafs.azure.net إلى مناطق DNS المكافئة الخاصة بـ Azure. لتبسيط هذا التكوين، قدمنا PowerShell cmdlets التي ستقوم بنشر خوادم DNS تلقائيا في شبكة Azure الظاهرية وتكوينها حسب الرغبة. لمعرفة كيفية إعداد إعادة توجيه DNS، راجع تهيئة DNS باستخدام ملفات Azure.

التشفير أثناء النقل

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

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

(راجع أيضًا )