SPF – Tech-Coffee //www.tech-coffee.net Tue, 19 Dec 2017 09:46:59 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.1 65682309 Windows Azure Pack and VM Clouds in High Availability //www.tech-coffee.net/windows-azure-pack-vm-clouds-high-availability/ //www.tech-coffee.net/windows-azure-pack-vm-clouds-high-availability/#respond Mon, 13 Oct 2014 11:27:19 +0000 //www.tech-coffee.net/?p=2661 When the Windows Azure Pack is installed for production, the access to the cloud services should be accessible 99,9% of the time. To implement this service level, the Windows Azure Pack has to be deployed with high availability mechanisms as Load-Balancing, SQL AlwaysOn and so on. The below schema shows the Windows Azure Pack deployment ...

The post Windows Azure Pack and VM Clouds in High Availability appeared first on Tech-Coffee.

]]>
When the Windows Azure Pack is installed for production, the access to the cloud services should be accessible 99,9% of the time. To implement this service level, the Windows Azure Pack has to be deployed with high availability mechanisms as Load-Balancing, SQL AlwaysOn and so on.

The below schema shows the Windows Azure Pack deployment in high availability that I have made on my mockup.

The Cluster-THUB hosts the below tenant web services:

  • Tenant public API (DNS alias: api.home.net);
  • Tenant authentication site (DNS Alias: auth.home.net);
  • Management portal for tenants (DNS alias: www.home.net).

The Cluster-AHUB hosts the below privileges web services:

  • Admin API (DNS Alias: wapadminapi.home.net);
  • Tenant API (DNS Alias: waptenantapi.home.net);
  • Admin authentication site (DNS Alias: wapadminauth.home.net);
  • Management portal for administrators (DNS Alias: wapadmin.home.net).

The SQL Server Availability Group AAGWAP01 hosts databases for Windows Azure Pack while AAGWAP02 hosts databases for SPF, SMA, and Websites. In this topic I don’t approach the installation and the configuration of SQL Server AlwaysOn. For more information about AlwaysOn topic, please read this article.

To implement load-balancing, I use the NLB feature included in Windows Server. For company that already have a load-balancing appliance such as F5, of course you can use it instead of NLB (and I recommend to use a dedicated load balancing appliance for intensive environment).

To deploy the infrastructure described above, first I have installed the SQL Always On. Then I have installed the Windows Azure Pack on servers.

Public services installation and configuration

Installation

To install the public services, please read the part “Public Services Installation” of this topic. Follow this procedure for each node that hosts public services. When you are on Database Server Setup screen, specify the same database information on each node. The database server name should be an AlwaysOn Availability Group (AAG) Listener. For me, the database server name is AAGWAP01.home.net.

NLB feature configuration

In the below screenshot you can see the Cluster-THUB. VMWAP01-THUB01 and VMWAP02-THUB02 are part of the cluster. These servers host public services of the Windows Azure Pack.

The Cluster-THUB is bound on the IP address 10.10.3.100.

I have configured the cluster operation mode to Multicast. Be careful, if you use unicast and Virtual Machine, don’t forget to enable the Mac Spoofing feature in your Virtual Machine configuration.

To finish with NLB, I have configured the port rules to load-balance equally across all members the traffic when it comes on port TCP 443.

DNS aliases

Next I have configured DNS aliases to the cluster cluster-thub.home.net. So I have just added entries in the DNS as below:

Certificates

Regarding certificates, one are needed per node which is a member of the load-balancing cluster. I have duplicated the Web Server certificate template in Active Directory Certificate Service. The issued to field contains the FQDN of the server. Next I have added each DNS alias in the Subject Alternative Name as below. In this way, the certificate can be used for all web services. For further information about certificate template, you can read this topic.

IIS binding configuration

Next, on each node I have reconfigured the site binding for tenant public API, tenant authentication site and management portal for tenants. As a reminder, below you can find the DNS aliases related the web services that I have set on my infrastructure:

  • Tenant public API (DNS alias: api.home.net);
  • Tenant authentication site (DNS Alias: auth.home.net);
  • Management portal for tenants (DNS alias: www.home.net).

Repeat this procedure for each node with the same configuration except the SSL certificate.

Privileged services installation and configuration

Installation

To install the public services, please read the part “Privileged services Installation” of this topic. Follow this procedure for each node that hosts privileged services. When you are on Database Server Setup screen, specify the same database information on each node. The database server name should be an AlwaysOn Availability Group (AAG) Listener. For me, the database server name is AAGWAP01.home.net.

NLB feature configuration

In the below screenshot you can see the Cluster-AHUB. VMWAP03-AHUB01 and VMWAP04-AHUB02 are part of the cluster. These servers host privileged services of the Windows Azure Pack.

The Cluster-THUB is bound on the IP address 10.10.0.100.

I have configured the cluster operation mode to Multicast. Be careful, if you use unicast and Virtual Machine, don’t forget to enable the Mac Spoofing feature in your Virtual Machine configuration.

DNS Aliases

Next I have configured DNS aliases to the cluster cluster-ahub.home.net. So I have just added entries in the DNS as below:

Certificates

The Certificates for privileged services are similar to the certificates for public services. I have used the same certificate template than I have used to enroll certificates for public services. The issued to field contains the FQDN of the server. Next I have added each DNS alias in the Subject Alternative Name as below. In this way, the certificate can be used for all web services

IIS binding configuration

Next, on each node I have reconfigured the site binding for admin API, tenant API, admin authentication site and management portal for administrators. As a reminder, below you can find the DNS aliases related the web services that I have set on my infrastructure:

  • Admin API (DNS Alias: wapadminapi.home.net);
  • Tenant API (DNS Alias: waptenantapi.home.net);
  • Admin authentication site (DNS Alias: wapadminauth.home.net);
  • Management portal for administrators (DNS Alias: wapadmin.home.net).

Repeat this procedure for each node with the same configuration except the SSL certificate.

Windows Azure Pack Configuration

N.B: I used scripts described in this Hyper-v.nu topic for this part. You can find the documentation about these scripts from this TechNet topic.

Before that the configuration works, it is necessary to reconfigure the Windows Azure Pack. First WAP components have to be reconfigured to point to the load-balancers. Next we have to Re-Establish trust between the authentication sites and the management portals. To finish the FQDN of resource providers must be updated. These scripts must be run from a node that hosts privileged services.

Reconfigure WAP components to point to Load-Balancers

To reconfigure WAP components use the below script. You can change all the variables to make it match your environment. Firstly, the script updates the federation endpoints to the load-balancers. These federation endpoints are used by admin and tenant sites to know the location of their authentication sites and vice versa. Once federation endpoints are updated, the endpoints of each web service are updated in The Windows Azure Pack database.

Import-Module MgmtSvcAdmin
### VARIABLES
## Environment settings
# SQL Server AlwaysOn DNS Listener containing the Windows Azure Pack databases
$server="AAGWAP01.home.net"

## Define the desired FQDNs and Ports
# Admin Site
$AdminSiteLB = "wapadmin.home.net"
$AdminSitePort = "443"
# Admin Authentication Site
$WinAuthSiteLB = "wapadminauth.home.net"
$WinAuthSitePort = "443"
# Tenant Site
$TenantSiteLB ="www.home.net"
$TenantSitePort = "443"
# Tenant Auth Site
$TenantAuthSiteLB ="auth.home.net"
$TenantAuthSitePort = "443"
# Admin API
$AdminApiLB ="wapadminapi.home.net"
$AdminApiPort = "443"
# Tenant API
$TenantApiLB = "waptenantapi.home.net"
$TenantApiPort = "443"
# Tenant Public API
$TenantPublicApiLB = "api.home.net"
$TenantPublicApiPort = "443"

### MAIN CODE
# Define the federation endpoints
$TenantMetadataEndpoint="https://${TenantAuthSiteLB}:$AuthSitePort/federationMetaData/2007-06/FederationMetadata.xml"
$AdminMetadataEndpoint="https://${WinAuthSiteLB}:$WinAuthSitePort/federationMetaData/2007-06/FederationMetadata.xml"
$AdminSiteMetadataEndpoint="https://${AdminSiteLB}:$AdminSitePort/federationMetaData/2007-06/FederationMetadata.xml"
$TenantSiteMetadataEndpoint="https://${TenantSiteLB}:$TenantSitePort/federationMetaData/2007-06/FederationMetadata.xml"

$adminApiUri = "https://${AdminApiLB}:$AdminApiPort"
$windowsAuthSite = "https://${WinAuthSiteLB}:$WinAuthSitePort"

# Reconfigure Windows Azure Pack components to point to load balancers
Set-MgmtSvcFqdn -Namespace AdminSite -FQDN $AdminSiteLB -Server $server -Port $AdminSitePort
Set-MgmtSvcFqdn -Namespace AuthSite -FQDN $TenantAuthSiteLB -Port $TenantAuthSitePort -Server $server
Set-MgmtSvcFqdn -Namespace AdminAPI -FQDN $AdminApiLB -Port $AdminApiPort -Server $server
Set-MgmtSvcFqdn -Namespace TenantSite -FQDN $TenantSiteLB -Port $TenantSitePort -Server $server
Set-MgmtSvcFqdn -Namespace WindowsAuthSite -FQDN $WinAuthSiteLB -Port $WinAuthSitePort -Server $server
Set-MgmtSvcFqdn -Namespace TenantApi -FQDN $TenantApiLB -Port $TenantApiPort -Server $server
Set-MgmtSvcFqdn -Namespace TenantPublicApi -FQDN $TenantPublicApiLB -Port $TenantPublicApiPort -Server $server

Re-Establish trust between the authentication sites and the management portals

Once you have run the above script, you have to execute below command. This re-establish trust between authentication sites and the management portals.


Set-MgmtSvcRelyingPartySettings -Target Tenant –MetadataEndpoint $TenantMetadataEndpoint -DisableCertificateValidation -Server $server
Set-MgmtSvcRelyingPartySettings -Target Admin –MetadataEndpoint $AdminMetadataEndpoint -Server $server
Set-MgmtSvcIdentityProviderSettings -Target MemberShip –MetadataEndpoint $TenantSiteMetadataEndpoint -Server $server
Set-MgmtSvcIdentityProviderSettings -Target Windows –MetadataEndpoint $AdminSiteMetadataEndpoint -Server $server

Update FQDNs for resource providers

To finish, the FQDN for resource providers must be updated to the load-balancers. There are three resource providers to update: marketplace, monitoring and UsageService. For that you can use the below script:


Import-Module MgmtSvcAdmin

## Environment settings
# SQL Server AlwaysOn DNS Listener containing the Windows Azure Pack databases
$server="AAGWAP01.home.net"

# Admin Authentication Site
$WinAuthSiteLB = "wapadminauth.home.net"
$WinAuthSitePort = "443"
# Admin API
$AdminApiLB ="wapadminapi.home.net"
$AdminApiPort = "443"

$adminApiUri = "https://${AdminApiLB}:$AdminApiPort"
$windowsAuthSite = "https://${WinAuthSiteLB}:$WinAuthSitePort"

# credentials for performing actions
$password = ConvertTo-SecureString "password" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ("home\rserre",$password)
$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $windowsAuthSite -ClientRealm "https://azureservices/AdminSite" -User $credential -DisableCertificateValidation

# Get a list of resource providers with the current configured endpoint values
$rp = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $adminApiUri -Token $token -DisableCertificateValidation
$rp | Select Name, @{e={$_.AdminEndPoint.ForwardingAddress}}, @{e={$_.TenantEndpoint.ForwardingAddress}}

# new fqdn for resource provider marketplace
$resourceProviderName = "marketplace"
$adminEndpoint = "https://${AdminApiLB}:30018/"
$tenantEndpoint = "https://${AdminApiLB}:30018/subscriptions"
$usageEndpoint = $null
$healthCheckEndpoint = $null
$notificationEndpoint = $null

if ($rp.AdminEndpoint -and $adminEndpoint) {
    # update endpoint
    $rp.AdminEndpoint.ForwardingAddress = New-Object System.Uri($adminEndpoint)
}
if ($rp.TenantEndpoint -and $tenantEndpoint) {
    # update endpoint
    $rp.TenantEndpoint.ForwardingAddress = New-Object System.Uri($tenantEndpoint)
}
if ($rp.UsageEndpoint -and $usageEndpoint) {
    # update endpoint
    $rp.TenantEndpoint.ForwardingAddress = New-Object System.Uri($usageEndpoint)
}
if ($rp.HealthCheckEndpoint -and $healthCheckEndpoint) {
    # update endpoint
    $rp.TenantEndpoint.ForwardingAddress = New-Object System.Uri($healthCheckEndpoint)
}
if ($rp.NotificationEndpoint -and $notificationEndpoint) {
    # update endpoint
    $rp.TenantEndpoint.ForwardingAddress = New-Object System.Uri($notificationEndpoint)
}
Set-MgmtSvcResourceProvider -ResourceProvider $rp -AdminUri $adminApiUri -Token $token -DisableCertificateValidation –Force

Re-run the above script by changing below variables:


$resourceProviderName = "monitoring"
$adminEndpoint = "https://${AdminApiLB}:30020/"
$tenantEndpoint = "https://${AdminApiLB}:30020/"
$usageEndpoint = $null
$healthCheckEndpoint = $null
$notificationEndpoint = $null

And re-run once again the script by changing below variables:


$resourceProviderName = "usageservice"
$adminEndpoint = "https://${AdminApiLB}:30022/"
$tenantEndpoint = "https://${AdminApiLB}:30022/"
$usageEndpoint = $null
$healthCheckEndpoint = $null
$notificationEndpoint = $null

To verify that the configuration is updated run these PowerShell commands:


$rp = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $adminApiUri -Token $token -DisableCertificateValidation
$rp | Select Name, @{e={$_.AdminEndPoint.ForwardingAddress}}, @{e={$_.TenantEndpoint.ForwardingAddress}}

SQL AlwaysOn configuration

I’m not a SQL server guy so I have followed the TechNet documentation regarding the AlwaysOn configuration. For each instance that hosts Windows Azure Pack database, you have to run the below script:

sp_configure contained database authentication, 1
RECONFIGURE
GO

Next you have to add the Windows Azure Pack to the Availability group. For that you have to:

  • Check if the database transaction logs is set to full;
  • Make a full backup of each Windows Azure Pack database;
  • Add the WAP databases to the AAG.

If you want information from a guy that who knows what his is doing on SQL Server, you can read this series.

Once database are in the AAG, you have to copy each security login from the first instance to the second. For that you can use this topic.

VM Clouds in High Availability

Architecture overview

Now that the Windows Azure Pack is installed in high availability we can install the VM clouds part in the same way. For that we can use the the SQL Servers than WAP installation. We need also a Virtual Machine Manager deployed in high availability and two more servers to host Service Provider Foundation.

NLB configuration

As other load-balancing clusters, I have used NLB. VMWAP08-WEB01 and VMWAP08-WEB02 are in this cluster. These servers host Service Foundation Provider.

The Cluster-WEB is bound on the IP address 10.10.0.101. I have configured the cluster operation mode to Multicast. Be careful, if you use unicast and Virtual Machine, don’t forget to enable the Mac Spoofing feature in your Virtual Machine configuration.

DNS Aliases

Next I have created DNS aliases for each roles installed on the nodes of the cluster. So for example, I will use spf.home.net to connect to SPF from the Windows Azure Pack.

Certificates

Two certificates have been created from a duplicate of Web server certificate template. The issued to field contains the FQDN of the related server. Next I have added each DNS alias in the Subject Alternative Name as below. In this way, the certificate can be used for all web services

Service Provider Foundation installation

To install Service Provider Foundation, please read this topic. However, please be careful about below information:

  • On each node, the SQL Server information provided in the SPF installation should be the same. For me the database server name is WAPAAG02.home.net;
  • Select the server certificate related to the node;
  • For security reason, use different services account on each node for Admin, Provider, VMM and Usage web service;
  • Create the same local account (with the same password) on each node.

After SPF installation don’t forget to add the SPF database to the AAG and to copy security login to the other instance (C.F the above part called SQL
AlwaysOn configuration).

Connect to SPF from Windows Azure Pack

Open an administrative portal on the Windows Azure Pack and click on VM Clouds. Register the SPF as below:

Install Virtual Machine Manager in high availability

To install Virtual Machine Manager in High availability, please read this topic.

Connect to Virtual Machine Manager from Windows Azure Pack

Now you can add the cluster of VMM to the Windows Azure Pack as below:

The post Windows Azure Pack and VM Clouds in High Availability appeared first on Tech-Coffee.

]]>
//www.tech-coffee.net/windows-azure-pack-vm-clouds-high-availability/feed/ 0 2661