- SharePoint on Windows Azure – Part 2: Storage
- SharePoint on Windows Azure Part 1: Introduction
- SharePoint on Windows Azure – Part 3: Networking
- SharePoint on Windows Azure – Part 4: SharePoint Farm
Letâ€™s review the previous articles in this series:
Part 1: Introduction â€“ We showed how to set up tools to interact with Windows Azure.
Part 2: Storage â€“ We showed how to setup Windows Azure storage, how to upload vhdâ€™s and some tools to manage storage.
Part 3: Networking â€“ We showed how virtual networking works, the advantages of using Cloud Services and how to setup the first virtual machine.
Letâ€™s talk about endpoints, load balancing and probes for a minute since weâ€™ll use this concept a bit later on. By default, when you create a VM an endpoint is automatically created. This is what allows you to use RDP (Remote Desktop Protocol) to connect to your VM. Hereâ€™s how that looks in the management portal:
Windows Azure assigns a random high port number for the public port that maps to the RDP port (3389). If youâ€™re familiar with NAT in networking, this is similar in concept. Note, this one is not load balanced.
So, how do we use this for our SharePoint Farm? To get a load balanced port thatâ€™s publically accessible, we simply define a local port and public port thatâ€™s the same for each VM. For example, we can open port 80 (public) and map it to port 80 (private) for our SharePoint Web Servers. If we do this a second time, Windows Azure recognizes that we want this port to be load balanced against all the virtual machines weâ€™ve specified.
Letâ€™s also take a minute to talk about probes. A probe is a method used to check the health of a server, especially in a load balanced set. For example, you may have 3 SharePoint Web Servers but one of them is down. The probe can detect this and prevent users from hitting that server. This is also useful in cases where you just donâ€™t want users accessing one of the servers (to apply updates, letâ€™s say).
Following the sample from Paul Stubbs, weâ€™ll use this snippet:
Add-AzureEndpoint -Name 'http' -LBSetName 'lbhttp' -LocalPort 80 -PublicPort 80 ` -Protocol tcp -ProbeProtocol http -ProbePort 80 -ProbePath '/healthcheck/iisstart.htm'
In this example, weâ€™re asking Windows Azure to use the â€œhttpâ€ protocol on port 80 and target the iisstart.htm page. For this to work, the machine much have a website at that path thatâ€™s alive. If not, the probe will fail and users wonâ€™t be routed to that machine. For our scenario, weâ€™ll keep the IIS â€œDefault Web Siteâ€ to use for probing purposes.
Now, it gets much easier. Weâ€™re going to provision the rest of the SharePoint Farm. Once again, letâ€™s do a quick connection test. Open Windows Azure PowerShell and type in the following:
Get-AzureSubscription | Select SubscriptionName, CurrentStorageAccount
Hopefully you can still connect. Next, weâ€™ll assign some values to our account variables as we did before. Remember to use the values you got when you ran the last command.
# your imported subscription name $subscriptionName = "Windows Azure Internal Consumption" $storageAccount = "wahidstore" AzureSubscription $subscriptionName Set-AzureSubscription $subscriptionName -CurrentStorageAccount $storageAccount
Now, weâ€™re going to specify parameters for a new Cloud Service. In my previous example, I used CS-ArchSP2013. For this one, Iâ€™m going to call it ArchSharePoint. Use any name thatâ€™s available, to test for available names, use Test-AzureName â€“Service â€˜<your chosen name>â€™
# Cloud Service Paramaters $serviceName = "ArchSharePoint" $serviceLabel = "ArchSharePoint" $serviceDesc = "Cloud Service for SharePoint Farm"
Now, Iâ€™ll specify the networking parameters using the same $vnetname, $ag, and $primaryDNS as before but the other $subnetName I created.:
# Network Paramaters $vnetname = 'vNet-Arch' $subnetName = 'SharePoint' $ag = 'AG-SharePoint-Arch' $primaryDNS = '192.168.1.4'
If youâ€™re creating a brand new farm, rather than using uploaded images, specify these two parameters too:
#VM Image names taken from: Get-AzureVMImage | select Label, ImageName | fl
$sqlimage = 'MSFT__Sql-Server-11EVAL-11.0.2215.0-05152012-en-us-30GB.vhd'
Next, weâ€™ll specify a few availability sets. Think of availability sets as a way to configure high availability. Weâ€™re telling Windows Azure that VMs in an availability set have the same role. This instructs Windows Azure to put these VMs on different racks and/or different servers to avoid any single points of failure.
# Availability Sets $avsetwfe = 'avset-arch-web' $avsetapps = 'avset-arch-apps' $avsetsql = 'avset-arch-sql'
Specify a location for these VMs. Iâ€™ve created a folder under my â€œvhdsâ€ container called â€œArchâ€ and I want these VMs to go there.
# MediaLocation $mediaLocation = "http://wahidstore.blob.core.windows.net/vhds/Arch/"
The next thing weâ€™re going to specify is the VM configuration. Since thereâ€™s a lot going on in the next set of PowerShell scripts, let me explain. The $size variable is self-explanatory. Iâ€™m going to use â€œLargeâ€ which gives me 4 cores and 7 GB of RAM. The recommendation here is to use smaller VMâ€™s that you can scale out (my adding more), rather than Extra Large VMs. You pay for compute hours based on the size, so many times several smaller ones are better than fewer larger ones.
For $vmStorageLocation, weâ€™re going to specify the $mediaLocation above, plus a name for the vhd. If you uploaded VMâ€™s use the name of the vhd you uploaded.
Iâ€™m going to skip it below, but you can use the following command to automate joining the domain by piping it after $vmLocaction:
$vmStorageLocation | Add-AzureProvisioningConfig -WindowsDomain -Password $dompwd ` -Domain $domain -DomainUserName $domuser -DomainPassword $dompwd ` -MachineObjectOU $advmou -JoinDomain $joindom
So, letâ€™s define our VM configuration:
## Create SP Web1 $size = "Large" $vmStorageLocation = $mediaLocation + "Arch-SPWeb1.vhd" $spweb1 = New-AzureVMConfig -Name 'Arch-SPWeb1' -AvailabilitySetName $avsetwfe ` -DiskName $vmStorageLocation -InstanceSize $size | Add-AzureEndpoint -Name 'https' -LBSetName 'lbhttps' -LocalPort 443 -PublicPort 443 ` -Protocol tcp -ProbeProtocol http -ProbePort 80 -ProbePath '/healthcheck/iisstart.htm' | Set-AzureSubnet $subnetName
Note: If youâ€™re creating new VMs, rather than using uploaded VMs, make the following changes.
Â§ Change â€“DiskName $vmStorageLocation to â€“ImageName $spimage (or $sqlimage for the SQL servers).
Â§ After â€“InstanceSize $size, type in â€“MediaLocation $vmStorageLocation
Â§ After Set-AzureSubnet $subnetName, add the following line:
Add-AzureProvisioningConfig -Password ‘pass@word1’ -Windows
We can copy the above set of commands as a template to build out our farm. In my case, Iâ€™ve got another SharePoint Web Server, a SharePoint App Server, and an Office Web Apps server.
## Create SP Web2 $size = "Large" $vmStorageLocation = $mediaLocation + "Arch-SPWeb2.vhd" $spweb2 = New-AzureVMConfig -Name 'Arch-SPWeb2' -AvailabilitySetName $avsetwfe ` -DiskName $vmStorageLocation -InstanceSize $size | Add-AzureEndpoint -Name 'https' -LBSetName 'lbhttps' -LocalPort 443 -PublicPort 443 ` -Protocol tcp -ProbeProtocol http -ProbePort 80 -ProbePath '/healthcheck/iisstart.htm' | Set-AzureSubnet $subnetName ## Create SP App1 $size = "Large" $vmStorageLocation = $mediaLocation + "Arch-SPApp1.vhd" $spapp1 = New-AzureVMConfig -Name 'Arch-SPApp1' -AvailabilitySetName $avsetwfe ` -DiskName $vmStorageLocation -InstanceSize $size | Add-AzureEndpoint -Name 'https' -LBSetName 'lbhttps' -LocalPort 443 -PublicPort 443 ` -Protocol tcp -ProbeProtocol http -ProbePort 80 -ProbePath '/healthcheck/iisstart.htm' | Set-AzureSubnet $subnetName ## Create WAC $size = "Large" $vmStorageLocation = $mediaLocation + "Arch-WAC1.vhd" $wac1 = New-AzureVMConfig -Name 'Arch-WAC1' -AvailabilitySetName $avsetwfe ` -DiskName $vmStorageLocation -InstanceSize $size | Add-AzureEndpoint -Name 'https' -LBSetName 'lbhttps' -LocalPort 443 -PublicPort 443 ` -Protocol tcp -ProbeProtocol http -ProbePort 80 -ProbePath '/healthcheck/iisstart.htm' | Set-AzureSubnet $subnetName
Similarly, Iâ€™m going to specify the configuration for the SQL Server. Thereâ€™s not much different here except that I donâ€™t need to create an endpoint. However, I do want to create a data disk. Refer to Part 2 on storage for an explanation:
## Create SQL Server1 $size = "Large" $vmStorageLocation = $mediaLocation + "Arch-SQL1.vhd" $spsql1 = New-AzureVMConfig -Name 'Arch-SQL1' -AvailabilitySetName $avsetsql -DiskName $vmStorageLocation -InstanceSize $size | Add-AzureDataDisk -CreateNew -DiskSizeInGB 100 -DiskLabel 'data' -LUN 0 â€“HostCaching â€œNoneâ€ | Set-AzureSubnet $subnetName
Now, DOUBLE-CHECK everything before you move forward. Undoing this configuration can be complicated. We have just created our configurations, nothing has actually happened just yet, thatâ€™s whatâ€™s the following commands do:
$dns1 = New-AzureDns -Name 'DNS1' -IPAddress $primaryDNS New-AzureVM -ServiceName $serviceName -ServiceLabel $serviceLabel ` -ServiceDescription $serviceDesc ` -AffinityGroup $ag -VNetName $vnetname -DnsSettings $dns1 ` -VMs $spweb1,$spweb2,$spapp1,$wac1, $spsql1
Hit Enter and away it goes. If you run into any problems, Iâ€™ll try to cover the ones Iâ€™ve encountered in the next article. If everything went smooth, youâ€™ll see something like the screenshot below. This will take a few minutes, sit back and enjoy some coffee or something. In my demo, this was taking a while on the second VM and I really wanted to hit CTRL+C or something, DONâ€™T â€“ just be patient.