클로이스터 → 간편 OTP 클러스터 관리

거의 모든 성공적인 비즈니스 애플리케이션은 조만간 수평적 확장이 필요한 단계에 들어갑니다. 대부분의 경우 간단히 새 인스턴스를 시작하고 로드 평균을 줄일 수 있습니다. 그러나 서로 다른 노드가 서로에 대해 알고 있는지 확인하고 작업 부하를 신중하게 분산해야 하는 덜 사소한 경우도 있습니다.

너무 운이 좋아서 그랬다. 얼랭우리가 유쾌한 구문과 그에 대한 과대 광고로 선택한 는 일류의 분산 시스템 지원. 이론적으로 이것은 완전히 사소한 것처럼 들립니다.

서로 다른 노드의 프로세스 간은 물론 링크와 모니터 간 메시지 전달은 투명합니다. […

실제로 모든 것이 조금 더 복잡합니다. 분산 얼랭 "컨테이너"가 배송을 위한 큰 철 상자를 의미하고 "도커"가 단순히 항만업자의 동의어일 때 개발되었습니다. 안에 IP4 비어 있는 주소가 많았고, 케이블을 씹는 쥐 때문에 네트워크가 중단되는 경우가 많았으며, 생산 시스템의 평균 가동 시간은 수십 년에 걸쳐 측정되었습니다.

이제 우리 모두는 믿을 수 없을 정도로 자급자족하고, 패키지화되어 분산 실행되고 있습니다. 얼랭 동적 IP 주소가 무작위성의 원칙에 따라 전달되고 노드가 스케줄러의 왼쪽 변덕에 따라 나타나고 사라질 수 있는 환경에서. 분산을 실행하는 모든 프로젝트에서 상용구 코드 더미를 피하기 위해 얼랭, 적대적인 환경에 맞서기 위해서는 도움이 필요합니다.

주의: 나는 그런 것이 있다는 것을 알고 있다. libcluster. 정말 멋지고, 별이 천 개가 넘고, 작가가 커뮤니티에서 유명하다는 것 등등이요. 클러스터 생성 및 유지 관리를 위해 이 패키지에서 제공하는 방법이 귀하에게 충분하다면 기쁩니다. 불행히도 더 많은 것이 필요합니다. 클러스터 재편의 현장을 외부의 방관자가 아닌 세밀하게 설정을 제어하고 싶습니다.

요구 사항

개인적으로 필요한 것은 클러스터 관리를 대신하고 다음과 같은 속성을 갖는 라이브러리였습니다.

• 하드 코딩된 노드 목록과 서비스를 통한 동적 검색을 통한 투명한 작업 얼랭;
• 모든 토폴로지 변경(거기 노드, 여기 노드, 네트워크 불안정, 분할)에 대한 완전한 기능의 콜백;
• 다음과 같이 긴 이름과 짧은 이름으로 클러스터를 시작하기 위한 투명한 인터페이스 :nonode@nohost;
• 인프라 코드를 작성할 필요 없이 즉시 Docker를 지원합니다.

후자는 로컬에서 애플리케이션을 테스트한 후를 의미합니다. :nonode@nohost, 또는 다음을 사용하여 인위적으로 분산된 환경에서 test_cluster_task, 난 그냥 달리고 싶어 docker-compose up --scale my_app=3 코드 변경 없이 docker에서 세 개의 인스턴스를 어떻게 실행하는지 살펴보세요. 나는 또한 다음과 같은 종속 응용 프로그램을 원합니다. mnesia - 토폴로지가 변경되면 애플리케이션에서 추가 작업 없이 클러스터를 실시간으로 재구축합니다.

회랑 클러스터를 지원하는 것부터 커피를 만드는 것까지 모든 것을 할 수 있는 라이브러리가 될 의도는 아니었습니다. 가능한 모든 사례를 포괄하는 것을 목표로 하는 만능책도 아니고, 출신 이론가들이 말하는 학문적으로 완전한 해결책이 되는 것도 아닙니다. CS 이 용어에 넣습니다. 이 라이브러리는 매우 명확한 목적을 제공하도록 설계되었지만 너무 크지 않은 작업을 완벽하게 수행합니다. 이 목표는 로컬 개발 환경과 적대적인 컨테이너로 가득 찬 분산된 탄력적 환경 사이에 완전한 투명성을 제공하는 것입니다.

선택된 접근법

회랑 고급 사용자는 직접 실행하여 수동으로 클러스터를 조립하고 유지 관리할 수 있지만 응용 프로그램으로 실행되도록 고안되었습니다. Cloister.Manager 대상 응용 프로그램의 감독자 트리에서.

애플리케이션으로 실행될 때 라이브러리는 다음을 사용합니다. config, 다음과 같은 기본 값을 읽습니다.

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

위의 매개변수는 문자 그대로 다음을 의미합니다. 회랑 OTP 신청에 사용 :my_app, 용도 얼랭 서비스 발견 최소 XNUMX개 이상의 노드를 연결하고 MyApp.Listener 모듈(구현 @behaviour Cloister.Listener)은 토폴로지 변경에 대한 알림을 받도록 구성됩니다. 전체 구성에 대한 자세한 설명은 다음에서 확인할 수 있습니다. 선적 서류 비치.

이 구성을 사용하면 애플리케이션이 회랑 의지 단계적으로 시작하다, 합의에 도달할 때까지 기본 애플리케이션 시작 프로세스를 지연합니다(위의 예와 같이 XNUMX개의 노드가 연결되고 연결됩니다.) 이는 기본 애플리케이션이 시작될 때 클러스터를 이미 사용할 수 있다고 가정할 수 있는 기회를 제공합니다. 토폴로지가 변경될 때마다(노드가 완전히 동기식으로 시작되지 않기 때문에 많은 변경이 있을 것임) 핸들러가 호출됩니다. MyApp.Listener.on_state_change/2. 대부분의 경우 상태 메시지를 받을 때 작업을 수행합니다. %Cloister.Monitor{status: :up}, 이는 "안녕하세요, 클러스터가 조립되었습니다."를 의미합니다.

대부분의 경우 설치 consensus: 3 더 많은 노드가 연결될 것으로 예상하더라도 콜백은 계속 진행되므로 최적입니다. status: :rehashing → status: :up 새로 추가되거나 제거된 노드에서.

개발 모드에서 시작할 때 설정만 하면 됩니다. consensus: 1 и 회랑 그가 볼 때 클러스터 조립을 기다리는 시간을 기꺼이 건너뛸 것입니다. :nonode@nohost또는 :node@host또는 :[email protected] - 노드가 구성된 방식에 따라(:none | :shortnames | :longnames).

분산 애플리케이션 관리

진공 상태가 아닌 분산 애플리케이션에는 일반적으로 다음과 같은 분산 종속성이 포함됩니다. mnesia. 동일한 콜백에서 재구성을 처리하는 것은 쉽습니다. on_state_change/2. 예를 들어 다음은 재구성 방법에 대한 자세한 설명입니다. mnesia 즉석에서 선적 서류 비치 회랑.

사용의 주요 이점 회랑 토폴로지 변경 후 클러스터를 재구축하는 데 필요한 모든 작업을 수행한다는 것입니다. 후드. 애플리케이션은 IP 주소와 노드 이름을 미리 알고 있는지 또는 동적으로 할당/변경되었는지 여부에 관계없이 모든 노드가 연결된 이미 준비된 분산 환경에서 실행됩니다. 여기에는 특별한 도커 구성 설정이 전혀 필요하지 않으며 애플리케이션 개발자의 관점에서 분산 환경에서 실행하거나 로컬 환경에서 실행하는 것 사이에 차이가 없습니다. :nonode@nohost. 이에 대한 자세한 내용은 다음에서 읽을 수 있습니다. 선적 서류 비치.

사용자 정의 구현을 통해 토폴로지 변경의 복잡한 처리가 가능하지만 MyApp.Listener, 이러한 라이브러리 제한 및 구성 편향이 구현의 초석이 되는 극단적인 경우가 항상 있을 수 있습니다. 괜찮습니다. 위의 내용을 따르세요. libcluster, 보다 일반적인 용도로 사용하거나 하위 수준 클러스터를 직접 처리할 수도 있습니다. 이 코드 라이브러리의 목표는 가능한 모든 시나리오를 다루는 것이 아니라, 불필요한 고통과 번거로운 복사-붙여넣기 없이 가장 일반적인 시나리오를 사용하는 것입니다.

참고 : 이 시점에서 원본에는 "행복한 클러스터링!"이라는 문구가 있었고 제가 번역한 Yandex에서는(직접 사전을 볼 필요가 없음) "행복한 클러스터링!" 옵션을 제공했습니다. 특히 현재의 지정학적 상황을 고려할 때 더 나은 번역을 상상하는 것은 아마도 불가능할 것입니다.

출처 : habr.com