Cloud World

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Monday, 2 December 2013

The new Persistent Disk - faster, cheaper and more predictable for Google Compute Engine

Posted on 20:30 by Unknown
High performing disk IO is critical to most virtual machine workloads, but today, developers face a big challenge. They want great performance, but at prices that are predictable. No one wants a big surprise when they see their bill.



Today, we are launching significant improvements to Persistent Disk (PD), unifying our block storage offerings.  First, we are significantly lowering PD pricing to Scratch Disk levels, reducing costs 60% - 92%. In addition, PD performance caps are being raised such that they scale linearly with volume size up to 8x the previous volume limits for random reads and 4x the previous volume limits for random writes. Finally, persistent disks can now meet the price and performance requirements of scratch data with better reliability, functionality, and flexibility.



New lower and more predictable Persistent Disk price model

Due to advancements in how we store PD data, we are able to cut PD prices significantly without sacrificing reliability or performance.










Old Price


New Price


Space


$0.10 / GB / month


$0.04 / GB / month


IO


$0.10 / million IOs


Included in price of the space






Our customers wanted more predictable pricing. So in addition to being lower, the new prices are also predictable and consistent from month to month due to the inclusion of IO charges.



For example, previously, if you created a 400 GB volume, the costs would vary depending on your IOPS. At a minimum, it would have been $40/month assuming no IO for the entire month. At a maximum, it would have been $197.80/month assuming 600 write IOs every second of the month.



With the new PD pricing, a 400 GB volume will cost $16 / month no matter how much IO your application performs for resulting in savings of ranging from 60% to 92%!



New Persistent Disk performance model

PD is introducing a new performance model that increases top volume IOPS caps 4x for random writes and 8x for random reads without sacrificing the performance consistency that has been PD’s distinguishing characteristic since its original release.



In the new model, PD performance caps scale linearly with the size of the volume — larger volumes can perform more IO than smaller volumes up to absolute limits described in the product documentation.  This model is designed to:





  • Raise the overall caps:  The highest performing volumes now have the following limits




    • 2000 random read IOPS (up from 250)



    • 2400 random write IOPS (up from 600)



    • 180 MB/s of streaming reads (up from 120 MB/s)



    • 120 MB/s of streaming writes (same as previous limit)




  • Simplify scaling of IO: As we’ve publicly discussed, PD volumes are striped across hundreds or even thousands of physical devices. With PD, we manage the RAID for you so you never have to stripe multiple small volumes together inside a VM to increase IO. You get the same performance for a single 1 TB volume as for 10 x 100 GB volumes





The new limits are discussed in detail in the product documentation.



PD is your new scratch disk

PD is now a great choice for storing scratch data. Your applications will run as well as using scratch disk in most cases, while at the same time, becoming more reliable and easier to manage. PD volumes remain available through planned maintenance and hardware failure. This is the key enabler for live migration and allows us to keep data centers up to date without customer disruption — a unique feature among public clouds.



PD volumes can be unmounted from one VM and remounted to another. This radically simplifies and speeds up the processes of upgrading applications and resizing VMs. In addition, PD volumes can be snapshotted to our global object store, Google Cloud Storage, for simple zone migration, backup and recovery, and disaster recovery. PD volumes can be up to 10 TB in size.



With the drop in PD price and performance improvements you can now use it, with all its benefits, to replace your scratch disk. To further improve scratch data costs, PD volumes are not restricted to predefined sizes - buy only as much space as you need to hold your data and access it with the right performance. Larger volumes can be mounted by smaller VMs if high CPU and memory are not required.



For more details, please see the product documentation and our technical article which includes helpful best practices. We hope you enjoy the new offering and look forward to your feedback at the Compute Engine discussion mailing list.



-Posted By Jay Judkowitz, Senior Product Manager
Email ThisBlogThis!Share to XShare to Facebook
Posted in Compute Engine | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Bridging Mobile Backend as a Service to Enterprise Systems with Google App Engine and Kinvey
    The following post was contributed by Ivan Stoyanov , VP of Engineering for Kinvey, a mobile Backend as a Service provider and Google Cloud ...
  • Tutorial: Adding a cloud backend to your application with Android Studio
    Android Studio lets you easily add a cloud backend to your application, right from your IDE. A backend allows you to implement functionality...
  • 2013 Year in review: topping 100,000 requests-per-second
    2013 was a busy year for Google Cloud Platform. Watch this space: each day, a different Googler who works on Cloud Platform will be sharing ...
  • Easy Performance Profiling with Appstats
    Since App Engine debuted 2 years ago, we’ve written extensively about best practices for writing scalable apps on App Engine. We make writ...
  • TweetDeck and Google App Engine: A Match Made in the Cloud
    I'm Reza and work in London, UK for a startup called TweetDeck . Our vision is to develop the best tools to manage and filter real time ...
  • Scaling with the Kindle Fire
    Today’s blog post comes to us from Greg Bayer of Pulse , a popular news reading application for iPhone, iPad and Android devices. Pulse has ...
  • Who's at Google I/O: Mojo Helpdesk
    This post is part of Who's at Google I/O , a series of guest blog posts written by developers who are appearing in the Developer Sandbox...
  • A Day in the Cloud, new articles on scaling, and fresh open source projects for App Engine
    The latest release of Python SDK 1.2.3, which introduced the Task Queue API and integrated support for Django 1.0, may have received a lot ...
  • SendGrid gives App Engine developers a simple way of sending transactional email
    Today’s guest post is from Adam DuVander, Developer Communications Director at SendGrid. SendGrid is a cloud-based email service that deliv...
  • Qubole helps you run Hadoop on Google Compute Engine
    This guest post comes form Praveen Seluka, Software Engineer at Qubole, a leading provider of Hadoop-as-a-service.  Qubole is a leading pr...

Categories

  • 1.1.2
  • agile
  • android
  • Announcements
  • api
  • app engine
  • appengine
  • batch
  • bicycle
  • bigquery
  • canoe
  • casestudy
  • cloud
  • Cloud Datastore
  • cloud endpoints
  • cloud sql
  • cloud storage
  • cloud-storage
  • community
  • Compute Engine
  • conferences
  • customer
  • datastore
  • delete
  • developer days
  • developer-insights
  • devfests
  • django
  • email
  • entity group
  • events
  • getting started
  • google
  • googlenew
  • gps
  • green
  • Guest Blog
  • hadoop
  • html5
  • index
  • io2010
  • IO2013
  • java
  • kaazing
  • location
  • mapreduce
  • norex
  • open source
  • partner
  • payment
  • paypal
  • pipeline
  • put
  • python
  • rental
  • research project
  • solutions
  • support
  • sustainability
  • taskqueue
  • technical
  • toolkit
  • twilio
  • video
  • websockets
  • workflows

Blog Archive

  • ▼  2013 (143)
    • ▼  December (33)
      • 2013 Year in review: topping 100,000 requests-per-...
      • 2013 Year in review: making Google Compute Engine ...
      • 2013 Year in review: bringing App Engine to the PH...
      • Now Get Programmatic Access to your Billing Data W...
      • 2013 year in review: making scalability easy with ...
      • 2013 Year in review: taking Google Cloud Platform ...
      • 2013 Year in review: pushing the limits of Big Data
      • 2013 Year in review: enabling native connections f...
      • 2013 Year in review: bringing Offline Disk Import ...
      • Best practices for App Engine: memcache and eventu...
      • 2013 Year in review: giving time back to developers
      • 2013 Year in review: bringing together mobile and ...
      • Go on App Engine: tools, tests, and concurrency
      • Qubole helps you run Hadoop on Google Compute Engine
      • Alert Logic security and compliance solutions for ...
      • Outfit 7’s Talking Friends built on Google App Eng...
      • You can now deliver any-screen streaming media usi...
      • Using Google Compute Engine with open source software
      • DataTorrent offers massive-scale, real-time stream...
      • DataStax Enterprise feels right at home in Google ...
      • Why We Deployed Zencoder on Google Cloud Platform
      • Scalr and Google Compute Engine
      • Cloud9 IDE on Google Compute Engine
      • Fishlabs architects upcoming game with Compute Eng...
      • An ode to Sharkon
      • SaltStack for Google Compute Engine
      • Google Compute Engine and App Engine give Evite fr...
      • SUSE Linux Enterprise Server Now Available on Goog...
      • Google Compute Engine is now Generally Available w...
      • The new Persistent Disk - faster, cheaper and more...
      • Red Hat and Google Compute Engine – Extending the ...
      • Google Compute Engine helps Mendelics diagnose gen...
      • CoolaData digs into the “why” of online consumer b...
    • ►  November (15)
    • ►  October (17)
    • ►  September (13)
    • ►  August (4)
    • ►  July (15)
    • ►  June (12)
    • ►  May (15)
    • ►  April (4)
    • ►  March (4)
    • ►  February (9)
    • ►  January (2)
  • ►  2012 (43)
    • ►  December (2)
    • ►  November (2)
    • ►  October (8)
    • ►  September (2)
    • ►  August (3)
    • ►  July (4)
    • ►  June (2)
    • ►  May (3)
    • ►  April (4)
    • ►  March (5)
    • ►  February (3)
    • ►  January (5)
  • ►  2011 (46)
    • ►  December (3)
    • ►  November (4)
    • ►  October (4)
    • ►  September (5)
    • ►  August (3)
    • ►  July (4)
    • ►  June (3)
    • ►  May (8)
    • ►  April (2)
    • ►  March (5)
    • ►  February (3)
    • ►  January (2)
  • ►  2010 (38)
    • ►  December (2)
    • ►  October (2)
    • ►  September (1)
    • ►  August (5)
    • ►  July (5)
    • ►  June (6)
    • ►  May (3)
    • ►  April (5)
    • ►  March (5)
    • ►  February (2)
    • ►  January (2)
  • ►  2009 (47)
    • ►  December (4)
    • ►  November (3)
    • ►  October (6)
    • ►  September (5)
    • ►  August (3)
    • ►  July (3)
    • ►  June (4)
    • ►  May (3)
    • ►  April (5)
    • ►  March (3)
    • ►  February (7)
    • ►  January (1)
  • ►  2008 (46)
    • ►  December (4)
    • ►  November (3)
    • ►  October (10)
    • ►  September (5)
    • ►  August (6)
    • ►  July (4)
    • ►  June (2)
    • ►  May (5)
    • ►  April (7)
Powered by Blogger.

About Me

Unknown
View my complete profile