Multi-tenancy features, also known as “multiple database containers” or MDC have been available in SAP HANA for several years already. With the new SAP HANA 2.0 SPS 01 release, all systems now run in multi-container database mode. All new systems are installed in multi-container database mode, and existing single-container systems are converted during the upgrade to SAP HANA 2.0 SPS 01.
Systems running in multi-container database mode can very easily be extended by adding new tenant databases. Being able to run and manage multiple tenant databases in one system helps you to lower capital expenditure, simplify database management, or for example build multi-tenant cloud applications.
Advantages of multi-container database mode
Systems running in multi-container database mode can very easily be extended by adding new tenant databases. Being able to run and manage multiple tenant databases in one system helps you to lower capital expenditure, simplify database management, or for example build multi-tenant cloud applications.
All the databases in a multi-container system share the same installation of database system software, the same computing resources, and the same system administration. However, each database is self-contained and fully isolated with its own:
- Set of database users
- Database catalog
- Repository
- Persistence
- Backups
- Traces and logs
- Workload management
This means, for example, that users in the system database have no access to content in the tenant databases, and vice versa. And of course users from one tenant database have no access to content in another tenant database. However, it is possible for example for cross-application reporting scenarios to enable cross-database SELECT queries. Cross-database access needs to be explicitly configured and is not possible by default.
From the administration perspective, there is a distinction between tasks performed at system level and those performed at database level. Database clients, such as the SAP HANA Cockpit, connect to specific databases.
Because all systems now run in multi-container mode by default, it is much easier to leverage multi-tenancy concepts to further strengthen security in your landscape, for example for
- Stronger protection of application data through isolation in dedicated tenant databases
- Enhanced segregation of duties with separate management of system and tenant databases and separate networks for administration and application access
- Hardening of tenant databases by restricting exposed functionality and configuration options, and fine-tuning security settings like TLS/SSL per tenant
In multi-container database mode, you have fine-granular control over your workload. You can manage and control the memory usage, concurrency and CPU consumption of your system by configuring limits for individual tenant databases, and by binding specific processes to logical CPU cores.
Automatic conversion to multi-container database mode during upgrade
During the upgrade to SAP HANA 2.0 SPS 01, existing single-container systems are automatically converted to multi-container database mode, resulting in a system with one system database and one tenant database. The new tenant inherits the name, content and configuration (e.g. port) of the former single-container system. Database size will stay roughly the same.
The upgrade is quick and no user data is changed or migrated. The SYSTEM user of the original single-container system will be assigned to the tenant database with the same password. You must set the password of the SYSTEM user of the new system database during the upgrade or installation process.
Do I have to change my applications after the conversion?
No. The default tenant database uses the same connection parameters and runs on the same ports as the single-container system and is also accessible through the same URLs. Existing applications do not need to be changed, the conversion is transparent for applications.
Adjusting the operations concept after the conversion
If you are moving from a single-container system to a multi-container system, you will see a few differences from an administration point of view. This means that you need to review your operations concept in order to account for the the new system database.
The system database stores and maintains the system topology and is responsible for overall system administration tasks. For example, software updates are executed on the system level. Also, some tenant-level administration tasks can optionally be executed from the system database, so you might want to think about removing some critical administration tasks with impact on hardware resources from the sphere of influence of tenant administrators, for example backup.
For security operations, you need to decide which additional administration users you would like to introduce in the system database. There are some other security-related configurations that you should review, for example your firewall settings (the system database has its own port), or your certificate configuration for TLS/SSL (the system database might need additional certificates).
The system database also needs to be backed up and integrated into your backup schedule in addition to the tenant database (which keeps the original backup settings during conversion from a single-container system). If you have created snapshot-based backups in your single-container system using an external backup tool, note that although snapshots can be created natively on tenant databases the tool vendors might have to makes some adjustments. Please get in touch with your tool provider for further details.
No comments:
Post a Comment