فحص صحة العقدة والجراب

هذا المقال جزء من سلسلة. ابدأ بنظرة عامة.

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

الخطوة 1: التحقق من صحة العقد العاملة

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

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

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

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

بعد معالجة هذه المشكلات المحتملة المتعلقة بالاتصال بلوحة التحكم ودقة DNS، يمكنك معالجة مشكلات صحة العقدة وحلها بشكل فعال داخل نظام مجموعة AKS.

يمكنك تقييم صحة العقد باستخدام إحدى الطرق التالية.

عرض سلامة حاويات Azure Monitor

لعرض صحة العقد وقرون المستخدم ووحدات النظام في نظام مجموعة AKS، اتبع الخطوات التالية:

1. في مدخل Microsoft Azure، انتقل إلى Azure Monitor.
2. في قسم Insights في جزء التنقل، حدد Containers.
3. حدد أنظمة المجموعات المراقبة للحصول على قائمة بمجموعات AKS التي تتم مراقبتها.
4. اختر نظام مجموعة AKS من القائمة لعرض صحة العقد وقرون المستخدم ووحدات النظام.

طريقة عرض عقد AKS

للتأكد من أن جميع العقد في نظام مجموعة AKS في حالة الاستعداد، اتبع الخطوات التالية:

1. في مدخل Microsoft Azure، انتقل إلى نظام مجموعة AKS.
2. في قسم الإعدادات من جزء التنقل، حدد تجمعات العقدة.
3. حدد العقد.
4. تحقق من أن جميع العقد في حالة الاستعداد.

المراقبة داخل نظام المجموعة باستخدام Prometheus وGrafana

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

في لوحة المعلومات، حدد Node conditions لمشاهدة مقاييس حول صحة وأداء نظام المجموعة. يمكنك تعقب العقد التي قد تواجه مشكلات، مثل المشكلات المتعلقة بجدولها الزمني أو الشبكة أو ضغط القرص أو ضغط الذاكرة أو ضغط المشتقات المتكاملة النسبية (PID) أو مساحة القرص. راقب هذه المقاييس، حتى تتمكن من تحديد ومعالجة أي مشكلات محتملة تؤثر على توفر نظام مجموعة AKS وأدائه بشكل استباقي.

مراقبة الخدمة المدارة ل Prometheus وAzure Managed Grafana

يمكنك استخدام لوحات المعلومات التي تم إنشاؤها مسبقا لتصور وتحليل مقاييس Prometheus. للقيام بذلك، يجب عليك إعداد نظام مجموعة AKS لتجميع مقاييس Prometheus في مراقبة الخدمة المدارة ل Prometheus، وتوصيل مساحة عمل Monitor بمساحة عمل Azure Managed Grafana . توفر لوحات المعلومات هذه عرضا شاملا لأداء مجموعة Kubernetes وصحتها.

يتم توفير لوحات المعلومات في مثيل Azure Managed Grafana المحدد في المجلد Managed Prometheus . تتضمن بعض لوحات المعلومات ما يلي:

• Kubernetes / موارد الحساب / نظام المجموعة
• Kubernetes / موارد الحساب / مساحة الاسم (Pods)
• Kubernetes / حساب الموارد / العقدة (Pods)
• Kubernetes / موارد الحوسبة / الجراب
• Kubernetes / موارد الحساب / مساحة الاسم (أحمال العمل)
• Kubernetes / موارد الحساب / حمل العمل
• Kubernetes / Kubelet
• مصدر العقدة / أسلوب الاستخدام / العقدة
• مصدر العقدة / العقد
• Kubernetes / حساب الموارد / نظام المجموعة (Windows)
• Kubernetes / حساب الموارد / مساحة الاسم (Windows)
• Kubernetes / حساب الموارد / جراب (Windows)
• Kubernetes / USE Method / Cluster (Windows)
• Kubernetes / USE Method / Node (Windows)

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

يمكنك استخدام لوحة معلومات Kubernetes / Compute Resources / Node (Pods) لمشاهدة مقاييس عقد عامل Linux. يمكنك تصور استخدام وحدة المعالجة المركزية والحصة النسبية لوحدة المعالجة المركزية واستخدام الذاكرة والحصة النسبية للذاكرة لكل جراب.

إذا كانت مجموعتك تتضمن عقد وكيل Windows، يمكنك استخدام لوحة معلومات Kubernetes / USE Method / Node (Windows) لتصور مقاييس Prometheus التي يتم جمعها من هذه العقد. توفر لوحة المعلومات هذه طريقة عرض شاملة لاستهلاك الموارد والأداء لعقد Windows داخل مجموعتك.

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

الخطوة 2: التحقق من مستوى التحكم واتصال العقدة العاملة

إذا كانت العقد العاملة سليمة، يجب فحص الاتصال بين وحدة التحكم AKS المدارة وعقد عامل نظام المجموعة. تتيح AKS الاتصال بين خادم Kubernetes API وkubelets الفردية للعقدة عبر أسلوب اتصال نفق آمن. يمكن لهذه المكونات الاتصال حتى لو كانت على شبكات ظاهرية مختلفة. النفق محمي بتشفير أمان طبقة النقل المتبادل (mTLS). يسمى النفق الأساسي الذي تستخدمه AKS Konnectivity (المعروف سابقا باسم apiserver-network-proxy). تأكد من أن جميع قواعد الشبكة وFQDNs تتوافق مع قواعد شبكة Azure المطلوبة.

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

للتأكد من أن جرابات عامل Konnectivity تعمل بشكل صحيح، قم بتشغيل الأمر التالي:

kubectl get deploy konnectivity-agent -n kube-system

تأكد من أن pods في حالة استعداد.

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

قم بتشغيل الأمر التالي لإعادة تشغيل konnectivity-agent pods:

kubectl rollout restart deploy konnectivity-agent -n kube-system

إذا لم تؤدي إعادة تشغيل pods إلى إصلاح الاتصال، فتحقق من السجلات بحثا عن أي حالات شاذة. قم بتشغيل الأمر التالي لعرض سجلات konnectivity-agent pods:

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

يجب أن تظهر السجلات الإخراج التالي:

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

إشعار

عند إعداد مجموعة AKS مع تكامل شبكة ظاهرية لخادم API وإما واجهة شبكة حاوية Azure (CNI) أو Azure CNI مع تعيين IP pod ديناميكي، ليست هناك حاجة لنشر عوامل Konnectivity. يمكن لخوادم API المتكاملة إنشاء اتصال مباشر مع عقد عامل نظام المجموعة عبر الشبكات الخاصة.

ومع ذلك، عند استخدام تكامل الشبكة الظاهرية لخادم API مع تراكب Azure CNI أو إحضار CNI (BYOCNI)، يتم نشر Konnectivity لتسهيل الاتصال بين خوادم واجهة برمجة التطبيقات وعناوين IP الخاصة بالجراب. يظل الاتصال بين خوادم واجهة برمجة التطبيقات والعقد العاملة مباشرا.

يمكنك أيضا البحث في سجلات الحاوية في خدمة التسجيل والمراقبة لاسترداد السجلات. للحصول على مثال يبحث عن أخطاء اتصال aks-link ، راجع سجلات الاستعلام من نتائج تحليلات الحاوية.

قم بتشغيل الاستعلام التالي لاسترداد السجلات:

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

قم بتشغيل الاستعلام التالي للبحث في سجلات الحاوية عن أي جراب فاشل في مساحة اسم معينة:

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

إذا لم تتمكن من الحصول على السجلات باستخدام الاستعلامات أو أداة kubectl، فاستخدم مصادقة Secure Shell (SSH). يبحث هذا المثال عن جراب الواجهة النفقية بعد الاتصال بالعقدة عبر SSH.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

الخطوة 3: التحقق من صحة دقة DNS عند تقييد الخروج

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

1. قم بتشغيل الأمر kubectl exec لفتح أمر shell في الحاوية التي تعمل في pod.

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. تحقق مما إذا كانت أدوات nslookup أو dig مثبتة في الحاوية.

3. إذا لم يتم تثبيت أي أداة في pod، فقم بتشغيل الأمر التالي لإنشاء حاوية أداة مساعدة في نفس مساحة الاسم.

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. يمكنك استرداد عنوان خادم API من صفحة النظرة العامة لمجموعة AKS في مدخل Microsoft Azure، أو يمكنك تشغيل الأمر التالي.

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. قم بتشغيل الأمر التالي لمحاولة حل خادم AKS API. لمزيد من المعلومات، راجع استكشاف أخطاء فشل دقة DNS وإصلاحها من داخل الجراب ولكن ليس من العقدة العاملة.

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. تحقق من خادم DNS المصدر من الجراب لتحديد ما إذا كانت دقة DNS تعمل بشكل صحيح. على سبيل المثال، بالنسبة إلى Azure DNS، قم بتشغيل nslookup الأمر .

   nslookup microsoft.com 168.63.129.16
   

7. إذا لم توفر الخطوات السابقة رؤى، فاتصل بإحدى العقد العاملة وحاول تحليل DNS من العقدة. تساعد هذه الخطوة على تحديد ما إذا كانت المشكلة مرتبطة ب AKS أو تكوين الشبكة.

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

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

الخطوة 4: التحقق من وجود أخطاء kubelet

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

مصنف AKS kubelet

للتأكد من أن عقدة العامل kubelets تعمل بشكل صحيح، اتبع الخطوات التالية:

1. انتقل إلى نظام مجموعة AKS في مدخل Microsoft Azure.

2. في قسم Monitoring في جزء التنقل، حدد Workbooks.

3. حدد مصنف Kubelet.

   

4. حدد Operations وتأكد من اكتمال العمليات لجميع العقد العاملة.

   

المراقبة داخل نظام المجموعة باستخدام Prometheus وGrafana

إذا قمت بنشر Prometheus وGrafana في مجموعة AKS الخاصة بك، يمكنك استخدام لوحة معلومات Kubernetes / Kubelet للحصول على رؤى حول صحة وأداء kubelets العقدة الفردية.

مراقبة الخدمة المدارة ل Prometheus وAzure Managed Grafana

يمكنك استخدام لوحة معلومات Kubernetes / Kubelet مسبقة الإنشاء لتصور وتحليل مقاييس Prometheus ل kubelets عقدة العامل. للقيام بذلك، يجب عليك إعداد نظام مجموعة AKS لتجميع مقاييس Prometheus في مراقبة الخدمة المدارة ل Prometheus، وتوصيل مساحة عمل Monitor بمساحة عمل Azure Managed Grafana .

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

الخطوة 5: استخدام أداة الكشف عن مشكلة العقدة (NPD) للتحقق من صحة العقدة

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

الخطوة 6: تحقق من عمليات إدخال/إخراج القرص في الثانية (IOPS) للتقييد

للتأكد من عدم تقييد IOPS والتأثير على الخدمات وأحمال العمل داخل نظام مجموعة AKS، يمكنك استخدام إحدى الطرق التالية.

مصنف الإدخال/إخراج قرص عقدة AKS

لمراقبة مقاييس الإدخال/الإخراج المتعلقة بالقرص للعقد العاملة في نظام مجموعة AKS، يمكنك استخدام مصنف الإدخال/الإخراج لقرص العقدة. اتبع هذه الخطوات للوصول إلى المصنف:

1. انتقل إلى نظام مجموعة AKS في مدخل Microsoft Azure.

2. في قسم Monitoring في جزء التنقل، حدد Workbooks.

3. حدد مصنف Node Disk IO.

   

4. راجع المقاييس المتعلقة بالإداء/الإخراج.

   

المراقبة داخل نظام المجموعة باستخدام Prometheus وGrafana

إذا قمت بنشر Prometheus وGrafana في مجموعة AKS الخاصة بك، يمكنك استخدام لوحة معلومات USE Method / Node للحصول على رؤى حول إدخال/إخراج القرص لعقد عامل نظام المجموعة.

مراقبة الخدمة المدارة ل Prometheus وAzure Managed Grafana

يمكنك استخدام لوحة معلومات مصدر العقدة / العقد التي تم إنشاؤها مسبقا لتصور وتحليل المقاييس المتعلقة ب I/O للقرص من العقد العاملة. للقيام بذلك، يجب عليك إعداد نظام مجموعة AKS لتجميع مقاييس Prometheus في مراقبة الخدمة المدارة ل Prometheus، وتوصيل مساحة عمل Monitor بمساحة عمل Azure Managed Grafana .

IOPS وأقراص Azure

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

ضع في اعتبارك مفهوم معدل النقل. يمكنك ضرب متوسط حجم الإدخال/الإخراج في IOPS لتحديد معدل النقل بالميغابايت في الثانية (MBps). تترجم أحجام الإدخال/الإخراج الأكبر إلى IOPS أقل بسبب معدل النقل الثابت للقرص.

عندما يتجاوز حمل العمل الحد الأقصى لحدود خدمة IOPS المعينة لأقراص Azure، قد تصبح المجموعة غير مستجيبة وأدخل حالة انتظار الإدخال/الإخراج. في الأنظمة المستندة إلى Linux، يتم التعامل مع العديد من المكونات كملفات، مثل مآخذ الشبكة وCNI وDocker والخدمات الأخرى التي تعتمد على إدخال/إخراج الشبكة. وبالتالي، إذا تعذرت قراءة القرص، فسيمتد الفشل إلى كل هذه الملفات.

يمكن للعديد من الأحداث والسيناريوهات تشغيل تقييد IOPS، بما في ذلك:

• عدد كبير من الحاويات التي تعمل على العقد، لأن Docker I/O يشارك قرص نظام التشغيل.

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

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

• باولو سالفاتوري | مهندس العملاء الرئيسي
• فرانسيس سيمي الناصرة | أخصائي تقني أول

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

• حدود قرص الجهاز الظاهري
• الأجهزة الظاهرية وأداء القرص

الموارد ذات الصلة

مراقبة عمليات توزيع حمل العمل