Es gab das Problem, dass ein SuSE SLES9-Server keine größeren Mengen an Daten mehr über das VPN austauschen konnte. Aufgefallen ist es, als der Zugriff auf die Samba-Freigabe bei großen Verzeichnissen und beim mounten abbrach. Nach weiteren Prüfungen ergab sich, dass weder rsync noch ftp größere Datenmengen über das VPN transportieren können. Im lokalen Netz war davon nichts zu spüren. Die allerersten Fehlersuchen gingen rein um Samba, MTU (das war der Haupttipp aller Kollegen und Admins), Windows-Zugriffe usw. Im Verlauf dessen entdeckte ich diese nützlichen Dinge im Netz:

• Samba Befehlsreferenz deutsch
• Wie man ein Netzwerkprotokoll NICHT designt (SMB)!
• Neue Samba-Versionen für alte Linuxe: Samba Enterprise
• gleiches Problem
• SMB-Übertragung, aber über welche Ports
• HowTo: Novell Open Enterprise Server als PDC
• Erklärung für MTU
• MS KB: MTU in Windows XP
• MS KB: Wie funktioniert der SMB-Verbindungsaufbau
• Samba-Tuning

Es stellte sich die Frage, warum dieser inzwischen doch schon ein par Jahre laufende Server plötzlich derartige Probleme hat. Offensichtlich hängt es mit der Umstellung von VMWare ESX 3.5 auf vSphere 4 zusammen. Seitdem bestand dieses Problem. Die endgültige Lösung kam über eine gänzlich unerwartete Seite: “TCP Segment Offloading” hat in den Linux-Kerneln vor 2.6.12 ein Problem und muss deaktiviert werden.

Der Fall ist zwar schon lange gelöst, ich wollte es aber nicht versäumen, die dazu gesammelten Links und Informationen hier noch nachzureichen.

Microsoft unterhält in Tokio für die Abteilungen Microsoft Innovation Center und Mircrosoft Technology Center ein nagelneues Rechenzentrum. Weil darin auch Aufbauten und Tests für große und spezielle Umgebungen gefahren werden sollen, und somit viele Kunden dort ein- und ausgehen werden, hat man auch einen Innenarchitekten damit beauftragt:

Eine ansprechende und gelungene Umsetzung.

siehe Kenzaburo Tamaru

Unsere Blades HP BL465c zeigen im vCenter ein gelbes Ausrufezeichen und Fehler in der Hardware: “System Board 2 ProcHot Warning limit exceeded”. Laut HP ist das kein Problem, der Fehler kann ignoriert werden:

The “Warning” message in the VI Client (for ESX 4.0 vSphere Client) is false and can be safely ignored.

Siehe HP Support Document c01833766

Vor kurzem habe ich über Nexenta (ZFS für lau) berichtet. Nun entdecke ich, dass die Thomas Krenn AG Nexenta Certified Channel Partner ist. Damit ist eine fertige Lösung ohne jeglicher Bastelei zu erhalten.

Suns Enterprisedateisystem ZFS gibt es wg. Lizenzprobleme nicht für den Linuxkernel (nur über FUSE), aber für OpenSolaris. Nun hat sich eine Entwicklergruppe daran gemacht, um diesen Opensolaris-Kernel eine Art Debian (zumindest mit den Tools aus Debian) herumzustricken. Herausgekommen ist Nexenta. Verheiratet man dies nun mit genügend Hardware (Beispielsweise Backplaze), hat man eine günstige Lösung, die sich hinter einem NetApp-Filer Featuretechnisch nicht groß zu verstecken braucht.

Video über ein USB-Stick-RAID mit ZFS

siehe schwabenblog