VPN 서버 디스크 증가는 어디서 오고 어떻게 상한을 둘 것인가

터널이 연결을 받지 않고, 서비스가 두 번 재시작되며, 그 뒤로 로그에 아무것도 나타나지 않습니다. 그 침묵이 단서입니다. 디스크를 채운 것은 로그이고, 데몬은 기다리는 오류를 쓸 곳이 없기 때문입니다. 오래 도는 서비스라면 어느 것이든 그 상태에 이를 수 있고, logs라는 디렉터리를 지우는 것으로는 거의 고쳐지지 않습니다. 오래 가는 해결책은 어느 저장소가 늘었는지, 그 보존 정책은 누구의 것인지, 기록자가 정말 공간을 놓아주었는지 아는 것입니다.

늘어난 저장소와 그 증가율을 찾으십시오

잊기 쉬운 두 숫자로 시작합니다. 여유 블록과 여유 inode입니다. 파일 시스템은 공간이 많다고 보고하면서도 inode가 남지 않아 쓰기를 거부할 수 있고, 이는 서비스가 세션마다 파일을 하나씩 만들 때 생깁니다. 같은 볼륨에서 두 수치를 모두 확인하십시오. 답은 같은 오후에도 어긋날 수 있습니다. 호스트가 건강할 때 해두면 숫자가 장애가 아니라 정상 운전을 설명합니다.

df -h /var
df -i /var

그다음 증가를 소유자에게 돌리십시오. journal 자체의 사용량 수치는 journal만 다루며, 설정 파일의 경로에 쓰는 데몬은 결코 보지 못합니다.

journalctl --disk-usage

시간에 따른 증가는 어느 한 번의 측정보다 더 많은 것을 말합니다. 켜 둔 디버그 수준, 시도마다 기록하는 재시도 루프, 아무도 멈추지 않은 캡처 파일. 각각은 한 순간에는 평범해 보이고 한 시간 뒤에는 걱정스럽게 보입니다. 한 번 측정하고, 바쁜 시간대를 지나 다시 측정한 뒤 간격으로 나누십시오. 말할 수 있는 증가율은 용량을 화재가 아니라 결정으로 바꿉니다.

회전이 열린 파일에 하는 일

로그 파일은 inode를 가리키는 이름이고, 공간은 마지막 열린 핸들이 닫힐 때만 돌아옵니다. 파일 이름을 바꾸면 기록자는 같은 inode를 계속 채우고, 지우면 이름 없는 inode를 계속 채웁니다. ‘파일을 지웠는데 디스크가 계속 찼다’는 말이 깨진 파일 시스템이 아니라 파일 기술자를 설명하는 이유입니다. 기록자를 재시작하거나 파일을 다시 여는 회전 방식을 고르는 것이 실제로 블록을 돌려줍니다.

lsof +L1 | head

정책은 파일을 쓰는 구성 요소에 속합니다. journal은 설정 파일에서 자체 저장 한도를 적용하고, 파일 기반 서비스는 보통 logrotate에 의존합니다. 생성 규칙과 다시 열기 신호를 쓰거나, 기록자가 다시 열 수 없을 때 제자리에서 잘라내는 방식을 씁니다. 먼저 아무것도 바꾸지 않고 결정을 확인하십시오:

logrotate -d /etc/logrotate.conf

상한은 어디에 두고 얼마나 커야 하는가

상한은 기록자가 설정된 곳에 두고, 마운트 지점에 두지 마십시오. 볼륨 전체의 할당량은 호스트를 보호하지만 어느 서비스가 먼저 실패하는지는 말해주지 않고, 전역 정리 스크립트는 다음 사건에 필요한 증거를 지우기 쉽습니다. journal 상한, 최대 크기가 있는 회전 횟수, 애플리케이션 차원의 보존은 각각 생산자 하나를 묶습니다. 함께면 전체를 묶지만, 따로면 각각은 추측입니다.

그 상한은 확보된 여유 공간이 아니라 지킬 수 있는 보존 기간에서 정하십시오. 검토에 일주일 치 연결 시도가 필요하다면, journal은 가장 붐빌 것으로 예상되는 빈도로 일주일을 담아야 하고, 그 빈도가 앞서 측정한 숫자입니다.

디버그 로깅은 시작 시각이 기록되는 임시 모드이지 저장 계획이 아닙니다. 개인정보 문제를 같은 결정 안에 두십시오. 연결 로그는 주소와 식별자를 담기 때문입니다. 더 긴 보존도 데이터 처리의 선택이며, 두 제약을 모두 아는 사람이 정해야 합니다.

재시작 후 상한을 확인하십시오

다음 재부팅까지만 유지되는 보존 변경은 변경이 아닙니다. 기록자를 재시작하고 새 한도가 적용되는지 확인하며, 그 뒤에도 회전이 도는지 점검하십시오. journal은 재시작 한 번과 사용량 측정 한 번으로 두 질문에 답합니다:

systemctl restart systemd-journald
journalctl --disk-usage

파일 기반 서비스라면 회전 작업을 한 번 직접 실행하고 파일이 교체되고 기술자가 다시 열렸는지 확인하십시오. 옛 핸들을 쥔 기록자는 표면적인 점검을 통과하고, 다음에 볼륨이 차면 실패합니다. 시험 중 여유 공간을 보십시오. 파일은 줄었는데 공간이 돌아오지 않았다면 옛 inode가 아직 붙잡혀 있습니다.

다음 측정을 이것과 비교하십시오

일주일 뒤 돌아와 증가율을 기록된 값과 비교하십시오. 일치하면 상한이 유지되고 부하가 안정적입니다. 두 배가 되었다면 무언가 바뀐 것이고, 유용한 질문은 무엇이 바뀌었는가입니다. 먼저 로그 내용에서 반복되는 실패를 읽으십시오. 재시도 루프는 증상이자 양의 원인이기 때문입니다. 그다음 새로 켜진 것을 확인하십시오. 사건 중에 켜고 끄지 않은 디버그 수준도 포함합니다.

백업은 같은 볼륨 밖에 두거나, 디스크가 차면 백업도 함께 사라진다는 점을 받아들이십시오. 보호하는 호스트 자체에 쓴 사본은 복구 계획이 아닙니다. 그 보존에도 별도의 답이 필요합니다.

무엇을 어디에 얼마 동안 보존하고 누가 지우는지 적어 두십시오. 그 문장이 결과물이며, 다음 재시작을 견디는 이 작업의 유일한 부분입니다.