Diskussion:Netzplanung

Aus LaborWiki
Version vom 1. Dezember 2008, 09:06 Uhr von Til (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

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)

Zum Thema cand: Das Teil mag ich beim besten Willen nicht auf Kisten wie casino oder demnächst esperance haben, dafür ist es zu wartungsintensiv. cand muss regelmäßig neugestartet werden und wenn mal wieder irgendwas in der filigranen Kette des CAN-Busses versagt, müsste direkt auf einer der wichtigen Kisten debugged werden, auf die nur wenige Leute Zugriff haben. Ich halte Roulette für die bessere Lösung. Und für den Fall, dass jemand was kaputtkonfiguriert, sollte man eh ein Backup der Konfigurationsdateien zur Hand haben. Tunix 00:37, 1. Dez. 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)

SVN und BZR sind Kandidaten, die besser nach vegas gehören. Mittlerweile ziehen auch viele externe Leute Sachen aus unseren Repositories. Dies macht sich im Lab hin und wieder durch lahmendes Internet bemerkbar (bzw. durch stotternde Filmwiedergabe auf Roulette). Tunix 00:37, 1. Dez. 2008 (CET)

Ich würde ein lokales SVN haben wollen, das jede Nacht/jeden Vormittag auf vegas gemirrored wird. Es ist nicht wirklich zweckmäßig im Fall von "kein Internet" auch kein SVN/BZR zu haben. Abgesehen davon haben wir keinen Einfluss auf den Fortschritt bei vegas und müssten demnach u.U. sowieso erstmal eine lokale Lösung haben, die wir dann auch direkt ordentlich machen könnten. --Til 09:05, 1. Dez. 2008 (CET)