My name is Rozal Singh,
and I'm a Solutions Architect on the SAP team at AWS.
SAP applications support various databases such as SAP HANA,
and these databases are often backed up
directly to an on-premises file server.
However, customers often run out of capacity
on their on-premises storage arrays
and face expensive hardware replacement cycles
every three to five years.
Many on-premises file workloads like web servers, logging,
and database backups do not need expensive storage arrays.
I'm going to show you how to establish a hybrid backup strategy
for your SAP databases using AWS Storage Gateway.
There are three types of Storage Gateways offered by AWS:
file, volume, and tape.
Today, we'll be using File Gateway.
With a File Gateway, you store and retrieve objects
in Amazon S3 with a local cache for low-latency access
to your most recently used data.
This enables you to leverage cost effective, flexible,
and secure Amazon S3 storage for your SAP database backups,
helping you reduce your storage footprint.
This architecture supports several popular use cases
such as, number one, some customers will still run production
SAP landscapes on-premises and non-production on AWS.
Taking the backups to AWS via Storage Gateway
helps them carry out SAP QA system refreshes.
Number two, another use case is setting up
demo or POC environments on AWS
using database backups from their on-prem databases.
Number three, homogenous migration from on-premises to AWS
is a use case that leverages database backup or restore.
Number four, customers are moving older backups
or archive data to low-cost storage classes such as Amazon Glacier.
Leveraging Storage Gateway allows them to free on-premises
storage and benefit from the durability of Amazon S3.
Let's get started.
Please read the AWS Storage Gateway documentation
beforehand if you are unfamiliar.
Let's look at the architecture for Storage Gateway, File Gateway.
In this demo, I'll be using an SAP HANA database,
but the steps remain the same for other SAP-supported databases
such as Oracle, SQL Server, SAP ASC, MaxDB and DB2.
In this architecture, I will simply be moving my data
from one AWS region to another, but the process will be the same
when moving the data from on-prem to AWS.
I'll be using Storage Gateway, File Gateway to present my S3 bucket
to this EC2 instance where my HANA database
is running as an NFS mount point, and I'll be triggering the backups,
which will first be stored on the local cache,
and then will be moved asynchronously to the Amazon S3 bucket.
You can further optimize costs
by leveraging Amazon S3 lifecycle policies
and move the older backups to any S3 storage class.
Now, let's look at the steps
to implement Storage Gateway, File Gateway.
Within the AWS Console,
we'll go to services and search for Storage Gateway.
When this opens, click on Get Started,
then select File Gateway, and click on Next.
Select the host platform.
In this case, I'm selecting Amazon EC2, and click Next.
Now we need to select our service endpoints.
There're a few options: public, FEPS or VPC.
In this case, we will select VPC
and provide the DNS for the VPC endpoint.
Click on Next.
Type the IP address of your gateway virtual machine.
Your web browser must be able to connect to this IP address.
Click on Connect to Gateway.
Now, you're ready to activate the gateway,
but before that, type in the gateway name,
and then we'll also be using tags.
In this case, we'll be using a couple of tags.
Update the gateway time zone.
Here, we'll be selecting Eastern Time,
and then click on Activate Gateway.
We can now configure our local disks.
Choose the disk type cache for all the disks.
Click on configure logging.
You have some options here.
You can create a new log group to monitor the gateway health,
you can use an existing group, or you can disable it.
For this demo, we are creating a new log group.
Click on Save and Continue.
Once the gateway is created, you can see its details.
You can also look at additional tabs like tags and monitoring.
Check the configuration of your gateway.
Now, it's time to create a file share using Storage Gateway, File Gateway.
Type in the S3 bucket name we created in the Oregon region
with the S3 prefix name, go to services, and search for S3.
Here, I've created a bucket name called Storage Gateway
HANA back, and then we'll go back to the Storage Gateway.
Type in the S3 bucket name, the prefix, file share name,
leave the other settings as they are, select the file share protocol,
select the gateway instance, add tags, if necessary.
Click on Next.
On the next screen, we stick with the default values,
but you can change based on your requirements.
Click Next, review all the parameters you have set up,
and then click on Create File Share.
Now, you have created the file share and we can check all the details,
which also lists all the commands that are required
to mount this particular file share on an EC2 instance
or your on-premises virtual machine.
Here, I'm logging on to my HANA database,
which is running on an SAP-certified EC2 instance,
to create a directory for my backups.
We can connect to the file share here.
With the commands provided, mount the file share on the SAP
HANA database instance and not Virginia region.
Create a directory, update the EDC FS tab,
and mount the NFS.
Check if the NFS is mounted, which it is.
Now, let's trigger the backups using SAP HANA Studio.
You can also use Cockpit or STB Sequel as well.
In this case, we are triggering backups of the system database,
first using HANA studio,
and we'll make the backup destination the NFS mount point,
which is pointing to the S3 bucket.
Once my system database is successfully backed up,
I will also backup my tenant database.
I’ll be backing these up to the same location.
After the backups are successful, let's go back to the HANA database
and check that the backups are successfully stored
in my NFS mount point, which is pointing to the S3 bucket.
First, we will check the system database backups,
and then we will check the tenant database backups.
Now, let's check if the backups were moved successfully
to the S3 bucket, which is in the Oregon region.
So, we go to the system database backups and click on refresh and,
as you can see, the backups have been moved successfully to the S3 bucket,
which is in the Oregon region.
Now, let's go back and check the tenant database backups.
Let's do a refresh and, as you can see,
the tenant database backups have also been moved to the S3 bucket.
So, we now have both our system database and tenant database
backups moved to an S3 bucket in Oregon
from an SAP HANA database, which is in North Virginia.
You can extend the same solution to on-premises
and move your backups to AWS by using AWS
Storage Gateway, File Gateway.
Today, you've learned how to establish
a hybrid storage architecture for SAP HANA database with Storage Gateway.
The same strategy can be extended
to other SAP-supported databases as well.
File Gateway does allow you to replace your entry-level
and mid-range on-premises NASS with cloud-backed storage,
with the additional benefit of getting access to data
in the cloud for further processing.
The cache provides low latency access to the working data set,
and you’d get the elasticity of cloud storage.
Now, you can take your on-premises SAP backups
to Amazon S3 using Storage Gateway.
To get started, visit aws.amazon.com/storagegateway.