'VSAN'에 해당되는 글 41건

  1. 2017.10.27 [VMware] 인벤토리에 레플리카가 표시됨
  2. 2017.10.25 [VMware] 기존 스토리지에서 vSAN으로의 이행 가이드
  3. 2017.10.09 [VMware] vSAN All Flash mode critical issue
  4. 2017.09.24 [VMware] vSAN 환경의 ESXi 재시작에 시간이 많이 걸림 (2)
  5. 2017.09.05 [VMware] 가상머신에 디스크추가시 씬프로비저닝이 적용않됨
  6. 2017.08.17 [VMware] vExpert 2017 VSAN (3)
  7. 2017.08.16 [VMware] vSAN upgrade guide
  8. 2017.07.29 [VMware] vSAN 6.6.1 릴리스
  9. 2017.07.27 [VMware] VCSA vSAN 6.6 easy install
  10. 2017.07.23 [VMware] vSAN 사이징 툴
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
2017.08.17 22:59

[VMware] vExpert 2017 VSAN

영광스럽게도 vExpert 2017 VSAN을 수여받게되었습니다.


vExpert 2017 VSAN Announcement




vExpert 2017 VSAN은 vExpert 수여자중에서도 특정 프로덕트의 전파에 공헌한 vExpert를 인정하는 서브 프로그램의 하나로 2016년 시작되었습니다. vSAN이외의 서브 프로그램으로는 NSX와 Horizon이 있습니다.


첫해인 2016년에는 20여명이었던걸로 기억합니다만 올해는 87명이 vExpert 2017 VSAN을 수여하게 되었습니다. 


물론 vExpert과 같이 명예직입니다만 1세대인 Virtual SAN 5.5부터 접해온 저로써는 상당히 애착(?)을 갖고있는 프로덕트이기 때문에 영광스럽고 기쁠뿐입니다. :)


앞으로도 vSAN에 관한 정보를 공유해 나가도록 하겠습니다,


저작자 표시 비영리 변경 금지
신고
Trackback 0 Comment 3
2017.08.16 15:17

[VMware] vSAN upgrade guide

얼마전 vSphere 6.5 Update 1 릴리스와 동시에 vSAN도 6.6.1로 조금(?) 버전에 올라갔죠. :)

vSAN 6.6.1의 새로운 기능에 대해서는 이전의 포스팅을 확인하시고요...


이번에는 업그레이 가이드에 대한 소개를 할까 합니다. 

정확히는 과거의 버전에서 vSAN 6.6.1로 업그레이드를 할 경우는 고려해야될 다음의 내용을 포함하고 있습니다.

    • vSAN 업그레이드시의 디스크 포맷 버전과 버전업의 프로세스
    • 네트워킹(멀티캐스트에서 유니캐스트로의 변경시 고려사항)




이외에도 업그레이드에는 필수인 vCenter의 업그레이드 방법이나 vSAN 업그레이드시의 트러블슈팅에 대한 내용도 포함하고 있습니다.


1세대인 Virtual SAN 5.5가 릴리스된지 4년이 지났습니다. 5.5을 포함한 초기의 버전을 도입하시는 분들은 슬슬 업그레이드를 검토하실 시기가 되지않았나 싶네요. 업그레이드를 검토하시는 분들은 읽어보시길 권장합니다. :)





저작자 표시 비영리 변경 금지
신고
Trackback 0 Comment 0
2017.07.29 19:53

[VMware] vSAN 6.6.1 릴리스

어제 vSphere 6.5 Update 1 이 릴리스되었습니다. ESXivCenter도 각각 6.5 U1이 되었죠. 아울러 vSAN도 6.6.1이 릴리스되었습니다. 이번 6.6.1은 버그 수정은 물론 다음과 같은 기능이 개선되었다고 합니다.


vSphere Update Manager의 통합

: Update Manager를 통해 vSAN 관련의 패치를 적용하거나 업그레이드할 수 있게되었습니다.


● vSAN의 성능진단 개선

: 6.6에서 CEIP(고객 환경 개선 프로그램)을 통해 vSAN 환경의 건강상태를 VMware사에 전송할 수 있는 기능이 추가되었죠. 6.6.1에서는 스루풋이나 지연 등을 비교할 수 있는 벤치마크 기능이 추가되었습니다.


● 스토리지 디바이스의 보수성 개선

: 각 ESXi의 스토리지 디바이스에 대해 vCenter에서 LED를 점등시킬 수 있게 되었습니다. 


● 새로운 라이센스 추가

: "vSAN Enterprise for ROBO"에서 "암호"와 "확장 클러스터"를 구성할 수 있게 되었습니다. 또한 Horizon Advanced 또는 Enterprise 에디션에 "vSAN Advanced"에디션이 포함되게 되었다고 합니다.


한가지 더...

vSphere 6.5의 GA가 릴리스된 후로 vSAN도 두 번의 버전 업그레이드가 실시되었습니다. 6.5 이전까지는 ESXi 버전 번호와 동일한 버전으로 구성되었습니다만, 6.5부터는 조금 애매하게 되었죠. 아시는 분들이 대부분이기겠지만 간단히 정리를 해보겠습니다.

 vSAN  버전

 ESXi 버전 

 vCenter 버전 

 vSAN 6.5  

 6.5 GA

 6.5a

 6.5 GA

 6.5a

 6.5b

 6.5c 

 vSAN 6.6

 6.5d 

 6.5d

 6.5e 

 vSAN 6.6.1

 6.5 U1 

 6.5 U1 


 

저작자 표시 비영리 변경 금지
신고

'virtualization > VMware' 카테고리의 다른 글

[VMware] 새로운 자격 신설  (0) 2017.08.25
[VMware] vExpert 2017 VSAN  (3) 2017.08.17
[VMware] vSAN upgrade guide  (0) 2017.08.16
[VMware] DRS Lens  (0) 2017.08.06
[VMware] vSAN 6.6.1 릴리스  (0) 2017.07.29
[VMware] VCSA vSAN 6.6 easy install  (0) 2017.07.27
[VMware] vSAN 사이징 툴  (0) 2017.07.23
[VMware] vRealize Automation 7.2 (18)  (0) 2017.07.12
[VMware] vSAN 모의 디스크 장애 테스트  (0) 2017.07.08
Trackback 0 Comment 0
2017.07.27 21:15

[VMware] VCSA vSAN 6.6 easy install

공식적으로 vsandatastore 위의 vCenter 구성을 지원하고 있습니다. (추천은 vCenter 같은 관리서버는 컴퓨트 클러스터와는 별도의 클러스터상에서 가동하는 것입니다)


하지만 실제로 구성을 할 경우 설치과정은 번거롭습니다. 과거의 포스팅에서도 소개를 했듯이, '닭'이 먼저인지 '달걀'이 먼저인지의 문제에 부닥치게 되어 1대의 ESXi 호스트의 디스크 일부를 로컬 데이터스토어로 구성을 한 뒤 vCenter를 설치하죠. vCenter가 설치되었다면 vSAN을 구성할 수 있으니 vSAN을 구성후 vCenter를 스토리지 vMotion으로 vsandatastore로 이동~. vCenter을 이동했다면 로컬 데이터스토어로 구성한 디스크를 vSAN 디스크로 재구성... 이 필요합니다. <--- vSAN 6.5까지는 이랬습니다.


vSAN 6.6에서는 바뀌었습니다. 이름하여 easy install!



대상은 VCSA 6.5d 이후의 버전입니다만, VCSA 전개 마법사 진행시 최초의 ESXi 호스트에 일시적으로 vsandatastore을 구성하여 VCSA를 설치할 수 있게해줍니다. 위의 그림처럼 설치할 데이터스토어 선택시 "새로운 vSAN 클러스터에 포함되는 ESXi 호스트에 설치" 옵션을 선택하면 됩니다.



"새로운 vSAN 클러스터에 포함되는 ESXi 호스트에 설치" 옵션을 선택한 뒤에는 vSAN에서 이용할 디스크를 선택하여 설치 마법사를 진행하면 끝입니다. 간단하죠?


설치후 확인을 해보니 아래와 같은 점을 발견했습니다.

위의 그림을 보시면 ”Used - VM Overreserved”가 440GB나 된다는 겁니다.  ”Used - VM Overreserved”는 스토리지 정책중 "Object Space Reservation"에 의해 예약된 상태를 말합니다. vSAN 구성시 자동적으로 생성되는 Virtual SAN Default Storage Policy의  Object Space Reservation 값은 0% 이기 때문에 예약 용량이 440GB이 된다는건 스토리지 정책이 적용되지않은 것을 의미하는거죠.


전개한 VCSA의 스토리지 정책을 확인해보니 아니나다를까 정책은 적용되지 않은 상태였습니다. easy install로 VCSA를 설치하고 나머지 2대의 ESXi 호스트를 추가하여 정상적인 vSAN을 구성한 뒤에도 말입니다. 뭐, 스토리지 정책이 자동적으로 적용되는게 아니니 당연한거지만 말입니다. 흐흐 :)


하여간 스토리지 정책을 적용해주었습니다.


스토리지 정책을 적용해주었더니 ”Used - VM Overreserved”의 용량은 20GB로 줄었습니다. 흐흐


easy install로 VCSA를 설치하시는 분들은 잊지마시고 vSAN 구성후 VCSA에 스토리지 정책을 적용하세요!





저작자 표시 비영리 변경 금지
신고
Trackback 0 Comment 0
2017.07.23 10:05

[VMware] vSAN 사이징 툴

간단한 구성과 다이나믹한 스케일-아웃을 세일스 문구로 하는 vSAN이긴 하지만 설계에 필요한 사이징은 의외로 중요합니다. vSAN 도입을 검토할 경우 CPU, 메모리에 대해서 10%의 vSAN 오버헤드를 고려하는 것은 물론 하이브리드 구성의 경우 캐시용 SSD 용량이 HDD 용량의 10% 이상이 되어야 된다는 점도  고려를 해야됩니다. 또한 스토리지 영역의 80%를 이용했을 경우 자동적으로 리밸런스가 실행되어 vSAN 성능 자체에 영향을 줄 수 있죠. 따라서 80%를 넘지않도록 실질적 이용가능 용량은 전체 스토리지 영역의 70%를 기준으로 각 디스크를 선정해야되죠. 여기에 Erasure Coding이나 중복제거/압축 기능을 이용할 경우는 더욱 신중해야 됩니다. :)


따라서 사이징과 디자인 가이드가 공개되어있죠. 하지만 문서다보니 전부 읽는건 귀찮죠? 흐흐 이러한 부분을 전부 해결하면서 간단히 사이징을 해주는 vSAN의 새로운 사이징 사이트가 공개되었습니다.

All Flash vSAN ReadyNode Sizer 



위의 사이징 사이트를 이용하면 간단히 몇대의 노드가 필요하며 노드는 어떤 종류의 CPU, 메모리 용량, 디스크 용량과 디스크 그룹의 구성을 알 수 있습니다.



위의 사이트의 이용에는  My VMware나 Partner Central의 계정이 있으면 편리합니다만 없어도 일반 용도의 vSAN 구성에 대해서는 확인을 할 수 있습니다.

All Flash vSAN ReadyNode Sizer - Evaluation



vSAN의 도입을 검토하시는 분은 사전에 위의 사이트에서 필요한 구성을 확인해 보시는 것이 좋을거 같네요. :)


위의 사이트는 All Flash 전용입니다. 하이브리드 구성의 경우는 기존의 사이징 사이트를 이용하시면 됩니다.

vSAN Hybrid TCO and Sizing Calculator





저작자 표시 비영리 변경 금지
신고
Trackback 0 Comment 0