Feature #191

SLX-Online-DEMO

Added by dvs about 4 years ago. Updated almost 4 years ago.

Status:Erledigt Start date:
Priority:Hoch Due date:
Assignee:dvs % Done:

0%
Category:konzept
Target version:Visionen ;)
Resolution:worksforme

Description

Damit Interessierte (mit passender Bandbreite) unser Zeugs möglichst ohne viel Aufwand ausprobieren können, schwebt mir eine CD-Boot-Lösung der folgenden Form vor:

1. Booten von einer CD/DVD oder geeignetem Medium, welches einen Spezialkernel (nicht aufregend aber mit "kexec") und spezielles [[InitRamFS]] (mit vielen unterstützten Netzwerkkarten)
 2. Herunterladen von einer Auswahl verfügbarer Systeme, Auswahl dem User anbieten (kann im ersten Schritt noch entfallen, wenn es nur ein System gibt)
 3. Herunterladen des (gewählten) System-Kernels, der System-InitRamFS und nachschauen, ob die Maschine schonmal da war (d.h. es existiert bereits ein [[ConfTGZ]]; alles per wget Applet der Busybox)
 4. Wenn Maschine schon da, gleich  neuen Kernel, neues [[InitRamFS]] anbooten und dann im üblichen Konfigurationsschritt das [[ConfTGZ]] laden (dazu sollte das entsprechende "file=!http://server-ip/pfad-zum-ConfTGZ" in der Kernel Commandline stehen.)
 5. Sonst User nach Config fragen: 
   a. gewünschtes Root-Passwort
   b. ID für einen unprivilegierten User mit Passwort
   c. weitere Sachen (welche Dienste starten etc.)
 6. Die erzeugte Konfiguration nach unseren Standards einpacken und auf unseren Server hochladen (auch per wget)
 7. Anschließend wie 4. weiterbooten ...

History

#1 Updated by dvs about 4 years ago

Es gibt jetzt eine erste Demo mit einer aktuellen OpenSuSE10.3. Das Passwort für das System: OpenS1X ... Bootzeit vom CD-Start bis zum KDM-Login 120sek. dd-Test (Lesen von 10MByte aus /dev/nbd0) zeigte ein IO von ca. 150-200kByte/sek.

#2 Updated by dvs about 4 years ago

Interessant werden hier evtl. wieder Konzepte wie Preload/Prefetch, siehe #43 ... So dauert der Start des Firefox mal lässige 75sek. :( Beim zweiten Aufruf sind es hingegen nur noch 3sek.

#3 Updated by dvs about 4 years ago

Derzeit besteht noch ein Problem mit dem VGA-Buffer. Wenn auch der zweite Kernel mit "quiet" gestartet wird, taucht plötzlich wieder das ISO-Auswahlmenü auf.


  

  

  

    
#4
    
    
    Updated by dvs about 4 years ago


    
    
Messungen mit hdparm in einer lokalen Umgebung (Gigabit) kamen auf 22MByte/sek. Das ist dann ordentlich fix. Aber schon größere Entfernungen scheinen sich negativ auszuwirken ...

  

  

  

    
#5
    
    
    Updated by dvs about 4 years ago


    
    
Verbesserungen mit DNBD2 (schnellerer Start: 1:33 zu 2:00), Read-Ahead bei NBD bringt etwas Verbesserung, siehe r1590. ... und der Durchsatz mit hdparm in 100Mbit/s steigt auf "realistische" 10.5MB/sek.

  

  

  

    
#6
    
    
    Updated by dvs about 4 years ago


    
    
Messungen auf der Leitung ergaben (bei einer Leitungskapazität von netto 15000kbit/s DSL):
	
    
	
  • 4200kbit/s max. für NBD
    • 
		
  • 5100kbit/s max. für DNBD2 (dabei schnellerer Start von System und Apps)
    • 
		
  • 13500kbit/s für FTP auf denselben Server aus dem gestarteten System heraus
    • 
	



	
... da ist irgendwie noch ordentlich Platz in der Leitung.

  

  

  

    
#7
    
    
    Updated by dvs about 4 years ago


    
    
Vorteil des DNBD2 - den stören meine DSL-Abbrüche (=IP-Wechsel) nicht. Da ist NBD deutlich kritischer ...

  

  

  

    
#8
    
    
    Updated by dvs about 4 years ago


    
    
NFS-Tests stehen noch aus ... Nächster Versuch - verkleinern der Blockgröße vom SquashFS auf 4kByte, damit nicht soviele Päckchen für ein Block notwendig sind ...

  

  

  

    
#9
    
    
    Updated by dvs about 4 years ago


    
    
Eine kleinere Blocksize (4kByte im Test) verschlechterte das Ergebnis von DNBD2 leicht und von NBD erheblich. Also erstmal wieder der Default-Wert (vorgegeben durch mksquashfs) von 64kByte.

  

  

  

    
#10
    
    
    Updated by dvs about 4 years ago


    
    
Vergleichswerte für lokales Netz, 100Mbit/s (SuSE10.3, von ISO-Menüauswahl bis KDM-Login-Screen):
	
    
	
  • Boottime: DNBD2 44, NBD 45, NFS 58sek.
    • 
		
  • Datenmenge: DNBD2/NBD ~54MB down, ~1MB up; NFS 83 down, 3 up
    • 
	

  

  

  

    
#11
    
    
    Updated by dvs about 4 years ago


    
    
    
      
       
  • Status changed from Neu to Erledigt
    • 
      
       
  • Resolution set to worksforme
    • 
      
    

    
    
Soweit funktionstüchtig, mit aktuellem kexec funktioniert auch der Neustart des Hauptkernels (r1599). Kompakter/unabhängig durch uClib-Umgebung, siehe auch #196. Bisher nur i586 - könnte aber für den Zweck vollauf genügen, da Kernel, Programme der Preboot-Umgebung für Hauptumgebung komplett ersetzt werden. Für Boot-Optimierungen siehe #197 ...

  

  

  

    
#12
    
    
    Updated by lmuelle about 4 years ago


    
    
Zwecks Optimierung müssen wir gegebenenfalls identifizieren, an welcher Stelle es klemmt.



	
Dazu bringen wird den Server und ein System, das im gleichen Netz wie der Clients steht, zeitlich per NTP in Sync. Unser System zur Beobachtung hängt dabei an einem Port, der alle Pakete bekommt (Monitoring oder Mirror Port), so dass wir auch die für den OpenSLX-Client bestimmten Pakete sehen. Dieser Ansatz erfordert keine Anpassung des OpenSLX-Clients und beeinflusst den Startvorgang nicht.



	
Dann machen wir uns Notizen, wann welche Punkte des Bootvorgangs erreicht wurden, wann das System stand oder zum Beispiel keine Daten über das Netz gingen.



	
Hier bei Bedarf weitere Anhaltspunkte zwecks Analyse einfügen.



	
Dann sniffen wir in beiden Netzen mit. Daraus erhoffe ich mir weiterführende Rückschlüsse was wo, wie, warum klemmt.

  

  

  

    
#13
    
    
    Updated by mj0 almost 4 years ago


    
    
Milestone V6.0 deleted

  

  



























Also available in:
  Atom
  PDF