VPN 서버 부하 해설: 사용자, CPU, 아니면 업링크?
낮은 부하 점수는 유휴 사용자, 남는 CPU, 또는 넓은 업링크를 뜻할 수 있습니다. 빠르다고 부르기 전에 loadavg, 인터페이스 카운터, 상태 파일을 읽어 보세요.
부하 0.4에 머무는 게이트웨이도 뒤에 있는 모든 사용자에게는 여전히 기어갈 수 있습니다. 평균 부하는 실행 가능하거나 중단 불가능한 수면에 갇힌 작업을 세며, 네 코어 호스트에서는 프로세스 하나가 포화되는 것만으로 1.0을 향해 밀려나고 나머지 세 코어는 놀고 있습니다. 이 숫자를 여유로 읽는 것이 엔드포인트 선택에서 가장 흔한 실수입니다. 터널을 실제로 제약하는 것은 보통 네 가지 중 하나입니다. 하나의 코어가 바쁘거나, 업링크가 좁거나, 그 앞의 큐가 막혀 있거나, 아무도 문서화하지 않은 세션별 정책이 있는 경우입니다.
평균 부하는 처리량이 아니라 작업을 센다
커널은 실행 큐와 입출력을 기다리는 작업 수를 표본으로 삼고, 둘 다 일분, 오분, 십오분에 걸쳐 평활화합니다. 그 정의에는 바이트도, 패킷도, 터널도 나오지 않습니다. 저장 장치가 막힌 호스트는 트래픽이 거의 없어도 높은 부하를 보고할 수 있고, 커널 데이터 경로로 기가비트를 밀어내는 호스트는 여유로운 부하를 보고할 수 있습니다.
따라서 부하를 터널 성능과 연결하려면 코어별 시각이 필요합니다. 한 코어가 꽉 차 있어도 대시보드의 전체 비율은 여전히 좋아 보일 것입니다:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20세 번째 명령이 VPN 호스트에서 가장 중요합니다. OpenVPN 2.x의 사용자 공간 패킷 처리는 프로세스별로 대부분 직렬화되므로, 하나의 바쁜 스레드가 상한이 될 수 있는데도 대시보드는 유휴 용량이 넘친다고 보고합니다. 느린 시간대에 한 스레드가 코어의 대부분을 차지한다면, 호스트가 전체적으로 부족한 것이 아니라 중요한 차원에서 제약된 것입니다.
타이밍도 보십시오. 십오분 평균은 통화를 망친 버스트를 숨기므로, 불만이 접수된 뒤에 찍은 스크린샷은 약한 증거입니다. 문제가 진행되는 동안 표본을 채취하고, 출력과 함께 타임스탬프를 남기십시오.
업링크와 그 앞의 큐
인터페이스 카운터는 CPU 수치가 답할 수 없는 대역폭 질문에 답합니다. 또한 용량과 손실을 구분해 주는데, 이는 해결책이 다른 서로 다른 고장입니다:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit테스트 중에 할당된 속도에 가까운 링크가 바로 설명이며, 남는 CPU를 아무리 늘려도 바뀌지 않습니다. qdisc 줄은 대화형 트래픽에 중요한 세부를 더합니다. 백로그와 드롭은 패킷이 나가기 전에 큐에서 기다리는지 알려 줍니다. 대용량 업로드 아래에서 큐가 차면, 사람들이 원격 서버 탓으로 돌리는 증상, 즉 벤치마크에서는 여전히 괜찮아 보이는 연결에서의 느린 통화가 정확히 발생합니다.
재전송 카운터는 패킷이 나가지만 깨끗하게 도착하지 않는 경우를 잡습니다. 느린 시간대에 재전송이 늘고 인터페이스가 용량과 거리가 멀다면, 문제는 호스트가 아니라 경로에 있으며 같은 도시의 다른 엔드포인트로 옮겨도 도움이 되지 않습니다.
세션 수는 수요를 설명할 뿐 여유가 아니다
모든 공개 디렉터리는 연결된 사용자 수를 얼마간 보여 주지만, 그 사용자들이 무엇을 하는지는 거의 알려 주지 않습니다. 대화형 작업을 하는 스무 개의 세션과 큰 파일을 받는 네 개의 세션은 같은 하드웨어에서 매우 다른 부하를 만듭니다. 두 번째 패턴은 사용자 수에 드러나지 않으며, 바로 그것이 저녁을 망칩니다. 그래서 세션 수는 수요의 단서로 읽는 것이 최선이며, 유휴 용량에 대한 단언으로 읽어서는 안 됩니다.
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
직접 관리하는 호스트라면 상태 파일이 빠진 차원을 제공합니다. OpenVPN은 클라이언트별 바이트 카운터를 포함한 주기적 스냅숏을 기록하므로, 한 세션이 업링크 전체를 차지하는지 볼 수 있습니다:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status십 초 간격의 표본 두 개면 그 누적 카운터가 클라이언트별 속도가 됩니다. 사용자 수가 대신 서 있는 측정이 바로 이것이며, 잘못 설정된 클라이언트 하나가 매일 밤 같은 시각에 링크를 포화시킨다는 것도 이렇게 발견합니다.
세션별 한도는 정책 안에 숨어 있다
서버가 유휴 상태여도 대역폭을 주지 않을 수 있습니다. 속도 제한, 클라이언트별 대역폭 상한, 트래픽 셰이핑은 흔히 공통 이름이나 풀 단위로 적용되므로, 같은 게이트웨이의 두 사용자가 전혀 다른 결과를 얻을 수 있습니다. 구조는 미묘하지 않지만 두 경우 모두 터널이 정상적으로 올라오기 때문에 밖에서는 보이지 않습니다.
셰이핑은 물리 인터페이스가 아니라 터널 인터페이스에서 찾으십시오. 한도가 사용자, 인증서, 주소 풀 중 무엇을 따르는지 확인하십시오. 테스트 계정이 상한 없는 풀에 들어가면, 서버는 괜찮고 불만을 제기한 사용자가 틀렸다고 결론 내리게 됩니다. 그 결론은 아무 결론도 없는 것보다 나쁩니다. 티켓을 닫아 버리기 때문입니다.
하나의 고정된 작업으로 두 엔드포인트를 비교하라
클라이언트 쪽 실험은 여전히 해 볼 가치가 있습니다. 다만 변수를 고정했을 때만 그렇습니다. 같은 기기, 같은 접속망, 같은 프로토콜, 같은 대상 파일을 쓰고, 비슷한 거리의 두 번째 엔드포인트를 상대로 반복하십시오. 실행 사이에 달라지는 모든 것, 하루 중 시간까지도 결과를 오염시킵니다.
실패도 성공만큼 꼼꼼히 기록하십시오. 세 엔드포인트가 동작하고 하나가 시간 초과되는 계열은 네 개의 속도 숫자보다 정보가 많습니다. 용량이 아니라 경로나 정책 문제를 가리키기 때문이며, 각 사례를 최소 두 번 실행하십시오. 공유 네트워크에서 느린 표본 하나는 아무것도 증명하지 못합니다.
마지막으로, 모은 숫자는 그것이 뒷받침하는 주장과 함께 보관하십시오. "이 엔드포인트는 다른 쪽이 멈춘 바로 그 구간에 전송을 처리했다"는 방어할 수 있지만, "이 엔드포인트가 더 빠르다"는 첫 화면 점수로는 이길 수 없는 논쟁을 부릅니다. OpenVPN 2.6 설명서에는 상태 파일과 셰이핑 옵션이 문서화되어 있으니, 호스트 쪽의 정확한 지시가 필요할 때 참고하십시오.