Preparing a Data Center for an Application Centric Infrastructure

Now-a-days, you may not see an IT infrastructure article without buzzwords like software-defined networking (SDN), network functions virtualization (NFV), OpenStack, application centric infrastructure (ACI), NSX, etc. At one point, these technologies were initially being marketed solely for cloud providers, but today, there is a huge swing in the industry. Large and medium-sized organizations are considering the value of this technology for their data centers.

My team at T2 Tech Group is currently helping to transform a California health system’s IT infrastructure. For the effort, one of the projects is to consolidate the client’s existing data centers to a new data center. After a lot of discussion with the client’s upper management and various vendors, our client selected Cisco ACI for their new data center.

Following a rigorous vendor selection phase, we embarked on the necessary prep work for the ACI implementation process. From the perspective of a vendor neutral network architect, I’m writing a blog series on how to plan, prepare and deploy a comprehensive SDN solution for an enterprise data center. Within my series, I will also address common challenges during the transformation and analyze the ROI from this technology.

Starting with a thorough application assessment

A few product vendors market SDN as a plug and play solution, but the reality isn’t like that. With ACI, NSX or OpenStack, there is a lot of planning and preparation that must be done. As the infrastructure is getting transformed to an application-focused model, you need to know about your applications very well.

In a healthcare organization, this can be a challenge. For example, there is often a mixture of legacy applications, interfaces with too many connections, and a laundry list of vendors without detailed documentation on proper communication between application tiers.

Even before my client made a vendor selection, we spent time collecting information on all applications running in our client’s healthcare organization. We had various discussions with the application vendors to understand the roadmap for the applications. We also had discussions within the client’s upper management to understand their vision on various applications, such as the electronic health record, the patient entertainment portal, cloud based applications, etc.

A few people may question, is a considerable time and effort spent reviewing applications required for selecting a network infrastructure? Our perspective is that it’s absolutely necessary. The knowledge gained upfront has already proven invaluable. After our study was completed, the network team, security team and application team all understood what they needed to make a secure, scalable and easy-to-manage infrastructure.

Changing the paradigm

An ACI operational model is completely different from the traditional data center model. In the old model, the network is built, servers are plugged into it and the application team builds their applications on the infrastructure. This often meant everyone worked independently in the beginning and collaborated in the end.

In an ACI model, the time we spent upfront on the applications helped our team understand the requirements for micro, nano, pico or whatever segmentation was named. Knowing the application behavior was important because the port-group for the virtual machine (VM), endpoint groups (EPGs) and all required rules are bound to the application. If you don’t do the proper planning, the profile may need to be changed, and it can require costly rework to create your application boundaries and communication again.

As another example of the need for a new model, studying the applications upfront also helps teams deal with the ternary content-addressable memory (TCAM) limitations on the ACI switches. It is best to reuse the policies to have an efficient utilization of TCAM. Teams can also save the TCAM space by not placing the group of servers in an application scattered across various leaf switches. By this design, not all leaf switches need to load all the policies in the Fabric, which indeed saves the TCAM space. For our project, we knew that optimal benefits could only be achieved if the team knew the application behavior, how to group the policies and other crucial steps.

Training to prime our team

As a next step to prepare our client’s in-house IT staff, we organized a 5-days Cisco ACI joint training program. The training outlined best practices for deploying, provisioning and maintaining the platform. With a lot of hands-on lab involvement, the training program gave an in-depth experience with the client’s future deployment scenario.

Now, the team is more prepared to handle configuration, automation and the common day-to-day operations and troubleshooting that can arise with the platform. The training was just one part of our effort to ensure the client could manage and operate the platform for years to come. The week before the training, the client had questions about the complexity and demands of the new design. After the training, the team was very comfortable.

We know the new system will call for adjustments and additional learning, but because we set up a framework of transparency and collaboration across teams, we have the joint buy-in we need for the next steps of implementation. Plus, I know the team is now willing to meet the transformation’s new requirements, and they are excited for what is to come.

In my next article, I will speak more on how to plan for your virtual routing and forwarding, Bridge Domain and EPG from an application perspective in your ACI design. If you have thoughts on the topic covered here or suggestions for more articles, please leave them in the comment section below.