Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

mcollective 와 상호작용하는 일반적인 방법은 mco cli 클라이언트이며 직접 CLI에서 사용을 하거나 스크립트에서 이용할 수 있다.

설정파일

MCollective client 에 대한 글로벌 설정 파일은 /etc/mcollective/client.cfg 이다. 유저별로 자신의 설정 파일을 가질 수 있으며 user 홈 디렉토리의 .mcollective 파일을 이용한다. command line 에서 -c config file 을 지정할 수도 있다. 각 설정 파일은 사용에 필요한 전체 설정을 완전히 담고 있어야 한다. 설정 파일을 지정하면 글로벌 설정 파일은 사용하지 않는다.

간단한 테스팅을 할 때는 사용자별 설정파일이 필요 없지만 인증을 위해서 SSL key 를 쓸 때는 각 사용자별로 설정을 해야 한다.

Connector

클라이언트에서 서버에 요청을 하기 위해서 클라이언트는 두가지 플러그인을 사용한다.

  • connector plugin : 미들웨어에 연결을 하고 topics 에 publish 하기 위해 필요
  • security plugin : to sign (and optionally encrypt) the data payload. clients 와 servers 간에 보안을 위해서 사용을 함.

이 두가지 connectors 는 전체 환경을 통해서 동일해야 한다.

위 예제에서는 connector = activemq 를 사용했으며 RabbitMQ 를 사용하거나 middleware connector 를 만들어서 사용할 수 있다.

securityprovider = psk 를 사용했으며 자세한 내용은 Middleware security, Mcollective security 에서 설명한다.

Facts

시스템의 여러가지 정보를 확인하는 방법중의 하나가 facts 이며 서버의 정보를 key/value 쌍으로 제공한다. Puppet Labs 에서 제공하는 facter 프로그램을 통해서 facts 를 가져올 수 있다.

먼저 /etc/mcollective/server.cfg 를 편집해서 mcollective 에서 facts 정보를 이용할 수 있도록 설정한다.

이제 cron 을 통해서 주기적으로 facts 정보를 업데이트 하도록 설정을 한다.

테스팅을 위해서 cron 대신 수작업으로 /etc/mcollective/facts.yaml 파일에 YAML 형식으로 정보를 넣어줄 수도 있다.

facts.yaml 파일을 생성한 후 MCOLLECTIVED 를 재시작 해 주어야 한다.

이렇게 한 후 inventory 요청을 보내고 읽을 수 있다.

awk 를 써서 필요한 정보만 볼 수도 있다.

얼마나 많은 노드가 동일한 facts 값을 공유하는지 질의를 할 수 있다.

Inventory

Mcollective clint 에서 제공하는 기본 명령중 하나는 inventory 이다. 이 명령을 통해서 특정 서버의 설정, collectives, 통계 등을 확인할 수 있다.

가장 중요한 부분 중의 하나는 해당 호스트에 설치된 agents 와 plugins 이다.

위의 facer 설명에서 mco inventory 명령을 참고하면 된다.

Inventory Reports

inventory 서비스에서 레포트를 만들 수도 있다. Ruby 스크립트를 짜서 몇가지 값을 출력하도록 하고 inventory 명령의 스크립트 인자로 넘겨서 실행을 해보자.

각 호스트의 hostname, architecture, operating system, OS Release Ver 를 출력하는 예제이다.

Discovery

Mcollective client 에서 실행하는 가장 기본적인 작업 중의 하나는 collective 에서 어떤 서버가 사용 가능한지 찾는 작업이다.

어떻게 client 에서 어떤 서버가 필터에 맞는지 결정을 할까? 답은 서버에 묻기 위해서 client.cfg 에 설정한 mc discovery plugin 을 사용한다는 것이다.

mc discovery plugin 은 지정한 필터에 맞는 모든 서버에 브로드캐스트 쿼리를 보낸다. 10대 이상의 서버가 응답을 하면, 요청을 브로드캐스트로 보낸다. 10 대 이하의 서버가 응답을 하면 각 서버로 직접 메시지를 보낸다.

client 설정에서 direct_addressing_threshold 옵션을 조정하여 언제 broadcast 와 direct addressing queries 를 할지 변경할 수 있다. (Figure 3-1 참고)

Figure 3-1. Direct addressing

 

mc 에서 사용하는 broadcast discovery 을 사용하지 않는 한가지 방법은 다른 discovery plugin 을 사용하는 것이다. 기본으로 제공하는 다른 discovery 플러그인은 flatfile 과 stdin discovery 플러그인이다. 이 플러그인들은 파일이나 표준 입력을 통해 호스트네임 목록을 사용한다.

다음과 같이 사용을 할 수 있다.

  • Use the ---nodes filename.
  • Use --disc-method flatfile --discovery-option filename
  • Use -disc-method stdin and send a list of identities on standard input

이렇게 사용을 하는 경우 broadcast 질의를 사용하지 않고 요청은 직접 각 노드별 특정의 큐로 간다.

Responses to the request are compared against the list of server ideintified in discovery, so as to know if any nodes failed to respond. (정확한 의미가 이해 안 감)

mco rpc 는 client applcation 을 사용하지 않고 agent 에 요청을 보내는 방법이다. Part III 에서 배울 것이다.

ping 과 함께 flatfile discovery 를 사용할 수 있는 유일한 방법은 RPC invocation 을 사용하는 것이다.

MCollective 에서 사용 가능한 여러 가지 discovery plugins 가 있으며 PuppetDB, Chef, MOngoDB, RiakDB, 그리고 Elastic Search 등이 있다. Part III에서 어떻게 직접 discovery plugin 을 만들 수 있는지 설명할 것이다.

명령을 제한하기 위해서 자신만의 커스터마이징된 discovery plugins을 만드는 것이 좋은 방법이라고 생각을 할 것이다. 그렇지만 실제로는 그렇지 않다. MCollective 는 일관된 discoveory view 에 의존한다. 명령을 적용할 특정 서버를 제한하기 위해서는 필터링을 살펴보자.

Filters

일 반적으로 각 MCollective 명령에서 사용할 대상 서버 목록을 만드는 것은 불필요한 작업이다. 기본 broadcast discovery method 와 필터를 쓰면 더 쉽다. discoveory plugin 에서 사용하는 필터는 어떤 서버에 요청을 보낼지를 제한한다. 필터는 어떤 MCollective 명령에도 적용할 수 있다. mco 에서 제공하는 아무 명령어에 help 를 이용하면 필터 사용법이 나온다.

각 필터 옵션별로 길고 짧게 쓸 수 있는데 길게 쓰는 경우가 더 이해하고 기억하기 쉽다.

flatfile discovery plugin 은 오직 identity 필터만 지원을 한다.그래서 사용 가능한 강력한 필터가 있기 때문에 mc discovery plugin 을 추천하고 사용하는 것이다.

Combination Filters

combination 필터에는 두가지 타입이 있다. 하나는 Puppet classes 와 facter facts 이다.

두 번째 타입은 select 필터로 더 강력한 필터 기능을 가지고 있다. select 필터는 Puppet classes, facts 와 복잡한 boolean logic 을 함께 이용하여 검색할 수 있다. and 와 or 를 사용할 수 있는 유일한 필터이다. 또한 부정을 의미하난 not 또는 ! 을 사용할 수 있다.

마지막 예제는 httpd 또는 nginx Puppet class 이고 is_virtual fact 를 가진 서버만 보여 주고 있다. 이러한 겅색은 오직 select 필터 타입에서만 가능하다.

Not All Filters Are Available with Every discovery Plugin

 flatfile 이나 stdin discovery method 를 사용하면 오직 identity 필터만 사용할 수 있다. 각  discovery method 에서 어떻게 필터를 이용 가능한지는 문서를 참고해야 한다.

명령어 라인에서 다른 plugin 을 지정해도 select 필터를 사용하면 mc discovery plugin 을 사용한다.

Limits

필터와 상관 없이 얼마나 많은 서버가 동시에 요청을 받을지 또는 동시에 얼마나 많이 처리를 할지 지정할 수 있다.

얼마나 많은 서버가 요청을 받을지는 –one, --limit, % 옵션이 있다.

--one 은 랜덤하게 한대의 서버를 지정할 수 있고 --limit 는 고정된 서버 숫자를 지정할 수 있으며 해당 서버를 %로 지정할 수도 있다.

임의의 15대 서버

오직 하나의 CentOS서버

Puppet class로 webserver 를 사용하는 5대의 서버

Puppet class로 webserver 를 사용하는 33%의 가상 서버

기 본적으로는 필터에 해당하는 모든 서버에서 동시에 요청을 보낸다. 그렇지만 이것을 제한하려고 하는 경우가 있을 수 있다. 예를 들어 동시에 로드밸런서 서버들을 업데이트 하고 싶지는 않을 것이다. 이럴 때는 배치 작업에서 얼마나 많은 서버가 요청을 받을지, 각 배치 작업 별로 시간 간격을 둘지 설정할 수 있다.

각 배치 작업별로 10대의 서버에 대해서 sudo package 버전을 체크하며 각 배치 작업 사이에는 20 초를 둔다.

모든 German 서버의 puppet 버전을 체크하는데 5대씩 30초의 시간 간격을 두고 체크한다.

name 에 w 를 가진 모든 서버에 대해서 ping 을 체크하며 지연시간이나 배치 작업 없이 체크를 한다.

Ping 은 매우 로우레벨의 요청이기 때문에 --batch 나 --limit 옵션을 사용하지 않는다.

Output

응답을 받을 때의 결과도 변경을 할 수 있다.

텍스트 대신에 구조화된 정보를 제공한다.

진행상황을 출력하지 않는다.

discovery 에 얼마나 시간이 걸리는지, 전체 RPC 통계를 출력한다.

명령을 보내지만 전체 응답큐를 생략한다. (결과를 출력하지 않는다)

유용한 옵션 중 하나는 오직 실패한 노드나 성공한 응답만 출력을 하는 경우이다.

요청을 받을 모든 서버에 대한 응답을 보기

이 책을 쓴 저자가 책을 쓸 당시에는 몇가지 애플리케이션에서만 display 옵션이 작동을 했다고 한다. 아직든 지원하지 않는 프로그램이 있는 것 같다.

Classes

Puppet Class, Chef 에 대해서는 설명 생략.

Puppet agent 에서는 일반적으로 /var/lib/puppet/state/classes.txt 파일에 적용하는 클래스를 기록한다. MCollective 는 기본값을 알고 있는데 만약 이 부분을 바꾸었다면 MCollective 의 server.cfg 설정에서 이 부분을 바꾸어 주어야 한다.

Bash Completion

MCollective 에서는 command-line completion 기능을 제공해서 mco 명령에서 Tab 을 이용하여 명령어를 선택할 수 있다. 그런데 직접 테스팅을 했는데 작동이 안 되었다. 이유는 살펴보지 않았다.

 

 

Labels
  • No labels