Beta Version of ApplicationServer 4 available for download

Discussion in 'Parallels Remote Application Server' started by Lee, Sep 14, 2006.

  1. Lee

    Lee Guest

    http://downloads.2x.com/applicationserver/betaversion/

    New features

    1.Integration of load balancing and application serving. This means that applications are load balanced depending on the availability of the applications on the servers farm.

    2. Publishing of both Applications and Desktops. An administrator can now publish both applications and full desktops. This requires the new client (Windows only at present).

    3. Published can be done on all the farm, defined server groups or individual machines.

    4. Load balancing of RDP and ICA connection at the same time. A single server can be serving both ICA and RDP at the same time. Obviously publishing is only available with RDP servers.

    5. Configuration are easier to do, using a single user interface which validates all settings from the user. Simple wizards help the administratot to create the servers farm and to publish the applications easily.

    6. Reconnection improved. Now we have a new option to reconnect to an already connected session as well

    7. Improved load balancing, any combination of counters can be used.

    8. Functional Notification.

    9. Information tab replaces the old monitor. The information about the farm is now inside the same UI.

    10. Improved managment of published applications and desktop by using Application groups.

    11. Predefined Application help adminitrator to publish difficult applications like control panel icons, etc.
     
  2. agressiv

    agressiv Guest

    I cant seem to connect with the beta client to the beta server over 20002 - I could only use port 80 with the gateway - this intentional?

    I don't want to use the gateway... - I've even tried not installing that, but its refusing connections from the client to 20002.

    agressiv
     
  3. agressiv

    agressiv Guest

    Yeah I'm giving up for now until I hear back - the documentation still refers to port 20002 for the client to point to but it doesn't seem to work. I can only get it to work when I use it as a gateway, and I do NOT want to tunnel all of my connections over port 80.

    Ideally, it would look like this:

    • Load balancer on two machines, neither of them are terminal servers, with both of them being Application Servers/consoles.
      Terminal Server "agent" on the rest of the servers.
      Gateway would come later, I dont want it installed here in the core.

    The load balancer/appserver would dish off connections to the agents and be done with it. Stopping anything on the load balancer should only prevent new connections, not affect anything currently existing.

    Yes its beta, but for the life of me I couldn't get something like this to work. I do NOT want to install the load balancer on the terminal server itself if I dont have to.

    agressiv
     
  4. agressiv

    agressiv Guest

    Any change notes with this new beta? Anything to look out for?

    agressiv
     
  5. Cedric

    Cedric Guest

    Hi agressiv,

    You mentioned that the documentation still refers to port 20002. Yes there is a mistake in Figure 66. It is displaying port 20002. This will be fixed ASAP though right now on the documentation there is special note in the same page which states:

    In order to connect through the 2X Client Gateway you just need to set the Port number that was configured on the Client Gateway Port in the
    Connection Settings Page. (Default Gateway Port 80)

    You also mentioned that you do not want to tunnel all connections over port 80. First it must be clear that port 80 can be configure to any port that you want. (Client Gateway Port in the Connection Settings Page).
    Secondly, the direct connection mode instead using the client gateway,
    is going to be available with the next new client release. These features and more are going to be incorporated with the new client.
    Therefore with the new client you'll be able to connect directly with your Terminal Servers.


    You've stated that ideally it would look like this:

    “Load balancer on two machines, neither of them are terminal servers, with both of them being Application Servers/consoles.
    Terminal Server "agent" on the rest of the servers.
    Gateway would come later, I don’t want it installed here in the core."

    I don't agree with that type of design, as you would need two extra machines just doing the load balancing!

    With the new 2X Solution, one can install (2X Publishing Agent, 2X Terminal Server Agent, 2X Client Gateway) * on one of the Terminal Servers and a 2X Terminal Server Agent on the rest of his Terminal Server.

    If there are clients who want to load balance the session on a machine without Terminal Server the can install 2X Client Gateway and 2X Publishing Agent on this machine and then install 2X Terminal Server Agent on each of the Terminal Server.

    I'm trying to establish the flexibility and ease of modification that users are going to have with these 2X modules.

    * These are all installed at one go, in the installation setup.
     
  6. agressiv

    agressiv Guest

    Big thing for us is redundancy. We want terminal servers to be terminal servers, not load balancers. If that load balancer goes down, no new connections can be made. And If I have to reboot it, I don't want to boot 100 users because the load balancer isn't working properly. We operate our terminal servers at 50-90% CPU all day and I'd rather have the load balancer just load balance. Right now we have F5 load balancers doing this job, so a couple of blades doing load balancing is trivial.

    I dont care that its running over port 80, I just didnt want a tunneled connection. So it sounds like I just need to wait for the new client. I like the agent idea (otherwise we'd have to reghack the config for the rest of the servers, a manual process) and thats definitely one of the better features.

    agressiv
     
  7. Cedric

    Cedric Guest

    Yes I agree with you agressiv, that redundancy is the most important aspect in Terminal Servers solutions.

    For a redundancy setup I would suggest to install 2X Client Gateway on two different machines [2X Client Gateway 1 & 2X Client Gateway 2].

    Then install the 2X Publishing Agent on another machine.

    On each 2X Client Gateway [2X Client Gateway 1 & 2X Client Gateway 2] configure the location of 2X Publishing Agent:
    [In the connection settings page - Connection tab - Click 'Advanced' Icon configure the ip/name of the 2X Publishing Agent]

    Then install the 2X Terminal Server Agent on each Terminal Server.

    With this solution, then you can configure the Primary and Secondary server of 2XapplicationServer & LoadBalancer Client to be 2X Client Gateway 1 & 2X Client Gateway 2 respectively.

    Please check the diagram below.

    Code:
       -------------                   -------------
       | 2X Client |                   | 2X Client |
       | Gateway 1 |                   | Gateway 2 |
       -------------                   -------------
                  \                     /
                   \                   /
                     ------------------
                     |  2X Publishing |
                     |      Agent     |
                     ------------------
                              |
         --------------------------------------------
         |          |         |           |         |
     --------   --------   --------   --------   --------
     | TS 1 |   | TS 2 |   | TS 3 |   | TS 4 |   | TS 5 |
     --------   --------   --------   --------   --------
    


    You mentioned that you don't want a tunneled connection. I've a good news for you about this, as the direct connection mode is already developed and implemented and will be released very soon with the next beta version.
     
  8. agressiv

    agressiv Guest

    In your diagram, the publishing agent would be a single point of failure. Can the publishing agent just be installed twice (on each gateway), with one being turned off (on the second node, cold standby?). I realize we'd have to manually replicate between the two, or is there another option?

    If the publishing agent server went down, would that prevent new connections?

    agressiv
     
  9. Cedric

    Cedric Guest

    Yes agressiv, right now the publishing agent would be a single point of failure. Though by the end of this week we'll release a version which supports 2 or more Publishing Agents with the facility of cold standby.

    I'll give more details about this scenario later this week.
     
  10. rafelbev

    rafelbev Guest

  11. rafelbev

    rafelbev Guest

Share This Page