linux

There are 2 parts to this that I would like to note. First, in order to get drbd, iscsi and multipath to play nicely together under systemd, I had to do the following:
Create /etc/systemd/system/drbd.service.d/override-after.conf with the following contents:

[Unit]
After=systemd-modules-load.service network.target open-iscsi.service dev-mapper-bhqibm01\x2dr6\x2dsata01\x2dlun01.device
Requires=dev-mapper-bhqibm01\x2dr6\x2dsata01\x2dlun01.device

I also had to edite each of the /etc/iscsi/nodes/_iqn_/_ip_/default files and set:

I recently had a look at a few linux deduplicated filesystems, namely opendedup, lessfs and ddumbfs to act as a backup repository storage.

I was frustrated with opendedup because if would return "filesystem full" when there was no obvious reason why the filesystem might be full. As a result, I did not feel confident that I could safely monitor the system to alert me prior to the filesystem filling up.

Lessfs was too slow in my environment using the berkelydb and tokyodb backends, and I could not get hamsterdb to make a clean filesystem

If you want to mount a multipath device during system boot, you need to install the multipath-tools-boot package.

The base Debian config for multipath looks something like this:

When using IPSEC, I prefer to use tunnel interfaces so you can route traffic normally across the tunnel and use BGP/OSPF to transfer routes between sites. I managed to get this working from Linux to Cisco as follows, with redundant DSL connections (yuo can adjust to suit your environment):

On the Cisco router:
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 3600

crypto isakmp key Pre-Shared-Key address Linux-IP-Address no-xauth

Before you begin:

Like any storage device, disk configuration is a factor, including:
• Disk speed (SSD/15k/10k/7200)
• RAID Level
• Write-back cache (Hardware RAID with BBU, Linux bcache, EMC FAST cache)
• Memory for read cache

In addition for the above, dedup appliances need RAM to store the contents of the hash. For SDFS the rule is:
• (volume size / chunk size) * 25. This equated to 256MB per TB for a 128k chunk size, and 8GB per TB for a 4k chunk size.
• You also need CPU to process the data

I have used the following tools to generate disk and filesystem benchmarks to evaluate both the performance of raw disks and different filesystems on the same disk.

ffsb - To benchmark filesystem operations
randomio - To benchmark the IOPS for a given disk
zcav - To generate throughput graphs for the different CAV zones of a hard drive (using gnuplot to generate a graph)

A bunch of servers started seeing very high CPU usage in system time. The cause appeared to be related to a high number of nfs_inode_cache objects:

server:~# slabtop
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
1525524 1525524 100% 1.02K 508508 3 2034032K nfs_inode_cache
966120 856476 88% 0.19K 48306 20 193224K dentry

This was confirmed by running the following to clear the nfs_inode_cache:
server:~# sync
server:~# echo 2 > /proc/sys/vm/drop_caches

To get the Linux kernel to re-scan a scsi controller (to detect missing or newly inserted disks), run the following command


echo "- - -" >/sys/class/scsi_host/hostNUMBER/scan


You can replace any of the "-" characters with a number to scan a specific channel, target or LUN