---
# System prepended metadata

title: CSC409

---

### CSC409 Report (weight 25%): 0/27

### Discussing the system's architecture
    
#### 0/3 Diagram showing
    [0] 1 Application system
    [0] 1 Monitoring system
    [0] 1 Data flow

#### 0/14 Discussion of each of the following with respect to your system.
    For each point, as appropriate, show an appropriate diagram, 
            list performance guarantees, discuss code/architecture choices.

    Example: 

    Availability: 
    - the availability guarantees your system provides
    - the architectural choices made to implement this

    Data Partitioning:
    - diagram explaining how data is partitioned
    - outline how your code implements this, for example,
      if you hash, then which hash algorithm
      

    [0] 1 Consistensy (not implemented)
        
        - more in Data partitioning section.
    [0] 1 Availablity (not implemented)
        - Each piece of data will be stored in (int(n * 1/3) + 1) different systems, 
          if less or equal to 1/3 server is down, the data will still be availble. 
    [0] 1 Partition tolarance (not implemented)
    [0] 1 Data paritioning (not implemented)
        - Using hash function to partition data
        - Let h(data1) = i; System count = n, data1 will store in system i%n (i+1)%n
    [0] 1 Data replication (not implemented)
        - Mentioned in Data paritioning section, data will be stored in 3 different system.
        - As long as one of the three host storing data is up, the data will be fine.
        - For example if we have 3 servers, when PUT is hashed to server i, send data to i and i+1. When GET, GET from first, if no request get from the second. 
        - In general if we have n servers, PUT data to at least (n//3)*2 servers (or ceiling division..).
        


    [0] 1 Load balancing (not implemented)
    [0] 1 Caching (not implemented)
    [0] 1 Process disaster recovery (not implemented)
    [0] 1 Data disaster recovery (not implemented)
    [0] 1 Orchestration (not implemented)
    [0] 1 Healthcheck (not implemented)
    [0] 1 Horizontal scalability (not implemented)
        - Very easily add/remove nodes
        - dedicate script for this task
        - redistribute data after add/remove node.
    [0] 1 Vertical scalability (not implemented)
    [0] 1 Well formatted document (implemented)
        - Perfect document by Zixi Qu

#### 0/4 Discussing the system's performance
    [0] 1 Graph showing performance of system under load1
    [0] 1 Analysis of system performance under load1
    [0] 1 Graph showing performance of system under load2
    [0] 1 Analysis of system performance under load2

#### 0/4 Discussing the system's scalability
    [0] 1 Number of hosts vs read requests per second
    [0] 1 Number of hosts vs write requests per second
    [0] 1 Number of hosts vs data stored

#### 0/2 Discussion of the tools used during testing. Listing them is not enough. You must define each tool used, and how you used it


#### Demo (weight 45%): /29

	0/7 Functionality
		0/3 Long to Short (PUT)
			[0] 1 Good request. 201
			[0] 1 Bad request. 400
			[0] 1 UI shows success or failure messages
		0/3 Short to Long (GET)
			[0] 1 Good request. 307
			[0] 1 Bad request. 404
			[0] 1 UI shows success or failure messages
		0/1 UI design
			[0] 1 Simple and clean user interface

	0/5 Monitoring
    		[0] 1 Monitoring system watching the health of the application system
    		[0] 1 Monitoring system is fault tolerant
    		[0] 1 UI showing the status of the hosts
    		[0] 1 UI shows up to date status
    		[0] 1 Simple and clean user interface

	0/7 Disaster recovery
		0/1 Load balancer recovery
			[0] 1 Load balancer recovers/heals from a process dying

		0/2 Application server recovery
			[0] 1 Url shortner recovers/heals from a process dying
			[0] 1 Url shortner recovers/heals from a host dying

		0/4 Data recovery
			[0] 1 Data is persistent after the system recovers/heals from a process dying
			[0] 1 Data is persistent after the system recovers/heals from a host dying
			[0] 1 The application responds after a database file gets corrupt
			[0] 1 The application responds after a database file gets deleted

            0/6 Scalability
                [0] 1 System can be run from empty with n nodes
                    ```python Monitor.py``` to start all hosts in hosts file

                [0] 1 System scales from n to n+1 nodes with minimal intervention

                    ```python Monitor.py -r``` to automated redistribute all data to new servers
                [0] 1 System scales from n to n+1 nodes without downtime
                [0] 1 System makes good use of additional compute
                [0] 1 System makes good use of additional storage
                [0] 1 System makes good use of additional ram

	0/4 Orchestration
        one bash file for all, command line input:
        start/add hostname (call wake function, write hostname to hosts file)
        remove hostname (call remove function)
        shutdown all (call remove on each host)
        
		[0] 1 Automate launching the cluster onto the given systems 
        # Similar to lab, read hosts file, wake each host
		[0] 1 Automate adding a host to the cluster
        # e.g. add a new host in the file, host will start automatically
		[0] 1 Automate removing a host from the cluster
        # similar kill all java
		[0] 1 Automate shutdowning the cluster
        # similar