This post is intended to cover the VCAP design objective around mapping service dependencies. At the time of writing, the required ‘Skills and Abilities’ listed by VMware for this topic are:
- Evaluate dependencies for infrastructure and application services that will be included in a vSphere design
- Create Entity Relationship Diagrams that map service relationships and dependencies
- Analyze interfaces to be used with new and existing business processes
- Determine service dependencies for logical components
- Include service dependencies in a vSphere 6.x Logical Design
- Analyze services to identify upstream and downstream service dependencies
- Navigate logical components and their interdependencies and make decisions based upon all service relationships
Evaluate dependencies for infrastructure and application services that will be included in a vSphere design
There are two areas to look at here – the first are the dependencies required for the infrastructure that we are designing, for example, ESXi has a dependency on shared storage and NTP. Be aware of the dependency requirements of everything that is included in the design.
The other part is knowing the dependencies of the applications and services that will run on the solution we are designing for. A common example would be a three tiered application with a web server, application server and database server. It’s important to be aware of these relationships as they will influence design decisions. For example, a decision may be made to use anti-affinity rules to ensure load-balanced web servers are never running on the same ESXi host.
The sorts of questions we should be asking here are – What systems are communicating with each other? How are they communicating – what ports/protocols? Are there load balancers, firewalls? And so on. There are also likely to be a number of common systems that multiple other systems rely on such as DNS, NTP and Active Directory.
Create Entity Relationship Diagrams that map service relationships and dependencies
This leads on from the previous section. Whilst gathering data on relationships and dependencies it’s useful to map these using entity relationship diagrams. More info on entity relationship diagrams here.
Determining the dependencies will initially come out of the discussions held with the relevant stakeholders, and is often followed by running dependency mapping tools such as vRealize Infrastructure Navigator, along with manual checks. It’s important to understand the dependencies, as the design is ultimately there to support these services. Going back to the three tier web application example in more detail, the dependencies may look something like this:
[table id=3 /]
Analyze interfaces to be used with new and existing business processes
This again is about understanding how systems interact. There is a good overview of interface analysis here. Tools can help with understanding how existing systems interact, for example doing application discovery and dependency mapping using vRealize Operations.
Determine service dependencies for logical components and Include service dependencies in a vSphere 6.x Logical Design
Having collected the dependency details during the previous phases we can start to build them into the logical design. Once we know what a given component requires we can create the dependency mapping for it, in the correct order to include in the design.
Analyze services to identify upstream and downstream service dependencies, and Navigate logical components and their interdependencies and make decisions based upon all service relationships
This is understanding what upstream or downstream services a given component is dependent on, and what the impact is if there is a failure in an upstream or downstream service. This understanding can feed into the design in the form of start up /shutdown orders, vSphere HA options and affinity/anti-affinity rules for example.
There is a lot of overlap between these topics, but in a nutshell it’s about the need to be able to map and understand the dependencies of the systems in scope in order to be able to make the appropriate design decisions. For further reading, there’s a great article here, which has an excellent example of an entity relationship diagram.