I’m pleased to announce that 18.104.22.168 is now available to download
There are a few different platforms available under the Storwize branding, each have their own specific feature set. IBM have listed a nice comparison page which compares the functionality/hardware/options between the different platforms.
I often get asked “What is the recommended multipathing configuration with vSphere and SVC?” and “Are there recommended LUN sizes for VMFS datastores?”.
Luckily there is a white paper that covers a lot of Best Practices when using vSphere with SAN Volume Controller and/or Storwize products.
Similarly, for larger SAN design considerations there is a Redbook that covers a large number of settings specifically regarding vSphere.
The IBM SAN Volume Controller is a fantastic storage solution to virtualize storage arrays from different vendors, offer performance improvements, replication, compression, encryption and a huge interoperability support matrix.
However, one of the annoyances of IBM SAN Volume Controller architecture is if a single node has a hardware error, or requires maintenance you’re limited to a single node in the IO group.
This issue has now been alleviated by introducing the option of a hot-swap node for when a node is offline for an extended period.
A IBM Redbook has been published here which describes the process.
This function is to be extended in future releases of SVC code to allow an automated hot-swap node during a code upgrade. Historically in a 2-node SVC cluster, you’d be left with a single node in the IO group would would be vulnerable to a single point of failure for prolonged periods of time. With this hot-swap node feature, the spare node would be upgraded first, before replacing a down-level node as it goes offline for upgrade. This should significantly improve reliability of the SVC cluster during the upgrade process.