여러 서버에 파일 배포

server-1에 파일의 중앙 저장소가 있습니다 /srv/www. 그런 다음 N 개의 서버도 있습니다. 우리는 server-1이 파일 /srv/www을 모든 서버에 가능한 한 빠르고 효율적으로 배포 할 수 있기를 원합니다 .

rsync와 같은 것이 있지만 단일 대상을 지정하는 대신 대상의 클러스터 (N 서버)를 지정합니까?

git작동한다고 생각 했지만 여러 리모컨을 지정하여 밀어 넣을 수 있습니까?

N 개의 서버가 결국 수백에 도달한다고 가정하면 가장 좋은 솔루션은 무엇입니까?

트위터 와 페이스 북 모두 클러스터에서 비트 토렌트를 사용하여 새로운 코드 개정판을 배포하기 시작했다. 이를 통해 기존의 중앙 집중식 배포 방법에 비해 매우 짧은 시간에 수만 대의 서버로 코드를 푸시 할 수 있습니다.

아직 규모가 큰 것 같지는 않지만 배포 시스템을 설계하는 데 아무런 해가 없으므로 조만간 병목 현상이 발생하지 않습니다.

나는 당신이 말하는 저울에 git을 권장하지 않습니다. 작동 할 수는 있지만 개인적으로 해당 모델을 가져 오는 데 약간의 결함이 있습니다.

가장 좋은 방법을 결정하는 몇 가지 사항이 있습니다.

1. 얼마나 큰 리포지토리를 공유해야합니까?
2. 얼마나 빨리 수렴해야합니까?

완벽한 컨버전스와 최대 속도를 위해서는 NFSv4와 같은 네트워크 파일 시스템을 사용해야합니다. 내가 아는 클러스터 파일 시스템은 수백 개의 노드로 확장되지 않으므로 네트워크 파일 시스템이어야합니다. 이는 고유 한 문제가 있지만 NFS 헤드에서 파일이 업데이트되는 순간 컨버전스에 도달 할 수 있음을 의미합니다.

빠른 수렴을 위해 일부 rsync 속임수를 사용할 수 있습니다. rsync 데몬이 CPU 바운드 상태가되면 haproxy와 같은로드 밸런서 뒤에 2-3 개의 rsync 서버를 배치 할 수 있습니다. cron 작업과 결합하여 데이터를 가져 오거나 코드 업데이트를 트리거하는 다른 방법을 사용하면 컨버전스를 매우 빠르게 달성 할 수 있습니다.

위의 두 가지 경우 모두 처리량을 극대화하기 위해 중앙 저장소를 10GbE 링크에 배치하는 것이 좋습니다.

대안은 푸시 리싱이며, 중앙 리포지토리에서 실행되어 서버에 업데이트를 푸시합니다. 위의 속도만큼 빠르지는 않지만 내부 대역폭에 더 친숙합니다. 더 나은 속도를 위해 여러 호스트를 분할 범위로 푸시하십시오.

rdist 가 당신을 위해 일할 수 있습니다.

[계열] Kwatee ( http://www.kwatee.net )를 사용 하면 원하는만큼 많은 서버에 배포 할 수 있습니다. 배포는 증분 (수정 된 파일 만 전송)되며 병렬화 될 수 있으므로 매우 빠릅니다. 업데이트 중에 서버가 LB에서 제거되었다가 다시 삽입되도록 Kwatee를 부하 분산 장치 인식으로 구성 할 수도 있습니다. 배포 매개 변수를 구성하는 그래픽 인터페이스가 있으며 GUI를 통해 수동으로 트리거하거나 python 명령을 사용하여 배포를 자동화 할 수 있습니다.