Amazon EBS를 여러 인스턴스에 연결할 수 있습니까?

현재 하나의 mysql 서버와 파일 서버에 액세스하는 여러 웹 서버를 사용하고 있습니다. 클라우드로 이동하는 과정에서 동일한 설정을 사용하여 EBS를 여러 머신 인스턴스 또는 다른 솔루션에 연결할 수 있습니까?

업데이트 (2015 년 4 월) :이 사용 사례의 경우 원하는 방식으로 곱하기 위해 설계된 새로운 Amazon Elastic File System (EFS)을 살펴보아야합니다 . EFS와 EBS의 주요 차이점은 서로 다른 추상화를 제공한다는 점입니다. EFS는 NFSv4 프로토콜을 노출하지만 EBS는 원시 블록 IO 액세스를 제공합니다.

아래에서 여러 블록에 원시 블록 장치를 안전하게 마운트 할 수없는 이유에 대한 원래 설명을 확인할 수 있습니다.

오리지널 포스트 (2011) :

EBS 볼륨을 둘 이상의 인스턴스에 연결할 수 있어도 _REALLY_BAD_IDEA_가됩니다. Kekoa의 말을 인용하자면, "한 번에 두 대의 컴퓨터에서 하드 드라이브를 사용하는 것과 같습니다"

왜 이것이 나쁜 생각입니까? ... 볼륨을 둘 이상의 인스턴스에 연결할 수없는 이유는 EBS가 고객이 ext2 / ext3 / etc와 같은 파일 시스템을 실행하는 "블록 스토리지"추상화를 제공하기 때문입니다. 이러한 파일 시스템의 대부분 (예 : ext2 / 3, FAT, NTFS 등)은 블록 장치에 독점적으로 액세스한다고 가정합니다. 동일한 파일 시스템에 액세스하는 두 인스턴스는 거의 확실하게 손상 및 데이터 손상으로 끝납니다.

즉, EBS 볼륨을 이중 마운트하면 여러 시스템간에 블록 장치를 공유하도록 설계된 클러스터 파일 시스템을 실행하는 경우에만 작동합니다. 또한 이것으로 충분하지 않습니다. EBS는이 시나리오에서 테스트를 거쳐 다른 공유 블록 장치 솔루션과 동일한 일관성 보장을 제공해야합니다. 즉, Dom0 커널, Xen 계층과 같은 중간 비공유 수준에서 블록이 캐시되지 않습니다. 그리고 DomU 커널. 그리고 여러 클라이언트간에 블록을 동기화 할 때 고려해야 할 성능 문제가 있습니다. 대부분의 클러스터 파일 시스템은 최선의 노력을 다하는 상용 이더넷이 아닌 고속 전용 SAN에서 작동하도록 설계되었습니다. 매우 간단하게 들리지만 요구하는 것은 매우 사소한 것입니다.

또는 데이터 공유 시나리오가 NFS, SMB / CIFS, SimpleDB 또는 S3 일 수 있는지 확인하십시오. 이러한 솔루션은 모두 공유 블록 장치 하위 시스템없이 파일을 공유하기위한 상위 계층 프로토콜을 사용합니다. 여러 번 그러한 솔루션이 실제로 더 효율적입니다.

귀하의 경우에도 여러 웹 프런트 엔드에서 액세스하는 단일 MySql 인스턴스 / 파일 서버를 가질 수 있습니다. 그런 다음 해당 파일 서버는 EBS 볼륨에 데이터를 저장하여 야간 스냅 샷 백업을 수행 할 수 있습니다. 파일 서버를 실행하는 인스턴스가 손실 된 경우 EBS 볼륨을 분리하고 새 파일 서버 인스턴스에 다시 연결 한 후 몇 분 안에 백업 및 실행할 수 있습니다.

"파일 시스템으로서 S3와 같은 것이 있습니까?" -그래요 그렇습니다. s3fs 와 같은 "제대로 작동"하는 타사 솔루션이 있지만, 여전히 각 읽기 / 쓰기에 대해 비교적 비싼 웹 서비스 호출을 수행해야합니다. 공유 도구 디렉토리의 경우 훌륭하게 작동합니다. HPC 세계에서 볼 수있는 클러스터 된 FS 사용량의 경우 기회가 아닙니다. 더 나은 결과를 얻으려면 NFS와 같은 이진 연결 지향 프로토콜을 제공하는 새로운 서비스가 필요합니다. 합리적인 성능과 동작으로 이러한 다중 마운트 파일 시스템을 제공하는 것은 EC2를위한 훌륭한 기능 애드온이 될 것입니다. 나는 오랫동안 아마존이 그런 것을 구축하도록 옹호했습니다.

업데이트 (2020) 이제 가능합니다!

동일한 가용 영역 내에서 AWS Nitro에서 실행중인 최신 인스턴스 유형으로 가능합니다. 몇 가지주의 사항이 있지만 이것은 EBS 속도가 필요하고 EFS를 실행할 수없는 특정 사용 사례에 적합합니다.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

오리지널 포스트 (2009)

아니요, 두 대의 컴퓨터에서 하드 드라이브를 사용하는 것과 같습니다.

공유 데이터를 원하는 경우 모든 인스턴스가 액세스 할 수있는 서버를 설정할 수 있습니다. 모든 인스턴스에 대해 간단한 스토리지 영역을 원하는 경우 Amazon S3 스토리지 서비스를 사용하여 분산 및 확장 가능한 데이터를 저장할 수 있습니다.

클라우드로 이동하면 정확히 동일한 설정을 할 수 있지만 파일 서버를 S3로 바꾸거나 모든 인스턴스를 파일 서버에 연결할 수 있습니다.

많은 옵션이 있지만 인스턴스간에 하드 드라이브를 공유하는 것이 가장 좋은 방법은 아닙니다.

EBS 문서에 따르면 : "한 번에 하나의 볼륨에만 볼륨을 연결할 수 있습니다".

현재 공유 스토리지를 어떻게 사용하고 있습니까? 파일 서버에서 파일을 제공하기위한 것이라면 웹 서버가 해당 파일을 제공하지 않고 파일 서버의 프로세스에 특정 요청을 프록시 할 수 있도록 시스템 설정을 고려 했습니까?

나는 당신이 할 수 없다고 확신하지만 EBS를 복제하여 다른 인스턴스에 연결할 수 있습니다.

고정 데이터 세트 또는 '실제'데이터 테스트에 유용하지만 단일 블록 저장소에서 둘 이상의 인스턴스를 작동 할 수는 없습니다.

AWS에서는 MySQL 서버 및 파일 서버에 액세스하는 여러 웹 서버가 정상입니다. 위에서 언급 한 아키텍처에서 따라야 할 모범 사례는 다음과 같습니다.

포인트 1) EC2의 MySQL은 AWS의 비동기 / 세미 동기화 모드에서 마스터 슬레이브로 설정할 수 있습니다. 고성능 DB에는 RAID 0의 EBS-OPT + PIOPS 권장

포인트 2) 또는 Amazon RDS + 다중 AZ 모드를 사용할 수 있습니다. 읽기 확장을 위해 여러 RDS 읽기 복제본을 MySQL RDS에 연결할 수 있습니다.

포인트 3) EBS 볼륨을 여러 EC2에 동시에 연결할 수 없습니다. EBS를 사용하여 Amazon EC2에서 GlusterFS를 기반으로 파일 서버를 생성 할 수 있습니다. 여러 웹 서버가 AWS 인프라에서 단일 GlusterFS와 동시에 통신 할 수 있습니다.

포인트 4) 응용 프로그램을 파일 저장소로 S3과 통합 할 수있는 경우 아키텍처에 가져 오는 안정성으로 인해 선호됩니다. 응용 프로그램에서 S3fuse와 같은 도구를 사용하여 S3에 액세스 할 수도 있습니다.

EBS는 이것이 가능하다고 발표했습니다 : https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

IT 세계에는 Clustered Filesystem, Redhat GFS, Oracle OCFS2, Veritas CFS 등이 있습니다.

짧은 대답은 범주 "아니오"입니다. 다른 사람들은 위에서 말했다.

"예"라고 대답 한 사람들은 그 질문에 대답하지 않고 다른 질문에 대답했습니다. EFS가 단순한 NFS 서비스 인 경우 원래 언급 한대로 질문에 대한 답변이 아닙니다. 또한 자체 NFS 인스턴스를 수행 할 수 있고 여러 서버가 NFS를 마운트 할 수 있기 때문에 EFS가 "모든 영역에서 롤아웃"되었는지 여부는 중요하지 않습니다. 그것은 새로운 것이 아닙니다. 우리는 이미 1992 년에 해냈습니다. SMB 및 sshfs는 모두 드라이브를 원격 파일 시스템으로 마운트하는 방법입니다.

"왜 그렇게 하시겠습니까?"또는 "모두 눈물로 끝날 것"이라고 말한 사람들은 잘못되었습니다. 우리는 수십 년 동안 여러 디스크를 여러 서버에 마운트 해 왔습니다. SAN (Storage Area Network)으로 작업 한 적이 있다면 일반적으로 FibreChannel SAN을 통해 동일한 장치를 여러 노드에 연결하는 기능은 완전히 정상입니다. 따라서 가상화 / 클라우드 서버가 유비쿼터스가되기 10 년 전에 서버를 운영 한 사람이라면 누구나 이에 노출 될 수 있습니다.

곧 두 시스템이 정확히 같은 볼륨을 읽고 쓸 수있는 클러스터 파일 시스템이있었습니다. 나는 이것이 역사상 이미 VAX와 Alpha VMS 시간으로 시작했다고 생각합니다. 클러스터 파일 시스템은 분산 상호 배제 체계를 사용하여 블록을 직접 조작 할 수 있습니다.

동일한 디스크를 여러 노드에 마운트하면 속도가 빠르고 단일 장애 지점이 줄어 듭니다.

이제 클러스터 된 파일 시스템은 "소비자"호스팅 비즈니스에서 큰 인기를 얻지 못했습니다. 그리고 그것들은 복잡하고 함정이 있습니다. 그러나 여러 컴퓨팅 노드에 연결된 디스크를 사용하기 위해 클러스터 된 파일 시스템이 필요하지 않습니다. 읽기 전용 드라이브를 원한다면 어떻게해야합니까? 클러스터 파일 시스템도 필요 없습니다! 읽기 전용 (ro)과 동일한 물리적 장치를 / etc / fstab에 넣습니다. 그런 다음 2 개 또는 10 개의 EC2 서버에 마운트하면 모든 장치에서 해당 장치를 직접 읽을 수 있습니다!

빠르게 확장되는 팜을 구축 할 때 클라우드 서버 세계에서이를위한 분명한 사용 사례가 있습니다. 주 시스템 디스크를 모두 준비하고 각 서버에 대해 아주 작은 부팅 및 구성 디스크 만 사용할 수 있습니다. 모두 동일한 부팅 디스크에서 부팅 할 수 있으며 읽기 / 쓰기 모드에서 다시 마운트하기 직전에 Union-FS를 3 계층으로 삽입 할 수 있습니다.

1. 부팅, 커널 및 사용자 영역 설치가있는 기본 읽기 전용 시스템 디스크
2. 개별 서버에 고유 한 파일이 거의없는 (주로 / etc에있는) 구성 파일 시스템. 이 디스크는 다른 서버에서 기록하여 새 인스턴스 부팅을 준비 할 수 있습니다. 예제 파일은 / etc / hostname이며 노드마다 다르게 유지해야하는 구성 파일은 거의 없습니다.
3. 전혀 필요하지 않은 쓰기 가능한 디스크는 메모리 파일 시스템으로서 / tmp 일 수 있습니다.

그래서, 그 질문은 많은 의미가 있었고, 불행히도 그 대답은 (아직도) "아니오"입니다. 그리고 NFS는 시스템 디스크의 모든 읽기 작업에 불이익을 주므로 해당 사용 사례를 대체하지 않습니다. 그러나 위에서 설명한 유스 케이스를 구현하는 유일한 대안은 NFS 시스템 디스크에서 네트워크 부트를하는 것입니다. 불행히도 네트워크 부트 에이전트와 NFS 설정은 동일한 물리적 블록 장치에 액세스하는 것보다 훨씬 까다 롭습니다.

추신 : 나는 짧은 버전의 의견을 의견으로 제출하고 싶었지만 어리석은 51 신용 포인트 임계 값으로 인해 할 수 없으므로 동일한 필수 "아니오"로 답을 작성해야하지만 이것이 왜 내 요지를 포함시켜야하는지 적절한 답변을받지 못한 관련 질문

PPS : StackExchange에서 iSCSI를 언급 한 사람을 찾았습니다. iSCSI는 NFS와 다소 비슷하지만 논리적으로 FibreChannel SAN과 같습니다. 물리적 블록 장치에 액세스하고 공유 할 수 있습니다. 부팅 디스크 공유가 쉬워 지므로 부팅 네트워크 부팅을 설정하지 않아도됩니다. 그러나 AWS에서는 사용 가능한 네트워크 부팅이 없습니다.

이전에 EBS에서 단일 EC2 인스턴스 만 지정된 볼륨에 연결할 수 있었지만 이제는 적어도 io1 볼륨에 대해 다중 연결이 가능합니다. 자세한 내용은 이 AWS 블로그 게시물을 참조하십시오 .

다른 인스턴스에서 볼륨과 sshfs를 사용하여 하나의 인스턴스를 생성하지 않는 이유는 무엇입니까?

AWS의 여러 서버에서 하나의 드라이브를 완전히 사용할 수 있습니다. sshfs를 사용하여 외장 드라이브를 마운트하고 EC2의 여러 서버와 공유합니다.

단일 드라이브를 여러 서버에 연결해야하는 이유는 모든 백업을 로컬로 가져 오기 전에 모든 백업을 배치 할 수있는 단일 장소가 있기 때문입니다.