SAP HANA operations guide

This guide provides instructions for operating SAP HANA systems deployed on Google Cloud by following the SAP HANA on Google Cloud deployment guide. Note that this guide is not intended to replace any of the standard SAP documentation.

Administering an SAP HANA system on Google Cloud

This section shows how to perform administrative tasks typically required to operate an SAP HANA system, including information about starting, stopping, and cloning systems.

Starting and stopping instances

You can stop one or multiple SAP HANA hosts at any time; stopping an instance shuts down the instance. If the shutdown doesn't complete within 2 minutes, the instance is forced to halt. As a best practice, you should first stop SAP HANA running on the instance before you stop the instance.

Note: the private IP address associated with the instance is not released after you stop the instance. When you restart the instance again, it starts with the same private IP address, network, and storage configuration as before.

Stopping a VM

Stopping a virtual machine (VM) instance causes Compute Engine to send the ACPI power-off signal to the instance. You are not billed for the Compute Engine instance after the instance is stopped. If you have persistent disks attached to the instance, the disks are not deleted and you will be charged for them.

If the data on the persistent disk is important, you can either keep the disk or create a snapshot of the persistent disk and delete the disk to save on costs. You can create another disk from the snapshot when you need the data again.

Note: After you stop the instance, you can edit instance tags, custom instance metadata, and remove or set a new static IP address.

To stop an instance:

1. In the Google Cloud console, go to the VM Instances page.

   Go to VM Instances page

2. Select one or more instances that you want to stop.

3. At the top of the VM instances page, click STOP.

For more information, see Stopping an instance.

Restarting a VM

1. In the Google Cloud console, go to the VM Instances page.

   Go to VM Instances page

2. Select the instances that you want to restart.

3. At the top right-hand of the page, click START to restart the instances.

For more information, see Restarting an instance.

Modifying a VM

You can change various attributes of a VM, including the VM type, after the VM is deployed. Some changes might require you to restore your SAP system from backups, while others only require you to restart the VM.

For more information, see Modifying VM configurations for SAP systems.

Creating a snapshot of SAP HANA

To generate a point-in-time backup of your persistent disk, you can create a snapshot. Compute Engine redundantly stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of your data.

Note: You must either stop SAP HANA or stop writes to the filesystem to obtain a consistent snapshot.

To create a snapshot, follow the Compute Engine instructions for creating snapshots. Pay careful attention to the preparation steps before creating a consistent snapshot, such as flushing the disk buffers to disk, to make sure that the snapshot is consistent.

Snapshots are useful for the following use cases:

Use case	Details
Provide an easy, software-independent, and cost-effective data backup solution.	Backup your data, log, backup and shared disks with snapshots. Schedule a daily backup of these disks for point in time backups of your entire dataset. After the first snapshot, only the incremental block changes are stored in subsequent snapshots. This helps save costs.
Migrate to a different storage type.	Compute Engine offers different types of persistent disks, including types backed by standard (magnetic) storage and types backed by solid-state drive storage (SSD-based persistent disks). Each has different cost and performance characteristics. For example, use a standard type for your backup volume and use an SSD-based type for the /hana/log and /hana/data volumes, because they require higher performance. To migrate between storage types, use the volume snapshot, then create a new volume using the snapshot and select a different storage type.
Migrate SAP HANA to another region or zone.	Use snapshots to move your SAP HANA system from one zone to another zone in the same region or even to another region. Snapshots can be used globally within Google Cloud to create disks in another zone or region. To move to another region or zone, create a snapshot of your disks including the root disk, and then create the virtual machines in your desired zone or region with disks created from those snapshots.

Migrating existing SAP HANA Persistent Disk volumes to Hyperdisk Extreme volumes

You can migrate existing Persistent Disk volumes to Hyperdisk Extreme volumes for your SAP HANA systems running on Google Cloud. Hyperdisk Extreme provides better performance for SAP HANA than the SSD-based Persistent Disk types.

To migrate your Persistent Disk volumes to Hyperdisk Extreme volumes, you use Google Cloud's persistent disk snapshots and SAP HANA Fast Restart Option. The SAP HANA Fast Restart option is used as a helper that reduces downtime when switching disk types by eliminating the need to wait for the tables to load. You should take into account the time needed to reload row store and Binary Large Object (BLOB) data types.

Although the migration process requires minimal downtime, the actual duration of the downtime depends on the time taken to complete the following tasks:

• Creating snapshots. To reduce downtime while taking snapshots, you can take snapshots of the disks before the planned migration activity, and then take some additional snapshots closer to the activity, which results in a smaller difference between the snapshots.
• Creating Hyperdisk Extreme volumes using the snapshots of your Persistent Disk volumes.
• Reloading SAP HANA tables into SAP HANA memory.

In the event of any problem during the migration, you can revert to the existing disks because they are unaffected by this procedure, and are available until your delete them.

Note: We strongly recommend that you test the migration procedure in a non-production environment and verify the results thoroughly before executing the procedure in production environments. You assume the responsibility for correctly executing the migration procedure.

Before you begin

Before you migrate your SAP HANA Persistent Disk volumes to Hyperdisk Extreme volumes, make sure the following conditions are met:

• SAP HANA is running on a certified Compute Engine VM type that supports Hyperdisk Extreme.
• SAP HANA data and log use separate persistent disks for /hana/data and /hana/log volumes.
• Linux logical volume management is used for SAP HANA storage persistence. While direct storage can be used, it would require explicit device remapping through /etc/fstab table.
• SAP HANA Fast Restart is enabled for your SAP HANA system. For more information about how to enable SAP HANA Fast Restart, see Enable SAP HANA Fast Restart.
• A valid backup of the SAP HANA database is available. This backup can be used to restore the database, if required.
• If the target VM instance is part of a high-availability cluster, then make sure that the cluster is in maintenance mode.
• The SAP HANA database is up and running.

• The tmpfs file system is fully loaded with the content of the MAIN data fragments. To view the file system utilization, run the following command: df -Th.

  You should see output similar to the following:

  #  df -Th
  Filesystem                        Type      Size  Used Avail Use% Mounted on
  ...
  /dev/mapper/vg_hana_shared-shared xfs       1.0T   56G  968G   6% /hana/shared
  /dev/mapper/vg_hana_data-data     xfs        14T  5.7T  8.2T  41% /hana/data
  /dev/mapper/vg_hana_log-log       xfs       512G  7.2G  505G   2% /hana/log
  /dev/mapper/vg_hana_usrsap-usrsap xfs        32G  276M   32G   1% /usr/sap
  tmpfsDB10                         tmpfs     5.7T  800G  4.9T  14% /hana/tmpfs0/DB1
  tmpfsDB11                         tmpfs     5.7T  796G  4.9T  14% /hana/tmpfs1/DB1
  tmpfsDB12                         tmpfs     5.7T  783G  4.9T  14% /hana/tmpfs2/DB1
  tmpfsDB13                         tmpfs     5.7T  780G  4.9T  14% /hana/tmpfs3/DB1
  tmpfsDB14                         tmpfs     5.7T  816G  4.9T  15% /hana/tmpfs4/DB1
  tmpfsDB15                         tmpfs     5.7T  780G  4.9T  14% /hana/tmpfs5/DB1
  tmpfsDB16                         tmpfs     5.7T  816G  4.9T  15% /hana/tmpfs6/DB1
  tmpfsDB17                         tmpfs     5.7T  780G  4.9T  14% /hana/tmpfs7/DB1
  

Migrate Persistent Disk volumes to Hyperdisk Extreme volumes

This section describes how to migrate the disk type of two persistent disks for /hana/data and /hana/logvolumes from Persistent Disks (pd-ssd) to Hyperdisk Extreme.

To illustrate the migration process, the following example configuration is used:

• Machine type: m2-ultramem-416 (12 TB memory, 416 vCPUs)
• SAP HANA scale-up system deployed using Google Cloud's Terraform: SAP HANA scale-up deployment guide.
  • OS: SLES for SAP 15 SP1
  • SAP HANA: HANA 2 SPS06, Patch 63
  • Default disk type: pd-ssd
  • /hana/data and /hana/log volumes are mounted on separate disks and are built using LVM and XFS
  • SAP HANA Fast Restart is enabled and about 6 TB of data is loaded into the database

To migrate Persistent Disk volumes to Hyperdisk Extreme volumes, perform the following steps:

1. Stop the SAP HANA database by using one of the following commands:

   HDB stop
   

   Or,

   sapcontrol -nr INSTANCE_NUMBER -function StopSystem HDB
   

   Replace INSTANCE_NUMBER with the instance number for your SAP HANA system.

   For more information, see Starting and Stopping SAP HANA Systems.

2. Unmount the /hana/data and /hana/log file systems:

   umount /hana/data
   umount /hana/log
   

3. Determine the names of data and log persistent disks by using one of the following methods:

   • Run the following command:

     ls -l /dev/disk/by-id/
     

     The output shows the mapping of disk names to devices:

     ...
     lrwxrwxrwx 1 root root  9 May 18 20:14 google-hana-vm-data00001 -> ../../sdb
     lrwxrwxrwx 1 root root  9 May 18 20:14 google-hana-vm-log00001 -> ../../sdc
     ...
     

   • Run the following gcloud compute command:

     gcloud compute instances describe INSTANCE_NAME --zone=ZONE
     
     

     Replace the following:

     • INSTANCE_NAME: the name of the VM instance.
     • ZONE: the zone of the VM instance.

     The output shows the VM instance details including the associated disk information:

     gcloud compute instances describe hana-vm --zone europe-west4-a
     ...
     disks:
     - autoDelete: false
     deviceName: hana-vm-shared00001
     diskSizeGb: '1024'
     - autoDelete: false
     deviceName: hana-vm-usrsap00001
     diskSizeGb: '32'
     - autoDelete: false
     deviceName: hana-vm-data00001
     diskSizeGb: '14093'
     - autoDelete: false
     deviceName: hana-vm-log00001
     diskSizeGb: '512'
     
     

   • In the Google Cloud console, go to the Compute Engine VM instances page, and click the VM name. The Storage section displays the associated disk information.

4. Create snapshots of the data and log persistent disks:

   gcloud compute snapshots create DATA_DISK-snapshot \
     --project=PROJECT_ID \
     --source-disk-zone=SOURCE_DISK_ZONE  \
     --source-disk=DATA_DISK
   gcloud compute snapshots create LOG_DISK-snapshot \
     --project=PROJECT_ID \
     --source-disk-zone=SOURCE_DISK_ZONE \
     --source-disk=LOG_DISK
   

   Replace the following:

   • DATA_DISK: the name of the data persistent disk from which you need to create a snapshot. This name is prefixed to the data volume snapshot.
   • LOG_DISK: the name of the log persistent disk from which you need to create a snapshot. This name is prefixed to the log volume snapshot.
   • PROJECT_ID: the ID of the project.
   • SOURCE_DISK_ZONE: the zone of the persistent disk from which you need to create a snapshot.

   For more information about creating snapshots, see Create and manage disk snapshots.

   Important: Because snapshots incrementally back up data from your persistent disks, the initial snapshot typically takes longer to create than subsequent snapshots, especially for large disks. To reduce the downtime while taking snapshots, you can take snapshots of the disks before the migration process starts and the SAP HANA database is stopped. You can also take multiple snapshots before maintenance.

5. Create new Hyperdisk Extreme disks for /hana/data and /hana/log volumes based on the snapshots:

   gcloud compute disks create DATA_DISK-hdx \
        --project=PROJECT_ID \
        --zone=ZONE \
        --type=hyperdisk-extreme \
        --provisioned-iops=IOPS_DATA_DISK \
        --source-snapshot=DATA_DISK-snapshot
    gcloud compute disks create LOG_DISK-hdx \
        --project=PROJECT_ID \
        --zone=ZONE \
        --type=hyperdisk-extreme \
        --provisioned-iops=IOPS_LOG_DISK \
        --source-snapshot=LOG_DISK-snapshot
   

   Replace the following:

   • DATA_DISK: the name of the original persistent disk data volume that is prefixed to the Hyperdisk Extreme data volume and snapshot of the data volume.
   • LOG_DISK: the name of the original persistent disk log volume that is prefixed to the Hyperdisk Extreme log volume and snapshot of the log volume.
   • PROJECT_ID: the ID of the project.
   • ZONE: the zone where you need to create Hyperdisk Extreme disks.
   • IOPS_DATA_DISK: the provisioned IOPS of the Hyperdisk Extreme disk for data volume. You set IOPS according to your performance requirements.

   • IOPS_LOG_DISK: the provisioned IOPS of the Hyperdisk Extreme disk for log volume. You set IOPS according to your performance requirements.

     For information about the minimum IOPS for Hyperdisk Extreme volumes attached to your instance type, see Minimum sizes for SSD-based persistent disks and Hyperdisks.

   For more information about restoring from a snapshot, see Restore from a snapshot.

6. Detach the old SAP HANA persistent disks:

   gcloud compute instances detach-disk INSTANCE_NAME \
     --disk=DATA_DISK \
     --zone=ZONE
   gcloud compute instances detach-disk INSTANCE_NAME \
     --disk=LOG_DISK \
     --zone=ZONE
   

   Replace the following:

   • INSTANCE_NAME: the name of the VM instance.
   • DATA_DISK: the name of the data volume persistent disk to detach.
   • LOG_DISK: the name of the log volume persistent disk to detach.
   • ZONE: the zone where the persistent disks exist.
   Note: Do not delete the old SAP HANA disks until you have completed the migration procedure successfully.

7. Attach the new Hyperdisk Extreme disks.

   gcloud compute instances attach-disk INSTANCE_NAME \
       --disk=DATA_DISK-hdx \
       --zone=ZONE
   gcloud compute instances attach-disk INSTANCE_NAME \
      --disk=LOG_DISK-hdx \
       --zone=ZONE
   

   Replace the following:

   • INSTANCE_NAME: the name of the VM instance.
   • DATA_DISK: the name of the data volume Hyperdisk Extreme to attach.
   • LOG_DISK: the name of the log volume Hyperdisk Extreme to attach.
   • ZONE: the zone where the new Hyperdisk Extreme disks exist.

8. To mount the new volumes, perform the following steps as sudo or root user:

   1. Remove all device mapping definitions to avoid LVM device mapping conflicts:

      dmsetup remove_all
      

   2. Scan all disks for volume groups, rebuild caches, and create missing volumes (including LVM):

      vgscan -v --mknodes
      

      You should see output similar to the following:

      Scanning all devices to initialize lvmetad.
      Reading volume groups from cache.
      Found volume group "vg_hana_data" using metadata type lvm2
      Found volume group "vg_hana_shared" using metadata type lvm2
      Found volume group "vg_hana_log" using metadata type lvm2
      Found volume group "vg_hana_usrsap" using metadata type lvm2
      

   3. Activate the volume groups:

      vgchange -ay
      

      You should see output similar to the following:

       1 logical volume(s) in volume group "vg_hana_data" now active
       1 logical volume(s) in volume group "vg_hana_shared" now active
       1 logical volume(s) in volume group "vg_hana_log" now active
       1 logical volume(s) in volume group "vg_hana_usrsap" now active
      

   4. Scan for logical volumes:

      lvscan
      

      You should see output similar to the following:

      ACTIVE            '/dev/vg_hana_data/data' [13.76 TiB] inherit
      ACTIVE            '/dev/vg_hana_shared/shared' [1024.00 GiB] inherit
      ACTIVE            '/dev/vg_hana_log/log' [512.00 GiB] inherit
      ACTIVE            '/dev/vg_hana_usrsap/usrsap' [32.00 GiB] inherit
      

   5. Mount the disks:

      mount -av
      

      You should see output similar to the following:

      /                        : ignored
      /boot/efi                : already mounted
      /hana/shared             : already mounted
      /hana/data               : already mounted
      /hana/log                : already mounted
      /usr/sap                 : already mounted
      swap                     : ignored
      /hana/tmpfs0/DB1         : already mounted
      /hana/tmpfs1/DB1         : already mounted
      /hana/tmpfs2/DB1         : already mounted
      /hana/tmpfs3/DB1         : already mounted
      /hana/tmpfs4/DB1         : already mounted
      /hana/tmpfs5/DB1         : already mounted
      /hana/tmpfs6/DB1         : already mounted
      /hana/tmpfs7/DB1         : already mounted
      

9. Verify the new volumes:

   • Verify the file systems utilization:

     df -Th
     

     You should see output similar to the following:

     Filesystem                        Type      Size  Used Avail Use% Mounted on
     ...
     /dev/mapper/vg_hana_shared-shared xfs       1.0T   56G  968G   6% /hana/shared
     /dev/mapper/vg_hana_usrsap-usrsap xfs        32G  277M   32G   1% /usr/sap
     tmpfsDB10                         tmpfs     5.7T  784G  4.9T  14% /hana/tmpfs0/DB1
     tmpfsDB11                         tmpfs     5.7T  783G  4.9T  14% /hana/tmpfs1/DB1
     tmpfsDB12                         tmpfs     5.7T  783G  4.9T  14% /hana/tmpfs2/DB1
     tmpfsDB13                         tmpfs     5.7T  782G  4.9T  14% /hana/tmpfs3/DB1
     tmpfsDB14                         tmpfs     5.7T  783G  4.9T  14% /hana/tmpfs4/DB1
     tmpfsDB15                         tmpfs     5.7T  783G  4.9T  14% /hana/tmpfs5/DB1
     tmpfsDB16                         tmpfs     5.7T  783G  4.9T  14% /hana/tmpfs6/DB1
     tmpfsDB17                         tmpfs     5.7T  782G  4.9T  14% /hana/tmpfs7/DB1
     /dev/mapper/vg_hana_log-log       xfs       512G  7.2G  505G   2% /hana/log
     /dev/mapper/vg_hana_data-data     xfs        14T  5.7T  8.2T  41% /hana/data
     

   • Verify that the devices are linked to the new volumes:

     lsblk
     

     You should see output similar to the following:

     NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
     ...
     sdd                       8:48   0    1T  0 disk
     └─vg_hana_shared-shared 254:0    0 1024G  0 lvm  /hana/shared
     sde                       8:64   0   32G  0 disk
     └─vg_hana_usrsap-usrsap 254:3    0   32G  0 lvm  /usr/sap
     sdf                       8:80   0 13.8T  0 disk
     └─vg_hana_data-data     254:1    0 13.8T  0 lvm  /hana/data
     sdg                       8:96   0  512G  0 disk
     └─vg_hana_log-log       254:2    0  512G  0 lvm  /hana/log
     

10. Start the SAP HANA instance by using one of the following commands:

    HDB start
    

    Or,

    sapcontrol -nr INSTANCE_NUMBER -function StartSystem HDB
    

    Replace INSTANCE_NUMBER with the instance number for your SAP HANA system.

    For more information, see Starting and Stopping SAP HANA Systems.

Fallback

If the disk migration fails, you can use the original disks as a fallback option because they contain the data as it existed before the migration procedure began.

To restore the original state, perform the following steps:

1. Stop the VM instance.
2. Detach the newly created Hyperdisk Extreme volumes.
3. Reattach the original disks to the VM instance.
4. Start the VM instance.

Cloning your SAP HANA system

You can create snapshots of an existing SAP HANA system on Google Cloud to create an exact clone of the system.

To clone a single-host SAP HANA system:

1. Create a snapshot of your data and backup disks.

2. Create new disks using the snapshots.

3. In the Google Cloud console, go to the VM Instances page.

   Go to VM Instances page

4. Click the instance to clone to open the instance detail page, and then click Clone.

5. Attach the disks that were created from the snapshots.

Note: If you clone your existing SAP HANA instance to a new instance, the hostname of your new instance will be different, so for continued operation of SAP HANA, you must run a rename operation to change the SAP HANA hostname. Alternatively, you can modify the host resolution in /etc/hosts to point your new instance private IP address to the old hostname, but this is not recommended and should be avoided.

To clone a multi-host SAP HANA system:

1. Provision a new SAP HANA system with the same configuration as the SAP HANA system you want to clone.

2. Perform a data backup of the original system.

3. Restore the backup of the original system into the new system.

Note: You cannot clone a multi-host SAP HANA system by creating an image.

Installing and updating the gcloud CLI

After a VM is deployed for SAP HANA and the operating system is installed, an up-to-date Google Cloud CLI is required for various purposes, such as transferring files to and from Cloud Storage, interacting with network services, and so forth.

If you follow the instructions in the SAP HANA deployment guide, the gcloud CLI is installed automatically for you.

However, if you bring your own operating system to Google Cloud as a custom image or you are using an older public image provided by Google Cloud, you might need to install or update the gcloud CLI yourself.

To check if the gcloud CLI is installed and whether updates are available, open a terminal or command prompt and enter:

 gcloud version

If the command is not recognized, the gcloud CLI is not installed.

To install the gcloud CLI, follow the instructions in Installing the gcloud CLI.

Note: If you have previously deployed a VM with a SUSE Linux Enterprise Server (SLES) public image, your image might include version 140 or earlier of the gcloud CLI that is integrated into the SLES operating system by SUSE. This version is deprecated and cannot be updated.

To replace version 140 or earlier of the SLES-integrated gcloud CLI:

1. Log into the VM by using ssh.

2. Switch to the super user:

    sudo su
   

3. Enter the following commands:

    bash <(curl -s https://dl.google.com/dl/cloudsdk/channels/rapid/install_google_cloud_sdk.bash) --disable-prompts --install-dir=/usr/local
    update-alternatives --install /usr/bin/gsutil gsutil /usr/local/google-cloud-sdk/bin/gsutil 1 --force
    update-alternatives --install /usr/bin/gcloud gcloud /usr/local/google-cloud-sdk/bin/gcloud 1 --force
    gcloud --quiet compute instances list
   

Setting up your SAP support channel with SAProuter

Note: Also see the "Getting Support" section in the SAP HANA Administration Guide.

If you need to allow an SAP support engineer to access your SAP HANA systems on Google Cloud, you can do so using SAProuter. Follow these steps:

1. Launch the Compute Engine VM instance that the SAProuter software will be installed on, and assign an external IP address so the instance has internet access.

2. Create a new, static external IP address and then assign this IP address to the instance.

3. Create and configure a specific SAProuter firewall rule in your network. In this rule, allow only the required inbound and outbound access to the SAP support network, for the SAProuter instance.

   Limit the inbound and outbound access to a specific IP address that SAP provides for you to connect to, along with TCP port 3299. Add a target tag to your firewall rule and enter your instance name. This ensures that the firewall rule applies only to the new instance. See the firewall rules documentation for additional details about creating and configuring firewall rules.

4. Install the SAProuter software, following SAP Note 1628296, and create a saprouttab file that allows access from SAP to your SAP HANA systems on Google Cloud.

5. Set up the connection with SAP. For your internet connection, use Secure Network Communication. For more information, see SAP Remote Support – Help.

Tip: For added security, shut down the Compute Engine instance hosting the SAProuter service when it is not needed for support.

Configuring your network

You are provisioning your SAP HANA system by using VMs with the Google Cloud virtual network. Google Cloud uses state-of-the-art, software-defined networking and distributed-systems technologies to host and deliver your services around the world.

For SAP HANA, create a non-default subnet network with non-overlapping CIDR IP address ranges for each subnetwork in the network. Note that each subnetwork and its internal IP address ranges are mapped to a single region.

Tip: For lower latency, configure your application servers to connect to SAP HANA in the same region as the subnetwork where SAP HANA is hosted.

A subnetwork spans all of the zones in the region where it is created. However, when you create a VM instance, you specify a zone and a subnetwork for the VM. For example, you can create one set of instances in subnetwork1 and in zone1 of region1 and another set of instances in subnetwork2 and in zone2 of region1, depending on your needs.

A new network has no firewall rules and hence no network access. You should create firewall rules that open access to your SAP HANA instances based on a minimum privilege model. The firewall rules apply to the entire network and can also be configured to apply to specific target instances by using the tagging mechanism.

Routes are global, not regional, resources that are attached to a single network. User-created routes apply to all instances in a network. This means you can add a route that forwards traffic from instance to instance within the same network, even across subnetworks, without requiring external IP addresses.

For your SAP HANA instance, launch the instance with no external IP address and configure another VM as a NAT gateway for external access. This configuration requires you to add your NAT gateway as a route for your SAP HANA instance. This procedure is described in the deployment guide.

Security

The following sections discuss security operations.

Minimum privilege model

Your first line of defense is to restrict who can reach the instance by using firewalls. By creating firewall rules, you can restrict all traffic to a network or target machines on a given set of ports to specific source IP addresses. You should follow the minimum-privilege model to restrict access to the specific IP addresses, protocols, and ports that need access. For example, you should always set up a bastion host, and allow SSH into your SAP HANA system only from that host.

Configuration changes

You should configure your SAP HANA system and the operating system with recommended security settings. For example, make sure that only relevant network ports are listed to allow access, harden the operating system you are running SAP HANA, and so on.

Refer to the following SAP notes (SAP user account required):

• 1944799: Guidelines for SLES SAP HANA installation
• 1730999: Recommended configuration changes
• 1731000: Unrecommended configuration changes

Disabling unneeded SAP HANA Services

If you do not require SAP HANA Extended Application Services (SAP HANA XS), disable the service. Refer to SAP note 1697613: Removing the SAP HANA XS Classic Engine service from the topology.

After the service has been disabled, remove all the TCP ports that were opened for the service. In Google Cloud, this means editing your firewall rules for your network to remove these ports from the access list.

Audit logging

Cloud Audit Logs consists of two log streams, admin activity and data access, both of which are automatically generated by Google Cloud. These can help you answer the questions, "Who did what, where, and when?" in your Google Cloud project.

Admin activity logs contain log entries for API calls or administrative actions that modify the configuration or metadata of a service or project. This log is always enabled and is visible by all project members.

Data access logs contain log entries for API calls that create, modify, or read user-provided data managed by a service, such as data stored in a database service. This type of logging is enabled by default in your project and is accessible to you through Cloud Logging, or through your activity feed.

Securing a Cloud Storage bucket

If you use Cloud Storage to host your backups for your data and log, make sure you use TLS (HTTPS) while sending data to Cloud Storage from your instances to protect data in transit. Cloud Storage automatically encrypts data at rest. You can specify your own encryption keys if you have your own key-management system.

Related security documents

Refer to the following additional security resources for your SAP HANA environment on Google Cloud:

• Security center
• Compliance in the Google Cloud
• Google Cloud security whitepaper
• Google Infrastructure security design

High availability for SAP HANA on Google Cloud

Google Cloud provides a variety of options for ensuring high availability for your SAP HANA system, including the Compute Engine live migration and automatic restart features. These features, along with the high monthly uptime percentage of Compute Engine VMs, might make paying for and maintaining standby systems unnecessary.

However, if required, you can deploy a multi-host scale-out system that includes standby hosts for SAP HANA Host Auto-failover, or you can deploy a scale-up system with a standby SAP HANA instance in a high-availability Linux cluster.

For more information about the high availability options for SAP HANA on Google Cloud, see the SAP HANA high-availability planning guide.

Enable the SAP HANA HA/DR provider hook

SUSE RHEL

Disaster recovery

The SAP HANA system provides several high availability features to make sure that your SAP HANA database can withstand failures at the software or infrastructure level. Among these features is SAP HANA System replication and SAP HANA backups, both of which Google Cloud supports.

For more information about SAP HANA backups, see Backup and recovery.

For more information about system replication, see the SAP HANA disaster recovery planning guide.

Backup and recovery

Backups are vital for protecting your system of record (your database). Because SAP HANA is an in-memory database, you should create regular backups so you can recover from instances of data corruption. SAP HANA system provides native backup and recovery features to help you do this. You can use Google Cloud services such as Cloud Storage to serve as the backup destination for SAP HANA backup.

You can also install the Cloud Storage Backint agent for SAP HANA so that you can use Cloud Storage directly for backups and recoveries.

This document assumes you are familiar with SAP HANA backup and recovery, along with the following SAP service Notes:

• 1642148: FAQ: SAP HANA Database Backup & Recovery
• 1821207: Determining required recovery files
• 1869119: Checking backups using hdbbackupcheck
• 1873247: Checking recoverability with hdbbackupdiag --check
• 1651055: Scheduling SAP HANA Database Backups in Linux

Using Compute Engine persistent disks and Cloud Storage for backups

If you followed the deployment instructions, you have an SAP HANA installation with a /hanabackup directory. This is backed by using a standard persistent disk. You use the standard SAP tools to create your online database backups to /hanabackup directory. Finally, you save the completed backup by uploading it to a Cloud Storage bucket, from which you can download the backup, when you need to recover.

Using Compute Engine to create backups and disk snapshots

You can use Compute Engine for SAP HANA backups, and you also have the option of backing up the entire disk hosting your data and log using persistent-disk snapshots.

If you followed the instructions in the deployment guide, you have an SAP HANA installation with a /hanabackup directory for your online database backups. You can use that same directory to store snapshots of the backup volume and maintain a point-in-time backup of your data and log.

An advantage of snapshots is that they are incremental, where each subsequent backup only stores incremental block changes instead of creating an entirely new backup. Compute Engine redundantly stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of your data.

Here is an illustration of the incremental backups:

Cloud Storage as your backup destination

Cloud Storage is a good choice to use as your backup destination for SAP HANA because it provides high durability and availability of data.

Cloud Storage is an object store for files of any type or format. It has virtually unlimited storage and you do not have to worry about provisioning it or adding more capacity to it. An object in Cloud Storage consists of file data and its associated metadata, and can be up to 5 TB in size. A Cloud Storage bucket can store any number of objects.

With Cloud Storage, your data is stored in multiple locations, which provides high durability and high availability. When you upload your data to Cloud Storage or copy your data within it, Cloud Storage reports the action as successful only if object redundancy is achieved.

The following table shows the different storage options you have if you use Cloud Storage:

Data access needed	Cloud Storage options recommended
Frequent access	Choose the Standard [storage class](/storage/docs/storage-classes) for backups accessed multiple times in a month.
Infrequent access	Choose Nearline or Coldline storage for infrequently accessed data. Nearline is a good choice for backed-up data you plan to access at most once a month, while Coldline is better for data that has very low probability of access, perhaps once a year at most.
Archival data	Choose Archive storage for your long-term archival data. Archive is a good choice for data you need to retain a copy of for an extended period of time, but which you don't intend to access more than once a year. Consider replacing your tape-based backup solution with Archive.

When you plan your usage of these storage options, start with the frequently accessed tier and age your backup data through to the infrequent access tiers. Backups generally become rarely used as they become older. The probability of needing a backup that is 3 years old is extremely low and you can age this backup into the Archive tier to save on costs, which are currently as low as 12/100th of a cent per GB/month (equal to $1.20 per TB/month).

Cloud Storage compared to tape backup

The traditional, on-premises backup destination is tape. Cloud Storage has many benefits over tape, including the ability to automatically store backups "offsite" from the source system, since data in Cloud Storage is replicated across multiple facilities. This also means that the backups stored in Cloud Storage are highly available.

Another key difference is the speed of restoring backups when you need to use them. If you need to create a new SAP HANA system from backup or restore an existing system from backups, Cloud Storage provides faster access to your data and helps you build the system faster.

Cloud Storage Backint agent for SAP HANA

You can use Cloud Storage directly for backups and recoveries for both on-premises and cloud installations by using the SAP-certified Cloud Storage Backint agent for SAP HANA (Backint agent).

For more information, see Cloud Storage Backint agent for SAP HANA overview.

Managing identity and access to backups

When you use Cloud Storage or Compute Engine to back up your SAP HANA data, access to those backups is controlled by Identity and Access Management (IAM). This feature gives admins the ability to authorize who can take action on specific resources. IAM provides you with centralized, full control, and visibility for managing all of your Google Cloud resources, including your backups.

IAM also provides a full audit trail history of permissions authorization, removal, and delegation gets surfaced automatically for your admins. This lets you configure policies that monitor access to your data in the backups, allowing you to complete the full access-control cycle with your data. IAM provides a unified view into security policy across your entire organization, with built-in auditing to ease compliance processes.

To grant access to backups in Cloud Storage:

1. In the Google Cloud console, go to the IAM & Admin page:

   Go to the IAM & Admin page

2. Specify the user you are granting access to, and assign the role Storage > Storage Object Creator:

   

How to make backups

SAP HANA systems provisioned on Google Cloud using the deployment guide are configured with a set of persistent disk volumes to be used as an NFS-mounted backup destination. SAP HANA backups are first stored on these local persistent disk volumes, and should then copied to Cloud Storage for long-term storage. You can either manually copy the backups over to Cloud Storage or schedule the copy to Cloud Storage in a crontab.

If you are using the Cloud Storage Backint agent for SAP HANA, you back up to and recover from a Cloud Storage bucket directly. Persistent disk storage is not required.

You can use SAP HANA Studio, SQL commands, or the DBA Cockpit to start or schedule SAP HANA data backups. Log backups are written automatically unless disabled. The following screenshot shows an example:

Configuring SAP HANA global.ini

If you followed the deployment guide instructions, the SAP HANA global.ini configuration file is customized with database backups stored in /backup/data/ and automatic log archival files are stored in /backup/log/, as follows:

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_databackup = /hanabackup/data
basepath_logbackup = /hanabackup/log

[system_information]
usage = production

To customize the global.ini configuration file for the Cloud Storage Backint agent for SAP HANA, see the Cloud Storage Backint agent for SAP HANA deployment guide.

Notes for scale-out deployments

In a scale-out implementation, a high-availability solution that uses live migration and automatic restart works in the same way as in a single host setup. The main difference is that the /hana/shared volume is NFS-mounted to all the worker hosts and mastered in the HANA master. There is a brief period of inaccessibility on the NFS volume in the event of a master host's live migration or auto restart. When the master host has restarted, the NFS volume will soon function again on all hosts, and normal operation resumes automatically.

The backup volume, /hanabackup, must be available on all hosts during backup and recovery operations. In the event of failure, you should verify the /hanabackup is mounted on all hosts and remount any that are not. When you choose to copy the backup set to another volume or Cloud Storage, you should run the copy on the master host to achieve better IO performance and reduce network usage. To simplify the backup and recovery process, you can use Cloud Storage Fuse to mount the Cloud Storage bucket on each host.

The scale-out performance is only as good as your data distribution. The better the data is distributed, the better your query performance will be. This requires that you know your data well, understand how the data is being consumed, and design table distribution and partitioning accordingly. Please refer to SAP Note 2081591.

Gcloud Python

Gcloud Python is an idiomatic Python client that you can use to access Google Cloud services. This guide uses Gcloud Python to perform backup and restore operations to and from Cloud Storage for your SAP HANA database backups.

If you followed the deployment guide instructions, Gcloud Python libraries are already available in the Compute Engine instances.

The libraries are open source and allow you to operate on your Cloud Storage bucket to store and retrieve backup data.

Note: If you did not follow the deployment guide instructions, and thus need to install the Gcloud Python libraries, run the following commands to install on SUSE Linux Enterprise Server (SLES) as root:

zypper in python-pip python-devel gcc
pip install packaging
pip install appdirs
pip install --upgrade google-cloud-storage

You can run the following command to list objects in your Cloud Storage bucket. You can use it to list the backup objects available:

python 2>/dev/null - <<EOF
from google.cloud import storage
storage_client = storage.Client()
bucket = storage_client.get_bucket("<bucket_name>")
blobs = bucket.list_blobs()
for fileblob in blobs:
     print(fileblob.name)
EOF

For complete details about Gcloud Python, see the storage client library reference documentation.

Backup example

Here are the steps you might take for a typical backup task, using SAP HANA Studio as an example:

1. In the SAP HANA Backup Editor, select Open Backup Wizard.

   

   1. Select File as the destination type. This backs up the database to files in the specified file system.
   2. Specify the backup destination, /hanabackup/data/[SID], and the backup prefix. Replace [SID] with the proper SAP SID.
   3. Click Next.

2. Click Finish in the confirmation form to start the backup.

3. When the backup starts, a status window displays the progress of your backup. Wait for the backup to complete.

   

   When the backup is complete, the backup summary displays a "Finished" message.

4. Sign in to your SAP HANA system and verify that the backups are available at the expected locations in the file system. For example:

   

5. Push or synchronize the backup files from the /hanabackup file system to Cloud Storage. The following sample Python script pushes the data from /hanabackup/data and /hanabackup/log to the bucket used for backups, in the form [NODENAME]/[DATA] or [LOG]/YYYY/MM/DD/HH/[BACKUP_FILE_NAME]. This allows you to identify backup files based on the time during which the backup was copied. Run this gcloud Python script on your operating system bash prompt:

   python 2>/dev/null - <<EOF
   import os
   import socket
   from datetime import datetime
   from google.cloud import storage
   storage_client = storage.Client()
   today = datetime.today()
   current_hour = today.strftime('%Y/%m/%d/%H')
   hostname = socket.gethostname()
   bucket = storage_client.get_bucket("hanabackup")
   for subdir, dirs, files in os.walk('/hanabackup/data/H2D/'):
     for file in files:
         backupfilename = os.path.join(subdir, file)
         if 'COMPLETE_DATA_BACKUP' in backupfilename:
               only_filename = backupfilename.split('/')[-1]
               backup_file = hostname + '/data/' + current_hour + '/' + only_filename
               blob = bucket.blob(backup_file)
               blob.upload_from_filename(filename=backupfilename)
   for subdir, dirs, files in os.walk('/hanabackup/log/H2D/'):
     for file in files:
         backupfilename = os.path.join(subdir, file)
         if 'COMPLETE_DATA_BACKUP' in backupfilename:
             only_filename = backupfilename.split('/')[-1]
             backup_file = hostname + '/log/' + current_hour + '/' + only_filename
             blob = bucket.blob(backup_file)
             blob.upload_from_filename(filename=backupfilename)
   EOF
   

6. Use either the Gcloud Python libraries or Google Cloud console to list the backup data.

Note: Backing up directly to Cloud Storage buckets by using Cloud Storage FUSE is not supported. However, if you want to use Cloud Storage FUSE, you can mount your Cloud Storage volumes to /hanabackup_gcs and create a script to schedule the movement of your backups from /hanabackup to /hanabackup_gcs. This would replace the operations in the previous two steps.

Restore example

To restore your SAP HANA database from a backup:

1. If the backup files are not available already in the /hanabackup file system but are in Cloud Storage, download the files from Cloud Storage, by running the following script from your operating system bash prompt:

   python - <<EOF
   from google.cloud import storage
   storage_client = storage.Client()
   bucket = storage_client.get_bucket("hanabackup")
   blobs = bucket.list_blobs()
   for fileblob in blobs:
     blob = bucket.blob(fileblob.name)
     fname = str(fileblob.name).split('/')[-1]
     blob.chunk_size=1<<30
     if 'log' in fname:
         blob.download_to_filename('/hanabackup/log/H2D/' + fname)
     else:
         blob.download_to_filename('/hanabackup/data/H2D/' + fname)
   EOF
   

2. To recover the SAP HANA database, click Backup and Recovery > Recover System:

   

3. Click Next.

4. Specify the location of your backups in your local filesystem and click Add.

5. Click Next.

6. Select Recover without the backup catalog:

   

7. Click Next.

8. Select File as the destination type, then specify the location of the backup files and the correct prefix for your backup. (In the backup example, remember that you used COMPLETE_DATA_BACKUP as the prefix.)

9. Click Next twice.

10. Click Finish to start the recovery.

11. When recovery completes, resume normal operations and remove backup files from the /hanabackup/data/[SID]/* directories.

What's next

You might find the following standard SAP documents helpful:

• SAP HANA Library
• SAP ONE Support Launchpad

You might also find the following Google Cloud documents useful:

• Signing up for free trial
• Getting started with Google Cloud
• Compute Engine
• Persistent Disk