استكشاف أخطاء ترقيات التطبيقات وإصلاحها
تتناول هذه المقالة بعض المشكلات الشائعة حول ترقية تطبيق نسيج خدمة Azure وكيفية حلها.
استكشاف أخطاء ترقية تطبيق فاشلة وإصلاحها
عند فشل الترقية، يحتوي إخراج أمر Get - ServiceFabricApplicationUpgrade على معلومات إضافية لتصحيح الفشل. تحدد القائمة التالية كيفية استخدام المعلومات الإضافية:
- حدد نوع الفشل.
- حدد سبب الفشل.
- عزل واحد أو أكثر من المكونات الفاشلة لمزيد من التحقيق.
تتوفر هذه المعلومات عندما يكتشف نسيج الخدمة الفشل بغض النظر عما إذا كان إجراء الفشل هو التراجع أو تعليق الترقية.
حدد نوع الفشل
في إخراج Get - ServiceFabricApplicationUpgrade، يحدد FailureTimestampUtc الطابع الزمني (في UTC) الذي تم فيه اكتشاف فشل في الترقية بواسطة نسيج الخدمة و تم تشغيل FailureAction. يحدد سبب الفشل أحد الأسباب الثلاثة المحتملة عالية المستوى للفشل:
- UpgradeDomainTimeout - يشير إلى أن نطاق ترقية معين قد استغرق وقتًا طويلاً لإكماله وأن UpgradeDomainTimeout قد انتهت صلاحيته.
- عموماً UpgradeTimeout - يشير إلى أن الترقية الإجمالية استغرقت وقتاً طويلاً لإكمالها وانتهت صلاحية UpgradeTimeout.
- HealthCheck - يشير إلى أنه بعد ترقية نطاق التحديث، ظل التطبيق غير صحي وفقًا للسياسات الصحية المحددة وانتهت صلاحية HealthCheckRetryTimeout .
تظهر هذه الإدخالات فقط في الإخراج عندما تفشل الترقية وتبدأ في التراجع. يُعرَض المزيد من المعلومات اعتمادًا على نوع الفشل.
التحقيق في مهلات الترقية
إن فشل مهلة الترقية هو الأكثر شيوعًا بسبب مشكلات توفر الخدمة. يعد الإخراج التالي لهذه الفقرة نموذجيًا للترقيات حيث تفشل نُسخ الخدمة المتماثلة أو المثيلات في البدء في إصدار التعليمات البرمجية الجديد. يلتقط حقل UpgradeDomainProgressAtFailure لقطة لأي عمل ترقية مُعَلَق في وقت الفشل.
Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName : fabric:/DemoApp
ApplicationTypeName : DemoAppType
TargetApplicationTypeVersion : v2
ApplicationParameters : {}
StartTimestampUtc : 4/14/2015 9:26:38 PM
FailureTimestampUtc : 4/14/2015 9:27:05 PM
FailureReason : UpgradeDomainTimeout
UpgradeDomainProgressAtFailure : MYUD1
NodeName : Node4
UpgradePhase : PostUpgradeSafetyCheck
PendingSafetyChecks :
WaitForPrimaryPlacement - PartitionId: 744c8d9f-1d26-417e-a60e-cd48f5c098f0
NodeName : Node1
UpgradePhase : PostUpgradeSafetyCheck
PendingSafetyChecks :
WaitForPrimaryPlacement - PartitionId: 4b43f4d8-b26b-424e-9307-7a7a62e79750
UpgradeState : RollingBackCompleted
UpgradeDuration : 00:00:46
CurrentUpgradeDomainDuration : 00:00:00
NextUpgradeDomain :
UpgradeDomainsStatus : { "MYUD1" = "Completed";
"MYUD2" = "Completed";
"MYUD3" = "Completed" }
UpgradeKind : Rolling
RollingUpgradeMode : UnmonitoredAuto
ForceRestart : False
UpgradeReplicaSetCheckTimeout : 00:00:00
في هذا المثال، فشلت الترقية في مجال الترقية MYUD1 وتم تعليق قسمين (744c8d9f-1d26-417e-a60e-cd48f5c098f0 و 4b43f4d8-b26b-424e-9307-7a7a62e79750). كانت الأقسام مُعَلقة لأن وقت التشغيل لم يتمكن من وضع النسخ المتماثلة الأساسية (WaitForPrimaryPlacement) على العقد المستهدفة العقدة 1 و العقدة 4.
يمكن استخدام أمر Get - ServiceFabricNode للتحقق من أن هاتين العقدتين في نطاق الترقية MYUD1 . تُظهر UpgradePhase PostUpgradeSafetyCheck، مما يعني أن فحوصات السلامة هذه تحدث بعد الانتهاء من ترقية جميع العقد في نطاق الترقية. تشير كل هذه المعلومات إلى وجود مشكلة محتملة في الإصدار الجديد من التعليمات البرمجية للتطبيق. المشكلات الأكثر شيوعًا هي أخطاء الخدمة في الفتح أو الترويج لمسارات التعليمات البرمجية الأساسية.
تعني مرحلة الترقية من PreUpgradeSafetyCheck أنه كانت هناك مشكلات في إعداد نطاق الترقية قبل تنفيذه. المشكلات الأكثر شيوعًا في هذه الحالة هي أخطاء الخدمة في الإغلاق أو خفض الرتبة من مسارات التعليمات البرمجية الأساسية.
حالة الترقية الحالية هي RollingBackCompleted ، لذلك يجب أن تكون الترقية الأصلية قد أُجريت مع إجراء الفشل ، والتي تقوم تلقائيًا بإعادة الترقية عند الفشل. إذا تم إجراء الترقية الأصلية باستخدام دليل إجراء الفشل، فستكون الترقية بدلاً من ذلك في حالة تعليق للسماح بالتصحيح المباشر للتطبيق.
في حالات نادرة، قد يكون حقل UpgradeDomainProgressAtFailure فارغًا إذا انتهت مهلة الترقية الإجمالية تمامًا كما يكمل النظام جميع الأعمال لنطاق الترقية الحالي. إذا حدث ذلك، فحاول زيادة قيم ضابط UpgradeTimeout و UpgradeDomainTimeout وأعد محاولة الترقية.
التحقيق في حالات فشل الفحص الصحي
يمكن تشغيل حالات فشل التحقق من الصحة بسبب العديد من المشكلات التي يمكن أن تحدث بعد انتهاء جميع العقد في مجال الترقية واجتياز جميع فحوصات السلامة. يعد الإخراج التالي لهذه الفقرة نموذجيًا لفشل الترقية بسبب الفحوصات الصحية الفاشلة. يلتقط حقل التقييمات غير الصحية لقطة من الفحوصات الصحية التي فشلت في وقت الترقية وفقًا للسياسة الصحية المحددة.
Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName : fabric:/DemoApp
ApplicationTypeName : DemoAppType
TargetApplicationTypeVersion : v4
ApplicationParameters : {}
StartTimestampUtc : 4/24/2015 2:42:31 AM
UpgradeState : RollingForwardPending
UpgradeDuration : 00:00:27
CurrentUpgradeDomainDuration : 00:00:27
NextUpgradeDomain : MYUD2
UpgradeDomainsStatus : { "MYUD1" = "Completed";
"MYUD2" = "Pending";
"MYUD3" = "Pending" }
UnhealthyEvaluations :
Unhealthy services: 50% (2/4), ServiceType='PersistedServiceType', MaxPercentUnhealthyServices=0%.
Unhealthy service: ServiceName='fabric:/DemoApp/Svc3', AggregatedHealthState='Error'.
Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.
Unhealthy partition: PartitionId='3a9911f6-a2e5-452d-89a8-09271e7e49a8', AggregatedHealthState='Error'.
Error event: SourceId='Replica', Property='InjectedFault'.
Unhealthy service: ServiceName='fabric:/DemoApp/Svc2', AggregatedHealthState='Error'.
Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.
Unhealthy partition: PartitionId='744c8d9f-1d26-417e-a60e-cd48f5c098f0', AggregatedHealthState='Error'.
Error event: SourceId='Replica', Property='InjectedFault'.
UpgradeKind : Rolling
RollingUpgradeMode : Monitored
FailureAction : Manual
ForceRestart : False
UpgradeReplicaSetCheckTimeout : 49710.06:28:15
HealthCheckWaitDuration : 00:00:00
HealthCheckStableDuration : 00:00:10
HealthCheckRetryTimeout : 00:00:10
UpgradeDomainTimeout : 10675199.02:48:05.4775807
UpgradeTimeout : 10675199.02:48:05.4775807
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
يتطلب التحقيق في حالات فشل الفحص الصحي أولاً فهما لنموذج صحة نسيج الخدمة. ولكن حتى بدون هذا الفهم المتعمق، يمكننا أن نرى أن خدمتين غير صحيتين: fabric:/DemoApp/Svc3 و fabric:/DemoApp/Svc2، إلى جانب تقارير صحة الخطأ ("InjectedFault" في هذه الحالة). في هذا المثال ، هناك خدمتان من أصل أربع خدمات غير صحية، وهو أقل من الهدف الافتراضي المتمثل في 0 ٪ غير صحية ( MaxPercentUnhealthyServices ).
تم تعليق الترقية عند الفشل عن طريق تحديد إجراء الفشل من الدليل عند بدء الترقية. يسمح لنا هذا الوضع بالتحقيق في النظام المباشر في الحالة الفاشلة قبل اتخاذ أي إجراء آخر.
الاسترداد من ترقية مُعَلَقة
مع تراجع إجراء الفشل، لا توجد حاجة إلى الاسترداد نظرًا لأن الترقية تتراجع تلقائيًا عند الفشل. باستخدام إجراء الفشل اليدوي، هناك العديد من خيارات الاسترداد:
- تشغيل التراجع
- المتابعة من خلال ما تبقى من الترقية يدويًا
- استئناف الترقية المُرَاقَبَة
يمكن استخدام الأمر Start-ServiceFabricApplicationRollback في أي وقت لبدء التراجع عن التطبيق. بمجرد عودة الأمر بنجاح، سُجِل طلب التراجع في النظام ويبدأ بعد ذلك بوقت قصير.
يمكن استخدام الأمر استئناف - ServiceFabricApplicationUpgrade للمتابعة خلال الفترة المتبقية من الترقية يدويًا، أي نطاق ترقية واحد في كل مرة. في هذا الوضع،تُجرى فحوصات السلامة فقط من قِبل النظام. لا مزيد من الفحوصات الصحية. لا يمكن استخدام هذا الأمر إلا عندما يعرض ترقية الحالة RollingForwardPending، مما يعني أن نطاق الترقية الحالي قد انتهى من الترقية ولكن لم تبدأ الترقية التالية (معلقة).
يمكن استخدام أمر Update - ServiceFabricApplicationUpgrade لاستئناف الترقية المراقبة مع إجراء فحوصات السلامة والصحة.
Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode : Monitored
ForceRestart :
UpgradeReplicaSetCheckTimeout :
FailureAction :
HealthCheckWaitDuration :
HealthCheckStableDuration :
HealthCheckRetryTimeout :
UpgradeTimeout :
UpgradeDomainTimeout :
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
تستمر الترقية من نطاق الترقية حيث عُلِقت آخر مرة وتستخدم نفس ضوابط الترقية والسياسات الصحية كما في السابق. إذا لزم الأمر، يمكن تغيير أي من ضوابط الترقية والسياسات الصحية الموضحة في الإخراج السابق في نفس الأمر عند استئناف الترقية. في هذا المثال، تم استئناف الترقية في وضع المراقبة، مع عدم تغيير الضوابط والسياسات الصحية.
مزيد من استكشاف الأخطاء وإصلاحها
نسيج الخدمة لا يتبع السياسات الصحية المحددة
السبب المحتمل 1:
يترجم نسيج الخدمة جميع النسب المئوية إلى أعداد فعلية من الكيانات (على سبيل المثال، النسخ المتماثلة، الأقسام، والخدمات) للتقييم الصحي ويقرب دائمًا إلى كيانات كاملة. على سبيل المثال، إذا كان الحد الأقصى MaxPercentUnhealthyReplicasPerPartition هو 21% وكان هناك خمس نسخ متماثلة، فإن نسيج الخدمة يسمح بما يصل إلى نسختين متماثلتين غير صحيتين (أي Math.Ceiling (5*0.21)). وبالتالي، ينبغي وضع السياسات الصحية وفقا لذلك.
السبب المحتمل 2:
يتم تحديد السياسات الصحية من حيث النسب المئوية لمجموع الخدمات وليس من حيث حالات الخدمة المحددة. على سبيل المثال، قبل الترقية، إذا كان التطبيق يحتوي على أربعة أمثلة خدمة A و B و C و D، حيث تكون الخدمة D غير صحية ولكن مع تأثير ضئيل على التطبيق. نريد تجاهل الخدمة غير الصحية المعروفة D أثناء الترقية وتعيين الضابط MaxPercentUnhealthyServices لتكون 25%، بافتراض أن A وB وC فقط هي التي يجب أن تكون صحية.
ومع ذلك، أثناء الترقية، قد يصبح D صحياً بينما يصبح C غير صحي. ستظل الترقية ناجحة لأن 25٪ فقط من الخدمات غير صحية. ومع ذلك، قد يؤدي ذلك إلى أخطاء غير متوقعة بسبب أن C غير صحية بشكل غير متوقع بدلاً من D. في هذه الحالة، يجب نمذجة D كنوع خدمة مختلف عن A و B و C. نظرًا لأن السياسات الصحية محددة لكل نوع خدمة، يمكن تطبيق عتبات نسب مئوية غير صحية مختلفة على الخدمات المختلفة.
لم أحدد سياسة صحية لترقية التطبيق، لكن الترقية لا تزال تفشل لبعض المهل التي لم أحددها أبدًا
عندما لا تتوفر السياسات الصحية لطلب الترقية،تأُخذ من ApplicationManifest.xml إصدار التطبيق الحالي. على سبيل المثال، إذا كنت تقوم بترقية التطبيق X من الإصدار 1.0 إلى الإصدار 2.0،تُستخدم سياسات صحة التطبيق المحددة في الإصدار 1.0. إذا كان يجب استخدام سياسة صحية مختلفة للترقية، فيجب تحديد السياسة كجزء من مكالمة واجهة برمجة التطبيقات لترقية التطبيق. لا تنطبق السياسات المحددة كجزء من مكالمة API إلا أثناء الترقية. بمجرد اكتمال الترقية، تُستخدم السياسات المحددة في ApplicationManifest.xml.
يتم تحديد مهلات غير صحيحة
ربما تكون قد تساءلت عما يحدث عندما يتم تعيين المهلة بشكل غير متسق. على سبيل المثال، قد يكون لديك مهلة الترقية أقل من مهلة نطاق الترقية . الجواب هو أنه يتم إرجاع خطأ. يتم إرجاع الأخطاء إذا كانت مهلة نطاق الترقية أقل من مجموع المهلة الزمنية للفحص الصحي و المهلة الزمنية للفحص الصحي ، أو إذا كانت المهلة الزمنية للترقية أقل من مجموع المهلة الزمنية للفحص الصحي و المهلة الزمنية للفحص الصحي .
تستغرق ترقياتي وقتًا طويلاً جداً
يعتمد وقت إكمال الترقية على الفحوصات الصحية والفترات الزمنية المحددة. تعتمد الفحوصات الصحية والإجازات على المدة التي يستغرقها نسخ التطبيق ونشره وتثبيته. قد يعني الإفراط في العدوانية مع المهل الزمنية مزيدًا من الترقيات الفاشلة، لذلك نوصي بالبدء بتحفظ مع فترات زمنية أطول.
فيما يلي تحديث سريع حول كيفية تفاعل المُهَل مع أوقات الترقية:
لا يمكن أن تكتمل ترقيات نطاق الترقية بشكل أسرع من HealthCheckWaitDuration + HealthCheckStableDuration.
لا يمكن أن يحدث فشل الترقية بشكل أسرع من HealthCheckWaitDuration + HealthCheckRetryTimeout .
يتم تحديد وقت الترقية لنطاق الترقية بواسطة مهلة نطاق الترقية. إذا كان HealthCheckRetryTimeout و HealthCheckStableDuration غير صفريين واستمرت صحة التطبيق في التبديل ذهابًا وإيابًا، فإن الترقية في النهاية تنتهي في مهلة نطاق الترقية . تبدأ مهلة نطاق الترقية العد التنازلي بمجرد بدء الترقية لمجال الترقية الحالي.
الخطوات التالية
يرشدك Upgrading your Application Using Visual Studio خلال ترقية التطبيق باستخدام Visual Studio.
يرشدك Upgrading your Application Using PowerShell خلال ترقية التطبيق باستخدام PowerShell.
تحكّم في كيفية ترقية التطبيق الخاص بك باستخدام معلمات الترقية.
اجعل ترقيات تطبيقك متوافقة من خلال تعلم كيفية استخدام Data Serialization.
تعرف على كيفية استخدام الوظائف المتقدمة أثناء ترقية التطبيق من خلال الرجوع إلى الموضوعات المتقدمة.