Rien ne va plus! Es war schon vor einigen Wochen abzusehen, dass die Konferenz auch in diesem Jahr wieder sehr gut besucht sein wird und dennoch ist es auch für uns wieder überraschend, dass wir nun 2-3 Wochen vor Veranstaltung restlos ausgebucht sind. Zwar haben wir in diesem Jahr ALLE Konferenzräume sowie nahezu das GESAMTE Zimmerkontingent des Holiday Inn ausgeschöpft aber es scheint als könne man davon nicht genug haben! 
Das Haus gehört also für zwei Tage wieder den Teilnehmern der Konferenz!
Wir freuen uns jetzt schon auf zwei spannende Tage hier in Nürnberg und auf viele neue und viele bekannte Gesichter!
Es gibt noch eine letzte Chance an Teilen der Konferenz teilzunehmen. Es werden auch in diesem Jahr von unseren Partner dem Linux Magazin alle Vorträg des Saals Jacobi via Live Stream übertragen. Ein schöner Nebeneffekt ist zudem, dass den Streaming- und Konferenz Teilnehmern nach der Konferenz auch alle Vorträge beider Hauptsäle (Programm: Jacobi und Elisabeth) im Archiv zur Verfügung stehen.
Btw: Man wird es kaum glauben, aber die Planungen und Vorbereitungen rund um die Konferenz 2009 haben bereits begonnen - denn nach der Konferenz ist vor der Konferenz!
Das Herz der Datenbank ist, neben dem eigentlichen MySQL-Daemon, die verwendete Storage-Engine. Im Gegensatz zu vielen kommerziellen Datenbanken wie Oracle und DB2 ist diese bei MySQL entkoppelt vom eigentlichen Serverprozess.
Diese Architekturfeinheit bietet dem Anwender die Möglichkeit innerhalb eines Servers mehrer Engines mit unterschiedlichen Features zu verwenden und abhängig von seinen Bedürfnissen auszuwählen. Hier eine Liste der aktuell existierenden Engines:
- MyISAM Storage Engine
- InnoDB Storage Engine
- MERGE Storage Engine
- MEMORY (HEAP) Storage Engine
- BDB (BerkeleyDB) Storage Engine (ab 5.1.12 nicht mehr unterstützt)
- EXAMPLE Storage Engine
- FEDERATED Storage Engine
- ARCHIVE Storage Engine
- CSV Storage Engine
- BLACKHOLE Storage Engine
Auf die Feinheiten der einzelnen Engines einzugehen würde den Rahmen dieses Beitrags sprengen, jedoch ist der Unterschied zwischen den beiden meist verwendeten Engines MyISAM und InnoDB kurz zu beleuchten: InnoDB ist wie auch die BDB-Engine eine transaktionssichere Datenbank, welche beim parallelen Zugriff mehrerer Benutzer besser geeignet ist, da sie mit Hilfe von Row-Level-Locking und ACID-Transaktion die Datenkonsistenz sicherstellt und trotzdem gutes Antwortzeitverhalten liefert. Da MyISAM auf solche Features verzichtet und großzügig auch mal eine ganze Tabelle blockiert, ist sie für diese Anforderung ungeeignet, bietet aber wiederum im seriellen Zugriff, wie z.B. beim Reporting oder anderen Analyseverfahren eine meist bessere Leseperformance.
Da MySQL einen Mischbetrieb erlaubt kann man natürlich seine Tabellen den individuelle Bedürfnissen anpassen.
Im nächsten Teil geht es um den MySQL-Proxy.
AKCP hat in den letzten Wochen neue Sensoren für die securityProbe-Reihe auf den Markt gebracht. Mit dem neuen “daisyTemp Sensor” kann man pro Port des securityProbes 8 Temperatursensoren in Reihe schalten. Somit können an einem Messgerät bis zu 64 dieser Sensoren angeschlossen werden, was besonders in größeren Serverräumen bzw. kleineren Rechenzentren eine große Flexibilität mit sich bringt, da diese Sensoren untereinander und mit dem securityProbe mit standard CAT5e-Kabeln verbunden werden.
Der neue Sensor “8 Port Sensor Relay” erlaubt es bis zu 64 Relais mit einem securityProbe zu schalten, wobei - wie die Bezeichnung schon sagt - 8 Relais pro Sensor geschaltet werden können. Diese Relais können im Webinterface des securityProbes mit anderen Sensoren verknüpft werden, so dass z.B. bei der Überschreitung eines Temperaturschwellwertes eine weitere Klimaanlage automatisch in Betrieb genommen werden kann und natürlich auch wieder nach Unterschreiten des kritischen Wertes automatisch außer Betrieb genommen wird.
Diese neuen Senoren sind ab sofort bei uns im Shop erhältlich.
Weitere Produkte im NETWAYS Shop:
AKCP MessPC Sensatronics Opengear Servprise Falcom Multitech Siemens Allnet Literatur
Fehlerseiten von Webservern kennt ja jeder. Entweder sind die Bookmarks veraltet und man bekommt einen “404 Not Found” Fehler oder vielleicht hat die Anwendung ein Problem und es meldet sich der ungeliebte “500 Internal Server Error”. Normalerweise liefert der Server nur den reinen Error Code zurück, aber man kann den Webserver auch so einstellen, dass er statt zusammen mit dem Code eine spezielle Fehlerseite ausliefert. In der Regel sehen diese Seiten nicht besonders interessant aus, aber man hat zumindest die Möglichkeit den User wieder auf die Startseite zu lotsen oder ihm eine Suchmaske anzubieten. Manche Admins haben sich aber anscheinend doch etwas mehr Arbeit gemacht und besonders interessante oder witzige Fehlerseiten erstellt. Die besten davon kann man sich in den 404 Research Labs anschauen.
Erst am Freitag haben wir etwas über den aktuellen Stand bezüglich Partnerschaft mit FSC gebloggt. Bereits am letzten Donnerstag gab es diesbezüglich schon eine News-Meldung beim Linux-Magazin. Somit ist zumindest bewiesen, dass der Presseverteiler funktioniert und möglichst viele über die aktuellen Entwicklung informiert sind.
Wir arbeiten bereits an Implementierungen für weitere Hardware-Komponenten und werden diese sobald möglich auf NagiosExchange bereitstellen.
Neulich hatte ich ja schon mal einen Post geschrieben, dass Wikis eine sehr praktische Sache zum Ablegen von Texten oder Dokumentationen sind. Einen Nachteil haben sie aber in der Regel: Da es sich um eine Webanwendung handelt, braucht man auch einen Internetzugang um darauf zugreifen zu können. Eine Alternative wäre es, dass Wiki zusammen mit einen lokalen Webserver zu installieren und dann einfach via http://localhost darauf zuzugreifen. Auch dafür empfiehlt sich TWiki, da es im Gegensatz zu MediaWiki keinen zusätzlichen SQL Server braucht. Praktisch, dass es auf der TWiki Download Page auch Pakete für Windows oder Mac OS X gibt.
Falls nach einem Upgrade auf Nagios V3.0.3 bei neuen Services keine sauberen Serviceext Files mehr generiert werden, bitten wir die geschundenen Gemüter auf die neueste NagiosGrapher-Version (latest/current-20080617) upzugraden. Sie beinhaltet ein paar keinere Bugfixes und ist wie immer einfachst über ‘autoconf’, ‘./configure’, ‘make update’ ruckzuck aufgespielt.
Zu haben gibt’s dieses Release wie immer unter nagiosforge.org.
Viel Spaß damit und schönes Wochenende!
Bereits im November letzten Jahres hat Julian über die geplante Zusammenarbeit zwischen Fujitsu-Siemens-Computers und NETWAYS berichtet. Nach einigen Tagen Test & Entwicklung und vielen Telefonkonferenzen, hat die Arbeit jetzt Früchte getragen.
Fujitsu Siemens hat gestern eine europaweite Pressemitteilung zum Thema Nagios-ServerView-Integration in Zusammenarbeit mit uns veröffentlicht, welche natürlich auch auf unserer Website in vollständiger Fassung bereitgestellt ist.
Das dafür entwickelte Plugin steht bereits seit einigen Wochen auf NagiosExchange zum Download zur Verfügung und wurde mit einem Großteil der aktuellen Systeme erfolgreich getestet und bereits produktiv eingesetzt. Verbunden mit einer entsprechenden NagVis-Visualisierung ist das ganze natürlich auch in unserem Demo-System integriert, damit sich Interessierte schon vorab informieren können.
Wir freuen uns über die entstandene Partnerschaft und neue Integrationsmöglichkeiten für Nagios.
In der Praxis ist es gar nicht so einfach festzulegen, wann ein Server wirklich überlastet ist und wie man das mittels Nagios oder anderer Monitoring Tools messen kann. Auf einem Linux Server ist eines der Kriterien dafür die Load. Und alleine über diesen einen Performance Wert, was normale Werte sind und ab wann der Server zu viel Load hat, gibt es wahrscheinlich Hunderte von Meinungen.
Wichtig ist auf jeden Fall, dass die Load zu der Anzahl der CPUs und der Cores passen muss, denn eine Load von 2 auf einer Dual CPU Dual Core Maschine, bedeutet gerade mal, dass die CPUs zur Hälfte ausgelastet sind. Und dann ist ja auch noch wichtig in welcher Zeiteinheit. Eine Load von 2 in der letzten Minute ist weniger schlimm, als 1,5 in den letzten 15 Minuten. Aus diesen Gründen kann es nicht schaden, sich ein paar Minuten mit den Warnschwellen seiner check_load Service Checks zu befassen. Hier wird das ganze in einem Blogpost nochmal etwas genauer erklärt.
Der erste Artikel unserer angekündigten Performance-Serie widmet sich dem Thema Hardware. Meistens ist zum Zeitpunkt der “auftretenden Langsamkeit” die Hardwareschlacht schon längst geschlagen und der Server eingebaut, jedoch gibt es auch nachträglich gute Potentiale den Zugriff durch Auf- und Umrüstung zu beschleunigen.
Priorität 1 hat bei den meisten Systemen unangefochten das Thema Hauptspeicher. Die Aufrüstung ist aus Kostensicht meist überschaubar und bringt bei korrekter Verwendung des zusätzlichen Speichers, in der Regel das beste Optimierungsergebnis. Stichwort an dieser Stelle ist der Query Cache, der ausgelieferte Ergebnismengen speichert und somit einen erneutem Aufruf aus dem Speicher bedienen kann und damit den Zugriff auf das langsame Plattensubsystem verhindert.
Trotz eines gut angepassten Hauptspeichers lässt sich das Lesen und vor allem das Schreiben auf Platte natürlich nicht gänzlich eliminieren. Da Platten-IO noch immer physikalische Arbeit ist, gilt noch immer die Faustregel: mehr Spindeln -> bessere Performance. Wer die Möglichkeit hat, auf ein RAID 0 (aus Sicherheitsgründen meist 10) zuzugreifen, dem sei dies empfohlen. Ansonsten ist vor allem wichtig, dass sich nicht ewig viele System auf dem selben Plattentopf tümmeln, da MySQL seine IO Ressourcen ungern mit anderen Anwendungen teilt und den Benutzer dann mit mieser Abfrageperformance straft.
Neben einer halbwegs schnellen CPU, ist vor allem die Verwendung eines 64-Bit-Systems ein absolutes muss um den eingebauten Hauptspeicher auch ausnützen zu können. Andernfalls bleibt alles über 4 GB ungenutzt rumliegen.
Unser nächste Teil widmet sich dem Thema Storage Engines.
Last 5 Comments