With the EMC VNX8000 storage models we created a solution based on 40 B440 M2 server – each with 512 GB memory – and 4 VNX8000 storages. Each storage provides the performance and capacity for the OS, HANA Data, HANA Log and HANA Share on 10 B440 server – regardless if multiple virtual HANA systems or a single one.
We scale to 40 Blades and 4 Storages per cell to guaranty the performance and a design with no over-subscription.
Boot Storage is based on FC / FCoE LUNs (this can change as PXE and persistent NFS root OS is supported by UCS-Director) All other storage, i.e. HANA data and log is based on NFS shares
We talked a lot about the cell design, now lets see how the solution scales beyond the 40 nodes.
For scalability we defined the terms Layer2 (L2) domain and Layer 3 (L3) domain. A L2 domain is based on VLAN ID separation and limitations and can hold multiple Cells. The core limitation is the number of VLAN Ids – 4090 max. A L3 domain is based on IP separation and can use multiple L2 domains to run the systems.
As shown in the sandwich slide at the beginning the L2 domain is managed by a Infrastructure/platform manager – we use UCS-Director. Every L2 domain do have a own UCS-Directory instance (purple dot). The L3 domain is managed by a network automation tool – we use Cisco Network manager – and we use Cisco Intelligent Automation for Cloud (orange dot) for the Cloud Automation Layer and to coordinate the L3 network automation and the L2 / cell automation.
We are fully aware that the most Service Providers do have a cloud automation and / or network automation tool in place and it is possible to use these tools for the L3 part.
One unique point of our solution is UCS-Director as this tool abstract the infrastructure complexity and provides a services catalog for the different HANA sizes and applications.
Here is a sample configuration that is designed for SAP to host HANA as a Service.
There are 5 cells with 40 nodes each – 200 nodes – in one L2 domain. All cells are attached to a pair of Nexus 7000 switches. There is a seperate management / backup cell. This cell hosts all the management tools, like UCS-Director, CIAC, Virtual Center, … as well as storages to store the application backups. The backup destination is outside of the cell for three reasons. #1 customers may want to discontinue the HANA service for a while but will come back. The application backup can be stored for X weeks or month withouth any impact to the cell design and as the customer comes back the new HANA system can be placed in any cell. #2 The backup storage can be optimized for capacity and does not impact the core HANA performance. #3 The backup destination is not on the same storage as the productive data.
For customer access Cisco ASA and ASR devices are used to provide VPN and MPLS functionality.
SAP HANA TDI Tailored Datacenter Integration with EMC
SAP HANA TDI
Robert Michael Moore (Mike)
SME, WW SAP Center of Competence
Tailored Datacenter Integration with EMC
Co-sponsored by Intel®