1) Die standardmäßige AWS-Instanz für JuJu-Bootstrap scheint eine kleine EC2 zu sein. Gibt es Nachteile, wenn man stattdessen eine Mikroinstanz daraus macht? Welche Instanz wäre in Bezug auf Kosten und Leistung ideal? (Ich führe möglicherweise eine Storm-Topologie auf AWS über JuJu aus, falls das hilft. Ich weiß noch nicht, wie groß der Cluster sein wird.)
2) Dem JuJu-Bootstrap-Knoten auf AWS ist automatisch ein 8-GiB-Datenvolumen zugeordnet. Ist das notwendig? Wofür wird es verwendet? Gibt es eine Möglichkeit, einen Bootstrap-Knoten ohne dieses zugeordnete Datenvolumen bereitzustellen bzw. den Typ des Datenvolumens zu ändern?
Ich konnte in den JuJu-Dokumenten online keine Informationen zu diesen Fragen finden.
Antwort1
Da es so etwas wie „winzig“ nicht gibt, nehme ich an, dass Sie eine Mikroinstanz meinen. t2.microDiese sind burstfähig und wir haben durch Erfahrung herausgefunden, dass Mikros einfach zu schwach sind, um einen Bootstrap-/State-Server-Knoten auszuführen.
Wenn Sie Kosten sparen möchten, können Sie eine Arbeitslast auf dem Bootstrap-Knoten ausführen, sodass Sie eine Maschine effektiv sowohl als Koordinationsknoten gemeinsam nutzen als auch für echte Arbeit verwenden. Vielleicht sollten Sie auch erwägen, Juju im HA-Modus auszuführen, sodass Sie einen Statusserver auf mehreren Knoten haben:
https://jujucharms.com/docs/stable/controllers-ha
Auf diese Weise verschwenden Sie keine Knoten, aber Sie setzen auch nicht alles auf eine Karte.
Über das Datenvolumen bin ich mir nicht im Klaren. Ich werde nachfragen und die Information hinzufügen, wenn ich sie bekomme.