Multiple Algorithms on global VIP based on the group of clients.

Adjust the WideIP Topology records so that those that clients (by source IP or region) which require RR service get a pool that utilizes RR and has all of the appropriate members in it. The remaining clients would follow normal Topology selection.

Answering your question more directly, I believe there is no method for changing the WideIP LB method via an iRule.

I apologize, but I don't understand. The original question suggested that clients are divided into two groups, and membership in a group is determined by the source IP from which the DNS request is arriving. Is this not the case? If it is not, then how do you determine which clients should use geographic distribution and which should use round-robin?

Incidentally, be aware that there are two levels of load-balancing for GSLB: the WideIP level and the pool level. The WideIP LB method is used to select a pool. Once a pool is selected, the pool level LB method selects a Virtual Server IP or a set of Virtual Server IPs (depending on how many return records you configure on the pool). Let's say you have three data centers, which we will call DC01, DC02 and DC03. You can create one pool for each datacenter. You could then use the Topology LB method on the WideIP to direct clients to a datacenter based on geolocation information. If the problem is that you're getting "clumping" at one datacenter, you could define each pool as a ratio. You could assign a high ratio value to the Virtual Server in the data center, and a much lower ratio to the Virtual Servers in the foreign data center.

To make this concrete, let's assume you have the WideIP www.example.com. Let's assume you have DC-Americas, DC-APAC and DC-EMEA. You generally want clients from the Americas to go to DC-Americas, clients from APAC to go to DC-APAC and all others to go to DC-EMEA. Let's further assume that there is one Virtual Server at each DC providing the www.example.com service. We'll call them americas:www01, apac:www01 and emea:www01 (that is [server]:[VirtualServer]). You would create one pool for each datacenter. We'll call them pool-americas, pool-apac and pool-emea. So, you'd configure it something like this:

  WideIP www.example.com
    - LB method: Topology
    - pools: pool-americas, pool-apac, pool-emea
    - Include Topology records to select pool based on source IP
    
  Pool pool-americas:
    - LB method: ratio
    - members: americas:www01 (ratio = 10); apac:www01 (ratio=1); emea:www01 (ratio=1)

  Pool pool-apac:
    - LB method: ratio
    - members: apac:www01 (ratio = 10); americas:www01 (ratio=1); emea:www01 (ratio=1)

  Pool pool-emea:
    - LB method: ratio
    - members: emea:www01 (ratio = 10); apac:www01 (ratio=1); americas:www01 (ratio=1)

In this configuration, a requestor from the Americas (for example) will go to americas:www01 10 out of 12 times, apac:www01 1 out of 12 times, and emea:www01 1 out of 12 times.

I apologize, but I don't understand. The original question suggested that clients are divided into two groups, and membership in a group is determined by the source IP from which the DNS request is arriving. Is this not the case? If it is not, then how do you determine which clients should use geographic distribution and which should use round-robin?

Incidentally, be aware that there are two levels of load-balancing for GSLB: the WideIP level and the pool level. The WideIP LB method is used to select a pool. Once a pool is selected, the pool level LB method selects a Virtual Server IP or a set of Virtual Server IPs (depending on how many return records you configure on the pool). Let's say you have three data centers, which we will call DC01, DC02 and DC03. You can create one pool for each datacenter. You could then use the Topology LB method on the WideIP to direct clients to a datacenter based on geolocation information. If the problem is that you're getting "clumping" at one datacenter, you could define each pool as a ratio. You could assign a high ratio value to the Virtual Server in the data center, and a much lower ratio to the Virtual Servers in the foreign data center.

To make this concrete, let's assume you have the WideIP www.example.com. Let's assume you have DC-Americas, DC-APAC and DC-EMEA. You generally want clients from the Americas to go to DC-Americas, clients from APAC to go to DC-APAC and all others to go to DC-EMEA. Let's further assume that there is one Virtual Server at each DC providing the www.example.com service. We'll call them americas:www01, apac:www01 and emea:www01 (that is [server]:[VirtualServer]). You would create one pool for each datacenter. We'll call them pool-americas, pool-apac and pool-emea. So, you'd configure it something like this:

  WideIP www.example.com
    - LB method: Topology
    - pools: pool-americas, pool-apac, pool-emea
    - Include Topology records to select pool based on source IP
    
  Pool pool-americas:
    - LB method: ratio
    - members: americas:www01 (ratio = 10); apac:www01 (ratio=1); emea:www01 (ratio=1)

  Pool pool-apac:
    - LB method: ratio
    - members: apac:www01 (ratio = 10); americas:www01 (ratio=1); emea:www01 (ratio=1)

  Pool pool-emea:
    - LB method: ratio
    - members: emea:www01 (ratio = 10); apac:www01 (ratio=1); americas:www01 (ratio=1)

In this configuration, a requestor from the Americas (for example) will go to americas:www01 10 out of 12 times, apac:www01 1 out of 12 times, and emea:www01 1 out of 12 times.