Hyperflex 클러스터의 성능 문제 해결
목차
소개
이 문서에서는 VM(Guest Virtual Machine), ESXi 호스트, SCVM(Guest Virtual Machine)의 관점에서 Hyperflex 환경의 성능에 미치는 영향에 대해 설명합니다
식별
Hyperflex 환경에서 성능 문제를 해결하려면 클러스터의 유형, 성능이 저하되는 작업, 성능 저하의 빈도 및 성능 저하의 원인이 되는 성능 영향 수준을 파악하는 것이 중요합니다.
게스트 VM, ESXI 호스트 레벨, 스토리지 컨트롤러 VM 레벨의 hyperflex 클러스터에는 여러 가지 영향 레벨이 있습니다.
클러스터 유형
● 하이브리드 노드: 캐싱에는 SSD(Solid State Drive) 드라이브를 사용하고 용량 레이어에는 HDD를 사용합니다.
● All-flash node: 캐싱에는 SSD 드라이브 또는 NVMe(Non-Volatile Memory Express) 스토리지를 사용하고, 용량 레이어에는 SSD 드라이브를 사용합니다.
● All-NVMe 노드: 캐싱에 NVMe 스토리지를 사용하고, 용량 레이어 all-NVMe 노드는 캐싱으로 가장 까다로운 워크로드에 가장 높은 성능을 제공합니다
성능 차트 설명
Hyperflex 시스템에는 성능을 모니터링하는 기능이 있으며, 차트에는 스토리지 클러스터의 읽기 및 쓰기 성능이 표시됩니다.
IOPS
IOPS(Input/Output Operations per second)는 HDD를 비롯한 컴퓨터 저장 장치를 측정하는 데 사용되는 일반적인 성능 메트릭입니다. 이 메트릭은 임의 I/O 워크로드의 성능을 평가하는 데 사용됩니다.
IOPS 성능 차트
처리량
이 그림에서는 스토리지 클러스터의 데이터 전송 속도(Mbps)를 보여줍니다.
처리량 성능 차트.
대기 시간
레이턴시는 단일 I/O 요청이 완료되는 데 걸리는 시간을 나타냅니다. 요청을 발행하고 응답을 수신하는 동안의 기간이며, 밀리초 단위로 측정됩니다.
대기 시간 성능 차트.
빈도
환경에 미칠 수 있는 영향을 검토하려면 성능 영향의 빈도와 기간을 정의하는 것이 중요합니다.
성능이 항상 영향을 받는 경우 성능이 저하되기 시작한 위치를 확인하고 클러스터 간의 컨피그레이션 변경 또는 문제를 확인해야 합니다.
성능에 간헐적으로 영향을 미치는 경우, 해당 시간에 실행 중인 작업 또는 서비스가 있는지 확인해야 합니다.
외부 요인
클러스터의 성능은 스냅샷 및 백업 작업과 같은 외부 요인의 영향을 받을 수 있습니다.
외부 요인에 대한 자세한 내용은 다음 링크를 참조하십시오.
VMware vSphere 스냅샷: 성능 및 모범 사례.
Cisco HyperFlex Systems 및 Veeam 백업 및 복제 백서
게스트 VM 레벨에서 성능 문제 파악
이는 hyperflex 환경에서 가장 가시적인 영향 수준이며 VM이 제공하는 서비스에 직접 영향을 미치며 직접 영향을 받는 사용자에게는 더욱 분명합니다.
다음은 일반적인 운영 체제의 성능을 확인하는 일반적인 테스트입니다.
창
Windows 게스트 VM의 성능 문제를 파악하기 위해 사용 가능한 툴을 검토합니다.
ESXi
성능 영향을 파악하고 성능 저하의 가능한 원인을 검토한 후 성능 향상을 위해 몇 가지 성능 점검을 실시합니다.
- 오버프로비저닝을 확인합니다(모든 VM에 할당된 총 vCPU 수가 ESXi 호스트 시스템에서 사용 가능한 총 물리적 코어 수를 초과해서는 안 됨).
- 게스트 OS에서 일부 vCPU를 사용하지 않더라도 해당 vCPU를 사용하여 VM을 구성하면 ESXi에 일부 소규모 리소스 요구 사항이 부과되며, 이는 호스트의 실제 CPU 소비로 전환됩니다.
- 또한 메모리를 과도하게 할당하면 VM 메모리 오버헤드가 불필요하게 증가하며 특히 예약이 사용되는 경우 메모리 경합이 발생할 수 있습니다.
- Balloon 드라이버가 메모리에 대한 보류를 유지하지 않는지 확인합니다. 자세한 내용은 이 링크를 참조하십시오.
ESX/ESXi 가상 머신 성능 문제 해결을 검토합니다.
PVSCSI 확인
PVSCSI(Paravirtual SCSI) 어댑터는 디스크 IO 요구 사항이 높은 가상 시스템의 처리량을 높이고 CPU 사용률을 낮출 수 있는 고성능 스토리지 어댑터입니다. PVSCSI 어댑터를 사용하는 것이 좋습니다. PVSCSI 컨트롤러는 가장 낮은 CPU 오버헤드로 가장 낮은 레이턴시와 가장 높은 처리량을 허용하는 가상화 지원 고성능 SCSI 어댑터입니다.
PVSCSI 어댑터.
네트워크 어댑터 검사
VMXNET 3은 성능을 위해 설계된 반가상화 방식의 NIC로서, 점보 프레임, 멀티 큐 지원(Windows에서는 Receive Side Scaling이라고도 함), IPv6 오프로드, MSI/MSI-X 인터럽트 전달 및 하드웨어 오프로드와 같은 최신 네트워크에서 일반적으로 사용되는 고성능 기능을 제공합니다.
어댑터 유형이 VMXNET3인지 확인합니다.
네트워크 어댑터.
RSS 확인
참고: 이 확인은 Windows 운영 체제를 실행 중인 게스트 VM에만 적용됩니다.
RSS(Receive Side Scaling)는 멀티프로세서 시스템의 여러 CPU에 걸쳐 네트워크 수신 처리를 효율적으로 배포할 수 있도록 하는 네트워크 드라이버 기술입니다.
Windows 서버에는 여러 CPU에 커널 모드 네트워크 처리 로드를 분산할 수 있는 드라이버 구성이 있습니다.
활성화되었는지 확인하고 Windows PowerShell에서 다음 명령을 실행합니다.
netsh interface tcp set global rss=enabledRSS를 사용하려면 이 링크를 검토하십시오.
CPU 핫 플러그 검사
CPU 핫플러그는 VM 관리자가 전원을 끄지 않고도 VM에 CPU를 추가할 수 있는 기능입니다. 이를 통해 서비스 중단 없이 CPU 리소스를 즉석에서 추가할 수 있습니다. VM에서 CPU 핫플러그가 활성화되면 vNUMA 기능이 비활성화됩니다.
CPU 핫 플러그가 비활성화되었습니다.
공통 운영 체제 및 애플리케이션에 대한 모범 사례를 검토합니다.
창.
Windows Server 2022의 성능 튜닝 지침.
레드햇
우선 순위 및 선호도를 통해 Linux 프로세스 성능 향상에 대한 3가지 팁.
SQL Server입니다.
VMware에서 Microsoft SQL Server 설계
레드햇
호스트 레벨에서 성능 문제 파악
호스트 레벨에서 성능에 미치는 영향을 파악하기 위해 ESXI 호스트가 ESXI 하이퍼바이저에 내장된 성능 차트를 검토하고 영향을 받는 호스트의 수를 확인할 수 있습니다.
vCenter의 성능 차트를 보려면 모니터 탭에서 성능 탭을 클릭합니다.
vCenter 성능 차트
이 차트에서 CPU, 메모리 및 디스크와 관련된 성능 차트를 볼 수 있습니다. 차트를 이해하려면 이 링크를 참조하십시오.
참고: 특히 스토리지 네트워크에서 CRC 오류 및 MTU 불일치가 발생하면 레이턴시 문제가 발생합니다. 스토리지 트래픽은 점보 프레임을 사용해야 합니다.
스토리지 I/O 제어 및 대기열 길이 검사
SIOC(Storage I/O Control)는 가상 시스템의 I/O 사용을 제어하고 사전 정의된 I/O 공유 레벨을 점진적으로 적용하는 데 사용되며 Hyperflex 클러스터에서 이 기능을 비활성화하는 데 필요합니다.
Queue depth는 저장소 리소스가 한 번에 처리할 수 있는 보류 중인 I/O(입력/출력) 요청 수입니다.
다음 단계를 사용하여 SIOC가 비활성화되어 있고 대기열 길이 컨피그레이션이 비활성화되어 있는지 확인할 수 있습니다.
SIOC가 ESXi 및 Queue Depth Configuration에서 실행 중인지 확인합니다
1단계. HX ESXi 호스트에 SSH를 연결하고 명령을 실행하여 데이터 저장소를 나열합니다.
[root@] vsish -e ls /vmkModules/nfsclient/mnt
encrypted_app/
Prod/ <----- Datastore name
Dev/
App/2단계. 데이터 저장소 이름을 사용하고 명령을 실행합니다.
vsish -e get /vmkModules/nfsclient/mnt/
/properties [root@] vsish -e get /vmkModules/nfsclient/mnt/Prod/properties mount point information { volume name:Prod server name:7938514614702552636-8713662604223381594 server IP:127.0.0.1 server volume:172.16.3.2:Prod UUID:63dee313-dfecdf62 client src port:641 busy:0 socketSendSize:1048576 socketReceiveSize:1048576 maxReadTransferSize:65536 maxWriteTransferSize:65536 reads:0 readsFailed:0 writes:285 writesFailed:0 readBytes:0 writeBytes:10705 readTime:0 writeTime:4778777 readSplitsIssued:0 writeSplitsIssued:285 readIssueTime:0 writeIssueTime:4766494 cancels:0 totalReqsQueued:0 metadataReqsQueued(non IO):0 reqsInFlight:0 readOnly:0 hidden:0 isPE:0 isMounted:1 isAccessible:1 unstableWrites:0 unstableNoCommit:0 maxQDepth:1024 <-------- Max Qdepth configuration iormState:0 <-------- I/O control disabled latencyThreshold:30 shares:52000 podID:0 iormInfo:0 NFS operational state: 0 -> Up enableDnlc:1 closeToOpenCache:0 highToAvgLatRatio:10 latMovingAvgSmoothingLevel:2 activeWorlds:55 inPreUnmount:0 }
3단계. 출력에서 행을 찾습니다.
iormState:0 0= disabled 2= enabledmaxQDepth 선은 1024여야 합니다.
4단계. 나머지 데이터 저장소에 대해서도 동일한 단계를 반복해야 합니다
SIOC 비활성화
SIOC를 비활성화하려면 다음 단계를 실행합니다.
1단계. HTML 클라이언트를 사용하여 vsphere에 로그인합니다.
2단계. 드롭다운 메뉴에서 Storage(스토리지)를 선택한 다음 왼쪽 창에서 해당 HX Datastore(HX 데이터 저장소)를 선택합니다.
데이터 저장소를 선택합니다.
3단계. 데이터 저장소의 오른쪽 창 상단 섹션에서 구성 탭을 선택합니다.
구성 탭
4단계. 오른쪽 창 가운데 섹션의 자세에서 일반을 선택하고 오른쪽에서 데이터 저장소 기능으로 스크롤한 다음 편집을 클릭합니다
데이터 저장소 기능을 편집합니다.
Disable Storage I/O Control and Statistics collection(스토리지 I/O 제어 및 통계 수집 비활성화) 라디오 버튼이 선택되지 않은 경우 선택합니다.
스토리지 I/O 제어를 비활성화합니다.
Disable Storage I/O Control and statistics collection(스토리지 I/O 제어 및 통계 수집 비활성화) 라디오 버튼을 선택한 경우 Enable Storage I/O Control and statistics collection(스토리지 I/O 제어 및 통계 수집 활성화)과 Disable Storage I/O Control and statistics collection(스토리지 I/O 제어 및 통계 수집 비활성화) 사이를 전환합니다.
스토리지 I/O 제어가 비활성화되었습니다.
5단계. 다른 모든 데이터 저장소에 대해 필요에 따라 1~4단계를 반복합니다.
MaxQDepth 수정
maxQDepth를 수정하려면 각 데이터 저장소에 대해 다음 명령을 실행합니다.
vsish -e set /vmkModules/nfsclient/mnt/
/properties maxQDepth 1024
Rx_no_Buff 확인
네트워크 트래픽이 많은 Hyperflex 서버 또는 마이크로버스트가 있는 네트워크 트래픽은 rx_no_bufs의 형태로 나타나는 패킷 손실로 이어질 수 있습니다.
이 문제를 확인하려면 ESXi 호스트에서 다음 명령을 실행하여 rx_no_buf 카운터를 확인합니다.
/usr/lib/vmware/vm-support/bin/nicinfo.sh | egrep "^NIC:|rx_no_buf"
NIC: vmnic0
rx_no_bufs: 1
NIC: vmnic1
rx_no_bufs: 2
NIC: vmnic2
rx_no_bufs: 2
NIC: vmnic3
rx_no_bufs: 71128211 <---------Very high rx_no_bufs counter
NIC: vmnic4
rx_no_bufs: 1730
NIC: vmnic5
rx_no_bufs: 897
NIC: vmnic6
rx_no_bufs: 24952
NIC: vmnic7
rx_no_bufs: 2
몇 분 정도 기다린 후 명령을 다시 실행하고 rx_no_bufs 카운터가 증가하지 않는지 확인합니다.
- 이러한 카운터가 낮으면(< 1,000) 기본 대기열 구성으로 인한 패킷 손실이 거의 없으며 튜닝할 필요가 없습니다.
- 이 카운터가 높은 경우(>10,000) 이 대기열 컨피그레이션 및 튜닝으로 인해 약간의 영향이 있을 수 있습니다.
- 이러한 카운터가 매우 높으면(>1,000,000) 더 큰 영향을 미칠 수 있으므로 대기열을 늘리는 것이 좋습니다.
- rx_no_bufs가 활발하게 증가하는 경우, 이는 패킷이 네트워크를 통해 도달하여 가상화된 레이어에 도착하면 패킷이 삭제됩니다.
이 값에 대한 카운터가 표시되면 Cisco TAC에 문의하여 vNIC 컨피그레이션을 조정하여 더 나은 성능을 얻으십시오.
ESXI 레벨에서 모범 사례 및 추가 검사를 검토합니다.
SCVM(Storage Controller Virtual Machine) 레벨의 성능 문제 파악
클러스터 상태
클러스터가 정상인지 확인합니다.
hxshell:~$ sysmtool --ns cluster --cmd healthdetail
Cluster Health Detail:
---------------------:
State: ONLINE <---------- State of the cluster
HealthState: HEALTHY <---------- Health of the cluster
Policy Compliance: COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 19 hours, 45 mins, 51 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is healthy.
# of nodes failure tolerable for cluster to be fully available: 1
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 3
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 2
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 3
# of caching devices failures tolerable for cluster to be fully available: 2
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 3
Current ensemble size: 3
Minimum data copies available for some user data: 3
Minimum cache copies remaining: 3
Minimum metadata copies available for cluster metadata: 3
Current healing status:
Time remaining before current healing operation finishes:
# of unavailable nodes: 0
hxshell:~$
이 출력은 사용할 수 없는 노드로 인해 비정상 클러스터를 표시합니다.
hxshell:~$ sysmtool --ns cluster --cmd healthdetail
Cluster Health Detail:
---------------------:
State: ONLINE <-------State of the cluster
HealthState: UNHEALTHY <-------Health of the cluster
Policy Compliance: NON-COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 19 hours, 55 mins, 9 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is unhealthy.Storage node 172.16.3.9 is unavailable. <----------- Health state reason
# of nodes failure tolerable for cluster to be fully available: 0
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 2
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 1
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 2
# of caching devices failures tolerable for cluster to be fully available: 1
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 2
Current ensemble size: 3
Minimum data copies available for some user data: 2
Minimum cache copies remaining: 2
Minimum metadata copies available for cluster metadata: 2
Current healing status: Rebuilding/Healing is needed, but not in progress yet. Warning: Insufficient node or space resources may prevent healing. Storage Node 172.16.3.9 is either down or initializing disks.
Time remaining before current healing operation finishes:
# of unavailable nodes: 1
hxshell:~$
이 출력은 재구축으로 인한 비정상 클러스터를 표시합니다.
Cluster Health Detail:
---------------------:
State: ONLINE
HealthState: UNHEALTHY
Policy Compliance: NON-COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 20 hours, 2 mins, 4 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is unhealthy.
# of nodes failure tolerable for cluster to be fully available: 1
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 2
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 1
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 2
# of caching devices failures tolerable for cluster to be fully available: 1
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 2
Current ensemble size: 3
Minimum data copies available for some user data: 3
Minimum cache copies remaining: 2
Minimum metadata copies available for cluster metadata: 2
Current healing status: Rebuilding is in progress, 58% completed.
Time remaining before current healing operation finishes: 18 hr(s), 10 min(s), and 53 sec(s)
# of unavailable nodes: 0이러한 명령은 클러스터의 상태에 대한 전반적인 요약을 보여주며, 클러스터 운영에 영향을 주는 것이 있는지(예: 블랙리스트 디스크, 오프라인 노드 또는 클러스터가 복구되고 있는지) 알려줍니다.
I/O에 참여하는 노드
입력 및 출력 작업에 참여하지 않는 노드가 성능에 영향을 줄 수 있습니다. I/O에 참여하는 노드를 확인하려면 다음 명령을 실행하십시오.
1단계. 스토리지 컨트롤러 VM의 진단 셸에 입력합니다.
hxshell:~$ su diag
Password:
_ _ _ _ _ _____ _ ___
| \ | (_)_ __ ___ | || | | ___(_)_ _____ / _ \ _ __ ___
| \| | | '_ \ / _ \ _____ | || |_ _____ | |_ | \ \ / / _ \ _____ | | | | '_ \ / _ \
| |\ | | | | | __/ |_____| |__ _| |_____| | _| | |\ V / __/ |_____| | |_| | | | | __/
|_| \_|_|_| |_|\___| |_| |_| |_| \_/ \___| \___/|_| |_|\___|
Enter the output of above expression: -1
Valid captcha
2단계. 이 명령을 실행하여 I/O 작업에 참여하는 노드를 확인합니다. IP 수는 클러스터의 통합된 노드 수와 같아야 합니다.
diag# nfstool -- -m | cut -f2 | sort | uniq
172.16.3.7
172.16.3.8
172.16.3.9내부 서비스 검사
클리너
Cleaner의 주요 목적 중 하나는 시스템에서 죽은 저장 블록을 식별하고 죽은 저장 블록을 제거하여, 그들이 점유하는 저장 공간을 확보하는 것입니다. 백그라운드 작업이며, 공격성은 정책에 따라 설정됩니다.
다음 명령을 실행하여 더 깨끗한 서비스를 확인할 수 있습니다.
bash-4.2# stcli cleaner info
{ 'name': '172.16.3.7', 'id': '1f82077d-6702-214d-8814-e776ffc0f53c', 'type': 'node' }: OFFLINE <----------- Cleaner shows as offline
{ 'name': '172.16.3.8', 'id': 'c4a24480-e935-6942-93ee-987dc8e9b5d9', 'type': 'node' }: OFFLINE
{ 'name': '172.16.3.9', 'id': '50a5dc5d-c419-9c48-8914-d91a98d43fe7', 'type': 'node' }: OFFLINE
클리너 프로세스를 시작하려면 이 명령을 실행합니다.
bash-4.2# stcli cleaner start
WARNING: This command should be executed ONLY by Cisco TAC support as it may have very severe consequences. Do you want to proceed ? (y/n): y
bash-4.2# stcli cleaner info
{ 'type': 'node', 'id': '1f82077d-6702-214d-8814-e776ffc0f53c', 'name': '172.16.3.7' }: ONLINE
{ 'type': 'node', 'id': 'c4a24480-e935-6942-93ee-987dc8e9b5d9', 'name': '172.16.3.8' }: ONLINE
{ 'type': 'node', 'id': '50a5dc5d-c419-9c48-8914-d91a98d43fe7', 'name': '172.16.3.9' }: ONLINE <---------All nodes need to be online
bash-4.2# 
주의: 이 명령은 Cisco TAC 승인과 함께 실행해야 합니다.
리밸런스
스토리지 클러스터가 정기적으로 밸런싱됩니다. 사용 가능한 스토리지의 변경 사항 간에 저장된 데이터의 배포를 재정렬하고 스토리지 클러스터 상태를 복원하는 데 사용됩니다.
리밸런스는 여러 가지 이유로 클러스터에서 실행됩니다.
- 물리적 리소스(노드/디스크)가 중단되고 HX가 해당 Vnode를 클러스터의 다른 물리적 리소스로 재배치합니다.
- 클러스터 전체의 개별 드라이브가 모두 비교해서 활용되는 것은 아니므로 HX 클러스터 내에서 데이터 가용성 측면에서 일부 핫스팟이 생성되었습니다(데이터 취합).
- 클러스터가 정상인 경우에도 영역 규정준수가 없는 경우 리밸런스를 실행할 수 있습니다.
- 기존 클러스터에 새 노드가 추가되면 추가된 노드는 기존 클러스터에 조인하는 즉시 새 쓰기를 수행합니다.
클러스터의 리밸런스가 활성화되었는지 확인합니다.
hxshell:~$ stcli rebalance status
rebalanceStatus:
percentComplete: 0
rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True <---------Rebalance should be enabled
hxshell:~$
주의: 리밸런스와 관련된 모든 작업은 Cisco TAC 승인을 받아 수행해야 합니다.
디스크 오류
제대로 작동하려면 클러스터에 블랙리스트 디스크 또는 오프라인 리소스가 없어야 합니다.
HX Connect 인터페이스의 클러스터에 블랙리스트 디스크가 있는지 확인해야 합니다.
블랙리스트 디스크.
CLI에서 각 컨버전스 노드의 오프라인 리소스를 확인합니다.
sysmtool --ns cluster --cmd offlineresources
UUID Type State InUse Last modified
---- ---- ----- ----- -------------
000cca0b019b4a80:0000000000000000 DISK DELETED YES <------- Offline disk
5002538c405e0bd1:0000000000000000 DISK BLOCKLISTED NO <------- Blacklisted disk
5002538c405e299e:0000000000000000 DISK DELETED NO
Total offline resources: 3, Nodes: 0, Disks: 3블랙리스트 리소스가 있는지 확인합니다.
hxshell:~$ sysmtool --ns disk --cmd list | grep -i blacklist
Blacklist Count: 0
Blacklist Count: 0
Blacklist Count: 0
Blacklist Count: 0
State: BLACKLISTED
Blacklist Count: 5
Blacklist Count: 0
Blacklist Count: 0
이 명령을 사용하여 각 컨버전스 노드에 장애가 발생한 디스크가 있는지 확인해야 합니다.
admin:~$ cat /var/log/springpath/diskslotmap-v2.txt
0.0.1:5002538e000d59a3:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302248:HXT76F3Q:SATA:SSD:3662830:Inactive:/dev/sdj <---------Inactive disk
1.0.2:5002538c40be79ac:Samsung:SAMSUNG_MZ7LM240HMHQ-00003:S4EGNX0KC04551:GXT51F3Q:SATA:SSD:228936:Active:/dev/sdb
1.0.3:5002538e000d599e:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302243:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdc
1.0.4:5002538e000d59a0:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302245:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdd
1.0.5:5002538e000eb00b:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302480:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdi
1.0.6:5002538e000d599b:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302240:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdf
1.0.7:5002538e000d57f6:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M301819:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdh
1.0.8:5002538e000d59ab:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302256:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sde
1.0.9:5002538e000d59a1:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302246:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdg
1.0.10:5002538e0008c68f:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M200500:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdj
0.1.192:000cca0b01c83180:HGST:UCSC-NVMEHW-H1600:SDM000026904:KNCCD111:NVMe:SSD:1526185:Active:/dev/nvme0n1
admin:~$디스크 장애가 없는 노드의 예.
hxshell:~$ sysmtool --ns cluster --cmd offlineresources
No offline resources found <-------- No offline resources
hxshell:~$ sysmtool --ns disk --cmd list | grep -i blacklist
hxshell:~$ <-------- No blacklisted disks
hxshell:~$ cat /var/log/springpath/diskslotmap-v2.txt
1.14.1:55cd2e404c234bf9:Intel:INTEL_SSDSC2BX016T4K:BTHC618505B51P6PGN:G201CS01:SATA:SSD:1526185:Active:/dev/sdc
1.14.2:5000c5008547c543:SEAGATE:ST1200MM0088:Z4009D7Y0000R637KMU7:N0A4:SAS:10500:1144641:Active:/dev/sdd
1.14.3:5000c5008547be1b:SEAGATE:ST1200MM0088:Z4009G0B0000R635L4D3:N0A4:SAS:10500:1144641:Active:/dev/sde
1.14.4:5000c5008547ca6b:SEAGATE:ST1200MM0088:Z4009F9N0000R637JZRF:N0A4:SAS:10500:1144641:Active:/dev/sdf
1.14.5:5000c5008547b373:SEAGATE:ST1200MM0088:Z4009GPM0000R634ZJHB:N0A4:SAS:10500:1144641:Active:/dev/sdg
1.14.6:5000c500854310fb:SEAGATE:ST1200MM0088:Z4008XFJ0000R6374ZE8:N0A4:SAS:10500:1144641:Active:/dev/sdh
1.14.7:5000c50085424b53:SEAGATE:ST1200MM0088:Z4008D2S0000R635M4VF:N0A4:SAS:10500:1144641:Active:/dev/sdi
1.14.8:5000c5008547bcfb:SEAGATE:ST1200MM0088:Z4009G3W0000R637K1R8:N0A4:SAS:10500:1144641:Active:/dev/sdj
1.14.9:5000c50085479abf:SEAGATE:ST1200MM0088:Z4009J510000R637KL1V:N0A4:SAS:10500:1144641:Active:/dev/sdk
1.14.11:5000c5008547c2c7:SEAGATE:ST1200MM0088:Z4009FR00000R637JPEQ:N0A4:SAS:10500:1144641:Active:/dev/sdl
1.14.13:5000c5008547ba93:SEAGATE:ST1200MM0088:Z4009G8V0000R634ZKLX:N0A4:SAS:10500:1144641:Active:/dev/sdm
1.14.14:5000c5008547b69f:SEAGATE:ST1200MM0088:Z4009GG80000R637KM30:N0A4:SAS:10500:1144641:Active:/dev/sdn
1.14.15:5000c5008547b753:SEAGATE:ST1200MM0088:Z4009GH90000R635L5F6:N0A4:SAS:10500:1144641:Active:/dev/sdo
1.14.16:5000c5008547ab7b:SEAGATE:ST1200MM0088:Z4009H3P0000R634ZK8T:N0A4:SAS:10500:1144641:Active:/dev/sdp <------All disks are active
hxshell:~$
사용 가능한 메모리
이 명령을 사용하여 사용 가능한 메모리를 확인합니다. 사용 가능한 메모리는 2048MB(free +cache)를 초과해야 합니다.
hxshell:~$ free –m
total used free shared buff/cache available
Mem: 74225624 32194300 38893712 1672 3137612 41304336
Swap: 0 0 0
hxshell:~$ 여유 + 캐시 메모리가 2048 미만인 경우, 메모리 부족 상태를 생성하는 프로세스를 식별해야 합니다.
참고: top 명령을 사용하여 많은 메모리를 사용하는 프로세스를 식별할 수 있지만, 변경 사항은 TAC 승인을 통해 수행해야 합니다. Cisco TAC에 문의하여 OM 상태를 해결하십시오.
공간 조건의 끝
스토리지 클러스터 공간 활용의 모범 사례는 HX Connect 용량 보기에서 76%를 초과하지 않는 것입니다. HX Connect 용량 보기의 사용량이 76%를 넘어서면 성능이 저하됩니다.
스토리지 클러스터에서 ENOSPC 조건이 발생하면 클리너가 높은 우선 순위로 자동 실행되어 클러스터에 성능 문제가 발생할 수 있으며, 우선 순위는 클러스터 공간 사용량에 따라 결정됩니다.
스토리지 클러스터가 ENOSPC WARN 조건에 도달하면, 청소기는 ENOSPC 설정 조건으로 쓰레기를 수집하는 I/O 횟수를 늘림으로써 강도를 높이며, 가장 높은 우선순위로 실행됩니다.
이 명령을 사용하여 클러스터의 ENOSPCINFO 상태를 확인할 수 있습니다.
hxshell:~$ sysmtool --ns cluster --cmd enospcinfo
Cluster Space Details:
---------------------:
Cluster state: ONLINE
Health state: HEALTHY
Raw capacity: 42.57T
Usable capacity: 13.06T
Used capacity: 163.08G
Free capacity: 12.90T
Enospc state: ENOSPACE_CLEAR <--------End of space status
Space reclaimable: 0.00
Minimum free capacity
required to resume operation: 687.12G
Space required to clear
ENOSPC warning: 2.80T <--------Free space until the end of space warning appears
Rebalance In Progress: NO
Flusher in progress: NO
Cleaner in progress: YES
Disk Enospace: NO
hxshell:~$
Cisco HyperFlex 백서의 용량 관리를 검토하여 Hyperflex 클러스터의 공간을 관리하는 모범 사례를 확인하십시오.
성능 차트 트러블슈팅
hyperflex 성능 차트에서 정보를 표시하지 않는 경우도 있습니다.
Hyperflex 성능 차트
이 동작이 발생하면 통계 서비스가 클러스터에서 실행 중인지 검토해야 합니다.
hxshell:~$ priv service carbon-cache status
carbon-cache stop/waiting
hxshell:~$ priv service carbon-aggregator status
carbon-aggregator stop/waiting
hxshell:~$ priv service statsd status
statsd stop/waiting
프로세스가 실행되고 있지 않으면 서비스를 수동으로 시작합니다.
hxshell:~$ priv service carbon-cache start
carbon-cache start/running, process 15750
hxshell:~$ priv service carbon-aggregator start
carbon-aggregator start/running, process 15799
hxshell:~$ priv service statsd start
statsd start/running, process 15855관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
27-Jul-2023 |
최초 릴리스 |
피드백