Redundancy Installation

[pshashipreetham]

Hi,

I am trying to do a Thingworx Redundancy Installation, and below is my Arch:

• Is there a need to have two Influx DBs and Postgres DBs?
• Can we connect two Thingworx Instances to a single Azure Postgres SQL and Influx DB?

Thanks,

[VladimirRosu]

Hi Shashi,

When you mentioned a "ThingWorx Redundancy Installation" what exactly is that?

If I look at what's here, the architecture makes me think of ThingWorx High Availability, but there are a number of components missing in order to work in HA.

Note that one Kepware instance can only connect to a single ThingWorx instance, so I believe there is something missing from this architecture.

1. Regarding the need of two Influxes. I do not know where that derives from. If you would be using ThingWorx HA, that would be connected to a single Influx DB instance (whether that is OSS or the InfluxDB Enterprise, which can indeed consist of multiple instances, it's another discussion)

2. Two TW instances can connect to a single Azure Postgres SQL instance, and also to a single Influx DB, but I don't think this is what you needed to know. I am guessing you want to know if they can connect to the same Database in a PostgreSQL instance, and the answer is no in this case. You need to define separate Databases in that PostgreSQL instance to have two ThingWorx instances connect to it (except if you use ThingWorx HA). The same applies for InfluxDB.

[pshashipreetham]

Hi @VladimirRosu ,

No, the Customer is not looking for a HA Development. The present Arch is simple for us, like below:

KepServerEx --> Thingworx --> Influx & Postgres.

But the load is very high as of now, We are doing 4448 Reads from KepServerEX and doing the 4448 to Influx, this is putting lots of load on the Thingworx.

So, to reduce the load, I built an arch like that. Just Checking If two Thingworx Can do a write to a single DB.

I am trying to achieve to achieve something like this, but based on the customer use case

Link: ThingWorx Deployment Architectures (ptc.com)

Thanks,

[VladimirRosu]

Some questions (assuming the 4448 is Property Writes per Second):

1. Are you 100% sure that the load is on the ThingWorx side?

2. What exactly do you see (CPU, IO, RAM usage)?

3. What are the specs of the ThingWorx machine?

4. Have you disabled persistence for the frequent changing properties?

The CX server's role in the diagram above is to multiplex multiple TCP sockets into a single one, therefore easing up ThingWorx's machine task of handling TCP sockets.

Two ThingWorx instances can not write at the same time to a single PostgreSQL database.