Understanding Global Namespace Acceleration (GNA)

With the proliferation of solid state drives (SSDs) in data centers across the world, companies are finding more and more ways to take advantage of the high speed and low latency of SSDs in unique and exciting ways. Within the EMC® Isilon® OneFS® operating system, one of the innovative ways Isilon is using SSDs is for Global Namespace Acceleration (GNA). GNA is a feature of OneFS that increases performance across your entire cluster by using SSDs to store file metadata for read-only purposes, even in node pools that don’t contain dedicated SSDs.

GNA is managed through the SmartPools™ software module of the OneFS web administration interface. SmartPools enables storage tiering and the ability to aggregate different type of drives (such as SSDs and HDDs) into node pools. When GNA is enabled, all SSDs in the cluster are used to accelerate metadata reads across the entire cluster. Isilon recommends one SSD per node as a best practice, with two SSDs per node being preferred. However, customers with a mix of drive types can benefit from the metadata read acceleration with GNA regardless of how SSDs are placed across the cluster. When possible, GNA stores metadata in the same node pool containing the associated data. If there are no dedicated SSDs in the node pool, however, a random selection is made to any node pool containing SSDs. This means as long as SSDs are available somewhere in the cluster, a node pool can benefit from GNA.

For more information about GNA, see the “Storage Pools” section of the OneFS web administration and CLI administration guides.

Important considerations when using GNA

Here are some important considerations to keep in mind when determining whether GNA can benefit your workflow.

  • Use GNA for cold data workflows. Certain workflows benefit more from the performance gains that GNA provides. For example, workflows that require heavy indexing of “cold data”—which is archive data on stored on disks that is left unmodified for extended periods of time—benefit the most from the increased speed of metadata read acceleration. GNA does not provide any additional benefit to customers who already have solely SSD clusters, because all metadata is already stored on SSDs.
  • SSDs must account for a minimum of 1.5% of the total space on your cluster. To use GNA, 20% of the nodes in your cluster must contain SSDs, and SSDs must account for a minimum of 1.5% of the total space on your cluster, with 2% being strongly recommended. This ensures that GNA does not overwhelm the SSDs on your cluster. Failure to maintain these requirements will result in GNA being disabled and metadata read acceleration being lost. To enable GNA again, metadata copies will have to be rebuilt, which can take time.
  • Consider how new nodes affect the total cluster space. Adding new nodes to your cluster affects the percentage of nodes with SSDs and total available space on SSDs. Keep this in mind whenever you add new nodes to avoid GNA being disabled and the metadata copy being immediately deleted. SSDs must account for a minimum of 1.5% of total space on your cluster.
  • Do not remove the extra metadata mirror. When GNA is enabled, an SSD is set aside as an additional metadata mirror, in addition to the existing mirrors set by your requested protection, which is determined in SmartPools settings. A common misunderstanding is that the SSD is an “extra” mirror and it can be safely removed without affecting your cluster. In reality, this extra metadata mirror is critical to the functionality of GNA, and removing it causes OneFS to rebuild the mirror on another drive. See the graphic below for information on the number of metadata mirrors per requested protection when using GNA. For more information about requested protection, see the “Storage Pools” section of the OneFS Web Administration Guide.
The number of metadata mirrors required by GNA per requested protection level in OneFS.
The number of metadata copies required by GNA to achieve read acceleration per requested protection level in OneFS.

[display_rating_result]

About the Author: Colin Torretta