Puppet을 사용한 다중 사이트 고 가용성 옵션

저는 두 개의 데이터 센터를 유지 관리하고 있으며 중요한 인프라 중 더 많은 부분이 꼭두각시를 통해 제어되기 시작하면서 기본 사이트가 실패 할 경우 두 번째 사이트에서 꼭두각시 마스터 작업이 중요합니다.

두 번째 사이트의 서버가 WAN을 통해 폴링하지 않도록 일종의 활성 / 활성 설정을하는 것이 더 좋습니다.

다중 사이트 꼭두각시 고 가용성의 표준 방법이 있습니까?

꼭두각시 (Puppet)는 실제로 멀티 마스터 환경에주의를 기울이고 있습니다. 메인? 꼭두각시의 많은 부분이 중앙 집중화되는 것을 좋아합니다. 인증 기관, 인벤토리 및 대시 보드 / 보고서 서비스, 파일 버킷 팅 및 저장된 구성-모두 대화 할 수있는 장소가 하나 뿐인 설정에서 최상의 상태를 유지합니다.

그러나 기본 사이트를 잃어 버렸을 때 일부 기능이 정상적으로 손실되면 다중 마스터 환경에서 작동하는 많은 부품을 얻는 것이 매우 효과적입니다.

기본 기능부터 시작하여 마스터에 노드보고를 가져 오십시오.

모듈과 매니페스트

이 부분은 간단합니다. 버전 관리가 가능합니다. 분산 버전 제어 시스템 인 경우 중앙 집중식으로 동기화하고 장애 조치 사이트에서 필요에 따라 푸시 / 풀 플로우를 변경하십시오. Subversion 인 경우 svnsync장애 조치 사이트 에 대한 저장소를 원할 수 있습니다.

인증 기관

여기서 한 가지 옵션은 마스터간에 인증 기관 파일을 간단히 동기화하여 모두 동일한 루트 인증서를 공유하고 인증서에 서명 할 수 있도록하는 것입니다. 이것은 항상 "잘못하고있다"고 생각했다.

• 한 마스터가 다른 마스터로부터 들어오는 연결에 대해 클라이언트 인증에 자신의 인증서가 실제로 유효한 것으로보아야합니까?
• 인벤토리 서비스, 대시 보드 등에서 안정적으로 작동합니까?
• 도로에 유효한 DNS 대체 이름을 어떻게 추가합니까?

솔직히이 옵션에 대한 철저한 테스트를 수행했다고 말할 수는 없습니다. 그러나 Puppet Labs는 여기 참고 사항에 따라이 옵션을 권장하지 않는 것 같습니다 .

따라서 중요한 것은 중앙 CA 마스터를 보유하는 것입니다. 모든 클라이언트와 다른 마스터가 CA 인증서와 CRL을 캐시하기 때문에 모든 트러스트 관계는 계속 작동합니다 (CRL을 자주 새로 고치지는 않지만)하지만 새 인증서에 서명 할 수있을 때까지 기본 사이트를 백업하거나 장애 조치 사이트의 백업에서 CA 마스터를 복원합니다.

하나의 마스터를 선택하여 CA로 작동하고 다른 모든 마스터가이를 비활성화하게합니다.

[main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

그런 다음 해당 중앙 시스템이 모든 인증서 관련 트래픽을 가져 오기를 원할 것입니다. 이에 대한 몇 가지 옵션이 있습니다.

1. SRV3.0 의 새로운 레코드 지원을 사용하여 모든 에이전트 노드가 CA의 올바른 위치를 가리 키도록합니다._x-puppet-ca._tcp.example.com
2. 모든 에이전트 ca_server에서 구성 옵션 설정puppet.conf

3. 에이전트에서 올바른 마스터로 CA 관련 요청에 대한 모든 트래픽을 프록시하십시오. 예를 들어, 승객을 통해 Apache에서 모든 마스터를 실행중인 경우 비 CA에서이를 구성하십시오.

   SSLProxyEngine On
   # Proxy on to the CA.
   ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
   # Caveat: /certificate_revocation_list requires authentication by default,
   # which will be lost when proxying. You'll want to alter your CA's auth.conf
   # to allow those requests from any device; the CRL isn't sensitive.
   

그리고 그렇게해야합니다.

보조 서비스로 넘어 가기 전에 부가 정보;

마스터 인증서의 DNS 이름

나는 이것이 바로 3.0으로 전환해야 할 가장 강력한 이유라고 생각합니다. "모든 ol '작업 마스터"에서 노드를 가리키고 싶다고 가정하십시오.

2.7에서는와 같은 일반 DNS 이름 puppet.example.com이 필요하며 모든 마스터는 인증서에이 이름 이 필요합니다. 즉 dns_alt_names, 구성에서 설정하고, 마스터로 구성되기 전에 가지고 있던 인증서를 다시 발행하고, 목록에 새 DNS 이름을 추가해야 할 때 인증서를 다시 발행하는 것을 의미합니다 (여러 DNS 이름을 에이전트가 자신의 사이트에서 마스터를 선호하게합니다.)

3.0에서는 SRV레코드 를 사용할 수 있습니다 . 모든 고객에게 이것을 제공하십시오;

[main]
    use_srv_records = true
    srv_domain = example.com

그런 다음 마스터에게 특별한 인증서가 필요하지 않습니다. SRVRR에 새 레코드를 추가 _x-puppet._tcp.example.com하면 그룹의 라이브 마스터입니다. 또한 마스터 선택 로직을보다 정교하게 만들 수 있습니다. 사이트마다 다른 SRV레코드 세트를 설정하여 "모든 ol '작업 마스터이지만 사이트의 레코드 마스터를 선호합니다" ; dns_alt_names필요 하지 않습니다.

보고서 / 대시 보드

이 방법은 중앙 집중식으로 가장 잘 작동하지만 기본 사이트가 다운 되어도 문제없이 살 수 있다면 아무런 문제가 없습니다. 모든 마스터를 올바른 위치에 구성하여 보고서를 작성하십시오.

[master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

.. 그리고 모든 준비가 끝났습니다. 보고서 업로드 실패는 구성 실행에 치명적이지 않습니다. 대시 보드 서버가 토스트되면 손실됩니다.

팩트 인벤토리

대시 보드에 붙어있는 또 다른 좋은 점은 인벤토리 서비스입니다. 으로 facts_terminus로 설정 rest중앙 재고 서비스가 다운되었을 때 설명서에 권장하는대로,이 사실은 구성 실행을 깰 수 있습니다. 여기서 비결 inventory_service은 비 중앙 마스터 에서 종단 을 사용하여 정상적으로 실패하는 것입니다.

facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

중앙 인벤토리 서버가 ActiveRecord 또는 PuppetDB를 통해 인벤토리 데이터를 저장하도록 설정하고 서비스가 제공 될 때마다 최신 상태를 유지해야합니다.

따라서 CA를 사용하여 복원 할 때까지 새 노드의 인증서에 서명 할 수없는 예쁜 기본 구성 관리 환경에 만족한다면 괜찮을 것입니다. 이러한 구성 요소 중 일부 가 배포하기에 더 친숙한 경우 .

Ladadadada가 설명하는 "마스터리스 퍼펫"접근 방식은 내가 가장 잘 알고있는 방법입니다 (기본적으로 우리 회사의 래드 마인드에서하는 일입니다). 더 정확하게는 "외부 프로세스에 의해 동기화 된 다중 마스터"로, 주어진 서버가 (이론적으로) 비상시에 전체 우주에 서비스를 제공 할 수 있습니다.

때문에 radmind의 성격 우리의 경우 우리는 단순히 rsync각 원격 사이트의 radmind 서버에 승인 된 마스터의 성적 증명서 및 데이터 파일, 그리고 클라이언트는 짧은 호스트 이름을 사용하여 서버에서 자신의 업데이트를 가져 radmind의 마법을 통해 ( resolv.conf이 평가됩니다 radmind.[sitename].mycompany.com항상 로컬 - radmind 서버 : 로컬 서버가 다운되면 다른 사이트의 서버를 무시하고 가리킬 수 있습니다.

이러한 종류의 rsync 프로세스는 아마도 귀하의 상황에서도 작동하지만 버전 제어 기반 솔루션과 비교할 때 차선책 일 수 있습니다.

꼭두각시 또는 요리사의 경우 버전 제어 기반 시스템은 몇 가지 이유로 단순한 rsync보다 더 의미가 있습니다. 큰 것은 꼭두각시와 같이 전체 OS 이미지가 아닌 꼭두각시 스크립트를 버전 제어한다는 것입니다.
버전 관리 기반 관리의 추가 이점으로 여러 사람이 한 번에 저장소에서 작업 할 수 있으며 (병렬 처리에 큰 도움이 됨) 기본적으로 개정 내역을 무료로 얻을 수 있으며 누군가가 Puppet 환경을 중단하는 경우 롤백이 쉽다고 가정합니다. 다시 사용 git하면 git blame주석에 표시된 것을 수행 할 수 있습니다 ).
크리에이티브 브랜칭 및 병합을 사용하면 버전 제어 프레임 워크 내에서 주요 OS 업그레이드 또는 기타 전환을 처리 할 수 ​​있습니다. 일단 올바르게 설정하면 새 브랜치로 전환하기 만하면 프로덕션 푸시가 바로 작동합니다.

여기에 이것을 구현하고 있다면 커밋 된 꼭두각시 구성이 제정신 (클라이언트 측 사전)인지 확인하기 위해 git의 사전 커밋 및 사후 커밋 후크를 활용하고 나머지 유니버스로 밀어 넣을 것입니다. (서버 측 게시물-배포 정책에서 이러한 동작을 허용하는 경우 환경 업데이트를 트리거 할 수도 있음).

각 사이트에 새로운 puppetmaster 서버를 제공하는 것과 관련하여 꼭두각시 환경을 각 원격 puppetmaster에 확인하고 위에서 설명한 resolv.conf / hostname 해커 또는 Michuelnik과 같이 로컬 시스템으로 리디렉션 된 애니 캐스트 서비스 IP를 사용할 수 있습니다 ( 후자는 한 사이트의 puppetmaster가 폭발 할 경우 자동 장애 조치를 원할 경우 유용합니다.) 각 사이트가 "올바른"puppetmaster를보고 업데이트를 가져 오려는 WAN 링크를 방해하지 않도록 처리합니다.

Brain Tree Payments 직원 들은 버전 제어 및 rsync 솔루션 을 일부 사용자 정의 Capistrano 작업 과 결합한 것으로 보입니다. 솔루션은 여전히 ​​수동 워크 플로 요소에 의존한다는 의미에서 절반에 구워진 것처럼 보이지만 너무 많은 일.
저의 편집증 강압 테스터는 noop위생 검사 단계에 대한 애정이 있습니다.