Tag Archives: Amazon S3

private cloud:Eucalyptus

original:http://open.eucalyptus.com/learn/what-is-eucalyptus

What is Eucalyptus

In the previous article, Learn about cloud computing we introduced the basics of cloud computing and we discussed how clouds are classified according to service offerings or “styles” (i.e., IaaS, PaaS, SaaS) and “types” (i.e., public, private and hybrid). In this article we introduce the Eucalyptus cloud computing platform.

Eucalyptus enables the creation of on-premise private clouds, with no requirements for retooling the organization’s existing IT infrastructure or need to introduce specialized hardware. Eucalyptus implements an IaaS (Infrastructure as a Service) private cloud that is accessible via an API compatible with Amazon EC2 and Amazon S3. For more information on our API see our Developer’s Corner. This compatibility allows any Eucalyptus cloud to be turned into a hybrid cloud, capable of drawing compute resources from public cloud. And Eucalyptus is compatible with a wealth of tools and applications that also adhere to the de facto EC2 and S3 standards.

Here are some of the characteristics that make Eucalyptus the most widely deployed cloud platform for the private (on-premise) cloud:

Open Source
Eucalyptus is open source: if you want to modify it, contribute to it, assess its security or just learn from it you can download it and have the source code at your fingertips. The Eucalyptus development process is in the open, as are bug reports, community contributions and security advisories.
Modular
Eucalyptus’ design is modular. The Eucalyptus components have well-defined interfaces (via WSDL, since they are web services) and thus can be easily swapped out for custom components.
Distributed
Eucalyptus allows its components to be installed strategically close to the needed/used resources. For example Walrus can be installed close to the storage, while the Cluster Controller can be installed close to the cluster it will manage.
Designed to Perform
Eucalyptus was designed from the ground up to be scalable and to achieve optimal performance in diverse environments (designed to overlay an existing infrastructure).
Flexible
Eucalyptus is flexible and can be installed on a very minimal setup. Yet it can be installed on thousands of cores and terabytes of storage. And it can do so as an overlay on top of an existing infrastructure.
Compatible
Eucalyptus is compatible with the most popular and widely used Cloud API currently available: Amazon EC2 and S3. Eucalyptus’ design allows for any other API to be implemented, but to date no other real Cloud API contender is as complete and as requested as Amazon’s.
Hypervisor Agnostic
Eucalyptus is designed to easily support most available and future hypervisors. Currently Eucalyptus fully supports KVM and Xen. Additionally, the Enterprise Edition supports the proprietary VMware hypervisor.
Hybrid Cloud
All of the above characteristics makes Eucalyptus easy to deploy as an hybrid cloud. An hybrid cloud combines resources drawn from multiple clouds, typically one private and one public. Eucalyptus compatibility with Amazon’s EC2 API allows for a natural hybrid cloud with the biggest public cloud available.

History of Eucalyptus

Eucalyptus was born as a University project in the MAYHEM labs of the Computer Science Dept. at UC Santa Barbara. The MAYHEM team’s experience in Grid Computing, HPC, and massively scalable systems (Rich Wolski’s team of NWS and EveryWare fame) made it the natural place for the birth of Eucalyptus.

The name EUCALYPTUS is an acronym and stands for Elastic Utility ComputingArchitecture for Linking Your Programs TUseful Systems. A brief description of this period can be read here. This is of course no coincidence as UCSB is a leading University in Cloud Computing research.

In 2009, the Eucalyptus team started a company (Eucalyptus Systems Inc.) to commercialize Eucalyptus. Currently there is Eucalyptus, the open source project, and Eucalyptus EE (Enterprise Edition), which is the commercial version of Eucalyptus.

Next Steps

Our talented development team has made installing Eucalyptus easy, but some planning is still required (e.g., Where is the storage for Walrus/S3? What about the storage and network for EBS? How many public IPs can Eucalyptus use? Is there a private network for the Node Controllers? How big will my cloud grow?). These questions are a normal part of the planning process that IT goes through in order to appropriately size the infrastructure for a deployment. Before embarking on a full-scale deployment we suggest familiarizing yourself with Eucalyptus by:

  • TestDrive our community cloud (ECC);
  • Reserve few machines, and follow our documentation in particular the administrator’s guide, to install Eucalyptus on your favorite distribution.

Our forum are always available if you need additional help. Or explore other ways toparticipate in our community.

[Repost]Product: Amazon Simple Storage Service

original:

Product: Amazon Simple Storage Service

Update: HostedFTP.com – Amazon S3 Performance Report. How fast is S3? Based on their own study HostedFTP.com has found: 10 to 12 MB/second when storing and receiving files and 140 ms per file stored as a fixed overhead cost.


Update: A Quantitative Comparison of Rackspace and Amazon Cloud Storage Solutions. S3 isn’t the only cloud storage service out there. Mosso is saying they can save you so money while offering support. There are number of scenarios in their paper, but For 5TB of cloud storage Mosso will save you 17% over S3 without support and 42% with support. For their CDN on a Global test Mosso says the average response time is 333ms for CloudFront vs. 107ms for Cloud Files which means globally, Cloud Files is 3.1 times or 211% faster than CloudFront.

Amazon S3 is storage for the Internet. It is designed to make web-scale computing easier for developers.

This service allows you to link directly to files at a cost of 15 cents per GB of storage, and 20 cents per GB transfer.

[repost]Build an Infinitely Scalable Infrastructure for $100 Using Amazon Services

original:

Build an Infinitely Scalable Infrastructure for $100 Using Amazon Services

Can you really create an infinitely scalable infrastructure for less than $100 using Amazon’s storage, grid, and queuing services platform? It appears so, at least for the right application. Amazon beams a spot light on the future battle of the roll-your-own versus the connect-the-dots approach to building next generation websites using core external services. Their argument is strong. Using Amazon’s platform you can quickly build an infrastructure that would otherwise take an eternity to make, a pile of money to create, and an unbounded mass of people to implement and maintain. Yet Amazon doesn’t provide SLAs, so you can you really trust them with your crown jewels? Facebook recently leap frogged Amazon’s vision with an even more comprehensive set of services. The battle for the future is on.

Site: http://aws.amazon.com/

Information Sources

  • Slides: Building Highly Scalable Web Applications
  • Podcast: Technometria: Amazon Web Services
  • Amazon Services Home.

    Platform

  • Amazon ECS (E-Commerce Service)
  • Amazon S3 (simple storage service)
  • Amazon SQS (simple queuing service)
  • Amazon EC2 (grid service)
  • Amazon Web Search Service
  • Amazon Flexible Payments Service (Amazon FPS)
  • REST and SOAP Service Interfaces

    What’s Inside?

    Why use external services?

  • Amazon’s services replace the boxes, wires, and disk drives part of the application stack.
  • Amazon has spent ten years and over $1 billion developing a world-class web service that millions of customers use every day. Maybe you can leverage that experience for your site?
  • Focus on the customer. 70% if Web Development isn’t about providing customer value. It’s about building and managing data centers. Your efforts would be better spent on your customers and not plumbing.
  • Quicker to market. Scaling is hard. Let someone else worry
    about that while you concentrate on adding user value.
  • Designing for peak load is expensive. So turn fixed costs into variable costs. Say you want to handle high traffic flows from slashdot or digg, or you have high seasonal demand, having the infrastructure in place to handle those loads is a high fixed cost. You could use that money better elsewhere. It make sense to create an infrastructure where you can automatically and
    temporarily scale resources to handle peak demand.
  • High reliability and availability. A dedicated service may be more reliable than a service you could create. It say “may” because Amazon doesn’t provide an SLA, so you wont get any guarantees. The idea is that Amazon is cheap enough and reliable enough that the few failures will be acceptable. Besides, SLAs usually just refund some money when things go wrong, they
    don’t really guarantee anything.
  • It’s a cheap CDN. Amazon’s storage network could serve a relatively inexpensive content delivery network. This option is discussed in
    Reducing Your Website’s Bandwidth Usage
    . The idea is that just the frequent downloading of a simple favicon.ico
    file can use a significant portion of your bandwidth. Using S3 for $2/month to offload 90% of your bandwidth to an external host is a good deal. However, without an SLA S3 can’t be thought of as a proper CDN.

    Amazon ECS (E-Commerce Service)

  • This service exposes Amazon’s product data and e-commerce functionality:
    Detailed Product Information on all Amazon.com Products, Access to Product Images, All Customer Reviews associated with a Product, etc.
  • Amazon products are aggressively priced.
  • I found this service disappointing. If you want to build a store on top of Amazon it seems great, but I didn’t see a way to add your own products to the store, so I don’t think it’s generally useful.

    Amazon S3 (simple storage service)

  • This service stores data in Amazon’s storage network.
  • $.15 per GPB per month storage
  • $.01 for 1000 to 10000 requests.
  • $.10 – $.17 per GB data transfer.
  • The service is: fast, relaible, scalable, redundant, dispersed.
  • You can have per object URLs. This means you can reference an image or other file directly with a URL, so it’s usable in a web page.
  • Typical use: CDN and backup storage.
  • Storage is distributed to multiple locations so you get a level of geographical distribution.

    Amazon SQS (simple queuing service)

  • This service provides an internet scale queuing service for storing messages. Distributed actors put work on the queue and take work off the queue.
  • $.10 per 1000 messages.
  • $.10 – $.18 per GB data transfer.
  • This service is: scalable, elastic, reliable, simple, secure.
  • Typical use: a centralized work queue. You put jobs on the queue and different actors can pop work of the queue and process them when they get CPU time.
  • Expected message latency, as of 2007, was 2-10 seconds. This is horrible for many applications, not bad for many others.
  • Part of scalability. Have any number of producers and consumers. You don’t worry about it.
  • Queues are spread across multiple machines and multiple data centers.

    Amazon EC2 (grid service)

  • This service provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.
  • Basically you create a Xen image for your Linux distro and upload it into their “elastic compute cloud.” Using an API you can then start as many instances as you like.
  • Typical use: transcoding, audio work, load testing.
  • Root level access to the server and full control over the machine.
  • Can scale up and scale down on a minute-by-minute basis.
  • For real-time processing one criticism has been slow CPUs (1.75 Ghz Xeon). This probably won’t be a problem if your application is written to linearly scale.
  • An EC2 instance is not persistent so you can’t store a database there. You have some local storage, but it goes away when the instance goes away.
  • Takes a few minutes to start and stop images, so it’s not really on demand.
  • You can add anything you want to an image. If you want a database you can add it in.

    GigaVox Media Example Web-Scale Architecture

  • You can start to see how Amazon’s services can work together. Let’s say you have a large batch of MP2s you would like transcode to MP3s. You would store the original media into S3, queue the work request into SQS, and have instances running in EC2 to take work of the queue and perform the transcoding, storing the results back into S3. And this is exactly what GigaVox does.
  • GigaVox is a podcasting company.
    – They take original recordings and transcode them say from MP2 to MP3. Many other transcodings are also performed.
    – Then these chunks of media are assembled together into a delivery format based on building a show. For example, old podcasts can be reassembled each night with up to date advertisements.
    – To do this at scale would take a lot of costly resources.
  • Using Amazon’s services GigaVox gets geographically redundancy and failover for relatively inexpensive CPU, bandwidth, and storage charges,
    and bandwidth costs. You have no boxes or wires. No data center to manage. And you can grow with small fixed costs.
  • Messages are time stamped on the queue. If the message waited in the queue for too long then they can start more EC2 images. You can balance costs. You could also layer in a customer based priority mechanism.
  • They have each instance have its own messaging queue for command and control.
  • For security reasons they upload files through ftp to instances rather than going through S3.
  • All bandwidth withing the Amazon cloud is free. This is an important business consideration for making the services work together.
  • Another set of instances and queues handles assembling the delivered media.
  • Allows GigaVox to deliver value to their customer at a low startup cost.

    Lessons Learned

  • Build or buy is always a difficult decision. If a service doesn’t work then you may lose your customers and there’s nothing more you can do other send yet another urgent email to nobody in particular. This is a horrible feeling. Yet, if it does work you could be way ahead of the game. How to choose? That would be telling :-)
  • Build a layer of virtualization so you can switch to another provider when they become available or so you can replace it with your own service. This lessens your dependency on Amazon in the event they get tired of offering services or their performance deteriorates.
  • As a startup using Amazon services isn’t a big risk because you are already in a risky situation. And any risk is moderated by the very low cost of starting up and money is always an issue for startups.
  • For many use cases buying your own dedicated servers may still be a better approach as you get more control, lower latency, and the same hardware is usable for multiple purposes.
  • Software as a service is a powerful and practical idea. It changes how you build software. It forces you to layer your software around interfaces. And once your software is composed of interfaces you have loosely coupled components that can be easily replaced. You also have the basis for a platform API should you ever want to provide an API you your customers. The highest level of development would to use the same API you give your customers to build your service.
  • Loosely coupled, message based architectures combined with service interfaces allow you to think several levels up the abstraction layer. You don’t have to wallow in the muck, which frees you how to structure your application using large scale blocks of behavior.
  • Designing a UI for an asynchronous interactive interface poses some challenges. It may take a while to perform an operation, so how do you interact with the user to handle that?
  • Instinctively I doubted Amazon could deliver. But if you have the right type of problem, you really can do a lot of work cheaply using Amazon services.

    See Also

  • Flickr and YouTube also deal with service level APIs.