Resource
BlogTopic
Edge ComputeDate
Apr 16, 2020FoundationDB is an open-source distributed NoSQL database released by Apple under the Apache 2.0 license. It is non-relational, so instead of using tables it organizes data as a set of ordered key-values. It can also handle massive volumes of data and is exceptionally well suited for write-intensive workloads.
FoundationDB has been designed from the ground up for distributed computing and, to get the most out of FoundationDB’s performance features, you need to put the database cluster as close as possible to where it is needed. To do this, you can leverage StackPath’s low-latency edge compute VMs to run FoundationDB clusters.
We’ll show you how in the tutorial below. But first, let’s review what makes FoundationDB great and determine if its a good fit for your project.
As the name implies, FoundationDB focuses on working with simple data types such as strings, integers, floating-point numbers, and arrays. Higher-order types are available via installable Layers.
Currently, there are two official Layers:
The scalable nature of FoundationDB makes it a great fit for:
FoundationDB design deliberately limits the size of the transactions. Because of this, the following workloads are NOT compatible with FoundationDB:
Each FoundationDB process uses up to one CPU and is assigned its own data directory. We can run as many processes as CPU cores we have in the machine.
FoundationDB minimum specs for production are:
FoundationDB has two storage modes:
FoundationDB has three levels of redundancy. Each redundancy level represents a different tradeoff between usable space and fault tolerance.
As a general rule, keep in mind the following when deciding what type of machine to choose:
FoundationDB doesn’t have any built-in security mechanisms; there are no database users or passwords, nor read and write permissions. As a result, most deployments will likely only run inside a private network.
Access control must be controlled by other means:
fdb.cluster) to connectTo get started you will need:
You will need an SSH key to access your StackPath servers. If you already have one, you can skip to Step 2.
To create an SSH key pair in Linux or Mac:
ssh-keygen -C "your_email@example.com"On Windows, install PuTTY and use puttygen.exe to generate the key pair.
In this section, we’ll create our first Virtual Machine (VM) on StackPath.
To start, go to StackPath and log in or sign up for an account.
In the left menu, click Workloads and then Create Workload. Name your workload and, on Workload Type, select VM.
On Image select the most recent Ubuntu LTS version available (Ubuntu 18.04 LTS).
Click Continue to Settings.
On Public Ports, type 22 and select TCP.
On First Boot Key, copy the contents of your SSH public key (the file with the .pub extension, for instance: id_rsa.pub).
Click Continue to Spec.
Select the machine Spec that suits your needs. The SP3 machine has enough power to run two FoundationDB processes.
If you’re planning to use the ssd mode, add a volume for the data. On Additional Volume, type /var/lib/foundationdb and set the amount of storage you want to dedicate to the databases on this node.
On Deployment Target, type the name of the deployment group. Deployment targets are groups of instances with the same scaling needs.
Select one of the PoPs that are near you or your users.
For Instances per PoP, select 1.
Create the machine using the Create Workload button.
Wait a few seconds for the machine. You’ll know it’s ready when it reaches the Running status.
Copy the Public IP, as shown in StackPath.
Open a terminal in your machine or start PuTTY.
Connect to the Public IP with SSH or PuTTY using the key generated in Step 1.
Log in with the ubuntu user.
ssh ubuntu@YOUR_NODE1_IPGo to the FoundationDB website’s download page and pick the newest version of FoundationDB server and client packages for Ubuntu.
Copy the addresses of the packages and download both files to the server.
wget https://www.foundationdb.org/downloads/6.2.11/ubuntu/installers/foundationdb-clients_6.2.11-1_amd64.deb
wget https://www.foundationdb.org/downloads/6.2.11/ubuntu/installers/foundationdb-server_6.2.11-1_amd64.debInstall them with dpkg.
dpkg -i foundationdb-clients_6.2.11-1_amd64.deb foundationdb-server_6.2.11-1_amd64.debAfter a few seconds, your first FoundationDB instance should be up and running.
$ ps -e | egrep "(fdb|backup_agent)"
14108 ? 00:00:02 fdbserver
14106 ? 00:00:00 fdbmonitor
14107 ? 00:00:00 backup_agentFoundationDB has three types of processes:
fdbserver processes as CPUs the system has. Each fdbserver has a dedicated port, starting from TCP 4500.fdbmonitor automatically reloads the servers. fdbmonitor is also in charge of managing the backup_agent.To get the server status information use:
fdbcli --exec statusAt any point, you can start, stop, or restart the database with:
systemctl stop foundationdb
systemctl start foundationdb
systemctl restart foundationdbIn this section, we’ll prepare FoundationDB for production.
Copy the configuration to a temporary directory.
cp /etc/foundationdb/foundationdb.conf /tmpOpen the file with your preferred editor.
nano /tmp/foundationdb.confAnd find the [fdbserver] section and uncomment the datacenter_id line.
Set a data center name; you should use an identical string for all nodes in the same PoP. For example, for a node in New York, a good name would be:
datacenter_id = nycIf your server has two CPUs: add the following line right before the [backup_agent] section; this tells FoundationDB to start a second process on port 4501.
[fdbserver.4501]If your server has more than two CPUs: repeat the previous step until the number of processes matches the number of CPUs.
When you complete the modifications, the file should look like this:
[fdbmonitor]
user = foundationdb
group = foundationdb
[general]
restart_delay = 60
cluster_file = /etc/foundationdb/fdb.cluster
[fdbserver]
command = /usr/sbin/fdbserver
public_address = auto:$ID
listen_address = public
datadir = /var/lib/foundationdb/data/$ID
logdir = /var/log/foundationdb
datacenter_id = nyc
[fdbserver.4500]
[fdbserver.4501]
[backup_agent]
command = /usr/lib/foundationdb/backup_agent/backup_agent
logdir = /var/log/foundationdb
[backup_agent.1]Save the file and copy it back to /etc/foundationdb.
cp /tmp/foundationdb.conf /etc/foundationdb/foundationdb.conf
You should now find a second fdbserver process (or as many processes as you configured).
ps -e|egrep "(fdb|backup_agent)"
14106 ? 00:00:00 fdbmonitor
14107 ? 00:00:09 backup_agent
14412 ? 00:00:00 fdbserver
14413 ? 00:00:00 fdbserverYou can also check how many processes are running with fdbcli.
fdbcli --exec status
[...]
Cluster:
FoundationDB processes - 2
Zones - 1
Machines - 1
Memory availability - 4.1 GB per process on machine with least available
[...]In this step, we’ll open the ports for external connections.
Keep in mind that if you have opened ports 4500 or 4501 in StackPath, your server may be publicly accessible. In that case, ensure that you’ve read all the security considerations carefully before continuing.
To allow external connections, install Python.
apt-get update && sudo apt-get install python -y
Then run the make_public.py script. FoundationDB binds itself to the server’s private IP.
/usr/lib/foundationdb/make_public.py
/etc/foundationdb/fdb.cluster is now using address 10.128.96.3Restart the service.
systemctl restart foundationdbThe first server is ready! Now we’ll copy the configuration files to your machine.
End your SSH session with logout or CTRL+D and copy the config and cluster files to your computer.
scp ubuntu@YOUR_NODE1_IP:"/etc/foundationdb/*" .In this step, we’ll create additional nodes to form a cluster. You can stop here if you plan on deploying only one machine.
To provision the rest of the machines, go back to your StackPath dashboard. Locate your FoundationDB workload and click the Gear icon to modify its settings.
Click Edit next to Spec, Storage & Deployment.
In the Deployment Target section, increase the number of instances to the number of nodes you want in the cluster.
Click Save Changes and wait for the new servers to reach the Running status.
FoundationDB clients and servers connect to the cluster using the information contained in the fdb.cluster file.
To add a node to a cluster, we have to copy this file from any server already in the cluster and put it on /etc/foundationdb on the new machine. Once restarted, the new node will automatically join the cluster and start synchronizing.
For each of the new servers, repeat these steps:
scp foundationdb.conf fdb.cluster ubuntu@YOUR_NEW_SERVER_IPcp foundationdb.conf fdb.cluster /etc/foundationdbsystemctl restart foundationdb
In this section, we’ll finalize the configuration of the cluster. Since the servers are linked up, we only need to run the following commands once.
First, ensure you are connected via SSH to any of the servers in the cluster. Then, start an interactive fdbcli session.
fdbcli
Using cluster file `/etc/foundationdb/fdb.cluster'.
The database is unavailable; type `status' for more information.
Welcome to the fdbcli. For help, type `help'.
fdbType status and check the number of machines in the Cluster.
> status
[...]
Cluster:
FoundationDB processes - 6
Machines - 3
[...]Set the coordinator mode to auto so the cluster can automatically nominate coordinators.
> coordinators autoYou can also set a name for the cluster.
> coordinators description=myclusterAfter a few seconds, you should see that the coordinators are activated.
> coordinators
Cluster description: mycluster
Cluster coordinators (3): 10.128.96.3:4500,10.128.96.4:4500,10.128.96.5:4500
Type `help coordinators' to learn how to change this information.If you wish to activate ssd storage mode, set the redundancy level now (single, double or triple).
> configure double ssdCheck the coordinator settings and the redundancy level with status.
> status
Configuration:
Redundancy mode - double
Storage engine - ssd-2
Coordinators - 3
[..]Congratulations! You’ve learned about FoundationDB and how to deploy it using StackPath’s edge compute VMs. You’re on your way to using high performance, low-latency databases.
As a next step, learn how to use datacenter mode to extend your database over more data centers. Then, learn how regions can help you build a truly global distributed database so that data is always close to your users.
Finally, check out these links to continue learning about FoundationDB: