development

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

big-blog 2020. 6. 27. 10:08
반응형

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를위한 훌륭한 기능 애드온이 될 것입니다. 나는 오랫동안 아마존이 그런 것을 구축하도록 옹호했습니다.


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

공유 데이터를 원하는 경우 모든 인스턴스가 액세스 할 수있는 서버를 설정할 수 있습니다. 모든 인스턴스에 대해 간단한 스토리지 영역을 원하는 경우 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에 액세스 할 수도 있습니다.


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


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


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

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

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

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

The advantage of mounting the same disk to multiple nodes is speed and reducing single points of failures.

Now, clustered file systems have not become hugely popular in the "consumer" hosting business, that is true. And they are complicated and have some pitfalls. But you don't even need a clustered file system to make use of a disk attached to multiple compute nodes. What if you want a read-only drive? You don't even need a clustered file system! You just put into your /etc/fstab the same physical device as read only (ro). Then you mount to 2 or 10 EC2 servers and all of them can read directly from that device!

There is an obvious use case for this in the world of cloud servers when building rapidly scaling farms. You can have your main system disk all prepared and use just a very small boot and configuration disk for each of the servers. You can even have all of them boot from the same boot disk, and right before the remount of / in read-write mode, you can insert a Union-FS with 3 layers:

  1. The main read-only system disk, with boot, kernel, and userland installation
  2. A configuration file system, with only the few files (mostly in /etc) that are specific to the individual server. This disk can be written out by another server to prepare for booting a new instance. Example files here would be /etc/hostname and just very few configuration files that need to remain different per node.
  3. The writable disk, which you may not need at all, could be just /tmp as a memory file system.

So, yes the question made a lot of sense, and unfortunately the answer is (still) "No". And no NFS is not a great replacement for that use case as it penalizes all read activity from the system disk. However, network boot from an NFS system disk is the only alternative to implementing the use case I described above. Unfortunately, since setting up network boot agent and NFS is much trickier than just accessing the same physical block device.

PS: I would have liked to submit a shorter version of this as comments, but I cannot because of the silly 51 credit points threshold, so I have to write an answer with the same essential "No" but to include my point why this is a relevant question that has not been receiving a deserved answer.

PPS: I just found someone over at StackExchange mention iSCSI. iSCSI is somewhat like NFS, but logically like a FibreChannel SAN. You get to access (and share) physical block devices. It would make boot disk sharing easier so you don't need to set up the bootd network booting which can be finicky. But then on AWS, there is no network booting available either.


You can totally use one drive on multiple servers in AWS. I use sshfs to mount an external drive and share it with multiple servers in EC2.

The reason I needed to connect a single drive to multiple servers is to have a single place to put all my backups before pulling them down local.

참고URL : https://stackoverflow.com/questions/841240/can-you-attach-amazon-ebs-to-multiple-instances

반응형