Many SAP Customers started using XS Advanced and there were several questions on how to deploy or where to deploy and what are the consideration for choosing any of those approached. Based on my experience with various customers I tried to address some key topics in this blog to consolidate information from various sources of documentations
1. Deployment Options
There are various ways of deploying the XS Advanced runtime. Before deploying the XSA many scenarios need to considered that will have impact on your landscape maintenance activity. For example the system refresh scenarios where you will need to refresh only a certain tenants instead of complete system this deployment plays a key role. I will go through the limitations in detail in backup restore section. In general, The following additional services run where XSA is deployed:
◉ xscontroller: Central management component of XSA. It has a view on all deployed and/or running applications, and persists configuration and status information in the database
◉ xsexecagent: Responsible for managing processes, i.e. starting, keeping alive, and stopping tasks
◉ xsuaaserver: Manages user logon and logoff requests in SAP HANA XSA
◉ diserver: HDI handles the deployment of design-time artefacts into SAP HANA
The following new HANA host roles are introduced for XSA:
◉ XS_WORKER: Host for SAP HANA XSA runtime
◉ XS_STANDBY: Optional idle standby host for SAP HANA XSA runtime in a high-availability environment
Option 1: Scale-Up HANA, Shared Host
Option 2: Scale-Out HANA, Shared Host
Option 3: Dedicated XSA Host
Key Points
◉ Sizing is one of the key factors of finalizing the deployment approach in case of intensive Application Development on XSA a dedicated host deployment (option3) is preferred.
◉ If you only run a XS_WORKER on the host, then the host does not require HANA certified hardware or meet the standards of HANA Worker nodes
◉ XS worker host roles can be assigned to different hosts along with XS standby
◉ In Option3 configuration HANA is still considered scale-up as neither data nor database-internal workload are distributed
◉ XS Advanced can be installed on SYSTEMDB or TENANTDB. This plays a key role as well due to the restriction in backup restore come in to picture based on where XSA is installed
2. Sizing
◉ When estimating the resource consumption for running XS Advanced there are two key sizing considerations
◉ It is a prerequisite for productive sizing to define how the platform will be used, what and how many applications will be developed
◉ If unknown, it’s recommended to first set-up a development environment to allow DEV teams define this
◉ XSA Platform Sizing
◉ Basic requirement for XSA services (xsuaaserver, xscontroller etc…), system applications and application runtimes
◉ Determines the maximum number of concurrent application accesses the XSA installation will serve and determines the basic resource consumption
◉ XSA Application Sizing
◉ Resource requirement to handle user workload and related behavior of deployed applications
◉ Influenced by the scalability of deployed custom code and related user workload generated on both XSA and HANA
◉ Load testing of developed applications recommended to identify requirement, expert sizing recommended to support in cases of intensive application development
◉ Resource utilization for XSA is distributed dependent on the chosen deployment option and layout of services:
◉ Central (xsuaaserver, xscontroller..) XSA platform services run on the XS master host (first host with xs_worker role)
◉ In multi-host set-up application workload may be distributed to additional HANA worker hosts (additional xs_worker hosts)
◉ Application artifacts are stored to XS advanced persistency which is located either in System DB or default tenant DB
XSA Application Sizing
◉ The usage types and profile sizes on the prior slides influence only the scaling of the core platform services. They do not estimate resource requirements of user workload on deployed applications
◉ The T-shirt sizes do not apply to customer app sizing/configuration, but only to system components.
◉ In the case of intensive application development (e.g. microservices) It’s recommended to apply an expert sizing methodology to size the requirement of custom apps deployed on XSA
In case of heavy load app you need to follow regular project approach of developing, single user testing, multi user test followed by load test to simulate several user requests to validate hardware sizing allocated memory, CPU requirements
3. XS Advanced – Backup/Recovery
◉ Since XS advanced stores most of its persistent data within the SAP HANA database, you can use the SAP HANA tools and mechanisms to backup and restore XS advanced. There is, however, some persistent data, namely the file-system service, which is not automatically included in the SAP HANA backup. XS advanced provides tools to store this information within the database manually and restore it back to the file system.
◉ XS-advanced-related data is spread across different tenant databases, the consistency of the backed up data cannot be ensured if XS advanced services are running during the backup. For this reason, it is recommended to shut down XS advanced during the back up operation.
◉ If you not prefer to shut down XS advanced during the back up process then you have to be sure that no SAP HANA service instances are created, deleted, bound or unbound in between the backup of the system database and the backup of the respective tenant databases. This is usually the case in productive systems, when no applications are updated or initially deployed during the backup. It is important to bear in mind that inconsistencies in the data stored within an SAP HANA service instance cannot occur.
◉ In case of XSA installed on Tenant the XS advanced platform services (for example XS Controller) store all persistent data, such as application and service metadata, run times, build packs, and application droplets within a tenant database of the SAP HANA Platform. Applications running on XS advanced might store their persistent data within the same or a different tenant database, depending on the respective configuration of the organization and space the application is deployed to.
◉ If you want to back up a XS advanced system you must always back up all of the tenant databases that are registered with XS advanced. Backup all tenants listed in command $ XSA list-tenants
◉ In case if the XS Advanced is installed on SYSTEMDB then you need to backup restore SYSTEMB as well for any migration or refresh activities
Backup sequence should follow
◉ File system backup $ XSA backup-fss
◉ Tenant backup of tenants listed in $ XSA list-tenants
◉ It’s not possible to backup and recover or move individual tenant databases registered for XS advanced individually. To ensure the consistency of XS advanced platform and application data, all tenant databases registered for XS advanced must be backed up and recovered or moved together. Follow the below sequence for restore
1. Disable XSA
2. Restore XS-advanced-related data( Restore tenants )
3. Point the XS advanced platform services to the tenant database containing the XS advanced platform data you just restored -$ XSA select-xsa-runtime-db <tenant database name>
4. Restore the file-system service
5. Enable XSA
◉ It is recommended to consider point in time recovery to bring all the tenants and XSA to same consistent state.
◉ In any case if between XSA backup and tenant data backup if any app are deployed that will cause inconsistences between tenant data and XSA. There is a possibility of fixing this by redeploying the app again to fix the inconsistencies
◉ Renaming tenant databases that are registered for XS advanced is only supported since XS advanced 1.0.82.
◉ You get the details of XS Advanced file system backup’s from command $ XSA recover –fss –l This will list the file system backups available.
Additional information on XSA Backup recovery can be found in SAP Note 2300937 – Backup and restore for SAP HANA extended application services, advanced model
4. HA/DR with XS Advanced
The approaches applicable to HANA also apply for XSA with some further considerations
◉ Host Auto Failover – Stand BY
◉ HANA System Replication
In a HA/DR set-up XSA Applications must be reachable under stable URL
This continued client connectivity can be achieved via:
◉ Mapping the XSA default domain to a separate reverse proxy that is responsible for dispatching user requests to the currently active host in-front of the XSA instances
◉ Network based DNS or network based IP redirection
More Information can be found in SAP Note 2300936 – Host Auto-Failover & System Replication Setup with SAP HANA extended application services, advanced model
Setting Up Failover option for XS services
◉ XS services are very light services and can be restarted quick compared to Indexserver where all data need to be loaded in to memory. It is better to define cluster solution to not take any action if XSA services are down. In this situation daemon process with trigger a startup of service in case of any unexpected down situations of XS services.
◉ But in case if daemon was not able to start the service even after several attempts the service will remain down and still no failover is initiated
◉ To address this situation we can use the “Automatic host shutdown by service failures “ feature
◉ For every service a fixed number of restarts can be defined after which the daemon stops itself. The involved parameters are set per service type in daemon.ini
◉ If set to true(startup_error_shutdown_instance=true) the daemon will shutdown all services on the host if this service cannot start after certain number of retries (startup_error_restart_retries=4 )
◉ The nameserver is the only service that has this parameter set to true as default. This means that any problem involving a constant nameserver crash will stop the daemon eventually. For instance, the presented settings can be used for the XS Controller if recurring startup problems of that service should stop the affected database instance.
SAP HANA Near-Zero-Downtime-Upgrade (NZDU) with XS Advanced
Starting with XS advanced 1.0.91, HANA NZDU is supported in combination with XS advanced.
The following steps describe the near zero downtime update (NZDU) procedure for XS advanced, where [Primary] and [Secondary] denote steps to be performed only on the primary and secondary host, respectively:
◉ [Secondary] Update SAP HANA + SAP HANA XS Advanced Runtime without additional XS advanced components.
◉ [Primary] Stop the Primary System
◉ Initiate a takeover to the secondary host, so that the secondary system is now reachable
◉ [Secondary] Optional: If necessary, update additional XS advanced components using “hdblcm” (XS advanced must be updated again) or the xs command-line client.
◉ [Primary] While the primary is still stopped, update SAP HANA + SAP HANA XS Advanced Runtime with hdblcm option “–hdbupd_server_nostart”
Note: It’s not necessary to install XS advanced additional components on the primary system as they will be automatically replicated to this system
◉ Configure system replication with the previous secondary host as active host
Optional: Eventually initiate a second takeover to have the primary host as active host. Only perform this step when the command ‘xs system-information’ reports ‘state: READY’ in section ‘Controller server version information’.
Additional Details
◉ XSA Cockpit provides monitoring views that give overview statistics of applications running in the specified space and also Instance Monitoring screen for each application to view statistics per application instance.
◉ XSA diagnose command performs various checks related to performance, connectivity and certification validation. XSA Command line tool will give more options to perform administration tasks reelected XS Advanced
No comments:
Post a Comment