Scope of work - High-Availability Gateway Design Build

Follow

This feature creates a redundant Gateway and Broker design by splitting out the roles of the Broker and Gateway across different servers.

To accomplish this duplicates of each type of server role will be created, thereby, making them redundant. There will be at least two Gateways and two Brokers, however, it is possible to have more than two gateways in order to accommodate a larger scale environment.

The HA design also requires a SQL server to host the RDS SQL database which is where the deployment stores the necessary configuration information to support the deployment. If desired, the SQL server can also be made redundant using SQL server HA methods.

After the Broker and Gateway servers are created, a load-balancing device is utilized to distribute the load across healthy active components. The load balancer should do the following;

  • Distribute user load across the different redundant servers,
  • Utilize monitor sets to determine when a components is not available
  • Maintain session state (stickiness) so a user continues to connect to the same server during their session.

By implementing this design, should one key component fail, other servers are available to service requests, thereby, making the deployment highly-available.

Scope of Work

Prerequisites:

  • Customer MUST have a deployed Load Balancer of their choice and must know how to integrate it. If using VMware NSX, then the Edge Services Gateway (ESG) load balancer will be utilized.
  • If the customer needs assistance with the setup of the load balancer that engagement will be covered under the professional services fees at $250 per hour. If using the ESG Load Balancer this fee does not apply.
  • Customer must have a SQL 2012 or newer server deployed in the environment. The customer must provide both the binaries and the SQL licensing.
  • If a SQL server does not exist, and the customer wishes to have Neverfail provision one, that engagement will be covered under the professional services fees at $250 per hour. The customer must provide both the license and binaries.
  • Customer must already have a domain for the specific Workspace for which the HA Gateway will be implemented.
  • If a new domain must be created then please refer to the section in this fee schedule for creating the type of domain required, and add that cost to the order total. All work outlined under the selected type of domain must be completed prior to the HA implementation engagement.

Once the prerequisites have been met, Neverfail will:

  • Assist with obtaining a self-signed certificate from the local Domain Certificate Authority. If a new domain is being created Neverfail will assist with getting a Certificate Authority created and configured.
  • Install and configure the self-signed SSL certificate and validate SSL connections are successful.
  • Deploy an HA design based upon two RDS Brokers and two RDS Gateways which are placed behind a Load Balancer.
  • Assist with configuring the Load Balancer pools, and virtual servers configuration, so that connections are both load balanced and redundant.
  • This design will allow for both full failover between each of the identified components should anything fail, as well as balancing connection across the gateway servers.
  • Test using a published application or desktop to validate session are launching using the new HA design.
  • Complete a test validation as outline in the acceptance criteria section to ensure redundancy across the environment.
  • Once the configuration is validated Neverfail will remove the old Broker Gateway.

NOTE: RDS does not support live failover, a failure of a Gateway server will cause the user to have to manually reconnect.

Acceptance Criteria

  • A full functional test plan will be performed to validate that the components have redundancy. Under each of the following scenarios an application will be launched to validate function.
    • Gateway #1 turned off and the environment continues to take connections.
    • Gateway #2 turned off and the environment continues to take connections.
    • Both Gateways are returned to operation.
    • Broker #1 turned off and the environment continues to take connections.
    • Broker #2 turned off and the environment continues to take connection
    • Both Brokers are returned to operation.
    • Both Gateway #1 and Broker #1 will be disabled and a successful new connection validated. After validation both will be returned to operation.
    • Both Gateway #2 and Broker #2 will be disabled and a successful new connection validated. After validation both will be returned to operation.
    • Next the Brokers and Gateway will be cross tested as follows:
      • GW#1 on, GW#2 off, Broker #1 on, Broker #2 off.
      • GW#2 on, GW#1 off, Broker #1 on, Broker #2 off.
      • GW#1 on, GW#2 off, Broker #2 on, Broker #1 off.
      • GW#2 on, GW#1 off, Broker #2 on, Broker #1 off.
    • A user session will be launched and left running for at least thirty (30) minutes in order to confirm sessions remain operational.
  • Success is defined as all tests in the FTP passing connectivity and session remaining stable over the thirty (30) minute period.
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.