Search:     Advanced search
Browse by category:
Glossary | Ask question



Glossary

  • algorithm
  • The algorithm used to balance load among real services that are members of the group. This parameter is optional, with a default value of Round Robin ("rr"). Depending on the algorithm used, additional parameters may need to be specified. Methods requiring additional parameters are designated with "*": (1)rr-Round Robin (2)pc-Persistent Cookie (3)pi-Persistent IP (4)hi-Hash IP (5)hc-Hash Cookie (6)ph-Persistent Hostname (7)pu-Persistent URL (8)ic-Insert Cookie (9)rc-Rewrite Cookie* (10)lc-Least Connections (11)sr-Shortest Response (12)hh-Hash Header* (13)sslsid-SSL Session ID (14)chi-Consistent Hash IP (15)prox-Proximity
  • chi
  • Consistent Hash IP: Distributes new connections to a real service based on a hash of the source IP address. Client sends a request to the virtual service. Array hashes source IP address of request to select a real service. Array forwards all requests with same hash value to the same real service. Note: If a real service fails, persistence will be maintained for existing clients on healthy servers. Mappings of client IP to real service are consistent across all Arrays so that clients will continue to go to the same real service on failover.
  • DNS Health Check
  • DNS health check opens a udp connection and sends a dns request, and the Array expects a special dns response .The dns request and response are not configurable because they are unchangeable. If those conditions are not satisfied, the server will be marked as “down”, otherwise, the server will be marked as “up”.
  • group_name
  • An assigned name, in the form of a character string, to the group service. Note: If the assigned name begins with a non-alphabetic character, then the string needs to be framed in double quotes.
  • hc
  • Hash Cookie: Real service selection is based on a hash of the specified cookie’s value. Used when each client browser session to the web site results in a unique cookie value for that browser session.
  • hc_down
  • The number of health checks to be performed with a negative result before determining the service as “down”. The default value is 3.
  • hc_up
  • The number of health checks to be performed with a positive result before marking the service as “up”. The default value is 3.
  • Health Check
  • The Health Check commands allow you to set parameters for the Array appliance to perform diagnostic observations on the performance of web servers and web server farms associated with each Array appliance. These observations on the performance health of the real server will allow the appliance to know how the servers are performing and which backend servers can best handle the incoming requests.
  • hh
  • Hash Header: In this group method, the list of headers is searched for one whose name matches with an assigned header's name <header_name>. If the header is found, the header value is mapped to an arbitrary real service in the group. This mapping is persistent, so the same header value will correspond to the same real service every time.
  • hi
  • The Hash IP load balancing method maps incoming traffic to real services based upon the source IP of the traffic. The Hash IP algorithm is consistent across multiple Arrays, as long as the Hash IP groups on each Array are configured the same. Note that if a real service in a Hash IP group goes down, existing persistence is disrupted.
  • HTTP Health Check
  • HTTP health check opens a tcp connection and sends a request defined in the health request table. The Array expects the health response defined in the response table. The 40 default index chosen to reference request/response table is 0. If those conditions are not satisfied, the server will be marked as “down”, server will be marked “up” otherwise.
  • HTTP requests
  • HTTP requests: slb real http <redirect_to_host> <ip> <port> [max_conn]{http|tcp|icmp} [hc_up] [hc_down]
  • ic
  • Insert Cookie: As the proxy processes a response from one of the real services which is a member of this group, it will insert a cookie into the response with the given cookie name. The value of this cookie will be a unique identifier for the real service. In subsequent requests, this unique ID is used to provide persistence to the same real service for all requests.
  • ICMP Health Check
  • A limited health check method that simply sends an ICMP echo (ping) to the server. If the server responds with an ICMP reply then the server is marked “up”. The server is marked “down” otherwise. This does NOT check for the running service or the quality of that service.
  • pc
  • Persistent Cookie: Real service is selected based on a static match of the cookie name/value pair. Each real service within a group must be configured with a unique cookie value. Steps: Client sends a request to the virtual service, Array selects a real service and forwards request to it, Response from real service contains a specific cookie with a value denoting that server, Client receives cookie in response, Next request from client includes cookie, Array examines cookie and sends request to proper real service.
  • ph
  • Persistent Hostname map requests with the same hostname to the same real service in this group.
  • pi
  • Persistent IP map requests with the same source IP to the same real service in this group.
  • Policy
  • Associates real service groups with virtual services
  • pu
  • Persistent URL: Based on a URL Value. A Group of this Method must be associated to a Virtual Service using the Persistent URL Policy.
  • Radius-Acct Health Check
  • Radius-Acct health check are especially provided for RADIUS servers.
  • Radius-Auth Health Check
  • Radius-Auth health check are especially provided for RADIUS servers.
  • rc
  • Rewrite Cookie: Array rewrites (modifies) a named cookie’s value in the server response. Used to simplify cookie based persistence configuration. All backend servers within a group must set the same name=value pair. Steps: Client sends a request to the virtual service, Array selects a real service and forwards request to it, Response from real service contains a specific cookie with a generic value, Array rewrites cookie value based on the real service, Client receives cookie in response, Next request from client includes cookie, Array examines cookie and sends request to indicated real service.
  • Real Service
  • Represents a physical server which will handle client requests
  • Real Service Group
  • Represents a group of real services which traffic will be distributed to. Defines which load balancing algorithm to use
  • real_name
  • An alpha-numeric string for the real service name. Note: If the assigned name begins with a numeric character, then the string needs to be framed in double quotes.
  • rr
  • Round Robin: Distributes new connections sequentially between available real services. Example: Connections are distributed to the real services in the following order: 1, 2, 3, 4, 5, 1, 2, 3
  • RTSP-TCP Health Check
  • RTSP health check opens a tcp connection and sends a RTSP "OPTIONS" request to real server. If the real server responses, the server will be marked as "up", otherwise, it will be marked as "down".
  • Script_TCP Health Check
  • Script_tcp health check provided for the generic script health check . They run over TCP connection respectively. Only when the hc_type is set to this type, the health check list will work while doing health check.
  • Script_UDP Health Check
  • script_udp Health Check provided for the generic script health check . They run over UDP connection respectively. Only when the hc_type is set to this two types, the health check list will work while doing health check.
  • SIP-TCP Health Check
  • SIP health check opens a tcp connection and sends a SIP "OPTIONS" request to real server. If real server responses, the server will be marked as "up", otherwise, it will be marked as "down"
  • SIP-UDP Health Check
  • SIP health check opens a udp connection and sends a SIP "OPTIONS" request to real server. If real server responses, the server will be marked as "up", otherwise, it will be marked as "down".
  • SLB
  • Server Load Balancing (SLB) improves server utilization, scalability, and failover redundancy. The Array Appliance monitors the available content servers, and directs client requests to the most appropriate server based on one of several available algorithms.
  • SPX
  • Secure Proxy
  • sr
  • Shortest Response: Server selection is based on lowest latency.
  • sslsid
  • SSL Session ID: SSL Session ID (negotiated during SSL connection setup) is used to maintain a client-to-server binding. May only be used when load balancing SSL connections. Steps: Client opens an HTTPS connection to the virtual service, Array selects a real service and forwards request to it, Response from real service contains an SSL Session ID, Array tracks SSL SID and real service combination, Next request from client contains SSL SID, Array examines SSL SID and sends request to the same real service that was chosen earlier.
  • TCP Health Check
  • TCP health check simply opens a tcp connection to the backend server. If that connection fails, the server will be marked as “down”. The server will be marked “up” if the TCP connection succeeds. This health check function will check for the presence of the real service by opening the TCP connection to a specific port of the real server. It does not tell you if the service is actually functioning. For checking if the server in question is functioning correctly, you will want to use the HTTP method.
  • TCPS Health Check
  • TCPS health check provides an SSL health check for SLB real servers. If the SSL handshake fails, the server will be marked as “down”. The server will be marked “up” if the SSL handshake succeeds. This health check function will check for the availability of the real service by opening the SSL connection to a specific port of the real server.
  • timeout
  • The maximum idle time before closing connections. Timeout period measured in seconds.
  • TMX
  • Traffic Manager
  • Virtual Service
  • Represents a service that clients can connect to
  • Weight
  • Weighting allows you to change the distribution between real services in the group. You may set one server to handle twice as many connections as another server. Use weighting if you have a mix of backend servers with different performance capabilities. Example: If you add new servers that have faster CPUs, you could weight them higher so they receive more connections.