CORBIMITE - Web Site Hosting, Domain Name Registration, Managed Servers1-604-591-1140 

 CORBIMITE Web Solutions

DevZone     Webmail   

Server Intellect

CORBIMITE now offers load balanced server clusters:

Server Clustering allows a group of servers to intelligently service requests made to a host name. This high performance architecture allows for significantly greater performance than can be achieved by a single server.

In addition, if any of the services on a single server fail, the requests will be automatically routed to the remaining server. As a result, downtime related to server failures or administrative maintenance can be significantly reduced or eliminated!

CORBIMITE server clusters feature the following:
 

  • Instant activation (servers are sold in pairs)
  • ASIC based, wire speed, hardware load balancing of HTTP, FTP, and SSL traffic
  • Twice the performance of a single server is possible
  • Automatic failover if a server or service becomes unavailable
  • Private network (PNET) "ready"
  • Remote console management to both servers
  • Remote reboot either server independently at the power strip

How Clustering works:

The servers are sold in pairs, and each physical server has 4 IP numbers. Also, in addition to the IP addresses bound to the physical servers, there are an additional 4 virtual IP addresses configured on the load balancer. When HTTP, FTP or SSL requests are made to any of the virtual IP numbers, the load balancer sends the request to one of the physical servers, provided that server is "up" on that service port. If the server is not responding to that service port, all requests will be automatically sent to the remaining server.

Examples:

A standard high availability server cluster is purchased with these IP numbers:

 
IPs on Server #1   IPs on Server #2   Virtual IP Protocols Supported
192.168.1.2 and 192.168.1.6 are mapped to 192.168.1.10 HTTP, FTP, SSL
192.168.1.3 and 192.168.1.7 are mapped to 192.168.1.11 HTTP, FTP, SSL
192.168.1.4 and 192.168.1.8 are mapped to 192.168.1.12 HTTP, FTP, SSL
192.168.1.5 and 192.168.1.9 are mapped to 192.168.1.13 HTTP, FTP, SSL

Example #1 - an e-commerce web site (widgets.com):

a) Create DNS records pointing towards the virtual IP addresses:

 
  Virtual IP
www.widgets.com 192.168.1.10
ftp.widgets.com 192.168.1.11
secure.widgets.com 192.168.1.12

b) Create identical web sites, FTP data and SSL sites on both servers and bind the HTTP, FTP and SSL services to IP addresses as follows:

 
  Server 1 Server 2
HTTP service 192.168.1.2 192.168.1.6
FTP service 192.168.1.3 192.168.1.7
SSL service 192.168.1.4 192.168.1.8

c) Clients communicate to the server cluster through the virtual IP numbers, and the supported requests are balanced across both real servers by changing the destination address at wire speed:

The following example is HTTP, but the same would also apply to both FTP and SSL.

 
Client #1 sends a request to www.widgets.com:
1) HTTP request from the remote client to the load balancer's virtual IP: Client IP -> 192.168.1.10
2) the load balancer changes the destination IP to one of the real servers
3) HTTP request is forwarded from the load balancer to the actual server: Client IP -> 192.168.1.2
The response from the real server:
4) HTTP response from the actual server passes through the load balancer: 192.168.1.2 -> Client IP
5) the load balancer restores the source IP back to the virtual IP
6) HTTP response is forwarded from the load balancer back to the client: 192.168.1.10 -> Client IP

 
Client #2 sends a request to www.widgets.com:
1) HTTP request from the remote client to the load balancer's virtual IP: Client IP -> 192.168.1.10
2) the load balancer changes the destination IP to one of the real servers
3) HTTP request is forwarded from the load balancer to the actual server: Client IP -> 192.168.1.6
The response from the real server:
4) HTTP response from the actual server passes through the load balancer: 192.168.1.6 -> Client IP
5) the load balancer restores the source IP back to the virtual IP
6) HTTP response is forwarded from the load balancer back to the client: 192.168.1.10 -> Client IP

Notice neither the client nor the server is aware of the load balancer as the traffic looks normal to both.

Example #2 - a web host of 200 virtual sites:

a) Create DNS records for www and ftp pointing towards the virtual IP addresses:

 
  Virtual IP
first 50 name based domains 192.168.1.10
second 50 name based domains 192.168.1.11
third 50 name based domains 192.168.1.12
the last 50 name based domains 192.168.1.13

b) Create identical web sites and FTP data on both servers and then bind HTTP and FTP services to all IP addresses as follows:

 
  Server 1 Server 2
HTTP service 192.168.1.2 192.168.1.6
192.168.1.3 192.168.1.7
192.168.1.4 192.168.1.8
192.168.1.5 192.168.1.9
FTP service 192.168.1.2 192.168.1.6
192.168.1.3 192.168.1.7
192.168.1.4 192.168.1.8
192.168.1.5 192.168.1.9

Notes:

- All IP addresses bound to the actual servers are also accessible from the Internet, including the 4 IP addresses on each server that participate in the load balancing. Additional IP addresses are available on request, however none of these additional IP addresses will participate in the load balancing.

- A client will always be mapped to the same physical server while communicating while using the same protocol. This will remain true until either the service fails, or the client has not communicated with the load balancer on that protocol for 1 hour.

- The load balancing method is based on the number of active clients allocated to each physical service. A request from a new client will be mapped to the server with the fewest active clients on that service. An active client is one that has communicated with the load balancer within the last hour.

- The load balancer performs layer 4 checks (opens a TCP connection to the service port) to determine if each service on both servers is "up". These checks are done every 10 seconds, and the service will be marked "down" if it fails 4 consecutive tests. The next time the server responds on the service port, it will be again be marked as available for requests.

- Both active and passive FTP are supported.

- Special server software is typically not necessary, and both the client and the servers are totally unaware of the load balancer.

* The private network (PNET) can be used to communicate between the two servers with un-metered bandwidth. This can be used to synchronize file system data, or utilize the same database. Moreover both of the load balanced servers can use the PNET to share a database hosted by a third server located anywhere on the network, even across datacenters.

* Custom load balancing setups are available with our private rack or private shelf offering. Email Frank Zander for additional details about custom private configurations.
 

 

CORBIMITE Website Hosting is a division of Contract CADD Group