Opinions, tips, and news orbiting Microsoft
First published on TECHNET on Feb 23, 2016
Securing privileged access is a critical first step to establishing security assurances for business assets in a modern organization. The security of most or all business assets in an organiza… Continue reading Securing Privileged Access – A practical approach
Here in the Xbox Insider section of the Wire, we make a point of calling out Xbox Insider participation as an important part of successfully launching features, updates, and games on Xbox and PC. Xbox Ideas is a part of this success, enabling our community to make contributions that improve all aspects of the Xbox experience by sharing their ideas. In the spirit of building a better Xbox experience together, we’re inviting you to help test an additional space for Xbox Idea Drives. We’ve recently created a space within the r/XboxInsiders subreddit called the Xbox Idea Hub. The Xbox Idea… Continue reading Help Us Rename “Feature Friday” via the Xbox Idea Hub
First published on MSDN on Jan 16, 2019
Over the years, we have been asked about what some of the Failover Cluster resources/resource types are and what they do. There are several resources that have been asked about on multiple occasi… Continue reading Windows Server 2016/2019 Cluster Resource / Resource Types
First published on MSDN on Nov 01, 2018
For those who attended Microsoft Ignite 2018 in Orlando, Florida, we thank you for making it another huge success.
So much fun was had by all. We had the privilege of showi… Continue reading Microsoft Ignite 2018 Clustering Sessions available
First published on MSDN on Aug 10, 2017
By Amitabh Tamhane
Goals: This topic provides an overview of providing persistent storage for containers with data volumes backed by Cluster Shared Volumes (CSV), Storage Spaces Direct (S2D) and SMB Global Mapping.
Applicable OS releases: Windows Server 2016, Windows Server version 1709
Prerequisites:
Blog:
With Windows Server 2016, many new
infrastructure and application workload features
were added that deliver significant value to our customers today. Amongst this long list, two very distinct features that were added: Windows Containers & Storage Spaces Direct!
Let’s review a few technologies that have evolved independently. Together these technologies provide a platform for persistent data store for applications when running inside containers.
In the cloud-first world, our industry is going through a fundamental change in how applications are being developed & deployed. New applications are optimized for cloud scale, portability & deployment agility. Existing applications are also transitioning to containers to achieve deployment agility.
Containers provide a virtualized operating system environment where an application can safely & independently run without being aware of other applications running on the same host. With applications running inside containers, customers benefit from the ease of deployment, ability to scale up/down and save costs by better resource utilization.
More about
Windows Containers
.
Cluster Shared Volumes (CSV) provides a multi-host read/write file system access to a shared disk. Applications can read/write to the same shared data from any node of the Failover Cluster. The shared block volume can be provided by various storage technologies like Storage Spaces Direct (more about it below), Traditional SANs, or iSCSI Target etc.
More about
Cluster Shared Volumes (CSV)
.
Storage Spaces Direct (S2D) enables highly available & scalable replicated storage amongst nodes by providing an easy way to pool locally attached storage across multiple nodes.
Create a virtual disk on top of this single storage pool & any node in the cluster can access this virtual disk. CSV (discussed above) seamlessly integrates with this virtual disk to provide read/write shared storage access for any application deployed on the cluster nodes.
S2D works seamlessly when configured on physical servers or any set of virtual machines. Simply attach data disks to your VMs and configure S2D to get shared storage for your applications. In Azure, S2D can also be configured on
Azure VMs
that have premium data disks attached for faster performance.
More about
Storage Spaces Direct (S2D)
. S2D Overview
Video
.
With containers, any persistent data needed by the application running inside will need to be stored outside of the container or its image. This persistent data can be some shared read-only config state or read-only cached web-pages, or individual instance data (ex: replica of a database) or shared read-write state. A single containerized application instance can access this data from any container host in the fabric or multiple application containers can access this shared state from multiple container hosts.
With
Data Volumes
, a folder inside the container is mapped to another folder on the container host using local or remote storage. Using data volumes, application running inside containers access its persistent data while not being aware of the infrastructure storage topology. Application developer can simply assume a well-known directory/path to have the persistent data needed by the application. This enables the same container application to run on various deployment infrastructures.
This data volume functionality is great but what if a container orchestrator decides to place the application container to a different node? The persistent data needs to be available on all nodes where the container may run. These technologies together can provide a seamless way to provide persistent store for container fabric.
Using S2D, you can leverage locally attached storage disks to form a single pool of storage across nodes. After the single pool of storage is created, simply create a new virtual disk, and it automatically gets added as a new Cluster Shared Volume (CSV). Once configured, this CSV volume gives you read/write access to the container persistent data shared across all nodes in your cluster.
With Windows Server 2016 (plus latest updates), we now have enabled support for mapping container data volumes on top of Cluster Shared Volumes (CSV) backed by S2D shared volumes. This gives application container access to its persistent data no matter which node the container orchestrator places the container instance.
Configuration Steps
Consider this example (assumes you have Docker & container orchestrator of your choice already installed):
New-Cluster -Name <name> -Node <list of nodes>
(Note: The generic warning text above is referring to the quorum witness configuration which you can add later.)
Enable-ClusterStorageSpacesDirect
or
Enable-ClusterS2D
(Note: To get the optimal performance from your shared storage, it is recommended to have SSD cache disks. It is not a must have for getting a shared volume created from locally attached storage.)
Verify single storage pool is now configured:
Get-StoragePool S2D*
New-Volume -StoragePoolFriendlyName *S2D* -FriendlyName <name> -FileSystem CSVFS_REFS -Size 50GB
Verify new CSV volume getting created:
Get-ClusterSharedVolume
This shared path is now accessible on all nodes in your cluster:
This assumes you have
installed Docker & able to run containers
. Start a container with data volume:
docker run -it –name demo -v C:\ClusterStorage\Volume1\ContainerData:G:\AppData nanoserver cmd.exe
Once started the application inside this container will have access to “G:\AppData” which will be shared across multiple nodes. Multiple containers started with this syntax can get read/write access to this shared data.
Inside the container, G:\AppData1 will then be mapped to the CSV volume’s “ContainerData” folder. Any data stored on “C:\ClusterStorage\Volume1\ContainerData” will then be accessible to the application running inside the container.
Now what if the container fabric needs to scale independently of the storage cluster? Typically, this is possible through SMB share remote access. With containers, wouldn’t it be great to support container data volumes mapped to a remote SMB share?
In Windows Server version 1709, there is a new support for SMB Global Mapping which allows a remote SMB Share to be mapped to a drive letter. This mapped drive is then accessible to all users on the local host. This is required to enable container I/O on the data volume to traverse the remote mount point.
With Scaleout File Server, created on top of the S2D cluster, the same CSV data folder can be made accessible via SMB share. This remote SMB share can then be mapped locally on a container host, using the new SMB Global Mapping PowerShell.
Caution: When using SMB global mapping for containers, all users on the container host can access the remote share. Any application running on the container host will also have access to the mapped remote share.
Configuration Steps
Consider this example (assumes you have Docker & container orchestrator of your choice already installed):
$creds = Get-Credentials
New-SmbGlobalMapping -RemotePath \\contosofileserver\share1 -Credential $creds -LocalPath G:
This command will use the credentials to authenticate with the remote SMB server. Then, map the remote share path to G: drive letter (can be any other available drive letter). Containers created on this container host can now have their data volumes mapped to a path on the G: drive.
Inside the container, G:\AppData1 will then be mapped to the remote share’s “ContainerData” folder. Any data stored on globally mapped remote share will then be accessible to the application running inside the container. Multiple containers started with this syntax can get read/write access to this shared data.
This SMB global mapping support is SMB client-side feature which can work on top of any compatible SMB server including:
Caution: SMB global mapping does not support DFS, DFSN, DFSR shares in Windows Server version 1709.
In Windows Server 2016, container data volumes are now supported on top of Cluster Shared Volumes (CSV). Given that CSV already works with most traditional block storage devices (iSCSI, FCoE). With container data volumes mapped to CSV, enables reusing existing storage topology for your container persistent storage needs.
First published on MSDN on Feb 14, 2017
Authors: Rob Hindman and Subhasish Bhattacharya, Program Manager, Windows Server
In this blog I am going to discuss deployment considerations and scenarios for IaaS VM Guest Clusters in Microsoft Azure.
A guest cluster in Microsoft Azure is a Failover Cluster comprised of IaaS VMs. This allows hosted VM workloads to failover across the guest cluster. This provides a higher availability SLA for your applications than a single Azure VM can provide. It is especially usefully in scenarios where your VM hosting a critical application needs to be patched or requires configuration changes.
Learn more about the advantages of Guest Clustering in this video:
The following Guest Cluster configurations are supported by Microsoft:
A sizable SQL Server FCI install base today is on expensive SAN storage on-premises. In the future, we see this install base taking the following paths:
Deployment guidance for the second path can be found
here
Azure templates decrease the complexity and speed of your deployment to production. In addition it provides a repeatable mechanism to replicate your production deployments.
It is easy to create a Guest Cluster in Azure using these “1-click” templates! Learn more in the following video:
The following are recommended templates to use for your IaaS VM guest cluster deployments to Azure.
Find template
here
Find template
here
Find template
here
MVP, Nirmal Thewarathanthri, provides more guidance
here
and a video below:
Find template
here
Find template
here
Find template
here
It is recommended to use a
Cloud Witness
for Azure Guest Clusters.
There are three options for Cluster Authentication for your guest cluster:
Azure template to create a new Azure VM with a new AD Forest can be found
here
Azure template to create a new AD Domain with 2 Domain Controllers can be found
here
2. Workgroup Cluster
A workgroup cluster reduces the cost of the deployment due to no DC VMs required. It reduces dependencies on Active Directory helping deployment complexity. It is an ideal fit for small deployments and test environments. Learn more
here
.
3. Using Azure Active Directory
Azure Active Directory provides a multi-tenant cloud based directory and identity management service which can be leveraged for cluster authentication. Learn more
here
There are three predominant options for cluster storage in Microsoft Azure:
Creates virtual shared storage across Azure IaaS VMs. Learn more
here
Replicates data in application layer across Azure IaaS VMs. A typical scenario is seen with SQL Server 2012 (or higher) Availability Groups (AG).
3. Volume Replication
Replicates data at volume layer across Azure IaaS VMs. This is application agnostic and works with any solution. In Windows Server 2016 volume replication is provided in-box with
Storage Replica
. 3rd party solutions for volume replication includes SIOS Datakeeper.
The recommended approach to configure the IP address for the VCO (for instance for the SQL Server FCI) is through an Azure load balancer. The load balancer holds the IP address, on 1 cluster node at a time. The below video walks through the configuration of the VCO through a load balancer.
[video width="1920" height="1080" mp4="https://msdnshared.blob.core.windows.net/media/2017/02/LoadBalancer.mp4"][/video]
[video width="1920" height="1080" mp4="https://msdnshared.blob.core.windows.net/media/2017/02/DskSpd.mp4"][/video]
The following are the workload characteristics for which Storage Replica is a better fit than Storage Spaces Direct for your guest cluster.
Remote Desktop Services (RDS) requires a domain-joined file server for user profile disks (UPDs). This can be facilitated by
deploying
a SoFS on a domain-joined IaaS VM guest cluster in Azure. Learn about UPDs and Remote Desktop Services
here
Continue reading Deploying IaaS VM Guest Clusters in Microsoft Azure
First published on MSDN on Oct 10, 2016
I
n a private cloud there may be multi-tier applications which are deployed across a set of virtual machines. Such as a database running in one VM, and an application leveraging that databas… Continue reading Failover Clustering Sets for Start Ordering
First published on MSDN on Sep 23, 2016
I am packing my bags getting ready for Ignite 2016 in Atlanta, and I thought I would post all the cluster and related sessions you might want to check out. See you there!
If you couldn… Continue reading Failover Clustering @ Ignite 2016
