Linux Container im High Performance Computing
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45623 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201954 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
LINUXMathematical singularitySupercomputerHypothesisComa BerenicesWINDOWS <Programm>High availabilityComputer hardwareComputerServer (computing)Stack (abstract data type)TwitterMenu (computing)LINUXMathematical singularityWordComputer scienceXMLUMLLecture/ConferenceComputer animation
01:05
LINUXHochleistungsrechnenService (economics)SoftwareCONSULTANT <Datenbank>SupercomputerLink (knot theory)Computer animationProgram flowchart
01:57
SupercomputerCloud computingLink (knot theory)Point cloudExact sequenceEIBSource codeService (economics)OutlookLINUXHochleistungsrechnenSupercomputerVirtual machineEnterprise architectureComputer animationMeeting/Interview
03:00
ComputerSupercomputerSource codeComputer scienceHochleistungsrechnenSupercomputerComputer hardwareFinite element methodCRAY <Vektorrechner>FunktionalitätLINUXOperating systemDirection (geometry)Computer animation
04:06
Source codeHochleistungsrechnenPoint cloudFlagOpen sourceSupercomputerInternet der DingePoint cloudComputer animation
04:54
SupercomputerOpen sourceCross-platformComputerPoint cloudWorkstation <Musikinstrument>LaptopProviderWorkstation <Musikinstrument>LaptopPoint cloudRoute of administrationOperating systemCodeMobile appSupercomputerXMLComputer animation
06:35
Open sourceProviderUser interfaceSource codeDevice driverLink (knot theory)Route of administrationCodeOperating systemUpdateComputer animationXML
07:46
Computer hardwareStack (abstract data type)BerechnungSoftwareVirtual machineMainframe computerKernel (computing)Run-time systemXMLComputer animation
08:45
Source codeOverhead (computing)Debian GNU/LINUXOpenMPLINUXCompilerVirtual machineIBMConfiguration spaceRoute of administrationComponent-based software engineering
10:02
Perturbation theoryXena <Computerspiel>VMware WorkstationVirtual machineLINUXOpenVZVirtualizationEckeTime zoneOperating systemUNIXHypercubeSource codeMeeting/InterviewComputer animation
11:18
SupercomputerWorkstation <Musikinstrument>Xena <Computerspiel>LINUXKernel (computing)Run-time systemEckeSupercomputerComputer animation
12:12
YouTubeSource codeData structureAtomic nucleusXMLUML
12:59
BefehlsprozessorRoutingKernel (computing)Mainframe computerLimitierungsverfahrenBefehlsprozessorComputer animation
13:49
SupercomputerEnterprise architecturemakeLINUXAppArmorSELinuxService (economics)Lösung <Mathematik>Mainframe computerSupercomputerStandard deviationMobile appBlogComputer animation
16:14
Computing platformOpen sourceComputing platformComputer animationMeeting/InterviewXMLUML
17:02
SupercomputerComputing platformScheduling (computing)Service (economics)LINUXAttribute grammarRoundingZugriffSupercomputerRoute of administrationProcess (computing)Message passingVolumeHypercubeComputer animation
18:49
Version <Informatik>Computer animation
19:43
Point cloudFragmentierung <Informatik>Common Language InfrastructureSolitary confinementImplementationStress (mechanics)Computer animation
21:08
Computing platformSELinuxLINUXHochleistungsrechnenService (economics)Computing platformFocus (optics)XMLUMLComputer animation
22:06
Computing platformSELinuxHochleistungsrechnenService (economics)LINUXWINDOWS <Programm>Data modelSupercomputerMusical ensembleFirst-person shooterBenchmarkSupercomputerPAPProzessmodellLINUXComputer animation
23:00
ComputerFreewareVAX/VMSPhysical quantityOverhead (computing)Service (economics)Computer animationXMLUML
24:23
Service (economics)SupercomputerLINUXUbuntu <Programm>IBMHochleistungsrechnenBefehlsprozessorMassUbuntu <Programm>Operating systemFocus (optics)Computer animationXML
25:14
Scope <Programmierung>Utility softwareCommon Language InfrastructureHochleistungsrechnenSupercomputerLINUXService (economics)Computer animation
25:59
Common Language InfrastructureServer (computing)Client (computing)DebuggerEASY <Programm>LINUXHochleistungsrechnenService (economics)Route of administrationMainframe computerComputer animation
27:51
SupercomputerAPILINUXMacOSWINDOWS <Programm>Service (economics)SupercomputerComputer animation
28:56
Just-in-Time-CompilerBlogMenu (computing)World Wide WebPDF <Dateiformat>PowerPointSlide ruleLINUXWordGoogleXML
30:01
SupercomputerSource codeHTTPMenu (computing)sedUser interfaceRevision controlOpen sourceSuperLearnHulk <Computerspiel>Computer hardwareGoogleIntelSocial classSupercomputerAMD <Marke>Spectre <Programm>Computer animationSource codeXML
31:06
Menu (computing)Proxy serverBeer steinUniformer RaumSupercomputerUser interfaceOrder of magnitudeComplete metric spaceAMD <Marke>Virtual machineXMLUML
31:53
SupercomputerSoftwareEnterprise architectureGraphics processing unitComplete metric spaceMainframe computerPhysical quantitySeries (mathematics)Systems <München>Enterprise architectureCodeLösung <Mathematik>SupercomputerScheduling (computing)Object (grammar)Heat transfer coefficientComputer animation
35:14
Source codeSupercomputerEnterprise architectureLINUXHochleistungsrechnenService (economics)CentOSVersion <Informatik>Route of administrationSpoke-hub distribution paradigmSocial classXMLComputer animation
36:16
Service (economics)Flow separationLINUXHochleistungsrechnenMainframe computerEigenvalues and eigenvectorsDistribution (mathematics)Decision theoryEckeComputer animation
37:20
ARCHIVE <Programm>Mainframe computerComputer animation
38:06
Source codeMathematical singularityTRAMO <Programm>Mainframe computerSpacetime
39:01
makeComputing platformHochleistungsrechnenEinstein field equationsWorld Wide WebEnterprise architectureRaw image formatVersion <Informatik>Web pageMach's principleComputer animation
39:55
Source codeSupercomputerIntelMathematical singularityCRAY <Vektorrechner>Version <Informatik>WORKS SuiteIntelVersion <Informatik>CRAY <Vektorrechner>Focus (optics)Graphics tabletLoop (music)Spoke-hub distribution paradigmPhysical quantityXMLComputer animation
41:06
SupercomputerCRAY <Vektorrechner>CUDA <Informatik>LaptopSource codeFinite element methodLINUXMatroidCodeVersion <Informatik>Focus (optics)CRAY <Vektorrechner>Customer relationship managementVersion <Informatik>CodeComputer animationXML
42:29
SupercomputerPasswordLINUXLoginLisaDownloadVersion <Informatik>SupercomputerVersion <Informatik>System administratorComputer animation
44:03
SupercomputerHochleistungsrechnenLINUXService (economics)HypermediaSource codeEigenvalues and eigenvectorsSupercomputerSimilarity (geometry)Computer animationXMLProgram flowchart
44:49
SupercomputerDistribution (mathematics)Distribution (mathematics)Version <Informatik>Shift operatorComponent-based software engineeringWindows RegistryXMLUMLComputer animation
46:11
Common Language InfrastructureEASY <Programm>Single-precision floating-point formatSupercomputerSSHGraphics processing unitSource codeEckeShift operatorInstallable File SystemSupercomputerComputer animation
47:37
SupercomputerSource codeHTTPSupercomputerInequality (mathematics)Moment (mathematics)Eigenvalues and eigenvectorsXMLUMLComputer animation
49:09
SupercomputerHTMLSource codeUser interfaceWorld Wide WebUniversal product codeHochleistungsrechnenService (economics)Apache <Programm>Mathematical singularityYES <Computer>Shift operatorInequality (mathematics)ZahlStatistikerXMLComputer animation
51:05
HochleistungsrechnenLINUXService (economics)Apache <Programm>Mathematical singularitySupercomputerEnterprise architectureTuring testPOSIXOrder of magnitudeMachine learningIBMSupercomputerFault-tolerant systemComputer animation
52:08
Scheduling (computing)SupercomputerHochleistungsrechnenService (economics)OutlookGraphics processing unitLINUXPoint cloudScheduling (computing)Enterprise architectureCW-KomplexSupercomputerQueue (abstract data type)EckeEigenvalues and eigenvectorsComputer animationXML
53:18
Source codeMathematical singularitySupercomputerSoftwareFirewall (computing)CountingSimulationPoint cloudScheduling (computing)CarriagewayService (economics)HochleistungsrechnenLINUXConcurrency (computer science)SupercomputerPropositional formulaComputer animationXMLMeeting/Interview
54:24
Point cloudCodeComputer musicInformationsvermittlungsstelleSupercomputerAgreeablenessFiber bundleSoftwarePOWER <Computerarchitektur>MikroarchitekturRun-time systemRoute of administrationParallel computingFixpunkt <Datensicherung>
59:22
openSUSELecture/ConferenceXMLComputer animation
Transcript: German(auto-generated)
00:08
Also, schönen guten Morgen erstmal. Morgen ist irgendwie nicht so ganz meine Uhrzeit, aber jetzt gucken wir mal, wie das alles wird. Ansonsten, ich habe jetzt nach dem Indeed die Ehre, ein bisschen was zu Linux Container im High-Performance-Computing zu erzählen.
00:20
Ja, Untertitel ist von mal zur Singularität und weiter. Und ich habe vor vier, fünf Jahren schon mal irgendwie einen Talk zu Container und HPC gemacht. Und das ist jetzt im Prinzip so der erweiterte Update-Vortrag. Da hat sich in den fünf Jahren ziemlich viel getan. Dann, was das alles ist, werde ich jetzt gleich irgendwie erzählen. Noch ein paar Worte zu mir. Mein Name ist Holger Ganteko.
00:40
Ich habe an der einzigen Hochschule mit zwei Wintersemestern im tiefen, tiefen Schwarzwald namentlich Futwagen Informatik studiert. Damals gab es nur so Zeug wie Diplom. Und bin dann über Praktika und Diplomarbeit irgendwie in Tübingen gelandet. Und bin da jetzt auch irgendwie seit knapp über zehn Jahren als inzwischen Senior Systems Engineer im HPC-Berechnungsumfeld.
01:01
Ja, im Bereich Automotive tätig. Und genau noch kurz zu meinem Brötchengeber. Es ist ein Computing AG in Tübingen. Wir waren irgendwann mal so knapp 300 Mann, relativ kuschelig. Seit ein paar Jahren gehören wir jetzt irgendwie zur Athos-Gruppe dazu. Dürfen auch unter dieser Brand auftreten. Gänsefüße bitte dazudenken. Und ansonsten, ja, Athos schon etwas größerer hausenbar,
01:23
wenn man aus einem 300-Mann-Unternehmen kommt mit irgendwie 125.000 Mitarbeitern in irgendwie 73 Ländern. Und wie gesagt, also der Bereich von Athos, der auch mit Umlauten kann, setzt sich halt eben mit Kunden aus dem Automotive-Bereich auseinander. Auch Lifesense und dergleichen.
01:42
Und ja, falls wer zufällig irgendwie Jobs mit Umlauten suchen sollte, darf gern mal in Tübingen bei uns gucken. Wir suchen relativ viele Linux-Leute. Also eben für diesen CAE HPC Linux-Themenbereich. Und ansonsten gern immer wieder für Praktika und Thesen bewerben oder mich einfach mal anhauen. Und ansonsten, ja, bin ich in meiner Freizeit noch irgendwie Teilzeitforscher
02:03
am Institut für Cloud Computing und IT-Sicherheit in Zusammenarbeit von Futwang und Plymouth University. Und setze mich da so mit dem Themenbereich Container und Security irgendwie auseinander. Und das Ganze mit dem Ziel, ja, den Containereinsatz im HPC einfach ein Stück weit sicherer zu machen
02:22
beziehungsweise klassische HPC-Umgebung einfach durch Container zu erweitern und auch ein Stück weit abzusichern. Ansonsten, was habe ich heute an Thema mitgebracht? Ja, zuerst gibt es mal so einen kleinen Überblick, warum möchte man in dem Bereich überhaupt Container einsetzen? Was machen die vielleicht an der Stelle besser als virtuelle Maschinen? Dann ein Rundumschlag, was für Container-Runtime gibt es,
02:43
die in dem Bereich einigermaßen relevant sind. Es gibt zwei große Unterscheiden. Einmal so Enterprise versus HPC-Aware. Und genau, hinterher gibt es eben noch den Überblick, was hat sich so die letzten fünf Jahre quasi getan? Wo stehen wir da heutzutage? Und wie geht es dann vielleicht weiter?
03:01
Ansonsten, Informatiker fangen ganz gerne bei Null an. Deswegen hier nochmal so ein kurzer Recap, falls sich irgendwer in den Vortrag verirrt hat, weil er gesehen hat, irgendwas mit Container. Ja, High-Performance-Computing, kurz HPC, geht es im Prinzip darum, ich habe irgendwie ein wissenschaftliches Problem, möchte das mit möglichst viel Hardware irgendwie erschlagen. Also, die Kunden, mit denen ich zu tun habe,
03:21
die setzen meistens irgendwie auf so Strömungssimulationen Sachen, auch viel Crash-Tests, Mehrkörper-Simulationen, Finite-Elemente-Methode und so weiter. Und mittel zum Zweck ist im Prinzip so was hier, möglichst viel Hardware draufschmeißen. Angefangen hat das Ganze mal hier mit so schönen Supercomputern, die man irgendwann dann auch mal irgendwie ins Museum stellen konnte oder noch als Möbelstück wenigstens hinterher verwenden.
03:43
Mitte der 90er auch durch irgendwie die Möglichkeit, mit Linux als qualeoffenen Betriebssystem sich fehlende Funktionalitäten im Vergleich softwareseitig zu so einem Supercomputer nachzurüsten, hat sich das dann Richtung Cluster entwickelt. Und ja, da sind mal die Herren auf die Idee gekommen, dass es ja eigentlich voll gut wäre,
04:00
wenn man da etwas günstigere Hardware irgendwie haben könnte, als irgendwie so eine schöne Cray. Und hat sich inzwischen alles irgendwie weiterentwickelt. So sieht es in der Regel aus, wenn man noch ein bisschen Budget über hat für ein Cluster, um irgendwie eine schöne Verglasung irgendwie ran zu machen oder in der Top 5 ist und ein schönes Marketingfoto haben will. So sieht es ein bisschen schicker aus als da, aber das ist so die Pragmatiker-Lösung.
04:21
Und bei Heise war neulich irgendwie ein Artikel von Suze irgendwie gemeint hat, hier ist doch hier für IT-Experten viel wichtiger als KI und IoT und dergleichen. Also insofern HPC-Techniken findet man in relativ vielen Bereichen. Nicht jetzt nur zwingend irgendwie Automotive. Und dadurch, dass schon mal so eine gewisse Demokratisierung
04:41
hin vom Supercomputer, weg vom Supercomputer hin zum Cluster-Computing passiert ist, ist momentan auch relativ spannend, vollends irgendwie in die Cloud zu gehen, quasi so als BioWolf 2.0. Und dafür ist auf jeden Fall Containern eine Technologie, wo das letztendlich relevant ist. Insofern schauen wir uns mal an, was in dem Bereich
05:00
irgendwie an Themen bzw. an Problemstellungen relevant ist. Ja, der Ingenieur sitzt typischerweise, fängt dann mal irgendwie bei seinem Laptop an. Manche gehen dann auf ihre oder haben eine schöne Workstation noch unterm Tisch stehen und wollen dann hin auf irgendwie einen Supercomputer, eine Cluster oder vielleicht auch irgendwie in die Cloud. Und da ist es halt einfach schön, den Programmcode,
05:21
den man einsetzen möchte, als eine portable Einheit zu haben und sich nicht unbedingt groß Gedanken um das Betriebssystem, auf dem es dann final zum Laufen kommt, irgendwie Gedanken machen zu müssen. Jetzt nicht unbedingt im kommerziellen Umfall. Das kriegsentscheidende Thema, aber zumindest in Forschungseinrichtungen, user-provided applications.
05:41
Der Anwender, ja, Wissenschaftler, Ingenieur, kommt irgendwie beim Admin an und sagt, du, ich hätte hier gerne meinen tollen Code, installiere den mal bitte auf den ganzen Cluster. Auf der Workstation kann man da vielleicht noch drüber reden, aber irgendwie auf ein paar Tausend-Knoten-Systemen das dann zu deployen, möchte man jetzt vielleicht nicht unbedingt haben. Ansonsten kommt noch das ganze Thema dazu.
06:01
Ja, Abhängigkeiten wollen erfüllt sein. Ich habe ein Latency-Problem sehr, sehr häufig. Im HPC-Umfeld kommen meistens etwas gut abgehangene Betriebssysteme irgendwie zum Einsatz. Also wir sind bestenfalls irgendwie mit Rell 7 momentan unterwegs, ist ja jetzt auch inzwischen nicht mehr ganz das Allerneueste und ja, kommen immer mal wieder so Anfragen.
06:21
Ich hätte hier diese schöne neue Anwendung gerne installiert bzw. halt einfach andersrum, dass man halt irgendwie Code von vor irgendwie 15 Jahren irgendwie mitschleppen muss oder halt irgendwie 15 unterschiedliche Geschmacksrichtungen von ein und derselben Applikationen. Also insofern ganz, ganz großes Thema hier damit umzugehen und ja, auch ein schönes
06:41
Beispiel von XKCD, wie sich bei manchen Anwendern irgendwie so die Python-Installation irgendwie entwickeln und ja, eher für wissenschaftliche Anwender das ganze Thema. Ich möchte mein Code weitergeben, ich möchte mit anderen Instituten zusammenarbeiten und Beispiel kurz aus dem Umfeld, vom Kollegen aus Tübingen, die machen
07:02
Genome Sequencing und haben das Problem, dass sie halt nicht nur eine Applikation quasi haben, sondern komplexe Pipelines. Die halt miteinander verschachtelt sind und ja, das dann halt irgendwie weiterzugeben war irgendwie wohl ziemlich schmerzhaft früher und in der Regel irgendwie in seitenlangen Anleitungen geendet, die dann damit geendet haben von wegen
07:21
und danach fasst das System nicht mehr an, kein Update mehr und einfach dadurch, dass halt irgendwie ein Teil der Installation aus dem Betriebssystem kam, ein Teil selbst kompiliert, ein Teil dann irgendwie über Pip rein und so weiter und da eine Möglichkeit haben quasi das komplette Environment mit allen Abhängigkeiten weiterzugeben ist halt großartig und
07:42
die setzen da in dem Umfeld ganz, ganz stark auf Container. Genau und ansonsten ja das Thema Reproduzierbarkeit, gut klar, kernel endet sich letztendlich auch, aber wenn man halt zumindest mal die Möglichkeit hat, für eine Berechnung den kompletten Software Stack im Prinzip eingefroren zu haben, ist das auf jeden Fall eine nette Lösung und
08:00
ansonsten ja, wie können hier jetzt Container irgendwie helfen bzw. was machen die besser? Großteil lässt sich letztendlich auch mit virtuellen Maschinen erschlagen, aber wenn es mir letztendlich darum geht, dass ich einfach nur meine Applikation hier oben verteilen möchte und dann sehe, dass ich halt den kompletten Gastbetriebssystem Stack irgendwie mitschleppen muss und pro Applikation, die ich betreiben
08:22
möchte, in so einer Umgebung dann im Prinzip auch den kompletten Kernel irgendwie mitschleppen möchte, ist bei virtuellen Maschinen dann meistens irgendwie etwas unschöner und ist halt dann Container mit, ja, ein Kernel, der quasi pro Host läuft irgendwie weitaus angenehmer und so Zeug wie, ich habe irgendwie ein Linux-Host und ich möchte eine Windows-Applikation drauf laufen,
08:42
hat man im HPC-Umfeld eigentlich relativ wenig. Dazu kommt dann im HPC-Umfeld der Aspekt, dass die Performance ziemlich nah am Blech ist. Wen es im Detail interessiert, es gibt dieses IBM-Paper vom Felkner, was das irgendwie, glaube ich, 2014, 2015 mal irgendwie verglichen hat mit dem Fazit, dass halt alles, was
09:01
irgendwie IO-intensiv ist, in Containern deutlich besser aufgehoben ist als in virtuellen Maschinen. Hat sich alles verbessert, wird sich auch noch alles weiter verbessern, aber zu dem Zeitpunkt war das halt letztendlich das große Fazit und der Performance-Overhead ist einfach an der Stelle geringer. Ansonsten so Sachen wie, dass ich
09:21
irgendwie Images mit Layern haben kann, Software, die aufeinander quasi aufbaut und ich dann so Kram machen kann, wie dass ich hier mir mein optimales Environment irgendwie zusammenklick, also ich kann ausprobieren. Ich habe eine Applikation, ich habe aber diverse andere Komponenten involviert, irgendwie unterschiedliche MPI-Versionen, ich habe einen
09:41
unterschiedlichen Compiler, mit dem ich es übersetzen kann und ich habe final dann drunter irgendwie einen Linux-Flavor drunter und unter Verwendung von halt entsprechenden CI-CD-Pipelines kann ich mir halt die diversen Konfigurationen generieren lassen und dann halt einfach mal durchprobieren, wie jetzt denn meine Applikation letztendlich am besten funktioniert. Also da ist es ein
10:01
durchaus spannender Einsatzzweck. Ansonsten fassen wir zusammen, ja Container sind keine magischen virtuellen Maschinen, sondern einfach was anderes und können in manchen Bereichen attraktiver sein. Ansonsten ist das Ganze jetzt nicht irgendwie keine Ahnung, die neueste Scheiße irgendwie die letzten drei Jahre irgendwie raus kam, sondern das
10:21
basiert alles irgendwie weitestgehend auf gut abgehangenen Basistechnologien. Angefangen hat das Ganze mit hier ja Betriebssystem oder OS-Level Virtualisierung. Wenn man mal von jenseits von ChangeRoute irgendwie mit dem frühen Unix-System weggeht irgendwie um die 2000 mit Jails unter BSD, der Linux kam dann 2002
10:42
dann die Namespaces dazu, 2006 kam dann noch weitere dazu und so als erster Ansatz auf dem Basieren kam dann irgendwie OpenVZ um die Ecke unter Solaris gab es dann parallel noch irgendwie die Zones. Weitere Kernkomponente für Container unter Linux waren dann eben Cgroups, die gibt es seit 2006, also
11:01
auch schon alles relativ gut abgehangene Basistechnologien. Darauf aufbauen kann man 2008 LXC um die Ecke und ab 2013 kam dann halt Docker und hat quasi so den Container-Hype letztendlich gestartet. Zwei Jahre später dann noch irgendwie Core OS Rocket irgendwie um die Ecke und inzwischen müssen wir noch zig andere hier aufführen, aber so
11:20
einfach um mal kurz die Geschichte angerissen zu haben. Ansonsten warum habe ich hier noch die Hypervisor, worauf ich letztendlich raus will, KVM ist auch erst von 2006, also sprich die Basistechnologien Cgroups und Namespaces, die letztendlich Container ausmachen, sind letztendlich ähnlich alt und ähnlich gut abgehangen an der
11:41
Stelle würde ich sagen. Ansonsten die HPC-Container-Runtimes, also Runtimes die wirklich irgendwie für HPC optimiert sind, sind ab 2015 um die Ecke gekommen, auf die gehe ich später noch ein, aber man hat halt in dem Bereich irgendwie festgestellt, dass irgendwie Docker jetzt nicht unbedingt das Nonplus Ultra in der Umgebung ist.
12:03
Genau, wie ich gerade eben schon erwähnt habe, Container sind keine grundsätzlich neue Technologie, sondern basieren auf relativ gut abgehangener Technologie, die bereits im Linux-Körner drin ist. So als Beweis, das ist aus einem Vortrag vom, wie heißt er denn, von Patersoni ist es glaube ich, von
12:21
genau Patersoni von Docker, einer der Kernentwickler bei denen, hat ich quasi mal für einen Vortrag so mal geschaut, was denn, wenn er jetzt auf Kernleuk geht und in den Soßen rumsucht und mal nach LXC sucht, findet er genau null Treffer. Wenn er nach Container sucht, findet er irgendwie 1000 Treffer. Bei genauerer Analyse stellt man fest, es geht nicht um die Linux-Container, sondern
12:42
um irgendwelche Datenstrukturen für zum Beispiel RCP-Container und ja, Martin, ist so. Und ansonsten halt, wenn es dann Referenzen auf unsere Container gab, dann bezieht sich das letztendlich einfach nur in der Dokumentation. Insofern, wie
13:00
gesagt, Container im Prinzip Namespaces plus Cgroups. Namespaces sorgen dafür, um einen isolierten Betrieb zu gewährleisten. Das heißt, ich kann zum Beispiel über den PID-Namespace sicherstellen, dass ein Prozess innerhalb oder der diesen anderen PID-Namespace nutzt, dass er halt nicht die, ja, die ganzen Prozesse, die auf dem Host laufen, sehen.
13:21
Das Gleiche gibt es noch für NetIPC-Mount, UTS-User, unser und auch noch irgendwie Cgroups. Und das ist im Prinzip das, was den isolierten Betrieb gewährleistet. Und zusätzlich kommen noch als, ja, für die Ressourcen-Usage-Limitierung kommen eben noch die Cgroups dazu. Kann ich zum Beispiel sagen hier, du darfst nicht alle
13:41
CPU-Cycles nutzen, sondern nur einen Anteil davon und das Ganze noch für weitere, für weitere Controller. Ja, ganz, ganz wichtig, nicht alle Containers sind letztendlich gleich. Also gerade, wenn man so die Enterprise-Lösung mit den HPC- Lösungen vergleicht, dann, ja,
14:01
läuft dann alles irgendwie schön unter dem Container-Sticker, aber wenn man sich das dann anschaut, dann ist es teilweise doch eine aufgebotene Change-Route-Umgebung letztendlich und das nur noch mal so vorab als Warnung. Und im Format gibt es ja teilweise auch große Unterschiede. So, was gibt es denn jetzt für Runtimes?
14:21
Ich unterscheide das im Prinzip in zwei große Bereiche, einmal die Enterprise-Runtimes, die zeichnen sich dadurch aus, dass wir halt einfach auf einen Enterprise-Markt adressiert sind, wo es darum geht, dass ich auf einem Host möglichst viele kleine Container irgendwie laufen habe, hier Shiploads auf Container, also kann man sich wirklich schön bildlich wie irgendwie so ein Containerschiff vorstellen.
14:42
Szenario eher Microservices, HPC in dem Umfeld und HPC ist einfach nicht der typische Use-Case für die Enterprise- Container. Im HPC habe ich eher den Use-Case, dass ich halt einen Container pro Host habe, eine Workload pro Host und nicht möglichst viel und in der Regel möchte ich auch darüber hinaus
15:01
meine Workload auf mehrere Hosts verteilen. Ja, und weiterer Schwerpunkt der Enterprise- Runtimes ist halt, dass man so viel Isolation zwischen Container und Host und den anderen Container bereitstellen kann, wie irgendwie möglich ist. Das heißt, ich habe Namespaces überall, ich möchte zusätzliche Linux
15:21
Security-Features einsetzen, Seccom, dass ich nur bestimmte Systemcalls freischalte oder entsprechende Blockier. Ich möchte Mandatory Access Control haben, SE Linux, App Armor und und und. Und ja, ein weiterer Punkt läuft am besten auf allen aktuellen Distributionen, weil aktueller Kernel, weil aktuelle Namespace-
15:40
Unterstützung und so weiter und das wird dann im HPC-Umfeld teilweise auch etwas schwierig. Ansonsten bieten die alle in der Regel OSCI-Kompatibilität, also OSCI ist die Open Container Initiative, die hat irgendwie eine Handvoll Standards quasi rausgebracht, um das Ganze einfach relativ stark interoperabel zu machen und hat sehr, sehr breit
16:02
zur Standardisierung einfach beigetragen. Ansonsten gar nicht teilweise so Features wie Creo nutzen, dass ich irgendwie im User-Space irgendwie Live-Migration mache und dann noch das ganze Orchestration-Thema, was jetzt hier für HPC jetzt nicht unbedingt so relevant ist. Ansonsten, ja, der Platzhirsch im
16:20
Enterprise-Markt nach wie vor größtenteils zumindestens Docker. Docker hat die größte Memes- Verbreitung in dem Umfeld und ist ansonsten auch so der große Platzhirsch beziehungsweise haben ein gesundes Selbstverständnis ihrerseits. Ansonsten war es Docker. Ja, das hängt von der Zeit ab, also irgendwann war es mal nur diese kleine Container-
16:41
Image, Container-Engine. Irgendwann haben sie dann gemerkt, ey, das ist ja voll cool, die Leute interessieren sich dafür, wir nennen einfach die komplette Firma danach und inzwischen ist so der Docker- Begriff auf ihre komplette Plattform übergeschwappt, was sie da anbieten. Insofern ist so ihre defensive Selbstverständnis, dass sie die world-leading Software-
17:01
Container-Plattform letztendlich werden. Jo, was sind so die Haupt- Attribute über Docker und die einzelnen Runtimes, könnte man größtenteils irgendwie jeweils einen separaten Vortrag halten. Ich habe versucht, irgendwie so ein bisschen zusammenfassend irgendwie hinzukriegen. Also im Prinzip, sie zeichnen sich dadurch aus, dass ein komplettes Ökosystem um
17:21
Container rum bieten. Es gibt Enterprise-Support, das lässt sich mit irgendwie LDAP und Co irgendwie integrieren und der gleichen. Im HPC-Umfeld, ja, ist die Installation der Docker-Runtimes eher überschaubar. Das Haupt- Argument dafür, ja, privilege
17:41
escalation, einfach dadurch, wenn der User direkt einen Zugriff auf die Kommando- Runde hat, irgendwelche Devices reingeben kann, Volumes reingeben kann und so weiter. Dazu kommt der ganze Punkt mit irgendwie den HPC-Besonderheiten, also dass wir sowas wie MPI als Passing-Schnittstelle haben für Nachrichtenaustausch zwischen den einzelnen Prozessen.
18:03
Dann kommt irgendwie noch der ganze Scheduling-Aspekt dazu. Und wenn ich das irgendwie sauber haben möchte, will ich idealerweise meinen Container- Privilege-Daten, möchte ich unter Security-Aspekt nicht unbedingt haben, weil es dann einfach sehr, sehr einfach ist, für einen Anwender sich deutlich höhere Rechte zu verschaffen, als er sonst auf dem System hätte.
18:22
Ansonsten, ja, dadurch kam in dem Umfeld relativ schnell irgendwie so eine Anti-Docker- Haltung letztendlich auf, aber das man zugutehalten muss, das ist nicht mehr der Monolith, wie es irgendwann in den Anfangstagen mal war, aber so momentan der Relationship- Status zwischen Docker und HPC ist eher so complicated.
18:41
Wie gesagt, also hat den ganzen Container-Hype angefangen, die ganzen Wissenschaften, das haben da angekommen, haben gemeint, ja, wir hätten gerne jetzt Docker auf dem Cluster und ja, ansonsten, warum ist es nicht mehr der Monolith? Also es hat irgendwie ab der Version 1.11 die Umstellung von diesem großen Paket sozusagen auf viele kleine, ersetzbare und austauschbare, sowie
19:01
standardisierte Bauteile irgendwie stattgefunden. Also wir haben jetzt Run-C und Container-D und das Nette ist gerade Container-D ist inzwischen so die Execution-Engine für eine Vielzahl von Container- environments. Der Umbau ist so, der End-User merkt nichts davon, er sitzt immer noch hier oben, kann hier mit dem Commandline-Interface
19:21
sprechen, das konnektiert an die Docker-Engine, die steuert hier Container-D und Container-D ist letztendlich das, was dann unter Verwendung von Run-C letztendlich den Container startet. Das Coole daran ist, ich kann zum Beispiel Container-D neu starten, ohne dass mir meine Container wegbrechen, ich kann irgendwie sagen, statt Run-C möchte ich eine andere Execution-Engine haben und
19:42
macht das Ganze etwas flexibler und genau Container-D, wie gesagt der Demon, um irgendwie Run-C irgendwie zu kontrollieren, ist inzwischen auch bei der Cloud-Native Computing Foundation, ist aber auch nicht das Tool, was man dem End-User an die Hand geben möchte, sondern das ist die Komponente, die man halt in
20:01
andere Orchestrierung-Lösungen und so weiter irgendwie halt einbindet, um damit zu interagieren. Run-C, das ist im Prinzip letztendlich das, was dafür erzeugt, dass der Container gestartet wird, das Nutzi-Lib-Container für die ganzen Isolationsgeschichten und so weiter, aber genau ist nicht wirklich End-User-friendly, was
20:21
momentan auch spannend ist, sind so die letzten Züge der Arbeit dran, dass man irgendwie sowohl das Run-C und Container-D rootless-Container unterstützen, das heißt ohne irgendwie eine Privilege Escalation, was sehr, sehr spannend ist, seit 2015 gibt es eben diese OCI,
20:41
die hatte ich ja vorhin schon mal angeschnitten und eben Run-C ist quasi die Referenz- Implementierung für diese Container-Runtime, das heißt, die kann einerseits sehr, sehr einfach ersetzt werden und kann aber auch andererseits in anderen Runtimes oder in anderen Environments eingesetzt werden. Ansonsten, ich habe hier immer noch weiterführende Links, wenn
21:01
irgendwas im Detail interessiert, das zieht sich wie so ein roter Faden letztendlich durch, einfach weil das hier jetzt nur ein Überblick letztendlich sein soll. Und ansonsten ja eine Alternative ist inzwischen auch so ein bisschen tot. Rocket war mal phasenweise ziemlich spannend vor dem Hintergrund oder vor dem Aufschrei irgendwie Docker war fundamental
21:21
flawed, weil er das CEO meinte von wegen, Docker war mal so eine kleine süße Runtime und inzwischen halt eben diese komplette Plattform, dieses komplette Environment. Wir machen dann mal was eigenes, was aber dann wirklich nur irgendwie mit Fokus auf eben dieser Runtime ist und nicht irgendwie eine komplette, ja ein komplettes Environment. Ja, 1.0 gibt es
21:43
seit 2016, das Blöde ist ein bisschen dran. Die letzte Release war, wenn ich es richtig gesehen habe, im April 2018, also inzwischen ja nicht ausentwickelt, sondern zu Ende entwickelt oder keine Ahnung, wie ich sagen soll. Sticker sagt secure by default, also Ansatz ist, sie haben
22:01
demeless Ansatz, was relativ spannend ist. Ich habe die Möglichkeit, verschiedene Isolationsstufen zu wählen, das nennt sich Stage 1 Flavor. Das einfachste ist, ich mache hier so einen Fly Stage 1 Flavor, dann habe ich im Prinzip einfach nur einen Change Shoot im Environment rein oder Sicherheitsaspekten, jetzt nicht unbedingt das Beste. Alternativ ist ein
22:22
BN Spawn. Dann habe ich im Prinzip C Groups Namespaces als Isolationsmechanismus oder ich sage, ich will noch mehr, dann lasse ich mir eine KVM außen rumgeben. Insofern unterstützen sie Docker und ja, sehr Linux orientiert, durch das Prozessmodell deutlich näher an irgendwie
22:41
Linux dran, direkt als irgendwie was Docker da getrieben hat und im HPC Umfeld hat sich Rocket irgendwie nie wirklich Großaufmerksamkeit irgendwie generiert. Ich weiß, es gab irgendwie ein Paper mit drei Benchmarks oder sowas, aber das war es dann eigentlich auch, hat nie wirklich großwer eingesetzt.
23:02
Ja, inzwischen ist es auch ein Stück weit, ich glaube, ja, es ist jetzt her, die Core ist übernommen durch Red Hat, im Prinzip tot. Das ist jetzt hier von August 2018, da ging es dann irgendwie schon los. Aktueller Status von, wann ist es Ende Mai war, dass es drei
23:21
Unpatched CWIs gibt, die irgendwie zur rechten Ausweitung irgendwie genutzt werden können. Also wer noch irgendwie Rocket einsetzt, sollte sich da irgendwie so eine Exit- Strategie so langsam überlegen. Ansonsten, ja, kommt auch noch. Ansonsten LXC habe ich deshalb drin, weil es einfach einen relativ interessanten
23:41
Alternativansatz hat. Docker hat ja so den Fokus, ich habe eine Applikation, die ich in meinem Container laufen haben möchte und nicht irgendwie zig Services und soll sich auch nicht anfühlen wie irgendwie, soll sich auch nicht anfühlen wie eine VM, sondern im Prinzip wirklich halt nur diese Applikation verpackt und LXC kommt aus der anderen Stoßrichtung,
24:01
sozusagen halt im Prinzip, sie möchten sowas haben, was sich für den Enduser anfühlt wie eine VM, ohne dass es halt den Overhead von VMs mitbringt. Das heißt, sie bringen Container, ja, die im Prinzip fast alles können, was VMs irgendwie können. Ich kann in diese Dinge rein SSHen ohne großen Aufwand, weitere Services
24:21
starten und so weiter. Und das war so deren Stoßrichtung, gibt es jetzt auch wie gesagt seit 2008. Die Entwicklung wird aktuell von Ubuntu getrieben, so Zeug wie irgendwie Usernames, Spacesupport haben sie deutlich vor Docker letztendlich gehabt, wird aber einfach im Vergleich zu, ich mach mal kurz einen Docker Pull und hab da mein
24:40
Image da einfach als komplizierter angesehen und hat sich aus dem Grund im HPC-Umfeld auch nicht so wirklich oder nicht zumindest auf so breite Masse durchgesetzt, wie es die Alternativen irgendwie gemacht haben. Und wie gesagt, also Fokus ist eher die Kontenarisierung von einem kompletten Betriebssystem mehr so, ich habe eine Applikation, die ich kontenarisieren möchte.
25:01
Genau, LXD überspringen mal, das ist quasi der Hypervisor. Weiteres, was es gibt, ist irgendwie Creo, ja, einfachste Beschreibung, eine leichtgewichtige Alternative für die Docker-Engine, wenn es letztendlich darum geht, das mit Kubernetes zu verheiraten. Hintergrund der Entwicklung ist, dass Kubernetes irgendwann mal beschlossen,
25:20
hat da so eine Abstraktion für die verschiedenen unterstützten Runtimes, irgendwie Container, die Dodger Legacy, Rocket, Fracti und so weiter brauchen und haben dafür diese Container-Runtime im Interface-Abstraktion eingeführt. Und das ist im Prinzip das, was das für Runtime implementiert.
25:41
Und ansonsten kann auch irgendwie Docker-Container, aber im Prinzip ist es kein Tool, was man irgendwie so dem End-User im HPC-Umfeld an die Hand geben möchte, sondern dient halt dazu da, um irgendwie über Kubernetes entsprechenden Container dann zu Upset, zu orchestrieren.
26:00
Mal ist eher ein bisschen spannend ist, es ist Podman in der Umgebung, da ist auch irgendwie, ja, Red Hat irgendwie ziemlich steigt dran und ansonsten Vergleich ist im Prinzip Podman ist für Creo, was das Docker-Command-Line- Interface-Tool, also das, mit dem der User interagieren würde, ist, ja, für die Docker-Engine ist. Und ja,
26:21
hat auch eine sehr ähnliche Syntax, also im Prinzip man kann hergehen und die Migration von Docker auf Podman durchführen, indem man einfach in Alias Docker gleich Podman definiert. Dann das Schöne ist, merken Anwender dann teilweise noch nicht mal und also sprich so die Standard-Lifecycle-Geschichten irgendwie pull, run, exit
26:41
habe ich darüber erschlagen. Klar wäre auch Docker Swarm-Einsatz oder Container-Update-Funktionalität, die halt nur Docker-only sind. Damit werde ich in dem Umfeld dann nicht glücklich. Es gibt auch ein paar neue Kommandos, die irgendwie Podman-only sind, also sie können irgendwie so Extended Health-Checks jenseits von oben ein Container läuft, sondern der
27:00
tut auch was Sinnvolles. Ich kann mir vom Host aus mein Container RootFS irgendwie direkt mounten. Es gibt irgendwie ein Tool, um mir irgendwie ein Image-Tree anzeigen zu lassen. Und was irgendwie aus Admin-Sicht irgendwie ganz nett ist, verfolgen folgt Exit-Modell, anders als das kleine
27:20
Server-Modell von Docker. Das heißt, ich habe auch irgendwie kein Root-Demon irgendwie laufen. Wer sich für Podman irgendwie interessiert, es gibt ein, oder speziell für Podman interessiert, bei Heise Developer gibt es einen Valentin. Das ist ein Entwickler aus dem Umfeld, beziehungsweise macht auch mit den ganzen anderen neueren Red Hat-Container-
27:40
Technologien irgendwie rum. Ein Übersichtsartikel bzw. eine Artikel-Serie, glaube ich, aus inzwischen drei Artikeln bei Heise Developer, also sehr, sehr, sehr empfehlenswert in dem Umfeld als weiterführende Literatur. Und nett an Podman ist es, dass er halt im Prinzip nicht komplett alles nochmal neu machen. Sondern sich halt durch ihre Schwester-Projekte
28:00
irgendwie Builder, Creo, Scopio, ja, orientieren bzw. halt einfach irgendwie Code-Recycle. Ansonsten im Container native Support für System.ly ist halt spannend, wenn ich irgendwie mehrere Services irgendwie laufen haben möchte. Es gibt für die Windows- und macOS-Anwender gibt es zumindest eine Möglichkeit,
28:21
über Warlink, also eine Remote-RPI, zu integrieren. Und ansonsten durch das Work-Exit-Modell, Unterstützung für Rootless-Container. Das heißt, ja, genau, unter Sicherheitsaspekten durchaus interessanter für viele Sachen als jetzt irgendwie Docker einzusetzen. Ansonsten, ja,
28:41
Podman HPC ist neu, ist aber sehr interessant. Ich habe mich noch mit dem Adrian Rebe von OpenHPC unterhalten und so das gemeinsame Fazit war. Also im Vergleich zu Singularity und Co. fiel Podman eigentlich nicht mehr wirklich viel um eine interessante Alternative im HPC-Umfeld zu sein. Ansonsten Container-Runtimes für besondere Anforderungen.
29:01
Sorry, mir hat leider die Slides irgendwie verschoben, als ich von PowerPoint irgendwie auf OpenOffice bin. Im PDF ist es schön. Was es noch gibt, ist irgendwie G-Wiser. Das können wir ziemlich kurz machen. Das ist im Prinzip auf Basis von dieser OCI implementiert, eine kompatible Runtime von Google mit dem besonderen
29:21
Feature, ja, das ist im Prinzip sowas wie User-Mode Linux ist. Fefe hat das ziemlich schön zusammengefasst. Ich zitiere jetzt einfach mal, das ist von der Idee her sowas wie User-Mode Linux. In Köln lernt Wirklichkeit ein User-Space-Prozess ist, der andere Prozess in diesen Wald-Docker-Container laufen lässt und den System-Calls emuliert, also nicht durchraucht,
29:40
sondern nachbaut im User-Space, im Go. Wenig überraschend verlieren Sie wenig Worte über die Features und keine Worte über die Performance einbußen. Dazu noch irgendwie das ganze Thema, warum man im Go-Code mehr vertrauen sollte. Als irgendwie im Linux-Köln und so weiter. Also aus Performancegründen HPC-Umfeld?
30:00
Nee, eher nicht so. Ansonsten Scone, wer irgendwie Intel SGX irgendwie Hardware hat und irgendwie eine Secure Enclave nutzen möchte. Grundsätzlich, ja, von der Idee her fände ich das jetzt spannend, wenn ich zum Beispiel einen großen Cluster habe und auch der Fremdarbeitskräfte drauf haben möchte und dann sowas irgendwie nutzen möchte.
30:20
Aber ansonsten Problem von ehemals Docker inzwischen irgendwo bei Google gelandet, meine ich, hat das mal schön zusammengefasst. Anything that passes system calls in and out super fast will be super slow with this. Also auch nicht so wirklich die HPC-Lösung. Ansonsten. Ach so, genau, was ich noch sagen wollte, unter Security
30:40
Aspekten mit Spectre und Go ist es inzwischen auch relativ broken. Zwischenfrage. Ja, ich würde wetten, die haben in absehbarer Zeit, wenn sie nicht schon was haben, irgendwie was eigenes. Frage wiederholen, ob das irgendwie Intel only ist. Also Intel SGX ist Intel
31:02
only. Keine Ahnung, AMD hat da bestimmt auch was eigenes. Aber wir haben seit irgendwie, wir haben momentan zum ersten Mal beim Kunden seit irgendwie Größenordnung zehn Jahre neue AMD-Systeme. Ich freue mich drauf. Insofern bin ich nicht ganz auf dem aktuellsten Stand, was irgendwie in dem Umfeld
31:21
irgendwie AMD jetzt alles kann. Ansonsten, Vollständigkeit halber noch die Cutter-Containers. Das weiterführende Material vom Udo gibt es einen ziemlich coolen Artikel bei der AIX. Und Gedanke ist im Prinzip Technologie aus dem Intel Clear Container Project, um irgendwie den Hypervisor Run V zu kombinieren und im Prinzip
31:42
leicht wichtige virtuelle Maschinen zu schaffen, die sich wie Container verhalten. Aber alles mit Hypervisor im HPC-Umfeld möchte man nicht unbedingt haben, deswegen auch eher so nicht unbedingt die Optimal-Lösung. Wie gesagt war es einfach nur der Vollständigkeit halber, um nochmal so einen Rundumschlag über die Container-Runtimes
32:00
zu geben. Ansonsten HPC-fokussiert. Was gibt es da? Da ist so der Platz. Erstmal die gemeinsamen Eigenschaften. Deren Ziel ist im Prinzip einen Container auf einem Host laufen zu lassen, weil HPC- Anwendung typischerweise einfach die Host-Resourcen komplett ausfüllen können, beziehungsweise idealerweise
32:22
über mehrere Hosts. Also irgendwie ein Job, der sich über ein Dutzend oder mehr Systeme verteilt, ist jetzt nicht wirklich ungewöhnlich. Nachteil daran ist, für die Container-Runtimes ist Enterprise nicht der typische Use-Case. Also die sind auch nicht unbedingt dafür ausgelegt, ganz, ganz, ganz viele kleine
32:42
Container-Runtimes auf einem Host zu starten. Ansonsten ist die Stoßrichtung, was die Isolation angeht, andersrum. Das heißt, man möchte eigentlich nur so wenig Isolation anbieten, wie letztendlich nötig ist. Also Gedanke ist, man sagt,
33:00
ich vertraue den Usern im HPC- Umfeld eh soweit, dass ich manchmal mehrere User parallel auf ein System drauf lass. Idealerweise können sich die User auch gleich noch auf der Compute-Resource anwenden und so weiter. Also die ganze Isolation, die stört eigentlich nur Kosten. Im Zweifelsfall alles Performance. Wollen wir nicht deswegen eher dann so einen Change-Route-Ansatz
33:21
als Namespaces, wenn man wissen will, wie denn jetzt die Isolation ist, einfach mal ein LS-LR-Proxelf-NS einmal auf dem Host um einen Container machen und die ID's miteinander vergleichen. Und machen tut man das letztendlich nicht nur wegen dieser Vertrauensfrage, sondern eben auch um möglichst eine
33:40
durchlässige Sicht aus dem Container auf den Host irgendwie rauszulassen. Gedanke ist einfach, ich möchte auf meinen Shared Storage irgendwie zugreifen. Ich möchte auf ein Infini-Band zugreifen. Und je weniger Isolation ich da habe, macht das halt einfach einfacher. Ansonsten manchmal werden da noch nicht mal irgendwie Seagroups verwendet, weil man sagt, das ist ein Scheduling
34:01
Feature, also der Workload-Manager würde ja dann eh vielleicht irgendwie Seagroups anmachen. Dann kann er das hier jetzt auch machen. Größtenteils setzen sie auf den Docker-Image-Bild-Prozess bzw. können OCI-Kompatible Images. Weiterer Nachteil durch diese Speziallösung, die Runtimes sind in der Reihe oder sind
34:21
häufig nicht OCI-Kompatibel. Ich hatte vorhin erzählt, dass das ja eigentlich cool ist mit diesen Layered-Images. Ja, zum Starten wollen hier aber die meisten Lösungen irgendwie ein großes Squash-FS Paket letztendlich haben. Hintergrund ist der, man hat sehr häufig irgendwie ein Lasterfallsystem oder sonst
34:41
was, also was halt über mehrere, ja über mehrere Object-Storages verteilt ist. Also ich hab mal Metadatenserver und im Prinzip für jeden Image-Lehr müsste ich dann Lookups irgendwie machen auf Metadatenserver. Ist Performance-mäßig nicht so cool, deswegen ist es einfach halt einfach ein großes Blop da irgendwie rumzulegen zu haben. Ganz großer Pferdefuß
35:01
meiner Meinung nach ist die ganzen Container-Runtimes fürs HPC haben im Prinzip weniger Contributors. Andererseits aber auch weniger Lines of Code und bieten dafür halt entsprechend Unterstützung für HPC-Features. So der platzische oder das Stocker des HPC-Umfälls ist momentan Singularity.
35:23
Ist am Lawrence Lawrence Berkeley National Laboratory entstanden unter Greg Kerzer, kennt man auch ein bisschen aus dem CentOS Projekt und so seine Helden-Geschichte oder seine Legende war letztendlich, weil es bei ihm dauernd die Anwender aufgeschlagen sind und gesagt haben, ich will Bocker auf ein Klasse und er dann gesagt, nö ist nicht.
35:42
Anwender immer wieder da standen uns dann halt mit Streets und Bribes irgendwie noch probiert haben und dann gemacht, okay, ich schreibe jetzt mal selber was und was braucht denn eigentlich, okay, ihr braucht die Features, okay, haben wir dann fertig. Inzwischen ist das irgendwie auch ein relativ großes Startup, was irgendwie
36:01
kommerziellen Support irgendwie dazu bietet. Es gibt dann irgendwie halt für die Pro-User noch eine kommerzielle Version und im HPC-Umfeld ist das letztendlich das, was man irgendwie relativ häufig irgendwie antrifft. Es gibt auch ein Image-Hub, ein Hub dazu und ja, die Design-Goals.
36:21
Deswegen, also wer so aus der Cloud- und Fancy-Enterprise-Ecke irgendwie kommt und sieht dann Singularity, wird sich erstmal wundern, warum manche Entscheidungen getroffen wurden, Support für Production, Distributions und Kernel, also eher so entwickelt mit Ziel, wir haben dann auch ganz viel REL6, auf dem wir Computing machen.
36:41
Das heißt, die ganzen Sachen, die irgendwie User-Namespaces können, sind raus, weil Kernel, der das kann, ist dann erst irgendwie ab REL7 drin. Ich möchte, um das einzusetzen, meine Architektur und meine ganzen Workflows um Computing rum nicht verändern und so Sachen wie, ich möchte User-Credentials beibehalten, also sprich,
37:01
wenn ich Root im Container sein möchte, muss ich erstmal Root auf dem Host sein, ansonsten bin ich halt nur der User, der ich auf dem Host bin und ansonsten möglichst Burry Container Roast Separation, also einfach dadurch, dass ich an die ganzen Ressourcen reinkomme, ansonsten eigenes Imageformat, eigener Bauprozess, das überspringen wir jetzt hier mal
37:21
und ja, als Privilege Escalation Methode, haben Sie sich ein ZUID-Binary überlegt. Sorry, ist so. Habe ich mir auch nicht überlegt, warum dem so ist, gibt's weiter für in der Literatur zu, also Problem ist halt einfach, du musst halt irgendwie diesen Wessel halt machen,
37:41
beziehungsweise halt das Ding gestattet bekommen und so weiter und genau, und so über den Ansatz können wir halt einfach relativ viel mit dem Host letztendlich sharen, was man halt einfach im Enterprise-Markt auch nicht unbedingt haben möchte. Ansonsten, wie gesagt, ein eigenes Imageformat mit 3.0 hat sich das wieder geändert, also im Prinzip immer, wenn es ein neues Imageformat gibt,
38:00
zählen so die Major-Releases hoch. Genau, was wollte ich jetzt gerade noch hier an der Stelle erzählen? Genau, Martin, da kannst du in Ruhe alles nachlesen, welche Option es gibt. Es ist einfach, dass du irgendwie das nur für den Root-User letztendlich zulässt, dass du irgendwie einen Root-Prozess hast. ZUID, du kannst
38:21
Usernamespaces nehmen, du kannst irgendwas über Capability machen und da haben sie erklärt, warum sie das so machen wie. Also inzwischen unterstützen sie auch den Ansatz über Usernamespaces. Das Problem ist halt, wenn du diese Features möchtest, dass du halt quasi deinen kompletten Host irgendwie drunter siehst, wird dann halt mit Usernamespaces deutlich schwerer, als wenn du schon über ZUID gehst.
38:40
Ansonsten zumindestens der zweier Codezweig ist von Susi irgendwie mal durchauditiert worden, war damals ganz gut, weil ja Go so toll ist in dem Umfeld, haben sie jetzt alles nochmal in Go neu geschrieben und insofern der Audit ist irgendwie wohl pending bzw. also wird gerade nochmal dran gearbeitet.
39:02
Ja, genau, ansonsten wie gesagt, adressieren sie einen Enterprise Computing-Markt, sind dran irgendwie sie stärker mit Kubernetes irgendwie zu integrieren, haben das Konzept der Data Containers irgendwie reingebracht. Also ich habe Immutable Base Image und ich habe persistente Overlays irgendwie drüber mit dem Hintergedanken, dass ich halt die einzelnen Image-Bereiche
39:21
individuell check-summen kann und hinterher dann auch verifizieren kann. Network Namespaces, also ein Hintergedanke ist, ich habe irgendwelche Forschungsergebnisse, ich gebe meine Rohdaten raus, ich gebe die Applikation raus. Das wird halt einfach durch diese Data Containers hier begünstigt. Ansonsten Network Namespaces-Support
39:41
haben sie jetzt mal reingebracht, Z-Group-Support haben sie reingebracht und das war jetzt bei der Version 3.0, aktuell ist die 3.2, die 3.3 ist irgendwie gerade in der Mache und weiterführendes Material, also es gibt irgendwie ein Paper, es gibt eine Webseite mit inzwischen relativ guter Dokumentation und wer da wirklich mal reinschnuppern möchte von Greg, gibt es vom Intel HPC-Developer
40:02
Conference irgendwie ein Workshop mit einem riesengroßen Berg an Folien. Ansonsten ja, Stichwort ChangeRoute, wir sind bei Shifter, wurde am NRSC entwickelt, irgendwie 2015 rausgebracht und Fokus ist irgendwie die großen Cray User, also das NRSC
40:20
in Amiland, CSCS an der ETH Zürich, ja, fällt in die Kategorie weniger häufig entwickelt, also die aktuelle Version ist vom April 2018, deren Ansatz sieht so aus, einfach, um das mal irgendwie nochmal gezeigt zu haben, man nimmt irgendwie Docker Hub Image, macht dann Tablet raus oder empackt den ganzen Image Tree,
40:42
legt den auf dem Shared FS ab, macht da dann ein Loop Device davon und macht dann am Schluss Final in ChangeRoute rein. Vorteil ist, ich habe meine ganzen User Credentials und so weiter, wie auf dem Host, aber ich habe trotzdem so was wie Images benutzt, also Gedanke war, ja, warum man das so gemacht hat, sie fanden die Idee
41:00
von Container super gut, aber haben halt einfach die Idee von einer Container Runtime ziemlich blöd gefunden und das war halt so der Ansatz. Dadurch, dass sie das halt so machen können, so halt gut mit CUDA, MPI, Integration mit den Workload-Managers und so weiter, aber ich habe halt zusätzlich noch, wenn ich ein Image bereitstellen möchte, halt den docker,
41:20
den typischen Docker-Image-Spielprozess und was so die Verbreitung angeht, also Fokus ist da ganz klar auf Cray System, da sieht man übrigens diese schönen Frontblenden, die ich meinte, wenn man noch Geld irgendwie über hat, wenn man ein Cluster gekauft hat und ansonsten, das ist deren Stoßrichtung, gibt es auch weiterführende
41:40
Literatur und hm, genau, auch noch so, wir machen auch mal noch unsere eigene Runtime, weil es so irgendwie hip ist, Charlie Cloud, das ist hier bei den Los Alamos Jungs irgendwie entstanden, die uns auch schon die Atombombe gebracht haben, haben auch gedacht, wir bringen euch noch Charlie Cloud, gibt es seit
42:00
2015, 2017 ziemlich viel Aufmerksamkeit bekommen, was cool dran ist, sind irgendwie nur grob 800 Zeilen Code, also als Referenz irgendwie selbst ein Rocket hat irgendwie 52.000 Zeilen, aktuelle Versionen ist von Mai 2019, die verwenden die Usernamespaces, um die Container
42:21
quasi bereit zu stellen, können auch Docker-Images müssen aber auch wieder umgepackt werden und so weiter, da gibt es entsprechende Kommandos dazu, brauchen deswegen aber halt auch ein RHEL 7, also hat man zwar meistens im HPC-Umfeld inzwischen, aber nicht unbedingt zwingend, ja HPC-Verbreitung, ja, aber nicht so
42:41
unglaublich viel, wie man es jetzt unbedingt erwarten würde, ich hatte es selber noch nicht entfingern, also weiterführende Literatur gibt es jetzt endlich da, einmal den Foliensatz von Michael Jennings und noch irgendwie ein Paper, irgendwie von Alisa 2017 dazu, und ja, die Lösung
43:01
YouDocker, finde ich jetzt aus einwanderer Sicht relativ spannend, weil bietet mir die Möglichkeit, dass ich im Prinzip die komplette Installation als End-User durchführe, ich brauche keinerlei Administrator-Privileges einerseits, um die Runtime zu installieren, andererseits, um irgendwie ja, die Container zu starten,
43:22
entstanden ist das Ganze aus dem Indigo Data Cloud EU-Projekt, gibt es seit 2016, aktuelle Version ist auch schon von November 2007, 2018, und die machen im Prinzip die Isolation dadurch, oder Isolation durch P-Route,
43:40
Fake-Change-Route und inzwischen wohl auch irgendwie noch Run-C und Singularity, die letzten beiden habe ich nicht ausprobiert, aber es ist halt total cool, weil ich mir als Anwender, wenn ich irgendwie eine Applikation, die halt auf einem Rell-System laufen soll, ich brauche aber nur Ubuntu, damit das tut, mir halt einfach mein entsprechendes Image ziehen kann und das halt an den Start bekommen kann,
44:01
ohne dass ich irgendwie jemals mit dem Admin telefonieren muss, bieten auch eine eigene, eine Docker-ähnliche, ja, eine Docker-ähnliche Interface und was, noch 15 Minuten, da kann ich ja noch ganz gemütlich erzählen, das wollte ich jetzt gerade sagen, genau, also Key-Feature durch ein End-User deploybar
44:20
und irgendwie auch einsetzbar und halt starker HPC-Fokus und das ist im Prinzip ein Installer, den man mal geschwind durchläuft und der primär irgendwie in Python als Dependency draufschmeißt. Wenn ich das Ganze mit Q-System kombinieren möchte, brauche ich irgendwie Bidocker zur Integration, aber so wirklich durchgesetzt
44:40
hat sich das auch nicht, also ist halt ein Forschungsprojekt und ich bin mir da ehrlich gesagt, nicht so ganz sicher, wie es damit weitergeht, wenn dann irgendwie mal dieses Forschungsprojekt ausgelaufen ist. Klar, ist alles Open Source, aber fällt eher unter die Kategorie der kleineren Vertreter, da kommen wir gleich aber noch dazu. Ansonsten, aus der Ecke, wir bauen uns unsere eigene Container-Engine,
45:00
ist Sarus, haben momentan noch kein eigenes tolles Logo, sind aber auch noch irgendwie ganz knapp vor der Version 1.1.0 und sind an CSCS, wir erinnern uns, das waren die, die auf Shifter einsetzen entstanden, das ist das Schweizer Nationale Supercomputing Center, ist unter der BSD-License,
45:21
ist mit einer Vielzahl von OCI-Standards kompatibel, also einmal die Distribution Specification, das heißt, auch Sie können Docker-Images irgendwie von der Registry irgendwie runterpullen, solange dem Standard genügt, unterstützen Sie das OCI-Image-Format, das heißt, ich kann dann auch mit den entsprechenden Images, die ich vielleicht bei einer anderen Runtime irgendwie einsetzen möchte,
45:41
andrücken und genau, setzen auf die Runtime-Specification von OCI, das heißt, als Container Executor setzen Sie auf Run-C, auch die fokussieren sich einfach von dem Hintergrund, dass es von hier dem Supercomputing Center kommt auf HPC, das heißt, können entsprechende Komponenten über OCI-Hooks
46:02
unterstützen, haben wohl auch Features drin, um irgendwie mit Diskless Notes umgehen zu können und eben halt parallel in der Tie-System, sowie halt Workload-Managern und genau, auch hier wieder eine Docker-ähnliche Syntax, dass sich der User möglichst minimal umstellen muss, Installation wird als einfach beworben, also es ist so neu, ich hab's selber
46:20
noch nicht gesehen, muss mich da ein bisschen auf die Doku verlassen und genau, setzen halt, oder versuchen halt möglichst viel auf Third-Party-Code irgendwie einzusetzen, der schon besser abgehangen ist, als das für Sie bringen. Ich hab da mal irgendwie auf der ISC im Sommer mal irgendwie einen der Entwickler angehauen, warum sie denn jetzt schon wieder eine eigene Runtime bringen,
46:41
vor allem wenn sie doch irgendwie nur so halb hier mit Shifter irgendwie im Bett sind und ja, ich hab dann gemeint, also warum denn hier nicht irgendwie Charlie Cloud oder so was, weil ihr macht dann auch irgendwie mit, im Prinzip bietet ähnliche Features wie aus der Ecke und ja, Charlie Cloud hat dann noch ein paar Features gefehlt, die sind dann irgendwann
47:00
in der späteren Release dann doch reingekommen und so weiter und, aber so, es war einfacher, jetzt was eigenes zu schreiben, als irgendwie bei den anderen mitzumachen. wie es halt oft so ist, aber deswegen gibt es halt noch mal eine eigene Runtime. Setzen auch wieder auf Squash FS Images, um irgendwie, ja, Parallel File System
47:21
Friendly zu sein und ansonsten halt Unterstützung für diverse HPC-Eigenheiten und ja, im HPC-Umfeld sieht das eigentlich relativ spannend aus, ist aber einfach zu neu, um irgendwie was sagen zu können, also es gibt es jetzt kein halbes Jahr und irgendwie die 1.0-Version ist noch nicht draußen. Ansonsten Doku ist auch eher mau,
47:40
aus der GitHub-Seite gibt es einen Foliensatz bzw. zwei Foliensätze, das ist der größere der beiden, es gibt noch kein Paper, das ist aber momentan in der Mache, insofern kann durchaus für HPC irgendwie noch final dann irgendwie spannend werden, um irgendwie mal eine Alternative zu Singularity zu haben. Ansonsten ja, Vergleich,
48:03
Moment Martin, ich hatte eigentlich mal letztes Jahr irgendwie vor, einen eigenen Vergleich zu machen, dann sucht man halt rum und guckt sich mal existierende Vergleiche an, dabei fällt eins auf. Es gibt sehr viele Vergleiche, jeder, der irgendwie eine Runtime auf den Markt schmeißt, sagt irgendwie,
48:20
oh, meine ist ja viel, viel besser und wir vergleichen das alles mal so, dass das irgendwie schön hinkommt. Das heißt, die Vergleiche sind einfach irgendwie relativ biased, teilweise sogar ungenau. Einfach vor dem Hintergrund zeige ich auf der nächsten Folie, teilweise ist halt einfach auch die Feature-Unterstützung sehr, sehr stark versionsabhängig,
48:41
denn teilweise wird halt Docker irgendwie noch als der Monolith und nicht hier. Wir haben ContainerD, wir haben RunC gesehen, wo sich dann manche Eigenheiten halt einfach anders zu verhalten und ansonsten muss man teilweise auch aufpassen mit der Negation. Ansonsten, warum meine Runtime irgendwie besser ist, ist hier so ein schönes Beispiel aus dem Singularity-Vergleich.
49:01
Also, wer hätte das erwartet, das hier ist aus einem Singularity-Dokument, das bei Singularity natürlich überall grün dran steht. Ansonsten, teilweise sind die Vergleiche auch einfach irgendwie falsch. Ist so Zeug wie, das war jetzt aus einer neutralen, aus einem neutralen Vergleich, da geht es drum, wir möchten die Images
49:21
oder den Imageinhalt vergleichen. Steht bei fast allem irgendwie ein No dran. Die setzen aber in der Regel auf gleiche Images. Das heißt, wenn ich also irgendwie mit sowas wie Clare irgendwie ein Image-Scan von Docker-Image oder aus die I-Image machen kann und kann dieses Image dann auf Shifter drauf packen, dann müsstest du eigentlich an der Stelle ein deutliches Yes stehen
49:41
oder auch bei U-Docker tut es aber nicht. Also muss man ziemlich aufpassen. Und da ich mich da dann nicht unbedingt in den Nesseln setzen wollte, da habe ich eher so den zahlengetriebenen Ansatz irgendwie mal gemacht und habe mir halt mal GitHub angeguckt. Wie denn da so die Entwickler-Statistiken sind, das war für die ISE letztes Jahr. Was dabei relativ spannend ist,
50:01
ist der Vergleich zwischen Docker, also hier vertreten durch Run-C versus Singularity. Wenn man sich die Zahl der Contributor anguckt, dann sind halt irgendwie, ja, machen bei Docker halt einfach dreimal so viele Leute mit. Was aber ziemlich cool ist, ist Singularity, also was Commits und Releases angeht, haben sie deutlich aufgeholt.
50:23
Was auch noch interessant ist, wenn man sich die Vorjahreszahlen anguckt, dann ist bei Run-C einfach so ein Stück weit ausentwickelt. Also die Entwicklerzahlen sind nicht mehr so stark eingestiegen. Commits sind auch eher so deutlich abgeflacht. Die Release-Anzahl ist, ja, man macht halt weiter, aber es gibt jetzt
50:41
nicht mehr Gefühl, so viel zu tun. Auf der anderen Seite Singularity. In einem Jahr irgendwie dreimal so viele Releases, doppelt so viele Developers und doppelt so viele Commits. Also insofern das ist deutlich stärker am Boom. Das heißt irgendwie Docker und ja, Run-C ist einfach irgendwie stable. Singularity wächst deutlich.
51:00
Und was man auch ganz klar sagen muss, sowas wie Charlie Cloud, Shifter, U-Docker und eben auch Sarus, wenn man sich halt mal anschaut, dann machen in der Größenordnung vier bis zehn Leute irgendwie mit. Muss man sich gut überlegen, ob man das dann irgendwie einsetzen möchte. Ansonsten, da Kunden total auf Kubernetes abfahren und noch kurz eine Folie dazu.
51:21
Also für Mixed Load Works super spannend, für Machine Learning und dem ganzen Kram ziemlich interessant. PC-Anforderungen sind da halt teilweise etwas anders, aber gibt es momentan ziemlich viel Arbeit in dem Umfeld. Singularity ist da stark dran, LSF ist da stark dran, also der IBM Workload Manager. Das Problem ist einfach,
51:41
ich habe so Sachen wie dynamisches Ressourcenskalieren ist halt mit HPC in der Regel nicht. Ich habe einen festen Ressourcenverbrauch. Fehlertoleranz ist auch eher ein bisschen schwierig. Ich habe auch weniger Short-Lift Workloads, sondern eher halt das Problem, dass meine Jobs Tage, Wochen oder gar Monate laufen. Ich habe auch nicht irgendwie viele Jobs auf einem Note,
52:01
sondern einen Job auf N-Notes verteilt und gibt durchaus Szenarien, wo ein User irgendwie direkt drauf zugreifen möchte und so weiter. Und so Aspekte in Enterprise und für wenn ich irgendwie UID, GroupID, Kerberos, SharedFS Einbindung haben möchte, wird ein bisschen schwierig. Der Scheduler ist weniger expressive als irgendwie HPC Scheduler.
52:21
Also sprich, wenn man sich der komplexen Queues Sachen überlegt hat, wird es teilweise auch schwierig. Uwe hat das mal als nicht unbedingt ideal für Batch Workloads beschrieben. Das heißt, große Anzahl von Jobs kann auch etwas schwierig werden. Und ansonsten, ja, da ist momentan sehr viel Drive irgendwie drin,
52:40
um diese zwei Welten so ein bisschen miteinander zu verheiraten. Also schauen wir mal in zwei Jahren, wie es da weitergeht. Ansonsten, die letzten fünf Jahre, so die Standardfrage war immer am Anfang, war so, wer hat denn schon mal von Linux-Containern gehört? Und inzwischen hat sich das halt einfach dahin entwickelt, dass die meisten eigentlich wissen, was Container Runtime sind,
53:00
wie man die ganzen schedult, was HPC da für Eigenheiten hat und so weiter. Und Container sind einfach für viele Workloads inzwischen in großen Data-Centern verbreitet, hat auch neue Möglichkeiten über Obercloud für irgendwie Cloud-basiertes HPC irgendwie um die Ecke gebracht. Und ansonsten noch ganz kurz
53:21
einmal in die Zukunft geguckt. Singularities, Docker für HPC, weiß ich nicht. Also ich habe das Gefühl, bei Podman entsteht da doch eine gewisse Konkurrenz. Auch wenn HPC nicht unbedingt zwingend der Kernbereich von Red Hat irgendwie ist, da muss man mal gucken. Ich denke mal, ganz falsch liegt man damit nicht. Vielleicht nicht unbedingt Dockerized,
53:41
sondern eher Containerized. Welche Runtimes dann aber final wird, muss man dann letztendlich einfach schauen. Ja, Image, das überspringen wir mal, dass man sich auch Gedanken darüber machen sollte, was man in seinen Container-Images drin hat. Und insofern, falls Chef am Montag fragt, was ich erzählen haben sollte. Also Container für HPC ist cool,
54:01
kann viele Probleme lösen. Dadurch durch diese OSI-Geschichte hat er eine deutliche Standard, eine Stabilisierung, beziehungsweise Austauschbarkeit stattgefunden. Und ja, Docker ist dieses Feld irgendwie sehr, sehr stark am vernachlässigen. Haben sie einfach aus Erfahrung, aus Interesse, beziehungsweise auch aus Aussagen heraus aus diesem Markt.
54:20
Und wer unbedingt HPC und Kubernetes machen will, ist momentan einfach ein bisschen schwierig. Und ansonsten wäre ich jetzt durch. Ansonsten bin ich heute und morgen da und auch irgendwie über Bratwurst oder Pult, Beef, Pork, was auch immer, irgendwie gerne anzuhauen. Und ansonsten Kontaktdaten
54:40
stehen auch noch im Folien-Satz. Den gibt's dann hinterher auch. Und dann bedanke ich mich auf jeden Fall mal für die Aufmerksamkeit. Und ansonsten gerne einfach anhauen.
55:06
Sonst kann ich einfach auch die Frage nochmal wiederholen, wenn ich dran denke. Ja? Wenn die Isolationsfeatures von den Container-Runtimes nicht so genutzt werden im High-Performance-Computing, warum ist dann so etwas wie Snap oder Flatpak nicht interessant,
55:20
wenn das sozusagen zum Bundlen der Dependency ist? Ja, aber unter REL7 Snap? Also da ist es deutlich, ja, ist aber Tatsache. Also wenn ich mir anschaue, wie unsere Systemverteilung ist, wir haben momentan noch eine REL5-Maschine. Ich schäme mich dafür. Ansonsten, der Großteil ist halt einfach noch auf REL6. Und die Neuinstallationen sind zwar alle mit REL7,
55:42
aber du bist da einfach nicht so bleeding edge unterwegs. Also Sachen können durchaus auch interessant sein. Aber momentan ist einfach Container für viele einfacher anstatt zu kriegen. Okay. Weitere Fragen?
56:01
Finden Sie, wenn man seinen Nutzern Software zur Verfügung stellt, sollte man die direkt kondernisieren oder einfach aufs parallele Fallsystem packen? Die Frage ist, was sich anbietet. Also wenn ein User irgendwie Alltag mit einer neuen Software ankommt oder sowas und hier mal schnell einen neuen Snapshot oder sonst irgendwas, dann würde ich sagen, User delegieren, wo es halt geht,
56:21
beziehungsweise was halt die Verträge oder sonst was zulassen. Also im akademischen Umfeld wäre ich da eher entspannt. Enterprise-Umfeld wäre nicht unbedingt, aber es wird halt teilweise einfach schwierig, wenn es darum geht. Du hast irgendwie 20 Versionen der gleichen Applikation und wir haben aus der Historie raus, so halt alle möglichen Sachen,
56:41
irgendwelche Environments und irgendwelche Start-up Scripts, die dir das alle passend bieten. Aber mit Containern kann das durchaus spannend sein. Ansonsten, um auf deine Frage zurückzukommen, es kommt auf die Umgebung an, würde ich sagen. Wie groß sie ist und wie viel Aufwand, was sie letztendlich macht. Also wenn das alles irgendwie Software ist, die ich ohne Probleme irgendwie gut verteilen kann,
57:01
ja, klar, ohne Schmerz irgendwie auf Container verzichten. Aber Container kann halt für solche Umgebungen, wo es schwierig ist, eine Lösung sein. Vielen Dank. Gern geschehen. Weitere Fragen? Kurz und danach die letzte Frage.
57:20
Okay. Und zwar, wie ist das mit dem Multi-Architecture-Support? Also teilweise ist es ja so, dass bestimmte Performance-Umgebungen noch mit Power laufen, oder? Gibt es? Ja, haben wir beim Kunden jetzt nicht im Einsatz und der Groß ist irgendwie auf Intel-Architektur, aber Container-Unterstützung gibt es auf anderen Architekturen. Ich kann dir jetzt gerade bloß nicht konkret sagen,
57:42
wie das Docker auf, keine Ahnung, Power läuft oder sowas. Also ich weiß, dass Docker und Run-C das supporten. Ich hätte mich halt gefragt, ob es in Rarity oder sowas das auch können. Kann es? Hätte ich jetzt auch erwartet, aber... Wir machen noch eine Frage.
58:03
Wie ist der Support für Checkpoint-Restart bei diesen HPC-Container-Lösungen? Ist das einfach, oder? Nö. Kurz Antwort ist nö. Also wir haben nach wie vor ziemlich viele Applikationen, also völlig losgelöst von Containern, Applikationen im Einsatz,
58:21
die nicht mal schaffen irgendwie so aus sich heraus irgendwie einen Checkpoint-Restart irgendwie zu machen, wo dann halt der Job, also selbst wenn man einen Downtime hat und das alles irgendwie geplant ist und halt einen Checkpoint machen kann, wo dann einfach halt der Lauf weg ist. Insofern, Creo könnte man da, also diese Checkpoint-Restore in User-Space
58:40
könnte man da durchaus irgendwie mal einsetzen, aber haben wir momentan jetzt nicht. Wir haben auch relativ wenig Container-Einsatz. Langsam fangen die Kunden an danach zu fragen, aber ist momentan zumindest bei den Enterprise-Kunden im HPC-Umfeld eher noch so, hm, machen wir mal langsam.
59:01
Du erwähntest vorhin das Thema Layered Images. Ja. Steht das im HPC-Bereich überhaupt eine Rolle und was sagt die Performance dazu? Nein. Die meisten setzen ja irgendwie, habe ich ja erzählt, auf ein eigenes großes Pfeil sozusagen einfach, weil paralleles Pfeilsystem, Metadaten, Lookups sparen und so weiter. Aber ich kann ja im Prinzip hergehen
59:20
und mir mein Image erstmal gelayert zusammenbauen und mir das so schön irgendwie rausgenerieren, wie ich es irgendwie halt haben möchte und wird dann halt im nächsten Schritt sozusagen gewandelt. Aber, also, dass ich halt irgendwie ein Layered Image irgendwie direkt auf den HPC-Klasse schmeiße, ist eher dann weniger, ist eher die Ausnahme. Gibt es noch eine letzte Frage?
59:41
Ansonsten einfach draußen irgendwie bei Kaffee anhauen. Martin könnte das dann auch später noch im Hotel klären. Also, man kann ja noch im Flur bzw. in den Gängen noch ein bisschen diskutieren. Ja, erstmal vielen Dank. Gern geschehen. Und dann geht es in der Füllschnecke knapp weiter.