您可以将 Amazon EBS 连接到多个实例吗？
我们目前使用多个 Web 服务器访问一台 mysql 服务器和文件服务器。 考虑迁移到云，我可以使用相同的设置并将 EBS 连接到多个机器实例吗？或者还有其他解决方案吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我们目前使用多个 Web 服务器访问一台 mysql 服务器和文件服务器。 考虑迁移到云，我可以使用相同的设置并将 EBS 连接到多个机器实例吗？或者还有其他解决方案吗？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（11）
更新（2015 年 4 月）：对于此用例，您应该开始查看新的 Amazon Elastic File System (EFS)，旨在以您想要的方式进行多重附加。 EFS 和 EBS 之间的主要区别在于它们提供不同的抽象：EFS 公开 NFSv4 协议，而 EBS 提供原始块 IO 访问。
下面您将找到我关于为什么无法在多台机器上安全安装原始块设备的原始解释。
原始帖子 (2011)：
即使您能够将一个 EBS 卷附加到多个实例，这也将是一种_REALLY_BAD_IDEA_。 引用 Kekoa 的话，“这就像同时在两台计算机上使用硬盘一样”
为什么这是一个坏主意？ ...
您无法将一个卷附加到多个实例的原因是 EBS 提供了一种“块存储”抽象，客户可以在该抽象上运行 ext2/ext3/等文件系统。 大多数这些文件系统（例如，ext2/3、FAT、NTFS 等）都是假设它们具有对块设备的独占访问权限而编写的。 访问同一文件系统的两个实例几乎肯定会导致撕裂和数据损坏。
换句话说，只有当您运行的集群文件系统旨在在多台计算机之间共享块设备时，双重挂载 EBS 卷才有效。 而且，即使这样也还不够。 EBS 需要针对这种情况进行测试，并确保它提供与其他共享块设备解决方案相同的一致性保证……即，块不会缓存在中间非共享级别，如 Dom0 内核、Xen 层、和 DomU 内核。 然后是在多个客户端之间同步块的性能考虑因素 - 大多数集群文件系统设计为在高速专用 SAN 上工作，而不是在尽力而为的商品以太网上工作。 听起来很简单，但你所要求的是一件非常不平凡的事情。
或者，查看您的数据共享方案是否可以是 NFS、SMB/CIFS、SimpleDB 或 S3。 这些解决方案都使用高层协议，旨在共享文件而无需共享块设备子系统。 很多时候这样的解决方案实际上更有效。
在您的情况下，您仍然可以拥有由多个 Web 前端访问的单个 MySql 实例/文件服务器。 然后，该文件服务器可以将其数据存储在 EBS 卷上，从而允许您进行夜间快照备份。 如果运行文件服务器的实例丢失，您可以分离 EBS 卷并将其重新附加到新的文件服务器实例，并在几分钟内恢复并运行。
“是否有像 S3 这样的文件系统？” - 是的，也不是。 是的，有像 s3fs 这样的第三方解决方案可以“正常”工作，但在但实际上，他们仍然必须为每次读/写进行相对昂贵的 Web 服务调用。 对于共享工具目录，效果很好。 对于您在 HPC 世界中看到的集群 FS 使用类型，这不是机会。 为了做得更好，您需要一个提供二进制面向连接的协议的新服务，例如 NFS。 提供这样一个具有合理性能和行为的多挂载文件系统将是 EC2 的一个很棒的功能附加组件。 长期以来，我一直倡导亚马逊打造类似的产品。
UPDATE (April 2015): For this use-case, you should start looking at the new Amazon Elastic File System (EFS), which is designed to be multiply attached in exactly the way you are wanting. The key difference between EFS and EBS is that they provide different abstractions: EFS exposes the NFSv4 protocol, whereas EBS provides raw block IO access.
Below you'll find my original explanation as to why it's not possible to safely mount a raw block device on multiple machines.
ORIGINAL POST (2011):
Even if you were able to get an EBS volume attached to more than one instance, it would be a _REALLY_BAD_IDEA_. To quote Kekoa, "this is like using a hard drive in two computers at once"
Why is this a bad idea? ...
The reason you can't attach a volume to more than one instance is that EBS provides a "block storage" abstraction upon which customers run a filesystem like ext2/ext3/etc. Most of these filesystems (eg, ext2/3, FAT, NTFS, etc) are written assuming they have exclusive access to the block device. Two instances accessing the same filesystem would almost certainly end in tears and data corruption.
In other words, double mounting an EBS volume would only work if you were running a cluster filesystem that is designed to share a block device between multiple machines. Furthermore, even this wouldn't be enough. EBS would need to be tested for this scenario and to ensure that it provides the same consistency guarantees as other shared block device solutions ... ie, that blocks aren't cached at intermediate non-shared levels like the Dom0 kernel, Xen layer, and DomU kernel. And then there's the performance considerations of synchronizing blocks between multiple clients - most of the clustered filesystems are designed to work on high speed dedicated SANs, not a best-effort commodity ethernet. It sounds so simple, but what you are asking for is a very nontrivial thing.
Alternatively, see if your data sharing scenario can be NFS, SMB/CIFS, SimpleDB, or S3. These solutions all use higher layer protocols that are intended to share files without having a shared block device subsystem. Many times such a solution is actually more efficient.
In your case, you can still have a single MySql instance / fileserver that is accessed by multiple web front-ends. That fileserver could then store it's data on an EBS volume, allowing you to take nightly snapshot backups. If the instance running the fileserver is lost, you can detach the EBS volume and reattach it to a new fileserver instance and be back up and running in minutes.
"Is there anything like S3 as a filesystem?" - yes and no. Yes, there are 3rd party solutions like s3fs that work "ok", but under the hood they still have to make relatively expensive web service calls for each read / write. For a shared tools dir, works great. For the kind of clustered FS usage you see in the HPC world, not a chance. To do better, you'd need a new service that provides a binary connection-oriented protocol, like NFS. Offering such a multi-mounted filesystem with reasonable performance and behavior would be a GREAT feature add-on for EC2. I've long been an advocate for Amazon to build something like that.
更新（2020）现在可以了！
现在，通过在同一可用区内的 AWS Nitro 中运行的最新实例类型，可以实现这一点。 有一些注意事项，但这对于需要 EBS 速度且 EFS 不可行的某些用例来说非常有用。
https://docs.aws.amazon.com/AWSEC2 /latest/UserGuide/ebs-volumes-multi.html
原始帖子 (2009)
不，这就像在两台计算机中使用硬盘一样。
如果您想要共享数据，您可以设置一个所有实例都可以访问的服务器。 如果您希望为所有实例提供一个简单的存储区域，则可以使用 Amazon 的 S3 存储服务来存储分布式且可扩展的数据。
迁移到云后，您可以拥有完全相同的设置，但您可以用 S3 替换文件服务器，或者让所有实例连接到文件服务器。
您有很多选择，但在实例之间共享硬盘驱动器可能不是最佳选择。
Update (2020) It is now possible!
This is possible now with the newest instance types running in AWS Nitro within the same Availability Zone. There are some caveats but this is great for certain use cases that need the speed of EBS and where EFS isn't feasible.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html
Original Post (2009)
No, this is like using a hard drive in two computers.
If you want shared data, you can setup a server that all your instances can access. If you are wanting a simple storage area for all your instances, you can use Amazon's S3 storage service to store data that is distributed and scalable.
Moving to the cloud, you can have the exact same setup, but you can possibly replace the fileserver with S3, or have all your instances connect to your fileserver.
You have a lot of options, but sharing a hard drive between instances is probably not the best option.
不可以，根据 EBS 文档：“一个卷一次只能附加到一个实例”。
您目前如何使用共享存储？ 如果只是为了从文件服务器提供文件，您是否考虑过设置一个系统，以便可以将某些请求代理到文件服务器上的进程，而不是让网络服务器提供这些文件？
No, according to the EBS docs: "A volume can only be attached to one instance at a time".
How are you using the shared storage currently? If it's just for serving files from the fileserver, have you considered setting up a system so that you could proxy certain requests to a process on the fileserver rather than having the webservers serve those files?
多个Web服务器访问MySQL服务器和 文件服务器在AWS中是正常的。 上述架构应遵循的一些最佳实践是：
第 1 点）EC2 上的 MySQL 可以在 AWS 中以异步/半同步模式设置为主从。 对于高性能数据库点，建议使用 RAID 0 中的 EBS-OPT+PIOPS
2) 或者，您可以使用 Amazon RDS + 多可用区模式。 对于读取扩展，可以将多个 RDS 只读副本附加到 MySQL RDS。
第 3 点）EBS 卷无法同时附加到多个 EC2。 您可以使用 EBS 在 Amazon EC2 上创建基于 GlusterFS 的文件服务器。 多个 Web 服务器可以同时与 AWS 基础设施上的单个 GlusterFS 通信。
第 4 点）如果您的应用程序可以与 S3 作为文件存储集成，那么它是首选，因为它为架构带来了稳定性。 您还可以使用 S3fuse 等工具从您的应用程序访问 S3。
Multiple Web Servers accessing MySQL Server & File Server is normal in AWS. Some of the best practices to be followed for the above mentioned architecture are:
Point 1) MySQL on EC2 can be setup as Master-Slave in async/semi sync mode in AWS. EBS-OPT+PIOPS in RAID 0 is recommended for High performance DB
Point 2) Alternatively you can use Amazon RDS + Multi-AZ mode. For read scaling Multiple RDS Read Replica's can be attached to MySQL RDS.
Point 3) EBS Volume cannot be attached to Multiple EC2's simultaneously. You can create File server based on GlusterFS on Amazon EC2 using EBS. Multiple Web Servers can talk to single GlusterFS simultaneously on AWS infra.
Point 4)In case your application can be integrated with S3 as file store, then it is preferred because of the stability it brings in to the architecture. You can also access S3 using tools like S3fuse as well from your application.
EBS 刚刚宣布这是可能的：https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/
EBS just announced this is possible: https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/
我相当确定您不能，但您可以克隆 EBS 并将其附加到另一个实例。
这对于固定数据集或“真实”数据测试很有用，但不允许超过 1 个实例在单个块存储上运行
I'm fairly sure you can't, but you can clone an EBS and attach it to another instance.
This is useful for fixed datasets, or for testing on 'real' data but doesn't allow more than 1 instance to operate on a single block store
IT 世界中有一些东西被称为集群文件系统、Redhat GFS、Oracle OCFS2、Veritas CFS...
There is something in the IT world known as Clustered Filesystem, Redhat GFS, Oracle OCFS2, Veritas CFS...
简短的回答是断然的“不”。 上面其他人也说过了。
那些说“是”的人并没有回答这个问题，而是另一个问题。 如果 EFS 只是一个 NFS 服务，那么它就不是最初所述问题的答案。 EFS 是否“在所有区域中推出”并不重要，因为您完全可以创建自己的 NFS 实例，并且让多个服务器挂载 NFS。 这不是什么新鲜事，我们在 1992 年就已经这么做了。 SMB 和 sshfs，所有这些都只是将驱动器安装为远程文件系统的方法。
那些说“你为什么要这么做”或“这一切都会以泪水结束”的人是错误的。 几十年来，我们一直在将多个磁盘安装到多个服务器上。 如果您曾经使用过 SAN（存储区域网络），那么通常通过 FibreChannel SAN 将同一设备连接到多个节点的能力是完全正常的。 因此，任何十年前在虚拟化/云服务器普及之前运行过服务器的人都对此有所了解。
很快就出现了集群文件系统，其中两个系统可以读取和写入完全相同的卷。 我相信这已经从历史上的 VAX 和 Alpha VMS 时代开始了。 集群文件系统使用分布式互斥方案来能够直接操作块。
将同一磁盘挂载到多个节点的优点是速度快并减少单点故障。
现在，集群文件系统还没有在“消费者”托管业务中变得非常流行，这是事实。 而且它们很复杂并且存在一些陷阱。 但您甚至不需要集群文件系统来使用连接到多个计算节点的磁盘。 如果您想要只读驱动器怎么办？ 您甚至不需要集群文件系统！ 您只需将相同的物理设备作为只读 (ro) 放入 /etc/fstab 中。 然后您安装到 2 或 10 个 EC2 服务器，所有这些服务器都可以直接从该设备读取！
在构建快速扩展的农场时，云服务器领域有一个明显的用例。 您可以准备好主系统磁盘，并为每台服务器使用非常小的启动和配置磁盘。 你甚至可以让它们全部从同一个启动盘启动，并且在以读写模式重新挂载 / 之前，你可以插入一个具有 3 层的 Union-FS：
安装
（主要在 /etc 中）特定于单个服务器。 这
磁盘可以由另一台服务器写出以准备启动
新实例。 这里的示例文件是 /etc/hostname 并且只是
每个节点需要保持不同的配置文件很少。
/tmp 作为内存文件系统。
所以，是的，这个问题很有意义，但不幸的是，答案仍然是“否”。 没有 NFS 并不是该用例的一个很好的替代品，因为它会惩罚来自系统磁盘的所有读取活动。 然而，从 NFS 系统磁盘进行网络引导是实现我上面描述的用例的唯一替代方案。 不幸的是，因为设置网络启动代理和 NFS 比仅仅访问相同的物理块设备要复杂得多。
PS：我本来想提交一个较短的版本作为评论，但我不能，因为愚蠢的 51 学分阈值，所以我必须写一个同样重要的“不”的答案，但要包括我的观点，为什么这是尚未得到应有答案的相关问题。
PPS：我刚刚发现 StackExchange 上有人提到了 iSCSI。 iSCSI 有点像 NFS，但逻辑上像 FibreChannel SAN。 您可以访问（和共享）物理块设备。 它将使启动磁盘共享更容易，因此您无需设置可能很挑剔的 bootd 网络启动。 但在 AWS 上，也没有可用的网络启动。
The short answer is a categorical "No". Others have said it above.
Those who said "yes" did not answer the question, but a different question. If EFS is just an NFS service, then it isn't the answer to the question as originally stated. And it doesn't matter if EFS is "rolled out in all zones" or not, because you can do your own NFS instance quite, and have multiple servers mount NFS. That isn't anything new, we've done that in 1992 already. SMB and sshfs, all of these are just ways to mount drives as a remote file system.
Those who said "why would you want to do that" or "it will all end in tears" are wrong. We have been mounting multiple disks to multiple servers for decades. If you ever worked with a SAN (Storage Area Network) the ability to attach the same device to multiple nodes usually through FibreChannel SAN is completely normal. So anyone who has run servers a decade ago before the virtualization / cloud servers became ubiquitous has some exposure to that.
Soon there were clustered file systems where two systems could read and write to the exact same volume. I believe this started with the VAX and Alpha VMS time in history already. Clustered file systems use a distributed mutual exclusion scheme to be able to manipulate blocks directly.
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:
installation
(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.
/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.
尽管 EBS 以前只允许将单个 EC2 实例附加到给定卷，但现在可以进行多重附加，至少对于 io1 卷而言是这样。 有关更多信息，请参阅 这篇 AWS 博客文章。
Although EBS has previously only allowed a single EC2 instance to be attached to a given volume, multi-attach is now possible, at least for io1 volumes. For more information, see this AWS blog post.
为什么不在其他实例中创建一个包含卷的实例并通过 sshfs 连接到该卷？
Why won't you create one instance with volume and sshfs to that volume in other instances?
您完全可以在AWS的多台服务器上使用一个驱动器。
我使用 sshfs 挂载外部驱动器并与 EC2 中的多个服务器共享。
我需要将单个驱动器连接到多个服务器的原因是，在将所有备份拉到本地之前，有一个地方可以放置所有备份。
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.