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.06.01 19:32

[Nutanix] AOS의 EOL에 대해서

4월 AOS 5.6 릴리스에 맞춰 지원 정책에 변경이 있었습니다. 내용중에는 AOS의 EOL에 대해서도 변경이 있기에 비망록 차원에서 이번에는 간단히 AOS의 라이프사이클에 대해서 소개를 할까 합니다.


AOS의 라이프사이클에 대해 소개를 하기 전에 AOS의 버전 번호에 대한 정의를 먼저 소개하겠습니다. AOS는 4개의 번호로 정의가 되어있습니다. 각 번호는 "메이저 버전", "마이너 버전", "보수 버전", "패치 버전"을 뜻합니다.



















Nutanix EOL Bulletine AOS Versions에서는 기본적으로 "마이너 버전"으로 구분되어있습니다. 


Nutanix EOL Bulletine AOS Versions



그런데 가만히 위의 EOL 정보를 확인해보면 버전중 "LTS"가 붙어있는 버전을 확인할 수 있습니다. 현재로는 AOS 5.5가 그것인데요, 그외의 버전은 붙어있지 않죠.


"LTS"는 Long Term Support, 이른바 장기간 지원을 하는 버전입니다. GA 릴리스후 최대 18개월후 EOL을 맞이합니다. "LTS"는 12개월 주기로 새로운 버전을 릴리스할 예정이라는군요.


장기간이 있다면 물론 단기간도 있습니다. 단기간은 "STS", Short Term Support로 GA 릴리스후 6개월로 지원이 끝납니다. 6개월?  (゜Д゜) ??? 

OS의 지원이 6개월이라니 믿기지 않을지 모르겠습니다만 "STS"는 기본적으로 신기능 추가가 목적인 버전으로 실환경보다는 검증환경에서 새로운 기능을 확인하기 위한 것이 목적일지 모르겠습니다. 그렇다면 지원이 6개월이라도 어느정도 납득이 되네요. ;) 


참고로 4월에 릴리스된 AOS 5.6는 10월에 지원이 종료된답니다.


이미 Nutanix를 이용하고 있는 분들은 AOS가 빈번히 릴리스되는 것을 알고 계실 겁니다. 새로운 버전이 릴리스되었을 때는 버전의 지원 기간을 확인하도록 주의하시길 바랍니다. ;)


지원 정책에 대해 더욱 자세히 알고 싶으신 분들은 지원 정책 페이지를 확인하세요.



Trackback 0 Comment 0
2018.05.21 20:05

[VMware] vRealize Automation 7.3 (22)



(0) vRA 개요

(1) vRA 구성요소

(2) vRA 설치 - vRA 어플라이언스

(3) vRA 설치 - IaaS서버

(4) vRA 초기설정 - 테넌트 작성

(5) 테넌트 구성 - AD

(6) 엔드포인트 작성

(7) 데이터 콜렉션과 패브릭 그룹 작성

(8) 머신 접두사와 네트워크 프로화일 작성

(9) 비지니스 그룹과 예약 작성

(10) 블루프린트 작성

(11) 서비스 카탈로그 작성

(12) 블루프린트의 요구

(13) 승인 정책의 설정

(14) 커스텀 속성(사용자 지정 속성)의 설정

(15) vRO 엔드포인트 작성

(16) NSX와의 통합

(17) 가상머신의 임포트

(18) 가상머신의 해제

(19) Nutanix 엔드포인트 작성

(20) vROps와의 통합

(21) 이벤트 브로커의 이용

(22) Health Service의 구성



오랜만의 시리즈네요. ;)



vRA 7.3에서 새롭게 추가된 기능중 Health Service가 있습니다. vRA 환경의 건강 상태를 확인할 수 있는 기능으로 싱글/멀티 vRA 환경과 vRO이 대상입니다. 이 Health Service는 스케줄링이 가능하여 정기적으로 환경의 건강 상태를 확인할 수 있습니다.

Health Service를 구성할 수 있는 권한은 IaaS 관리자가 갖고 있으며 구성한 Health Service는 테넌트 관리자나 Health Consumer가 참조할 수 있습니다.

 

(21) Health Service의 구성

 

① [관리]탭의 [Health]를 선택하여 [NEW CONFIGURATION]를 클릭합니다.

※이 Health Service는 복수의 vRA이나 vRO를 등록할 수 있기 때문에 우선은 건강 상태를 체크할 환경의 "테스트 카드(프로화일과 같은 이미지입니다)"를 작성합니다.

 

② 마법사가 표시되므로 다음의 테스트 카드의 개요를 지정합니다.

  • Name:작성하는 건강 상태 테스트 카드명
  • Product:건강 상태를 체크하는 대상 프로덕트(vRA나 vRO를 선택할 수 있습니다)
  • Schedule:건강 상태 체크의 스케줄

 

체크할 항목을 선택합니다. vRA를 선택했을 경우는 ”시스템”이나 ”테넌트”를 선택할 수 있습니다.

 

④ 대상 vRA 환경의 정보를 입력합니다.

  • Public Web Server Address:vRA 어플라이언스의 URL
  • SSH Console Address:vRA 어플라이언스의 FQDN
  • SSH Console Password:vRA 어플라이언스의 root 패스워드
  • System Tenant Password:vRA 디폴트 테넌트(vsphere.local)의 패스워드
  • Tenant Under Test: 건강 상태를 체크하는 테넌트
  • Fabric Administrator Username:건강 상태를 체크하는 테넌트의 패브릭 관리자
  • Fabric Administrator Password:건강 상태를 체크하는 테넌트의 패브릭 관리자의 패스워드

※ 입력이 필요한 부분만 표시했습니다.

 

⑤ [Finish]를 클릭하여 테스트 카드를 작성합니다.

 

⑥ 작성한 테스크 카드의 [RUN]을 클릭하여 건강 상태를 체크합니다. 환경 규모에 따라 다르긴 하겠습니다만 소규모 환경의 경우는 1분 정도가 소요됩니다.

 

⑦ 결과는 우선 시각적으로 알기 쉬운 원그래프로 표시되어 그래프의 색을 클릭하면 내용을 확인할 수 있습니다.

 

⑧ 내용은 건강 상태 체크의 결과는 물론 실패의 경우 그 원인이나 수정 방법을 참조할 수 있습니다.

※ 수정 방법은 그냥... 클릭하면 공식문서 페이지의 링크입니다. ;)

 

⑨ 복수의 vRA 환경이나 테넌트, vRO까지 테스트 카드를 만들 수 있으므로 하나의 화면에서 직감적으로 모든 환경의 건강 상태를 확인할 수 있습니다.

 

vRSLCM도 그렇습니다만, 카드의 배치를 커스터마이즈 되었으면 좋겠네요. :)

Trackback 0 Comment 4
2018.05.19 16:04

[VMware] vRealize Automation 7.4로의 업데이트


3월 기다리고 기다리던 vRA 7.4가 릴리스되었습니다만, 업무가 바쁜 관계로 제대로 검증을 못하다가 얼마전 검증 환경을 7.4로 업데이트했습니다. 원래는 vRSLCM을 이용하여 검증 환경을 업그레이드할 생각이었습니다만, vRA와 vRB가 계속 에러가 발생하여 계획대로 않되더군요. 그래서 vRA와 vRB는 가상 어플라이언스의 관리 UI를 통해 업데이트를 실시했습니다. (vRLI와 vROps는 vRSLCM에서 업그레이드가 되었는데 말이죠...)

 

vRA의 업데이트는 [vRA 어플라이언스] [vRA IaaS 서버] → [vRO] → [vRB] 순입니다만, Embedded vRO를 이용하고 있으며 vRB는 설치하지 않은 환경이라면 지금부터 소개하는 방법으로 업데이트가 끝나리라 생각합니다.

업데이트 전에 반드시 vRA 어플라이언스,  vRA IaaS 서버의 스냅숏 작성과 IaaS DB의 백업을 잊지마세요.

 

① vRA 어플라이언스의 관리 UI에 로그인하여 [Update]탭의 [Check Updates]를 클릭합니다. vRA 어플라이언스가 인터넷 접속이 가능하다면 디폴트 레포지트리로부터 업데이트 가능할 버전이 표시될 것입니다.

 

② [Install Updates]를 클릭하여 업데이트를 시작합니다. 우선 레포지트리로부터 화일을 다운로드 하기 때문에 위의 화면 상태가 한동안(10분정도) 지속됩니다.

 

③ 업데이트용 화일의 다운로드가 끝나면 자동적으로 업데이트가 시작되어 사전체크가 실행됩니다.

 

④ 사전체크의 결과 업데이트의 조건을 만족시키고 있다면 사전설치로서 Java 등의 소프트웨어 업데이트가 실행됩니다.

 

⑤ 일단 사전 설치가 끝난 뒤 관리 UI를 확인하면 7.3에서는 없었던 탭이 추가되어있는 것을 확인할 수 있습니다.

  • Orchestrator : vRO의 서비스, Control Center의 서비스를 유효화할 수 있습니다.
  • SW Agent : SW Agent의 관리가 가능합니다.
  • Patches : vRA 관련의 패치를 적용할 수 있습니다. 왠지 여기만 HTML 5입니다.  🙂

 

⑥ 본격적인 설치(업데이트)가 시작됩니다.

 

⑦ 업데이트 도중에 vRA 어플라이언스의 재시작이 필요합니다. 재시작이 끝나면 vRA 어플라이언스의 업데이트는 끝입니다.

 

⑧ vRA 어플라이언스의 업데이트가 끝나면 자동적으로 vRA IaaS 서버의 업데이트가 시작됩니다. 자세히 보면 vRA 어플라이언스는 이미 7.4로 업데이트 되어져 있네요. 

 

⑨ 제 검증 환경의 경우는 전부 5 스텝으로 나뉘어져있습니다. 최초의 스텝은 IaaS 서버 컴포넌트의 업데이트입니다.

 

⑩ 다음에는 DEM 관련 컴포넌트입니다.

 

⑪ DEM의 업데이트가 끝났다면 이번에는 Proxy Agent가 업데이트 되어집니다.

 

⑪ Proxy Agent의 업데이트가 이어집니다. 검증 환경은 vCenter 이외의 Hyper-V 호스트에도 설치를 하였기 때문에 Hyper-V용 Proxy Agent의 업데이트도 이루어집니다.

 

⑫ 마지막 스텝으로 Model Manager 관련 컴포넌트의 업데이트가 실행됩니다. 

모든 업데이트가 완료되어 ”Upgrade completed successfully”가 표시되면 vRA 7.4로의 업데이트는 성공입니다.


제 검증 환경에서 업데이트에 걸린 시간은 약 1시간정도 였습니다.

 

다음부터는 7.4로 소개를 할 수 있네요. :)

Trackback 0 Comment 0


티스토리 툴바