Ganeti
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 3 | |
| Anzahl der Teile | 59 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung 2.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/19632 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FrOSCon 20143 / 59
1
2
3
4
8
11
21
23
26
29
30
34
35
36
37
38
39
41
42
43
45
46
50
52
53
54
56
57
58
00:00
Open SourceFreewareVirtuelle RealitätKnotenmengeInformationsspeicherungKinematikTermCluster <Rechnernetz>BildschirmmaskeVirtuelle MaschineInstantiierungPunktDienst <Informatik>Spezifisches VolumenNatürliche SpracheQuick-SortAutomatische HandlungsplanungCoxeter-GruppeInformationsspeicherungXMLUMLVorlesung/KonferenzComputeranimation
01:05
Interface <Schaltung>BetriebsmittelverwaltungHypercubeInformationsspeicherungDatenverwaltungErweiterte Realität <Informatik>Gleitendes MittelDatenverwaltungMereologiep-BlockDatenreplikationInformationsspeicherungDifferenzkernBitrateInterface <Schaltung>AggregatzustandWeg <Topologie>PhysikalismusServerVorlesung/KonferenzComputeranimation
01:47
Interface <Schaltung>BetriebsmittelverwaltungInformationsspeicherungDatenverwaltungAusgeglichener BaumHypercubeRelationentheorieMereologieResultanteInstantiierungQuellcodeCluster <Rechnernetz>Ausgeglichener BaumLeistung <Physik>KontrollstrukturInformationsspeicherungHalbleiterspeicherMAPATMMini-DiscComputeranimationVorlesung/Konferenz
02:45
WinkelRechenwerkElektronische UnterschriftCluster <Rechnernetz>ValiditätInteraktives FernsehenInformationSoftwareInstantiierungNetzadresseAdressraumMini-DiscDatenreplikationComputeranimationVorlesung/Konferenz
03:52
InstantiierungComputerspielInstantiierungMini-DiscBildschirmmaskeNetzadresseInformationsspeicherungZweiDienst <Informatik>NetzbetriebssystemDefaultMAPGeradeComputeranimationVorlesung/Konferenz
04:46
SkriptspracheInstantiierungVirtuelle MaschineNetzbetriebssystemInterface <Schaltung>InformationVariableProgrammierumgebungTaskZahlenbereichVerzeichnisdienstInstantiierungInteraktives FernsehenSkriptspracheMini-DiscComputeranimationVorlesung/Konferenz
05:50
SoftwarewartungCASE <Informatik>Endliche ModelltheorieMögliche-Welten-SemantikSoftwarewartungInstantiierungATMComputeranimation
06:36
SoftwarewartungLokales MinimumRechenwerkEntscheidungstheorieInstantiierungSummengleichungCluster <Rechnernetz>BitInformationAggregatzustandMereologieKlasse <Mathematik>WellenpaketVorlesung/KonferenzComputeranimation
07:38
SoftwarewartungATMTaskLeistung <Physik>SoftwarewartungDemoszene <Programmierung>RichtungSummengleichungBitsinc-FunktionParametersystemDämon <Informatik>SprachsyntheseProtokoll <Datenverarbeitungssystem>Domain <Netzwerk>SocketComputeranimationVorlesung/Konferenz
08:37
GravitationsgesetzTaskCLIInformationBetragsflächeMini-DiscKnotenmengeDigitaltechnikProzess <Informatik>VerkehrsinformationDomain <Netzwerk>Dämon <Informatik>Arithmetische FolgeInformationUmwandlungsenthalpieInterface <Schaltung>GeradeVorzeichen <Mathematik>MultiplikationsoperatorDatenverwaltungDeskriptive StatistikGüte der AnpassungPunktShape <Informatik>RelationentheorieVorlesung/KonferenzComputeranimation
09:41
TaskInverser LimesBetragsflächeInformationProzess <Informatik>Elektronische PublikationMini-DiscArithmetisches MittelGruppenoperationFormation <Mathematik>Dämon <Informatik>WellenlehreMonster-GruppeRechter WinkelInverser LimesZahlenbereichCASE <Informatik>PunktThreadSoftwaretestDatenflussInstantiierungVorlesung/KonferenzComputeranimation
10:44
TaskBetragsflächeInverser LimesMAPBitrateKnotenmengeOrdnung <Mathematik>ZahlenbereichNichtlinearer OperatorInstantiierungBitrateBitProzess <Informatik>Parallele SchnittstelleLaufzeitfehlerCoprozessorSchnittmengeKanalkapazitätBestimmtheitsmaßMultiplikationsoperatorHyperbelverfahrenVorlesung/KonferenzComputeranimation
11:58
RFIDTaskBetragsflächeKonfigurationsraumKnotenmengeMathematikNichtlinearer OperatorInstantiierungEreignishorizontDomain <Netzwerk>MultiplikationsoperatorKonfigurationsraumMini-DiscDeskriptive StatistikAggregatzustandProzess <Informatik>TermVorlesung/KonferenzComputeranimation
12:50
DämpfungTaskKonfigurationsraumKnotenmengeBetragsflächeKonfigurationsraumAggregatzustandProzess <Informatik>FeuchteleitungAnnulatorInstantiierungMathematische LogikDämon <Informatik>Kontextbezogenes SystemSpezifisches VolumenVorlesung/KonferenzComputeranimation
13:48
KonfigurationsraumTaskBetragsflächeFehlermeldungMAPAggregatzustandKonfigurationsraumFehlermeldungDämon <Informatik>Kategorie <Mathematik>Wiederherstellung <Informatik>ZeitrichtungSystemverwaltungBitrateProzess <Informatik>Kernel <Informatik>ComputeranimationVorlesung/Konferenz
14:36
Weg <Topologie>ProgrammverifikationGruppenoperationCASE <Informatik>Prozess <Informatik>Weg <Topologie>TaskNichtlinearer OperatorParallele SchnittstelleGruppenoperationExogene VariableComputeranimationVorlesung/Konferenz
15:22
ProgrammverifikationGruppenoperationInstantiierungParallele SchnittstelleWeg <Topologie>DatenverwaltungProzess <Informatik>InstantiierungIntegralFreewareExploitComputeranimation
16:11
Weg <Topologie>MereologieMailing-ListeQuellcodeBildgebendes VerfahrenKlasse <Mathematik>Stabilitätstheorie <Logik>Weg <Topologie>Prozess <Informatik>Mailing-ListeQuellcodeZeitstempelMusterspracheMaschinenschreibenNichtlinearer OperatorVorlesung/KonferenzComputeranimation
16:55
Weg <Topologie>MereologieMailing-ListeQuellcodeWärmeausdehnungBitrateMaschinenschreibenGruppenoperationLeistung <Physik>KonstanteProzess <Informatik>Dämon <Informatik>PunktVererbungshierarchieSchnittmengeInverser LimesBitrateWeg <Topologie>Computeranimation
17:36
PrimzahlzwillingeBitrateWeg <Topologie>MereologieMailing-ListeQuellcodeWärmeausdehnungInverser LimesOrdnung <Mathematik>RechenzentrumGruppenoperationZahlenbereichNichtlinearer OperatorInstantiierungInformationsüberlastungAdditionTaskInverser LimesBitrateWeg <Topologie>Vorlesung/KonferenzComputeranimation
18:23
MereologieWeg <Topologie>BitrateMailing-ListeQuellcodeWärmeausdehnungInverser LimesGruppenkeimBildschirmmaskeInverser LimesBitrateZeichenketteProzess <Informatik>GruppenoperationMatrizenrechnungLastSoftwarewartungInstantiierungMultiplikationsoperatorZahlenbereichRechter WinkelVorlesung/KonferenzComputeranimation
19:03
KnotenmengeGleichheitszeichenInstantiierungProtokoll <Datenverarbeitungssystem>BetriebsmittelverwaltungAlgorithmusEntscheidungstheorieProzess <Informatik>InstantiierungWeg <Topologie>MathematikDeskriptive StatistikProgrammierungTaskZahlenbereichSummengleichungMessage-PassingInterface <Schaltung>Affiner RaumCoxeter-GruppeAuswahlverfahrenVorlesung/KonferenzComputeranimation
20:14
InstantiierungKnotenmengeGleichheitszeichenProtokoll <Datenverarbeitungssystem>BetriebsmittelverwaltungAlgorithmusEntscheidungstheorieAuswahlaxiomProgrammbibliothekInstantiierungSummengleichungCluster <Rechnernetz>BetriebsmittelverwaltungInzidenzalgebraEntscheidungstheorieResultanteAutomatische HandlungsplanungVorlesung/KonferenzComputeranimation
20:56
Folge <Mathematik>InstantiierungKnotenmengeGleichheitszeichenProtokoll <Datenverarbeitungssystem>BetriebsmittelverwaltungAlgorithmusEntscheidungstheorieAuswahlaxiomParallele SchnittstelleFehlermeldungInstantiierungAuswahlaxiomServerSummengleichungBildschirmmaskeStrategisches SpielFehlermeldungAdditionBetriebsmittelverwaltungMonster-GruppeVorlesung/KonferenzComputeranimation
22:13
InstantiierungParallele SchnittstelleKnotenmengeFehlermeldungMathematikInstantiierungZahlenbereichAutomatische HandlungsplanungCASE <Informatik>Mailing-Listep-BlockMechanismus-Design-TheorieZentrische StreckungNichtlinearer OperatorWeb SiteVorlesung/KonferenzComputeranimation
23:22
InformationsspeicherungMaßstabProgrammbibliothekClientBitREST <Informatik>DatenverwaltungProgrammbibliothekGrenzschichtablösungFlächeninhaltCASE <Informatik>ClientCluster <Rechnernetz>MedianwertURLComputeranimationVorlesung/Konferenz
24:15
ClientProgrammbibliothekVirtuelle MaschineDämon <Informatik>TopologieInterface <Schaltung>Schreiben <Datenverarbeitung>Vorlesung/KonferenzComputeranimation
24:58
ClientInformationSoftwareAggregatzustandClientFunktion <Mathematik>GeradeCASE <Informatik>InstantiierungPunktMailing-ListeVerkehrsinformationVorlesung/KonferenzComputeranimation
25:51
PasswortClientKnotenmengeHochdruckSoftwareAggregatzustandArithmetisches MittelNichtlinearer OperatorCASE <Informatik>InstantiierungMailing-ListeSkriptspracheBefehl <Informatik>PasswortURLSchreiben <Datenverarbeitung>Vorlesung/KonferenzComputeranimation
27:23
KlumpenstichprobeBetriebsmittelverwaltungInstantiierungOrdnungsreduktionInverser LimesAutomatische HandlungsplanungKanalkapazitätSoftwaretestMereologieAutomatische HandlungsplanungBenutzerschnittstellenverwaltungssystemSchnittmengeKanalkapazitätSoftwareentwicklerDatenverwaltungQuick-SortPunktKlasse <Mathematik>Minkowski-MetrikEinsVorlesung/KonferenzComputeranimation
28:06
KanalkapazitätRechenwerkGlobale OptimierungLokales MinimumStichprobenumfangZahlenbereichInstantiierungBetriebsmittelverwaltungMechanismus-Design-TheorieInverser LimesPunktVorlesung/Konferenz
28:49
KnotenmengeInstantiierungBetriebsmittelverwaltungMinkowski-MetrikBefehlsprozessorTemplateMini-DiscROM <Informatik>RechenwerkInklusion <Mathematik>HalbleiterspeicherBitInstantiierungMini-DiscMinkowski-MetrikDivergente ReiheKanalkapazitätInverser LimesMetrisches SystemKlasse <Mathematik>InformationsspeicherungSummengleichungCluster <Rechnernetz>ComputeranimationVorlesung/Konferenz
30:11
Automatische HandlungsplanungDateiformatGruppenoperationBetriebsmittelverwaltungGruppenkeimKnotenmengeMini-DiscMinkowski-MetrikBefehlsprozessorSimulationInstantiierungTemplateROM <Informatik>SimulationDeskriptive StatistikGruppenoperationInstantiierungPartitionsfunktionDifferenteHardwareComputerarchitekturTermÄußere Algebra eines ModulsWort <Informatik>GraphfärbungComputeranimationVorlesung/Konferenz
31:10
SimulationHill-DifferentialgleichungMenütechnikAutomatische HandlungsplanungDateiformatGruppenoperationBetriebsmittelverwaltungMini-DiscMinkowski-MetrikGruppenkeimKnotenmengeBefehlsprozessorInstantiierungTemplateROM <Informatik>RelativitätstheorieDeskriptive StatistikTelekommunikationMAPGruppenoperationMenütechnikCASE <Informatik>InstantiierungATMInformationsspeicherungBetriebsmittelverwaltungNeuroinformatikDatenreplikationDateiformatMini-DiscFitnessfunktionVorlesung/KonferenzComputeranimation
32:30
SimulationVisualisierungMini-DiscHardwareMigration <Informatik>CASE <Informatik>RechenwerkGrundraumCASE <Informatik>Virtuelle MaschineMini-DiscKette <Mathematik>VersionsverwaltungDienst <Informatik>DifferenzenrechnungPhysikalisches SystemNichtlinearer OperatorATMStandardabweichungVirtualisierungNetzbetriebssystemVorlesung/KonferenzComputeranimation
33:32
InformationsspeicherungVolumenGruppenkeimKnotenmengeFahne <Mathematik>InstantiierungOperations ResearchSummengleichungMini-DiscAutomatische HandlungsplanungKanalkapazitätCodePeripheres GerätPhysikalismusAutomatische HandlungsplanungInstantiierungSummengleichungSpezifisches VolumenInformationsspeicherungDisjunktion <Logik>Computeranimation
34:15
SimulationTemperaturstrahlungDesintegration <Mathematik>InformationsspeicherungKnotenmengeSpeicherbereichsnetzwerkNetzwerk-gebundene SpeicherungInstantiierungMini-DiscGenerizitätInterface <Schaltung>GruppenoperationNormalvektorATMAdditionKanalkapazitätDateiverwaltungIntegralInformationsspeicherungVersionsverwaltungVorlesung/KonferenzComputeranimation
35:27
PrimzahlzwillingeInformationsspeicherungOperations ResearchSkriptspracheVariableProgrammierumgebungParametersystemService providerInstantiierungMini-DiscMetadatenImplementierungTypentheorieMomentenproblemInformationsspeicherungSkriptspracheInterface <Schaltung>ZeichenketteVariableProgrammierumgebungNichtlinearer OperatorParametersystemInstantiierungAdditionMetadatenMechanismus-Design-TheorieProgrammverifikationMini-DiscVorlesung/KonferenzComputeranimation
36:36
ImplementierungMini-DiscInformationsspeicherungInstantiierungMigration <Informatik>InstantiierungPay-TVInformationsspeicherungSkriptspracheCodecPhysikalisches SystemNormalvektorMini-DiscService providerVorlesung/KonferenzComputeranimation
37:33
InstantiierungBefehlsprozessorSummengleichungGerichtete MengeInformationsspeicherungBetriebsmittelverwaltungTemplateUmsetzung <Informatik>Mini-DiscStrom <Mathematik>ParametersystemService providerMereologieSchnittmengeInformationsspeicherungParametrische ErregungSkriptspracheEinsBitVersionsverwaltungInstantiierungSoftwareentwicklerStrömungsrichtungWort <Informatik>Cluster <Rechnernetz>MultiplikationsoperatorVorlesung/KonferenzComputeranimation
38:50
HalbleiterspeicherProdukt <Mathematik>SoftwaretestGruppenoperationRechenschieberZahlenbereichAbstandFormation <Mathematik>PunktKondition <Mathematik>InformationsspeicherungBefehlsprozessorInstantiierungUmsetzung <Informatik>SummengleichungVorlesung/Konferenz
39:49
KnotenmengeVersionsverwaltungPhasenumwandlungAnalytische FortsetzungInstantiierungMechanismus-Design-TheorieSoftwareKonfigurationsraumDämon <Informatik>Geometrische FrustrationWort <Informatik>Dienst <Informatik>Computeranimation
40:50
Mechanismus-Design-TheorieKnotenmengeVersionsverwaltungStrom <Mathematik>RPCComputersicherheitDigitales ZertifikatDatenkompressionInstantiierungSicherungskopieKonfiguration <Informatik>GruppenkeimMathematikMAPAggregatzustandMereologieVersionsverwaltungNichtlinearer OperatorEnergiedichteComputersicherheitDistributionenraumProtokoll <Datenverarbeitungssystem>Digitales ZertifikatStrömungsrichtungStabilitätstheorie <Logik>Computeranimation
42:00
Strom <Mathematik>RechenwerkBildgebendes VerfahrenComputerspielRückkopplungSoftwareDatenkompressionInstantiierungSchnittmengeKonfigurationsraumFahne <Mathematik>Vorlesung/Konferenz
42:43
Migration <Informatik>InformationsspeicherungKnotenmengeÜberlastkontrolleVirtuelle MaschineMultiplikationsoperatorVirtualisierungSoftwareentwicklerZeitzoneMetropolitan area networkInstantiierungSchnittmengeComputeranimation
43:24
SteuerwerkDualitätstheorieAdhäsionInformationProgrammierumgebungBitLastPhysikalisches SystemAutomatische HandlungsplanungInstantiierungEnergiedichteMailing-ListeMultiplikationsoperatorKategorie <Mathematik>EntscheidungstheorieLineare RegressionSatellitensystemVirtuelle MaschineQuick-SortVorlesung/Konferenz
45:26
CodeGoogolKette <Mathematik>MereologieProjektive Ebenet-TestOpen SourceProdukt <Mathematik>QuellcodeCMM <Software Engineering>Computeranimation
46:08
TemplateMini-DiscCodeGlättungUmsetzung <Informatik>GoogolInformationsspeicherungDatenverwaltungRechnernetzKlumpenstichprobeInstantiierungSoftwaretestInverser LimesMigration <Informatik>KontrollstrukturQuaderCodeBitProjektive EbeneGoogolSoftwareTypentheorieEINKAUF <Programm>MereologieFlächeninhaltProzess <Informatik>TemplateInformationsspeicherungWort <Informatik>Richtungt-TestCluster <Rechnernetz>DifferenteAutomatische HandlungsplanungComputeranimation
47:35
RückkopplungEreignishorizontBefehlsprozessorVirtuelle MaschineInstantiierungDifferenteWeb SiteProjektive EbeneZahlenbereichVorlesung/KonferenzComputeranimation
48:27
Affiner RaumGravitationsgesetzSoftwareÄquivalenzklasseGruppenoperationMereologieSpeicherabzugZahlenbereichZentrische StreckungE-MailSoftwarewartungÄhnlichkeitsgeometrieServerInstantiierungService providerMailing-ListeCluster <Rechnernetz>Patch <Software>MultiplikationsoperatorOffice-PaketTopologieProdukt <Mathematik>SoftwaretestGerichteter GraphZellularer AutomatBasis <Mathematik>AusnahmebehandlungParallele SchnittstellePunktKlasse <Mathematik>SchnittmengeVorlesung/Konferenz
53:03
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:09
Thank you very much. As mentioned, GANETI is managing clusters. So let's recall what a cluster is in GANETI terms.
00:24
The whole point of a cluster is to have some virtual machines. That's the reason why you operate the whole cluster in GANETI terms they're called instances, because the instance of some service or some prototypical machine. Of course, you need to have physical machines to run the whole thing on,
00:44
which in GANETI terms are called nodes. You use some form of hypervisor, XEN is the traditional one, KVM is currently very popular, and as mentioned LXC is coming, at least an experimental version, and you have some storage,
01:02
either plain volumes or the traditional one is using DRBD, so Distributed Replicated Block Device, and you have two copies of each disk, and GANETI helps to manage that. So the first part is it's a lot of convenience, because it provides you a uniform interface to all the various hypervisors,
01:22
to all the various storage solutions you might be using. It also helps you to keep the physical nodes used at equal rate, and enforce some policies, and keep track of little things like, oh please don't run my two name servers on the same physical node,
01:41
and things like that. And it also helps you to stay in a good state. So part of the reason why you have redundant storage is that you can cope with one node breaking. So then GANETI will be providing commands to fail over the instances,
02:01
rebalance the cluster afterwards, the remaining of the clusters, also as a watcher to keep out for nodes being power cycled without you planning it, and then at least restarting the instances, and things like that. Also at the policy level, it already takes care of possible failure modes,
02:22
because if you use DRBD as a storage solution, you typically have two nodes where you have a copy of the disks, so if one node breaks you have one node where you can start the instance immediately, and you better have enough memory reserved for the instance to fail over so that you can start without too much of a hassle.
02:42
Okay, so how does it look and feel? Basic interaction with GANETI is you start by initializing a cluster. So you provide the command cluster unit, you provide the name of the cluster, and that name is not just a name to refer to it, but it is supposed to resolve to a valid IP address,
03:02
which is the IP under which you then always reach the cluster, no matter which node currently is managing the cluster. The host name will then be kind of the primary way to communicate with the cluster, and you can also provide
03:20
the secondary IP address of that node, because GANETI typically has at least two networks involved. One network where you reach the nodes, and a separate network which only has to work between the nodes for all the replication traffic for disks, and usually want to keep that separate.
03:41
That's why you provide the information about a secondary IP address. And typically the instances, if they communicate to the outside world, are yet another network. You add nodes, it's also just a command, you again provide the name of the node, which has to resolve to the primary IP address you provide the second IP address,
04:01
do that for all the nodes, and then you add an instance. You provide all the data you need for an instance, so you say, well, which form of storage solution do we use? Typically, so the T is for disk template, typically DRBD. You specify the size of the disks,
04:23
or leave the default value. You might provide some text, and depending which text you provide, you can, at that level, already say, this provides a certain service, and make sure that instances providing the same service don't end up on the same physical node. You give the name of the instance,
04:41
and you provide the operating system. And GANETI itself, by design, is to manage virtual machines, and be agnostic about what did you do with these machines. So the operating system kind of has to come from the outside, and GANETI just provides an interface
05:02
to specify how to get the operating system on the disk of the virtual machine. Quite simple interface, you have a directory for each OS definitions, you have a couple of scripts, most importantly, a create script that is called over the environment variables to get all the information you need,
05:20
like the name of the instance, the devices which will then be the disks of the instance, the number of disks which devices, size, and et cetera. And then it's your task to get whatever data you want to get on the disk before actually starting the instance.
05:41
A couple of other scripts, some of them are optional. So other interaction is that creating a cluster is one thing, maintaining it is another piece of work. As an example, take a plant maintenance. So you say, well, this node, I want to replace some disks,
06:01
so I better have it empty beforehand. The way you would do it with GANETI is to say, you modify the node, and you change the status, in this case, to drained. So a node can be in one of three possible modes. Online is hopefully the normal mode, the node is just running, GANETI can reach it,
06:20
and instances are running, and everyone is happy. Then there is a node can be offline, meaning, well, offline. Don't even try to connect to that node, but assume that nothing will come out from that node, and no instances are running on it. And drained is kind of in between. Technically, the node is fully operational, but it's a policy decision
06:41
that I intend to get that node empty. In particular, GANETI will not place any new instances on that node. And if you then tell GANETI to balance the cluster, which is the command hball, it will also consider cluster imbalance where there are instances running on nodes that are planned to get empty.
07:02
So that will already keep you all the instances away from that. So the name might be a bit confusing. Ball is for balancing, and this h is, well, because it's part of a tool set on top of GANETI, which I call the h tools for historical reasons.
07:21
The commands, well, you tell it, ask the cluster directly to get information about what the current state of the cluster is, and actually not tell me how to balance the cluster, but actually carry out the command, execute them. So that will move all the instances away from the node which you marked as trained. Once there's nothing on it, you can tell GANETI don't try to connect that node.
07:42
Then you just power it off, you do whatever you want to do with the maintenance. Once you're done, you just set it to online again, and tell it balance again so that it's actually used. Yep, so that's basic direction, and what happens behind the scenes.
08:04
And there are things that have changed quite a bit since last year, so it might also be interesting for people who attended last year's talk. First of all, these commands which I've shown you, this gnt-cluster, modify, blah, blah, blah, they don't do a lot. They're just a command line interface,
08:21
so what they do is they pass the parameters, do some very basic sanity checks, JSON encoded and over domain socket, give it to the main GANETI daemon, which is called looks daemon because the protocol it's speaking is looks. So this is essentially JSON over Unix domain socket.
08:40
And then they tell the daemon to do it, and then wait for a report on how the job progresses. In fact, you don't even have to wait on the command line. You can just say, well, submit a job. I'll get back later and see whether it succeeded or not. So you can just tell it to submit the commands,
09:02
and with gnt-jobinfo, you get information for a specific job ID that is assigned there. So that's just a simple interface. So the main work is done from the daemon. The first thing it does is it writes the job description to disk
09:20
so that if the daemon gets restarted, no information is lost. And then the whole point of cluster management is to also have some redundancy and be in a good shape if something goes wrong. It makes sense to also have the GANETI specific information replicated, so it replicates it to a couple of nodes,
09:42
which are called master candidates because they have all the information to take over the role of the master should something happen to the actual master. And well, the way it's done, it's on the local disk written directly with the usual write to temp file, fsync, remove, rename, dance.
10:02
And for the remote node, it tells some daemon, please write that file to the job queue. Then the job is in the status queued, meaning we have it on disk and we're not doing anything on it. And there are several reasons why it can be queued. The main reason is that you want to have a limit
10:21
on the number of jobs running concurrently on your cluster. That used to be for historical reasons when all the handling was done in one huge multi-filet Python process and at some points you would hit the limit so better keep the number of threads low, that's no longer the case. But still, you don't want to have
10:41
too much going on on the master node because typically the master node also hosts instances, so all these operations going on on DOM zero and all the resources you use for the node are wasted for instances, so normally that's a bit scarce on resources. But since the resources you donate to your master node
11:01
is kind of a policy of the administrator, the number of jobs you want to run parallel is also a runtime tunable, at least now. The other reason is jobs can be more complicated and you can say this job should only be run once another job, either finished or even only if the other job succeeded.
11:21
And if it doesn't succeed, then well, don't even try that job. And you can also have some autocrate limiting which I will be talking about later. As I was saying, well, I'm happy with more jobs running, but jobs of that kind, there should only be a few at the same time. I'll give an example later.
11:41
So once that's all done, you see, okay, all the prerequisites are met. There's also capacity that we can start a job. Then the job gets forked off as a new process and the stating is waiting. The reason why you wait is that you still might need some locks,
12:01
either because you now manipulate some entity in the real world, like an instance, and you don't want two changes to the instance at the same time, or because you're waiting for resources, because some operations are quite heavy on resources in DOM zero, like copying a full disk or whatever, and you want to limit that, again,
12:23
as DOM zero resources are normally rare. It still talks to, needs the configuration to know where an instance is running, which nodes to lock, et cetera, and since the configuration, well, the configuration in that term is just a description of what we believe
12:41
the cluster currently is in, which state it is in, which state it should be in. Since that is accessed by several jobs, which are now processes, we have a separate daemon for that that takes care of the configuration. So it reads the configuration,
13:01
and all the updates, like oh, I'm waiting for that lock, or the job I'm depending on has actually failed, so I'm not supposed to run. All these updates are now done by the jobs themselves, and then the job is a running state, which means it does what it's supposed to do,
13:21
except that it doesn't do it personally, because you need operation on various nodes, typically not the master node, because one master node, a lot of nodes having instances. Again, the way it works, it contacts the daemon on that node, telling him please create that logical volume, please do that DIBD command, please tell that to the hypervisor, et cetera.
13:40
So these are the daemons running this route, permissions, and just communicating with the jobs. Well, also, if you change something, well, we tell that we actually created the disk on purpose, and it's not there left over of anything else, so we update the configuration. Again, by just calling the appropriate daemon.
14:00
And then hopefully, we end the state of success. It might go, other statuses could be an error, and there, the idea of GANETI, we do one level of error recovery, something goes wrong, we try to undo what we've done before, and if that fails, we just shout out loud, and the administrator's supposed to pick up the pieces.
14:22
But normally, if you can do something, we can also undo it. GANETI is, if the administrator says, well, I submitted the job, but I don't want it anymore, well, then also everyone is happy. So I mentioned a talk rate limiting, and before I can talk about that,
14:42
there's another concept which I have to introduce, and that is the reason trail. It's not quite true what a, well, jobs do tasks, but it's not always the case that jobs do everything themselves. If you have tasks that can be done
15:01
or should be done in parallel, then a job just says, well, to do this operation, like verify the cluster, just run all the following jobs, which I submit for you, like verify every node group in parallel. Other command, typical command that expands
15:22
to a lot of jobs is node evacuation. You tell GANETI, well, please get this node free of instances because it failed in a hard way. Please start the instances on the corresponding nodes, and then that expands to a lot of jobs that can run in parallel, like for every instance, you get one job.
15:43
So jobs can expand to other jobs, and also you have a lot of high-level commands that submit lots of jobs to GANETI, one we've already seen balancing the cluster that usually involves moving a lot of instances around, and that's all done by submitting more jobs.
16:03
GANETI, you can have other tools on top of GANETI that, well, either do user management or manage lots of clusters, so it might not be the top layer, and they also submit jobs to GANETI. And to keep track of what's actually going on
16:21
or why a particular job was submitted, jobs are annotated with reasons why they're executed. Reason is just a list of triples, source, reason, and timestamped. Timestamp is kind of obvious, nanoseconds in the epoch. Source is the tool that added this comment,
16:42
so typically the tool that submitted the job or the tool that picked up and transformed it. And reason is some human-readable text on why we actually want to have this operation on the cluster. And I said every entity that touches a job in some way or another, as the command line,
17:01
the demons taking over, handing off to other demons, et cetera, can extend that reason trail. That's why it's a list, and usually they do. Also, if you have a lot of tools before it actually hits GANETI, then you can also extend the reason trail there. And that's the main point. If one job expands to a lot of jobs,
17:21
then the reason trail is inherited. And as I said, sometimes you want to do a talk rate limiting. Typical example is you have one node group and you want to send the whole node group to repair or you expect a power down in that data center, then you want to move all the instances
17:41
out of that group to a different group. That's one command, but there's a lot of operation, and you want to limit the number of instances being moved simultaneously in order not to overload the switches on top of the node group or something. And that's why a recent addition to GANETI saying, well, we can use that reason trail
18:03
as it's convenient in groups together operations that kind of belong to the same task. Also, to do some rate limiting, at least in our talk fashion, by having reasons where the name happens to start with rate minus limit colon followed by number,
18:24
then these form rate limit buckets, the whole string forms a rate limit bucket, and you ensure that GANETI will make sure that only N jobs belonging to that reason run together. So a typical example is that you want to evacuate a group
18:42
but only move seven instances at the same time because otherwise we'll have too much load on the switch. Then you just specify the reason why you're doing it. You start with the matrix rate limit, the number, and then some human-readable explanation by your evacuating the group in the first place,
19:01
typically a reference to some planned maintenance or to some bug or whatever. That's the reason trail. And kind of more fine-grained job control is going on, is being planned, let's see. Other thing I want to talk about is locking
19:21
because there have been some changes as well. And the reason, to start the story, I start with instance placement. I said one of the tasks of GANETI is to keep the cluster reasonably well-balanced,
19:40
so the same number of instances or same amount of resources used on every node. And best is to already start when adding new instances so that we don't have to do much balancing moves later. And the way to do it is to, again, have an external interface to some program which,
20:02
so the interface works is you call a program, you give a description of the cluster and the instance you want to place on the cluster and send it in, in some JSON encoding, and you expect to get out a message saying, well, place the instance here. GANETI itself already also ships
20:21
with an instance allocation tool, which is called TALE. I think it's the most popular one among all GANETI clusters. And it uses the same notion of balancedness as H-ball we've already seen. And the same, I really mainly take the same library.
20:41
Okay, so that brings us into the realm of locking, because when I plan where to put the instance, I need to be sure that once I made the decision, the resources are left on the instance. And so if I want to have a perfect balancedness,
21:02
I need to lock all nodes where I could to electrically put the instance, then see what is the best choice, release the remaining locks, and well, place the actual instance. A corollary of that allocation strategy is that all the instances additions are done sequentially,
21:23
because the next instance allocation also says, well, give me all locks, and then I can decide where a good placement is. There already is a solution which has been small improvement, small but hopefully significant improvement later, which is opportunistic locking. You can also tell GANETI, well,
21:41
only opportunistically acquire some locks when trying to place the instance. So just give me some node locks, and from those I choose where to place the instance. It might not be as balanced, but at least I can create more instances in parallel without waiting for all the locks beforehand.
22:02
That, of course, gives me the new form of error that I choose some node locks, find out that none of the nodes I've chosen have enough resources to actually hold the instance. And then I'm not sure whether I can't place the instance on the cluster or not, and I just say, well, try again.
22:23
Small change, small but important change recently added. Well, we crap some locks, but at least the number of locks we need, at least one node, otherwise I know it won't work, so I wait for at least one node being available, or two in the case of DRBD for primary and secondary. And we are planning to also do this
22:40
retry mechanism internally, saying, but that's kind of future work. Okay, I think that's all I wanted to tell about. Basically, GANETI operation and locking, and Telga will tell about how to use GANETI in large scale.
23:02
Microphone? Does this work? Okay. Um, yeah, welcome also from my site.
23:21
My name is Helga. I will talk a bit about features that are not that well known, because we figured we have given a talk last year, so we should also tell you something new. And most of the features are more interesting if you run bigger clusters, but some already are quite useful
23:40
if you have a small cluster and want to expand it, or we can plan for the next upgrade. So, one feature that's rather old is our REST API. So, we call it RAPI. There are client libraries
24:00
which actually hide the HTTP details, so you don't have to deal with the ugly URLs. This is what you use when you have more than one cluster and want to build tools around it that, for example, create several clusters, or, yeah, manage more than one, then you might not only SSH into machines
24:22
and run the commands on the master node. As Klaus mentioned before, that's actually what we need the cluster name for, because the RAPI daemon runs on the master node, and the master node can also fail, and we try to keep the cluster running no matter what happens, so you can fail over the master node to another node,
24:42
and of course then the IP has to be served from that node. That's why we always use the name so that you can still access RAPI then. One thing you need credentials for, but only for writing. So, if you just read something
25:01
about the state of the cluster, then you don't need the credentials, so that means if you run RAPI, you might want to secure your network in a way that everybody can read all the data or the information of your cluster. This is an example of the Python client that we also ship.
25:20
So, you just import one Python file, and then you create the cluster client, and in this case, we just want to read something, so we only need the name. There's a standard port which we use if you have configured in a way that you want a different port, you can of course have to say it here,
25:41
otherwise it takes the report. So, in this case, we want to read the list of instances that we have running, and the output is some JSON, which is not easy to read, so if you want to have it printed in a nice way, yeah, you do some pretty printing here.
26:03
Yeah, so if you just want to read, you don't need credentials, but if you want to write stuff, or writing means doing any operation which changes the cluster state, like moving instances, changing names, text, whatever, and this is done, like this way,
26:21
you give it the cluster and also the username and password, and then you can do stuff that needs writing. But if you don't want to use the Python client, or you want to write your own scripts, you can just do the bare, yeah, HTTP itself, you can use curl or wget,
26:42
or whatever you want, and here is an example where you just read the list of nodes from a cluster, and yeah, you get the IDs, so the host names, and you also get an URL if you want to know more about a particular node, you can just call the cluster
27:01
with this URL. And here's an example for a post request where you want to change something. In this case, you want to change the state of a node from master candidate to false so that it's no longer a master candidate, and yeah, you need to make a post request, which is kind of ugly if you do it this way,
27:22
but if you want to write it, for example, in a monitoring script, this is actually quite doable. Yeah, that was about RAPI, and we have another tool called HSpace, which is also part of the HTools set.
27:40
And when you run a cluster, at some point, you want to do some future planning, so your boss asks you, yeah, we have, I don't know, two more developers coming, then you test machines, do we actually have enough resources on our cluster, or how long will our resources last? And HSpace is a way which helps you
28:01
to do capacity planning on your cluster, and it's a tool that simulates resource consumption, so it adds new instances, like virtually, till it runs out of resources, and it tells you which resource you run out first, it uses internally the same allocation mechanism
28:23
that you would use if you really would add the instances, and you can specify the maximum number of instances that you plan to run, and so we start with the biggest instance, add so many as we can,
28:41
and then get to the next smaller instance, and yeah, till we hit the limits at some point. I have an example here, so you don't need to read all of this, so we just run this HSpace minus L on the master node, and it tells you a bit about your cluster, that it has three nodes,
29:00
the overall capacity, like memory disk and CPU, and here it starts adding instances, so it says, okay, you can add four more instances with a bigger disk, and then I still have some space left for two more instances, but then all my disk is filled,
29:21
and which is here the most likely failure reason, and it also tells you the cluster score, that's a metric that tells you how balanced the cluster is, so if it's zero, it means your cluster is perfectly balanced, but that's rare in reality, and here you can see in the end,
29:41
it's actually, it will be less balanced, but I mean, it depends on the metrics cover, or not only disk, but also other like CPU and memory, so it can actually be a bit less balanced if you want to really hit the limit. Yeah, and here it shows you like, okay, if you hit the disk limit,
30:01
you still have plenty of RAM, so that shows you, you should maybe buy more disk, and you don't need new nodes, but it might be sufficient to just add more storage. If you, so this works on the cluster master node, but sometimes you don't have a cluster yet,
30:21
so you need to set up a new cluster, and you want to do the same thing, and therefore there's a simulation back end, which Hspace, you give it a description of an empty cluster, and then you do the same thing. You would specify the instances sizes, and then it tries to fill it up, and tells you what resource do you run up first,
30:42
and you can do this for several node groups, so Gennetty has this concept of having a partition of different node groups for, for example, different purposes, or different user groups, or different architectures, and you can do this also in the simulation,
31:01
so for example, you might have some node groups, I don't know, more disk, or slower hardware, and you can simulate this, or include this in the simulation, so for this, you have to give it a description of the cluster, which is kind of broad,
31:22
so this is actually the format here, so you have an allocation policy, which is actually on a node group level, so this, you might have a node group that is the preferred place for new instances, but you have maybe a last resort node group, which is, I don't know, some slow computers that are still running somewhere,
31:41
and if not everything else fails, you use that one. Yeah, you specify a number of nodes, this, all the resources, and this is what you do here, and then you also have to give it the disk template, which means, for example, if you use TLBD, you of course need double the amount of storage,
32:00
because you always have a replication, and here you give it the size of the instances, tiered allocation is a mode where you start with this, and reduce it in steps to at least fit something on it, so it does the same thing here, and here in this case, you see,
32:21
I get 33 instances, and then I can add three more with fewer CPU, and in this case, you see, okay, I run out of CPU first. Another use case that we encountered was, sometimes you want to have virtualization,
32:42
but not quite all of it, so we have teams that wanted virtual machines, but they don't want to share the disk, so they don't want that their virtual machine gets in trouble when some other virtual machine running on the same disk is doing higher overload, so they won't actually not be affected by other services,
33:04
and for this, you could say, okay, I just give them bare metal, and they have only their machine, but of course, you might still want to have the benefits of virtualization, so they might need a different operating system than your standard operating system, and you still want to be able to migrate it easily,
33:22
but you still want to make sure that not two virtual machines use the same disk, and we call this mode GANETI Dedicated, and it's actually quite easy to set it up in GANETI. You use LVM storage, either plain LVM or DRBD.
33:41
You have to make sure that not two physical volumes share the same physical device, because GANETI got just things in physical volumes and if you, of course, place two of them on the same disk, it cannot know that you actually did this, and you have to tell GANETI, okay, I want to use this exclusive storage mode,
34:01
and if you set it up this way, GANETI will change two things, so it will make sure that no two instances run on the same physical volume, and it also respects this if you do any cluster balancing or the capacity planning, so this will be taken into account.
34:21
And since it's a thing of node group level, you can actually have in the same cluster the normal mode and additional node group with this mode. Then another feature, GANETI historically was developed with the LVM storage in mind,
34:42
so we actually internally still used DRBD, but in the last years, there was more and more demand for shared and distributed storage. There are a few things which we support, like more integrated, like we have a more integrated sub support, or you can just mount some distributed file system
35:04
on all the nodes and use it as shared storage, but if you want to have, if you have some really cool external storage appliance, and you want to, I don't know, for performance reasons, you want to not only mount it somewhere and let GANETI totally be agnostic about any features.
35:24
But we cannot possibly support all different appliances with other complications, so we have the X storage interface, which is you have to provide a few scripts for your type of appliance,
35:41
and GANETI just calls them at the right moment, and so for GANETI, it's a generic way to access external storage, but you can use it to do some performance tweaks, and yeah, I have some examples here. So it works in a way that you have to provide
36:02
a few scripts that do the typical operations, which means you create an instance disk on that appliance, you grow, remove it, and then if you want to actually place the instance, you attach or detach it to a node, you might need to set some metadata, and you can have additional parameters, as I said,
36:24
and the scripts would like to do some verification that it actually is a valid string or whatever you expect there. And the parameters are actually transmitted by environment variables. This is a similar mechanism to the instance or essence store scripts
36:40
that GANETI already has implemented. So this is an example here. Let's say I have two different shared storage, one, you can see, one IBM storage, and then you can do something like this. You have your normal instance at a command. You define as disk template that is an external device,
37:03
and then you specify the size for any normal disk, but then you have to tell it which provider to use. This way, GANETI knows which script to run. And this actually works that you can run instances with two disks on two different appliances.
37:23
You can also, I mean, it's actually really well integrated in the GANETI workflow, so you can modify things on the disk, like shrink or grow it, depending if it's supported. You can migrate instances, and since it assumes that all your nodes
37:41
are connected to this storage, it's actually quite easy to migrate nodes and quite fast. And as I said, you can actually add more parameters that GANETI doesn't know, so it doesn't interpret it in a way, it just forwards it to the provider script. So this is just an example here.
38:02
Yeah, so these were the features that are interesting if you deploy GANETI at a higher amount of nodes. And I want to go a bit through the current development and the future development. So last time, I think, we were at 2.9, so I started at 2.10.
38:21
2.10 is the current version that you get for example if you use W and WYSI back ports. We worked a bit on KVM. There were some contributions to support flat block, and more direct access to RDB storage.
38:40
We improved the cross-cluster move, so you can actually move instances between two clusters, but there were a few problems of performance, and some features were just missing. So this time, you can just tell it, okay, move it to this cluster, and it will figure out which node on that cluster to place the instance on. Before that, you actually had to give it a specific node,
39:04
and it actually can also convert this to place on the fly. So we often had the setup that you have some test cluster and because you don't have so much storage, you just use like plain LVM, and then you want to move a VM to the production cluster, where there you have DRVD. So this kind of conversion shouldn't be too complicated,
39:24
but it was missing so far. Then there's this tool, H4, that we were talking about, which does the cluster balancing. So far, it considered like storage CPU and memory, but only the number of CPUs, and this can now be done actually on the CPU load.
39:44
Then another feature is the Ganeti upgrades. I have some extra slides for that. So far, there were no mechanism to upgrade the Ganeti software itself, and since you have this big setup with many nodes, it's kind of tedious to upgrade a cluster,
40:03
and many people were kind of frustrated with that because you don't want to take your whole cluster down, and I mean the risk with that. We try to make this more easy. So this is like the old way, so you have to stop the Ganeti demons. That means actually your instances continue running,
40:21
but if anything fails, of course, Ganeti is not there to fix it, and then you install the new packages. You have to update the configuration. You have to restart all Ganeti services, and then you have to redistribute the configuration, and then depending on different versions, you have to do a lot more steps,
40:42
and if everything goes wrong, there was no way to get back easily, so you had to fix this manually. And from 2.10 on, you can use the Ganeti upgrade command, and so that means the earliest that you can use it to upgrade to is from 2.10 to 2.11,
41:01
and this works like that, so you have to install your new packet or whatever distribution you use, and then you just say gnt cluster upgrade, and then the version you want to upgrade to, and if something goes wrong, you can actually use the upgrade to downgrade as well
41:21
to the previous version. The current stable version of Ganeti is 2.11, which is available in Deviant Jesse. We worked on RPC security, so we used some internal RPC protocol for the master node to talk to the other nodes,
41:40
and so far, it was not that secure because all nodes use the same certificate. That means if you have this certificate from one compromised node, you can actually pretend to be the master node and do evil things, so now there's some improvement that you have individual certificates, and not just every certificate will be accepted.
42:03
For the instance moves that are the cross-cluster instance moves, we have now compression for, I don't know, slow network setups. You can now configure SSH ports and not only the standard port. We have cluster support now integrated,
42:23
so this is still flag experimental, which is, I mean, it's fairly new, and we don't have so much feedback yet from real-life setup, so if you want to try this out, we're happy to get any feedback on this, and there's another tool, h-squeeze and the h-tools tool set,
42:43
which was also requested from an external user, so when you have a cluster that has a high fluctuation in load, so for example, you might have a cluster that has virtual machines for your developers to test, but your developers are just in one time zone,
43:01
so when they go home at night, the machine's actually idling, or you have a setup where you only need a lot of virtual machines, like, I don't know, a few days every couple of weeks because you release some updates or something like that, and otherwise, you don't actually need that many instances,
43:22
so what we wanted to do is whenever there's slow times of load, you can shut down some instances and move the remaining instances to a few nodes to use them as best as possible and really physically shut down the remaining nodes, so you save some money or some energy for the environment,
43:44
and for this, to make it more easy to move them together and then know which nodes to shut down, you can use this to cool h-squeeze, so it's actually handling your instances together, and so this is a bit contrary
44:02
to the cluster balancing, just usually tries to balance it fairly equally on all nodes, but this is like, okay, packing as many as I can on a few nodes and shutting down the rest, so it calculates some aggregation plan for the instances, and of course, this works better with shared storage
44:22
because if you use CRBD, you would actually need to move the storage, and that would take too long, so it drains as many nodes as possible, but not too many because you don't want to have any info on the remaining instances, so you don't want all of a sudden
44:41
not having enough ROM or something, and it uses hbar to calculate the load of the few nodes that stay on. Into 11, only the planning was implemented, so it actually gives you a list of things to do, but you still have to do it yourself,
45:00
but into 13, you can just say, okay, please cluster, move my instances according to this plan, and then you needed to shut the nodes down, and of course, if you want to use this, you have to make sure that your remaining environment adhesives this properly, so your monitoring system shouldn't get alarmed when you shut down the machines,
45:21
et cetera, that of course you have to take care of as well. Two more features, so we have been asked a lot, we have LXC support, and so far it was always existed, but it was flagged as experimental, and the reason was we also didn't have many users,
45:43
and so we didn't know how mature it is, and this year we took part in Google Summer of Code, which I hope everybody knows, but it's maybe not. Google gives some money to students that work on open source projects over the summer, and they have to implement a reasonably sized feature,
46:03
and we had a student who worked on the LXC support to make sure it actually works, to find any bugs, to set up a QA that properly tests this for us, so whenever we now do something, we see actually when it breaks, and it works with LXC 1.0,
46:21
it will probably be released into 13, so a bit in the future, and the live migration is still experimental, which was due to some limitations in LXC. Another Google Summer of Code project that we have, that Ganeti now supports all these different types of storage, but it was not always that easy
46:42
to convert between the storage templates, and we had a student who worked on that to convert more directions, and it's also going well, we will release it into 13. There's the future, so this is things we work on, or like to work on in the future,
47:01
so as Klaus already mentioned, we did some stuff on the job queue. There are some more plans here. We want to get the network part more flexible, and especially better to work with IPv6. We work more on the shared storage part, because that's obviously a very growing area of interest.
47:23
We have some interest in heterogeneous clusters. Actually, Ganeti can work with heterogeneous setups, but it was not technically tested for it very well, so whenever somebody has a complaint about this, like if you only have three very different machines
47:42
and something doesn't work, we would like to know about this, and yeah, we continue working on the cross-cluster instance moves, and some improvement on the SSHG handling as well, and with that, I'm done. You can check our project if you just Google for Ganeti,
48:03
and we are the first hit, but we did not manipulate that, and usually we list the number of conferences that we go to, but this year's not that much anymore. Next week, we are in Portland on a small Ganeti conference, also our own home conference,
48:21
and yeah, that's it from my side. Thanks for your attention. Questions?
48:40
So far, nobody has asked for it, but I was kind of expecting the, oh yeah, the question was if we have any intention to use Docker, and so far, we haven't any requests yet, but I mean, I guess as with LXC at some point, we might integrate that. You have to speak up, but sorry.
49:10
No questions. That's a good question.
49:21
I think we never really, I don't know, got any numbers, right? I mean, if you want to. So the question was about the size of the external contributor base. Looked recently at the commits, majority still comes from people working at Google.
49:41
There are kind of two big groups that are contributing. One is GNNet, company providing infrastructure for the Creek academic community. They use a lot of KVM, so a lot of KVM related patches actually are contributed from them. Also, GNT network is a big part of them.
50:05
So size patch, if you just count patches about 10% or so, and another big external contributor is Apollon, who is the Debian maintainer for the GNNet package,
50:22
and it's quite good relation because if he finds something is not working in his setup, he also sends patches and he tests very well also the KVM, LVM setup, I think, because he's using it himself. But roughly, I think, 80 or 90% of all patches
50:41
come from people working at Google. Not necessarily the core team, a lot of people do internships, and then work on GNNet. Also, within Google, some people use 20% of their time to contribute to GNNet. You have quite a lot of interesting features
51:00
for larger size stuff. Would you also recommend it for a small, say, four or six node clusters, or is that too much or better? The question was whether we would recommend using GNNet for a small, and the suggestion was four to six node clusters. We're using it ourselves for such small clusters, typically in offices to provide name server
51:23
and similar basic infrastructure. So yes, we use it ourselves for small clusters. Also, people report that one of the reasons why they use GNNet is that it's easy to get started even on a small cluster and use it, and it scales to big clusters as well.
51:42
What is the biggest cluster? The question was? Yep, this one. So the question was what's the biggest clusters that we know of. We actually will release some numbers next week, so I think the biggest we have internally
52:02
is a couple of, I don't know, 100 nodes, maybe, and it runs 1,300 instances. So that's, but we have several clusters then. From externally, I don't know, I don't have any numbers right now. Yes?
52:25
We have also a network tool like GNT network that does some stuff, but we don't, we are aware that it's not that sophisticated yet, but yeah, that's equivalent part. There's this network stuff.
52:41
I just chose some topics here, of course, and I couldn't go into detail of that. More questions? Okay, so thank you, and if you have any questions, you can mail on our mailing list or, yeah, IRC channel. Thank you.