Dell PowerEdge r620 TrueNAS Build: part 1

I have eight Samsung Evo 940 SSD 1tb drives that needed a deserving home; so I decided to build  another TrueNAS to server as a VMware shared storage appliance.  A Dell PowerEdge r620 server was picked out a to use, as it had eight 2.5" drive bays.  The dual CPU's e5-2650's should be way more horse power needed to be an ISCSI/NFS target.  Eventually they will be upgraded to v2 CPU's as they are stupid cheap on eBay and it is roughly 30% more performance with no extra electricity. 

An Intel 64gb SSD was brought out of retirement, installed into a slim-CDROM to 2.5" HDD adapter. This would be where the OS will be installed.  However first, I installed Windows Server to it just to test out the hardware and then update the firmware.  

First issue I ran into is that even though this server has eight 2.5" drive bays, the backplane only had four drive connectors!  I have seen other r620's with only four drive bays, but the other side was a metal face, this one had drive sled in it!  Interesting!   As luck would have it I found another r620, that had a backplane that did have all 8 drive connectors but was only two hard drives, so the back plane got swapped.  

This server has a Perc H710 mini monolithic RAID card with 512mb of battery backed cache.  TrueNAS works much better using an actual hard drive controller, not a RAID card where the OS officiates the disk info.  It appears that the r710 does not support non-RAID-ed disks.  I attempted to pull out the RAID card, to see if the machine would see the drives; it would not.  On a previous build (a Dell r320) I removed the RAID card moved the cable to to a different mini-SAS-8087 36 pin connector, thus the system ran the drives off of the onboard SATA controller.  This Perc H710 uses a SAS-8654 cable?  I didn't have a one into two SAS sas-8087 to go from the single onboard connector to the two back plane connectors.

Well, time to gamble a bit and attempt to flash the Perc into "IT-mode"...basically re-writing the firmware to make it think it is a some sort of LSI 2208 series SAS HBA controller.  The H710 does have a faster processor than H310, and with spinning disk one probably would not max out the controller; with SSD's getting to that ceiling is a real possibility.  It turns out there is not one but two different versions of the H710, one is PCI-e 2.0 vs 3.0 "capable".   If one searches the web for great resource: "Art of the Server", he has lots of great information on these.

Following the steps here on Jon Fohdeesha's site the BIOS changes were made.  The RAID battery removed, the drives removed, the ROM on the Perc was erased, via the FreeDOS utility, although I did erase it three times as it would error out on the 2nd step. The new firmware was then written, the SAS identifier reprogramed.  All was successful!  During post, one now sees the LSI/Avago BIOS and menu screen.  Also interesting is that the Dell "System setup" also see the HBA.

TrueNAS & NFS (sync vs async vs sync w/ zLOG)

 

Another TrueNAS (core v13.0) build!  This one is mostly just a backup repository....or as I call them: "here, hold this, server".  This is a SuperMicro SM SGG-6029p-e1cr24l....which is a pretty crazy server that in a 2U configuration holds twenty-four 3.5" hard drives!  Plus rear mounted two 2.5" hard drives.  This one has dual Xeon 3104 CPU's at 1.7ghz, 64gb DDR4 ECC ram, a 64 SATA DOM, two Intel 480gb SSD's and soon to be 24 (currently only 22 are in service, the other two are out for warranty) Seagate 8tb 7200rpm SATA drives, driven by a SAS 9305-16i-IT controller.  Network connections are the onboard 1gbps NIC which is shared for IMPI and Network (which is giving me grief, but won't go into that now) and a dual port 10gb NIC.

TrueNAS was installed onto the 64gb SSD DOM (Disk On Motherboard); yes certain people will get all bent out of shape about this.  Yes the DOM has a limited lifespan, it could die as the endurance isn't as high as a normal SSD.  We also don't have mirrored drives for the boot OS.  Well, you know what?  I don't care!  TrueNAS doesn't really write that much to the boot volume, especially if since most of the OS is copied to RAM.  If the drive fails, just reinstall TrueNAS, import the config file.  Plus this is just an additional backup target, if it goes down for a day or so, no big deal.

The data volume was created with five groups of four drives in a ZFS RAIDz2.  So basically a twenty drive RAID 10.  NFS v3 was setup, and presented to a VMware host.  A Windows 10 VM was migrated to it and the ATTO Disk Benchmark was ran. 

This first the first test, but notice the frankly unacceptable write speed?  NFS has what is commonly referred to as "synchronous writes" turned on by default.  In short, the each disk write must be confirmed to be written to disk before continuing.  This options can be turned off, however there is a risk.  In the event of power loss or other disaster the data in cache might not be written, and therefore lost.

sync or async options can be set at the dataset level.

Same test with sync turned off; much better.

For this test sync was turned back on and NVMe drive was added and configured to be zLOG vDev.  Essentially a write cache buffer.  ZFS/TrueNAS will flush the log device every 5 seconds, and with a 10Gbps NIC, doing back of the napkin math that means the system will only use about 6gb of space......yes only 6gb, so the 512gb NVMe is largely being unused.  TrueNAS requires an entire disk to be allocated.  So this would be a great use case for NVMe name spaces.  

There is NO benefit of running a zLOG on a pool that has Sync turned off.

SuperMicro BigTwin SSG-2029-DN2R24L...and VMware ESXi Part#2

 Decided to do a little bit of network benchmarking. 

Both nodes have a VM setup on them, both VMs live on NVMe.

First test is both VMs talking to each other over the built in 10gb NICs.  In the part #1 it was mentioned that this server has network backplane for the two nodes to communicate, using Intel 10gb NIC hardware.

Second test is both VMs talking to each other using a virtual switch that has a 100mb NIC.

Third test is both VMs talking to each other using a virtual switch has a 10mb NIC.

Fourth test: just add some perspective.  This is two VM's each running on HP ML350's G8's connected via 10gb NICs on a really old Broadcomm switch.

SuperMicro BigTwin SSG-2029-DN2R24L...and VMware ESXi Part#1

This 2U server holds two compute nodes and has a shared backplane to 24 U.2 dual path NVMe drives.

Each compute node has a X11DSN-ts motherboard, containing a M.2 slot, twelve DDR4 memory slots, dual LGA-3647 sockets (this one has Xeon Gold 6140 CPU's).  For networking they have two Intel 1gb/10gb RJ45 NICs plus two more Intel 10gb NICs that are strictly node-to-node communication.

This system poses some questions.  How will VMware react to have having two hosts accessing the very same hard drives?  Is VM failover possible with out vCenter?  What will vCenter think about the shared datastore?  How will storage vMotion work?  And what about those internal NICs?   

ESXi 7 was installed onto the onboard M.2 NVMe drive.  Virtual switches were setup, one for the added in PCI-e 100gb NICs, one for the two onboard 1/10gb NICs, and a third for the two internal NICs (the ones for node-to-node communication).  A single VM was created on each host, and connected to the internal switch.  It was confirmed that a VM on host-A could communicate to a VM on host-B.

A datastore was created using one of the U.2 NVMe drives on host-A.  Host-B didn't pick up this datastore until after a reboot.  I am sure there is someway of refreshing how ESXi scans for new/existing datastores that are local.  Additional disks to the datastore were added as an extent on host A.  Host B automatically picked up the size increase, without having to reboot.

A VM on host-A was stood up; host-B could not register that VM until it was shutdown. After registering the VM on host B, host A did not seem to care or know anything was different, other than it still showed the VM as powered off.  Rebooting host A shows those VMs as invalid.  VMware file locking is taking affect in the background.  After shutting down the VM, waiting a few minutes, refreshing the screen, that VM could not be powered on; on host-A.  It appears the only way to bring the VM back to the original host is to unregister the VM and register it.

HP Smart Array p420 RAID card notes

 A couple of quick notes...

The controller WILL support larger than 4tb drives.  I have used both Seagate ST6000nm0034 6tb drives and Seagate Exos 12tb SAS drives.

The ROM utility will misreport the drives, but do not worry.

ILO however will see the drive correctly.

HP Storage Administrator also reports the drives correctly.

If for some reason one needs to re-order the drives; the RAID card will figure it out.  The RAID card will notify one that on boot that the drive order was changed and has been corrected.  In my case I was originally running 3.5" drives bolted into the case, and not in the drive cage.  Through a bunch of trades/migration I was able to acquire a drive cage.  Somehow despite taking notes of the drive position on the SAS break out cable and matching that to the drive cage, it still wasn't correct. 

 

Dealing with large drives can be a PAIN!  This is in now way unique to HP, but when one modifies the RAID structure, or has a drive failure; doing all the recalculation takes forever.  In my case, migrating a RAID1 (mirror) of two12tb 7200rpm SAS drives to a three drive RAID5, took over 24hours, and that was just the 1st step.  That is correct, there is two steps, one must first recalculate the array, then another recalculation for Logical drive, which also takes forever and a day.   So this is another reason why it might be better to buy more drives of a smaller size vs. fewer and larger drives.  Also keep in mind the type of RAID one is using, RAID-5 will take more processing than RAID-10 and RAID-1.  RAID 6 is also deserves a good look at, where available. 

NVMe namespace notes:

 Just a bunch of notes for my future self, as I am sure I will forget, and for anyone else who may benefit. 

What is a namespace?  Think of it just like a partition on a normal hard drive.  Except the partitioning of the drive is done at the hard drive level not at the operating system level.  Thus the operating system sees the name spaces as unique hard drives.  IE if one had a 1tb NVMe, and setup four 256gb name spaces, Windows would think there was four 256gb NVMe drives in the system.  

FROM LINUX (PartedMagic was used):

nvme list <--show what nvme name spaces are present and the model of the drive

nvme id-ctrl /dev/nvme0 | grep mcap <--shows" tnvmcap (total NVM capacity) and unvmcap (unallocated NVM capacity) attributes.

nvme id-ctrl /dev/nvme0 | grep cntlid <--show the controller(s) ID's

 

DELETE NAMENSPACES

nvme detach-ns /dev/nvme0 –n 1 –c 0 <-- detaches the namespace "1" from the controller "0" 

    sometimes using the flag --controllers=0 is necessary

nvme delete-ns /dev/nvme0 -n 1 <--deletes the namespace "1" from the controller "0"

nvme ns-rescan /dev/nvme0 <--rescans the drive "0"

 

CREATE NAMESPACES

nvme create-ns /dev/nvme0 -s 26214387 -c 26214387 -b 4096  <--creates a 100gb name space, formatted to 4k

nvme ns-rescan /dev/nvme0 <--rescan
 

nvme attach-ns /dev/nvme0 -n 1 -c 0x1  <--attach the namespace to the controller
 

nvme ns-rescan /dev/nvme0  <--rescan

Ignore this stuff....just notes to me...

nvme detach-ns /dev/nvme0 -n 1 -c 6

    detaches namespace 1 from nvme0 from controller 6

nvme delete-ns -n 1 /dev/nvme0

    deletes namespace1 from nvme0

nvme create-ns /dev/nvme0 -s 15,000,000,000 -b 512

    creates a namespace of 7.86tb w/ 512 sector size

nvme attach-ns /dev/nvme0 -n 1 -c 6

    attaches namespace 1 to controller 6 on nvme0

size:

size in mb...IE 7.68tb =7,680,000,000,000

take that number dived by 4096 or 512, if there is a remainder, subtract the remainder from the original size, and divide again.

7,680,000,000,000/512=15,000,000,000

NVMe U.2 drives in machines with out U.2 backplanes

 I just discovered these and figured it worth the share.

NVMe drives that are in 2.5" hard drive form factor (versus the more familiar M.2 "gum stick" variety), look just like a normal SAS hard drive.  However the pinout is slightly different, and one needs to have different backplane and connections to the PCIe bus than SAS.  IE one can not take a server physically configured for SAS/SATA drives and utilize these U.2 drives. 

This is where this adapter comes in.  Mount the drive to the PCIe card, plug the card into the computer, and one can now utilize that hard drive.  Another feature of this specific card is one could use a normal 2.5" SATA hard drive on this card as well.  One just needs to feed a SATA cable to the card.  Both are very handy options to for instance adding a single 2.5" drive to a machine that is doesn't have any extra drive bays, or the bays are configured for 3.5".

Cable Length is relative....

 Turns out when one order 0.5m cable it might not actually be a half meter.  In this case two cables one from Mellanox the other from FS.com.  Obviously someone isn't right here.  Apparently one vendor includes the length of the transceiver in their overall length vs just the cable.   Anyways, buyer beware as it can make a difference. 

Those couple of inches make a difference, especially when doing 16 cables; in this case I resorted to 1M cables.....or should I say "1M"? :)

Amphenol 1M cables are just over 39" tip to tip.

This FS 1M cable is 40" long, just the cable, add another 6" or so for the transceivers.  

vCenter Backup/Restore and "Upstream Server not found"

I learned somethings on Virtual Center 7.x this weekend.  Here are a few key take aways that hopefully helps someone else out there:

Restoring Virtual Center using Veeam

If one needs to restore a vCenter using Veeam; and assuming that Veeam was setup where the vCenter was added to Veeam, like most environments, versus having each ESXi host added to Veeam.  Veeam cannot restore vCenter the same way one would normally do a VM restore.  Since during the restore process Veeam NEEDS to communicate with the now non-existent vCenter.  The restore cannot happen and the process will waste great amounts of time.  

The work around is to first add a single ESXi host to Veeam, add that host using the IP (assuming it the friendly name is known by Veeam; the point is we are tricking Veeam this is a new ESXi server.  Then restore the vCenter backup to an alternate location...aka this "new" server.  One isn't really restoring the VM to an alternate location, one can totally restore over the top of the existing VM, this is just a necessary step to get past the requirment of having to circumvent communicating with a vCenter that is currently not functioning. 

Restoring Virtual Center using built-in restore options.

For those you who are using vCenter's built in backup feature, the restore process works as follows.   Start the vCenter installation process, choose "Restore", give it the backup repository details, and follow the rest of the prompts.  What happens is a new vCenter VM is deployed and the backup information is replayed into it.  HOWEVER, the backup files and the install media need to be on the very same version.  For me, I attempted to use vCenter 7.0.3-209 installaton media, and my broken vCenter started out life as a v7.0.1x , then upgraded several times and currently on 7.0.3.01000.  It would not restore and complained about a versioning mismatch. I did not bother trying to acquire previous versions of vCenter to attempt the recovery.  Apparently, one should keep the install media around, and when patching vCenter, also acquire the full ISO to install from. 

VCenter Error when logging in:  "No Healthy Upstream Server"

For some unknown reason my vCenter quit working and I was presented with the no healthy upstream server message when attempting to log in.  The error message is very vague and somewhat of a "catch all".  Hence,  there is no one golden fix out there, but a dozen different fixes.  Many people give up and just re-deploy from scratch. 

I could log into the appliance administration page, where I attempt to start the non-running services with no luck, restarting the appliance didn't work.  

My server the "VMware vCenter Server" (VMware-vpxd service) would not start, it would process for a good two minutes before failing.

A few usefull commands to type in at the shell:

service-control --list <--list all of the running services

#service-control --start --all <--start all services #service-control –-start {service-name} <--start a specific service

DNS both forward and backwards worked, resolution with the FQDN and short name worked. Disk space was not an issue, as mentioned by dozens of others. I did attempt to change my IP settings as recommended but some sort of GUI bug prevented me of doing that.  Changing the IP via console did not help.  NTP did not seem to be an issue.  

An attempt to upgrade vCenter, thinking the upgrade would replace/repair any broken bits, was tried.  This made things way worse, and the upgrade failed; so I had to roll back.

I downloaded and ran python script from a VMware KB to check my SSL certificates, and they passed.   

The logs to vmware-vpxd are found here: /storage/log/vmware/vpxd-svcs/vpxd-svcs.log

After several hours of beating on it, I found several other pages talking about certs. and a different way to check for cert. valitity.  This check showed mine as being failed.  Turns out the .py script I ran previously, actually lead me astray, I did indeed have expired certs.

for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo STORE $i; sudo /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done

 Running the Cert. Tool contained within vCenter to reset all the Certs fixed my issue.  FYI it does take quite a while to run.

/usr/lib/vmware-vmca/bin/certificate-manager <---to launch the cert. utility; #8 to reset the cert

Post Recovery

After all is said and done, Veeam will be broken.  When a backup job is attempted to be ran it will fail.   Since the SSL certs have changed, as far as Veeam is concerned vCenter is not the same machine.  To fix it go into Veeam:

-Backup Infrastructure->click the vCenter, choose properties->Next->accept the dialog box to update the Certificate->Finish

VMware & NVMe drives

The VMware HCL (Hardware Compatibility List) has always been a problem for those of us on a tight IT budget; no matter if it is for a business or home-lab.  Turns out the selective approval of the HCL also applies to NVMe drives.  I have been a fan of using PCIe to NVMe adapters and a NVMe gum-stick drive in older hardware for higher IOPs loads, caching tier such as vSAN, or even just for swap space.  See some of my previous posts on this subject.

My last home-lab upgrade, I had allocated a specific NVMe drive to use because of the price and speed.   I couldn't get that drive to work.  I assumed it was because it was a Generation 4 drive and was just too new to use on my older HP G8.  An older enterprise drive was purchased second hand, that I knew from previous expirence would work   

Months later, almost the exact same issue cropped up on a Dell PowerEdge r730.  This time after some Google-Fu and reading William Lam's blog post it turns out the that the drive I was attempting to use simply wasn't in the HCL list, and therefore ESX was not going to accept it.

ESXi would see the memory controller, but not address the drive:

Running this command one would not see the device:

"esxcli storage core path list"

Also running this command, one would not see the device:

"esxcfg-scsidevs -l"

Running this command one could see the memory controller:

"esxcli hardware pci list"

In my case it saw the HP EX950 as:

   VMkernel Name: vmhba5

  Vendor Name: Silicon Motion, Inc.

   Device Name: SM2262/SM2262EN SSD Controller
   Configured Owner: VMkernel
   Current Owner: VMkernel
   Vendor ID: 0x126f
   Device ID: 0x2262
   SubVendor ID: 0x126f
   SubDevice ID: 0x2262
   Device Class: 0x0108
   Device Class Name: Non-Volatile memory controller

In the end the HP 950 NVMe drive was pulled out and a Kioxia KXG60ZNV256G which has a Toshiba brand controller was installed.  Things worked as expected.  

The forums did talk about replacing a driver with an older ond from ESXi v6.7.0, but I decided to avoid all that for fear of loosing access to the drive after various updates.

ALSO!  It turns out ESXi does not like drives that are formatted to 4k!  I had a drive that ESXi would see, but could not provision as storage.  Deleting the name space and recreating it formatted to 512b and it worked just fine.