readme.md 4.94 KB
Newer Older
1 2 3 4 5 6
# Project Xanadu

## A Hybrid execution environment for Serverless Workloads

Execution environments are typically container oriented for FaaS platforms but this creates problems since containers are on one hand not totally secure and on the other hand not capable of high-performance. This project looks into creating a hybrid execution environment to cater to different workload needs.

7 8 9 10
## Buy one for yourself!

Clone using "git clone --recursive https://git.cse.iitb.ac.in/synerg/xanadu"

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
## Architecture

Xanadu is divided into two extremely loosely coupled modules, the **Dispatch Module (DM)** and the **Resource Manager (RM)** module. The RM looks after resource provisioning and consolidation at the host level while the DM looks after handling user requests and executing those requests at the requisite isolation level using resources provided by the RM. \
A loose architecture diagram of Xanadu is given below.

![Xanadu Architecture](design_documents/hybrid_serverless.png)

## Dispatch Module (DM)

The DM is divided into two submodules the **Dispatcher** and the **Dispatch Daemon**. The Dispatcher runs on the Master node while the Dispatch Daemon runs on each Worker nodes. When a request arrives at the dispatcher, it queries the RM for resources and on receiving the resource requests the Dispatch Daemon to run and execute the function on the specified worker node.

### Directory Structure

```bash
.
├── constants.json
├── dispatch_daemon
│   ├── config.json
│   ├── execute.js
│   ├── index.js
│   ├── isolate.js
│   ├── lib.js
│   ├── local_repository
│   ├── package.json
│   └── package-lock.json
├── dispatcher
│   ├── index.js
│   ├── isolate.js
│   ├── lib.js
│   ├── package.json
│   ├── package-lock.json
│   └── repository
└── package-lock.json
```

### System Requirements

- Node.js (10.x and above)
- g++
- build-essential
- Docker
- Java
- Apache Kafka (Configure to allow auto-delete and auto-registration of topics)

### Starting the server

 After nodejs has been installed

- Install the dependencies: execute `npm install` from within the project folder
- Modify the constants.json file as required.
- For Worker nodes modify the config.json in dispatch_daemon to provide an unique ID to each node.
- Run the Master and Worker server as `npm start` or `node index.js`

Nilanjan Daw's avatar
Nilanjan Daw committed
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87
### Internal Communication Interfaces
Internally DM uses Apache Kafka for interaction between the Dispatcher and the Dispatch Agents, while the messages are in JSON format. 
Every Dispatch Agent listens on a topic which is its own UID (Currently the primary IP Address), the Dispatcher listens on the topics *"response"* and *"heartbeat"*.
- **Request Message:** When a request is received at the Dispatcher, it directs the Dispatch Agent to start a worker environment. A message is sent via the chose Worker's ID topic. \
Format:
```javascript
{ type: "execute",
  function_id: "onetime unique ID",
  runtime: "isolation runtime",
  functionHash: "hash of the function to be run" }
```
- **Response Message:** In response, the worker executes the function, pulling resources from the central repository as required and sends a response. \
Format:
```javascript
{ status: 'success',
  result: 'result of the execution',
  function_id: 'onetime unique ID' }
```
- **Heartbeat Message:** The Dispatch Daemons also publish a periodic Heartbeat message back to the Dispatcher as a liveness test.\
Format:
```javascript
{ address: 'UID of the worker' }
```

88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
### Interaction API

The platform works via a HTTP API based interface, the interface is divided into two parts:

- Deploy: The deploy interface is used to upload the function file and store on the server, and also setup containers and VM images.\
An example CURL command:

```bash
curl -X POST \
  http://localhost:8080/serverless/deploy \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'cache-control: no-cache' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -F runtime=container \
  -F serverless=@/home/nilanjan/Desktop/serverless/hybrid/test/script.js
```

The POST request contains two parameters: 1. *runtime* which specifies the runtime to use viz. isolate, process, container or virtual machine and 2. *severless* which sends the serverless function as file via multipart/form-data.\
On successful deployment the API returns a function key which is to be for function execution.

- Execute: To execute the submitted function, we use the Execute API.\
 An example CURL command:

 ```bash
 curl -X POST \
  http://localhost:8080/serverless/execute/761eec785d64451203293427bea5c7ad \
  -H 'cache-control: no-cache' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -F runtime=process
 ```

The API takes a route value as the key returned by the deploy API and a runtime parameter specifying the runtime to be used.