2016 seems to be the year of big hardware renewals for me - after completely overhauling my virtual infrastructure, I also needed new hard drives for my NAS after nearly 4 years.

NAS, DAS, what?

For many years, I have been using D.I.Y. NAS servers for collecting my data and media library on a single host. After I was switching the hardware platform a couple of times, I'm currently using a HP MicroServer Gen8 with four 2 TB HDDs (see details below!). Once in a week, I'm doing a complete backup of all the data on an external HDD array, Onnto DataTale, that is also equipped with four 2 HDD. Both systems are using RAID-5 volumes. Some people might say that this is kinda paranoid - but some accidents in the past proved that it is basically a good idea to have a backup ("Better safe than sorry"). 🙂

Currently I'm disappointed about the throughput of my NAS, which is caused by my former design. Back then I only planned to use my NAS for the media library, but later I also started to use it as shared storage for my VMware vSphere landscape. The stability is good - the HGST hard drives are running 24/7 even though there are not certified for this purpose and never failed. Storage capacity is also not a problem as I often remove unused data and thus have enough remaining capacity. 🙂

Hard drive selection

When selecting hard drives I focussed on a fixed rotational speed. Variable rotational speeds based on access footprints (à la Coolspin, IntelliPower™) are not applicable to my setup. On the internet (e.g. here) I found out that these technologies can shorten the hard drive life time under Linux as it seems that unnecessary spin down/up commands are executed. Seagate would have been an alternative, but I made terrible experiences with their products. Of course I don't want to start bashing - production problems can occur with every brand and product. For my taste, I had too much defects with Seagate hard drives and didn't want to start yet another experiment - at least for my NAS which is data, that is very important to me. 😉

Finally I had a look at the current Deskstar NAS and Ultrastar series by HGST. I have been using 8 HDDs by HGST in the last couple of years and I was very satisfied. The following table compares my current HDDs with two successor products:

Because throughput was very important to me, I focussed on a cache of 128 MB. The Deskstar NAS and Ultrastar series are only differing slightly regarding the throughput. Big differences can be found regarding the warranty and MTBF (Mean Time Between Failures) - the Ultrastar offers longer warranty and doubled MTBF. Both HDDs are certified for 24/7 usage - unlike my current HDDs. The price difference is also small which made things hard for me.

Like already mentioned, storage capacity was not that important to me - so I decided not to go for 6 TB HDDs. By choosing 4 TB HDDs I would be able to reduce the total amount of HDDs from four to three and still have more capacity(8 TB instead of 6 TB in RAID-5 mode). This would also reduce the higher power consumption impact of the Ultrastar HDDs. If more storage resources are need, I would be able to add another HDDs as the MicroServer offers 4 HDD slots.

At a later point I might by necessary to replace the HDDs of my external array. For this setup I would be sufficient to choose slower HDDs as the DataTale is only used for weekly backups. Another comparison:

Again, the price difference is quite small. Choosing HDDs certified for 24/7 is not necessary as the array is only used sometimes. The model names of the two HDD types also shows, that there are only small differnces (H3IKNAS40003272SE, H3IK40003272SE). Some people say, that there are no technical but marketing differences. 😉

Conclusion

Finally I decided to go for the HGST Ultrastar 7K6000 for my NAS. Once the storage resources of my DataTale are exhausted, I would choose the HGST Deskstar 7K4000 - at this point no HDD upgrade was needed.

Benchmark

The HDDs seem to be very high quality - in comparison with conventional HDDs, they are clearly heavier. The loudness is quite okay, only under high load they are kinda noisy. For a quiet NAS I would consider choosing different HDDs.

Before usage, I'm checking new HDDs for bad blocks. Using HD Tune it is also possible to do performance benchmarks - a good moment to check whether the product can meet the requirements.

With nearly 180 MB/s during read and write benchmarks the advertised 208 MB/s specification is realistic.

Implementation

I have been using mdadm, LUKS und LVM for a long time along with my D.I.Y. NAS systems. I'm not using hardware RAID because it might be necessary to buy the same controller in case of a failure which can be a challenge after some years. Hardware RAID controllers are mainly used to ensure that the Host CPU is able to do other things than managing IO - which is not needed for a NAS. Migrating software RAID volumes under Linux is a simple task - just plug the HDDs into another Linux system and mount the volume. 🙂

After the HDDs have been attached, I created GPT labels and RAID partitions on them:

1# parted /dev/sd{a,b,d} mklabel gpt
2# parted -a optimal -- /dev/sd{a,b,d} mkpart primary 0% 100%
3# parted /dev/sd{a,b,d} set 1 raid on

The next step was to create the RAID-5 volume using mdadm:

1# mdadm --create /dev/md0 --auto md --level=5 --raid-devices=3 /dev/sda1 /dev/sdb1 /dev/sdd1

The initial data synchronization process can be seen by accessing the /proc/mdstat file:

1# cat /proc/mdstat
2md0 : active raid5 sdd1[3] sdb1[1] sda1[0]
3      7813771264 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
4      [>....................]  recovers =  3.8% (151748612/3906885632) finish=331.3min speed=188880K/sec
5      bitmap 0/30 pages [0KB], 65536KB chunk
6
7unused devices: <none>

After this procedure has been finished, the encrypted LUKS container can be created on the RAID volume.

 1# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/md0
 2
 3WARNING!
 4========
 5This will overwrite data on /dev/md0 irrevocably.
 6
 7Are you sure? (Type uppercase yes): YES
 8Enter LUKS passphrase:
 9Verify passphrase:
10Command successful.

Afterwards, the LUKS container can be enabled:

1# cryptsetup luksOpen storage

Finally, the LVM construct including physical volume, volume group and logical volume and a file system can be created:

1# pvcreate /dev/mapper/storage
2# vgcreate vg_storage /dev/mapper/storage
3# lvcreate --name lv_storage --extents 100%FREE
4# mkfs.ext4 /dev/mapper/vg_storage-lv_storage
5# mkdir /mnt/storage

For mounting the encrypted construct I'm using a small script:

1#!/bin/sh
2cryptsetup luksOpen /dev/md0 storage
3vgscan
4lvchange -a y vg_storage
5mount /dev/mapper/vg_storage-lv_storage /mnt/storage

Also, I created another script for unmounting the construct:

1#!/bin/sh
2umount /dev/mapper/vg_storage-lv_storage
3lvchange -a n vg_storage
4cryptsetup luksClose storage

In another benchmark, the encrypted container offers up to 300 MB/s in read mode - quite a good value. The former volume was slower. After a couple of weeks, I'm still very satisfied with the new setup. 🙂