Cloud watch – Log  중앙 수집 관리. Alart 설정 가능 (report update)

 

AWS Directory Service – 자체 구축(samba 기반), AD Connector

Support Console 통합. 기존에는 페이지 분리되어 있었으나 콘솔 안으로 통합 됨.

Route 53 – Private DNS 구축 가능. AWS 내부에서만 가능.

 

톰캣 튜닝

조대협

 

이번에는 톰캣 서버에 대한 튜닝 옵션에 대해서 한번 알아보자.

애플리케이션 관점에서의 튜닝도 중요하지만, 각 솔루션에 대한 특성을 업무 시나리오에 맞춰서 튜닝하는 것도 못지 않게 중요하다. 여기서 톰캣 튜닝을 설명하는 것은 톰캣 자체에 대한 튜닝 옵션을 소개하는 것도 목적이 있지만, 그보다 업무형태에 따라서 어떠한 접근을 해서 톰캣을 튜닝하는지를 소개하기 위함이다.

 

가정

여기서 튜닝 하는 톰캣은 HTTP/JSON형태의 REST 형태로 서비스를 제공하는 API 서버의 형태이다. 여러대의 톰캣을 이용하여 REST 서비스를 제공하며, 앞단에는 L4 스위치를 둬서 부하를 분산하며, 서비스는 stateless 서비스로 공유되는 상태 정보가 없다. 

server.xml 튜닝

톰캣의 대부분 튜닝 패러미터는 ${Tomcat_HOME}/conf/server.xml 파일에 정의된다.

몇몇 parameter를 살펴보도록 하자.

 

Listener 설정

 <Listener className=”org.apache.catalina.security.SecurityListener” checkedOsUsers=”root” /> 

이 옵션은 tomcat이 기동할 때, root 사용자이면 기동을 하지 못하게 하는 옵션이다. 서버를 운영해본 사람이라면 종종 겪었을 실수중의 하나가application server를 root 권한으로 띄웠다가 다음번에 다시 실행하려고 하면 permission 에러가 나는 시나리오 이다. root 권한으로 서버가 실행되었기 때문에, 각종 config 파일이나 log 파일들의 permission이 모두 root로 바뀌어 버리기 때문에, 일반 계정으로 다시 재 기동하려고 시도하면, config 파일이나 log file들의 permission 이 바뀌어서 파일을 읽어나 쓰는데 실패하게 되고 결국 서버 기동이 불가능한 경우가 있다. 이 옵션은 이러한 실수를 막아 줄 수 있다.

 

Connector 설정

 

protocol=”org.apache.coyote.http11.Http11Protocol”

먼저 protocol setting인데, Tomcat은 네트워크 통신하는 부분에 대해서 3가지 정도의 옵션을 제공한다. BIO,NIO,APR 3 가지이다. NIO는 Java의 NIO 라이브러리를 사용하는 모듈이고, APR은 Apache Web Server의 io module을 사용한다. 그래서 C라이브러리를 JNI 인터페이스를 통해서 로딩해서 사용하는데, 속도는 APR이 가장 빠른것으로 알려져 있지만, JNI를 사용하는 특성상, JNI 코드 쪽에서 문제가 생기면, 자바 프로세스 자체가 core dump를 내면서 죽어 버리기 때문에 안정성 측면에서는 BIO나 NIO보다 낮다. BIO는 일반적인 Java Socket IO 모듈을 사용하는데, 이론적으로 보면 APR > NIO > BIO 순으로 성능이 빠르지만, 실제 테스트 해보면 OS 설정이나 자바 버전에 따라서 차이가 있다. Default는 BIO이다.

 

acceptCount=”10″

이 옵션은 request Queue의 길이를 정의한다. HTTP request가 들어왔을때, idle thread가 없으면 queue에서 idle thread가 생길때 까지 요청을 대기하는 queue의 길이이다. 보통 queue에 메세지가 쌓였다는 것은 해당 톰캣 인스턴스에 처리할 수 있는 쓰레드가 없다는 이야기이고, 모든 쓰레드를 사용해도 요청을 처리를 못한다는 것은 이미 장애 상태일 가능성이 높다.

그래서 큐의 길이를 길게 주는 것 보다는, 짧게 줘서, 요청을 처리할 수 없는 상황이면 빨리 에러 코드를 클라이언트에게 보내서 에러처리를 하도록 하는 것이 좋다. Queue의 길이가 길면, 대기 하는 시간이 길어지기 때문에 장애 상황에서도 계속 응답을 대기를 하다가 다른 장애로 전파 되는 경우가 있다.

순간적인 과부하 상황에 대비 하기 위해서 큐의 길이를 0 보다는 10내외 정도로 짧게 주는 것이 좋다.

 

enableLookups=”false”

톰캣에서 실행되는 Servlet/JSP 코드 중에서 들어오는 http request에 대한 ip를 조회 하는 명령등이 있을 경우, 톰캣은 yahoo.com과 같은 DNS이름을 IP주소로 바뀌기 위해서 DNS 서버에 look up 요청을 보낸다. 이것이 http request 처리 중에 일어나는데, 다른 서버로 DNS 쿼리를 보낸다는 소리이다. 그만큼의 서버간의 round trip 시간이 발생하는데, 이 옵션을 false로 해놓으면 dns lookup 없이 그냥 dns 명을 리턴하기 때문에, round trip 발생을 막을 수 있다.

 

compression=”off”

HTTP message body를 gzip 형태로 압축해서 리턴한다. 업무 시나리오가 이미지나 파일을 response 하는 경우에는  compression을 적용함으로써 네트워크 대역폭을 절약하는 효과가 있겠지만, 이 업무 시스템의 가정은, JSON 기반의 REST 통신이기 때문에, 굳이 compression을 사용할 필요가 없으며, compression에 사용되는 CPU를 차라리 비지니스 로직 처리에 사용하는 것이 더 효율적이다.

 

maxConnection=”8192″

하나의 톰캣인스턴스가 유지할 수 있는 Connection의 수를 정의 한다.

이 때 주의해야 할 점은 이 수는 현재 연결되어 있는 실제 Connection의 수가 아니라 현재 사용중인 socket fd (file descriptor)의 수 이다. 무슨 말인가 하면 TCP Connection은 특성상 Connection 이 끊난 후에도 바로 socket이 close 되는 것이 아니라 FIN 신호를 보내고, TIME_WAIT 시간을 거쳐서 connection을 정리한다. 실제 톰캣 인스턴스가 100개의 Connection 으로 부터 들어오는 요청을 동시 처리할 수 있다하더라도, 요청을 처리하고 socket이 close 되면 TIME_WAIT에 머물러 있는 Connection 수가 많기 때문에, 단시간내에 많은 요청을 처리하게 되면 이TIME_WAIT가 사용하는 fd 수 때문에, maxConnection이 모자를 수 있다. 그래서 maxConnection은 넉넉하게 주는 것이 좋다.

이외에도 HTTP 1.1 Keep Alive를 사용하게 되면 요청을 처리 하지 않는 Connection도 계속 유지 되기 때문에, 요청 처리 수 보다, 실제 연결되어 있는 Connection 수가 높게 된다.

그리고, process당 열 수 있는 fd수는 ulimit -f 를 통해서 설정이 된다. maxConnection을 8192로 주더라도, ulimit -f에서 fd 수를 적게 해놓으면 소용이 없기 때문에 반드시 ulimit -f 로 최대 물리 Connection 수를 설정해놔야 한다.

 

maxKeepAliveRequest=”1″

HTTP 1.1 Keep Alive Connection을 사용할 때, 최대 유지할 Connection 수를 결정하는 옵션이다. 본 시나리오에서는 REST 방식으로Connectionless 형태로 서비스를 진행할 예정이기 때문에, Kepp Alive를 사용하지 않기 위해서 값을 1로 준다.

만약에 KeepAlive를 사용할 예정이면, maxConnection과 같이 ulimit에서 fd수를 충분히 지정해줘야 하낟.

 

maxThread=”100″

사실상 이 옵션이 가장 중요한 옵션이 아닌가 싶다. 톰캣내의 쓰레드 수를 결정 하는 옵션이다. 쓰레드수는 실제 Active User 수를 뜻한다. 즉 순간 처리 가능한 Transaction 수를 의미한다.

일반적으로 100 내외가 가장 적절하고, 트렌젝션의 무게에 따라 50~500 개 정도로 설정하는 게 일반적이다. 이 값은 성능 테스트를 통해서 튜닝을 하면서 조정해 나가는 것이 좋다.

 

tcpNoDelay=”true”

TCP 프로토콜은 기본적으로 패킷을 보낼때 바로 보내지 않는다. 작은 패킷들을 모아서 버퍼 사이즈가 다 차면 모아서 보내는 로직을 사용한다. 그래서 버퍼가 4K라고 가정할때, 보내고자 하는 패킷이 1K이면 3K가 찰 때 까지 기다리기 때문에, 바로바로 전송이 되지 않고 대기가 발생한다.

tcpNoDelay 옵션을 사용하면, 버퍼가 차기전에라도 바로 전송이 되기 때문에, 전송 속도가 빨라진다. 반대로, 작은 패킷을 여러번 보내기 때문에 전체적인 네트워크 트래픽은 증가한다. (예전에야 대역폭이 낮아서 한꺼번에 보내는 방식이 선호되었지만 요즘은 망 속도가 워낙 좋아서tcpNoDelay를 사용해도 대역폭에 대한 문제가 그리 크지 않다.)

 

Tomcat Lib 세팅

다음으로 자바 애플리케이션에서 사용하는 라이브러리에 대한 메모리 사용률을 줄이는 방법인데, 일반적으로 배포를 할때 사용되는 라이브러리(jar)를 *.war 패키지 내의 WEB-INF/jar 디렉토리에 넣어서 배포 하는 것이 일반적이다. 보통 하나의 war를 하나의 톰캣에 배포할 때는 큰 문제가 없는데, 하나의 톰캣에 여러개의 war 파일을 동시 배포 하게 되면, 같은 라이브러리가 각각 다른 클래스 로더로 배포가 되기 때문에, 메모리 효율성이 떨어진다.

그래서 이런 경우는 ${TOMCAT_HOME}/lib 디렉토리에 배포를 하고 war 파일에서 빼면 모든 war가 공통 적으로 같은 라이브러리를 사용하기 때문에 메모리 사용이 효율적이고, 또한 시스템 운영 관점에서도 개발팀이 잘못된 jar 버전을 패키징해서 배포하였다 하더라도, lib 디렉토리의 라이브러리가 우선 적용되기 때문에, 관리가 편하다.

반대로 war의 경우, war만 운영중에 재배포를 하면 반영이 가능하지만, lib 디렉토리의 jar 파일들은 반드시 톰캣 인스턴스를 재기동해야 반영되기 때문에, 이 부분은 주의해야 한다.

 

JVM Tuning

Java Virtual Machine 튜닝은 java 기반 애플리케이션에서는 거의 필수 요소이다.

-server

제일 먼저 해야할일은 JVM 모드를 server 모드로 전환하는 것이다. JVM 내의 hotspot 컴파일러도 클라이언트 애플리케이션이나 서버 애플리케이션이냐 에 따라서 최적화 되는 방법이 다르다.

그리고 메모리 배치 역시 클라이언트 애플리케이션(MS 워드와같은)의 경우 버튼이나 메뉴는 한번 메모리에 로드 되면, 애플리케이션이 끝날 때 까지 메모리에 잔존하기 때문에 Old 영역이 커야 하지만, 서버의 경우 request를 받아서 처리하고 응답을 주고 빠져서 소멸되는 객체들이 대부분이기 때문에, New 영역이 커야 한다.

이런 서버나 클라이언트냐에 대한 최적화 옵션이 이 옵션 하나로 상당 부분 자동으로 적용되기 때문에, 반드시 적용하기를 바란다.

 

메모리 옵션

앞에서도 설명하였듯이 JVM 튜닝의 대부분의 메모리 튜닝이고 그중에서도 JVM 메모리 튜닝은 매우 중요하다. 결국 Full GC 시간을 줄이는 것이 관건인데, 큰 요구 사항만 없다면, 전체 Heap Size는 1G 정도가 적당하다. 그리고 New대 Old의 비율은 서버 애플리케이션의 경우 1:2 비율이 가장 적절하다. 그리고 PermSize는 class가 로딩되는 공간인데, 배포하고자 하는 애플리케이션이 아주 크지 않다면 128m 정도면 적당하다. (보통256m를 넘지 않는다. 256m가 넘는다면 몬가 애플린케이션 배포나 패키징에 문제가 있다고 봐야 한다.)

그리고 heap size는 JVM에서 자동으로 늘리거나 줄일 수 가 있다. 그래서 -Xms와 -Xmx로 최소,최대 heap size를 정할 수 있는데, Server 시스템의 경우 항상 최대 사용 메모리로 잡아 놓는 것이 좋다. 메모리가 늘어난다는 것은 부하가 늘어난다는 것이고, 부하가 늘어날때 메모리를 늘리는 작업 자체가 새로운 부하가 될 수 있기 때문에, 같은 값을 사용하는 것이 좋다.

이렇게 JVM 메모리를 튜닝하면 다음과 같은 옵션이 된다.

-Xmx1024m –Xms1024m -XX:MaxNewSize=384m -XX:MaxPermSize=128m

이렇게 하면 전체 메모리 사용량은 heap 1024m (이중에서 new가 384m) 그리고 perm이 128m 가 되고, JVM 자체가 사용하는 메모리가 보통300~500m 내외가 되서 java process가 사용하는 메모리 량은 대략 1024+128+300~500 = 대략 1.5G 정도가 된다.

 

32 bit JVM의 경우 process가 사용할 수 있는 공간은 4G가 되는데, 이중 2G는 시스템(OS)이 사용하고 2G가 사용자가 사용할 수 있다. 그래서 위의 설정을 사용하면 32bit JVM에서도 잘 동작한다.

64 bit JVM의 경우 더 큰 메모리 영역을 사용할 수 있는데, 일반적으로 2G를 안 넘는 것이 좋다.(최대 3G), 2G가 넘어서면 Full GC 시간이 많이 걸리기 시작하기 때문에, 그다지 권장하지 않는다. 시스템의 가용 메모리가 많다면 Heap을 넉넉히 잡는 것보다는 톰캣 인스턴스를 여러개 띄워서 클러스터링이나 로드밸런서로 묶는 방법을 권장한다.

 

OutOfMemory

자바 애플리케이션에서 주로 문제가 되는 것중 하나가 Out Of Memory 에러이다. JVM이 메모리를 자동으로 관리해줌에도 불구하고, 이런 문제가 발생하는 원인은 사용이 끝낸 객체를 release 하지 않는 경우이다. 예를 들어 static 변수를 통해서 대규모 array나 hashmap을 reference 하고 있으면, GC가 되지 않고 계속 메모리를 점유해서 결과적으로 Out Of Memory 에러를 만들어낸다.

Out Of Memory 에러를 추적하기 위해서는 그 순간의 메모리 레이아웃인 Heap Dump가 필요한데, 이 옵션을 적용해놓으면, Out Of Memory가 나올때, 순간적으로 Heap Dump를 떠서 파일로 저장해놓기 때문에, 장애 발생시 추적이 용이하다.

-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_pid<pid>.hprof

 

GC 옵션

다음은 GC 옵션이다. Memory 옵션 만큼이나 중요한 옵션인데, Parallel GC + Concurrent GC는 요즘은 거의 공식처럼 사용된다고 보면 된다. 이때 Parallel GC에 대한 Thread 수를 정해야 하는데, 이 Thread수는 전체 CPU Core수 보다 적어야 하고, 2~4개 정도가 적당하다.

-XX:ParallelGCThreads=2 -XX:-UseConcMarkSweepGC

GC 로그 옵션

그리고 마지막으로 GC Log 옵션이다. 서버와 JVM이 건강한지 메모리상 문제는 없는지 GC 상황은 어떻게 디는지를 추적하려면 GC 로그는 되도록 자세하게 추출할 필요가 있다. GC로그를 상세하게 걸어도 성능 저하는 거의 없다.

-XX:-PrintGC -XX:-PrintGCDetails -XX:-PrintGCTimeStamps -XX:-TraceClassUnloading -XX:-TraceClassLoading

 

마지막에 적용된 TraceClassLoading은 클래스가 로딩되는 순간에 로그를 남겨준다. 일반적으로는 사용하지 않아도 되나, OutOfMemory 에러 발생시 Object가 아니라 class에서 발생하는 경우는 Heap dump로는 분석이 불가능 하기 때문에, Out Of Memory 에러시 같이 사용하면 좋다.

 

지금까지 간략하게 나마 톰켓 솔루션에 대한 튜닝 parameter 에 대해서 알아보았다. 사실 이러한 튜닝은 일반적인 개발자에게는 힘든 일이다. 해당 솔루션에 대한 많은 경험이 있어야 하기 때문에, 이런 parameter는 vendor의 기술 지원 엔지니어를 통해서 가이드를 받고, 성능 테스트 과정에서 최적화를 하고 표준화된 parameter를 정해서 사용하는 것이 좋다. Apache Tomcat의 경우에도 오픈소스이기는 하지만, Redhat등에서 기술 지원을 제공한다.

 

Apache Tomcat Tuning Guide

 

출처: <http://bcho.tistory.com/category/%EC%84%B1%EB%8A%A5%EA%B3%BC%20%ED%8A%9C%EB%8B%9D/WAS%20%ED%8A%9C%EB%8B%9D>

출처 : http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1259&keyword=WD+My+Cloud+%B8%B5%C5%A9+%B8%F0%C0%BD%C1%FD

 

1. 수령기 – http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=453

내용물이 어떤 것들이 있나 볼 수 있습니다.

2. 사용기 – 메뉴편  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=462

메뉴를 하나씩 뜯어보는 사용기입니다.

3. 사용기 – 성능편  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=476

복구 후 다시 측정해보았습니다.

FTP에서 약간 낮은 성능이 나오고, 삼바에서는 MBL과 거의 비슷한 60~100MB/s 정도 뽑아줍니다.

※ 외국 사용기 – http://www.smallnetbuilder.com/nas/nas-reviews/32244-wd-my-cloud-reviewed

※ 공식 한글 매뉴얼 – http://www.wdc.com/wdproducts/library/UM/KOR/4779-705103.pdf

규규s님의 도움으로 추가합니다.

4. 전체 파티션 백업 파일  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=452

혹시나 분해 후 전체 초기화를 시도하시는 분은 이 파일을 이용하시면 됩니다.

2TB, 3TB, 4TB 모두 있습니다.

5. 분해하는 방법 및 복구 시도기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=477

분해하고 싶으신 용자분들을 위해 사진을 찍어보았습니다.

6. 트랜스미션 설치하기 – 디엠님의 글을 참조하여 초보분들도 설치하기 쉽게 써봤습니다.

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=534

6-(0) WD My Cloud 새펌웨어에 트랜스미션 설치하기 (펌웨어 v04버전)

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=1008

6-(1) 트랜스미션 설치하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=836

디엠님의 글입니다. – 요새는 Abort 에러가 난다고 합니다.

6-(2) Transmission 설정 자동 백업 하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2009

펌웨어 업그레이드 할 때 트랜스미션의 백업 및 복원을 편하게 하기위한 글입니다.

6-(3) 트랜스미션 다운받은 파일의 samba 권한 문제 해결 – http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2070

비스바덴님의 좋은 글입니다.

6-(4) rtorrent + rutorrent 설치하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=764

트랜스미션보다 속도가 더 빠른 토렌트 패키지입니다.

7. minidlna 설치하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1147

올나이트님의 글입니다.

TV에서 My Cloud의 영상을 볼 수 있게 하는 패키지 설치 방법입니다.

7-(1) minidlna 설치하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2139

아야옹님의 좀더 자세한 설치기입니다.

7-(2) 블벅고아님의 파일을 적용한 SMI 파일 인식되는 minidlna 설치하는 강좌입니다.

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=690

8. 에어코믹스 쉽게 설치하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=841

디엠님의 강좌와 DRS님의 버그 수정까지 포함했습니다.

쉽게 설치하고 쉽게 삭제 가능합니다.

8 – (1) 디엠님의 에어코믹스 설치하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=938

My Cloud의 만화를 폰이나 태블릿으로 바로 볼 수 있게하는 패키지입니다.

8 – (2) 에어코믹스 웹 뷰어 설치하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=539

인터넷 브라우저로 에어코믹스 만화를 볼 수 있는 방법입니다.

9. 이츠모히토리님의 복구 방법 연구기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=980

복구하는 방법에 대한 논의입니다.

10. mrlee님의 복구 성공기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=986

복구 성공하셨다고 합니다.

11. 분노의코딱지님의 복구 성공기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1042

마찬가지로 성공하셨네요.

12. 등잔밑님의 복구 성공기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1092

제가 올려드린 풀백업본으로 성공하셨습니다.

13. 하나아빠II님의 복구 성공기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1102

풀백업본으로 성공하셨습니다.

14. 통이미지로 복구하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1285

제가 복구한 방법입니다. MBL의 복구 방식과 정확하게 같고, 마지막에 reboot을 해주는게 핵심입니다.

14-(1) WD My Cloud에 새 하드 설치하는 방법 + 공장초기화

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=674

마이클라우드 공장초기화 하는 방법입니다.

마찬가지로 새 하드에도 설치할 수 있어서 같이 적어봤습니다.

14-(2) My Cloud 3TB 통이미지와 복구 방법입니다.  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2217

잠시깬겨울잠님의 소중한 글입니다.

14-(3)  2TB 보다 적은 용량의 하드 또는 SSD에 마클을 설치하는 방법입니다.  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=4700

arimaKim님과 K.a.Z.e님의 소중한 글과 댓글이 있습니다.

15.  닉할게없어님의 Webdav 강좌  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1301

외부에서 폴더를 바로 보고 다운받을 수 있게 해줍니다.

webdav 프로토콜 지원하는 앱에서 바로 접속도 가능하구요.

16. 제가 적어본 Webdav 강좌입니다.  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=496

유저 추가와 삭제 부분 보강하였습니다. 나머지는 윗글과 같습니다.

17. My Cloud 사양과 사양 보는 방법입니다.  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=494

18. MBL에서도 소개드렸던 모니터링 툴입니다.  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=493

HTOP과 IFTOP 설치 방법입니다.

19. 아이튠즈 서버를 이용하여 음원을 스트리밍으로 듣는 방법 –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=503

20. USB3.0 연결하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=504

21. 대시보드 접근 불가시 SSH로 펌웨어 수동 업그레이드하여 해결하는 방법  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=1609

신기루오아시스님의 글입니다. 기기 분해하기 전에 시도해보는 것을 추천합니다.

22. 쥬스박스(JuiceBox) 웹 갤러리 설치하는 방법  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=553

언제 어디서나 사진을 볼 수 있는 웹 갤러리를 MC에 설치하는 강좌입니다.

23. MC의 파일을 쉽게 공유하기 – http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=554

아파치를 이용하여 암호 없이 지인에게 쉽게 파일 링크를 주는 방법입니다.

파일 목록을 보여줄 수도 있고, 활용법은 무궁무진하겠죠.

24. Mysql 설치하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=556

DB가 필요한 패키지 설치를 위해서 설치 방법을 올려봅니다.

25. PHP 설치 및 업그레이드하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=557

PHP 버전이 이상하여 추가 패키지가 설치되지 않았습니다.

sid 소스로 업그레이드 가능합니다. 하지만 대시보드에서 이메일 알림이 되지 않는 버그가 있습니다.

26. 나만의 홈페이지를 만들 수 있습니다. My Cloud가 서버 역할을 하는 것이죠 ^^  –

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=560

26-(1) 홈페이지에 아미나테마 꾸미기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=369

썰렁한 그누보드에 옷을 입혀줍시다!

27. 수동으로 펌웨어 업데이트 하기

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=631

대시보드가 깨졌거나, 각종 패키지들이 문제가 생겼을 떄 해결할 수 있는 방법입니다.

27-(1) WD My Cloud v03.04.01-230로 펌웨어 다운그레이드 하는 방법

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=1006

28. 최신 펌웨어 업그레이드 후기 (03.03.01-156)

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=616

29. FTP 설정 및 내부 외부 접속하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2150

burrowman님의 초보를 위한 좋은 글입니다.

30. Rync를 이용한 MC 파일을 USB외장하드에 백업하는 방법 – http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2422

Woody님의 좋은 글입니다.

31. 미디어 검색 이상시 해결 방법  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2399

ainamva님의 좋은 글입니다.

32. MPD 설치하여 음악 재생 머신으로 사용하기

1편 : http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=709

2편 : http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=710

33. 외부에서 대시보드 접속하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2954

파인애플에이드님의 글입니다.

34. EBS 라디오 녹음하기  –  MBL와 같이 EBS 녹음이 가능합니다.

http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=686

34 – (1) MMS 프로토콜 라디오 녹음하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=724

MBC나 SBS 라디오 같이 MMS 주소를 가지고 있는 인터넷 라디오 녹음 방법입니다.

35. 미디어 크롤러 정지시키기  –  마클에 부하를 주는 크롤러를 정지시키는 방법입니다.

http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=2957

36. bubble upnp server 설치하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=3431

외부에서 DLNA 또는 UPNP 서버를 접속할 수 있게 해줍니다.

성스러운 곰탱이님의 좋은 글입니다.

37. 나만의 클라우드 owncloud 설치하기 – http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=775

드롭박스 같은 기능을 MC에 설치할 수 있습니다.

파일 링크 기능만으로도 설치 가치가 충분한 프로그램입니다.

38. cups를 설치하여 printer server로 사용하기  –  http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=4334

성스러운곰탱이님의 소중한 글입니다.

39. 비트토렌트 싱크 설치하기 – http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=840

드롭박스나 유클라우드처럼 마클과 다른 기계간의 폴더 동기화를 시켜주는 프로그램입니다.

39-(1) 큼큼큼큼님의 설치 강좌입니다. – http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=4766

40. 타임머신 백업할 때 작은 팁 – http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=4861

헉키님의 글입니다.

40-(1) mac에서 afp를 통한 자동 마운트 및 내외부 타임머신 자동 백업 – http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=4891

net40ml님의 글입니다.

41. HD-IDLE 패키지 설치하여 수동으로 절전모드 관리하기 – http://www.ppomppu.co.kr/zboard/view.php?id=nas&no=4921

큼큼큼큼님의 글입니다.  수동으로 진입 가능하며, 자체 절전모드가 잘 안될 때 좋은 방법입니다.

42. 가벼운 웹하드서비스 h5ai 설치하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=886

외부에서 편하게 public 폴더들을 볼 수 있습니다.

43. SSH 접속 비밀번호 초기화 하기  –  http://www.wsgvet.com/bbs/board.php?bo_table=iomega&wr_id=887

SSH 비번을 잊어버렸다면 시스템만 초기화를 선택하면 됩니다.

44. 순정 데비안 설치하기  –  http://www.wsgvet.com/iomega/1207

WD에서 벗어나 순정으로 돌아갈 수 있습니다.

44 – 1. WD My Cloud 순정 데비안에 openmediavault 설치하기

http://www.wsgvet.com/iomega/1214

오픈소스인 OMV를 설치하는 방법입니다.

44 – 2. openmediavault(OMV)에 gmail 알림 설정하기

http://www.wsgvet.com/iomega/1215

OMV에서 알림 메일 설정하는 방법입니다.

44 – 3. 순정 데비안에 Samba4 설치하기

http://www.wsgvet.com/iomega/1220

Samba 최신버전을 순정 데비안에 설치하는 방법입니다.

OMV와는 호환되기 어려워보입니다.

 

마운트를 해제 하려 하지만, 해당 장치 혹은 파티션이 사용 중일때 발생하는 메세지입니다.

 

# umount /data

umount: /data: device is busy

 

아래 명령어를 통해 data 디렉토리를 사용하고 있는 유저를 확인 합니다.

# fuser -cu /data

/data:               22838c(rubi) 24997c(rubi)

 

/data 디렉토리를 사용하고 있는 유저를 kill 시킵니다. (logout 됩니다)

ssh 와 같이 접속 된 계정이 포함되어 있다면 같이 로그아웃 될 수 있으니 유의하시기 바랍니다.

# fuser -ck /data

 

정상적으로 유저가  로그아웃 처리 되었다면 umount 처리 됩니다.

# umount /data

 

위와 같이 수행 했는데 안될 경우. 강제 옵션을 통해 처리합니다.

-f     Force unmount (in case of an unreachable NFS system).  (Requires kernel 2.1.116 or later.)

 

# umount -f /data

최근 관심을 가지게 된 oepnstack의 찾아보던 중 한번에 다 읽어볼 수 없기에 남겨놓습니다.

다른 글 및 링크들도 추가할 예정.

 

오픈스택을 다루는 기술 의 저자이신 장현정님의 블로그 링크.

[OpenStack Class] 제1강 클라우드가 뭐지?

[OpenStack Class] 제2강 컴퓨트 서비스와 스토리지 서비스

[OpenStack Class] 제3강 클라우드의 핵심! 하이퍼바이저

[OpenStack Class] 제4강 블록 스토리지와 오브젝트 스토리지

[OpenStack Class] 제5강 클라우드 서비스를 구축할 수 있는 오픈소스 플랫폼

[OpenStack Class] 제6강 OpenStack의 역사!

[OpenStack Class] 제7강 컴퓨트 서비스! NOVA

[OpenStack Class] 제8강 오브젝트 스토리지 서비스! SWIFT

[OpenStack Class] 제9강 이미지 서비스! GLANCE

[OpenStack Class] 제10강 인증 서비스! KEYSTONE

[OpenStack Class] 제11강 네트워크 서비스! NEUTRON

[OpenStack Class] 제12강 블록 스토리지! CINDER

[OpenStack Class] 제13강 데쉬보드 서비스! HORIZON

[OpenStack Class] 제14강 기타 서비스들~!!

[OpenStack Class] 제15강 오픈스택을 설치하기 위한 방법들~!!

[OpenStack Class] 제16강 오픈스택 설치 1편 – 하이퍼바이저를 이용한 서버 준비

[OpenStack Class] 제17강 오픈스택 설치 2편 – 버철박스에서의 가상서버 생성

[OpenStack Class] 제18강 오픈스택 설치 3편 – 가상서버에 우분투 서버 설치하기

[OpenStack Class] 제19강 오픈스택 설치 4편 – 오픈스택 네트워크 구성도를 그려보자!

OpenStack Class] 제20강 오픈스택 설치 5편 – 오픈스택을 설치해 보자!

[OpenStack Class] 제21강 오픈스택 설치 6편 – 첫번째 인스턴스 생성하기!

[OpenStack Class] 제22강 오픈스택 설치 7편 – 인스턴스에 접속해보자~!

[OpenStack Class] 제23강 네트워크 서비스인 Neutron을 알아보자!

[OpenStack Class] 제24강 Neutron 설치 1편 – 네트워크 구성도 그리기!

[OpenStack Class] 제25강 Neutron 설치 2편 – 버철박스 가상서버 생성!

[OpenStack Class] 제26강 Neutron 설치 3편 – DevStack을 이용한 오픈스택 설치!

[OpenStack Class] 제27강 Neutron 설치 4편 – Neutron 네트워크 생성1~!!

[OpenStack Class] 제28강 Neutron 설치 5편 – Neutron 네트워크 생성2~!!

 

모든 링크가 출처로 연결 되어있지만.. 밝혀둡니다. 오픈스택 관련해 좋은 내용들이 많이 있네요.

출처 :  http://naleejang.tistory.com/

 

출처 : http://lunatine.net/thp-and-page-allocation-error/

 

접근 안되는 것을 방지하기 위해 복사.

 

CentOS 6.3 64bit 환경인데 파일명이 변경 된 것으로 확인 됨.

 

/sys/kernel/mm/redhat_transparent_hugepage/defrag

/sys/kernel/mm/redhat_transparent_hugepage/enabled

 

Transparent Huge Pages 와 page allocation error

1. Page allocation Error

RHEL6/Centos6를 사용하다보면 아래와 같은 메시지를 마주 할 때가 있다.

특히 위의 메시지 형태 중에서 swapper에서 발생시키는 메시지의 경우 Bug 761442에서 언급 된 것 처럼 zone_reclaim_mode를 설정해서 해결하는 방안이 있었다.

하지만, swapper가 아닌 일반 프로세스에서도 (특히, IO작업이 많거나 네트워크 처리량이 많은 서버) page allocation error가 발생하는 경우가 RHEL6.4/CentOS6.4 이하에서 많이 발견 되었다.

이를 해결하기 위해 커널 패치 이력을 살펴보았다. 이력 중에 관련성이 있어보이는 몇개의 Bug Fix 내용은 접근 권한이 없어서 상세히 못 봤지만 유추되는 내용을 통해서 해결 할 수가 있었다.

본 문서에서는 THP(Transparent Hugepages)와 Page alloation failure 메시지 해결 방안 2가지를 안내한다.

  • 대상: RHEL6.4/CentOS6.4 이하의 환경

2. Transparent Huage Pages

Linux는 메모리에 대한 관리를 Pages 블록을 통해서 하는 사실은 익히 알려진 내용이다. 그리고 기본 페이지는 4096바이트(4K)로 고정되어있다. 1GB의 메모리는 256,000개의 page로 구성되어있는 것이다. 이러한 페이지는 전체 메모리 크기가 늘어남에 따라 관리테이블(TLB)도 커지게 되는데 이를 해결하기 위해서는 페이지의 크기를 확대하는 방법이 있다. 이를, Huge Pages라 지칭하며 보통 Oracle과 같은 DB서버에서 활용하곤 했다.

Huge Pages는 기본 크기가 2MB를 많이 사용하는데 2MB 단위로 페이지를 사용하게 되면 1GB 메모리는 512개의 페이지로 관리 할 수 있다. 요즘처럼 서버에 수십에서 수백GB의 메모리를 탑제하는 환경에서는 Huge Pages가 관리/성능적인 측면에서 유리한 것이 맞다.

다만, 이러한 Huge Pages의 경우 부팅시에 커널에 파라미터를 지정해서 관리해야하는 번거로움이 있기 때문에 이를 자동으로 관리하는 방안으로 Transparent Huge Pages(THP)가 등장하게 되었다. THP를 사용하게 되면 페이지의 생성, 관리, 사용에 대한 모든 부분을 자동으로 관리하게 되며 어플리케이션에서 대용량의 메모리를 요구하게 되면 알아서 2MB (현재 2MB 단위로 제공된다) 크기의 페이지로 할당해준다.

THP는 커널 2.6.38에 등장하였다. (LWN문서) 그리고 RHEL 계열의 경우 2.6.32커널을 Base로 하면서도 THP 기능을 추가하여 릴리즈했고 무엇보다 THP를 기본으로 활성화 되도록 하였다. 문제는 성능 향상을 목적으로 한 THP가 오히려 성능을 저하하는 경우가 자주 발견되고 있다. 대표적으로 Oracle, JVM, Hadoop 등이 있으며 Google에 THP에 대해 검색해보면 많은 불만이 보일 것이다.

실제로 본 문서에서 언급한 page allocation failure의 메시지도 THP에 의해서 유동적으로 관리되던 Huge Page의 버그성 동작으로 인해 발생하는 것으로 보이며 THP 관련 된 작업을 통해서 해당 오류 메시지를 제거하였다.

3. 해결방안

page allocation failure 메시지를 제거하기 위한 방법은 크게 2가지이다.

1) THP 비활성화

첫 번째 방법은 THP를 Disable 시키는 것이다. 별도의 바이너리 패치작업 없이 Disable 설정 후에 리부팅만 진행하면 된다. 리부팅을 안해도 되는 경우도 있지만 이미 AnonHugePages가 많이 사용되고 있는 시스템 (cat /proc/meminfo로 확인해보자)에서는 리부팅을 해야 효과가 있다.

/sys 파일시스템 설정으로 비활성화

아래 파일의 설정 값을 변경하여 비활성화 할 수 있다.

위 방법은 리부팅 후에도 적용해줘야 하기 때문에 보통 /etc/rc.d/rc.local 파일에 아래와 같이 추가해 줘서 적용한다.

커널 파라미터로 비활성화

부트로더에 직접 커널 파라미터를 지정하여 비활성화 할 수 있다. grub.conf 파일의 부트 옵션에 아래의 내용을 추가해주면 된다.

2) RHEL6.5/CentOS6.5 커널로 패치

두 번째 방법은 커널을 패치하는 방법이다. 6.4에서 6.5릴리즈 커널로 변경 될 때 메모리 관리 쪽에 많은 패치가 이루어졌는데 그로 인해 THP에 의한 page allocation failure가 사라진 것을 커널 패치와 한 달 이상의 모니터링을 통해서 확인하였다.

커널 패치는 RHEL6/CentOS6 6.5릴리즈 기준 커널인 2.6.32-431.el6 이상으로 설치하면 된다. 만약 6.5릴리즈에 대한 저장소가 설정 되어있다면 간단히 yum으로 패치가 가능하다.

4. 어떤 방법이 좋은가?

page allocation failure 메시지를 없애기 위한 방법으로 크게 2가지가 있지만 (sysfs vs kernel) 어떤 방법을 적용해야 좋을지에 대해선 정답은 없다. 현재 운영하고 있는 시스템의 관리 방법에 가장 적합한 방법을 선택하기를 바란다.

Critical 한 취약점으로 반드시 Bash Shell을 사용하는 관리 시스템은 업데이트 해주시는 것이 좋습니다.

 

( 맥북, 아이폰 등 MAC의 OS X 또한 해당 됩니다. 허나, 애플에서는 대부분의 맥 사용자들은 안전 하다고 하는데요. 글쎄요..

아직 MAC용 패치는 나오지 않은 것 같습니다. 아래 기사 내용 참고)

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140927094700

 

 

해당 취약점은 환경변수에 함수정의를 통해서 원하는 코드를 추가 하고, 실행 할 수 있게 되는 취약점입니다.

 

 

– 취약점 확인 방법

아래와 같이 명령 수행시 ‘vulnerable’ 메세지가 출력 된다면 취약한 버전을 사용 중인 것입니다.

env x='() { :;}; echo Vulnerable’ bash -c “echo This is Test”

</pre>

env x='() { :;}; echo Vulnerable’ bash -c “echo This is Test”

vulnerable

This is Test

<pre>

 

– 취약점 관련 Redhat 참고링크

https://access.redhat.com/announcements/1210053

https://access.redhat.com/articles/1200223

 

– KISA에서 발생 된 두 차례 보안 업데이트 권고문

KISA 1차 업데이트 권고 – http://krcert.or.kr/kor/data/secNoticeView.jsp?p_bulletin_writing_sequence=21983

KISA 2차 업데이트 권고 – http://krcert.or.kr/kor/data/secNoticeView.jsp?p_bulletin_writing_sequence=21984

 

– 취약점 패치 방법

해당 취약점을 패치 하는 방법은 최신버전으로 update 하는 것입니다.

 

Redhat 계열

 yum 사용이 가능한 환경이라면, yum update bash -y 

yum을 사용 할 수 없는 환경이라면 아래 URL에서 rpm 파일을 받아 업데이트 해주시기 바랍니다.

https://rhn.redhat.com/errata/RHSA-2014-1293.html

 

Ubuntu 

http://www.ubuntu.com/usn/usn-2362-1/

http://www.ubuntu.com/usn/usn-2363-2/

 

Debian 

https://www.debian.org/security/2014/dsa-3035

전체 패키지 업그레이드를 하거나,

apt-get update && apt-get upgrade
bash 패키지만 업그레이드 하시면 됩니다.

apt-get update && apt-get install –only-upgrade bash

 

현재(2014.10.02) debian 7 (wheezy)은 해당 취약점이 fix된 버전이 나왔지만,

6버전(squeeze)의 경우 아직 업데이트 되지 않았습니다.

https://security-tracker.debian.org/tracker/source-package/bash

 

필요하신 분들은 LTS 버전의 source list를 추가 하셔서 업데이트 하시기 바랍니다.

echo “#LTS security” >> /etc/apt/sources.list
echo “deb http://http.debian.net/debian/ squeeze-lts main contrib non-free” >> /etc/apt/sources.list
echo “deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free” >> /etc/apt/sources.list

apt-get update && apt-get install –only-upgrade bash

 

 

SUSE Linux

http://support.novell.com/security/cve/CVE-2014-7169.html