تحرير

مشاركة عبر

تصميم حل نظام أسماء المجالات المختلط باستخدام Azure

Azure Bastion
Azure DNS
Azure ExpressRoute
Azure Virtual Network

توضح هذه البنية المرجعية كيفية تصميم حل نظام أسماء المجالات المختلط (DNS) لحل أسماء أحمال العمل المستضافة محليا وفي Microsoft Azure. تعمل هذه البنية للمستخدمين والأنظمة الأخرى التي تتصل من الإنترنت المحلي والعام.

الهندسة

Diagram showing a Hybrid Domain Name System (DNS).

قم بتنزيل ملف Visio لهذه البنية.

Workflow

تتكون البنية من المكونات التالية:

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

    إشعار

    يمكن استبدال الشبكة الظاهرية المركزية بمركز شبكة ظاهرية واسعة النطاق (WAN)، وفي هذه الحالة يجب استضافة خوادم DNS في شبكة Azure الظاهرية (VNet) مختلفة. في البنية على نطاق المؤسسة، يتم الاحتفاظ بالشبكة الظاهرية في اشتراكها الخاص بعنوان اشتراك الهوية.

    • الشبكة الفرعية Azure Bastion. يتم استخدام خدمة Azure Bastion في الشبكة الظاهرية المركزية لإعادة الاتصال بالأجهزة الظاهرية (VMs) في المركز والشبكات الظاهرية المحورية من الإنترنت العام لأغراض الصيانة.
    • الشبكة الفرعية لنقطة النهاية الخاصة. تستضيف الشبكة الفرعية لنقطة النهاية الخاصة نقاط نهاية خاصة لأحمال العمل المستضافة من Azure في الشبكات الافتراضية التي لا يتم إقرانها بالمركز. باستخدام هذا النوع من الشبكة الافتراضية غير المتصلة، يمكن أن تتعارض عناوين IP الخاصة بها مع عناوين IP الأخرى المستخدمة في Azure ومحليا.
    • الشبكة الفرعية للبوابة. تستضيف الشبكة الفرعية للبوابة Azure VPN أو ExpressRoute، البوابة المستخدمة لتوفير الاتصال مرة أخرى إلى مركز البيانات المحلي.
    • الشبكة الفرعية للخدمات المشتركة. تستضيف الشبكة الفرعية للخدمات المشتركة الخدمات التي تتم مشاركتها بين أحمال عمل Azure المتعددة. في هذا السيناريو، تستضيف هذه الشبكة الفرعية الأجهزة الظاهرية التي تشغل Windows أو Linux التي تستخدم أيضا كخوادم DNS. تستضيف خوادم DNS هذه نفس مناطق DNS مثل الخوادم المحلية.
  • اشتراك متصل. يمثل الاشتراك المتصل مجموعة من أحمال العمل التي تتطلب شبكة ظاهرية والاتصال مرة أخرى بالشبكة المحلية.
    • نظير الشبكة الظاهرية. هذا المكون هو اتصال نظير مرة أخرى إلى الشبكة الظاهرية المركزية. يسمح هذا الاتصال بالاتصال من الشبكة المحلية إلى المحور والعودة من خلال الشبكة الظاهرية المركزية.
    • الشبكة الفرعية الافتراضية. تحتوي الشبكة الفرعية الافتراضية على نموذج حمل عمل.
      • web-vmss. تستضيف عينة مجموعة مقياس الجهاز الظاهري هذه حمل عمل في Azure يمكن الوصول إليه من أماكن العمل وAzure والإنترنت العام.
      • موازن التحميل. يوفر موازن التحميل الوصول إلى حمل العمل الذي تستضيفه سلسلة من الأجهزة الظاهرية. يجب استخدام عنوان IP لموازن التحميل هذا في الشبكة الفرعية الافتراضية للوصول إلى حمل العمل من Azure ومن مركز البيانات المحلي.
    • الشبكة الفرعية ل AppGateway. هذه الشبكة الفرعية هي الشبكة الفرعية المطلوبة لخدمة Azure Application Gateway.
      • AppGateway. توفر بوابة التطبيق الوصول إلى نموذج حمل العمل في الشبكة الفرعية الافتراضية للمستخدمين من الإنترنت العام.
      • wkld1-pip. هذا العنوان هو عنوان IP العام المستخدم للوصول إلى نموذج حمل العمل من الإنترنت العام.
  • اشتراك غير متصل. يمثل الاشتراك غير المتصل مجموعة من أحمال العمل التي لا تتطلب الاتصال مرة أخرى بمركز البيانات المحلي والتي تستخدم خدمة الارتباط الخاص.
    • PLSSubnet. تحتوي الشبكة الفرعية لخدمة الارتباط الخاص (PLSSubnet) على مورد واحد أو أكثر من موارد خدمة الارتباط الخاص التي توفر الاتصال بأحمال العمل المستضافة في الاشتراك المتصل.
    • الشبكة الفرعية الافتراضية. تحتوي الشبكة الفرعية الافتراضية على نموذج حمل عمل.
      • web-vmss. تستضيف عينة مجموعة مقياس الجهاز الظاهري هذه حمل عمل في Azure يمكن الوصول إليه من أماكن العمل وAzure والإنترنت العام.
      • موازن التحميل. يوفر موازن التحميل الوصول إلى حمل العمل الذي تستضيفه سلسلة من الأجهزة الظاهرية. يتم توصيل موازن التحميل هذا بخدمة الارتباط الخاص لتوفير الوصول للمستخدمين القادمين من Azure ومركز البيانات المحلي.
    • الشبكة الفرعية ل AppGateway. هذه الشبكة الفرعية هي الشبكة الفرعية المطلوبة لخدمة Application Gateway.
      • AppGateway. توفر بوابة التطبيق الوصول إلى نموذج حمل العمل في الشبكة الفرعية الافتراضية للمستخدمين من الإنترنت العام.
      • wkld2-pip. هذا العنوان هو عنوان IP العام المستخدم للوصول إلى نموذج حمل العمل من الإنترنت العام.
    • الشبكة الفرعية Azure Bastion. يتم استخدام خدمة Azure Bastion في الشبكة الظاهرية غير المتصلة لإعادة الاتصال بالأجهزة الظاهرية في المركز والشبكات الظاهرية المحورية من الإنترنت العام لأغراض الصيانة.

المكونات

  • الشبكة الظاهرية . Azure Virtual Network (VNet) هي لبنة الإنشاء الأساسية لشبكتك الخاصة في Azure. يتيح VNet الكثير من أنواع موارد Azure، مثل Azure Virtual Machines (VM)، للتواصل بشكل آمن مع بعضها البعض، والإنترنت، والشبكات المحلية.

  • Azure Bastion. Azure Bastion هي خدمة مدارة بالكامل توفر وصولاً أكثر أماناً وسلاسة لبروتوكول سطح المكتب البعيد (RDP) وبروتوكول Shell الآمن (SSH) إلى الأجهزة الظاهرية (VMs) دون أي تعرض من خلال عناوين IP العامة.

  • بوابة VPN. ترسل بوابة VPN حركة مرور مشفرة بين شبكة Azure الظاهرية وموقع محلي عبر الإنترنت العام. يمكنك أيضا استخدام بوابة VPN لإرسال نسبة استخدام الشبكة بطريقة مشفرة بين شبكات Azure الظاهرية عبر شبكة Microsoft. بوابة VPN عبارة عن نوع معين من بوابة الشبكة الظاهرية.

  • Private Link. يوفر Azure Private Link اتصالاً خاصاً من شبكة ظاهرية إلى نظام Azure الأساسي كخدمة (PaaS) أو مملوكة للعملاء أو خدمات شركاء Microsoft. فهو يبسط بنية الشبكة ويؤمن الاتصال بين نقاط النهاية في Azure عن طريق القضاء على تعرض البيانات للإنترنت العام.

  • بوابة التطبيق. إن«بوابة تطبيق» Azure هي موازن تحميل نسبة استخدام الشبكة على الويب التي تتيح لك إدارة نسبة استخدام الشبكة إلى تطبيقات الويب الخاصة بك. تعمل موازنات التحميل التقليدية في طبقة النقل (طبقة OSI 4 - TCP وUDP) وتوجه حركة المرور استناداً إلى عنوان IP المصدر والمنفذ، إلى عنوان IP الوجهة والمنفذ.

التوصيات

تنطبق التوصيات التالية على معظم السيناريوهات. اتبع هذه التوصيات ما لم يكن لديك متطلب محدد يلغيها.

إشعار

للحصول على التوصيات التالية، سنشير إلى حمل العمل 1 على أنه حمل عمل متصل و حمل العمل 2 كحمل عمل غير متصل. سنشير أيضا إلى المستخدمين والأنظمة التي تصل إلى أحمال العمل هذه كمستخدمين محليين، ومستخدمي الإنترنت، وونظمة Azure.

توسيع AD DS إلى Azure (اختياري)

استخدم مناطق DNS المتكاملة في AD DS لاستضافة سجلات DNS لمركز البيانات المحلي وAzure. في هذا السيناريو، هناك مجموعتين من خوادم DNS AD DS: واحدة محلية وواحدة في الشبكة الظاهرية المركزية.

نوصي بتوسيع مجال AD DS الخاص بك إلى Azure. نوصي أيضا بتكوين المركز والشبكات الظاهرية المحورية لاستخدام خوادم DNS AD DS في الشبكة الظاهرية المركزية لجميع الأجهزة الظاهرية في Azure.

إشعار

تنطبق هذه التوصية فقط على المؤسسات التي تستخدم منطقة DNS المتكاملة ل Active Directory لتحليل الاسم. يمكن للآخرين التفكير في تنفيذ خوادم DNS التي تعمل كمحلل/معاد توجيه.

تكوين DNS المقسم

تأكد من أن DNS المقسم للدماغ في مكانه للسماح لأنظمة Azure والمستخدمين المحليين ومستخدمي الإنترنت بالوصول إلى أحمال العمل استنادا إلى المكان الذي يتصلون منه.

لكل من أحمال العمل المتصلة وغير المتصلة، نوصي بالمكونات التالية لحل DNS:

لفهم توصية تقسيم الدماغ هذه بشكل أفضل، ضع في اعتبارك حمل العمل 1، الذي سنستخدم له wkld1.contoso.com اسم المجال المؤهل بالكامل (FQDN).

في هذا السيناريو، يجب على مستخدمي الإنترنت حل هذا الاسم إلى عنوان IP العام الذي تعرضه بوابة التطبيق من خلال Wkld1-pip. تتم هذه الدقة عن طريق إنشاء سجل عنوان (سجل A) في Azure DNS للاشتراك المتصل.

يجب على المستخدمين المحليين حل نفس الاسم إلى عنوان IP الداخلي لموازن التحميل في الاشتراك المتصل. تتم هذه الدقة عن طريق إنشاء سجل A في خوادم DNS في اشتراك المركز.

يمكن لأنظمة Azure حل نفس الاسم إلى عنوان IP داخلي لموازن التحميل في الاشتراك المتصل إما عن طريق إنشاء سجل A في خادم DNS في اشتراك المركز، أو باستخدام مناطق DNS الخاصة. عند استخدام مناطق DNS الخاصة، إما إنشاء سجل A يدويا في منطقة DNS الخاصة أو تمكين التسجيل التلقائي.

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

لفهم توصيات DNS ل حمل العمل 2 بشكل أفضل، سنستخدم wkld2.contoso.com FQDN ونناقش التوصيات الفردية.

في هذا السيناريو، يجب على مستخدمي الإنترنت حل هذا الاسم إلى عنوان IP العام الذي تعرضه بوابة التطبيق من خلال Wkld2-pip. تتم هذه الدقة عن طريق إنشاء سجل A في Azure DNS للاشتراك المتصل.

يجب على المستخدمين المحليين وأنظمة Azure المتصلة بالشبكة الظاهرية المركزية والشبكات الظاهرية المحورية حل نفس الاسم إلى عنوان IP داخلي لنقطة النهاية الخاصة في Hub VNet. تتم هذه الدقة عن طريق إنشاء سجل A في خوادم DNS في اشتراك المركز.

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

لا يزال بإمكان أنظمة Azure في الشبكات الظاهرية المختلفة حل عنوان IP لحمل العمل 2 إذا قمت بربط تلك الشبكات الظاهرية بمنطقة DNS الخاصة التي تستضيف سجل A لحمل العمل 2.

تمكين التسجيل التلقائي

عند تكوين ارتباط VNet مع منطقة DNS خاصة، يمكنك اختياريا تكوين التسجيل التلقائي للسجل التلقائي لجميع الأجهزة الظاهرية.

إشعار

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

إذا كنت تستخدم خادم AD DS DNS، فقم بتكوين Windows يمكن للأجهزة الظاهرية استخدام التحديثات الديناميكية لأجهزة الكمبيوتر Windows للحفاظ على سجلات DNS الخاصة بك محدثة في خوادم AD DS DNS. نوصي بتمكين التحديثات الديناميكية وتكوين خوادم DNS للسماح بالتحديثات الآمنة فقط.

لا تدعم أجهزة Linux الظاهرية التحديثات الديناميكية الآمنة. بالنسبة لأجهزة كمبيوتر Linux المحلية، استخدم بروتوكول تكوين المضيف الديناميكي (DHCP) لتسجيل سجلات DNS إلى خوادم DNS AD DS.

بالنسبة لأجهزة Linux الظاهرية في Azure، استخدم عملية تلقائية.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

قابلية التوسع

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

التوافر

  • ضع في اعتبارك موضع خوادم DNS. كما هو موضح في قسم اعتبارات قابلية التوسع، يجب وضع خوادم DNS بالقرب من المستخدمين والأنظمة التي تحتاج إلى الوصول إليها.
    • لكل منطقة Azure. تحتوي كل منطقة Azure على شبكة ظاهرية مركزية خاصة بها أو مركز vWAN. هذا هو المكان الذي يجب نشر خوادم DNS فيه.
    • لكل مركز بيانات محلي. يجب أن يكون لديك أيضا زوج من خوادم DNS لكل مركز بيانات محلي للمستخدمين والأنظمة في تلك المواقع.
    • بالنسبة لأحمال العمل المعزولة (غير المتصلة)، استضيف منطقة DNS خاصة ومنطقة DNS عامة لكل اشتراك لإدارة سجلات DNS المقسمة.

قَابلية الإدارة

  • ضع في اعتبارك الحاجة إلى سجلات DNS لخدمات النظام الأساسي كخدمة (PaaS).
  • يجب أيضا مراعاة دقة DNS لخدمات PaaS التي تستخدم نقطة نهاية خاصة. استخدم منطقة DNS خاصة لذلك واستخدم مسار DevOps لإنشاء سجلات في خوادم DNS.

الأمان

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

  • إذا كنت تحتاج إلى استخدام DNSSEC، ففكر في أن Azure DNS لا يدعمه حاليا.
  • للتحقق من صحة DNSSEC، قم بنشر خادم DNS مخصص وتمكين التحقق من صحة DNSEC.
  • توفر Azure DDoS Protection، جنبا إلى جنب مع أفضل ممارسات تصميم التطبيق، ميزات محسنة لتخفيف DDoS لتوفير المزيد من الدفاع ضد هجمات DDoS. يجب تمكين Azure DDOS Protection على أي شبكة ظاهرية محيطة.

DevOps

  • أتمتة تكوين هذه البنية من خلال الجمع بين قوالب Azure Resource Manager لتكوين جميع الموارد. تدعم مناطق DNS الخاصة والعامة الإدارة الكاملة من Azure CLI وPowerShell و.NET وAPI REST.
  • إذا كنت تستخدم مسار تكامل مستمر وتطوير مستمر (CI/CD) لنشر أحمال العمل وصيانتها في Azure وفي أماكن العمل، يمكنك أيضا تكوين التسجيل التلقائي لسجلات DNS.

تحسين التكلفة

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

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

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

تعرف على المزيد حول تقنيات المكونات:

استكشاف البنى ذات الصلة: