☰

如何为两个相同的 Icecast 主服务器设置自动故障转移反向代理？

tag-icon • tag-icon nginx haproxy high-availability streaming icecast
如何为两个相同的 Icecast 主服务器设置自动故障转移反向代理？

我正在尝试做简单的事情一切都在前面有反向代理Icecast 主流媒体服务器的高可用性（即我这里不讨论 Icecast 中继）。因此，三台虚拟机：

  • 2 个相同的独立 Icecast VM（每个都带有本地 MPD 音乐源和本地 nginx 前端，用于正确的标题）
  • 单个负载均衡器/反向代理 nginx VM。

我的问题是 –如果其中一个 Icecast VM 发生故障，并且对流客户端的中断尽可能少，我该如何配置反向代理来执行自动故障转移？

插图：

                             /--- [ local nginx A <-> icecast master A <- mpd A]
-> [nginx reverse proxy] ---<
                             \--- [ local nginx B <-> icecast master B <- mpd B]

我第一次尝试这个简单的教程设置反向代理 nginx，之后我可以通过打开 nginx VM 来监听流。

upstream backend  {
  ip_hash; # try to send the same clients to the same servers
  server 1.2.3.4;
  server 1.2.3.5 max_fails=1  fail_timeout=15s;
}
server {
  location / {
    proxy_pass  http://backend;
  }
}

但是，当我在作为最终端点的 Icecast VM 上停止 Icecast 服务时，客户端不会故障转移到好的 Icecast。出于某种原因，即使在刷新后也不会。我尝试使用各种ip_hash、、选项、不同的响应头属性、缓冲区大小等进行实验max_fails。fail_timeout其他 站点 提及，但什么都没起作用。我感觉有点像在黑暗中摸索，考虑到那里有这么多受欢迎的广播电台，应该有一些明显的流媒体故障转移解决方案。有没有关于如何最好地设置它的建议或一些好的资源？我想要 302 重定向还是真正的代理通行证？

如果 HAProxy 是更好的选择，我愿意接受基于 HAProxy 的建议。

答案1

正如您所发现的，反向代理 Icecast 不是一个好主意。它没有真正的好处，同时还存在一些缺点，并且您仍然有一个单点故障：您的前端。

Icecast 是一个非常稳定和可靠的服务器，通过 HTTP 提供网页的典型策略不一定适用于它。

您可能最好花些精力去了解 Icecast、它的配置和限制。也就是说，如果配置正确，Icecast 可以轻松满足 1 GBit/s 的连接需求，并服务超过 20,000 个并发监听者。测试实际上表明，它的扩展能力远远超出这个范围，但可能存在一些极端情况。

然后问问自己：我真正想解决的可用性问题是什么而问题的答案很可能不是“反向代理”。

相关内容