نظرة عامة على الشبكات لقاعدة بيانات Azure ل PostgreSQL - خادم مرن مع وصول خاص (تكامل VNET)

يطبق على: قاعدة بيانات Azure لـ PostgreSQL - الخادم المرن

توضح هذه المقالة مفاهيم الاتصال والشبكات لقاعدة بيانات Azure لخادم PostgreSQL المرن.

عند إنشاء مثيل خادم مرن لقاعدة بيانات Azure ل PostgreSQL، يجب عليك اختيار أحد خيارات الشبكة التالية: الوصول الخاص (تكامل VNet) أو الوصول العام (عناوين IP المسموح بها) ونقطة النهاية الخاصة. سيصف هذا المستند خيار شبكة الوصول الخاص (تكامل VNet).

الوصول الخاص (تكامل VNet)

يمكنك نشر مثيل خادم مرن لقاعدة بيانات Azure ل PostgreSQL في شبكة Azure الظاهرية (VNet) باستخدام حقن VNET. تساعد شبكات Azure الظاهرية على توفير اتصال شبكة خاص وآمن. يمكن للموارد في شبكة ظاهرية الاتصال من خلال عناوين IP الخاصة التي تم تعيينها على هذه الشبكة.

حدد خيار الشبكة هذا إذا كنت تريد الإمكانات التالية:

  • الاتصال من موارد Azure في نفس الشبكة الظاهرية إلى مثيل خادم Azure Database for PostgreSQL المرن باستخدام عناوين IP الخاصة.
  • استخدم VPN أو Azure ExpressRoute للاتصال من موارد غير Azure بقاعدة بيانات Azure لمثيل خادم PostgreSQL المرن.
  • تأكد من أن مثيل خادم Azure Database for PostgreSQL المرن لا يحتوي على نقطة نهاية عامة يمكن الوصول إليها من خلال الإنترنت.

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

في الرسم التخطيطي السابق:

  • يتم إدخال قواعد بيانات Azure لمثيلات الخادم المرن PostgreSQL في الشبكة الفرعية 10.0.1.0/24 للشبكة الظاهرية VNet-1.
  • يمكن للتطبيقات التي يتم نشرها على شبكات فرعية مختلفة داخل نفس الشبكة الظاهرية الوصول إلى قاعدة بيانات Azure لمثيلات الخادم المرن PostgreSQL مباشرة.
  • لا تتمتع التطبيقات التي يتم نشرها على شبكة ظاهرية مختلفة (VNet-2) بالوصول المباشر إلى قاعدة بيانات Azure لمثيلات الخادم المرن PostgreSQL. يجب عليك إجراء نظير شبكة ظاهرية لمنطقة DNS خاصة قبل أن يتمكنوا من الوصول إلى الخادم المرن.

مفاهيم الشبكة الظاهرية

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

فيما يلي بعض المفاهيم التي يجب أن تكون على دراية بها عند استخدام الشبكات الظاهرية حيث يتم دمج الموارد في الشبكة الظاهرية مع قاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة:

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

    يجب أن يكون مثيل الخادم المرن لقاعدة بيانات Azure المتكاملة ل VNET ل PostgreSQL في شبكة فرعية مفوضة. أي أن قاعدة بيانات Azure لمثيلات الخادم المرن PostgreSQL فقط يمكنها استخدام تلك الشبكة الفرعية. لا يمكن أن توجد أنواع موارد Azure أخرى في الشبكة الفرعية المفوضة. يمكنك تفويض شبكة فرعية عن طريق تعيين خاصية التفويض الخاصة بها كـ Microsoft.DBforPostgreSQL/flexibleServers. أصغر نطاق CIDR يمكنك تحديده للشبكة الفرعية هو /28، والذي يوفر 16 عنوان IP، ولكن لا يمكن تعيين العنوان الأول والأخير في أي شبكة أو شبكة فرعية إلى أي مضيف فردي. تحتفظ Azure بخمسة عناوين IP لاستخدامها داخليا بواسطة شبكات Azure، والتي تتضمن اثنين من عناوين IP التي لا يمكن تعيينها للاستضافة، المذكورة أعلاه. هذا يترك لك 11 عنوان IP متوفرا لنطاق CIDR /28، بينما يستخدم مثيل خادم Azure Database for PostgreSQL المرن مع ميزات قابلية الوصول العالية أربعة عناوين. بالنسبة لاتصالات النسخ المتماثل وMicrosoft Entra، يرجى التأكد من أن جداول التوجيه لا تؤثر على حركة المرور. يتم توجيه نمط شائع لجميع نسبة استخدام الشبكة الصادرة عبر جدار حماية Azure أو جهاز تصفية شبكة محلي مخصص. إذا كانت الشبكة الفرعية تحتوي على جدول توجيه مقترن بالقاعدة لتوجيه كافة نسبة استخدام الشبكة إلى جهاز ظاهري:

    • إضافة قاعدة باستخدام علامة خدمة الوجهة "AzureActiveDirectory" والوثبة التالية "الإنترنت"
    • إضافة قاعدة مع نطاق IP الوجهة نفس نطاق الشبكة الفرعية للخادم المرن لقاعدة بيانات Azure ل PostgreSQL والوثبة التالية "الشبكة الظاهرية"

    هام

    الأسماء AzureFirewallSubnet وAzureFirewallManagementSubnet وAzureBastionSubnet وGatewaySubnet محجوزة داخل Azure. لا تستخدم أياً من هذه كاسم شبكتك الفرعية.

  • مجموعة أمان الشبكة (NSG). تمكّنك قواعد الأمان في مجموعات NSG من تصفية نوع نسبة استخدام الشبكة التي يمكن أن تتدفق داخل وخارج الشبكات الفرعية للشبكة الظاهرية وواجهات الشبكة. لمزيد من المعلومات، راجع نظرة عامة على NSG.

    تسهل مجموعات أمان التطبيقات (ASGs) التحكم في أمان الطبقة الرابعة باستخدام مجموعات NSG للشبكات المسطحة. يمكنك بسرعة:

    • الانضمام إلى الأجهزة الظاهرية في ASG، أو إزالة الأجهزة الظاهرية من ASG.
    • تطبيق القواعد ديناميكياً على تلك الأجهزة الظاهرية، أو إزالة القواعد من تلك الأجهزة الظاهرية.

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

    في هذا الوقت، لا ندعم مجموعات أمان الشبكة حيث يكون ASG جزءا من القاعدة مع قاعدة بيانات Azure لخادم PostgreSQL المرن. ننصح حالياً باستخدام تصفية المصدر أو الوجهة المستندة إلى IP في NSG.

    هام

    تتطلب قابلية الوصول العالية والميزات الأخرى لقاعدة بيانات Azure لخادم PostgreSQL المرن القدرة على إرسال/تلقي نسبة استخدام الشبكة إلى منفذ الوجهة 5432 داخل الشبكة الفرعية لشبكة Azure الظاهرية حيث يتم نشر خادم Azure Database for PostgreSQL المرن، وكذلك إلى تخزين Azure لأرشفة السجل. إذا قمت بإنشاء مجموعات أمان الشبكة (NSG) لرفض تدفق نسبة استخدام الشبكة من وإلى قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن داخل الشبكة الفرعية حيث يتم نشرها، فتأكد من السماح بنسبة استخدام الشبكة إلى منفذ الوجهة 5432 داخل الشبكة الفرعية، وكذلك إلى تخزين Azure باستخدام علامة الخدمة Azure Storage كوجهة. يمكنك تصفية قاعدة الاستثناء هذه عن طريق إضافة منطقة Azure إلى التسمية مثل us-east.storage. أيضا، إذا اخترت استخدام مصادقة Microsoft Entra لمصادقة تسجيلات الدخول إلى قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن، فاسمح بنسبة استخدام الشبكة الصادرة إلى معرف Microsoft Entra باستخدام علامة خدمة Microsoft Entra. عند إعداد قراءة النسخ المتماثلة عبر مناطق Azure، تتطلب قاعدة بيانات Azure لخادم PostgreSQL المرن القدرة على إرسال/تلقي نسبة استخدام الشبكة إلى منفذ الوجهة 5432 لكل من الأساسي والنسخة المتماثلة، بالإضافة إلى تخزين Azure في مناطق النسخ المتماثلة الأساسية من كل من خوادم النسخ المتماثلة والأساسية.

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

استخدام منطقة DNS خاصة

يوفر Azure Private DNS خدمة DNS موثوقة وآمنة لشبكتك الظاهرية. يقوم Azure Private DNS بإدارة وحل أسماء المجالات في الشبكة الافتراضية دون الحاجة إلى تكوين حل DNS مخصص.

عند استخدام الوصول إلى الشبكة الخاصة مع شبكة Azure الظاهرية، يعد توفير معلومات منطقة DNS الخاصة إلزاميا لكي تتمكن من إجراء تحليل DNS. لإنشاء مثيل خادم مرن جديد ل Azure Database for PostgreSQL باستخدام الوصول إلى الشبكة الخاصة، يجب استخدام مناطق DNS الخاصة أثناء تكوين قاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة مع وصول خاص. لإنشاء مثيل خادم مرن جديد ل Azure Database for PostgreSQL باستخدام الوصول إلى الشبكة الخاصة باستخدام واجهة برمجة التطبيقات أو ARM أو Terraform، أنشئ مناطق DNS خاصة واستخدمها أثناء تكوين قاعدة بيانات Azure لمثيلات الخادم المرن PostgreSQL مع وصول خاص. اطلع على مزيد من المعلومات حول مواصفات REST API لـ Microsoft Azure. إذا كنت تستخدم مدخل Microsoft Azure أو Azure CLI لإنشاء قاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة، يمكنك إما توفير اسم منطقة DNS خاص قمت بإنشائه مسبقا في نفس الاشتراك أو اشتراك مختلف أو يتم إنشاء منطقة DNS خاصة افتراضية تلقائيا في اشتراكك.

إذا كنت تستخدم واجهة برمجة تطبيقات Azure أو قالب Azure Resource Manager (قالب ARM) أو Terraform، فبادر بإنشاء مناطق DNS خاصة تنتهي ب .postgres.database.azure.com. استخدم هذه المناطق أثناء تكوين قاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة مع وصول خاص. على سبيل المثال، استخدم النموذج [name1].[name2].postgres.database.azure.com أو [name].postgres.database.azure.com. إذا اخترت استخدام النموذج [name].postgres.database.azure.com، فلا يمكن أن يكون الاسم هو الاسم الذي تستخدمه لأحد قواعد بيانات Azure لمثيلات الخادم المرن ل PostgreSQL أو سيتم عرض رسالة خطأ أثناء التوفير. لمزيد من المعلومات، راجع نظرة عامة على مناطق DNS الخاصة.

باستخدام مدخل Microsoft Azure أو واجهة برمجة التطبيقات أو CLI أو ARM، يمكنك أيضا تغيير منطقة DNS الخاصة من المنطقة التي قدمتها عند إنشاء مثيل خادم مرن لقاعدة بيانات Azure ل PostgreSQL إلى منطقة DNS خاصة أخرى موجودة في نفس الاشتراك أو اشتراك مختلف.

هام

القدرة على تغيير منطقة DNS الخاصة من تلك التي قدمتها عند إنشاء مثيل خادم مرن لقاعدة بيانات Azure ل PostgreSQL إلى منطقة DNS خاصة أخرى معطلة حاليا للخوادم مع تمكين ميزة التوفر العالي.

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

هام

لم نعد نتحقق من وجود ارتباط الشبكة الظاهرية على إنشاء الخادم لقاعدة بيانات Azure لخادم PostgreSQL المرن مع الشبكات الخاصة. عند إنشاء خادم من خلال المدخل نقدم اختيار العميل لإنشاء ارتباط عند إنشاء الخادم عبر خانة الاختيار "ربط منطقة DNS الخاصة بالشبكة الظاهرية الخاصة بك" في مدخل Microsoft Azure.

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

التكامل مع خادم DNS مخصص

إذا كنت تستخدم خادم DNS مخصصا، فيجب عليك استخدام معيد توجيه DNS لحل FQDN لقاعدة بيانات Azure لخادم PostgreSQL المرن. يجب أن يكون عنوان IP الخاص بمعيد التوجيه هو 168.63.129.16.

يجب أن يكون خادم DNS المخصص داخل الشبكة الظاهرية أو يمكن الوصول إليه عبر إعداد خادم DNS للشبكة الظاهرية. لمعرفة المزيد، راجع تحليل الاسم الذي يستخدم خادم DNS الخاص بك.

منطقة DNS الخاصة وتناظر الشبكة الظاهرية

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

إشعار

يمكن ربط أسماء مناطق DNS الخاصة التي تنتهي ب "postgres.database.azure.com". لا يمكن أن يكون اسم منطقة DNS هو نفس مثيل (مثيلات) خادم Azure Database for PostgreSQL المرن وإلا سيفشل تحليل الاسم.

لتعيين اسم خادم إلى سجل DNS، يمكنك تشغيل أمر nslookup في Azure Cloud Shell باستخدام Azure PowerShell أو Bash، واستبدال اسم الخادم الخاص بك لمعلمة <server_name> في المثال أدناه:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

استخدام تصميم الشبكات الخاصة Hub و Spoke

Hub and spoke هو نموذج شبكة شائع لإدارة متطلبات الاتصال أو الأمان الشائعة بكفاءة.

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

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

هناك ثلاثة أنماط رئيسية لتوصيل الشبكات الظاهرية المحورية ببعضها البعض:

  • المحاور متصلة مباشرة ببعضها البعض. يتم إنشاء نظيرات الشبكة الظاهرية أو أنفاق VPN بين الشبكات الظاهرية المحورية لتوفير اتصال مباشر دون اجتياز الشبكة الظاهرية للمركز.
  • تتواصل المحاور عبر جهاز شبكة. تحتوي كل شبكة ظاهرية محورية على نظير ل Virtual WAN أو إلى شبكة ظاهرية مركزية. يقوم الجهاز بتوجيه نسبة استخدام الشبكة من spoke إلى spoke. يمكن إدارة الجهاز بواسطة Microsoft (كما هو الحال مع Virtual WAN) أو من قبلك.
  • بوابة الشبكة الظاهرية المرفقة بشبكة المركز والاستفادة من المسارات المعرفة من قبل المستخدم (UDR)، لتمكين الاتصال بين المحاور.

رسم تخطيطي يوضح بنية المركز المحوري الأساسية مع الاتصال المختلط عبر Express Hub.

استخدم Azure Virtual Network Manager (AVNM) لإنشاء محور جديد (قم بإدخال الموجود) وطوبولوجيا شبكة ظاهرية للمحور للإدارة المركزية لعناصر التحكم في الاتصال والأمان.

التواصل مع العملاء ذوي الشبكات الخاصة في مناطق مختلفة

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

  • نظير الشبكة الظاهرية العمومية. المنهجية الأكثر شيوعا، لأنها أسهل طريقة لتوصيل الشبكات في مناطق مختلفة معا. ينشئ نظير VNET العمومي اتصالا عبر العمود الفقري ل Azure مباشرة بين شبكتي VNET المتناظرتين. يوفر هذا أفضل معدل نقل للشبكة وأقل زمن انتقال للاتصال باستخدام هذا الأسلوب. عندما يتم إقران VNETs، سيتعامل Azure أيضا مع التوجيه تلقائيا نيابة عنك، يمكن ل VNETs هذه الاتصال بجميع الموارد في VNET المتناظرة، التي تم إنشاؤها على بوابة VPN.
  • اتصال VNET إلى VNET. اتصال VNET إلى VNET هو في الأساس VPN بين موقعي Azure المختلفين. يتم إنشاء اتصال VNET إلى VNET على بوابة VPN. وهذا يعني أن نسبة استخدام الشبكة الخاصة بك تتحمل قفزتين إضافيتين لنسبة استخدام الشبكة مقارنة بتناظر VNET العالمي. هناك أيضا زمن انتقال إضافي وعرض نطاق ترددي أقل مقارنة بتلك الطريقة.
  • الاتصال عبر جهاز الشبكة في بنية Hub و Spoke. بدلا من توصيل الشبكات الظاهرية المحورية مباشرة ببعضها البعض، يمكنك استخدام أجهزة الشبكة لإعادة توجيه نسبة استخدام الشبكة بين المحاور. توفر أجهزة الشبكة المزيد من خدمات الشبكة مثل الفحص العميق للحزمة وتجزئة حركة المرور أو المراقبة، ولكنها يمكن أن تؤدي إلى اختناقات في زمن الانتقال والأداء إذا لم يتم تغيير حجمها بشكل صحيح.

النسخ المتماثل عبر مناطق Azure والشبكات الظاهرية مع الشبكات الخاصة

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

يوفر خادم Azure Database for PostgreSQL المرن طريقتين للنسخ المتماثل: الفعلية (أي البث) عبر ميزة النسخ المتماثل للقراءة المضمنة والنسخ المتماثل المنطقي. كلاهما مثالي لحالات الاستخدام المختلفة، ويمكن للمستخدم اختيار واحدة على الأخرى اعتمادا على الهدف النهائي.

يتطلب النسخ المتماثل عبر مناطق Azure، مع شبكات ظاهرية منفصلة (VNETs) في كل منطقة، الاتصال عبر حدود الشبكة الظاهرية الإقليمية التي يمكن توفيرها عبر نظير الشبكة الظاهرية أو في تصميمات Hub و Spoke عبر جهاز الشبكة.

بشكل افتراضي، يتم تحديد نطاق تحليل اسم DNS إلى شبكة ظاهرية. وهذا يعني أن أي عميل في شبكة ظاهرية واحدة (VNET1) غير قادر على حل قاعدة بيانات Azure لخادم PostgreSQL المرن FQDN في شبكة ظاهرية أخرى (VNET2).

لحل هذه المشكلة، يجب التأكد من أن العملاء في VNET1 يمكنهم الوصول إلى قاعدة بيانات Azure لخادم PostgreSQL المرن منطقة DNS الخاصة. يمكن تحقيق ذلك عن طريق إضافة ارتباط شبكة ظاهرية إلى منطقة DNS الخاصة بقاعدة بيانات Azure لمثيل خادم PostgreSQL المرن.

سيناريوهات الشبكة الظاهرية غير المدعومة

فيما يلي بعض القيود للعمل مع الشبكات الظاهرية التي تم إنشاؤها عبر تكامل VNET:

  • بعد نشر مثيل خادم مرن لقاعدة بيانات Azure ل PostgreSQL إلى شبكة ظاهرية وشبكة فرعية، لا يمكنك نقلها إلى شبكة ظاهرية أو شبكة فرعية أخرى. لا يمكنك نقل الشبكة الظاهرية إلى مجموعة موارد أخرى أو اشتراك.
  • لا يمكن زيادة حجم الشبكة الفرعية (مساحات العنوان) بعد وجود الموارد في الشبكة الفرعية.
  • لا يمكن للموارد المحقونة في VNET التفاعل مع Private Link بشكل افتراضي. إذا كنت ترغب في استخدام Private Link للشبكات الخاصة، فشاهد Azure Database for PostgreSQL flexible server networking with Private Link

هام

يدعم Azure Resource Manager القدرة على تأمين الموارد، كعنصر تحكم أمان. يتم تطبيق تأمين الموارد على المورد، وهي فعالة عبر كافة المستخدمين والأدوار. هناك نوعان من تأمين المورد: CanNotDelete و ReadOnly. يمكن تطبيق أنواع التأمين هذه إما على منطقة DNS خاصة أو على مجموعة سجلات فردية. قد يتداخل تطبيق تأمين من أي نوع مقابل منطقة DNS الخاصة أو مجموعة السجلات الفردية مع قدرة قاعدة بيانات Azure لخادم PostgreSQL المرن على تحديث سجلات DNS والتسبب في مشكلات أثناء العمليات الهامة على DNS، مثل تجاوز الفشل عالي التوفر من الأساسي إلى الثانوي. لهذه الأسباب، يرجى التأكد من عدم استخدام منطقة DNS الخاصة أو تأمين السجلات عند استخدام ميزات التوفر العالي مع قاعدة بيانات Azure لخادم PostgreSQL المرن.

اسم المضيف

بغض النظر عن خيار الشبكة الذي تختاره، نوصي دائما باستخدام FQDN كاسم مضيف عند الاتصال بقاعدة بيانات Azure لمثيل خادم PostgreSQL المرن. عنوان IP الخاص بالخادم غير مضمون للبقاء ثابتا. يساعدك استخدام FQDN على تجنب إجراء تغييرات على سلسلة الاتصال.

مثال يستخدم FQDN كاسم مضيف هو hostname = servername.postgres.database.azure.com. حيثما أمكن، تجنب استخدام hostname = 10.0.0.4 (عنوان خاص) أو hostname = 40.2.45.67 (عنوان عام).

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

  • تعرف على كيفية إنشاء مثيل خادم مرن لقاعدة بيانات Azure ل PostgreSQL باستخدام خيار الوصول الخاص (تكامل VNet) في مدخل Microsoft Azure أو Azure CLI.