들어오는 파일을위한 라운드 로빈

고유 한 파일 이름을 가진 많은 새 파일이 한 서버에 정기적으로 " ¹ "나타납니다 . (매일 수백 GB의 새 데이터와 마찬가지로 솔루션은 테라 바이트로 확장 할 수 있어야합니다. 각 파일의 크기는 수 메가 바이트, 최대 수십 메가 바이트입니다.)

해당 파일을 처리하는 여러 시스템이 있습니다. (수백 가지로 솔루션을 확장 할 수 있어야합니다.) 새로운 기계 를 쉽게 추가하고 제거 할 수 있어야합니다 .

아카이브 스토리지를 위해 각 수신 파일 을 복사 해야하는 백업 파일 스토리지 서버 가 있습니다. 데이터가 유실되어서는 안되며 들어오는 모든 파일은 백업 스토리지 서버에 전달되어야합니다.

각 파일 수신 미스트는 처리하기 위해 단일 시스템에 전달, 및 백업 스토리지 서버에 복사해야합니다.

수신자 서버는 파일을 보낸 후에 파일을 저장할 필요가 없습니다.

위에서 설명한 방식으로 파일을 배포하는 강력한 솔루션을 조언하십시오. 솔루션 은 Java를 기반으로 하지 않아야 합니다 . 유닉스 방식이 바람직하다.

서버는 우분투 기반이며 동일한 데이터 센터에 있습니다. 다른 모든 사항은 솔루션 요구 사항에 맞게 조정할 수 있습니다.

¹파일이 파일 시스템으로 전송되는 방식에 대한 정보를 의도적으로 생략했습니다. 그 이유는 오늘날 여러 가지 다른 레거시 수단 (이상하게도 scp, ØMQ를 통해)으로 파일을 타사에서 전송하기 때문입니다. 파일 시스템 수준에서 크로스 클러스터 인터페이스를 절단하는 것이 더 쉬운 것처럼 보이지만 하나 이상의 솔루션에 실제로 특정 전송이 필요한 경우 레거시 전송을 해당 전송으로 업그레이드 할 수 있습니다.

storage cluster

— 알렉산더 글라 디쉬
소스

나는이 질문을 좋아한다. 선거 전 선언문에서 SF로 다시 격려하는 것에 대해 이야기 한 것입니다.

— Tom O'Connor

이 질문을 마무리하기 위해 투표 한 사람들이 의견에 대한 동기 부여에 대해 자세히 설명해 주시면 대단히 감사하겠습니다. 특히 논외 투표. 감사합니다.

— Alexander Gladysh 2016 년

@AlexanderGladysh 역사적으로, 우리는 "시스템 디자인"스타일 질문에 너무 열중하지 않았습니다. 여기서 문제가 실제로 좁은 범위에서 해결할 수 있기 때문에 내가 대답했습니다. 모두 나와 나와 동의하지는 않습니다.

— sysadmin1138

흠. 이 질문을하기에 더 좋은 곳이 있습니까?

— Alexander Gladysh 2016 년

@AlexanderGladysh ServerFault Chat은 이러한 최종 개방형 질문 인 것처럼 보입니다.

— sysadmin1138

답변:

찾고있는 솔루션 중 하나가 있습니다. 이 시스템을 만드는 데는 자바가 없으며 오픈 소스 비트 만 사용 가능합니다. 여기에 제시된 모델은 내가 사용하고있는 기술 이외의 다른 기술과 함께 사용할 수 있습니다.

확장 가능한 업로드

파일은 특정 라운드 로빈 DNS 주소로 HTTP POST됩니다.
그런 다음 파일을 POST하는 시스템은 다른 한 쌍의로드 밸런서를 통해 AMQP 시스템 (여기의 Rabbit MQ)에 작업을 드롭하여 처리 워크 플로우를 시작합니다.
HTTP POST를 수신하는로드 밸런서는 각각 OpenStack Swift 오브젝트 저장소 서버 그룹 앞에 있습니다.
- 로드 밸런서에는 각각 두 개 이상의 OpenStack Swift 오브젝트 저장소 서버가 있습니다.
- 대상이 HA 인 경우 '라운드 로빈은 HA가 아닙니다.'가 될 수 있습니다. YMMV.
- 내구성을 높이기 위해 RRDNS의 IP는 개별 핫 스탠바이 LB 클러스터 일 수 있습니다.
실제로 POST를 가져 오는 오브젝트 저장소 서버는 파일을 Gluster 기반 파일 시스템으로 전달합니다.
- Gluster 시스템은 분산 (일명 샤드) 및 복제이어야합니다. 이를 통해 어리석은 밀도로 확장 할 수 있습니다.
AMQP 시스템은 첫 번째 작업을 디스패치하고 백업을 사용 가능한 처리 노드로 보냅니다.
처리 노드는 파일을 기본 스토리지에서 백업 스토리지로 복사하고 필요에 따라 성공 / 실패를보고합니다.
- 실패 모드 처리는 여기에 표시되지 않습니다. 기본적으로 작동 할 때까지 계속 시도하십시오. 작동하지 않으면 예외 프로세스를 실행하십시오.
백업이 완료되면 AMQP는 처리 작업을 사용 가능한 처리 노드로 발송합니다.
처리 노드는 파일을 로컬 파일 시스템으로 가져 오거나 Gluster에서 직접 처리합니다.
처리 노드는 처리 제품을 보관하고 AMQP에 성공을보고합니다.

이 설정은 충분한 서버가 주어진 경우 최고 속도로 파일을 수집 할 수 있어야합니다. 충분히 큰 크기의 10GbE 수집 속도를 얻는 것이 가능해야합니다. 물론 많은 양의 데이터를 빠르게 처리 하려면 처리 시스템 클래스에 더 많은 서버가 필요합니다. 이 설정은 최대 1,000 개의 노드로 확장 될 수 있으며 그 이상으로 확장 될 수 있습니다 (그러나이 모든 작업을 수행하는 대상에 따라 얼마나 멀리 떨어져 있는지).

엔지니어링 문제는 AMQP 프로세스 내에 숨겨진 워크 플로 관리 프로세스에 있습니다. 그것은 모든 소프트웨어이며 아마도 시스템 요구에 맞게 사용자 정의되었습니다. 그러나 데이터가 잘 공급되어야합니다!

— sysadmin1138
소스

전송 메커니즘이 계층 3에서 리디렉션 될 수있는 것이기 때문에 scp를 통해 파일이 도착한다는 사실을 알았으므로 프런트 엔드 서버가 존재하는 이유는 전혀 없습니다.

처리 서버 풀과 라운드 로빈 리디렉션 정책을 사용하여 LVS 디렉터 (페어)를 앞에 배치했습니다. 따라서 풀에 서버를 추가하거나 빼는 것이 매우 쉬워지고 넘어 질 프런트 엔드 서버가 없기 때문에 안정성이 향상되며 파일 가져 오기에 대한 풀 / 푸시 문제를 해결할 필요가 없습니다. 프런트 엔드가 없기 때문에 처리 서버에 대한 프런트 엔드

그런 다음 각 풀 서버는 파일을받을 때 두 가지 작업을 수행해야합니다. 먼저 보관 저장소에 파일을 복사 한 다음 파일을 처리하여 전송합니다.

— 매드 해 터
소스

무엇을 요청 받았는데 무엇이 부족하다고 생각 하십니까? 질문에 제시되지 않은 세부 사항 만 해결하지 못하면 질문이 질문이 아닌 경우 답변이 아닙니다. 그리고 당신은 그 질문이 그 자체로 좋은 질문이라고 생각한다는 것을 분명히했습니다.

— MadHatter

나는 그 질문에 대한 의견으로 그 질문에 대한 질문을하는 경향이 있지만, 우리는 간다.

— Tom O'Connor

차라리 당신에게 동의합니다. 그러나 당신이 질문을 정식화 한 이후로, 나는 당신이 적어도 그에 근거한 모든 대답을 이겼다고 생각합니다. ;-)

— MadHatter

그것은 일치 운동 문제 일 것입니다.

— Tom O'Connor

의견을 보내 주셔서 감사합니다. @MadHatter 질문에 정보를 추가했습니다.

— Alexander Gladysh 2016 년