Skip to content

OUTDATED: Reference Architecture for SAP HANA on different infrastructure platforms

License

Notifications You must be signed in to change notification settings

sap-linuxlab/architecture.sap_hana

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Reference Architecture for SAP HANA

Objective

SAP HANA database is offering many different options how to design the infrastructure.

There are different ways how to implement High Availability (HA) and Disaster Recovery (DR) and there are many optional SAP HANA extensions (like Extension Nodes, Dynamic Tiering, XSA, etc.) that can be deployed.

There are various considerations that must be taken into account when designing infrastructure - for example ability to seamlessly move tenant (tenant portability) or whole instance (instance portability) without breaking external connectivity to the component.

Additional challenge is how to configure hostname resolution for individual virtual IPs to enable support for certificates and ensure their validity in relation to tenant or instance portability.

As result of this there are too many ways how to deploy SAP HANA and therefore almost all published Reference Architectures are very high-level showing only the generic concepts and they lack important details how to correctly implement the solution.

Goal of this project is to provide one standardized multi-cloud and on-premise architecture for SAP HANA that is able to support as many optional extensions as possible and to offer implementation details for different platforms including Public Cloud vendors (AWS, Azure, GCP, etc.) as well as on-premise implementations (VMware, Bare Metal).

It is important to state that other architectures are still valid (as long as formally supported by SAP) and can be used for specific requirements or use cases.

Approach

The approach taken by the team is driven by the opinion that it is simpler to remove the features rather than to add them and make them work in harmony with the rest of the design.

Basic steps are following:

  1. Define complex requirements including most common optional features
  2. Make Architectural Decisions (ADs) to reduce the amount of deployment options
  3. Design infrastructure architecture meeting as many requirements as possible (one standardized architecture)
  4. Derive simplified versions of the architecture by removing specific requirements
  5. Modify the infrastructure architecture for different platforms by introducing platform-specific details

Table of Content

  1. Requirements
  2. Architectural Decisions
  3. Generic SAP HANA Architecture
  4. Platform Specific Architecture
  5. Operational Procedures
    • High Availability (HA) Operation
    • Disaster Recovery (DR) Operation
    • SAP HANA Instance Move
    • SAP HANA Tenant Move
  6. Additional Information
    • SAP HANA: Network Latency Requirements
    • SAP HANA: Stacking Options (MCOD, MCOS, MDC)
    • SAP HANA: Certificate setup

Contributing

Please refer to How to Contribute to understand how to contribute to this project.

About

OUTDATED: Reference Architecture for SAP HANA on different infrastructure platforms

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Shell 65.5%
  • Awk 34.5%