المحتويات

المقدمة

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

المتطلبات

المكونات المستخدمة

نظرة عامة

التحليل والملاحظة

لقطة إستخدام القرص

عملية أستكشاف الأخطاء وإصلاحها

الخطوة 1: تنظيف السجلات القديمة باستخدام JournalCtlVacuum

الخطوة 2:تكوين استبقاء دفتر اليومية للمنع في المستقبل

الخطوة 3 الاختيارية: حل خطأ إعادة التشغيل

التحقق بعد التغيير

التوصية

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء إستخدام مساحة القرص العالية وإصلاحها لنظام الملفات /dev/vda3 في RCM.

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

المتطلبات

cisco يوصي أن يتلقى أنت معرفة من:

- إدارة وبنية نظام StarOS للتحكم وفصل مستوى المستخدم (CUPS).

- أوامر Basic Linux/Unix لنظام الملفات ومراقبة إستخدام الأقراص.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

نظرة عامة

في عمليات نشر Cisco Ultra Packet Core باستخدام Control وفصل مستوى المستخدم (CUPS)، يلعب مدير التحكم في التكرار (RCM) دورا بالغ الأهمية في عمليات مستوى التحكم وإدارتها. يعد الاستخدام المستقر لنظام الملفات على عقد RCM أمرا مهما لضمان التشغيل السلس للتسجيل والمراقبة وإدارة جلسة عمل المشترك.

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

التحليل والملاحظة

وخلال عملية المراقبة، تبين أن عقدة RCM وصلت إلى إستخدام 72٪ على نظام الملفات الجذري الخاص بها.

لقطة إستخدام القرص

df -kh

Filesystem Size Used Avail Use% Mounted on

tmpfs 6.3G 9.7M 6.3G 1% /run

/dev/vda3 39G 27G 11G 72% /

tmpfs 32G 4.0K 32G 1% /dev/shm

tmpfs 5.0M 0 5.0M 0% /run/lock

/dev/vda2 488M 48K 452M 1% /var/tmp

/dev/vda1 488M 76K 452M 1% /tmp

وبعد إجراء المزيد من التحقيقات، لوحظ أن سجلات اليومية تحت /var/log/journal/ قد زادت بشكل كبير. وقد شكلت السجلات التي تم إنشاؤها خلال شهر يوليو وحده ما يصل إلى 3 غيغابايت من المساحة.

عملية أستكشاف الأخطاء وإصلاحها

للتحكم في إستخدام القرص، تم تطبيق خطوات تنفيذ التغيير المطلوبة:

الخطوة 1: تنظيف السجلات القديمة باستخدام فراغ JournalCTL

الاحتفاظ فقط بالإسبوعين الأخيرين من السجلات:

sudo journalctl --vacuum-time=2weeks

أو تحديد حجم دفتر اليومية (على سبيل المثال، الاحتفاظ ب 600 ميجابايت فقط):

sudo journalctl --vacuum-size=600M

الخطوة 2: تكوين الاحتفاظ بالصحفي لمنع الاستخدام في المستقبل

تحرير تكوين دفتر اليومية:

vi /etc/systemd/journald.conf

إضافة/تعديل المعلمة:

MaxRetentionSec=2week

تطبيق التكوين:

sudo systemctl restart systemd-journald

الخطوة 3 الاختيارية: حل خطأ إعادة التشغيل

أثناء إعادة تشغيل خدمة system-journald في الخطوة 2، يمكنك الحصول على خطأ مقلق:

Error : Failed to allocate directory watch: Too many open files

1. يستخدم SystemD-Journal التعديل لمراقبة أدلة السجل للتغييرات.

2. تقوم كل ساعة أو مراقبة تقوم بإعدادها بالعدد باتجاه حدود معينة لنواة واة واة واة الطباعة.

الحدود الحالية المحددة في آلية التنسيق الإقليمي الإشكالية هي:

cat /proc/sys/fs/inotify/max_user_watches

501120

cat /proc/sys/fs/inotify/max_user_instances

128

ulimit -n

1024

من المخرجات المجمعة:

- الحد الأقصى لعدد ساعات الهوية: 501120

- الحد الأقصى لمثيلات التعديل: 128

فتح حد واصف الملف لدفتر اليومية: 1024

يمكن أن يكون أي من (أو كل) حد قيم المخرجات قد ضرب يؤدي إلى الخطأ. لذا، قمنا بتجميع القيمة المستخدمة الحالية وقارنناها بحد الإنتاج المجمع:

sudo lsof -p $(pidof systemd-journald) | wc -l

65

echo "Root inotify instances: $(sudo find /proc/*/fd -user root -type l -lname 'anon_inode:inotify' 2>/dev/null | wc -l) / $(cat /proc/sys/fs/inotify/max_user_instances)"

Root inotify instances: 126 / 128

- المثيلات الحالية: 126

- واصف الملف المفتوح الحالي: 65

يبدو أن الجذر يستخدم بالفعل 126 من أصل 128 مثيل مسموح به. وهذا يترك الصحفي بلا مجال تقريبا لإنشاء مثيل IoTify جديد عند إعادة تشغيله.

لحل الخطأ: يمكننا زيادة قيمة max_user_instances ثم إعادة تشغيل الخدمة:

# Temporarily increase the limit (until next reboot)

echo 256 > /proc/sys/fs/inotify/max_user_instances

sudo systemctl restart systemd-journald

# Temporarily increase the limit (until next reboot)

echo 256 > /proc/sys/fs/inotify/max_user_instances

sudo systemctl restart systemd-journald

التحقق بعد التغيير

بعد تطبيق التغييرات، انخفض إستخدام القرص إلى 61٪، مما يؤدي إلى إستعادة العقدة إلى حالة التشغيل العادية.

df -kh

Filesystem      Size  Used Avail Use% Mounted on

tmpfs           6.3G  9.7M  6.3G   1% /run

/dev/vda3        39G   23G   15G  61% /

tmpfs            32G  4.0K   32G   1% /dev/shm

tmpfs           5.0M     0  5.0M   0% /run/lock

/dev/vda2       488M   48K  452M   1% /var/tmp

/dev/vda1       488M   76K  452M   1% /tmp

التوصية

- يمكنك تنفيذ نفس التكوين عبر جميع عقد إدارة المسار (RCM) في عملية النشر للحفاظ على إستخدام القرص في حدود آمنة.

- ضع RCM الهدف دائما في وضع الاستعداد قبل إجراء التغييرات لتجنب التأثير على حركة المرور المباشرة.

- مراقبة إستخدام /dev/vda3 ونمو سجلات اليومية بشكل دوري كجزء من عمليات فحص سلامة النظام الاستباقية.