RabbitMQ/ActiveMQ 와 같은 비동기 메시징 미들웨어를 이용하여 다량의 서버를 orchestration(command & control) 할 수 있는 mcollective에 대한 한글 ppt 자료입니다. 상세한 내용은 http://wiki.tunelinux.pe.kr/x/LQAy 를 참고하시면 됩니다.
3. 목차
• MCollective 는 무엇인가 ?
• MCollective 작동방식
• Mcollective component
• MCollective 설치 - Vagrant
• MCollective 테스팅 - mco
• MCollective 설치
• 미들웨어 설정
• ActiveMQ 클러스터링
• 대규모 환경에서 미들웨어 설정하기
• 미들웨어 보안
• MCollective 보안
4. MCollective 는 무엇인가 ?
• 병렬 job 실행에 대한 프레임워크를 제공함 . 최대한 실
시간으로 서버 클러스터를 변경하는데 필요한 조정 작업
(command & control) 을 하는데 사용을 한다 .
• Puppet/Chef/Salt 등과 같은 설정 관리 프로그램은 설정
의 일관성을 관리하는데 사용을 하지만 Mcollective 는
보다 빠르게 전체 시스템에 걸쳐 특정 작업 또는 자주 하
는 1 회성 작업을 조정하는데 사용
• publish/subscribe 미들웨어를 사용 (ActiveMQ,
RabbitMQ, etc)
5. MCollective 는 무엇인가 ?
• 마스터 서버가 없는 환경을 제공해서 수천 대 이상의 시스
템에서 병렬 작업을 실행할 수 있음
• 커스터마이징할 수 있는 authentication( 인증 ),
authorization ( 인가 ) 메카니즘을 제공함
• 서로 다른 플랫폼 , 아키텍쳐 , 로컬 환경을 투명하게 처
리할 수 있음
• Returns full data sets as result codes, allowing intelligent
response ( 리턴 코드로 전체 데이터 셋을 제공하여 지능
적인 응답을 할 수 있음 .)
• Directs results to a processor that takes action on
responses
• Puppet, Chef 같은 설정 관리 프로그램과 통합을 할 수
있음 .
6. MCollective - 작동방식
• 일관성 있고 반복할 수 있는 있는 결과를 보장하는 진정한 병렬 실행
을 위해 만들어 졌음 .
• 명령과 제어를 위해 중앙의 마스터를 사용하지 않기 때문에 중앙 마
스터 서버의 리소스 문제를 피하고 있음 . 또한 클라이언트에 순차적
으로 접근하는 방식이 아니기 때문에 시스템 간의 drift 를 피할 수 있
다 . ( 순차적으로 명령을 실행하는 경우 각 시스템간에 실행 시간에
차이가 생김 . )
• 클러이언트와 서버간의 요청을 전달하기 위해서 publish/subscribe
미들웨어를 사용 . Controlled 노드는 mcollectived 라는 서버 애플리
케이션을 실행 . 이 서버는 message topics 에 sbuscribe 되어 있다
.
• 클라이언트는 message topics 에 요청을 하는 애플리케이션임 .
publish/subscribe 작업은 미들웨어 브로커에 대한 persistent
connections 를 통해서 처리가 된다 .
7. MCollective - 작동방식
• mcollectived 서버는 미들웨어 브로커에 등록이 되고 listening 이나
IDLE 상태로 남아 있다 . 클라이언트에서 미들웨어에 요청을 보낼
때마다 각 서버는 바로 그리고 독립적으로 요청을 받고 처리를 한다 .
• mcollectived 는 요청에 대해서 확인을 하고 해당 요청을 처리할
agent 에 요청을 전달한다 . 해당 agent 는 요청을 처리하고 응답을
보낸다 . Puppet Master 나 Chef 서버처럼 중앙의 리소스에서 정보
를 가져오거나 보내지 않으며 사용하는 모든 리소스는 노드의 로컬
자원이다 .
• 이러한 모델에서는 정확히 같은 시간에 몇십대 , 몇백대 , 몇천 대 이
상의 노드에서 명령 실행이 가능하다 . publish/subscribe 인프라스트
럭쳐를 통해 확장가능하고 빠른 병렬 실행 환경을 만들 수 있다 .
• 특정 노드에만 명령을 실행할 경우에는 어떻게 하는가 ? Mcollective
는 어떤 노드에서 명령을 실행할지를 지정할 수 있는 방법을 제공한
다 . hostname, OS, 설치한 패키지 , 실행하고 있는 프로세스 등으로
필터를 설정할 수 있다 . 자신의 환경에 맞게 직접 agent 를 만들 수
도 있다 .
18. MCollective 설치 - 요구사항
• OS
– 시간 동기화 작동해야 함
– Ruby 1.8.7, 1.9.3, 2.0
– Ruby STOMP gem 1.2.10, 1.3.2, or higher
– 5MB 디스크 공간
– 256MB 메모리
• 미들웨어 브로커
– 최소 500MB 메모리
– STOMP connector 를 지원하는 ActiveMQ 5.8 또는 이상 버전
– STOMP connector 를 지원하는 RabbitMQ 3.2 또는 이상 버전
– 디스크 공간은 미들웨어에 따라 다르며 ActiveMQ 는 45MB,
RabbitMQ 는 10MB
– PuppetLab 에서는 ActiveMQ 추천
19. MCollective 설치
• Puppet Lab 에서 APT, YUM rep 를 제공함 . Puppet Lab repo 를 통
하여 Mcollective, Puppet, Facter, ActiveMQ 등과 RHEL 5.X 에서
Ruby 1.8.7 과 같은 의존성 있는 패키지를 설치할 수 있다 . RHEL6,
RHEL5, Fedora, Debian 과 Ubuntu 등을 제공한다 .
• ActiveMQ 설치
• MCollective Server 설치
• MCollective Client 설치
• MCollective Agents and Client Plugins 설치
• 설치한 것 테스팅 (mco ping)
• 이 문서에서는 자세한 설치 내용은 생략을 함 .
• MCollective 를 배포하고 유지보수 하기위해서는 Puppet, Chef 등의
설정 관리 툴을 이용하는 것이 좋음
20. 미들웨어 설정 - ActiveMQ
• 예제 : https://github.com/jorhett/learning-
mcollective/blob/master/examples/activemq_59.xml
• Broker Definition : broker element 는 모든 서버와 클라이
언트가 통신을 할 ActiveMQ 자바 애플리케이션을 정의
• Topic and Queue Tuning
– Flow control off
– garbage collection ( 활동하지 않는 큐 정리 )
– vmCursor, vmQueueCursor ( 토픽 , 큐를 메모리에 유지 )
21. 미들웨어 설정 - ActiveMQ
• Authentication and Authorization
– 미들웨어 인증에서 가장 중요한 부분은 nodes queue 와 agent
topic
– node queue 에 대한 메시지는 하나의 노드에만 전달이 됨
– agent topic 에 publish 한 메시지는 해당 agent 가 설치된 모든
mcollective 대몬에서 받고 처리가 됨 .
– Users and groups : users 와 할당할 그룹 정의 . 각 토픽이나 큐
에 누가 요청을 보낼 수 있는지 제어
– brokers 그룹은 모든 queue, topic 에 쓰기 권한
– Topics and queues the clients send to : mcollective topic, queue
– Topics and queues the servers read from : mcollective agent
topic, mcollective node queue
– Topics and queues the servers write to : mcollective registration
agent topic, mcollective reply queue
22. 미들웨어 설정 - ActiveMQ
• Authentication and Authorization
Publish to a topic, receive responses on a unique queue
23. 미들웨어 설정 - ActiveMQ
• Transport Connectors
– 서버와 클라이언트가 IP 네트워크를 통해서 미들웨어 브로커
와 연결하는 방법을 정의
– 모든 MCollective 메시지는 Streaming Text Oriented
Messaging Pro tocol (STOMP)‐ 패킷으로 포맷이 된다 .
– 사용하지 않는 transport connector 는 비활성해야 함 .
• Management Interfaces
– 일반적으로는 콘솔에 꼭 필요한 것은 아니나 디버깅시 유용
– ActiveMQ 자체적으 로 web console 제공
– Jolokia API and HawtIO
– JMX MBean Console
24. ActiveMQ 클러스터
• sites 간에 메시지를 전달하기 위해
network of brokers 구성
• 사이트에 redundancy 를 제공하기 위해
master/slave 동기화 구성
• 사이트 간의 트래픽 암호화
• 모든 옵션을 쓰거나 조합해서 사용할 수 있
다
25. 대규모 환경에서 브로커 설정
• 가능한한 많은 메모리를 Java engine 에 사용하고 borker 의 크기도 이에
맞춤 . 브로커는 오직 필요한 메모리만 사용을 할 것임
• oepn files 의 숫자를 늘리고 네트워크 연결을 위한 read, write 버퍼를 늘린
다 . sysctls 이용 .
• 대규모 클러스터나 지역적으로 분산된 사이트에서는 트래픽을 분리하기 위
해 여러개의 collectives 를 사용함 .
• 수백대 이상의 서버에서 TLS 인증을 사용하려면 SSL-enabled NIO
connector 를 사용하기 위해 ActiveMQ 5.9.1 로 업그레이드를 한다 .
• 서버와 클라이언트간에 메시지가 전달될 브로커 숫자를 제한하기 위해서는
start 또는 modified start 설정을 사용한다 .
• 설정상의 잘못은 서버나 클라이언트를 작동하지 않게 하기도 하고 연결을 시
도하려고 한다 . 미들웨어 호스트에서 IP 주소당 열린 커넥션 숫자를 확인하
고 잘못 설정된 노드를 찾아내야 한다 .
• 모든 서버가 클라이언트에 응답을 전달하기 위해 필요한 discovery, request
timeouts 를 늘여야 한다 .
26. 미들웨어 보안
• 미들웨어 보안은 오직 노드가 브로커에 연결할 수 있는지 , 통신에 암호화를
할 것인지를 제어
• Anonymous TLS 암호화 : 암호화된 키를 만들기 위해 오직 서버 인증서만
사용 . 이것은 웹사이트에서 사용하는 방식이며 구현이 간단
• CA-Verified TLS 암호화 : 쌍방향 authentication 을 제공하는 것으로 동일
한 CA 로 사인을 한 각자의 인증서에 따라서 서로를 확인 . 이경우 모든 서
버와 클라이언트를 위해 단일한 키와 인증서로 사인을 하는 것이 필요하다 .
27. MCollective 보안
• 보안플러그인
– Security(authentication) plugin : 현재의 설정은 컨텐츠에 대한
MD5 hash 를 만드는 Pre-Shared Key 를 사용한다 . 이것을
이용하여 서버는 plain-text 요청이 변경되지 않았다는 것을
확인한다 . 이보다 더 강한 암호화 확인을 원할 수 있다 .
– Authorization plugin : 당시은 어떤 요청을 할 수 있거나 없을
수 있다 . 특정 클라이언트가 특정 호스트 또는 특정 요청을 할
수 있는지 제한하는 보안 모델을 원할 수 있다 .
– Auditing plugin : 기본 로그 파일은 누가 특정 요청을 했는지에
대해 자세한 정보를 보여주지 않는다 . 허용이나 거부된 요청
과 누가 그 요청을 했는지 등 더 자세한 로그를 원할 수 있다 .
29. MCollective 보안
• Authorization plugin
– 특정 사용자 , 특정 호스트 , 특정 agent 등을 제한할 수 있음
.
– 한 명 이상의 관리자가 있는 환경에서 배포를 할 때 , 모든 서
버를 위해 ActionPolicy authorization 플러그인을 배포할 것을
권장 . ActionPolicy 는 각 agent 별로 정책 룰을 사용할 수 있
다 .
– 예 ) 기본 정책은 모두 거부 . puppet agent 만 허용 .
• Auditing plugin
– 기본 audit 플러그인은 각 서버에서 받는 모든 요청 사항 , 해
당 요청을 허용했는지 거부했는지 등을 디스크의 로그파일에
기록
– audit 로그는 authentication 이나 authorization 실패에 대한
정보는 담고 있지 않다 . 이러한 정보는 main logfile 인
mcollective.log 에서 DEBUG 로그레벨로 정보를 수집할 수
있다 .