Xen summit gogrid and xen - april 2010 v4
•Als PPT, PDF herunterladen•
0 gefällt mir•676 views
![About GoGrid ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (14)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Xen summit gogrid and xen - april 2010 v4
Ähnlich wie Xen summit gogrid and xen - april 2010 v4 (20)
Mehr von The Linux Foundation
Mehr von The Linux Foundation (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Xen summit gogrid and xen - april 2010 v4
- 1. Xen Summit at AMD April 28-29, 2010 GoGrid & Xen Paul Lappas VP Engineering & Co-Founder
- 3. GoGrid = IaaS SaaS – Software as a Service PaaS– Platform as a Service IaaS – Infrastructure as a Service Google App Engine
- 5. Web Portal – Grid View
- 6. Web Portal – List View
- 11. Remember the Rio player? Xen Summit at AMD April 28-29, 2010
- 12. Xen Summit at AMD April 28-29, 2010
- 13. The Virtual App Marketplace Xen Summit at AMD April 28-29, 2010 Migration tools Syncing tools Commercial SW Etc etc
Hinweis der Redaktion
- Our target markets are small to medium tech startups, and IT departments of larger companies. GoGrid charges for two resources: RAM and TRANSFER. Basically you’re billed a few pennies per hour per gig of RAM deployed.
- We use HVM mode so we can support multiple, unmodified OS’s on the guest. Joke about AMD We are using NEHALEM and testing WESTMERE. We spend lots of effort in evaluate, testing, and validating new HW configurations. We are constantly evaluating new configurations. We use the CPU scheduler to assign a “pro-rata” share of CPU cycles depending on how much RAM a guest is assigned. VERY happy with Xen and as one of the earliest adopters, was our best option at the time.
- While Xen has enjoyed strong adoption from early players in the market, like EC2, GoGrid, and Rackspace, we are seeing more and more enterprise clouds adopt VMware as their hypervisor of choice. Even though VMware has cons, which we’ll take a look at , let’s take a look at why that would be.
- FIRST let’s take a look at what customer wants. This is what consumers of cloud computing customers want today. When designing features, you should be asking yourself “how is what I’m doing going to solve either of the above needs?” Let’s talk a bit about vendor lock-in.
- What was missing STILL was: Not easy to test, trial software perpetual licensing means decision paralysis
- Who remembers the RIO player? 1. Possible to get software onto it, but not very easily. 2. No easy way to pay for only the songs you want (perpetual versus recurring) DIED because easier to BURN CDs. What made the PLAYER blow up? The ITUNES store! Now you could only pay for what you wanted, trial things quickly, by them from one source, and automatically get them. Shazaam. In a way, the RIO player was like a cloud server without access to a virtual appliance marketplace.
- With the marketplace customers can have the luxury of selecting from a number of tools, and de facto support for these appliances between multiple clouds.
- So let’s FOCUS on building an eco-system. What is an eco-system? How do we build it?
- So IaaS clouds are adopting commercial hypervisors like VMware because it gives them the option to participate in an ECO-SYSTEM and thus meet the need of customer’s who DON’T WANT LOCK IN! But then they have to deal with this stuff
- We spent the 90s training customer that shared is good. We spent the 00s training customers that dedicated is good. Now we are asking them to use shared again. At the very least we need a way to prevent customers from clobbering one another; ie we can’t have VMs become unusable due to sharing problems. So preventing starvation is a necessity although not done very well today. Better than prevention is an ability to assign a maximum IO throughput per guest,
- We spent the 90s training customer that shared is good. We spent the 00s training customers that dedicated is good. Now we are asking them to use shared again. At the very least we need a way to prevent customers from clobbering one another; ie we can’t have VMs become unusable due to sharing problems. So preventing starvation is a necessity although not done very well today. Better than prevention is an ability to assign a maximum IO throughput per guest,