Implementing Cold Standby in 4.1.110 and later

Discussion in 'Parallels Remote Application Server' started by Cedric, Sep 29, 2006.

  1. Cedric

    Cedric Guest

    Edit: The following information does not hold for 2X ApplicationServer & LoadBalancer Version 5.

    Please note that a new release [29/09/2006] was released which supports 'cold standby' apart from other new features.

    Application Server & LoadBalancer 4.1 [] Cold Standby.

         Primary Server                 Secondary Server
       ------------------              ------------------
       |   2X Client    |              |   2X Client    |
       |   Gateway 1    |              |   Gateway 2    |
       |      ---       |              |      ---       |
       | 2X Publishing  |              | 2X Publishing  |
       | Agent (MASTER) |              | Agent (Slave)  |
       ------------------              ----------------
                |                               |
         |          |         |           |         |
     --------   --------   --------   --------   --------
     | TS 1 |   | TS 2 |   | TS 3 |   | TS 4 |   | TS 5 |
     --------   --------   --------   --------   -------- 
    1) Using the 2XAppServer4.msi, install the 2x Client Gateway and the 2X Publishing Agent on the primary Server and install the 2X Terminal Server Agent on the Terminal servers.
    2) Configure the Primary Server from the 2X Console to load balance requests on the required Terminal servers.
    3) After applying the settings, export the settings to a file on the Secondary server.
    4) Install the 2x Client Gateway and the 2X PublishingAgent on the secondary Server, and the first time the 2X Console is loaded import the settings from the previously exported file and click 'Ok'.
    5) On the Secondary Server change the 'Priority' registry key in 'HKEY_LOCAL_MACHINE\SOFTWARE\2X\2XManagmentConsole\Connection' to the value 1.*
    6) Restart the 2X Publishing Agent on the Secondary Server from the MS Services console.

    *The 'Priority' registry key represents the priority level of the 2X Publishing Agents. The value 0 has the highest priority while greater values will have lower priority. One must make sure that there are no 2X Publishing Agents with the same priority value in the same Farm.

    p.s. 2X ApplicationServer & LoadBalancer Client supports both Direct Connection Mode and Regular Gateway Mode in this version.
  2. agressiv

    agressiv Guest

    OK, got the direct connect to work, and got the Publishing Agent to act on a secondary box.

    You can put the primary publishing agent and the secondary in the configuration, and if you take down the primary, the secondary kicks in and works. However, the secondary doesn't seem to function (says it cant find the terminal server) if the primary is up. I would assume this is the explanation behind the priority bit in the last post.

    I would just worry about error conditions, I dont want it dumping connections to the secondary (and thus giving the user an error message) if that small timeout value that seems to be there is hit. It might be safer to just configure a primary with a floating IP address or dns entry rather than take the risk of it unintentionally failing over.

    The only other catch is the export/import bit is manual, so to truely be highly available one would have to use some fancy registry exporting so that ongoing changes to the farm would get reflected on both publishing agents and load balancers.

    I will tinker around with it more - good work!

  3. Cedric

    Cedric Guest

    Yes agressiv, you've assumed right. You can't have 2X Publishing Agents working at the same time. The Secondary Server will activate itself if the Primary server is down.

    You're worried about the timeout value and error conditions. Can you please explain in more detail what type of error conditions you're concerned about?

    You also mentioned 'unintentionally failing over'. The take over occurs after a small timeout value of approximately 30 seconds. Can you also please clarify what do you mean by 'unintentionally failing over'?

    Right now the export/import is manual. Though in future releases we'll make this feature automatic and configurable from the console itself (settings will be propagated on the 2X Publishing Agents).

  4. agressiv

    agressiv Guest

    I guess I'd have to experiment with it more. With the services stopped on the primary, the secondary kicked in within about 2 seconds. I'm just wondering what would happen say, if the machine was busy at the time, and unresponsive. That is, it responds to ping, but the service is not responding. Would it wait 30 seconds, or just the two?

    I had a test condition where the primary wasn't working (even though all the services were running) and the secondary was always attempting to take the connections (and failing).

    My only guess is that another service had port 80 occupied during the install (that I stopped later) and that prevented it from ever working (even though i double-checked the configuration, the gateway WAS listening on port 80, and I saw the TCP connections from my test machine through netstat, and I had restarted services many times etc). My only solution was to uninstall and wipe the HKLM registry entries, and try again. That worked. So I can only explain why the install might have failed, but not why it would have continually failed even after I resolved the conflict.

    THAT is the type of error condition that I would be worried about - how it deals with something that is broken.

  5. nixu

    nixu Guest

    Hi agressiv,

    The fail over machanisim works on the state of the TCP/IP connection between the 2X Publishing Agent Service and the 2X TS Agents. If the server replies back to ping requests, then the secondary 2X Publishing Agent does not kick in.

    When the connection between the 2X Publishing Agent Service and the 2X TS Agents fails, the 2X TS Agents will connect with the Secondary 2X Publishing Agent. The 2X TS Agent's connection failure can be triggered either when updating the 2X Publishing Agent with updated resource counters or after 30 sec from the last update.


  6. socram

    socram Guest

    One cuestion, if the primary and secondary server are published trough ISA Server 2004 or 2006, are there any problemen with this infrastructure?

    Another cuestion, if the TS4 y TS5 are in other site with a 300 Kbps tunnel, is any problem?

    Thank you
  7. nixu

    nixu Guest

    Hi there,

    The current versions of 2x ApplicationServer & Loadbalancer work with firewalls that do not inspect protocol data.

    There should be not problem in having servers connected through 300Kbps links, what one needs to take care of is the level of packet loss, in the network as UDP protocols are used between the 2X Publishing Agents and the Terminal Server agents.


  8. mtkmis

    mtkmis Guest

    I'm curious what the diagram looks like above the load balancers.

    We have a scenario where we need full failover and have about 75 thinstations running to the IP of the primary LB. We also have some remote users outside our network connecting to the IP of the LB through the firewall. In this case I don't see how the secondary (standby) LB is ever going to be able to do anything since all the traffic is hitting the primary LB.

    Any thoughts?

    I checked into this but that appears to be specific to the 2X RDP client where we are running rdesktop and MSRDP. Unless I missed something, I also don't see that setting anywhere.
  9. nixu

    nixu Guest

    Hi there,

    In the client you can set the primary and a secoundry client gateway ips.
    This sould solve your issue.

  10. akoei

    akoei Guest

    My question here is: when client request a RDP connection from the farm, which IP address should they ask?

    From my understanding, when both works, client should ask priIP:3389, but if primary fail, like system down, if I need to notice all client use secIP:3389 for their requesting?

  11. nixu

    nixu Guest

    There are 2 ways how to solve this issue.

    1. In the client one can specify a primary and secondary server. So if the primary fails the secondary can be contacted.

    2. Using multiple DNS resolution. Specify a DNS name with 2 ips, the client will resolve the Name and will randomly connect to one of the gateways. This solution will also load balance the connections on both gateways

  12. nixu

    nixu Guest

Share This Page