storage

If you are vaguely familiar with ownCloud, you may have noticed quite a bit of ruckus on the tech blogs back in July when their US business entity was essentially gutted. The Chief Executive Office and cofounder, Frank Karlitschek, announced he was resigning. Within a few weeks, most of the core development team followed suit. This left many long time ownCloud users, such as myself, completely puzzled. Here we are a few months later and a few questions still linger, but many have been answered. First, let’s briefly review what the ownCloud platform provides and why this matters.

What is ownCloud?

ownCloud is an Open Source cloud platform that closely mimics the functionality of Dropbox, Box, Google Drive, and all the other big guys. There is an ownCloud server, that runs on a simple LAMP stack (Linux, Apache, MySQL, PHP), and then there’s a client(s). The client is an application that can be installed on Linux, Windows, OSX, iOS, Android and pretty much everything else. Each user has a folder full of files that magically stays synchronized on the server and each device the client has the software installed on. Then users can share files and folders with other users, collaborate, and the list goes on. Functionality has expanded quite a bit over the years, in way of apps. Apps have integrated mail, calendar, contacts, music, photo galleries and so much more into the ownCloud ecosystem. The main difference between ownCloud, and the big guys mentioned earlier, is it’s completely free. Well, it started out free. Needless to say, with thousands of developers contributing code, and tens of thousands of installations later, it grew. So, when did things go sour?

What happened?

A couple years ago, things started to change. Instead of the community being the driving force behind development decisions and what direction the project was heading (the core principle of Open Source software) venture capital had another idea. Less attention was being given to community submitted bugs and feature requests, and a divide was being formed between the community and ownCloud’s business entities, ownCloud GmbH (Germany) and ownCloud Inc (USA). The business makes money by charging for support, but that started to expand into other areas. The list of complaints from the Open Source community is pretty long, so I’ll give you the headlines.

ownCloud developers were ignoring feedback and hoarding functionality for their paying “enterprise” customers.

User interfaces were mutilated for many of the core services, such as the contacts and calendar apps.

Any attempt to give construction criticism was taken as a personal attack and/or just ignored.

Major defects in the code were being released, such as broken updater utilities.

ownCloud GmbH/Inc was not sharing future road maps and maintained a veil of secrecy.

Today, I’m going to guide you through the process of creating an iSCSI target / extent on FreeNAS-9. This will also work on previous versions of FreeNAS, such as version 7 and 8. There are a few different ways you can go about creating an iSCSI share. You can dedicate an entire device (Hard drive, or RAID array) to the iSCSI share, or you can simply create a Volume, and create multiple iSCSI shares and each is simply a file on the volume. This approach works well because you can use part of a volume as an NFS share, part of it as a CIFS share for Windows, and if you want a few separate iSCSI targets you can just create a single file for each. Lets get started.

How to create an iSCSI Target / Share on FreeNAS

First, we need to add a volume using your hard drive or RAID array that is connected to your FreeNAS server. If you have already done this, you can skip this step. Let’s get started with the rest.

Log into your FreeNAS web interface, and go to Storage > Volumes > Volume Manager. Fill in a volume name (make sure it starts with a letter, and NOT a number, otherwise you will get an error). Add one or more of your Available Disks (by clicking the + sign). Select a RAID type if you wish to do so. In my case, I’m using hardware RAID, so I will leave the default (single drive stripe, IE, JBOD). Now click Add Volume.

Now that we have added a volume, we can begin the process of creating an iSCSI share. This process required multiple steps, in the following order:

GlusterFS is one of the fastest growing Open Source storage platforms in existence. It’s very simple to install, scale, and manage. What makes Gluster so amazing, is its ability to scale and replicate. It really sets the bar for software defined storage systems. It runs on whitebox hardware, or virtual machines. Lately, I’ve come across quite a few people that seem to be scared of Gluster and don’t know where to begin. I am here to help! Today, we’re going to install and configure GlusterFS on a CentOS 7 virtual machine; and, we’re going to make it NFS accessible for VM storage. Every hypervisor in existence supports NFS storage for virtual machines, including VMware ESXi / vSphere, Proxmox, Xen, KVM, oVirt, OpenStack, and all the others.

Installing GlusterFS Server and Client on CentOS 7 (two nodes)

I am using two virtual machines, each running CentOS 7. Their hostnames are gfs1 and gfs2. I have added a 40GB second disk to each VM that will be dedicated to GlusterFS. I suggest you have an identically sized second partition or drive on each of your systems as well.

As always, after connecting via SSH or console, go ahead and make sure everything is updated and upgraded on both nodes.

yum -y update

And, let’s go ahead and install a few useful packages (both nodes).

yum -y install nano net-tools wget

Edit the hosts file on both nodes. Make sure both nodes can resolve to each other via hostname.

Last night I noticed a new version of FreeNAS 9.3 was released. Just two days earlier I built this FreeNAS server, so I wanted everything to be up to date. When I tried to update FreeNAS via the web GUI, it errored out. As I came to find out, this was one of the bugs addressed in the update I was trying to install. It was a catch-22. So, I downloaded the installation disc, burnt it to CD, and booted the FreeNAS server from it. That errored out as well. I had no choice but to blow away the existing installation and do a fresh FreeNAS load. All of my shares and iSCSI targets were stored on a 4 disk RAID-Z array, and FreeNAS itself is installed on an 8GB USB Thumb drive. So, I expected my data to stay in tact.

When I booted the fresh installation for the first time, it automatically imported the zpool stored on the RAID array. I was able to re-create the SMB shares and point them to the /mnt folders those shares pointed to before, everything was going well. Until I got to work trying to bring my iSCSI target volumes back online. In Storage > Volumes, I could see all of the volumes that matched up with my previous ISCSI targets, but I couldn’t import them. I couldn’t figure out how to do anything with them. All of my virtual machines were stored on these volumes so I was desperate to find a solution. I did.

Have you lost your FreeNAS installation? Just recovered from a catastrophe? Recently reinstalled FreeNAS and need to get your iSCSI and other shares back? Going through a FreeNAS recovery? You’ve come to the right place.

How to import an iSCSI target volume from an old FreeNAS installation

First, let’s make sure the volumes that previously correlated to iSCSI targets are visible. Navigate to Storage > View Volumes. Here is what mine looks like.

I’ve been digging into Proxmox VE 3.4 quite a bit lately. I have a FreeNAS server on my network that I use for VM storage in my lab. When I went to add an iSCSI target on Proxmox for virtual machine and image storage, it was a bit confusing. So, I thought I would put a quick step by step guide together to help other folks in the same boat. Here goes.

How to add an iSCSI target in Proxmox

First, log into your Proxmox VE 3.4 server via the web interface. Make sure Datacenter (top level) is selected in the left pane, and make sure you are on the Storage tab on the right pane. It should look like this.

This morning I got an email from the datacenter that informed me of a loud alarm coming from one of my servers. I knew right away it was the LSI card sounding off due to a hard drive failure. Since I almost always use RAID 10 in critical arrays, I was more annoyed than concerned. So, off to the datacenter I went, new drive in hand. While diagnosing the issues, I realized there is no out-of-the-box way to be notified of a drive failure within ESXi. As far as I could tell, everything was fine, except for an audible alarm I would have never heard.

The RAID card in this particular server is an LSI 9260-8i, however this guide is the same for all of the 92xx series cards, like the 9265-8i, or 9265-16i. VMware includes drivers for these cards, starting in ESXi 5.1 if I remember correctly. However, there is no health data for drives and no management interface for arrays. After a couple google searches, I quickly found that there is a lot of conflicting information and tons of problems that go along with installing the LSI MegaRAID Manager, MSM, on ESXi. I also ran into some problems. So, I thought I would put together a quick, easy, clear guide to save others the hassle of going through what I went through. So, here we go.

How to install MSM on ESXi 5.5

To complete this process, you will have to put your ESXi host into maintenance mode, and you will have to reboot. So make sure your VMs are all shut down before proceeding.

Share this!

I always come across pages, links, and things that I don’t want to forget about, and I want to share with the world. So, I decided to create a post with nothing but links. From time to time I will update this post with new links. I’ve tried to categorize everything as much as possible. Be sure to hit the break below to get the full list. Enjoy!