Clusters follow general guidelines for different applications. In this page we examine some applications of clusters and possibly suitable applications. We stress that the examples given in these situations may not be suitable in similar situations, every aspect of design must be taken into account when making decisions about cluster architecture.
Database Replication – MySQL database replication cluster as a backend for a website.
Batch Processing – When many tasks need scheduling.
Render Farm – Distributed rendering cluster configuration.
Software Development Architecture – Compile Farm – Clusters for software development.
Message Passing Architectures – Essentially Supercomputers for true high performance applications.
Database replication is a necessary and useful application of clusters. Many databases are read intensive with many more read requests made than write requests. By replicating the data across a community of nodes it is possible to scale the number of read requests which can be dealt with per second in a linear fashion.
Figure 1 demonstrates a read intensive replicating database. This kind of architecture is becoming common in modern webserving environments.
A website has large amounts of content all stored in a MySQL database. The web servers (which are also probably clustered), make read requests from the replication nodes through a load balancer. Write requests are sent to the master node.
Multi master configurations are also common. In situations with high levels of writes it is necessary to be creative with the architecture of the database to allow replication between masters or partition the database such that there are essentially two separate databases for different queries. For example one database for searches and another for user data.
Batch processing systems are key in the banking industry. Good scheduling and rapid response are important if for example we are not to be kept waiting at the cash point as our bank checks we have the money in our account we just asked for.
Sometimes referred to as compute farm, the key part of batch processing systems is maximising up time and maintaining performance at peak load while minimising cost levels.
In this sort of situation it can be wise to save money by reducing capcity during low demand by shutting down some nodes and bringing them back up when demand will be high. To maximise efficiency a intelligent Workload Management System (WMS) should be implemented.
Render farms are a special form of batch processing clusters, with less of an emphasis on responsiveness – most of the processing jobs will take more than a minute. Low cost hardware and the quantity of available processing power is most important. Rendering is used in the visual effects, computer modelling and CGI industries and refers to the process of creating an image from what are essentially mathematical formulae. Rendering engines provide numerous different features, which in combination can produce a scene with the desired effects.
One of the most intensive aspects of these processes is in producing photo realistic scenes and animations. This is where clusters come into their own.
Illustrated in Figure 2 is a simple render farm. An artist working at their workstation submits an animation job to the farm which distributes it between the nodes and returns the result to the workstation or keeps the files on a network share for convenience.
Alternatively a single frame can be submitted and distributed between all the nodes. This can either make use of message passing or split the frame into smaller chunks and pass each one to the different nodes.
A compile farm takes a very similar approach to render farms. The difference is in how the code being developed is handled.
Compile farms provide the opportunity to increase the speed of compilation of a complete program. Although the individual file a developer is working on may only take a matter of seconds to compile when the entire program is put together it may take an hour or more! Additionally it is important to provide the means to develop embedded applications, where compiling on the host may be painfully slow.
Ainkaboot believe in making things a simple a possible, so our systems can be integrated into you existing code management system or we can deploy an entirely new system with the cluster managing your CVS (Concurrent Versions System) and development, verification, pre-production and production environments as well.
The most impressive massively parallel applications make use of all the CPU’s across the nodes as one giant system, providing significant quantities of processing power suitable for intensive simulation and modelling applications.
MPI stands for Message Passing Interface and numerous implementations exist all with their own particular advantages. However an MPI standard has been agreed on and Ainkaboot support all the open source MPI implementations available.
The architecture of an MPI cluster depends on the specific application and many Supercomputing clusters are designed specifically with a couple of applications in mind. However there are some general points to note.
A key feature of MPI systems is low latency networks for internode communication. As such the newtwork switching technology is important for determining the eventual performance of the system. Additionally the application must be designed to take advantage of the system and should also take advantage of the processors architecture in use.
Figure 4 demonstrates a MPI cluster, a well designed application will scale almost linearly with the addition of more nodes allowing increases in accuracy and speed for modelling and simulation.