OpenVPN 트래픽 카운터와 디스크 I/O: 세 가지 다른 숫자

큰 파일을 터널로 통과시키면 인터페이스 카운터가 파일 크기만큼 올라갑니다. 그 숫자가 같은 양이 디스크에 도달했다는 것을 뜻하지는 않습니다. 이런 논의에서는 서로 다른 세 가지 측정이 비교되며, 그것들은 서로 다른 세 가지 질문에 답합니다: 얼마나 많은 트래픽이 네트워크 계층을 지났는가, 프로세스가 시스템 호출로 몇 바이트를 읽고 썼는가, 그리고 얼마나 많은 작업이 스토리지 계층에 도달했는가.

첫 번째와 세 번째를 비교하는 것이 흔한 실수이며, 그것은 유령 디스크 문제를 만들거나 실제로 일어나는 쓰기를 무시한 용량 계획을 만듭니다. 셋은 분리할 수 있고, 각각 올바른 용도가 있습니다.

혼동되는 세 가지 숫자

인터페이스 카운터는 네트워크 계층에서 처리되는 트래픽을 설명합니다. 대역폭, 터널의 크기, 그리고 전송에 값을 매기는 과금 모델에는 이 숫자가 맞습니다.

프로세스의 문자 카운터는 파이프, 터미널, 문자 장치를 포함한 모든 디스크립터에서 읽기와 쓰기 호출로 옮겨진 바이트를 설명합니다. 시스템 호출 경계에서 프로세스가 얼마나 바쁜지 묻는 데는 이 숫자가 맞으며, 스토리지 청구서는 아닙니다.

스토리지 카운터는 커널이 블록 장치로 또는 그로부터 옮기려 한 바이트를 설명합니다. 용량 계획에는 이 숫자가 맞지만, 커널이 자체 회계 한계를 문서화한다는 점을 유의해야 합니다: 캐시된 읽기는 스토리지 읽기가 되지 않고, 나중에 취소된 쓰기는 완료된 장치 쓰기가 되지 않습니다.

파일 디스크립터가 디스크 쓰기가 아닌 이유

사용자 공간의 VPN은 TUN 장치를 통해 커널과 패킷을 주고받으며, 이 장치는 일반 파일이 아니라 문자 장치입니다. 여기서 읽으면 패킷이 넘어오고, 여기에 쓰면 패킷이 주입됩니다. 스토리지를 위해 준비되는 파일 내용 페이지가 없고, 파일 시스템 경로도 관여하지 않습니다.

그래서 바쁜 터널은 스토리지 카운터가 거의 없는 채로 거대한 문자 카운터를 보여줄 수 있습니다. 프로세스는 정말로 그 바이트를 옮겼고, 커널은 정말로 그 일에 디스크가 필요하지 않았습니다.

cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0

첫 번째 출력은 프로세스 시작 이후의 누적으로 읽고, 속도로 읽지 마세요. 두 번째는 같은 트래픽의 인터페이스 관점을 보여줍니다. 둘 사이의 큰 격차는 예상된 것이며 누수나 큐, 잘못된 설정을 뜻하지 않습니다.

바이트는 실제로 어디서 오는가

지속적 출력에는 자체 예산이 있습니다. 그것은 페이로드가 아니라 작업에 의해 움직이며, 장황한 로그 수준, 자주 바뀌는 클라이언트 목록, 또는 좁은 루프에서 반복되는 오류는 터널이 아주 적게 실어 나를 때도 상당한 쓰기를 만들어낼 수 있습니다.

상태 파일은 일정 간격으로 다시 쓰이는 스냅숏이므로, 그 비용은 간격과 담긴 레코드 수에 달려 있습니다. 모든 클라이언트 트래픽의 실행 사본이 아니며, 간격을 줄이면 트래픽 양을 바꾸지 않고 쓰기 양이 바뀝니다.

그 쓰기를 찾을 때는 소유권이 중요합니다. 서비스가 메시지를 로깅 데몬에 넘긴다면 저널이나 로그 파일은 그 데몬이 쓰며, 바이트는 VPN 프로세스 자체의 카운터가 아니라 데몬의 회계에 나타납니다. VPN 프로세스만 보는 것은 디스크 활동도, 그 부재도 설명하지 못합니다.

다른 기여자는 놓치기 쉽습니다: 시작할 때의 인증서와 설정 읽기, 자체 레코드를 쓰는 훅, 회계 플러그인, 크래시 덤프, 그리고 같은 호스트의 무관한 워크로드입니다. 어느 것도 터널 트래픽을 쓴 바이트와 같다고 놓고 추정해서는 안 됩니다.

각 카운터를 올바르게 읽기

세 가지 세부 사항이 비교에 의미가 있는지를 결정합니다. 프로세스의 동일성이 중요하며, 재시작된 서비스는 카운터를 초기화합니다. 시간 간격도 중요하며, 누적 수치와 초당 그래프는 다른 측정입니다. 그리고 단위도 중요하며, 로그 파일의 현재 크기 역시 속도가 아닙니다.

grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usage

실제 페이로드 쓰기를 의심한다면 페이로드를 저장하는 것이 임무인 구성 요소를 찾으세요: 패킷 캡처 도구, 본문을 캐시하는 프록시, 아카이브하는 플러그인입니다. 이것들은 기록하라는 양에 따라 커지는 스토리지 트래픽을 만들며, 보존과 접근에 관한 별도의 정책 결정에 속합니다.

올바른 숫자로 용량 계획하기

패킷 경로는 네트워크 수치로 산정하세요: 처리량, 암호 처리, 메모리 이동입니다. 스토리지는 실제로 선택한 관측성 결정으로 산정하세요: 로그 수준, 보존, 상태 간격, 의도적으로 켠 캡처입니다.

두 예산을 분리해 두면 사고를 읽기도 쉬워집니다. 터널 트래픽은 적은데 디스크가 가득 차면 로그, 캡처, 또는 무관한 무언가를 가리키며, 인터페이스 카운터는 결코 그것을 설명하지 못합니다. 로그는 조용한데 링크가 포화되면 반대 방향을 가리킵니다.

할 가치가 있는 비교는 같은 종류의 측정 사이의 비교입니다. 시간에 따른 인터페이스 바이트 대 인터페이스 바이트는 경로에 대해 알려줍니다. 스토리지 쓰기 대 스토리지 용량은 보존에 대해 알려줍니다. 교차 비교, 즉 트래픽 대 디스크는 의미 있어 보이기만 하고 결코 그렇지 않습니다.