좀 TechNet의 기사뿐만 아니라 읽고 있던 이 하나의 CPU 스케줄링을하는 방식으로 VM웨어와 하이퍼 V의 차이점에 대한합니다.
이것에 대한 객관적인 정보를 얻을 수 있는지 궁금합니다. VMware에서 사용하는 갱 스케줄링은 큰 단점이지만, 단지 coolaid를 마시고 싶지는 않습니다. 성능에 심각한 영향을 미치거나 VMware 하이퍼 바이저의 최신 반복으로이 문제가 해결됩니까?
편집 : 단점을 말할 때 Hyper V의 “무료 프로세서 스케줄링”과 관련이 있지만 KVM은 그렇지 않습니다. 내가 읽은 자료는 갱 스케줄링으로 피할 수있는 “무료 프로세서 스케줄링”에 문제가 있다고 말하지 않았다.
답변
블러디 메리 를 어두운 조명의 욕실 거울로 부르는 것처럼 제이크 오신 스가 나타나게 할 수 있는지 보자 …
갱 예약은 공동 예약이라고도합니다. VMware는 갱 스케줄링보다 공동 예약이라는 용어를 선호한다고 생각합니다.
버전 3.x 이전의 ESX 버전에서 VMware는 “엄격한”공동 예약을 사용했으며 동기화 단점이있었습니다. ESX 3.x 이상에서 VMware는 “휴식”공동 예약으로 전환했습니다.
편안한 공동 예약은 ESX 3.x의 엄격한 공동 예약을 대체했으며 후속 릴리스에서 개선되어 CPU 사용률을 높이고 광범위한 다중 프로세서 가상 머신을 지원합니다. 편안한 공동 예약은 엄격한 공동 예약 알고리즘과 비교하여 몇 가지 특징이 있습니다. 가장 중요한 것은 엄격한 공동 예약 알고리즘에서 지연된 vCPU가 있으면 전체 가상 시스템이 공동 중지되는 것입니다. 편안한 공동 예약 알고리즘에서 선행 vCPU는 가장 느린 형제 vCPU에 대한 스큐를 기반으로 자체 중지할지 여부를 결정합니다. 스큐가 임계 값보다 크면 선행 vCPU가 자체 중지됩니다. 지연 vCPU는 가장 빠른 형제 vCPU보다 훨씬 적은 진행률을 나타냅니다. 선행 vCPU는 가장 느린 형제 vCPU보다 훨씬 더 진보 한 것입니다. 가장 느린 형제 vCPU를 추적함으로써 이제 각 vCPU가 자체적으로 공동 예약 결정을 내릴 수 있습니다. 코스 톱과 마찬가지로 코 스타트 결정도 개별적으로 이루어집니다. 가장 느린 형제 vCPU가 진행되기 시작하면 동시 중지 된 vCPU는 공동 시작될 수 있으며 pCPU 가용성에 따라 예약 될 수 있습니다. 이렇게하면 vCPU 그룹을 함께 예약하지 않아도되므로 엄격한 공동 예약 알고리즘의 CPU 조각화 문제가 해결됩니다. 4-vCPU 가상 머신의 이전 예에서 사용 가능한 유휴 pCPU가 하나만 있어도 가상 머신은 앞으로 진행할 수 있습니다. 이것은 CPU 사용률을 크게 향상시킵니다. 가장 느린 형제 vCPU를 추적함으로써 이제 각 vCPU가 자체적으로 공동 예약 결정을 내릴 수 있습니다. 코스 톱과 마찬가지로 코 스타트 결정도 개별적으로 이루어집니다. 가장 느린 형제 vCPU가 진행되기 시작하면 동시 중지 된 vCPU는 공동 시작될 수 있으며 pCPU 가용성에 따라 예약 될 수 있습니다. 이렇게하면 vCPU 그룹을 함께 예약하지 않아도되므로 엄격한 공동 예약 알고리즘의 CPU 조각화 문제가 해결됩니다. 4-vCPU 가상 머신의 이전 예에서 사용 가능한 유휴 pCPU가 하나만 있어도 가상 머신은 앞으로 진행할 수 있습니다. 이것은 CPU 사용률을 크게 향상시킵니다. 가장 느린 형제 vCPU를 추적함으로써 이제 각 vCPU가 자체적으로 공동 예약 결정을 내릴 수 있습니다. 코스 톱과 마찬가지로 코 스타트 결정도 개별적으로 이루어집니다. 가장 느린 형제 vCPU가 진행을 시작하면 동시 중지 된 vCPU가 공동 시작될 수 있으며 pCPU 가용성에 따라 예약 될 수 있습니다. 이렇게하면 vCPU 그룹을 함께 예약하지 않아도되므로 엄격한 공동 예약 알고리즘의 CPU 조각화 문제가 해결됩니다. 4-vCPU 가상 머신의 이전 예에서 사용 가능한 유휴 pCPU가 하나만 있어도 가상 머신은 앞으로 진행할 수 있습니다. 이것은 CPU 사용률을 크게 향상시킵니다. 가장 느린 형제 vCPU가 진행을 시작하면 동시 중지 된 vCPU가 공동 시작될 수 있으며 pCPU 가용성에 따라 예약 될 수 있습니다. 이렇게하면 vCPU 그룹을 함께 예약하지 않아도되므로 엄격한 공동 예약 알고리즘의 CPU 조각화 문제가 해결됩니다. 4-vCPU 가상 머신의 이전 예에서 사용 가능한 유휴 pCPU가 하나만 있어도 가상 머신은 앞으로 진행할 수 있습니다. 이것은 CPU 사용률을 크게 향상시킵니다. 가장 느린 형제 vCPU가 진행을 시작하면 동시 중지 된 vCPU가 공동 시작될 수 있으며 pCPU 가용성에 따라 예약 될 수 있습니다. 이렇게하면 vCPU 그룹을 함께 예약하지 않아도되므로 엄격한 공동 예약 알고리즘의 CPU 조각화 문제가 해결됩니다. 4-vCPU 가상 머신의 이전 예에서 사용 가능한 유휴 pCPU가 하나만 있어도 가상 머신은 앞으로 진행할 수 있습니다. 이것은 CPU 사용률을 크게 향상시킵니다. 사용 가능한 유휴 pCPU가 하나만 있어도 가상 머신은 앞으로 진행할 수 있습니다. 이것은 CPU 사용률을 크게 향상시킵니다. 사용 가능한 유휴 pCPU가 하나만 있어도 가상 머신은 앞으로 진행할 수 있습니다. 이것은 CPU 사용률을 크게 향상시킵니다.
위의 스 니펫은 VMware 자체 문서 에서 발췌 한 것입니다 .
따라서 VMware는 더 이상 엄격한 갱 스케줄링을 사용하지 않습니다. 벤더의 문서를보다 권위있는 것으로 취급합니다.
어려운 숫자를 줄 유일한 것은 벤치 마크이며 CPU가 실행하는 코드의 종류에 전적으로 의존합니다. 그러나 VMware가 이러한 단점을 가지고 있다면 가상화 시장에서 여전히 큰 비중을 차지하지는 않을 것입니다.
답변
알았어, 라이언 내 하루를 만들었 어 예전처럼이 포럼을 읽지 못했지만 체크인했습니다.
Red888, Microsoft Hyper-V에서 일하는 소프트웨어 아키텍트임을 미리 알아야합니다. 나는 이것을 읽는 대부분의 사람들 이이 아래의 내 이름 링크를 클릭하고 그것을 발견하거나 심지어 인터넷 검색을 할 수 있다고 완벽하게 생각하지만,이 답변을 읽는 사람들은 내 관점에 대해 의심의 여지가 없다는 것을 완전히 확신하는 것이 유용합니다.
일반적으로 갱 스케줄링은 하이퍼 바이저가 VM 내에서 실행되는 OS의 동작에 영향을 줄 수있는 방법이없는 경우에 유용합니다. 물론 이것이 VMware가 이런 식으로 시작한 이유입니다. 운영 체제를 소유하지 않았기 때문에 기존 운영 체제가 제대로 작동하도록하는 것이 목표였습니다. 내가 그들이라면, 내가 시작했을 곳입니다.
갱 예약 및 VMware는 아마도 이것에 대해 옳다고 말할 것입니다. 시스템 내에서 물리적 프로세서를 사용하는 방법에는 많은 제한이 있습니다. 하이퍼 바이저는 종종 현재 적합한 리소스를 찾을 수 없습니다. 그래서 그들은 수년에 걸쳐 알고리즘을 수정하여 더 나은 스케줄링을 수행하는 방법을 찾고있었습니다.
마이크로 소프트 (그리고 아마도 몇몇 다른 회사들)는 다른 관점에서 출발했다. 우리는 Windows를 소유합니다. 가상화 될 때 Windows가 제대로 작동하도록합니다. 따라서 갱 스케줄링은 필요하지 않습니다. 우리는 갱 스케줄러를 구축하지 않아도됩니다.
흥미롭게도 Microsoft는 VMware, KVM, Xen, Oracle 또는 Unisys보다 나은 Hyper-V보다 다른 운영 체제와 비교할 때 Windows가 잘 실행되도록하는 데 더 많은 관심을 기울이고 있습니다. 따라서 Windows의 인터페이스를 게시했습니다. 하이퍼 바이저와 협력하는 데 사용합니다. 취침 시간 독서로 권장하지 않지만 궁금한 점이 있으면 다음 링크를 참조하십시오.
따라서 모든 하이퍼 바이저 공급 업체는 Windows에서 협력적인 동작을 유발하는 항목을 노출시킬 수 있습니다. 그들 중 몇몇은 가지고 있습니다. 나는 VMware가 이것을 가지고 있는지, 또는 노출 시킬지 솔직히 모른다. 당신은 그들에게, 또는 그들에게 많은주의를 기울이는 누군가에게 물어봐야합니다. 그리고 그들이 할 경우, 스케줄러를 더 긴장을 풀도록 수정하지 않았다면 매우 놀랐습니다. 물론 마지막 진술은 순수한 추측입니다.
결론적으로, 하이퍼 바이저 스케줄러의 작동 방식에 따라 2014 년에 구매 결정을 내려야한다고 의심합니다. 나는 그들이 지금까지 모두 꽤 좋다고 생각합니다. 몇 년 전, 그것은 사실이 아닐 수도 있습니다.
다양한 시스템에서 워크로드를 시도하고 작동 방식을 확인해야합니다. 스토리지와 네트워킹이 요구 사항을 충족하는지 여부에 따라 최고의 성능이 제공됩니다.
