Architecture
From CUGNet
Design
CUGNet makes heavy use out of VMWare Server to allow us to virtualize multiple machines on a single 1U server. This is not only beneficial from the cost standpoint, but also allows us to dynamically meet the needs of the community.
By default, there are always 3 VMs running (CUGWeb, CUGIRC, and CUGShell). All three of these VMs provide the basic services that CUGNet offers in a manner that is both secure and easy to manage. Users log in and interact with the system via CUGShell; their data is mounted into CUGShell via an NFS (Network File System) mount from the physical system. These mount points also allow us to mount in the data needed for CUGWeb to function, while also limiting the amount of access that CUGWeb has to the rest of the environment. In order to prevent the NFS mounts from consuming bandwidth that would otherwise be used by the users and web visitors, the mounts, as well as logging data is pushed through a virtual network specifically built to allow interaction with not only these primary systems, but to also allow users to access any project systems as well.
There is a second virtual network that is also live. This network has no access to the internet and is designated for use with the Hacklab only.
ToDo
While the new environment is in place, there is still a long way to go before it truly is declared stable. The following is a list of items that are on the table to improve the administrative staff's overhead and automate/improve functions.
- Work out any remaining bugs after CUGNet 2.0 goes live...
- Automate user creation (old user creation no longer works and currently more manual work is required).
- Automate vhost creation (new vhost organization is a LOT better, however there is no reason to not be automated).
- Build user management application (Will tie in all the various scripts into a central "console").
- Password Synchronization (Admin users and project systems most effected here).
- Tighten down on Quotas.
- Automate the Hacklab startup/shutdown and provide a means for selecting what VMs to startup.
Future Ideas
- Double RAM to 16 GB
- Upgrade to VMWare Server 2.x
- Backup Systems
- Second Environment in a geographically different location.
- Gain enough users to cover costs??