성능은 워크로드에서 필요한 리소스를 얻을 수 있도록 보장하는 것입니다. KPI(주요 성능 지표)를 사용하여 워크로드와 관련된 성능 문제를 식별할 수 있습니다. 이러한 KPI를 사용하여 서비스 계층과 연결된 SLA를 정의합니다. 이러한 대시보드는 KPI를 사용하여 소비자 계층에서 워크로드의 성능과 제공자 계층의 워크로드에 대한 집계 성능을 표시합니다.
SLA는 고객과 함께 보유하고 있는 공식적인 비즈니스 계약입니다. 일반적으로 SLA는 IaaS 제공자(인프라 팀)와 IaaS 고객(애플리케이션 팀 또는 사업부) 사이의 계약입니다. 공식 SLA에는 작업 변환이 필요합니다. 예를 들어 기술 변경 이상이 필요하며 계약, 가격(비용 아님), 프로세스 및 인력을 확인해야 할 수 있습니다. KPI는 SLA 메트릭과 조기 주의를 제공하는 추가 메트릭을 다룹니다. SLA가 없는 경우 내부 KPI로 시작합니다. IaaS의 실제 성능을 이해하고 프로파일링해야 합니다. 자체 임계값이 없는 경우 vRealize Operations 에서 기본 설정을 사용합니다. 이러한 임계값은 선제적인 작업을 지원하기 위해 선택되었기 때문입니다.
성능 관리의 3가지 프로세스
- 계획 성능 목표를 설정합니다. vSAN을 설계할 때는 원하는 디스크 지연 시간(밀리초)을 알고 있어야 합니다. VM 수준(vSAN 수준이 아님)에서 측정된 10밀리초는 좋은 시작입니다.
- 모니터링 계획을 실제와 비교합니다. 실제와 아키텍처가 제공해야 하는 항목이 일치합니까? 그렇지 않은 경우 수정해야 합니다.
- 문제 해결 실제가 계획과 맞지 않을 경우 문제 및 불만을 기다리지 않고 선제적으로 수정해야 합니다.
- 경합: 이것이 기본 지표입니다.
- 구성: 버전 비호환성을 확인합니다.
- 가용성: 소프트 오류, vMotion 스턴 시간, 잠금을 확인합니다. 여기에는 Log Insight가 필요합니다.
- 활용률: 마지막으로 이것을 확인합니다. 처음 3개의 매개 변수가 양호하면 이를 건너뛸 수 있습니다.
성능 관리의 세 가지 계층
엔터프라이즈 애플리케이션의 주요 영역에는 세 가지가 있습니다. 이러한 각 영역에는 고유한 팀 집합이 있습니다. 각 팀은 고유한 책임 집합을 가지고 있으며 연결된 기술 집합이 필요합니다. 세 가지 영역은 비즈니스, 애플리케이션 및 IaaS로 구성됩니다. 아래 그래픽을 참조하면 세 가지 계층과 각 계층에 대해 일반적으로 궁금한 사항을 이해할 수 있습니다. 
성능 관리는 주로 배제법 방식으로 실행됩니다. 방법론은 각 계층을 나누고 해당 계층에 성능 문제가 발생하는지 확인합니다. 따라서 특정 계층의 성능이 정상인지 여부를 나타내는 단일 메트릭이 있어야 합니다. 이 기본 메트릭의 이름은 KPI(주요 성능 지표)입니다.
상위 계층은 그 아래 계층에 따라 다르므로 경합의 소스는 일반적으로 인프라 계층입니다. 결과적으로 상위 계층의 기초가 되는 맨 아래 계층에 먼저 초점을 맞춥니다. 이 계층은 일반적으로 실행 중인 비즈니스 애플리케이션에 관계없이 일반 인프라 서비스 집합을 제공하는 가로 계층입니다.
성능 관리의 두 가지 메트릭
성능에 대한 기본 카운터는 경합입니다. 활용률이 높을 때 문제가 발생할 수 있다는 우려 때문에 활용률을 가장 많이 확인합니다. 이러한 문제가 바로 경합입니다. 경합 매니페스트는 대기열, 지연 시간, 삭제됨, 취소됨 및 컨텍스트 스위치와 같은 다양한 형식으로 되어 있습니다.
그러나 초고활용률 표시기를 성능 문제로 혼동하지 마십시오. ESXi 호스트가 벌루닝, 압축 및 스와핑을 경험하는 경우 VM에 성능 문제가 있음을 의미하지 않습니다. 호스트의 VM 지원 정도로 호스트의 성능을 측정합니다. 성능은 ESXi 호스트 활용률과 관련되어 있지만 성능 메트릭은 활용률을 기반으로 하지 않고, 대신 경합 메트릭을 기반으로 합니다.
| 인프라 구성 | VM 및 게스트 OS 구성 |
|---|---|
ESXi 설정
|
VM: 제한, 공유 및 예약
|
네트워크
|
크기: NUMA 효과. NUMA 노드에 걸쳐 있는 VM. |
클러스터 설정
|
스냅샷. IO가 2배로 처리됩니다. VM 드라이버. |
vSAN
|
Windows 또는 Linux 프로세스 핑퐁, 프로세스 런어웨이 및 OS 수준 대기열. |
성능 관리 관점에서 vSphere 클러스터는 리소스의 가장 작은 논리적 구축 블록입니다. 리소스 풀 및 VM 호스트 선호도는 더 작은 조각을 제공할 수 있지만, 운영면에서 복잡하며 IaaS 서비스의 약속된 품질을 제공할 수 없습니다. 리소스 풀은 구별된 서비스 클래스를 제공할 수 없습니다. 예를 들어, SLA는 골드가 200% 더 청구되기 때문에 실버보다 두 배 더 빠르다고 명시합니다. 리소스 풀은 골드에 두 배 더 많은 공유를 제공할 수 있습니다. 해당 추가 공유가 CPU 준비의 절반으로 해석되는지 여부는 솔직히 확인할 수 없습니다.
VM 성능
KPI 카운터가 일부 사용자를 위해 기술적으로 될 수 있으므로 vRealize Operations는 시작하도록 하기 위해 시작 줄을 포함합니다. 환경을 프로파일링한 후에는 임계값을 조정할 수 있습니다. 대부분의 고객에게는 기준선이 없으므로 이 프로파일링은 좋은 연습이 될 수 있습니다. 프로파일링을 사용하려면 Advanced 버전이 필요합니다.
성능 메트릭
| IaaS | VM 카운터 | 임계값 |
|---|---|---|
| CPU | 준비 | 2.5% |
| RAM | 경합 | 1% |
| 디스크 | 지연 시간 | 10ms |
| 네트워크 | TX 손실 패킷 | 0 |
이 표는 엄격한 임계값의 예입니다. 인프라 팀의 소비에 대한 내부 KPI이기 때문에 성능에 대한 높은 표준이 사용됩니다. 고객에게 확인된 외부 공식 SLA가 아닙니다. 운영 팀에서 조기 경고를 수신하고 외부 SLA 위반이 발생하기 전에 대응할 시간을 갖도록 내부 KPI와 외부 SLA 사이에 버퍼가 있어야 합니다. 높은 표준은 개발 환경에 대한 미션 크리티컬한 관점에서도 작동합니다. 최저한도의 성능을 가진 환경으로 표준을 설정하면 더 중요한 개발에 적용할 수 없습니다.
단일 임계값은 작업을 단순하게 유지하기 위해 사용됩니다. 이것은 운영 환경의 성능 점수가 개발 환경보다 더 높아야 한다는 것을 의미합니다. 개발 환경 성능은 운영 환경보다는 낮을 것으로 예상되지만 나머지는 모두 동일합니다. 단일 임계값은 다른 서비스 등급에서 제공하는 QoS(서비스 품질)의 차이를 설명하는 데 도움이 됩니다. 예를 들어 요금을 적게 지불하면 저하된 성능을 기대할 수밖에 없고 가격의 절반을 지불하면 절반의 성능을 얻게 됩니다.
표에 언급된 대로 IaaS의 4가지 요소(CPU, RAM, 디스크 및 네트워크)는 모든 수집 주기에서 평가됩니다. 수집 시간은 5분으로 설정됩니다. 모니터링에 적절한 시간이기 때문입니다. SLA가 1분을 기반으로 하는 경우 간격이 너무 좁아 비용이 증가하거나 임계값이 감소하게 됩니다.
설계 시 고려 사항
모든 성능 대시보드는 동일한 설계 원리를 공유합니다. 동일한 목표가 있다고 간주되는 각 대시보드가 서로 다르게 표시되는 경우에는 혼동을 야기하기 때문에 의도적으로 유사한 방식으로 설계되었습니다.
대시보드는 별도의 두 섹션(요약 및 세부 정보)으로 설계되었습니다.
- 요약 섹션은 일반적으로 대시보드 위쪽에 배치되어 전반적인 그림을 제공합니다.
- 세부 정보 섹션은 요약 섹션 아래에 배치됩니다. 이를 통해 특정 개체로 드릴다운할 수 있습니다. 예를 들어 특정 VM에 대한 자세한 성능 보고서를 얻을 수 있습니다.
세부 정보 섹션에서 빠른 컨텍스트 스위치를 사용하여 성능 문제 해결 중 여러 개체의 성능을 확인합니다. 예를 들어 VM 성능을 확인하는 경우 화면을 변경하지 않고 VM 관련 정보 및 KPI를 볼 수 있습니다. 여러 창을 열지 않고도 한 VM에서 다른 VM으로 이동하여 세부 정보를 볼 수 있습니다.
대시보드는 점진적 노출을 사용하여 정보 과부하를 최소화하고 웹페이지가 빠르게 로드되도록 합니다. 또한 브라우저 세션이 계속되면 인터페이스는 마지막 선택을 기억합니다.
이러한 작업 요소 간에 공유되는 공통점이 있으므로 대부분의 성능 및 용량 대시보드가 유사한 레이아웃을 공유합니다.
