Tag: Storage

Building the lab 5: Storage I

On By sam.aaronIn Daily, Home Lab, HowTo, ProjectsLeave a comment

This part of my homelab rebuild will touch on something interesting… storage options. Knowing that my lab is going to be a couple levels of nesting, I wanted to look at the different options that are out there.

For years, I have had and use a Synology DS 1512+ storage array. This thing has been running like gangbusters. It serves multiple purposes from backups & fileshares, to NFS storage for the virtual environment.

Over the years, I have upgraded the drives from 1TB to 2TB, to 3TB. Because of this, I have a few drives lying around not in use. I thought that maybe I could spin up a FreeNAS or OpenFiler box for iSCSI within the environment. By creating differing storage arrays, I could introduce Storage Policies within the environment for potential feature consumption down the road.

As I explored the various options out there, I discovered many simulators from various vendors: 3PAR, EMC, NetApp. In addition to these, you have the free options as mentioned above: OpenFiler, FreeNAS, etc. But I also stumbled across this jewel….. XPEnology.

I’m sure you are wondering — What is XPEnology?
Xpenology is a bootloader for Synology’s operating system which is called DSM (Disk Station Manager) and is what they use on their NAS devices. DSM is running on a custom Linux version developed by Synology. Its optimized for running on a NAS server with all of the features you often need in a NAS device. Xpenology creates the possibility to run the Synology DSM on any x86 device like any pc or self-built NAS.

You read that right, it is possible to run XPEnology on bare metal. XPEnology runs as a faux Synology NAS.

Now, before you continue, you should know this. XPEnology is not supported or owned by Synology, micronauts, or anyone in their right mind. The links provided are ONLY for experimentation purposes and should not be used in any production or development environment. It is very possible you could lose all data and put yourself in jeopardy. If you need reliable, dependable storage, then buy a Synology NAS.

PROCEED AT YOUR OWN RISK!

Alex Lopez at ThinkVirtual has a good write up on how to create a Synology Storage VM
https://ithinkvirtual.com/2016/04/30/create-a-synology-vm-with-xpenology/

Alex’s write up was based on Erik Bussink’s build, found here.
https://www.bussink.ch/?p=1672

The original XPEnology website walkthrough on how to create a Synology Storage VM.
http://xpenology.me/installing-dsm-5-1-vmware-esxi5-5u1/

The original Xpenology website has become a ghost-town. I’m not sure if it is being maintained, or if the original creator(s) just don’t have the time to update it any longer. The last updates came out around DSM 5.2-5644.5 (so a while ago). However, the XPEnology forums will provide all kinds of glorious information from the wealth of knowledge within the community.

Additionally, you can get more information from this new XPEnology info site. They also have a pretty good walk-through for a storage VM. The video tutorial even covers how to setup ESXi 5.1 (http://xpenology.org/installation/).

I chose to build on baremetal.
While having a storage VM is great, I think having XPEnology on baremetal is even better. As you read and research how to do this, you are going to discover that it involves grabbing files stashed all over the internet — files ranging from a bootloader to PAT files. Make sure that you read EVERYTHING. I reutilized some hardware and some of my old synology drives and built a XPEnology server on bare metal.

I booked marked this site (https://github.com/XPEnology/JunLoader/wiki/Installing-DSM-6.0-Bare-Metal) as it provides a pretty good walkthrough on how to create a bootable USB drive for the XPEnology OS. I also found this one (http://blog.pztop.com/2017/07/24/Make-Xpenology-boot-loader-1.02b-for-DSM-6.1-on-Ubuntu/). For those of you, like myself, who are on a MAC…. you may need this nugget (https://xpenology.com/forum/topic/1753-create-a-bootable-usb-on-os-x/).

Again, I would like to say, if you need reliable and dependable storage, go purchase a real storage array.

How to Mount a USB Drive as an ESXi Datastore

On By sam.aaronIn ESXi, Home Lab, HowTo, Projects, VMware7 Comments

Seagate Backup Plus Portable Drive
Seagate Backup Plus Portable Drive

Recently, I have upgraded my homelab – yet again. There will be an oncoming post about the hardware I chose and how it is set up. This time, my lab is mobile. I can take it with me on the road or leave it at home.
One of the features that I wanted to be able to capture and utilize was VMware Data Protection (vDP) to backup my Infrastructure and Important VMs. However, there was a small hurdle that I needed to overcome – storage – and how do I make it mobile. VDP requires – at minimum, a 2TB datastore for backup storage. Normally, you would utilize your storage array and carve out some space for the backups; I wanted to see if I could do something different – something radical. I wanted to use my USB3 USB drive.
Continue reading “How to Mount a USB Drive as an ESXi Datastore” →

PernixData – First Impressions

On By sam.aaronIn Daily, ESX, Projects, VMwareLeave a comment

PernixData Dashboard
PernixData Dashboard
As you’ve probably guessed, I got a new toy in the lab at work. I’m talking PernixData v1.0. For my initial review, I will say that the install, setup, and configuration was very simple — just a few steps actually. This was probably the easiest installation that I’ve done in the last year.
Continue reading “PernixData — First Impressions” →

Script: Changing the Path Selection Policy

On By sam.aaronIn Daily, ESXi, HowTo, VMwareLeave a comment

Last week I had performed a semi-automatic (scripted) turn key installation. Before going out to the customer site, I had set the install script to set the SATP and the PSP for an Equallogic Array (SATP = VMW_SATP_EQL, PSP = DELL_PSP_EQL_ROUTED) during the installation. Unfortunately, I found out after the fact, that they had a Compellent Array. Because of this, I needed to change the SATP and the PSP (SATP = VMW_SATP_DEFAULT_AA, PSP = VMW_PSP_RR) for each of the existing LUNs and any future LUNs.
Continue reading “Script: Changing the Path Selection Policy” →

SAN Loop Failure

On By sam.aaronIn Daily, ESX, VMwareLeave a comment

Here’s an example of how important it is for your VMware Engineers to either have visibility into the SAN infrastructure, or work very intimately with the SAN Admins.

We lost a fiber loop on one of our NetApp FAS 3160 SANs yesterday. If my team did not receive the critical fail-over emails, we would not have known that there were storage issues for a couple of vital hours.

When your customers are complaining that there is something wrong with their VMs, or they have lost access to them; it is imperative to investigate and start troubleshooting. If we would have started troubleshooting without the knowledge of the SAN issue, then we would have started working on the VMs, which would have quickly led back to the ESX hosts they resided on. Troubleshooting the ESX hosts could have potentially made our outage A LOT worse.

This particular environment consists of a virtual center 4.1 and eight ESX 4.01 U2 hosts. There happens to be a bug in ESX 4.XX that occurs when a rescan is issued while an all-paths-down state exists for any LUN in the vCenter Server cluster. Therefore, a virtual machine on one LUN stops responding (temporarily or permanently) because a different LUN in the vCenter Server cluster is in an all-paths-down state. (Yeah, I cut and paste that from the VM KB, that you can read here.) The VM KB also mentions that the bug was fixed in ESX 4.1 U1.

Since we were receiving the outage emails, we knew that something was up with our storage. This allowed us to work closely with our storage admins to understand the full extent of the outage.

The details of our recovery goes something like this: A fail-over from Node A to Node B was made during the outage, however, Node B did not have access to the failed loop, therefore the aggregate on that loop was down. Node B carried the load for all other working aggregates giving our storage guys and the NetApp technician time to work on the loop. When repairs were completed, a fail-back (give-back) was done to allow Node A to take back over its share of the load. We confirmed with the NetApp tech that all paths and LUNs were represented to the ESX hosts. We then went in and rescanned each ESX host in the cluster for the ESX host to recognize the downed LUNs once more. After the scan, we viewed the properties of the LUN to ensure all paths were up. Once that was verified, we QA’d our VMs. Of 45 affected VMs, we had one casualty. The VMX file of one VM got corrupted.

The situation could have been worse, much worse. But I’m very glad that we stayed smart and calm and worked closely with our storage admins.