In keeping with the theme of moving the Software-Defined Data Center from concept to reality, I discussed in my previous blogs why VMware vSphere is the perfect platform to deploy cutting edged technologies like SAP HANA. This is because vSphere enables our customers to agilely react to rapidly changing hardware/software requirements by recasting memory, CPU, IO, or network resources where needed in your landscape through software in a centrally managed manner. I also discussed how VMware Virtual Volumes can be leverage to simplify SAP’s multi-temperature data management strategy; where data is classified by the frequency of access as either hot, warm, or cold depending on data usage. This is an example of the essence of Software-Defined Storage.
Mission Critical Architectures: Completing The Picture with VMware NSX
In this blog I want to discuss how VMware NSX can be leveraged in your SAP HANA Landscapes. Figure 1. is an excerpt from the SAP HANA Network Requirements Guide, which kind of goes to the heart of why networks should be virtualized. Now the components of an SAP HANA system communicate via different network channels. Rightfully so, SAP recommended to have a well-defined network topology to control and limit access into only the required access channels in order to apply the appropriate security measures as necessary.
Figure 1. SAP HANA Network Zones
In the Client Zone access is granted to different clients, such as the SQL clients on SAP application servers. In addition there are also browser applications using HTTP/S to access the SAP HANA server, as well as other data sources (such as BI) which need a network communication channel to the SAP HANA database
Now moving on to the Internal Zone, the internal zone covers the communication between hosts in a distributed SAP HANA system as well as the communication used by SAP HANA system replication between two SAP HANA sites.Lastly looking at the Storage Zone, although SAP HANA holds its data in memory, SAP HANA is a fully ACID compliant relational database so data also persists on storage. SAP HANA data need to be accessed via a network to provide protection against power failures or in the events a hosts becomes unavailable
Plus we now have the Dynamic Tiering zone not shown here which also has its own set of unique networking requirements. The bottom line is that in the physical world this can become quite complex because each communication zone needs special attention with regard to setup, security and performance requirements. With NSX software I was able to create a virtual network architecture from my desktop based on the SAP HANA Network Requirements Guide. VI-Architects should also apply already established virtual networking best practices and heuristics to these various zones when using NSX.
VMware NSX Overview
Now I just want to give a high level overview of what NSX is, its architecture, and components. For a deep dive of NSX there are many excellent white papers and resources available like; “VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide”. Think of NSX as a network hypervisor, with NSX you now have the ability to abstract and reproduce a complete set of layer 2 to layer 7 networking services (like switching, routing, firewalling and load balancing) in software. NSX network virtualization is just like when creating virtual machines and abstracting a physical servers CPU, RAM, Storage, and or NICs
Figure 2: NSX Overview
Also like a virtual machine, NSX can be centrally managed to create any combination of network services, to produce unique, isolated virtual networks quickly and dynamically. These virtual networks are independent of the underlying network hardware, which allows IT to treat the physical network as a pool of transport capacity that can be consumed and repurposed on demand.
I think it’s easiest to understand NSX by first looking at what’s available with core ESXi, with core ESXi you can create standard switches and distributed switches. Standard Switches are used to manage virtual machine and networking at the host level, while Distributed Switches manage virtual machine and networking at the data center level, essentially centralized management and deployment across multiple Hosts
Now the Virtual Distributed Switch (VDS) is a building block for the NSX-v architecture. With NSX you can create “logical switches”, which among other things can span multiple virtual distributed switches.
The use of distributed switches is entirely consistent with Tier1/Mission Critical deployments; our best practice recommendations for SAP HANA on vSphere prior to NSX is to always use virtual distributed switches to enable central management through software.
To expose these NSX capabilities seen in the data plane, you install VMware Installation Bundles (VIBs) which are a collection of files that get installed in the Kernel space of the ESXi hypervisor to enable the functionalities requested in the NSX-v architecture.
The Controller cluster in the NSX platform is the control plane component that is responsible for managing the switching and routing modules in ESXi.
For the Management Plan – NSX manager provides the single point of configuration in vSphere environment for NSX. In a vSphere environment this is accomplished via the vSphere Web UI to deploy NSX functional services and as well as integration to the cloud
SAP HANA Client Zone NSX Design
So just a word of caution, VMware has made it very easy to create and deploy network service with NSX, however I want to stress the actual abstraction of these services is a collaborative effort, at a minimum you must involve your network operations team, the storage team, VI-Admins, application owners, and dba’s in order to create an optimized virtual architecture; this should not be a siloed task.
Now from my desktops using NSX, I decomposed the “SAP HANA Network Requirements” for Tailored Data Center Integration deployments and translate that into a virtual network design. Starting with the Client Zone, the application server network and the network for other SAP HANA clients such as the SAP HANA studio, BI clients, and so on could be either on the same network or separate network. For scalability, management, and security purposed we recommend having them on different networks using micro-segmentation. Micro-segmentation gives customers the ability to secure, isolate, and characterize workload to workload network traffic. We will also be recommending a distributed routing scheme rather than a centralized routing scheme because we want to optimize for both North-West Traffic and East-West Traffic.
The east-west dynamic routing capabilities of the DLR are key here because of the way SAP HANA load balances its client connections. SAP uses techniques like, Statement routing, Connection Selection, and Command splitting to direct queries to the proper nodes. These routing techniques are based on the type of query and which node or nodes the data lives on.
As your database grows, the data distribution and types of queries can change. So with DLR’s you have to ability to centrally manage and optimizing east-west traffic by proactively reacting to database growth and traffic patterns.
For external communications with SAP HANA servers that are initiated by a web browser or a mobile applications We use an NSX Edge Services Perimeter Gateway to manage and optimize North-South network traffic, plus leveraging its multi-function capabilities as a firewall, load balancer, and VPN device.
And because these external connections could have vastly different security requirements, customers can use NSX to associate firewall rules at the router or at the virtual machine level to achieve greater granularity.
Figure 3: SAP HANA Client Zone NXS Network Design
SAP HANA Internal Zone NSX Design
In this slide I’m showing more detail which includes the Transport Zone and transit switch. Since I am creating various tiers using micro-segmentation which are fully isolated and secured zones, I need a way of centrally managing and communicating with these tiers. That’s what the transport Zone allows me to do. I can communicate with one or more ESXi clusters spanning multiple logical switches through the transport zone. This Transport Zone is also connected to the other NSX and VMware components, such as the Control Cluster, NSX Manager, and vCenter Server.
Figure 4. SAP HANA Internal Zone NSX Network Design
For the internal zone, SAP requires that the internode network must be configured with its own NIC for performance and security reasons. The internal network requires separate network interface cards that are exclusively configured as part of a private network, using separate IP addresses and ports.
Depending on the customers deployment needs SAP HANA tables can be distributed or replicated among multiple nodes or assigned to a single node, in addition tables may need to be joined and aggregated which can produce different network traffic patterns. So as with the client zone, the NSX DLR can be used to dynamically manage, load balance, and optimize network traffic based on growth, data distribution, and queries in your unique SAP HANA cluster.
SAP HANA Storage Zone NSX Design
Although SAP HANA is an in-memory database, data does still persist to storage. HANA can be deployed on SAN-fiber channel, 8Gb or NAS 10GB/E, and the storage must be certified for production use case. As mentioned earlier NSX fully support these protocols.
This slide shows a separate storage network and backup network, which SAP does recommends. This is another example of micro-segmentation to isolate backup jobs from normal database processing traffic. You can also configure your landscapes to perform databases backup to the cloud or keep multiple copies of your backups in the cloud using NSX’s VXLAN L2 over L3 technology.
Figure 5. SAP HANA Storage Zone NSX Network Design
Lastly I do want to touch on SAP HANA virtual machine mobility throughout the various network zones. I mentioned firewalls rules can be set at the network level or at the VM level. If you choose to set firewall rules at the VM level, your HANA virtual machines are still full mobility because those rules are bound to the VM, so when a live migration is perform via vMotion the firewall rules move with the VM. They are not locked to the server as in the physical world.
Putting It All Together – VMware vRealize Operations Management Pack for SAP HANA
The “SAP HANA Network Requirements Guide” for Tailored Data Center Integration deployments provides excellent guidance and recommendations when configuring your network topology. In interpreting these recommendations, customers can architect their network infrastructure in many ways to meet the KPIs, so the above virtual network architecture is only one abstraction based on SAP design guidelines. For this reason VMware NSX provides the perfect network platform to experiment with SAP’s recommendations then proactively optimize and secure your landscape as your infrastructure evolves.
Whether it be creating a virtual network, “right sizing” your SAP HANA database, determining the temperature of your data, or deploying Virtual Volumes, data collection is key. VMware vRealize Operations Management coupled with the SAP HANA management pack from Blue Medora can be used to collect end to end performance data so IT organizations and the business can make intelligent capacity planning decisions while proactively monitoring and managing their landscapes. In future I will be blogging about how this can be accomplished in virtual enterprise and cloud architectures including SAP HANA.
