MS Azure에서 Ubuntu VM을 생성해 사용하던 중에 어느 시점부터 ssh 연결이 되지 않는 경우가 생겼다.

Portal dashboard 상에서는 running 상태로 표시되고 있고 실제 DNS나 IP는 제대로 할당된 것으로 보였는데 ssh 접속을 시도하면 connection refused라고 표시되었는데 verbose option으로 메세지를 봐도 특별한 내용은 없었다.

1. Reset remote access​

해결을 위해 Azure에서 제시하고 있는 방법은 아래 링크와 같다.

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-troubleshoot-ssh-connections/

가장 손쉬운 방법은 remote access를 reset하는 것인데 별 문제가 아니라면 이 기능으로 해결이 되는 것 같다.

예전 portal (https://manage.windowsazure.com)에서 VM dashboard를 보면 해당 기능에 대한 링크가 있고 누르면 새로운 portal로 이동해서 진행하도록 되어있다.

대략 10분 이내에 reset이 되는데 이걸로 해결이 안된다면 아래의 방법을 참조한다.

2. Disk만 분리해서 문제해결 후 VM을 재생성하는 방법​

VM에 접속이 안되니 문제를 확인할 수도, 추측되는 문제의 원인을 해결할 수도 없다.

국내 IDC에 있거나 근처에 있는 장비라면 직접 가서 상태를 확인할 수도 있겠지만 클라우드라 그럴 수도 없다.

이 방법은 VM의 disk만 따로 떼어내서 원인 확인 및 해결 후에 다시 VM에 연결해서 살리는 방법이다.

참조한 링크문서는 아래와 같다.

https://social.msdn.microsoft.com/Forums/en-US/54c600c0-f4d6-4b20-ad87-1358fa10d27a/linux-vm-ssh-connection-refused?forum=WAVirtualMachinesforWindows

(0) 사전에 유의할 내용

Disk를 attach, detach 하거나 VM 삭제하면서 남겨둔 disk 정보가 리스트에 늦게 반영되는 경우가 있었다.

관련 작업을 하면서 disk가 보이지 않는다면 몇 분 정도 후에 다시 시도해보면 확인할 수 있다.

임시로 사용할 VM은 삭제하는 VM과 동일한 storage account를 사용하고 있어야 한다.

Disk는 storage account 별로 동일한 공간에 위치하기 때문이다. (물리적으로는 다른 영역일 수 있지만)

(1) VM 삭제

우선 VM을 삭제해야 하는데 삭제할 때 관련 disk는 남겨둔다. (select "Keep the attached disks")

VM에 attach되어 있는 disk는 다른 VM에 붙일 수 없게 되어있기 때문이다.

(2) 새로운(임시) VM에서 attach disk / mount

새로운 VM을 생성하거나 이미 사용중인 VM에서 attach disk 버튼을 눌러 (1) 과정에서 남겨둔 disk를 붙여준다.

정상적으로 붙었다면 dashboard에 표시되지만 임시 VM에서 확인하면 보이지 않는다.

하지만 /var/log/syslog를 SCSI로 grep을 해보면 새롭게 추가된 disk를 확인할 수 있다.

일반적인 경우라면 /dev/sda1가 root filesystem으로 /dev/sdb1이 붙어있는 상태이고 신규로 추가한 disk는 sdc로 연결된다.

VM에서 mount할 임시 경로를 만들고 /dev/sdc1을 (sdc인 경우) 생성한 경로에 mount 해준다.

mount /dev/sdc1 mount_point

(3) 문제 분석 / 해결

위 과정까지 문제가 없었다면 ssh 연결이 되지 않던 VM의 disk 내용을 고스란히 볼 수 있다.

boot log나 syslog, dmesg 등을 mount 된 경로에서 확인하고 문제의 원인을 분석한다.

나의 경우에는 fstab에서 webdav로 mount 하고 있는 외부 disk 연결에 문제가 발생하는게 원인이었던 것으로 보여 fstab에서 그 부분을 주석처리 해버렸다.

(fstab에서 사용한 option을 좀 수정해야 하겠지만 우선은 VM을 살리는게 목적이었으니 그냥 진행)

(4) Detach disk / VM 생성

다시 booting을 해도 문제가 없을 것처럼 손을 봤으면 임시 VM에서 disk를 umount하고 portal dashboard에서도 detach 해준다.

그 이후에는 실제로 사용할 VM (과거에 제거한 VM과 동일하게 해도 문제없음. Cloud service만 같이 제거한 상태라면)을 생성하는데 detach된 disk를 가지고 생성해야 한다. (VM 생성시에 Gallery의 MY DISKS 항목에서 수정된 disk를 선택)

사전 유의사항에도 명시한 것처럼 disk list가 갱신되는데 시간이 좀 걸릴 수 있으니 list에 disk가 보이지 않으면 얼마 후에 다시 시도해야 한다.

Java로 웹에 있는 영상 파일을 다운로드하는 기능을 간단하게 구현하면서 기본함수에 대한 의문이 생겼다.

실제로 영상 파일이 깨지는 문제도 있었다.

1. FileOutputStream write(byte[] b)​

아래 구문에서 사용된 write 함수는 byte buffer, offset, length를 parameter로 받는다.

좀 더 간단한 형태인 write(byte[] b)를 사용하는 것으로 코드를 변경하면 문제가 발생한다. (테스트했던 영상파일들에서는)

InputStream is = conn.getInputStream();
FileOutputStream fos = new FileOutputStream(filename);
byte[] buffer = new byte[4096];
int readBytes = -1;
while((readBytes = is.read(buffer)) != -1) {
  fos.write(buffer, 0, readBytes);
}

write(byte[] b)의 내용을 보자.

내용은 간단하다. byte 배열의 길이만큼 file output stream에 쓰는 기능이다.

2. 왜 문제가 생겼는가?​

결과적으로 보자면 HTTP로 들어온 input stream을 읽어들인 byte 수가 byte array의 총 크기보다 작은 경우가 있기 때문이다.

보통의 파일을 읽으면 마지막만 제외하고 buffer로 사용하는 byte array를 꽉꽉 채웠었는데 이 경우는 그렇지 않았다.

궁금해서 살펴보니 HttpInputStream의 read(byte[])는 이렇게 구현되어 있다.

read(byte[], int, int) 함수를 호출하지만 상속트리를 뒤지다보면 결국 자신이 구현한 read() 함수 호출이 기본이 된다.

read() 함수는 아래 그림처럼 -1이 나오기 전까지 1바이트씩 읽어들이도록 되어있고 read(byte[], int, int) 함수도 -1을 만나기 전까지는 byte array의 길이만큼 읽어들이게 된다.

그러니까 byte array 만큼 읽어들이지 못하는 경우가 있을 수 있는데 이에 대해서 고려하지 못했던게 문제였다.

실제로 찍어보면 사용된 byte array는 4096만큼 0으로 초기화되어 있고 계속 사용하기 때문에 byte array의 길이는 4096으로 항상 동일하고 읽어들인 실제 byte 수는 그것보다 작은 경우가 지속적으로 발생했다.

이런 상태에서 FileOutputStream의 write(byte[]) 함수를 사용하면 byte array의 길이만큼 쓰게된다. 실제 읽어들인 byte 만큼이 아니라 과거에 사용했던 일부 byte가 섞이게 되는 거다.

3. 결론​

가능하면 write(byte[]) 함수는 사용하지 않을 생각이다.

조금 불편해보여도 확실한게 낫다.

ESXi는 가상화 솔루션이기 때문에 HDD, SSD 등을 사용하기 위해 storage 등록을 선행해야 한다.

Disk를 100GB, 200GB 정도로 만든다면 크게 문제될게 없겠지만 대용량 disk를 통째로 한가지 용도로 등록해서 사용할거라면 storage 등록 과정에 소요되는 시간이 부담스러워질 수 밖에 없다.

내 경우 700GB 정도를 추가 등록하는데 약 3시간 정도가 필요했다.

1. RDM​

RDM (Raw Device Mapping)은 여러가지 용도로 나온 기술(?) 이겠지만 위와 같은 경우 소요시간만 보더라도 충분히 유용하게 사용할 수 있다.

직접 storage 등록하는 경우 시간이 많이 소요되는 이유가 VMWare 가상화 환경에서 사용할 수 있는 파일시스템 (vmfs)으로 만들기 때문인 것으로 보이는데 RDM을 사용할 경우 디스크 전체 혹은 일부를 vmfs로 만들지 않아도 된다.

과정이 잘 설명된 이 문서에 기술된 것처럼 raw disk를 가리키는 vmdk 파일을 하나 생성하는 것으로 끝낼 수 있다. (얼마 걸리지 않는다)

2. 제한사항​

처음에는 사용중이던 disk (파일들이 있는)를 그대로 활용할 수 있을것이라 생각했는데 불가능했다.

사용중이던 disk는 파티션이 하나 이상 생성되어 있는 상태인데 파티션이 있는 상태에서 파티션을 대상으로 rdm 설정을 하려고 vmkfstools를 실행하면 오류가 발생한다.

그렇다고 파티션을 무시하고 디스크 자체에 대해서 vmkfstools를 실행하면 파티션을 초기화해버릴까봐 진행해보진 않았다.

3. 결론​

RDM은 그냥 새 disk 하나 추가할 때 사용하자.

그 때 partition이 있는 상태에서 물리 디스크를 대상으로 RDM 설정하면 어떻게 되는지 시도해볼 예정.

지난번에 2주 정도 고생(덕만이 잠든 시간에 - Gen8 esxi 삽질기)하고 된다고 생각했는데 착각이었다.

1. VT-d​

HDD가 멈추는 듯한 현상이 지속적으로 발생됐다. 그것도 boot 완료된 시점에서 약 3분후.

아는 분들의 도움으로 BIOS 설정이 잘못된 걸 알게 되었다.

VT-d 설정이 enable로 되어있었는데 현재 사용중인 CPU는 VT-d를 지원하지 않는다.

G1610T 라는 Celeron CPU인데 제조사에서 안된다고 하니 잘못 설정한게 맞다.

http://ark.intel.com/products/71074/Intel-Celeron-Processor-G1610T-2M-Cache-2_30-GHz

BIOS 설정을 공장초기화한 값이 enable로 되어있는게 이해되지 않지만 그래도 제대로 설정.

2. SATA AHCI vs SATA Legacy​

VT-d 설정을 변경하고 설치를 다시 진행해봤는데 해결되기를 기대했지만 문제는 여전했다.

현상 만으로는 알 수가 없어서 로그를 뒤져보기로 했다. (이 때부터 커널로그를 보기 시작했다)

Failed, Driver ahci, for vmhba0 라는 부분이 반복되는 걸 알 수 있었다.

AHCI driver 로딩하는데 뭔가 문제가 있는 것 같아서 vmware 자료들을 뒤져봤는데 내 상황에서 특별히 조치할만한게 없었다.

(http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2000641 외 기타)

이런 내용도 있었는데 지원안하는 드라이버가 아니었기 때문에 역시 조치할 수 없었다.

드라이버 문제라는 걸 확실히 하기 위해 BIOS setting에서 AHCI 대신 SATA Legacy (IDE 타입의 구형 HDD를 지원하기 위한 내용으로 보인다)를 선택해서 다시 설치를 해보니 문제 해결.

드라이버 문제가 맞다는 확신을 가지고 HDD 등록하고 이런저런 작업을 더 진행해보니 이번엔 너무 느린게 문제였다.

느낌으론 속도가 일반적인 경우에 비해 1/10 또는 그 이상 느린 것 같았다.

순간 '버릴까?' 생각했다.

3. Service Pack for Proliant 설치​

목표가 좀 더 뚜렷해졌다.

"AHCI controller를 사용하면서 ESXi를 올린다"

다시 원래대로 돌아가 AHCI driver 로딩에 문제가 발생하는 상황에서 이런저런 내용을 살펴보니 할 게 하나 생겼다.

SPP (Service Pack for Proliant) 업데이트를 안해봤으니 그걸 해보기로 했다.

최신버전이 2015년 10월에 나온 것 같은데 업데이트 해보니 오! 몇 개 system firmware가 업데이트 된다.

하지만 기대했던 AHCI driver는 업데이트 되지 않았다.

초기 로딩화면에 AHCI 버전이 나오는데 HDD에 대한 드라이버는 0.90 버전이 ODD에 대한 드라이버로 0.84 버전이 로딩되는 것처럼 보인다.

이해 안된다. 그리고 뭔가 잘못 관리되는 듯한 인상을 받았다.

이 때부터 얘네 웹사이트에 올라와있는 파일들의 checksum 값을 확인하기 시작했다.

그래도 SPP 업데이트 후에 몇가지 달라졌다.

(1) SD / USB 설치

ESXi를 SD나 USB에 올리는게 계속 문제가 있었는데 SPP 업데이트 후에는 문제없이 잘 설치된다.

(2) Kernel log

AHCI driver 로딩이 안되는 듯한 로그가 사라졌다!!

잘 되어야 할 것 같았는데 문제는 여전했다.

다시 원점.

4. HDD에 직접 설치​

갑자기 멈춘 시점의 커널로그를 보면 특이사항이 없었다.

다만 vmware 측에서는 무시해도 되는 로그라고 하는 warning이 반복적으로 찍혔다.

Scratch partition에 대한 내용인데 SD나 USB에 설치할 경우 시스템 로그가 저장된다는 scratch partition을 만들지 못하는데 없는 경우 ram disk에 저장하기 때문에 단순히 경고만 할 뿐 특별히 시스템에 문제는 주지 않는다고 한다.

ESXi를 SD에 올리고 HDD를 추가한 후 reboot (boot 후 약 3분 후에 freeze 되고 HDD 추가할 때 쯤이면 시간이 얼마 없다)하고

warning을 없애기 위해 HDD에 scratch partition 경로를 지정해줬다.

그래도 문제는 해결되지 않았는데 아무래도 SD나 USB에 ESXi를 올리는게 불안해졌다.

그리고 RAID 구성을 하지 않을거라 굳이 SD 등에 ESXi를 올릴 필요가 없다는 생각이 들었다.

그래서 HDD에 ESXi를 직접 올리기로 했다.

iLO의 remote console에서 가상드라이브 할당해서 해보니 이번엔 HDD 설치 도중 문제가 생긴다.

(1) device or resource busy

(2) 설치 도중 멈춤

난 아무 작업을 하지 않았고 깨끗하게 포맷한건데 이랬다.

이쯤에서 다시 한 번 버릴까 생각했다.

그래도 포기하지 않고 Intelligent provisioning 기능으로 설치해보기로 했다.

참고로 전혀 intelligent 하지 않다.

USB에 여러 버전의 iso 이미지를 담아놓고 설치를 시도했다.

ESXi 6.0 이미지는 intelligent provisioning에서 인식하지 않는다.

ESXi 5.5, 5.1의 여러 버전중에서 최신 순으로 설치해봤다.

이미 SD나 USB로 여러번 반복했던 거였지만 HDD로 설치할 때는 조금씩 현상이 달랐다.

예를 들어 5.5 U2는 device or resource busy 라는 메세지 때문에 설치를 시작조치 못했다.

완전히 동일한 환경에서 설치 버전에 따라 문제가 나타나거나 그렇지 않다는 것은 뭔가 잘못 만든거다.

결국 2014년에 배포된 것으로 보이는 5.5 U1 까지 내려가서야 설치가 완료되었다.

그리고 그 버전 설치 이후에 더이상 문제는 발생하지 않았다.

힘들었다.

5. 기타 문제점들​

HP의 문제인지 VMWare의 문제인지 모르겠지만 발견한 기타 문제점들은 아래와 같다.

(1) SD/USB 사용시 scratch partition

http://blog.pasion.kr/esxi-warning-host-solution1/

위에서 기술했던 내용이지만 SD나 USB에 ESXi 설치시 scratch partition을 만들지 않는다.

SD나 USB에 여유공간이 많아도 절대 만들지 않는다.

난 16GB짜리 micro SD를 사용했는데 (요즘 마트가면 16GB 이하 제품을 찾기 힘들다) 위 그림에서 몇백메가씩 잡혀있는 나머지 공간은 그냥 버리게 된다.

(2) Driver 버전차이에 따른 문제들

장비 특성상 수많은 controller들과 driver들이 있는건 알겠는데 각 driver 버전에 따른 문제점들이 많은 것 같다.

이번에 내가 경험한 문제도 그런 문제 중 하나로 추측되고 인터넷에는 수많은 문제들이 보고되어 있다.

(3) HP의 esxi custom image 관리

http://www8.hp.com/us/en/products/servers/solutions.html?compURI=1499005#tab=TAB4

이곳에 기록되어 있는 날짜를 신뢰할 수가 없었다.

VMWare 어느 사이트에는 각 이미지별 release date가 위와는 달랐고 일부 해외 유저들이 기술한 문서와도 날짜가 달랐다.

날짜와 Update 번호로는 알기가 너무 어려워서 결국은 Build number를 비교하면서 문서들을 읽었다.

내 안의 무언가가 답보상태에 있는 것이 아닌가라는 답답함을 이겨내보고자 아이가 잠든 후에 무언가를 해보기로 했다.

그것이 무엇이든 그렇게라도 좀 더 의미있는 시간을 만들어가야 스스로에게 미안하지 않을 것 같았기 때문이다.

그렇게 2주에서 3주 정도를 지속해보고 있는데 답답함은 줄어드는 것 같고 전반적인 생활에 의욕이 조금씩 생겨나는 듯한 느낌이 든다.

1. Gen8​

여러가지를 진행했지만 지난 2~3주 야간에 가장 많은 시간을 투입한 것은 Gen8 (HP의 마이크로서버 제품군)에 ESXi (VMware의 hypervisor)를 올리는 작업이었다.

2주 전쯤 중고/신품으로 구매한 장비들이 도착한 것이 시발점이 되었고 다양한 가상화 환경을 경험해 보고싶다는 생각도 있었지만 이런 류가 대부분 그렇듯이 좀 더 그럴싸한 환경을 갖는게 목적이었음을 부정할 수 없다. (사실은 장비욕)

굴러다니는 아이의 DVD를 재생할 수 있게 해주겠다는 감언이설로 부인을 설득했는데 평소에는 워낙 보살같은 분이라 그냥 넘어가준 것 같다. (이 비용이면 DVD player를 몇 개 사고 남은 돈은 맛있는 걸 사먹거나 플레이스테이션4를 사고도 남는다)

아무튼 나의 진정한 목적은 따로 있었지만 DVD play를 1차 목표로 작업을 진행해봤다.

2. ESXi 6.0 올리기​

한글, 영문을 따지지 않고 정말 수많은 웹사이트를 참고했다. 'gen8 esxi'로만 검색해도 내용이 정말 많이 나온다.

하지만 나와 같은 특이한 현상을 경험한 사람은 거의 없었던 것 같다.

많은 사람들이 사용하는 방법대로 sd card를 넣고 (보드에 slot이 내장되어 있다) gen8의 훌륭한 ilo의 remote client로 붙어서 가상 cd/dvd rom에 iso 파일을 추가해 설치를 진행했다. (이런게 된다. remote로...)

처음 6.0을 sd card에 올릴 때에는 전혀 문제가 없었다. 정상적으로 올라간 걸 확인하고 새로 구매한 하드를 장착한 후 data store 등록까지 한 번에 완료할 수 있었다.

이렇게 그냥 가면 되는 거였는데 뭔가 의심병 같은게 도져서 6.0이 아닌 5.5를 올리는게 낫지 않을까라는 생각을 하게 되었다.

(1) SD card / USB format은 필수가 아닌가

보통 os 같은 걸 설치해보면 이미 존재하는 경우 파티션을 새로 잡거나 하면서 포맷을 알아서 하도록 진행할 수 있다.

그런데 6.0이 설치된 sd card에 5.5를 올리려고 하니 진행하다 멈춰버렸다.

이후 과정에서도 멈췄다 라고 판단한 이유는 야밤에 30분 이상 졸다 깨거나 책을 수십페이지 읽다 쳐다봐도 progress가 동일했기 때문이다.

깔끔하게 포맷하고 다시 설치했더니 별 문제없이 끝났다.

(2) CreateVmfsDatastore 오류

6.0이 설치된 상태에서 하드를 data store로 등록했기 때문에 5.5로 내리기 전에 등록된 data store를 삭제했었는데 5.5에서 다시 등록하려고 하니 아래와 같은 오류가 발생했다.

이후에도 수없이 마주한 저 오류는 사실 esxi 버전의 문제가 아니라 하드 초기화 여부가 원인으로 보인다.

그런데 이 때에는 그 사실을 몰랐기 때문에 '5.5는 뭔가 문제가 있나보군' 이라 생각하며 다시 6.0으로 올리기로 마음먹음.

(3) 5%, 16%, 22%, 90%

이 때부터 문제였다.

sd card를 포맷하고 설치를 시도했음에도 어느 시점부터 설치가 진행되지 않고 멈춰있는 현상이 생겼다.

주로 90%에서 멈추는 경우가 많았는데 실제로 같은 경험을 하신 분이 있다.

https://www.2cpu.co.kr/bbs/board.php?bo_table=vm&wr_id=3017

이 분은 sd card 종류를 타는 것이 아니냐 결론 내리셨던데 그게 원인은 아니라고 판단하고 있다.

왜냐하면 처음엔 문제없이 설치된 card였기 때문이다.

수없이 반복.

sd card도 새로 사서 해보고 usb도 종류를 바꿔가며 올려봤고, remote client로 붙어서 진행했기 때문에 iso 이미지를 실제로는 네트웍으로 전송하는 것이었을테니 iso를 usb에 얹어서도 설치해보고 ilo의 intelligent provisioning으로도 해봤다.

결과는 경우에 따라 달랐지만 5%, 16%, 22%, 90% 진행도중 멈춰버렸고 왜 안되는지 원인을 알 수 없었다.

ilo에 보이는 로그에는 특이사항이 없었던 데다가 더 상세한 로그를 볼 수 있는 방법을 몰랐기 때문이다.

하지만 방법을 바꿔가며 며칠을 시도하다 꿈까지 꿔가며 '이제 슬슬 사리가 만들어지겠구나' 라는 느낌이 들 때 되더라.

왜 된건지 알 수 없었다. 딱 이런 상황.

<출처 : http://www.imawebdeveloper.com/photos/memes/>

3. Data store 등록​

간신히 usb에 esxi를 올리고 data store를 등록할 차례가 되었다.

분명 ESXi 6.0에서 문제없이 등록되었던 하드인데 5.5에서와 동일한 오류가 발생하기 시작.

오류 메세지로 검색해보니 역시 많은 내용이 보였다.

많은 사람들이 겪는 문제인가 싶어서 금방 해결될 것 같은 느낌이 들었지만 결과적으로는 이것도 며칠 걸렸고 역시 왜 된건지는 지금도 알 수가 없다.

처음에도 아래의 내용대로 진행해서 실패했고, 마지막에도 아래의 내용대로 진행해서 성공했다.

http://www.virtualizationteam.com/server-virtualization/call-hostdatastoresystem-createvmfsdatastore-for-object-ha-datastoresystem-on-esxi-xxx-xxx-xxx-xxx-failed.html

(1) Format

하드가 WD사 제품이었기 때문에 그들의 툴을 써서 포맷을 했다.

http://uplaza.co.kr/customer/view.aspx?id=pds&code=23&category=&page=&search=

윈도우용 툴밖에 없는 것 같아서 윈도우에서 진행했는데 위와 같이 포맷하고 data store 등록하려고 하면 아래와 같은 화면을 볼 수 있다.

분명 파티션을 다 날린 상태인데 MBR로 파티션 잡힌게 보인다.

실제로 ESXi console에서 fdisk로 확인해보면 파티션이 있다. 왜 있지?

그래서 파티션만 날려보고 해봤더니 동일한 오류가 발생했다.

(2) AHCI driver?

로그를 보면 대충 아래와 같은 내용들이 반복해서 등장한다.

반복되는 내용 중 가장 마지막 라인이 신경쓰였다.

RAID를 구성하지 않을거라서 Gen8에서 SATA AHCI로 설정한 상태였는데 로그는 AHCI driver를 로딩하는데 문제가 있는 것처럼 생겼다.

혹시나 RAID가 필수인가 싶었는데 생각해보니 처음엔 분명 잘 되었었기 때문에 이것도 원인이 아니다.

드라이버 로딩 문제인가 싶어 별 자료를 다 찾아서 살펴봤는데 딱히 AHCI 드라이버가 로딩이 안 될 이유가 보이질 않았다.

(3) Device locked

하드 포맷을 윈도우, 맥에서 여러가지 툴로 해보고 파티션은 따로 날려보고 하는 등의 작업을 며칠간 수없이 반복하다가 어느 날 다시 로그를 보니 이런 내용이 등장했다.

'아 디바이스가 잠겨있나보네' 라고 잠깐 생각했는데 포맷하고 바로 밀어넣은 하드인데다 난 추가로 아무런 작업을 하지 않았는데 잠겨있다는게 이상했고 마지막 줄에 다시 초기화를 하는 것 보니 스스로 뭔가 조치를 하는구나 싶었다.

야식으로 라면을 먹고 오니 원래 반복되어야 하는 warning 로그들이 없었다.

'오 뭔가 다른데?' 라고 생각하며 스크린 세이버를 걷어버리니 등록이 되어있더라.

왜? 인지를 알 수가 없었다. 답답...

4. VM 생성​

드디어 VM을 하나 생성해서 윈도우를 올려봤다.

그리고 부인에게 보고하기 위해 곰 플레이어를 설치하고 Gen8에 꽂아넣은 DVD (장치는 기본적으로 없다. 새로 사서 끼워넣은거)에 dvd 한 장을 올려놓고 재생해봤다.

ESXi client에서 재생해보니 그럭저럭 잘 나오기는 하는데 부인은 이런거 사용할 줄 모른다.

고민하다가 방치된 ipad에 remote desktop 앱을 설치해서 연결한 후에 플레이를 해보니 혹시나 했지만 RDP는 역시나 끊긴다.

5. 다음 여정​

VM 하나를 더 생성해서 NAS로 만들어버릴 생각이다.

그리고 DVD는 몽땅 파일로 만들어서 Plex나 기타 서비스로 재생할 계획인데 알 수 없는 문제들을 겪은 터라 벌써부터 겁이 난다.

그래도 해야 한다.

부인 입장에서 뭔가 신기한 효과나 효용성을 보여줘야 내가 다음에 어떤 장비를 사려고 할 때 문제가 없을 것이다.

U+ TV 사용시 불편한 점 하나가 그들의 공유기(나의 경우엔 LG-5000P)를 최상단에 위치시켜야 한다는 점이다.

일반적인 경우라면 문제가 없을 수 있지만 이미 공유기를 하나 사용중이었고 DDNS로 외부에서 접근하곤 했었는데 TV 하나 보자고 조치를 취해야 하는 상황이었다. 초기에는 설치된 상태를 바꿔 LG 공유기를 내 공유기 아래에 붙여 봤었는데 얼마 안가서 TV가 안나오기 시작했다. (지금은 어쩌면 변경할 경우 처음부터 아예 안되게 막혀있는지도 모른다) 고객센터에 전화해서 얘기도 몇번인가 했었는데 기술부서와 연결이 되서 대화해봐도 그들의 공유기가 최상위가 아니면 안된단다. DDNS가 꼭 필요한 것은 아니었지만 외부에서 내 공유기 네트웍에 연결하고 싶었다.

1. 초기 상태​

그림처럼 LG-5000P가 집 내부 네트웍의 최상위에 있고 TV를 제외한 device들은 무선으로 IPTIME 공유기에 붙어있다. 인터넷 연결에는 별 문제가 없는 상황이지만 IPTIME 공유기가 DHCP로 내부 IP를 할당받아 동작하고 있기 때문에 외부에서 접근하지 못한다. 내 공유기를 서랍에 모셔두고 LG 공유기만 사용하면 되지 않느냐 할 수 있지만 LG-5000P는 무선 네트웍이 안된다. (무선이 되는 다른 모델을 받을 수도 있긴 하다) 그리고 포트포워딩 등의 설정을 옮기는 작업이 싫었다. 해본 사람들은 느끼겠지만 LG-5000P 관리화면에 접속하는 순간 그냥 브라우저를 닫고 싶어진다.

2. 일반적인 조치방법들​

사용자가 많아져서인지 처음 사용하기 시작했던 2~3년 전보다 알아서 조치해서 사용하는 사례가 많이 보이는데 대충 이렇다.

(1) MAC address 복제

아마도 인증 등의 과정에 LG 공유기의 MAC이 이용되는게 아닌가 싶은데 개인 공유기의 MAC을 LG의 MAC으로 교체하면 LG 공유기는 서랍에 던져놔도 된다고 한다. (IPTIME 공유기의 경우 최근 firmware로 업데이트 해보면 IPTV 설정을 업체별로 할 수 있는 기능도 제공한다.) 이게 제대로만 된다면 가장 깔끔한 방법일 것 같은데 과거에는 TV 볼 때 끊김이 있거나 하는 문제상황들에 대한 글들을 본 기억이 있다.

(2) DMZ 사용

(1)과는 달리 공유기를 모두 사용하되 하단에 위치한 개인 공유기를 LG 공유기의 DMZ에 넣어두고 사용하는 방법이다.

3. Bridged​

내 공유기 네트웍에 연결하지 못하는 것은 공유기 IP가 NAT로 동작하는 LG 공유기에서 할당된 내부 IP인 것이 원인이다. 그렇기 때문에 공유기 IP를 LG 공유기 위에서 받을 수 있기만 하면 된다. (LG 공유기도 상위에서 할당받은 외부에서 접근 가능한 IP가 설정되어 있고 개인 공유기를 최상단에 위치하는 것과 같은 효과) 그래서 LG 공유기를 Bridge mode로 변경해보기로 했다. 역시 손대기 싫었던 LG-5000P 관리화면에서 설정을 변경했고 대충 이런 모양으로 바뀌었다. (물리적인 변경은 없음)

TV와 내 공유기가 LG-5000P와 같은 네트웍 대역에서 동일한 위치로 올라왔고 각각 외부에서 접근가능한 IP를 할당받았고 IPTIME의 DDNS에서도 과거엔 등록된 호스트를 찾지 못하다가 정상상태가 되었다. 한 사용자가 외부 IP를 여러개 할당받는게 가능한지 의심스러웠는데 아직 큰 문제는 없는 것 같다.

4. 결론​

물리적인 변경없이 NAT를 bridge로 변경하는 것만으로도 필요한 걸 얻을 수 있었다. 하지만 mode 변경 후 IPTIME 공유기가 새로운 IP 할당받는데 시간이 꽤 소요되는 현상이 있었고 이것 때문인지 가끔 TV나 인터넷 연결이 끊어지는 것 같은 느낌이 드는 경우가 있었다. 이런 현상이 지속되면 MAC address 복제하는 방법을 시도할 생각이다.

Update #1.​

Bridge mode에서 인터넷, TV 모두 끊기는 현상이 지속되서 결국 MAC address 복제하는 방법을 사용했다.

1주에 한번씩 스터디 중이고 이번주는 hadoop을 deploy 해서 가야 한다.

Hadoop에 대해서는 잘 모른다. 하지만 배우면 되겠지라고 생각하면서 시작.

1. Juju charm​

Charm을 찾아보니 간단하게 기술되어 있다.

(Charm 자체는 간단하겠지만 hadoop에 대한 내용은 어려울 것이다.)

기술된 내용을 읽다보니 HDFS와 MapReduce가 혼합된 형태로 deploy 하는 부분이 있다.

Scale out을 위해 분리된 형태로 deploy 하는 내용도 있었지만 일단은 가볍게 시작하기로 하고 순식간에 deploy / relation 완료.

2. Web UI​

Apache Hadoop 페이지를 대강이라도 읽어두어야겠다는 생각이 들어서 살펴보니 Hadoop cluster를 올리고나면 web ui가 있으니 확인해보라는 내용이 있었다. Name node는 default 50070, Resource manager라는 애는 default port가 8088이다. 그런데...위의 이미지처럼 간단하게 deploy를 해보니 Azure (연습용이라 Azure를 사용한다)에 생성된 VM에 Endpoint 설정이 SSH 말고는 되어있질 않았다. 역시 이런 부분은 문제가 있다고 생각하며 넘어가기로 했다.

3. Listening port 확인​

설마 혹시 제대로 deploy가 안된 것은 아닌가 다른 문제가 있는 것은 아닌가 의심하기 시작. 하지만 로그를 봤을 때 특이사항이 없었으므로 Apache 문서가 맞다면, 또 deploy가 제대로 되었다면 port는 listen 상태로 있겠지라는 생각이 들었다. 그래서 netstat.

Hadoop의 구조는 잘 모르지만 master, slave로 나뉘어 있는 것으로 보아 master만 보면 되겠다며 port를 확인하니 Apache 문서대로 8088, 50070 등의 port로 들을 준비를 하고 있더라. 그렇다면 문제는 하나.

4. Expose​

Charm 문서에는 기술되어 있지 않지만 Azure endpoint 설정이 안되어 있으므로 expose를 해보기로 했다. (직접 VM에서 열어도 되지만...) 해보니 자동으로 몇 개 설정이 추가된다.

그런데 왠지 중요해보이는 resource manager가 사용할거라던 8088은 추가되지 않았다.

그래서 손으로 추가.

5. Hadoop Resource Manager​

접속해보니 잘 열린다. hadoop-slavecluster를 deploy 한 후 unit을 2개 더 추가했기 때문에 총 3개가 active node로 잡힌다.

근데 이것으로 무엇을 해야하는건지는 모르겠다.

6. 결론​

Juju로 hadoop cluster 구성하는건 매우 간단하다.

하지만 Azure로 진행하는건 여전히 몇가지 문제가 있다.

Azure의 특성 때문이기도 하지만 charm을 만들 때 고려해야할 문제이기도 한 것 같다.

Azure 사용중인데 얼마전 연락을 받았다. 비용이 좀 과다하게 나오고 있는 것 같다고.

1. Outbound traffic​

확인해보니 outbound traffic이 약 2주동안 63TB 정도.

Azure 정책상 inbound는 무료, outbound에는 GB당 얼마씩 과금이 되는데 합하니 약 천만원 정도의 비용이 찍혀있었고 billing history 상세 내역을 확인해보니 (날짜, category, vm 별로 상세 데이터가 csv로 제공됨) 특정 vm 2개가 매일 2~6TB씩 outbound traffic을 발생시키고 있었다. 뭐 특별한거 서비스하는 것도 아니었는데...

2. Process 확인​

해당 VM 중 하나에 접속해서 우선 top으로 CPU 점유 / Memory 사용량과 사용되는 process 들을 확인해봤다.

jenkins user가 사용하는 XiosElom이라는 process가 눈에 띄었는데 지금까지 본 적 없는 이름이어서 더 상세한 process 정보를 확인해보니 jenkins 설치 경로 하위에 처음 보는 이름의 파일이 복수의 process로 실행중이었다. 이상하다.

3. File / 문서 확인​

XiosElom 이라는 파일을 확인해보니 9월 22일에 생성이 되어있었고 관련 자료를 검색해보니 malware라는 얘기가 위키에 올라와있다. 10월 1일 날짜로 등록된 것으로 보아 비교적 최근에 발견되고 있는 문제인 것으로 보인다.

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-10-01

4. 원인 / 조치​

문제가 된 2개의 VM 모두 테스트용 jenkins가 설치되어 있는 상태라 process를 중단하고 jenkins를 purge로 삭제한 후 재설치를 하고 security 설정을 enable 했다. 근본적으로는 jenkins를 통해 누군가가 설치하고 실행한 process가 원인이지만 방심하고 security 설정을 하지 않은게 그것을 가능하게 했다고 생각한다. 또 급하게 조치하고 나서 보니 추가로 분석할 로그 파일과 실행 파일을 남겨두지 않은게 후회된다.

Jenkins plugin 중 하나를 수정할 일이 있어서 clone 해서 빌드를 해봤는데 테스트에서 실패하는 문제(테스트 코드 상으로는 전혀 문제가 없어보였는데)가 생겨서 plugin 개발 과정 그대로를 진행해봤다.

OS : OS X Yosemite (10.10.3)

IDE : Eclipse Luna

1. settings.xml 준비​

Jenkins plugin은 maven으로 dependency 관리 및 빌드를 하도록 되어있는데 라이브러리나 모듈 등을 maven 중앙 저장소 대신 별도 저장소에서 관리하고 있다. 그렇기 때문에 jenkins 저장소들에 대한 경로를 maven이 인식할 수 있어야 하므로 settings.xml 파일에 아래 내용을 추가하라고 가이드하고 있다.

나의 경우에는 별도로 settings.xml 파일을 변경해서 사용하고 있지 않기 때문에 maven 기본 설정을 따라가게 되어있는데 위의 내용을 ~/.m2/settings.xml 파일로 생성해 놓으니다른 maven project들이 의존관계를 갖는 모듈을 찾지 못하는 문제가 있었다. 그래서 별도로 eclipse에서 workspace를 생성해서 그 위치에 settings.xml 파일을 두고 그 workspace에 있는 project들만 위의 settings.xml 내용을 따르도록 조치해두었다. 불편한 점인데 maven의 기본 settings.xml 내용을 안다면 위의 내용만 추가해서 처리할 수 있을 것 같은데 뒤로 미뤄두기로 했다.

2. Plugin 생성 (skeleton)​

Plugin tutorial을 따라서 해보니 아래의 command로 새로운 plugin을 생성해줘야 한다.

mvn -U org.jenkins-ci.tools:maven-hpi-plugin:create

그런데 위의 내용대로 하면 maven에 설정된 settings를 따라가게 되기 때문에 jenkins에 대한 의존관계를 찾지 못해 아래와 같은 오류가 발생한다.

그래서 별도로 생성한 settings.xml을 적용할 수 있게 command를 변경했다.

mvn -s settings.xml -U org.jenkins-ci.tools:maven-hpi-plugin:create

아래 이미지처럼 groupId와 artifactId를 입력하면 skeleton project가 생성된다.

3. mvn install (optional)​

튜토리얼에는 hpi로 packaging 하기 위해 아래의 command를 사용하라고 되어있다.

mvn install

단순 packaging인데 goal을 install로 하라는게 이상하다. 어차피 IDE에서 드럼과 장구를 칠테니 이 과정은 없어도 될 듯 하다. 그래도 command 변경해서 한 번 해봤다.

mvn -s ../settings.xml install

전형적인 install 처럼 maven 로컬 저장소 경로에 packaging 된 파일들이 생성된다. packaging 과정을 거쳐서 진행되는거니 /project_path/target 에도 hpi가 생성되고 goal을 package로만 지정해도 target에는 hpi가 생성된다.

4. mvn hpi:run​

Dependency 중에 jenkins war도 있어서 hpi:run을 goal로 지정하면 플러그인이 설치된 상태로 jetty로 jenkins를 실행시켜준다. 이 때 기본 context path는 /jenkins이고 port는 8080

mvn -s ../settings.xml hpi:run

5. Project import​

Skeleton project는 기본으로는 maven을 사용하고 있으므로 'Existing Maven Project'로 import 해도 된다. 나의 경우엔 특이한 현상이 있어서 eclipse project로 변환해 보기도 했는데 변환할 경우 아래의 command 형태를 사용하도록 튜토리얼에 기술되어 있다.

mvn -DdownloadSources=true -DdownloadJavadocs=true -DoutputDirectory=target/eclipse-classes -Declipse.workspace=/path/to/workspcae eclipse:eclipse eclipse:add-maven-repo

이제 수정하거나 이것저것 만들어서 빌드하고 실행해볼 수 있다.

6. 특이한 현상​

경험했던 특이한 현상이 아래의 두가지였다.

(1) Skeleton project를 run 했을 때 configuration에 나타나지 않는 문제

Skeleton project를 그대로 실행하면 원래는 아래 그림처럼 jenkins configuration에 'Hello World Builder' 라는 section이 추가되고 job 설정에서 프랑스어로 인사를 print 할 수 있는 기능을 build에 넣을 수 있게 되어있는데 어느 곳에도 project와 관련된 부분이 나타나지 않는 현상이 있었다.

(2) Clone한 project build시 test에서 실패하는 문제

수정하려고 했던 plugin을 clone해서 packaging을 했는데 테스트에서 실패하는 문제가 있었다. 아래 그림처럼 단순한 형태의 테스트 코드였는데 객체가 얻어지지 않는게 테스트 실패의 원인이었다.

두 가지 문제를 해결하려고 시도하던 중 eclipse project로 변환하면서 문제들이 저절로 해결되었다. source를 download 하라고 설정되어 있어서 source가 꼭 필요한 무언가가 있어서 해결된 것인가 (그래도 이상하다) 아니면 변환 과정에서 의존성을 가진 일부 모듈을 download 하는 건지 추측을 해봤지만 정확하지는 않다. 아래는 같은 현상을 경험했던 분이 stackoverflow에 올려놓은 글.

http://stackoverflow.com/questions/23002818/jenkins-plugin-shows-on-plugin-page-but-does-not-show-on-configuration-page

Ubuntu를 배포하고 있는 Canonical에서 사용자가 cloud 환경에서 쉽게 서비스를 모델링하고 배포하기 위한 tool을 Juju라는 이름으로 내놓았다. Server instance를 간편하게 관리한다는 측면에서는 Chef와 유사하지만 instance 자체를 생성하거나 제거할 수 있기 때문에 또 다른 것 같다. Juju는 instance가 아닌 service 위주의 관리와 배포를 목적으로 하고 있는 것으로 보인다. 실제로 특정 서비스 (charm이라고 부르는)를 deploy하면 신규 instance를 추가해서 charm에 정의된 내용대로 서비스를 배포하게 된다. (option에 따라 이미 추가된 instance에 배포하는 것도 가능)

참고 : 아래의 모든 터미널 이미지에 표시된 dns name과 instance-id 들은 이미 다 destroy 해서 사용할 수 없는 정보들임

1. Juju의 구조​

<출처 : http://www.slideshare.net/LeonardoBorda/leonardo-borda-maas-and-juju-introduction\>

Juju는 위 그림처럼 client가 state server에 상태값을 추가하거나 update 하도록 되어있고 하위의 모든 machine 들은 state의 변경에 따라 특정 동작을 처리하도록 되어있는 것으로 보인다. 예를 들어 wordpress와 mysql을 연결하라는 명령을 client에서 보내면 내부적으로 event가 발생되고 wordpress, mysql이 event에 맞는 hook을 실행해 세부적인 동작을 처리하게 되며 그 과정에서의 상태값들은 모두 state server에 저장되거나 변경된다. (State는 Mongo DB로 관리되는 것으로 보임)

2. Bootstrap​

Juju client 설치 후 내가 사용하는 cloud 환경 (AWS, MS Azure, Openstack, Joyent, GCE, VMWare 등 대부분의 환경을 지원한다)에 대한 설정을 마친 후에 bootstrap 명령을 내리면 bootstrap instance를 생성하고 필요한 tool들의 설치, 설정까지 진행한다. Bootstrap instance는 state server로서 동작하게 된다.

Azure의 경우 vnet 생성 후에 instance를 생성해서 연결하게 되고 hash가 포함된 것으로 보이는 문자열로 DNS name을 설정하는 걸 확인할 수 있다. 사실 Juju로 관리할 경우 DNS name은 크게 중요한 요소는 아닌데 아래의 그림처럼 state server에서 별도로 일련번호(0)나 unit name을 붙이고 있어서 client에서는 DNS name이 아니라 일련번호나 unit name으로 대부분의 관리가 가능하다.

3. Charm​

Juju에서 배포하고자 하는 service들은 charm이라는 이름으로 정의되고 관리된다. (Chef에서 cookbook이나 recipe처럼) Charm의 구성요소는 아래와 같다.

(1) Metadata

(2) Hooks

(3) Custom contents

Metadata는 name, description, relation, configuration option 등으로 구성이 되는데 이 중 중요한 것은 relation이다.

예를 들어, Wordpress charm의 metadata는 위의 그림처럼 정의되어 있는데 requires와 provides, peers로 된 부분이 relation 설정이다. Relation은 interface, kind, name으로 구성되어 있는데 각각의 정의는 이렇다.

Interface : Hook을 통해서 정보를 교환하기 위한 protocol (진짜 interface의 의미도 있지만...)

Kind : Relation의 종류로 requirer, provder, peer 중 하나를 의미하는데 requirer는 이런 relation이 필요해, provider는 이런 relation을 내가 해줄게, peer는 클러스터링 할 때는 이런 걸로 하자로 이해하면 편할 것 같다.

Name : identifier로서의 역할이고 위 wordpress metadata에서 보면 name 항목의 wordpress,  requires: db: interface: mysql 항목의 mysql을 모두 name이라고 생각하면 된다.

Hook은 위에서도 언급했듯이 event가 발생했을 때 실행되는 script로 어떤 언어로 된 script도 관계없다고 명시되어 있다. 그러니까 특정 event 발생시 각 service unit들이 해줘야 하는 동작을 script로 정의하면 되는데 몇 개 charm을 둘러보니 대부분 bash와 python으로 구현하는 것으로 보인다.

4. Deploy​

Bootstrap 한 이후에 위의 charm을 가지고 deploy하는 과정은 단순히 juju deploy <charm name> 형태의 command만 실행하면 된다. 정말 간단하다. 실행하면 charm이 올라갈 instance를 생성하고 instance 생성이 완료되면 charm에 정의된 install hook이 실행되서 필요한 tool을 설치하거나 설정하게 된다. 그리고 deploy 후에 state server (bootstrap instance)에 상태 정보를 요청하면 아래와 같은 내용을 확인할 수 있다.

5. Instance에 접속하고 싶다면​

대부분의 관리가 juju command로 가능하지만 그래도 배포된 instance에 접속해야하는 상황이 있을 수 있다. 그 경우 juju ssh 0 (0번은 bootstrap instance에 대해서 붙여진 번호), juju ssh <unit_name> 형태의 command를 사용하면 ssh로 접속이 가능하다. 실제로 bootstrap instance나 다른 instance를 생성할 때 juju client에서 관리하는 public key를 전송해서 각 instance (machine)의 authorized_keys에 추가하기 때문에 juju command가 싫다면

ssh -i <private_key_path> ubuntu@<dns_name>

으로 접속할 수 있다. (Juju client가 설치된 장비의 private key는 기본적으로 ~/.juju/ssh 경로에 생성됨)

6. Add relation​

4에서처럼 charm을 deploy 하고나면 단지 설치만 된다. Wordpress charm의 경우 설치했을 때 wordpress만 설치되고 mysql 등의 DB는 별도로 설치되지 않는다. MySQL이 필요하니 deploy를 한다해도 역시 설치만 되고 각 service는 별개의 것으로 남아있게 된다. juju add-relation wordpress mysql 명령을 실행해보자. (wordpress, mysql은 charm의 이름이지만 이미 설치된 것이고 state server에서 각 service unit에 대한 상태를 관리하고 있으니 문제없다)

위 그림은 순서대로 mysql과 wordpress가 설치된 instance에서 수집한 로그인데 add-relation 명령 실행시 mysql에서는 db-relation-joined, wordpress에서는 db-relation-changed가 순차적으로 실행되는 것을 확인할 수 있다. db-relation-joined와 db-relation-changed는 각각 mysql과 wordpress charm에 정의되어 있는 hook으로 add-relation 명령이 수행되면 wordpress와 mysql이 provide하고 require하고 있는 항목인 db에 대한 relation-joined hook이 실행되는데 db-relation-joined hook은 mysql에만 정의되어 있으므로 먼저 실행된다.

db-relation-joined hook의 내용을 살펴보면 위 그림처럼 relation-set 명령을 호출해서 db 접속정보를 설정하는 것을 알 수 있다. 위의 접속정보는 state server에 저장되고나면 변경사항이 발생되었기 때문에 db-relation-changed hook이 실행되는데 이것은 wordpress에만 정의되어 있는 hook이므로 wordpress에서만 실행되며 state server에 저장된 db 접속정보를 받아와서 설치된 wordpress에 설정파일들을 수정하거나 다른 조작을 가하도록 정의되어 있어 wordpress와 mysql 사이의 연결이 가능해진다.

7. Expose​

Deploy와 relation의 과정을 거치고 나더라도 바로 wordpress를 이용할 수는 없다. Cloud service 들의 특성상 보안 등의 이유로 대부분의 port는 연결이 되지 않도록 막혀있기 때문에 특정 port를 열어주는 작업이 필요하다. 위의 과정으로 deploy 한 것은 wordpress와 mysql 뿐이고 wordpress만 열면 되기 때문에 간단하게

juju expose wordpress

명령만 실행하고 나면 약간의 시간 후에 아래의 그림처럼 endpoint 설정이 추가된 것을 확인할 수 있다. (Azure 기준)

Wordpress나 MySQL charm에서 어떤 부분이 expose를 가능하게 하는지 아직 찾지 못했다. MySQL을 expose 해보니 status에서 exposed flag 값만 false에서 true로 바뀔 뿐 실제 endpoint 설정이 추가되지는 않는데 이 부분은 좀 더 살펴볼 필요가 있을 것 같다.

8. 참고​

https://jujucharms.com/docs/stable/getting-started

http://blog.labix.org/2013/06/25/the-heart-of-juju

http://askubuntu.com/questions/55179/what-is-the-purpose-of-the-bootstrapping-instance-in-juju

http://www.slideshare.net/LeonardoBorda/leonardo-borda-maas-and-juju-introduction