Difference between revisions of "BigGrid virtualisatie/notulen 20090706"

From BioAssist
Jump to: navigation, search
(Oorspronkelijke versie van Sander Klous)
 
 
(3 intermediate revisions by one other user not shown)
Line 16: Line 16:
 
#* Volgende vergadering
 
#* Volgende vergadering
  
 +
== Notulen ==
 
;Datum: 6 juli 2009
 
;Datum: 6 juli 2009
;Aanwezig: Marc, Pieter, Floris, Ronald, Sander
+
;Aanwezig: Marc (MvD), Pieter (PvB), Floris (FS), Ronald (RS), Sander (SK)
;Afgemeld: Ron
+
;Afgemeld: Ron (RT)
  
Uit de introductie zijn een aantal zaken naar voren gekomen.
+
Sander doet verslag van de virtualisatie-workshop bij CERN d.d. 24–26 juli. In dit verslag komen de volgende zaken aan de orde:
# Het naieve idee dat VMs voor extra veiligheid zorgen omdat de gebruikers binnen een VM 'gevangen zitten' is onjuist. VMs veroorzaken extra security risks omdat er veel relatief nieuwe software wordt geintroduceerd (hypervisor, network bridges, paravirtual drivers, VM management, etc.) met bijkomende exploits.
+
# SK: Het idee dat VMs voor extra veiligheid zorgen omdat de gebruikers binnen een VM 'gevangen zitten' was volgens sommige aanwezigen naïef: VMs zouden extra security risks veroorzaken omdat er veel relatief nieuwe software wordt geintroduceerd (hypervisor, network bridges, paravirtual drivers, VM management, etc.) met bijkomende exploits.
# Bij het gebruik van VMs op de worker nodes kan onderscheid worden gemaakt tussen drie categorieen.
+
# SK: Bij het gebruik van VMs op de worker nodes kan onderscheid worden gemaakt tussen drie categorieen.
 
#;Class 1: site generated VMs, trusted by site
 
#;Class 1: site generated VMs, trusted by site
 
#;Class 2: VO generated VMs, trust based on certification and policy
 
#;Class 2: VO generated VMs, trust based on certification and policy
 
#;Class 3: User generated VMs, untrusted
 
#;Class 3: User generated VMs, untrusted
# Het managen en schedulen van VMs is gecompliceerd.
+
# SK: Het managen en schedulen van VMs is gecompliceerd.
#* Men wil kunnen kiezen uit verschillende soorten VMs. Hoe worden die beheerd?
+
#* De beheerders op de CERN workshop wilden kunnen kiezen uit verschillende soorten VMs. Hoe worden die beheerd?
#* Het schedulen van VMs moet worden geintegreerd met de huidige job scheduling.
+
#* Het CERN wil dat het schedulen van VMs geintegreerd is met de huidige job scheduling.
 +
# PvB: er waren bij CERN uitsluitend HEP-gebruikers; de belangen van niet-HEP gebruikers niet zijn meegenomen. SK: ontkent dit
  
 
Tijdens de discussie over de scope van de werkgroep werden een aantal punten gemaakt.
 
Tijdens de discussie over de scope van de werkgroep werden een aantal punten gemaakt.
* Sites zien voordeel in het gebruik van Class 1 VMs maar hebben ernstige twijfels over Class 2 en 3 VMs. Er is een IP adres probleem voor Class 1 dat moet worden opgelost als het aantal adressen met ongeveer een factor 10 toeneemt (NAT/private addresses). Er zijn policy en security issues die moeten worden opgelost voordat het gebruik van Class 2 en/of 3 kan worden toegestaan.
+
* SK+RS: Het Nikhef ziet voordeel in het gebruik van Class 1 VMs maar heeft ernstige twijfels over Class 2 en 3 VMs. Er is een IP adres probleem voor Class 1 dat moet worden opgelost als het aantal adressen met ongeveer een factor 10 toeneemt (NAT/private addresses). Er zijn policy en security issues die moeten worden opgelost voordat het gebruik van Class 2 en/of 3 kan worden toegestaan.
* HEP heeft voorkeur voor het gebruik van Class 2 VMs. Ten eerste omdat HEP VOs vaak gemeenschappelijke software draaien, die prima in een VO generated VM beschikbaar kan worden gemaakt. Ten tweede omdat ze de kans groter achten voor Class 2 VMs dat oplossingen kunnen worden gevonden voor de policy en security issues dan voor Class 3 VMs.
+
* SK: HEP heeft voorkeur voor het gebruik van Class 2 VMs. Ten eerste omdat HEP VOs vaak gemeenschappelijke software draaien, die prima in een VO generated VM beschikbaar kan worden gemaakt. Ten tweede omdat ze de kans groter achten voor Class 2 VMs dat oplossingen kunnen worden gevonden voor de policy en security issues dan voor Class 3 VMs.
* Other sciences hebben voorkeur voor het gebruik van Class 3 VMs. Zij geven aan dat er voor hun geen winst zit in het gebruik van Class 2 VMs. Individuele gebruikers draaien allemaal hun eigen software op verschillende platforms en willen de mogelijkheid hebben om die specifieke combinaties te gebruiken op de sites. Zij geven aan dat het nog onduidelijk is of policy en security issues echt gecompliceerder zijn voor Class 3 VMs.
+
* MvD+PvB+FS: niet-HEP heeft voorkeur voor het gebruik van Class 3 VMs; er is voor hun geen winst in het gebruik van Class 1 of Class 2 VMs. Individuele gebruikers draaien allemaal hun eigen software op verschillende platforms en willen de mogelijkheid hebben om die specifieke combinaties te gebruiken op de sites. Zij geven aan dat het nog onduidelijk is of policy en security issues echt gecompliceerder zijn voor Class 3 VMs.
 +
* PvB: Uitgangspunt moet zijn wat nuttig is voor gebruikers. Indien nodig moeten security policies en wetten daarop worden aangepast.
 +
* MvD+PvB: Binnen het kader van BigGrid gaat het erom dat we iets goeds maken voor eindgebruikers. Class 1 VMs zijn een interne beheers-aangelegenheid; sites kunnen zelf beslissen of ze hun gLite WN's in fysieke of virtuele machines draaien. Dat valt buiten de scope van BigGrid, of in ieder geval van deze werkgroep. Het interessants voor gebruikers is duidelijk de Class 3 VM, en dat is waar we ons op moeten richten.
 +
* PvB: Class 2 VM's zijn buiten HEP niet "viable": De niet-HEP VO's zijn puur administratieve entiteiten, zonder de resources om, in overleg met sites en gebruikers, VMs te bouwen en te laten certificeren. PvB betwijfelt zelfs dat dit voor HEP-VO's een werkbare oplossing is.
  
 
Er volgt een technische discussie over het schedulen van de VMs.
 
Er volgt een technische discussie over het schedulen van de VMs.
* Pieter geeft aan dat er voorkeur is voor een systeem waarbij het opstarten van VMs niet automatisch leidt tot het draaien van een job. Ook wil hij een aparte VM scheduler die veel eenvoudiger toegankelijk is dan de huidige job scheduling user interface. Sander geeft aan dat er al implementaties zijn (Haizea) die via de huidige scheduler de mogelijkheid bieden om VMs te schedulen zonder het draaien van een job, de user interface zal dan echter niet veranderen. Ook zijn er mogelijkheden (DESY/INFN) om jobs automatisch in VMs te laten draaien. Dat laatste mechanisme voldoet echter niet aan de gewenste scheiding tussen VMs en jobs.
+
* PvB heeft voorkeur voor een systeem waarbij het opstarten van VMs en het draaien van gLite jobs verschillende dingen zijn: nieuwe, non-HEP gebruikers kunnen via een Amazon-achtige web-interface (en RESTful web-service) VMs draaien op het Grid. Legacy gebruikers (HEP) kunnen jobs blijven inschieten in de gLite WMS. De WMS zal dan, indien nodig, gLite workernode VMs opstarten op het Grid (via bovengenoemde aparte interface) en vervolgens op die gLite nodes de jobs doen uitvoeren.
 +
* SK: er zijn al implementaties (Haizea) die via de huidige scheduler de mogelijkheid bieden om VMs te schedulen zonder het draaien van een job, de user interface zal dan echter niet veranderen. Ook zijn er mogelijkheden (DESY/INFN) om jobs automatisch in VMs te laten draaien. Dat laatste mechanisme voldoet echter niet aan de gewenste scheiding tussen VMs en jobs.
  
 
Om vooruitgang te boeken zijn de volgende actiepunten gedefinieerd.
 
Om vooruitgang te boeken zijn de volgende actiepunten gedefinieerd.
Line 46: Line 52:
  
 
;Volgende vergadering: dinsdag 18 augustus 15:00 -- Floris zal ook weer aanwezig zijn
 
;Volgende vergadering: dinsdag 18 augustus 15:00 -- Floris zal ook weer aanwezig zijn
 +
 +
[[Category:BiGGrid / Agendas and Minutes]]

Latest revision as of 09:40, 5 November 2010

Agenda

  1. Introductie
  2. Verzamelen Use Cases.
    • Welke vakgebieden?
    • Hoe (methode)?
    • Wie (mensen)?
  3. Externe initiatieven
    • Virtualisatie (CERNVM, KVM, VMWare, Xen).
    • Cloud computing (Nimbus, Eucalyptus, OpenNebula).
    • Cloud/Grid integratie (Desy, Karlsruhe, INFN, CERN-VMO).
  4. Security and Operations
    • Public versus private network.
    • Classificatie van Virtual Machines.
  5. AOB
    • Volgende vergadering

Notulen

Datum
6 juli 2009
Aanwezig
Marc (MvD), Pieter (PvB), Floris (FS), Ronald (RS), Sander (SK)
Afgemeld
Ron (RT)

Sander doet verslag van de virtualisatie-workshop bij CERN d.d. 24–26 juli. In dit verslag komen de volgende zaken aan de orde:

  1. SK: Het idee dat VMs voor extra veiligheid zorgen omdat de gebruikers binnen een VM 'gevangen zitten' was volgens sommige aanwezigen naïef: VMs zouden extra security risks veroorzaken omdat er veel relatief nieuwe software wordt geintroduceerd (hypervisor, network bridges, paravirtual drivers, VM management, etc.) met bijkomende exploits.
  2. SK: Bij het gebruik van VMs op de worker nodes kan onderscheid worden gemaakt tussen drie categorieen.
    Class 1
    site generated VMs, trusted by site
    Class 2
    VO generated VMs, trust based on certification and policy
    Class 3
    User generated VMs, untrusted
  3. SK: Het managen en schedulen van VMs is gecompliceerd.
    • De beheerders op de CERN workshop wilden kunnen kiezen uit verschillende soorten VMs. Hoe worden die beheerd?
    • Het CERN wil dat het schedulen van VMs geintegreerd is met de huidige job scheduling.
  4. PvB: er waren bij CERN uitsluitend HEP-gebruikers; de belangen van niet-HEP gebruikers niet zijn meegenomen. SK: ontkent dit

Tijdens de discussie over de scope van de werkgroep werden een aantal punten gemaakt.

  • SK+RS: Het Nikhef ziet voordeel in het gebruik van Class 1 VMs maar heeft ernstige twijfels over Class 2 en 3 VMs. Er is een IP adres probleem voor Class 1 dat moet worden opgelost als het aantal adressen met ongeveer een factor 10 toeneemt (NAT/private addresses). Er zijn policy en security issues die moeten worden opgelost voordat het gebruik van Class 2 en/of 3 kan worden toegestaan.
  • SK: HEP heeft voorkeur voor het gebruik van Class 2 VMs. Ten eerste omdat HEP VOs vaak gemeenschappelijke software draaien, die prima in een VO generated VM beschikbaar kan worden gemaakt. Ten tweede omdat ze de kans groter achten voor Class 2 VMs dat oplossingen kunnen worden gevonden voor de policy en security issues dan voor Class 3 VMs.
  • MvD+PvB+FS: niet-HEP heeft voorkeur voor het gebruik van Class 3 VMs; er is voor hun geen winst in het gebruik van Class 1 of Class 2 VMs. Individuele gebruikers draaien allemaal hun eigen software op verschillende platforms en willen de mogelijkheid hebben om die specifieke combinaties te gebruiken op de sites. Zij geven aan dat het nog onduidelijk is of policy en security issues echt gecompliceerder zijn voor Class 3 VMs.
  • PvB: Uitgangspunt moet zijn wat nuttig is voor gebruikers. Indien nodig moeten security policies en wetten daarop worden aangepast.
  • MvD+PvB: Binnen het kader van BigGrid gaat het erom dat we iets goeds maken voor eindgebruikers. Class 1 VMs zijn een interne beheers-aangelegenheid; sites kunnen zelf beslissen of ze hun gLite WN's in fysieke of virtuele machines draaien. Dat valt buiten de scope van BigGrid, of in ieder geval van deze werkgroep. Het interessants voor gebruikers is duidelijk de Class 3 VM, en dat is waar we ons op moeten richten.
  • PvB: Class 2 VM's zijn buiten HEP niet "viable": De niet-HEP VO's zijn puur administratieve entiteiten, zonder de resources om, in overleg met sites en gebruikers, VMs te bouwen en te laten certificeren. PvB betwijfelt zelfs dat dit voor HEP-VO's een werkbare oplossing is.

Er volgt een technische discussie over het schedulen van de VMs.

  • PvB heeft voorkeur voor een systeem waarbij het opstarten van VMs en het draaien van gLite jobs verschillende dingen zijn: nieuwe, non-HEP gebruikers kunnen via een Amazon-achtige web-interface (en RESTful web-service) VMs draaien op het Grid. Legacy gebruikers (HEP) kunnen jobs blijven inschieten in de gLite WMS. De WMS zal dan, indien nodig, gLite workernode VMs opstarten op het Grid (via bovengenoemde aparte interface) en vervolgens op die gLite nodes de jobs doen uitvoeren.
  • SK: er zijn al implementaties (Haizea) die via de huidige scheduler de mogelijkheid bieden om VMs te schedulen zonder het draaien van een job, de user interface zal dan echter niet veranderen. Ook zijn er mogelijkheden (DESY/INFN) om jobs automatisch in VMs te laten draaien. Dat laatste mechanisme voldoet echter niet aan de gewenste scheiding tussen VMs en jobs.

Om vooruitgang te boeken zijn de volgende actiepunten gedefinieerd.

  • Sander maakt een concreet scenario voor het gebruik van Class 2 VMs bij Nikhef. Daaruit moet kunnen worden opgemaakt welke wijzigingen nodig zijn in het huidige systeem om Class 2 VMs te ondersteunen.
  • Pieter doet hetzelfde voor Class 3 VMs.
  • Ronald maakt een overzicht van alle policy en security issues die de site heeft met Class 2 en 3 VMs. Daarbij verdienen twee argumenten bijzondere aandacht:
    1. Waarom kan het bij Amazon wel en bij ons niet?
    2. Waarom geldt een argument wel voor VMs en niet voor 'normale' jobs?
Volgende vergadering
dinsdag 18 augustus 15:00 -- Floris zal ook weer aanwezig zijn