Star Pattern
Star Pattern
Also known as the "hub and spoke model" (like a wagon wheel), the star deployment pattern uses a single central server from which additional servers pull components. Using a star deployment pattern helps conserve bandwidth while making components available across geographical regions. The example star pattern above has only two points, but you can expand this pattern to as many points as you need.
In a star pattern, you have a primary region ("Region A" in the example above) with a primary Sonatype Nexus Repository instance (node). This is where all writes happen.
Developers in another region ("Region B" in the example above) may need access to the components in region A. Whether they are pulling things into their IDEs or pulling containers, you save bandwidth between regions A and B by setting up a cache. Do this by standing up a Sonatype Nexus Repository instance that is primarily focused on proxying the node in region A.
You might also have non-human consumers such as highly secured production deployments that need to pull directly from a local cache as shown in the section called "Region C" in the example above.
The star pattern provides great content availability and access speed while saving bandwidth.
Combines With
Make your primary node a cluster and combine this pattern with one of the following:
Create a disaster recovery site for your primary node and combine this pattern with Disaster Recovery Site
Ensure you have perfected the Backup/Same-Site Restore pattern before combining it with more advanced patterns like this one
Problems Addressed
- Read intensive traffic across geographical regions (on-prem/cloud)
- Improves content availability and access speed (for reads)
Prerequisites
- Resilient network connectivity between the primary and proxy Sonatype Nexus Repository instances (nodes)
- Common DNS name can ensure low-network latency
Factors to Consider
- Must maintain corresponding repository structures between primary and proxy nodes