Mening gevraagd mbt Cloud Computing Management Framework

**Kreft** · 23/07/09 15:36

Beste WHT'ers,

Bij deze had ik graag even jullie mening gevraagd. Samen met enkele collega's ben ik aan het werken aan een Cloud Computing Management Framework. Een zeer abstracte term, I know, maar sta me even toe een woordje uitleg te geven.

Situering

Het wordt een modulair management framework voor cloud computing, onafhankelijk van de onderliggende virtualisatietechnologieen, storagetechnologieen,... Welk tot doel heeft om het beheer van cloudomgevingen drastisch te vereenvoudigen en te automatiseren, maar ook ondersteuning wil bieden aan zo veel mogelijk (per definitie in principe oneindig) technologieen die door elkaar kunnen gebruikt worden zonder dat dit extra werk, problemen of downtime toebrengt aan de cloud.

Zo zal het mogelijk zijn om binnen 1 cloud meerdere virtualisatietechnologieen (Xen, VBox, VMware,...) te gaan gebruiken zonder dat dit voor de management layer enig verschil maakt. Dit laat toe om zonder enig probleem met verschillende technologieen te gaan testen, of er gewoon meerdere door elkaar te gaan gebruiken (om welke reden dan ook) zonder dat hiervoor drastische veranderingen moeten doorgevoerd worden. Aan de hand van modules in het framework kunnen de verschillende virtualisatietechnologieen er gewoon aangehangen worden.

Hetzelfde geldt uiteraard voor storagetechnologieen. Of er nu geopteerd wordt voor LVM of diskimages of ... maakt op zich weinig uit. Dit kan perfect voor elke VM iets anders zijn. Het framework vangt de boel op en zorgt dat het nodige gedaan wordt. Ook voor de transferprotocollen is dit van toepassing, zo kan de ene storageserver zijn data aanleveren over iSCSI, de andere over NFS,... Op zich maakt het weinig uit, zolang het framework de technologie ondersteund is hier geen probleem.

Alle technologieen worden uiteraard ontwikkeld als modules en de klant kan zelf zijn selectie maken welke hij nodig heeft, alsook er later altijd toevoegen. Ook is het natuurlijk altijd mogelijk om een specifieke technologie op vraag van de klant te gaan ondersteunen en hiervoor een module te ontwikkelen.

Dit alles resulteert uiteindelijk (geabstraheerd) in 2 API's. Eentje die alle managementtaken ter beschikking stelt, deze zal door ons ook aan een cpanel gekoppeld worden maar dit hoeft niet gebruikt te worden. Aan de hand van de API kunnen deze functies gerust verwerkt worden in bestaande softwarepakketten. De tweede API voorziet in alle functionaliteit voor de eindgebruiker waarboven dan en een cpanel moet gaan hangen naar de eindgebruiker toe. Ook hier zullen wij een eigen cpanel voorzien maar ook dit is geen verplichting.

Verder zullen ook de nodige voorzieningen aanwezig zijn voor geautomatiseerde high-availability, klantenbeheer, facturatie en boekhouding,... Om zo uiteindelijk te komen tot een totaalpakket waar de klant enkel nog hardware en licenties van non-free software moet voorzien om van start te kunnen gaan. Zonder twijfel zullen wij de klant van begin tot eind bijstaan met het nodige advies bij de te kiezen technologieen, hardware, het opzetten van de cloud,...

Ik ga niet verder in detail treden, het zou me namelijk veel te ver leiden. Hetgeen momenteel bij ons uitgeschetst staat is behoorlijk geavanceerd, dit betreft vooral de management features. Als ik hier volledig in detail moet op ingaan ben ik vermoedelijk morgenochten nog aan het typen. Ik hoop dat het algemeen concept ongeveer duidelijk is, daar draait het momenteel immers om. Mocht dat niet het geval zijn dan antwoord ik met plezier op verdere vragen.

Eigenlijke vraag

Er is al heel wat onderzoek gebeurd, maar alvorens als gekken te gaan beginnen programmeren wouden wij toch even rustig de tijd nemen voor een "marktonderzoekje" en even te luisteren wat de doelgroep van ons product ervan denkt en welke dingen zij (as in jullie) hier graag in zouden zien zitten.

Bij deze dus de vraag om even te laten horen wat jullie hiervan denken, of dergelijk product voor jullie interesant zou zijn en of jullie effectief ook geinteresseerd zouden zijn om dit in gebruik te nemen mocht het op de markt komen. Ook zijn alle opmerkingen altijd welkom alsook zaken die jullie hier zeker in zouden willen zien.

Deze vraag komt van mensen met serieuze bedoelingen, bijgevolg zou het ook geapprecieerd worden om enkel serieuze antwoorden te ontvangen. Mocht er iets nog niet duidelijk zijn, stel gerust verdere vragen. Alvast bedankt.

**Kreft** · 24/07/09 09:53

Echt niemand die hier iets op aan te brengen heeft..?

**DutchTSE** · 24/07/09 10:05

Het 1e dat in mij op komt is "dat product zal niet te betalen zijn".
Wij doen verder weinig/niets met CC dus kan er inhoudelijk niet helemaal op in gaan.

**_Lamp_** · 24/07/09 10:11

Het idee klinkt goed voor als je met omgevingen bezig bent welke meerdere virtualisatietechnieken door elkaar wilt gebruiken. En dit zou nog tijdens testen handig kunnen zijn. Echter zal in de meeste gevallen zul je geen meerdere virtualisatie technieken door elkaar gebruiken. Na een test periode zal je voor een bepaalde leverancier een keuze maken. Daarna overstappen kan, maar is meestal een lang en kostbaar traject.
Daarnaast zul je ook altijd toch kennis moeten opbouwen van de beheerstools welke door de leverancier geleverd worden. Indien je support nodig heb zal de leverancier eisen dat met foutmeldingen/test resultaten welke gegeven worden door hun eigen tools.
Ook trainingen en certificeringen door de leverancier zullen gedaan worden met hun eigen tools. Na een training en certificering zal de eindgebruiker nog een training moeten doorgaan voor jullie applicatie.

Een koppeling naar klantenbeheer, facturatie en boekhouding,... kan wel intressant zijn.

Ik persoonlijk zou dus meer zien in een schil om bestaande tools van leveranciers, aangevult met extra koppelingen voor koppeling naar klantenbeheer, facturatie en boekhouding. Deze schil kan ook taken uitvoeren welke normaal in de tooling van de leverancier gedaan kan worden, via de API's van die tooling. Op deze manier kun je de tooling van de leverancier blijven gebruiken welke gesupport is en kun je toch meerwaarde leveren door de koppeling naar facturatie, klantbeheer en boekhouding.

**Kreft** · 24/07/09 16:28

Zowiezo wordt er gebouwd bovenop de API's of configuratietools die voorzien worden door de leverancier van de desbetreffende virtualisatietechniek. De modules voor ons framework per virtualisatietechniek moeten gewoon de API van de techniek porten naar de abstracte API die voorzien wordt door ons framework.

Om er zo voor te zorgen dat het framework steeds dezelfde instructies kan geven ongeacht de virtualisatietechniek. De tussenliggende module is immers verantwoordelijk om er voor te zorgen dat die instructie omgezet wordt naar de passende instructie van de techniek.

Zo zou de gebruiker van ons framework op zich geen gedetailleerde kennis moeten hebben van de virtualisatietechniek, maar enkel met ons framework overweg moeten kunnen. OK, kennis over de gebruikte technieken is altijd wel in zeker zin nodig en komt de reactiesnelheid in geval van problemen natuurlijk alleen maar ten goede.

Tot op heden hebben wij enkel diepgaand geexperimenteerd met Xen en VirtualBox. Deze technieken zijn op zich behoorlijk eenvoudig op vlak van beheer, en het zou echt niet nodig zijn om getraind te zijn in het gebruik van deze pakketten om deze via ons framework te gaan deployen. Alles wordt mooi afgehandeld door het framework, het is enkel nodig om hier mee overweg te kunnen, maar het is niet onze bedoeling om dit onnodig ingewikkeld te gaan maken..

Oorspronkelijk geplaatst door _Lamp_

Ik persoonlijk zou dus meer zien in een schil om bestaande tools van leveranciers, aangevult met extra koppelingen voor koppeling naar klantenbeheer, facturatie en boekhouding. Deze schil kan ook taken uitvoeren welke normaal in de tooling van de leverancier gedaan kan worden, via de API's van die tooling. Op deze manier kun je de tooling van de leverancier blijven gebruiken welke gesupport is en kun je toch meerwaarde leveren door de koppeling naar facturatie, klantbeheer en boekhouding.

Dit is een mooie omschrijving van wat eigenlijk de bedoeling is hoor.. Het is misschien niet goed overgekomen. Zoals gezegd bouwen wij verder op de API's en tools die voorzien zijn, het zou wat nutteloos zijn om het warm water opnieuw te gaan uitvinden. (tenzij bepaalde tools veel te veel overhead met zich meesleuren.. efficientie is ook nog wel belangrijk)

Maar zoals gezegd, bovenop de functionaliteit die in de API's en tools van de virtualisatietechnieken te vinden zijn willen wij nog heel wat extra functionaliteit aanbrengen. Zaken zoals cluster control, advanced high availability,... en natuurlijk ook het gehele klantensysteem inclusief facturatie en boekhouding.

De voornaamste reden waarom we meerdere technologieen willen gaan ondersteunen is omdat we het gewoonweg zonde vinden om dergelijk stuk software te gaan schrijven voor slechts 1 technologie. En leuk extraatje is dan natuurlijk dat er meerdere technologieen door elkaar kunnen worden gebruikt zonder dat dit voor het framework enig verschil maakt. Switchen van de een naar de ander is op zich ook geen erg, zolang dezelfde diskimages (of lv's of...) maar kunnen gebruikt worden. Anders is dat dus niet zomaar te fixen..

**frankske** · 24/07/09 18:34

Heb je een idee wat de kost per server zou zijn? Er is een pak soft op de markt. Maar geen enkele waarvoor ik zou betalen. Het is ofwel te duur ofwel niet goed genoeg

**Kreft** · 26/07/09 09:53

Het is helaas nog wat vroeg om kostprijzen te gaan noemen. Maar je zal er kunnen op rekenen dat elke euro die ervoor gerekend wordt de software en service meer dan waard zal zijn en dat dit een eerlijke, aanvaardbare en betaalbaar bedrag zal betreffen.

In ieder geval, low-budget zal het niet zijn.. Ik denk ,gezien de aard van de software en het belang dat deze kan hebben binnen de dienstverlening van een bedrijf, dat dit voor geen van de partijen een goed idee zou zijn.

Nu, over de kostprijs maak ik mij niet meteen druk, ik ben er van overtuigd dat wij dit product kunnen gaan leveren tegen een zeer correcte prijs. Het is in eerste instantie om de vraag/interesse na te gaan dat ik hier even te rade kwam. Maar dan ook het "niet goed genoeg" gedeelte, hoofdzakelijk om even te horen wat de bedrijven binnen onze doelgroep hier graag van features wensen.

En ik heb het dan niet alleen over de standaard zaken, maar ook custom, geavanceerde en diepergaande features dan enkel de core. Wij hebben zelf al een featurelijstje opgesteld van dingen die wij hierbij nuttig achten. Maar dit is dan voor ons specifiek, ik ben ervan overtuigd dat sommigen hier wel graag nog iets aan toegevoegd zouden zien.

**lmp** · 27/07/09 14:30

Oorspronkelijk geplaatst door Kreft

Zowiezo wordt er gebouwd bovenop de API's of configuratietools die voorzien worden door de leverancier van de desbetreffende virtualisatietechniek. De modules voor ons framework per virtualisatietechniek moeten gewoon de API van de techniek porten naar de abstracte API die voorzien wordt door ons framework.

Om er zo voor te zorgen dat het framework steeds dezelfde instructies kan geven ongeacht de virtualisatietechniek. De tussenliggende module is immers verantwoordelijk om er voor te zorgen dat die instructie omgezet wordt naar de passende instructie van de techniek.

Dit kan zolang beide virtualisatie technieken de zelfde functionaliteiten bieden. Als er een meer aanbied of net iets anders kan ook dit lastig worden. Denk hierbij aan Thin provisioning of Fault Tolerance. Nog niet veel virtualisatie ondersteunen deze voorbeelden.

Oorspronkelijk geplaatst door Kreft

Zo zou de gebruiker van ons framework op zich geen gedetailleerde kennis moeten hebben van de virtualisatietechniek, maar enkel met ons framework overweg moeten kunnen. OK, kennis over de gebruikte technieken is altijd wel in zeker zin nodig en komt de reactiesnelheid in geval van problemen natuurlijk alleen maar ten goede.

Als je HA of DRS wilt gebruiken van VMware, dan zul je toch de hele tool set van VMware moeten gebruiken om dit voor elkaar te krijgen. De tool set die dan gebruikt wordt, is ook meteen je management tool voor VMware. Dit bedoel ik met dat je alsnog kennis moet hebben van de tool set welke door de leverancier geleverd wordt.
Ga je daarnaast ook de addons voor die specifieke leverancier ondersteunen? Als voorbeeld neem ik hier de vmware update manager. Software om je host machines en je virtuele machines up2date te houden (clients voor zover ondersteunt). Dit wordt standaard vanuit de management tools van vmware aangeboden. Ga je dit vanuit het framework ook ondersteunen en hoe ga je dan met andere virtualisatie leveranciers om die dit niet hebben?

Oorspronkelijk geplaatst door Kreft

De voornaamste reden waarom we meerdere technologieen willen gaan ondersteunen is omdat we het gewoonweg zonde vinden om dergelijk stuk software te gaan schrijven voor slechts 1 technologie. En leuk extraatje is dan natuurlijk dat er meerdere technologieen door elkaar kunnen worden gebruikt zonder dat dit voor het framework enig verschil maakt. Switchen van de een naar de ander is op zich ook geen erg, zolang dezelfde diskimages (of lv's of...) maar kunnen gebruikt worden. Anders is dat dus niet zomaar te fixen..

En zolang de software de installatie van drivers meteen ondersteunt. Een Virtuele machine uit XEN overzetten naar VMware is meer dan alleen een disk overzetten. Beide emuleren andere hardware en zal dus ook verschillende drivers binnen de client eisen.
Het zal dus meer dan alleen zijn dan een virtuele machine onder product A stoppen en onder product B weer starten.

Ik denk dat het framework een prachtig product kan worden zolang de basis van alle virtualisatie software leveranciers gebruikt wordt: het draaien van virtuele machine. En dit kan al een uitdaging worden als je virtuele machines wil laten jumpen tussen de omgevingen.
Als je in het framework ook wil verwerken dat de uitgebreidere functies van elke leverancier gebruikt kan gan worden (HA, DRS, VMotion, Fault Tolerance, ....) dan kan het naar mijn mening al een hell worden om dat goed te krijgen. Mocht je deze opties/functies gaan gebruiken, heb je meestal al voor een specifieke leverancier gekozen incl de management tools.

* Ik noem alle naampjes van VMware, omdat ik als VCP het beste thuis ben in VMware.

**Kreft** · 27/07/09 16:59