Datacore

DataCore describes in their Host Configuration Guide for VMware ESXi some settings that must be adjusted before storage from DataCore SANsymphony-V storage servers will be assigned to the ESXi hosts. Today, for ESXi 5.x and 6.0, you have to add a custom rule and adjust the advanced setting DiskMaxIOSize. For ESX(i) 4 more parameters had to be adjusted. But I will focus on  ESXi 5.x and 6.0. You need to adjust these settings for each host that should get storage mapped from a DataCore storage server. If you have more then one host, you may have the wish to automate the necessary steps. The check the current value of DiskMaxIOSize, you can use this lines of PowerCLI code.

When you install DataCore SANsymphony-V (SSV), you will be asked during the setup to allow the installation of some special drivers. DataCore SANSymphony-V needs this drivers to act as a storage target for hosts and other storage servers. Usually you have three different port roles in a DataCore SSV setup:

• Frontend Ports (FE)
• Mirror Ports (MR)
• Backend Ports (BE)

Frontend (FE) ports act only in target-only mode. These ports will be disabled, if you stop a DataCore storage server. Mirror (MR) ports (can) act as target AND initiator. You can set (if you like) a mirror port to a specific mode (target or initiator), but I wouldn’t recomment this. Theoretically you can set one MR port to act as initiator, and a second to target-only mode. If the port is set to target-only, the port is also stopped when the DataCore storage server is stopped. A backend (BE) port acts as initiator for backend storage. Usually the FE ports act as target-only, the MR as target/ initiator and the BE ports as initiator-only. If you use local storage (or SAS connected), there will be no BE ports.

One of my longtime DataCore customers has started a project to replace their current DataCore storage servers and backend storage with new hardware. In opposite of the current setup, the newly installed backend storage is now FC-attached. The customer has selected Nexsan E-Series E32V, E32XV and E48V storage systems in combination with DataCore SANsymphony-V10.

Who is Nexsan?

The question should be: Who is Imation? Nexsan was founded in 1999 in Derby, England, but was aquired by Imation in December 2012. Since December 2012, Nexsan is one of Imations brands and offers, as a storage-only company, three different product lines: Assureon Secure Storage, E-Series High Density Storage and NST Hybrid Storage.

Last sunday a customer suffered a power outage for a few hours. Unfortunately the DataCore Storage Server in the affected datacenter weren’t shutdown and therefore it crashed. After the power was back, the Storage Server was started and the recoveries for the mirrored virtual disks started. Hours later, three mirrored virtual disks were still running full recoveries and the recovery for each of them failed repeatedly.

Some days ago I talked to a colleague from our sales team and we discussed different solutions for a customer. I will spare you the details, but we discussed different solutions and we came across PernixData FVP, HP 3PAR Adaptive Optimization, HP 3PAR Adaptive Flash Cache and DataCore SANsymphony-V. And then the question of all questions came up: “What is the difference?”.

Simplify, then add Lightness

Lets talk about tiering. To make it simple: Tiering moves a block from one tier to another, depending on how often a block is accessed in a specific time. A tier is a class of storage with specific characteristics, for example ultra-fast flash, enterprise-grade SAS drives or even nearline drives. Characteristics can be the drive type, the used RAID level or a combination of characteristics. A 3-tier storage design can consist of only one drive type, but they can be organized in different RAID levels. Tier 1 can be RAID 1 and tier 3 can be RAID 6, but all tiers use enterprise-grade 15k SAS drives. But you can also mix drive types and RAID levels, for example tier 1 with flash, tier 2 with 15k SAS in a RAID 5 and tier 3 with SAS-NL and RAID 6. Each time a block is accessed, the block “heats up”. If it’s hot enough, it is moved one tier up. If it’s less often accessed, the block “cools down” and at a specific point, the block is moved a tier down. If a tier is full, colder blocks will to be moved down and hotter block have to be moved up. It’s a bit simplified, but products like DataCore SANsymphony-V with Auto-Tiering or HP 3PAR Adaptive Optimization are working this way.

Sometimes you have to update the OS of your DataCore Storage Server, or the server is crashed and you have to reinstall it. In both cases, a configuration backup is the starting point. The procedure remains the same, regardless if it’s an update or a reinstall after a server crash:

• Install Windows Server OS
• Copy configuration backup file to C:\Program Files\DataCore\SANsymphony\Recovery
• Install DataCore SANsymphony-V

Take a backup

You can take the configuration backup on different ways:

This is only a short blog post. Just got an e-mail from the DataCore Support. They found a critical bug in SANsymphony-V 10.0.0.0 which should be fixed with Update 1. Only VMware customers are affected, because the bug is related to VMware Thin Provisioning Thresholds. Update 1 is planned for early September 2014. If you’re running SANsymphony-V 10.0.0.0 open an incident at the DataCore Support to get an available hotfix. If you have planned to update to SANsymphony-V 10, delay this update until the release of SANsymphony-V 10 Update 1.

Today DataCore announced their latest SANsymphony-V release. After the merge of SANmelody & SANsymphony, SANsymphony-V10 is the 10th generation of DataCores flagship product. Interestingly DataCore uses the terms  “software-defined” and “Virtual SAN”. Whether the product of the definition of the terms corresponds everyone should decide for themselves. But this is another story.

What is DataCore SANsymphony-V?

What DataCore definitely does is automating and simplifying storage management and provisioning. I really like it the simplicity. DataCore SANsymphony-V can deliver enterprise-class functionality, like synchronous mirroring, replication, snapshots, clones, thin-provisioning and tiering . It runs on x86 hardware with Microsoft Windows Server 2008 or 2012. Multiple servers can grouped together for load balancing and redundancy. A storage pool can created out of the internal or external flash and roting rust. Single or mirrored virtual disks can be carved out of this storage pool. Hosts can access these virtual disks using iSCSI or Fibre-Channel. Because DataCore SANsymphony-V10 can use several different technologies as backend for storage pools, it’s easy to replace backend storage. You can add or remove disks to or from storage pools. If you backend storage is an old EMC CLARiiON and you get a new HP MSA 2040 Storage, you can replance the old storage without disruption.

About two weeks after the release of DataCore SANsymphony-V 9.0 PSP4 Update 2, DataCore announces Update 3. This is a really short release cycle… DataCore fixed three issues in Update 3. This is an excerpt from the release notes:

Problem: SANsymphony 9.0 PSP4 Update2 failed to update configurations with shared pools on DataCore Servers running SANsymphony 9.0 PSP3, PSP3 U1 or PSP3 U2. Cause: An upgrade script run during installation expected a cmdlet parameter that wasn‟t supported in these versions. Resolution: Updated the script to no longer rely on this parameter.

Yesterday I got an e-mail from DataCore in which Update 2 for DataCore SANsymphony-V PSP4 was announced. DataCore found a critical issue in all releases since SANsymphony-V 9.0 PSP3. According to the releases notes a situation can occur, in which storage space reclamation and migration can happen at the same time. This can lead to a situation in which two storage allocation unit (SAU) can point to the same disk offset. If this happens, the disk pool can be marked offline.