Tag Archives: mysql

Debian wheezy isc-dhcp-server with mysql support / dbi support für debian Squeeze howto

Hier http://blog.alex.org.uk/2011/02/25/adding-sql-support-to-dhcpd-part-3/ gibt es einen Patch für ISC DHCP Server 4.2 welcher auch für den isc dhcp server in debian wheezy (4.2.2) funktioniert. Um dieses als .deb Paket für debian squeeze zu bauen braucht es folgendes:

1. /etc/apt/sources.list Zeile hinzufügen:

deb-src http://ftp2.de.debian.org/debian/ wheezy main

apt-get update

cd /usr/src

apt-get source -t wheezy isc-dhcp

wget http://blog.alex.org.uk/wp-uploads/dhcpd-dbi-20110202-01.patch

cd isc-dhcp-4.2.2.dfsg.1/

patch -p1 <../dhcpd-dbi-20110202-01.patch

in debian/rules

“–with-dbi” hinzufügen in Zeile 49 und 77

dpkg-buildpackage

cd ..

dpkg -i isc-dhcp-common_4.2.2.dfsg.1-5+deb70u2_amd64.deb

dpkg -i isc-dhcp-server_4.2.2.dfsg.1-5+deb70u2_amd64.deb

 

Die ultimative E-Mail Lösung – The ultimate E-Mail Solution

Es war einmal ein Mailserver…

Wenn man Administrator eines produktiv genutzten Mailservers ist, macht man sich schon ab und zu mal Gedanken, wie man die Probleme, welche beim Betrieb des Servers auftreten oder auftreten könnten, mit möglichst wenig Aufwand – jetzt im Sinne von möglichst wenig Aufwand in der Zukunft – lösen kann. Ich betreibe einen kostenlosen E-Mail Dienst mit derzeit ca. 12.000 Usern. Seit 1998 hat sich das Setup des Mailservers eigentlich kaum geändert. Damals war sendmail noch das Nonplusultra, man war stolz dass SMTP-Auth und diverse Workarounds wie POP-Before-SMTP etc funktionierten, und im Allgemeinen gab es auch weniger SPAM. Zu dieser Zeit hatte quickemail.de ca. 500 User und die Welt der Flat-File Konfiguration war noch in Ordnung.

Irgendwann reicht das jedoch nicht mehr aus – Flat-Files werden schnell unübersichtlich und es musste eine Lösung her, um zumindest die E-Mail Accounts und User zu verwalten. Eine mySQL Datenbank war schnell aufgesetzt und mit ein paar Scripts und Cronjobs wuchs die Userbase dann immer weiter an. Da gingen dann aber auch die Probleme los.

SPAM von Botnets == DDOS?

Wenn man mehrere tausend User auf einer physikalischen Maschine hat, bringt das diverse Probleme mit sich. Zum einen braucht man ständig größere Festplatten, zum anderen natürlich auch mehr CPU und RAM. Das lässt sich eigentlich auf normaler Hardware noch relativ einfach erweitern. Problematisch wird das ganze dann, wenn man distributed SPAM von diversen Botnets abbekommt. Nicht nur der Mailserver an sich ist hier dann überfordert – bei jedem Connect wird ein nslookup durchgeführt, was sich auch wieder mit erhöhter Last auf den Nameservern auswirkt. Irgendwann ist dann jedoch Schluss – bei 200 gleichzeitigen Connects und einer Load von >100 kann es schon mal ein paar Minuten dauern, bis man diverse Services gestoppt hat um zumindest die Maschine wieder administrieren zu können.

SPOFs am laufenden Band

Eine einzelne Maschine zu verwenden ist natürlich auch nicht gerade von Vorteil. Fällt die Hardware aus, oder sind die Platten voll, steht die Maschine und nichts geht mehr. Klar kann man solche Ausfälle durch gutes Monitoring minimieren, spätestens jedoch beim nächsten Upgrade steht der Dienst erst mal wieder.

Wie man diese Probleme in den Griff bekommt?

Nun, wenn man nicht gerade im Lotto gewonnen hat, braucht man hier eine günstige Lösung die dennoch gut skaliert und fehlertolerant ist, also die Mails an sich redundant speichert, sowie mehrere Server zur Verfügung stellt um bei einem ausgefallenen System dennoch den Dienst aufrecht erhalten zu können. Das gestaltet sich jedoch gar nicht so einfach. Alleine dafür zu sorgen, dass die Daten auf allen Maschinen synchron sind, ist eine Herausforderung.

Es gibt diverse Lösungen mit NAS oder DRBD, proprietäre Lösungen von diversen Herstellern, Backup-Mailserver, etc – aber eine wirkliche günstige Alternative die mit normaler x86er Hardware auskommt, und bei der man nicht Tausende Euro Lizenzgebühren zahlen muss, hatte ich bisher noch nicht gefunden.

Deshalb habe ich mich mal eine Woche intensiv damit beschäftigt, das Mailproblem, zumindest für mich, ein für alle mal zu Lösen.

Continue reading Die ultimative E-Mail Lösung – The ultimate E-Mail Solution

Nach einem Datenbank Crash fix alle mysql DBs/Tabellen reparieren

Es kann schon mal vorkommen, dass nach einem Reboot oder Hard-Reset eines Servers der mysql-Server meldet, dass einige Tabellen defekt sind. Die Datenbank startet dann zwar ganz normal, einige Queries auf defekte/korrupte Tabellen können dann jedoch nicht mehr ausgeführt werden.

Um diese defekten Tabellen zu reparieren, kann man z.B. myisamchk mit den Optionen -rf im Datenverzeichnis von mySQL (unter Debian /var/lib/mysql) die Datenbanken reparieren. Alternativ kann man dies jedoch auch direkt mit mySQL erledigen, der Syntax lautet dann REPAIR TABLE <tabellenname>.

Continue reading Nach einem Datenbank Crash fix alle mysql DBs/Tabellen reparieren

mysqlfs mit mySQL NDB Cluster als verteiltes Dateisystem

Jeder der kritische Anwendungen über das Web laufen hat, wie z.B. einen Onlineshop, stellt sich irgendwann, bei hinreichend großem Umsatz, die Frage, wie man das System noch ausfallsicherer machen kann.

Meist wird dann hierzu ein Loadbalancer (ob Hardware oder Software ist erst mal egal) aufgesetzt, welcher die Anfragen an mehrer Server verteilt, welche sich einen gemeinsammen Massenspeicher teilen. Dadurch ist es möglich, dass einzelne Server gewartet werden können, bzw. auch ausfallen können, ohne dass die Applikation dadurch gestört wird.

Leider beschränkt sich diese Variante auf nur eine Location, d.h. wird aus irgendwelchen Gründen z.B. die Internetanbindung an das System unterbrochen, ist die Applikation offline.

Dies kann man damit umgehen, dass man das System multihomed aufbaut, d.h. mehrere Server an unterschiedlichen Standorten betreibt, um bei einem Ausfall von einem Standort trotzdem noch erreichbar zu sein. Diese Variante hat den Nachteil, dass die Daten des Systems sehr aufwändig synchronisiert werden müssen, falls ein Standort nicht mehr erreichbar war. Weiterhin muss man auch bei Updates etc. aufpassen, dass es keine Versionskonflikte bei der Applikation gibt, denn man kann die Software nicht an beiden Standorten gleichzeitig aktualisieren.

Benötigt wird für so eine Lösung also zum einen eine Datenbank, welche automatisch repliziert und dies auch über mehr als einen Standort hinweg, weiterhin dazu noch ein Dateisystem, welches verteilten Host-Systemen eine gemeinsame Datenbasis bereitstellen kann.
Continue reading mysqlfs mit mySQL NDB Cluster als verteiltes Dateisystem