Documentation of FarrellIT Hosting Network

Preface

The Farrell IT Network is a work in progress, designed to meet the goals, and implemented through the techniques, described below. All services, resources, and mechanisms may not yet be in place. This internal documentation is available soley to facilitate implementation and is not meant as a description of available services nor a service agreement of any kind.

Contents

  1. Infrastructure
    1. Internal Networks
    2. File Storage
    3. Databases
    4. Server Strategy
  2. Services
    1. DNS
    2. Email
    3. Web
    4. FTP Access
    5. SSH Access

Infrastructure

In designing and configuring the infrastructure at Farrell IT, special care has been given to:

Redundancy & High Availability

Steps have been taken to ensure the highest possible uptime in the event of hardware failure. All storage mechanisms are redundant; data is stored on multiple servers and databases are stored in a fully redundent mySQL cluster. Heartbeet solutions for fast automatic failover are being considered.

Networks

In an effort to uinfy subnet allocations throughout the greater network (the extent of which is outside the scope of this document) the 172.17.0.0/21 (172.17.0.0 to 172.17.7.255) address range has been reserved for Farrell IT's networks.

Currently, all storage-level communications occur accross the storage.farrellit.net subnet. Other subnets may be provided as the need arises.

subdomain subnet uses
storage.farrellit.net 172.17.1.0/24 mySQL Cluster
glusterFS Cluster
Internal DNS

File Storage

We are currently experimenting with GlusterFS, which appears to be a promising method of distributing redundant storage to multiple disks on multiple hosts across a network. GlusterFS is currently storing the new production web sites' content; it will likely be used in the future to store email as well.

Gluster has built-in support for failover via round-robin DNS, and so the clusters below also represent rrDNS virtual hosts.

Gluster Servers

ClusterServers Clients Serves
cluster.storage.farrellit.net oak.storage.farrellit.net
cedar.storage.farrellit.net
zeus.storage.farrellit.net
oak.storage.farrellit.net
/mnt/www-fs: high availability storage for webserver data

Database Storage

We are currently testing a distributed and high availability SQL cluster using mySQL. mySQL has been determined to be the best clustered SQL database solution available, because the database needn't rely on a single server.

Database Servers

ClusterServers Clients Serves
cluster.storage.farrellit.net oak.storage.farrellit.net
cedar.storage.farrellit.net
oak.storage.farrellit.net
/mnt/www-fs: high availability storage for webserver data

Server Strategy

The infrastructure is built on two servers, Oak and Cedar. These servers boast moderatly quick processors, fast disks, and plentiful ram. As shown abovce, the storage and database clusters are built on these servers. The technologies used for these core services are flexible enough to allow for additional cluster foundations to be added to the group with relative ease; however, we anticipate a two- or three- server configuration to be sufficient for all anticipated uses.

Additional servers, perhaps without any such provisions, could be configured to use the services offered by the core servers. In this way additional processor power or redundancy can be added to webservers, database API servers, email servers, IMAP servers, &c. without much additional investment in hardware.

Services

Of course. the end goal of all this infrastructure is to be able to offer High Performance, High Availability solutions for public internet services, primarily DNS, Email, and flexible Web Hosting. Corresponding FTP, IMAP, SMTP, and perhaps even SSH services will be provided to support these core Internet services.

DNS

Server Requirements

Ongoing Concerns

Email

Web Hosting

FTP Access

The hope is that FTP access to the data stored in Gluster and made accessible via the share on /mnt/www-fs (as explained above). It will require some userid sharing between webservers and fileservers. I believe it is important to maintain per-user permissions on web content storage; distribution methods for /etc/passwd and related files are being considered. For security reasons I am leaning towards a semi-automated rsync solution.

SSH Access

SSH and FTP access can be provieded nearly at once. With the move of the FTP server away from the physical web servers, the risk of system disease due to widespread SSH access becomes less of a problem. As long as strong user permission checking and, eventually, a chrooted environment, can be enforced, there is no reason that a few lightweight servers can be made available as more or less "disposable" ssh clients.