Skip to main content

5 posts tagged with "azure"

View All Tags

· 5 min read

Java로 간단한 console application을 만들다가 이상한 문제들을 마주하게 되었다.  그 중 하나는 DB 연결이 계속 끊어지는 현상. 현재 시점에서도 DB에 가해지는 부하는 정말 작은 수준이었기 때문에 특별히 tuning할 이유는 없었고 퍼포먼스와 관련해서는 기본 설정값으로 사용하고 있었는데 끊어지는 이유를 알 수가 없었다. (MySQL 5.5의 default wait_timeout은 8시간)

1. 환경

Application 동작의 흐름은 DB select, 특정 행위, DB update 순서였는데 특정한 기능을 수행하는게 길게는 20분 정도 혹은 그 이상 소요되는 경우가 있었고 편의를 위해 MyBatis를 사용했으며 pool을 사용하도록 설정해 두었다. 연결이 끊어지는 현상을 보고 poolPingQuery, poolPingEnabled를 설정해 봤는데 마찬가지.

2. Azure에 idle timeout이 있다

우선은 MyBatis 설정과 별개로 왜 DB연결이 끊어지는지 궁금해졌다. DB와의 연결은 어차피 socket을 사용하기 때문에 DB와 application 사이의 통신에 영향을 줄 수 있는 것들은 많다. MyBatis 아래의 JDBC, Kernel의 socket timeout, 공유기 설정 등을 살펴봤는데 특이한 내용은 발견할 수 없었다.

다음으로 Azure에 어떤 특성이 있지 않을까 싶어서 알아보니 따로 idle timeout이 있다고 한다. 기본값이 4분이라고 하는데 테스트한 내용과 정확히 맞는다. (강제로 sleep 시간을 늘려가며 테스트해보니 3분까지는 문제가 없었고 4분부터 연결이 끊김을 확인) 이런 내용은 Azure 문서에 잘 보이지 않고 설정 또한 UI로는 불가능하다. PowerShell로만 가능한데 현재 열려있는 endpoint를 확인해보면 공백으로 표시되고 있고 powershell로 IdleTimeoutInMinutes 값을 30분까지 늘릴 수 있다고 한다.

3. Pool ping에 대한 잘못된 소문

Azure의 idle timeout과 별개로 MyBatis의 poolPing에 대해서 살펴보기로 했다. Pool ping 설정 중에 poolPingConnectionsNotUsedFor 가 있는데 문서 상으로는 마치 설정된 시간에 한번씩 DB에 ping으로 설정된 쿼리를 날려서 연결을 유지해줄 것처럼 보인다. 국내의 대부분 블로그 등에서도 비슷하게 설명하고 있다. 하지만 이 내용은 공식 문서가 잘못된 것인지 예상한대로 동작하지 않는다. 거의 동일한 의문을 가진 해외 사용자의 글을 보기도 했는데 소스를 보면 connection pool에서 실제 connection을 꺼내오거나 넣을 때만 connection이 유효한지 확인을 하는데 이 때 pool ping과 관련된 작업을 수행한다. poolPingConnectionsNotUsedFor에 설정된 값은 connection 유효성을 확인할 때만 영향을 주기 때문에 pool에서 connection을 꺼내오고 집어넣는 시점 이외에는 전혀 영향을 주지 않는다.

4. 결론

Azure나 기타 환경에 대한 timeout 값을 늘리는 것은 좋은 방법은 아니라고 본다. DB connection을 오래도록 유지해야만 하는 상황이라면 별도의 장치를 두어서 connection을 유지하도록 조치하거나 아니면 아예 비용이 소모되더라도 필요한 상황에서만 connection을 맺고 끊는 게 나을 것 같다..

5. 참고

(1) MyBatis 공식문서

http://www.mybatis.org/mybatis-3/configuration.html

(2) MyBatis 참고 소스

https://github.com/mybatis/mybatis-3/blob/mybatis-3.3.1/src/main/java/org/apache/ibatis/datasource/pooled/PooledDataSource.java

https://github.com/mybatis/mybatis-3/blob/mybatis-3.3.1/src/main/java/org/apache/ibatis/datasource/pooled/PooledConnection.java

· 6 min read

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로 이동해서 진행하도록 되어있다.

reset_remote_access

대략 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를 붙여준다.

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

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

grep_scsi

일반적인 경우라면 /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가 보이지 않으면 얼마 후에 다시 시도해야 한다.

· 4 min read

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

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

1. Juju charm

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

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

hadoop-charm

기술된 내용을 읽다보니 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-netstatHadoop의 구조는 잘 모르지만 master, slave로 나뉘어 있는 것으로 보아 master만 보면 되겠다며 port를 확인하니 Apache 문서대로 8088, 50070 등의 port로 들을 준비를 하고 있더라. 그렇다면 문제는 하나.

4. Expose

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

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

그래서 손으로 추가.

5. Hadoop Resource Manager

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

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

6. 결론

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

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

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

· 3 min read

Azure에서 VM 생성시 disk size가 30GB 밖에 되질 않는다.

운영체제가 올라가는 disk이고 다른 data 들을 위한 공간은 disk를 하나 더 생성해서 붙여도 되겠지만 그럴 경우 linux는 추가로 mount를 해야 하고 내가 원하는 경로로 설정하기 위해서는 다른 작업을 거쳐야 할 수 있다.

이런 경우 운영체제가 올라가 있는 disk 자체를 resizing 할 필요성이 생기는데 (아무리 그래도 사실 30GB는 작다. 왜 최초 VM 생성시에 disk size를 지정할 수 없을까?) MSDN이나 기타 여러 곳의 자료들을 보면 내용이 좀 복잡하다. 보통 이런 것 같다.

1. VM 삭제

2. VHD download

3. VHD resizing (별도의 tool을 이용)

4. VHD upload

5. VM 다시 생성

다른 과정이야 그냥 넘어간다 하더라도 download / upload가 걸린다. 30GB 짜리를 다운로드하고 늘려서 다시 업로드를 해야 한다니.

그래서 더 조사를 해봤더니 역시 나와 같은 고민을 하는 사람이 있었고 그 양반이 괜찮은 솔루션을 제시해 놨다.

그 과정은 아래와 같다.

1. VM shutdown

2. VM 삭제 (삭제할 때 drive는 유지하는 옵션을 골라야 한다)

3. VM의 disk 삭제 (삭제할 때 VHD를 유지하는 옵션을 선택한다. 그럼 VHD 파일은 storage에 그대로 남아있게 됨)

4. WindowsAzureDiskResizer로 VHD resizing (Azure storage에 올라가 있는 그대로 resizing 됨)

5. Disk 생성 (이제부터는 거꾸로 반복, resizing된 VHD로 disk를 생성한다)

6. VM 생성 (5의 disk를 선택하고 원래의 VM 내용대로 설정한다)

 

결론

VHD 파일을 분석해서 괜찮은 툴을 만들고 그걸 오픈소스로 공개한 Maarten Balliauw 덕분에 좀 편해졌다.

그래도 VM 삭제하고 다시 생성해야 하는 과정이나 애초에 disk size 선택이 불가능한 부분은 개선이 필요해 보인다.

 

참조

1. Expanding an Existing Azure VM System Drive : 여기에 설명된 과정에 백업이 있는데 별로 중요하지 않거나 귀찮다면 skip 해도 무방하다

2. Tales from the trenches: resizing a Windows Azure virtual disk the smooth way

· 6 min read

AWS, Azure 등을 사용하면서 로그 확인중에 누군가가 지속적으로 SSH 로그인 시도를 하는 것을 확인했다. IP를 확인해보니 대부분은 중국이었는데 개중엔 네팔도 있더라. 다른 계정은 알기가 어려우니 당연한 거겠지만 항상 root 계정으로 로그인을 시도했는데 그냥 두어도 무슨 문제가 있겠냐 싶었지만 뒤돌아서면 찜찜한게 마음에 걸려서 아래의 방법을 사용해보기로 했다.

 

1. ACL 설정

ACL에 특정 IP와 subnet을 등록해서 접근을 제어하는 방식을 일반적으로 많이 사용하는 것 같다. 원격지 또는 클라우드 환경에서 중요한 보안을 강화할 수 있는 간단하면서도 확실한 방법이라는 생각을 한다. 현재 사용하는 Azure에서는 설정이 매우 간단하다. 사실 복잡할 이유도 없다. 리스트에 넣기만 하면 되는거니까. Azure에서는 AWS와 달리 Endpoints 항목에서 열어놓을 port를 설정하는데 (AWS는 Security group 이라는 이름으로 관리한다) 현재 문제가 되는 서비스가 SSH라서 SSH에 대한 ACL만 설정했다.

acl

위 그림처럼 모든 IP에 대해서는 접근을 거부하고 특정 subnet에 대해서만 허용하도록 했는데 subnet이 다른 환경에서 접근이 필요한경우 ACL에 추가 설정을 해야 하겠다는 생각이 들었다. 집이나 카페에서 접속하는 경우도 있고 때에 따라서는 테더링으로 연결하는 경우도 있는데, 또 나 혼자만 SSH로 접속할게 아니지 않는가. 이렇게 환경이 변경될 때마다 리스트를 추가하는건 귀찮은 일이 아닐 수 없다. 그래서 다른 방법을 생각해야만 했다.

 

2. VPN

ACL에서 관리할 리스트를 최소로 줄이기 위해서는 Azure에 접근하는 경로를 최소한으로 줄이면 된다. 하지만 실제는 여러 경로이기 때문에 여러 경로를 최소한으로 줄일 수 있는 방법을 찾으면 되는 건데, 여러 방법이 있을 수 있지만 우선은 VPN을 구성해 보기로 했다. (RDP로 특정 서버에 접속해서 할 수도 있겠다는 생각을 하는데 VPN에 비해 상대적으로 귀찮을 것 같다) 구성하면 아래와 같은 그림이 된다.

vpn

난 VPN server를 구축하면 되고 SSH 접속이 필요한 사용자들은 VPN에 연결한 후 SSH를 사용하면 된다. VPN server의 IP에 대해서만 접근을 허용하도록 ACL에 subnet을 추가하면 불편함도 좀 덜고 동시에 SSH 로그인 시도는 막을 수 있다.

 

3. VPN 구성

공유기에도 VPN server 기능을 할 수 있는게 있다는 것 같은데 불행히도 가지고 있는 공유기들은 지원하지 않았다. 그래서 그냥 ubuntu 12.04에 설정하기로 했는데 2가지 방법을 시도해봤다. 많이 사용한다는 OpenVPN을 (이름도 마음에 든다) 우선 적용해봤는데 설정이 약간 복잡하고 몇가지 문제가 있었다. 가장 큰 걸림돌 중 하나가 OS X이나 Windows에 기본으로 사용 가능한 VPN 연결 기능에서 프로토콜을 지원하지 않는 것이었다. 별도의 client tool을 사용해야만 하는 것 같은데 VPN 연결마저도 귀찮을 수 있는데 따로 툴을 설치해야 한다는건 더 귀찮을 것 같았다. 그래서 pptpd를 사용하기로 했다. Ubuntu에 사용되는 pptpd는 OpenVPN에 비해 설정도 상대적으로 간단했다. 설정했던 내용은

(1) apt-get으로 pptpd 설치

(2) VPN에 연결하는 client에 분배할 IP 대역 설정 (/etc/pptpd.conf)

(3) 네임서버 설정 (/etc/ppp/pptpd-options)

(4) VPN 계정 및 허용 IP 설정 (/etc/ppp/chap-secrets)

(5) IP forwarding 설정 (/etc/sysctl.conf)

(6) iptables masquerade 설정

 

VPN 구성하다보니 네트웍 부분에 대해 더 깊게 알아야겠다는 생각이 든다.