Magento托pipe预算
我必须为Magento做一个设置。 我的约束主要是便于安装和容错/故障切换。 而且成本是一个问题。 我有三个相同的物理服务器来完成这项工作。 每个服务器节点在软件RAID 1configuration中都有一个i7四核，16GB RAM和2x3TB HD。 每个节点运行Ubuntu 12.04。 马上。 我有一个额外的IP地址可以路由到任何这些节点。
Magento商店有最大。 1000个产品，其中50％是捆绑产品。 我估计，最大。 10个用户同时激活。 这使我得出结论，performance不是这里的重中之重。
我的第一个设置想法
一个节点（lb）运行nginx作为负载均衡器。 附加IP与域名一起使用，并默认路由到此节点。 Nginx将负载平均分配给另外两个节点（shop1，shop2）。 Shop1和Shop2configuration相同：每台服务器运行Apache2和MySQL。 Mysqlsconfiguration了主/从复制。
我的故障转移策略：
- Lb失败=>将IP路由到shop1（MySQL master），继续。
- Shop1失败=> Lb会自动处理，在shop2上升级MySQL从属掌握，重新configurationMagento使用shop2进行写入，继续。
- Shop2失败=> Lb会自动处理，继续。
这是一个理智的战略？ 有没有人做过与Magento类似的设置？
我的第二个设置想法
另一种方法是使用drbd在shop1和shop2上存储MySQL数据文件。 我明白，在这种情况下，只有一个节点/ MySQL实例可以是活动的，而另一个被用作热备份。 所以如果shop1失败，我会在shop2上启动MySQL，将IP路由到shop2，然后继续。 我喜欢这一点，因为MySQL设置更容易，节点可以configuration99％相同。 所以在这种情况下，负载平衡器变得毫无用处，我有一个备用服务器。
我的第三个设置想法
第三种方式可能是MySQL数据库的主 – 主复制。 然而，在我的select中这可能是棘手的，因为Magento不是针对这种情况构build的（例如，新行的冲突ID）。 直到听说过一个实例，我才会这样做。
你能给我一个build议，哪条路要走？ 似乎没有一个“好”的方法来做到这一点。 例如，我读博客文章描述Magento的MySQL主/从设置，但在其他地方，我读到，当奴隶落后于主人（例如，当订单被放置，顾客可能被创build两次）时，数据可能被重复。 我有点迷路了
吻
保持简单愚蠢。
我有点迷路了
出于这个原因，不要开始过度复杂的事情，不需要复杂。 如果你不知道在一开始就实施某些东西的正确方法 – 当出现问题时你肯定不知道该怎么做。
首先，让我们解决硬件问题
参考： https ： //www.sonassihosting.com/help/magestack/cpu-sizing/
a）一个标准的Magento演示商店能够每小时提供每GHz约230个独立用户。
b）一个典型的networking商店，pipe理员用户活动，开发活动，产品添加/删除可以看到这个降低了100％左右，每小时115个独特的频率。
在任何特定时间使用您的100名活跃访问者的数字，
hourly_hits = (60 / time_on_site (mins)) * concurrent_users 因此，我们假设每个访问的行业平均时间为8分钟，访问量为8页。
hourly_hits = (60 / 8) * 100 hourly_hits = (7.5) * 100 hourly_hits = 750
其中每小时750名访客，或每天约7500名独立访客。
为了支持每小时750个访问者，115个独立/ GHz，您将需要相当于7个1GHz的CPU内核。 所以，让我们假设你的i7四核心是2.5GHz – 这将累计总共10GHz。
其次，让我们解决你的configuration
你的目标是什么？
- 高可用性
- 可靠性
- 简单的pipe理
- 性能
- 可扩展性
你的想法都不是特别好，你的负载平衡器是一个单一的失败点，我觉得你有点太过于在MySQL冗余。
Master-Master是一个configuration噩梦，你没有这样做的好处。 Magento不受MySQL限制，丝毫不受限制。 看看我应该放在我的大机器上？ Magento数据库的Magentonetworking服务器？
除非你打算让你的架构中的所有东西都是多余的，也就是说。
- 绑定的networking接口
- A + B开关
- A + B防火墙
- A + B将不同的UPS分开供电
- 多宿主上游连接
尝试在软件层build立一定的韧性是没有多大意义的。
我们如何做到这一点
有没有人做过与Magento类似的设置？
总之， 是。
我们通过容器化每个节点来configurationMageStack中的单服务器到n台服务器。
所以在你的情况下，我们通常会设置以下（假设你要求HA）。
**Server 1** **Server 2** **Server 3** LB (m) <==> LB (s) Web (m) Web (m) Web (m) DB (s) <==> DB (m)
LB和DB虚拟服务器将在DRBD镜像上具有其根分区（由<==>表示）。 networking节点可能会使用一个普通的NFS存储，或者更常见的情况是在活动的networking节点上进行回收。
只是在这里引用一个答复如何安排Web服务器与清漆？
我们典型的build筑是
lvs (initial ssl load balancing) -> pound (ssl-unwrapping) -> varnish (caching) -> haproxy (load balancing) -> nginx (static content) -> php (dynamic content) -> mysql (db)
心跳将维护机器之间的健康检查，并提供IP故障转移和启动/停止各自的虚拟服务器。
所以最终的集装箱式架构看起来就像这样…（原谅这个graphics，我从市场营销的PDF中挖掘出来的）。
我会如何推荐你这样做
不要使用主/从，不要使用DRBD，只要保持真实，非常简单 – 当事情不起作用时，便于pipe理和debugging。
**Server 1** **Server 2** **Server 3** LB Web Web Web DB
这样，你可以得到负载分配和硬件的充分利用。 最糟糕的情况 – 如果服务器1或服务器3出现故障 – 那么您将硬盘驱动器放入服务器2中。远程交给DC – 这可以在5分钟内完成。 这将是一个该死的网站更容易pipe理，这将意味着你将不需要生成一个30页的文件configuration的机器和运行手册程序，并将需要相当less的时间来build立。
我们有服务器的正常运行时间超过3年 – 所以应该考虑多久服务器级设备出现故障。 通常情况下，服务器上最常见的问题原因是纯粹的软件configuration。
我唯一担心的是你的硬件不是服务器等级，所以你可能会冒更高的失败率 – 但你select使用它的风险。
综上所述
我不build议尝试为电子商务商店自己构build，pipe理和监督服务器configuration，其中托pipe和支持是保持您的业务在线的最重要的部分。
一台服务器？
我永远不会推荐包含电子商务SPoF（单点故障）的解决scheme
FWIW，我目前正在为亚马逊的Elastic Beanstalk服务设置指南，这将允许您自动扩展所有维度，同时只支付实际使用的资源。
当然，这是所有多区域，并具有冗余和故障转移内置:)
维护是一件轻而易举的事情 – 您可以使用AWS命令行工具和git直接更新您的Magento，也可以将Magento应用程序的zipfile upload到AWS控制台 – 这样做并不容易！