![如何为两个相同的 Icecast 主服务器设置自动故障转移反向代理?](https://linux22.com/image/671910/%E5%A6%82%E4%BD%95%E4%B8%BA%E4%B8%A4%E4%B8%AA%E7%9B%B8%E5%90%8C%E7%9A%84%20Icecast%20%E4%B8%BB%E6%9C%8D%E5%8A%A1%E5%99%A8%E8%AE%BE%E7%BD%AE%E8%87%AA%E5%8A%A8%E6%95%85%E9%9A%9C%E8%BD%AC%E7%A7%BB%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86%EF%BC%9F.png)
我正在尝试做简单的事情一切都在前面有反向代理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 个并发监听者。测试实际上表明,它的扩展能力远远超出这个范围,但可能存在一些极端情况。
然后问问自己:我真正想解决的可用性问题是什么而问题的答案很可能不是“反向代理”。