Let's finish off this module by looking at an example of creating

complex Windows infrastructure on Google flatform.

Typically, setting up an environment with

highly available SQL server deployment on premises,

would start with a purchase order and take many weeks to complete.

On GCP, you'll be able to harness an entire launcher solution and with just a few clicks,

your provision the entire enter and configuration.

Mission critical SQL server work loads,

require support for high availability and disaster recovery.

To achieve this, Google Cloud platform supports Windows Server Failover Over Clustering,

WSFC and SQL Server always on availability groups.

Always On Availability Groups,

the SQL server's flagship high availability disaster recovery solution,

allowing you to configure replicas for automatic failover,

in the case of failure.

These replicas can be readable allowing you to offload,

real workloads, and backups.

Compute engine users can now configure always on availability groups.

This includes configuring replicas on virtual machines in different isolated servers,

as described in this reference architecture.

In this reference architecture,

you'll need two custom server networks.

Each will hold a SQL Server Instance.

We also need an active directory,

as with most typical windows workloads will

promote this domain controller to also be the DNS Server.

SQL Server nodes need to join the active directory and update their own DNS settings.

When you build the WSFC and availability groups using these two nodes,

since we're using static IP addresses,

the system will ask you to specify cluster IP, unless no IP addresses.

We need to configure these using Google Compute Engines Advanced Routing.

So the packet can be forwarded to the appropriate node.

This configuration offers Regional high availability.

Well, you could create two networks in the same zone.

This won't handle zone level failure.

We need two or more custom networks,

because the system has built a multi-site failover clustering.

It also means that SQL clients need to support

multisubnetfailover for the optimal failure time.

When Google have tested this,

it can usually complete failover within 15 seconds.

When it comes to IP addresses,

type networking is very different from

the on premises network environments we're used to.

At a high level,

Google compute engine networking is like a big layer three switch.

JCP and similar everyday features,

work differently from how you might

expect based on your on premise networking experience.

Google compute engine networking doesn't know about cluster virtual IP addresses,

such as the SQL server availability group listener.

It won't automatically assign a new IP address to the VM.

As we configured compute engine advance routing,

the list of IP address must,

by definition, be outside of any Google compute engine network address range.

However, from the perspective of Windows running inside the VM,

it has to be in the same Supnet ranges the primary internal IP for the virtual machine.

Here's a typical network configuration that Google recommends for use in the scenario.

There are two subnets 10.1.0.0/24 and 10.2.0.0/24.

On the virtual machine side,

the VM network configuration has a subnet mask is 255.255.0.0.

So the virtual machine view of

the network is a superset of the Google compute engine sub network view.

When we pick up the list of IP address,

we just need to pick up an address which is outside of the compute engine subnetwork.

But inside the virtual machines, subnet masks.

Look at listener's IP address one as an example.

This is 10.1.1.5, which is outside of the Google compute engine subnet,

but it is the same network as the internal lP address

10.1.0.4 from the virtual machine perspective.

High-Availability SQL Server on GCE

Develop and Deploy Windows Applications on Google Cloud Platform

与讲师见面