0

We have 3 DMZ zones in which we have setup our xConnect XP topology.

  • Zone A - Processing on one machine; - Reporting on one machine; - Collection, Collection Search, MA, MA Rep, Ref data on one machine; - DB server A
  • Zone B - same topology, DB server B
  • Zone C - same topology, DB server C

CDs are in DMZ as well CM machine is stored in the internal network.

My question is to which of the xConnect zones will the CM have to connect ?

2

There can be only one

If I misunderstood the above statement and you actually have 3 completely separate xDB collection databases, then you might be having a harder time as that is not a supported scaling model for the xDB database in 9.0 and 9.1

Here is the horizontal scaling documentation: https://doc.sitecore.com/developers/90/platform-administration-and-architecture/en/scale-horizontally.html

It's all the same to xDB

However, if you are running a supported model with a single xDB collection database, you should be fine. Ultimately, regardless of the number of zones, there is only one xDB behind xConnect so whichever xConnect you connect to will get the same data because you are connecting to the same underlying data store.

Searching against the index

From an indexing perspective, any calls that trigger searches against the xDB Search Index could be impacted depending on how you have decided to scale your indexing. However, in a typical setup, all your indexing endpoints have the same indexes in them so effectively your lookups should behave the same regardless of the xConnect endpoint.

Remember that there is only one xConnect Search Indexer. From the docs:

Although it is possible to scale out the xConnect Search service, there can only be one instance of the xConnect Search Indexer. In Microsoft Azure, the indexer web job is automatically configured to run on one instance with the ability to fail over to another instance.

Keep impact low

I would recommend having CM connect to whichever zone is going to have the least impact to your content delivery endpoints. While the likelihood of your xConnect requests from CM causing a performance hit is low, if you have a choice, that would be how to go.

  • What about if we have the databases replicated from one db server to another? – Aura Petric May 21 at 15:22
  • You could replicate xDB, I suppose, from one zone to another, but that would mean that your non-primary xConnects couldn't do writes to their respective DBs and would be writing to the primary DB, which then replicates down. At which point, again, your CM can connect to any xConnect because they all are writing to the same primary xDB. I'm not certain that type of replication is supported for production environments, though, with xDB, but in any case, you are still coming down to "one writeable xDB" – Jason St-Cyr May 21 at 16:19
  • One question has come into my mind, if each zone points to its dedicated Solr cloud URL, would this be an issue? – Aura Petric May 22 at 11:56
  • This would again come down to how you are doing the xDB indexing. There is only one xConnect Search Indexer, it does not support horizontal scaling. Therefore you would only be updating one index endpoint. – Jason St-Cyr May 22 at 16:46
  • In general, if you want to avoid pitfalls, have a single Solr endpoint (you can have a cloud for high availability and DR) and have a single xDB database (you can use multiple shards) and then scale everything else. – Jason St-Cyr May 22 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.