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

MCollective 를 어떻게 만들지 추천 사항임.

Configuratoin Management 를 사용

Configuratoin Management 를 사용할 것을 추천. 대규모 서버를 관리할 때 설정 관리 프로그램 없이 사용을 하려면 힘듬. 자세한 설명은 생략.

각 자의 상황에 따라 Puppet, Chef 등을 사용하자. 문제가 생긴 MCollectiev 서버를 설정 관리 프로그램으로 고칠 수 있고 문제가 생긴 설정 관리 agent 를 MCollective 로 고칠 수 있다. 이 두가지 툴을 함께 사용하면 좋다.

최적의 Discovery 방법을 선택

Mcollective 가 요구사항에 맞지 않다고 가장 많이 불평을 한 것들은 discovery 에 브로드캐스트를 사용한 것이다. 오래된 MCollective 버전은 오직 mc 브로드캐스트 방법만 지원을 했었다. 서버가 오프라인이면 요청이 새로 생겼어도 discovery 에 응답을 할 수 없고 요청을 처리할 수도 없다.

MCollective 는 다양한 데이터를 수용하기 위한 discovery 플러그인을 개선하기 위해 노력을 하였다. 일반 파일, PuppetDB, Chef, Foreman, MongoDB, RiakDB, 그리고 Elasticsearch 등에서 서버 목록을 필터링할 수 있는 여러 플러그인들이 있다.

discovery 플러그인과 관련해서는 당신의 요청에 맞는 적절한 discovery 플러그인을 사용해야 한다.

collective 에서 모든 노드에 대해 동일한 connector와 동일한 security 플러그인을 사용할 수 있다. 그렇지만 각 요청마다 다른 discovery 플러그인을 사용할 수 있다. 요청에 맞는 적절한 discovery 플러그인을 선택하자.

간단한 예로, 대부분의 경우 온라인이고 현재 동작중인 노드에만 요청을 하고 싶을 것이다. 샌프란시스코 클러스터의 모든 노드만 apache를 재시작하고 싶다면, 노드가 현재 오프라인인 것은 신경을 쓸 필요 없다. 이때 요청을 처리하기 위해 나는 mc (기본값임) discovery 플러그인을 사용할 것이다:

그 러나, 클러스터에 있는 모든 노드의 apache를 내리기 원할 경우  오프라인에 있던 어떤 노드가 온라인으로 바뀌자 마다 메시지를 받도록 하고 싶을 것이다. 이럴 경우 다음과 같은 명령으로 사용을 했다. 모든 알려진 서버에 명령을 보내고 정말로 긴 timeout 을 사용한다:

필요하다면, 응답하지 않는 노드에 대한 정보를 담은 새로운 목록을 만들어서 명령을 다시 실행하도록 래퍼를 만들 수 있다.

github 에서 discovery 플러그인을 찾을 수 있다.  https://github.com/search?q=mcollective+discovery&ref=cmdform

Authorize and Audit Each Request

MCollective 배포시 보안에 대한 부분은 security(authentication), authorization, 그리고 auditing 플러그인에 의지한다. 이들 각각은 필요한 기능을 제공한다:

  • 리소스를 막을 수 이는 적절한 미들웨어 보안 모델 선택. 신뢰하지 않는 네트워크에서 정보를 전송한다면 언제나 암호화를 사용해야 한다. Puppet 을 사용한다면 간단한 설정 변경으로 TLS 암호화를 활성화할 수 있다.
  • security (authentication) 플러그인은 authorization 과 auditing 플러그인에서 검증할 수 있는 caller 정보를 제공한다. authentication 을 빈약하게 하면 보안 문제가 생길 수 있다. A poor choice of authentication mechanisms will reinforce the well-known garbage in, garbage out phenomenon.
  • SSL, AES, SSHKey security 플러그인을 이용한 접근 제어를 사용하자. 이러한 플러그인들은 caller 의 신분을 검증하기 위해 암호화된 공개키를 사용한다.
  • 강 한 authentication을 멈추지 말자. 각 요청에 대해 authentication(권한 제어)를 하지 않으면서 강한 authentication을 쓰는 것은 의미가 없는 일이다. 어떤 사람의 신분증을 확인하고 그 사람이 올수 있는 곳에 당신의 지갑을 두는 것과 비슷하다.
  • authorization 에서 아무것도 넣지 않는 것보다는 명확한 "allow any" 정책이 더 좋다. 이렇게 해야 새로운 authorization 룰을 추가할 때도 룰을 조정하기가 쉽다.
  • 언제나 MCollective 요청을 audit 해야 한다. audit 데이터는 인증로그나 sudo log를 보호하는 것과 같이 백업을 해야 한다.
  • 보안은 플러그인을 통해서 제공을 하기 때문에 각 조직이나 host 의 각 collective는 요구사항에 맞는 서로 다른 보안 모델을 사용할 수 있다.

MCollective의 보안을 위한 플러그인 구조는 실제 구현을 할 때 유연성을 준다. MCollective의 보안을 강화하는 정답은 없다. 대신에 당신의 필요에 맞게 동작을 하도록 해야 한다.

 

Labels
  • No labels