Distributed architecture design and management system development

Distributed System architecture has emerged as a result of the efforts focused on solving the time and space issues of large-scale applications. Prior architectures had taken hardware (multi-processor systems, multi-core processors, etc.) or software (client / server etc.) based approaches to speed up computationally demanding applications, however, these approaches could not keep up with the growth in application scale. On the other hand, achieving the target performance with a constant number of server computers results in high cost solutions. Recent increases in the use of smart phones and tablet computers have triggered substantial improvements in the cost / performance ratios of embedded grade processors and memory components. This observation has led to the idea that it can be possible to build systems with better cost / performance ratios compared to high-end server based systems using existing or custom designed embedded systems. The goal of this work is to divide a large-scale application into small chunks of work that are executed on embedded computers and compare the cost / performance ratio of the resulting system with the existing server based systems. An additional advantage of the resulting system is that the increased number of computers that constitute the system helps distribute the risks associated with system sustainability across a larger number of sub-systems, improving the overall system reliability and efficiency. In the literature survey conducted on distributed systems, mainframe, client/server, distributed objects, computer cluster and grid architectures have been examined, advantages and disadvantages of these architectures have been analyzed. Based on the conducted work, it has been concluded that since the target applications are to be run with high performance and since embedded computers have limited computation resources, the architecture that is best suited for large scale applications is computer clusters, therefore it is selected as the preferred architecture in the thesis. However, computer cluster architecture is not without shortcomings, the most important of which is their lack of platform flexibility. The application to be executed on the computers must be compatible with the processor architecture and the operating system available on the cluster nodes. Within the context of computer systems, platform independence and performance are contradicting design goals, that is, platform independence comes with an apparent performance loss. Since the main goal of this thesis is to increase performance, platform independence will not be taken into account. Computer cluster architecture is based on a central management software on the manager node managing all the nodes present in the cluster to distribute and execute subtasks of the application. The work described in this thesis consists of a central management software along with a matrix multiplication based test application. The resulting control software was used to distribute and execute the matrix multiplication work among nodes. Different from the previous works on this topic, multiple execution, one-to-one backup and pool backup approaches have been examined to increase system reliability. Pool backup approach marks fewer nodes to be kept as sustainability nodes compared to the other approaches, however, still provides better reliability. As a result, pool backup was chosen as the preferred approach in this thesis. On the other hand, system efficiency was increased by (1) optimizing file transfers by avoiding redundant transfers via MD5 based controls, (2) using the scoring algorithm designed as part of this thesis to prioritize the nodes providing a mechanism to assign priority scores to subtasks to be executed at nodes, (3) homogenizing use among all nodes to equalize weathering rates and delay the first breakdown. Regarding the choice of communication framework, Berkeley Sockets, Message Passing Interface, Remote Procedure Call and Distributed Shared Memory approaches have been analyzed. Considering the embedded computers to be used can have varying configuration requirements and in the light of performance tests TCP/IP based Berkeley Sockets was preferred instead of Message Passing Interface, which is typically used in computer clusters. As a result of using Berkeley Sockets, a new messaging structure was designed, implemented and integrated into the central management software. This new structure serializes the objects and files to be transferred, adds to the message structure, and on the receiving side extracts these from the message and reconstructs the objects and files. OSCAR, ROCKS, WareWulf, xCAT and Debian Cluster Components were studied and compared to each other to serve as a reference to the developed software. The central management software achieves partitioning the application into subtasks and executing these subtasks on nodes by three main components, namely, distributor, collector(s) and node(s). Instead of orchestrating the whole process, the distributor only manages the collectors and nodes, simplifying the management of the process and providing component level insulation. Since the transfers between the collector and the nodes are independent of the distributor, there is no need for messaging and synchronization mechanisms between these units. The collector simply processes the rule files that reside on the computers where the application subtasks are located and achieves the transfer of the subtasks to the nodes. Finally, the nodes use the rules and associated files coming from the collector to execute their jobs. All the requirements such as the files that are associated with the subtask to be executed at a node and the parameters are defined as a rule list by the user and stored in rule files. The rules have no specific information about the application to be distributed among the nodes. From the system's point of view, the application is simply a bunch of files, parameter sets and the way the subtasks are to be executed. This guarantees that the central management software is completely agnostic to the application to be executed. The proposed system was tested with two desktop computers and four different types of embedded computers. The embedded computers are Raspberry PI Model B, Raspberry PI 2 Model B, BeagleBone Black Model C and HardKernel ODROID U3. The costs of these embedded computers are within 6-11% of the reference computer. The tests were conducted in three stages. First, the application was run on the reference computer with all the subtasks parallelized. It was observed that the performance did not scale with the number of nodes due to serial execution limitations such as having a single processor and single storage unit. Next, the same application was run on the embedded computers with all the subtasks parallelized and the performance was observed to scale with the number of nodes. This observation leads to the conclusion that the data transfer over network, which is the only serializing factor for this scenario, has negligible effect on the overall performance. Then all the embedded computers were tested separately and their performances relative to the reference computer were measured as 4%, 21%, 11% and 48%, respectively. Finally, a cost analysis was conducted where the cost / performance ratios of the embedded computers were compared to the reference computer to see if these embedded computers can be considered as an alternative to the reference computer. The resulting cost / performance ratios were found to be 58%, 289%, 156% and 314%, respectively. Based on these results, all embedded computers except for first version of Raspberry PI have better cost / performance ratios compared to the reference computer.