목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

개요

분석 및 관찰

디스크 사용률 스냅샷

문제 해결 프로세스

1단계: journalctlVacuum을 사용하여 오래된 로그 정리

2단계: 향후 방지를 위한 저널드 보존 구성

선택 사항 3단계: 재시작 오류 해결

변경 후 확인

권장 사항

소개

이 문서에서는 RCM의 /dev/vda3 파일 시스템에 대한 높은 디스크 공간 사용률 문제를 해결하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

Cisco에서는 다음 사항에 대해 알고 있는 것이 좋습니다.

- StarOS 제어 및 CUPS(User Plane Separation) 시스템 아키텍처 및 관리.

- 파일 시스템 및 디스크 사용량 모니터링을 위한 기본 Linux/Unix 명령

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

개요

Control 및 CUPS(User Plane Separation)가 있는 Cisco Ultra Packet Core 구축에서는 RCM(Redundancy Control Manager)이 컨트롤 플레인 운영 및 관리에 중요한 역할을 합니다. 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/ 아래의 저널 로그가 크게 증가했습니다. 7월 한 달 동안 생성된 로그만 ~3GB의 공간을 차지했습니다.

문제 해결 프로세스

디스크 사용률을 제어하려면 필요한 변경 구현 단계를 적용했습니다.

1단계: journalctl Vacuum을 사용하여 오래된 로그 정리

마지막 2주의 로그만 보존:

sudo journalctl --vacuum-time=2weeks

또는 저널 크기를 제한합니다(예: 600MB만 유지).

sudo journalctl --vacuum-size=600M

2단계: 향후 방지를 위한 저널드 보존 구성

저널드 구성 편집:

vi /etc/systemd/journald.conf

매개 변수 추가/수정:

MaxRetentionSec=2week

컨피그레이션 적용:

sudo systemctl restart systemd-journald

선택 사항 3단계: 재시작 오류 해결

2단계에서 systemd-jourald 서비스를 다시 시작하는 동안 다음과 같은 문제가 발생할 수 있습니다.

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

1. systemd-jourald는 inotify를 사용하여 로그 디렉터리에서 변경 사항을 확인합니다.

2. 각 시계 또는 모니터는 특정 커널 제한에 대한 카운트를 설정합니다.

문제가 되는 RCM에 정의된 현재 제한은 다음과 같습니다.

cat /proc/sys/fs/inotify/max_user_watches

501120

cat /proc/sys/fs/inotify/max_user_instances

128

ulimit -n

1024

수집된 출력에서:

- 최대 식별 시계 수: 501120

- 최대 inotify 인스턴스 수: 128

journald에 대한 열린 파일 설명자 제한: 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

- 현재 inotify 인스턴스: 126

- 현재 열린 파일 설명자: 65

루트에서 이미 허용된 inotify 인스턴스 128개 중 126개를 사용하고 있는 것 같습니다. 그러면 저널을 다시 시작할 때 새로 inotify 인스턴스를 만들 수 있는 공간이 거의 없습니다.

오류를 해결하려면 다음을 수행합니다. 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 활용률 및 저널릿 로그 증가를 정기적으로 모니터링합니다.