Archived

This forum has been archived. Please start a new discussion on GitHub.

deploying glacier2 instances in grid

I am working on a solution in which glacier2 is to be used to secure access to Ice services. These Ice services can be accessed only via SSL endpoints, and IceSSL will be configured to allow only connections authenticated bi-directionally - i.e. both server and client must present certificates, and each is validated against the presenter's network identity. We want clients to access these services, but don't want to have to deploy certificates to all of the boxes the clients will possibly run on. If we have client access proceed via glacier2, we only have to deploy certificates to the boxes hosting glacier. A PermissionsVerifier will consult LDAP to authenticate the client's user. Glacier2 will consult grid to provide the client with service proxies.

We are running many of our services in grid. We wanted to run glacier2 in grid as well, but it seems that a glacier session is a function of the connection between a client and server. This means that we cannot leverage grid to provide high-availability for glacier2 instances. In other words, we could not add our glacier2 instances to a ReplicaGroup, and then configure the Ice.Default.Router property with an indirect proxy. Or configure the Ice.Default.Router property with multiple endpoints, much like the Ice.Default.Locator can be configured. Even if we could, it would not make sense to do so, as a session is not a semantic unit detached from a glacier2 instance (e.g. stored in a database) and hence reference-able from multiple glacier2 instances. I would like this understanding confirmed.

So the onus would be on glacier2 client logic to provide high-availability: the client could be configured to have proxies to the various glacier2 instances, and establish sessions and obtain proxies itself - i.e. if a connection to one glacier2 instance were refused, it would fail over to one of the remaining instances. If we wanted to do this, we would have to be able to point the Ice.Communicator.getDefaultRouter() to a specific glacier2 instance. Is this possible?
Do you guys have any better ideas?

And finally, I noticed in another post that glacier2 will not consult grid to resolve an indirect proxy if this indirect proxy has already been resolved to a concrete instance, thereby circumventing grid's load-balancing functionality - i.e. the first concrete proxy will be invoked over and over. Is this still the case? If so, do you intend to support a glacier2 configuration which will tell glacier2 to consult grid every time to resolve an indirect proxy?

Thanks

Dirk

Comments

  • bernard
    bernard Jupiter, FL
    Hi Dirk,

    You can deploy one or more Glacier2 instances with IceGrid, typically as activation=manual server, with a direct Client object adapter. This is what the Glacier2 template (part of the IceGrid default templates) does.

    Another common setup is to run Glacier2 as a Windows service or Unix/Linux daemon. On Windows, please refer to the file WINDOWS_SERVICE.txt in your Ice distribution.

    With such typical setups, the object adapters are direct, so no replica group and the clients use direct proxies to connect to the Glacier2 router.
    dhogan wrote: »
    So the onus would be on glacier2 client logic to provide high-availability: the client could be configured to have proxies to the various glacier2 instances, and establish sessions and obtain proxies itself - i.e. if a connection to one glacier2 instance were refused, it would fail over to one of the remaining instances. If we wanted to do this, we would have to be able to point the Ice.Communicator.getDefaultRouter() to a specific glacier2 instance. Is this possible?
    Do you guys have any better ideas?

    Yes, there is a much simpler solution: just use a replicated Glacier2 router, presented to the clients as a multi-endpoints proxy, e.g.

    Ice.Default.Router=HPGlacier2/router:ssl -h server1 -p 4064:ssl -h server2 -p 4064:ssl -h server3 -p 4064

    (4064 is the IANA-registered port for Glacier2/ssl)
    And finally, I noticed in another post that glacier2 will not consult grid to resolve an indirect proxy if this indirect proxy has already been resolved to a concrete instance, thereby circumventing grid's load-balancing functionality - i.e. the first concrete proxy will be invoked over and over. Is this still the case? If so, do you intend to support a glacier2 configuration which will tell glacier2 to consult grid every time to resolve an indirect proxy?

    That's still the default behavior -- the result of an indirect proxy resolution is cached and by default it's kept forever. However you can now change this behavior. See Ice.Default.LocatorCacheTimeout in http://www.zeroc.com/doc/Ice-3.2.1/manual/PropRef.50.7.html.

    Also, if you use a replicated IceGrid registry, you should set Ice.Default.Locator in the Glacier2 router configuration to point to several (or all) your registry replicas. (If you start the Glacier2 router with IceGrid, this Ice.Default.Locator is set to your IceGrid node's Ice.Default.Locator).

    Best regards,
    Bernard
  • bernard
    bernard Jupiter, FL
    Also, if you want to understand Ice connection management and per-request load-balancing, I recommend to read "Connection Management in Ice", in issue 24 of our newsletter.

    Best regards,
    Bernard
  • Excellent. Thanks for the prompt reply.