현재 클라이언트가 Linux 커널 알림을 통해 inotify를 트리거하여 해당 파일에 대한 조치를 취하기 위한 구문 분석을 트리거하는 파일을 FTP로 보내는 시스템 설정이 있습니다. 제가 겪고 있는 문제는 파서가 현재 하나의 EC2 인스턴스에서 I/O 용량에 도달하고 있으며 파일 로드 분할 작업을 위해 추가 노드를 추가하고 싶다는 것입니다. 안타깝게도 클라이언트는 FTP를 통해서만 업로드할 수 있습니다. 이로 인해 파일이 삭제되는 EBS 볼륨을 공유하지 않는 다른 인스턴스를 어떻게 보유하고 해당 파일에서 작업할 수 있는지 궁금합니다.
현재 FTP를 사용하는 클라이언트를 건드리지 않고(IP 변경도 괜찮음) 여러 EC2 인스턴스가 파일 시스템에 액세스할 수 있게 해주는 AWS 솔루션이 있습니까?
답변1
물론...
두 유형 중 하나의 여러 볼륨에 연결하고 스트라이프하여 Amazon EC2 애플리케이션에서 사용할 수 있는 I/O 성능을 높일 수 있습니다.
EBS 볼륨의 RAID-10이 제가 사용해 본 것 중 하나입니다. 하지만... 여러분도 그런 것을 생각해 보셨으리라 생각합니다.
나는 다음과 같은 것을 사용하여 FTP 서버를 확장하는 것을 제안하려고 생각했습니다.HAProxy및/또는 redirUbuntu와 함께 번들로 제공되는 유틸리티(해당 프로토콜에 내재된 불합리한 부분을 수정하기 위해 FTP 패킷을 다시 작성할 수 있음) 그러나 FTP의 어색한 다중 연결 특성으로 인해 복잡한 제안이 될 수 있으며 실제로는 그렇지 않을 수도 있습니다. 원하다.
그렇다면 s3fs는 어떻습니까?
이것을 제안하기 전에 구글링을 해서 다음과 같은 것을 찾았습니다.이 게시물, 이는 작동하지 않을 수 있다고 제안했지만 그 경우 OP는 S3와 파일 시스템이 실제로 어떻게 작동하는지에 대한 이해가 상당히 부족한 것 같고 inotify가 외부 원인을 통해 S3에서 원격으로 변경되었음을 인식할 것으로 기대하고 있다는 것을 깨달았습니다. (로컬 파일 시스템을 통과하지 않은 상태에서) 물론 말이되지 않습니다.
하지만 테스트하기 위해 몇 가지 코드를 작성했는데 s3fs는 실제로 inotify와 올바르게 상호 작용하는 것으로 보입니다. FTP 서버에서 EBS 볼륨 대신 버킷을 마운트하면 클라이언트가 FTP를 통해 파일을 업로드할 때 해당 파일이 바로 버킷에 들어가고 inotify는 다음과 같이 기존 파일 시스템에서와 마찬가지로 해당 이벤트를 포착합니다. 이 시점에서는 SQS나 기타 여러 메커니즘을 사용하여 수행할 작업이 있음을 작업자 컴퓨터에 알릴 수 있습니다. 그런 다음 각 시스템과 S3 인프라 사이에서 사용 가능한 대역폭에 의해서만 I/O가 제한되는 방식으로 파일을 독립적으로 가져오고 처리할 수 있습니다.
동일한 정적 콘텐츠를 계속해서 제공하는 서버와 같이 s3fs가 완전히 부적합한 경우가 많이 있습니다. s3fs는 이에 대한 좋은 솔루션이 아닙니다. 발생하는 일 및/또는 로컬로 캐시하기 위해 s3fs가 필요함(가능하지만 소용 없음 - 필요한 경우 파일을 로컬에 저장하기만 하면 됨) 및 필요에 따라 개별적으로 가져오는 데 소요되는 대기 시간 반응형 웹 사이트를 제공하려고 시도하는 동안 문제가 발생할 수 있습니다... 하지만 각 파일이~ 아니다계속해서 액세스하면서 긍정적인 결과를 얻었습니다.
저는 최근 S3에 공개적으로 다운로드 가능한 자산을 저장하려는 클라이언트를 위해 작은 프로젝트를 수행했지만 아마도 귀하와 비슷한 제약이 있었을 것입니다.정말FTP를 사용하여 파일을 업로드할 수 있기를 원했습니다. proftpd를 s3fs를 통해 EC2 인스턴스에 마운트된 버킷과 결합하면 기존 시스템과 호환되는 S3에 대한 쉬운 "게이트웨이"가 제공되었습니다. 그래서 나는 그것이 작동한다는 것을 알고 있으며 inotify로 동일한 설정을 테스트한 결과 이제 두 사람이 예상했던 상호 작용을 하는 것 같다고 말씀드릴 수 있습니다.
이와 같이 EC2 내부에서 S3를 사용하면 스토리지 가격은 본질적으로 EBS와 동일하며 버킷이 엔드포인트와 동일한 지역에 있는 경우 대역폭 비용을 지불하지 않습니다. 각각에 대해서만 비용을 지불하고 PUT(요청 백만 건당 5달러) GET(백만 개 요청당 4달러) (가격표에 대한 내 해석. S3에 수백만 개의 개체가 저장되어 있으며 청구서에 놀라는 일이 없었지만 내 말을 받아들이지는 않습니다.) s3fs는 의사 파일 시스템 에뮬레이션의 일부로 파일 모드와 소유권을 S3에 저장하기 위해 백그라운드 원숭이 비즈니스를 수행해야 하고 개체를 반복해야 하기 때문에 파일과 요청의 정확한 1:1 상관 관계는 없을 가능성이 높습니다. 디렉토리 목록을 생성하므로 요청에 대한 YMMV가 있지만 실행 가능한 솔루션인 것 같습니다.
S3가 수행하는 기능과 기존 파일 시스템이 수행하는 기능 사이의 임피던스 불일치를 올바르게 이해하고 있는 한, 이것이 필요한 만큼 무한정 확장되지 않는 이유를 알 수 없습니다.
물론 s3fs에서 제가 가장 좋아하는 부분은 공간이 부족하지 않다는 것입니다. :)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
답변2
클라이언트가 IP가 아닌 DNS를 통해 FTP에 액세스할 수 있는 경우 가장 쉬운 솔루션은 여러 FTP 인스턴스 앞에 ELB를 배치하여 수평적으로 확장할 수 있는 것 같습니다.
그런 다음 처리가 완료되었을 때 ftp로 저장된 모든 파일을 한 위치에 모아야 하는 경우 S3 또는 다양한 솔루션을 사용하여 처리된 파일을 단일 위치에 지속적으로 저장할 수 있습니다.
답변3
inotify가 헤드 노드에 FTP로 전송되는 새 파일이 있음을 발견했을 때 해당 파일을 다른 노드로 scp하는 스크립트를 가질 수 없습니까?