【问题标题】:No single point of failure with Thingsboard and CassandraThingsboard 和 Cassandra 没有单点故障
【发布时间】:2021-04-19 12:36:41
【问题描述】:

我已经有一些关于 Thingsboard 设置的经验,但直到现在我只使用独立场景部署它。一个带有 Postgres(混合设置)的 Thingsboard 实例 - 一个 Cassandra。

我想做的是创建一个无单点故障安装。

我的想法是使用 HAproxy 在两个 Thingsboard 实例之间切换,并让两个 Cassandra 实例具有完全相同的数据。

有可能吗?如果是那怎么办?

https://pasteboard.co/JJNhbON.png

我想做什么的简单图表。

提前致谢!

【问题讨论】:

    标签: cassandra haproxy thingsboard


    【解决方案1】:

    就个人而言,我会通过为 Cassandra 部署多个 DC 来简化存储层,每个 Thingsboard 实例将流量路由到自己的 Cassandra DC。使用这种设计,您不必担心必须保持两个不同的 Cassandra 集群同步。

    HA 代理可以简单地将流量转移到正在运行的 Thingsboard 实例。干杯!

    【讨论】:

    • 首先感谢您花时间回答。我理解你关于HAproxy分流的观点,这是我想使用它的主要原因。但是我将如何确保每个人都可以根据您的建议访问所有数据。也许我没有完全理解(最可能的情况)。您能否制作一个简单的图表,以便我更好地可视化您的解决方案?提前致谢! PS我在问题的链接中稍微更改了图表
    【解决方案2】:

    没有单点故障配置是:

    1. Zookeeper 集群 - 3 个节点
    2. Kafka 集群 - 3 个节点
    3. Cassandra 集群 - 3 个节点
    4. PostgreSQL 集群 - 2 个节点(主/从)+ PgPool 1 个节点
    5. Redis 集群 - 3-6 个节点
    6. Thingsboard - 2 个节点(可用作单体或微服务)
    7. 负载平衡器(HAproxy 或其他)

    这将带来真正的容错和水平扩展的能力。您可以启动 Kubernetes 集群来轻松管理它。如果您的负载不重,您可以使用 Docker-compose 或 Kubernetes 共享 CPU 资源。在不同的机架中至少需要 3 台物理机。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2013-04-25
      • 2015-03-21
      • 2017-12-19
      • 1970-01-01
      • 2016-03-19
      • 2018-01-23
      • 2012-04-20
      • 2019-07-21
      相关资源
      最近更新 更多