성능은 워크로드에서 필요한 리소스를 확보하도록 보장하는 것이며 성능 관리는 주로 제거를 위한 실행에 관한 것입니다. 방법론은 각 계층을 나누고 해당 계층에 성능 문제가 발생하는지 확인합니다. 이를 위해서는 특정 계층의 수행 여부를 나타낼 수 있는 단일 메트릭이 있어야 합니다. 이 기본 메트릭의 이름은 KPI(주요 성능 지표)입니다.
디스크 지연 시간과 같은 각 메트릭에는 녹색, 노란색, 주황색 및 빨간색의 4가지 범위가 있습니다.
범위는 쉽게 모니터링할 수 있도록 0-100%로 매핑되어 있습니다. 녹색은 75–100%로, 빨간색은 0 -25%로 매핑됩니다. 100%를 4개의 동일 범위로 나누면 각 범위가 적정 크기의 밴드를 가질 수 있습니다.
위의 기술을 통해 다른 단위를 사용하는 메트릭을 결합할 수 있습니다. 각 항목은 동일한 밴드(백분율)에 매핑됩니다.
메트릭을 4개의 범위에 올바르게 매핑하려면 논리적으로 4개가 아닌 5개의 메트릭이 필요합니다. 디스크 지연 시간을 예로 들어 설명해 보겠습니다.
-
지연 시간이 41ms이면 빨간색의 상한이 40ms이므로 0%(즉, 빨간색)가 됩니다.
-
지연 시간이 35ms이면 경우 이것은 30ms와 40ms의 중간이므로 12.5%가 되고 빨간색이 됩니다.
-
지연 시간이 30ms이면 이것은 빨간색과 주황색의 경계이므로 25%가 됩니다.
각 메트릭이 0–100% 범위로 변환되면 피크가 아닌 평균을 사용하여 KPI 메트릭을 도출합니다. 평균을 사용하는 이유는 어떤 메트릭도 KPI 값을 지배하지 않도록 하기 위해서입니다. 특정 메트릭이 작업에 중요한 경우 해당 메트릭에 대해 경고를 사용할 수 있습니다. 평균을 사용하는 경우 각 메트릭이 동일하게 설명되므로 실재를 반영할 수 있습니다.
이러한 대시보드는 KPI를 사용하여 소비자 계층에서 Horizon 세션의 성능을 표시하고 Horizon 인프라 계층에서 워크로드의 집계 성능을 표시합니다. 이러한 대시보드는 Horizon 설계자 또는 수석 관리자를 위해 설계되었습니다. 이 대시보드는 Desktop as a Service의 데이터 센터 부분에 대한 전반적인 성능을 제공합니다.
성능 관리 관점에서의 Horizon
성능 모니터링 및 문제 해결을 위해, Horizon은 클라이언트가 WAN 네트워크를 통해 작업하는 클라이언트/서버 아키텍처와 유사합니다. 네트워크 및 데이터 센터 구성 요소는 서로 독립적이며 서로 다른 메트릭 집합을 사용하고 자체적으로 엔티티로 모니터링되어야 합니다. 자체적인 업데이트 적용 작업 집합이 있습니다. 대기업에서는 별도의 팀이 네트워크를 소유합니다.
이 경우 Management Pack for Horizon은 개별적인 모니터링을 통해 KPI를 제공합니다.
클라이언트 구성 요소는 기본적으로 텔레비전처럼 작동하므로 성능 모니터링의 마지막 초점입니다. 이는 전송된 픽셀을 표시하고 단순 입력을 수락합니다. 또한 클라이언트 문제는 분리되는 경향이 있습니다. 그러나 네트워크 및 데이터 센터 운영 중단은 많은 사용자에게 영향을 줄 수 있습니다.
성능 문제 해결의 세 가지 프로세스
성능 관리의 세 가지 고유 프로세스는 다음과 같습니다.
-
계획. 여기에서 성능 목표를 설정합니다. vSAN을 설계할 때 염두에 두었던 디스크 지연 시간은 몇 밀리초입니까? VM 수준(vSAN 수준이 아님)에서 측정했을 때 10밀리초로 시작하는 것이 좋습니다.
-
모니터링. 여기에서 계획과 실제를 비교합니다. 실제와 아키텍처가 제공해야 하는 항목이 일치합니까? 그렇지 않다면 수정해야 합니다.
-
문제 해결. 불만이 있을 때가 아니라 현실이 계획보다 더 나쁠 때 수행합니다. 문제 해결에는 많은 시간이 걸릴 수 있으므로 사전 예방적으로 수행하는 것이 가장 좋습니다.
성능 관리의 두 가지 메트릭
성능에 대한 기본 카운터는 경합입니다. 대부분의 고객은 활용률이 높을 때 문제가 발생하는 것을 걱정하기 때문에 활용률을 확인합니다. 그러한 문제가 바로 경합입니다. 경합은 여러 가지 형태로 나타납니다. 경합은 대기열, 지연 시간, 삭제, 중단 또는 컨텍스트 전환으로 나타날 수 있습니다.
매우 높은 활용률 지표를 성능 문제로 혼동하지 마십시오. ESXi 호스트에서 벌루닝, 압축 및 스와핑이 발생한다고 해서 VM에 메모리 성능 문제가 있는 것은 아닙니다. 호스트의 VM 지원 정도로 호스트의 성능을 측정합니다. ESXi 활용률과 관련이 있지만 성능 메트릭은 활용률을 기반으로 하는 것이 아니라 경합 메트릭을 기반으로 합니다.
클러스터 활용률이 낮은데도 클러스터의 VM 성능이 저하될 수 있습니다. 한 가지 주요한 이유는 클러스터 활용률은 제공자 계층(ESXi)을 확인하는 반면, 성능은 개별 소비자(VM)를 확인하기 때문입니다.
성능 관리 관점에서 vSphere 클러스터는 리소스의 가장 작은 논리적 빌딩 블록입니다. 리소스 풀 및 VM 호스트 선호도는 더 작은 조각을 제공할 수 있지만, 운영면에서 복잡하며 IaaS 서비스의 약속된 품질을 제공할 수 없습니다. 리소스 풀은 차별화된 서비스 클래스를 제공할 수 없습니다. 예를 들어, SLA는 프리미엄 데스크톱이 일반 데스크톱보다 200% 더 청구되기 때문에 속도도 두 배 더 빠르다고 명시합니다. 리소스 풀은 프리미엄 데스크톱에 두 배 더 많은 공유를 제공할 수 있습니다. CPU 준비의 절반으로 해석되는 추가 공유는 미리 확인할 수 없습니다.
깊이와 범위
사전 예방적인 모니터링을 수행하려면 여러 각도에서 인사이트가 필요합니다. 사용자에게 성능 문제가 발생한 경우에는 다음과 같은 질문을 해야 합니다.
-
상황이 얼마나 심각합니까? 문제의 깊이를 측정하려고 합니다.
-
얼마나 많은 사용자가 영향을 받고 있습니까? 문제의 범위를 측정하려고 합니다.
두 번째 질문의 답은 문제 해결 과정에 영향을 미칩니다. 고립적 사건입니까? 아니면 광범위한 문제입니까? 고립적 사건이라면 영향을 받는 개체를 보다 긴밀하게 확인합니다. 광범위한 문제라면 영향을 받는 개체 간에 공유되는 공통 영역(예: 클러스터, 데이터스토어, 리소스 풀, 호스트)을 확인합니다.
평균 성능에 대해 묻지 않았음을 눈치채셨나요? 이 경우 평균을 고려하는 것은 너무 늦었습니다. 평균 성능이 좋지 않은 시점에는 대상 사용자의 절반 정도가 영향을 받고 있을 수 있습니다.
멤버 수가 많으면 Percentage()보다는 Count()가 적합합니다. 예를 들어 사용자가 10만 명인 VDI 환경에서 5명의 사용자가 영향을 받는다면 0.005%입니다. 실제 사람 수로 변환되므로 count를 사용하여 모니터링하는 것이 더 쉽습니다.
전체 흐름
Management Pack for Horizon 대시보드는 분리하여 설계되지 않았습니다. 흐름을 형성하고 드릴다운할 때 컨텍스트를 전달합니다. 다음 예는 조감도에서 세션을 지원하는 기본 VM으로 드릴다운하는 방법을 보여 줍니다. 첫 번째 대시보드는 Horizon 환경의 모든 포드를 포함합니다. 여기서 RDS 팜 또는 VDI 풀로 드릴다운할 수 있습니다. 각 분기 내에서 개별 세션으로 드릴다운할 수 있습니다.
설계 시 고려 사항
모든 성능 대시보드는 동일한 설계 원리를 공유합니다. 각 대시보드가 서로 다르게 보일 경우 혼동을 야기하기 때문에 의도적으로 유사한 방식으로 설계되었습니다. 대시보드의 목표는 동일합니다.
대시보드는 요약 및 세부 정보 섹션과 함께 하향식으로 설계되었습니다.
-
요약 섹션은 일반적으로 대시보드의 상단에 배치되며 더 큰 그림을 제공합니다.
-
세부 정보 섹션은 요약 섹션 아래에 배치됩니다. 이를 통해 특정 개체로 드릴다운할 수 있습니다. 예를 들어 VM 성능에 관한 것이라면 특정 VM의 성능 세부 정보를 얻을 수 있습니다.
이 세부 정보 섹션은 빠른 컨텍스트 전환으로도 설계되었습니다. 성능 문제 해결 중에 여러 개체의 성능을 확인할 수 있기 때문입니다. 예를 들어, RDS 호스트 성능 대시보드는 모든 RDS 호스트 관련 정보를 제공하며 화면을 변경하지 않고도 KPI를 볼 수 있습니다. 여러 창을 열지 않고도 한 RDS 호스트에서 다른 RDS 호스트로 이동하여 세부 정보를 볼 수 있습니다.
사용자 인터페이스 측면에서, 대시보드는 점진적 노출을 사용하여 정보 과부하를 최소화하고 웹 페이지가 빠르게 로드되도록 합니다. 브라우저 세션은 활성 상태를 유지하는 동안 마지막으로 선택한 내용을 기억합니다.
색상의 의미
대시보드는 색상을 사용하여 다양한 임계값이 사용되는 의미를 전달합니다.
| 카운터 | 사용된 임계값 |
|---|---|
| KPI | 녹색: 75% - 100% 노란색: 50% - 75% 주황색: 25% - 50% 빨간색: 0% - 25% 따라서 임계값 집합은 25%, 50% 및 75%입니다. |
| 빨간색 항목의 수입니다. 예를 들어 빨간색 KPI가 포함된 VDI 세션의 수입니다. |
KPI 값이 빨간색 범위에 속하는 VDI 세션이 없어야 하므로 이 값은 항상 0이 되어야 합니다. 따라서 임계값 집합은 1, 2, 3입니다. 개수가 1일 때 빨간색이 나타나도록 하려면 0.1, 0.2 또는 1로 설정할 수 있습니다. |
녹색 영역(75%-100%)에 표시될 숫자를 예상하십시오. 평균값은 100%가 아닐 수 있지만 해당 숫자가 녹색 범위에 오는 것을 목표로 하십시오.
통찰력으로서의 테이블
테이블은 각 행이 개체를 나타내고 각 열이 단일 값을 표시하는 단순한 목록입니다. 여기에는 필터링 및 정렬이 가능한 수백 개의 행이 나열되어 있습니다. 각 셀 값을 색상으로 구분할 수도 있습니다.
테이블은 세부 정보를 얻는 데 유용합니다. 하지만 각 셀에는 하나의 값만 포함될 수 있기 때문에 이것이 시간 경과에 따른 통찰력을 제공할 수 있는지가 주요 문제입니다. 과거에 발생한 사건에 대한 통찰력을 제공하는 방법은 무엇입니까? 예를 들어 지난 1주 동안 성능을 확인하는 방법은 무엇입니까? 지난 7일 동안 수천 개의 데이터 지점이 있습니다. 어떤 데이터 지점을 선택하시겠습니까?
vRealize Operations Cloud 8.2에는 몇 가지 가능한 옵션이 있습니다.
-
현재 숫자입니다. 이것은 현재 상황을 표시하는 데 유용합니다. 그러나 5분 전에 발생한 사건은 표시하지 않습니다.
-
기간의 평균입니다. 평균은 후행 지표입니다. 평균 성능이 좋지 않은 시점에는 전체의 약 50%가 양호하지 않을 가능성이 있습니다.
-
기간의 최악입니다. 이것은 하나의 피크만 고려하기 때문에 너무 극단적일 수 있습니다. 일부 경우 수백 개의 데이터 지점 중 하나만 이상일 수 있습니다. 피크를 감지하는 데에는 좋지만 보완이 필요합니다.
-
95번째 백분위 수입니다. 이것은 평균과 최악 사이의 적절한 중간점입니다. 성능 모니터링의 경우 95번째 백분위 수는 평균보다 더 나은 요약을 제공합니다.
95번째 백분위 수부터 시작하여 최악 및 95번째 백분위 수 숫자를 함께 사용합니다. 숫자가 멀리 떨어져 있다면 최악이 이상치일 수 있음을 나타냅니다.
더 나은 가시성을 위해 98번째 백분위 수를 추가하여 95번째 백분위 수와 최악을 보완하는 것을 고려하십시오.
통찰력으로서의 막대형 차트
분포 차트는 다양한 형태로 제공되며 막대형 차트는 그 중 가장 친숙한 것 중 하나입니다. 이를 사용하여 큰 데이터 집합에 대한 인사이트를 제공할 수 있습니다. 예를 들어 vSphere 공유 데이터스토어는 남은 용량으로 표시되는데, 남은 용량이 가장 작은 것부터 가장 많은 것까지 5개의 버킷으로 분류됩니다. 각 버킷에는 의미를 전달하기 위한 색상이 지정됩니다. 80%를 초과하는 용량은 회색으로 지정됩니다. 사용되지 않은 용량이 많으면 리소스가 낭비되고 있음을 나타냅니다.
