PolyMix allows for two kinds of network configurations: flat and routed. In the flat configuration, all devices have the same subnet mask. In the routed configuration, Polygraph clients are on one subnet and servers are on another.
For the flat configuration, the subnet mask is ``/16'' or 255.255.0.0. For the routed configuration, the subnet mask is ``/17''. The clients use 255.255.0.0/17 and servers use 255.255.128.0/17.
The advantage to the flat network is that you only need one switch or hub. The disadvantage is that under the current scheme, the hosts generate a lot of ARP traffic.
The advantage of the routed network is the reduction of ARP traffic. The disadvantage is that you need to include a router (or equivalent) in your configuration, and this may increase the cost of your product in a performance/price analysis. The routed network is also a little harder to set up.
The following table describes the allocation of IP addresses for PolyMix-3 at the third Cache-off:
Address Range Zone Description ---------------- --------- ---------------------------- 10.x.0.1-30 vendor Proxy cache(s) [1] 10.x.0.61-99 polyteam Polyclt primary address 10.x.0.100 polyteam Monitoring station 10.x.0.253 vendor Router [2] 10.x.1-127.* polyteam Polyclt aliases 10.x.128.1-30 vendor Proxy cache(s) [3] 10.x.128.61-99 polyteam Polysrv primary address 10.x.128.100 polyteam Reserved 10.x.128.253 vendor Router [2] 10.x.128-254.* polyteam Polysrv aliases
NOTES:
I've had some difficulty configuring the new version of polymix-3. With the addition of benches.pg and the change in specifying robot and server IPs I've run into a problem. I specified the robot and server IPs in benches.pg (as one apparently must do to conform to PolyMix rules now), configured everything else, and tried to start polysrv. It ran briefly, spraying a long list of IP addresses up on the screen, and then terminated without errors. Any idea what I'm doing wrong?
I suspect you didn't run aka on your machines. We're working on code to automate that part as well. For now, you have a choice:
Both techniques still require you to manually assign the virtual IP addresses to the network interfaces. This is done with the aka command. You'll probably also find the pmix2-ips.pl script handy. For example, lets say your request rate is 1000/sec:
% perl pmix2-ips.pl 99 1000
bench: 99
req.rate: 1000/sec (actual: 1003.20/sec)
PCs: 3pairs
robots: 2508 ( 836/machine)
servers: 756 ( 252/machine)
rbt_ips: 10.99.1-12.1-209
srv_ips: 10.99.129-134.1-126
You need three client/server pairs. You divide the rbt_ips and srv_ips evenly among them, using the aka command:
1st client: aka fxp0 10.99.1-4.1-209 2nd client: aka fxp0 10.99.5-8.1-209 3rd client: aka fxp0 10.99.9-12.1-209 1st server: aka fxp0 10.99.129-130.1-126 2nd server: aka fxp0 10.99.131-132.1-126 3rd server: aka fxp0 10.99.133-134.1-126
Now, in benches.pg you put this:
client_addr_mask = '10.99.0.0';
server_addr_mask = '10.99.0.0:80';
and in polymix-3.pg you put this:
benchPolyMix3.peak_req_rate = 1000;
In a flat network configuration, the clients and servers will not have a default route. All hosts are on the /16 subnet, so no routes are needed.
For the routed network configuration, the clients and servers need routes so that they can talk to each other. The router addresses should be 10.x.0.253 and 10.x.128.253. For example, you would execute this command on all clients:
route add -net 10.x.128.0/17 10.x.0.253And this command on all servers:
route add -net 10.x.0.0/17 10.x.128.253
You can, so long as the proxy routes all traffic between the client and server subnets. The rules for PolyMix-3 (and other tests) require IP-layer connectivity between all clients and servers at all times. For example, the clients must be able to ping the servers, and vice-versa.
If you use your proxy as a router, then you should assign both 10.x.0.1 and 10.x.0.253 addresses to the proxy interface if possible. If that is not possible, then use 10.x.0.253 and tell polygraph to use 10.x.0.253 as the proxy address.
In a routed test network, the clients use the 10.x.0.0/17 network, and the servers use the 10.x.128.0/17 network. The monitoring PC goes on the client's subnet and uses the IP address 10.x.0.100. The monitoring PC needs a route to the servers, just like the other machines on the client subnet.