微官网开发建设_贮存

　　起始时间，Picnik使用开源项目，omgilefs，用于文件存储。我们的大多数服务器都有几个闲置的驱动器插槽，我们访问这些插槽上的大容量SATA驱动器。用于Mogilefs文件存储。大多数背景服务都是CPU密集型的，所以， 匹配这些I / O密集型存储是非常好的。这一策略工作得很好。但在储存要求超过CPU需求之后，不能这样做，此时，亚马逊的S3服务似乎是扩展存储的最简单方法。

　　在[高端品牌网站设计品牌]在测试S3之前，我们实际上没有太多的成本评估。一方面， 当时选择云计算并不多。此外， 一些可爱的工程师也必须推荐S3，最后，我们从未预料到过很多。

　　因为开发人员的机器不使用猫咪，因此已经有一个接口存储系统的框架。因此，支持S3支持相对容易。实际上，只有一天， 我做网站哪家好意识到S3支持。我测试了一两天。然后将其包装到我们每周发布中。这种实现的简单性是我们选择S3的另一个关键因素。

　　最初的，我们计划将最早的文件迁移到S3，这些文件从2007年12月开始，因为这些文件具有低访问频率，因此不要担心性能和可用性。这种模式非常好。S3看起来非常好。

　　唯一的缺点，我们迁移来自Mogilefs的文件并不足够快。没有速度来跟上文件的增长。而且， Mogilefs还开始有一些性能问题。我们的解决方案与其他大型网站相同：将文件直接存储到S3。起始时间，只将少量新文件直接存储到S3，然后逐渐增加，它一直流向亚马逊，直到大多数新文件。这样的，事情再次完成，让我们转身解决其他问题。

　　虽然S3非常可靠，但还有一些值得注意的问题。我们遇到的第一个问题是最终的动态问题。基本上，这意味着不保证立即阅读文档，写信给S3的西雅图集群后，尝试从EC2读取，这个问题更加严重。通过访问西雅图的数据中心代理的所有文件， 这个问题很容易，但是这样，我们的带宽增加。

　　我们遇到的第二个问题是亚马逊？返回http500错误，我们的代码可以尝试回复未成功的请求，这在大多数情况下都很好[网站在哪里定制？这很好。每两周一次，我们会遇到一个错误突然爆发了。所以重试不起作用。这种爆炸将持续大约一个小时。一天，我正在查看关键字（键），请注意，这些关键字具有相同的前缀！结果表明，S3是基于关键字的分区数据。这意味着维持（例如增加或减少分区容量）可以在范围内导致大量关键字。亚马逊这是为了维持S3高性能。为我们，这个突然的错误更大， 这很麻烦。因为我们也有巨大的工作，如果您写入营销型网站服务公司S3失败，把它写成猫咪：随着增长率往往稳定，现在很少出现这个问题。但是猫咪仍在玩。

　　实际上， 我们遇到的这些问题是建立一个大规模的系统。所以亚马逊也不使用任何东西。人们很容易忘记，这实际上是具有许多用户的庞大分布式系统。

　　随着流量的增长，我们越来越依赖S3。如果S3下降，大半天，我们的Mogl无法处理巨大的请求。幸运的是，S3中的大多数问题不是我网站的高峰时间，所以， Mogilev也可以被复制。我也应该提到的是，在这两种情况下，莫吉都将是停机时间。情况是修改MySQL的表结构，还有一个调试Mogilev的Perl代码。这次，将在S3上按下1009％的流量，我们的用户永远不会知道发生了什么。

　　“无限制”储存的危险易于浪费。为我们，我没有注意删除使用无用文件的背景工作行业。对于创建的文件，最终删除接近75％，无用的文件很快成长。

　　即使我们注意到了这个问题，实际上， 我决定忽略它。Picnik的每个人都很忙。这看起来并不大笔交易，而且，还有更好的新功能或其他可扩展性问题来应注意。有趣的是，S3让我们选择或雇用并培养更多人，或更简单，写一张支票。当我们的信用卡是本月， 是时候使用光。所有东西都变了。

　　经过几个月的调整， 分析和重写代码，我们终于拿出了一种清洁无用文件的可扩展方案。首先是数据库清除无用的文件记录。然后在数据库的文件记录和S3上的关键字列表之间进行大的连接操作（填料 [做网站]合并 - 加入，执行实际删除。

　　在实现更好的清洁系统的中间，我们开始意识到这一点是我们的工作量（工作负载），实际上非常昂贵。以前的成本分析没有考虑放置操作的成本。很多S3负载，存储成本占大头，因为文件上传，在很长的时间，偶尔访问。如前面提到的，我们的负载是创建大量文件，然后我在接下来的几天中删除它，这意味着所需的成本已经上升。

　　意识到这一点后，我们开始优化MogileFSL的性能，并研究高性能NAS产品。最后，我们已经实现了基于Linux的NFS概念系统作为前端存储。这意味着S3上只需要大约25％的文件超过1周，这些文件还有一个更友好的访问模式对于S3。

　　有很长一段时间，我们不清楚S3仍然适合。虽然更传统的NAS硬件看起来很贵，但但如果您对长期存储需求有信心，可以在一年或两年内支付。另一方面，许多企业家CFO（包括我们自己的）会告诉你，为了保持灵活性和一定程度的自由，更多的花费更多金钱也值得这一灵活性和自由的S3。当然，这种灵活性比运营和维护成本的成本更重要。至于我们的关注，只需操作和维护成本，因为这与流量和功能直接相关。

　　混合计算

　　Picnik的主要服务器组件之一是我们的渲染农场。当用户在Picnik上保存图片时，您经常需要在服务器上重建此图像。此时，客户端向服务器发送大段XML文本说明用户的编辑操作。收到Web服务器后，将与XML文本一起打包您需要的图像，并将其添加到渲染作业队列中。渲染服务器获取作业，重建图片，然后将结果图片返回到Web服务器。此时，客户端处于阻止状态。等待服务器的响应。大多数时候，客户只需要等几秒钟。

　　虽然这是一个可扩展系统的典型架构，但我们仍然考虑到设计期间对云计算的未来需求。此时渲染服务器无需访问任何内部服务。如数据库或存储服务器。简而言之，它们是在EC2上运行的理想选择，此外，我们已经开发了一个配置管理和代码部署系统。服务器管理器。

　　像S3一样，真的意识到简单快速。内部渲染网站已考虑在Xen上运行WM，所以我需要做的是一些简单的修改。为EC2的Xen进行渲染服务器的VM映像，然后将其包装为AMI。当图像打开时，首先连接到服务器管理器？获取需要安装和运行的组件列表，其中一个是renderserver，renderserver用于连接渲染队列以获取呈现作业。我要做的第一件事是激活两个实例来运行，看看它是如何伟大的！

　　第二阶段是实现云操作的最终目标：自动缩放。我们的自动拉伸仍然很容易。因为所有处理都通过队列实现。由于用户正在等待渲染结果，所以， 自动缩放代码的目标是维持空气队列5。服务器管理器的线程每分钟将唤醒。轮询队列统计信息（在最后一分钟中完成），然后计算，看看我需要做些什么，以保持傻瓜和忙碌的人的比例。当然，由于流量和网络延迟， 会有轻微的波动。为了避免不必要的振荡， 会有迟滞的现象。如果你需要几分钟， 你可以开始它。我们的代码还考虑到这些问题。所有这些实证调整都经历了两周时间。系统运行后，这很简单。

　　自动缩放性不仅仅是典型的容量需求问题，我们还遇到了EC2等网络延迟，或释放代码校正以使渲染速度慢下来。当你遇到这些情况时，让我们停止自动伸缩，它不是找出真正的原因并纠正它。我们还修复了错误，此错误使用户的保存操作的一小部分失败，这种纠正使得渲染负载加20％在圣诞节之前。

　　此设置也适用于批量工作。一段时间，我们必须重建一些缩略图，我写了一些代码。将您的工作提交给渲染队列，然后用新的缩略图文件更新数据库记录。我不需要做任何特殊的东西来分配空间或晚上放置工作环境。Server Manager只需添加新实例以适应新的负载要求。

　　来自金融，使用EC2比使用S3更清晰。我们试图扩展内部渲染以满足平均容量要求。同时地，将呈现为Web服务的CPU也很容易。这意味着云使一些动态特性作为渲染服务器带到Web服务器。这使我们很容易适应负载模式的变化，和，通过购买硬件，这也允许我们更有效地使用现有硬件。E.G，您可以在数据中心订购新内阁。然后将服务器从服务器置于服务器。不要担心浪费大部分内阁电力。

　　通常与EC2相关的问题主要集中在连通性上。虽然互联网整体可靠，但但任何两点之间的连接都不是这种情况。通常，如果在网络和数据中心之间出现问题，只有少数用户受到影响，但，如果网络恰好是云计算提供商，所有用户都将受到影响。这种停机时间可能非常严重。因为问题可能在这样的区域中，您是否仍然是云计算提供商， 没有付款，那是， 该地区令人难以忘怀。

　　发生严重问题（但也在繁忙时期），唯一的选择是摆脱负载。过去的，我们只有一种控制有多少用户进来的方法，现在我们分类用户（访客， 免费用户， 伙伴， 金用户）根据优先级。大多数情况下都可以访问[哪家公司建设网站] 那你必须等待停机时间恢复。无论如何，我们所做的第一件事是更新Twitter信息（FECD）。我们的下雨onour picnik页面上也显示了这些消息。我们不会责怪任何不关心它的人。

　　我们不监视EC2实例，如内部服务器。Nagiosi通过ServerManager自动从EC2实例获取信息。Nagiost还监视队列的深度，因为这是很多问题， 早期指标。

　　CACI在图示中示出，以显示运行实例的数量（通过EC2API）和集群层上的性能数据。我们不需要在Cacti添加有关单个实例的信息，因为它实际上并不处理群集，而且， 例子仍然是动态的。

　　实际上，我们不关心单一实例的性能。众所周知，这些实例比本地机器慢。没关系，因为自动伸缩系统总是在现有资源条件下找到余额。

　　由于实例从队列中获取，因此EC2实例略微慢，少做干燥，不会躺着。这使我专注于重点关注高级的性能数据。一天内EC2实例的比例是多少。在一天结束时，只需为Web服务器执行容量规划，从而确定硬件购买决策，渲染服务器仅从尚未使用的容量中受益。

　　要有效地使用本网站来构建云计算资源，对应用架构和配置管理/自动化有一个合理的“增长”态度。我们将渲染服务器设计为分解，我们有一个配置管理系统， 等等。这些事实使自动伸缩实施既容易可靠。