'VSAN'에 해당되는 글 46건

  1. 2018.06.07 [VMware] vExpert VSAN 2018을 수상했습니다
  2. 2018.06.04 [VMware] vSAN 캐시 디스크에 장애가 발생하면 디스크 그룹이 보이지않음
  3. 2018.02.01 [VMware] vSAN 6.6 환경에서 ovf 전개가 실패함
  4. 2018.01.03 [VMware] vSAN 팁 몇가지 (1)
  5. 2017.12.20 [VMware] vSAN 6.2 Essentials 무료 공개
  6. 2017.10.27 [VMware] 인벤토리에 레플리카가 표시됨
  7. 2017.10.25 [VMware] 기존 스토리지에서 vSAN으로의 이행 가이드
  8. 2017.10.09 [VMware] vSAN All Flash mode critical issue
  9. 2017.09.24 [VMware] vSAN 환경의 ESXi 재시작에 시간이 많이 걸림 (2)
  10. 2017.09.05 [VMware] 가상머신에 디스크추가시 씬프로비저닝이 적용않됨
2018.06.07 22:15

[VMware] vExpert VSAN 2018을 수상했습니다

영광스럽게 올해도 vExpert VSAN 2018을 수상하게 되었습니다.




vExpert VSAN 2018 Announcement


vExpert VSAN 프로그램은 vExpert의 서브 프로그램으로 vExpert 안에서 모집하여 vExpert 팀과 Storage & Availability 부문(SABU)에서 심사, 수상자를 결정합니다. VSAN 이외에는 NSX와 Cloud가 있으며 각각 8월, 10월경에 수상자를 발표하는 것 같습니다. (작년에는 그랬네요)


하여간 굉장히 기쁘네요. 흐흐 올해는 한국분도 수상을 하신 것 같아 더욱 반갑네요. ;)


Horizon 관련의 프로그램도 있습니다만, Horizon의 경우는 vExpert의 서브 프로그램이 아닌 독립 프로그램인 것 같습니다. 정식 명칭은 VMware EUC Champions입니다.


Here They Are: VMware 2018 EUC Champions



Trackback 0 Comment 0
2018.06.04 22:52

[VMware] vSAN 캐시 디스크에 장애가 발생하면 디스크 그룹이 보이지않음


조금 시간이 지난 내용일지 모르겠습니다.


작년에 vSAN에 대한 팁을 몇가지 소개한 적이 있습니다. 내용중에 vSAN 도입후 장애 테스트를 실행할 경우는 가동중인 디스크를 해제하지말고 "vsanDsikFaultInjection.pyc"를 이용하도록 소개를 했었습니다. 이 스크립트를 실행하면 캐시/용량 디스크의 장애 시험을 할 수 있죠. 


제 자신도 vSAN을 도입한 뒤에는 "vsanDsikFaultInjection.pyc"를 이용하여 디스크의 장애 시험을 행하고 있습니다만, vSAN 6.5부터 예상 밖의 문제에 부딪혔습니다.


뭐가 예상 밖이냐면 말이죠, 캐시 디스크에 장애를 일으키면 디스크 그룹이 보이지않게 된다는 겁니다. 이건 문제입니다. 디스크 그룹이 않보이면 뭐가 문제냐면 말이죠, 그 디스크 그룹내의 용량 디스크를 삭제할 수 없기 때문입니다. 용량 디스크를 삭제할 수 없으면 장애가 발생한 캐시 디스크를 교환했더라도 디스크 그룹을 새로 만들 수 없습니다. 왜냐하면 용량 디스크는 여전히 장애가 발생했던 캐시 디스크의 디스크 그룹의 메타 데이터를 갖고 있어 디스크 그룹을 만들려해도 용량 디스크가 표시되질 않기 때문입니다.  (용량 디스크에 장애가 발생하였을 경우는 디스크 그룹이 보이지않는 문제는 발생하지 않습니다)


이 현상, vSAN 6.5~6.6.1의 버그인거 같습니다. vSAN 6.2까지는 이 버그의 영향을 받지않았으며 캐시 디스크에 장애가 발생해도 디스크 그룹은 보여지기 때문에 Web Client를 통해 용량 디스크나 디스크 그룹을 삭제할 수 있었습니다. 이 버그, vSAN 6.7에서 해결(이라기보다는 대응)되었다고 합니다.

 


검증환경에서 확인을 해보죠.


위의 그림은 vSAN 6.6.1의 검증 환경입니다. 3 노드 구성으로 첫번째 노드(n-esxi65-15)의 캐시 디스크에 장애를 일으키겠습니다.


"vsanDsikFaultInjection.pyc"를 실행하여 "Permanent Disk Failure" 상태를 만듭니다.


보이시나요? 첫번째 노드(n-esxi65-15)의 디스크 그룹이 보이지 않게 되었습니다. 하지만 캐시 디스크와 용량 디스크는 확인을 할 수 있습니다. 하지만... 용량 디스크를 삭제할 수 있는 방법이 없습니다. 허허허


이번에는 버그를 대응한 vSAN 6.7의 검증 환경입니다. 역시나 3 노드 구성으로 첫번째 노드(n-esxi67-21)의 캐시 디스크에 장애를 일으키겠습니다.


"vsanDsikFaultInjection.pyc"를 실행하여 "Permanent Disk Failure" 상태를 만듭니다.

음? 대응되었을 버전임에도 불구하고 vSAN 6.6.1과 동일하게 디스크 그룹이 보이지 않게 되었습니다. 아울러 용량 디스크를 삭제할 수 있는 메뉴가 없습니다. 흐음...


HTML5 Client로 다시금 vSAN 6.7 클러스터를 확인해 봤습니다. 확인해보니 [Remove Disk(s)] 메뉴가 있네요! ;) 아시겠지만 Flash Client는 vSAN 6.7에서 비추천, 다음의 버전에서 비지원이 됩니다. 따라서 Flash Client에는 이 대응 메뉴가 추가되지 않은 것 같습니다.


[Remove Disk(s)]를 클릭하면 용량 디스크를 삭제할 수 있습니다. 


깔끔하게(?) 삭제가 되었네요. 흐흐



참고로 이 버그의 영향을 받는 vSAN 6.5 ~ 6.6.1 환경에서 만약 캐시 디스크에 장애가 발생하였다면 아래의 방법으로 ESXi에서 직접 용량 디스크를 삭제할 수 있습니다.


우선 삭제할 용량 디스크의 디바이스명을 확인합니다.

esxcli vsan storage list


디바이스명을 확인했다면 다음의 명령어를 실행, 용량 디스크를 하나씩 삭제합니다.

esxcli vsan storage remove –evacuation-mode=noAction –disk=디스크명


;)

Trackback 0 Comment 0
2018.02.01 21:50

[VMware] vSAN 6.6 환경에서 ovf 전개가 실패함


얼마전 동료에게 공유받은 내용입니다.


vSAN 6.6 환경에서 ovf 템플릿을 전개하려고 하면 다음과 같은 메시지와 함께 실패할 경우가 있습니다.

The operation is not allowed in the current state (현재 상태에서 허용되지 않는 작업입니다)



■ 원인

vSAN 6.6의 알려진 버그인거 같습니다. 릴리즈 노트를 확인해보면 알려진 문제로 소개되었습니다.


vSAN 클러스터에 OVF 템플릿을 배포하는 경우 vSAN 클러스터에서 DRS를 사용하지 않도록 설정하면 작업이 실패합니다. 다음과 유사한 메시지가 표시될 수 있습니다. 현재 상태에서 허용되지 않는 작업입니다.


이 문제는 6.6.1 에서도 해결되지않은 듯, 6.6.1 릴리즈 노트에도 명기되어있습니다.



■ 해결방법

릴리즈 노트에는 워크어라운드로 DRS를 유효화하라고 쓰여있습니다. 아마도 ovf 전개시 DRS의 추천치를 적용하려고 하기 때문이 아닐까 싶습니다만, 문제는 DRS를 이용하기 위해서는 Enterprise Plus 에디션이 필요하다는 점입니다. Standard 이하의 에디션의 경우는 이 워크어라운드가 그다지 도움이 되질 않습니다.




물론 필요한 ovf 화일을 도입초기의 평가판 라이센스가 유효기간중에 전개하면 될지도 모르겠습니다만... 일단 정규 라이센스를 적용후에는 Web Client에서는 ovf 템플릿을 전개할 수 없을 수 있습니다. 이럴 경우는 ESXi Host Client로 접속하여 ESXi 호스트상에서 전개를 하면 회피할 수 있으니 참고하시길...





Trackback 0 Comment 0
2018.01.03 17:33

[VMware] vSAN 팁 몇가지

이미 10,000사 이상에서 도입되었으며 기세가 점점 거대해지는 vSAN입니다만 고객과 얘기를 해보면 의외로 vSAN에 대한 정보가 부족한 것 같습니다. 왜냐하면 vSAN이란 솔루션의 특징은 알고 있어도 실제로 도입할 경우나 도입후 운용해나갈 경우 주의해야될 점들에 대해서는 잘모르는것 같았기 때문입니다.


따라서 도입시나 운용시 조금은 주의가 필요한 내용을 정리해 봤습니다.(이미 알려진 내용일지 모르겠습니다)


● 하나의 RAID Controller에서는 VMFS과 vSAN FS을 구성할 수 없습니다.

아마 초기 버전의 vSAN 구성에서 있을 수 있는 경우일지 모르겠습니다만, 최근에도 지원 의뢰가 있는거 같습니다. 하나의 RAID Controller상에서 VMFS과 vSAN FS을 구성하는 것은 지원을 받을 수 없습니다. 하나의 RAID Controller에 ESXi용 RAID 1과 vSAN용 non-RAID를 구성하는 것은 피해야 됩니다. 

vSAN을 구성할 경우 ESXi의 부트 디바이스로 내장 SD카드나 SATADOM 같은 플래시 디바이스를 이용하는 것이 일반적이라고 할 수 있습니다만 스크래치 파티션을 로컬 데이터스토어에 보존하기위해 하드 디스크에 ESXi를 설치하고자 할 때는, ESXi용으로 RAID Controller를 준비, vSAN용 RAID Controller를 추가로 준비해줘야 됩니다.


● 부트 디바이스로 내장 SD 카드를 이용할 경우, 스크래치 파티션을 고려해야 됩니다.

내장 USB 메모리나 SD 카드에 ESX를 설치할 경우 로그는 RAM 디스크상에 보존됩니다. 단지 RAM 디스크상에 보존되기 때문에 ESXi 호스트를 재기동하면 로그는 사라지고 이로인해 장해의 원인 규명이 힘들어지게 됩니다.


이를막기위해서는 스크래치 파티션을 구성할 필요가 있습니다만, vSAN에서는 ① ESXi 호스트의 로컬 데이터스토어를 이용하든지 ② NFS의 디렉토리를 호스트별로 준비하는 방법뿐입니다. 단지 ①의 경우는 위의 팁에서 소개를 했듯이 RAID Controller를 추가로 준비해야되죠. ②역시 NFS 디렉토리를 준비해줘야 됩니다.


지금까지의 경험상, 스크래치 파티션 때문에 ①이나 ②를 준비하는 사례는 거의 없었습니다. 때문에  Remote Syslog와 Network Dump를 구성하는 방법이 가장 무난할지 모르겠습니다. 단지 이것도 모든 로그를 보존할 수 있는 것이 아니기 때문에 vSAN을 도입할 경우는 돈을 들여 스크래치 파티션을 준비하든지 syslog 만을 준비하여 최소한의 로그라도 보존을 하든지를 고려해야될 필요가 있습니다. 개인적으로는 vRealize Log Insight에 로그를 전송하는 것을 추천하고 싶네요. 

 


● vsanDatastore의 미사용영역을 항상 30% 확보하도록 합니다.

운용시작후 vsanDatastore의 사용영역이 전체영역의 80%를 넘지않도록 주의하는 것은 널리 알려져 있습니다. (SIer에 따라서는 70%를 이용가능한 최대영역으로 안내를 하는 경우도 있죠)

이와 비슷한 내용일지 모르겠습니다만 vsanDatastore의 미사용영역은 항상 30% 정도 확보해두는 것을 추천합니다. FTT가 다른 복수의 스토리지 정책을 이용는 환경에서 스토리지 정책을 변경할 경우, 일시적으로 변경전의 스토리지 정책과 변경하는 스토리지 정책이 공존하게 됩니다.


예를들어 가상머신에 FTT=1의 스토리지 정책이 적용되어있다고 하죠 이 가상머신의 스토리지 정책을 erasure coding의 스토리지 정책으로 변경할 경우, 데이터의 변환이 끝날 때까지 RAID 1와 RAID 5가 공존하게 됩니다. RAID 5의 스토리지 정책으로 변경중 vsanDatastore의 영역이 부족하면 정책 변경은 실패합니다.


따라서 vsanDatastore의 미사용영역은 항상 30% 정도 남겨두도록 하는 것을 추천합니다.



● 최소 구성은 3 호스트, 하지만 4 호스트를 추천합니다.

네, 알고 있습니다. vSAN의 최소 구성의 호스트 수는 3 호스트입니다.(ROBO나 2 호스트 다이렉트 접속 구성을 제외) 지원도 문제없이 받을 수 있습니다.


하지만 3 호스트면 가상머신의 가용성 유지에 불안한 점이 있습니다. 특히 운용중의 리스크가 커지게 됩니다. 3 호스트 구성시는 1 호스트를 유지보수하더라도 FTT=1를 충족할 수 없게되어 가용성을 확보할 수 없게 되기 때문이죠.


1 호스트 유지보수중 다른 호스트에 장해가 발생할 경우는 거의 드물다고요? 이렇게 생각하시는 분들, 장해가 발생한 뒤에는 늦습니다. 저같으면 싫습니다. 매번 두근두근하면서 패치 적용하는 건... 흐흐 :)


호스트 장해에 대한 대비는 물론이지만, 운용시 유지보수의 편리성을 생각한다면 vSAN 클러스터는 최소 4 호스트 구성을 추천합니다.


 


● “중복제거와 압축” 기능의 유효시, 디스크 단위의 삭제는 않됩니다.

All-Flash 모드의 vSAN을 도입하여 ”중복제거와 압축”기능을 검토하고 계신 분들은 “중복제거와 압축” 기능은 디스크 그룹 단위로 구성된다는 것에 주의하시길... 디스크 그룹 단위로 구성이 되기 때문에 capacity SSD에 장애가 발생하면 해당 디스크 그룹을 일단 삭제, SSD 교환후 새롭게 작성을 해야됩니다.


운용을 시작하여 일정 시간이 경과후 발생하면 의외로 번거로운 문제가 될 수 있으므로 "중복제거와 압축"기능을 검토할 경우는 운용면에서의 부하도 충분히 검토를 하시길 바랍니다.


● vSAN을 구성하면 ESXi 호스트의 reboot는 시간이 걸립니다.

거의 포스팅에서도 소개를 했습니다만, vSAN의 호스트는 부팅시 vSAN 메타 데이터 테이블을 재작성합니다. (KB에 의하면 디스크 그룹당 최장 1시간이 걸릴 수도 있다고 합니다)

때문에 non-vSAN의 ESXi 호스트보다 시작에 시간이 걸립니다. 기동에 실패하여 에러가 표시되기 전까지는 인내심을 갖고 기다리기 바랍니다.


ESXi 호스트의 시작이내 재시작시에는 DCUI나 원격 콘솔에서 부팅 프로세스를 확인하는 것을 추천합니다.


● 가동중에 디스크를 뽑는 것은 장해 테스트라고 할 수 없습니다.

vSAN 도입직후 대부분 장해 테스트를 하실겁니다. 네트워크나 전원, 혹은 호스트 장해 테스트를 하시겠죠. 물론 디스크(cache 티어나 capacity 티어) 장해에 대해서도 테스트를 하실겁니다. 단지 디스크는 다른 장해 테스트와는 달리 간단히 장해 상태를 만들 수 없죠. 결국 가동중인 디스크를 뽑는 것이 일반적으로 이루어지고 있지 않을까 합니다.(과거에 저도 장해 테스트로 가동중인 디스크를 뽑는 방법을 소개한 적이 있습니다... )


이건 absent 상태가 되어 제대로 된 장해 테스트라고 할 수 없습니다.(물론 이 상태에서 ClomRepairDelay의 타임아웃이 되면 데이터의 동기가 실행되므로 결과적으로는 같을지 모르겠습니다...)


그렇다면 어떻게 해야되느냐...? Failure Testing을 이용하면 됩니다.


VMware 공식 문서인 이 Failure Testing에는 호스트 장해, 디스크 장해시의 동작에 대한 설명과 함께 디스트 장해를 발생시킬 수 있는 방법도 소개하고 있습니다.

/usr/lib/vmware/vsan/bin/vsanDiskFaultInjection.pyc


위의 명령어를 이용하면 간단히 디스크를 Permanent Error 상태로 만들 수 있습니다. 장해 테스트를 하실 경우는 꼭 이용해보세요.


음... 원래 HCI의 디스크 장해 테스트의 목적은 "장해가 발생해도 서비스(가상머신)는 정지하지 않는 것을 확인"하는 것이라고 생각합니다만, 이상하게 "가상머신의 가용성을 어떻게 수복하는가"를 확인하는 쪽으로 바뀐 것 같네요. :)



● 격리 어드레스 변경후는 vSphere HA를 재유효화해야 됩니다.

이것도 이미 알고 계시리라 생각됩니다. vSAN을 구성하면 하트비트가 관리 네트워크로부터 vSAN 네트워크로 변경되죠. 따라서 호스트 격리시에 이용되는 격리 어드레스도 변경해줘야 됩니다. 격리 어드레스는 vSphere HA의 고급설정에서 변경이 가능합니다만 변경후 추가 작업이 필요합니다.


격리 어드레스의 변경은 vSphere HA를 일단 무효후 다시금 유효화해주지 않으면 반영되지 않습니다. 격리 어드레스를 변경한 뒤에는 반드시 vSphere HA를 재유효화해 주는 것을 잊지마세요. :)



 VCSA을 Easy Install로 설치하였을 경우는 vSAN 구성후 스토리지 정책을 적용해주세요.

vSAN 6.6부터 vSAN 클러스터상에 VCSA를 설치하는 것이 무지하게 편해졌습니다. VCSA 설치시 "새로운 vSAN 클러스터에 포함되는 ESXi 호스트에 설치" 옵션을 선택해주기만 하면 되죠. 간단히 싱글 호스트에 일시적으로 vsanDatastore를 구성, VCSA를 설치해줍니다. VCSA가 설치되면 남은 ESXi 호스트를 vSAN 클러스터에 추가해주면 vSAN 구성이 끝납니다. 간단하죠. :)

하지만 잘 생각해보세요. vsanDatastore 상에 가상머신(VCSA)를 설치했다는 말은 자동적으로 vSAN Default Storage Policy가 적용된다는 말이죠. vSAN Default Storage Policy는 FTT=1에 Stripe=1입니다. 이말은 최소한 3 호스트가 필요하다는 말이죠. 하지만 VCSA를 설치한 시점에서는 1 호스트밖에 없으므로 VCSA는 스토리지 정책이 적용되지 않은 상태가 됩니다.

 

Easy Install로 VCSA를 설치했을 경우는 vSAN 구성이 끝난 뒤에 잊지말고 스토르지 정책을 적용해주세요. 

 



● 컴포넌트 사이즈에는 최대치가 있습니다.

vsanDatastore에는 최대 62TB의 vmdk 화일을 작성할 수 있습니다. 최대 사이즈는 다른 스토리지와 다를바없습니다만 vSAN의 경우는 조금 특수합니다. vSAN은 최종적으로 capacity 디스크에 "컴포넌트"로 저장이 됩니다. 이 컴포넌트에는 최대 사이즈가 있어, 255GB가 최대 사이즈입니다. 255GB를 넘는 화일은 자동적으로 분할되어 복수의 capacity 디스크에 저장이 됩니다. 컴포넌트는 분할되어 각 정보는 메타데이터에 의해 관리됩니다. 예를들어 vmdk 화일 사이즈가 1TB의 경우, capacity 디스트에 저장되는 컴포넌트 수는 4 이상이 됩니다. FTT=1의 경우 8 이상이 되는거죠. 참고로 오브젝트는 분할되지 않습니다.

위의 그림처럼 가상머신에 3개의 vmdk 화일이 있다고 하죠. 스토리지 정책은 FTT=1입니다. 하드 디스크 1과 2는 100GB 정도입니다. 이에비해 하드 디스크 3은 약 400GB 정도됩니다. 하드 디스크 1과 2는 FTT=1의 정책이 적용되어 각각 2개의 컴포넌트가 각각 다른 호스트상에 저장되게 됩니다.

 

하드 디스크 3은 400GB 이므로 컴포넌트의 최대 사이즈를 넘습니다. 따라서 RAID 1의 안에 각각 RAID 0로 3개의 컴포넌트로 분할되어 저장되어 있는 것을 확인할 수 있습니다.(몇개의 컴포넌트로 분할될지는 화일의 사이즈에 따라서 달라집니다)


재미있죠? :)


거대한 가상머신을 작성할 경우는 이 컴포넌트의 구성이나 배치도 고려하는 것이 좋습니다.



 

이외에도 팁이 있으리라 싶습니다만, 생각나는건 이정도네요. vSAN의 도입이나 운용에 조금이나마 도움이 되었으면 합니다. :)

Trackback 0 Comment 1
2017.12.20 19:05

[VMware] vSAN 6.2 Essentials 무료 공개

vSAN계에서는 유명한 인물이 2명있습니다. Cormac Hogan씨와 Duncan Epping씨가 바로 그 2명입니다.

2명 모두 VMware사의 SABU(Storage & Availability Business Unit) CTO면서도 vSphere Clustering관련, 스토리지나 vSAN 관련의 유익한 정보를 많이 소개해주고 있어 항상 도움을 받고있죠. 


이 두명이 집필한 Essential Virtual SAN (VSAN): Administrator’s Guide to VMware Virtual SAN의 vSAN 6.2 대응판을 무료로 공개해주었습니다.

Holiday gift: vSAN Essentials book available for free

vSAN Essentials e-book is now free

 

300 페이지에 걸쳐 아키텍쳐를 시작으로 설치, 스토리지 정책, 관리/운용 그리고 트러블슈팅까지 vSAN의 모든 것을 커버하고 있습니다. vSAN 6.2 대응이라 조금은 오래된 내용일 듯 보일지도 모르겠습니다만, 대부분은 지금도 충분히 활용할 수 있는 내용입니다. vSAN 인프라의 관리자분들이나 vSAN 도입을 검토하고 계신 분들에게는 필독서라고 생각합니다.

 

다시 한번 Cormac Hogan씨와 Duncan Epping씨에게 감사를 드리고 싶네요. :)


Trackback 0 Comment 0
2017.10.27 20:09

[VMware] 인벤토리에 레플리카가 표시됨

2017/12/5 Updated

커뮤니티 회원님에게 좋은 정보를 들었습니다. 어쩌면 이 KB가 해결방법인지 모르겠네요. 다음에 또 다시 발생한다면 써봐야겠네요.

A virtual machine on a vSAN datastore might be renamed when vSAN becomes inaccessible





얼마전 vSAN을 도입한 고객사에서 장애가 발생했습니다. 

4 호스트의 소규모 구성이었습니다만 운없게 2 호스트가 1시간안에 멈춰버린거 같았습니다.(FTT=1임에도 불구하고 "접근불가" 상태의 가상머신이 많았기 때문이죠)


장애 발생후 호스트는 복구를 했으며 vSAN 클러스터의 헬스 상태나 오브젝트의 헬스 상태도 정상이었도 모든 가상머신도 정상적이었던거 같습니다.(표면적으로는 말이죠)


몇시간 뒤에 고객으로부터 연락을 받았습니다. 일부 리눅스 가상머신의 반응이 느려진거 같다고 하더군요. 아울러 이상하게도 가상머신에 로그인하여 명령어를 실행하면 일부 명령어가 먹히질 않는다고 하더군요. 


다음날 직접 확인을 해봤습니다.

확실히 고객이 말한대로 더군요. SSH의 접속도 늦고 일단 접속이 되더라도 일부 명령어, 예를들어 sudo나 reboot 등을 실행하면 "버스 에러"란 메시지가 표시되더군요. 리눅스에 대해서 그다지 자세하질 않아서 검색을 해보니 "버스 에러"는 일반적으로 리소스가 부족하거나 일부 라이브러리가 파손되었을 경우 발생하는 것 같더군요. 장애 발생전과 후에 해당 가상머신의 리소스를 변경한 일은 없으니, 역시나 호스트 장애로 HA가 발동한 타이밍에 게스트 OS에 영향이 있던 것이 아닌가라는 잠정 결론의 분위기였습니다.


다행히도 문제가 발생한 가상머신은 수일전에 새롭게 작성한 것으로 최악의 경우 삭제를 해도 문제가 없다길래 일단 가상머신을 강제적으로 정지했습니다.

정지했더니 인벤토리에서 가상머신이 사라졌더군요. 대신 FTT=1로 생성된 레플리카가 표시되더군요. 이렇게 말이죠.



음... 호스트 장애로 HA가 발동한 타이밍에 레플리카가 인벤토리에 등록이 된 것일까요? 자세한 내용은 확인을 할 수가 없었습니다만, 인벤토리에서 레플리카를 삭제한 뒤에 가상머신을 인벤토리에 재등록 해주니 가상머신이 등록되었고 반응도 정상적으로 돌아왔으며 모든 명령어도 실행을 할 수 있게 되었습니다.  


추축에 불과합니다만 레플리카가 인벤토리에 등록된 바람에 가상머신의 화일이 읽기 전용이 되어 명령어가 실행되지 않았던거 같네요... 쩝... 좀더 빨리 로그를 수집해서 지원부서에 돌리지 않은게 후회되네요.

Trackback 0 Comment 0
2017.10.25 23:28

[VMware] 기존 스토리지에서 vSAN으로의 이행 가이드

얼마전 세계적으로 vSAN을 도입한 고객수가 10,000사를 넘었다는 소식을 들었습니다. 


개인적인 경험으로도 개발 환경이나 검증 환경이 아닌 실환경에 도입을 하는 사례가 부쩍 늘었으며 SSD의 가격이 낮아진 때문인지 All Flash 모드가 주류를 이루고 있으며 기존 SAN 환경의 교체로써 vSAN을 선택하는 기업들도 늘고 있습니다.


이런 시기에 아주 도움이 될 가이드가 공개되었습니다.


"Migrating to vSAN"이란 타이틀의 이 가이드는 기존 SAN 환경의 교체로써 vSAN을 이용할 경우 가상머신의 이행에 대한 다음과 같은 방법을 소개하고 있습니다.

    • VMFS로부터의 이행
    • NFS로부터의 이행
    • 비공유 RDM로부터의 이행
    • 공유 RDM로부터의 이행
    • 물리 서버로부터의 이행


vSAN 도입이나 이행을 고려중이신 관리자분들은 꼭 읽어보시길 권장합니다.




Trackback 0 Comment 0
2017.10.09 00:03

[VMware] vSAN All Flash mode critical issue

며칠 전 vSAN All Flash 모드에  대한 중요한 패치가 공개되었습니다.



내용은 첵썸 에러로 인해 특정한 조작이나 IO 패턴이 발생했을 경우, 가상머신에 대한 접근불가, 호스트 실패, 재동기 실패 등의 치명적인 상황이 발생한다고 합니다.


조건은 ESXi 6.0 Patch 4 (build number 4558694) 이상 vSAN, 즉 vSAN 버전 6.2, 6.5, 6.6, 6.6.1의 All Flash 구성에 중복제거를 유효화했을 경우이며, KB에 의하면 즉시 수정 패치를 적용할 것을 권장하고 있습니다.


Trackback 0 Comment 0
2017.09.24 22:40

[VMware] vSAN 환경의 ESXi 재시작에 시간이 많이 걸림

이미 운용을 하고 계신 분들은 아시시라 생각합니다.


vSAN 환경의 ESXi 호스트를 재시작할 경우 non-vSAN 환경에 비해 시간이 많이 걸립니다. 이유는 아래의 상태에서 상당시간 진척이 없어보이기 때문이죠.

VSAN: Initializing SSD: xxxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxxx Please wait....



위의 상태가 한동안 이어지기 때문에 마치 기동에 실패한 것처럼 보이죠. 아무런 변화가 없이 10분 이상 시간이 걸리면 안절부절하는 분도 계시리라 생각됩니다. 그럴 경우는 가볍~게 「Alt+F12」를 눌러보세요. 그러면 아래 그림처럼 사실은 열심히 처리중인 것을 알 수 있습니다.


그렇다면 왜 이렇게 시간이 걸리는가?인데요. vSAN의 경우 ESXi 호스트가 기동할 때 SSD상의 로그를 참조하여 메타 데이터 테이블을 작성하기 때문이라고 합니다. 따라서 디스크 그룹내의 데이터가 많으면 많을수록 메타 데이터 테이블 작성에 시간이 걸리고, 결과적으로 ESXi 호스트의 기동에 시간이 걸리는 것입니다.


이 현상에 대한 KB도 공개되었으니 확인을 해보시기 바랍니다.

Initializing vSAN during boot takes a longer time


한가지 주의해야 될 점은 KB에도 기재되어있듯이 이 상태에서는 강제로 재시작을 실행해서는 않된다는 겁니다. 잘못하면 데이터가 손실될 수도 있습니다.



Trackback 0 Comment 2
2017.09.05 19:22

[VMware] 가상머신에 디스크추가시 씬프로비저닝이 적용않됨

오늘은 운용상의 참고사항을 한가지 소개할까 합니다.


아시다시피 vSAN을 구성하면 자동적으로 "vSAN Default Storage Policy"이 생성됩니다. vSAN을 이용하는데 표준적인 룰로 구성되어있기 때문에 이 정책을 이용하시는 분들도 많으리라 생각됩니다.

이 정책의 룰중 "Object Space Reservation"이 있으며 초기값은 '0%'로 오브젝트에 대한 영역을 예약하지않습니다. 즉 오브젝트는 씬프로비저닝으로 영역을 소비하게 되죠.


아래 그림과 같은 vSAN 6.6의 환경이 있습니다. 소비된 영역은 70GB을 밑돌고 있죠.


가상머신에 적용된 스토리지 정책은 "vSAN Default Storage Policy"로 "Object Space Reservation"은 '0%'입니다.


이 상태에서 가상머신에 100GB 사이즈의 디스크를 추가해보겠습니다. 

자아~ 복습입니다. vSAN은 오브젝트에 대해서 스토리지 정책을 적용, 데이터를 보호하죠? 따라서 지금부터 추가하는 디스크도 스토리지 정책이 적용될 것입니다. 디폴트라면 "Thin provision"이 선택되어져있을겁니다. 이 상태에서 디스크를 추가했습니다.


디스크가 추가되어 스토리지 정책 적용여부터 확인을 할 수 있죠. 문제없네요.


이번에는 데이터스토어의 용량을 보도록 하죠. "씬프로비전"& 데이터가 없기때문에 디스크 추가전과 비교해도 거의 차이가 없습니다,


자아~ 일단 추가한 디스크를 삭제, 다시금 100GB 사이즈의 디스크를 추가해보도록 하죠. 이번에는 "Thin provision"이 아닌 "Thick provision (lazy zeroed)"를 선택했습니다. ※ vSAN의 경우 "Thick provision (eager zeroed)" 포맷은 없습니다. 따라서 "Thick provision (eager zeroed)"을 선택했다치더라도 "Thick provision (lazy zeroed)"으로 포맷되어집니다.


"Thin provision"때와 동일하게 디스크가 추가되어 스토리지 정책도 적용되었습니다. 


데이터스토어의 용량은 어떨까요? 어라? 소비된 용량이 200GB 정도 늘었네요? 이상하죠? 위의 그림에서처럼 스토리지 정책도 적용되었고 컴플라이언스 상태도 정상임에도 불구하고 소비 용량이 200GB 늘었다는 것은 추가한 디스크가 "Thin provision"이 아니라는거죠.


스토리지 정책이 적용된 가상머신에 디스크를 추가시 디스크 포맷을 수동으로 "Thick provision (lazy zeroed)"로 지정을 했을 경우, 스토리지 정책을 덮어쓰는거 같습니다.


참고하시길... :)


만약 "Thick provision (lazy zeroed)"로 작성을 했다면 "Object Space Reservation"가 '0%'인 스토리지 정책을 적용해주면 디스크 포맷이 "Thin provision"으로 변경됩니다.


새롭게 스토리지 정책을 적용해주었더니 약 260GB가 70GB 이하로 줄어들었네요~ 




Trackback 0 Comment 0


티스토리 툴바