4 C’s for Using Cloud to Support Scientific Research
•Als PPTX, PDF herunterladen•
1 gefällt mir•593 views
While cost is a primary "c" driving the adoption of object-based cloud solutions in the life sciences, compute, capacity, and collaboration may all be bigger incentives. In this webinar, we'll examine how to use an Avere Hybrid Cloud NAS infrastructure to gain big benefits in areas like genomics research, personalized medicine, drug discovery, imaging, and other data analysis applications. • Compute - Building production environments in the compute cloud without rewriting existing applications • Capacity - Modernizing storage archives and disaster recovery by adding object storage for durability while leveraging existing on-premises NAS • Collaboration - Using the cloud t o safely and securely share data globally • Cost - Using cloud to lower overall costs to keep pace with fast-growing demands of research initiatives
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie 4 C’s for Using Cloud to Support Scientific Research
Ähnlich wie 4 C’s for Using Cloud to Support Scientific Research (20)
Mehr von Avere Systems
Mehr von Avere Systems (18)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
4 C’s for Using Cloud to Support Scientific Research
- 2. Jeff Tabor Sr. Director of Product Management & Marketing Avere Systems Jeff Tabor has worked at Avere Systems for six years, leading product definition and marketing efforts. Prior to Avere, Jeff managed clustered NAS solutions at NetApp and Spinnaker Networks. Jeff holds Bachelor’s and Master’s degrees in Electrical Engineering and Computer Science from the Massachusetts Institute of Technology. 2
- 3. Scott Jeschonek Director of Product Management Avere Systems Scott has more than twenty years of synthesizing his enterprise, telecommunications, and vendor experience to provide a unique perspective to the implications of the cloud phenomenon. After working with several technology companies, Scott joined Avere in early 2014 where he is responsible for the software roadmap. 3
- 4. Agenda • Cloud overview – Opportunities & challenges • Cloud benefits for scientific research – “The 4 C’s” – Compute scaling – Capacity scaling – Collaboration across global enterprise – Cost savings • Cloud demo – Running scientific apps – Storing scientific data 4
- 5. Poll Question #1 Which one of the 4 “Cs” do you think would be the best use for cloud in your organization? A. Compute B. Capacity C. Collaboration D. Cost
- 6. Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute Hybrid Cloud 6 Bucket 2 Bucket n Bucket 1App servers
- 7. Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute • App servers • Compute farm • Desktops Hybrid Cloud 7 Bucket 2 Bucket n Bucket 1App servers
- 8. Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute • NAS and Object • Multiple tiers of storage • App servers • Compute farm • Desktops Hybrid Cloud 8 Bucket 2 Bucket n Bucket 1App servers
- 9. Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute • NAS and Object • Multiple tiers of storage • App servers • Compute farm • Desktops • Near infinite compute • Cloud bursting • Permanent infrastructure Hybrid Cloud 9 Bucket 2 Bucket n Bucket 1App servers
- 10. Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute • NAS and Object • Multiple tiers of storage • App servers • Compute farm • Desktops • Near infinite compute • Cloud bursting • Permanent infrastructure • Near infinite capacity • Mostly backup and archive today Hybrid Cloud 10 Bucket 2 Bucket n Bucket 1App servers
- 11. Storage Cloud Bucket 2 Bucket n Bucket 1 Compute Cloud App servers Cloud is Attractive BUT has Challenges 11 On-Prem Storage NAS Object On-Prem Compute
- 12. Storage Cloud Bucket 2 Bucket n Bucket 1 Compute Cloud App servers Cloud is Attractive BUT has Challenges 12 On-Prem Storage NAS Object On-Prem Compute Cloud challenges 1. Unfamiliar object- based interface S3 S3 S3 S3
- 13. Storage Cloud Bucket 2 Bucket n Bucket 1 Compute Cloud App servers Cloud is Attractive BUT has Challenges 13 On-Prem Storage NAS Object On-Prem Compute Cloud challenges 1. Unfamiliar object- based interface 2. High latency to remote storage S3 S3 S3 S3 Latency of 10-100ms or more
- 14. Storage Cloud Bucket 2 Bucket n Bucket 1 Compute Cloud App servers Cloud is Attractive BUT has Challenges 14 On-Prem Storage NAS Object On-Prem Compute Cloud challenges 1. Unfamiliar object- based interface 2. High latency to remote storage 3. No easy on-ramp to cloud storage S3 S3 S3 S3 Latency of 10-100ms or more
- 15. Storage Cloud Bucket 2 Bucket n Bucket 1 Compute Cloud App servers Cloud is Attractive BUT has Challenges 15 On-Prem Storage NAS Object On-Prem Compute Cloud challenges 1. Unfamiliar object- based interface 2. High latency to remote storage 3. No easy on-ramp to cloud storage 4. Cloud Gateways do NOT scale S3 S3 S3 S3 Latency of 10-100ms or more Single-node Gateway Single-node Gateway
- 16. Compute • Cloud benefits – Unlimited compute capacity • Time to market – Cost effective • Easy to turn on and turn off • Zero footprint • Cloud challenges – High latency to data • Performance impact • Compute cloud NOT intended for storage – Familiar file system interface • No change to apps
- 17. Cloud Computing with Avere 17 Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute Customer Need • Performance for tier-1 applications • Avoid latency to storage • Don’t replicate all data to compute cloud Bucket 2 Bucket n Bucket 1App servers
- 18. Cloud Computing with Avere 18 Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute Customer Need • Performance for tier-1 applications • Avoid latency to storage • Don’t replicate all data to compute cloud Recommended Solution • Automatic caching of active data only • Handle read, writes, and metadata ops • Hide latency (50:1 or more offload) Physical Edge Filer Virtual Edge Filer Cache data near compute Hide latency to storage Bucket 2 Bucket n Bucket 1App servers
- 19. Cloud Computing with Avere 19 Customer Need • Keep pace with growing demand • Avoid disruptive upgrades • Start small, grow huge at “click of button” Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute Physical Edge Filer Virtual Edge Filer Bucket 2 Bucket n Bucket 1App servers
- 20. Cloud Computing with Avere 20 Customer Need • Keep pace with growing demand • Avoid disruptive upgrades • Start small, grow huge at “click of button” Storage CloudCompute Cloud On-Prem Storage NAS Object On-Prem Compute Physical Edge Filer Virtual Edge Filer Bucket 2 Bucket n Bucket 1App servers Recommended Solution • Scale-out NAS provided via clustering • Performance scaling (more CPUs, DRAM) • Capacity scaling (more SSD for better hit rate) Cluster from 3 to 50 nodes
- 21. Capacity • Cloud benefits – Unlimited storage capacity – Simple to manage (no maintenance, easy scaling) – Pay only for what you use • Cloud challenges – Protect investment in on-prem storage – Unfamiliar access protocol (e.g. S3 API) – Missing features • Security • Compression • Snapshots
- 22. Data Source: http://genome.gov/sequencingcosts Slide Source: Chris Dagdigian, BioTeam, as presented in BioIT World webinar, April 2014
- 23. Use Case – Inova Health System Enabling Personalized Medicine with a Hybrid Cloud Avere + AWS Benefits – 6,300 whole genomes, 1.3PB, and 7M files in AWS – Genomic analysis results in hours not days – Saved more than $10 million – Avere encryption & AWS HIPAA compliance Customer Challenges – Scale to petabytes of capacity – Scale performance for genomic analysis – Contain cost (opex, not capex) – Security & compliance
- 24. GNS AWS S3AWS EC2 Use Case – Large Pharmaceutical Company Public Cloud Services • New apps, built for cloud • FlashMove to public cloud - Lowest cost - Simplest management • Centralized resources - Collaboration - Scalable, most efficient On-Prem Resources • Existing apps, no changes • Data that cannot move to public cloud (security) • FlashMove to object storage - Lower cost - Better scaling • Geo-dispersal, no replication - Simpler to manage - More efficient Bucket 2 Bucket n Bucket 1 Physical FXT On-Prem Storage NAS Object On-Prem Compute Virtual FXT Virtual Compute Farm FlashMove FlashMove New Apps Existing Apps
- 25. Use Case – Next Gen Sequencing at CDC Avere Benefits – Scalable performance for SMB and NFS – Reduced Isilon spend by 33% – GNS provides central mount point for all storage – Hide network latency to remote labs – Add public or private cloud in future Customer Challenges – Isilon performance at scale – Isilon cost – Legacy Isilon – Distributed users and storage – Network saturation and latency Datacenter B (legacy) EMC Isilon (old) FXT Cluster (3 nodes)EMC Isilon (510PB) FXT Cluster (11 nodes) Generate (SMB) Process (NFS) Interpret (SMB) Datacenter A (centralized, scalable storage) Remote Labs Use central storage Simplify mgmt Cache at edge GNS
- 26. Collaboration • Cloud benefits – Centralized data – Accessible from many geographic regions • Cloud challenges – Hide latency to centralized data – Read and write access coordination • One writer, many readers • Many writers, minimal sharing • Many writers to shared files
- 27. Primary Datacenter Hybrid Cloud NAS for Global Enterprises Remote Office
- 28. Primary Datacenter Hybrid Cloud NAS for Global Enterprises Remote Office Secondary/Partner/Colo Datacenter
- 29. Primary Datacenter Hybrid Cloud NAS for Global Enterprises Cloud Computing (Public/Private) Remote Office Secondary/Partner/Colo Datacenter Virtual or Physical
- 30. Cloud Storage (Public/Private) Primary Datacenter Hybrid Cloud NAS for Global Enterprises Cloud Computing (Public/Private) Remote Office Secondary/Partner/Colo Datacenter Virtual or Physical
- 31. Cloud Storage (Public/Private) Primary Datacenter Hybrid Cloud NAS for Global Enterprises Cloud Computing (Public/Private) Remote Office Secondary/Partner/Colo Datacenter Virtual or Physical
- 32. Cost • Cloud benefits – Economy of scale – Zero footprint, power, and cooling – Pay only for what you use (capacity & compute) – Simplified management • Cloud challenge/change – Opex, not capex
- 33. Avere + Amazon TCO Example TCO Savings = $2,701,000 Old Way (NetApp or EMC) New Way (Avere + Amazon) T1 Customer Reqs • 200k IOPS • 200TB primary • 1PB Amazon S3 T2 200k IOPS + 200TB Primary NetApp 6000+SAS or EMC Isilon S200 1PB Archive NetApp 3000+SATA or EMC Isilon NL400 T2 AWS 200TB Primary Private object or legacy NAS 1PB Storage AWS S3: 1,000TB Avere 200k IOPS Avere 3800 (4x)manual copy FlashMove TCO Saving with Avere + Amazon Cost NetApp or Isilon Avere + Amazon S3 Storage Acquisition $2,067,000 $298,000 Service $930,000 $134,000 Amazon S3 (capacity) $0 $1,032,000 Amazon S3 (data out) $0 $298,000 Storage Admin $1,080,000 $196,000 Facilities & Power $264,000 $43,000 Data Migration $360,000 $0 3-year TCO $4,701,000 $2,000,000 Avere + AWS TCO savings ($) $2,701,000 Avere + AWS TCO savings (%) 57%
- 34. Comparing 1,000,000 IOPS Solutions* EMC Isilon $10.7 / IOPS NetApp $5.1 / IOPS 150ms Avere $2.3 / IOPS Throughput (IOPS) Latency/ORT (ms) List Price $/IOPS Disk Quantity Rack Units Cabinets Product Config Avere FXT 3800 1,592,334 1.24 $3,637,500 $2.3 549 76 1.8 32-node cluster, cloud storage config NetApp FAS 6240 1,512,784 1.53 $7,666,000 $5.1 1728 436 12 24-node cluster EMC Isilon S200 1,112,705 2.54 $11,903,540 $10.7 3360 288 7 140-node cluster *Comparing top SPEC SFS results for a single NFS file system/namespace. See www.spec.org/sfs2008 for more information.
- 35. Comparing 1,000,000 IOPS Solutions* EMC Isilon $10.7 / IOPS NetApp $5.1 / IOPS 150ms Avere $2.3 / IOPS Throughput (IOPS) Latency/ORT (ms) List Price $/IOPS Disk Quantity Rack Units Cabinets Product Config Avere FXT 3800 1,592,334 1.24 $3,637,500 $2.3 549 76 1.8 32-node cluster, cloud storage config NetApp FAS 6240 1,512,784 1.53 $7,666,000 $5.1 1728 436 12 24-node cluster EMC Isilon S200 1,112,705 2.54 $11,903,540 $10.7 3360 288 7 140-node cluster *Comparing top SPEC SFS results for a single NFS file system/namespace. See www.spec.org/sfs2008 for more information. Avere 32-node FXT cluster
- 36. Comparing 1,000,000 IOPS Solutions* EMC Isilon $10.7 / IOPS NetApp $5.1 / IOPS 150ms Avere $2.3 / IOPS Throughput (IOPS) Latency/ORT (ms) List Price $/IOPS Disk Quantity Rack Units Cabinets Product Config Avere FXT 3800 1,592,334 1.24 $3,637,500 $2.3 549 76 1.8 32-node cluster, cloud storage config NetApp FAS 6240 1,512,784 1.53 $7,666,000 $5.1 1728 436 12 24-node cluster EMC Isilon S200 1,112,705 2.54 $11,903,540 $10.7 3360 288 7 140-node cluster *Comparing top SPEC SFS results for a single NFS file system/namespace. See www.spec.org/sfs2008 for more information. Avere 32-node FXT cluster Core Filer -NAS -Public object -Private object
- 37. Poll Question #2 What applications are you looking to deploy in the cloud? A. Business apps (e.g. email, DB, knowledge base) B. File services (e.g. file serving, home dirs, document management, patient management) C. High-performance apps (e.g. genomic sequencing, imaging, bioinformatics ) D. Backup and archival only E. Other (please specify in chat)
- 38. Real-world Demo: Life Sciences in Google Cloud
- 39. Cloud Bursting Use Case – Life Sciences 39 Proprietary & Confidential Cloud StorageCloud Compute Customer Challenges •Add compute resources at peak times •Need for 3-6 months, no long- term commitment •Do NOT want to rewrite applications •May move data to the cloud for capacity scaling (later) Avere Benefits •Virtual FXT provides scalable NAS in Cloud Compute •Hide latency to on-prem NAS and object storage •Easy setup, easy teardown •Pay only for what is used •Future: move data to the cloud for better economics Physical FXT On-Prem Storage NAS On-Prem Compute Virtual FXT Virtual Compute Farm
- 40. Cloud Bursting + Archive Use Case – Life Sciences 40 Proprietary & Confidential Cloud StorageCloud Compute Customer Challenges •Add compute resources at peak times •Need for 3-6 months, no long- term commitment •Do NOT want to rewrite applications •Wishes to post results for general access in lower-cost Cloud Compute Avere Benefits •Provide File System access to virtually unlimited cloud storage •Provide Global NameSpace (GNS) directory structure between on-prem and cloud for application continuity Physical FXT On-Prem Storage NAS On-Prem Compute Virtual FXT Virtual Compute Farm Bucket 2 Bucket n Bucket 1
- 41. Hybrid Galaxy-in-Cloud – Life Sciences 41 Proprietary & Confidential Cloud StorageCloud Compute Customer Challenges •Never enough compute nodes on-prem •Linear OPEX costs for new on-prem, seeking to reduce •Requires file-system and performance for continuity •Storage flexibility must remain for compliance, etc Avere Benefits •Empower application operation completely in Cloud and eliminate on-prem compute, no matter the size of organization Physical FXT On-Prem Storage NAS On-Prem Compute Virtual FXT Virtual Compute Farm Bucket 2 Bucket n Bucket 1 Sequencer
- 42. Galaxy-in-Cloud – Life Sciences 42 Proprietary & Confidential Cloud StorageCloud Compute Customer Challenges •Company or Project too small for on-prem costs •But need file system with sufficient performance characteristics •Duration of project may be short Avere Benefits •No on-prem requirement •Run only when you need the nodes helps reduce overall costs •The ultimate flexibility Virtual FXT Virtual Compute Farm Bucket 2 Bucket n Bucket 1 Small Company, Research Lab, etc
- 43. Galaxy in Cloud Compute Instance (8CPUs, 8GB Memory, 500GB Disk or less) Debian Linux Galaxy Server installed with all tools 3-Node Avere vFXT cluster BucketNFS Mounts to the Avere Cluster Map to Cloud Bucket S3 Protocol Cloud Storage, Single Bucket / /gcs File System Maintained By Avere for Object Storage /galaxy-data
- 44. Galaxy in Cloud /etc/fstab Maps NFS to the vFXT environment as /mnt/galaxy-data Galaxy Server is locally installed, though it could also be located in the Cloud Storage and mounted via the vFXT
- 45. Avere vFXT maps to Cloud Storage
- 46. Avere vFXT maps to Cloud Storage
- 47. Avere vFXT Exports NameSpace
- 48. Galaxy Client is mounted on the FXT cluster
- 50. Reference Data located in Bucket Reference Genome data stored in a directory on the Cloud Bucket
- 51. Step 1, upload fastq files
- 52. Client uploads through vFXT
- 53. Run TopHat2
- 54. Run TopHat2
- 55. The Power of Caching 3-Node Avere vFXT cluster BucketNFS Mounts to the Avere Cluster Map to Cloud Bucket S3 Protocol Cloud Storage, Single Bucket / /gcs File System Maintained By Avere for Object Storage /galaxy-data Multiple Galaxy Clients calling: Reference Genomes Same output files Read / Read-ahead caching Ensures faster response and minimizes Cloud Bucket “hits”
- 56. Thank you! Questions? For more information, visit: averesystems.com Contact Us at: 888.88.AVERE askavere@averesystems.com
Hinweis der Redaktion
- Gretchen does speaker intro and hands of to Jeff.
- Gretchen does speaker intro and hands of to Jeff.
- Thanks Gretchen. As Gretchen said, our topic today is Best Practices for Architecting Enterprise NAS in the Hybrid Cloud. If you have questions, please send them via chat and we will get to them at the end. I will attack this topic in three steps. (This overview slide shows the path I will take to get there.) First, we define the Hybrid Cloud to make sure we are all on the same page. The Hybrid cloud bring s lots of benefits but it brings challenges as well and we will discuss these. Next, there’s an early generation of products called Cloud Gateways helping customers use the cloud and we will look at the pros and cons of these. Last, we will talk about deploying Enterprise NAS apps in the cloud, how the requirements go beyond what typical Cloud Gateways offer today and the best practices for building robust and scalable Enterprise NAS apps in the cloud.
- Let’s talk about the Hybrid Cloud. This diagram shows the way I am defining it. I hope you like this slide since you will see a lot of it during this presentation. The Hybrid Cloud encompasses all the IT resources that admin or architect has available to him or her. They have an on-prem compute + storage infrastructure and a parallel compute + storage infrastructure in the cloud. The point of this presentation is to learn how we can us all this available infrastructure both on-prem and in-cloud in a holistic, single system way. I’ve organized this into four quadrants. Let’s talk about the individual quadrants.
- In the lower left, we have op-prem compute. This includes the app servers, compute farms, and desktops. For an Enterprise NAS app, this is where most NAS clients are running today.
- Next we have the on-prem storage. Historically this has been all NAS for file-based applications. Recently people have begun to deploy object storage here. This typically includes multiple tiers of storage including tier-1 for performance, tier-2 for nearline, and tier-3 for deep archive/backup.
- Next we have the compute cloud. This is a service offered by a service provider like Amazon or Google. This is near infinite compute available in the compute cloud and is very attractive for temporary bursting of applications into the cloud or permanently moving your IT infrastructure to the cloud.
- Last we have the storage cloud. Again, the storage cloud is a service offered by a service provider such as Amazon or Google. And again, the capacity in the storage cloud is nearly infinite. Today, the storage cloud is used mainly for backup and archive. In this presentation I will show you how you can use it for more than just backup and archive. Which brings me to a larger point. And that’s the main point of this presentation. The Hybrid Cloud presents all the IT resources available to me. The question we are trying to answer in this presentation is how can I use all the resources for my Enterprise NAS of file-based applications.
- Cloud is attractive in many ways but does pose some challenges. Let’s examine these challenges.
- First, object storage presents an unfamiliar, object-based interface. The most popular such interface is Amazon’s S3 API. Most apps running on-prem or in the cloud do not support S3. Most file-based apps support NAS protocols such as NFS and SMB/CIFS. This is a challenge since users don’t want to re-write their apps for the cloud.
- Second, in a Hybrid Cloud environment, there is a lot of latency between the storage clients and the storage itself. For on-prem clients, this latency is suffered when going to remote on-prem storage or the storage cloud. Similarly, for app servers running in the compute cloud, this latency is suffered when going to the storage cloud or on-prem storage. This is a challenges since makes your apps run slow.
- Third, there is no easy way to get data into the cloud. You may be moving data to the storage cloud for archival purposes or because you want to process the data in the cloud. But, this is no easy way to get it there without disrupting the users of the data.
- Last, there are Cloud Gateway products offered to solve some of these challenges, but the gateways are all implemented as a single node products and do not scale and therefore are not useful for your Enterprise NAS applications. Let’s dig into this gateway topic a little deeper…
- Building production environments in the compute cloud without rewriting existing applications
- On each of the next five slides, I will first discuss the need in a little more depth and then recommend the solution or best practice for achieving this need. Best practice #1 is that you need to architect for high performance. The goal here is to run tier-1 apps both on-prem and in the compute cloud. Remember, there is a lot of latency between the compute and the storage and you need a way to hide this latency. Last, you don’t want to replicate large amounts of data to the compute in order to avoid this latency. This is a wasteful approach. It is also complex since it is difficult to know which data to replicate. The compute cloud, for instance, contains SSDs where you can store date will it is being processed but this is expensive and you want to use this capacity intelligently and not just blindly replicate large amounts of data.
- The best practice is to be working with a Cloud Gateway type device that does automatic caching of active data to be near the compute. The right device should be available in both virtual/software-only and physical hardware included models. The virtual device runs in the compute cloud and the physical devices runs on-prem. Both the virtual device and the physical device must be able to access storage both on prem and in the cloud. Hence, the four lines in my diagram. In my diagram, I am calling this device an Edge Filer since it needs to do more than a typical gateway. For example, the Edge File needs to handle read, write, and metadata operations locally near the compute. Enterprise NAS apps issue all these operations and you don’t want to suffer the latency on any of them. By handling all these operations out at the edge, the Edge Filer hides the latency of the WAN to the storage. Doing this effectively means the edge file can provide 50:1 offload or more. This means for every 50 operations the Edge Filer services to the compute clients, only 1 operations goes back to the storage.
- Best practice #2 is that you need a solution that is Highly Scalable. Enterprise NAS/file applications are always growing and you need to keep pace with demand. As you add more app servers or nodes in the compute farm, you need to be able to scale the access to the storage as well. Scaling must be non-disruptive since you cannot stop the application. And, you want to be able to start small for a good entry price and grow to be huge over timer at the “click of a button.”
- The best practice is to be working with a Scale-out NAS solution that supports clustering. There are solutions on the market that allow scaling from 3 to 50 nodes. On-prem, you bring in additional physical nodes and they can be simply added to the cluster. In the compute cloud it’s even simpler since from 3 to 50 nodes can be added in a software-only manner with the click of a button on a mgmt GUI. Adding nodes to the Edge Filer increases performance since the load is automatically spread over more CPUs, DRAM, and network ports. Adding nodes to the Edge Filer increases SSD capacity which enables caching a larger working set of data and yields a better cache hit rate.
- Modernizing storage archives and disaster recovery by adding object storage for durability while leveraging existing on-premises NAS
- Why is there so much data? One source is that the cost of genomic sequencing is come down dramatically in the past decade. In the tech sector we always brag about Moore’s Law and that technology equipment is getting twice as dense/fast/cheap every two years. The cost of genomic sequencing is dropping much faster than this. So the equipment used for storing the data is not keeping up with the data being generated. Data: 2001=$100M 2011=$3M 10 years Cost reduce by half 5 times 32x less (2x4x8x16x32x)
- Inova use case
- BMS (Bristol Meyers Squibb) use case.
- CDC use case
- Using the cloud to safely and securely share data globally
- This slide shows four scenarios where Avere can be used to implement a cloud infrastructure. Some enterprises may use just one scenario whiles other may use multiple. The slide starts with the scenario where Avere is used to accelerate data access at remote offices. Avere has many customers doing this type on thing. One example is a company that is headquartered in San Jose but has software engineers in offices all over the world. In their Boulder office they replaced their NetApp storage with an Avere cluster. The software engineers use the Avere cluster to access their homedirs, run their software builds, etc. Meanwhile, their data is actually stored, managed, and protected back in the San Jose data center. The Avere cluster automatically caches the active data at the Boulder site and guarantees the data is pushed back to the San Jose site for long-term data retention. While this “data center to remote office” may be the most common cloud scenario today, there are other needs across the enterprise. (click) A second example is when there are two data centers that the enterprise wants to run as a single “mega” data center. These exist for disaster recovery reasons, due to acquisitions, due to partnerships, due to growing out of space in the primary data center which requires leasing space at a co-lo facility, etc. In these cases, the goal is run the two data centers as one large datacenter where each individual data center can borrow resources of the other data center. Avere can help make this happen. An example of this is Pixar and Disney. Pixar is in N. Cal and Disney is in S. Cal. Pixar and Disney are Avere customers and we allow them to run these two data centers as one. For example, if Pixar is working a movie with a near-term release date and they need to crank up the volume on the renders, rather than going out and buying new render nodes, they can borrow them from Disney. They can do this because they have placed Avere nodes by Disney’s render farm. When Pixar fires up some renders on the Disney farm, the Avere nodes are automatically populated with the data for the renders. Hence, the renders see the WAN latency once on the first read, but subsequent reads are very low latency. Until recently, when studios like this would borrow renders nodes they would literally pull them out of the rack, put them in a truck, and drive them to the other facility. This is because the renders nodes need to be near the data. With Avere, these studios can quickly and easily move the data so it is near the render farm. (click) The next example is cloud computing. Today, Avere supports private cloud computing. Technically this is similar to public cloud computing which we will support in the future. In the private cloud case, a customer moves their compute infrastructure somewhere else because it’s cheaper or they are out of space in their data center. Avere makes this possible since an Avere cluster can be co-located with the compute gear to hold the data that is actively being processed. We have a number of customers doing this today. In Las Vegas, there is a co-lo facility called the SuperNAP. This facility was originally built by ENRON, the failed energy company. You may recall that ENRON was getting into all sorts of strange businesses and one of them was “bandwidth trading.” So they built a giant co-lo facility in LV with tons of b/w coming in an out. Well, after ENRON failed, a company called Switch Communications bought the facility and turned it into an outsource co-lo facility. We have a number of customers who are using the SuperNAP. Digital Domain is one of these customers who are using the SuperNAP because: 1) it cheaper using their own CA-based data centers and 2) its centrally located between the 3 sites (LA, SF, Vancouver) that use the compute resources at the SuperNAP. Today, when D2 fires up their renders (whether from LA, SF, or Vanc.) they fire them up on the LV farm and the Avere nodes in LV automatically populate the data needed for the renders. (click) The fourth example is cloud storage. With release 4.0, Avere supports both public and private cloud computing. For public cloud, we support Amazon S3. For private cloud, we support Cleversafe and any 3rd-party NAS solution. One of the primary use cases is using cloud storage as a lower cost alternative to on-premise storage for archival data. This use case is discussed in more detail in the next two slides. (click) Over time, much of the storage in data centers today will move to the cloud. Avere enables this by providing a complete set of NAS functionality on the enterprise premise (e.g. performance scaling, HA, NFS, SMB/CIFS) and the ability to hide the latency of the WAN to the public cloud.
- This slide shows four scenarios where Avere can be used to implement a cloud infrastructure. Some enterprises may use just one scenario whiles other may use multiple. The slide starts with the scenario where Avere is used to accelerate data access at remote offices. Avere has many customers doing this type on thing. One example is a company that is headquartered in San Jose but has software engineers in offices all over the world. In their Boulder office they replaced their NetApp storage with an Avere cluster. The software engineers use the Avere cluster to access their homedirs, run their software builds, etc. Meanwhile, their data is actually stored, managed, and protected back in the San Jose data center. The Avere cluster automatically caches the active data at the Boulder site and guarantees the data is pushed back to the San Jose site for long-term data retention. While this “data center to remote office” may be the most common cloud scenario today, there are other needs across the enterprise. (click) A second example is when there are two data centers that the enterprise wants to run as a single “mega” data center. These exist for disaster recovery reasons, due to acquisitions, due to partnerships, due to growing out of space in the primary data center which requires leasing space at a co-lo facility, etc. In these cases, the goal is run the two data centers as one large datacenter where each individual data center can borrow resources of the other data center. Avere can help make this happen. An example of this is Pixar and Disney. Pixar is in N. Cal and Disney is in S. Cal. Pixar and Disney are Avere customers and we allow them to run these two data centers as one. For example, if Pixar is working a movie with a near-term release date and they need to crank up the volume on the renders, rather than going out and buying new render nodes, they can borrow them from Disney. They can do this because they have placed Avere nodes by Disney’s render farm. When Pixar fires up some renders on the Disney farm, the Avere nodes are automatically populated with the data for the renders. Hence, the renders see the WAN latency once on the first read, but subsequent reads are very low latency. Until recently, when studios like this would borrow renders nodes they would literally pull them out of the rack, put them in a truck, and drive them to the other facility. This is because the renders nodes need to be near the data. With Avere, these studios can quickly and easily move the data so it is near the render farm. (click) The next example is cloud computing. Today, Avere supports private cloud computing. Technically this is similar to public cloud computing which we will support in the future. In the private cloud case, a customer moves their compute infrastructure somewhere else because it’s cheaper or they are out of space in their data center. Avere makes this possible since an Avere cluster can be co-located with the compute gear to hold the data that is actively being processed. We have a number of customers doing this today. In Las Vegas, there is a co-lo facility called the SuperNAP. This facility was originally built by ENRON, the failed energy company. You may recall that ENRON was getting into all sorts of strange businesses and one of them was “bandwidth trading.” So they built a giant co-lo facility in LV with tons of b/w coming in an out. Well, after ENRON failed, a company called Switch Communications bought the facility and turned it into an outsource co-lo facility. We have a number of customers who are using the SuperNAP. Digital Domain is one of these customers who are using the SuperNAP because: 1) it cheaper using their own CA-based data centers and 2) its centrally located between the 3 sites (LA, SF, Vancouver) that use the compute resources at the SuperNAP. Today, when D2 fires up their renders (whether from LA, SF, or Vanc.) they fire them up on the LV farm and the Avere nodes in LV automatically populate the data needed for the renders. (click) The fourth example is cloud storage. With release 4.0, Avere supports both public and private cloud computing. For public cloud, we support Amazon S3. For private cloud, we support Cleversafe and any 3rd-party NAS solution. One of the primary use cases is using cloud storage as a lower cost alternative to on-premise storage for archival data. This use case is discussed in more detail in the next two slides. (click) Over time, much of the storage in data centers today will move to the cloud. Avere enables this by providing a complete set of NAS functionality on the enterprise premise (e.g. performance scaling, HA, NFS, SMB/CIFS) and the ability to hide the latency of the WAN to the public cloud.
- This slide shows four scenarios where Avere can be used to implement a cloud infrastructure. Some enterprises may use just one scenario whiles other may use multiple. The slide starts with the scenario where Avere is used to accelerate data access at remote offices. Avere has many customers doing this type on thing. One example is a company that is headquartered in San Jose but has software engineers in offices all over the world. In their Boulder office they replaced their NetApp storage with an Avere cluster. The software engineers use the Avere cluster to access their homedirs, run their software builds, etc. Meanwhile, their data is actually stored, managed, and protected back in the San Jose data center. The Avere cluster automatically caches the active data at the Boulder site and guarantees the data is pushed back to the San Jose site for long-term data retention. While this “data center to remote office” may be the most common cloud scenario today, there are other needs across the enterprise. (click) A second example is when there are two data centers that the enterprise wants to run as a single “mega” data center. These exist for disaster recovery reasons, due to acquisitions, due to partnerships, due to growing out of space in the primary data center which requires leasing space at a co-lo facility, etc. In these cases, the goal is run the two data centers as one large datacenter where each individual data center can borrow resources of the other data center. Avere can help make this happen. An example of this is Pixar and Disney. Pixar is in N. Cal and Disney is in S. Cal. Pixar and Disney are Avere customers and we allow them to run these two data centers as one. For example, if Pixar is working a movie with a near-term release date and they need to crank up the volume on the renders, rather than going out and buying new render nodes, they can borrow them from Disney. They can do this because they have placed Avere nodes by Disney’s render farm. When Pixar fires up some renders on the Disney farm, the Avere nodes are automatically populated with the data for the renders. Hence, the renders see the WAN latency once on the first read, but subsequent reads are very low latency. Until recently, when studios like this would borrow renders nodes they would literally pull them out of the rack, put them in a truck, and drive them to the other facility. This is because the renders nodes need to be near the data. With Avere, these studios can quickly and easily move the data so it is near the render farm. (click) The next example is cloud computing. Today, Avere supports private cloud computing. Technically this is similar to public cloud computing which we will support in the future. In the private cloud case, a customer moves their compute infrastructure somewhere else because it’s cheaper or they are out of space in their data center. Avere makes this possible since an Avere cluster can be co-located with the compute gear to hold the data that is actively being processed. We have a number of customers doing this today. In Las Vegas, there is a co-lo facility called the SuperNAP. This facility was originally built by ENRON, the failed energy company. You may recall that ENRON was getting into all sorts of strange businesses and one of them was “bandwidth trading.” So they built a giant co-lo facility in LV with tons of b/w coming in an out. Well, after ENRON failed, a company called Switch Communications bought the facility and turned it into an outsource co-lo facility. We have a number of customers who are using the SuperNAP. Digital Domain is one of these customers who are using the SuperNAP because: 1) it cheaper using their own CA-based data centers and 2) its centrally located between the 3 sites (LA, SF, Vancouver) that use the compute resources at the SuperNAP. Today, when D2 fires up their renders (whether from LA, SF, or Vanc.) they fire them up on the LV farm and the Avere nodes in LV automatically populate the data needed for the renders. (click) The fourth example is cloud storage. With release 4.0, Avere supports both public and private cloud computing. For public cloud, we support Amazon S3. For private cloud, we support Cleversafe and any 3rd-party NAS solution. One of the primary use cases is using cloud storage as a lower cost alternative to on-premise storage for archival data. This use case is discussed in more detail in the next two slides. (click) Over time, much of the storage in data centers today will move to the cloud. Avere enables this by providing a complete set of NAS functionality on the enterprise premise (e.g. performance scaling, HA, NFS, SMB/CIFS) and the ability to hide the latency of the WAN to the public cloud.
- This slide shows four scenarios where Avere can be used to implement a cloud infrastructure. Some enterprises may use just one scenario whiles other may use multiple. The slide starts with the scenario where Avere is used to accelerate data access at remote offices. Avere has many customers doing this type on thing. One example is a company that is headquartered in San Jose but has software engineers in offices all over the world. In their Boulder office they replaced their NetApp storage with an Avere cluster. The software engineers use the Avere cluster to access their homedirs, run their software builds, etc. Meanwhile, their data is actually stored, managed, and protected back in the San Jose data center. The Avere cluster automatically caches the active data at the Boulder site and guarantees the data is pushed back to the San Jose site for long-term data retention. While this “data center to remote office” may be the most common cloud scenario today, there are other needs across the enterprise. (click) A second example is when there are two data centers that the enterprise wants to run as a single “mega” data center. These exist for disaster recovery reasons, due to acquisitions, due to partnerships, due to growing out of space in the primary data center which requires leasing space at a co-lo facility, etc. In these cases, the goal is run the two data centers as one large datacenter where each individual data center can borrow resources of the other data center. Avere can help make this happen. An example of this is Pixar and Disney. Pixar is in N. Cal and Disney is in S. Cal. Pixar and Disney are Avere customers and we allow them to run these two data centers as one. For example, if Pixar is working a movie with a near-term release date and they need to crank up the volume on the renders, rather than going out and buying new render nodes, they can borrow them from Disney. They can do this because they have placed Avere nodes by Disney’s render farm. When Pixar fires up some renders on the Disney farm, the Avere nodes are automatically populated with the data for the renders. Hence, the renders see the WAN latency once on the first read, but subsequent reads are very low latency. Until recently, when studios like this would borrow renders nodes they would literally pull them out of the rack, put them in a truck, and drive them to the other facility. This is because the renders nodes need to be near the data. With Avere, these studios can quickly and easily move the data so it is near the render farm. (click) The next example is cloud computing. Today, Avere supports private cloud computing. Technically this is similar to public cloud computing which we will support in the future. In the private cloud case, a customer moves their compute infrastructure somewhere else because it’s cheaper or they are out of space in their data center. Avere makes this possible since an Avere cluster can be co-located with the compute gear to hold the data that is actively being processed. We have a number of customers doing this today. In Las Vegas, there is a co-lo facility called the SuperNAP. This facility was originally built by ENRON, the failed energy company. You may recall that ENRON was getting into all sorts of strange businesses and one of them was “bandwidth trading.” So they built a giant co-lo facility in LV with tons of b/w coming in an out. Well, after ENRON failed, a company called Switch Communications bought the facility and turned it into an outsource co-lo facility. We have a number of customers who are using the SuperNAP. Digital Domain is one of these customers who are using the SuperNAP because: 1) it cheaper using their own CA-based data centers and 2) its centrally located between the 3 sites (LA, SF, Vancouver) that use the compute resources at the SuperNAP. Today, when D2 fires up their renders (whether from LA, SF, or Vanc.) they fire them up on the LV farm and the Avere nodes in LV automatically populate the data needed for the renders. (click) The fourth example is cloud storage. With release 4.0, Avere supports both public and private cloud computing. For public cloud, we support Amazon S3. For private cloud, we support Cleversafe and any 3rd-party NAS solution. One of the primary use cases is using cloud storage as a lower cost alternative to on-premise storage for archival data. This use case is discussed in more detail in the next two slides. (click) Over time, much of the storage in data centers today will move to the cloud. Avere enables this by providing a complete set of NAS functionality on the enterprise premise (e.g. performance scaling, HA, NFS, SMB/CIFS) and the ability to hide the latency of the WAN to the public cloud.
- This slide shows four scenarios where Avere can be used to implement a cloud infrastructure. Some enterprises may use just one scenario whiles other may use multiple. The slide starts with the scenario where Avere is used to accelerate data access at remote offices. Avere has many customers doing this type on thing. One example is a company that is headquartered in San Jose but has software engineers in offices all over the world. In their Boulder office they replaced their NetApp storage with an Avere cluster. The software engineers use the Avere cluster to access their homedirs, run their software builds, etc. Meanwhile, their data is actually stored, managed, and protected back in the San Jose data center. The Avere cluster automatically caches the active data at the Boulder site and guarantees the data is pushed back to the San Jose site for long-term data retention. While this “data center to remote office” may be the most common cloud scenario today, there are other needs across the enterprise. (click) A second example is when there are two data centers that the enterprise wants to run as a single “mega” data center. These exist for disaster recovery reasons, due to acquisitions, due to partnerships, due to growing out of space in the primary data center which requires leasing space at a co-lo facility, etc. In these cases, the goal is run the two data centers as one large datacenter where each individual data center can borrow resources of the other data center. Avere can help make this happen. An example of this is Pixar and Disney. Pixar is in N. Cal and Disney is in S. Cal. Pixar and Disney are Avere customers and we allow them to run these two data centers as one. For example, if Pixar is working a movie with a near-term release date and they need to crank up the volume on the renders, rather than going out and buying new render nodes, they can borrow them from Disney. They can do this because they have placed Avere nodes by Disney’s render farm. When Pixar fires up some renders on the Disney farm, the Avere nodes are automatically populated with the data for the renders. Hence, the renders see the WAN latency once on the first read, but subsequent reads are very low latency. Until recently, when studios like this would borrow renders nodes they would literally pull them out of the rack, put them in a truck, and drive them to the other facility. This is because the renders nodes need to be near the data. With Avere, these studios can quickly and easily move the data so it is near the render farm. (click) The next example is cloud computing. Today, Avere supports private cloud computing. Technically this is similar to public cloud computing which we will support in the future. In the private cloud case, a customer moves their compute infrastructure somewhere else because it’s cheaper or they are out of space in their data center. Avere makes this possible since an Avere cluster can be co-located with the compute gear to hold the data that is actively being processed. We have a number of customers doing this today. In Las Vegas, there is a co-lo facility called the SuperNAP. This facility was originally built by ENRON, the failed energy company. You may recall that ENRON was getting into all sorts of strange businesses and one of them was “bandwidth trading.” So they built a giant co-lo facility in LV with tons of b/w coming in an out. Well, after ENRON failed, a company called Switch Communications bought the facility and turned it into an outsource co-lo facility. We have a number of customers who are using the SuperNAP. Digital Domain is one of these customers who are using the SuperNAP because: 1) it cheaper using their own CA-based data centers and 2) its centrally located between the 3 sites (LA, SF, Vancouver) that use the compute resources at the SuperNAP. Today, when D2 fires up their renders (whether from LA, SF, or Vanc.) they fire them up on the LV farm and the Avere nodes in LV automatically populate the data needed for the renders. (click) The fourth example is cloud storage. With release 4.0, Avere supports both public and private cloud computing. For public cloud, we support Amazon S3. For private cloud, we support Cleversafe and any 3rd-party NAS solution. One of the primary use cases is using cloud storage as a lower cost alternative to on-premise storage for archival data. This use case is discussed in more detail in the next two slides. (click) Over time, much of the storage in data centers today will move to the cloud. Avere enables this by providing a complete set of NAS functionality on the enterprise premise (e.g. performance scaling, HA, NFS, SMB/CIFS) and the ability to hide the latency of the WAN to the public cloud.
- Using cloud to lower overall costs to keep pace with fast-growing demands of research initiatives
- With that, I’ve reached the end of my presentation. Thank you for your time today. I am happy to take any questions you may have. (Answer questions.) Thanks again. We appreciate your feedback. Please use the “rating” button to send us your feedback.
- With that, I’ve reached the end of my presentation. Thank you for your time today. I am happy to take any questions you may have. (Answer questions.) Thanks again. We appreciate your feedback. Please use the “rating” button to send us your feedback.