2018.11.13 00:16

[VMware] VMworld 2018 Europe 참석기 Day 1

지난 주 VMworld 2018 Europe에 다녀왔습니다. 운이 참 좋은거 같습니다. ;)

간단히 하루하루 들은 세션 내용을 소개할까 합니다.



첫날입니다. 일기예보에서는 오후부터 비가 내릴 것이라고 했습니다만 점심때 조금 내리고는 저녁까지 버텨줬습니다.  작년에는 개최장소와 호텔만을 이동할 정도로 관광에는 그다지 관심이 없었습니다만 이번엔 관광 비슷한 것도 했습니다. 나름대로 충실한 하루였죠. ;)


오전에는 예정이 없었던지라 구웰 공원(Park Güell)에 다녀왔습니다. 역시나 바르셀로나, 관광객이 정말 많더군요. 구웰 공원은... 역에서 멀었습니다.  꽤나 급한 경사길이었고요... 😉

 

적당히 패시지 데 그라시아(Passeig de Gràcia)에서 점심을 해결하고 오후에는 개최장소인 피라 데 바르셀로나 그란비아(Fira Barcelona - Gran Via)에서 참가 등록을 끝내고 Alumni Lounge도 들렸습니다. Alumni Lounge는 3회 이상 VMworld에 참석자들이 이용할 수 있는 장소입니다. 뭐 그다지 특별한 것은 없지만 전용 음료 서비스가 있죠. ;) 올해는 이제까지와는 달리 등록을 하면 받을 수 있는 것은 백팩뿐이었습니다. 작년까지는 백팩에 티셔츠니 물통이니 이런저런 노벨티가 들어있었습니다만 올해는 등록하면 받을 수 있는 것은 백팩뿐이고 개최기간중에 4개의 목표를 달성해야 받을 수 있었습니다. 예를들어 브레이크아웃 세션 4개와 키노트 세션 하나 들으면 티셔츠를 받을 수 있죠. 개인적으로 백팩대신 티셔츠를 받는 것이 좋습니다만..😉


 

오늘 들은 세션은 하나뿐이었습니다.

 

【VMs on vSAN – An End to End View】

30분의 짧은 세션으로 vSAN 6.7 U1의 데모가 중심이었습니다.

전반에는 vSAN의 개요에서부터 구성 방법의 소개 등의 기본적인 내용이었습니다만 후반은 VMware Cloud on AWS과 SRM을 구성한 데모였습니다만 이게 꽤 인상적이었습니다. 온프레미스에 10 호스트로 구성한 vSAN 클러스터와 3 호스트 구성의 vSAN 클러스터가 AWS상에 있는 환경에서 온프레미스 사이트가 전부 정지한 시나리오였습니다만 AWS쪽으로 페일오버될 때 부족한 7 호스트가 자동적으로 추가되는 Elastic DRS로 완벽하게 온프레미스의 모든 가상 머신이 올라오더군요. 흐흐

온프레미스와 AWS 사이의 SRM과 Elastic DRS를 구성한다면 최소한의 비용으로 DR 환경이 준비되니 서비스가 시작된다면 검토하는 고객도 많아질거 같네요. ;)

 

내일부터 General Session를 시작으로 본격적인 VMworld 2018 Europe입니다.

 

PS> 여담입니다만 아직도 vSphere HA와 DRS를 이용하지 않는 유저가 많다고 발표자가 한탄하더군요.  그렇다면 Standard 에디션에서도 DRS 쓰게 해주시길! ;)

Trackback 0 Comment 1
2018.11.05 23:44

[VMware] vSphere 업그레이드 가이드


vSphere 환경의 업그레이드를 검토하고 계신 분들에게 좋은 사이트가 공개되었습니다.

vSphere Central



vSphere Central은 vSphere 관련의 순서나 기능 소개를 모아놓은 사이트입니다만, 여기에 vSphere Upgrade의 내용이 추가되었습니다.



내용은 vSphere Upgrade에 필요한 전제 조건의 확인부터 vCenter, ESXi, vDS 등의 컴포넌트 업그레이드 순서, 업그레이드후의 태스크가 깔끔하게 정리되어있네요.


아직 6.5에서의 업그레이드밖에 없습니다만 조만간 6.0도 포함될 것을 기대해야겠네요. ;)



Trackback 0 Comment 0
2018.11.03 11:10

[VMware] vCenter HA 구성 - 6.7U1 버전


지난 번에 Embedded PSC로 전환한 vCenter를 VCHA로 구성을 했기에 간단히 소개를 할까 합니다.



VCHA에 대해서는 과거에 소개한 적이 있습니다만 당시는 버전 6.5였습니다. 6.5애서는 VCHA를 구성하는 대상 vCenetr가 어느 클러스터에서 가동중인지에 따라서 ”Basic”과 ”Advanced”의 구성으로 나뉘어져 구성 방법도 달랐었죠. 6.7이 되었어도 HTML5 Client에서는 VCHA를 구성을 지원하지 않았기 때문에 Flash Web Client에서 구성해야 되었기에 결국은 6.5와 동일한 마법사를 통해야 되었죠.


이것이 6.7 U1에서 드이어! HTML5 Client에서도 구성을 할 수 있게 되었습니다. 2 타입이었던 구성 방법도 하나로 통일되었습니다. (゚∀゚)



그러면 간단히 구성 방법을 소개하도록 하겠습니다.


① HTML5 Client에 접속하여 [vCenter HA]의 셋업을 진행합니다. 보세요. 이 심플한 Clarity 디자인! 맘에 듭니다. ;)


② 우선은 Active-Passive-Witness 사이에서 통신할 하트비트용 네트워크를 지정합니다.


③ 다음에는 새롭게 전개할 Passive와 Witness용 vCenter의 네트워크, 하트비트용 네트워크, 전개할 데이터스토어를 지정합니다.


④ 각 vCenter에서 하트비트용 네트워크의 IP 어드레스 정보를 지정하면 OK입니다. 이걸로 구성을 시작할 수 있습니다.


⑤ 화면 중앙의 VCHA 개요를 보면 Active만이 ”UP”의 상태이며 Active vCenter를 베이스로 Passive, Witness용 vCenter가 클론되어지고 있는 것을 확인할 수 있습니다.


⑥ Passive, Witness용 vCenter가 전부 전개되어 모든 vCenter가 ”UP” 상태인 것을 확인할 수 있습니다. VCHA 구성 직후는 Active-Passive 사이에서 데이터베이스나 설정 정보 등의 복제중이기 때문에 경고가 표시됩니다만, 레플리케이션이 끝나면 경고는 자동적으로 사라집니다.


⑦ Active-Passive 사이의 데이터 복제가 끝나, 경고가 사라진 상태입니다. 이 상태가 VCHA 구성후의 정상적인 상태라고 할 수 있습니다.



그러면 Active vCenter를 Power-off하여 VCHA의 움직임을 확인해 보겠습니다.


Active vCenter 정지로부터 약 32초후 ”이 사이트에 연결할 수 없습니다”란 부라우저 에러가 표시되었습니다. 이것은 vCenter 서버 자체에 도달하지 못한다는 의미이므로 Active vCenter 는 완전히 정지한 것을 알 수 있습니다.


Active vCenter 정지로부터 약 1분 57초후에는 “404 Not Found”가 표시되었습니다. 404 에러가 표시되었으니 Passive vCenter로 접속이 바뀐 것을 알 수 있습니다. ;)


Active vCenter 정지로부터 약 2분 5초후에는 “Failover in progress”가 표시되었습니다. 그대로네요. 현재 Passive vCenter가 Active로 승격하기 위해 데이터베이스나 설정을 변경하거나 서비스를 시작중일 겁니다. 이 상태가 한동안 이어집니다.


Active vCenter 정지로부터 약 6분 42초후 겨우서야 Web 서비스가 시작을 하기 시작했네요. 😉


Active vCenter 정지로부터 약 7분 40초후 Failover가 끝났습니다. 


HTML5 Client에서 확인을 해본면 Passive가 Active로 승격되어있는 것을 확인할 수 있습니다. Active vCenter의 관리 IP 어드레스도 정상적으로 인계가 되어 있네요.


 

구성은 상당히 간단히 할 수 있습니다만 Failover에 걸리는 시간은 6.5와 비교를 해도 그다지 개선된 것 같지는 않네요. 흐흐 ※여기서 소개를 한 시작은 제 검증환경의 경우입니다. 당근, 환경이 규모나 vCenter의 사이즈 등에 의해서 Failover에 걸리는 시간은 달라지므로 참고만 하시길...  ;)



ESXi 호스트의 장애에 대해선 vSphere HA로, vCenter OS 장애에 대해서는 이 VCHA로 가용성을 확보하면 vCenter의 가용성은 상당히 강화됩니다. Failover에 7분이나 걸리면 어디 쓰겠나? 라고 생각하실지 모르겠습니다만, 백업 데이터로부터 복구할 필요도 없고, Failover후 Passive를 재디플로이하기만 하면 복구되는 것을 생각해보면 당장 구성하고 싶어지지 않습니까?  😉



Trackback 0 Comment 0
2018.10.30 20:14

[VMware] External PSC를 Embedded PSC로 변경


vCenter 6.5에서 추가된 VCHA로 vCenter의 가용성이 높아졌습니다. VCHA를 유효화하여 Active-Passive-Witness의 하트비트용 IP 어드레스를 설정하기만 하면 간단히 구성할 수 있기 때문이죠.


단지 이 VCHA는 vCenter만을 지원하는 것이 약점이었습니다. 뭔말인가 하면 External PSC는 VCHA를 구성할 수 없기 때문입니다.아시는대로 PSC는 SSO나 증명서 서비스, 라이센스 서비스 등을 제공하고 있기 때문에 이녀석이 죽어버리면 vSphere Client에도 로그인할 수 없을정도로 중요하죠.


이런 PSC의 가용성을 높이기 위해서는 NSX나 3rd 파티의 로드 밸런서를 이용하여 이중화할 방법뿐입니다. 아니면 애시당초 Embedded PSC로 구성을 하여 VCHA로 이중화를 하면 됩니다만 이건 이거대로 간단하지않는게... 확장 링크 모드를 구성할 셩우는 External PSC가 필수이기 때문이죠. (;´д`)=3 여기까지는 vCenter 6.5의 경우입니다.


PSC는 VCHA를 구성할 수 없다는게 뭔 말임? 추가로 LB를 도입해야 비용은 누가 대주남?

등 이런저런 불만이 있었나 보죠.


vCenter 6.7에서는 Embedded PSC에서도 확장 링크 모드를 구성할 수 있게 되었습니다.이렇게되면 External PSC 구성이 필요한 시나리오가 많이 줄어, 거의 대부분 Embedded PSC의 구성으로도 충분하게 되었습니다. 여기까지가 vCenter 6.7의 경우입니다.


헉? 어처구니가 없네... 이미 External PSC로 구성한 사내 환경은 어쩌라는거임?

등 이런 저런 불만이 있었나보죠. ( ̄▽ ̄)


이번에 릴리스된 vCenter 6.7 U1에서 External PSC를 Embedded PSC로 전환할 수 있게 되었습니다. ( ̄▽ ̄;) 전환이라는 단어를 썼습니다만 실제로는 vCenter에 External PSC의 부분을 통합하는 것입니다.


vCenter 6.7 U1의 미디어에는 컨버전스 툴(convergence tool)이 내포되어있어, 이 툴을 이용하면 External PSC를 Embedded PSC로 전환하여 External PSC를 폐지할 수 있습니다.


 

이번 포스팅에서는 External PSC를 Embedded PSC로 전환하는 방법을 소개하도록 하겠습니다.


우선 이 툴을 이용하기 위한 전제 조건을 소개하겠습니다.

  • 이 툴은 VCSA만 이용할 수 있습니다. Windows vCenter의 경우는 먼저 VCSA로 마이그레이션해야 됩니다.
  • vCenter, External PSC 둘다 6.7 U1로 업데이트되어 있어야 됩니다.
  • DRS를 구성하였을 경우 자동화 레벨을 ”일부 자동화”나 ”수동”으로 변경을 해둬야 됩니다.
  • 이 툴을 Windows 10 이전의 Windows 버전에서 실행을 할 경우는 Visual C++ 재배포 팩키지 버전 14.0 이상이 설치되어 있어야 됩니다.

 

컨버전스 툴을 이용하여 External PSC를 통합하는 흐름은 다음과 같습니다.



먼저 대상 vCenter와 External PSC를 6.7 U1로 업데이트합니다. 제 환경은 6.7이라서 각각의 VAMI에서 Update 1로 올렸습니다.



vCenter, External PSC 모두 6.7 U1이 되었다면 vCenter 6.7 U1 미디어를 작업 PC에 마운트하여 아래의 폴더에서 ”converge.json” 화일을 다운로드합니다.


I:\vcsa-converge-cli\templates\converge


다운로드한 화일을 환경에 맞춰 파라메터를 변경합니다.


※ ”managing_esxi_or_vc” 부분입니다만, 컨버전스 타겟의 vCenter 자신이 관리하고 있는 클러스터내에서 움직이고 있을 경우는 vCenter가 가동중인 ESXi 호스트를 지정합니다.이게 전제 조건의 하나인 DRS 레벨을 ”일부 자동화” 이하로 변경하는 이유입니다. 또한 ”ad_domain_info”나 ”Replication” 부분은 구성하지 않았다면 삭제합니다.


 

필요한 정보를 입력하였다면 저장후, 사전 체크를 실행합니다.

PS I:\vcsa-converge-cli\win32> .\vcsa-util.exe converge 옵션 converge.json 화일 패스


↓↓↓↓↓↓↓↓


PS I:\vcsa-converge-cli\win32> .\vcsa-util.exe converge –no-ssl-certificate-verification –backup-taken –precheck-only –verbose C:\tmp\converge.json


참고로 이용한 옵션은 다음과 같습니다.

–no-ssl-certificate-verification : 증명서 확인을 스킵

–backup-taken : 백업 실행 여부의 확인 

–precheck-only : 사전 체크만 실행

–verbose : 처리 메시지를 표시

 


사전 체크가 문제없이 끝났다면 실제로 통합을 실행합니다. 제 경우는 사전 체크의 옵션에서 ”–precheck-only”만 삭제했습니다.

PS I:\vcsa-converge-cli\win32> .\vcsa-util.exe converge –no-ssl-certificate-verification –backup-taken –verbose C:\tmp\converge.json


검증 환경이라서 그런지 5분정도 걸렸습니다. AD 도메인에도 참가한 상태였기 때문에 마지막 처리에 AD 도메인에 재참가가 이루어졌습니다.


vSphere Client에서 보면 오오! Embedded PSC로 되어있네요. 그위의 k-psc04는 이번 통합 대상의 External PSC로 지금부터 폐지할 예정입니다.


폐지전에...


무사히 Embedded PSC로 전환이 되었다면 PSC를 인증 서비스로 등록했던 솔루션의 PSC를 Embedded PSC로 변경을 합니다. 제 경우는 NSX Manager와 vRealize Replication였습니다.



그렇다면 필요없어진 External PSC를 폐지하겠습니다.


이번에는 아래의 폴더에서 ”decommission_psc.json” 화일을 다운로드하여 사용합니다.


I:\vcsa-converge-cli\templates\decommission


 다운로드한 화일의 파라메터를 환경에 맞춰 변경합니다.


필요한 정보를 입력했다면 저장후, 동일하게 사전 체크를 합니다.

PS I:\vcsa-converge-cli\win32> .\vcsa-util.exe decommission 옵견 decommission_psc.json 화일 패스


↓↓↓↓↓↓↓↓


PS I:\vcsa-converge-cli\win32> .\vcsa-util.exe decommission –no-ssl-certificate-verification –backup-taken –precheck-only –verbose C:\tmp\decommission_psc.json



사전 체크가 문제없이 끝났다면 실제로 External PSC를 폐지합니다. 사전 체크의 명령어로부터 ”–precheck-only” 옵션을 삭제, 다시금 명령어를 실행합니다.

PS I:\vcsa-converge-cli\win32> .\vcsa-util.exe decommission –no-ssl-certificate-verification –backup-taken –verbose C:\tmp\decommission_psc.json



폐지 처리도 5분 정도 걸린거 같습니다. 처리가 끝나면 자동적으로 External PSC는 셧다운됩니다.


vSphere Client를 확인해보면 External PSC의 k-psc04가 사라진 것을 확인할 수 있습니다. 이걸로 끝입니다. 😉


 


어떤가요? 생각보다 간단히 External PSC를 Embedded PSC로 통합되었습니다. 이걸로 VCHA를 구성하여 PSC도 vCenter도 전부 가용성을 확보하게 되었네요. 😉



Trackback 0 Comment 0
2018.10.14 08:34

[Nutanix] NTC 2019 응모 개시


2019년 NTC 프로그램의 응모가 10월 9일 시작되었습니다.




2019 Nutanix Technology Champion Applications Are Open!

 


NTC는 아래의 취지처럼 IT업계나 커뮤니티에서 Nutanix의 기술에 대한 전파를 꾸준히 하고있는 이른바 테크놀러지 엠버서더입니다. NTC에 대한 자세한 내용은 여기여기를 확인하세요.


This program recognizes Nutanix enterprise cloud experts for their ongoing and consistent external contributions to the community and industry. Nutanix Technology Champions are our advocates and technology ambassadors who influence change with practical advice, and bold ideas.


2018년 Nutanix 관련의 책을 집필한 분부터 Nutanix 관련 블로그를 포스팅한 분, 커뮤니티에서 열심히 활동을 하신 분, 제안을 열심히 하신 분 등 돌이켜보면 Nutanix, AHV, CVM 등의 단어를 많이 사용하신 분들은 꼭 응모해 보세요. 😉



응모기간은 11월 9일까지로 발표는 12월로 예정되어있습니다.


Trackback 0 Comment 0


티스토리 툴바