gateways on different subnets - architecture question

[fputhod@cpacanada.ca]

Hi everyone,
I have been deploying our cognos analytics 11.04 env the following way:
1 IIS gateway
2 Cognos Analytics Dispatchers as Main and Secondary CM
1 MSSQL CM and AUDIT DB

all of the above 4 servers are in the same internal subnet as intended for internal users.

we now want to expose Cognos Analytics to the world and I think I have 2 options:
-set up a new IIS web gateway server in the DMZ, configure it to ReverseProxy to the dispatchers. However I am think this won't work as the other "internal" webgateway and the dispatchers as set to know of each other. To my knowledge, there is only 1 Gateway URI per Dispatcher. And so this doesn't seem like a valid option.

-move the current IIS gateway to the DMZ zone and configure communicaiton between it and the dispatchers. This solves the gateway-dispatchers communication issue but it doesn't seem practical or best practice to have internal users go to the DMZ to get that service.

-perhaps another one where I have internal user going to the main dispatcher (servername:9310) but this is not quite a nice URL thing to do. it would be better to have everyone use the same URL.

What are other options to allow both internal and external users to access our BI install using the same url namespace?

Thank you

[fputhod@cpacanada.ca]

I guess not a lot of people do that...
Would anyone know any ref doc I could examine to find out? I guess I am looking for some doc that will describe the set up of multiple dispatchers with multiple gateways without load balancing.

perhaps I missed something all together?

[bdbits]

There are a host of issues (no pun intended) that go with exposing something as complex as Cognos infrastructure to the internet. My experience only goes up through 10.2, but since no one else is speaking up... a few things to think about. Your hosts are already using a public URL? What is your authentication provider? Are your database connections using a signon or user credentials?

Actually the easiest thing would be to allow your external users to VPN to your network. I know, that was not feasible at my previous employer either. So, we chose to set up a full Cognos server whose only connection to the internal network was back to the databases. The content store was also separate from our internal content store, so we had to have procedures to transfer between them. Most users used the external server for authoring, so it was not such a big deal as we only had to deal with copying internally-developed reports to the external server, a simple export/import.

Come to think of it, I cannot recall how authentication was handled. We had to interface with an off-premise AD, and as I recall we set up a tunnel between the AD server and our external Cognos box. Things can get a bit messy.

I am not conversant enough these days to address a solution via gateways and dispatchers. Anyone with that experience care to join in?

You might also ask your IBM rep for a technical support engineer to help (I think that is what they are called, it is NOT the standard support desk). They generally know whereof they speak and can be a great resource, often at no cost.

[fputhod@cpacanada.ca]

thank you for chiming in. My hosts do not have public URLs, just internals. However they can be translated to the outside (internal name resolution and external matching). Today due to the placement of the servers (corp network only) they cannot be exposed to the public.

To add some more information, we use AD to authenticate - internal only, my understand is that the dispatchers being inside would not have problems to do LDAP Auth, the gateway being, well, just a gateway.
Our Contents are inside obviously.

VPN is indeed another options but not at this point.

[cogdude]

Dear fputhod,

What I've done is gone for your option1, however, there are 2 gateways setup:
1 internal and 1 external

the external gateway (non-sso) + IIS machine is in its own DMZ domain with its own LDAP  (this IIS is forced to auth from the LDAP only)
I also installed a second IIS and gateway on the application server that continues to reside within your safezone.
this is an SSO (AD based for the internal users).    your external facing reverse proxy forwards to the external gateway in DMZ.   Le voila!