MySQL NDB Cluster 7.09a mit nur 2 Nodes (nicht 3!)

in der Dokumentation von mysql cluster wird immer darauf hingewiesen, dass man für ein redundantes Setup mindestens 3 Server benötigt: 2 Server für die NDB-Datenknoten und einen weiteren Server als separater Management-Server. Dies ist jedoch unschön, wenn man nur 2 physikalische Maschinen verwenden will/kann.

Mit etwas Konfigurationsarbeit und dem Linux VServer Patch (auf welchem auch die Vserver bei vlinux.biz laufen) lässt sich das Setup dennoch mit nur 2 Servern durchführen wobei auch ein Server komplett ausfallen kann, ohne dass der mysql cluster down ist oder crashed.

Man installiere ein Debian Lenny oder neuer, wähle entweder den bei Debian mitgelieferten VServer Kernel (linux-image-vserver-bigmem) oder baue seinen eigenen (z.B. 2.6.31.7-vs2.3.0.36.27 ) auf jeweils beiden Systemen.

Dann legt man auf den Servern vier virtuelle Server an:

vserver sql0[1-4] build –context 700[0-3] –hostname sql0[1-4]-n sql0[1-4] –interface sql0[1-4]=eth0:192.168.0.10-14 -m debootstrap — -d lenny

Danach wie gehabt mysql ndb herunterladen und installieren (z.B. mysql-cluster-gpl-7.0.9-linux-i686-glibc23) in /usr/local/ entpacken, und einen symlink auf /usr/local/mysql setzen.

Dann die Konfiguration (config.ini) wie folgt aufsetzen:

[NDBD DEFAULT]
NoOfReplicas: 2

DataDir: /var/lib/mysql-cluster
FileSystemPath: /var/lib/mysql-cluster

# Data Memory, Index Memory, and String Memory

DataMemory: 900M
IndexMemory: 300M
BackupMemory: 128M

MaxNoOfConcurrentOperations=100000

StringMemory=25
MaxNoOfTables=4096
MaxNoOfOrderedIndexes=2048
MaxNoOfUniqueHashIndexes=512
MaxNoOfAttributes=24576

TimeBetweenLocalCheckpoints=20
TimeBetweenGlobalCheckpoints=1000
TimeBetweenEpochs=100

MemReportFrequency=30
BackupReportFrequency=10

### Params for setting logging
LogLevelStartup=15
LogLevelShutdown=15
LogLevelCheckpoint=8
LogLevelNodeRestart=15

### Params for increasing Disk throughput
BackupMaxWriteSize=1M
BackupDataBufferSize=16M
BackupLogBufferSize=4M

[MGM DEFAULT]
PortNumber: 1186
DataDir: /var/lib/mysql-cluster

[NDB_MGMD]
Id:1
HostName: sql01

[NDB_MGMD]
Id:2
HostName: sql02

[NDB_MGMD]
Id:3
HostName: sql03

[NDB_MGMD]
Id:4
HostName: sql04

[NDBD]
Id:5
HostName: sql01

[NDBD]
Id:6
HostName: sql02

[NDBD]
Id:7
HostName: sql03

[NDBD]
Id:8
HostName: sql04

[API]
Id:9
HostName: sql01

[API]
Id:10
HostName: sql02

Nun die Management-Knoten auf allen vier VServern starten / initialisieren. Dazu in /usr/local/mysql

ndb_mgmd –initial -f config.ini

ausführen, anschliessend die 4 ndb Knoten starten (ndbd –initial)

Für die API Nodes natürlich noch mit ./scripts/mysql_install_db die mysql Datenbanken anlegen und anschliessend mit chmod mysql.mysql data -R die Rechte passend setzen.

Anschliessend sollte man mit ndb_mgm => show folgenden Output erhalten:

Cluster Configuration
———————
[ndbd(NDB)]     4 node(s)
id=5    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0)
id=6    @192.168.0.12  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0, Master)
id=7    @192.168.0.11  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)
id=8    @192.168.0.13  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)

[ndb_mgmd(MGM)] 4 node(s)
id=1    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9)
id=2    @192.168.0.12  (mysql-5.1.39 ndb-7.0.9)
id=3    @192.168.0.11  (mysql-5.1.39 ndb-7.0.9)
id=4    @192.168.0.13  (mysql-5.1.39 ndb-7.0.9)

[mysqld(API)]   2 node(s)
id=9    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9)
id=10   @192.168.0.12  (mysql-5.1.39 ndb-7.0.9)

Nun sollte jeweils ein ndbd einer Nodegroup (0 und 1) auf einem physikalschen Server liegen, d.h. fällt ein Server aus, so sind immer noch mind. ein ndbd aus der jeweiligen Nodegroup verfügbar und der Cluster läuft weiterhin problemfrei.

Natürlich habe ich vorrausgesetzt, dass die Installation soweit fertig gestellt ist, d.h. mysql user angelegt, Datenverzeichnis angelegt (/var/lib/mysql-cluster – kann auch anders sein..) wurde etc. und in der my.cnf die Einträge für ndb gemacht wurden:

[mysql_cluster]
ndb-connectstring=sql01

[ndb_mgmd]
config-file=/usr/local/mysql/config.ini

Googles DNS Services kritisch betrachtet

Seit ein paar Tagen bietet Google öffntliche DNS Recurser für jedermann an. Behauptet wird zudem, dass Googles DNS Services schneller seien als die vom ISP zugeteilten DNS Server. Ich kann dazu nur sagen, dass ich persönlich es für einen großen Fehler halte, die DNS Server von Google zu verwenden, denn zum einen kann man nicht wissen, was Google mit den DNS Anfragen der User so treibt (damit lässt sich zumindest leicht nachvollziehen, auf welche Seiten ein User so surft), zum anderen wage ich es zu bezweifeln, dass Googles DNS Server wirklich schneller sind als z.B. ein lokal laufender Nameserver auf einem Router, bzw die Nameserver welche der ISP selbst vorgibt. Hier kann man zwar auch nicht wissen, ob seitens des ISP gefiltert wird, aber wenn man sich in dieser Hinsicht gedanken macht, bleibt einem sowieso nur das Betreiben eigener Nameserver und Recursor.

Ein Test mit Namebench bestätigt, dass lokale Nameserver nicht langsamer sind als die von Google angepriesenen Services. Vereinzelt ist Google schneller, da Google natürlich sämtliche Anfragen von Usern cachen kann, während man lokal jedoch meist nicht so viele Seiten besucht und die Wahrscheinlichkeit eines Cachelookups dadurch natürlich sinkt.

Aus Datenschutzgründen sollte man die Nameserver von Google meiner Meinung nach nicht verwenden, selbst wenn ein Lookup 20ms schneller erfolgen sollte, als mit einem vom ISP zugewiesen Nameserver – diese 20ms fallen beim Surfen meist sowieso nicht auf.

Hier nochmal die Auswertung von Namebench für meinen lokalen Nameserver, meinen Nameserver in unserem RZ in Nürnberg sowie als Vergleich Googles Nameserver:

https://www.netz-guru.de/downloads/namebench_2009-12-05_2018.html

Es erscheint auch logisch, warum der lokale Nameserver schneller Antworten kann als ein Nameserver aus einem entfernten Netz – das liegt einfach an den Latenzen der Paketlaufzeiten zu den einezelnen Servern. Lokal hat man hier meist unter 0,1ms, während es bei DSL mindestens 10-20ms dauert, vorrausgesetzt das ist der Nameserver des ISP. Zu Googles Nameserver habe ich schon mal allein 110ms Latenz – da ist der eigentliche Request und die Zeit die das dauert bis ich eine Response bekomme noch nicht mitgerechnet.

Fazit: Finger weg von Googles DNS Services!

Die wikipedia Misere

Soeben habe ich den Post http://blog.koehntopp.de/archives/2675-Communitygift.html gelesen und muss sagen, dass mir der Autor Kristian Köhntopp aus der Seele spricht. Ich selbst habe zwar bisher erst einen einzigen Artikel auf den Weg gebracht, und nur diverse Korrekturen bei einigen Artikeln durchgeführt – aber wie der Autor schon angemerkt hat – es fehlt an Struktur. Durch die fehlende Struktur passieren Fehler, das kostet Zeit und Nerven – auf beiden Seiten. Hoffen wir mal dass sich das in Zukunft irgendwie zum Positiven verändert – Anregungen gibt es ja genug, die Frage ist eben nur, ob diese auch umgesetzt werden.

PHP IPv6 ip2long und long2ip Funktionen

php bietet aktuell ip2long() und long2ip() nur für IPv4 an, für IPv6 gibt es aktuell soweit ich weiss noch keine native Funktionen, deshalb hier meine zwei Funktionen um ip2long und long2ip auch für IPv6 zu verwenden – diese Funktionen benötigen die php gmp-lib, unter Debian: apt-get install php5-gmp:

$ipv6 = “2001:4860:a005::68”;
function ip2long6($ipv6) {
$ip_n = inet_pton($ipv6);
$bits = 15; // 16 x 8 bit = 128bit
while ($bits >= 0) {
$bin = sprintf(“%08b”,(ord($ip_n[$bits])));
$ipv6long = $bin.$ipv6long;
$bits–;
}
return gmp_strval(gmp_init($ipv6long,2),10);
}

function long2ip6($ipv6long) {

$bin = gmp_strval(gmp_init($ipv6long,10),2);
if (strlen($bin) < 128) {
$pad = 128 – strlen($bin);
for ($i = 1; $i <= $pad; $i++) {
$bin = “0”.$bin;
}
}
$bits = 0;
while ($bits <= 7) {
$bin_part = substr($bin,($bits*16),16);
$ipv6 .= dechex(bindec($bin_part)).”:”;
$bits++;
}
// compress

return inet_ntop(inet_pton(substr($ipv6,0,-1)));
}

print $ipv6long =  ip2long6($ipv6).”\n”;
print $ipv6 = long2ip6($ipv6long).”\n”;

Ergebnis:

42541956150894553250710573749450571880
2001:4860:a005::68

postfix policyd 1.80 und mysql ndb cluster als backend patch

Wer den postfix-policyd auf einem Mailserver Cluster einsetzen möchte, der bekommt zumindest mit einer Mysql-Cluster-Datenbank als Backend Probleme, denn NDBCluster unterstüzt kein “Insert delayed” Syntax.

Deshalb hier ein kleiner Patch, der den aktuellen source von debian lenny (postfix-policyd-1.80) patched, damit postfix-policyd keine delayed inserts mehr macht und einwandfrei mit Mysql-NDB-Cluster funktioniert.

postfix-policyd-1.80_mysqlndb.patch

Installiert wird das Ganze mit:

apt-get source postfix-policyd

wget https://www.netz-guru.de/wp-content/uploads/2009/08/postfix-policyd-1.80_mysqlndb.patch.txt

patch -p0 <postfix-policyd-1.80_mysqlndb.patch.txt

cd postfix-policyd-1.80

dpkg-buildpackage  -uc -b

Typo3 4.2.8 und PHP5.3 Kompatibilitäts-Patch

Heute hatte ich mal etwas Zeit über, und konnte mich einem weiteren kleinen Problem welches aus dem Upgrade auf PHP5.3 resultiert widmen. Einige Funktionen sind bei PHP5.3 nicht mehr verfügbar, oder werden mit PHP6.0 nicht mehr unterstüzt. Auf der php Webseite gibt es eine Liste aller veralteten Funktionen.

In Typo3 4.3.0alpha3 ist davon zwar Einiges, wenn nicht sogar Alles behoben, im aktuellen Stable 4.2.8 gibt es jedoch eine Menge Probleme, wenn man auf PHP5.3 umstellt. Deshalb hier der von mir erstellte Patch für typo3 4.2.8 mit PHP5.3

typo3-4.2.8-php5.3-compat-patch

Falls jemand wider Erwarten einen Fehler findet und mir mitteilt, so werde ich den neuen Patch ebenfalls hier veröffentlichen.

Einen komplett gepatchten source gibt es hier zum download, da viele User nicht wissen wie man mit patch umgeht:

https://www.netz-guru.de/wp-content/uploads/2009/07/typo3_src-4.2.8-compat-patched-php5.3.tgz

Internet Zensur und Internet Sperren des DNS in Deutschland umgehen

Am Freitag, den 17.04.2009 war es dann soweit. Die fünf größten Internet-Provider in Deutschland (www.t-online.de, www.arcor.de / www.vodafone.de, www.alice.de, www.kabel-deutschland.de und www.o2online.de / www.telefonica.de) haben einen Vertrag mit dem BKA unterzeichnet, in dem sie sich dazu bereit erklären, vom BKA gelieferte Listen von Domains über DNS-basierte Filter zu sperren.

Abgesehen davon, dass die Sperren an sich schon fraglich sind, da die Sperren gegen Artikel 5 GG verstossen, in dem es ausdrücklich heisst:

“(1) Jeder hat das Recht, seine Meinung in Wort, Schrift und Bild frei zu äußern und zu verbreiten und sich aus allgemein zugänglichen Quellen ungehindert zu unterrichten. Die Pressefreiheit und die Freiheit der Berichterstattung durch Rundfunk und Film werden gewährleistet. Eine Zensur findet nicht statt.

haben die Sperren auch nicht die Wirkung, Kinderpornographie zu unterbinden, Kindesmisshandlungen oder Vergewaltigung zu verhindern, oder in sonst irgend einer Weise etwas auszurichten, außer dem BKA die Möglichkeit zu geben, willkürlich Seiten im Internet zu filtern. Willkürlich deshalb, weil diese Filterlisten “geheim” gehalten werden sollen, und weil es keine Möglichkeit der Kontrolle durch die Öffentlichkeit gibt. So können ebenfalls Webseiten unliebsamer Kritiker oder politischer Gegner gefiltert werden, ohne dass hierbei eine regulierende Instanz notfalls einschreiten könnte. Außerdem stellt sich die Frage, ob es nicht an sich schon strafbar ist, dass das BKA eine solche Liste weitergibt.

Was einem auch zu Denken geben sollte ist der Umstand, dass wenn eben eine solche Liste existiert auf der Webseiten erfasst sind, welche strafrechtlich relevantes Material verbreiten, warum denn dann die Strafverfolgungsbehörden nicht einfach die Provider anschreiben, in letzter Instanz die Server beschlagnahmen und den Geldfluss zu den eigentlichen Tätern zurückverfolgen.

Weiterhin ist es problematisch, über das DNS zu filtern, wenn man sich folgendes Szenario einmal vorstellt:

Angenommen, man möchte einen Konkurrenten im Internet ausschalten – man bräuchte nur einige anfällige Nameserver mittels DNS-Cache Poisoning mit IP-Adressen von Webseiten füttern, welche strafrechtlich relevantes Material anbieten und dann entweder abwarten, bis die Domain des Konkurrenten auf der Sperrliste des BKA landet, oder eben selbst nachhelfen, in dem man anonym die entsprechende Seite meldet.

Abgesehen davon ist es ein leichtes, die DNS Sperren der Provider zu umgehen:

  • Man suche sich im Internet Nameserver, welcher keiner Zensur unterliegen, z.b. die Nameserver von OpenDNS (208.67.222.222 und 208.67.220.220)
  • Man trage die Nameserver in die Netzwerkeinstellungen seines lokalen Rechners oder Router ein. (Bei Windows XP: Start -> Einstellungene -> Netzwerkverbindungen -> Lanverbindung -> rechtsklick Eigenschaften -> Internetprotokoll (TCP/IP) -> Folgende DNS Server verwenden)
  • Alternativ dazu, VPNs oder Anonymizer wie the onio router (TOR),  JAP, oder eine Kombination von beidem.

Bei einem reinen DNS Filter reicht es aus, Nameserver zu verwenden, die eben nicht gefiltert werden und keiner Blacklist unterliegen. Gefilterte IPs aus dem Ausland kann man meist mittels einem VPN oder Anonymizern wie TOR erreichen, wenn der Endpunkt der Verbindung eben nicht mehr gefiltert wird.

Das war es schon – ich würde fast sagen, jeder halbwegs intelligente Mensch schafft es innerhalb von weniger als 10 Minuten die Nameserver zu ändern. Das Filtern an sich geht völlig am Problem des Kindsmissbrauchs vorbei und ist in meinen Augen einfach nur ein trojanisches Pferd um die Gesellschaft langsam an Internetfilter zu gewöhnen und kritisch Denkende oder der Politik Unliebsame aus dem Netz zu verbannen, damit diese keinen weiteren “Schaden” anrichten können. Weitere heiße Luft von diversen Politikern (und entsprechende Kommentare von denkenden Individuen) kann man hier finden:

Alles in allem finde ich es mehr und mehr befremdlich, was in diesem Land so alles geschieht. Auf der einen Seite wird nach mehr Datenschutz und Datensicherheit gerufen (man denke an die zig Affairen Lidl, T-Com, Müller, etc..) – auf der anderen Seite werden Filterlisten etabliert um die User von angeblicher Kinderpornographie abzuhalten. Offensichtlich haben wir keine wichtigeren Probleme – die Umwelt, die Umverteilung von Ressourcen, Krankheiten, Energiegewinnung sind eben nicht so wichtig wie den Bürger unter Kontrolle zu halten…

XTC Xt-Commerce Fix für Multihomed Mailserver

Bei vielen Shop-Systemen wird XT-Commerce eingesetzt, da es vielseitig und flexibel ist um den meisten Anforderungen gerecht zu werden. Will man XTC jedoch in einer Cluster-Umgebung einsetzen, und hat einen Mailserver-Cluster zur Verfügung, gibt es ein Problem sobald XTC versucht, einen Connect zu einem Mailserver aufzubauen, der gerade nicht erreichbar ist. Obwohl weitere Server des Mailserver-Clusters verfügbar sind, gibt XTC nach einmaligem Versuch auf.

Hier ein kleiner Fix für XTC, damit zu einem Hostname alle verfügbaren IP-Adressen zum versenden von Mail durchprobiert werden:

In Zeile 106 in

/includes/classes/class.smtp.php

einfügen:

		// retry connections 
 		$hosts = gethostbynamel($host);
 		while ((empty($this->smtp_conn)) && (count($hosts) > 0)) {
        	$this->smtp_conn = fsockopen(array_pop($hosts), # server
                                      $port,    # the port to use
                                      $errno,   # error number if any
                                      $errstr,  # error message if any
                                      $tval);   # give up after ? secs
 		}

Damit versucht nun XTC mehrmals Mails zuzustellen, wenn der erstmalige Connect zu einem MTA fehlschlägt.

Die fraglichen Testmethoden von Internet Intern

wieder mal ein VServer Test

vlinux.biz wurde in der aktuellen Ausgabe 02/2009 von Internet Intern getestet. Abgesehen davon, dass vlinux.biz vom Preis/Leistungsverhältnis gegenüber den anderen getesteten VServer-Anbietern gar nicht berücksichtig wurde, möchte ich hier doch mal meinen Unmut über die Testpraktiken von Internet Intern loswerden.

Testmethoden oder so was Ähnliches…

Webserver Stress Tool wurde als Last-Test für den vorinstallierten apache2 verwendet. Dabei hat Internet Intern festgestellt, dass von in etwa 18.000 Tests ca. 10.000 Fehler aufgetreten sind – dies ist nicht verwunderlich, hat der von Debian vorinstallierte apache2 als Standard nur 2 Serverprozesse gestartet, sowie ein Connection-Limit von 150 Maxclients gesetzt. Dass hierbei dann natürlich so viele Fehler auftreten, ist nicht verwunderlich – wurde aber von Internet Intern in keinster Weise erwähnt – wundert mich aber jetzt nicht wirklich, denn es hat nicht ein einziger Login via SSH von den Internet Intern Testern stattgefunden. Bei Max-Clients von 150 und 500 parallelen Test-Zugriffen bleiben eben einfach 350 davon unbeantwortet, dies entspricht exakt den von Internet Intern beobachteten Werten.

Konfigurationssoftware

Auch wurde bemängelt, dass vlinux.biz seinen Kunden keine Konfigurations-Software wie Plesk oder cPanel aufzwängen will – hier ist die Philosophie von vlinux.biz so, dass der Kunde selbst entscheiden soll und darf, welche und ob er überhaupt eine Konfigurationssoftware eingesetzt werden soll. Dies als Nachteil auszulegen und darauf rumzureiten, dass Plesk der Quasistandard für VServer-Management sei, ist einfach frei erfunden – schliesslich will nicht jeder VServer Kunde Massenwebhosting mit dem VServer betreiben. Viele Kunden installieren Gameserver oder Teamspeak-Server auf dem VServer, oder nutzen diesen als SVN-Server. Offensichtlich ist man aber bei Internet Intern in dieser Hinsicht nicht in der Lage, über den Tellerrand hinausszuschauen. Auch bietet vlinux.biz als einziger der getesten Anbieter mehr als 15 GB Space, nämlich stattliche 40GB RAID1 Space, und garantiert eine 100MBit Anbindung.

Fazit

Insgesamt kann man den Test von Internet Intern einfach nur als Zeitverschwendung betrachten – auf essentielle Dinge wie maximal verfügbares RAM, Anzahl der Kunden pro Host-System, etc. muss man in diesem Testbericht verzichten. Auch habe ich in den Logs des Test-Servers festgestellt, dass nicht ein einzier Login via SSH von Internet Intern erfolgt ist – vielleicht hatten die Tester auch überhaupt keine Lust, den Test wirklich aussagekräftig zu gestalten. Einfach nur enttäuschend. Ich kann die Internet Intern deshalb nicht empfehlen – kauft lieber die iX oder c’t, die wissen wenigstens wie man aussagekräftig testet…