您的公司使用亚马逊云服务吗?[关闭]
-
09-06-2019 - |
解决方案
我在 EC2 上设置了应用程序的两个实例,并一直使用 S3 作为本地到 AWS 的备份和媒体资产传输。6 月中旬,我们将超过 15% 的应用程序内容/流量转移到了 EC2。结果好坏参半,我们正在将内容频繁使用的实例移回我们的托管数据中心,现在正在研究其他内容交付选项。
请注意:
- 我的应用程序需要大量带宽(每个实例从 100mbps 开始)
- 我和我的公司都位于瑞士,这肯定对我们的评估产生了影响。
- 我将带宽定义为流量速率(mbps 等),将流量定义为容量(mb、gb 等)
优点:
- 中低流量的流量成本(假设每月不到 1 TB)。超越这条模糊线,要么自己做,要么找到合适的 CDN
- 活跃的用户社区
- 通过 S3/CloudFront 交付的内容,带宽实际上不受限制
- 灵活性(启动实例并在几分钟内运行)
- 实例中可用的 CPU 能力(即使是小型实例类型)始终足以满足我的应用程序的需要。还有其他高 CPU 实例类型可供需要的人使用。
缺点:
- 我们有一个实例变得无法访问(并非闻所未闻的情况),并执行了我们的灾难恢复程序。12小时。
- S3 和 EC2 的网络延迟可能高得令人无法接受(数百毫秒)
- EC2 实例带宽有限。尽管进行了数小时的搜索,但我从未找到一份官方声明,其中明确指出了用户可以期待的数字。最初,我们在测试中看到最大速度约为 250mpbs,但似乎已经有了显着改善。
- 每个 HTTP 连接的带宽可能低得令人无法接受。即使我们的瑞士数据中心具有 800mpbs 连接和高质量对等互连,也能达到 1-2mbps。编辑:我们最近发现我们的数据中心和 EC2 之间的速率在 3-4mpbs 范围内。
- S3 不是“普通”文件系统
, ,并且需要专门的软件。我们选择了 JungleDisk,我现在发现它不适合 24/7、中等大小的数据集服务器环境。会发生奇怪的事情(使用“ls”命令列出文件两次)和意外崩溃。使用 电子束系统 对于持久数据,尽管那是 并非没有警告. S3 是 不是 CDN。与许多其他公司一样,我的公司也尝试使用 Amazon S3 作为 CDN。还有其他低成本替代方案。(Akamai、voxel.net、easycache.com)
我是云概念的粉丝,我们将继续运行 EC2 实例,但我们发现它目前的形式不适合我们的主要生产需求。AWS 有一些问题需要解决。
其他提示
我目前正在使用S3进行视频托管,我喜欢它。如果您正在使用.NET,请给自己一点时间,以便在您的站点中集成设置。我会高度推荐他们的服务。
我发现粗暴的唯一一件事就是你必须花费> 100才能获得银级服务,我们的网站最终会花费那么多,但我们还没有进入测试阶段。我没有问题,我只想看看他们的支持是什么样的。
支持很棒,而且非常有帮助,但我本来希望能够在不必掏腰包的情况下提出一些问题(而不是老板的口袋)
哦,我没有遇到任何许可证问题。
相比之下,对于这笔钱,我会选择S3高于其他托管服务,因为他们的覆盖范围非常广泛且价格指向它如此之低。
关于可靠性
我没有在云服务上运行任何内容,但我想解决可靠性问题。
我确信亚马逊团队拥有比我更多的经验和资源来运行重型网站。他们上周停工了几个小时,但我相信他们的正常运行时间将比我们拥有的经验和资源水平更好。
我正在使用S3进行图像托管(目前超过500万个文件)和服务器备份。我使用EC2进行图像处理,使用SQS协调这些任务。我必须说我已经删除了EC2,因为对于那个特定的任务,非虚拟化服务器被证明是快10倍。我使用mysql编写了自己的排队解决方案,事实证明它更快,并且没有与AWS建立紧密联系。
Coding Aloud上有一篇重要文章[ http://www.codingaloud.com/2008/01/going-bankrupt-with-amazon-s3.html] 称为Going Bankrupt使用Amazon S3,请看一下。
免责声明:我是UCSB的一名研究生,他推出了我要提及的软件。
如果您担心云所有权(例如,不是实际拥有云盒),您可能需要查看桉树。它符合EC2 API,允许您使用服务器,它是开源的,因此您可以准确地看到发生了什么。
但是对于实际问题,不,我们不会在云中托管我们的网站,尽管我们当然有很多想法可以用来做。
要进行第二次编辑,请查看 CloudStatus 。它监控AWS内容和Google App Engine的中断和性能。亚马逊还通过 http://status.aws.amazon.com/ 跟踪他们的停电情况。
我们将公司文件存储在S3上,以便随时随地访问员工。非常便宜和容易。在S3上访问文件的应用程序很多。我们使用的是一个不错的在线文件管理器: S3fm 。
我和一群朋友正在研究一个存在于云中的应用程序。但是,它所居住的云部分在我们的控制之下。我永远不会相信第三方为我的申请做那种解除,因为我无法控制它。最近的Amazon S3中断是一个很好的说明原因。
我绝对,肯定地说,永远不会把我的基础设施的任何部分放在(例如)亚马逊的服务器上。构建服务器,源代码等始终受到严格控制。不仅因为潜在的不可靠性,而且因为我发现这些服务的许可证对服务提供商过于宽松。除此之外,一个不道德的主机*可能会使用我的源代码并将其用于自己的目的,即使这样的东西没有通过许可协议合法化,我将不得不接受以使用该服务。
*可能不适用于亚马逊,但我从来没有听说过你提到的其他两个,直到它们已经存在了十年左右,我可能不会相信它们,或者像他们这样的任何服务