已经有一段时间了,但认为我们的用例会有所帮助...
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大大超过了专用的解决方案