Re-Think Storage – PernixData. Meet & greet with Frank Denneman
•Als PPTX, PDF herunterladen•
0 gefällt mir•913 views
Die Verwendung von Storage-Arrays wird allgemein als natürliches Design einer Virtualisierung angesehen. Die Verwendung dieser Storage-Arrays fürhrt allerdings oft zu Problemen mit der Speicherleistung. Flash-Speicher wird als Retter für die Speicherengpässe angesehen. Stellt sich nur noch die Frage, wo denn Flash am sinnvollsten eingesetz werden sollte? Frank Denneman, Tech Evangelist und Author, sprach am VMware Storage Event vom 30. April 2015 über den Einsatz von Flash-Speicher. Ebenfalls stellte er in seiner Präsentation PernixData FVP™, mit der die Storage-Performance um ein vielfaches erhöht werden kann.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Re-Think Storage – PernixData. Meet & greet with Frank Denneman
Ähnlich wie Re-Think Storage – PernixData. Meet & greet with Frank Denneman (20)
Mehr von Digicomp Academy AG
Mehr von Digicomp Academy AG (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Re-Think Storage – PernixData. Meet & greet with Frank Denneman
- 1. © PernixData. All rights reserved. © PernixData. All rights reserved. Re-Thinking Storage by Virtualizing Flash and RAM Frank Denneman, Chief Technologist PernixData
- 2. Traditional I/O path in virtual datacenters © PernixData. All rights reserved. 2 Scale out-compute using single storage array Context based I/O inside host, loss of application identity outside host Non integrated QOS throughout stack Oversubscribed data-path Solution: add more disks to array Switch Switch VM VM ESXi Host Storage Array VM VM ESXi Host
- 3. Flash placement © PernixData. All rights reserved. 3 Server Array Network
- 4. But flash performance is all about distance © PernixData. All rights reserved. 4
- 5. Stage 1 Stage 2 Now Industry development © PernixData. All rights reserved. 5 Flash behind HBA Flash on PCIe Flash on DIMMs Flash-RAM convergence RAM Lightspeed Ludicrous speed
- 6. Million IOPS for 5K USD © PernixData. All rights reserved. 6
- 7. Leveraging flash performance in your architecture © PernixData. All rights reserved. 7 Insert Flash Here Diagram by Chad Sakac
- 8. © PernixData. All rights reserved. ARCHITECTURE OVERVIEW PERNIXDATA FVP
- 9. PernixData FVP © PernixData. All rights reserved. 9 Accelerating application read and write I/O You are in control!
- 10. © PernixData. All rights reserved. PernixData FVP clustered platform
- 11. © PernixData. All rights reserved. Supports mobility at scale ESXi Host Flash Device ESXi Host Flash Device VM Remote flash access FVP (DRS) Migration VM Read Storage Array data
- 12. Write through policy © PernixData. All rights reserved. 12 Write to Flash & Array I/O complete after ack of both resources Primarily accelerating subsequent reads Offloads array & SAN of Read I/O
- 13. Write back policy © PernixData. All rights reserved. 13 Write to Flash then ack Write to Array transparent to application Read & Write acceleration
- 14. © PernixData. All rights reserved. Fault tolerance
- 15. © PernixData. All rights reserved. FVP Fault Domains Fault Domain Blade Center 2 Fault Domain Blade Center 3 Fault Domain Blade Center 1 vSphere Cluster Storage Array VMVM VM VMVM VM Acceleration resources ESXi Host 5 Acceleration resources ESXi Host 6 AVM VM VMVM VM Acceleration resources ESXi Host 3 Acceleration resources ESXi Host 4 VMVM VM VMVM VM Acceleration resources ESXi Host 1 Acceleration resources ESXi Host 2 Peer host selection Peer host selection FVP
- 16. © PernixData. All rights reserved. INFRASTRUCTURE ALLEVIATION
- 17. © PernixData. All rights reserved. Accelerate VM = The most social thing you can do 8 Billion Reads didn’t reach primary storage 318 Terabytes of storage bandwidth not used 10 Billion Writes saw significantly low latency Freeing up resources for other workloads Hero numbers in 6 weeks time:
- 18. © PernixData. All rights reserved. Datastore writes Application performance Uniform write patterns Smooth out writes Time release I/O Reduce forced array cache flushes
- 19. Scale out © PernixData. All rights reserved. 19 16 VMs running SQLIO Work Profile: Series of sequential reads and writes at 8K, 16K, and 64K, then random reads and writes of same block size pattern $2.5 million USD array (64 EFD’s, multiple TB of cache) FVP+SAN 1.6 Million IOPS Array: 51000 IOPS
- 20. © PernixData. All rights reserved. Offload your storage controller CPU Setting up and maintaining data paths Mirror writes (storage controller redundancy) Data movement and data integrity Maintaining RAID levels, calculating & writing parity data Snapshots, Replication, Dedup, Compression Multi-tiering algorithms Running integrated management software
- 21. PernixData FVP: Recovering useable capacity © PernixData. All rights reserved. 21 CPU at Max (~95%), over 200TB of stranded storage FVP offload array utilization (IOPS and CPU) by 75% Releasing Stranded capacity
- 22. © PernixData. All rights reserved. TODAY’S DATACENTER WORKLOADS DEMANDS A NEW ARCHITECTURE
- 23. © PernixData. All rights reserved. Plan-able performance scale-out Non disruptive performance scale out Linked Compute + Storage performance growth Future proof: new tech instantly usable
- 24. Decouple storage perfromance from capacity © PernixData. All rights reserved. 24 VMVM VM VMVM VMVM FVP ESXi Host Flash Device ESXi Host Flash Device ESXi Host Flash Device Storage Array VM VM Performance Capacity + Data services
- 25. Deterministic performance © PernixData. All rights reserved. 25
- 26. Today’s possibilities © PernixData. All rights reserved. 26 New gen. server media … FVP + 32-192 TB RW acceleration resource in 32 node cluster 250.000 IOPS per host 32 Million IOPS per cluster Consistent sub millisecond latency 40Gb interconnects between hosts
- 27. An insurance policy for current and future workloads © PernixData. All rights reserved. 27
- 28. © PernixData. All rights reserved. Deterministic performance Application performance – Change perception of storage performance – Consistent and predictable latency Infrastructure alleviation – Insurance policy for existing application performance levels – Absorb any unknown workload without affecting current workloads Service offering – Control which application gets performance
- 29. © PernixData. All rights reserved. Questions? @frankdenneman @pernixdata
Hinweis der Redaktion
- The hypervisor contains context about I/O. However when leaving the hypervisor, the context is lost. Typically the compute and storage stack is comprised of many components of different vendors. Consequentially unable to provide an integrated QOS throughout the stack.
- And its going on for a few years and it’s a great advancement in the storage technology and which we haven’t seen for decades. One fine morning you wake up and you storage substrate is ready to go 10.000 times faster then your older storage substrate. Well what do you do with it and it turns there’s many folks thinking about and and it turns out that every thought was to make something that’s already existed, which was a storage array, faster. And by itself it’s a great thing, that is needed. But the REAL question is, is that the next big idea? Is that what Flash Tops at? Is it the Next Big Thing? Or can we do something with flash, enable something that was not previously not possible.
- To get the best performance is all about location, you want to get the native performance of the device
- Flash behind the server HBA uses light speed to communicate, yet the industry determined we need faster speeds. We need to be able to remove as much components as possible. Going from networks, to PCI bus, to straight up memory devices.
- The stack is comprised of many queues
- Solving the Traditional Storage Design Problem
- Application agnostic Flash technology agnostic Storage infrastructure agnostic FVP does that in a manor that require no change to the virtual machine, That means No drivers or changes to applications/VMs or static partitioning of server flash. It requires no change to your storage system and it requires, no new virtual appliance, no new datastores to manage. It’s the same old virtual machines that run on the same old datastores on the same old Storage Array except they are magically faster. And that magically faster applies to both read intensive virtual machines as write intensive virtual machines.
- Solving the Traditional Storage Design Problem
- For more information: http://frankdenneman.nl/2014/07/21/stop-wasting-storage-controller-cpu-cycles/
- Solving the Traditional Storage Design Problem
- When to use memory and when to use flash? Timing: current chipsets support up to 1.5TB-3TB per host, 6TB (Intel E7-v2) chipsets already announced