Distributed Servers
Risks with Distributed Servers
Situation At Risk
There are a growing number of distributed departmental applications housed on a server located within the
department for convenience of maintenance.
High Level Risk
The McMaster campus network is almost as open as the Internet, in that it's a semi-public network with client machines used by students, faculty & staff owned & managed by individuals, with wide variation in practice whereby operating system upgrades & anti-viral or anti-malware software updates are applied. Also, there is no control over devices plugged into a network jack in offices & labs across campus, so there's risk of network loops being created if devices are connected "backwards", swamping switches with large redundant traffic flows, disrupting normal traffic.
Specific Risks
Examples of symptoms arising from the nature of the campus network described above:
- Occasional local performance degradation:
- If client machines are located in various building networks (e.g. point of sale systems), and a central server is in another building's network (e.g. central sales server & application database), then a successful transaction requires that the client building's local network be operating normally to send traffic across the campus core to the building LAN where the server is located, which also must be operating normally to pass the transaction to the server.
- If a client machine in either building were infected (e.g. a malware-infected machine in the building is activated by a remote botnet, or somebody plugs a device in which causes a network loop), then short bursts of high volumes of traffic can disrupt normal traffic in that LAN for a short period of time. Where longer-term disruptions are likely to be noticed, and the offending client's port shut down for causing a problem for other users, short-term bursts can pass unnoticed by most casual users, but may cause disruption for applications which support 'real-time' transactions across campus such as POS terminals.
- Security Concerns:
- Servers performing payment card transactions should be protected by a firewall to ensure that transactions originate only from designated point of sale systems configured to access the server. University central firewalls cannot protect servers distributed around campus, so the best compromise is a small local firewall in front of those servers, with the requirement for the department running the application to also manage the firewall rules.
Risk Reduction - These risks can be mitigated in several ways:
- Distribution Layer Routing:
- Preventing layer 2 traffic from crossing the campus core isolates problems to a building or a section of a building, rather than allowing disruptive traffic to affect the core causing widespread disruption. Routing traffic on the building distribution switch protects the core & other subnets.
- Locating Servers Centrally:
- A designated machine room subnet is used to host application servers. These servers are on a separate subnet, and hence not subject to sporadic performance issues caused by wayward clients within a building LAN, and this subnet is placed behind a separate 'Hosts' firewall with more stringent rules to limit server access to designated classes of clients specific to each application. UTS servers are being located within this type of machine room environment, and once the second data centre renovation is complete (expected summer, 2009), an area within that room is expected to be designated as a hosted environment within which departments can physically locate their servers, while managing them remotely.
- Improved Application Design:
- An application which is designed to tolerate transaction delays and retry automatically with appropriate short delays if there's no response will be more tolerant of short disruptions than a design which assumes the network is more controlled and centrally managed than the University network can be.
- Updating Edge Switches:
- Older switches lack security features which help detect spanning tree loops and abnormal traffic flows automatically and shut down the offending port until the problem is rectified.
- Improved Monitoring:
- While this will help, it won't prevent problems, but may detect them more quickly. This doesn't help with distributed servers trying to perform real-time transactions.
Service Desk
| Hours: | Monday - Friday 8:30 am - 4:30 pm |
|---|---|
| Phone: | 905-525-9140 x24357 (2HELP) |
| Email: | uts@mcmaster.ca |
| Location: | Main Campus BSB Rm. 245 |
| Service Catalog: | |
| http://www.mcmaster.ca/uts | |
Service Bulletins
- There are no Service Bulletins at this time