Die ganze Idee von diesem Blog war ja ursprünglich mal, die Serverkonsolidierung mit Xen anhand von einem konkreten, wirklichkeitsnahen Beispiel zu erläutern – ich habe mich eindeutig nicht dran gehalten, doch als Ausgleich jetzt einmal ein Überbick, über das was war, ist und wird.
Ein Ausschnitt aus xentop ergibt zur Zeit folgendes Bild:
| NAME | CPU(sec) | CPU(%) | MEM(k) | MEM(%) | VCPUS |
| caliban | 112195 | 100.0 | 1048220 | 6.36 | 1 |
| Domain-0 | 123083 | 4.4 | 1945736 | 11.6 | 8 |
| gruenehoelle | 4624 | 3.5 | 1580500 | 9.4 | 1 |
| mond | 126145 | 2.3 | 2096772 | 12.5 | 2 |
| neith | 17457 | 0.5 | 2096828 | 12.5 | 1 |
| phoebe | 10488 | 0.1 | 1048176 | 6.2 | 1 |
| pomona | 19070 | 0.0 | 1048124 | 6.2 | 1 |
| upsand | 1593 | 0.1 | 1048108 | 6.2 | 1 |
Zu den virtuellen Boxen im einzelnen ein paar Worte.
Caliban ist ein Debian-Server, genutzt für die alten Projekte mit einem MySQL 4.0, installiert direkt aus den Paketen von Sarge. Die Last auf dieser Box ist zur Zeit sehr hoch, da zur Zeit die Datenaufbereitung für ein Abschuss eines Projekts stattfindet – heute abend weise ich dem Ding mal mehr Speicher und eine weitere CPU zu (ich _mag_ Virtualisierung :) ). Caliban ist übrigens ein Uranus-Mond, Planeten sind hier traditionell Servernamen und ich führe das jeweils mit passenden Monden weiter…
Domain-0 ist der eigentliche Xen-Host, normalerweise war die Last bei tendentiell 0.0 – bis dann
Gruenehoelle kam, ein mit Intel VT virtualisierter Windows-2000-Server, der als File-, SQL- und Lizensierungsserver für dieses Produkt dient. Xen nutzt die VT-Prozessorerweiterungen mittels QEMU, was augenscheinlich noch nicht wirklich verlustfrei geschieht.
Mond ist ein Tomcat-Applikationsserver für die hauseigene Groupware, die Namensgebung hat selbstverständlich nichts damit zu tun, dass die Groupware auf den Mond geschossen werden soll, sondern ist einfach der Nachfolger für den Server Erde. Die Applikation ist sehr variabel in der Ausnutzung von Ressourcen, obwohl sie bei der Erstellung der obigen Tabelle kaum aktiv war, sind immer mal wieder die beiden zugewiesenen Prozessoren voll ausgelastet.
Neith ist der Tomcat für alle Test- und Demo-Versionen unserer J2EE-Applikationen, weiter nicht erwähnenswert, nur bei der Namensgebung mußte ich etwas mogeln – Venus hat keine Monde, aber 1672 dachte der Astronom Cassini, er hätte einen gefunden.
Phoebe dient als Webserver und ist natürlich ein Saturn-Mond.
Pomona ist ein MySQL-Server in der Version 4.1, mit etwas hängen und würgen läßt sich ein solcher auch unter Etch installieren. Pomona ist übrigens die Göttin des Obstsegens, da der ursprüngliche Server Apfelbaum hieß – absolut untypisch, nach Bäumen heißen hier sonst nur Desktops.
Upsand ist ein neu aufgesetzter Debian-Server mit Tomcat 5.5, MySQL 5 und Java 6, an diesem werde ich die Testversionen unserer Applikationen mit aktueller Basissoftware austesten, Ups And ist ein Sternensystem mit Exoplaneten, ich dachte mir, dass so überraschende Änderungen wie das verpassen von 2 Java-Releases und jeweils einem Major-Release von Tomcat und MySQL einen weit entfernten Namen verdienen.
4 Antworten auf „Be\Last\ungen“
Charon, Nix and Hydra are the moons of the (ex-) planet Pluto.
„Pluto is one of the alternate names of Hades, the Greek god of the Underworld, appropriate for such a presumably dark and cold world“ [1].
So, there you probably should place the software from the dark side. For example…. well, you know… :)
————-
[1] http://en.wikipedia.org/wiki/Pluto
————-
What is so surprising in skipping *one* (not two) major Sun Java(tm) release? Reading some forums you will find out there are developers who still don’t think about switching from 1.4 to 1.6 for their enterprise software because of stability, compatibility and other issues. Not to forget, Sun fixes severe problems in Java when the problem is 2 to 10 years old :):):)
You know, if a set of settled platforms serve well and everything works, migration is only acceptable with a really really good reasons behind.
MySQL 5.0 was in beta when your enterprise software was started. There are no advantages in it compared to MySQL 4.1.x branch, which your system could really really benefit from. Same for Tomcat.
Greetings
hi Geo,
I agree, my post wasn’t 100% fair – it was a (failed?) try to create a blog entry that enjoys my readers. Personally, I see no disadvantages with older (but stable) software versions that do their job – but you should include our customer related situation, it isn’t uncommon that we have to argue with the IT staff about ‚archaic‘ software versions our applications requires. The testing environment is a great chance to institutionalize the process of a regularly upgrade scheme for the underlaying software – in my opinion it should be manageble to perform a kind of software development process that includes the expectations of a „Otto-Normal-Anwender“ (hmm, in English maybe a John Doe user), if an application don’t support the extensions of a newer version it should at least run with it.
You mentioned the server-side software like MySQL and Tomcat: You should know that I try to enable a complete Debian-based network and with the current version 4.0 Etch I had many problems to install running versions of MySQL 4.0 and 4.1 as the stable mirror don’t supports them, for 4.0 I was able to install the Sarge packages, 4.1 was a little bit harder, you can find a little bit about this topic here. Both Tomcat 5 and 5.5 are stable packages in Debian and the newly installed server Upsand is perfectly runnung with Java 6, MySQL 5 and Tomcat 5.5, so the hard work of our developers is highly appreciated.
Yes, I’m talking as a dumb administrator but the topic of versions requirements in the customer side eats many of my work hours…
Renke, the reasons you mentioned are actually the „really really good reasons behind“ which I was talking about :):):):):):):):):)
If the company is using the software only internally, then there could be some arguments against migration. But when a company has to deal with customers… migration is usually required. No doubt.
And how can I forget the problems you had when you had to install archaic MySQL on the Debian, since I have a similar/same problem!
The good news are that there is a pretty good administrator behind that Solar system ;)
while school time I worked for a litte system vendor in Konstanz and found in a co-worker my archetype: As soon as I’m a _real_ good sys admin my next employment contract will be like his:
1st clause: no customer contact
2nd clause: no Microsoft products to use