The TDI model leverages existing storage and network investment in people, process and equipment: Reduced hardware and operational costs by reusing existing hardware components and operation processes (most customers already have Cisco Networking and EMC/NetApp Storage) Mitigate risks and optimizes time-to-value by using existing IT Management processes for SAP HANA implementations Provides more flexibility in hardware vendor selection and leverages the existing ecosystem
With the SAP HANA TDI model, SAP has defined specific rules and responsibilities: Server: Only servers listed in the SAP HANA Product Availability Matrix are supported. No local disks and no flash-memory cards are required. Additional Fibre Channel adapters for booting from the SAN are allowed. Storage: All storage devices must have successfully passed the hardware certification for SAP HANA. A list of storage resources certified for SAP HANA TDI can be found http://scn.sap.com/docs/DOC-48516. SAP HANA Installation: SAP Certified Technology Specialists must perform the installation. The certification includes: SAP Certified Technology Specialist (E_HANAINS131) with prerequisite SAP Certified Technology Associate (C_HANATEC_1 or C_HANATEC131) certification. Cisco is certified to perform these installations. Customer: The SAP HANA TDI solution is owned and supported by the customer, end to end, including design, implementation, certification, and support. Cisco and its partners can help you through any or all of these phases with Cisco Advanced Services for SAP HANA TDI
Slide is done
There are three HANA Deployment Models: Appliance Model – Pre-designed, validated and factory built SAP HANA solution Tailored Datacenter Integration (TDI) Model - Delivery model that provides the customer the flexibility to use existing infrastructure and operation processes/skill sets. Cloud Model – Delivery model where customers use a HANA Hosted or “Infrastructure as a Service” through a Cisco Cloud Provider (e.g. Virtustream). This is for customers who are looking for an OPEX vs. CAPEX model.
Journey with lots of twists and turns…but ultimately will converge on standard building blocks which cover the full landscape. We think that a Standards with common architectural approach across deployment options will win out.
Here are some of the potential use cases for the TDI model:
1) Utilize customer’s existing datacenter storage area network (SAN) Example: Use existing SAN (EMC or NetApp) with the storage vendor providing support (e.g NetApp for OnTap)
2) Support for multiple SAP HANA production systems within one UCS Example: Two PRD HANA instances running on the same UCS configuration Example: Run the SAP Application Server together with SAP HANA on the same UCS configuration
3) Utilize customer’s existing datacenter 10GB Ethernet networking Example: Network provider will provide support (e.g. Cisco if on our switches)
4) Run SAP HANA together with other applications on shared infrastructure
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.
SAP HANA TDI
SAP HANA TDI
Robert Michael Moore (Mike)
SME, Cisco | WW SAP Center of Competence
Tailored Datacenter Integration with EMC
Co-sponsored by Intel®