Diskussion:Netzplanung: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
K
Zeile 18: Zeile 18:
 
Hat man dafür nicht sein eigenes bastelenvironment?<br>
 
Hat man dafür nicht sein eigenes bastelenvironment?<br>
 
Welcher use-case benötigt eine laborumgebung auf ner virtuellen kiste (sei es convenience, selbst da fällt mir nix ein)??
 
Welcher use-case benötigt eine laborumgebung auf ner virtuellen kiste (sei es convenience, selbst da fällt mir nix ein)??
 +
 +
1. Das Labor soll sich auch in seinen Möglichkeiten etwas weiterentwickeln, und es ist ziemlich praktisch sich mal eben für $stuff ein System hochziehen zu können.
 +
2. Dienste trennen. Ich denke, es ist unstrittig, dass wir 3 Systeme haben wollen, weil auf rl nunmal gebastelt werden wird. Telko-Stuff, SVN/BZR etc. sollen aber auf einem möglichst selten geänderten System laufen, da entweder die Daten oder der Dienst nunmal ziemlich wichtig sind. => Das Raid ist von daher sowieso angebracht und ein sync-/backup-Plan würde auch nicht schaden. Da sowohl der Asterisk, als auch der CANd direkten Hardwarezugriff brauchen und CANd nicht auf esperance laufen soll (subject to changes, s.o.), fällt eine Virtualisierung dieser Systeme flach => 3 physikalische Systeme.
 +
Wir können die 3. Kiste dann auch gleich so auslegen, dass man noch ein paar andere Systeme darauf virtualisieren kann, der Kostenaufwand ist so überschaubar, dass man das mit einer Kollekte wohl wird lösen können. --[[Benutzer:Til|Til]] 22:42, 30. Nov. 2008 (CET)

Version vom 30. November 2008, 23:42 Uhr

Gleich 4 Stromverbraucher? Warum so viele Kisten? Tunix, schau mal bitte auf diese Seite Diskussion:Umzugsplanung. Der cand ist mittlerweile zu wichtig für den Laborbetrieb als das er auf RL sein sollte.

ja, 4 Stromverbraucher. Wie dick wir die dimensionieren, können wir ja dann schauen. Die Aufteilung sollte schon sein. Der cand muss auf roulette, denn er ist ein Stück Software mit und an dem schon ab und zu noch gebastelt wird, ähnlich wie ltv. Esperance wird sehr restiktiv gehandhabt werden und daher nur so ca. 4 user haben, ähnlich vegas.

Alternativ: "nur" casino, roulette und esperance, esperance macht die Telko-Sachen im nativen System (wg. direct HW access und so) und wir virtualisieren den ganzen Rest. Würde dann eine Kiste sparen, dafür sollten wir esperance dann dicker dimensionieren und nach Möglichkeit zumindest mit einem Raid 1 versehen. Für die Hardware sollten wir dann vermutlich zusammenschmeissen um zumindest etwas mit zwei Cores (!= Atom 330) + 2n 500GB Platten anzuschaffen (n \in N >= 1). SATA-Raid Controller anyone? (OT: discuss-beträge bitte mit Namen versehen, das macht das Lesen einfacher) --Til 13:37, 29. Nov. 2008 (CET)


Hansi: Jo klar! Bevor wir virtualisierungsdings anschaffen, bitte nennt mir doch mal die use-cases dafür!?
Wild server aus der luft zu schneiden bringt nix, wenn die teile hinterher völligst unterlastet da herumstehen!
Also, her mit den konkreten use cases für all die kisten!
Wer zum beispiel will sich ne virtuelle box auf unserem server aufsetzen??
Hat man dafür nicht sein eigenes bastelenvironment?
Welcher use-case benötigt eine laborumgebung auf ner virtuellen kiste (sei es convenience, selbst da fällt mir nix ein)??

1. Das Labor soll sich auch in seinen Möglichkeiten etwas weiterentwickeln, und es ist ziemlich praktisch sich mal eben für $stuff ein System hochziehen zu können. 2. Dienste trennen. Ich denke, es ist unstrittig, dass wir 3 Systeme haben wollen, weil auf rl nunmal gebastelt werden wird. Telko-Stuff, SVN/BZR etc. sollen aber auf einem möglichst selten geänderten System laufen, da entweder die Daten oder der Dienst nunmal ziemlich wichtig sind. => Das Raid ist von daher sowieso angebracht und ein sync-/backup-Plan würde auch nicht schaden. Da sowohl der Asterisk, als auch der CANd direkten Hardwarezugriff brauchen und CANd nicht auf esperance laufen soll (subject to changes, s.o.), fällt eine Virtualisierung dieser Systeme flach => 3 physikalische Systeme. Wir können die 3. Kiste dann auch gleich so auslegen, dass man noch ein paar andere Systeme darauf virtualisieren kann, der Kostenaufwand ist so überschaubar, dass man das mit einer Kollekte wohl wird lösen können. --Til 22:42, 30. Nov. 2008 (CET)