Oracle : Query to find Active SQL’s in database

set feedback off

set serveroutput on size 9999

column username format a20

column sql_text format a55 word_wrapped

begin

for x in

(select username||'(‘||sid||’,’||serial#||’) ospid = ‘|| process ||

‘ program = ‘ || program username,

to_char(LOGON_TIME,’ Day HH24:MI’) logon_time,

to_char(sysdate,’ Day HH24:MI’) current_time,

sql_address,

sql_hash_value

from v$session

where status = ‘ACTIVE’

and rawtohex(sql_address) <> ’00’

and username is not null ) loop

for y in (select sql_text

from v$sqlarea

where address = x.sql_address ) loop

if ( y.sql_text not like ‘%listener.get_cmd%’ and

y.sql_text not like ‘%RAWTOHEX(SQL_ADDRESS)%’ ) then

dbms_output.put_line( ‘——————–‘ );

dbms_output.put_line( x.username );

dbms_output.put_line( x.logon_time || ‘ ‘ || x.current_time || ‘ SQL#=’ || x.sql_hash_value);

dbms_output.put_line( substr( y.sql_text, 1, 250 ) );

end if;

end loop;

end loop;

end;

/

Oracle : Script Monitor and size the Redo Log buffer

As a DBA, you are responsible to monitor and resize the Redo Log buffer in the SGA memory in case of performance problems. Your job’s responsibilities dictate that you should at least be informed of the following basic fundamental subjects:
– Monitoring the Redo Log Buffer memory size
– Re-sizing the Redo Log Buffer memory size
– Checking the Redo allocation entries ratio
– Checking waiting sessions
– Checking for an Online Full Redo Log file
– Using the V$SESSION_WAIT view
******************************************************************************************************************************************************************
CONNECT sys AS SYSDBA
SELECT name, value FROM v$sysstat
WHERE name = 'redo buffer allocation retries';
Note that if you have a positive number, that means that you may have a problem. Be sure that you have compared the above positive number with the Redo entries and it should not be more than 1%.
SELECT a.value/b.value "redo buffer entries ratio" FROM v$sysstat a, v$sysstat b
WHERE a.name = 'redo buffer allocation entries' AND b.name = 'redo entries';
If the number is greater than 1%, you should increase the size of the Redo Log buffer. You should also check the checkpoint and size of the online redo log file.
SELECT sid, event, seconds_in_wait, state FROM v$session_wait
WHERE event = 'log buffer space';
If the Log Buffer space waits exist, consider increasing the size of the redo log. Also you should check the speed of the disk that the Online Redo Log files are in.
SELECT name, value FROM v$sysstat
WHERE name = 'redo log space requests';
Now, check to see if that Online Redo Log file is full and the server is waiting for the next Redo Log file.
To resize the Online Log Buffer do the following:
ALTER SYSTEM SET log_buffer=###M scope=SPFILE; -- ### is a integer number that you want to assign to your log buffer.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Check Database Start Time and Log on Time of User
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT to_char(startup_time,'DD-MON-YYYY HH24:MI:SS') "DB Startup Time"
FROM   sys.v_$instance;
select to_char(logon_time,'dd/mm/yyyy hh24:mi:ss'),osuser,status,schemaname,machine from v$session where type !='BACKGROUND'; ‎
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To Monitor the Redolog file Statsu (How much it is fill)?
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT lq.leseq  "Current log sequence No", 100*cr.cpodr_bno/lq.lesiz "Percent Full",
cr.cpodr_bno "Current Block No", lq.lesiz  "Size of Log in Blocks"
FROM x$kcccp cr, x$kccle lq
WHERE lq.leseq =CR.cpodr_seq AND bitand(lq.leflg,24) = 8;
 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To check the Group and Member of Redolog
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Prompt
Prompt Redo Log File Locations >>>>
Prompt
col Grp    format 9999
col member format a50 heading "Online REDO Logs"
col File#  format 9999
col name   format a50 heading "Online REDO Logs"
break on Grp
select group#,member
from   sys.v_$logfile;
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To Monitor  Redolog Lateches Statistics
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
COLUMN name  format a30      heading Name
COLUMN percent format 999.999  heading Percent
COLUMN total  heading Total
SELECT l2.NAME, immediate_gets + gets total, immediate_gets "Immediates",
       misses + immediate_misses "Total Misses",
       DECODE (100. * (  GREATEST (  misses + immediate_misses, 1)
       / GREATEST (  immediate_gets + gets, 1) ), 100, 0 ) PERCENT
FROM v$latch l1, v$latchname l2
 WHERE l2.NAME LIKE '%redo%' AND l1.latch# = l2.latch#;

citrix load balancer - Flushing the Surge Queue

When a physical server receives a surge of requests, it becomes slow to respond to the clients that are currently connected to it, which leaves users dissatisfied and disgruntled. Often, the overload also causes clients to receive error pages. To avoid such overloads, the NetScaler appliance provides features such as surge protection, which controls the rate at which new connections to a service can be established.

The appliance does connection multiplexing between clients and physical servers. When it receives a client request to access a service on a server, the appliance looks for an already established connection to the server that is free. If it finds a free connection, it uses that connection to establish a virtual link between the client and the server. If it does not find an existing free connection, the appliance establishes a new connection with the server, and establishes a virtual link between client and the server. However, if the appliance cannot establish a new connection with the server, it sends the client request to a surge queue. If all the physical servers bound to the load balancing or content switching virtual server reach the upper limit on client connections (max client value, surge protection threshold or maximum capacity of the service), the appliance cannot establish a connection with any server. The surge protection feature uses the surge queue to regulate the speed at which connections are opened with the physical servers. The appliance maintains a different surge queue for each service bound to the virtual server.

The length of a surge queue increases whenever a request comes for which the appliance cannot establish a connection, and the length decreases whenever a request in the queue gets sent to the server or a request gets timed out and is removed from the queue.

If the surge queue for a service or service group becomes too long, you may want to flush it. You can flush the surge queue of a specific service or service group, or of all the services and service groups bound to a load balancing virtual server. Flushing a surge queue does not affect the existing connections. Only the requests present in the surge queue get deleted. For those requests, the client has to make a fresh request.

You can also flush the surge queue of a content switching virtual server. If a content switching virtual server forwards some requests to a particular load balancing virtual server, and the load balancing virtual server also receives some other requests, when you flush the surge queue of the content switching virtual server, only the requests received from this content switching virtual server are flushed; the other requests in the surge queue of the load balancing virtual server are not flushed.

Note: You cannot flush the surge queues of cache redirection, authentication, VPN or GSLB virtual servers or GSLB services.

Note: Do not use the Surge Protection feature if Use Source IP (USIP) is enabled.

To flush a surge queue by using the command line interface

The flush ns surgeQ command works in the following manner:

• You can specify the name of a service, service group, or virtual server whose surge queue has to be flushed.
• If you specify a name while executing the command, surge queue of the specified entity will be flushed. If more than one entity has the same name, the appliance flushes surge queues of all those entities.
• If you specify the name of a service group, and a server name and port while executing the command, the appliance flushes the surge queue of only the specified service group member.
• You cannot directly specify a service group member (<serverName> and <port>) without specifying the name of the service group (<name>) and you cannot specify <port> without a <serverName>. Specify the <serverName> and <port> if you want to flush the surge queue for a specific service group member.
• If you execute the command without specifying any names, the appliance flushes the surge queues of all the entities present on the appliance.
• If a service group member is identified with a server name, you must specify the server name in this command; you cannot specify its IP address.

At the command prompt, type:

flush ns surgeQ [-name <name>] [-serverName <serverName> <port>] 

Examples

1. 
flush ns surgeQ –name SVC1ANZGB –serverName 10.10.10.1 80 
The above command flushes the surge queue of the service or virtual server that is named SVC1ANZGB and has IP address as 10.10.10 
2. 
flush ns surgeQ 
The above command flushes all the surge queues on the appliance.  

To flush a surge queue by using the configuration utility

Navigate to Traffic Management > Content Switching > Virtual Servers, select a virtual server and, in theAction list, select Flush Surge Queue.

Load Balancing – Least Connections

Load balancing allows you to distribute client requests across multiple servers. Load balancers improve server fault tolerance and end-user response time. Load balancing distributes client requests across multiple servers to optimize resource utilization. In a scenario with a limited number of servers providing service to a large number of clients, a server can become overloaded and degrade server performance. Load balancing is used to prevent bottlenecks by forwarding the client requests to the servers best suited to handle them. Thus, balancing the load.

In a load balancing setup, the load balancers are logically located between the client and the server farm. Load balancing is used to manage traffic flow to the servers in the server farm. The network diagram shows the topology of a basic load balancing configuration. Load Balancing can be performed on HTTP, HTTP, SSL, FTP, TCP, SSL_TCP, UDP, SSL_BRIDGE, NNTP, DNS, ANY, SIP-UDP, DNS-TCP, and RTSP.

Load balancing uses a number of algorithms, called load balancing methods, to determine how to distribute the load among the servers. When a load balancer is configured to use the least connection method, it selects the service with the least number of active connections to ensure that the load of the active requests is balanced on the services. This method is the default load balancing method because it provides the best performance.

The following example shows how a NetScaler selects a service for load balancing by using the least connections method. Consider the following three services:

• Server-1 is handling 3 active transactions.
• Server-2 is handling 15 active transactions.
• Server-3 is not handling any active transactions.

The load balancer selects the service by using the value (N) of the following expression:
N = Number of active transactions

The requests are delivered as follows:

• Server-3 receives the first request because the service is not handling any active transactions.
  Note: The service with no active transaction is selected first.
• Server-3 receives the second and third requests because the service has the next least number of active transactions.
• Server-1 receives the fourth request.

When Server-1 and Server-3 have same number of active transactions, NetScaler performs load balancing in a round robin manner. Therefore, Server-3 receives the fifth request, Server-1 receives the sixth request, Server-3 receives the seventh request, and Server-1 receives the eighth request and so forth.

Whether it’s load balancing XenApp Web Interface, iPhone/iPad resources, websites, linux servers, windows servers, e-commerce sites, or enterprise applications, NetScaler is the perfect choice. NetScaler, available as a network device or as a virtualized appliance, is a web application delivery appliance that accelerates internal and externally-facing web application up to 5x, optimizes application availability through advanced L4-7 traffic management, increases security with an integrated application firewall, and substantially lowers costs by increasing web server efficiency.

Citrix NetScaler is a comprehensive system deployed in front of web servers that combines high-speed load balancing and content switching with application acceleration, highly-efficient data compression, static and dynamic content caching, SSL acceleration, network optimization, application performance monitoring, and robust application security.

Available as a virtual machine, the NetScaler is perfect for load balancing virtual servers in the datacenter or in the cloud.

How To Run a Multi-Node Cluster Database with Cassandra ?

Introduction

Apache Cassandra is a highly scalable open source database system, achieving great performance on multi-node setups.

Previously, we went over how to run a single-node Cassandra cluster. In this tutorial, you’ll learn how to install and use Cassandra to run a multi-node cluster on Ubuntu 14.04.

Prerequisites

Because you're about to build a multi-node Cassandra cluster, you must determine how many servers you'd like to have in your cluster and configure each of them. It is recommended, but not required, that they have the same or similar specifications.

To complete this tutorial, you'll need the following:

• At least two Ubuntu 14.04 servers configured using this initial setup guide.
• Each server must be secured with a firewall using this IPTables guide.
• Each server must also have Cassandra installed by following this Cassandra installation guide.

Step 1 — Deleting Default Data

Servers in a Cassandra cluster are known as nodes. What you have on each server right now is a single-node Cassandra cluster. In this step, we'll set up the nodes to function as a multi-node Cassandra cluster.

All the commands in this and subsequent steps must be repeated on each node in the cluster, so be sure to have as many terminals open as you have nodes in the cluster.

The first command you'll run on each node will stop the Cassandra daemon.

sudo service cassandra stop

When that's completed, delete the default dataset.

sudo rm -rf /var/lib/cassandra/data/system/*

Step 2 — Configuring the Cluster

Cassandra's configuration file is located in the /etc/cassandra directory. That configuration file,cassandra.yaml, contains many directives and is very well commented. In this step, we'll modify that file to set up the cluster.

Only the following directives need to be modified to set up a multi-node Cassandra cluster:

• cluster_name: This is the name of your cluster.
• -seeds: This is a comma-delimited list of the IP address of each node in the cluster.
• listen_address: This is IP address that other nodes in the cluster will use to connect to this one. It defaults to localhost and needs changed to the IP address of the node.
• rpc_address: This is the IP address for remote procedure calls. It defaults to localhost. If the server's hostname is properly configured, leave this as is. Otherwise, change to server's IP address or the loopback address (127.0.0.1).
• endpoint_snitch: Name of the snitch, which is what tells Cassandra about what its network looks like. This defaults to SimpleSnitch, which is used for networks in one datacenter. In our case, we'll change it to GossipingPropertyFileSnitch, which is preferred for production setups.
• auto_bootstrap: This directive is not in the configuration file, so it has to be added and set tofalse. This makes new nodes automatically use the right data. It is optional if you're adding nodes to an existing cluster, but required when you're initializing a fresh cluster, that is, one with no data.

Open the configuration file for editing using nano or your favorite text editor.

sudo nano /etc/cassandra/cassandra.yaml

Search the file for the following directives and modify them as below to match your cluster. Replaceyour_server_ip with the IP address of the server you're currently working on. The - seeds: list should be the same on every server, and will contain each server's IP address separated by commas.

/etc/cassandra/cassandra.yaml

. . .

cluster_name: 'CassandraDOCluster'

. . .

seed_provider:
  - class_name: org.apache.cassandra.locator.SimpleSeedProvider
    parameters:
         - seeds: "your_server_ip,your_server_ip_2,...your_server_ip_n"

. . .

listen_address: your_server_ip

. . .

rpc_address: your_server_ip

. . .

endpoint_snitch: GossipingPropertyFileSnitch

. . .

At the bottom of the file, add in the auto_bootstrap directive by pasting in this line:

/etc/cassandra/cassandra.yaml

auto_bootstrap: false

When you're finished modifying the file, save and close it. Repeat this step for all the servers you want to include in the cluster.

Step 3 — Configuring the Firewall

At this point, the cluster has been configured, but the nodes are not communicating. In this step, we'll configure the firewall to allow Cassandra traffic.

First, restart the Cassandra daemon on each.

sudo service cassandra start

If you check the status of the cluster, you'll find that only the local node is listed, because it's not yet able to communicate with the other nodes.

sudo nodetool status

Output

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns    Host ID                               Rack
UN  192.168.1.4  147.48 KB  256          ?       f50799ee-8589-4eb8-a0c8-241cd254e424  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless

To allow communication, we'll need to open the following network ports for each node:

• 7000, which is the TCP port for commands and data.
• 9042, which is the TCP port for the native transport server. cqlsh, the Cassandra command line utility, will connect to the cluster through this port.

To modify the firewall rules, open the rules file for IPv4.

sudo nano /etc/iptables/rules.v4

Copy and paste the following line within the INPUT chain, which will allow traffic on the aforementioned ports. If you're using the rules.v4 file from the firewall tutorial, you can insert the following line just before the # Reject anything that's fallen through to this point comment.

The IP address specified by-s should be the IP address of another node in the cluster. If you have two nodes with IP addresses 111.111.111.111 and 222.222.222.222, the rule on the111.111.111.111 machine should use the IP address 222.222.222.222.

New firewall rule

-A INPUT -p tcp -s your_other_server_ip -m multiport --dports 7000,9042 -m state --state NEW,ESTABLISHED -j ACCEPT

After adding the rule, save and close the file, then restart IPTables.

sudo service iptables-persistent restart

Step 4 — Check the Cluster Status

We've now completed all the steps needed to make the nodes into a multi-node cluster. You can verify that they're all communicating by checking their status.

sudo nodetool status

Output

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns    Host ID                               Rack
UN  192.168.1.4  147.48 KB  256          ?       f50799ee-8589-4eb8-a0c8-241cd254e424  rack1
UN  192.168.1.6  139.04 KB  256          ?       54b16af1-ad0a-4288-b34e-cacab39caeec  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless

If you can see all the nodes you configured, you've just successfully set up a multi-node Cassandra cluster.

You can also check if you can connect to the cluster using cqlsh, the Cassandra command line client. Note that you can specify the IP address of any node in the cluster for this command.

cqlsh your_server_ip 9042

You will see it connect:

Output

Connected to My DO Cluster at 192.168.1.6:9042.
[cqlsh 5.0.1 | Cassandra 2.2.3 | CQL spec 3.3.1 | Native protocol v4]
Use HELP for help.
cqlsh>

Then you can exit the CQL terminal.

exit

Conclusion

Congratulations! You now have a multi-node Cassandra cluster running on Ubuntu 14.04. More information about Cassandra is available at the project's website. If you need to troubleshoot the cluster, the first place to look for clues are in the log files, which are located in the /var/log/cassandra directory.

Citrix NetScaler :Setting Up Basic Load Balancing

Setting Up Basic Load Balancing

Before configuring your initial load balancing setup, enable the load balancing feature. Then begin by creating at least one service for each server in the load balancing group. With the services configured, you are ready to create a load balancing virtual server, and bind each service to the virtual server. That completes the initial setup. Before proceeding with further configuration, verify your configuration to make sure that each element was configured properly and is operating as expected.

To set up basic load balancing, see the following sections:

• Enabling Load Balancing
• Configuring Services
• Creating a Virtual Server
• Binding Services to the Virtual Server
• Verifying the Configuration

Enabling Load Balancing

You can configure load balancing entities such as services and virtual servers when the load balancing feature is disabled, but they will not function until you enable the feature.

To enable load balancing by using the command line interface

At the command prompt, type the following command to enable load balancing and verify the configuration:

• enable ns feature LB 
• show ns feature

EXAMPLECopy

> enable ns feature LoadBalancing 
Done 
> show ns feature 

Feature Acronym Status 
------- ------- ------ 
1) Web Logging WL OFF 
2) Surge Protection SP ON 
3) Load Balancing LB ON 
. 
. 
. 
24) NetScaler Push push OFF 
Done

To enable load balancing by using the configuration utility

Navigate to System > Settings and, in Configure Basic Features, select Load Balancing.

Configuring Services

After you enable the load balancing feature, you must create at least one service for each application server that is to be included in your load balancing setup. The services that you configure provide the connections between the NetScaler appliance and the load balanced servers. Each service has a name and specifies an IP address, a port, and the type of data that is served.

If you create a service without first creating a server object, the IP address of the service is also the name of the server that hosts the service. If you prefer to identify servers by name rather than IP address, you can create server objects and then specify a server's name instead of its IP address when you create a service.

When you create a service that uses UDP as the transport layer protocol, a ping monitor is automatically bound to the service. A ping monitor is the most basic of the built-in monitors. When you create a service that uses TCP as the transport layer protocol, a TCP_default monitor is automatically bound to the service. When you develop a strategy for managing your load balancing setup, you might decide to bind a different type of monitor, or multiple monitors, to the service.

Creating a Service

Before you create a service, you need to understand the different service types and how each is used. The following list describes the types of services supported on the NetScaler appliance.

HTTP

Used for load-balanced servers that accept HTTP traffic, such as standard web sites and web applications. The HTTP service type enables the NetScaler appliance to provide compression, content filtering, caching, and client keep-alive support for your Layer 7 web servers. This service type also supports virtual server IP port insertion, redirect port rewriting, Web 2.0 Push, and URL redirection support.

Because HTTP is a TCP-based application protocol, you can also use the TCP service type for web servers. If you do so, however, the NetScaler appliance is able to perform only Layer 4 load balancing. It cannot provide any of the Layer 7 support described earlier.

SSL

Used for servers that accept HTTPS traffic, such as ecommerce web sites and shopping cart applications. The SSL service type enables the NetScaler appliance to encrypt and decrypt SSL traffic (perform SSL offloading) for your secure web applications. It also supports HTTP persistence, content switching, rewrite, virtual server IP port insertion, Web 2.0 Push, and URL redirection.

You can also use the SSL_BRIDGE, SSL_TCP, or TCP service types. If you do so, however, the NetScaler performs only Layer 4 load balancing. It cannot provide SSL offloading or any of the Layer 7 support described above

FTP

Used for servers that accept FTP traffic. The FTP service type enables the NetScaler appliance to support specific details of the FTP protocol.

You can also use TCP or ANY service types for FTP servers.

TCP

Used for servers that accept many different types of TCP traffic, or that accept a type of TCP traffic for which a more specific type of service is not available.

You can also use the ANY service type for these servers.

SSL_TCP

Used for servers that accept non-HTTP-based SSL traffic, to support SSL offloading.

You can also use the TCP service type for these services. If you do so, the NetScaler appliance performs both the Layer 4 load balancing and SSL offloading.

UDP

Used for servers that accept UDP traffic. You can also use the ANY service type.

SSL_BRIDGE

Used for servers that accept SSL traffic when you do not want the NetScaler appliance to perform SSL offloading. Alternatively, you can use the SSL_TCP service type.

NNTP

Used for servers that accept Network News Transfer Protocol (NNTP) traffic, typically Usenet sites.

DNS

Used for servers that accept DNS traffic, typically nameservers. With the DNS service type, the NetScaler appliance validates the packet format of each DNS request and response. It can also cache DNS responses. You can apply DNS policies to DNS services.

You can also use the UDP service type for these services. If you do, however, the NetScaler appliance can only perform Layer 4 load balancing. It cannot provide support for DNS-specific features.

ANY

Used for servers that accept any type of TCP, UDP, or ICMP traffic. The ANY parameter is used primarily with firewall load balancing and link load balancing.

SIP-UDP

Used for servers that accept UDP-based Session Initiation Protocol (SIP) traffic. SIP initiates, manages, and terminates multimedia communications sessions, and has emerged as the standard for Internet telephony (VoIP).

You can also use the UDP service type for these services. If you do, however, the NetScaler appliance performs only Layer 4 load balancing. It cannot provide support for SIP-specific features.

DNS-TCP

Used for servers that accept DNS traffic, where the NetScaler appliance acts as a proxy for TCP traffic sent to DNS servers. With services of the DNS-TCP service type, the NetScaler appliance validates the packet format of each DNS request and response and can cache DNS responses, just as with the DNS service type.

You can also use the TCP service type for these services. If you do, however, the NetScaler appliance only performs Layer 4 load balancing of external DNS name servers. It cannot provide support for any DNS-specific features.

RTSP

Used for servers that accept Real Time Streaming Protocol (RTSP) traffic. RTSP provides delivery of multimedia and other streaming data. Select this type to support audio, video, and other types of streamed media.

You can also use the TCP service type for these services. If you do, however, the NetScaler appliance performs only Layer 4 load balancing. It cannot parse the RTSP stream or provide support for RTSPID persistence or RTSP NATting.

DHCPRA

Used for servers that accept DHCP traffic. The DHCPRA service type can be used to relay DHCP requests and responses between VLANs.

DIAMETER

Used for load balancing Diameter traffic among multiple Diameter servers. Diameter uses message-based load balancing.

SSL_DIAMETER

Used for load balancing Diameter traffic over SSL.

Services are designated as DISABLED until the NetScaler appliance connects to the associated load-balanced server and verifies that it is operational. At that point, the service is designated as ENABLED. Thereafter, the NetScaler appliance periodically monitors the status of the servers, and places any that fail to respond to monitoring probes (called health checks) back in the DISABLED state until they respond.

Note: You can create a range of services from a single CLI command or the same dialog box. The names in the range vary by a number used as a suffix/prefix. For example, service1, service2, and so on. From the configuration utility, you can specify a range only in the last octet of the IP address, which is the fourth in case of an IPv4 address and the eighth in case of an IPv6 address. From the command line, you can specify the range in any octet of the IP address.

To create a service by using the command line interface

At the command prompt, type:

add service <name> <serverName> <serviceType> <port>

EXAMPLECopy

add service Service-HTTP-1 192.0.2.5 HTTP 80

To create a service by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Services.

2. In the details pane, click Add.

3. In the Create Service dialog box, specify values for the following parameters:

• Service Name—name
• Server—serverName
• Protocol—serviceType
• Port—port

4. Click Create, and then click Close. The service you created appears in the Services pane.

Creating a Virtual Server

After you create your services, you must create a virtual server to accept traffic for the load balanced Web sites, applications, or servers. Once load balancing is configured, users connect to the load-balanced Web site, application, or server through the virtual server’s IP address or FQDN.

Note: The virtual server is designated as DOWN until you bind the services that you created to it, and until the NetScaler appliance connects to those services and verifies that they are operational. Only then is the virtual server designated as UP.

To create a virtual server by using the command line interface

At the command prompt, type:

add lb vserver <name> <serviceType> <ip> <port>

EXAMPLECopy

add lb vserver Vserver-LB-1 HTTP 10.102.29.60 80

To create a virtual server by using the configuration utility

Navigate to Traffic Management > Load Balancing > Virtual Servers, and then create a virtual server.

Binding Services to the Virtual Server

Note: A service can be bound to a maximum of 500 virtual servers.

After you have created services and a virtual server, you must bind the services to the virtual server. In most cases, services are bound to virtual servers of the same type, but you can bind certain types of services to certain different types of virtual servers, as shown below.

Virtual Server Type	Service Type	Comment
HTTP	SSL	You would normally bind an SSL service to an HTTP virtual server to do encryption.
SSL	HTTP	You would normally bind an HTTP service to an SSL virtual server to do SSL offloading.
SSL_TCP	TCP	You would normally bind a TCP service to an SSL_TCP virtual server to do SSL offloading for other TCP (SSL decryption without content awareness).

The state of the services bound to a virtual server determines the state of the virtual server: if all of the bound services are DOWN, the virtual server is marked DOWN, and if any of the bound services is UP or OUT OF SERVICE, the state of the virtual server is UP.

To bind a service to a load balancing virtual server by using the command line interface

At the command prompt, type:

bind lb vserver <name> <serviceName>

EXAMPLECopy

bind lb vserver Vserver-LB-1 Service-HTTP-1

To bind a service to a load balancing virtual server by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Virtual Servers, and select a virtual server.
2. Click in the Service section, and select a service to bind.

Note: You can bind a service to multiple virtual servers.

Verifying the Configuration

After finishing your basic configuration, you should view the properties of each service and load balancing virtual server in your load balancing setup to verify that each is configured correctly. After the configuration is up and running, you should view the statistics for each service and load balancing virtual server to check for possible problems.

Viewing the Properties of a Server Object

You can view properties such as the name, state, and IP address of any server object in your NetScaler appliance configuration.

To view the properties of server objects by using the command line interface 

At the command prompt, type:

show server <serverName>

EXAMPLECopy

show server server-1

To view the properties of server objects by using the configuration utility

Navigate to Traffic Management > Load Balancing > Servers. The parameter values of the available servers appear in the details pane.

Viewing the Properties of a Virtual Server

You can view properties such as the name, state, effective state, IP address, port, protocol, method, and number of bound services for your virtual servers. If you have configured more than the basic load balancing settings, you can view the persistence settings for your virtual servers, any policies that are bound to them, and any cache redirection and content switching virtual servers that have been bound to the virtual servers.

To view the properties of a load balancing virtual server by using the command line interface

At the command prompt, type:

show lb vserver <name>

EXAMPLECopy

show lb vserver Vserver-LB-1

To view the properties of a load balancing virtual server by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Virtual Servers.

2. In the details pane, click a virtual server to display its properties at the bottom of the

details pane.

3. To view cache redirection and content switching virtual servers that are bound to this

virtual server, click Show CS/CR Bindings.

Viewing the Properties of a Service

You can view the name, state, IP address, port, protocol, maximum client connection, maximum requests per connection, and server type of the configured services, and use this information to troubleshoot any mistake in the service configuration.

To view the properties of services by using the command line interface

At the command prompt, type:

show service <name>

EXAMPLECopy

show service Service-HTTP-1

To view the properties of services by using the configuration utility

Navigate to Traffic Management > Load Balancing > Services. The details of the available services appear on the Services pane.

Viewing the Bindings of a Service

You can view the list of virtual servers to which the service is bound. The binding information also provides the name, IP address, port and state of the virtual servers to which the services are bound. You can use the binding information to troubleshoot any problem with binding the services to virtual servers.

To view the bindings of a service by using the command line

At the command prompt, type:

show service bindings <name>

EXAMPLECopy

show service bindings Service-HTTP-1

To view the bindings of a service by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Services.

2. In the details pane, select the service whose binding information you want to view.

3. In the Action tab, click Show Bindings. 

Viewing the Statistics of a Virtual Server

To evaluate the performance of virtual servers or to troubleshoot problems, you can display details of the virtual servers configured on the NetScaler appliance. You can display a summary of statistics for all the virtual servers, or you can specify the name of a virtual server to display the statistics only for that virtual server. You can display the following details:

• Name
• IP address
• Port
• Protocol
• State of the virtual server
• Rate of requests received
• Rate of hits

To display virtual server statistics by using the command line interface

To display a summary of the statistics for all the virtual servers currently configured on the NetScaler, or for a single virtual server, at the command prompt, type:

stat lb vserver [-detail] [<name>]

EXAMPLECopy

>stat lb vserver -detail

Virtual Server(s) Summary

vsvrIP port Protocol State Req/s Hits/s

One * 80 HTTP UP 5/s 0/s

Two * 0 TCP DOWN 0/s 0/s

Three * 2598 TCP DOWN 0/s 0/s

dnsVirtualNS 10.102.29.90 53 DNS DOWN 0/s 0/s

BRVSERV 10.10.1.1 80 HTTP DOWN 0/s 0/s

LBVIP 10.102.29.66 80 HTTP UP 0/s 0/s

Done

To display virtual server statistics by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Virtual Servers.

2. If you want to display the statistics for only one virtual server, in the details pane, select the virtual server whose statistics you want to display.

3. In the details pane, click Statistics.

Viewing the Statistics of a Service

You can view the rate of requests, responses, request bytes, response bytes, current client connections, requests in surge queue, current server connections, and so forth using the service statistics.

To view the statistics of a service by using the command line interface

At the command prompt, type:

stat service <name>

EXAMPLECopy

stat service Service-HTTP-1

To view the statistics of a service by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Services.

2. In the details pane, select the service whose statistics you want to view (for example, Service-HTTP-1).

3. Click Statistics. The statistics appear in a new window.