Skip to main content

SAP HANA Tailored Datacenter Integration (TDI)

SAP HANA was initially available as an appliance only. This created significant financial and operational challenges for many organizations. However, today SAP HANA TDI offers you a range of choices for deploying HANA, with even more to come in the future.

SAP HANA TDI stands for SAP HANA tailored data center integration program that allows customers to leverage existing hardware and infrastructure components for their HANA deployment.

TDI stands for Tailored Datacenter Integration and describes a program that allows HANA customers to leverage existing hardware and infrastructure components for their HANA environment.

TDI targets the usage of certain hardware and infrastructure components already existing in a customer's landscape instead of the corresponding components delivered with a HANA appliance.

Compared to the SAP HANA appliance “all-in-one-box” approach in which certified hardware partners deliver HANA appliance with all necessary components pre-configured and pre-installed, HANA TDI provides customers with more flexibility and choices for HANA hardware infrastructure. With the HANA TDI approach, customers can choose their preferred hardware vendors and infrastructure components from a menu of supported SAP HANA hardware. By enabling customers to leverage existing hardware and operation processes in their data centers, HANA TDI can significantly lower the costs and allow for easier integration of SAP HANA into customers data center.

SAP HANA TDI further delivers on SAP commitment towards HANA openness. Initially,

HANA TDI approach – with each phase further opening HANA hardware infrastructure:

SAP HANA TDI Phase 1: Shared Enterprise Storage

It was first introduced in 2013 to allow customers to leverage their existing enterprise storage for SAP HANA deployments. As of today, most of the major enterprise storage vendors have certified their solutions for SAP HANA, providing customers with a variety of choices for designing their HANA storage landscape.

SAP HANA TDI Phase 2: Shared Enterprise Networking

In 2014 to define requirements, reference architecture and best practices for SAP HANA networking. HANA TDI enables customers to leverage the existing networking infrastructure and network components in their data center, such as routers, bridges, and switches for HANA cluster inter-node and cross-site communication. 

SAP HANA TDI Phase 3: Introduction of entry-level HANA E5 systems

It provides the more price-sensitive customers with a new choice for HANA compute nodes based on Intel Xeon E5 commodity hardware. These cost-optimized, HANA entry-level systems are based on 2-socket, Intel Xeon E5 v2/v3 family of processors and are only supported for scale-up deployment scenarios, with the maximum of 1.5TB of memory. 


 
Labels:

Comments

Post a Comment

Popular posts from this blog

Error: could not find function "read.xlsx" while reading .xlsx file in R

Got this during the execution of following command in R > dat Error: could not find function "read.xlsx" Tried following command > install.packages("xlsx", dependencies = TRUE) Installing package into ‘C:/Users/amajumde/Documents/R/win-library/3.2’ (as ‘lib’ is unspecified) also installing the dependencies ‘rJava’, ‘xlsxjars’ trying URL 'https://cran.rstudio.com/bin/windows/contrib/3.2/rJava_0.9-8.zip' Content type 'application/zip' length 766972 bytes (748 KB) downloaded 748 KB trying URL 'https://cran.rstudio.com/bin/windows/contrib/3.2/xlsxjars_0.6.1.zip' Content type 'application/zip' length 9485170 bytes (9.0 MB) downloaded 9.0 MB trying URL 'https://cran.rstudio.com/bin/windows/contrib/3.2/xlsx_0.5.7.zip' Content type 'application/zip' length 400968 bytes (391 KB) downloaded 391 KB package ‘rJava’ successfully unpacked and MD5 sums checked package ‘xlsxjars’ successfully unpacked ...
Post a Comment
Read more

Training LLM model requires more GPU RAM than storing same LLM

Storing an LLM model and training the same model both require memory, but the memory requirements for training are typically higher than just storing the model. Let's dive into the details: Memory Requirement for Storing the Model: When you store an LLM model, you need to save the weights of the model parameters. Each parameter is typically represented by a 32-bit float (4 bytes). The memory requirement for storing the model weights is calculated by multiplying the number of parameters by 4 bytes. For example, if you have a model with 1 billion parameters, the memory requirement for storing the model weights alone would be 4 GB (4 bytes * 1 billion parameters). Memory Requirement for Training: During the training process, additional components use GPU memory in addition to the model weights. These components include optimizer states, gradients, activations, and temporary variables needed by the training process. These components can require additional memory beyond just storing th...
Post a Comment
Read more

What is the benefit of using Quantization in LLM

Quantization is a technique used in LLMs (Large Language Models) to reduce the memory requirements for storing and training the model parameters. It involves reducing the precision of the model weights from 32-bit floating-point numbers (FP32) to lower precision formats, such as 16-bit floating-point numbers (FP16) or 8-bit integers (INT8). Bottomline: You can use Quantization to reduce the memory footprint off the model during the training. The usage of quantization in LLMs offers several benefits: Memory Reduction: By reducing the precision of the model weights, quantization significantly reduces the memory footprint required to store the parameters. This is particularly important for LLMs, which can have billions or even trillions of parameters. Quantization allows these models to fit within the memory constraints of GPUs or other hardware accelerators. Training Efficiency: Quantization can also improve the training efficiency of LLMs. Lower precision formats require fewer computati...
Post a Comment
Read more