See Part 1, Part 2, and Part 3.
Let’s start with a quick refresher of some key services and databases that need to be available to all installations:
- Core database (SQL or Oracle)
- Analytics (Mongo)
- Tracking.Live (Mongo)
- Sitecore_Analytics_Index (Solr)
- If we assume Content Delivery is in a DMZ and all other Sitecore functions are “behind the firewall”, the following diagram gives a visual overview of which databases should be closer to the various Sitecore roles and network zones. Blue databases icons are relational (SQL/Oracle) and green are Mongo collections.
On the left is the LAN or internal network which would house management functions and databases used solely by the management functions. In the center area is a SECURED zone that is shared with the internal network and the DMZ. The DMZ is on the right.
The assumption in this depiction is that anything in the LAN can communicate with SECURED AND DMZ.
In cases where content delivery is distributed across multiple data centers, the web and session databases will be created in each data center.
How you now choose to deploy this logical diagram is a question of assessing complexity and available budget vs security, performance and availability requirements. A single instance of SQL/Oracle and Mongo could be placed in the SHARED zone and serve all needs, or at the other extreme there is an actual database instance for each database/collection. The following diagram shows the simple example. The other extreme case described would be the same depiction as the previous diagram – just with servers instead of databases.
The most common model we see is:
- SQL Server / Oracle cluster located in SECURE that holds Master, Core, Reporting.
- SQL Server / Oracle cluster located in DMZ that holds Web, Session (and maybe replica of CORE).
- Mongo replica set located in SECURE for Analytics, Tracking.History, Tracking.Live, Tracking.Contact.
In our next post, we will turn to another option we have yet to discuss, xDB Cloud.
