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

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

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

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

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

ملاحظة

تدعم ذاكرة التخزين المؤقت Azure ل Redis كلا من نموذج التوزيع الكلاسيكي والشبكات الظاهرية Resource Manager Azure.

هام

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

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

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

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

   

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

   

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

   الإعداد	القيمة المقترحة	الوصف
   اسم نظام أسماء المجالات (DNS)	أدخل اسمًا فريدًا عالميًا.	يجب أن يكون اسم ذاكرة التخزين المؤقت عبارة عن سلسلة بين 1 و63 حرفًا تحتوي فقط على أرقام أو أحرف أو واصلات. يجب أن يبدأ الاسم وينتهي برقم أو حرف، ولا يمكن أن يحتوي على واصلات متتالية. سيكون اسم مضيف مثيل ذاكرة التخزين المؤقت اسم <DNS.redis.cache.windows.net>.
   الاشتراك	حدد اشتراكك من القائمة المنسدلة.	الاشتراك الذي يتم بموجبه إنشاء مثيل Azure Cache الجديد لـ Redis.
   مجموعة الموارد	حدد مجموعة موارد من القائمة المنسدلة، أو حدد إنشاء جديد وأدخل اسم مجموعة موارد جديد.	اسم مجموعة الموارد التي سيتم فيها إنشاء ذاكرة التخزين المؤقت والموارد الأخرى. وعبر وضع جميع موارد التطبيق في مجموعة موارد واحدة، يمكنك إدارتها أو حذفها بسهولة.
   ⁧⁩الموقع⁧⁩	حدد موقعا من القائمة المنسدلة.	حدد منطقة بالقرب من الخدمات الأخرى التي ستستخدم ذاكرة التخزين المؤقت.
   نوع ذاكرة التخزين المؤقت	حدد ذاكرة تخزين مؤقت Premium المستوى من القائمة المنسدلة لتكوين ميزات الطبقة Premium. لمزيد من المعلومات، راجع تسعير Azure Cache for Redis.	يحدد التسعير مختلف الفئات الحجم والأداء والميزات المتوفرة في ذاكرة التخزين المؤقت. لمزيد من المعلومات، راجع نظرة عامة على Azure Cache for Redis.

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

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

   هام

   عند نشر Azure Cache for Redis إلى شبكة ظاهرية Resource Manager، يجب أن تكون ذاكرة التخزين المؤقت في شبكة فرعية مخصصة لا تحتوي على موارد أخرى باستثناء Azure Cache لمثيلات Redis. إذا حاولت نشر Azure Cache لمثيل Redis إلى شبكة فرعية Resource Manager شبكة ظاهرية تحتوي على موارد أخرى، أو تم تعيين بوابة 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. في علامة التبويب خيارات متقدمة لمثيل ذاكرة التخزين المؤقت Premium المستوى، قم بتكوين الإعدادات لمنفذ غير TLS والتكوين المجمع واستمرارية البيانات.

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

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

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

11. بعد ظهور رسالة التحقق من الصحة الخضراء التي تم تمريرها ، حدد إنشاء.

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

للاتصال بمثيل Azure Cache for Redis عند استخدام شبكة ظاهرية، حدد اسم مضيف ذاكرة التخزين المؤقت في سلسلة الاتصال، كما هو موضح في المثال التالي:

private static Lazy<ConnectionMultiplexer>
    lazyConnection = new Lazy<ConnectionMultiplexer> (() =>
    {
        return ConnectionMultiplexer.Connect("contoso5premium.redis.cache.windows.net,abortConnect=false,ssl=true,password=password");
    });

public static ConnectionMultiplexer Connection
{
    get
    {
        return lazyConnection.Value;
    }
}

الأسئلة المتداولة حول Azure Cache for Redis virtual network

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

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

ما هي بعض مشكلات التكوين الخاطئ الشائعة مع ذاكرة التخزين المؤقت Azure ل Redis والشبكات الظاهرية؟

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

هام

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

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

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

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

المنافذ	الاتجاه	بروتوكول النقل	الغرض	IP المحلي	IP البعيد
80, 443	الصادر	بروتوكول تحكم الإرسال	تبعيات Redis على Azure Storage/PKI (الإنترنت)	(شبكة Redis الفرعية)	* 4
443	الصادر	بروتوكول تحكم الإرسال	تبعية 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	الصادر	بروتوكول تحكم الإرسال	الاتصالات الداخلية ل Redis	(شبكة Redis الفرعية)	(شبكة Redis الفرعية)
10221-10231	الصادر	بروتوكول تحكم الإرسال	الاتصالات الداخلية ل Redis	(شبكة Redis الفرعية)	(شبكة Redis الفرعية)
20226	الصادر	بروتوكول تحكم الإرسال	الاتصالات الداخلية ل Redis	(شبكة Redis الفرعية)	(شبكة Redis الفرعية)
13000-13999	الصادر	بروتوكول تحكم الإرسال	الاتصالات الداخلية ل Redis	(شبكة Redis الفرعية)	(شبكة Redis الفرعية)
15000-15999	الصادر	بروتوكول تحكم الإرسال	الاتصالات الداخلية ل Redis والنسخ المتماثل الجغرافي	(شبكة Redis الفرعية)	(شبكة Redis الفرعية) (الشبكة الفرعية لنظير النسخة المتماثلة الجغرافية)
6379-6380	الصادر	بروتوكول تحكم الإرسال	الاتصالات الداخلية ل Redis	(شبكة Redis الفرعية)	(شبكة Redis الفرعية)

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

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

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

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

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

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

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

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

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

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

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

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

• اتصال الشبكة الصادرة بنقاط نهاية تخزين Azure في جميع أنحاء العالم. يتم تضمين نقاط النهاية الموجودة في نفس المنطقة مثل مثيل Azure Cache for Redis ونقاط نهاية التخزين الموجودة في مناطق Azure الأخرى . يتم حل نقاط نهاية Azure Storage ضمن مجالات DNS التالية: table.core.windows.netblob.core.windows.netqueue.core.windows.netfile.core.windows.net.
• اتصال الشبكة الصادرة ocsp.digicert.comcrl4.digicert.comocsp.msocsp.commscrl.microsoft.comcrl3.digicert.comcacerts.digicert.comoneocsp.microsoft.comcrl.microsoft.com. هذا الاتصال مطلوب لدعم وظائف TLS/SSL.
• يجب أن يكون تكوين DNS للشبكة الظاهرية قادرا على حل جميع نقاط النهاية والمجالات المذكورة في النقاط السابقة. يمكن تلبية متطلبات DNS هذه عن طريق ضمان تكوين بنية أساسية DNS صالحة وصيانتها للشبكة الظاهرية.
• اتصال الشبكة الصادرة بنقاط نهاية Azure Monitor التالية، والتي يتم حلها ضمن مجالات DNS التالية: shoebox2-black.shoebox2.metrics.nsatc.net، north-prod2.prod2.metrics.nsatc.net، azglobal-black.azglobal.metrics.nsatc.net، shoebox2-red.shoebox2.metrics.nsatc.net، east-prod2.prod2.metrics.nsatc.net، azglobal-red.azglobal.metrics.nsatc.net، shoebox3.prod.microsoftmetrics.com، shoebox3-red.prod.microsoftmetrics.comshoebox3-black.prod.microsoftmetrics.comazredis-red.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 for Redis في شبكة ظاهرية، لماذا أتلقى خطأ يفيد بأن الشهادة البعيدة غير صالحة؟

عند محاولة الاتصال بمثيل Azure Cache for 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

استخدام ExpressRoute مع ذاكرة التخزين المؤقت Azure ل Redis

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

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

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

الحل هو تعريف مسار واحد أو أكثر من التوجيهات المعرفة من قبل المستخدم (UDRs) على الشبكة الفرعية التي تحتوي على 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 لمثيل Redis.

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

هام

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

تحذير

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

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

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

الخطوات التالية

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

• ذاكرة التخزين المؤقت Azure ل Redis Premium مستويات الخدمة