Eggs Datacenter v.0.1 [Community Report]

6 min readMar 14, 2018

This article is by Edward S.Kevbrin, founder and CEO of Eggs Datacenter, a distributed data center for Edge Computing

Hi! I would like to say a few words on inner workings of the distributed DC in this article. This text is firstly intended for technical specialists. If you are interested in products at our facilities learn about CryptoVPS here.

“Design is not just what it looks like it’s how it works”, — Steve Jobs

*Eggs DC architecture includes 3 administrative levels*

We start with architecture, foundation of the Eggs DC. There are 3 administrative levels at DC:

Local level. KVM virtualization and host resources management
Regional level. Template repositories and backup
Global level. Personal account, order placement system and host rating.

*Proxmox (v.0.1.) host resources management console*

Host resources are the basis of the DC work. They are provided by corporate data centers and ordinary people. All the hardware should meet the certain requirements. It strictly implies separately located servers where all resources are virtualized via 1st level hypervisor. Virtualization refers to the following host resources:

CPU in our case physical cores divide into logical flows thus in fact users work with virtual cores — vCPU.
RAM — random access memory is fully used except the part which is exploited by the hypervisor (approximately 1GB).
GPU — user’s video card. We use direct PCI passthrough which means one video card might be used for one cloud computer and one user. To passthrough GPU we add the following parameter into hypervisor settings: “hostpci0: xx:xx.x, x-vga=on, pcie=1”.
HDD hard drives are slow, but have big volume. Every hard disk gets its own volume and an identification marking like hddqcow [n…n].
SSD are speedy but has a little volume. Every SSD also gets its own identification marking and number like ssdqcow [n…n].

Host templates are stored in few regional repositories, we are planning to store user backups there too (not yet implemented)

Global level includes the user’s control panel, an authentication system, blockchain, and the order system providing random choice of the hosts.

Eggs DC development phases

v.0.1: the order system, integration with KVM is made via API (Proxmox tools), setup of the test hosts, setup of the system responsible for preparation of new hosts via Ansible.
v.0.2: client’s personal account including data on hosts, its locations, current orders, rating
v.0.3: Graphene-based blockchain which can store immutable data on hosts rating and make transactions using an inner token EGS.
v 1.0: a working version with possibility to be freely scaled up to 100 hosts and quickly connect computers of new hosters.
v 1.1: scaling up to 1000 hosts with OpenStack for orchestration.

v.0.1

V. 0.1. implies back-end storing data on hosters, hosts and orders. Working principle of the back-end — Russian Roullette — random choice of the host on the basis of the selected region (worldwide now). As soon as the order is made the system go through several stages before user gets access keys. In particular:

New Order — new order created, no resources allocated yet,
Matcher Order — system found node with free resources and reserved it,
In deployment — cloud computer is creating on the node,
Is deployed — cloud computer is created and started; waiting for IP allocation,
In production — cloud computer is ready to use by customer,
Canceled — Order is canceled, cloud computer is destroyed.

Users get an IP adress, a login and a password at the 5th stage when the cloud computer is ready for action. During the first entry the user should change the login/password, the system uses a Microsoft RDP free tool and an RDP protocol accordingly.

Rating at Graphene

Rating is formed on the basis of the host data. Virtualization system stores and collects the data. We need to know uptime, cores loading, volume of the exploited RAM and the total volume of the storage. Some data goes to blockchain and is stored as a NVS (Name-Value Signatures) like Namecoin, Emercoin etc. Partly the data goes to back-end to let the order system know if there is a free space. More hosts uptime means higher rating to the hoster. I will consider the rating system and working principles of our blockchain in a separate article.

Ready-made templates

Templates are the copies of the operating system (Windows/Linux) prepared in advance where all the programs are already installed. Our DC proposes to choose a ready-made templates for using it on hosts with GPU or without it. We are providing different templates for medium size companies, crypto-users, traders, gamers, and designers. All the templates are stored at reginal repositories and at every host (in technical section qcow). to store the data locally is mandatory and it allows to speed up significantly the process of the cloud computer preparation.

Installed programs depend on the chosen template.

Data transfer. We’ve installed a SynkTryzor to provide an opportunity to backup the data from the folder to your local computer or any chosen cloud system. To make synchronization of the data the system uses p2p and only trustworthy folders without passing through unreliable mediators.
Trading. Templates for traders imply MetaTrader 4 and MetaTRader 5 installed for the cryptocurrency trading using the leverage through FOREX brokers. We recommend to choose the nearest location to the broker in order to get the lowest ping.
Network setup. We have Open VPN installed to provide a private VPN network without any possibility to wiretap on servers’ side.
Cryptocurrency keeping. We have Mist, Bitcoin Core, Zcash and Monero wallets installed.

Principles of an encryption and information security.

I want to speak about security and main working principles of our DC separately.

Only virtualization. Major information leakages go through those RAM that is used by several apps and users. It refers especially to containers using the common operating system. We reckon that we should provide every user with his own OS as a guarantee from wiretapping through RAM.
Stand-alone servers. Hoster (who provide the hardware) can’t use the hardware connected to the distributed DC.
One host — one router — one IP adress. As our facilities are situated locally and have not so much power (5–6 users use one farewall), it’s nor appropriate to waste resources on hacking them. It’s better to attack Amazon and get the data from 200–300 virtual devices.
Mandatory encryption of the communication channel. To use RDP connection you will be asked to give your consent on using a SSL certificate protecting the communication channel between you and a cloud computer.
Mandatory encryption of the LVM volumes. We encrypt hard disks of your cloud computers using cryptsetup function and SHA256 algorithm in order not to allow hackers to get an access to the information even in case they have access to the hard disk. Here is one of the commands used to encrypt the volume: “cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 luksFormat /dev/sdc /root/bin/mykey”.
Online synchronisation. We are proposing to use an open-source application Syncting for the backup of the information from the cloud folders to your computer directly through the p2p protocol.

Market and potential of the business model.

You may learn more about kinds of problems we solve with help of our distributed DC and CryptoVPS here in my article devoted to our vision of the future of domestic data centers and Edge Computing. Potential of the local computing power is huge thus the demand is expected not only on the side of crypto-users but also on a business side especially when we talk about industries where there is need in low ping without latency and online analytics.