esyker / cnv_raddar_scanner Goto Github PK

Figure 1 depicts how the application is organized. It contains several packages and can work as a Master or a Worker:

• The package pt.ulisboa.tecnico.cnv.solver contains the instrumented solver and is responsible for solving the queries.

• Then we have the master and workers packages and other complementary packages used with a set of utilities needed for the execution of complementary functions (i.e. packages utils and BIT). The Master is the main class of the application: it runs both the Load Balancer and Auto-Scaler on different threads of the same instance. The Load Balancer receives requests, distributes them, receives the results and redirects the response back to the user.

• The Auto-Scaler monitors the performance of each machine and is responsible for starting new instances in case of overloading, terminating instances in case of under-loading and rebooting instances if they become unresponsive.

• The master also contains a singleton class, called Cluster, which acts as the interface to manage units. These are objects of the class Unit which store information and methods that can act on their corresponding AWS instances. Only the Cluster can interact with this class. By doing so we abstract cloud-provider specific methods which helps prevent lock-in. Another important package developed, independent of the master previously explained, is the worker. It consists of the original WebServer class that we customized, the datasets, the ServerArgumentParser and also the customized BIT tool that is used to instrument the code, implemented by the class StatisticsTool.

• Moreover the structure of the application also contains the package provided with the solver that was instrumented with the BIT tool, the package with the BIT tool and bit samples, complementary org classes and the package utils. The utils contains the classes that are used both by the master and workers. These class are the following: AppConfig loads the parameters of the application from a appconfig.json file, presented in Appendix A. To name a few: it defines the AMI Id which the cluster uses to launch units, Elastic IP allocation ID the load balancer gets associated with and the overload/underload thresholds for both units and cluster. This allows for their easy adjustment while avoiding the overhead of compilation. The class DeserializedParameters verifies the compliance of received queries and turns them into a more readable format, aiding in programming. The class DynamoConfig contains all the functions that communicate with the Dynamo database. The class UnitState and ClusterState enumerates all the possible states of the unit and cluster.

Go to appconfig.json. Use public "imageId" to create AWS instance. It will automatically create a load balancer and workers.

• utils: general functions useful to more than one package
• master: loadbalancer and autoscaler code
• worker: web server that solves requests
• EntryPoint: class that decides whether the instance will become a master or worker