关于scale Groups的概念，在看Dynamics crm online的时候，一直不理解缩放组scale group的概念，后来查到GP也在用这个概念，想想不就是动态扩展嘛，马上顿悟了，原来如些。
From : https://community.dynamics.com/gp/b/dynamicsgp/posts/scale-groups-for-the-web-client
Scale Groups are a very interesting feature for the Web Client. Though the idea for its creation came to fill in a need for our partners hosting the Web Client, it does have practical application in On Premise installations as well.
In its simplest sense, it is a mechanism to affect the routing to a specific Session Host or group of Session Hosts. It has a one to many relationship with both Session Hosts and Tenants.
When Web Client was initially released, it was not uncommon to see the following environment:
With this environment, you would set up the location of the Dynamics GP client in Tenant Services that would be deployed to each Session Host. This worked perfectly fine until you needed more than 51 Dynamics GP clients. Once more than 51 Dynamics GP clients were needed, this model no longer was viable. The environment then needed to change to this:
As you can see, a second Web Server needed to be spun up to handle the next 51 GP Clients. This creates some very challenging scenarios for the administrators when troubleshooting multiple deployment environments.
This is the design challenge that is overcome with Scale Groups for the Web Client. The multiple environment above can now be designed as:
One functional change was made to validation of the user entered on the Logon.aspx page. The Authorize() method is now called from the Web Server versus the Session Host. This will allow for the user to be routed to the correct Session Host when it comes time to create a session.
When it comes to setup for Scale Groups, this is all done through PowerShell. This includes the creation of a Scale Group, defining the relationship between a Scale Group and a Tenant, defining the relationship between a Scale Group and Session Host, and everything in between. To this end, a GP PowerShell application has been created and can be deployed from the media. It does have a requirement that PowerShell 3.0 be deployed before it can be installed.
With the GP PowerShell application, 17 cmdlets have been created to help. Here is the list of those cmdlets:
- Scale Group PowerShell cmdlets
- Get-GPScaleGroup
- New-GPScaleGroup
- Update-GPScaleGroup
- Remove-GPScaleGroup
- Session Host PowerShell cmdlets
- Get-GPSessionHost
- Update-GPSessionHost
- Remove-GPSessionHost
- Scale Group \ Tenant PowerShell cmdlets
- Get-GPScaleGroupTenant
- Add-GPScaleGroupTenant
- Update-GPScaleGroupTenant
- Remove-GPScaleGroupTenant
- Session Host \ Tenant PowerShell cmdlets
- Get-GPSessionHostTenant
- Update-GPSessionHostTenant
- Miscellaneous PowerShell cmdlets
- Get-GPSessions
- Get-GPSessionCentralAddress
- Set-GPSessionCentralAddress
- Get-GPWebClientVersion
Information on the intent of each cmdlet and its syntax (including the required and optional parameters) can be found by running a Get-Help. For example, you could run Get-Help Remove-GPScaleGroup and the following result would be displayed:\
With all of this information, hosting partners will likely leverage this feature in their deployments. It allows you to create a more customized environment where the needs of a customer can be tailored to their situation. An example of this would be two tenants (Tenant A and Tenant B) are part of the same Scale Group (Scale Group 1). Tenant A is heavily using the system and because of this usage, Tenant B is seeing performance issues. You can move Tenant B to another Scale Group (which would be a different Session Host than what they were using in Scale Group 1) to help rectify the situation.
Lastly, I discussed that this can be used in an On Premise environment. I have seen customer set up a multitenant environment for a number of reasons. It could be:
- There are multiple reports.dic
- There are multiple product configurations that need to be in place within the Dynamics.set
- A training environment is set up so that a user can become familiar with the systems and with the data without negatively affecting that data when practicing
- A development\test environment has been set up
For #1 and #2, each tenant can only specify one Dynamics.set and one Dex.ini. With multiple reports.dic, each unique Dynamics.set in which the path to the reports.dic resides would need to be its own tenant.
It is with #3 and #4 where Scale Groups would have an impact. You could have your production environment on one scale group with it set of Session Hosts and your development\test\training environment on another scale group with its set of Session Hosts. Since a Session Host can only belong to one Scale Group, the actions performed on the development\test\training environment won't adversely affect the performance of production.
Though this feature may not fit every scenario where Web Client is installed, it is good to understand the flexibility that Tenant Services and Scale Groups provides so that your environment can be designed to take advantage of the features if a future need dictates its usage.