locked
Global Deployment -- Access Edge, Director, and Traffic Flow Question RRS feed

  • Question

  •  

    Trying to think through a global deployment scenario...

     

    I am considering an Enterprise Consolidated deployment to support a US and Aust office.  Each location will have (1) consolidated enterprise server, (1) consolidated Edge server, (1) Reverse Proxy. 

    • No EV or high availability.
    • There will be a single director in the US location.
    • Single domain.
    1. I called pre-sales support and was informed that an Access Edge role can only exist in one geographic location (confirmed what I was thinking).  However, in the Microsoft IT OCS deployment documentation (http://technet.microsoft.com/en-us/library/cc297283.aspx), there is a failover Access Edge server in a separate geographic location.  Again, I thought there can only be a load balanced collection of access edge servers in a single geographic area.  If multiple Access Edge servers are supported globaly, how would the “failover” be handled across a US based and Aust based site?  Is this even possible with a single domain (@company.com)?
    2. Assuming only a single collection of load balanced access edge servers is supported (and these Access edge servers exist in the US) then external to internal Australia SIP traffic will route to the US access edge, then US director, then to the correct enterprise consolidated pool in Aust, correct?
      1. The above scenario isn’t ideal, but I am just playing through ideas.  The web conference and A/V requests will route to the appropriate edge server though (US or Aust) regardless of access edge and director because it is dependent upon URLs within each pool, correct?
      2. How would the aus. Internal to external  SIP traffic play out?  Would the internal Aust SIP traffic again be routed out the US based director/access edge (say for external users and federated partners)?  Ideally, I would want to have Australia traffic local to Australia as much as possible… Should an Access Edge be installed in Aust to support the internal to external traffic flow then?

    Are there any documents that depict the traffic flow from an internal/external and external/internal scenario in a global deployment?   

     

    Thanks!
    Thursday, October 2, 2008 10:17 PM

All replies

  • It is true that you can only have one Access EDGE server / array for a specific sip address

     

    So your solution would be to have separate sip addresses for AUST users

    ex. user@domain.com for US and user@domain.au  for AUST

    In this scenario you can have a second Access EDGE server / array for Aust

    (note : that you should also add the user@domain.au to their smtp addresses for good outlook interop)

    Thursday, October 2, 2008 10:43 PM
  • Hi - here's my take. I've been looking into this for a while as well...

    1. For your first question, MS does use a secondary Access Edge server in a secondary data center, but that's just for DR. And it's not supported. The way to do that is by using multiple SRV records for your SIP domain. Apparently the DNS query will return both records and communicator will try the second if the first fails. Since it's not supported, the details on the SRV records are sketchy, but I believe that they are doing it by changing the priority/weight of the SRV record.
    2. You are correct - the SIP traffic goes into the US, through the director and over to Australia's pool.
      1. You are also correct - the users who generate the LiveMeeting request will have their requests made from their home pool in Aus. When the meeting goes out to external users, the OCS servers will embed the Austrailian webconferencing edge server in the invite.
      2. Yes - Australian internal SIP traffic will route out the US edge server for federation and PIC

     

    And to the best of my knowledge there are no good docs that show exactly what you are talking about. The closest one is probably the Planning doc or the perimeter network deployment doc, but neither really show what you're looking for.

     

    Regards,

    Matt

    Friday, October 3, 2008 7:16 PM
  • All,

     

    Thanks for the replies.

     

    Deli,

    Actually, I have confirmed that your solution is only supported by Microsoft if there are two seperate forests.  Therefore, if two forests were established, then federation would be configured to support the two domain names. 

     

    Matt,

    The SRV priority/weight description def. makes sense.  As for having two seperate Access Edge servers in two geographic areas, you are correct in that it is UNSUPPORTED.  I spoke to a Microsoft OCS product manager yesterday, and he confirmed that having two access edge deployments in two seperate geographic locations is an unsupported topology!

     

    As for question/answer 2.2, I've confirmed that while Aust SIP traffic will flow through the US director/access edge, it is simply for authentication and presence with external corporate, federated, and PIC users.  Once the authentication is successful, the SIP communication becomes peer-to-peer between clients (to reduce bandwidth and latency).

     

    In regards to documentation, you'd are correct.  The MS product manager only pointed me to the planning guide.  There is nothing that does a good job describing this scenario in depth.  Below is a snippet from the planning guide that briefly discussing the traffic flow from a high-level.

    Code Snippet

     

    Multiple Site with Remote Site Edge Topology

    The remote-site edge topology supports multiple sites and is appropriate for organizations with remote sites that are geographically dispersed and are connected by using a WAN.

    In the multiple-site edge topology using a remote site, you integrate remote locations into a scaled topology by deploying:

    ·         The scaled topology in your data center (as specified in the scaled single-site edge topology).

    ·         Local A/V Conferencing and Web Conferencing Edge Servers and a local Standard Edition server or pool in each remote location.

    In this topology, traffic from remote or federated users in the remote location travels across the WAN only to contact the Access Edge Server for authentication and instant messaging and presence, which incurs lower bandwidth cost. The Access Edge Server returns the local pool or Standard Edition server for users at the remote site, and the pool or server points the user to the local A/V or Web Conferencing Edge Server. A/V traffic and traffic from the Web Conferencing Server remain local, which results in a better user experience and lower bandwidth usage of the WAN.

     

     

    Thanks,

     

    Keenan

     

    Friday, October 3, 2008 9:46 PM
  • Did Microsoft confirm this to you?

    Any documentation on not supporting multiple edge server for differnent sip domains?

     

    Friday, October 3, 2008 10:30 PM
  • Deli,

    I spoke to a Microsoft OCS Product Engineer and he confirmed the topology.

    As for documentation, the supported topologies section in the planning guide is it (what I referenced above)...

    Thanks,
    Keenan
    Monday, October 6, 2008 7:58 PM
  •  mmcgille wrote:
    For your first question, MS does use a secondary Access Edge server in a secondary data center, but that's just for DR. And it's not supported. The way to do that is by using multiple SRV records for your SIP domain. Apparently the DNS query will return both records and communicator will try the second if the first fails. Since it's not supported, the details on the SRV records are sketchy, but I believe that they are doing it by changing the priority/weight of the SRV record.

     

    The OCS 2007 Planning Guide states that both the weight and priority are used when deciding which SRV record to use.

     

    Note: Configuring multiple SRV records for the same SIP domain is not supported. If multiple DNS records are returned to a DNS SRV query, the Access Edge Server will always pick the DNS SRV record with the lowest numerical priority and highest numerical weight.

    Monday, October 6, 2008 8:52 PM
    Moderator