Proxmox VE mit Ceph & ZFS
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/45645 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FrOSCon 201932 / 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
HTTPSystem administratorSoftwareFloppy diskSoftware developerXMLUMLComputer animationLecture/Conference
00:49
Data centerServer (computing)Enterprise architectureGateway (telecommunications)Hausdorff spaceXMLComputer animationLecture/Conference
01:29
Gateway (telecommunications)Server (computing)Time zoneLevel (video gaming)Enterprise architectureComputer animation
02:19
Enterprise architectureGateway (telecommunications)Server (computing)Enterprise architectureSoftware developerComputer animationLecture/Conference
02:58
Route of administrationSun <Marke>Program flowchartLecture/Conference
03:40
LINUXPasswordLINUXStack (abstract data type)ForestProgram flowchartXMLUML
05:00
Stack (abstract data type)Partition (number theory)Server (computing)Computer animation
05:51
BefehlsprozessorRAMService (economics)Queue (abstract data type)RAMVAX/VMSRoute of administrationHand fanLecture/ConferenceComputer animation
06:38
Server (computing)RAMBefehlsprozessorVirtual machineLecture/Conference
08:29
High availabilityScalabilityEigenvalues and eigenvectorsStack (abstract data type)Service (economics)XMLComputer animation
09:50
C++Graphical user interfaceLecture/Conference
10:35
ScalabilityHigh availabilityDECStack (abstract data type)Graphical user interfaceComputer animationXML
11:19
DECServer (computing)VAX/VMSXMLComputer animation
12:22
Noten <Programm>Lecture/Conference
13:16
DECInstallable File SystemVAX/VMSSet (mathematics)Zusammenhang <Mathematik>VolumeBootingXMLComputer animationProgram flowchart
15:24
Set (mathematics)MagnetplattenspeicherBackupStreaming mediaObject (grammar)Lecture/Conference
16:52
Hard disk driveARC <Programmiersprache>Mobile appHard disk driveFactorizationMetadataComputer animation
18:55
Computer wormWorld Wide WebProcess capability indexMonster groupVersion <Informatik>Service (economics)Noten <Programm>UpdateXMLUMLJSONLecture/ConferenceMeeting/InterviewComputer animationProgram flowchart
20:46
Client (computing)Client (computing)Computer animation
21:42
Client (computing)BefehlsprozessorSmart cardComputer hardwareCore dumpFrequencyComputer animationLecture/Conference
22:45
Distribution (mathematics)Kernel (computing)Dressing (medical)OscillationMetadataPACERAMCache (computing)Client (computing)Kernel (computing)Template (C++)Hausdorff spaceBusiness reportingProgram flowchart
27:44
Distribution (mathematics)Dressing (medical)Process capability indexDDR SDRAMWindows RegistryMotherboardSingle-precision floating-point formatBefehlsprozessorNoten <Programm>Program flowchartComputer animationXML
28:41
Switch <Kommunikationstechnik>Mainframe computerVAX/VMSRAMComputer animation
29:53
Switch <Kommunikationstechnik>BefehlsprozessorSwitch <Kommunikationstechnik>PriorityBackupXMLProgram flowchart
32:16
VAX/VMSServer (computing)PAPDownloadWeb pageComputer animation
33:57
AMOS <Software>Coma BerenicesWind waveBefehlsprozessorNoten <Programm>Computer animation
34:38
Menu (computing)Noten <Programm>VAX/VMSDirection (geometry)Enterprise architectureComputer hardwareComputer animation
35:15
RAMEnterprise architectureComputer hardwareZahlPackung <Mathematik>Diagram
36:13
EthernetRAMGraphic WorkshopDDR SDRAMReceiver operating characteristicHauptspeicherLecture/ConferenceXMLComputer animationProgram flowchart
36:49
RAMDDR SDRAMGDFGraphic WorkshopEthernetReceiver operating characteristicGeographic information systemCache (computing)Information engineeringMicrocontrollerFirmwareXMLComputer animation
38:50
WikiTranslation (relic)Source codeElectronic mailing listContinuous trackComputer animationLecture/ConferenceMeeting/Interview
39:26
Graphical user interfaceVAX/VMSMobile appComputer animationLecture/Conference
41:02
Switch <Kommunikationstechnik>Link (knot theory)XMLProgram flowchart
42:20
Lecture/Conference
43:16
WikiTranslation (relic)BefehlsprozessorSocial classHIT <Programm>Computer animation
43:55
Capability Maturity ModelMaximum (disambiguation)Menu (computing)User interfaceSymmetric multiprocessingBefehlsprozessorVAX/VMSWikiDebian GNU/LINUXDrum memoryKernel (computing)Version <Informatik>Internet forumHand fanComputer animationLecture/Conference
46:46
openSUSEXMLComputer animation
Transcript: German(auto-generated)
00:07
So, ich bin ja schon so halb vorgestellt, auch wenn man es da nicht ganz sieht. Mittlerweile mache ich 15 Jahre lang IT. Ja, angefangen immer schönes Beispiel mit der ersten SUSE und vielen Disketten
00:22
und bin mittlerweile zu den Programmierern übergegangen und habe, sagen wir mal jetzt seit zwölf, sind es 13 Jahre ungefähr, als IT-System-Netzwerke-Administrator gearbeitet. Also, ich kenne die ganzen Leiden, die man so hat als IT-Admin
00:41
und die ganzen Sachen, die man zu tun hat. Ich stelle euch heute vor, das was wir hier am Anfang haben, Boxmox mit ZFS und CEF. Also, ich werde sehr storage-lastig heute unterwegs sein und werde einige Sachen auslassen, die ich vielleicht in anderen Vorträgen schon erwähnt habe.
01:03
Und ich bin dann eh draußen, falls ihr dann zu den anderen Teilen auch noch Fragen habt. Ja, zum Einstieg, wer kennt Boxmox, wer hat es in Verwendung? Gut, dann kann ich ja nach Hause gehen, wenn ihr es schon wisst.
01:20
Gut, für alle, die jetzt noch neu oder vielleicht das eine und andere nicht wissen, und seit 2005 in Wien und nur in Wien, also wir haben keine andere Niederlassung oder dergleichen in der Welt. Wir machen auch den ganzen Support bei uns in Wien, also wenn da im Enterprise Support oder im Forum jemand von uns schreibt als Mitarbeiter,
01:48
passiert das alles aus Wien und dementsprechend mit den Zeitzonen ist das manchmal ein bisschen schwierig. Unser ganzes Produkt ist Open Source, es gibt keine versteckte Geldeinwurfmaschine,
02:02
damit man jetzt irgendwelche Lizenzen oder Features kriegt, die vorher nicht da waren, also man kann das Produkt so verwenden und seine Infrastruktur damit virtualisieren. Wenn ihr Enterprise Support haben wollt, dann gibt es dafür in verschiedenen Levels eine Subscription.
02:22
Und mit dieser Subscription schlagt ihr dann bei uns im Enterprise Support zum Beispiel auf und habt einen Entwickler von uns dran, der sich um euer Thema kümmert. Damit könnt ihr euch sicher sein, ihr habt kein First-Level Call Center oder so, irgendwo in Hickstibude und ihr versteht den Menschen nicht
02:44
und ihr müsst über 10.000 Ecken, um eigentlich zu jemandem zu kommen, der weiß, von was er redet. Das finde ich ist einer der großen Schwerpunkte, warum auch der Support von uns Entwicklern durchgeführt wird. Dann immer wieder gerne die traditionelle Infrastruktur.
03:08
Ich glaube wir haben alle in einem Unternehmen gearbeitet, das aus sogenannten, wie wir es gerne haben, aus solchen Silo-Lösungen entstanden ist. Quasi man hat da mal einen File Server, dann war es einmal eine Synology, dann ein NetApp oder sonst eine Box.
03:23
Man hat seine physikalischen Server, auf denen die Anwendungen drauflaufen und irgendwie ist das Ganze ein bisschen starr, unschön und man ist nicht so fixibel, wie man gerne sein will. Man ist storageplatz aus allen Nähten. Man muss sich eigentlich eine neue Sun oder eine neue NASA oder so etwas zulegen,
03:42
weil man braucht jetzt doch einen zweiten Share. Das ist alles nicht so geschmackig. Darum hat man angefangen Hyper-Kommergenz zu machen, um auch wieder ein Passwort zu haben. Was wir im Prinzip machen mit unserem Stack ist, wir nehmen Compute, Network und Storage und managen das alles.
04:03
Also sprich wir haben einmal, wie man es hier sieht, OVS für Open V-Switch, die Linux Bridge für den Netzwerke-Teil. Wir haben KVM und LXC als LXC für Container. Ja, es können auch Docker-Container in LXC-Containern laufen. Das ist eines der neuen Features, die wir mit drin haben.
04:23
Dann haben wir Ceph, die auch auf Hyper-Konverged läuft. Also mit drei Nodes sind wir da schon einmal im Spiel. Und nicht zu guter Letzt ist auch, was jetzt hier nicht mehr Platz gefunden hat, auch natürlich ZFS am Start. Und mit ZFS haben wir einen super tollen lokalen Speicher,
04:42
mit dem wir auch sozusagen eine Storage-Replication drumherum gebaut haben. Und das zeige ich euch im Anschluss ein bisschen, wie das Ganze ausschaut. Und ich werde auch ein bisschen aufräumen mit so Themen, die uns immer wieder begegnen, sei es im Support oder in den ganzen anderen Foren.
05:02
Ja, vorweg genommen, wir machen das Ganze als einen Stack. Und wie gesagt, drei Kisten zum Anfang. Das ist fürs Quorum, also wer AA haben will, und jemand anderes, der Storage hat, der braucht auch drei Server für gescheites AA. Und mittlerweile können wir auch sagen, wir haben einen Quorum-Device,
05:25
wo ein Demon läuft. Der kann jetzt auch entfernt stehen. Und das ist Teil vom Coro Sync. Also man kann auch eine dritte Node als sozusagen eine Blind-Node verwenden, wo in den Partitionen des Devices die anderen Nodes ein Status reinschreiben
05:44
und damit eine Vote von demjenigen kriegen. Und dieses Device, also der Dienst, der da läuft, der entsprechend Partition dann halt eine Vote gibt oder auch nicht. Also es muss mittlerweile nicht drei physische sein.
06:01
Besser natürlich ist es, wenn wir dann weitermachen mit Ceph. Da brauchen wir auch wieder drei Dienste und da gibt es so ein Queue Device heute nicht. Ich habe es hier mal mit angeführt, weil ich viele Dinge jetzt ein bisschen auslassen werde. CPU, RAM und Netzwerk.
06:22
Alles, was niedrigere Latenz schafft, ist besser. Und je niedriger die Latenz, desto besser für die Anwendung, desto besser für Safe, desto besser sprechen die ganzen VMs an oder die Applikationen in den Containern. Also man kauft lieber CPUs, die eine höhere Taktung haben
06:42
und nicht ganz so viele Cores, manchmal geht das nicht einher. Man hat dafür die Wahl, in einem Cluster mehrere Server zu verwenden. Also man macht dieses Scale Out anstatt dem Scale Up. Und dasselbe natürlich für den RAM. Man ist ja auch ein bisschen begrenzt in der RAM-Größe.
07:04
Also wer Terabyte-Mengen an RAM braucht für seine Virtual-Maschinen, wird dann irgendwann auch an eine Grenze stoßen. Also da kommt man auch wieder in Scale Out. Und natürlich mit Numa und den ganzen Feinheiten ist natürlich je schneller der RAM ist,
07:20
je schneller die CPU ist, desto niedriger natürlich die Latenz für die einzelnen Numa-Notes. Und wir kommen später darauf zu sprechen, warum das auch wirklich so wichtig ist. Netzwerk habe ich auch was Schönes mitgebracht. Also heute gibt es viele Grafiken. Beim Netzwerk gibt es natürlich auch weniger Latenz ist besser. Da fangen wir dann halt an zu sprechen, ja 1G ist besser als 10G in der Latenz,
07:44
10 als 25, 25 dann 10 und dann 25 aufwärts natürlich bis 100. Jetzt war der Gewinn ein bisschen kleiner von der Geschwindigkeit, aber die Latenz, wer die Bandbreite braucht, ist natürlich da gut aufgehoben.
08:04
Zum Thema Storage kommen wir. Wir haben auch wieder das Nicht-Enterprise-Hardware-Beispiel im Gepäck. Und ich habe auch ein paar Grafiken, das ein bisschen illustriert, warum Enterprise-Hardware, wo wir immer sagen, kauft es Enterprise-Hardware und keine Prosumer oder Consumer-Hardware.
08:22
Und wir werden feststellen, warum Enterprise-Hardware leider nicht immer Enterprise-Hardware ist. So, eine Grafik fürs Wassertrinken.
08:41
So, was ist ZFS, was ist CEF? Beide sind Software-Defined Storage-Lösungen. Das eine ist ZFS ist lokal, das CEF ist verteilt im Netzwerk. Das bringt natürlich mit sich andere Voraussetzungen und hat ein bisschen so seine anderen Eigenheiten.
09:00
Ihr könnt es gerne im Forum auch durchschauen. Da gibt es viele Anwendungsbeispiele oder Fall-Szenarien dazu. Da findet ihr auch uns und könnt gerne Fragen stellen. Über eben diese Eigenheiten von ZFS und CEF. Wir verwalten das Ganze über unseren Stack.
09:20
Also wir können mittlerweile bei CEF alle Dienste und ein ganzes CEF-Cluster von Mausklick installieren. Wer die GUI-Liefer hat oder natürlich per Kli. Das geht wie immer. Wir sind mittlerweile auf CEF Nautilus. Dank dem Wechsel auf Basta.
09:40
Und wir haben mittlerweile auch den 5.0er-Körner mit dem Gepäck. Und sind da jetzt Gott sei Dank schon ziemlich aktuell. Im Gegensatz zu dem PVF5 mit natürlich, wo wir den 4er-Körner noch hatten. Und leider der Umstellung geschuldet von dem C++ auf C++ 17 für CEF auf Luminus gestanden sind.
10:06
Also da gibt es viele Neuerungen in diesen Technologien. Auch ZFS ist mit 0.8.1 da. Das bietet endlich Encryption, was wir mit drin haben. Wir können auch sogenannte Metadata Caching Devices,
10:22
das ist mittlerweile auch drin, verwenden. Und können bei ZFS auch so die, sagen wir, ein bisschen mehr als die Basics auch verwalten über die GUI. Also zwei Platten ausgewählt und los geht's. Ja, vergessen Sie erwähnen, wir bieten beide einen technischen Support.
10:43
Also wenn ihr ZFS oder CEF verwendet und ihr kauft eine Subscription von uns, das ist auch mit inkludiert. Also ihr könnt dann auch Fragen zu CEF und ZFS stellen, die auch natürlich mit uns im Stack verbunden sind.
11:02
ZFS haben wir, wie man hier schön sieht, in der GUI mit eingebaut. Das ist eines meiner Testcluster. Wir haben mittlerweile den Status drin. Wir können ausgeben, wie es um die Health, also um die Gesundheit der Disken steht oder des Pools steht.
11:24
Wir haben das Kriieren drin. Was wir nicht drin haben, ist das Zerstören, weil man klickt mal schnell und dann ist das Storage weg. Das ist speziell bei ZFS. Bist du dir wirklich, wirklich, wirklich sicher, Fragen oder Optionen zu wählen?
11:42
Also wäre das ziemlich schnell passiert. Das ist, wenn man zwei leere Disken hat, ziemlich zwei Klicks. Man hat sein eigenes Storage. Dieses Storage verwenden wir, um VMs oder Container, also Subvolts in dem Fall für Container und Zvolts für VMs auch auf andere Server zu replizieren.
12:06
Also wir verwenden das ZFS Send and Receive dafür. Man kann damit also auch HA-Lösungen ohne einem dezidierten Shared Storage machen. Sprich, man hat den Dacron-Job, der im Hintergrund die Platten, das Delta, vom Snapshot zu Snapshot sendet.
12:29
In so einem Minutenintervall laufen lassen und im Falle der Fälle, wenn die Maschine ausfällt, geht es per HA auf die andere Note. Und die Maschine läuft dort mit natürlich ein bisschen Verlust weiter.
12:41
Also je nachdem, wann der letzte Sync lief und ob der in Ordnung war, ist natürlich da ein bisschen Verlust drin. Aber man hat einen konsistenten Stand, von dem man dann wieder starten kann. Das Ganze funktioniert dann quasi schon so automagisch, dass man, wenn man migriert, sich die Kronen, also die Replication-Jobs auch wechseln.
13:04
Also man muss sich da nicht mehr verkopfen, ok, jetzt muss ich den neu anlegen. Sondern man migriert zwischen den zwei Notes, wo der eingerichtet ist und muss sich nicht weiter darum kümmern. Ein bisschen zur Architektur vom ZFS, weil das doch immer wieder eine Rolle und eine Frage spielt.
13:28
Die Architektur, also es war einfach natürlich ausgezeichnet. Wir verwenden einmal das Filesystem und das ZVol, das ist die Besonderheit von ZFS.
13:41
Es ist also ein Volume-Manager plus ein Filesystem. Und das Ganze ist wieder mit einem Pool verbunden. Also man sieht in seiner Storage an sich da einen Pool und da drin wohnen dann im Filesystem per Subvolume. Und in ZVol natürlich als einzelnes Volume die VMs oder Filesystem-Container.
14:04
Und dementsprechend bietet uns über das Pool hinaus ZFS, Snapshots, De-Komprimierung, Ach, De-Duplizierung, so, Komprimierung und De-Duplizierung. Plus mittlerweile Encryption, die man sich auf den ganzen Pool zum Beispiel legen kann und damit einen Encrypted Pool macht.
14:29
Leider momentan geht kein Airpool Encrypted, das mit dem Booten. Also das ist noch was, wo sie am Arbeiten sind, damit das natürlich auch, wenn möglich, funktioniert.
14:41
Man sieht hier unten schön seine V-Devs, also seine Virtual Devices, die wieder um Disken beinhalten. Beliebte Frage ist natürlich, soll ich immer ein großes V-Dev machen oder lieber kleinere und dem Pool zusammenhängen.
15:02
Wichtiger Punkt ist, ZFS schreibt, also macht kein Rebalance. Also was geschrieben ist, das bleibt halt auf dem einen V-Dev und wird nicht auf das andere verteilt, dass das dann der gleichen Füllmenge hat zum Beispiel. Also man müsste dann zum Beispiel selber Handanlegen oder aus bestimmten Konstellationen heraus, einfach
15:24
ganz frisch von vorne mit einem Setup anfangen, das vielleicht mehrere V-Devs beinhaltet. Und speziell werden wir auch immer wieder gefragt, soll man lieber ein Rate Set 2 oder 1 oder vielleicht doch lieber ein Rate 10 oder 01 in dem Fall verwenden.
15:46
Und ja, wir sagen immer dann, es kommt auf die Workload drauf an, die da drauf läuft oder für was ihr das eigentlich nutzen wollt. Bewehrt hat sich das Setup für 01, also vier Disken, das ist einmal gestript und dann wieder gemirrolt, damit natürlich von einem Stapel natürlich eins ausfallen kann.
16:07
Wir haben mit dem, für dann größere Setups gibt es dann Leute, die dann auch das Rate Set 1 einsetzen und die berichten natürlich dann, man braucht natürlich eine starke CPU, um auch die Checksum ordentlich schnell zu generieren.
16:25
Plus natürlich SSDs, während HDDs natürlich in dem Fall auch vorzuziehen. Wenn man natürlich ein bisschen IOPS braucht, wenn man nur einen Plattenspeicher für seinen Backup haben möchte, dann kann man natürlich x HDDs reinstecken und das lustig konfigurieren, wie man will.
16:43
Da bietet ZDFS eine sehr gute Performance beim Streaming bei größeren Objekten. Falls es jemand noch nicht kennt, ZDFS hat so ein paar Schmähsauflager.
17:00
Das eine ist, es gibt das Ziel, das Intentation Log vom ZDFS. Da werden vor allem kleinere Rates landen, da werden auch die ganzen Metadatenupdates und dergleichen mit reingeschrieben und die wandern dann irgendwann auf die HDD selbst.
17:21
Also wenn man es nicht hat, dann landet das alles gleich drauf. Also man hat viele kleine Rates auf der großen Spinner, die man sich vielleicht dafür vorbereitet hat. Und dann auch die ganzen großen Rates, die man da drauf gemacht hat, dann als zusätzlichen Faktor. ZDFS ist schlau genug und bietet das an, dass man es auf eine SSD packt.
17:42
Damit kann man vor allem kleine Rates da reinschieben. Also alles, was unter 128k ist, wenn ich mich nicht irre. Aber bitte lieber nachlesen. Werden da oft das kleinere, vielleicht hoffentlich schnellere Device ist. Also es bietet sich dann so ein Optane Memory oder etwas Vergleichbares zu haben, wenn man einen ordentlich frequentierten Pool hat.
18:06
Und dann werden die großen Daten auf die HDD geschrieben. Und mittlerweile was drin ist, ich habe es leider noch nicht ausprobieren können. Wer eigentlich zusätzlich zu diesem Ziel dazu eigentlich ein Metadata Device ist.
18:27
Am besten natürlich mirrored, damit das nicht der Pool kaputt ist, wenn die ausfällt. Am besten ein Mirror aus zwei SSDs. Und dann kann man seine Metadata auf die SSD schreiben, was natürlich viele kleine Rates sind. Und der Stapel von HDDs kriegt dann die großen Rates ab.
18:47
Damit soll sich natürlich dann die Performance auch nochmal drastisch steigern lassen. So, kurz zu ZDFS. Jetzt kommen wir zum nächsten großen. Das ist ein anderes Monster.
19:02
ZEV. So mein Steckenpferd die letzten fünf Jahre. Schaut, wir haben mittlerweile in der 6er Version alles bunt und in Farbe und lustige Graphen drin. Also den Status vom ZEV selbst nochmal erweitert.
19:23
Und noch würde ich mal sagen auch eine Verbesserung dazu gegeben. Man sieht auf welchem Node welcher Service läuft. Das ist aus ZEV Sicht heraus nicht nötig. Aber für uns ist es natürlich wichtig, weil wir wollen wissen, wo habe ich jetzt den Manager installiert.
19:44
Nicht nur, dass ich einen installiert haben muss. Mindestens damit so Stati und die gleichen Sachen funktionieren. Sondern wo ist er denn bei uns installiert? Läuft der Dienst? Und fürs Update ist es wichtig, hat er auch die richtige Version. Also wenn man mit dem Mouseover, das hat mein Skinshot leider nicht geschafft,
20:02
ein Mouseover macht, dann sieht man auch in welcher Version der ist. Und ein bisschen extra Stati, ob das der einzige ist oder ob es noch andere gibt. Hier habe ich natürlich eine Note ausgeschaltet, damit ein bisschen bunter Status zusammenkommt. Dass natürlich schön dynamisch alles funktioniert.
20:23
Das was so nett ist an der GUI, man sieht nicht wie das eigentlich hinten drinnen funktioniert. Und wir haben es oft mal als Supportanfrage oder auch im Forum. Ja, also ich hatte jetzt zwei Netzwerk-Devices. Und habe ich dann mal Bond und Faulanz gemacht und habe gedacht, ich bin auf der guten Seite des Ceph-Stacks.
20:47
Und ja, man stellt fest, dann wenn ich die Grafik schicke, kommt bei vielen dann schon der Haareffekt. Mit einem Bond ist es meistens leider nicht getan, da Ceph sehr traffic-hungrig ist.
21:05
Die OSDs, wie man hier sieht, die sind angebunden über entweder ein Cluster-Netzwerk oder ein Public-Netzwerk. In unserem Standardfall ist das der selbe IP-Range, man kann das aber gern trennen.
21:24
Und man übersieht leider sehr oft gerne, dass das was hier so schön steht, ist das nur Heartbeats-Traffic und die Replication-Traffic über dieses extra Cluster-Netzwerk läuft. Aber sonst, was die Clients schicken, der Heartbeat nach vorne, die müssen alle mit den Monitoren,
21:41
also mit den Jungs hier quatschen, der die aktuelle Karte für das Ceph-Cluster ausgibt und da gibt es fünf Stück. Also man kann sich vorstellen, da ist ganz schön viel Wumms dahinter, was den Netzwerk-Grafik betrifft. Und auch hier haben wir es wieder, Cephmon braucht niedige Latenz, muss sehr schnell die Karten ausliefern.
22:07
Deshalb hohe CPU-Taktung von Vorteil, also wenn man so eine CPU mit drei, vier Gigahertz hat, ist das natürlich so einem Xeon vorzuziehen, der nur so 1,5 im Standardfall schafft. Und man ist da besser getan, weniger Cores dafür mehr Frequenz zu haben
22:26
und eventuell bei größeren Clustern das auch auf eigene Hardware oder natürlich im Cluster mit Proxmox zusammen auf eigenen Notes verteilt.
22:40
Wenn wir mal zu diesem Knackpunkt durch sind, dann kommt meistens auch noch das nächste, die Grafik hier zeigt, wie Ceph so logisch ein bisschen arbeitet. Ich hoffe, ich verwirre die meisten damit nicht, also ich habe selber ein bisschen gebraucht, als ich es gemacht habe.
23:06
Dass es auch so nicht zu kompliziert wird, um ein Gefühl zu geben, wie das ungefähr ist, wenn man auf VM Create klickt und seinen RBD-Storage angibt. Man hat hier oben, fängt man an, man kreiert seine VM, man kreiert seine CD
23:21
und dann kommt schon die erste Auswahl, ja, was verwende ich, mache ich das lib-rbd oder mache ich kr-rbd? Und die Berichte sind immer teils teils, die einen haben bessere Performance und mehr Erfolg in dem Fall, wenn sie kr-rbd, sprich den kernel-rbd-Client verwenden
23:41
und andere Leute haben halt gesagt, ja ok, lib-rbd funktioniert bei uns besser, weil wir unser eigenes Caching damit unter Kontrolle haben. Wo wir gleich zum Thema sind, kr-rbd verwendet den Page Cache, also wir hören immer wieder von Kunden und Usern im Forum, ja, aber seitdem ich umgestellt habe von kr-rbd auf lib-rbd ist auf einmal mein RAM-Verbrauch doppelt so hoch.
24:09
War vorher auch nicht, aber man sieht halt im Page Cache nicht als extra Prozess, wie viel RAM dieser verbraucht. Beim lib-rbd mit jeder Connection, die das KVM aufmacht,
24:24
wächst natürlich dort der RAM-Verbrauch für diesen KVM-Prozess an, weil der extra Caching verwendet, weil lib-rbd eben nicht ein kernel-Interface ist, sondern die Library, die direkt Interface zur Seft ausstellt.
24:41
Wir haben seit Neuestem, also schon etwas her, das CFFS, da ist gut geeignet für ISOs, Templates und Backups drauf zu tun und da haben wir auch wieder dieselbe Qual der Wahl, einmal Fuse Client oder einmal den Kernel Client.
25:00
Je nach Ansatz, also der Fuse Client kann sein, dass der andere Features oder neuere Features unterstützt und der Kernel Client natürlich je nach kernel-Version ein bisschen hinterherhängt. Selber beim kr-rbd oder lib-rbd, da ist es immer schneller. Wenn man die Qual der Wahl getroffen hat, dann geht es auf den Pool,
25:23
also sprich, man hat einmal einen rbd-Pool, den man für seine rbd-Images verwendet und man hat einmal einen für CFFS, oder es sind zwei besser gesagt für CFFS, weil die Metadaten für das File-System wohnen auch in einem eigenen Pool in Seft
25:43
und dann die Daten, die natürlich wieder einen eigenen Pool haben. Das führt meistens auch ein bisschen zum Grübeln, weil es gibt die Placement-Groups und sich die Placement-Groups auszurechnen ist meistens nicht so trivial,
26:01
wenn man mehrere Pools hat und auch Device-Klassen hinzufügt, dass natürlich Pools auf nur bestimmten Devices zu Hause sind und auf anderen nicht. Darum hören wir immer von Kunden, ja, also meine Performance ist gar zu schlecht und man stellt fest, ja, ich habe zu wenig Placement-Groups oder ich habe zu viele Placement-Groups und man muss darüber nachdenken, das anzupassen, glücklicherweise,
26:24
seit ein Autolus kann man das aufwärts und abwärts machen, sprich man kann die Placement-Groups hinzufügen, also vervielfältigen oder man kann sie natürlich minimieren, was natürlich den administrativen Aufwand wesentlich erleichtert.
26:40
Also wer über einen Seft-Cluster nachdenkt und muss sich natürlich vorhin sicher sein, wie viele Pools er haben möchte und wie viel Daten er drin speichern will, darum gibt es nämlich den PG-Calc von Seft, der das eh schon von sich aus macht, man gibt ein paar Daten ein und super hat man seine Anzahl der Placement-Groups
27:05
und damit ist man dann hoffentlich auf der sicheren Seite und wer es automatisch haben möchte, der kann einen, den PG Autoscaler aktivieren, der läuft dann hinterher und je nach wachsendem oder schrumpfendem Cluster passt er die Placement-Groups im Hintergrund an, was wiederum heißt,
27:23
es wird wieder ordentlich Netzwerk-Traffic produziert. Dann kommen wir zu dem ganzen Block, ja, Crush-Map, Placement-Groups, das ist eine Wissenschaft für sich, was wichtig ist, im Standard-Fall werden alle OSDs verwendet
27:40
und sobald man Device-Klassen anfängt, werden halt dementsprechend der Device-Klasse zugeordnete OSDs verwendet und die Verteilung, was bei vielen auch Rätsel auflöst, die Verteilung ist auf Notebene, sprich es wird immer geschaut, dass nicht das selbe Placement-Group auf derselben Note zweimal oder mehrmal vorhanden ist
28:01
und dementsprechend eine Redundanz übers Netzwerk hinaus gegeben ist. Dann kommen wir zu ein paar Fallbeispielen, die habe ich eh beim letzten Mal auch schon mit dabei gehabt und die Basis dafür ist dieselbe, also es hat sich in der Hardware, den Epic,
28:24
habe ich leider nicht mehr zum ausprobieren und den Roam 2, der ist noch nicht da, dass ich da schon umspielen kann, aber so ist der Test, also wenn ihr dann die Folien habt, das könnt ihr auch so abfeuern, das funktioniert auch.
28:41
Zum ersten, wo wir hinkommen, ist kein separiertes Netz. Wie wir im nächsten hier sehen, ja, es ist ein typisches Beispiel, wir haben sehr viele Kunden, die leider irgendwie gebunden sind an entweder zwei Onboard-Devices oder sich denken, ja, naja, eigentlich wenn ich einen Bond mache,
29:01
dann bin ich auf der sicheren Seite für alles, was ich haben möchte und ich verwende einen oder vielleicht noch einen zweiten Switch, um redundant zu sein und will jeden Traffic, sei es ZFS über die Replika, sei es Safe, sei es der ganze VM-Client-Traffic oder Container-Client-Traffic, sei es Chorus, übrigens Heartbeat, der auch irgendwo drüber muss,
29:25
dann läuft da mal ein Backup, das man machen will, oh, da will man in eine Maschine migrieren und dann stellt man fest, naja gut, 128 GB RAM dauern doch etwas, um sie vom einem Memory auf einem Host zum anderen zu schieben und wundern sich dann, dass ihre Infrastruktur zusammenbricht
29:41
und ihre Notes lustig neu starten und man dann quasi mit gestoppten VMs im ganzen Cluster zu tun hat. Wie es eigentlich ausschauen sollte, es ist ungefähr so als Beispiel, das kann natürlich je nach Infrastruktur variieren. Man sieht schon, es ist plötzlich explodiert, das Cluster, obwohl es nur drei Notes sind.
30:05
Man kann natürlich einige Sachen auf, wenn man zwei große Performanteswitches hat, was auch wieder heißt, starke CPU-Leistung, einen guten S6 eingebaut, nicht natürlich den Billigstorfer-Switch, der vielleicht 1200 Euro C&G-Ports bietet
30:23
und unmanaged auch noch drauf ist, das wäre natürlich fatal in der Lage. Hier sieht man, wir haben extra-switches für Storage, einmal für das Cluster, etwas separiert, und dann für den Public Traffic und wir haben jetzt das mal ausgelassen, dass man Backup und Migration
30:43
auch nochmal aufträngen kann, weil die Folie ist nur so groß, wie sie groß ist. Hier sieht man aber schon, wir brauchen mindestens zwei gute Switche. Wir brauchen hier in dem Fall sogar sechs Ports, wenn man die einzeln auftreten will.
31:01
Das Allerwichtigste ist, was wir bei Kunden immer wieder sehen, und was wir in der Doku stehen haben, Trends, Storage-Traffic von dem restlichen Traffic ab. Weil das ist ein Domain von Unkontrollierbarkeit, die man nicht auf dem selben haben will, wie das Cluster-Netzwerk zum Beispiel.
31:23
Oder wie zum Beispiel, wenn man Client-Traffic, wenn man Web-Server anbindet mit irgendwelchen Streaming-Services und die ruckeln vor sich hin, weil das Storage gerade die ganze Bandbreite wegnimmt. Umgekehrt ist natürlich auch der Fall für das Cluster-Netzwerk. Das steckt nie mit dem Storage zusammen.
31:41
Auch wenn mittlerweile das Codosync mehrere Links verwendet und einen davon als Aktiv, je nach Priorität, dann einen weiteren Aktiv hat als Priorität. Und nur Traffic immer auf einem rausgeht, wenn natürlich fast zufällig am selben Switch, beide Links zufällig am selben Switch hängen, hat uns auch wenig geholfen,
32:04
wenn das Storage reinfunkt. Das kann ich nicht oft genug betonen. Wenn man separiert das Netzwerk, dann könnte es friedlicher schlafen. Um ein Beispiel zu geben, haben wir hier zwei nette Grafiken.
32:20
Das sind die aus unserem Radus-Benchmark-Test, den wir 2018 gemacht haben. Da gibt es das Paper zum Download auf unserer Webseite. Da ist es so, wir haben hier einfach mal hergegangen, ein Dreinot-Cluster, 4, 5, 6 und wir haben hier die Bandbreite pro Sekunde
32:42
und wir haben vier OSDs verwendet pro Not, damit wir natürlich je nachdem immer die gleiche Anzahl haben und skalieren können. Und man sieht schon, ein Gigabit Netzwerk für self, das wird wohl nichts. Da ist man ziemlich gleich am Ende der Fahnenstange und wenn wir da jetzt etwas anderes drauf hätten,
33:01
naja, man kann sich das vorstellen. Wir sind bei 10G angelangt. Man sieht, wir sind auch schon ziemlich am Ende der Fahnenstange und die blaue Linie, das 100G, da hätte man noch Luft nach oben, was nicht unbedingt heißen soll, dass man dann allen Treffig gleich wieder da drauf packen kann.
33:22
Das ist leider ein kleiner Druckschluss. Aber man hat für das Netzwerk, vor allem für kleinere Klassen, in dem man NVMe einsetzt, die von sich aus schon so viel Bandbreite bieten, natürlich ein Plus. Umgekehrt haben wir es natürlich noch schöner im Lesen.
33:41
Self macht das schön parallel. Darum sind wir da bei den 100G auch 3,5 Gigabyte, was wir mit einer NVMe gemacht haben pro Server. Ja, das nächste ist Overcommitment. Das ist eigentlich ziemlich einfach und kurz. So, wer findet den Fehler?
34:04
Ich habe da ein paar Maschinen angelegt, wie man sieht. Es sind keine Ressourcen mehr vor, dass ich entweder eine weitere anlegen kann. Und wenn man sich jetzt noch vorstellt, dass man Self-Dienste drauf hat, wie ein Self-Monitor auf einer Not. Man hat vielleicht vier OSDs drin, sind wieder weitere Dienste, die um die CPU kämpfen.
34:24
Naja, man will vielleicht noch in ZDFs eine Replication laufen lassen. Dann ist wieder ein Service, der da läuft und ein Prozess, der da ran braucht. Also wichtig in einem hyperkonvertierten Fall, dass man ein Cluster lieber rausscaled
34:40
und lieber in die Richtung mehr Ressourcen schafft, als sich auf einer Note alles zu packen. Lassen wir mal so sein, man hat seine VMs, drei Notes, eine fällt aus. Naja, was mache ich jetzt mit den restlichen VMs, die werden da nicht mehr starten. Die werden auf dem anderen wahrscheinlich auch nicht mehr starten.
35:00
Also lieber genug Ressourcen zur Verfügung haben und rausscalen. Dann ein beliebtes Ding, Enterprise Hardware. Und da gibt es eine schöne Grafik dazu. Die habe ich das letzte Mal in Chemnitz schon gezeigt, glaube ich.
35:20
Ja, Enterprise Hardware ist leider nicht Enterprise. Kurz unten hier ist eine Spinner, Seagate, als Vergleich daneben eine Evo. Also man hätte auch lieber zwei Spinner kaufen können, dann hätte man sich den Preis für die Evo gespart. Das ist natürlich das Flaggschiff von Samsung, was jetzt auch schon alt ist und den Nachfolger gibt, aber man sieht diesen
35:43
Unterschied in der IOPS Zahl. Also das sind hier IOPS, von unten nach oben ist es besser. Und man hat oben die Latenz. Und da ist natürlich oben ist besser und unten ist schlecht. Und man sieht, dass die Evo bescheidene Werte dafür hat, dass sie eine SSD ist. Also auch wieder Finger von weg und man muss genau
36:02
lesen für jede SSD oder für jede Hardware, die ihr kauft. Das ist leider nicht immer das, was so auf der Packung drauf steht. Im Nachhinein ist Tauschen immer teuer. Dann habe ich ein weiteres liebes Thema, das fällt uns bei ZFS und bei Ceph auf den Füßen. Und da geht es darum,
36:23
wenn man sich das Bild schon anschaut, sieht man, naja, eh, eigentlich da gibt es Input, Output, da gibt es Prozessoren, da gibt es Arbeitsspeicher. Na, das schaut aus, wie wenn das ein Computer wäre. Im Prinzip Redkarten, HWAs sind kleine Computer, die wir uns wieder in einen Computer stecken, um mehrere Disken anzuschließen.
36:43
Und ZFS und Ceph mögen beide lieber einen HWA, weil da weniger drumherum eingebaut ist, was Writes optimiert, was Caching verwendet. RAID funktioniert super, wenn man einen Stapel hat und da wird dann da drauf
37:02
Vollgas geschieben, das macht der Cache super. Sobald man solche lustigen Sachen, wie man im Video sieht, RAID 0, naja, ich kann kein IT-Mod, dann muss ich RAID 0 machen. Lieber schmeißt den RAID-Controller weg und kauft euch einen HWA, bevor ihr RAID 0 macht, weil der Cache ist leider für alle da und der erste, der reinschreibt, der hat den natürlich befüllt
37:22
und wenn die nächste OST reinschreiben will, steht das zumindest. Selbe für ZFS. ZFS will gern wissen, wie sind die Blockgröße der Platten, wie ist das Alignment und man kann darauf wetten, wenn man das nächste Mal bootet und man hat seinen Airpull auf einem RAID-Controller, macht es puff und man kann in der Group
37:42
Rescue Shell sich wiederfinden. Und darum, auch wenn IT-Mod eine Variante ist, haben wir festgestellt, dass bei vielen Controllern leider der Cache nicht abgeschaltet wird. Also wenn man IT-Mod macht, ist zwar der Cache nicht passierbar, aber das heißt nicht, dass der auch intern den wirklich deaktivieren kann.
38:03
Also es gibt dann komische Effekte, die wir uns nicht wirklich erklären können und da wir leider nicht in die Firmware reinschauen können, mutmaßen wir es natürlich in der Hinsicht, dass gewisse Teile, auch das heißt die RAID-Engine nicht komplett abgeschaltet werden können, weil es einfach aus dem Prinzip, wie sie gebaut worden sind oder designt worden sind,
38:25
herstammt, dass ein RAID-Controller immer irgendwelche Probleme machen wird, sei es jetzt im IT-Mod oder wenn er so verwenden wird. Lieber einen HBA kaufen, der ist meistens auch wesentlich günstiger als einen guten RAID-Controller, aber leider HP und Dell haben da was anderes im Sinn und wenn man da
38:43
auswählt, kostet leider der HBA mehr als der RAID-Controller, weil er inkludiert ist. Gut, dann sind wir eh schon zum Schluss. Bitte macht es mit, sei es in der Community Fragen beantworten, sei es Doku schreiben, sei es auch wirklich mitentwickeln, wo wir beim nächsten
39:03
Punkt sind. Ihr setzt einen eher auf den Folien, dem Bug Tracker und unser Roadmap und ihr könnt es auf die Mailing-Liste schreiben und damit werde ich auch am Ende angekommen. Vielen Dank.
39:21
So, wir haben wieder Zeit für Fragen. Schauen wir mal hier an. Hallo. Ist es vorgesehen, dass Live-Migration bei dieser
39:42
ZFS-Szenario mal über die GUI möglich ist? Also im laufenden Betrieb? Schon, vor allem, es geht doch. Also eine ZFS-Replication, wenn die eingerichtet ist, geht es von der Seite, wo der Master die Replication macht, auf die andere Seite geht eine Migration.
40:01
Die Migration geht aber nur im ausgeschalteten Fischstand? Genau. Ich habe das gekundignoriert. Ist das vorgesehen? Das ist in der Werde, das muss aber noch getestet und verfeinert werden, aber es gibt Möglichkeiten, den Rahmen mitzunehmen und das sollte eigentlich
40:21
so weit funktionieren, dass wir dann hoffentlich ZFS- und Live-Migration machen können für VMs. Aber es gibt noch keinen Zeitpunkt für das? Nein, da sitzt gerade ein Kollege dran und er brütet mit dem Kopf, wie man das am besten macht, dass das auch im produktiven Einsatz funktioniert, also das ist aber am Werden, hoffe ich. Das soll dann hoffentlich bald
40:41
kommen. Bei dem Netzwerkbild mit dem 6-Switch-Variante, sind dann da immer zwei Ports im Bonding zusammen? Also zum Beispiel ENS 18 und 19 sind zusammen gebondet oder wie empfehlt ihr das am besten? Also sicherlich für
41:02
Netzwerk-Traffic, wenn man VM-Client-Traffic sieht, kann man natürlich gerne einen Bond verwenden, wenn man nicht unterschiedliche Netze oder eine andere Variante vielleicht hat, die man machen möchte. Prinzipiell ist es beim Cluster, da haben wir es immer spezieller ein bisschen, da bietet
41:22
nämlich Corosync von sich aus eigene Links an. Was den Vorteil hat, der Bond ist unten drunter schon eine Schicht, wo Corosync nicht mitkriegen würde in jedem Szenario, dass vielleicht einfach nur der eine Linkdown ist, weil der Bond halt gerade mal nicht funktioniert. Da macht das Corosync wesentlich intelligenter und
41:42
sagt, okay, ich fahre auf Link 0 und wenn ich nichts mehr höre, probiere ich Link 1 und wenn das geht, dann sind wir immer noch glücklich. Beim Storage, also bei Ceph, ist es so, entweder trennt man auf Cluster und das Public oder man sagt sich, okay, ich mache einen Bond,
42:03
um eventuell mehr Bandbreite zu kriegen, aber dann geht es aber erst, würde ich mal sagen, wenn man fünf oder mehr Nodes hat, weil je nach Cache-Algorithmus kann es sein, dass man halt einen Link einfach saturiert und der andere langweilt sich. Haben wir noch weitere Fragen?
42:31
Hallo, ich muss kurz hoch, ich habe es mir nämlich aufgeschrieben, ich habe drei Sachen. Das erste als Anmerkung, ich fände es sehr interessant, mal zu wissen,
42:42
wieso denn tatsächlich die minimal Hardware-Anforderung ist. Also meint die Konstellation, dass ich eben, ich brauche eben drei Geräte im Cluster in Verbindung mit mindestens
43:01
vier irgendwie Massen- Speichergeräten. Also das hätte ich noch ganz informativ gefunden, vielleicht kannst du das schnell beantworten. Ja, wir hätten es sogar aufgeschrieben. In unserer Doku haben wir im ersten Teil drin, was unsere Minimal-Anforderungen sind, dass es läuft, wo drin steht es für ZFS
43:22
und ich glaube mittlerweile auch für Ceph ein Teil. Und in den Ceph-Sections selber steht auch nochmal auch die Pre-Conditions, das ist das Wichtige bei Ceph, da steht drin, was man denn verwenden soll, um auch wirklich ein glückliches Cluster zu haben. Im Prinzip drei Nodes, wie ich es erwähnt habe, schnelle CPU, schnell RAM,
43:43
immer so viel wie möglich, lieber SSDs oder NVMe anstatt HITs natürlich und mindestens drei Nodes. Und man sieht ja schon anhand der Grafik, die wir hier hatten, mit der Bandbreite.
44:00
Na, jetzt habe ich zu viel gemacht. Geht gerade nicht, meine Präsentation hängt, liebe Officer, danke. Gibt es dann quasi die Bandbreite für Netzwerk, drei OSDs, braucht natürlich reicht 10G für SSDs, wenn man 15 OSDs hat, dann sollte man vielleicht doch lieber auf die 100G oder so etwas umsteigen.
44:22
Mir ging es wirklich um die Minimal-Konstellation. Wenn man ganz minimal rumtesten will, dann kann man sich drei VMs machen und alles in den VMs machen, das funktioniert super. Wahrscheinlich hätte ich das auch selber schon gemacht und hätte euch das ins Wiki geschrieben, aber gibt es einen Grund, dass das Wiki nicht für die
44:41
Community offen ist? Ja, das ist leider der liebe Spam. Also die Wiki-Geschichten sind auf Anfrage, da kann man Anfragen, wo man einen Account bekommt und was man dann reinschreiben möchte. Da die Spam-Welle leider nicht abreißt, wurde das aus
45:02
gutem Grund dann mal geschlossen. Also die registrieren zumindest. Und ich erreiste mir die dritte, abschließende Frage. Kannst du vielleicht noch was zum Politischen sagen? Es hat ja vielleicht einen Grund, dass ihr immer sagt, wir nutzen Debian, habt dann aber eben im Kernel ZFS-Support mit drin
45:23
und nutzt da, verweist ja darauf, dass ihr den Ubuntu-Kernel nutzt. Kannst du vielleicht noch kurz was dazu sagen? Also, diese Konstellation war vor mir schon da. Somit ist die Politik
45:40
mal so ein bisschen an der Seite. Das Wichtige daran ist, wir verwenden Debian wegen der Stabilität, also wegen dem stabilen, läuft 5 Jahre. Man hat den Ubuntu-Kernel, der hat einfach mehr Marktdurchdringung. Also mehr Leute in Produktiven machen das.
46:02
Und deshalb mehr Bugs, die gefunden werden und gefixt werden. Und ZFS will doch jeder haben. Drum ist es auch drin. So eine schöne Frage haben wir noch. Die Frage ist, ab welcher Version kann ZFS die Trimfunktion
46:20
mit SSDs einsetzen? Das gibt es noch eine Zeit lang nicht. 0.8.1. Ich weiß noch nicht, welche Minusversion das bei uns drin war. Ansonsten draußen. Ansonsten draußen, wie gesagt, der ist ja noch eine Zeit lang da. Danke fürs Kommen, Alwin. Und nochmal einen Applaus.