Hetzner的Amazon EC2 vs专用服务器,EC2有什么用?


8

在网上搜索后,我仍然找不到使用EC2的原因。扩展EC2有什么意义?他们说,如果您预计流量会激增。

是的,但是如果您已经有几个站点的流量很好,例如中等保留的EC2实例,那还不够。

如果您使用数据库和S3,您将在欧盟(爱尔兰)支付$ 36.60(保留1年的中型)+流量+数据库和S3的可选费用。

当然,当您的价格在$ 56.6- $ 66.1以下时,您可以使用Amazon EC2优化托管成本。但是,如果到某个时候从Hetzner购买EX4服务器,它将在很长一段时间内超过您的性能需求,然后才获得大量流量。(我错了?)

CPU: i7-2600四核(3.4-3.8 Ghz)

内存: 16 GB

硬盘: 2x3 TB SATA(6 Gbit / s)- 我认为专用磁盘的性能要优于Amazon EBS

流量:每月10 TiB。这是您从Hetzner以56美元(-19%的增值税)或66美元的欧盟居民价格获得的。

请告诉我使用亚马逊的原因是什么?Hetzner的服务器不会承受哪种负载,但是Amazon Auto Scaling可以承受什么负载?

专用vs EC2的维护是否仍然相同?还是亚马逊的硬件故障,不会破坏您的EBS存储?

当我需要昂贵的托管服务时,我还没有达到这个水平,但想事先知道,只是为了确定Amazon基础设施是否比Hetzner硬件的纯性能更好。


您已经阅读了Hacker News的讨论吗?
冒犯君主

我想我已经比较阅读过《黑客新闻》或《黑客新闻》中的其他主题。最后我无法下结论。当您确实需要扩展数十个实例并在几个小时内将其关闭时,Amazon是个很好的选择。加上所有其他基础架构。
C-Blu

Answers:


4

老实说,这取决于使用情况,但是与专用相比,云技术有很多好处,例如...

可扩展性

可伸缩性要求因客户而异,许多人甚至可能根本不需要它,而某些企业可能会在预期BURST的某些版本中需要它。云计算的想法是,您可以在需要时增加服务器规格,使用API​​可以增加这些规格,因此即使EC2上的高规格实例的成本很高,也可能不需要每年的每一天来节省成本。在专用服务器上。

尽管每天使用HIGH SPEC vs Dedicated的费用会更高,但最终是的,他们需要降低价格才能更接近于专用,但他们还不得不考虑MARGINS。

乌云密布

一般而言,优质云提供商将拥有多个冗余故障转移系统,这些系统可使您的站点在发生故障时继续不受影响。专用服务器上的套件故障会导致服务中断。当专用服务器中断时,除非您有多个专用服务器,否则通常不会有故障转移系统。此外,如果您只有一台专用服务器,则需要花费一些时间才能使它恢复在线状态,具体取决于您使用的提供商,这可能需要几个小时甚至几天,并且如果考虑将提供商用于专用服务器,请问“发生这种情况的可能性如何? ”。

云端流量

如果您充分利用AWS系统,则EC2上的流量应尽可能少,因为SQL可以存储在RDS实例中,而静态文件也可以存储在S3容器中。

有了专用服务器,它们可以提供2x3TB和10TB的流量,但这又不是一个防故障系统,即使您要以镜像模式操作硬盘,也总是有两个硬盘都可能一次出现故障的机会,我知道这很不错。苗条,但如果...

关于此主题的其他内容,我非常怀疑专用服务器比内容传递网络提供文件的速度更快,这纯粹是因为它们将SAN镜像到世界各地的多个网络,因此,对于服务器所在区域的人们来说,它可能会更快。在世界其他地区的速度会明显变慢。同样,通过使用CDN来提供文件,您可以释放资源并允许主服务器更快地提供内容。

专用服务器维护成本更高

许多专用服务器提供商隐藏了费用,例如备份,重置,硬件修复-包括预期的周转时间,有些甚至没有提供正常运行时间SLA!

一般来说,从我阅读过的内容以及租用的服务器来看;备份文件非常广泛,您需要为此服务付费。另外,如果您自己进行备份,如果软件出现故障,我知道这对Linux来说是很小的机会,但是这又是另一个假设。使用简单的还原按钮即可恢复图像。

云计算增加了安全层

使用云计算可以通过使用多层来提高站点安全性,例如以S3为例,CDN极其安全,并增加了一层。数据库的RDS再次添加了一个附加层。

此外,大多数专用服务器并不像AWS使用的组件那样强大,我的意思是,AWS在DOS攻击下的抵抗力要强于甚至可能不在防火墙后面的专用服务器。请注意,我没有在这里说停止DOS攻击:P

老实说

老实说,您的问题没有正确答案,因为专职人员可能很适合您,您需要做的就是解决所有缺点,例如我列出的缺点,然后权衡一下-我个人不会再谈专心致志,因为我遇到了硬件故障的问题,发生故障时效果不好。


感谢您在这里的详细评论。好吧,那么我可以考虑在这种情况下使用EC2。我已经使用微型实例来执行某些cron作业,并使用S3托管静态内容和Route 53作为DNS服务。我想是时候来了,如果我将获得一些有关自动扩展和云基础架构的经验,那么最好只配置一台专用服务器。
C-Blu

4

我都用。您不会比Hetzner在任何地方都能得到更好的回报。它们坚如磐石。我仍然依靠CDN来获取静态内容,但除此之外,Hetzner很棒。

EC2是另一种动物。如果您有超级碗广告或其他内容,请使用它。更贵。如果您需要启动新节点,则速度也会更快一些。

如果您很懒,EC2也更容易。使用Hetzner,您必须安装ProxMox之类的东西才能获得与EC2相同的虚拟机收益,并需要一点定制。

我的推荐?节省一些现金。使用proxmox和hetzner设置负载均衡器vm和一些Web主机。如果您确实需要,有一个程序可以使用附加到负载均衡器的EC2来启动一些其他VM(对于DDOS,则具有自动限制功能)。将CDN用于静态内容。

编辑:获得两台中型计算机,而不是一台大计算机,这样您就可以在发生故障时翻转。设置自动备份到不是hetzner的服务。DNS是您的朋友,因为您拥有ProxMox虚拟机,因此您可以使用最坏的情况切换到其他云。


3

已经有一段时间了,但认为我们的用例会有所帮助...

AWS上的第一点

我们在知名主机上有一个专用服务器。这是一个巨大的规格,并且多年来一直试图经营Magento商店。我们已经对配置进行了调整,并且不会降低站点的性能。我们的主机尚未安装APC(在我开始之前),因此即使我们向他们付款以构建Magento服务器,他们也安装了APC,并使用损坏的PHP版本将站点关闭了3个小时。我们设法通过禁用的APC使它再次运行。

在AWS中,我们拥有等待在AWS上等待的所有AMI(NGINX,NGINX + Varnish,Control Server)的精确副本,我们可以随时启动并使用它们。我们可以克隆VBS数据所在的EBS卷,将一些IP映射到我们的VPC内部IP地址,将它们锁定到服务器,并立即启动并运行。做我们的测试,确保一切正常,然后更改LIVE系统,然后关闭副本,直到再次需要它为止。至此,我们对配置进行的更改被克隆到新版本的AMI中。

AWS的第二点。我们在当前主机上达到了IP地址限制。在AWS中,我们有任意数量的内部VPC IP地址,并已为我们的账户分配了20个可以映射到内部IP地址的弹性外部IP。AWS VPC中的网络功能绝对令人赞叹。他们是如何为低级网络管理员打包的,这是不现实的。花了3天的时间在我们的主机上获取了一些新IP地址并将其添加到其防火墙中。

这是我给AWS另一个+

当前专用服务器上的备份只是备份保管库中文件夹的克隆。基本上是已安装的驱动器。已安装的驱动器仅适用于该服务器。因此,在发生大规模停机的情况下,我们将必须进行新的服务器设置,安装备份存储,以完全相同的方式安装和配置新服务器(大任务),然后重新创建数据。我们的主机拥有4个小时的新硬件周转时间,但这对我而言根本没有任何意义。备份配置和站点。

我们的业务为整个网络生命周期内的业务提供解决方案。咨询,设计,SEO,支持和维护。如果我们在专心致志的工作上遇到了故障,那么我们将倒闭,因为那是几天之后,我们才能再次站起来。即使在假设地图上,我们也无法实现这种情况。只是不可能发生。

当前,在AWS中,我们的Web内容安装在750IOPS的EBS卷上的AWS实例上,第二个实例(我们称为控制服务器)将数据按计划同步到另一个可用区,并为最新配置更新一个实例,以防万一。需要从该AMI启动实例。为此,它会同步所有NGINX配置,PHP-FPM设置文件。

因此,现在我们有两组数据。一个AMI,它是生产型NGINX Web服务器的克隆,以及一个Vhosts目录内容的副本,其中包含配置文件和Vhosts,以防我们需要启动新服务器。

这是AWS 在高峰时段获得的另一种+我们的专用服务器的难题。是的,我们运行Magento,因此它与某些应用有些不同。我们有一个Quad Core 32GB Raid Disk Setup,当客户同时发送一两个或两个电子邮件活动时,它有时甚至会出现故障而难以解决。我们几乎什么也做不了。它在本地具有MySQL,其内存针对MYSQL优化,但磁盘较差。

在AWS中,我们运行3个High CPU实例。2个NGINX / PHP-FPM Web服务器,以及一个NGINX SSL +清漆缓存实例。然后,我们有一个较小的Magento Admin服务器,该服务器托管所有图像和媒体,然后通过CNAMES通过Cloudfront映射所有图像和媒体。这是所有保留实例,以降低成本。

然后,我们将数据库存储在2000IOPS大型实例的RDS中,两个Web服务器都连接到该实例,并每晚进行快照。稍作停顿(我们有商店的维护页面),我们可以调整IOPS和实例大小。关于RDS最好的事情是我们可以拍摄最新快照并创建一个新的数据库以进行测试和开发。然后关闭。太棒了。

我们使用Elastic Cache +,现在测试Redis对前端Web服务器的缓存管理。同样,我们可以调整大小。

我们可以添加一些新的服务器高CPU随需应变实例(通过克隆NGINX前端),并通过一些手动工作来帮助Xmas,如果需要,当客户告诉我们他们将发送10万个电子邮件活动时,产品享有75%的折扣。

现在,我们正在测试我们在Amazon中的自动扩展,以及如何启动服务器,添加IP地址,更新NGINX配置等,并开始正常工作,然后在安静时间(临近时间)将服务器取出并关闭。

AWS + + 在我们专用的服务器上移动数据会破坏服务。复制,Rsync MV等将击中磁盘IO,从而降低站点速度。

在AWS中使用卷和快照非常简单。真的不需要在这里说什么。

AWS +++++++ 常规服务器管理和控制。实际上,我们的专用服务器没有真正的可见性。它只是SSH进入,还有一些非常糟糕的服务器报告,我们的主机每月发送一次。

AWS,我们可以看到统计数据,尽管我认为应用程序性能并不完全准确,但它们确实为您提供了有关实际实例如何工作的好主意。我们有警报设置来检测问题。

结论 * AWS vs专用-Pure Power。*对于所有AWS Troll,我不是要说甚至要尝试说AWS将执行具有两个Quads,SSD内存加载等的专用。甚至AWS都不会尝试告诉您。您可以采取一些措施来提高性能,优化EBS,配置IOPS并调整实例大小,但是我知道,纯粹的纯硬件将胜过一切。

AWS VS专用-正确解决方案的体系结构 专用服务器坐在一个孤独的地方,对我来说就不那么适合了。在为企业提供经营商​​店或站点的解决方案时,这不是现实情况,也不适合作为解决方案。

我们在AWS VPC中拥有整个服务器网络,我们可以扩展,收缩,查看所有资源在哪里。作为一种解决方案,我永远都不想回到专用服务器。

如果我正在运行的站点可以处理大量停机,并且我们可以等待与主机一起重建新服务器,或者愿意使用两个主机或AWS作为备份并在专用站点出现故障时移动站点,那么这就是我这样做的唯一方法。这本身就是一个耗时的问题。

成本 专用服务器之所以如此便宜的原因是,AWS提供了廉价的方法来管理您自己的小型数据中心,而这正是许多数据中心用来为其添加额外费用的方法。定价发生了变化,数据中心现在必须对AWS使用排渣技术来出售其服务,或大喊有关Raw Server的功能以及某些AWS实例类型不足的信息。

将专用服务器与AWS实例进行比较的人们应该真正考虑AWS围绕该服务器实例提供的所有额外服务,并将其映射为专用价格。让我扩展。在离开并向我们的当前主机发出合同通知时,他们说是AWS,不良EBS成本等。因此,我们发送了我们想要的解决方案图。

  • 具有安全/路由策略和防火墙的专用局域网
  • 20个外部IP地址,能够即时或通过控制面板跨服务器重新映射
  • 4个服务器,每个服务器具有8个核心,每个核心具有16个线程
  • 32 GB内存
  • 数据库服务器能够提供高达10000 IOPS,但通常约为2000IOP
  • 点击备份
  • 没有合同或只有12个月

他们不仅不能做到所有这些,而且还说,如果他们可以提供软件堆栈来完成此任务,那么我们的安装成本约为10,000英镑,另加每月费用。

专用服务器的性能将超过云,但这已经成为过去。您可以在针对云计算的市场营销中看到它。云计算是将小型企业连接到拥有自己的数据中心的完整解决方案。在我看来,在设置了许多AWS解决方案之后,AWS目前是业务解决方案

我知道当我购买一个AWS实例时,不仅是实例,还包括它附带的所有套件。我知道,当我购买专用服务器时,它实际上只是一台丢弃在机架中并带有电缆的服务器。

我知道专用的服务器将比AWS更好,但是对于我的客户和实际业务需求,AWS大大超过了专用的解决方案


谢谢,这个详细的用例是我当时需要的答案,但是即使现在阅读它也很有用。好了,现在我有了关于云计算与专用定价的想法。建立这样的基础架构的能力非常适合像您这样的用例。也许是小型项目,不需要云托管,但是对于小型企业而言,这确实是一个不错的设置。
C-Blu

1

在上次AWS中断之后,我在AWS市场上找到了GSLB的解决方案,但您也可以使用Route53或Neustar来完成此任务。

我将其与EC2结合使用,并将一台专用服务器与opsource Varnish(由欧洲廉价托管服务提供商Leaseweb托管)一起使用。如果我检测到AWS故障,或者用EC2交付内容的预算已用完,则将流量引导到便宜的缓存服务器上。

这是我的最佳解决方案,而且成本高,并且可确保容错能力。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.