'2017/09'에 해당되는 글 9건

  1. 2017.09.24 [VMware] vSAN 환경의 ESXi 재시작에 시간이 많이 걸림 (2)
  2. 2017.09.22 [Nutanix] IPMI 정보의 변경
  3. 2017.09.17 [VMware] VMworld 2017 Europe 참관기 #6
  4. 2017.09.15 [VMware] VMworld 2017 Europe 참관기 #5
  5. 2017.09.14 [VMware] VMworld 2017 Europe 참관기 #4
  6. 2017.09.13 [VMware] VMworld 2017 Europe 참관기 #3
  7. 2017.09.12 [VMware] VMworld 2017 Europe 참관기 #2
  8. 2017.09.11 [VMware] VMworld 2017 Europe 참관기 #1
  9. 2017.09.05 [VMware] 가상머신에 디스크추가시 씬프로비저닝이 적용않됨
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.22 19:33

[Nutanix] IPMI 정보의 변경


그다지 이용할 경우가 많지않으리라 생각됩니다만, 비망록겸...


얼마전 vSphere를 하이퍼바이저로 이용을 하는 Nutanix, 정확히는 Dell EMC의 XC 시리즈를 도입한 고객으로부터 연락을 받았습니다. Dell EMC 서버의 IPMI인 iDRAC의 IP 어드레스를 변경후, 아래와 같은 내용의 경고 메일을 받았다고 합니다.

IPMI IP address on Controller VM xxx.xxx.xxx.xxx was updated from xxx.xxx.xxx.xxx to xxx.xxx.xxx.xxx without following the Nutanix IP Reconfiguration procedure.


Impact          : The host is unreachable through the IPMI interface.

Cause           : The IP address configured in the cluster does not match the actual setting of the IPMI interface.

Resolution      : Follow the IP address change procedure in the Nutanix documentation.


Node Id         : NA

Block Id        : 11111112

Cluster Id      : 122345678884

Cluster Name    : cluster.clustername

Cluster Version : nutanix-core-el6-release-danube-4.5.2-stable-aa92c58bb4cd101868bbe59ce13350ea2237e8f3

Cluster Ips     : aaa.aaa.aaa.aaa bbb.bbb.bbb ccc.ccc.ccc

Timestamp       : Mon Sep 10 02:51:56 2017


확인을 해보니 고객은 iDRAC의 UI에서 직접 IP 어드레스를 변경했다고 합니다.


당연한 경고입니다. iDRAC에서 직접 IP 어드레스를 변경했을 경우, 그 내용은 CVM 측에서 인식을 하지 못합니다. 따라서 iDRAC의 IP 어드레스를 변경할 경우는 호스트측에서 변경을 해줘야 합니다.

변경은 Linux 공통의 명령어인 ipmitool을 이용하면 됩니다.


우선 다음의 명령어로 현상태를 확인합니다.

[root@esx-3:~]  /ipmitool lan print 1

Set in Progress         : Set Complete

Auth Type Support       : MD5

Auth Type Enable        : Callback : MD5

                        : User     : MD5

                        : Operator : MD5

                        : Admin    : MD5

                        : OEM      :

IP Address Source       : Static Address

IP Address              : 10.3.12.213

Subnet Mask             : 255.255.255.0

MAC Address             : 74:e6:e2:fc:9d:3a

SNMP Community String   : public

IP Header               : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10

BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled

Gratituous ARP Intrvl   : 2.0 seconds

Default Gateway IP      : 10.3.12.254

Default Gateway MAC     : 00:00:00:00:00:00

Backup Gateway IP       : 0.0.0.0

Backup Gateway MAC      : 00:00:00:00:00:00

802.1q VLAN ID          : Disabled

802.1q VLAN Priority    : 0

RMCP+ Cipher Suites     : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14

Cipher Suite Priv Max   : Xaaaaaaaaaaaaaa

                        :     X=Cipher Suite Unused

                        :     c=CALLBACK

                        :     u=USER

                        :     o=OPERATOR

                        :     a=ADMIN

                        :     O=OEM


위의 명령어를 실행하므로써 현재의 네트워크 정보를 확인할 수 있습니다.


다음에는 아래의 명령어를 실행하여 설정이 가능한 상태로 전환을 합니다.

[root@esx-3:~] /ipmitool lan set 1 ipsrc static


다음에는 아래의 명령어를 실행하여 새로운 네트워크 정보를 설정합니다.

[root@esx-3:~] /ipmitool lan set 1 ipaddress 10.3.12.3

Setting LAN IP Address to 10.3.12.3

[root@esx-3:~] /ipmitool lan set 1 netmask 255.255.255.0

Setting LAN Subnet Mask to 255.255.255.0

[root@esx-3:~] /ipmitool lan set 1 defgw ipaddr 10.3.12.254

Setting LAN Default Gateway IP to 10.3.12.254


다시금 아래의 명령어를 실행하여 설정한 정보를 확인합니다.

[root@esx-3:~]  /ipmitool lan print 1

Set in Progress         : Set Complete

Auth Type Support       : MD5

Auth Type Enable        : Callback : MD5

                        : User     : MD5

                        : Operator : MD5

                        : Admin    : MD5

                        : OEM      :

IP Address Source       : Static Address

IP Address              : 10.3.12.3

Subnet Mask             : 255.255.255.0

MAC Address             : 74:e6:e2:fc:9d:3a

SNMP Community String   : public

IP Header               : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10

BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled

Gratituous ARP Intrvl   : 2.0 seconds

Default Gateway IP      : 10.3.12.254

Default Gateway MAC     : 00:00:00:00:00:00

Backup Gateway IP       : 0.0.0.0

Backup Gateway MAC      : 00:00:00:00:00:00

802.1q VLAN ID          : Disabled

802.1q VLAN Priority    : 0

RMCP+ Cipher Suites     : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14

Cipher Suite Priv Max   : Xaaaaaaaaaaaaaa

                        :     X=Cipher Suite Unused

                        :     c=CALLBACK

                        :     u=USER

                        :     o=OPERATOR

                        :     a=ADMIN

                        :     O=OEM

[root@esx-3:~]


위의 내용을 변경할 모든 호스트에서 실행하면 되며, 변경한 내용은 자동적으로 iDRAC에 반영되므로 별도로 iDRAC에서 설정을 변경할 필요는 없습니다.




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

[VMware] VMworld 2017 Europe 참관기 #6

VMworld 2017는 끝났답니다. 그런데 왜 포스팅을 하냐고요? 집에 와야죠... :)

VMworld에 관한 내용은 없습니다. 그냥 귀국한 내용을 남기는거죠. 


바르셀로나 시간으로 9월 15일 아침 11시 5분발 암스테르담행 비행기였습니다. 전날 누군가가 트윗에 바르셀로나 공항 출국 심사에 시간이 걸린다고 올려놨기에 일찍 움직였습니다. 아침 7시에 일어나서 아침먹고, 8시 전에 택시를 잡으니 8시 30분정도에 공항에 도착할 수 있었습니다. 보딩패스 체크인하고 짐맡기고 서둘러서 출국 심사로 향했죠. 확실히 붐비더군요. 그런데 의외로 빨리 움직이는거에요. 가만히 생각을 해보니 바르셀로나에서는 이른바 여권에 도장을 찍어주는 출국 심사는 안합니다. 그냥 휴대품과 보안 체크뿐이죠. --; 결국 보안 체크를 끝낸 시간은 9시 전이었습니다. 공항내를 두리번 두리번 거리며 시간을 때우고 탑승 시간이 되어서 게이트에 줄을 섰더랍니다.

탑승 시간이 되었는데도 탑승을 안시키고 20여분 지나서야 탑승을 할 수 있었습니다. 탑승하고 알았는데요... 비가 오고 있었습니다. 승객이 전원 탑승을 하고나니 안내방송이 나오더군요. "바르셀로나 그리고 암스테르담의 기상조건이 좋지않다. 때문에 대기중이다. 기상조건이 나아지면 바로 출발할 수 있도록 이대로 대기를 하겠다." --;; 음? 데자뷰? 며칠 전 암스테르담에서도 들은 기억이... 하여간 좁은 이코노미석에 앉아서 60분 정도 대기했습니다. 결국 예정보다 90분 늦게 암스테르담을 향해 출발했습니다.

일정대로라면 암스테르담 도착후 1시간 뒤 출발하는 비행기를 탈 예정이었지만 당연히 불가능했죠. 암스테르담 착륙 30분전에 나리타행은 못타니까 다른편을 재예약해야 된다고 알려주더군요. 허허...


암스테르담에 도착을 해서 그라운드 스탭에게 물어보니 어디어디에 가서 확인해라... 갔더니 이미 줄이 장난아니게 길더군요. 한 1시간 30분 정도 줄에 섰던거 같습니다. 우연히 뒤에 일본인 커플있었습니다만, 직원이 그들에게 나리타행이라면 다른 창구가 빠르다고 알려주길래 저도 따라갔죠. --;;; 다른 창구를 가기 위해서는 일단 패스포트 컨트롤을 해야되더군요. 패스포트 컨트롤을을 하고 알려준 창구에 가니 금방 재예약을 해주더군요. 단지... 암스테르담에서 나리타행은 하루 1편뿐... 결국 일단 파리를 경유, 나리타가 아닌 하네다로 가는 편을 재예약받았습니다. 20시 30분 출발... 5시간 남았네요... --;;; 다시금 패스포트 컨트롤을 한 뒤에 게이트로... 결국 스키폴 공항에서는 5시간 난민이 되었습니다.


밤 20시 30분 파리로 출발, 이번만큼은 예정대로 출발했습니다. :) 파리에 도착후에는 계획대로 23시 출발의 비행기에 탈 수 있었습니다. 후우... 파리에서 하네다까지는 11시간 정도 소요되었고, 9월 16일 18시 20분에는 하네다에 도착한거 같습니다. 


이로써 VMworld 여행이 모두 끝났습니다. 흐흐





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

[VMware] VMworld 2017 Europe 참관기 #5

마지막 날입니다. 

오늘로 VMworld 2017 Europe은 마지막이죠. 각 행사장도 14시정도면 정리를 시작하며 세션도 16시로 끝나죠. 재작년에 왔을 때는 14시 정도에 행사장을 나와 몬주익성도 둘러보고 맛있다는 오징어 먹물 파에리아(정말 맛있더군요)도 먹고 반나절 관광을 즐겼습니다만, 올해는 마지막까지 세션을 등록해버렸네요. 쩝...


General Session도 없기에 아침 9시부터 세션을 들었습니다.


vSAN 6.6 : A Day in the Life of an I/O

타이틀만 보면 vSAN의 I/O에 관한 내용이죠? 하.지.만... 들어보니 전반적으로 vSAN 6.6의 기능적에 대한 설명이었습니다. 전반부는 일반적인 vSAN의 내용, 후반부는 vSAN 6.6의 새로운 기능에 대한 설명이었습니다. 물론 중간중간 IO에 관한 내용도 있었으니 소개하도록 하죠.


우선 중복제거와 압축에 대한  IO 패스에 관한 설명이었습니다. 중복제거와 압축의 순서에 대해서 알기 쉽게 정리를 했었습니다.


물론 중복제거와 압축에는 트레이드-오프로 오버헤드가 발생한다는 설명도 잊지않더군요. :)

또한 vSAN의 트래픽에 대한 개념을 알기쉽게 정리한 슬라이드도 소개를 하겠습니다.


Reference Design for SDDC with NSX and vSphere : Part 2

두번째 세션은 NSX에 관한 내용이었습니다. 타이틀을 보시면 알 수 있듯이 Part 2입니다. Part 1은 듣질못했거든요. 프레젠터도 같은 분이었던거 같고, 참석한 거의 대부분도 Part 1을 들었다고 합니다. 흐음... 간단히 세션을 시작하고 Part 1의 wrap up을 해주었는데 프레젠터가 말이 너무 빠르더라고요. 완전히 어웨이였죠... 


두서없이 메모한걸 소개하자면... 

  • 소규모의 NSX 구성(1-2 랙)이라면 굳이 VXLAN을 구성하지않고 DFW만 이용을 해도 된다.
  • DLR의 구성없이 ESG만으로도 충분하다. 
  • Edge 클러스터는 안만들어도 된다


  • 중규모의 경우는 Management 클러스터와 Edge 클러스터를 같이 구성해도 된다.
  • ESG는 ECMP의 다중화 구성을 추천한다.


  • 대규모의 경우는 독립된 Edge 클러스터 구성을 추천한다. 
  • Edge 클러스터는 최소 4노드를 추천한다.
  • DLR Control VM과 ESG는 다른 노드에서 가동시키도록 한다.


이외에 NIC에 대한 얘기, 엔터프라이즈 토폴로지 구성 등에 대해서도 설명이 있었습니다만, 메모하는걸 포기했습니다. 말이 너무 빨랐다는거 핑계아니에요. 도중에 너무 빨리 말한다는 지적도 있었어요... --;;;


vSAN Networking Design and Configuration Consideration

이미 vSAN Networking Design Guide는 공개가 되어있죠. 꼭 들을 필요는 없었습니다만 vSAN에서는 아주 유명한 Cormac씨가 프레젠터로 등단을 하기에 들었습니다. 이야~ 오오라가 틀리더군요. 흐흐


우선 vSAN Networking을 구성하는 중요한 컴포넌트가 소개되었습니다.

  • CMMDS : vSAN 내부 통신과 메타데이터 교환용으로 6.6에서 유니캐스트도 변경된 것이 바로 이 CMMDS입니다. 이 CMMDS는 호스트 사이의 하트비트 교환용으로도 이용된다고 합니다.
  • RDT:가상 디스크를 클러스터에 분배하거나 복제, 재동기의 트래픽에 이용됩니다.

아울러 몇가지 네트워크 구성의 고려사항은...

  • vSAN을 구성할 경우 ESXi  호스트의 방화벽은 신경쓰지않아도 된다. 자동적으로 알아서 설정되어진다.
  • IPv4과 IPv6의 믹스 구성은 업그레이드시에만 지원된다. 그외에는 지원이 않되니 믹스 구성은 하지마라.
  • 가상스위치는 vDS를 추천한다. 왜냐하면 LACP를 이용하는 것이 좋기 때문에...
  • 티밍은 vSS/vDS 둘 다 Route Based on IP Hash를 추천한다.
  • vSAN은 로드 밸런싱의 메카니즘을 갖고있지않기에 LAG과 LACP 구성을 추천한다.
  • 확장 클러스터를 구성할 경우 witness는 L3 레이어 구성을 해라.


확장 클러스터의 경우 사이트-사이트의 네트워크 지연이 10 ms이면 IOPS가 절반으로 줄어들더군요.


또한 패킷로스가 2% 발생하면 IOPS가 절반으로, 10%이면 1/10로 줄어든다고 합니다.


vSAN Day2 Guidance and Recommendations for Running and Maintaining a vSAN Cluster

vSAN 클러스터를 운용할 때의 추천 내용을 소개하는 세션이었습니다. 당연한 얘기를 새삼스럽게? 라고 생각이 들기도 했지만 그만큼 "당연한 것"이 중요하다는걸 다시금 깨닫게 해준 세션이었습니다.


이 세션에서는 총 17 가지의 추천이 있었습니다.

vSAN 클러스터의 저장 가능 용량은 25%-30%를 확보해라.

② vSAN은 스케일-아웃과 스케일-업이 간단히 되기 때문에 상황에 맞춰 구성을 변경해라.

③ 유지 보수 모드로 전환할 경우 "No Data Migration" 옵션은 선택하지 말아라.

④ 가용성을 유지하기 위해 FTT에 필요한 호스트 +1 호스트를 권장한다.

⑤ 중복제거와 압축은 편리하지만 디스크를 삭제할 경우는 디스크그룹을 삭제해야되니 주의해라.

⑥ 클러스터에 에러가 표시되었을 경우는 오브젝트의 상태와 건정성을 확인해라.

⑦ 네트워크 파티션의 유무를 체크해라.

⑧ 드라이버의 업데이트는 Update Manager를 이용해라.

⑨ Web Client의 성능 모니터를 체크해라.

⑩ vROps와 vLI를 이용하면 트러블슈팅이 편해진다.

⑪ 호스트를 재시작할 경우, 원격 DCUI로부터 재시작 상태를 확인해라.


⑫ 건전성 UI에서 디스크의 밸런스 상태를 체크해라.

⑬ Update Manager를 이용하여 드라이버의 업데이트를 실행할 경우는 과정을 확인해라.

⑭ 클러스터의 업그레이드는 vCenter → ESXi 호스트 순으로 진행해라.

⑮ 호스트를 삭제할 경우는 유지보수 모드로 전환, 데이터를 이행, 디스크 그룹을 삭제, 호스트를 삭제해라.

⑯vSAN 클러스터의 정지는 올바른 순서로 진행을 해라.


⑰모든 ESXi 호스트와 vCenter는 동일한 DNS와 NTP를 참조하도록 해라. 


당연한 내용이지만 다시금 확인해보시는게 좋을거 같네요. :) 


이렇게해서 등록한 세션을 모두 들었습니다. 올해는 알기쉬운 프로덕트의 업데이트가 거의 없었습니다만 PKS나 HCX가 발표되었고 VMware on AWS의 서비스가 시작되는 등 새로운 VMware사의 전략을 확인할 수 있는 좋은 기회가 되었습니다.


아! 올해의 Hands-on-Labs은 NSX와 vSAN이 인기였네요.




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

[VMware] VMworld 2017 Europe 참관기 #4


3일째입니다. 

아침 9시부터 General Session을 시작으로 세션 4개를 들었습니다.


General Session

어제에 이어 오늘도 팻 CEO가 등단을 했습니다. 오늘은 유저로부터의 질문에 대한 답변을 하겠다며 Sanjay COO와 Ray CTO도 같이 등단을 했습니다. 질문과 답변을 간단히(아주 간단히) 적어보자면...

  • AWS와의 관계는? 향후에도 강력하게 파트너쉽을 이어갈 것이다.
  • 라이센스나 팩키징에 대한 개선 의향은? 라이센스나 팩키징에 대해서는 향후 간략화해 나갈 것이다.
  • HTML5 Client의 완전한 버전의 릴리스 시기는? 현재 90%다, 다음에는 100%가 될 것이다.
  • 오픈소스로 전환할 의향은? 계속적으로 오픈소스의 커뮤니티를 지원하여 공헌해 나가겠다. 
  • Dell Technologies와의 관계는? 독립, 에코시스템, 엑셀러레이션을 유지해 나가겠다. 

이런 내용이었던거 같습니다. 쩝... 그놈의 영어가...


후반부는 PKS나 VMware Cloud Service, NSX Cloud 등을 Elastic Sky Pizza라는 가상의 회사를 모델로 소개를 했습니다. 


될 수 있으면 공개된 아래의 동영상을 보시길 권장합니다. Elastic Sky Pizza의 예는 향후 VMware사의 비전에 대해서 알 수 있으리라 생각됩니다. 아래 동영상의 약 26분부터 보세요.


아! 도중에 최연소 NSX 닌자를 소개하더군요. 몇살일거 같나요?

15살의 이집트 출신의 학생(이겠죠?)이었습니다. 이미 VCIX-NV를 취득했다네요. 흐흐


vSAN Troubleshooting Deep Dive

vSAN이 VMware 스토리지 솔루션의 플래그 맨쉽이 되어 가고 있으니 앞으로도 vSAN을 도입하는 경우가 많아질겁니다. 당연히 문제도 많아질거고 트러블슈팅의 필요하게되죠. 이런 생각은 저뿐만이 아닌듯 세션은 만원이었던거 같습니다. 


간단히 메모한 내용을 공유하자면 우선, "기본적인 고려사항으로 하드웨어의 화환성을 맞춰라", "스토리지 정책이 올바른지 확인을 해라"더군요. 트러블슈팅에 이용할 수 있는 툴도 간단히 소개했습니다. 


아울러 Absent와 Degraded의 차이는 ESXi SCSI Sense Code를 수신하는지 아닌지도 설명을 하더군요.


이외의 내용은 시간이 되면 소개를 하도록 하죠.


VMware Validated Design for Software-Defined Data Center Architecture Deep Dive

제게는 생소한 내용이었습니다. VMware Validated Design for SDDC란 말그대로 VMware사가 하드웨어부터 소프트웨어까지 검증을 통해 동작을 인정한 이른바 표준화된 사양을 말합니다. VMware사는 검증을 토대로 어느 버전의 프로덕트가 유효한지 레퍼런스 가이드까지 제공을 하고있죠.


내용 자체는 흥미있었습니다만, 스케일이 커서 그런지 실감이 나질 않더군요. 구성을 할 규모의 고객이 얼마나 될지... 흐흐 


 VMware Validated Design for SDDC의 최신 버전은 4.1이며 지원을 하는 프로덕트는 다음과 같다고 합니다.


아울러 클러스터와 네트워크는 이렇게 구성을 한다~ 라고 설명을 했습니다만 흐음...~ 


잘모르겠네요... 흐흐


vCenter Server Design and Availability

이 세션은 vCenter의 설계팁이나 6.5부터 VCSA에서 지원을 하게된 VCHA에 대한 내용이었습니다.

우선 Embedded 구성을 할지 External PSC+vCenter의 구성을 할지는 Enhanced Linked Mode를 구성할 필요가 있는지 없는지를 먼저 판단하라고 하더군요. Embedded 구성도 실환경에서 충분히 이용을 할 수 있으며 External PSC+vCenter를 구성할 경우는 PSC는 외부의 로드밸런스를 이용, vCenter는 VCHA를 이용하면 된다고 합니다. 이런식으로 말이죠.


아울러 VCHA가 간단히 그리고 낮은 비용으로 vCenter의 가용성을 높일 수 있는 방법이라고 강조하더군요. 


VCHA의 특징을 정리해둔 슬라이드도 있었기에 올려봅니다.


Extreme Performance: vCenter Performance Deep Dive

오늘의 마지막 세션이었습니다. 역시나 만원이더군요. 그만큼 vCenter가 중요하며 문제가 생기면 골칫거리라는 얘기겠죠?


우선 VCSA가 Windows 버전보다 성능이 좋다는 벤치마킹 결과를 소개했습니다.


이미 아시는 분들도 있겠습니다만 vCenter의 성능저하는 다음과 같은 내용으로 막을수도 있나데요. 

클론을 작성할 경우는 동일한 호스트에서 실행을 하는 것이 아니라 마스터와 다른 호스트로 클론을 작성하고 vMotion과 프로비저닝 네트워크 어댑터를 나눠주는 것이 좋다고 합니다. 아울러 CPU와 메모리는 70%를 고정적으로 넘을 경우는 늘려주는 것이 좋다고 하네요.


또한 쓰기가 집중하는 DB의 경우, SSD에 위치시키거나 정기적으로 리소스나 용량을 확인하여 부족할 경우 늘리는 것도 하나의 방법이라고 하더군요. 아울러 이벤트/태스크 보존 세대를 줄여서 DB의 용량이 부족해지는 것을 막을 수도 있다고 합니다. 당연한거죠?


이외에 문제가 있는 프로세스를 찾아내는 방법 등도 소개를 했었는데, 이것도 나중에 시간이 되면 소개를 하도록 하죠. 정리를 좀 해야될거 같네요.


오늘은 모든 세션이 끝난 뒤에 '고객 감사 파티'가 있었습니다. 이 파티에는 Kaiser Chiefs란 밴드를 초청, 라이브를 하더군요.



꽤 재미있었는데, 정말이지 피곤해서 3곡 정도 듣고는 호텔로 돌아왔습니다.


앞으로 하루 남았네요. :)

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

[VMware] VMworld 2017 Europe 참관기 #3

둘째날입니다. 개최장소에서 가까운 지하철역을 나오니 비가 내리더군요. 역에서 수백미터는 걸어가야했던지라 쫄딱 젖었는데 아침부터 기분이 영 아니더군요.(저는 비에 젖는걸 아주 싫어합니다...)


하여간 8시 30분정도에 도착 주절주절 혼잣말을 하면서 General Session를 기다렸습니다.

오늘은 원격회의가 있었기때문에 General Session은 자유롭게 있을 수 있는 vmvillage에서 커다란 화면으로 경청을 했습니다.


General Session

시작전 무대에 VR 헤드셋을 장착한 아티스트가 나와서 화면에 그림도 그리고 현악기 연주자가 연주도 하며 분위기를 고조하더군요.


팻 CEO가 등장하여 과거의 IT에 비해 거대하고 급속히 발전하는 현재의 IT, 그리고 미래의 IT를 어떻게 맞이할 것인지, 그리고 VMware사의 전략은 시대의 트랜드에 어떻게 맞춰나갈 것인지 대한 내용이었던거 같습니다.  아울러 몇몇 고객의 높은 분들을 불러 패널 형식의 진행도 했었습니다만 그다지 기억에 남는게 없네요.(음... 아니 제대로 이해를 못했다고 하는게 맞네요)


내용중에 인상적인 것은 팻 CEO가 한 말이었습니다. "과거의 Science Fiction은 Science Fact되어가고 있다..." 공상과학에서나 등장할 것들이 점점 현실이 되어가고 있다... 실감나더군요.



또 한 가지는 VR 헤드셋을 이용한 데모였습니다. 팻 CEO가 VR 헤드셋과 컨트롤러를 장착하니 화면은 가상 데이터 센터가 등장했습니다. 컨트롤러를 이용하여 가상 데이터 센터의 ESXi 호스트위의 가상머신을 쓰레기통에 집어던져 삭제하거나 AWS(정말로 구름속의...)에 가상머신을 던져서 마이그레이션하거나 VMware on AWS의 Elastic DRS를 이용하여 간단히 클러스터의 리소스를 추가하는 등 Science Fact가 되기에는 조금 무리가 있지 싶었지만 인상적이었습니다. :)


General Session이 끝나고 등록한 세션이 시작되기까지 시간이 있길래 vSAN Specialist 자격 시험을 치뤘습니다. VMworld 개최기간중에는 50% 할인된 가격으로 치룰수 있다길래 응시했죠. 결과는... 


흐흐 운좋게 패스했습니다.


vSphere Clients Roadmap: HTML5 Client, Host Client, and Web Client

로드맵이라는 거창한 타이틀에 또 속았습니다. 흐흐 그냥 Web Client가 어떻게 진화했고 개선되어가고 있다라는 내용이 전반에 있었습니다. 후반은 HTML5 Client(세션에서는 HTML5 Client를 vSphere Clients로 언급)에 대한 내용이었습니다. Flings를 통해서 빠르게 개선되어가고 있으며 여러분의 피드백이 중요하다!라며 재차 삼차 유저의 협력(?)을 요청하더군요. 아래 그림은 HTML5 Client 기능 대응 상황을 비교한 슬라이드입니다.



Migrate to the vCenter Server Appliance You Should

이전에 포스팅을 했듯이 Windows 버전의 vCenter는 다음 메이저 버전부터 "비추천"이 되어 그 다음 버전에서는 지원을 하지않게됩니다.


따라서 필연적으로 VCSA로의 이행이 필요합니다만, 이 세션은 VCSA로의 이행에 대한 고려사항을 소개했습니다.


이행의 스텝으로는 우선 Migration Assistant를 이용하여 사전 체크를 실시한 뒤에 Migration Tool을 이용을 권장하더군요. 아울러 제한사항으로 다음 내용을 소개했습니다.

    • 동일 버전의 Windows vCenter에서 VCSA로의 이행
    • 복수 Windows vCenter의 단일 VCSA로의 이행
    • 토폴로지의 변경(PCS+vCenter을 embedded VCSA로)


이외에 vCenter, ESXi Hosts, vCenter 솔루션, 가상머신에 대한 고려사항도 소개를 했습니다만, 이건 나중에 소개를 하도록 하죠.


VMware Cloud on AWS Hybrid Cloud Architectual Deep Dive:Networking and Storage Best Practices

VMware Cloud on AWS 관련은 처음으로 듣는 세션입니다. 사실 AWS를 이용하지 않으니 세션 내용의 절반은 뭔소리인가? 싶었습니다만, vSphere, 특히나 vSAN에 대한 내용을 들을 수 있었습니다.


위의 그림처럼 VMware Cloud on AWS은 vSAN을 제공합니다만, ESXi의 부트 디바이스로는 AWS의 EBS(Elastic Block Store) 서비스를, 스토리지 영역으로는 NVMe의 Instance Store를 이용하여 제공을 한다고 합니다. 아울러 VMware Cloud on AWS은 vSAN 이외에 S3 서비스를 추가로 이용이 가능하며 화일 서비스, 데이터 백업, 빅 데이터 분석용으로의 S3 이용을 예로 들었습니다.


네트워크의 얘기도 있었습니다만 네트워크에 그다지 정통하질 못하다보니 흘려듣고 말았네요... 쩝


It's the Apps: Fully Loaded Application Monitoring with vRealize Operations

오늘의 마지막 세션입니다. 업무상 vROps를 설계하여 도입을 하는 경우가 늘고있습니다(vSOM 덕분이죠)만, 실제로 도입을 한 고객에게 물어보면 대부분 제대로 활용을 못하고 있는 것이 실정인거 같았습니다. 이용을 하더라도 인프라의 모니터링 정도일까요? vROps도 SCOM이나 그외의 모니터링 툴과 마찬가지로 커스터마이징하면 상당히(!) 유용한 프로덕트죠. 프레젠터로 저와 같은 생각을 갖고 있는거 같더군요. vROps로 어플리케이션을 모니터링하므로써 문제가 발생하였을 경우 신속한 원인 추긍과 트러블슈팅, 무엇보다도 인프라 관리자의 결백을 증명할 수 있다고 합니다. :) 인프라 관리자들은 아실겁니다. 어플리케이션의 성능이 저하되면 개발팀에서는 십중팔구 인프라에 원인이 있다고 문의하는 것을 말입니다. 흐흐


하여간 vROps로 어플리케이션을 모니터링하자~ 며 VMware사 환경의 vROps 데모를 보여줬습니다.

멋지더군요. 단지...


어떻게 어플리케이션을 모니터링하는지 방법을 알려주었다면 더욱 좋았을텐데 말입니다.  


세션이 다 끝나고 솔루션 익스체인지에 갔더니 마시고 떠들고 하더군요. 


전 피곤해서 그냥 호텔로 돌아왔습니다. 세션을 듣고나니 다 귀찮네요.



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

[VMware] VMworld 2017 Europe 참관기 #2

오늘부터 시작입니다. 정확히 말하자면 오늘은 파트너를 대상으로하는 제네럴 세션이나 브레이크아웃 세션이 예정되어있습니다.


간단히 참석한 세션에 대해서 느낌를 적자면... 


How to Build A Software Defined DR Practice with vSAN and SRM

vSAN 확장 클러스터를 이용하며 저비용으로 DR을 구성할 수 있다는 내용이었습니다. 확장 클러스터 환경에서 primary 사이트가 정지했을 경우의 가상머신의 거동에 대한 데모가 있었죠. 물론 secondary 사이트으로 failover되었죠. :) 여기에 secondary 사이트까지 정지했을 경우를 대비하여 SRM을 구성하면 더욱 완벽하게 DR을 구성할 수 있다는 내용이었습니다.




Advanced Security as a Service with VMware AppDefense

AppDefense는 새롭게 발표된 어플리케이션 방어 솔루션입니다. Capture-Detect-Respond의 단계로 어플리케이션을 방어한다고 하는군요.

Cehf나 Puppet같은 툴을 통해 어플리케이션의 거동을 학습하여 비정상적인 거동을 감지, 블록이나 경고 등의 대응을 취한다고 합니다. 대응에는 옵션으로써 NSX나 vRA과 연동을 할 수 있다고도 하는군요.


구성은 아래 그림을 보시는 것처럼 클라우드상에 Security Manager와 Security Manager Proxy를 전개하여 동작을 하는거 같습니다. 온프레미스의 경우는  Security Manager를 디플로이하는 것이 아니라 Security Manager Proxy를 전개하여 구성이나 정책을 동기하는 것 같습니다. 



가상어플라이언스로 제공되며 현재는 보호대상은 Windows만 가능하다고 합니다. 어플리케이션의 정보는 물론 vmware tools를 통해 얻는다고 하는군요.


라이센스는 다른 프로덕트와 동일하게 CPU 소켓 단위라고 합니다.



Partner Exchange General Session

솔직히 말하자면 저와는 전혀 거의 관계가 없는 내용이었습니다. 그것도 그렇죠. EMEA 파트너 대상으로 리베이트를 최대 7%까지 올린다, NSX, vSAN의 실적이 아주 좋았다, 더욱 팔자~ 등의 내용이었네요. 



Automating NSX with vRealize Automation and vRealize Orchestrator

쩝... 점심이 늦어져서 조금 늦게 갔더니 정원이 다 찾다며 입장할 수 없었습니다. 등록까지 했는데 말이죠...


vRealize Automation -  Building the Foundation for Automating IT Services in Your Cloud

데모 중심의 세션이었습니다. 간단한 서비스 카탈로그나 블루프린트 작성부터 멀티 블루프린트나 소프트웨어 컴포넌트 작성에 대한 데모로 구성되어있었습니다. 음... Puppet이나 Chef를 공부하지않으면 진정한(?) vRA를 구성할 수 없을거 같네요. 흑...


What's New in vSAN 6.6 - A Deep Dive

오늘의 마지막 세션입니다. 6.6.1에 대한 내용은 어느정도 파악은 하고 있습니다만 deep dive란 말에 세션을 들었죠. 결론은 6.6(6.6.1 포함)의 새로운 기능에 대한 내용이었네요...


한가지 세션에서 확인한 내용은 부분적인 수복 기능이었습니다. 


위의 그림처럼 FTT=2인 상태에서 호스트 2대에 장애가 발생하였을 경우, 6.5까지는 가상머신의 가동에는 문제가 없습니다만 가용성은 잃어버린 상태가 되었었습니다만 6.6 이후는 FTT=1로 부분적인 수복을 하여 가상머신의 가용성을 확보하도록 설계되었다고 합니다. 설명을 들으니 이해가 되더군요. 


영어도 약하고... 주위를 둘러보면 제머리 하나정도 더 큰 유럽인들뿐이니 의외로 긴장을 해서 그런지 피곤한 하루였습니다. 흐흐


 

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

[VMware] VMworld 2017 Europe 참관기 #1

우여곡절끝에 VMworld에 참가를 할 수 있게 되었습니다.

처음에는 않된다고 하더니 일주일전에 급거 바르셀로나행이 결정되었습니다.


VMworld는 글로벌 레벨의 컨퍼런스입니다. 매년 미국와 유럽에서 각각 8월, 9월에 열리죠.

개인적인 느낌입니다만 US 개최전에 제품의 새로운 버전을 발표하는 경향이 있습니다. 새로운 버전 또는 제품의 소개와 기대 때문에 축제같은 분위기인 반면에 한달 정도 뒤늦게 개최되는 유럽의 경우는 들뜬 분위기도 조금음 가라앉아 테크니컬 정보도 US보다는 많아집니다. 그래서 전 개인적으로는 US보다는 유럽을 선호하죠. 세션 내용은 동일합니다만... :)


참가기간중의 내용을 간단히 하루하루 소개할까 합니다.


일본-바르셀로나의 직행편은 없기 때문에 올해는 암스테르담 경유로 현지에 도착했습니다.


기내에서 영화를 5편 봐도 도착을 않하네요. 흐흐


네덜란드 스키폴 공항을 경유해서...


바르셀로나 엘프라트 공항에 도착했습니다. 스키폴 공항에서는 바르셀로나의 기상악화로 탑승후 1시간 정도 축발을 하지않더군요. --; 답답해서 죽는줄 알았습니다. 이래저래 바르셀로나에 도착하기까지 19시간 정도 걸렸습니다.


공항에 도착을 하니 이곳 저곳에 VMworld 관련의 광고가 보이더군요. VEEAM사와 RUBRIK사의 광고는 좋은 자리를 잡았네요. 흐흐



컨퍼런스는 월요일부터입니다만, 체크인은 전날부터 가능하기에 체크인하고 컨퍼런스킷(배낭) 받아왔습니다.


내일부터는 세션에 대한 정보도 소개하도록 하죠...


저작자 표시 비영리 변경 금지
신고
Trackback 0 Comment 0
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