On Tue, 2010-07-20 at 20:48 -0600, Christopher A. Williams wrote: > On Wed, 2010-07-21 at 03:00 +0100, Marko Vojinovic wrote: > > On Tuesday, July 20, 2010 23:18:11 Phil Meyer wrote: > > > That is the whole point. Ideally this is how it works from a ptactical > > > point of view: > > > > > > I am the Dean of Engineering and we need to run a massive simulation of > > > a type 5 tornado on a set of bridge types. This is not only for > > > instruction is a senior level class, but as our main graduate focus for > > > the next year. > > > > > > We assess our own needs, and access the University 'cloud' website. I > > > order 256 2.6 GHZ or better CPUs, 192GB of RAM, and 2TB of disk space, > > > and specify Linux as my OS. > > > > > > Thirty minutes later I get an email notification with the hostname, IP > > > Address, administrator login, and password for my new compute environment. > > <snip...> > > > Nope. Thirty minutes later you will get an email saying that the simulation > > from the Dean of Engineering is using up vast amount of resources, and that > > there is nowhere nearly enough RAM for what you want. > > Nope - That's not true. Resource sharing in a cloud environment doesn't > work that way unless you're really bad at managing things. If you are, > go back to the 101 level course on managing cloud infrastructure. This > is the most basic of operations management for cloud. > > > Then you get pissed off, call the Engineering Dean on the phone, and he tells > > you that his department invested more money for the cloud infrastructure than > > you, and that his simulation is more important than your database, from the > > scientific point of view. Then you call University Dean and through him order > > the cloud maintainers to reduce the resources for the simulation in order to > > accommodate for your database. > > > > Dean of Engineering then gets pissed off, and decides to withdraw his share of > > money and build his own cloud, to be used only by the Engineering department. > > Soon enough other departments do the same and you end up having a dozen of > > clouds on the University, and they don't interoperate since people are fighting > > over resources and who invested more money and whose work is more important. > > > > This will of course defeat the purpose of having a cloud in the first place, > > since every department is going to invest into their own equipment, and then > > have it idling or thrown away after their projects are over. > > > > And actually, all this has already happened. I've seen it on a couple of > > Universities. It's just that they were "sharing" (ie. fighting over) *cluster* > > resources, not *cloud* resources. But that's just terminology difference. > > No - It's not just a terminology difference. There truly is a difference > between clusters and cloud environments. In cloud environments, You can > absolutely guarantee resource availability (CPU, RAM, Disk, and Network > resources) to a designated groups of systems, and you can dynamically > scale the environment to efficiently meet the compute needs of all > parties. If anything, it makes capacity planning much simpler. > Traditional clusters simply do not, and cannot, do this. > > > When people invest their money into something, they want to be "in charge" of > > it. And if they are supposed to share it with others, there is bound to be a > > lot of friction. > > > > I agree that this cloud environment can be useful in a commercial company > > where there is only one "money bag". But in University environment, somehow I > > doubt... > > I've faced this issue in more client engagements than I care to count. > It's invariably a red herring. The vast majority of people really just > want reasonable guarantees that they will actually have their > *realistic* expectations met. Maintaining control over one's own little > IT fiefdom for the sake of ego maintenance is something even commercial > organizations can not afford these days. Let's not even start with > universities. > > In my professional life, I deal with exactly these kinds of issues > constantly. While most folks just want to understand how things work, > the truly dogmatic objectors turn out with impressive consistency to all > be basically ego driven control freaks, who are also not very adept at > this kind of technology - let alone IT infrastructure. > > One short, but true story: Someone who fit this dogmatic category well > (his own coworkers would joke about him) once asked me about how much > storage we were allocating VMs. I said, "On the average we plan for 50GB > of disk per VM," - an industry norm. > > Half-chuckling, he said, "Well, that's not enough for us." > > "Really?" I replied. "How much disk do you need?" > > Leaning back in his chair, he smugly answered, "We usually deal with > storage in a minimum of half-terabyte increments." > > "Oh." I said. "I see. ...and how much of that half-terabyte are you > currently using?" > > Someone from the other end of the table snickered (I guess they couldn't > help it) and said, "...About 20GB." > > ...That pretty much ended the meeting. I thought to myself, so in > reality, this guy *wastes* about half a terabyte of disk at a time. > > Over the life of that phase of the project, he never came close to using > 200GB (although he demanded much more repeatedly - he just couldn't > justify it), and when his disk usage spiked, people jokingly questioned > what part of his personal MP3 collection he was keeping out there - at > which point his storage usage started to go down. > > We just made sure he always had the compute resources he really needed, > and also made sure that he was efficiently using what was given to him. > Think of it as a "Eat all of your food, children, or no dessert!" > mantra. I like my systems to be local. I program them, I explore them, I sometimes hack on them with software, hardware, or a combination. I occasionally take one of the off line and use it for a program dump, or just to mess with ethernet stuff without impacting my network. I have private files on my system, and lots of works in progress. I sometimes do customer work on my systems (if they permit it), and the data files, simulation files, pattern files (I test SoC devices) can consume up to 20G/device. They don't compress well, due to the size and variety of the data, and I often have device data for 10-12 devices on line at a time. I do not have that all the time, it is "burst work", and consumes trememdous amounts of disk space sometimes for hours, sometimes for days and in a few cases weeks at a time. A 500G disk is about $200, lasts me an average of 3-5 years, with no other costs. The backup is a similar disk, via a plugin usb, firewire, or sometimes mounted. Total cost for supporting 5 years data, $400. A cloud system where I use that much bandwidth, and storage runs about 3500 for the equivalent usage, and some of the things I do would not be permitted by the cloud management for fear I would mess things up, and I occasionally do (have you written bugfree programs of any significant size?) Moreover you pointed out one of the real issues: month to month rental or lease or whatever you want to call it. And that is not counting the connection costs, storage premium if you are a non-standard user, or the lack of control, or the subject to search of the on line data because it falls under different jurisdictions. In addition, the security of encryption on a server system must by design be reduced in class for any given equivalent algorithm on a private system, due to the available resources to hack at it. IT folks love the idea of more control, less diversity in program support and all the other control they can exercise. The guys who make a real difference in IP are cost out of the equation, because they don't fit the parameter of the "average user". In addition the down time becomes universal instead of private. In a time when we are threatened by terrorists, putting your whole organizations software and data in a big "basket in the cloud" seems like a recipe for disaster. And it is a disaster that would make the financial melt down look tame. A single EMP weapon could disable or destroy multiple companies in a signal region. A domino economic effect that could have catastrophic implications. I watched a very good company have a big breakdown when their old server system with dumb terminals went down. The costs, and impacts nearly put them out of business. If they had been smaller it would have. I have no doubt that companies will embrace the cloud. At least until it all comes crashing down around their ears. PC's became dominant precisely because centralized solutions were an inhibiting factor on business, and personal schedules. Some lessons are too soon forgotten. Regards, Les H -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
