(gears whirring)
- Coming up, we look at the fastest and largest
memory-optimized virtual machines in the cloud,
with the availability of six terabyte and twelve terabyte
Mv2 VMs in Azure, ideal for running SAP HANA
and large-scale business-critical workloads.
With the Mv2 series based on Intel Xeon Platinum processors,
you can now create virtual machines with
up to 416 virtual cores
and 12 terabyte RAM on demand,
offering simplified management through the Azure portal.
Combined with Azure Premium storage and Write Accelerator,
you can achieve sub-millisecond write performance
for your SAP HANA database transactions.
Until now, for on-premises infrastructure at this scale,
you had to run on bare metal,
which you would end up having to maintain yourself.
This often resulted in paying for idle
or under-utilized hardware in your data center.
Using Mv2 VMs, large-scale SAP HANA deployments
can take advantage of being able to scale easily
from three terabytes all the way up to 12 terabytes,
or scale down seamlessly to meet your business needs.
This also increases your agility.
You can speed up SAP release cycles by spinning up
delta systems in minutes and pay only for what you use.
Let's put it to the test.
Here, I have a Mv2 VM running SAP HANA
with three terabytes of memory
that you can see in the Azure portal.
Now, let's look at our HANA database in HANA Studio.
I can see the database memory size here,
along with the status.
So now I'm going to show you how to easily
scale up this environment to keep up with demand.
First, we'll gracefully shutdown the database,
resize the virtual machine,
and then bring the database back online.
Starting in HANA Studio, I will right-click on the database,
select Configuration and Monitoring, and Stop System.
Now, that will shut down HANA.
Let's go back to our VM in the Azure Portal
and select the size tab.
And here, you can see that
there are three, six, and 12 TB options
with up to 416 cores.
Let's choose the 12 TB, or 11,400 gibibytes option,
and click Resize.
This will reboot the virtual machine
with the increased memory size.
Usually, you would do this
during a defined maintenance window
in off-peak hours.
You could also accomplish this with zero downtime
in a HA environment by resizing your secondary VM,
failing over the web, and then resizing your primary.
Now our resizing is complete. And in our case, in reality,
it took around 10 minutes and we can see that
our VM now has 12 terabytes of memory.
Lets use HANA studio, and bring HANA database back online.
I'll perform the reverse steps of what you saw earlier
and click Restart System.
And in a moment, you will see
that everything is back up and running successfully
in our 12 terabyte VM.
I just showed you scaling up,
but you can also scale down just as easily.
Back in the Azure portal,
I'll scale the VM down to six terabytes.
And in roughly the same amount of time
it'll resize the virtual machine seamlessly.
Now beyond scalability, these mission critical environments
also need to be designed for high availability.
One of the ways you can increase availability of your system
is by leveraging Azure availability zones.
This works by running a primary and a secondary replica
of your instance in two different Azure data centers
within the same Azure region.
This means, if anything happens to the data center
with the primary instance, services will continue
to run via the secondary instance
without incurring down time
and reaching 99.99% availability.
Let me show you how this works.
As you can see here, I have two Mv2 Virtual machines,
HANA1 and HANA2, running a clustered HANA database.
HANA1 is currently primary, HANA2 is the secondary.
Each are running in different Azure zones
within the same region.
In HANA studio, if I click into the landscape,
I can also see HANA1 and HANA2.
Before I force a failover event, I'll open SAP GUI
and begin an SAP user transaction.
I'm going to change this user's first and last name
without committing the change.
Here, we want to show that this is available
after we have failed over to the secondary.
So, I'll minimize the window,
get to my script on the desktop,
and run it.
This will force the failover from HANA1 to HANA2.
And in just a moment, you'll see
it has failed over successfully.
As proof, in SAP HANA studio,
we'll see HANA2 is now the primary
and is running successfully.
So lets go back to our SAP GUI.
I can see my transaction and I'll hit save.
Because the session persists,
the transaction completed successfully.
I've shown you how you can seamlessly scale-up
SAP HANA databases on Azure Mv2 VMs
and also architect highly available database clusters
with near zero down time for business continuity.
If you are a SAP costumer,
check out our certifications at aka.ms/SAPcert
and you can start using it today.
To learn more,
check out azure.com/SAP and github.com/SAPHANA
Thanks for watching.
(whirring gears)
(upbeat electronic music)