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