--- id: 2acec7d5-3eaf-4115-9d61-45647c4ec01e kind: QUESTION slug: is-production-on-a-hypervisor title: 운영 서버는 CPU 가상화 계층의 영향을 받는 구조인가 topic: cpu-virtualization topicName: CPU 가상화 project: virtualization status: 초안 questionStatus: OPEN studio: "https://hyeonworks.com/studio/documents/2acec7d5-3eaf-4115-9d61-45647c4ec01e/edit" sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 source: - final/document.md#20-이-concept에서-파생되는-open-question-oq-6 - final/document.md#18-bare-metal-k3s와-vm-기반-k3s의-차이 - final/document.md#25-cpu-문제를-계층별로-구분하는-진단표 --- # 운영 서버는 CPU 가상화 계층의 영향을 받는 구조인가 운영 서버가 bare-metal 인지 상위 하이퍼바이저나 클라우드 가상 머신 위인지는 SSOT 에 적혀 있지 않다. §25 의 진단표에는 Virtualization 과 Host 계층에만 걸리는 행이 따로 있어서, 그 구조가 정해져야 어느 행을 운영 진단에 쓸지 고를 수 있다. ## 관계 - **KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지** 운영 서버가 가상 머신 위라면 무엇이 더 끼어드는지를 설명한 기록이다. ## 사실 §18 은 호스트 OS 에 K3s 를 직접 설치했을 때의 CPU 경로를 적었다. 컨테이너에서 도는 작업은 K3s 와 컨테이너 런타임을 지나 호스트 Linux 스케줄러로, 다시 물리 CPU 로 간다. 그 호스트 위에 별도 가상 머신이 없다면 그 작업이 QEMU 와 /dev/kvm, KVM, VMX 경로를 타지는 않는다. 컨테이너의 프로세스는 호스트 커널을 공유하고 호스트 스케줄러가 직접 스케줄링한다. 가상 머신 안에 K3s 를 구성하면 계층이 더 붙는다. §18 이 든 것은 게스트 Linux 와 K3s, vCPU, QEMU vCPU 스레드, 호스트 Linux 스케줄러, KVM / VMX 다. 그래서 같은 부하 테스트라도 가상 머신 기반 환경에서는 호스트 가상화 자원 병목을 추가로 확인해야 한다. §20 의 OQ-6 은 두 경로를 K3s -> Host Scheduler -> Physical CPU 와 K3s -> Guest -> vCPU -> Hypervisor -> Physical CPU 로 나란히 적고, 구조에 따라 진단 지표가 달라진다고 밝혔다. §25 의 진단표는 문제마다 주된 계층을 갈라 적었다. vCPU 과다 할당 : VM 구성 CPU overcommit : Host 구성 CPU contention · Scheduling latency : Host Scheduler 잘못된 pinning : Host / VM 설정 과도한 VM Exit : KVM / VMX Steal time 증가 : Guest 에서 관측 Host CPU saturation : Host §218 은 운영을 `desktop` 이라 부르고 그 배치를 `nginx → 127.0.0.1:30080(NodePort) → Traefik` 으로 적었다. 이 실험대의 배치와 다른 것은 단일 노드냐 2노드냐 하나다. §284 는 그 `desktop` 이 Ubuntu 라고 적는다. 같은 절이 이 실험대가 `sites-available` 방식을 쓰는 이유도 적었다. 「운영(`desktop`)이 Ubuntu라 그 구조를 쓰고 있으므로, 설정을 운영으로 옮길 때 경로가 그대로 맞는 편이 낫다는 판단이다.」 SSOT 가 운영과 같다고 적은 것은 그 2홉 경로와 이 설정 관례 둘이다. 운영 서버가 bare-metal 인지 상위 하이퍼바이저나 클라우드 가상 머신 위인지는 SSOT 에 적혀 있지 않다. ## 가정 운영 서버도 K3s 로 Keycloak 을 돌린다고 전제한다. §20 이 나눈 두 경로는 둘 다 K3s 에서 시작한다. 운영 서버가 그 두 갈래 중 하나라고 전제한다. 중첩 가상화처럼 계층이 더 들어가는 구성은 이 물음에 넣지 않았다. 구조가 정해지면 §25 의 진단표를 운영 진단에도 그대로 쓴다고 전제한다. 진단표를 만든 근거는 이 테스트 환경이다. ## 미지수 운영 서버가 bare-metal 호스트에 직접 K3s 를 설치한 것인가, 상위 하이퍼바이저나 클라우드 가상 머신 위에 있는가. 하이퍼바이저 위라면 그 호스트의 CPU 지표를 볼 수 있는가. 클라우드 가상 머신이면 호스트 쪽 실행 대기열과 사용률을 읽을 수 없어 §25 의 Host 행을 그대로 쓰기 어려워진다. 운영 서버에 직접 붙어 명령을 돌릴 수 있는가. ## 제약 이 물음은 부하를 걸어 재는 것이 아니라 구성을 확인해서 닫는다. §14.1~§14.3 은 그 장비가 가상 머신을 직접 돌리는 호스트인지를 보여 준다. 그 장비 자신이 어떤 하이퍼바이저의 게스트인지는 이 세 명령이 말해 주지 않는다. 구조가 정해지기 전에는 §25 의 어느 행을 운영 진단에 넣을지 고를 수 없다. §25 는 그 표의 목적을 「하나의 지표로 장애 원인을 확정하는 것이 아니라, 어느 계층부터 조사해야 하는지 범위를 줄이는 것」이라고 적었다. 그래서 이 물음이 닫혀도 운영 장애의 원인이 정해지는 것은 아니다. 정해지는 것은 어느 계층부터 조사할지다. ## 선택지 ### 1. 구성 기록과 도입 경로로 확인한다 서버를 어떻게 마련했는지 남은 기록으로 bare-metal 인지 하이퍼바이저나 클라우드 가상 머신 위인지 가른다. 운영 서버에 붙지 않아도 되고 부하도 걸지 않는다. 기록이 실제 구성과 어긋나 있으면 어긋난 채로 적히므로 2번과 함께 쓴다. ### 2. 서버에 붙어 명령으로 확인한다 §14.1~§14.3 의 grep -E 'vmx|svm' /proc/cpuinfo · lsmod | grep kvm · ls -l /dev/kvm 로 그 장비가 가상 머신을 직접 돌리는 호스트인지부터 적는다. 이어서 게스트 안에서 top 의 %st 가 관측되는지 본다. 세 명령이 모두 비어 있으면 그 장비가 가상 머신을 직접 돌리지는 않는다는 뜻이고, 그 위에 하이퍼바이저가 있는지는 1번의 구성 기록으로 가른다. ### 3. 제외 — 테스트 환경의 구조를 운영에 옮겨 적는다 테스트 환경이 가상 머신 위라는 것이 운영 서버의 구조를 말해 주지 않는다. 두 환경을 같다고 적으면 §25 의 Virtualization 행을 근거 없이 운영 진단에 넣게 된다. ## 다음 검증 1. 운영 서버의 구성 기록이나 도입 경로로 bare-metal 인지 하이퍼바이저 / 클라우드 가상 머신 위인지 확인한다. 2. 서버에 붙을 수 있으면 §14.1~§14.3 의 grep -E 'vmx|svm' /proc/cpuinfo · lsmod | grep kvm · ls -l /dev/kvm 으로 그 장비가 가상 머신을 직접 돌리는 호스트인지 적는다. 3. 게스트 안에서 top (§14.8) 의 %st 가 관측되는지 함께 본다. 닫는 조건 : 운영 서버가 bare-metal 로 확인되면 §25 의 Virtualization · Host 행을 운영 진단에서 빼도 된다고 적고 닫는다. 하이퍼바이저나 클라우드 가상 머신 위로 확인되면 그 사실이 운영 진단의 전제가 되고, §25 의 어느 행을 운영에서 쓸지는 그 뒤 Decision 이 정한다.