ترحيل مثيل إدارة واجهة برمجة التطبيقات المحقونة من VNet المستضاف على منصة stv1 إلى stv2

ينطبق على: المطور | قسط

توفر هذه المقالة خطوات لترحيل مثيل APIM المستضاف على stv1 النظام الأساسي للحساب في مكانه إلى stv2 النظام الأساسي عند إدخال المثيل (نشره) في VNet خارجية أو داخلية. تعرف على ما إذا كنت بحاجة إلى القيام بذلك.

بالنسبة لمثيل VNet-inject، لديك خيارات الترحيل التالية:

• الخيار 1: الاحتفاظ بنفس الشبكة الفرعية - ترحيل المثيل في مكانه والاحتفاظ بتكوين الشبكة الفرعية الموجودة للمثيلات. يمكنك اختيار ما إذا كان يتم الاحتفاظ بعنوان VIP الأصلي لمثيل APIM (مستحسن) أو ما إذا كان سيتم إنشاء عنوان VIP جديد.

• الخيار 2: التغيير إلى شبكة فرعية جديدة - قم بترحيل المثيل الخاص بك عن طريق تحديد شبكة فرعية مختلفة في نفس الشبكة الظاهرية أو شبكة ظاهرية مختلفة. بعد الترحيل، قم بالترحيل مرة أخرى اختياريا إلى الشبكة الفرعية الأصلية للمثيل. تغير عملية الترحيل عنوان (عناوين) VIP للمثيل. بعد الترحيل، تحتاج إلى تحديث أي تبعيات للشبكة بما في ذلك DNS وقواعد جدار الحماية والشبكات الظاهرية لاستخدام عنوان (عناوين) VIP الجديد.

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

إذا كنت بحاجة إلى ترحيل إدارة واجهة برمجة التطبيقات غير المحقونة من VNet المستضافة stv1 على النظام الأساسي، فشاهد ترحيل مثيل إدارة واجهة برمجة التطبيقات غير المحقونة من VNet إلى النظام الأساسي stv2.

ماذا يحدث أثناء الترحيل؟

يتضمن ترحيل النظام الأساسي لإدارة واجهة برمجة التطبيقات من stv1 إلى stv2 تحديث الحساب الأساسي وحده وليس له أي تأثير على تكوين الخدمة/واجهة برمجة التطبيقات المستمر في طبقة التخزين.

• تتضمن عملية الترقية إنشاء حساب جديد بالتوازي مع الحساب القديم، والذي قد يستغرق ما يصل إلى 45 دقيقة. التخطيط لأوقات أطول للتوزيعات متعددة المناطق وفي السيناريوهات التي تتضمن تغيير الشبكة الفرعية أكثر من مرة.
• ستكون حالة إدارة واجهة برمجة التطبيقات في مدخل Microsoft Azure قيد التحديث.
• بالنسبة لبعض خيارات الترحيل، يمكنك اختيار الاحتفاظ بعنوان VIP أو سيتم إنشاء VIP عام جديد.
• بالنسبة لسيناريوهات الترحيل عند إنشاء عنوان VIP جديد:
  • يدير Azure الترحيل.
  • لا يزال DNS للبوابة يشير إلى الحساب القديم إذا كان المجال المخصص قيد الاستخدام.
  • إذا لم يكن DNS المخصص قيد الاستخدام، فإن DNS للبوابة والمدخل يشيران إلى الحساب الجديد على الفور.
  • بالنسبة لمثيل في وضع VNet الداخلي، يدير العميل DNS، لذلك تستمر إدخالات DNS في الإشارة إلى الحوسبة القديمة حتى يتم تحديثها من قبل العميل.
  • إنها DNS التي تشير إما إلى الحساب الجديد أو القديم وبالتالي لا يوجد وقت تعطل لواجهات برمجة التطبيقات.
  • التغييرات مطلوبة على قواعد جدار الحماية، إن وجدت، للسماح للشبكة الفرعية للحوسبة الجديدة بالوصول إلى الواجهات الخلفية.
  • بعد الترحيل الناجح، يتم إيقاف تشغيل الحساب القديم تلقائيا بعد فترة قصيرة. عند التغيير إلى شبكة فرعية جديدة باستخدام شفرة ترحيل النظام الأساسي في المدخل، يمكنك تمكين إعداد ترحيل للاحتفاظ بالبوابة القديمة لمدة 48 ساعة. يتوفر خيار التأخير لمدة 48 ساعة فقط للخدمات المحقونة من VNet.

المتطلبات الأساسية

• مثيل APIM مستضاف على stv1 النظام الأساسي للحساب. للتأكد من استضافة المثيل الخاص بك على stv1 النظام الأساسي، راجع كيف أعمل معرفة النظام الأساسي الذي يستضيف مثيل APIM الخاص بي؟
• يجب نشر المثيل حاليا في شبكة ظاهرية خارجية أو داخلية.

المتطلبات الأساسية الأخرى خاصة بخيارات الترحيل في الأقسام التالية.

الخيار 1: ترحيل الشبكة الفرعية نفسها والاحتفاظ بها

يمكنك ترحيل مثيل APIM الخاص بك إلى stv2 النظام الأساسي مع الاحتفاظ بتكوين الشبكة الفرعية الموجودة، ما يبسط الترحيل. يمكنك الترحيل باستخدام شفرة ترحيل النظام الأساسي في مدخل Microsoft Azure أو ترحيل إلى Stv2 REST API.

المتطلبات الأساسية

• يجب إرفاق مجموعة أمان الشبكة بكل شبكة فرعية، ويجب تكوين قواعد NSG لإدارة واجهة برمجة التطبيقات على stv2 النظام الأساسي. فيما يلي الحد الأدنى من إعدادات الاتصال:

  • الصادر إلى Azure Storage عبر المنفذ 443
  • الصادر إلى Azure SQL عبر المنفذ 1433
  • الصادر إلى Azure Key Vault عبر المنفذ 443
  • الواردة من Azure Load Balancer عبر المنفذ 6390
  • الواردة من علامة خدمة ApiManagement عبر المنفذ 3443
  • الوارد عبر المنفذ 80/443 للعملاء الذين يتصلون بخدمة APIM
  • يجب أن تحتوي الشبكة الفرعية على نقاط نهاية خدمة ممكنة ل Azure Storage وAzure SQL وAzure Key Vault

• يجب أن تكون مساحة العنوان لكل شبكة فرعية موجودة كبيرة بما يكفي لاستضافة نسخة من الخدمة الموجودة جنبا إلى جنب مع الخدمة الحالية أثناء الترحيل.

• اعتبارات الشبكة الأخرى:

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

• استخدم بيئة Bash في Azure Cloud Shell. لمزيد من المعلومات، راجع التشغيل السريع ل Bash في Azure Cloud Shell.

  

• إذا كنت تفضل تشغيل أوامر مرجع CLI محلياً قم بتثبيت CLI Azure. إذا كنت تعمل على نظام تشغيل Windows أو macOS، ففكر في تشغيل Azure CLI في حاوية Docker. لمزيد من المعلومات، راجع كيفية تشغيل Azure CLI في حاوية Docker.

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

  • عندما يُطلب منك، قم بتثبيت ملحق Azure CLI عند الاستخدام لأول مرة. لمزيد من المعلومات بشأن الامتدادات، راجع استخدام امتدادات مع Azure CLI.

  • يُرجى تشغيل إصدار az للوصول إلى الإصدار والمكتبات التابعة التي تم تثبيتها. للتحديث لآخر إصدار، يُرجى تشغيل تحديث az.

خيارات عنوان IP العام - ترحيل نفس الشبكة الفرعية

يمكنك اختيار ما إذا كان يتم الاحتفاظ بعنوان VIP الأصلي لمثيل APIM (مستحسن) أو ما إذا كان سيتم إنشاء عنوان VIP جديد.

• الاحتفاظ بعنوان IP الظاهري - إذا قمت بالاحتفاظ بعنوان VIP في VNet في الوضع الخارجي، يمكن أن تظل طلبات واجهة برمجة التطبيقات مستجيبة أثناء الترحيل (راجع وقت التعطل المتوقع)؛ بالنسبة للشبكة الظاهرية في الوضع الداخلي، من المتوقع وقت تعطل مؤقت. سيتم تأمين تكوين البنية الأساسية (مثل المجالات المخصصة والمواقع وشهادات المرجع المصدق) لمدة 45 دقيقة. لا يلزم إجراء أي تكوين آخر بعد الترحيل.

  باستخدام هذا الخيار، stv1 يتم حذف الحساب نهائيا بعد اكتمال الترحيل. لا يوجد خيار للاحتفاظ به مؤقتا.

  تعرض الصورة التالية نظرة عامة عالية المستوى لما يحدث عند الاحتفاظ بعنوان IP.

  

• عنوان IP ظاهري جديد - إذا اخترت هذا الخيار، فإن APIM تنشئ عنوان VIP جديدا للمثيل الخاص بك. تظل طلبات واجهة برمجة التطبيقات مستجيبة أثناء الترحيل. سيتم تأمين تكوين البنية الأساسية (مثل المجالات المخصصة والمواقع وشهادات المرجع المصدق) لمدة 30 دقيقة. بعد الترحيل، ستحتاج إلى تحديث أي تبعيات للشبكة بما في ذلك DNS وقواعد جدار الحماية وVNets لاستخدام عنوان VIP الجديد.

  باستخدام هذا الخيار، stv1 يتم الاحتفاظ بالحوسبة لفترة قصيرة بشكل افتراضي بعد اكتمال الترحيل بحيث يمكنك التحقق من صحة المثيل الذي تم ترحيله وتأكيد الشبكة وتكوين DNS.

  تعرض الصورة التالية نظرة عامة عالية المستوى لما يحدث عند إنشاء عنوان IP جديد.

  

عنوان IP تم إنشاؤه مسبقا للترحيل

بالنسبة لمثيلات APIM التي يمكن الوصول إليها بواسطة عنوان IP عام، تقوم APIM بإنشاء عنوان IP عام مسبقا لعملية الترحيل. ابحث عن عنوان IP الذي تم إنشاؤه مسبقا في إخراج JSON لخصائص مثيل APIM. ضمن customProperties، عنوان IP الذي تم إنشاؤه مسبقا هو قيمة الخاصية Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps . للنشر متعدد المناطق، القيمة هي قائمة مفصولة بفواصل لعناوين IP التي تم إنشاؤها مسبقا.

استخدم عنوان IP (أو العناوين) الذي تم إنشاؤه مسبقا لمساعدتك في إدارة عملية الترحيل:

• عند ترحيل عنوان VIP والاحتفاظ به، يتم تعيين عنوان IP الذي تم إنشاؤه مسبقا مؤقتا إلى النشر الجديد stv2 ، قبل تعيين عنوان IP الأصلي للنشر stv2 . إذا كانت لديك قواعد جدار حماية تحد من الوصول إلى مثيل APIM، على سبيل المثال، يمكنك إضافة عنوان IP الذي تم إنشاؤه مسبقا إلى قائمة السماح للحفاظ على استمرارية وصول العميل أثناء الترحيل. بعد اكتمال الترحيل، يمكنك إزالة عنوان IP الذي تم إنشاؤه مسبقا من قائمة السماح الخاصة بك.
• عند الترحيل وإنشاء عنوان VIP جديد، يتم تعيين عنوان IP الذي تم إنشاؤه مسبقا للنشر الجديد stv2 أثناء الترحيل ويستمر بعد اكتمال الترحيل. استخدم عنوان IP الذي تم إنشاؤه مسبقا لتحديث تبعيات الشبكة، مثل DNS وقواعد جدار الحماية، للإشارة إلى عنوان IP الجديد.

وقت التعطل المتوقع والاحتفاظ بالحوسبة

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

خطوات الترحيل - احتفظ بنفس الشبكة الفرعية

APIM_NAME={name of your API Management instance}
# In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
RG_NAME={name of your resource group}
# Get resource ID of API Management instance
APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
# Call REST API to migrate to stv2 and preserve VIP address
az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "PreserveIp"}'
# Alternate call to migrate to stv2 and change VIP address
# az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "NewIp"}'

الخيار 2: الترحيل والتغيير إلى شبكة فرعية جديدة

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

تعرض الصورة التالية نظرة عامة عالية المستوى لما يحدث أثناء الترحيل إلى شبكة فرعية جديدة.

المتطلبات الأساسية

• شبكة فرعية جديدة في الشبكة الظاهرية الحالية، في كل منطقة يتم فيها نشر مثيل APIM. (بدلا من ذلك، قم بإعداد شبكة فرعية في شبكة ظاهرية مختلفة في نفس المناطق والاشتراك مثل مثيل APIM الخاص بك). يجب إرفاق مجموعة أمان الشبكة بكل شبكة فرعية، ويجب تكوين قواعد NSG لإدارة واجهة برمجة التطبيقات على stv2 النظام الأساسي.

• (اختياري) مورد عنوان IPv4 عام قياسي جديد ل SKU في نفس المنطقة (المناطق) والاشتراك مثل مثيل APIM الخاص بك. للحصول على التفاصيل، راجع المتطلبات الأساسية لاتصالات الشبكة.

خطوات الترحيل - التغيير إلى شبكة فرعية جديدة

1. في مدخل Azure، انتقل إلى مثيل API Management الخاص بك.

2. في القائمة اليسرى، ضمن Settings، حدد Platform migration.

3. ضمن تحديد خيار ترحيل، حدد تغيير إلى شبكة فرعية جديدة.

4. ضمن اختيار السيناريو الذي يتوافق مع متطلباتك، اختر أحد الخيارين، اعتمادا على ما إذا كنت تريد الاحتفاظ بالحوسبة الأصلية stv1 لفترة بعد الترحيل.

   

5. ضمن تعريف إعدادات الترحيل لكل موقع:

   1. حدد موقعا للترحيل.
   2. حدد الشبكة الظاهرية والشبكة الفرعية وعنوان IP العام الاختياري الذي تريد الترحيل إليه.

   

6. ضمن التحقق من أن الشبكة الفرعية تفي بمتطلبات الترحيل، حدد التحقق لتشغيل عمليات التحقق التلقائية على الشبكة الفرعية. إذا تم الكشف عن مشاكل، فقم بضبط تكوين الشبكة الفرعية وتشغيل عمليات التحقق مرة أخرى. بالنسبة إلى تبعيات الشبكة الأخرى، مثل DNS وقواعد جدار الحماية، تحقق يدويا.

7. تأكد من رغبتك في الترحيل، وحدد ترحيل. تتغير حالة مثيل API Management إلى تحديث. تستغرق عملية الترحيل حوالي 45 دقيقة لإكمالها. عند تغيير الحالة إلى Online، يكتمل الترحيل.

إذا تم نشر مثيل APIM الخاص بك في مناطق متعددة، كرر الخطوات السابقة لمتابعة ترحيل إعدادات VNet للمواقع المتبقية من المثيل الخاص بك.

(اختياري) الترحيل مرة أخرى إلى الشبكة الفرعية الأصلية

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

تعرض الصورة التالية نظرة عامة عالية المستوى لما يحدث أثناء الترحيل مرة أخرى إلى الشبكة الفرعية الأصلية.

المتطلبات الإضافية

• الشبكة الفرعية الأصلية غير المؤمنة، في كل منطقة يتم فيها نشر مثيل APIM. يجب إرفاق مجموعة أمان الشبكة بالشبكة الفرعية، ويجب تكوين قواعد NSG لإدارة واجهة برمجة التطبيقات.

• (اختياري) مورد عنوان IPv4 عام قياسي جديد ل SKU في نفس المنطقة (المناطق) والاشتراك مثل مثيل APIM الخاص بك.

  هام

  • بدءا من مايو 2024، لم تعد هناك حاجة إلى مورد عنوان IP عام عند نشر (إدخال) مثيل APIM في VNet في الوضع الداخلي أو ترحيل تكوين VNet الداخلي إلى شبكة فرعية جديدة. في وضع VNet الخارجي، يكون تحديد عنوان IP عام اختياريا؛ إذا لم توفر عنوانا، يتم تكوين عنوان IP عام مدار من Azure تلقائيا واستخدامه لحركة مرور واجهة برمجة التطبيقات وقت التشغيل. قم بتوفير عنوان IP العام فقط إذا كنت تريد امتلاك عنوان IP العام المستخدم للاتصال الوارد أو الصادر إلى الإنترنت والتحكم فيه.

تحديث تكوين VNet

1. في المدخل، انتقل إلى الشبكة الظاهرية الأصلية.
2. في القائمة اليسرى، حدد الشبكات الفرعية، ثم الشبكة الفرعية الأصلية.
3. تحقق من إصدار عناوين IP الأصلية بواسطة APIM. ضمن عناوين IP المتوفرة، لاحظ عدد عناوين IP المتوفرة في الشبكة الفرعية. يجب أن تكون جميع العناوين (باستثناء عناوين Azure المحجوزة) متوفرة. إذا لزم الأمر، انتظر حتى يتم إصدار عناوين IP.
4. انتقل إلى مثيل APIM الخاص بك.
5. في القائمة اليسرى، ضمن Network، حدد Virtual network.
6. حدد اتصال الشبكة في الموقع الذي تريد تحديثه.
7. حدد شبكة VNet الأصلية والشبكة الفرعية. اختياريا حدد IP عاما جديدا. حدد تطبيق.
8. إذا تم نشر مثيل APIM الخاص بك في مناطق متعددة، فتابع تكوين إعدادات VNet للمواقع المتبقية من المثيل الخاص بك.
9. في شريط التنقل العلوي، حدد حفظ.

بعد تحديث تكوين VNet، تتغير حالة مثيل APIM إلى Updateing. تستغرق عملية الترحيل حوالي 45 دقيقة لإكمالها. عند تغيير الحالة إلى Online، يكتمل الترحيل.

التحقق من الترحيل

للتحقق من نجاح الترحيل، عندما تتغير الحالة إلى Online، تحقق من إصدار النظام الأساسي لمثيل API Management. بعد الترحيل الناجح، تكون القيمة هي stv2 أو stv2.1.

تأكيد الإعدادات قبل إزالة البوابة القديمة

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

• خلال هذه النافذة، تكون البوابات القديمة والجديدة متصلة بالإنترنت وتقدم نسبة استخدام الشبكة. لم تتم محاسبتك خلال هذا الوقت.
• استخدم هذه النافذة لتحديث أي تبعيات للشبكة بما في ذلك DNS وقواعد جدار الحماية والشبكات الظاهرية لاستخدام عنوان VIP الجديد ومساحة عنوان الشبكة الفرعية.
• بالإضافة إلى ذلك، تحقق من حالة شبكة المثيل المحدث لضمان اتصال المثيل بتبعياته. في المدخل، في القائمة اليمنى، ضمن النشر والبنية التحتية، حدّد حالة اتصال الشبكة>حالة الشبكة. إذا لزم الأمر، قم بتحديث الإعدادات مثل UDRs وقواعد NSG.
• بعد النافذة، يتم إيقاف تشغيل البوابة القديمة والبوابة الجديدة هي البوابة الوحيدة التي تخدم حركة المرور.

العودة تلقائيا إذا فشل الترحيل

إذا كان هناك فشل أثناء عملية الترحيل، فسيعود المثيل تلقائيا إلى النظام stv1 الأساسي. إذا اكتمل الترحيل بنجاح (يظهر إصدار النظام الأساسي للمثيل ك stv2 أو stv2.1 والحالة متصل)، فلا يمكنك العودة إلى stv1 النظام الأساسي.

للحصول على المساعدة في حالة فشل الترحيل، اتصل بدعم Azure.

إذا كنت بحاجة إلى القدرة على التراجع يدويا، فإن التوصية هي نشر مثيل جديد stv2 جنبا إلى جنب مع مثيل APIM الأصلي.

الشروط والسيناريوهات الخاصة

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

• VNet مع شروط داخلية خاصة - إذا تم نشر مثيل APIM الخاص بك حاليا في VNet بشروط داخلية خاصة (غير مرتبطة بتكوين العميل)، يتم إعلامك في المدخل بأن الخيار 1 لترحيل نفس الشبكة الفرعية في المدخل يتضمن وقت تعطل إضافي (ساعة واحدة تقريبا). يوصى باستخدام المدخل للترحيل. يمكنك أيضا استخدام البرنامج النصي Azure CLI المعدل التالي لترحيل نفس الشبكة الفرعية مع ما يقرب من ساعة واحدة من التوقف:

  APIM_NAME={name of your API Management instance}
  # In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
  RG_NAME={name of your resource group} 
  # Get resource ID of API Management instance
  APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
  # Call REST API to migrate to stv2 and preserve VIP address for special condition
  az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2024-06-01-preview&migrateWithDowntime=true" --body '{"mode": "PreserveIP"}' 
  

• مثيلات stv1 متعددة في الشبكة الفرعية - قد لا تتوفر عناوين IP مجانية كافية لترحيل نفس الشبكة الفرعية إذا حاولت ترحيل المثيلات في وقت واحد. قد تتمكن من ترحيل المثيلات بشكل تسلسلي باستخدام الخيار 1.

• تفويض الشبكة الفرعية - إذا تم تفويض الشبكة الفرعية حيث يتم نشر APIM حاليا إلى خدمات Azure الأخرى، يجب الترحيل باستخدام الخيار 2.

• تم حظر Azure Key Vault - إذا تم حظر الوصول إلى Azure Key Vault حاليا، فيجب عليك الترحيل باستخدام الخيار 2، بما في ذلك إعداد قواعد NSG في الشبكة الفرعية الجديدة للوصول إلى Azure Key Vault.

الترحيل الآلي

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

قد تتم إزالة تكوين الشبكة الظاهرية أثناء الترحيل التلقائي

المراسلة الفورية في معظم الحالات، يحتفظ الترحيل التلقائي بإعدادات الشبكة الظاهرية لمثيل APIM، إذا تم تكوينها. في ظل ظروف خاصة معينة، تتم إزالة تكوين الشبكة الظاهرية لمثيل الخدمة أثناء stv1 الترحيل التلقائي، وكإجراء أمان، يتم حظر الوصول إلى نقاط نهاية الخدمة. إذا تمت إزالة إعدادات الشبكة أثناء عملية الترحيل، فسترى رسالة في المدخل مشابهة ل: We have blocked access to all endpoints for your service.

أثناء حظر الوصول، يتم تعطيل الوصول إلى بوابة API ومدخل المطور وواجهة برمجة تطبيقات الإدارة المباشرة ومستودع Git. لاستعادة الوصول إلى نقاط نهاية الخدمة:

1. إعادة نشر مثيل API Management في شبكتك الظاهرية. للحصول على خطوات، راجع إرشادات نشر إدارة واجهة برمجة التطبيقات في شبكة ظاهرية خارجية أو داخلية. نوصي بشدة بنشر المثيل في شبكة فرعية جديدة للشبكة الظاهرية مع إعدادات متوافقة مع النظام الأساسي لحساب APIMstv2.
2. بعد إعادة تأسيس الشبكة الظاهرية، قم بإلغاء حظر الوصول إلى نقاط نهاية الخدمة. في المدخل، في صفحة نظرة عامة للمثيل، حدد إلغاء حظر خدمتي. هذا الإجراء غير قابل للعكس.

الدعم والتعليمات

نحن هنا لمساعدتك على الترحيل إلى النظام stv2 الأساسي بأقل قدر من التعطيل لخدماتك.

إذا كانت لديك أسئلة، فاحصل على إجابات سريعة من خبراء المجتمع في Microsoft Q&A. في حالة امتلاكك خطة دعم وتحتاج إلى مساعدة تقنية، أنشئ طلب الدعم.

1. اكتب وصفًا لمشكلتك في الملخص، على سبيل المثال، "إيقاف stv1".
2. ضمن Issue type، حدد Technical.
3. ضمن Subscription، حدد اشتراكك.
4. ضمن الخدمة، حدد خدماتي، ثم حدد خدمة API Management.
5. ضمن المورد، حدد "مورد Azure" الذي تُنشئ طلب دعم من أجله.
6. بالنسبة إلى نوع المشكلة، حدد الإدارة.
7. بالنسبة إلى النوع الفرعي للمشكلة، حدد ترقية أو تغيير حجم أو تغييرات SKU.

الأسئلة الشائعة

• ما هي المعلومات التي نحتاجها لاختيار مسار ترحيل؟

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

• ما هي المتطلبات الأساسية للترحيل؟

  بالنسبة إلى المثيلات المحقونة من VNet، راجع المتطلبات الأساسية لخيارات الترحيل والاحتفاظ بنفس الشبكة الفرعية أو الترحيل والتغيير إلى شبكة فرعية جديدة.

• هل سيؤدي الترحيل إلى وقت تعطل؟

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

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

• حركة المرور الخاصة بي إجبارية نفقية من خلال جدار حماية. ما التغييرات المطلوبة؟

  • أولا وقبل كل شيء، تأكد من أن الشبكة الفرعية (الشبكات) التي تستخدمها للترحيل تحتفظ بالتكوين التالي (يجب تكوينها بالفعل إذا كنت تقوم بالترحيل والاحتفاظ بالشبكة الفرعية الحالية):
    • تمكين نقاط نهاية الخدمة كما هو موضح هنا
    • يحتوي UDR (المسار المعرف من قبل المستخدم) على القفزة من علامة خدمة ApiManagement التي تم تعيينها إلى "الإنترنت" وليس فقط إلى عنوان جدار الحماية الخاص بك
  • تظل متطلبات تكوين NSG ل stv2 كما هي سواء كان لديك جدار حماية أم لا؛ تأكد من أن شبكتك الفرعية الجديدة تحتوي عليه
  • يجب تحديث قواعد جدار الحماية التي تشير إلى نطاق عناوين IP الحالي لمثيل APIM لاستخدام نطاق عناوين IP للشبكة الفرعية الجديدة.

• هل يمكن أن تحدث خسائر في البيانات أو التكوين بحلول/أثناء الترحيل؟

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

• كيفية تأكيد اكتمال الترحيل ونجاحه

  يعتبر الترحيل كاملا وناجحا عندما تقرأ الحالة في صفحة Overview Online مع إصدار النظام الأساسي إما stv2 أو stv2.1. تحقق أيضا من أن حالة الشبكة في شفرة الشبكة تظهر باللون الأخضر لجميع الاتصالات المطلوبة.

• هل يمكنني إجراء الترحيل باستخدام المدخل؟

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

• هل يمكنني الاحتفاظ بعنوان IP للمثيل؟

  نعم، تحتوي شفرة ترحيل النظام الأساسي في المدخل وواجهة برمجة تطبيقات REST على خيارات للحفاظ على عنوان IP.

• هل هناك مسار ترحيل دون تعديل المثيل الموجود؟

  نعم، تحتاج إلى ترحيل جنبا إلى جنب. وهذا يعني إنشاء مثيل APIM جديد بالتوازي مع المثيل الحالي ونسخ التكوين إلى المثيل الجديد.

• ماذا يحدث إذا فشل الترحيل؟

  إذا لم يظهر مثيل API Management إصدار النظام الأساسي ك stv2 أو stv2.1 وحالة على أنه متصل بعد بدء الترحيل، فمن المحتمل أن يكون قد فشل. يتم التراجع عن الخدمة تلقائيا إلى المثيل القديم ولا يتم إجراء أي تغييرات.

• ما هي الوظائف غير المتوفرة أثناء الترحيل؟

  تظل طلبات واجهة برمجة التطبيقات مستجيبة أثناء الترحيل. يتم تأمين تكوين البنية الأساسية (مثل المجالات المخصصة والمواقع وشهادات المرجع المصدق) لمدة 30 دقيقة.

• كم من الوقت سيستغرق الترحيل؟

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

• هل هناك طريقة للتحقق من صحة تكوين VNet قبل محاولة الترحيل؟

  إذا كنت تخطط لتغيير الشبكة الفرعية أثناء الترحيل، يمكنك نشر مثيل API Management جديد مع VNet والشبكة الفرعية ومورد عنوان IP (اختياري) الذي ستستخدمه للترحيل الفعلي. انتقل إلى صفحة حالة الشبكة بعد اكتمال النشر، وتحقق مما إذا كانت كل حالة اتصال نقطة نهاية خضراء. إذا كانت الإجابة بنعم، يمكنك إزالة مثيل APIM الجديد هذا والمضي قدما في الترحيل الحقيقي مع الخدمة الأصلية stv1المستضافة.

• هل يمكنني التراجع عن الترحيل إذا لزم الأمر؟

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

• هل هناك أي تغيير مطلوب في المجال المخصص/ مناطق DNS الخاصة؟

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

• يتم نشر مثيل stv1 الخاص بي إلى مناطق Azure متعددة (متعددة المناطق). كيف أعمل الترقية إلى stv2؟

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

• هل يمكنني ترقية مثيل stv1 الخاص بي إلى نفس الشبكة الفرعية؟

  نعم، استخدم جزء ترحيل النظام الأساسي في المدخل، أو استخدم واجهة برمجة تطبيقات ترحيل إلى stv2 REST.

• هل يمكنني اختبار البوابة الجديدة في شبكة فرعية جديدة قبل تبديل حركة المرور المباشرة؟

  • عند الترحيل إلى شبكة فرعية جديدة، بشكل افتراضي، تتعايش البوابات المدارة القديمة والجديدة لمدة 15 دقيقة، وهي نافذة صغيرة من الوقت للتحقق من صحة النشر. يمكنك تمكين إعداد ترحيل للاحتفاظ بالبوابة القديمة لمدة 48 ساعة. يحافظ هذا التغيير على البوابات المدارة القديمة والجديدة نشطة لتلقي حركة المرور وتسهيل التحقق من الصحة.
  • تقوم عملية الترحيل تلقائيا بتحديث أسماء المجالات الافتراضية، وفي حالة استخدامها، توجه نسبة استخدام الشبكة إلى البوابات الجديدة على الفور.
  • إذا كانت أسماء المجالات المخصصة قيد الاستخدام، فقد تحتاج سجلات DNS المقابلة إلى تحديث بعنوان IP الجديد إذا لم تكن تستخدم CNAME. يمكن للعملاء تحديث ملف المضيفين الخاص بهم إلى عنوان IP الجديد لإدارة واجهة برمجة التطبيقات والتحقق من صحة المثيل قبل إجراء التبديل. أثناء عملية التحقق من الصحة هذه، تستمر البوابة القديمة في خدمة حركة المرور المباشرة.

• هل هناك أي اعتبارات عند استخدام اسم المجال الافتراضي في شبكة فرعية جديدة؟

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

• ما الذي يجب أن نأخذه بعين الاعتبار للبوابات المستضافة ذاتيا؟

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

• كيف يتأثر مدخل المطور بالترحيل؟

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

• هل هناك أي تأثير على التكلفة بمجرد ترحيلنا إلى stv2؟

  يظل نموذج الفوترة كما هو بالنسبة stv2 ولن تكون هناك أي تكلفة إضافية يتم تكبدها أثناء الترحيل وبعده.

• ما هي أذونات التحكم في الوصول استنادا إلى الدور المطلوبة لترحيل stv1 إلى stv2؟

  سيحتاج المستخدم/العملية التي تقوم بالترحيل إلى الوصول للكتابة إلى مثيل APIM. بالإضافة إلى ذلك، مطلوب الإذنان التاليان:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/publicIPAddresses/join/action

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

• كيف أعمل تعرف النظام الأساسي الذي يستضيف مثيل APIM الخاص بي؟

• فوائد النظام الأساسي لحساب stv2 لإدارة واجهة برمجة التطبيقات

• توقف النظام الأساسي stv1 - Azure العالمي (أغسطس 2024)

• إيقاف النظام الأساسي stv1 - Azure Government وAzure المشغلة بواسطة 21Vianet (فبراير 2025)