[VMware] 09-26 vSAN(w. Ansible)

 

23일자 포스팅에 이어서!

Trouble shooting) 

> Site-B에 대한 vMotion Network 구성 

 : 새로 구성한 SB-esxi-01이 Cluster로 Join이 되지 않았던 이유는, vMotion용 Network 구성의 Fault...

   Site-B의 gateway인 10.10.20.1 대역으로 통신이 되지 않았던 이유였다~ 이를 수정하고 분산포트 그룹 및 VMKernel adapter의 업링크 매칭 후 통신 확인 및 Cluster로 Join확인.

 

 

> SB-ESXi 에 대한 vSAN Disk 할당 

 

> Stand Alone이어서 여전히 구성상 오류 경보 확인된다 

 : 늘 Object에 대해 오류 내용을 확인 해야 한다 

 

 - Shared Storage를 구성함으로써 가능한 것 

Migration(DRS, HA) 

1TB에 대한 disk 할당을 다른 Host로 Rebuilding 

> Reduced availability with no rebuild > delay timer : 60mins

60분이 지나도 살아나지 않으면, 다른 Host로 rebuliding 시작 

* Redundant DATA > Test Server는 무관할 수 있지만, 고객사 환경에서는 필수 구성해야 한다 : 덤탱이 쓸지도모름

 

 > vSAN Full data migration : 갖고 있는 모든 Data를 갖고 넘긴다 

작업 실패 (왜? Component가 1이기 때문)

 

> vSAN 액세스 지원 보장 : 일부 Data를 전송 

이 상태에서 다른 Server에서 장애가 발생한다면 심각한 Data Loss가 발생한다

 

Data+Data+Witness 총 3대의 Server로 구성되어야 하는게 vSAN Cluster ! 

최소 3대의 Server가 요구사항이지만, 안정적인 운영을 위해서는 4대의 Server로 구성해야함을 권고(인지) 시켜야 한다

 

 > vSAN data migration : No data migration 

Tool tip 에 존재 하긴 하나 없는 기능이라 생각하는게 맞다!!!!!

해당 모드로 유지보수모드 실행 시 Component가 Absent상태가 되기 때문

(Absent 상태때는, Object의 Disk를 다시 찾아주든 생성해주든 해주어야 한다)

 

> 유지보수모드(Pre-check) 

vSAN Data Migration Mode별 사전 검사를 통해 유지보수모드 사용 여부를 미리 확인 할 수 있다

 

 

현재 Virtual Object에 문제가 있는지 여부를 먼저 확인 한 후 작업을 실행해야 한다 

 

> Cache Disk : 삭제시 전체 Disk가 걍 삭제됨 

 

 > 작업시 꼭 확인해야 할 것 

 

> 삭제한 디스크그룹(할당되지 않은 디스크)을 기존에 있던 디스크 그룹에 마운트 진행 

 > 디스크 그룹 없이 SSD Join 가능 함(License는 vSAN Cluster로 적용) 

 

 > 해당 Disk Group도 삭제시 VM의 상태 확인 

 

 

> 디스크 그룹을 모두 삭제 해놨기 때문에, 해당 VM의 물리 Disk를 빠르게 찾아주거나 재생성 해주어야 하는 작업을 해보도록 한다~

Cache 계층은 하나의 디스크만 선택 가능하며, Capacity 계층은 여러개의 디스크를 선택 할 수 있으나, 위의 Cache계층에서 선택된 디스크는 항목 제외된다

 

 > 아래 그림과 같이 생성된 디스크 그룹을 다시 확인 가능!

 

 > 클러스터 선택 > Skyline Health 선택 > 개체 즉시 복원 으로 경보 상태를 정상으로 복구 할 수 있다

 

vSAN > Reservation and Alerts

HA에선 Admission Control과 같이 자원에 제약을 두는건 CPU, Memory 였는데 vSAN에서는 Storage Resource만 Host 장애가 났을때 어떻게 할 것인가에 대한 설정을 하는것이다.

: vSAN

 디스크 그룹 중복 제거 및 압축 하는 순간 > 부분(partial) 복구나 제거 가 불가해지기 때문에 그룹을 통으로 날렸다가 재할당 하는 불편함..... 그것의 vSAN의 약점..

Back-End I/O 는 최소 두배의 I/O가 발생한다. (VM 1ea당)

 

 

Fault Domain > Stretched Cluster 구성

위 같은 3:1 구조로는 구성 할 수 없고 기본 도메인과, 보조 도메인이 같은 구성은 아니더라도 최소 두 대 이상의 Server가 있어야 한다 

 

 > Site-B ESXi host 2, 3 도 마찬가지로 Cluster 내 Host Join 및

분산가상스위치에 Host 추가, vSAN, vMotion 분산 포트그룹에 Host 추가 

 

> Stretched Cluster - witness Server 구성 

> Witness SC 는 기 생성된 Cluster 밖에서 host 등록 해야 함

 

 

> 장애도메인 (Fault Domain 구성)

 

 

> 장애 도메인 구성 후 R5 구성인 VM-05의 스토리지 정책을 확인하면 FTM=R5 정책이 비준수로 확인 됐었는데, 준수< 로 표시됨을 확인 가능하다 

 

> Stretch Cluster 구성에 의해 R5 구성이고 강제 프로비저닝이어서 실제 요구 조건에 의한 구성이 아니기 때문에 아래 처럼 보이는것 

 

 

 

 

 > VM Storage 정책 구성해둔것을 VM-02에 적용 후 물리적 디스크 배치를 다시 확인해보면 witness Server가 3개로 확인된다 실제 vSAN 공인 시험에서도 아래 구성요소로 어떤 구성인지 R6인지 R5인지 묻는 문제가 출제된다

 

 

> 장애 도메인을 일괄 prefered, 또는 Secondary로 적용했을 때 보여지는 Tooltip 확인