'virtualization/VMware'에 해당되는 글 579건

  1. 2018.07.09 [VMware] vSAN 6.7 SSD의 초기화
  2. 2018.06.30 [VMware] vExpert 2018 후반기 응모 시작
  3. 2018.06.29 [VMware] VMworld 2018
  4. 2018.06.07 [VMware] vExpert VSAN 2018을 수상했습니다
  5. 2018.06.04 [VMware] vSAN 캐시 디스크에 장애가 발생하면 디스크 그룹이 보이지않음
  6. 2018.05.21 [VMware] vRealize Automation 7.3 (22) (4)
  7. 2018.05.19 [VMware] vRealize Automation 7.4로의 업데이트
  8. 2018.05.07 [VMware] vCenter 6.7의 고급 연결 모드에 대해서 (4)
  9. 2018.05.04 [VMware] VCSA의 백업과 복원
  10. 2018.05.01 [VMware] Windows vCenter에서 VCSA로의 마이그레이션
2018.07.09 21:27

[VMware] vSAN 6.7 SSD의 초기화


과거의 포스팅에서도 설명을 했듯이 vSAN의 ESXi 호스트는 재시작시, 캐시용 SSD상의 로그 엔트리를 처리하여 메타 데이터 테이블을 작성합니다. 때문에 non-vSAN의 ESXi 호스트보다 시간이 걸립니다.


아래 스크린숏의 "Initializing SSD~"의 메시지가 표시되는 부분이 바로 그 부분입니다만, 프로그레스바가 전혀 진행되지 않기 때문에 재기동이 실패, 멈춘 것처럼 보입니다. 서버의 전원을 눌러 강제적으로 리셋을 하고 싶어지지만, 백그라운드에서는 제대로 움직이고 있죠.(「Alt+F12」나 「Alt+F1」를 누르면 확인을 할 수 있죠)


(KB에 의하면 이 처리는 고속화되지 않는다고 합니다. 재시작의 시간이 짧아지지는 않는다는거죠) 



이것이 vSAN 6.7에서 개선되었습니다. ;)


위의 스크린숏처럼 앞으로 얼마나 걸릴 것인지 알 수 있게 되었습니다. 로그 엔트리 처리가 몇%가 끝났으며 앞으로 몇초/분 걸릴지 알 수 있기 때문에 아주 편리합니다.



더이상 보수유지시나 장애 복구시 재시작에 시간이 걸려 초조하게 모니터를 뚫어지도록 쳐다보지 않아도 됩니다. 흐흐 ;)

Trackback 0 Comment 0
2018.06.30 13:10

[VMware] vExpert 2018 후반기 응모 시작


vExpert 2018 후반기 응모가 6월 18일 시작되었습니다.





2015년부터(였던거 같습니다) 1년에 두 번 응모할 수 있게 되었죠. vExpert 프로그램에 대해서는 과거의 포스팅을 확인하세요. 매번 말합니다만 vExpert는 공식적인 자격이 아닌 명예상입니다.


그러나...


VMware사 사내에서 심사를 걸쳐 수상자를 결정했으며 수상후에는 전용 Slack 채널이나 얼리 Beta 테스트 등 가치가 적지않으니 관심있는 분들은 응모해 보시길...


vExpert 2018 Second Half Application


참고로 응모기간은 7월 13일까지이며 수상자 발표는 8월 9일로 예정되어 있습니다.


Trackback 0 Comment 0
2018.06.29 00:04

[VMware] VMworld 2018




Possible Begins With You



가상화/클라우드 업계의 글로벌 컨퍼런스로써는 최대 규모일 VMworld도 15년째를 맞이합니다. 2004년 1회의 함가자는 약 1,500명 정도였다고 합니다만, 작년 2017년의 참가자는 30,000명을 넘었다고 합니다. 올해도 30,000명 이상의 이 참가를 하지 않을까 싶네요.


올해도 참가할 수 있기를 바라면서 VMworld의 매력에 대해서 간단히 소개를 할까합니다.(물론 개인적인 의견입니다)


 듣고 싶은 세션이 반드시 있습니다.

얼마전 공개된 컨텐트 카탈로그(세션 리스트)를 보면 US는 632, 유럽은 387의 세션(미니 씨어터, 인스트럭터-리드 HOL 등을 포함)이 있었습니다. 거의 모든 프로덕트의 세션이 있으므로 듣고 싶은 세션이 반드시 있습니다. 듣고 싶은 세션만으로도 시간이 부족할지 모르겠네요. 흐흐


■ 세션에 집중할 수 있습니다.

당연히 모든 세션은 영어로 진행됩니다. 집중해서 세션을 들을 수 있습니다. 잠시라도 딴생각을 하면 순식간에 뭔소리를 하는건지 모르게 되거든요. 이상하게도 전혀 안졸려요. 흐흐 


■ 축제분위기입니다.

vForum과는 달리 축제 분위기를 느낄 수 있습니다. 혼자라도 꽤 즐겁게 시간을 보낼 수 있습니다. ;)


■ 타국의 엔지니어에게 자극을 받습니다.

궁금한 내용은 세션중이라도 질문을 하거나 Meet the Experts 라운드 테이블에서 VMware의 엔지니어와 얘기를 하기위해 행렬이 이루고 있는 참가자들을 보면 이벤트를 즐기면서도 적극적으로 알려고 하는 자세에 의외로 자극을 받습니다. 아울러 외국 엔지니어와 친해질 수도 있죠. ;)


올해의 VMworld는 라스베가스와 바르셀로나에서 개최됩니다.


VMworld 2018 US 

2018/8/26-30 라스베가


VMworld 2018 Europe

2018/11/5-8 바르셀로나

























Trackback 0 Comment 0
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.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
2018.05.07 19:26

[VMware] vCenter 6.7의 고급 연결 모드에 대해서


대규모 환경이나 여러 거점이 있어 각각 vSphere 환경이 있을 경우, 운용이 번잡하죠. 각 환경을 관리하기 위해서는 각 환경의 vCenter에 접속하지 않으면 않되기 때문이죠. 이것을 해결하기 위한 기능이 "고급 연결 모드"입니다.


고급 연결 모드는 여러 vCenter를 하나의 관리 UI(Web Client)에서 관리할 수 있게 해줍니다. 고급 연결 모드를 구성하면 PSC 사이에 SSO 정보는 물론 롤이나 권한, 정책 등이 복제됩니다.


이 고급 연결 모드, vCenter 5에서는 ”연결 모드”로 불렸습니다. 이 연결 모드가 PSC와 vCenter의 아키텍쳐로 크게 바뀐 vCenter 6부터 ADAM을 의존하지 않게되어 VCSA에서도 구성이 가능한 ”고급 연결 모드”로 개선된 것이라고 할 수 있습니다.


vCenter 6.5까지는 이 고급 연결 모그를 구성하기 위해서는 PSC를 Embedded가 아닌 External PSC로 설치를 할 필요가 있었습니다. 이건 이거대로 번잡해지는데요... External PSC는 VCHA를 구성할 수 없기 때문입니다. vCenter는 VCHA를 구성하면 간단히 가용성을 확보할 수 있습니다만 External PSC는 결국 NSX나 3rd Party의 로드 밸런서에 의존할 수 밖에 없었기 때문입니다.


6.7부터는 Embedded PSC에서도 고급 연결 모드를 구성할 수 있게 되었습니다. 이로써 더욱 간단히 고급 연결 모드를 구성할 수 있게 되었습니다. 가용성도 로드 밸런서 없이 VCHA를 구성하기만 하면 되죠. :)





고급 연결 모드를 구성하는 방법은 아주 간단합니다. 우선 최초의 VCSA(Embedded PSC)를 설치합니다. (제 경우는 이전에 WIndows vCenter에서 VCSA로 이행 & 업그레이드한 VCSA 6.7를 이용했습니다)


최초의 VCSA가 설치되었다면 2번째 VCSA(Embedded PSC)를 설치합니다. 설치중 스테이지 2의 [SSO 설정]에서 [기존SSO 도메인에 참가]를 선택하여 처음에 설치한 VCSA를 지정해주기만 하면 됩니다.

 

2번째 VCSA 설치후 HTML5 Client에 접속을 해보면 인벤토리에 2대의 vCenter가 표시되는 것을 확인할 수 있습니다. 여기서 SSO로 Active Directory 도메인을 추가하면 양쪽 다 AD 도메인 계정으로 접속, 관리를 할 수 있습니다.

 

며칠전 vSphere 6.5 Update 2도 릴리스되었습니다. vCenter 6.5 U2는 vCenter 6.7의 기능이 그대로 이식되어 Embedded PSC의 고급 연결 모드가 구성 가능하다고 합니다.


※주의!!!! 

현시점(2018년 5월 6일)에서는 vSphere 6.5 Update 2로부터 vSphere 6.7로의 업그레이드는 지원을 하지않습니다.


vSphere 6.7 로 업그레이드를 검토중인 경우는 vSphere 6.5 Update 2로는 업그레이드하지 마세요.



Trackback 0 Comment 4
2018.05.04 17:21

[VMware] VCSA의 백업과 복원



※ 일본어 환경의 캡쳐를 이용하고 있습니다.



VCSA 6.5부터 VCSA의 가용성을 높이는 기능이 2가지 추가되었습니다. "vCenter High Availability(VCHA)"와 "네이티브 백업(화일 베이스 백업)"이 그것입니다. VCHA에 대해서는 과거에 소개를 했었으니 이번에는 네이티브 백업(화일 베이스 백업)"에 대해서 소개를 할까 합니다.


VCSA 6.0까지는 화일 베이스의 백업이나 DB만을 백업하는 것은 지원을 하지 않았습니다. 따라서 VDP나 3rd 파티의 백업 솔루션을 이용하여 VCSA 전체를 백업해야되었습니다. 하지만 6.5부터 화일 베이스의 백업이 가능하게 되어 간단히 필요한 데이터를 백업할 수 있게 되었습니다.


또한 6.7에서는 백업을 정기적으로 돌릴 수 있는 일정이 가능하게 되어, 더이상 VCSA의 백업에 대해서 고민할 필요가 없어졌습니다. ;)



(1) VCSA의 백업

우선 수동으로 백업을 실행해보도록 하겠습니다.


① VCSA 관리 페이지의 [Backup]을 선택, [지금 백업]을 클릭합니다.


② 다음의 정보를 입력후 [시작]을 클릭합니다.

    • 백업 위치 : 백업 서버의 정보입니다. 전 점프서버에 FTP 서버를 설치했습니다. FTP 이외에 HTTP, HTTPS, SCP, FTPS를 이용할 수 있습니다.

    • 백업 서버 자격 증명 : 백업 서버의 자격 증명을 입력합니다.

    • 암호화(옵션) : 백업 데이터의 암호화를 할 경우, 암호를 지정합니다.

    • 데이터 : 백업 데이터를 선택합니다. 구성정보는 물론 이벤트나 통계 정보도 백업을 할 수 있습니다.



③ 백업이 실행됩니다.


④ 백업 상태가 완료된 것이 확인되면 끝입니다. ;)


⑤ 백업 서버에서는 저장된 백업 데이터를 확인할 수 있습니다.



(2) VCSA의 복원

이번에는 복원을 해보겠습니다. 복원이라고 해도 VCSA를 가상 어플라이언스로 복원하는 것은 아닙니다. 새롭게 VCSA를 전개후 데이터를 복사하는 형태입니다.


① VCSA 설치 마법사는 시작하여 [복원]을 선택합니다.


② 스테이지 1의 구성을 시작합니다.


③ EULA 동의후 복원할 백업의 정보를 입력합니다.

    • 위치 또는 IP 어드레스/호스트 이름 :  백업 데이터의 절대경로(backup-metadata.json 화일이 저장되어있는 폴더)

    • 유저 이름 : 백업 서버의 유저 이름

    • 패스워드 : 백업 서버의 유저의 패스워드


④ 검출된 백업의 정보를 확인루 [Next]를 클릭합니다.


⑤ 여기서부터는 새롭게 전개할 VCSA의 정보를 입력합니다. 이 부분은 새롭게 VCSA를 전개하는 방법과 동일하므로 소개를 하지않겠습니다.


⑥ 네트워크 정보는 백업 데이터로부터 정보가 자동적으로 반영되므로 새롭게 입력을 할 필요는 없습니다만, 네트워크 포트 그룹만은 올바르게 지정을 해줘야 됩니다.


⑦ [완료]를 클릭하여 VCSA의 전개를 시작합니다.


⑧ HTML5 Client에서도 새롭게 전개되는 VCSA를 확인할 수 있습니다.


⑨ VCSA의 전개가 끝났다면 계속해서 스테이지 2로 진행을 합니다.


⑩ 다시금 백업 서버의 자격 증명 정보를 입력후 [Next]를 클릭합니다.


⑪ 복원 대상의 VCSA가 아직 동작중이라면 정지후 [종료]를 클릭합니다.


⑫ 복원이 시작됩니다.


⑬ VCSA의 복원이 정상적으로 완료되었습니다.


⑭ VCSA의 관리 페이지로 접속을 하여 전체 상태에 이상이 없는 것을 확입니다.


⑮ HTML5 Client로 접속을 하여 데이터센터, 클러스터, 호스트 등 복원하기 전과 차이가 없는 것을 확인합니다.



(3) VCSA 백업의 일정

VCSA 6.5에서는 이 일정 기능이 없었기에 매번 관리자가 직접 백업을 실행하거나 스크립트를 짜서 운용할 수 밖에 없었습니다만, VCSA 6.7에서는 대망(?)의 백업 실행 일정을 설정할 수 있게 되었습니다.


① 백업 일정의 [편집]을 클릭합니다.


② 수동으로 백업을 실행했던 것과 동일하게 백업 정보를 입력합니다. 기본적인 백업 정보이외에 "일정"과 "보존할 백억 수"를 추가로 설정후 [저장]을 클릭합니다. 설정이 가능한 백업 일정은 "일단위", "주단위", "요일단위"입니다.


③ 백업 일정이 작성된 것을 확인합니다. 참고로 백업 일정은 하나만 작성을 할 수 있으며 작성한 백업 일정은 삭제하지않고 "사용 안 함" 설정도 가능합니다.



백업 서버만 준비가 된다면 아주 간단히 백업을 작성하거나 일정을 설정할 수 있습니다. 복원 자체도 간단합니다. VCSA에 관해서는 별도의 백업 솔루션을 이용할 필요가 없습니다. 



VCSA를 도입한 관리자 분들은 빨리 6.7로 업그레이드하여 백업에 고민으로부터 해방되시길... :)







Trackback 0 Comment 0
2018.05.01 01:00

[VMware] Windows vCenter에서 VCSA로의 마이그레이션


얼마전에 vSphere 6.7이 릴리스되었죠.

Introducing VMware vSphere 6.7!

 

이번 버전은 vCenter Server로써는 특별한 버전입니다. 왜냐하면 이번 버전 6.7은 Windows vCenter를 지원하는 마지막 버전이 되기 때문입니다. 정확하게 말하자면 지원은 하지만 Windows vCenter은 ”비추천”이 되어버린 버전입니다. (이 내용에 대해서는 과거의 포스팅을 확인하세요)

 

그렇다면 말입니다... Windows vCenter를 이용하는 환경이라면 언젠가는 VCSA로의 마이그레이션이 필요하다는 말이 되죠. 아마도... 18개월에서 24개월 정도일까요? 물론 6.5 이하의 버전을 계속 이용한다면 가능한 Windows vCenter의 연명이 가능할지도 모르겠습니다만, vSphere 환경을 계속적으로 이용을 한다면 언젠가는 VCSA로의 이사가 필요합니다.

특히 vSphere 5.5를 운용중인 환경일 경우, 올해 9월 18일로 general Support가 종료되기 때문에 꽤나 심각하게 VCSA로의 마이그레이션을 검토해야 됩니다.

 

제 테스트 환경에도 Windows vCenter가 몇대 있기에 6.7 릴리스 기념(?)으로 VCSA로 이사를 해봤습니다. ;)

참고로 Windows vCenter 6.0 U2로부터 VCSA 6.7로 업그레이드함과 동시에 이행했습니다.


그렇다면 간단하게 소개를 하도록 하죠.

 

우선 마이그레이션을 하기 위해서는 "사전체크"를 실시해야 됩니다.


Windows vCenter에 VCSA 6.7 iso 이미지를 마운트하여 화일내의 ”migration-assistant\VMware-Migration-Assistant.exe”를 실행합니다.

 

② migration assistant가 시작되었다면 administrator@vsphere.local의 패스워드를 입력합니다. migration assistant가 정상적으로 vCenter에 접속되었다면 자동적으로 이행에 필요한 ”사전체크”가 시작됩니다. ”사전체크” 결과, 이행 조건을 만족시키고 있는 상태라면 프롬프트에 ”Waiting for migration to start…”가 표시됩니다. 이로써 이행준비 끝입니다.

※ 이 migration assistant는 이행이 끝날때까지 닫지않도록 주의합니다.

 

③ 이번에는 이행 작업을 실시할 서버에 VCSA 6.7 iso 이미지를 마운트하여 ”vcsa-ui-installer\win32\installer.exe” 화일을 실행합니다. 설치마법사가 시작되면 「Migrate」를 클릭합니다.

※ VCSA의 설치마법사는 Windows vCenter 에서는 실행하지 마세요. 당연한거지만 이행중 Windows vCenter가 정지되기 때문에 이행작업을 이어나갈 수 없습니다.

 

④ 처음에 얘기했듯이 ”이행”도 ”설치”와 같은 프로세스입니다. 스테이지 1에서 VCSA를 전개하여 스테이지 2에서 VCSA를 구성하는 순으로 진행됩니다. [NEXT]를 클릭합니다.

 

⑤ EULA에 동의합니다.

 

⑥ Windows vCenter의 정보를 입력후 [NEXT]를 클릭합니다.

 

⑦ Windows vCenter의 증명서를 받아들입니다.

 

⑧ migration assistant를 확인해보면 네트워크의 정보가 확인되어집니다.

 

⑨ VCSA의 전개할 환경 정보를 입력후 [NEXT]를 클릭합니다.

 

⑩ 자기 증명서의 경고를 받아들입니다.

 

⑪ VCSA를 전개할 데이터센터를 선택후 [NEXT]를 클릭합니다.

 

⑫ VCSA를 전개할 클러스터를 선택후 [NEXT]를 클릭합니다.

 

⑬ 전개할 VCSA의 이름, root 패스워드를 설정후 [NEXT]를 클릭합니다.

 

⑭ VCSA의 사이즈를 결정합니다.

 

⑮ VCSA를 전개할 데이터스토어를 선택후 [NEXT]를 클릭합니다.

 

⑯ 이행에 필요한 일시적인 네트워크를 설정후 [NEXT]를 클릭합니다.

 

⑰ 설정 내용을 확인후 [FINISH]를 클릭합니다.

 

⑱ 스테이지 1이 시작되어 VCSA가 새롭게 전개됩니다.

 

⑲ 스테이지 1이 끝나 VCSA가 전개되었습니다. 계속해서 스테이지 2를 진행합니다.

※ 스테이지 1이 끝난 상태에서는 Windows vCenter에 영향은 없습니다. 단지 여기서 일단 이행 작업을 중지, 스테이지 2를 나중에 실행할 경우는 순서 ①의 migration assistant를 다시금 실행해야할 필요가 있습니다.

 

⑳ 스테이지 2의 마법사를 시작합니다.

 

㉑ 스테이지 2를 시작하면 ”사전체크”가 새롭게 실행되어 네트워크 구성을 재확인함과 동시에 migration assistant의 로그가 VCSA로 복사되어집니다.

 

㉒ Active Directory의 정보를 입력합니다. Windows vCenter가 AD 도메인에 참가된 상태였기 때문에  새롭게 전개한 VCSA도 AD 도메인에 참가시킵니다.

 

㉓ 이행할 데이터를 결정합니다. 또한 이행시 발생하는 다운타임도 확인을 할 수 있습니다.

    Configuration : 구성정보만을 이행합니다.

    Configuration and historical data (events and tasks) : 구성정보를 포함하여 이벤트, 태스크의 이력도 이행을 합니다.

    Configuration and historical data (events, tasks and performance metrics) : 구성정보를 포함하여 이벤트, 태스크, 성능 메트릭의 이력도 이행을 합니다.

선택한 데이터는 VCSA의 시작을 우선시 할지, 데이터의 이행을 우선시할지를 선택할 수 있습니다.

제 경우는 모든 데이터의 이행을 우선시하도록 선택을 하였습니다. 40분정도 다운타임이 발생하는거 같네요. 😉

 

㉔ CEIP의 참가여부를 선택합니다.

 

㉕ 이행에 필요한 정보가 제대로 설정되었는지 확인을 합니다. 문제가 없다면 VCDB의 백업실행후 [FINISH]를 클릭합니다.

 

㉖ 여기서 경고가 표시됩니다. [OK]를 클릭하면 Windows vCenter가 정지됩니다. [OK]를 클릭합니다.

 

㉗ 이행이 시작됩니다.

 

㉘ migration assistant에서도 데이터의 이행이 시작되는 것을 확인할 수 있습니다.

※ 데이터 이행이 끝나면 자동적으로 정지됩니다.

 

㉙ 데이터 이행이 끝나 Windows vCenter가 정지되었습니다. 잘못해서 시작하지 않도록 주의하세요. 🙂

 

㉚ 이행은 순서 ㉓에서 표시된 예상시간보터 일찍, 약 30분 정도 걸렸습니다.

 

㉛ 무사히 VCSA로 이행되었으므로 가상 어플라이언스의 관리 페이지에 접속해 보도록 하죠. 로그인후 헬스 상태를 확인합니다. VCSA 6.7부터는 GUI에서도 각 서비스의 정지/시작을 할 수 있는 [서비스]가 추가되었네요. 

 

㉜ HTML5 Client에도 접속을 해보겠습니다. 문제없이 데이터센터, 클러스터, 호스트 등의 오브젝트 정보가 표시되는 것을 확인할 수 있었습니다.

 

이행은 의외로 간단히 끝났습니다. 걸린 시간도 어느정도 설치마법사에서 표시된 시간과 크게 차이가 없었습니다. 또한 이행후 동작을 확인해봤습니다만 문제없이 이행되어있었습니다.

오랫동안 Windows vCenter를 운용해온 관리자로써는 VCSA의 허들이 꽤 높게 보일 수 있을겁니다. 하지만 그런 걱정은 할 필요없습니다. 기본적으로 VCSA를 콘솔이나 SSH로 접속하여 관리할 필요가 없고, 예를들어 6.0 이후는 Windows vCenter에서도 관련 서비스는 ”services.msc”이 아닌 ”service-control” 명령어를 이용해야되는 등 Windows vCenter에서도 VCSA에서도 운용의 경계가 거의 없어졌기 때문이죠. 더군다나 VCHA나 네이티브 백업 등 새로운 기능은 VCSA에서만 제공되기 때문에 이행하지않을 이유가 없습니다.


Windows vCenter를 운용중인 관리자분들은 VCSA로의 마이그레이션을 검토하시길 바랍니다.

 





Trackback 0 Comment 0


티스토리 툴바