By Gabor Karakas
Data centers are wildly complicated in nature and grow in an organic fashion, which fundamentally means that very few people in the organization understand the IT landscape in its entirety. Part of the problem is that these complex ecosystems are built up over long periods of time (5–10 years) with very little documentation or global oversight; therefore, siloed IT teams have the freedom to operate according to different standards – if there are any. Oftentimes new contractors or external providers replace these IT teams, and knowledge transfer rarely happens, so the new workforce might not understand every aspect of the technology they are tasked to operate, and this creates key issues as well.
Migration or consolidation activities can be initiated due to a number of reasons:
- Reduction of the complexity in infrastructure by consolidating multiple data centers into a single larger one.
- The organization simply outgrew the IT infrastructure, and moving the current hardware into a larger data center makes more sense from a business or technological perspective.
- Contract renegotiations fail and significant cost reductions can result from moving to another provider.
- The business requires higher resiliency; by moving some of the hardware to a new data center and creating fail-proof links in between the workloads, disasters can be avoided and service uptime can be significantly improved.
When the decision is made to move or consolidate the data center for business or technical reasons, a project is kicked off with very little understanding into the moving parts of the elements to be changed. Most organizations realize this a couple of months into the project, and usually find the best way forward is to ask for external help. This help usually comes from the joint efforts of multiple software and consultancy firms to deliver a migration plan that identifies and prioritizes workloads, and creates a blueprint of all their vital internal and external dependencies.
A migration plan is meant to contain at least the following details of identified and prioritized groups of physical or virtual workloads:
- The applications they contain or serve
- Core dependencies (such as NTP, DNS, LDAP, Anti-virus, etc.)
- Capacity and usage trends
- Contact details for responsible staff members
Any special requirements that can be obtained either via discovery or by interviewing the right people
In reality, creating such a plan is very challenging, and there can be many pitfalls. The following are common problems that can surface during development of a migration plan:
Technical Problems
It is vital that communication is strong between all involved, technical details are not overlooked, and all information sources are identified correctly. Issues can develop such as:
- · Choosing the right tool (VMware Application Dependency Planner as an example)
- · Finding the right team to implement and monitor the solution
- · Reporting on the right information, which can prove difficult
Technical and human information sources are equally important, as automated discovery methods can only identify certain patterns; people need to put the extra intelligence behind this information. It is also important to note that a discovery process can take months, during which time the discovery infrastructure needs to function at its best, without interruption to data flows nor appliances.
Miscommunication
As previously stated, team communication is vital. There is a constant need to:
- Verify discovery data and tweak technical parameters
- Involve the application team in frequent validation exercises
It is important to accurately identify and document deliverables before starting a project, as misalignment with these goals can cause delays or failures further down the timeline.
Politics
With major changes in the IT landscape, there are also Human Resource-related matters to handle. Depending on the nature of the project, there are potential issues:
- The organization’s move to another data center might abandon previous suppliers
- IT staff might be left without a job
It can be part of an outsourcing project that moves certain operations or IT support outside the organization
Some of these people will need to help in the execution of the project, so it is crucial to treat them with respect and to make sure sensitive information is closely guarded. The blueprinting team members will probably know what the outcome of the project will bring for suppliers and the customer’s IT team. If some of this information is released, the project can be compromised with valuable information and time lost.
Blueprint Example
When delivering a migration blueprint, each customer will have different demands, but in most cases, the basic request will be the same: to provide a set of documents that contain all servers and applications, and show how they are dependent on each other. Most of the time, customers will also ask for visual maps of these connections, and it is the consultant’s job to make sure these demands are reasonable. There is only so much that can be visualized in a map that is understandable, so it is best to limit the number of servers and connections to about 10–20 per map. The following complex image is an example of just a single server with multiple running services discovered.
Figure 1. A server and its services visualized in VMware’s ADP discovery tool
Beyond putting individual applications and servers on an automated map, there can also be demand for visualizing application-to-application connectivity, and this will likely involve manipulating data correctly. Some dependencies can be visualized, but others might require a text-based presentation.
The following is an example of a fictional setup, where multiple applications talk to each other―just like in the real world. Both visual and text-based representations are possible, and it is easy to see that for overview and presentation purposes, a visual map is more suitable. However, when planning the actual migration, the text-based method might prove more useful.
Figure 2. Application dependency map: visual representation
Figure 3. Application dependency map: raw discovery data
Figure 4. Application dependency map: raw data in pivot table
It is easy to see that a blueprinting project can be a very challenging exercise with multiple caveats and pitfalls. So, careful planning and execution is required with strong communication between everyone involved.
This is the first in a series of articles that will give detailed overview, implementation and reporting methods on data center blueprinting.
Gabor Karakas is a Technical Solutions Architect in the Professional Services Engineering team and is based in the San Francisco Bay Area.
