peer - Manage connected peer Web proxies
[1] peer [(share | ha | previous) [add <ip> [<qos>]]]
[2] peer [next [add <ip> [<port-number>]]]
[3] peer [(share | ha | next | previous) [raz | del <ip>]]
A peer appliance is a remote Web proxy interacting with the local Web proxy. There are three types of peer:
* Share peer,
* HA (High Availability) peer
* Chained peers (next and previous)
A share peer is a remote proxy that is requested from the local proxy when it does not have a requested object (by a client) in its cache. Several share peers may be defined to share their caches. In this case, each peer must be configured adequately with regards to the others. Share peers work together in order to deliver Web object to end-users from their caches rather than searching them on the internet and hence optimise the bandwidth usage.
An HA (High Availability) peer is a specific share peer, the difference being that Web objects retrieved from a share peer are not cached on the requesting proxy while Web objects retrieved from a HA peer are cached. HA peers should be used when peers are configured in a HA mode. In this case, when a master HA node fails, the newly elected master contains all Web objects as in the failed system (see the mode and vrrp commands for further information).
Share and HA peers works in parallel to provide caching performances and availability to local clients. It is also possible to serialise (or chain) peers to provide caching performances and high availability to remote end-users. To chain a proxy with a peer, one must be configured as a next peer while the other is configured as a previous peer (to allow the other to query it). A next peer is queried when it receives a request from an end-user. When several peers are chained, each system can participate to secure and optimise the traffic. For instance one can be configured to cache the traffic while a second one performs traffic shaping and a third one filters the traffic.
It is important to note that when at least on previous peer is defined, only end-users (clients) that are explicitly defined with the command access web are allows to connect to the local web proxy (see the command access). Also, note that, next peers are applicable only if the rweb mode is not activated (see the command mode).
The first [1] usage form allows you to add a share, ha or previous peer to the system. To add a share peer, use the share add keywords followed by the internal IP address of the remote share peer. The optional <qos> value allows you to customise the shaping of the traffic exchanged with the added peer. The <qos> is a percentage of the total bandwidth allocated to peers by the qos command. It should be an integer between 1 and 100. If no <qos> is given, the value of 100% is used by default. To add an HA or previous peer, use the ha or previous keywords instead of the share keyword.
A peer always uses its external IP address to query the internet or next peers. That’s why previous peers should be added using their external IP addresses.
The second [2] usage form allows you to add a next peer. To add a next peer, use the next add keywords followed by the internal IP address of the remote next peer. By default the system connect to the next peer using the proxy port (see the port command). If the next peer is listening on another port, the optional <port-number> argument can be used to specify that port.
The third [3] usage form allows you to delete a peer or completely erase a list of peers.
The current OS version does not support the SSL mediation between peers so HTTPS traffic use the HTTP CONNECT method to establish point-to-point tunnels to connect Web users to HTTPS servers across the system without passing by peers.
access (1) apply (1) mode (1) port (1) qos (1) vrrp (1)
CacheGuard Technologies Ltd <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2024 CacheGuard - All rights reserved