Slashdot Mirror
Red Hat Releases Preview Version of Open Stack Distribution
hypnosec writes "Red Hat has announced the availability of a preview version of its OpenStack Distribution that would enable it to compete with the likes of Amazon which is considered one of the leaders in infrastructure-as-a-service cloud services. The enterprise Linux maker was a late entrant into the OpenStack world where players like Rackspace, HP and Internap have already made their mark. Red Hat's OpenStack distribution enterprises can build and manage private, public, and hybrid infrastructure-as-a-service clouds. These companies will not only be competing with the likes of Amazon, but will also be competing against themselves to get a bite out of the IaaS cloud. What started as a project has quickly developed into an open source solution that enables organizations to achieve performance, features and greater functionality from their private and/or public clouds. The announcement of OpenStack Foundation acted as a catalyst toward the fast-paced development of the platform."
I'd like to see an open, user-driven, distributed cloud where all data is encrypted at a low level, so participants in the cloud don't know what specific data is on their computer: just how much space it is taking up.
Freenet, which has been around since the 90s or so?
The killer with those architectures is pruning. How do you know when the info is no longer needed? Well you toss out the least recently requested data. This leads to really antisocial behavior like setting up two boxes who do nothing but request each others data over and over.
Another exciting architectural feature is random extremely high latency when fetching.
Finally ideally your fetcher would be content aware and failure tolerant. So if you're missing precisely one packet of a movie file, it doesn't just curl and die, but inserts a single blank frame. mpeg / whatever will work around it.
Summary: We've got what you requested, but we need 1) intelligent pruning 2) some kind of semi-intelligent pre-fetch algorithm 3) fault tolerant and content aware fetcher
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
OpenStack is the ability for organizations to offer the kinds of services that Amazon provides to internal (or even external) clients.
I have no proof one way or the other, but I'm convinced that Amazon got in to the "Cloud" business simply because they had already adopted the service and virtualization idiom for development and the infrastructure to support it internally for their own services, and then found they had a lot of idle hardware after the Christmas shopping rush. Opening up that spare hardware to the world to use was simply an attempt to monetize idle system using infrastructure they already had. I guess it turned out to be a pretty good idea in its own right. Who knew.
Deploying cloud services to internal clients for development, deployments, testing, marketing, etc. has show to be an efficient use of both hardware as well as human resources in terms of easier management. OpenStack is one of sets of infrastructure that makes the management of such systems easier, and includes capabilities such as auditing and billing so that costs can be better and more easily allocated to internal operation units.
Nothing sinister here.
Probably not in the form it takes now. Android based devices do a lot to improve usability of Linux, and feel pretty damn forign to anyone with heavy unix experience. On the upside, they are very easy to manage. If linux makes it to the desktop, it won't be in the form we see now.
"When you buy a system and colocate it, you get 100% of the system resources."
Yes. And 100% of the inconveniencies.
"When you use OpenStack (or any resource virtualization scheme) you lose 15% of all the resources to begin with"
Yes. And when the hardware breaks you lose 100% of said resources. Something a migration (maybe even live) can save you of. Now, how many servers do you know with *exactly* 100% load?
"All hardware-acceleration (no TOE on the network)"
Given that the standard live for a production server is about three years, you can bet that, unless you use a lessen OS, about half of that life you are better managing network packets on the OS than on the NIC firmware.
"To add, then you're charged for CPU time per core, Bandwidth by the byte, and disk IOPS by the IOPS."
Yes... or not. There's nothing in the IaaS business model that forces to charge for any single of those items. On the other hand, you *are* paying for CPU, network, etc. on your dedicated server, only it's not itemized, nor upgradable.
But there's something else you are not noticing. Openstack is basically two things: a manager for the IaaS provider and a standard API for the consumer. Nothing more, nothing less. There's absolutly nothing avoiding a provider to offer you a "dedicated server" (minus the virtualization overhead, and even this is probably going to change, given that Openstack is aiming at providing "bare iron" provisioning in the future) just like any other current provider, exactly on the same terms of service and then even more (if wanted/needed) because of the provider-facing facilities any "cluster manager" like Openstack adds.
"Building this stuff is expensive"
But not more expensive than your own datacenter/server room under other technologies.
"and using cheap commodity hardware is unreliable"
But much more reliable than a traditional server room under same conditions (you can't live-migrate instances on a traditional server room).
"so the only way to beat Amazon is to either have enough leverage to make the bandwidth free, or to use unreliable hardware configurations"
So you have done the numbers, didn't you? Just in case you didn't: http://www.buildcloudstorage.com/2012/01/can-openstack-swift-hit-amazon-s3-like.html
"What may help is if the concept of "****stack" is eliminated. Instead of trying to create 4 VM's on one machine, it should instead be about virtualizing the storage system"
You don't have the slightest idea of what Openstack brings to the table, do you? Well, here comes a starting point: http://www.openstack.org/
I'd rather use Fedora 17.
From the FAQ:
It supports the Essex version and will support the next rev when released, but this part bothers me:
"What are the requirements for using the preview software?
A: The preview version of the Red Hat OpenStack software only works with Red Hat Enterprise Linux 6.3 or higher. You'll need a Red Hat Enterprise Linux subscription for each server you install with the Red Hat OpenStack software."
It maybe less work than with Fedora 17- but 17 includes OpenStack and has a how to get started (some bash-ing required).
http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17
"Should we care?" is what I'm trying to figure out. Redhat has lost almost all relevance in the Cloud-arena. CloudStack is in Apache Incubation, and OpenStack Essex is already live in Ubuntu 12.04 LTS. Redhat's OpenStack is presumably all KVM-based as it's built on RHEL6. Does it support bare-metal Cloud instances? Granted, this feature is 'beta' on CloudStack, but it is still there to use.
It seems like a desperate play to stay relevant. With Redhat's "virtualization brain trust" posting erroneous and irrelevant FUD while moderating/rejecting all replies, it appears there's a severe lack of strategy outside of "stop all the Xen-based clones with dom0's based on our OSS distribution!" Redhat shot themselves in the foot pushing KVM down people's throats to thwart Oracle and Citrix clones.
As someone that's built Private Clouds, and runs significant amounts of infrastructure, I personally have a hard time caring. None-the-less, I'm checking it out to see if the Swift object storage part is in any way cleaner integrated. If it's just some pre-built, probably back-level RPMs, I'll be highly unimpressed.
Does anybody have some good recommendations for cloud servers?
Well the really cool thing about these clouds is the API that allows your services to manipulate the servers.
Imagine a couple of app servers behind a load balancer, that are monitored by another service. This monitor service can watch response times and as traffic grows and the response times increase the monitor service can hit the API and deploy another app server. Once the app server is running the monitor service can hit the API on the load balancer and add the new node into the spray. Once traffic dwindles down you can do the opposite and spin down the extra instances saving you server resources (or money if you are on the public cloud) that can be used for other things. Basically if you build your applications to scale properly you can use the cloud to use your resources where they are actually needed.
The cloud also makes deployments easier. Lets say you have updates to apply. You can simply apply the updates to your golden image, and deploy to dev. The image has automated scripts that deploy the services on the machine for the environment. You can then test the changes in dev/test and promote the new image to prod. Instead of applying updates directly to the currently running machines just add in new instances with the new image into the load balances and then remove the old instances.
Now imagine if this was all automated. Have your sysadmin install the updates during the week and test out that everything is working, dev automatically gets redeployed every day in the morning with the new image and any new code to go with it. QA during the week and then promote your image for the auto redeploy into prod on Sunday mornings.
It seems like a lot of people are scared of the cloud, or think that its all hype, but I think that if you can architect your environment properly the cloud can be a very powerful tool.