430 lines
18 KiB
Markdown
430 lines
18 KiB
Markdown
---
|
|
title: Origin Cluster
|
|
sidebar_label: Origin Cluster
|
|
hide_title: false
|
|
hide_table_of_contents: false
|
|
---
|
|
|
|
# OriginCluster
|
|
|
|
The SRS origin cluster is a group of origin servers intended for handling a large number of streams.
|
|
|
|
The new origin cluster is designed as a collection of proxy servers that load balance and proxy to a
|
|
set of origin servers. For more information, see [Discussion #3634](https://github.com/ossrs/srs/discussions/3634).
|
|
If you prefer to use the old origin cluster, please switch to a version before SRS 6.0.
|
|
|
|
## Introduction
|
|
|
|
You can deploy multiple SRS origin servers, to handle a large number of streams. The proxy server is
|
|
used as a load balancer for these origin servers:
|
|
|
|
```text
|
|
+--------------------+
|
|
+-------+ SRS Origin Server +
|
|
+ +--------------------+
|
|
+
|
|
+-----------------------+ + +--------------------+
|
|
+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
|
|
+-----------------------+ + +--------------------+
|
|
+
|
|
+ +--------------------+
|
|
+-------+ SRS Origin Server +
|
|
+--------------------+
|
|
```
|
|
|
|
The origin cluster also enhances the scalability of the origin server. For instance, with 200 backend
|
|
SRS origin servers, it can support 100 WebRTC streamers, each with 200 viewers, totaling 20,000 connections.
|
|
If you deploy this cluster on a server with a large number of CPU cores, it becomes a very powerful
|
|
media server.
|
|
|
|
> Note: You are also able to deploy multiple proxy servers, or proxy to other media servers, or work
|
|
> with edge cluster, see [Design](#design) for details.
|
|
|
|
The proxy server support almost all protocols of SRS, including RTMP, HTTP-FLV, HLS, WebRTC, and SRT.
|
|
Please see [Protocols](#protocols) for details.
|
|
|
|
## Build
|
|
|
|
To build the proxy server, you need to have Go 1.18+ installed. Then, you can build the proxy
|
|
server by below command, and get the executable binary `./srs-proxy`:
|
|
|
|
```bash
|
|
git clone https://github.com/ossrs/proxy-go.git
|
|
cd proxy-go && make
|
|
```
|
|
|
|
> Note: You can also download the dependencies by running `go mod download` before building.
|
|
|
|
We will support the Docker image in the future, or integrate the proxy server into the Oryx
|
|
project.
|
|
|
|
## Legacy
|
|
|
|
From SRS 7.0+, the new Origin Cluster is based on proxy server, not the old MESH based SRS servers.
|
|
However, if you want to use the old origin cluster, you can switch to SRS 6.0.
|
|
|
|
## RTMP Origin Cluster
|
|
|
|
To use the RTMP origin cluster, you need to deploy the proxy server and the origin server.
|
|
First, start the proxy server:
|
|
|
|
```bash
|
|
env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \
|
|
PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \
|
|
PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./srs-proxy
|
|
```
|
|
|
|
> Note: Here we use the memory load balancer, you can switch to `redis` if you want to run more
|
|
> than one proxy server.
|
|
|
|
Then, deploy three origin servers, which connects to the proxy server via port `12025`:
|
|
|
|
```bash
|
|
./objs/srs -c conf/origin1-for-proxy.conf
|
|
./objs/srs -c conf/origin2-for-proxy.conf
|
|
./objs/srs -c conf/origin3-for-proxy.conf
|
|
```
|
|
|
|
> Note: The origin servers are independent, so it's recommended to deploy them as Deployments
|
|
> in Kubernetes (K8s).
|
|
|
|
Now, you're able to publish RTMP stream to the proxy server:
|
|
|
|
```bash
|
|
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
|
|
```
|
|
|
|
And play the RTMP stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay rtmp://localhost/live/livestream
|
|
```
|
|
|
|
Or play HTTP-FLV stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay http://localhost:8080/live/livestream.flv
|
|
```
|
|
|
|
Or play HLS stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay http://localhost:8080/live/livestream.m3u8
|
|
```
|
|
|
|
Or play the WebRTC stream via [WHEP player](http://localhost:8080/players/whep.html) from proxy server.
|
|
|
|
You can also use VLC or other players to play the stream in proxy server.
|
|
|
|
## WebRTC Origin Cluster
|
|
|
|
To use the WebRTC origin cluster, you need to deploy the proxy server and the origin server.
|
|
First, start the proxy server:
|
|
|
|
```bash
|
|
env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \
|
|
PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \
|
|
PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./srs-proxy
|
|
```
|
|
|
|
> Note: Here we use the memory load balancer, you can switch to `redis` if you want to run more
|
|
> than one proxy server.
|
|
|
|
Then, deploy three origin servers, which connects to the proxy server via port `12025`:
|
|
|
|
```bash
|
|
./objs/srs -c conf/origin1-for-proxy.conf
|
|
./objs/srs -c conf/origin2-for-proxy.conf
|
|
./objs/srs -c conf/origin3-for-proxy.conf
|
|
```
|
|
|
|
> Note: The origin servers are independent, so it's recommended to deploy them as Deployments
|
|
> in Kubernetes (K8s).
|
|
|
|
Now, you're able to publish WebRTC stream via [WHIP publisher](http://localhost:8080/players/whip.html) to the proxy server.
|
|
|
|
And play the WebRTC stream via [WHEP player](http://localhost:8080/players/whep.html) from proxy server.
|
|
|
|
Or play the RTMP stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay rtmp://localhost/live/livestream
|
|
```
|
|
|
|
Or play HTTP-FLV stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay http://localhost:8080/live/livestream.flv
|
|
```
|
|
|
|
Or play HLS stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay http://localhost:8080/live/livestream.m3u8
|
|
```
|
|
|
|
You can also use VLC or other players to play the stream in proxy server.
|
|
|
|
## SRT Origin Cluster
|
|
|
|
To use the SRT origin cluster, you need to deploy the proxy server and the origin server.
|
|
First, start the proxy server:
|
|
|
|
```bash
|
|
env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \
|
|
PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \
|
|
PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./srs-proxy
|
|
```
|
|
|
|
> Note: Here we use the memory load balancer, you can switch to `redis` if you want to run more
|
|
> than one proxy server.
|
|
|
|
Then, deploy three origin servers, which connects to the proxy server via port `12025`:
|
|
|
|
```bash
|
|
./objs/srs -c conf/origin1-for-proxy.conf
|
|
./objs/srs -c conf/origin2-for-proxy.conf
|
|
./objs/srs -c conf/origin3-for-proxy.conf
|
|
```
|
|
|
|
> Note: The origin servers are independent, so it's recommended to deploy them as Deployments
|
|
> in Kubernetes (K8s).
|
|
|
|
Now, you're able to publish SRT stream to the proxy server:
|
|
|
|
```bash
|
|
ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \
|
|
'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish'
|
|
```
|
|
|
|
And play the SRT stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request'
|
|
```
|
|
|
|
Or play the RTMP stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay rtmp://localhost/live/livestream
|
|
```
|
|
|
|
Or play HTTP-FLV stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay http://localhost:8080/live/livestream.flv
|
|
```
|
|
|
|
Or play HLS stream from the proxy server:
|
|
|
|
```bash
|
|
ffplay http://localhost:8080/live/livestream.m3u8
|
|
```
|
|
|
|
Or play the WebRTC stream via [WHEP player](http://localhost:8080/players/whep.html) from proxy server.
|
|
|
|
You can also use VLC or other players to play the stream in proxy server.
|
|
|
|
## Config
|
|
|
|
The proxy server is configured by environment variables. The supported environment variables for proxy
|
|
backend server are:
|
|
|
|
* `PROXY_HTTP_API`: The HTTP API port, proxy to SRS origin server. Default: `11985`
|
|
* `PROXY_HTTP_SERVER`: The HTTP streaming server, proxy to SRS origin server. Default: `18080`
|
|
* `PROXY_RTMP_SERVER`: The RTMP server, proxy to SRS origin server. Default: `11935`
|
|
* `PROXY_WEBRTC_SERVER`: The WebRTC server, proxy to SRS origin server, via UDP protocol. Default: `18000`
|
|
* `PROXY_SRT_SERVER`: The SRT server, proxy to SRS origin server. Default: `20080`
|
|
|
|
The following environment variables are about the proxy server itself:
|
|
|
|
* `PROXY_SYSTEM_API`: The system API port, allow origin server register services to proxy servers. Default: `12025`
|
|
* `PROXY_STATIC_FILES`: The files directory for static web server, like the players. Default: `../trunk/research`
|
|
* `PROXY_LOAD_BALANCER_TYPE`: The load balancer type, `memory` or `redis`. Default: `redis`
|
|
|
|
For the Redis load balancer, you need to set the following environment variables:
|
|
|
|
* `PROXY_REDIS_HOST`: The Redis host. Default: `127.0.0.1`
|
|
* `PROXY_REDIS_PORT`: The Redis port. Default: `6379`
|
|
* `PROXY_REDIS_PASSWORD`: The Redis password. Default to empty, no password.
|
|
* `PROXY_REDIS_DB`: The Redis DB. Default: `0`
|
|
|
|
For debugging, the proxy server will proxy to a default origin server, you can set the following
|
|
environment variables:
|
|
|
|
* `PROXY_DEFAULT_BACKEND_ENABLED`: Whether to enable the default backend origin server. Default: `off`
|
|
* `PROXY_DEFAULT_BACKEND_IP`: The default backend IP. Default: `127.0.0.1`
|
|
* `PROXY_DEFAULT_BACKEND_RTMP`: The default backend RTMP port. Default: `1935`
|
|
* `PROXY_DEFAULT_BACKEND_HTTP`: The default backend HTTP port. Default: `8080`
|
|
* `PROXY_DEFAULT_BACKEND_RTC`: The default backend WebRTC port via UDP. Default: `8000`
|
|
* `PROXY_DEFAULT_BACKEND_SRT`: The default backend SRT port. Default: `10080`
|
|
* `PROXY_DEFAULT_BACKEND_API`: The default backend API port. Default: `1985`
|
|
|
|
> Note: The default backend origin server, is designed for any RTMP server like nginx-rtmp, it does not
|
|
> require the origin server to register to the proxy server.
|
|
|
|
## Design
|
|
|
|
The proxy works with SRS origin servers, and the stream flow operates as follows:
|
|
|
|
```text
|
|
Client ----> Proxy Server ---> Origin Servers
|
|
Client ---> LB --> Proxy Servers --> Origin Servers
|
|
|
|
OBS/FFmpeg --RTMP--> K8s(Service) --Proxy--> SRS(pod A)
|
|
|
|
Browsers --FLV/HLS/SRT--> K8s(Service) --Proxy--> SRS(pod A)
|
|
|
|
Browsers --+---HTTP-API--> K8s(Service) --Proxy--> SRS(pod A)
|
|
+---WebRTC----> K8s(Service) --Proxy--> SRS(pod A)
|
|
```
|
|
|
|
> Note: This proxy server can be deployed in Kubernetes (K8s) and can route traffic to the SRS origin
|
|
> servers. The proxy server functions as a load balancer to distribute the load among the origin servers.
|
|
> You can also use the proxy server without Kubernetes.
|
|
|
|
This is the detailed deployment process that works with the Kubernetes (K8s) system:
|
|
|
|
```text
|
|
+-----------------------+
|
|
+---+ SRS Proxy(Deployment) +------+---------------------+
|
|
+-----------------+ | +-----------+-----------+ + +
|
|
| LB(K8s Service) +--+ +(Redis/MESH) + SRS Origin Servers +
|
|
+-----------------+ | +-----------+-----------+ + (Deployment) +
|
|
+---+ SRS Proxy(Deployment) +------+---------------------+
|
|
+-----------------------+
|
|
```
|
|
|
|
> Note: There are multiple proxy servers, so they need Redis or MESH to synchronize their state. MESH means
|
|
> the proxy servers connect to each other to sync the state and should be deployed as a StatefulSet in
|
|
> Kubernetes (K8s). The Redis solution is preferable because the proxy server can be deployed as a Deployment
|
|
> in K8s, and you can also use a Redis cluster for high availability.
|
|
|
|
> Note: There are multiple origin servers, which are deployed as Deployments in Kubernetes (K8s), as there is
|
|
> no need to sync the state between origin servers. These origin servers are completely independent, making
|
|
> the system very robust. Please note that this is different from the previous origin cluster before SRS 6.0,
|
|
> which used MESH to connect to each other, and it was not a good architecture.
|
|
|
|
If you want to build an origin cluster with a single proxy server and multiple origin servers:
|
|
|
|
```text
|
|
+--------------------+
|
|
+-------+ SRS Origin Server +
|
|
+ +--------------------+
|
|
+
|
|
+-----------------------+ + +--------------------+
|
|
+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
|
|
+-----------------------+ + +--------------------+
|
|
+
|
|
+ +--------------------+
|
|
+-------+ SRS Origin Server +
|
|
+--------------------+
|
|
```
|
|
|
|
> Note: A single proxy server architecture is also useful if you only want to support many streams with a
|
|
> small number of viewers. The proxy server is very high performance and supports multiple processes.
|
|
|
|
> Note: If you want to use multiple proxy servers, you can simply deploy more and connect them to the same
|
|
> Redis server. These proxy servers will work together to support a large number of streams. This architecture
|
|
> is scalable.
|
|
|
|
With this architecture, you can support a large number of streams and then use edge servers to support
|
|
multiple viewers.
|
|
|
|
```text
|
|
+------------------+ +--------------------+
|
|
+ SRS Edge Server +--+ +-------+ SRS Origin Server +
|
|
+------------------+ + + +--------------------+
|
|
+ +
|
|
+------------------+ + +-----------------------+ + +--------------------+
|
|
+ SRS Edge Server +--+-----+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
|
|
+------------------+ + +-----------------------+ + +--------------------+
|
|
+ +
|
|
+------------------+ + + +--------------------+
|
|
+ SRS Edge Server +--+ +-------+ SRS Origin Server +
|
|
+------------------+ +--------------------+
|
|
```
|
|
|
|
> Note: With this architecture, you can build a very large media system that supports a large number of
|
|
> streams and viewers. It is a complex system to maintain, so only use it if necessary.
|
|
|
|
In fact, a proxy server also works with SRS edge servers, but it is not a typical architecture.
|
|
|
|
## Protocols
|
|
|
|
Because the proxy server is a new server, not all protocols are supported yet. The supported
|
|
protocols are:
|
|
|
|
- [x] RTMP: Proxy RTMP protocol to the SRS origin server.
|
|
- [x] HTTP-FLV: Proxy HTTP-FLV protocol to the SRS origin server.
|
|
- [x] HTTP-TS: Proxy HTTP-TS protocol to the SRS origin server.
|
|
- [x] HLS: Proxy HLS protocol to the SRS origin server.
|
|
- [x] WebRTC: Proxy WebRTC(WHIP/WHEP) protocol to the SRS origin server.
|
|
- [x] SRT: Proxy SRT protocol to the SRS origin server.
|
|
- [ ] MPEG-DASH: Proxy MPEG-DASH protocol to the SRS origin server.
|
|
- [ ] RTSP: Proxy RTSP protocol to the SRS origin server.
|
|
|
|
There are also some key features not supported yet:
|
|
|
|
- [x] Single node proxy server, use memory to store state.
|
|
- [x] Redis: Connect to the Redis server to sync the state.
|
|
- [ ] MESH: Connect to other proxy servers to sync the state.
|
|
- [ ] HTTP-API: Provide an HTTP API that collects all the metrics of the origin servers.
|
|
- [ ] Exporter: Provide a Prometheus exporter that exports the metrics of the proxy server.
|
|
|
|
For a media cluster, the media server is only one part of the whole system. The control and management panel
|
|
are also very important to maintain this complex system.
|
|
|
|
## Register
|
|
|
|
The origin server can register itself to the proxy server, so the proxy server can load balance
|
|
the backend servers. The register API is a simple HTTP API:
|
|
|
|
```bash
|
|
curl -X POST http://127.0.0.1:12025/api/v1/srs/register \
|
|
-H "Connection: Close" \
|
|
-H "Content-Type: application/json" \
|
|
-H "User-Agent: curl" \
|
|
-d '{
|
|
"device_id": "origin2",
|
|
"ip": "10.78.122.184",
|
|
"server": "vid-46p14mm",
|
|
"service": "z2s3w865",
|
|
"pid": "42583",
|
|
"rtmp": ["19352"],
|
|
"http": ["8082"],
|
|
"api": ["19853"],
|
|
"srt": ["10082"],
|
|
"rtc": ["udp://0.0.0.0:8001"]
|
|
}'
|
|
#{"code":0,"pid":"53783"}
|
|
```
|
|
|
|
* `ip`: Mandatory, the IP of the backend server. Make sure the proxy server can access the backend server via this IP.
|
|
* `server`: Mandatory, the server id of backend server. For SRS, it stores in file, may not change.
|
|
* `service`: Mandatory, the service id of backend server. For SRS, it always changes when restarted.
|
|
* `pid`: Mandatory, the process id of backend server. Used to identify whether process restarted.
|
|
* `rtmp`: Mandatory, the RTMP listen endpoints of backend server. Proxy server will connect backend server via this port for RTMP protocol.
|
|
* `http`: Optional, the HTTP listen endpoints of backend server. Proxy server will connect backend server via this port for HTTP-FLV or HTTP-TS protocol.
|
|
* `api`: Optional, the HTTP API listen endpoints of backend server. Proxy server will connect backend server via this port for HTTP-API, such as WHIP and WHEP.
|
|
* `srt`: Optional, the SRT listen endpoints of backend server. Proxy server will connect backend server via this port for SRT protocol.
|
|
* `rtc`: Optional, the WebRTC listen endpoints of backend server. Proxy server will connect backend server via this port for WebRTC protocol.
|
|
* `device_id`: Optional, the device id of backend server. Used as a label for the backend server.
|
|
|
|
The listen endpoint format is `port`, or `protocol://ip:port`, or `protocol://:port`, for example:
|
|
|
|
* `1935`: Listen on port 1935 and any IP for TCP protocol.
|
|
* `tcp://:1935`: Listen on port 1935 and any IP for TCP protocol.
|
|
* `tcp://0.0.0.0:1935`: Listen on port 1935 and any IP for TCP protocol.
|
|
* `tcp://192.168.3.10:1935`: Listen on port 1935 and specified IP for TCP protocol.
|
|
|
|
You can also use SRS 5.0+ as backend server, which supports `heartbeat` feature to register itself
|
|
to proxy server.
|
|
|
|
Furthermore, you can write a curl script to register the backend server, or a dedicate backend server
|
|
manage service. For example, if you don't want to modify the nginx-rtmp code, you can use a isolate program
|
|
to register the nginx-rtmp to proxy server.
|
|
|
|
|
|
|