Azure | SIOS SANless clusters

Toyo Gosei Ltd. Migrates SAP Enterprise System to Azure

April 26, 2020 by Jason Aw Leave a Comment

Toyo Gosei Ltd. Migrates SAP Enterprise System to Azure: To Build a “System That Never Stops” With Replication

“”We got several proposals for both on-premises and cloud, and decided to migrate to Microsoft Azure with Fujitsu’s proposal of SIOS DataKeeper – that best fits our requirements,” said Akihiko Kobayashi, a System Representative.

Toyo Gosei is a long-established chemical manufacturer that has been operating business for 65 years. The company’s main product, photosensitive materials for photoresist, is an indispensable material for manufacturing liquid crystal displays and semiconductor integrated circuits. The company is also focusing on technological development for the most advanced photosensitive materials.

In 2007, the company was required to select the successor system of GLOVIA/Process C1, which had been used as a core business system. While receiving proposals from several companies, they chose to introduce “SAP,” an ERP system of German company SAP because of its solid J-SOX support. Time passed and around 2015, the servers installed when introducing SAP had come to the end of maintenance.

IT Infrastructure

The company’s IT infrastructure is an on-premises VMware-based data center and a remote data center for business continuity/disaster protection. Since most of their applications run on the Microsoft Windows operating system, they used guest-level Windows Server failover clustering in their VMware environment to provide high availability and disaster protection.

The Challenge – Migrating to Azure

Behind the migration to cloud, there were needs to be free from on-premises system maintenance, demands for flexibility of scale-up and preparing for disaster based on the experience during the Great East Japan Earthquake.

Their decision to go to cloud was driven by the fact that the servers in their premises physically moved during the earthquake and it almost led to a failure.

When migrating to Azure, the company built a backup system to address system failures and in case of disasters. “SAP has all the data necessary for our business. If SAP stops, the production process also stops. If the outage continues for two or three days, shipment, payment and billing is also stopped. The SAP system cannot be stopped,” said Kobayashi.

The first step was to set up a SAP backup system on Azure to take a daily backup of the production system in the East Japan region of Azure and a weekly backup of the standby system in the West Japan region.

Implementation

“However, backup is just a backup. Basically we need to make production system redundant in order to prevent it from stopping. On AWS, which was used for information systems, shared disks were available with a redundant configuration. However, Azure does not support shared disks. For this reason, we decided to use DataKeeper of SIOS Technology that enables data replication on Azure,” said Kobayashi.

They created a cluster configuration between storage systems connected to the redundant SAP production system and replicate the data using DataKeeper to make it consistent. This provides the same availability as when using shared disks even on Azure where shared disk configuration is not supported.

“We have been in stable operations after the initial stage where a failover occurred,” said Kobayashi. “Regarding SIOS DataKeeper, the only thing we have to do is renew the maintenance contract.”

The Results

As a mid-term plan in the future, they need to prepare for the “SAP 2025 problem” where support for the current SAP version will expire. They have not built a specific plan, but Kobayashi said, “when moving to the new architecture S/4HANA and if clustering is required, we will implement SIOS DataKeeper because we trust it.“

SIOS DataKeeper is a reliable partner for Kobayashi. “Because you cannot stop the production system, it is IT personnel’s responsibility to choose a reliable tool,” he said.

Get a Free Trial of SIOS DataKeeper

Learn more about SAP high availability on Azure

Download the PDF version of the Case Study

Achieving Application Consistent Recovery Points of SQL Server 2008 R2 With Azure Site Recovery In Azure

June 20, 2019 by Jason Aw Leave a Comment

Achieving Application Consistent Recovery Points of SQL Server 2008 R2 With Azure Site Recovery In Azure

If you want to use ASR to replicate SQL Server 2008 R2 standalone or clustered instances, you will need to update the SQL Writer to 2012 or later.

You can use SQL express version as it is a free download.

https://www.microsoft.com/en-us/download/details.aspx?id=29062

Once downloaded, navigate to the download location and run the executable with /x. This will give you an option to specify a location to extract the files to.

ENU\x64\SQLEXPRADV_x64_ENU.exe /x

Once the extraction completes, navigate to the extracted location and the following location:

SQL\1033_enu_lp\x64\setup\x64

Within that folder you should find SQLWriter.msi. Run this on the system where you want to update the SQL writer.

You now will be able to use ASR to do application consistent recovery points of SQL Server 2008 R2.

Reproduced with permission from Clusteringformeremortals.com

New Azure “SQL Server Settings” Blade In The Azure Portal

May 30, 2019 by Jason Aw Leave a Comment

New Azure “SQL Server Settings” Blade In The Azure Portal

There is a new blade in the Azure portal when creating a new SQL Server virtual machine. I’ve been looking for an announcement regarding this new Azure portal experience but to no avail. This feature wasn’t available when I took the screen shots for my last post on creating a SQL Server 2008 R2 FCI in Azure on April 19th. I presume it must be relatively new.

Most of the settings are pretty self explanatory. Under Security and Networking, you can specify the port you want SQL to listen on. It also appears as if the Azure Security Group will be updated to allow different levels of access to the SQL instance: Local, Private or Public. Authentication options are also exposed in this new SQL Server settings blade.

Security, Networking and Authentication options are part of your SQL Server deployment

The rest of the features include licensing, patching and backup options. In addition, if you are deploying the Enterprise Edition of SQL Server 2016 or later, you also have the option to enable SQL Server R Services for advanced analytics.

Licensing, Patching, Backup and R Services options can be automatically configured

All of those options are welcome additions to the Azure portal experience when provisioning a new SQL Server instance. I’m sure the seasoned DBA probably has a list of a few dozen other options they would like to tweak before a SQL Server deployment, but this is certainly a step in the right direction.

Storage Configuration Options

The most interesting new feature I have found on this blade is the Storage Configuration option.

When you click on Change Configuration, you get the following blade.

As you slide the IOPS slider to the right you will see the number of data disks increase, the Storage Size increase, and the Throughput increase. You will be limited to the max number of IOPS and disks supported by that instance size. You see in the screenshot below I am able to go as high as 80,000 IOPS when provisioning storage for a Standard E64-16s_v3 instance.

The Standard E64-16s_v3 instance size supports up to 80,000 IOPS

There is also a “Storage optimization” option. I haven’t tried all the different combinations to know exactly what the Storage optimization setting does. If you know how the different options change the storage configuration, leave me a comment, or we will just wait for the official documentation to be released.

For my test, I provisioned a Standard DS13 v2 instance and maxed out the IOPS at 25600, the max IOPS for that instance size. I also optimized the storage for Transactional processing.

I found that when this instance was provisioned, six P30 premium disk were attached to the instance. This makes sense, since each P30 delivers 5000 IOPS, so it would take at least six of them to deliver the 25,600 IOPS requested. This also increased the Storage Size to 6 TB, since each P30 gives you one 1 TB of storage space. The Read-only host caching was also enabled on these disks.

The six disks were automatically provisioned and attached to the instance

I logged in to the instance to see what Azure had done with those disk. Fortunately, they had done exactly what I would have done; they created a single Storage Pool with the six P30 disks and created a Simple (aka, RAID 0) Storage Space and provisioned a single 6 TB F:\ drive.

This storage configuration wizard validates some of the cloud storage assumptions I made in my previous blog post, Storage Considerations for Running SQL Server in Azure. It seems like a single, large disk should suffice in most circumstances.

A Simple Storage Space consisting of the six P30s are presented as a single F:\ drive

This storage optimization is not available in every Azure Marketplace offering. For example, if you are moving SQL Server 2008 R2 to Azure for the extended security updates, you will find that this storage optimization in not available in the SQL2008R2/Windows Server 2008 R2 Azure Marketplace image. Of course, Storage Spaces was not introduced until Windows Server 2012, so that makes sense. I did verify that this option is available with the SQL Server 2012 SP4 on Windows Server 2012 R2Azure Marketplace offering.

There is a minor inconvenience however. In addition to adding this new Storage configuration option on SQL Server settings blade, they also removed the option to add Data Disks on the Disks blade. Let’s say I wanted to provision additional storage without creating a Storage Space. To do that, I would have to create the instance first and then come back and add Data disks after it the virtual machine is provisioned.

Final Thoughts

All of the SQL Server configuration options in this new Azure blade are welcome additions. I would love to see the list tunable settings grow. Information text should include guidance on current best practices for each tunable.

What SQL Server or Windows OS tunables would you like to see exposed as part of the provisioning process to make your life as a DBA easier? These tunables make your life easier. They would also make the junior DBA look like a season pro by guiding them through all the current SQL Server configuration best practices.

I think the new Storage configuration option is probably the most compelling new addition. Prior to the Storage configuration wizard, users had to be aware of the limits of their instance size, the limits of the storage they were adding. On top of that, have the wherewithal to stripe together multiple disks in a Simple Storage Space to get the maximum IOPS. A few years ago, I put together a simple Azure Storage Calculator to help people make these decisions. My calculator is currently outdated. That said, this new Storage configuration option may make it obsolete anyway.

I would love to see this Storage configuration wizard included as a standard offering in the Disks blade of every Windows instance type. Instead in just the SQL Server instances. I would let the user choose to use the new Storage configuration “Wizard” experience. Or even the “Classic” experience where you manually add and manage storage.

Reproduced with permission from Clusteringformeremortals.com

Webinar: Failover Clustering in the Cloud – Understanding Your Options

May 24, 2019 by Jason Aw Leave a Comment

Failover Clustering in the Cloud – Understanding Your Options

Webinar: Failover Clustering in the Cloud – Understanding Your Options

Windows Server 2016 introduced Storage Spaces Direct, to allow for shared storage in Azure that could help with building and configuring a Windows cluster in the cloud. While this sounded like a killer feature (and it can be with proper infrastructure) it runs into challenges in cloud environments with limited bandwidth available for both storage and data traffic.

In this webinar, you will learn about the configuration of clusters in the cloud, some real-world examples of problems, and alternatives for maintaining a shared storage infrastructure within Azure.

Register Webinar: Failover Clustering in the Cloud – Understanding Your Options

Multi-Instance SQL Server Failover Cluster With New Azure ILB Feature

April 14, 2019 by Jason Aw Leave a Comment

New Azure ILB Feature Allows You To Build A Multi-Instance SQL Server Failover Cluster

At Microsoft Ignite this past September, Microsoft made some announcements around Azure. One of these announcements was the general availability of multiple VIPs on internal load balancers. Why is this so important to a SQL Server DBA? Well, up until now if you want to deploy highly available SQL Server in Azure you were limited to a single SQL Server FCI per cluster or a single Availability Group listener.

This limitation forced you to deploy a new cluster for each instance of SQL Server you wanted to protect in a Failover Cluster. It also forced you to group all of your databases into a single Availability Group if you wanted automatic failover and client redirection in your AlwaysOn AG configuration.

How To Get Out Of These Restrictions?

Those restrictions have now been lifted with these new ILB features. In this post I am going to walk you through the process of deploying a SQL Server FCI in Azure that contains two SQL Server instances. In a future post I will walk you through the same process for SQL Server AlwaysOn AG.

Let’s Start With A Multi-Instance SQL Server Failover Cluster

Build a basic, single instance SQL Server FCI in Azure as I describe in my post Deploying Microsoft SQL Server 2014 Failover Clusters in Azure Resource Manager .

That post describes the process of creating the Multi-Instance SQL Server Failover Cluster. Using DataKeeper to create the replicated volume resources used in the cluster, try creating the Internal Load Balancer (ILB) and then fixing the SQL Server Cluster IP Resource to work with the ILB. If you want to skip that process and jumpstart your configuration you can always use the Azure Deployment Template that creates a 2-Node SQL Server FCI using SIOS DataKeeper

Assuming you now have a basic two node SQL Server FCI, the steps to add a 2^nd named instance are as follows:

Create another DataKeeper Volume Resource on another volume that is not currently being used. You may need to add additional disks to your Azure instance if you have no available volumes. As part of this volume creation process the new DataKeeper Volume resource will be registered in Available Storage in the cluster. Refer to the article referenced earlier for the details.
Install a named instance of SQL Server on the first node, specifying the DataKeeper Volume that we just created as the storage location.
“Add a node” to the cluster on the second node.
Lock down the port number of this new named instance to a port that is not in use. In my example I use port 1440.

Adjust ILB To Second Instance

Next we have to adjust the ILB to redirect traffic to this second instance. Here are the steps you need to follow:

Add a frontend IP address that is identical to the SQL cluster IP address you used for the second instance of SQL Server as shown below.

Multi-Instance SQL Server Failover Cluster With New Azure ILB Feature

Next, we will need to add another probe since the instances could be running on different servers. As shown below, I added a probe that probes port 59998 (instead of the usual 59999). We will need to make sure the new rules reference this probe. We will also need to remember that port number since we will need to update IP address associated with this instance during the last step of this process.

Multi-Instance SQL Server Failover Cluster With New Azure ILB Feature

Now we need to add two new rules to the ILB to direct traffic destined for this 2^ndinstance of SQL. Of course we need to add a rule to redirect TCP port 1440 (the port I used for the named instance of SQL), but because we are now using named instances we will also need to have a port to support the SQL Server Browser Service, UDP Port 1434.

In the picture below depicting the rule for the SQL Server Browser Service, take note that the Front End IP Address is referencing the new FrontendIP address (10.0.0.201), UDP port 1434 for both the Port and Backend Port. In the pool you will need to specify the two servers in the cluster, and finally make sure you choose the new Health Probe we just created.

Multi-Instance SQL Server Failover Cluster With New Azure ILB Feature

We will now add a rule for TCP/1440. As show in the picture below, add a new rule for port TCP 1440, or whatever port locked down for the named instance of SQL Server. Again, be sure to choose the new FrontEnd IP Address and the new Health Probe (59998). Also, make sure the Floating IP (direct server return) is enabled.

Multi-Instance SQL Server Failover Cluster With New Azure ILB Feature

The Last Step

Now that the load balancer is configured, the final step is to run the PowerShell script to update the new Cluster IP address associated with this 2^nd instance of SQL Server. This PowerShell script only needs to be run on one of the cluster nodes.

# Define variables

$ClusterNetworkName = “”

# the cluster network name 
(Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)

$IPResourceName = “”

# the IP Address resource name of the second instance of SQL Server

$ILBIP = “”

# the IP Address of the second instance of SQL, 
which should be the same as the new Frontend IP address as well

Import-Module FailoverClusters

# If you are using Windows Server 2012 or higher:

Get-ClusterResource $IPResourceName | 
Set-ClusterParameter -Multiple @{Address=$ILBIP;ProbePort=59998;
SubnetMask="255.255.255.255";Network=$ClusterNetworkName;EnableDhcp=0}

# If you are using Windows Server 2008 R2 use this:

#cluster res $IPResourceName /priv enabledhcp=0 address=$ILBIP probeport=59998  
subnetmask=255.255.255.255

You now have a fully functional multi-instance SQL Server FCI in Azure. Let me know if you have any questions to build a Multi-Instance SQL Server Failover Cluster With New Azure ILB Feature

Reproduced from Clusteringformeremortals.com