[Pgi-wg] SIENA and OGF PGI : Useful de facto and official standards for grids and clouds
Etienne URBAH
urbah at lal.in2p3.fr
Thu Mar 10 15:45:25 CST 2011
Martin, Morris, Johannes and all,
Concerning standards for grids and clouds :
I have updated the diagram presenting useful de facto and official
standards for grids and clouds.
In particular, I have added SNIA CDMI, DMTF OVF, and some OGF HPC profiles.
This diagram is open source, and is available at :
- http://forge.gridforum.org/sf/go/doc15990 as PNG file,
- http://forge.gridforum.org/sf/go/doc15977 as ZARGO file editable with
the ArgoUML tool which anybody can download from http://argouml.tigris.org/
I will fix the comment about JSPG as soon as ArgoUML permits it.
Then, I will update my slides accordingly.
Best regards.
-----------------------------------------------------
Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
Bat 200 91898 ORSAY France
Tel: +33 1 64 46 84 87 Skype: etienne.urbah
Mob: +33 6 22 30 53 27 mailto:urbah at lal.in2p3.fr
-----------------------------------------------------
On Mon, 07/03/2011 17:18, Martin Antony Walker wrote:
> Thank you, Etienne. I find this material very helpful in arriving at a
> clear picture. Best regards, - Martin
>
> -----Original Message-----
> From: Etienne URBAH [mailto:urbah at lal.in2p3.fr]
> Sent: Monday, March 07, 2011 5:09 PM
> To: martin.antony.walker at googlemail.com
> Cc: lodygens at lal.in2p3.fr; edgi-na2 at mail.edgi-project.eu
> Subject: Re: [REB-SIENA] Cloud Federation raised by Reuven Cohen - Standards
>
> Martin,
>
> Concerning Cloud Federation and standards :
>
>
> DMTF CIM (Common Information Model)
> ------------------------------------
> For information standardization, DMTF CIM may be considered. In
> particular, it is used by the Japanese NAREGI middleware, as described
> in chapter 2.6.1 of
> http://middleware.naregi.org/Download-v1.1.5/Docs/GD-Overview-e.pdf
>
> But most European Grid stakeholders have agreed on OGF GLUE 2.0 instead.
>
>
> Standards missing from my slides
> --------------------------------
> Yes, my slides at
> http://www.xtremweb-hep.org/IMG/pdf/Standards-For-Distributed-Data-Processin
> g-Infrastructures-DCIs.pdf
> have to be updated.
>
> I know that I have to add references to at least following standards :
>
> - SNIA CDMI : Cloud Data Management Interface
>
> http://www.snia.org/tech_activities/standards/curr_standards/cdmi/CDMI_SNIA_
> Architecture_v1.0.pdf
>
> - DMTF OVF : Open Virtualization Format
>
> http://www.dmtf.org/standards/published_documents/DSP0243_1.1.0.pdf
>
> - OGF http://www.ogf.org/documents/
> GFD.111 : JSDL HPC Profile Application Extension
> GFD.115 : JSDL SPMD Application Extension
> GFD.151 : HPC-BP Advanced Filter Extension
> GFD.174 : Data Format Description Language (DFDL)
>
> I hope to update the source diagram and the slides very quickly.
>
>
> Best regards.
>
> -----------------------------------------------------
> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
> Bat 200 91898 ORSAY France
> Tel: +33 1 64 46 84 87 Skype: etienne.urbah
> Mob: +33 6 22 30 53 27 mailto:urbah at lal.in2p3.fr
> -----------------------------------------------------
>
>
> On Mon, 07/03/2011 10:21, Martin Antony Walker wrote:
>> Etienne, thanks again for the slides. They are very clear. I have boiled
>> down the content to one and a half pages for myself. I have a question
> and
>> a remark. Why is the DMTF CIM schema not considered for information
>> standardization? The remark is that I miss CDMI and OVF among the
> available
>> standards - and I guess there are others. Best regards, - Martin
>>
>>
>> -----Original Message-----
>> From: Etienne URBAH [mailto:urbah at lal.in2p3.fr]
>> Sent: Friday, March 04, 2011 4:50 PM
>> To: martin.antony.walker at googlemail.com
>> Cc: Morris RIEDEL; david.wallom at oerc.ox.ac.uk; REB at sienainitiative.eu;
>> lodygens at lal.in2p3.fr; edgi-na2 at mail.edgi-project.eu
>> Subject: Re: [REB-SIENA] Cloud Federation raised by Reuven Cohen
>>
>> Martin,
>>
>> Concerning Cloud Federation, I fully agree with Reuven Cohen.
>>
>> The good news is that federations of data processing resources already
>> exist, and run in full production : they are called Computing Grids.
>>
>> For a presentation about the issues and solutions for a Cloud
>> Federation, you can take a look at my 'Standards for Distributed Data
>> Processing Infrastructures (DCIs)' presentation at
>>
> http://www.xtremweb-hep.org/IMG/pdf/Standards-For-Distributed-Data-Processin
>> g-Infrastructures-DCIs.pdf
>>
>> Acknowledgments to :
>> - Morris Riedel for the diagram in my slide number 27.
>> - David Wallom for the diagrams showing dependencies between OGF
>> recommendations which he presented at the 6th E-infrastructure
>> Concertation Meeting in Lyon on 24 November 2008.
>>
>> Professionalism and Engineering pay in the long term.
>>
>> Best regards.
>>
>> -----------------------------------------------------
>> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
>> Bat 200 91898 ORSAY France
>> Tel: +33 1 64 46 84 87 Skype: etienne.urbah
>> Mob: +33 6 22 30 53 27 mailto:urbah at lal.in2p3.fr
>> -----------------------------------------------------
>>
>>
>> On Fri, 04/03/2011 15:55, Martin Antony Walker wrote:
>>> FYI – you might have seen SpotCloud getting positive mention in a
>>> recent issue of The Economist. Best regards, - Martin
>>>
>>> *From:*noreply+feedproxy at google.com
>>> [mailto:noreply+feedproxy at google.com] *On Behalf Of *ElasticVapor - Life
>>> in the cloud
>>> *Sent:* Friday, March 04, 2011 3:08 PM
>>> *To:* martin.antony.walker at gmail.com
>>> *Subject:* ElasticVapor : Living on the Edge
>>>
>>>
>>> ElasticVapor : Living on the Edge<http://www.elasticvapor.com/>
>>> Image removed by sender.
>>>
>>
> <http://fusion.google.com/add?source=atgs&feedurl=http://feeds.feedburner.co
>> m/Elasticvapor>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *Living on the Edge*
>>>
>>
> <http://feedproxy.google.com/~r/Elasticvapor/~3/cNO_4CUnSnA/living-on-edge.h
>> tml?utm_source=feedburner&utm_medium=email>
>>>
>>>
>>> Posted: 03 Mar 2011 01:04 PM PST
>>>
>>> There's somethin' wrong with the cloud today, I think I know what it is.
>>> We're seeing things in a different way, but should we be judging a cloud
>>> provider by the color of their -- logo?
>>>
>>> It's seems that for many, the only basis of comparing cloud providers is
>>> based upon superficial aspects. I know of the company, recognize the
>>> logo, or read a random review. But the reality is we're moving away from
>>> the traditional vendor driven marketing fluff of a single provider world
>>> to a multi-cloud, federated ecosystem of capacity providers, where brand
>>> recognition is less important than performance and price. I'm talking
>>> about living on the edge, the edge of the network.
>>>
>>> One of the more interesting recent announcements was *Amazon's Japan
>>> availability zone*
>>> <http://aws.typepad.com/aws/2011/03/now-open-aws-region-in-tokyo.html>,
>>> in describing their launch AWS spoke of latency for users within Tokyo
>>> being less than 10ms. Hitting directly at the heart of the opportunity.
>>> Yet on the flip side, they also mentioned that the Japanese zone was
>>> ideal for other nearby geographies, to which I say they're missing the
>>> point. Using Japanese resources in South Korea makes little sense given
>>> the rapid advancement and availability of cloud capacity in South Korea.
>>> The opportunity going forward isn't to address generalized areas of the
>>> world, but to address the specifics, not just on a country basis but on
>>> a city or even a neighbourhood basis. A single provider will never be
>>> able to get this level of granularity regardless of how much money they
>>> have. Economies of scale will always be limited by total market size,
>>> the more granular the market the less economies of scale work in favor
>>> the large provider. The only way to address this growing movement toward
>>> edge based, latency dependent application deployment is to federate many
>>> providers with many customers across many diverse geographies.
>>>
>>> I admit that this is easier said than done, ask anyone who's attempted
>>> to use more than one provider in a federated, intercloud connection
>>> global cloud of clouds type of deployment and tell me what you think
>>> about your sit-u-a-tion. They'll tell you it's complication, and
>>> aggravation.
>>>
>>> I know a few of you will point back to the inevitable economies of scale
>>> that an AWS or Google bring forth. Yes, they probably spent many
>>> millions building their Japanese cloud infrastructure. But did they have
>>> to? Economies of scale are important factors mostly for true for
>>> commoditized IT aspects such as bandwidth. But for areas such as
>>> ultra-localization computing, this is not practical for even the largest
>>> web companies. Sure there are many factors that cause a cloud providers
>>> average cost per compute unit to fall as the scale of output is
>>> increased, purchasing power is probably the most relevant. Essentially
>>> the biggest Internet companies can buy the most servers at a massive
>>> volume thus getting the lowest cost per unit of compute time and
>>> therefore achieving the best margins at the lowest cost. But even this
>>> equation has a practical limit when it comes to geography.
>>>
>>> When it comes to ultra-localization the boundaries of the so-called
>>> provider economies of scale, commoditiziation and volume quickly
>>> breakdown. Now it becomes a question of federation and aggregation. Many
>>> providers connected through a normalized or structured market interface
>>> rather then one provider attempting to address all markets. I'm not just
>>> talking about what we're doing with *SpotCloud*
>>> <http://www.spotcloud.com/>, but what I believe to be the move toward a
>>> market centric economy of federated cloud ecosystems, a move I think is
>>> inevitable. Ultra-local capacity or edge based computing, or whatever
>>> you chose to call it in a nutshell is the opportunity moving forward.
>>>
>>> The choice will quickly become one of choosing a single provider (one to
>>> many) or an aggregator (many to many). I believe the choice will quickly
>>> become obvious to anyone who has a geographic component to their
>>> applications. The opportunity is living on the edge.
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *Announcing The Enomaly Cloud Service Provider Edition*
>>> <http://www.enomaly.com> | *Twitter Me*<http://www.twitter.com/ruv> |
>>> *Get Linkedin*<http://www.linkedin.com/in/reuvencohen> | *Contact
>>> Reuven*<https://cloudcomputing.wufoo.com/forms/contact-reuven/> |
>>> *Disclosure Policy*
>>> <http://www.elasticvapor.com/2009/05/elasticvapor-disclosure-policy.html>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Image removed by sender.
>>>
>>> *Image removed by sender.*
>>>
>>
> <http://feeds.feedburner.com/~ff/Elasticvapor?a=cNO_4CUnSnA:_YDXnI4P0Ck:4cEx
>> 4HpKnUU>*Image
>>> removed by sender.*
>>>
>>
> <http://feeds.feedburner.com/~ff/Elasticvapor?a=cNO_4CUnSnA:_YDXnI4P0Ck:yIl2
>> AUoC8zA>*Image
>>> removed by sender.*
>>>
>>
> <http://feeds.feedburner.com/~ff/Elasticvapor?a=cNO_4CUnSnA:_YDXnI4P0Ck:qj6I
>> DK7rITs>*Image
>>> removed by sender.*
>>>
>>
> <http://feeds.feedburner.com/~ff/Elasticvapor?a=cNO_4CUnSnA:_YDXnI4P0Ck:V_sG
>> LiPBpWU>*Image
>>> removed by sender.*
>>>
>>
> <http://feeds.feedburner.com/~ff/Elasticvapor?a=cNO_4CUnSnA:_YDXnI4P0Ck:F7zB
>> nMyn0Lo>*Image
>>> removed by sender.*
>>>
>>
> <http://feeds.feedburner.com/~ff/Elasticvapor?a=cNO_4CUnSnA:_YDXnI4P0Ck:-BTj
>> WOF_DHI>
>>>
>>> Image removed by sender.
>>>
>>> You are subscribed to email updates from ElasticVapor - Life in the
>>> cloud<http://www.elasticvapor.com/>
>>> To stop receiving these emails, you may unsubscribe now
>>>
>>
> <http://feedburner.google.com/fb/a/mailunsubscribe?k=petIEsZUdsZ3VYU95tUROl7
>> iW6A>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5073 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20110310/d6b3a2be/attachment.bin
More information about the Pgi-wg
mailing list