الموثوقية في Azure Container Apps

توضح هذه المقالة دعم الموثوقية في Azure Container Apps، وتغطي كلا من المرونة الإقليمية مع مناطق التوفر والمرونة عبر المناطق مع التعافي من الكوارث. للحصول على نظرة عامة أكثر تفصيلا على الموثوقية في Azure، راجع موثوقية Azure.

دعم منطقة القابلية للوصول

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

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

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

تستخدم Azure Container Apps مناطق التوفر في المناطق التي تتوفر فيها لتوفير حماية عالية التوفر لتطبيقاتك وبياناتك من حالات فشل مركز البيانات.

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

إشعار

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

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

تقدم Azure Container Apps نفس دعم الموثوقية بغض النظر عن نوع خطتك.

تستخدم Azure Container Apps مناطق التوفر في المناطق التي تتوفر فيها. للحصول على قائمة بالمناطق التي تدعم مناطق التوفر، راجع خدمة منطقة التوفر والدعم الإقليمي.

تحسينات اتفاقية مستوى الخدمة

لا توجد اتفاقيات مستوى خدمة متزايدة لتطبيقات حاويات Azure. لمزيد من المعلومات حول اتفاقيات مستوى الخدمة لتطبيقات حاوية Azure، راجع اتفاقية مستوى الخدمة لتطبيقات حاوية Azure.

إنشاء مورد مع تمكين منطقة التوفر

إعداد تكرار المنطقة في بيئة تطبيقات الحاوية

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

تمكين تكرار المنطقة عبر مدخل Microsoft Azure

لإنشاء تطبيق حاوية في بيئة مع تمكين تكرار المنطقة باستخدام مدخل Microsoft Azure:

1. انتقل إلى مدخل Azure.
2. ابحث عن Container Apps في مربع البحث العلوي.
3. حدد Container Apps.
4. حدد Create New في حقل Container Apps Environment لفتح لوحة Create Container Apps Environment .
5. أدخل اسم البيئة.
6. حدد Enabled لحقل Zone redundancy .

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

1. حدد علامة التبويب Networking
2. لتعيين اسم شبكة ظاهرية مخصصة، حدد إنشاء جديد في حقل الشبكة الظاهرية.
3. لتعيين اسم شبكة فرعية مخصصة للبنية الأساسية، حدد إنشاء جديد في حقل الشبكة الفرعية للبنية الأساسية.
4. يمكنك تحديد Internal أو External ل Virtual IP.
5. حدد إنشاء.

تمكين تكرار المنطقة باستخدام Azure CLI

إنشاء شبكة ظاهرية وشبكة فرعية للبنية الأساسية لتضمينها مع بيئة Container Apps.

عند استخدام هذه الأوامر، استبدل <PLACEHOLDERS> بالقيم الخاصة بك.

إشعار

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

Azure CLI

az network vnet create \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <VNET_NAME> \
  --location <LOCATION> \
  --address-prefix 10.0.0.0/16

az network vnet subnet create \
  --resource-group <RESOURCE_GROUP_NAME> \
  --vnet-name <VNET_NAME> \
  --name infrastructure \
  --address-prefixes 10.0.0.0/21

Azure PowerShell

$SubnetArgs = @{
    Name = 'infrastructure-subnet'
    AddressPrefix = '10.0.0.0/21'
}
$subnet = New-AzVirtualNetworkSubnetConfig @SubnetArgs

$VnetArgs = @{
    Name = <VNetName>
    Location = <Location>
    ResourceGroupName = <ResourceGroupName>
    AddressPrefix = '10.0.0.0/16'
    Subnet = $subnet 
}
$vnet = New-AzVirtualNetwork @VnetArgs

بعد ذلك، استعلم عن معرف الشبكة الفرعية للبنية الأساسية.

Azure CLI

INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`

Azure PowerShell

$InfrastructureSubnet=(Get-AzVirtualNetworkSubnetConfig -Name $SubnetArgs.Name -VirtualNetwork $vnet).Id

وأخيرا، قم بإنشاء البيئة باستخدام المعلمة --zone-redundant . يجب أن يكون الموقع هو نفس الموقع المستخدم عند إنشاء الشبكة الظاهرية.

Azure CLI

az containerapp env create \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --location "<LOCATION>" \
  --infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
  --zone-redundant

Azure PowerShell

مساحة عمل Log Analytics مطلوبة لبيئة Container Apps. تنشئ الأوامر التالية مساحة عمل Log Analytics وتحفظ معرف مساحة العمل والمفتاح المشترك الأساسي إلى متغيرات البيئة.

$WorkspaceArgs = @{
    Name = 'myworkspace'
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    PublicNetworkAccessForIngestion = 'Enabled'
    PublicNetworkAccessForQuery = 'Enabled'
}
New-AzOperationalInsightsWorkspace @WorkspaceArgs
$WorkspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).CustomerId
$WorkspaceSharedKey = (Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).PrimarySharedKey

لإنشاء البيئة، قم بتشغيل الأمر التالي:

$EnvArgs = @{
    EnvName = <EnvironmentName>
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    AppLogConfigurationDestination = "log-analytics"
    LogAnalyticConfigurationCustomerId = $WorkspaceId
    LogAnalyticConfigurationSharedKey = $WorkspaceSharedKey
    VnetConfigurationInfrastructureSubnetId = $InfrastructureSubnet
    VnetConfigurationInternal = $true
}
New-AzContainerAppManagedEnv @EnvArgs

تحقق من تكرار المنطقة باستخدام Azure CLI

إشعار

لا يظهر مدخل Microsoft Azure ما إذا كان قد تم تمكين تكرار المنطقة.

az container app env show استخدم الأمر للتحقق من تمكين تكرار المنطقة لبيئة تطبيقات الحاوية.

Azure CLI

az containerapp env show \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --subscription <SUBSCRIPTION_ID>

Azure PowerShell

az containerapp env show `
  --name <CONTAINER_APP_ENV_NAME> `
  --resource-group <RESOURCE_GROUP_NAME> `
  --subscription <SUBSCRIPTION_ID>

يقوم الأمر بإرجاع استجابة JSON. تحقق من أن الاستجابة تحتوي على "zoneRedundant": true.

تقنيات التوزيع خزينة

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

يجب عليك الاستمرار في استخدام تقنيات التوزيع الآمنة مثل النشر الأزرق والأخضر. لا توفر Azure Container Apps توزيعا أو ترقيات لمنطقة واحدة في كل مرة.

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

ترحيل منطقة التوفر

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

التعافي من الكوارث عبر المناطق واستمرارية الأعمال

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

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

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

• الاسترداد اليدوي: النشر يدويا إلى منطقة جديدة، أو انتظار استرداد المنطقة، ثم إعادة نشر جميع البيئات والتطبيقات يدويا.

• الاسترداد المرن: أولا، انشر تطبيقات الحاوية مسبقا إلى مناطق متعددة. بعد ذلك، استخدم Azure Front Door أو Azure Traffic Manager لمعالجة الطلبات الواردة، مع الإشارة إلى حركة المرور إلى منطقتك الأساسية. بعد ذلك، في حالة حدوث انقطاع، يمكنك إعادة توجيه نسبة استخدام الشبكة بعيدا عن المنطقة المتأثرة. لمزيد من المعلومات، راجع النسخ المتماثل عبر المناطق في Azure.

إشعار

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

المزيد من الإرشادات

يمكن أن تساعدك الموارد التالية في إنشاء خطة التعافي من الكوارث الخاصة بك:

• الفشل والإصلاح بعد كارثة لتطبيقات Azure
• إرشادات تقنية لمرونة Azure

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

الموثوقية في Azure