ZFS Guide
In the following guide we will demonstrate a typical IRONdb installation on Linux, using ZFS.
Last updated
Was this helpful?
In the following guide we will demonstrate a typical IRONdb installation on Linux, using ZFS.
Last updated
Was this helpful?
This guide assumes a server with the following storage configuration:
One or more OS drives with ext4 on LVM, md, etc., depending on installer choices and/or operator preference.
12 data drives attached via a SAS or SATA HBA (non-RAID) that will be used exclusively for ZFS.
If you are new to ZFS, there are some basic concepts that you should become familiar with to best utilize your server hardware with ZFS.
References:
Old but still largely relevant presentation introducing ZFS, from Sun Microsystems
Pools are the basis of ZFS storage. They are constructed out of "virtual devices" (vdevs), which can be individual disks or groupings of disks that provide some form of redundancy for writes to the group.
Review the zpool man page for details.
Datasets are logical groupings of objects within a pool. They are accessed in one of two ways: as a POSIX-compliant filesystem, or as a block device. In this guide we will only be dealing with the filesystem type.
Filesystem datasets are mounted in the standard UNIX hierarchy just as traditional filesystems are. The difference is that the "device" part of the mount is a hierarchical name, starting with the pool name, rather than a device name such as /dev/sdc1. The specific mountpoint of a given filesystem is determined by its mountpoint property. See the zfs man page for more information on ZFS dataset properties.
Please note that IRONdb setup configures all necessary datatset properties. No pre-configuration is required.
On Linux, ZFS filesystems are mounted at boot by the zfs-mount service. They are not kept in the traditional /etc/fstab file.
Packages for ZFS are available from the standard Ubuntu repository.
IRONdb setup expects a zpool to exist, but will take care of creating all necessary filesystems and directories.
For best performance with IRONdb, consider using mirror groups. These provide the highest number of write IOPS, but at a cost of 50% of available raw storage. Balancing the capacity of individual nodes with the number of nodes in your IRONdb cluster is something that Apica Support can help you with.
Using the zpool status command we can see our new pool:
At this point you may wish to reboot the system to ensure that the pool is present at startup.
This step is only required if using the standalone IRONdb product. If you are referring to this appendix as an on-premise Apica Inside user, there is no further manual setup required at this point. All IRONdb setup from this point is handled by the Apica Inside installer.
The setup script takes care of creating the /irondb mountpoint and all other necessary filesystems, as well as setting the required properties on those filesystems. No other administrative action at the ZFS level should be required at this point.
In our example system we have 12 drives available for our IRONdb pool. We will configure six 2-way mirror groups, across which writes will be striped. This is similar to a RAID-10 setup. We will call our pool "data". To simplify the example command we are using the traditional sdX names, but it's recommended that you use for your devices that are less susceptible to change and make it easier to maintain.
Now that you have created a ZFS pool you may begin the IRONdb . If you have multiple pools configured and you want to use a specific pool for IRONdb, you can use the -z option to the setup script.