The document discusses emerging trends in storage architectures and technologies. By 2016, server-based storage solutions will lower hardware costs by 50% due to consolidation. Three of the top seven disk array vendors will exit the hardware business by 2018. New storage architectures are designed for web-scale, multi-tenancy, high access, and resilience needs. Open source software-defined storage solutions like Nutanix and Gluster address these needs through distributed, scalable designs. Emerging workload-based architectures require assessing specific requirements to determine the optimal solution.
7. Type 1: Clustered Architecture
‘Federated Model’ layered a top
‘scale-up’ architecture makes
them more ‘scale-out’ type from a
management standpoint.
Tends to ‘bounce the IO’ un6l it
gets to the brain (header) that has
the data. ’Federated’ models use
data mobility approach to
rebalance between brains &
persistence pools, leading to low
latency on writes
Brains (HA Header)
Persistent Pool
8. Type 2: Tightly Coupled, Scale-Out
Uses shared memory (cache and
metadata) between nodes, and the data
itself is distributed across some number
nodes. This architecture deals with large
amount of inter-node communica6on
The defining element of shared
memory models is cri6cal to
these designs. It enables
‘symmetric’ IO paths through all
brains. It is designed so that in
failure (planned or unplanned)
modes, IO opera6ons would
remain rela6vely balanced.
Brains (HA Header)
Persistent Pool
IO Path (Shared Memory)
9. Type 3: Loosely Coupled, Scale-Out
This model does not using shared
memory between nodes, but the
data itself is distributed across
mul6ple nodes. It deals with a
larger amount of inter-node
communica6on on writes (IO
intensive) as data is distributed.
As it is transac6onal the writes are
distributed & always coherent
The design –
• Simple in opera6ons and scaling.
• Very good distributed reads as data
is serviced by mul6ple nodes.
• Not ‘HA’. The resilience comes from
data copies & distribu6on.
Brains (mul@-node)
Distributed Pool
10. Type 4: Distributed, Share Nothing
The Design –
• No Shared Memory
• Non-transac6on, Lazy data
• Distributed reads can be achieved
• No ‘HA’. The resilience of specified
data can come from distribu6on.
The Architecture –
• The ‘Most Scalable’ Architecture
• Super-Simple implementa6on
• Highly COTS reliable, Low cost
• Mostly ‘SoMware Only’ design
• Object & non-POSIX support on
base filesystem
14. Single global namespace
Aggregates disk and memory resources into
a single trusted storage pool.
Security
Support SELinux enforcing mode with SSL-
based in-flight encryp@on
Object access to file storage
Filestore can be accessed using object-API.
Erasure coding
Enhance data protec@on by using
informa@on stored in the system to
reconstruct lost or corrupted data.
Bit-rot detecXon
Help preserve the integrity of data assets by
detec@ng silent corrup@on.
Tiering
Automa@cally move data between fast (SSD-
based) and slow (HDD) @ers based on access
frequency.
ReplicaXon
Supports synchronous replica@on within a
data center and asynchronous replica@on
for disaster recovery.
Snapshots
Assure data protec@on through cluster-wide
filesystem snapshots. User accessible for
easy recovery of files.
ElasXc hashing algorithm
No metadata server layer eliminates
performance boYlenecks and single points
of failure.
Feature Glance…
15. Industry Standard Client Support
• NFS, SMB protocols for file-based
access
• NFSv4 mul@-headed support for
enhanced security & resilience
• OpenStack Swi] support for Object
access
• GlusterFS na@ve client for highly
parallelized access
Deep Hadoop IntegraXon
• HDFS-compa@ble filesystem
• No single point of failure
• NFS and FUSE based data inges@on
IntegraXon with RHEV
• Centralized visibility and unified
management of storage and virtual
infrastructures through RHEV Manager
console.
• Live migra@on of virtual machines
Feature Glance…
Easy online management
• Web-based management console
• Powerful and intui@ve CLI for Linux
admins
• Monitoring (Nagios-based)
• Expand/shrink storage capacity without
down@me
16. Scale-out Write…
• The client ini6ate an IO and transmits it to
the node it's communica6ng with. For all-
in-one style architectures, this is a VM
node that's co-located with the client on
the same hardware
• Once the node receives the write
acknowledgement from the other node(s),
it responds back to the client
acknowledging the write.
• Depending on the array plaiorm, other
things can be done with the write like
inline deduplica6on, compression, etc.
• Some arrays that implement flash-based
write caching can stage the writes to flash
to clear the RAM for more incoming writes.
• The write is eventually flushed to disk (SSD
or Magne6c) on each node that received
the write
17. Scale-out Read…. • The client ini6ates an IO request and
t r a n s m i t s i t t o t h e n o d e i t s
communica6ng with. For all-in-one style
architectures, this is a VM node that's co-
located with the client on the same
hardware.
• The node receives that IO, checks its read
cache in RAM for the data and then
(depending on the array) checks SSD
cache for the data.
• If the data isn't in either loca6on, the
node checks its metadata table to locate
the data on disk (local or another node /
nodes). Data is read directly from the
underlying disks if local or is requested
from containing node across the inter-
node link.
• The node places a copy of the read in
cache and responds to the client with the
requested data.