使用 Windows AMI 的 Amazon EC2 和 EBS
我将我们的应用程序放在 EC2(Windows 2003 x64 服务器)上并附加最多 7 个 EBS 卷。 该应用程序对于存储来说是 I/O 密集型的 - 通常我们使用带有 NTFS 挂载点的 DAS(通常大约 32 个挂载点,每个挂载点为 1TB 驱动器),所以我尝试使用 EBS 复制它,但 I/O 速率很糟糕,如下所示最高 22MB/秒。 我们怀疑 EBS 的 NIC 卡(如果我没看错的话,它们是动态 SAN)限制了管道。 我们的应用程序主要使用流式传输来进行磁盘访问(不是随机的),因此对我们来说,当很少有东西妨碍我们与磁盘控制器对话并直接处理 IO 时,它会工作得更好。
另外,当我创建一个卷并附加它时,我看到它出现在实例中(很好),然后我将其制作成指向我的安装点的动态磁盘,然后快速格式化它 - 当我这样做时,所有数据都会被删除。音量被擦除? 因为当我将它附加到另一个 AMI 时,看起来确实如此。 我肯定错过了什么。
我很好奇是否有人有将 IO 密集型应用程序放在 EC2 云上的经验,如果有的话,设置卷的最佳方法是什么?
谢谢!
I put our application on EC2 (Windows 2003 x64 server) and attached up to 7 EBS volumes. The app is very I/O intensive to storage -- typically we use DAS with NTFS mount points (usually around 32 mount points, each to 1TB drives) so i tried to replicate that using EBS but the I/O rates are bad as in 22MB/s tops. We suspect the NIC card to the EBS (which are dymanic SANs if i read correctly) is limiting the pipeline. Our app uses mostly streaming for disk access (not random) so for us it works better when very little gets in the way of our talking to the disk controllers and handling IO directly.
Also when I create a volume and attach it, I see it appear in the instance (fine) and then i make it into a dymamic disk pointing to my mount point, then quick format it -- when I do this does all the data on the volume get wiped? Because it certainly seems so when i attach it to another AMI. I must be missing something.
I'm curious if anyone has any experience putting IO intensive apps up on the EC2 cloud and if so what's the best way to setup the volumes?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我的经验有限,但我注意到一件小事:
初始写入通常比后续写入慢。
因此,如果您将大量数据流式传输到磁盘(例如写入日志),这可能会让您感到困扰。 但是,如果您创建一个大文件,用数据填充它,并对它进行大量随机访问 I/O,那么第二次写入任何特定位置时它会变得更好。
I've had limited experience, but I have noticed one small thing:
The initial write is generally slower than subsequent writes.
So if you're streaming a lot of data to disk, like writing logs, this will likely bite you. But if you make a big file fill it with data, and do a lot of random access I/O to it, it gets better on the second time writing to any specific location.