![吻](https://linux22.com/image/596659/%E5%90%BB.png)
我必须为 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。
其次,让我们解决你的配置
你的目标到底是什么?
- 高可用性
- 可靠性
- 管理简单
- 表现
- 可扩展性
您的想法都不是特别好,您的负载均衡器是单点故障,我觉得您有点过于陷入 MySQL 冗余。
Master-Master 的配置简直是噩梦,而且你必须不这样做有好处。Magento 丝毫不受 MySQL 的约束。看我应该把哪个放在我的大型机器上?Magento Web 服务器还是 Magento 数据库?
除非您计划让架构中的所有内容都变得冗余,否则。
- 绑定网络接口
- A+B 开关
- A+B 防火墙
- A+B 独立供电,来自不同的 UPS
- 多宿主上行连接
... 尝试在软件层构建一些弹性是没多大意义的。
我们将如何做
有人用 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 中截取的)。
我建议你如何做
不要使用主/从,不要使用 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 控制台 - 没有比这更简单的了!