OPM

화면과 같이 ESXi root 패스워드를 연속해서 잘못 입력을 하면 lock이 걸려 접속이 안됩니다.

콘솔에 직접 접속해서 

pam_tally2 --user root --reset 입력

ETCD : ETCD 데이터 저장소는 Node, POD, Config, Secret, Account, Role, Binding 등과 같은 클러스터 정보를 저장 합니다.

Kube-apiserver : 클러스터 내의 모든 작업을 오케스트레이션 합니다.

Kubelet

몬스터 VM들의 vMotion 과제

상당한 수의 I / O를 처리하는 대규모 트랜잭션 데이터베이스 플랫폼은 vMotion 동안 성능 저하를 경험할 수 있습니다.

vSphere 7의 향상된 vMotion 로직은 이러한 모든 문제를 극복하고 성능 또는 가용성에 큰 영향을주지 않으면 서 대규모 워크로드를 실시간 마이그레이션 할 수 있습니다.

vSphere 7에서의 변화

• vMotion 로직 최적화
• 성능저하 감소
• 가상머신 스턴 타임 감소

vSphere 7의 이러한 vMotion 개선 사항을 통해 vMotion 동안 성능 저하없이 워크로드를 실시간으로 마이그레이션 할 수 있습니다. 다음 다이어그램은 vSphere 7에서 잠재적 인 성능 향상을 보여주는 테스트의 예입니다. 테스트 베드는 HammerDB 워크로드를 실행하는 큰 VM (72 vCPU / 512GB)입니다. 타임 라인에서 1 초 단위로 커밋 / 초를 모니터링합니다.

vSphere 6.7과 비교하여 vSphere 7에서이 테스트 중에 확인한 몇 가지 주요 사항은 다음과 같습니다.

• 더 이상 페이지 추적 단계에서 성능에 영향을 미치지 않습니다.
• 스턴 시간은 몇 초가 걸리지 않고 1 초 이내에 유지됩니다.
• 전체 라이브 마이그레이션 시간은 거의 20 초 짧습니다.

vSphere7 vMotion Logic

• 메모리 사전 복사 최적화
• 페이지 테이블 세분성
• 전환 단계 향상
• 성능 개선

1. 메모리 사전 복사 최적화

1-1 VMware7 이전 버전에서 vMotion 원리

 vMotion 프로세스는 VM에 대해 구성된 모든 vCPU에 페이지 추적 프로그램을 설치합니다. 이렇게하면 vMotion은 어떤 메모리 페이지를 덮어 쓰는지 이해합니다. 이를 페이지 추적 중 'Page Fire'이라고합니다. 실시간 마이그레이션 된 VM의 모든 vCPU에 추적 작업을 배포합니다.

  페이지 추적 프로그램을 설치하고 페이지 실행을 처리하기 위해 vCPU가 잠시 중지됩니다. 마이크로 초에 불과하지만 모든 vCPU를 중지하면 워크로드가 중단됩니다. VM의 컴퓨팅 리소스를 확장하면 vMotion 작업의 영향이 커집니다.

추적 작업을 위해 vCPU를 중지 한 후 모든 메모리 페이지 테이블 항목 (PTE) 이 읽기 전용으로 설정되고 TLB (Translation Lookaside Buffers) 가 플러시되어 TLB 적중을 방지하고 페이지 테이블을 강제로 이동하여 vMotion 프로세스가 완전히 이해합니다. 덮어 쓴 메모리 페이지 이 블로그 게시물에서 이러한 메모리 구성 에 대해 자세히 알아보십시오 . 여기에 설명 된 방법을 "Stop-based Page Trace Install"라고합니다.

1-2 vSphere7 에서 vMotion 하는 방법

 가장 큰 영향은 페이지 추적을 위해 모든 vCPU를 중지해야한다는 것입니다. 모든 vCPU를 중지 할 필요없이 페이지 추적 프로그램을 설치할 수 있다면 어떨까요? vSphere 7에서는“Loose Page Trace Install”이 도입되었습니다. 페이지 추적 방법은 대부분 동일하지만 모든 vCPU를 사용하는 대신 모든 추적 작업을 수행하기 위해 하나의 vCPU 만 청구합니다. VM에 권한이 부여 된 다른 모든 vCPU는 중단없이 계속 워크로드를 실행합니다.

 페이지 트레이서는 요청된 하나의 vCPU에 설치되고 모든 PTE를 읽기 전용으로 설정합니다. TLB는 vCPU에 따라 다르므로 각 vCPU는 여전히 해당 TLB를 플러시해야합니다. 그러나 이것은 영향을 최소화하기 위해 다른 시간에 발생합니다. 전체적으로이 방법은 하나의 vCPU 만 페이지 추적에 사용되므로 훨씬 효율적입니다.

2.페이지 테이블 세분성

따라서 추적 비용을 줄 였지만 더 효율적으로 만들 수 있다면 어떨까요?

메모리를 읽기 전용으로 설정하는 방식을 최적화했습니다. 즉,이 부분에서 수행 할 작업이 줄어 듭니다. 적은 작업으로 효율성이 향상됩니다.

2-1 이전버전에서 메모리 읽기방식

vSphere 7 이전의 메모리가 읽기 전용으로 설정되는 방식은 4KB 페이지 단위입니다. vSphere 7 이전 버전에서는 모든 개별 4KB 페이지를 읽기 전용 액세스로 설정해야했습니다.

2-2 vSphere 7에서 부터 메모리 읽기 방식

vSphere 7부터 VMM (Virtual Machine Monitor) 프로세스는 1GB 페이지에서 더 큰 단위로 읽기 전용 플래그를 설정합니다. 페이지 실행 (메모리 페이지 덮어 쓰기)이 발생하면 1GB PTE가 2MB 및 4KB 페이지로 나뉩니다. VMware 엔지니어는 일반적으로 vMotion 프로세스 중에 VM이 모든 메모리를 건드리지 않는 것으로 나타났습니다. vMotion 중 메모리 작업 세트 크기는 일반적으로 10-30 %입니다. vMotion 시간 동안 더 많은 메모리를 사용하면 비용 효율성이 떨어집니다.

1. 전환 단계 향상

지금까지 논의한 모든 개선 사항은 추적이 발생하는 메모리 사전 복사 단계에서 수행됩니다. 메모리 수렴 단계에 도달하면 거의 모든 메모리가 대상 호스트에 복사되고 vMotion이 대상 ESXi 호스트로 전환 할 수 있습니다. 이 마지막 단계 에서 소스 ESXi 호스트의 VM이 일시 중단되고 검사 점 데이터가 대상 호스트로 전송됩니다 . 전환 시간 (Stun Time)은 1 초 이하가되어야합니다. 대규모 VM의 경우 시간이 지남에 따라 증가하는 워크로드 크기로 인해 이는 문제가되었습니다.

전환 단계에서는 검사 점 데이터와 메모리 비트 맵을 보냅니다. 메모리 비트 맵은 VM의 모든 메모리를 추적하는 데 사용됩니다. 어떤 페이지를 덮어 쓰고 대상 ESXi 호스트로 전송해야하는지 알고 있습니다. vMotion이 마지막 메모리 페이지를 전송함에 따라 대상 호스트의 VM 전원이 켜집니다. 그러나 전송을 위해 남은 마지막 페이지가 여전히 필요할 수 있습니다. 대상에서 이러한 페이지를 식별하기 위해 소스에서 전송 된 비트 맵을 사용합니다. 고객이 메모리를 초과 커밋하는 경우 스왑 아웃 페이지는 선택적 스왑 비트 맵에서 추적됩니다.

메모리 비트 맵이 드문 드문 나 있습니다. 여기에는 마지막 메모리 페이지와 VM에서 사용중인 모든 메모리 페이지의 정보가 포함됩니다. 1GB의 메모리가있는 VM의 메모리 비트 맵 크기는 32KB입니다. 32KB를 전송하는 데 밀리 초가 걸립니다 : 문제 없습니다!

이 단계에서는 대부분의 메모리 페이지를 이미 복사 했으므로 마지막으로 남은 메모리 페이지 만 보내면됩니다. vMotion은 압축 된 메모리 비트 맵을 사용하여 밀리 초 단위로 큰 VM에 대한 비트 맵을 전송하여 기절 시간을 크게 줄입니다.

결론

vSphere 7에서 vMotion 성능이 엄청나게 개선 되었습니다.

출처 : https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vmotion-enhancements.html