Marathon: Zuweisung persistenter Volumes auf Nicht-Root-Mesos-Festplattenressourcen zulassen

Hallo @timcharper , danke für deine Hilfe hier, wir würden uns über deinen Beitrag freuen.

Was den aktuellen Status angeht, bin ich mir nicht sicher, warum andere Festplatten als Root nicht verwendet werden; sie werden nicht explizit herausgefiltert.

Für Path Disketten klingt der Ansatz gut und ich stimme zu, das scheint ziemlich einfach zu implementieren. Bei Mount Festplatten bin ich mir jedoch nicht sicher, ob es sich um Einfachheit oder den besten Ansatz handelt. Es gibt Dinge zu beachten:

• Mount Festplatten können nicht in kleinere Blöcke aufgeteilt werden. Wenn die Festplatte 100 GB hat, wie kann das Volume _take all_ angeben? Es wird die ganze Festplatte bekommen, aber es muss wissen, wie groß das ist ...
• daher scheint eine Mount Festplatte etwas Besonderes zu sein (denken Sie an eine schnelle SSD)
• Es können mehrere Mount-Festplatten mit unterschiedlichen Spezifikationen im Cluster oder sogar auf einem Agenten vorhanden sein
• Wie würden wir diese unterscheiden/abgleichen?

Indem Sie also einfach ein kind oder kinds hinzufügen, können Sie nur angeben, welche Art für eine Übereinstimmung berücksichtigt wird. Ich denke, das reicht nicht. Angesichts der Tatsache, dass eine Mount Festplatte einen besonderen Zweck haben könnte, möchte ich nicht, dass eine Aufgabe, die kind nicht angibt, meine SSD für besondere Zwecke übernimmt. Vielleicht wäre der Standard Root or Path but NOT Mount ?

Für die Verwendung einer Mount Festplatte möchten wir wahrscheinlich die Festplatte weiter spezifizieren: this task should have a persistent volume on a Mount disk that's labelled with SSD and the persistent volume should include the whole disk .

Irgendwelche Gedanken dazu?

Ich glaube, dass Sie theoretisch Ressourcenrollen verwenden könnten, um zu steuern, welche Festplatten für die Zuweisung durch eine Anwendung verfügbar sind. Dies kann jedoch die Dinge verkomplizieren, da Speicher und RAM von derselben Ressourcenrolle zugewiesen werden müssen. _(ツ)_/¯

Ich kenne keine anderen Signale, die wir verwenden könnten. Vielleicht könnten Ressourcenrollen angegeben werden oder nur persistenter Speicher?

Dafür können wir keine Ressourcenrollen verwenden – sobald Sie eine Ressource statisch reservieren, indem Sie ihr eine Rolle zuweisen, können Sie sie nicht mehr dynamisch reservieren. Ich denke, wir könnten die Logik so ändern, dass sie auf statisch reservierten Datenträgern übereinstimmt, aber dann konnten wir keine Reservierungsbezeichnungen hinzufügen (um zu identifizieren, welche Aufgabe sie verwendet).

Gibt es ein Update zum Implementieren des Verbrauchs von Path Festplattenressourcen? Ich sehe Angebote, die mit 0.0-Datenträgerressourcen protokolliert wurden, während ein paar Zeilen später die richtigen angebotenen Ressourcen protokolliert werden

May 20 16:57:47 daasinoa-vls01 marathon[13795]: [2016-05-20 16:57:47,753] INFO Offer [8054cda3-39a1-4af3-aa5b-fb1020033a7b-O13934]. Considering unreserved resources with roles {*}. Not all basic resources satisfied: cpus SATISFIED (1.0 <= 1.0), mem SATISFIED (128.0 <= 128.0), disk including volumes NOT SATISFIED (256.0 > 0.0) (mesosphere.mesos.ResourceMatcher$:marathon-akka.actor.default-dispatcher-155)

dann sehen Sie in der nächsten Protokollzeile das komplette Angebot, einschließlich der nicht - Root Festplatte ( disk(*) 65536.0 )

May 20 16:57:47 daasinoa-vls01 marathon[13795]: [2016-05-20 16:57:47,754] INFO Finished processing 8054cda3-39a1-4af3-aa5b-fb1020033a7b-O13934. Matched 0 ops after 1 passes. ports(*) 20000->65535; disk(*) 65536.0; cpus(*) 8.0; mem(*) 30989.0 left. (mesosphere.marathon.core.matcher.manager.impl.OfferMatcherManagerActor:marathon-akka.actor.default-dispatcher-103)

Ich habe einen Work-in-Progress-Commit dafür:

https://github.com/timcharper/marathon/tree/multi-disk

Es kompiliert (mit Ausnahme der Tests). Es ist nicht wirklich schön, nur Code herumzuschaufeln, um an dieser Stelle ein Gefühl für die allgemeine Richtung zu bekommen. Ich musste die Strategie der Festplattenressourcenzuweisung ändern, um jede Zuweisung mit einem persistenten Volume zu koppeln (damit das persistente Volume auf der entsprechenden Festplatte erstellt werden konnte). Die Zuweisungsstrategie ist insofern kurzsichtig, als sie nicht verschiedene Kombinationen von Zuweisungen ausprobiert, um erfolgreich zu sein, aber das kann verbessert werden, sobald dies behoben ist.

Was das Ressourcen-Tagging angeht, denke ich an Folgendes:

• Fügen Sie dem persistenten Volume ein Flag "Whole Disk" hinzu. Wenn diese Option aktiviert ist, verwenden Sie die Bereitstellungsdiskette. Wenn nicht, verwenden Sie das Root- oder PATH-Volume.
• Hinzufügen von Einschränkungen zu persistenten Volumes, um den Mangel an Ressourcen-Tags in Marathon auszugleichen. "constraints": [["path", "LIKE", "^.+/ssd.*]] . Dies würde es dem Benutzer ermöglichen, Informationen zu Datenträgereigenschaften in den Pfad einzufügen, in dem der Datenträger bereitgestellt wird, was wahrscheinlich sowieso keine schlechte Idee ist, und dann den Datenträger entsprechend auszuwählen.

Wenn Sie das sehen, schauen Sie sich bitte meine PR an ^^

@timcharper Hast du die Kommentare von @meichstedt zu deiner PR gesehen?
Ein großes Lob an euch beide, dass ihr das anpackt!

Dies wurde zusammengeführt und sollte in 1.4.0 veröffentlicht werden