도둑질: 가상 머신에서 CPU 시간을 훔치는 사람

안녕하세요! 가상 머신 내부의 도난 메커니즘과 연구 중에 발견한 몇 가지 명확하지 않은 아티팩트(클라우드 플랫폼의 기술 디렉터로서 제가 깊이 파고들었던)에 대해 간단한 용어로 말씀드리고 싶습니다. Mail.ru 클라우드 솔루션. 플랫폼은 KVM에서 실행됩니다.

CPU 도용 시간은 가상 머신이 실행을 위한 프로세서 리소스를 수신하지 않는 시간입니다. 이 시간은 가상화 환경의 게스트 운영 체제에서만 계산됩니다. 인생에서처럼 가장 많이 할당된 자원이 어디로 가는지에 대한 이유는 매우 모호합니다. 그러나 우리는 그것을 알아내기로 결정했고 심지어 여러 가지 실험을 수행하기도 했습니다. 이제 우리가 도둑질에 대해 모든 것을 아는 것은 아니지만, 이제 흥미로운 사실을 알려드리겠습니다.

1. 도둑질이란 무엇인가

따라서 스틸은 가상 머신 내부 프로세스에 대한 프로세서 시간이 부족함을 나타내는 지표입니다. 설명한대로 KVM 커널 패치에서스텔스란 실행을 위해 가상 머신 프로세스를 대기열에 넣었음에도 불구하고 하이퍼바이저가 호스트 OS에서 다른 프로세스를 실행하는 동안의 시간입니다. 즉, 스틸은 프로세스가 실행될 준비가 된 시간과 프로세스에 프로세서 시간이 할당된 시간의 차이로 계산됩니다.

가상 머신 커널은 하이퍼바이저로부터 도용 지표를 수신합니다. 동시에 하이퍼바이저는 자신이 실행 중인 다른 프로세스가 무엇인지 정확히 지정하지 않고 단순히 "바빠서 시간을 드릴 수 없습니다"라고만 말합니다. KVM에서 도용 계산 지원이 추가되었습니다. 패치. 여기에는 두 가지 핵심 사항이 있습니다.

• 가상 머신은 하이퍼바이저로부터 도용에 대해 학습합니다. 즉, 손실의 관점에서 가상 머신 자체의 프로세스에 대한 이는 다양한 왜곡이 발생할 수 있는 간접적인 측정입니다.
• 하이퍼바이저는 수행 중인 다른 작업에 대한 정보를 가상 머신과 공유하지 않습니다. 가장 중요한 것은 하이퍼바이저가 시간을 투자하지 않는다는 것입니다. 이로 인해 가상 머신 자체는 경쟁 프로세스의 특성으로 평가할 수 있는 도용 표시기의 왜곡을 감지할 수 없습니다.

2. 스틸에 영향을 미치는 요소

2.1. 도둑질 계산

기본적으로 스틸은 일반적인 CPU 사용 시간과 거의 동일하게 계산됩니다. 재활용이 어떻게 고려되는지에 대한 정보가 많지 않습니다. 아마도 대부분의 사람들이 이 질문을 당연하다고 생각하기 때문일 것입니다. 그러나 여기에도 함정이 있습니다. 이 프로세스에 익숙해지려면 다음을 읽어보세요. 브렌든 그레그의 기사: 활용률을 계산할 때 많은 차이와 다음과 같은 이유로 이 계산이 잘못되는 상황에 대해 알아봅니다.

• 프로세서가 과열되어 사이클이 건너뛰게 됩니다.
• 프로세서 클럭 속도를 변경하는 터보 부스트를 활성화/비활성화합니다.
• SpeedStep과 같은 프로세서 절전 기술을 사용할 때 발생하는 시간 조각 길이의 변화입니다.
• 평균 계산의 문제점: 80분 사용률을 100%로 추정하면 XNUMX%의 단기 버스트를 숨길 수 있습니다.
• 스핀 잠금으로 인해 프로세서가 회수되지만 사용자 프로세스에는 실행 진행 상황이 표시되지 않습니다. 결과적으로, 프로세스가 물리적으로 프로세서 시간을 소비하지는 않더라도 프로세스에 의해 계산된 프로세서 사용률은 XNUMX%가 됩니다.

도둑질에 대한 유사한 계산을 설명하는 기사를 찾지 못했습니다(아신다면 댓글로 공유해 주세요). 그러나 소스 코드로 판단하면 계산 메커니즘은 재활용과 동일합니다. 간단히 말해서 KVM 프로세스(가상 머신 프로세스)에 대해 직접 커널에 또 다른 카운터가 추가되어 KVM 프로세스가 CPU 시간을 기다리는 기간을 계산합니다. 카운터는 해당 사양에서 프로세서에 대한 정보를 가져와 모든 틱이 가상 머신 프로세스에서 활용되는지 여부를 확인합니다. 그게 전부라면 프로세서는 가상 머신 프로세스에만 사용된다고 가정합니다. 그렇지 않으면 프로세서가 다른 작업을 수행하고 있음을 알리고 도용이 나타납니다.

도난품 계산 과정은 일반 재활용품 계산과 동일한 문제를 안고 있습니다. 그러한 문제가 자주 나타나는 것은 아니지만 실망스러워 보입니다.

2.2. KVM의 가상화 유형

대체로 가상화에는 세 가지 유형이 있으며 모두 KVM에서 지원됩니다. 도난 발생 메커니즘은 가상화 유형에 따라 달라질 수 있습니다.

방송. 이 경우 물리적 하이퍼바이저 장치를 사용하는 가상 머신 운영 체제의 작동은 다음과 같이 발생합니다.

1. 게스트 운영 체제는 게스트 장치에 명령을 보냅니다.
2. 게스트 장치 드라이버는 명령을 수신하고 장치 BIOS에 대한 요청을 생성하여 하이퍼바이저로 보냅니다.
3. 하이퍼바이저 프로세스는 명령을 물리적 장치에 대한 명령으로 변환하여 무엇보다도 장치의 보안을 더욱 강화합니다.
4. 물리적 장치 드라이버는 수정된 명령을 수락하고 이를 물리적 장치 자체에 보냅니다.
5. 명령 실행 결과는 동일한 경로를 따라 되돌아옵니다.

변환의 장점은 모든 장치를 에뮬레이트할 수 있고 운영 체제 커널을 특별히 준비할 필요가 없다는 것입니다. 하지만 우선 속도에 대한 비용을 지불해야합니다.

하드웨어 가상화. 이 경우 하드웨어 수준의 장치는 운영 체제의 명령을 이해합니다. 이것이 가장 빠르고 좋은 방법입니다. 그러나 불행히도 모든 물리적 장치, 하이퍼바이저 및 게스트 운영 체제에서 지원되는 것은 아닙니다. 현재 하드웨어 가상화를 지원하는 주요 장치는 프로세서입니다.

반가상화. KVM의 장치 가상화에 대한 가장 일반적인 옵션이며 일반적으로 게스트 운영 체제에 대한 가장 일반적인 가상화 모드입니다. 그 특징은 일부 하이퍼바이저 하위 시스템(예: 네트워크 또는 디스크 스택) 작업 또는 메모리 페이지 할당이 하위 수준 명령을 변환하지 않고 하이퍼바이저 API를 사용하여 발생한다는 것입니다. 이 가상화 방법의 단점은 이 API를 사용하여 하이퍼바이저와 통신할 수 있도록 게스트 운영 체제 커널을 수정해야 한다는 것입니다. 그러나 이는 일반적으로 게스트 운영 체제에 특수 드라이버를 설치하면 해결됩니다. KVM에서는 이 API를 호출합니다. 버티오 API.

반가상화를 사용하면 브로드캐스팅에 비해 가상 머신에서 호스트의 하이퍼바이저 프로세스로 직접 명령을 보내 물리적 장치에 대한 경로가 크게 줄어듭니다. 이를 통해 가상 머신 내부의 모든 명령 실행 속도를 높일 수 있습니다. KVM에서는 네트워크나 디스크 어댑터와 같은 특정 장치에서만 작동하는 virtio API를 통해 이 작업이 수행됩니다. 이것이 virtio 드라이버가 가상 머신 내부에 설치되는 이유입니다.

이 가속화의 단점은 가상 머신 내부에서 실행되는 모든 프로세스가 가상 머신 내부에 남아 있지는 않다는 것입니다. 이로 인해 도둑질 시 생성될 수 있는 몇 가지 특수 효과가 생성됩니다. 이 문제에 대한 자세한 연구를 시작하는 것이 좋습니다. 가상 I/O용 API: virtio.

2.3. "공정한" 일정

하이퍼바이저 상의 가상 머신은 사실 리눅스 커널의 스케줄링(프로세스 간 자원 분배) 법칙을 따르는 일반적인 프로세스이므로 좀 더 자세히 살펴보겠습니다.

Linux는 커널 2.6.23부터 기본 스케줄러가 된 소위 CFS, Completely Fair Scheduler를 사용합니다. 이 알고리즘을 이해하려면 Linux 커널 아키텍처 또는 소스 코드를 읽어보세요. CFS의 핵심은 실행 기간에 따라 프로세스 간에 프로세서 시간을 분배하는 것입니다. 프로세스에 필요한 CPU 시간이 많을수록 받는 CPU 시간은 줄어듭니다. 이를 통해 모든 프로세스가 "공정하게" 실행되도록 보장합니다. 즉, 하나의 프로세스가 지속적으로 모든 프로세서를 점유하지 않고 다른 프로세스도 실행할 수 있도록 합니다.

때때로 이 패러다임은 흥미로운 결과물로 이어집니다. 오랫동안 Linux를 사용해 온 사용자라면 컴파일러와 같이 리소스 집약적인 애플리케이션을 실행하는 동안 데스크탑에서 일반 텍스트 편집기가 정지되었던 일을 기억할 것입니다. 이는 데스크톱 애플리케이션의 리소스 집약적이지 않은 작업이 컴파일러와 같은 리소스 집약적인 작업과 경쟁했기 때문에 발생했습니다. CFS는 이것이 불공평하다고 생각하여 주기적으로 텍스트 편집기를 중지하고 프로세서가 컴파일러 작업을 처리하도록 합니다. 메커니즘을 사용하여 수정되었습니다. sched_autogroup, 그러나 작업 간 프로세서 시간 분배에 대한 다른 많은 기능은 그대로 유지되었습니다. 실제로 이것은 CFS의 모든 것이 얼마나 나쁜지에 대한 이야기가 아니라 프로세서 시간의 "공정한"분배가 가장 사소한 작업이 아니라는 사실에 주목하려는 시도입니다.

스케줄러의 또 다른 중요한 점은 선점입니다. 이는 프로세서에서 비웃는 프로세스를 쫓아내고 다른 프로세스가 작동하도록 하는 데 필요합니다. 배출 프로세스를 컨텍스트 전환이라고 합니다. 이 경우 작업의 전체 컨텍스트, 즉 스택, 레지스터 등의 상태가 보존된 후 프로세스가 대기 상태로 전송되고 다른 프로세스가 그 자리를 차지합니다. 이는 OS에 있어서 비용이 많이 드는 작업이므로 거의 사용되지 않지만 본질적으로 잘못된 것은 없습니다. 빈번한 컨텍스트 전환은 OS에 문제가 있음을 나타낼 수 있지만 일반적으로 지속적이며 특별한 것을 나타내지는 않습니다.

한 가지 사실을 설명하려면 이렇게 긴 이야기가 필요합니다. 정직한 Linux 스케줄러에서 프로세스가 소비하려고 하는 프로세서 리소스가 많을수록 다른 프로세스도 작동할 수 있도록 프로세스가 더 빨리 중지됩니다. 이것이 맞는지 아닌지는 다양한 부하에서 다르게 해결될 수 있는 복잡한 질문입니다. Windows에서는 최근까지 스케줄러가 데스크톱 애플리케이션의 우선 처리에 중점을 두어 백그라운드 프로세스가 정지될 수 있었습니다. Sun Solaris에는 다섯 가지 클래스의 스케줄러가 있었습니다. 가상화를 출시하면서 여섯 번째 항목을 추가했습니다. 공정한 공유 스케줄러, 이전 XNUMX개는 Solaris 영역 가상화에서 제대로 작동하지 않았기 때문입니다. 다음과 같은 책을 통해 이 문제에 대한 자세한 연구를 시작하는 것이 좋습니다. Solaris 내부: Solaris 10 및 OpenSolaris 커널 아키텍처 또는 리눅스 커널 이해.

2.4. 도용을 모니터링하는 방법은 무엇입니까?

다른 프로세서 메트릭과 마찬가지로 가상 머신 내부의 도용을 모니터링하는 것은 간단합니다. 모든 프로세서 메트릭 도구를 사용할 수 있습니다. 가장 중요한 것은 가상 머신이 Linux에 있다는 것입니다. 어떤 이유로 Windows에서는 이 정보를 사용자에게 제공하지 않습니다. 🙁

최상위 명령 출력: 프로세서 로드 세부 정보(가장 오른쪽 열) - Steal

하이퍼바이저에서 이 정보를 얻으려고 할 때 어려움이 발생합니다. 예를 들어 로드 평균(LA) 매개변수(실행 대기열에서 대기 중인 프로세스 수의 평균 값)를 사용하여 호스트 시스템에서 도용을 예측할 수 있습니다. 이 매개변수를 계산하는 방법은 간단하지 않지만 일반적으로 프로세서 스레드 수로 정규화된 LA가 1보다 크다면 이는 Linux 서버에 무언가 과부하가 있음을 나타냅니다.

이 모든 프로세스는 무엇을 기다리고 있습니까? 분명한 대답은 프로세서입니다. 그러나 때로는 프로세서가 무료이지만 LA가 규모를 벗어나기 때문에 대답이 완전히 정확하지는 않습니다. 기억하다 NFS의 몰락과 LA의 성장. 디스크 및 기타 입/출력 장치에서도 마찬가지입니다. 그러나 실제로 프로세스는 I/O 장치와 관련된 물리적 잠금이나 뮤텍스와 같은 논리적 잠금이 끝날 때까지 기다릴 수 있습니다. 여기에는 하드웨어 수준의 잠금(디스크의 동일한 응답) 또는 논리(소위 잠금 기본 요소라고 하며 여러 엔터티, 뮤텍스 적응형 및 스핀, 세마포어, 조건 변수, rw 잠금, ipc 잠금 포함)도 포함됩니다. ...).

LA의 또 다른 특징은 운영 체제 평균으로 간주된다는 것입니다. 예를 들어, 100개의 프로세스가 하나의 파일을 위해 경쟁하고 있으며 LA=50입니다. 이렇게 큰 값은 운영 체제가 나쁘다는 것을 나타내는 것처럼 보입니다. 그러나 다른 비뚤어진 코드의 경우 이는 단지 나쁘고 운영 체제의 다른 프로세스가 영향을 받지 않는다는 사실에도 불구하고 정상적인 상태일 수 있습니다.

이러한 평균화(그리고 XNUMX분 이내에) 때문에 LA 지표로 무엇이든 결정하는 것은 가장 보람 있는 작업이 아니며 특정 경우에 결과가 매우 불확실합니다. 이를 알아내려고 하면 Wikipedia 및 기타 사용 가능한 리소스의 기사가 프로세스에 대한 깊은 설명 없이 가장 간단한 사례만 설명하고 있음을 알 수 있습니다. 관심 있으신 모든 분들께 다시 한 번 보내드립니다. 여기 브렌든 그레그에게  - 아래 링크를 따라가세요. 너무 게으른 사람은 영어를 할 수 없습니다 - LA에 관한 그의 인기 기사 번역.

3. 특수효과

이제 우리가 접한 주요 도둑질 사례를 살펴보겠습니다. 위의 모든 내용을 어떻게 따르고 하이퍼바이저의 표시기와 어떤 관련이 있는지 알려 드리겠습니다.

재활용. 가장 간단하고 가장 일반적입니다. 하이퍼바이저가 재사용되었습니다. 실제로 실행 중인 가상 머신이 많고, 그 내부의 프로세서 소비량이 높으며, 경쟁이 심하고, LA 활용도가 1 이상입니다(프로세서 스레드로 정규화됨). 모든 가상 머신 내부의 모든 것이 느려집니다. 하이퍼바이저에서 전송되는 도난도 증가하고 있으므로 부하를 재분배하거나 누군가를 꺼야 합니다. 일반적으로 모든 것이 논리적이고 이해 가능합니다.

반가상화와 단일 인스턴스. 하이퍼바이저에는 가상 머신이 하나만 있으며, 그 중 작은 부분을 소비하지만 예를 들어 디스크에서 큰 I/O 로드를 생성합니다. 그리고 어딘가에서 최대 10%까지 작은 도둑질이 나타납니다(여러 실험에서 알 수 있듯이).

이 사건은 흥미롭습니다. 반가상화 드라이버 수준의 차단으로 인해 Steal이 여기에 나타납니다. 인터럽트는 가상 머신 내부에서 생성되어 드라이버에 의해 처리되고 하이퍼바이저로 전송됩니다. 하이퍼바이저의 인터럽트 처리로 인해 가상 머신의 경우 전송된 요청처럼 보이고 실행 준비가 되어 프로세서를 기다리고 있지만 프로세서 시간이 제공되지 않습니다. 가상 소녀는 이번이 도난당했다고 생각합니다.

이는 버퍼가 전송되는 순간 발생하며 하이퍼바이저의 커널 공간으로 들어가고 우리는 이를 기다리기 시작합니다. 하지만 가상 머신의 관점에서는 즉시 돌아와야 합니다. 따라서 도용 계산 알고리즘에 따르면 이번 시간은 도용으로 간주됩니다. 대부분의 경우 이 상황에는 다른 메커니즘(예: 다른 sys 호출 처리)이 있을 수 있지만 크게 다르지 않아야 합니다.

스케줄러와 로드가 많은 가상 머신 비교. 한 가상 머신이 다른 가상 머신보다 더 많이 도용당하는 경우 이는 스케줄러 때문입니다. 프로세스가 프로세서를 더 많이 로드할수록 스케줄러가 이를 더 빨리 제거하여 다른 프로세스도 작업할 수 있게 됩니다. 가상 머신이 거의 소비하지 않으면 도용을 거의 볼 수 없습니다. 해당 프로세스는 정직하게 앉아서 기다렸으므로 더 많은 시간을 주어야 합니다. 가상 머신이 모든 코어에서 최대 로드를 생성하는 경우 종종 프로세서에서 쫓겨나고 많은 시간을 주지 않으려고 합니다.

가상 머신 내부의 프로세스가 데이터 처리에 대처할 수 없기 때문에 더 많은 프로세서를 확보하려고 하면 상황은 더욱 악화됩니다. 그러면 하이퍼바이저의 운영 체제는 정직한 최적화로 인해 프로세서 시간을 점점 더 적게 제공하게 됩니다. 이 프로세스는 눈사태처럼 발생하며 다른 가상 머신에서는 이를 거의 알아차리지 못할 수도 있지만 하늘로 도약이 발생합니다. 코어가 많을수록 영향을 받는 시스템은 더욱 악화됩니다. 즉, 코어가 많고 부하가 높은 가상 머신이 가장 큰 어려움을 겪습니다.

LA는 낮지만 스틸은 있다. LA가 약 0,7(즉, 하이퍼바이저가 언더로드된 것으로 보임)이지만 개별 가상 머신 내부에서 스틸이 관찰되는 경우:

• 반가상화 옵션은 이미 위에 설명되어 있습니다. 하이퍼바이저에는 문제가 없지만 가상 머신은 도용을 나타내는 측정항목을 수신할 수 있습니다. 실험 결과에 따르면 이 스틸 옵션은 10%를 초과하지 않으며 가상 머신 내부 애플리케이션 성능에 큰 영향을 미치지 않아야 합니다.
• LA 매개변수가 잘못 계산되었습니다. 보다 정확하게는 특정 순간마다 정확하게 계산되지만 0,15분 이상 평균을 내면 과소평가되는 것으로 드러납니다. 예를 들어 하이퍼바이저의 0,6/25당 하나의 가상 머신이 정확히 XNUMX분 동안 모든 프로세서를 사용하는 경우 하이퍼바이저의 분당 LA는 XNUMX가 됩니다. 동시에 작동하는 XNUMX개의 가상 머신은 XNUMX을 제공합니다. 그리고 LA 지표에 따르면 각각 XNUMX분 동안 XNUMX%의 와일드 스틸이 있었다는 사실은 더 이상 빼낼 수 없습니다.
• 또 누군가가 너무 많이 먹는다고 판단하고 그 누군가를 기다리게 하는 스케줄러 때문이다. 그동안 저는 컨텍스트를 전환하고, 인터럽트를 처리하고, 기타 중요한 시스템 작업을 처리하겠습니다. 결과적으로 일부 가상 머신에서는 아무런 문제도 발견되지 않는 반면 다른 가상 머신에서는 심각한 성능 저하가 발생합니다.

4. 기타 왜곡

가상 머신에서 프로세서 시간의 공정한 반환을 왜곡하는 데에는 백만 가지 이상의 이유가 있습니다. 예를 들어 하이퍼스레딩과 NUMA로 인해 계산이 어려워집니다. 스케줄러는 컨텍스트를 전환할 때 계산을 더욱 어렵게 만드는 계수(가중치)를 사용하기 때문에 프로세스 실행을 위한 커널 선택을 완전히 혼동합니다.

사용률을 계산할 때 서버의 주파수나 시간 조각을 인위적으로 늘리거나 줄일 수 있는 터보 부스트 또는 반대로 에너지 절약 모드와 같은 기술로 인해 왜곡이 있습니다. 터보 부스트를 활성화하면 다른 프로세서 스레드의 성능 증가로 인해 한 프로세서 스레드의 성능이 감소합니다. 현재 현재 프로세서 주파수에 대한 정보는 가상 머신으로 전송되지 않으며 누군가가 시간을 훔치고 있다고 생각합니다(예: 2GHz를 요청했지만 그 절반을 수신함).

일반적으로 왜곡에는 여러 가지 이유가 있을 수 있습니다. 특정 시스템에서 다른 것을 찾을 수도 있습니다. 위에 링크를 제공한 책으로 시작하고 perf, sysdig, systemtap과 같은 유틸리티를 사용하여 하이퍼바이저에서 통계를 검색하는 것이 좋습니다. 수십.

5. 결론

1. 반가상화로 인해 어느 정도의 도용이 발생할 수 있으며 이는 정상적인 것으로 간주될 수 있습니다. 그들은 이 값이 5-10%가 될 수 있다고 인터넷에 씁니다. 가상 머신 내부의 애플리케이션과 물리적 장치에 가하는 로드에 따라 달라집니다. 여기서는 가상 머신 내에서 애플리케이션이 어떻게 느껴지는지에 주의를 기울이는 것이 중요합니다.
2. 하이퍼바이저의 로드와 가상 머신 내부의 도용 비율은 항상 명확하게 상호 연관되어 있는 것은 아닙니다. 두 도용 추정치는 서로 다른 로드의 특정 상황에서 잘못될 수 있습니다.
3. 스케줄러는 많은 것을 요구하는 프로세스에 대해 나쁜 태도를 가지고 있습니다. 그는 더 많은 것을 요구하는 사람들에게 더 적은 것을 주려고 노력합니다. 대규모 가상 머신은 사악합니다.
4. 반가상화 없이도 약간의 도용이 표준이 될 수 있습니다(가상 머신 내부의 부하, 이웃 부하의 특성, 스레드 전체의 부하 분산 및 기타 요소 고려).
5. 특정 시스템에서 도용을 파악하려면 다양한 옵션을 탐색하고 지표를 수집하고 신중하게 분석하고 로드를 균등하게 분배하는 방법을 생각해야 합니다. 어떤 경우에도 편차가 발생할 수 있으며, 이는 실험적으로 확인하거나 커널 디버거에서 살펴봐야 합니다.

출처 : habr.com