Server SANs: Don't throw the baby out with the bathwater

Killing shared array complexity


Getting rid of SAN complexity and cost is an idea that appeals to many CIOs sick of juggling storage area networking components and array costs.

Let app servers virtualise a SAN into existence by pooling their own direct-attached storage and just buy servers with server SAN software, such as StoreVirtual from HP, DataCore's SAN Symphony or VMware’s VSAN and its EVO:RAIL converged server/storage architecture offering,

EVO:RAIL architecture is being used by a number if vendors, including EMC and HP, to offer so-called hyperconverged offerings which can be replicated simply in a scale-out scenario.

The Wikibon consultancy reckons: "[With server SANs] DAS pools will begin to replicate SAN and NAS functionality at much lower cost and provide compelling economic advantages to enterprise customers. In many important application segments (for example high-performance databases), Server SAN will offer superior performance, functionality and availability over traditional SAN and NAS."

Server SANs are also part of hyperconverged (server plus storage plus networking) appliances from a range of suppliers. They include HP with its ConvergedSystem 200-HC StoreVirtual appliances, and startups such as Nutanix, Maxta and others.

There can be up to 32 x 200-Cs in a cluster with a theoretical total of 230TB of raw disk capacity and 25.6PB of raw flash capacity. This is more than the 3.2PB capacity maximum of HP's StoreServ 10800 array.

But there may be a danger of throwing the baby out with the bathwater if you replace physical SANs with virtual ones. Problem areas include data locality, protection and feeding a server SAN with data.

Where is the data?

A SAN is a disk array with several shelves of storage media hooked up to one or two controllers. A server SAN is a disk array with several shelves of storage media each hooked to an app-running server controller connected to the others by a network link such as 10GbitE.

A consequence is that app data accesses can be faster (local to the server in question) or slower – involving a network hop to a separate server. Arguably such an access is equivalent to a physical SAN access.

In effect a server SAN exhibits NUSA (cf NUMA for non-uniform memory access) – non-uniform storage access, with off-node accesses taking longer than on-node accesses.

Won't this delay data access by adding network latency? Yes it will, and, as ever, caching can help mitigate the effects.

Some people think that data locality algorithms will smartly migrate data to the app node accessing the data. They point out that physical SANs can't do this and you always suffer from network latency, even if the physical SAN is a flash-enabled or all-flash device.

Where server SAN nodes are all-flash then their capacity is limited, due to raw flash costs, unless they deduplicate data. This is a CPU-intensive activity and may well prevent the full server SAN CPU resources being applied to business applications.

Missing elements

Server SANs, especially VMware’s VSANs, are often viewed as not really enterprise-class and immature. Physical SAN vendors will clearly see VSAN disadvantages in the data protection area. For example, they may say VSAN and EVO:RAIL lock you in to VMware, and they don’t have:

  • Lost write protection
  • Drive firmware control
  • Deduplication
  • An alternative to wasteful 3-node mirroring
  • An answer to the issue of losing a VSAN disk group from a failed SSD

Also, virtual machine backup is slow when all reads come from only one or two drives. A shared array can have reads from multiple drives at once and better protection from drive failure.

The thinking here is that VSAN is fine and dandy, but business line apps need to read and write data fast and in a simple environment; when you want this a VSAN can seem like a SAN-lite product. It makes sense then to complement it with a physical SAN.

NetApp has announced its Integrated EVO:RAIL Solution, which integrates its FAS arrays with EVO:RAIL server nodes to solve this set of problems. Other array vendors are bound to offer the same functionality.

Feed the SANs

One point of view is that server SANs will kill physical SANs. An opposing one is that they are just the latest iteration of the trend towards moving data into faster stores closer to servers so a shared, physically separate bulk storage facility will still be needed.

Have the primary working set data in the server SAN but have it fed to the server nodes from a bulk capacity shared disk store.

For example, quarterly accounting app runs use data that is not needed so intensively at other times. It can be kept in a single place – a shared drive array – and then fed to a server SAN when needed. Once the quarterly run ends the data can be written back to the physical SAN and the server SAN space can be reclaimed for other data.

Tiering software could be used to move data automatically from a physical SAN to a server SAN. It can already move data from a SAN to individual servers' flash caches.

HP’s Adaptive Optimisation software is one such technology that could be developed to provide this functionality. EMC's FAST (fully automated tiering software) is another.

Disaster recovery

The shared array could provide local disaster recovery facilities for the server SAN as well as replicate data off-site, perhaps to the public cloud, for remote disaster recovery.

It could pump out older data to archive stores and thus keep the server SAN nodes focused on immediate business application needs, while the mature physical SAN takes care of more infrastructure-focused background tasks which would otherwise take up server SAN CPU cycles.

It seems clear that simply throwing out storage arrays and replacing them willy-nilly with server SANs may not be the best way to move your IT infrastructure forward when you have requirements that are best met by physical SANs.

This is more likely to be the case if you are considering storage needs in an enterprise data centre rather than small or remote offices or small businesses. If you can have all your needs met by a server SAN, then great. You will avoid a deal of complexity and expense.

If you can’t, then don’t throw the SAN baby out with the bathwater when you rip-and-replace your physical SAN with a server SAN. That way lies pain and grief. ®

Similar topics

Narrower topics


Other stories you might like

  • 381,000-plus Kubernetes API servers 'exposed to internet'
    Firewall isn't a made-up word from the Hackers movie, people

    A large number of servers running the Kubernetes API have been left exposed to the internet, which is not great: they're potentially vulnerable to abuse.

    Nonprofit security organization The Shadowserver Foundation recently scanned 454,729 systems hosting the popular open-source platform for managing and orchestrating containers, finding that more than 381,645 – or about 84 percent – are accessible via the internet to varying degrees thus providing a cracked door into a corporate network.

    "While this does not mean that these instances are fully open or vulnerable to an attack, it is likely that this level of access was not intended and these instances are an unnecessarily exposed attack surface," Shadowserver's team stressed in a write-up. "They also allow for information leakage on version and build."

    Continue reading
  • A peek into Gigabyte's GPU Arm for AI, HPC shops
    High-performance platform choices are going beyond the ubiquitous x86 standard

    Arm-based servers continue to gain momentum with Gigabyte Technology introducing a system based on Ampere's Altra processors paired with Nvidia A100 GPUs, aimed at demanding workloads such as AI training and high-performance compute (HPC) applications.

    The G492-PD0 runs either an Ampere Altra or Altra Max processor, the latter delivering 128 64-bit cores that are compatible with the Armv8.2 architecture.

    It supports 16 DDR4 DIMM slots, which would be enough space for up to 4TB of memory if all slots were filled with 256GB memory modules. The chassis also has space for no fewer than eight Nvidia A100 GPUs, which would make for a costly but very powerful system for those workloads that benefit from GPU acceleration.

    Continue reading
  • GitLab version 15 goes big on visibility and observability
    GitOps fans can take a spin on the free tier for pull-based deployment

    One-stop DevOps shop GitLab has announced version 15 of its platform, hot on the heels of pull-based GitOps turning up on the platform's free tier.

    Version 15.0 marks the arrival of GitLab's next major iteration and attention this time around has turned to visibility and observability – hardly surprising considering the acquisition of OpsTrace as 2021 drew to a close, as well as workflow automation, security and compliance.

    GitLab puts out monthly releases –  hitting 15.1 on June 22 –  and we spoke to the company's senior director of Product, Kenny Johnston, at the recent Kubecon EU event, about what will be added to version 15 as time goes by. During a chat with the company's senior director of Product, Kenny Johnston, at the recent Kubecon EU event, The Register was told that this was more where dollars were being invested into the product.

    Continue reading

Biting the hand that feeds IT © 1998–2022