abhishekgupta-1/cloudhaoma

Cloud Project (Distributed Storage)

Cloud Haoma

The project was done in a team effort. Team Members:-

1. Supriya Aggarwal 2014A7PS0013P
2. Vidhi Jain 2014A7TS0113P
3. Abhishek Gupta 2014A7PS0026P

Run the following commands on all the nodes of the cluster

Python version 2.7

1. sudo apt-get install nodejs nodejs-legacy npm libzmq-dev git
2. pip install pyzmq-static
3. Open Terminal in the base directory of the project
4. npm install
5. pip install zmq

Network topology is star.

Run the following on the designated router.

1. python2.7 router.py 12345 [[1,2,3],[4,5]] '[6]' false

Run the following on the cluster nodes (you may include router also (Let IPADDRESS of router node for this be 127.0.0.1):-

Group I

1. python2.7 server.py 1 tcp://127.0.0.1 12345 ["1","2","3"] on node1
2. python2.7 server.py 2 tcp://127.0.0.1 12345 ["1","2","3"] on node2
3. python2.7 server.py 3 tcp://127.0.0.1 12345 ["1","2","3"] on node3

Group II

1. python2.7 server.py 4 tcp://127.0.0.1 12345 ["4","5"] on node4
2. python2.7 server.py 5 tcp://127.0.0.1 12345 ["4","5"] on node5

Run the following code on the node which you want to run your web server (Currently webserver tries to insert hardcoded values in the db on receiving the API call instead of using request Data)

1.node clientServer.js 6 tcp://127.0.0.1 12345 true 3000

API CALL:-

IPADDRESSOFWEBSERVER:3000/readData

//For writing request //Requests Information:- //POST REQUEST - multipart/formdata //Keys - fileData, clientId, sourceId

IPADDRESSOFWEBSERVER:3000/pushData

//For reading request //Request Infromation: //Post Request - multipart/formdata //Keys - clientId, sourceId

IPADDRESSOFWEBSERVER:3000/readData

Strategy

Using RAFT for log replication. Each log entry contains the write request by a client. Request contains sufficient information to identify the file. State machine operation is to append the request data to the identified file. Reads can be handled by the leader Data is sharded across the groups (here gropu I and II). Raft replicates the logs on all the nodes of the cluster => So if we run a single Raft instance for our cluster, we can't achieve a replication factor less than that of cluster size => Cluster should be divided into groups(shards) and raft instance should run for that group. => A data item will be present in one group only and replication is within the nodes of that group

Some consensus algorithms support partial replication in which we can control which data will replicated and its replication factor. Raft doesn't support it so we should shard our data to get decrease replication factor. Also, sharding improves writes throughput.

Status

Code for supporting the write and read operation is working with the API Calls.

Reference

This project is based on the raft implementation present at https://github.com/albertdb/Raft.

The entire code was rewritten into python (Original code was written in nodejs which we suspect to be better choice than python because of its asynchronous nature)

ZeroMQ (http://zeromq.org/) is used for providing communication

cloudhaoma's Issues

Connecting Frontend to the clientServer.js

Adding API to register client and their sources

Phase 1:

1. Receive register client request and create the folder for the client
2. Receive login client request and check if the folder exists or not
3. Receive register source request and create the file for the source
4. Receive regular logging requests from source and check if the file exists or not

Phase 2:
Authentication

Use heartbeatTime variable instead

https://github.com/abhishekgupta-1/FUCloud/blob/2d36fe6f780a234158eafeadf379d7f263ff1a14/server.py#L134

Process entries Asynchronously

Do file writes asynchronously.

https://github.com/abhishekgupta-1/FUCloud/blob/2d36fe6f780a234158eafeadf379d7f263ff1a14/server.py#L141

Support for multiple client servers

Support for running web servers on multiple nodes required. Requires changes in router.py.

Closing the program

Need to press Ctrl+C multiple times to close the program because of use of threads. Find a clean way to close the program.

Is votedFor == candidateId required?

https://github.com/abhishekgupta-1/FUCloud/blob/2d36fe6f780a234158eafeadf379d7f263ff1a14/server.py#L170

Single Point of Failure

Current network has star topology. If the router fails, entire cluster goes down.

Adding scripts to test the server

Livelock

Check if livelock occurs because of prevLogIndex < recoveryPrevLogIndex?

https://github.com/abhishekgupta-1/FUCloud/blob/b1101a8204ff5ba8e4b3c13a5bb5185d283d1168/server.py#L243

Consider followerId node enters the recovery node and sends the leader a message containing index of the mismatched log and updates the recoveryPrevLogIndex. If the message is lost and doesn't receive the leader, the leader will not decrement prevLogIndex and call appendEntries with the prevLogIndex value which will be >= than currently updated recoveryPrevLogIndex. In this case followerId node will do nothing.

Support for Read

Nothing is done to support reads.

Use of persistent storage.

We are not making use of persistent storage to store variables like term.

Service Timeout response in Master

Handle the case when Last log entry is behind the oldest log

CloudHaoma/server.py

Line 310 in b1101a8

else: #Last log is behind oldest entry still in the log

Client Write Failure

Bugs in the appendEntries and replyAppendEntries because of which log entry replication fails across nodes of the cluster.

Data Sharding

Instead of replicating data across all nodes we should use data sharding technique.

New Variables not required

We can reduce code length here.

CloudHaoma/server.py

Line 245 in 433b444

log_length = log._length

Connection between webserver and router

I ran the router by the following command.

python2.7 router.py 12345 ["4"] false

The router should listen on 12345 on all IP addresses.

I ran webserver by the following command.

node clientServer.js 4 tcp://127.0.0.1 12345

This is not working today but was working few days ago.

But the following is working now.

node clientServer.js 4 tcp://localhost 12345

Possible explanation???

Sending requests to the cluster.

Presently requests are sent to node 1 and forwarded to the leader node from there. Service will go down if node 1 goes down.

Use `election' variable instead

https://github.com/abhishekgupta-1/FUCloud/blob/2d36fe6f780a234158eafeadf379d7f263ff1a14/server.py#L112

Why log_prevterm = 1000000?

https://github.com/abhishekgupta-1/FUCloud/blob/2d36fe6f780a234158eafeadf379d7f263ff1a14/server.py#L221

Testing performance through httperf