Multiple chirpstack component deploy

ChirpStack (v4)
1

Dear all,

I ran the entire chirpstack v4 stack using docker compose，here are part of docker-compose.yml file i modify.

chirpstack:
    image: chirpstack/chirpstack:latest
    command: -c /etc/chirpstack
    restart: unless-stopped
    volumes:
      - ./configuration/chirpstack:/etc/chirpstack
      - ./lorawan-devices:/opt/lorawan-devices
    depends_on:
      - postgres
      - mosquitto
      - redis
    environment:
      - MQTT_BROKER_HOST=mosquitto
      - REDIS_HOST=redis
      - POSTGRESQL_HOST=postgres
    ports:
      - 8080:8080
      - 9090:9090

  chirpstack2:
    image: chirpstack/chirpstack:latest
    command: -c /etc/chirpstack
    restart: unless-stopped
    volumes:
      - ./configuration/chirpstack:/etc/chirpstack
      - ./lorawan-devices:/opt/lorawan-devices
    depends_on:
      - postgres
      - mosquitto
      - redis
    environment:
      - MQTT_BROKER_HOST=mosquitto
      - REDIS_HOST=redis
      - POSTGRESQL_HOST=postgres
    ports:
      - 8088:8080
      - 9098:9090

Once I have a large number of gateways and sensors, and send data (via udp or mqtt) to server.

  1. As shown above, I use the same configuration file (chirpstack.toml) to start two chirpstack component programs A and B, when there is uplink data coming in, will both A and B process the (same) data?
  2. I hope chirpstack can carry more sensors and gateways. Do I need to load balance the chirpstack component (https://github.com/chirpstack/chirpstack), such as letting some data be processed by A and some by B?

Best regards

2

Chirpstack uses a “shared MQTT subscription” so that multiple Chirpstack instances can be connected to the same broker and events will be distributed between them. So no they will not process the same data.

For gRPC requests and web interface traffic it is a good idea to use a load balancer + multiple Chirpstack intances. But then the bottle neck becomes the actual databases and MQTT backhaul themselves (postgres, redis, mqtt)

1 Like
3

When using chirpstack v3, I often encounter the problem Redis: connection pool timeout (code: 2). Related to (Redis: connection pool timeout (code: 2))
After checking, I found it due to application-server too busy that AS did not release the redis connection in time, actually, I checked redis itself and it was working properly.

For these reason and To keep migration(v3 → v4) easy, I upgraded to chirpstack v4, and try to deployed multiple chirpstack components to avoid this problem.

So the various instances of chirpstack can work together to process more data, but the subsequent bottleneck will be mqtt, redis and postgres. Is it right?

Thank you very much for your patient and prompt response, it helped me a lot.

4

This should be much less of an issue in V4, there have been many performance improvements since V3 that reduce Chirpstack overhead.

Yup, thats correct. Although I have never done serious stress tests of Chirpstack before, likely they would only actually become a bottle neck in networks of thousands of devices, but in theory once you spin up multiple Chirpstack instances you should look to the databases and backhaul next to improve throughput and performance.

1 Like
5

I understand now, thank you for your enthusiastic response.

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.