고성능, 짧은 지연 시간으로 여러 AWS 인스턴스 간에 데이터를 공유하고 싶습니다. 모든 인스턴스에 읽기 전용 액세스 권한을 부여하는 것은 괜찮습니다(쓰기를 처리하는 인스턴스 하나 제외). 이 사용 사례에 대한 두 가지 사항:
- 볼륨에 연결된 노드는 언제든지 왔다가 갈 수 있습니다(시작, 중지, 종료 등).
- 공유 데이터에는 나열하고 메타데이터를 확인해야 하는 잠재적으로 작은 파일이 수천 개 포함되어 있습니다.
그래서 처음에 EFS를 시도해 보았지만 수백, 수천 개의 작은 파일을 열거하거나 수정해야 하는 작업에는 다소 느립니다.
그래서 지금은 EBS 다중접속을 고려하고 있습니다. 그러나 데이터 손상을 방지하기 위해 AWS에서는 GFS2 또는 OCFS와 같은 클러스터 파일 시스템만 사용할 것을 권장합니다. 두 가지 모두 구성이 복잡하고 까다로울 뿐만 아니라 노드가 언제든지 오고 갈 수 있는 클러스터의 사용 사례에 취약한 것으로 보입니다. 예를 들어, GFS2에서는 노드 수가 2개 이상에서 정확히 2개로 변경되면 모든 노드의 클러스터 소프트웨어를 다시 시작해야 합니다. 또는 새 노드를 추가하려면 현재 노드에 로그인하고, 일부 명령을 실행하고, 업데이트된 구성 파일을 다른 모든 노드에 다시 배포해야 합니다. 정말 융통성이 없고 추가 오버헤드도 많이 발생하는 것 같습니다.
하지만 단 하나의 인스턴스만 디스크에 쓰기 작업을 수행한다고 확신한다면(또는 각 인스턴스가 자체 하위 폴더나 디스크 파티션에만 쓸 수 있을 수도 있음) 이 볼륨에 XFS와 같은 일반 파일 시스템을 사용하여 문제를 해결할 수 있을까요? ? 아니면 액세스가 기술적으로 읽기 전용이거나 쓰기 액세스가 인스턴스별 하위 폴더 또는 파티션으로 제한된 경우에도 미묘한 데이터 손상 문제가 있습니까?
아니면 제가 놓친 완전히 다른 해결책이 있나요?
답변1
이(XFS)를 테스트했는데 작동하지 않습니다. 클러스터된 파일 시스템이 필요합니다. 가장 좋은 방법은 클러스터 파일 시스템을 사용하는 것입니다. Veritas Infoscale과 같은 다른 옵션을 살펴보십시오.
답변2
정적 볼륨 콘텐츠 공유는 다중 연결 및 일반 XFS에서 제대로 작동하는 것으로 보입니다. 볼륨에 대한 핫 "추가"는 데이터를 쓴 인스턴스에만 표시됩니다. 이를 확립한 상태에서 핫 "업데이트" 또는 "삭제"는 작성자에게만 표시되지만 잠재적으로 다른 인스턴스의 해당 데이터에 대한 액세스가 중단될 수 있다고 가정하여 테스트하지 않았습니다. 재부팅, 재시작 및/또는 다시 연결된 인스턴스에는 최신 볼륨 상태가 표시됩니다. 따라서 하나의 인스턴스가 새 데이터를 드물게 작성하여 다른 인스턴스가 강제 재부팅을 실행하는 사용 사례는 결국 데이터가 이 기술을 지원할 수 있는 사용 사례인 것처럼 보입니다.