Exploring CSM Global Server Load Balancing
| The CSM supports GSLB by enabling participating CSMs to respond to A record requests from client DNS servers. As you learned in previous examples, you should specify your CSMs in NS records that you configure in your IDNS or TLD DNS servers. The CSM does not maintain APP connections between GSLB peers and therefore does not support DNS proximity or the DNS sticky features discussed in this Chapter. However, the CSM can maintain APP connections to the GSS, which can send KAL-AP requests to the CSM to determine the load of the CSM's virtual servers. Note You should consider using the GSS at the headquarters site in the place of the CSM, just as you considered using GSS for DD and CSS. As mentioned previously, the GSLB principals of the GSS are similar to the DD, CSS, and CSM. Refer to the product documentation on Cisco.com for more information on the GSS. To configure your CSM based on the topology in Figure 12-9, you can use the configuration in Example 12-6. Figure 12-9. GSLB Using the CSM Example 12-6. Configuring the CSM for GSLB
In Example 12-6, both CSMs are configured to respond to DNS A record requests. The CSMs match incoming A record requests with the virtual server called dns-virtual. The policy dns-policy specifies the server farm containing the available VIPs for the A record request, the TTL (that is, 60 minutes), and the number of responses to return to client DNS servers. You specify the domain that the CSM will match A record requests against within the DNS map called dns-map. When the CSM receives an A record request from a client DNS server, it selects among the VIPs that you specify in the server farm called gslb-farm. You must specify the local and remote VIPs and the load-balancing method in this server farm. You can use round-robin, least connections, ordered list, domain hash, and source IP address/domain hash. The ordered list method is unique to GSLB, where the CSM uses the first address in the list of VIPs you specify in the server farm until it becomes unavailable or overloaded, and then moves to the next address in the list. The CSM repeats this process for every subsequent entry in the list. You can also use Route Health Injection (RHI) for distributing requests to multiple CSM VIPs in the following scenarios:
CSM performs RHI in the first two scenarios by advertising healthy VIPs as host routes (that, is /32 routes) into the local MSFC routing table. A VIP is considered healthy if it is configured within at least one healthy virtual server that contains at least one healthy real server. The MSFC advertises the host route, using an IGP routing protocol that you configure, throughout the network. Other CSMs may advertise the same VIP, resulting in multiple host routes for the VIP. As you learned in Chapter 3, "Introducing Switching, Routing, and Address Translation," when multiple routes exist within an IGP, routers select a single route to forward packets. Routers choose the route with the best distance or metric or both, depending on the IGP used. If the routes have the same cost, you learned how CEF per-flow load balancing shares the load equally across the VIPs. If a CSM determines that the advertised VIP is no longer available or is overloaded, it removes the route from its MSFC routing table. The remaining VIP(s) located at another site(s) takes the full load of requests, until the failed VIP comes back online. To configure your virtual servers with RHI, use the following virtual server configuration command: advertise active You can also use RHI for Internet GSLB by effectively providing BGP-anycast routing discussed previously. The CSMs at each site install host routes in the MSFC routing tables. The MSFC can then advertise the host routes using an IGP to the Autonomous System Border Router (ASBR). The ASBRs can then summarize the host route and advertise it to their BGP peers. When a client requires access to the VIP, the DNS infrastructure returns the VIP address advertised by all sites. The BGP protocol handles distributing requests across the sites, using various metrics, including AS path. Because BGP does not propagate host routes to other autonomous systems, you need to make sure that the host routes are summarized before being advertised to remote BGP peers in different autonomous systems. For greater control of summarization boundaries, manual summarization on the ASBRs may be desirable, depending on your IP addressing scheme at the different sites. Note Route Health Injection can also be achieved on the CSS using OSPF. For more information on configuring RHI on the CSS, refer to the CSS technical documentation on Cisco.com. |
EAN: 2147483647
Pages: 178