مشاركة عبر

تكوين دعم الشبكة الظاهرية (VNet) لمثيل Premium Azure Cache for Redis

  • مقالة

يوفر نشر Azure Virtual Network أمان وعزل محسنين إلى جانب: الشبكات الفرعية، وسياسات التحكم في الوصول، وميزات أخرى لتقييد الوصول بشكل أكبر. عندما يتم تكوين مثيل Azure Cache for Redis باستخدام شبكة ظاهرية، فإنه غير قابل للعنوان بشكل عام. بدلاً من ذلك، يمكن الوصول إلى المثيل فقط من الأجهزة الظاهرية والتطبيقات داخل الشبكة الظاهرية. توضح هذه المقالة كيفية تكوين دعم الشبكة الظاهرية لمثيل Azure Cache for Redis من المستوى المتميز.

إشعار

سيتم إيقاف نموذج التوزيع الكلاسيكي في أغسطس 2024. لمزيد من المعلومات، راجع إيقاف نموذج توزيع الخدمات السحابية (الكلاسيكية) في 31 أغسطس 2024.

هام

توصي ذاكرة التخزين المؤقت Azure ل Redis باستخدام Azure Private Link، والذي يبسط بنية الشبكة ويؤمن الاتصال بين نقاط النهاية في Azure. يمكنك الاتصال بمثيل Azure Cache من شبكتك الظاهرية عبر نقطة نهاية خاصة، والتي تم تعيين عنوان IP خاص لها في شبكة فرعية داخل الشبكة الظاهرية. يتم تقديم ارتباطات Azure الخاصة على جميع مستوياتنا، بما في ذلك دعم نهج Azure وإدارة قاعدة NSG المبسطة. لمعرفة المزيد، راجع Private Link Documentation. لترحيل ذاكرة التخزين المؤقت التي تم إدخالها من VNet إلى Private Link، راجع الترحيل من ذاكرة التخزين المؤقت لحقن VNet إلى ذاكرة التخزين المؤقت ل Private Link.

حدود إدخال VNet

  • غالبا ما يكون إنشاء تكوينات الشبكة الظاهرية وصيانتها عرضة للخطأ. يعد استكشاف الأخطاء وإصلاحها أمرا صعبا أيضا. يمكن أن تؤدي تكوينات الشبكة الظاهرية غير الصحيحة إلى مشكلات:
    • نقل المقاييس المعرقلة من مثيلات ذاكرة التخزين المؤقت
    • فشل عقدة النسخة المتماثلة في نسخ البيانات من العقدة الأساسية
    • فقدان محتمل للبيانات
    • فشل عمليات الإدارة مثل التحجيم
    • في السيناريوهات الأكثر خطورة، فقدان التوفر
  • لا تتوفر ذاكرة التخزين المؤقت التي تم إدخالها من VNet إلا لذاكرة التخزين المؤقت Azure من المستوى المتميز ل Redis، وليس المستويات الأخرى.
  • عند استخدام ذاكرة التخزين المؤقت المدخلة لـ VNet، يجب عليك تغيير VNet إلى تبعيات التخزين المؤقت مثل CRLs/PKI وAKV وAzure Storage وAzure Monitor والمزيد.
  • لا يمكنك إدخال Azure Cache لمثيل Redis موجود في شبكة ظاهرية. يجب تحديد هذا الخيار عند إنشاء ذاكرة التخزين المؤقت.

إعداد دعم الشبكة الظاهرية

يتم تكوين دعم الشبكة الظاهرية في جزء New Azure Cache for Redis أثناء إنشاء ذاكرة التخزين المؤقت.

  1. لإنشاء ذاكرة التخزين المؤقت المميزة، قم بتسجيل الدخول إلى مدخل Microsoft Azure وحدد Create a resource. يمكنك أيضًا إنشائها باستخدام قوالب Resource Manager أو PowerShell أو Azure CLI. للمزيد من المعلومات حول كيفية إنشاء مثيل Azure Cache for Redis، راجع Create a cache.

    Screenshot that shows Create a resource.

  2. في صفحة New، حدد Databases. ثم حدد Azure Cache for Redis.

    Screenshot that shows selecting Azure Cache for Redis.

  3. في صفحة New Redis Cache، قم بتكوين إعدادات ذاكرة التخزين المؤقتة من المستوى المتميز الجديدة.

    الإعدادات القيمة المقترحة ‏‏الوصف
    اسم DNS أدخل اسمًا فريدًا عالميًا. يجب أن يكون اسم ذاكرة التخزين المؤقت عبارة عن سلسلة بين 1 و63 حرفًا تحتوي فقط على أرقام أو أحرف أو واصلات. يجب أن يبدأ الاسم وينتهي برقم أو حرف، ولا يمكن أن يحتوي على واصلات متتالية. سيكون \<DNS name>.redis.cache.windows.netاسم مضيف مثيل ذاكرة التخزين المؤقت الخاص بك هو .
    الاشتراك حدد اشتراكك من القائمة المنسدلة. الاشتراك الذي يتم بموجبه إنشاء مثيل Azure Cache الجديد لـ Redis.
    مجموعة الموارد حدد مجموعة موارد من القائمة المنسدلة، أو حدد Create new وأدخل اسمًا جديدًا لمجموعة الموارد. اسم مجموعة الموارد المراد إنشاء ذاكرة التخزين المؤقت والموارد الأخرى فيها. وعبر وضع جميع موارد التطبيق في مجموعة موارد واحدة، يمكنك إدارتها أو حذفها بسهولة.
    Location حدد موقعًا من القائمة المنسدلة. حدد منطقة بالقرب من الخدمات الأخرى التي ستستخدم ذاكرة التخزين المؤقت.
    نوع ذاكرة التخزين المؤقت حدد ذاكرة تخزين مؤقت من المستوى المتميز من القائمة المنسدلة لتكوين ميزات الطبقة المتميزة. لمزيد من المعلومات، راجع تسعير Azure Cache لـ Redis. يحدد التسعير مختلف الفئات الحجم والأداء والميزات المتوفرة في ذاكرة التخزين المؤقت. لمزيد من المعلومات، راجع Azure Cache من أجل Redis overview.

  4. حدد علامة التبويب Networking أو انقر فوق زر Networking في أسفل الصفحة.

  5. في علامة التبويب Networking، حدد Virtual Networks كطريقة اتصال. لاستخدام شبكة ظاهرية جديدة، قم بإنشائها أولاً باتباع الخطوات الواردة في إنشاء شبكة ظاهرية باستخدام مدخل Microsoft Azure أو إنشاء شبكة ظاهرية (كلاسيكية) باستخدام مدخل Microsoft Azure. ثم ارجع إلى جزء New Azure Cache for Redis لإنشاء ذاكرة التخزين المؤقت للمستوى المتميز وتكوينها.

    هام

    عند نشر Azure Cache for Redis إلى شبكة ظاهرية في Resource Manager، يجب أن تكون ذاكرة التخزين المؤقت في شبكة فرعية مخصصة لا تحتوي على موارد أخرى باستثناء مثيلات Azure Cache for Redis. إذا حاولت نشر مثيل Azure Cache for Redis إلى شبكة فرعية Resource Manager شبكة ظاهرية تحتوي على موارد أخرى، أو تم تعيين بوابة NAT لها، فسيفشل النشر. يرجع الفشل إلى أن Azure Cache for Redis يستخدم موازن تحميل أساسي غير متوافق مع بوابة NAT.

    الإعدادات القيمة المقترحة ‏‏الوصف
    الشبكة الظاهرية حدد الشبكة الظاهرية من القائمة المنسدلة. حدد شبكة ظاهرية في نفس الاشتراك والموقع مثل ذاكرة التخزين المؤقت.
    الشبكه الفرعيه حدد الشبكة الفرعية من القائمة المنسدلة. يجب أن يكون نطاق عناوين الشبكة الفرعية برمز CIDR (على سبيل المثال، 192.168.1.0/24). يجب أن يتم احتواؤه بواسطة مساحة العنوان للشبكة الظاهرية.
    عنوان IP ثابت (اختياري) أدخل عنوان IP ثابتًا. إذا لم تحدد عنوان IP ثابتًا، يتم اختيار عنوان IP تلقائيًا.

    هام

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

    بالإضافة إلى عناوين IP المستخدمة بواسطة البنية الأساسية لشبكة Azure الظاهرية، يستخدم كل مثيل Azure Cache for Redis في الشبكة الفرعية عنواني IP لكل جزء وعنوان IP إضافي واحد لموازن التحميل. تعد ذاكرة التخزين المؤقت غير متفاوتة الأجزاء تحتوي على مقطع واحد.

  6. حدد علامة التبويب Next: Advanced أو حدد الزر Next: Advanced في أسفل الصفحة.

  7. من علامة تبويب الخيارات المتقدمة لمثيل ذاكرة التخزين المؤقت المميزة، قم بتكوين إعدادات منفذ غير TLS والتجميع وثبات البيانات.

  8. حدد علامة Next: Tags أو حدد الزر Next: Tags في أسفل الصفحة.

  9. اختياريًا، من علامة تبويب Tags أدخل الاسم والقيمة إذا كنت ترغب في تصنيف المورد.

  10. حدد "Review + create". يتم نقلك إلى علامة التبويب Review + create إذ يقوم Azure بالتحقق من صحة التكوين الخاص بك.

  11. بعد ظهور رسالة Validation passed الخضراء، حدد Create.

قد يستغرق ذلك بعض الوقت لإنشاء ذاكرة التخزين المؤقت. يمكنك مراقبة التقدم المحرز فيAzure Cache لـصفحة Redis الخاصة بالنظرة العامة. عندما تظهر الحالة ك تشغيل، تكون ذاكرة التخزين المؤقت جاهزة للاستخدام. بعد إنشاء ذاكرة التخزين المؤقت، يمكنك عرض تكوين الشبكة الظاهرية عن طريق تحديد Virtual Network من قائمة Resource.

Virtual network

الأسئلة المتداولة حول الشبكة الظاهرية لذاكرة Azure Cache لـ Redis

تحتوي القائمة التالية على إجابات للأسئلة الشائعة حول Azure Cache لشبكات Redis.

ما هي بعض مشكلات التكوين الخطأ الشائعة مع Azure Cache لـ Redis والشبكات الظاهرية؟

عند استضافة Azure Cache for Redis في شبكة ظاهرية، يتم استخدام المنافذ الموجودة في الجداول التالية.

هام

إذا تم حظر المنافذ الموجودة في الجداول التالية، فقد لا تعمل ذاكرة التخزين المؤقت بشكل صحيح. حظر منفذ واحد أو أكثر من هذه المنافذ هو مشكلة التكوين الخطأ الأكثر شيوعًا عند استخدام Azure Cache for Redis في شبكة ظاهرية.

متطلبات المنفذ الصادر

هناك تسعة متطلبات للمنفذ الصادر. الطلبات الصادرة في هذه النطاقات هي إما: أ) الصادرة إلى الخدمات الأخرى الضرورية لذاكرة التخزين المؤقت للعمل، أو ب) داخلية إلى شبكة Redis الفرعية للاتصال الداخلي. بالنسبة للنسخ المتماثل الجغرافي، توجد متطلبات صادرة أخرى للاتصال بين الشبكات الفرعية لذاكرة التخزين المؤقت الأساسية والنسخة المتماثلة.

منافذ الاتجاه بروتوكول النقل الغرض IP المحلي IP البعيد
80, 443 صادر TCP تبعيات Redis على Azure Storage/PKI (الإنترنت) (شبكة Redis الفرعية) * 4
443 صادر TCP تبعية Redis على Azure Key Vault وAzure Monitor (شبكة Redis الفرعية) AzureKeyVault، AzureMonitor 1
53 صادر TCP/UDP تبعيات Redis على DNS (شبكة الإنترنت/الشبكة الظاهرية) (شبكة Redis الفرعية) 168.63.129.16 و169.254.169.254 2 وأي خادم DNS مخصص للشبكة الفرعية 3
8443 صادر TCP الاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)
10221-10231 صادر TCP الاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)
20226 صادر TCP الاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)
13000-13999 صادر TCP الاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)
15000-15999 صادر TCP الاتصالات الداخلية لـ Redis والنسخ المتماثل الجغرافي (شبكة Redis الفرعية) (شبكة Redis الفرعية) (الشبكة الفرعية لنظير النسخة المتماثلة الجغرافية)
6379-6380 صادر TCP الاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)

1 يمكنك استخدام علامات الخدمة AzureKeyVault وAzureMonitor مع مجموعات أمان الشبكة Resource Manager (NSGs).

2 تستخدم عناوين IP هذه المملوكة من قبل Microsoft لمعالجة الجهاز الظاهري المضيف الذي يخدم Azure DNS.

3 هذه المعلومات غير مطلوبة للشبكات الفرعية التي لا يوجد بها خادم DNS مخصص أو ذاكرة تخزين مؤقت أحدث لـ Redis تتجاهل DNS المخصص.

4 لمزيد من المعلومات، راجع متطلبات اتصال الشبكة الظاهرية الإضافية.

متطلبات منفذ نظير النسخ المتماثل الجغرافي

إذا كنت تستخدم النسخ المتماثل الجغرافي بين ذاكرة التخزين المؤقت في شبكات Azure الظاهرية: أ) ألغِ حظر المنافذ 15000-15999 للشبكة الفرعية بأكملها في كل من الاتجاهات الواردة والصادرة، ب) لكلا المخزنين المؤقتين. مع هذا التكوين، يمكن لجميع مكونات النسخ المتماثلة في الشبكة الفرعية الاتصال مباشرة مع بعضها البعض حتى إذا كان هناك تجاوز فشل جغرافي مستقبلي.

متطلبات المنفذ الوارد

هناك ثمانية متطلبات لنطاق المنفذ الوارد. الطلبات الواردة في هذه النطاقات إما واردة من خدمات أخرى مستضافة في نفس الشبكة الظاهرية. أو، فهي داخلية لاتصالات شبكة Redis الفرعية.

منافذ الاتجاه بروتوكول النقل الغرض IP المحلي IP البعيد
6379, 6380 وارد TCP اتصال العميل بـ Redis، موازنة تحميل Azure (شبكة Redis الفرعية) (شبكة Redis الفرعية)، (الشبكة الفرعية للعميل)، AzureLoadBalancer 1
8443 وارد TCP الاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)
8500 وارد TCP/UDP موازنة تحميل Azure (شبكة Redis الفرعية) AzureLoadBalancer
10221-10231 وارد TCP اتصال العميل بأنظمة Redis Clusters، والاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)، (الشبكة الفرعية للعميل)، AzureLoadBalancer
13000-13999 وارد TCP اتصال العميل بأنظمة Redis Clusters، موازنة تحميل Azure (شبكة Redis الفرعية) (شبكة Redis الفرعية)، (الشبكة الفرعية للعميل)، AzureLoadBalancer
15000-15999 وارد TCP اتصال العميل بأنظمة Redis Clusters، وموازنة تحميل Azure، والنسخ المتماثل للموقع الجغرافي (شبكة Redis الفرعية) (شبكة Redis الفرعية)، (الشبكة الفرعية للعميل)، AzureLoadBalancer، (الشبكة الفرعية لنظير النسخة المتماثلة الجغرافية)
16001 وارد TCP/UDP موازنة تحميل Azure (شبكة Redis الفرعية) AzureLoadBalancer
20226 وارد TCP الاتصالات الداخلية لـ Redis (شبكة Redis الفرعية) (شبكة Redis الفرعية)

1 يمكنك استخدام علامة الخدمة AzureLoadBalancer Resource Manager أو AZURE_LOADBALANCER لنموذج النشر الكلاسيكي لتأليف قواعد NSG.

متطلبات اتصال الشبكة الظاهرية الإضافية

هناك متطلبات اتصال شبكة لمثيل Azure Cache for Redis التي قد لا يتم استيفاءها في البداية في شبكة ظاهرية. يتطلب Azure Cache for Redis جميع العناصر التالية للعمل بشكل صحيح عند استخدامه داخل شبكة ظاهرية:

  • اتصال الشبكة الصادرة بنقاط نهاية Azure Key Vault في جميع أنحاء العالم. يتم حل نقاط نهاية Azure Key Vault ضمن مجال vault.azure.netDNS .
  • اتصال الشبكة الصادرة بنقاط نهاية Azure Storage في جميع أنحاء العالم. يتم تضمين نقاط النهاية الموجودة في نفس المنطقة مثل مثيل Azure Cache for Redis ونقاط نهاية التخزين الموجودة في مناطق Azure الأخرى. يتم حل نقاط نهاية تخزين Azure ضمن مجالات DNS التالية: table.core.windows.netو blob.core.windows.netqueue.core.windows.netو وfile.core.windows.net.
  • اتصال الشبكة الصادرة ب ocsp.digicert.comcrl4.digicert.comocsp.msocsp.comو و mscrl.microsoft.comو.crl.microsoft.comcrl3.digicert.comcacerts.digicert.comoneocsp.microsoft.com هذا الاتصال مطلوب لدعم وظائف TLS/SSL.
  • يجب أن يكون تكوين DNS للشبكة الظاهرية قادرًا على حل جميع نقاط النهاية والمجالات المذكورة في النقاط السابقة. يمكن تلبية متطلبات DNS هذه عن طريق ضمان تكوين بنية أساسية لنظام DNS صالحة وصيانتها للشبكة الظاهرية.
  • اتصال الشبكة الصادرة بنقاط نهاية Azure Monitor التالية، والتي يتم حلها ضمن مجالات DNS التالية: shoebox2-black.shoebox2.metrics.nsatc.netو azredis-red.prod.microsoftmetrics.comshoebox3-black.prod.microsoftmetrics.comshoebox3-red.prod.microsoftmetrics.comnorth-prod2.prod2.metrics.nsatc.netazglobal-red.azglobal.metrics.nsatc.netazglobal-black.azglobal.metrics.nsatc.netshoebox2-red.shoebox2.metrics.nsatc.neteast-prod2.prod2.metrics.nsatc.netshoebox3.prod.microsoftmetrics.com.azredis-black.prod.microsoftmetrics.com

كيف يمكنني التحقق من أن ذاكرة التخزين المؤقت تعمل في شبكة ظاهرية؟

هام

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

بعد تكوين متطلبات المنفذ كما هو موضح في القسم السابق، يمكنك التحقق من أن ذاكرة التخزين المؤقت تعمل باتباع الخطوات التالية:

  • إعادة تشغيل جميع عقد ذاكرة التخزين المؤقت. لن تتمكن ذاكرة التخزين المؤقت من إعادة التشغيل بنجاح إذا تعذر الوصول إلى جميع تبعيات ذاكرة التخزين المؤقت المطلوبة--- الموثقة في متطلبات المنفذ الوارد ومتطلبات المنفذ الصادر.
  • بعد إعادة تشغيل عقد ذاكرة التخزين المؤقت، كما تم الإبلاغ عنها بواسطة حالة ذاكرة التخزين المؤقت في مدخل Microsoft Azure، يمكنك إجراء الاختبارات التالية:

    • اختبار نقطة نهاية ذاكرة التخزين المؤقت باستخدام المنفذ 6380 من جهاز داخل نفس الشبكة الظاهرية مثل ذاكرة التخزين المؤقت، باستخدام tcping. على سبيل المثال:

      tcping.exe contosocache.redis.cache.windows.net 6380

      إذا أبلغت أداة tcping أن المنفذ مفتوح، فإن ذاكرة التخزين المؤقت متاحة للاتصال من العملاء في الشبكة الظاهرية.

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

عندما أحاول الاتصال بمثيل Azure Cache لـ Redis في شبكة ظاهرية، لماذا أتلقى خطأ يفيد بأن الشهادة البعيدة غير صالحة؟

عند محاولة الاتصال بمثيل Azure Cache لـ Redis في شبكة ظاهرية، سترى خطأ التحقق من صحة الشهادة مثل هذا:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

قد يكون السبب هو أنك تتصل بالمضيف بواسطة عنوان IP. نُوصي باستخدام اسم المضيف. بمعنى آخر، استخدم السلسلة التالية:

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

تجنب استخدام عنوان IP المشابه لسلسلة الاتصال التالية:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

إذا لم تتمكن من حل اسم DNS، تتضمن بعض مكتبات العميل خيارات تكوين مثل sslHost، والتي يوفرها عميل StackExchange.Redis. يسمح لك هذا الخيار بتجاوز اسم المضيف المستخدم للتحقق من صحة الشهادة. على سبيل المثال:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

هل يمكنني استخدام الشبكات الظاهرية مع ذاكرة تخزين مؤقت قياسية أو أساسية؟

يمكن استخدام الشبكات الظاهرية فقط مع ذاكرة التخزين المؤقت من المستوى المتميز.

لماذا يفشل إنشاء Azure Cache لمثيل Redis في بعض الشبكات الفرعية ولكن ليس في شبكات أخرى؟

إذا كنت تقوم بنشر مثيل Azure Cache لـ Redis إلى شبكة ظاهرية، فإنه يجب أن تكون ذاكرة التخزين المؤقت في شبكة فرعية مخصصة لا تحتوي على أي نوع مورد آخر. يفشل النشر عادةً، إذا جرت محاولة لنشر مثيل Azure Cache for Redis إلى شبكة فرعية للشبكة الظاهرية لـ Resource Manager والتي تحتوي على موارد أخرى، مثل مثيلات Azure Application Gateway وOutbound NAT. احذف الموارد الموجودة من أنواع أخرى قبل إنشاء مثيل Azure Cache for Redis جديد.

يجب أن يكون لديك أيضًا عناوين IP كافية متوفرة في الشبكة الفرعية.

ما هي متطلبات مساحة عنوان الشبكة الفرعية؟

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

بالإضافة إلى عناوين IP المستخدمة بواسطة البنية الأساسية لشبكة Azure الظاهرية، يستخدم كل مثيل Azure Cache for Redis في الشبكة الفرعية عنواني IP لكل جزء نظام مجموعة، بالإضافة إلى عناوين IP للنسخ المتماثلة الإضافية، إن وجدت. يتم استخدام عنوان IP آخر لموازن التحميل. تحتوي ذاكرة التخزين المؤقت غير متفاوتة الأجزاء على جزء واحد.

هل يمكنني الاتصال بذاكرة التخزين المؤقت الخاصة بي من شبكة ظاهرية نظيرة؟

إذا كانت الشبكات الظاهرية في نفس المنطقة، فإنه يمكنك توصيلها باستخدام نظير شبكة ظاهرية أو اتصال من شبكة ظاهرية إلى شبكة ظاهرية لبوابة VPN.

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

لمزيد من المعلومات حول قيود تناظر الشبكة الظاهرية، راجع الشبكة الظاهرية - التناظر - المتطلبات والقيود. أحد الحلول هو استخدام اتصال VPN Gateway VNET إلى VNET بدلاً من نظير الشبكة الظاهرية.

هل تعمل جميع ميزات ذاكرة التخزين المؤقت عند استضافة ذاكرة تخزين مؤقت في شبكة ظاهرية؟

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

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

هل يتم دعم حقن VNet على ذاكرة التخزين المؤقت حيث يتم تمكين Azure Lighthouse؟

لا، إذا تم تمكين Azure Lighthouse في اشتراكك، فلا يمكنك استخدام حقن VNet على Azure Cache لمثيل Redis. بدلا من ذلك، استخدم ارتباطات خاصة.

استخدام ExpressRoute مع ذاكرة Azure Cache لـ Redis

يمكن للعملاء توصيل دائرة Azure ExpressRoute بالبنية الأساسية للشبكة الظاهرية الخاصة بهم. بهذه الطريقة، يقومون بتوسيع شبكتهم المحلية إلى Azure.

بشكل ظاهري، لا تستخدم دائرة ExpressRoute التي تم إنشاؤها حديثًا توجيه لأسفل مفروض (إعلان مسار ظاهري، 0.0.0.0/0) على شبكة ظاهرية. نتيجة لذلك، يسمح بالاتصال بالإنترنت الصادر مباشرة من الشبكة الظاهرية. يمكن لتطبيقات العميل الاتصال بنقاط نهاية Azure الأخرى، والتي تتضمن مثيل Azure Cache لـ Redis.

تكوين العميل الشائع هو استخدام توجيه لأسفل مفروض (الإعلان عن مسار افتراضي)، ما يفرض نسبة استخدام الإنترنت الصادرة على التدفق المحلي بدلاً من ذلك. يكسر تدفق نسبة استخدام الشبكة هذا الاتصال بذاكرة Azure Cache لـ Redis إذا تم حظر نسبة استخدام الشبكة الصادرة محليًا حتى لا يتمكن مثيل Azure Cache for Redis من الاتصال بتبعياته.

الحل هو تحديد مسار واحد أو أكثر من التوجيهات المعرفة من قبل المستخدم (UDR) على الشبكة الفرعية التي تحتوي على Azure Cache لمثيل Redis. يحدد UDR المسارات الخاصة بالشبكة الفرعية التي سيتم احترامها بدلًا من المسار الافتراضي.

إذا كان ذلك ممكناً، استخدم التكوين التالي:

  • يعلن تكوين ExpressRoute عن 0.0.0.0/0، وبشكل افتراضي، يقلل نسبة استخدام الشبكة الصادرة محليًا.
  • يحدد UDR المطبق على الشبكة الفرعية التي تحتوي على مثيل Azure Cache for Redis 0.0.0.0/0 مع مسار عمل لنسبة استخدام الشبكة TCP/IP إلى الإنترنت العام. على سبيل المثال، فإنه يعين نوع الوثب التالي إلى الإنترنت.

التأثير المدمج لهذه الخطوات هو أن UDR على مستوى الشبكة الفرعية له الأسبقية على التوجيه لأسفل المفروض لـ ExpressRoute ويضمن الوصول إلى الإنترنت الصادر من مثيل Azure Cache for Redis.

الاتصال بمثيل Azure Cache for Redis من تطبيق محلي باستخدام ExpressRoute ليس سيناريو استخدام نموذجي لأسباب تتعلق بالأداء. للحصول على أفضل أداء، يجب أن يكون عملاء Azure Cache for Redis في منطقة مثيل Azure Cache for Redis نفسها.

هام

يجب أن تكون المسارات المعرفة في UDR محددة بما يكفي لتأخذ الأسبقية على أي مسارات يتم الإعلان عنها بواسطة تكوين ExpressRoute. يستخدم المثال التالي نطاق العنوان 0.0.0.0/0 الواسع، وعلى هذا النحو، يمكن تجاوزه عن طريق الخطأ عن طريق إعلانات المسار التي تستخدم نطاقات عناوين أكثر تحديدًا.

تحذير

لا يتم دعم Azure Cache for Redis مع تكوينات ExpressRoute التي تقوم بشكل غير صحيح بالإعلان المتبادل عن التوجيهات من مسار التناظر العام إلى مسار تناظر خاص. تتلقى تكوينات ExpressRoute التي تم تكوين تناظر عام لها إعلانات المسار من Microsoft لمجموعة كبيرة من نطاقات عناوين IP لـ Microsoft Azure. إذا تم الإعلان عن نطاقات العناوين هذه بشكل غير صحيح عبر مسار التناظر الخاص، فستكون النتيجة هي أنه سيتم فرض جميع حزم الشبكة الصادرة من الشبكة الفرعية لمثيل Azure Cache for Redis بشكل غير صحيح على البنية الأساسية للشبكة المحلية للعميل. يسبب تدفق الشبكة هذا عطلاً في Azure Cache for Redis. يتمثل الحل لهذه المشكلة في إيقاف مسارات الإعلانات المتقاطعة من مسار التناظر العام إلى مسار التناظر الخاص.

تتوفر معلومات الخلفية حول عمليات UDR في توجيه نسبة استخدام الشبكة الظاهرية.

لمزيد من المعلومات حول ExpressRoute، راجع نظرة عامة تقنية على ExpressRoute.

المحتوى ذو الصلة

تعرف على المزيد حول ميزات Azure Cache for Redis.