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

collective 는 요청 트래핑을 그룹으로 묶을 때 사용하는 ActiveMQ topic 과 queue 세트이다. 규모가 작을 때는 단일 collective 를 사용하면 된다. 이 책에 사용했던 것은 기본값인 mcollective 였다.

다음의 이유로 여러 개의 collective 를 만들기 원할 수 있다.

  • 대규모 클러스터 또는 sites 간에 트래픽을 제한하는데 Collectives 사용
  • client 접근을 제약하기 위해 노드를 그룹으로 묶는데 Collectives 사용

언제 여러 개의 collective 생성할지 결정하기

현재의 네트워크에서 여러 개의 collectives를 구현하기 원하는 경우:

  • 천대 이상의 서버를 가지고 있음
  • 지연시간이 긴 여러 지역에서 서버를 운영
  • 여러 지역에서 서버를 운영하고 있고 그 사이에 네트워크 트래픽을 줄이고 싶을 때
  • 로컬 관리자는 로컬 호스트를 관리하도록 허용을 하되 글로벌 팀은 모든 호스트를 관리할 수 있도록 허용할 때

여러 개의 collectives 를 구성할 필요가 없는 경우:

  • 미 들웨어 셋업에서 fault tolerance를 원하는 경우 : Collectives 는 fault tolerance를 제공하지 않는다. fault tolerance 는 network of brokers 나 master/slave 셋업을 해야 하며 p113 "ActiveMQ Clusters"에서 설명을 했다. Collectives 는 각 사이트의 로컬에 있는 브로커에 트래픽을 제한하는 경우 효율적인 방법이다.
  • authorization 제어에 여러가지 다양한 것을 필요로 하는 경우 : 클라이언트가 서버에 접근하는 것을 제한하기 위해 특정 collectives를 제약할 수 있지만 이것이 일반적인 authorization 메커니즘은 아니다. p163 의 "Authorization"을 이용할 것을 권장한다.
  • 서로 다른 Puppet domains 을 가지고 있는 경우 : Puppet 과 MCollective 는 둘이 함께 작동을 할 수 있지만 Puppet domain 이 같을 필요는 없다. 많은 Puppet domans 에 단일한 MCollective를 쓸 수 있다.

지금의 목록에서 답변을 찾을 수 없는 경우 collective를 어떻게 만드는지 살펴보자.

Collectives != Clustering

먼저 이해해야 할 것은 collectives 는 ActiveMQ 클러스터와는 다르다는 것이다.

collective 는 네트워크 트래픽을 분리하기 위해 사용하는 ActiveMQ topics 와 queues 의 세트이다. ActiveMQ 클러스터는 토픽과 큐 세트에 fault tolerance 를 제공한다. 단일 ActiveMQ 브로커에 수백개의 collectives 를 운영하는 것은 가능하며 이를 통해서 zero fault tolerance를 제공할 수 있다. 마찬가지로 단일 collective 에 더 강력한 fault tolerance 와 고성능을 위해서 여러 개의 ActiveMQ 브로커를 사용하는 것도 가능하다.

대부분의 환경에서는 다음과 같은 구성을 한다.

  • A master/slave pair of brokers : 모든 collectives 에 단일 site redundancy 제공  A master/slave pair of brokers that support all collectives for single-site redundancy

  • 각 지역에 하나의 ActiveMQ brokers 를 가진 network of brokers 를 구성하며 모든 collectives를 이 site에서 처리함. A network of brokers with one ActiveMQ broker in each location which hosts all collectives at that site
  • 각 지역에 여러개의 ActiveMQ 브로커를 가진 network of brokers 를 구성 A network of brokers with multiple ActiveMQ brokers in each location
  • 이 세가지 옵션을 조합.

p113 의 "ActiveMQ Clusters"에서 클러스터 설정에 대한 예제를 보여주었다. 이러한 것들이 다른 점을 깨닫는 것이 중요하다. The collective is a message path configured on top of network of brokers.

If you are familiar with the OSI model for networking, it is not entirely accurate but easiest to think of clustering as Layer 4 and collectives as Layer 6. This reflects how the collective is an application-specific path that relies on the transport layer.

정확한 것은 아니지만 클러스터링으로 Layer 4, collectives를 Layer 6으로 생각하면 쉽다. collective는 transport layer 에 의존하는 application-specific 경로이다.

Traffic 설정

다음은 client 에서 collectives 를 정의하는 설정이다.

각 서버에서는 오직 연관된 로컬 collectives를 설정해야 한다.

collectives 구성에 대한 정보를 조회할 수 있다. collective 구조를 DOT 파일로 보내서 Graphviz, ZGRViewer, 등의 프로그램에서 읽을 수 있다.

특정 서버가 어느 collectives 에 속해 있는지 조회를 할 수도 있다.

요청을 보낼 때 target 를 지정하여 요청을 소규모 collective 로 제한할 수도 있다. target 을 저정하지 않으면 , 요청은 client.cfg 파일에 정의된 main_collective 파라미터에 있는 collective 로 보내진다.

오직 asia collective 에 있는 노드만이 응답을 할 것이다.

Localizing Traffic

미 들웨어에서는 리스닝하고 있는 것을 아는 노드에만 트래픽을 보낸다. 이 부분은 topc subsciption 메커니즘이 작동하고 있기 때문이다. 오직 다섯 대의 시스템에서 Puppet plugin 을 로드했으면 (또한 collective.puppet.agent topic 에 가입되어 있음) 오직 다섯 대의 시스템에서만 Puppet client plugin 의 요청을 받을 것이다. 이와같이 해당 collective 의 모든 시스템이 특정 브로커에 연결되면 미들웨어 브로커는 해당 topic 이나 queue 에 가입하지 않은 브로커에게는 collective의 메시지를 복사하지 않을 것이다. 이렇게 해서 sites 간에 트래픽 양을 매우 많이 줄일 수 있다.

이러한 이점을 위해서, collectives 를 다음과 같이 설계하자:

  • registration 과 다른 글로벌 메시지에 가입한 모든 호스트를 위한 하나의 collective 사용 (예 mcollective)
  • 각 물리적인 지역이나 인프라스트럭쳐 영역에 대해 하나의 collective 추가. 그 이름은 간단하게 국가, 도시 또는 공항 코드 등으로 하기 원할 것이다.

새로운 collective 이름을 위한 동일한 클라이언트와 서버 로그인을 허용할 수 있도록 미들웨어를 설정하자.

해당 영역에 대해 서버를 설정한다.

그러고나서 클라이언트가 모든 로컬 사이트를 가지도록 설정한다.

이렇게 설정을 하면 관리자는 오직 특정 sites 에만 명령을 보내거나 요청의 타겟에 따라 모든 호스트에 명령을 보낼 수 있다.

접근 제약하기

여러 개의 collectives 를 쓰는 또다른 이유는 각 사이트에 대해서 로컬 관리 팀에만 접근을 허용을 하는 경우이다. 이러한 장점을 위해 다음과 같이 collectives 를 설계한다:

  • registration 과 다른 글로벌 메시지에 가입한 모든 호스트를 위한 하나의 collective 사용 (예 mcollective)
  • 구분되는 클라이언트 세트를 통해 관리를 할 각 서버를 위한 하나의 collective 추가
  • 모든 collective 는 접근을 위해 유일한 그룹 이름을 가지도록 함.

불 행히도 이렇게 설정을 변경하려면 서로 다른 그룹 숫자에 따라 설정이 늘어날 것이다. 각 그룹의 관리자는 유일한 클라이언트 로그인과 유일한 그룹명이 필요하다. 다음의 예에서는 admnistrators 와 delvelopers 를 사용하는 두 그룹 시스템을 보여줄 것이다. delvelopers 는 오직 자신의 collective 에서만 작업을 할 수 있다. 글로벌 관리자는 모든 collective 에서 작업할 수 있는 클라이언트 로그인을 가지고 있다.

이렇게 하면 메인 클라이언트 로그인은 모든 collectives 에 글로벌하게 접근할 수 있지만 새롭게 만든 로그인은 자신만의 collectives 에만 메시지를 주고 받을 수 있다.

서버에서는 다음과 같이 제한된 collectives를 설정한다:

클라이언트에서는 로컬 collective 를 자신의 main (기본) collective로 가진다.

이렇게 설정을 한 경우 dev 관리자는 dev 시스템에만 요청을 할 수가 있지만 글로벌 관리자 (username 과 password에 client 계정을 가진 관리자)은 모든 호스트에 접근할 수 있다.

결론

여 러 개의 collectives 를 가지면 서로 다른 레벨에서 확장성을 처리하는데 도움이 된다. 대부분의 상황에서는 확장성에 문제가 있거나 각 그룹(고객, 개발팀 등)에게 제한된 접근을 허용하는 경우가 아니라면 기본 collective로 충분하다.

이번 장에서 설명한 기능을 이해하는 것은 좋지만 필요성이 있을 때까지는 여러 개의 collectives 를 쓰는 것을 권장하지 않는다.

Labels
  • No labels