1) CompatibleOne: How doesit work?
1st Step: Handling the user's requirements
The user'srequirements are expressed in a service manifest document which describes indetail the services to be delivered, the technical and economical criteria andthe constraints that are to be taken into consideration. The structure of thecontents of this manifest corresponds to the model described by CORDS(CompatibleOne Resource Description System).
2nd Step: Validation and construction of theprovisioning plan
Themanifest is received by the SLAP MASTER allocation engine which initiates thetransactional event management, destined to be used by the accountancy andbilling system. The manifest is then transfered to the CORDS Parser where theXML dexcription will be transformed into a fully qualified and validatedprovisioning plan. The CORDS Parser first checks the syntactical validity ofthe manifest document and then ensures the existance of the appropriateresources for the understanding and expression of the needs as they areexpressed.
3rd Step: Execution of the provisioning plan
Once theplan has been validated, it will be transfered to the CORDS Broker which willbe responsible for the actual provisioning operation requiring the creation ofa control graph for the management of the different components involved in andresulting from the provisioning process. During this operation the CORDS Brokerwill make use of the different CompatibleOne brokering services required tosatisfy the constraints described in the initial manifest, using for example arequest optimisation service.
4th Step : Delivery of the Cloud Services
The CORDSBroker establishes and engages service contracts with each of the individualCloud Providers required for the provision of the different components in acontractual manner.
Thecapacity of these Providers to make available their resources and services isdiscovered by the CORDS Procci through the CORDS Publisher and theannouncements of service performed there by each Provider. Communicationwith the different Providers is performed through client/server interfacesdescribed using the standard OCCI and implemented on the CompatibleOne sidewithin the CORDS Procci and on the Provider side within a Provider specificProcci component. In this way we find a proxy per Provider including theOpenNebula Procci, the OpenStack Procci, an Amazon Procci or a Windows AzureProcci for example. In this way the implementation of a Provider specific proxyis all that is required to be performed in order to make ressources availablefor use within the CompatibleOne provisioning system. A template serverimplementing the different aspects of the OCCI / REST server available ondemand to facilitate this.
The Knowledge Base
Theelements stored in the Knowledge Base are the Manifests, the Plans, theContracts and the Services. A unique and universal identifier is attributed toeach element in the Knowledge Base and may be used to reference the element foruse in subsequent solutions. This can be in the definition of topologiesspecific to certain activities such as clouds for High Performance Computing oras an Internet Service Provider or SaaS Editor.
The Publisher
ACCORDS(Advanced Capabilities for CORDS) is actually the Provisioning System forCompatibleOne. All communication within ACCORDS is performed in conjunctionwith the Publication Service offered by the Publisher, working in tightcoordination with the Security Service COSS (CompatibleOne SecurityService) and using OCCI (Open Cloud Computing Interface) over HTTP (Hyper TextTransfer Protocol). This collection of protocols and specifications constitutesthe cloud middleware or cloudware offered by ACCORDS.
2) Which interfaces forCompatibleOne?
First it seems all CompatibleOne components useREST to communicate. It seems that each “cloud provider” is accessed through anOCCI proxy which is then perhaps translated to the native API (e.g. OpenStack). However the interfaces between the different CompatibleOne components(e.g. publisher, parser or broker) are so far not published on CompatibleOne's web site. Where could we have access to these?
Thisunderstanding of the architecture is exact, the different proxy components, orproccis, in CompatibleOne jargon offer a standard OCCI interface to the genericprocci for the 'negociation' of contract instances over a REST interface. Theinterface has not been published as such, simply because it is a standard OCCIREST interface and the usual OCCI capacity discovery mechanisms are availablefor clients to be able to consult the different server components with respectto their interface categories and their associated actions. Each of theinterface categories will of course be fully documented as theyreach maturity during the project.
3) Can CompatibleOneprovision more than one cloud service?
Is the aim of compatible one is “to be able to deploy anapplication across more than one cloud”, or to only deploy an application in one ofthe possible clouds? Either for the initial deployment or later for life cyclemanagement (e.g. scale up). From the resource description schema, it does not seem thatthis is currently envisaged. But is this in the CompatibleOne roadmap?
Thearchitecture was devised to be as flexible as possible for the description ofcomplex cloud systems. It is intended for a wide range of uses from the simpleprivate corporate infrastructure usage to the fully blown public infrastructurecloud broker. The differences really lie in the way the platform is configuredto behave by the actual operator. A Manifest however may declarethat a node be contractually instanced through a specific cloud provider fortechnical reasons, or it may be left to the broker to decide taking intoconsideration financial, energetic, geographic or operator contractualpreferences. A complete service manifest may describe nodes provisioned bydifferent cloud providers and being "sewn" together by the configurationsection of the manifest.
4) What about the network?
From the point of view of the network, this schemadefines an L2 network. OCCI model is used here. Reading thedocumentation, it is difficult to know if CompatibleOne will use theNetworkLink to create links (routes/firewalls) between created networks.However for now, it seems that what is supported is that a single “network” iscreated and the VMs/storage are deployed within that network. So is it possibleto know more of CompatibleOne road map on this item?
As far asnetworking goes, in the current state of the CompatibleOne platform, the aim isto provide an automatic provisioning system and would indeed appear to target asingle network but in fact, in order that the provisioning may scan multipleand heterogeneous cloud provider platforms, the idea of a single network isvery much ruled out since the different VM's would be within the local networkspace of each provisioner. In such complex cases the CompatibleOne platformaims at provision of the necessary network components, be they simple public IPaddresses or more complex VPN and tunnelling configurations. Devices of thiskind, including routers and firewalls are intended to be described in the sameterms as othe nodes with the concerned Manifest. Symmetry is the aim here, asfar as possible.
5) Who should useCompatibleOne and Why ?
Open cloudhas a strong potential for the catalysis of new ideas and initiatives. CompatibleOne is as such a good example. By establishing the necessaryfoundations for the operators, developers and architects of cloud computing,CompatibleOne facilitates the creation of new services and even newprofessions.
Cloud Operators would be able to useCompatibleOne cloudware to maximize returns in the exploitation of their datacenters in terms of economical, technical and geographical criteria. The CORDSmodel was designed to be usage driven and these operators could eventuallydefine their infrastructures in accordance with their target market be theyprovision of internet services, hosting, on demand HPC and so on and soforth.
A cloud entrepreneur wouldbe able to offer, thanks to CompatibleOne, and in complete independance with respect to the choice of actual operator, services to their clientswith a high added value. It would become possible, for example, to imagine theprovision of a courtier service based on diverse criteria, their professionalorientation (automobile, aeronautics, defense, agriculture, …) or theireconomical constraints (the best cloud services or the best price offered tolocal government for example).
Finally,for a software developer and vendor, CompatibleOne cloudware provides theideal tools for the construction of new and inovative offers of highlycompetitive services compared to those already available. Detailled billing ofservice would be possible allowing examination of actual and real serviceconsummation with an aim to optimisation of the resources required. In additionthese services would be offered in form of SaaS.
6) How does theCompatibleOne ecosystem work?
CompatibleOneis an Open Source project, open to all, the results of which can be freelyreused, modified and distributed. The availability of the entire code base andits documentation under open source license makes possible not only theadoption of this Cloudware but also aims at encouraging participation from newcontributors in order to enrich and enhance the existing code base. CompatibleOne is part of the open source cloudware initiative of OW2(OSCi) aiming to establish and encourage synergy between open source projectsand players in cloud computing area.
CompatibleOne was made possible thanks to the support ofFrench competitiveness clusters Systematic and Solutionsde Communications Sécurisées, FUI (Fonds UniqueInterministériel), Paris Region (Ile de France), Conseil Général des Yvelinesand the Paris Town Hall. To date, the participants and contributors areActiveEon, Bull, CityPassenger, Enovance, Eureva, INRIA, Institut Télécom,Mandriva, Nexedi, Nuxeo, OW2, Prologue, Xwiki. CompatibleOne is open toany newcontributor.
It is alsothe objective of CompatibleOne to provide models, specifications and componentsfor re-use in subsequent projects such as EasiClouds, CloudForce,CloudPort, Magellan, and there by facilitating the development of open sourceindustrial solutions and open cloud computing services in France and Europe.
CompatibleOne will make intensive use of existing openstandards, such as OCCI and intends to contribute also to their specifications.In addition links are established with projects sharing similar goals such asOpenNebula and Contrail.
7) Glossary, Acronyms andAbbreviations
| ACCORDS | Advanced Capabilities for CORDS |
| CORDS | CompatibleOne Resource Description System |
| OCCI | Open Cloud Computing Interface Working Group |
| COSS | CompatibleOne Security Service |
| COES | CompatibleOne Elasticity Services |
| COEES | CompatibleOne Energy Efficiency Services |
| COMONS | CompatibleOne Monitoring Services |
| CONETS | CompatibleOne Network Services |
| COOBAAS | CompatibleOne Ordering, Billing, Accounting Services |
| EZVM | VM Interoperability |
| PAAS4DEV | Runtime OSGI |
| UniData | Data Interoperability |
扫一扫
2083
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
