☰

吻

tag-icon • tag-icon failover drbd magento master-slave master-master
吻

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

Magento 商店最多有 1000 种产品，其中 50% 是捆绑产品。我估计最多有 10 个用户同时处于活动状态。这让我得出结论，性能在这里并不是首要任务。

我的第一个设置想法

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

我的故障转移策略：

  • Lb 失败 => 将 IP 路由到 shop1 (MySQL 主服务器)，继续。
  • Shop1 失败 => Lb 会自动处理，将 shop2 上的 MySQL 从属服务器提升为主服务器，重新配置 Magento 以使用 shop2 进行写入，然后继续。
  • Shop2 失败 => Lb 将自动处理，并继续。

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

我的第二个设置想法

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

我的第三个设置想法

第三种方法可能是 MySQL 数据库的主主复制。但是，在我看来，这可能比较棘手，因为 Magento 不是为这种情况构建的（例如新行的 ID 冲突）。除非我听说了一个可行的示例，否则我不会这么做。

您能给我一个建议，告诉我应该遵循哪条路线吗？似乎没有一种“好”的方法。例如，我读过一些博客文章，其中描述了 Magento 的 MySQL 主/从设置，但我在其他地方读到，当从服务器落后于主服务器时，数据可能会重复（例如，下订单时，客户可能会被创建两次）。我有点迷茫了。

答案1

吻

保持简单愚蠢。

我有点迷路了。

正是出于这个原因，不要开始把本来不需要复杂的事情变得过于复杂。如果你一开始就不知道正确的方法来实现某件事——当出现问题时，你当然不知道该怎么做。

首先，让我们来讨论一下硬件

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

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

b) 一个典型的网上商店，包括管理员用户活动、开发活动、产品添加/删除，可以看到这一数字下降了大约 100%，即每 GHz 每小时 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每小时独立访客数，或大约7,500每日独立访客。

要支持每小时 750 名访客，即 115 个独立访客/GHz，您需要相当于 7 个 1GHz CPU 核心。因此，假设您的 i7 四核为 2.5GHz，那么累计总数将达到 10GHz。

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

你的目标到底是什么？

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

您的想法都不是特别好，您的负载均衡器是单点故障，我觉得您有点过于陷入 MySQL 冗余。

Master-Master 的配置简直是噩梦，而且你必须不这样做有好处。Magento 丝毫不受 MySQL 的约束。看我应该把哪个放在我的大型机器上？Magento Web 服务器还是 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 布置网络服务器？

我们的典型架构是

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

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

因此最终的容器化架构看起来会像这样...（请原谅这张图，是我从营销 PDF 中截取的）。

MageStack 示例配置

我建议你如何做

不要使用主/从，不要使用 DRBD，只是保持它的真正简单 - 这样当事情不起作用时您就可以轻松管理和调试。

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

这样，您就可以实现负载分配并充分利用硬件。最坏的情况是 - 如果服务器 1 或服务器 3 发生故障 - 那么您可以取出硬盘并将其放入服务器 2。使用 DC 的远程人员 - 这可以在大约 5 分钟内完成。这将是一个非常易于管理的站点，这意味着您不必制作一份 30 页的有关机器配置和运行手册程序的文档，并且设置所需的时间将大大减少。

我们的服务器正常运行时间超过 3 年 - 因此应该了解服务器级设备发生故障的频率。通常情况下，服务器出现问题的最常见原因纯粹是软件配置不当。

我唯一担心的是您的硬件不是服务器级别 - 因此您可能会面临更高故障率的风险 - 但您选择使用它来承担风险。

总之

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

答案2

单个服务器？

我永远不会推荐包含 SPoF（单点故障）的电子商务解决方案

值得一提的是，我目前正在编写亚马逊 Elastic Beanstalk 服务的设置指南，它将允许您自动扩展所有维度，同时只需为您实际使用的资源付费。

当然，它是多区域的，并且具有内置的冗余和故障转移功能:)

维护非常简单 - 您可以直接使用 AWS 命令​​行工具和 git 来更新您的 Magento，也可以将您的 Magento 应用程序的 zip 上传到 AWS 控制台 - 没有比这更简单的了！

相关内容