Another example for Virtual Server Construct
virtual pavankumar_vs {
snatpool pavan_snatpool_sp
destination 1.1.1.1:80
pool pavan_pl
ip protocol tcp
rules pavan_test_rl
persist source_ip_persist_pr
profiles{
clientssl_pavan_pr{
client side
}
serverssl_default_tcs_pr{
serverside
}
http_default_tcs_pr{}
tcp_default_tcs_pr{}
}
vlans p_bspos_f_r_770 enable
}
Health Monitors
A monitor
is a test that the LTM can perform on either a node of member. A monitor
typically tests for a specific response within a specified time period. BigIP
uses the results of this to decide on whether traffic should be sent to the
node or pool member.
TYPES OF MONITORING
There 4
main types of monitoring:
Address Check - IP address
(Node)
Service Check - IP : port
Content Check - IP :
port & check data returned
Interactive Check - Interactive with servers. Multiple
commands and multiple responses.
ADDRESS CHECK
This is the
simplest type of check. An example of an address check is ICMP. This is used to
ping an IP address and if there is no response within the specified time period
the node is marked as down.
SERVICE CHECK
Rather then
just checking the IP Service Checks monitors the port. This is achieved by
issuing a layer 4 connection to the node. The connection is opened and closed.
If connection fails, the member is marked as as down and no traffic is
distributed to the particular node.
CONTENT CHECK
Content
Checks check whether the server is also serving the correct content. Once the
TCP connection is opened, a command is sent (such as a HTTP GET) and the
response is examined and the connection closed. If the connection fails or the
received string is not obtained the member is marked as down and no further
connections are sent to the member.
Note :
It is important that the receive string is not configured using a string that
may be also used with any error pages (such as a 404 page), as this would
prevent the monitor from correctly marking the the member as offline.
INTERACTIVE CHECK
Protocols
such as FTP require interactive checks as additional commands such as username,
password and directory are typically required.
Typically Interactive Checks consist of a TCP connection that is opened,
command(s) are then sent, the responses examined and the connection closed.
If any condition fails the member is marked as down and no further connections
are sent to the member.
Note :
Most interactive checks are external monitors. External monitors external
scripts (perl, shell etc) that the LTM calls to perform the required tests (and
to aggregate the results).
Below
describes the various interactive checks available:
Scripted
Monitors - Scripted Monitors use the Expect method/"model"
(send/expect) to determine a nodes health. Expect is a UNIX binary that sends a
command and then expects are specific response back.
External Monitors - External Monitors are custom shell scripts that can be
created to determine the health of a node.
Performance Monitors - As the name suggests Performance monitors deem the
nodes health by querying the nodes performance. There are a number of methods
in which this can be achieved. These are :
- Dynamic Ratio LoadBalancing - Dynamic Ratio Load-Balancing
queries the given agent on either a RealNetwork RealServer, WMI or SNMP based
platform to determine a ratio value. This ratio value is then dynamically
assigned to the node.
- SNMP DCA - SNMP DCA determines performance via the data
collected from the nodes SNMP agent.
- SNMP DCA Base - SNMP DCA determines performance via only
the user-data collected from the nodes SNMP agent.
- WMI - WMI determines performance via the data collected
from the nodes WMI agent.
Normally Health Monitors are either Layer 7 or Layer 4
based.
Layer 7 load balancers health check the performance of the applications on the servers, these servers that come from the hardware and/or virtual load balancer manufacturers
Example : HTTP or HTTPS
Layer 4 load balancers are able to monitor the health of the server and decide whether to take it out of the network or to continue to use it, these load balancers cannot monitor the health of the applications
Example: TCP or UDP
Recommended Setting - Timeout = (3 x Interval) + 1 sec.
Interval - Interval between checks.
Timeout - Defines how long F5 should wait before marking a node/member as down.
SCRIPTED MONITORS
You use the Scripted type of monitor to generate a simple script that reads a file that you create. The file contains send and expect strings to specify lines that you want to send or that you expect to receive.
expect 220
send HELO bigip1.somecompany.net\r\n
expect 250
send quit\r\n
|
Using a Scripted monitor, you can then generate a script that acts on the above file. When the Scripted monitor script reads this file, the script examines each line, and if the line has no quotation marks (" "), the line is sent or expected to be received as is. If the line is surrounded by quotation marks, the script strips off the quotation marks, and examines the line for escape characters, treating them accordingly.
Name ""
Type Scripted
Import Settings scripted
Interval 10
Timeout 31
Manual Resume No
Check Until Up No
Filename <filename>
Alias Address * All Addresses
Alias Service Port * All Ports
Debug No
|
Name
Specifies a unique name for the custom monitor, such as my_scripted_monitor.
Type
Specifies the type of monitor you are creating.
Interval
Specifies the frequency at which the system issues the monitor check. The default is 10 seconds.
Timeout
Specifies the number of seconds in which the node must respond to the monitor request. The default is 31 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.
Manual Resume
Using the Manual Resume setting, you can manually designate a resource as being available.
Check Until Up
Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member.
Filename
The Filename setting specifies the name of a file that you create. The file contains send and expect strings to specify lines that you want to send or that you expect to receive.
Alias Address and Alias Service Port
The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses.
The Debug setting specifies whether the monitor sends error messages and additional information to a log file created and labeled specifically for the monitor. Possible values for the Debug setting are No and Yes. The default setting is No, which specifies that the system does not redirect error messages and additional information related to this monitor. The Yes setting specifies that the system redirects error messages and additional information to the/var/log/<monitor_type>_<ip_address>.<port>.log file. You can use the log information to help diagnose and troubleshoot unsuccessful health checks.
External Monitors
Using an External type of monitor, you can create your own monitor type. To do this, you create a custom External-type monitor and within it, specify a user-supplied monitor to run.
Name ""
Type External
Interval 5
Timeout 16
Manual Resume No
Check Until Up No
External Program ""
Arguments ""
Variables ""
Alias Address * All Addresses
Alias Service Port * All Ports
|
Name
Specifies a unique name for the custom monitor, such as my_external_monitor.
Type
Specifies the type of monitor you are creating.
Interval
Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.
Timeout
Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.
Manual Resume
Using the Manual Resume setting, you can manually designate a resource as being available.
Check Until Up
Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member.
External Program
It is the External Program setting that you use to specify the executable name of your user-supplied monitor program. An External-type monitor searches the directory /usr/bin/monitors for that monitor name.
Arguments
The Arguments setting allows you to specify any command-line arguments that are required.
Variables
This setting specifies the variables that an External monitor requires, namely a Name/Value pair.
Alias Address and Alias Service Port
The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses
HTTP Monitors
You can use an HTTP type of monitor to check the status of Hypertext Transfer Protocol (HTTP) traffic. Like a TCP monitor, an HTTP monitor attempts to receive specific content from a web page, and unlike a TCP monitor, may send a user name and password.
Name ""
Type HTTP
Interval 5
Timeout 16
Manual Resume No
Check Until Up No
Send String GET /
Receive String ""
User Name ""
Password ""
Reverse No
Transparent No
Alias Address * All Addresses
Alias Service Port * All Ports
|
Name
Specifies a unique name for the custom monitor, such as my_http_monitor.
Type
Specifies the type of monitor you are creating.
Interval
Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.
Timeout
Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.
Manual Resume
Using the Manual Resume setting, you can manually designate a resource as being available.
Check Until Up
Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member.
Send String and Receive String
This type of monitor takes a Send String value and a Receive String value. If the Send String value is blank and a connection can be made, the service is considered up. A blank Receive String value matches any response. The check is successful when the content matches the Receive String value. Note that you can specify the value of a response header as the Receive String value. For example, the value of the Receive String attribute can be 404 Object Not Found.
User Name and Password
If there is no password security, you must use blank strings [""] for the Username and Password settings.)
Transparent and Reverse
Both Transparent and Reverse modes are options.
HTTPS MONITORS
You use an HTTPS type of monitor to check the status of Hypertext Transfer Protocol Secure (HTTPS) traffic. An HTTPS type of monitor attempts to receive specific content from a web page protected by SSL security. The check is successful when the content matches the Receive String value.
The BIG-IP system provides two pre-configured HTTPS monitors, https and https_443. Figure A.6 shows the settings of the pre-configured monitor https, and Figure A.7 shows the settings of the pre-configured https_443.
Name ""
Type HTTPS
Interval 5
Timeout 16
Manual Resume No
Check Until Up No
Send String GET /
Receive String ""
Cipher List ""
User Name ""
Password ""
Compatibility Enabled
Client Certificate ""
Reverse No
Transparent No
Alias Address * All Addresses
Alias Service Port * All Ports
|
Name
Specifies a unique name for the custom monitor, such as my_https_monitor or my_https_443_monitor.
Type
Specifies the type of monitor you are creating.
Interval
Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.
Timeout
Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.
Manual Resume
Using the Manual Resume setting, you can manually designate a resource as being available.
Check Until Up
Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member.
Send String and Receive String
This type of monitor takes a Send String value and a Receive String value. If the Send String value is blank and a connection can be made, the service is considered up. A blank Receive String value matches any response. The check is successful when the content matches the Receive String value. Note that you can specify the value of a response header as the Receive String value. For example, the value of the Receive String attribute can be 404 Object Not Found.
Cipher List
If you do not specify a cipher list, the monitor uses the default cipher list DEFAULT:+SHA:+3DES:+kEDH.
User Name and Password
If there is no password security, you must use blank strings [""] for the Username and Password settings.)
Compatibility
When you set the Compatibility setting to Enabled, this sets the SSL options to ALL.
Client Certificate
You use the Client Certificate setting to specify a certificate file that the monitor then presents to the server.
Transparent and Reverse
Both Transparent and Reverse modes are options.
Alias Address and Alias Service Port
The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses.
PERFORMANCE MONITORS
Real Server
A Real Server type of monitor checks the performance of a pool, pool member, or node that is running the RealSystem Server data collection agent. The monitor then dynamically load balances traffic accordingly. Performance monitors are generally used with dynamic ratio load balancing.
Note: Unlike health monitors, performance monitors do not report on the status of a pool, pool member, or node.
The BIG-IP system provides a pre-configured Real Server monitor named real_server.
Name ""
Type Real Server
Interval 5
Timeout 16
Manual Resume No
Method GET
Command GetServerStats
Metrics ServerBandwidth:1.5, CPUPercentUsage, MemoryUsage, TotalClientCount
Agent Mozilla/4.0 (compatible: MSIE 5.0; Windows NT)
|
Like all pre-configured monitors, the real_server monitor cannot be modified by users. However, if you want to modify the Metrics setting, you can create a custom Real Server monitor, to which you can add metrics and modify metric values.
Name
Specifies a unique name for the custom monitor, such as my_real_server_monitor.
Type
Specifies the type of monitor you are creating.
Interval
Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.
Timeout
Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.
Manual Resume
Using the Manual Resume setting, you can manually designate a resource as being available
Gateway ICMP Monitor
A Gateway ICMP type of monitor has a special purpose. You use this monitor for a pool that implements gateway failsafe for high availability.
A Gateway ICMP monitor functions the same way as an ICMP monitor, except that you can apply a Gateway ICMP monitor to a pool member. (Remember that you can apply an ICMP monitor to a node only and not a pool member.)
Name ""
Type Gateway ICMP
Interval 5
Timeout 16
Manual Resume No
Check Until Up No
Transparent No
Alias Address * All Addresses
Alias Service Port * All Ports
|
Name
Specifies a unique name for the custom monitor, such as my_gw_icmp_monitor.
Type
Specifies the type of monitor you are creating.
Interval
Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.
Timeout
Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.
Manual Resume
Using the Manual Resume setting, you can manually designate a resource as being available.
Check Until Up
Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member.
Transparent
The Transparent mode is an option for this type of monitor. When you set this mode to Yes, the monitor pings the node with which the monitor is associated.
Alias Address and Alias Service Port
The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses.
LTM Comes with a set of monitors known as "monitorroot"
Monitor Examples
monitorroot type http {
defaults from none
interval 5
up interval 0
timeout 16
time until up immediate
dest *:*
ignore down response disable
enable
is read only
partition Common
}
monitor gateway_icmp_default_mn{
defaults from gateway_icmp
interval 30
timeout 91
}
Example HTTP Monitor
monitorroot type http {
defaults from none
interval 5
up interval 0
timeout 16
time until up immediate
dest *:*
ignore down response disable
enable
is read only
partition Common
password none
recv disable none
recv none
send "GET /\r\n"
username none
}
monitor http_default_mn{
defaults from http
recv "200 OK"
send "GET /health/health.htm
HTTP/1.0\r\n\r\n"
}
Example TCP Monitor
monitorroot type tcp {
defaults from none
interval 5
up interval 0
timeout 16
time until up immediate
dest *:*
ignore down response disable
enable
is read only
partition Common
recv disable none
recv none
send none
}
monitor tcp_80_crml_mn{
defaults from tcp
dest *:http
}
pool ams_r7pd002srs_crml_80_pl{
lb method member predictive
monitor all tcp_80_crml_mn
members {
10.174.72.14:http{}
10.174.72.15:http{}
}
}
Multiple Monitor Example
pool mail_alo_mns_135_7575_7576_pl{
lb method least conn
action on svcdown reselect
slow ramp time 600
monitor all tcp_7575_mms_mn and tcp_7576_mms_mn and
https_443_mms_mn
members{
10.228.4.10:any{}
10.228.4.11:any{}
}
STATUS DUE TO MONITORS
TYPES
There are 4 main status types (with regards to monitors). These are :
- Up / Available - Means the most recent monitor check was successful.
- Down / Offline - Means no response equal to the configured timeout period.
- Unknown - Typically means no monitor is assigned nor the monitor has yet to return a result.
- Connection Limit / Unavailable - Previously defined connection limit has been reached. In turn no traffic is sent.
POOLS
Pools are group of servers that will be used as resources for the VIP
They are consist of
- Load Balancing Method
- Pool Members
- Protocol port
- monitor
Pool features
You can configure Local Traffic Manager to perform a number of different operations for a pool. For example, you can:
- Associate health monitors with pools and pool members
- Enable or disable SNAT connections
- Rebind a connection to a different pool member if the originally-targeted pool member becomes unavailable
- Specify a load balancing algorithm for a pool
- Set the Quality of Service or Type of Service level within a packet
- Assign pool members to priority groups within a pool
Load Balancing Pool
A load balancing pool is a logical set of devices, such as web servers, that you group together to receive and process traffic. Instead of sending client traffic to the destination IP address specified in the client request, Local Traffic Manager sends the request to any of the servers that are members of that pool. This helps to efficiently distribute the load on your server resources.
When you create a pool, you assign pool members to the pool. A pool member is a logical object that represents a physical node (server), on the network. You then associate the pool with a virtual server on the BIG-IP system. Once you have assigned a pool to a virtual server, Local Traffic Manager directs traffic coming into the virtual server to a member of that pool. An individual pool member can belong to one or multiple pools, depending on how you want to manage your network traffic.
The specific pool member to which Local Traffic Manager chooses to send the request is determined by the load balancing method that you have assigned to that pool. A load balancing method is an algorithm that Local Traffic Manager uses to select a pool member for processing a request. For example, the default load balancing method is Round Robin, which causes Local Traffic Manager to send each incoming request to the next available member of the pool, thereby distributing requests evenly across the servers in the pool.
Load Balance Methods
Methods fall into two groups
Round Robin(static)
- BigIP gets a new request and sends to the first server in the pool
- The next request is sent to the next server in the pool
- This process repeats
- Round Robin mode works well in most configurations, especially if the equipment that you are load balancing is roughly equal in processing speed and memory.
Ratio(static)
- Ratio values are placed on the pool members
- Used to send a percentage of traffic to a certain pool member based upon the weight
Priority(Static)
- Set a priority to members of the pool
- Often used to send all traffic to one server and if the server fails, then send traffic to the other pool member
Least Connection(Dynamic)
- Makes a LB decision based upon which server has the least amount of connections
Nodes
- Pool members are a combination of IP address and a port
- Nodes are objects that consist of only the pool member's IP Address
- Nodes can be used in many pools
- You don't need to create a node before creating a pool member
- Nodes are created as soon as pool member is created
PROFILES
- Provides information for how the VIP should behave
- Controls how connections are managed
- Can provide more details packet inspection based upon the profile
- You must have a profile assigned to a vitual server. If the profile is not specified, will use a TCP or UDP by default depending upon the protocol
b virtual pavan_vs{
destination 1.1.1.1:80
pool pavan_pl
ip protocol tcp
profile tcp_default_pr
}
Profile Categories
Protocol
FastL4
Services
Persistence
SSL
- Client - Decrypting Traffic between Client and LTM
- Server - Encrypting Traffic between LTM and Server
Viewing Profile Configuration
b profile <profile_name> list
- Will show common parameters of the profile
b profile <profile_name> list all
- Will show all parameters of the profile
Profile types
The LTM system provides several types of profiles. While some profile types correspond to specific protocols, such as HTTP, SSL, and FTP, other profiles pertain to traffic behaviors applicable to multiple protocols. Examples of these are connection persistence profiles and authentication profiles.
PROFILE TYPE
|
DESCRIPTION
|
|---|
Protocol profiles
|
Fast L4
|
Defines the behavior of Layer 4 IP traffic.
|
Fast HTTP
|
Improves the speed at which a virtual server processes traffic.
|
TCP
|
Defines the behavior of TCP traffic.
|
UDP
|
Defines the behavior of UDP traffic.
|
Services profiles
|
HTTP
|
Defines the behavior of HTTP traffic.
|
FTP
|
Defines the behavior of FTP traffic.
|
SSL profiles
|
Client SSL
|
Defines the behavior of client-side SSL traffic. See also Persistence Profiles.
|
Server SSL
|
Defines the behavior of server-side SSL traffic. See also Persistence Profiles.
|
Persistence profiles
|
Cookie
|
Implements session persistence using HTTP cookies.
|
Destination Address
|
Implements session persistence based on the destination IP address specified in the header of a client request. Also known as sticky persistence.
|
Hash
|
Implements session persistence in a way similar to universal persistence, except that the LTM system uses a hash for finding a persistence entry.
|
MSRDP
|
Implements session persistence for Microsoft Remote Desktop Protocol sessions.
|
SIP
|
Implements session persistence for connections using Session Initiation Protocol Call-ID.
|
Source Address
|
Implements session persistence based on the source IP address specified in the header of a client request. Also known as simple persistence.
|
SSL
|
Implements session persistence for non-terminated SSL sessions, using the session ID.
|
Universal
|
Implements session persistence using the LTM system's Universal Inspection Engine (UIE).
|
Authentication profiles
|
LDAP
|
Allows the LTM system to authenticate traffic based on authentication data stored on a remote Lightweight Directory Access Protocol (LDAP) server.
|
RADIUS
|
Allows the LTM system to authenticate traffic based on authentication data stored on a remote RADIUS server.
|
TACACS+
|
Allows the LTM system to authenticate traffic based on authentication data stored on a remote TACACS+ server.
|
SSL Client Certificate LDAP
|
Allows the LTM system to control a client's access to server resources based on data stored on a remote LDAP server. Client authorization credentials are based on SSL certificates, as well as defined user groups and roles.
|
SSL OCSP
|
Allows the LTM system to check on the revocation status of a client certificate using data stored on a remote Online Certificate Status Protocol (OCSP) server. Client credentials are based on SSL certificates.
|
Other profiles
|
OneConnect
|
Enables client requests to reuse server-side connections. The ability for the LTM system to reuse server-side connections is known as Connection PoolingTM.
|
Stream
|
Defines the behavior of Real-Time Streaming Protocol (RTSP) traffic.
|
