预算有限的 Magento 托管

Question

我必须为 Magento 进行设置。我的限制主要是易于设置和容错/故障转移。此外，成本也是一个问题。我有三个相同的物理服务器来完成工作。每个服务器节点在软件 RAID 1 配置中都有一个 i7 四核、16GB RAM 和 2x3TB HD。每个节点都运行 Ubuntu 12.04。马上。我有一个额外的 IP 地址，可以路由到这些节点中的任何一个。

Magento 商店有最大。1000个产品，其中50%是捆绑产品。我估计最大。10 个用户同时处于活动状态。这使我得出结论，性能不是这里的重中之重。

我的第一个设置想法

一个节点 (lb) 将 nginx 作为负载均衡器运行。附加 IP 与域名一起使用并默认路由到此节点。Nginx 将负载平均分配给其他两个节点（shop1、shop2）。Shop1 和 shop2 配置相同：每个服务器运行 Apache2 和 MySQL。Mysqls 配置了主/从复制。

我的故障转移策略：

• Lb 失败 => 将 IP 路由到 shop1（MySQL 主站），继续。
• Shop1 失败 => Lb 将自动处理，将 shop2 上的 MySQL 从站提升为 master，重新配置 Magento 以使用 shop2 进行写入，继续。
• Shop2 失败 => Lb 会自动处理，继续。

这是一个明智的策略吗？有没有人用 Magento 做过类似的设置？

我的第二个设置想法

另一种方法是使用 drbd 将 MySQL 数据文件存储在 shop1 和 shop2 上。我知道在这种情况下，只有一个节点/MySQL 实例可以处于活动状态，另一个用作热备用。因此，如果 shop1 失败，我会在 shop2 上启动 MySQL，将 IP 路由到 shop2，然后继续。我喜欢这样，因为 MySQL 设置更容易，并且节点可以配置为 99% 相同。所以在这种情况下负载平衡器变得无用，我有一个备用服务器。

我的第三个设置想法

第三种方式可能是 MySQL 数据库的 master-master 复制。但是，在我的选择中，这可能很棘手，因为 Magento 不是为这种情况构建的（例如，新行的 id 冲突）。在我听说过一个可行的例子之前，我不会这样做。

你能给我建议走哪条路吗？似乎没有一种“好”的方法可以做到这一点。例如，我阅读了描述 Magento 的 MySQL 主/从设置的博客文章，但在我读到的其他地方，当从设备落后于主设备时，数据可能会重复（例如，下订单时，客户可能会被创建两次）。我有点迷失在这里。

Answer 1

吻

保持简单愚蠢。

我有点迷失在这里。

正是出于这个原因，不要开始将不需要复杂的东西变得过于复杂。如果您不知道在第一个实例中实现某些东西的正确方法 - 当出现问题时，您肯定不知道该怎么做。

首先，让我们解决硬件问题

参考：https : //www.sonassihosting.com/help/magestack/cpu-sizing/

a) 标准的 Magento 演示商店能够在每小时每 GHz 提供大约 230 个唯一身份。

b) 一个典型的网络商店，具有管理员用户活动、开发活动、产品添加/删除可以看到这种下降大约 100%，达到每小时 115 个唯一身份/GHz。

使用您在任何给定时间的 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 名独立访问者的数字，或每天大约7,500 名独立访问者。

要以 115 个唯一身份/GHz 的速度支持每小时 750 名访问者 - 您需要相当于 7 个 1GHz CPU 内核。因此，让我们假设您的 i7 Quad Core 为 2.5GHz - 累计总频率为 10GHz。

其次，让我们解决您的配置

你的目标是什么？

1. 高可用性
2. 可靠性
3. 管理简单
4. 表现
5. 可扩展性

你的想法都不是特别好，你的负载均衡器是一个单点故障，我觉得你有点过于关注 MySQL 冗余了。

Master-Master 是配置噩梦，你这样做没有任何好处。Magento 丝毫不受 MySQL 的约束。看看我应该把哪个放在更大的机器上？Magento 数据库的 Magento 网络服务器？

除非您打算使架构中的所有内容变得多余，即。

1. 绑定网络接口
2. A+B 开关
3. A+B 防火墙
4. A+B 将来自不同 UPS 的电源分开
5. 多宿主上行连接

...尝试在软件层建立一些弹性并没有多大意义。

我们将如何做

有没有人用 Magento 做过类似的设置？

一句话。是的。

我们n在 MageStack 中配置从单个服务器到服务器的任何内容 - 通过容器化每个节点。

因此，在您的情况下，我们通常会设置以下内容（假设您请求 HA）。

**Server 1**        **Server 2**        **Server 3**
LB  (m)    <==>     LB  (s)             
Web (m)             Web (m)             Web (m)
                    DB  (s)    <==>     DB  (m)

LB 和 DB 虚拟服务器的根分区位于 DRBD 镜像（由 表示<==>）上。Web 节点将使用公共 NFS 存储，或者更常见的是，使用实时 Web 节点上的 repo pull。

只是为了参考这里的回复如何使用 Varnish 安排 Web 服务器？

我们的典型架构是

lvs (initial ssl load balancing)
 -> pound (ssl-unwrapping) 
 -> varnish (caching) 
 -> haproxy (load balancing) 
 -> nginx (static content) 
 -> php (dynamic content) 
 -> mysql (db)

Heartbeat 将维护机器之间的健康检查，并提供 IP 故障转移和启动/停止相应的虚拟服务器。

所以最终的容器化架构看起来像这样......（原谅这个图形，我从营销 PDF 中挖出来的）。

我会建议你怎么做

不要使用主/从，不要使用 DRBD 并保持它非常非常简单 - 这样当事情不工作时，您可以轻松管理和调试。

**Server 1**        **Server 2**        **Server 3**
LB                           
Web                 Web                 Web 
                                        DB  

这样，您就可以获得负载分配和硬件的充分利用。最坏的情况 - 如果服务器 1 或服务器 3 出现故障 - 然后您拔出硬盘驱动器并将它们放在服务器 2 中。在 DC 上使用远程手 - 这可以在大约 5 分钟内完成。这将是一个更易于管理的该死的站点，这意味着您不必制作有关机器配置和运行手册程序的 30 页文档，并且设置所需的时间将大大减少。

我们的服务器的正常运行时间超过 3 年 - 因此应该考虑服务器级设备出现故障的频率。通常情况下，服务器出现问题的最常见原因完全归结为不可靠的软件配置。

我唯一担心的是你的硬件不是服务器级的——所以你可能会冒更高故障率的风险——但是你选择使用它的风险。

总之

我不建议尝试自己为电子商务商店构建、管理和监督服务器配置，其中托管和支持是保持业务在线的最重要的部分。