Kürzlich habe ich etwas Hardware im RZ für unseren KVM VServer Cluster erweitert. Nun schafft unser Disk-Subsystem 1000MB/sek:
Benchmark mit 1MB Blocksize, unlimitiertem Disk-IO und 4 Cores, 4 GB RAM, normale KVM VServer haben ein Disk-IO Limit bei 50MB/s read, 30MB/s write.
Endlich weniger IO-Wait 🙂
Yippie!
Sieht so aus als ob GMX aktuell bei spamcop gelistet ist:
http://www.senderbase.org/senderbase_queries/detailip?search_string=212.227.15.18
Eigentlich sollte man meinen, dass gerade ein Anbieter für kostenlose E-Mail Accounts seinen Usern eine einfache Möglichkeit bieten könnte, via E-Mail erreichbar zu sein. Das ist aber leider fernab der Realität wie ich kürzlich schmerzhaft feststellen musste. Ein in .de tätiger Freemail Anbieter schafft es wirklich auf höchst kreative Art und Weise sich so von der Aussenwelt abzuschotten, dass wohl nicht einmal Ray Tomlinson, der Erfinder der E-Mail, eine Chance hätte, sich bei diesem rießigen Freemail Anbieter elektronisch Gehör zu verschaffen.
Das Problem bei diesem Freemail Anbieter mit drei Buchstaben war, dass es der verwendete Amavis bzw. Spamassassin wohl etwas zu sehr genau mit Mails von unseren Mailservern nahm, und deshalb prompt jede E-Mail von unseren Mailserver als Spam markierte. Kurz – es lag ein Konfigurationsproblem vor oder aber wir wurden geblacklisted. Ich habe daher versucht, irgendwo auf der Webseite Informationen für Postmaster zu finden, was nun zu tun sei. Das Kontaktformular versteckt sich hinter der FAQ für Anwender ganz am Ende der Seite – ich habe es nicht selbst gefunden (ich würde ein Kontaktformular auch nicht verlinkt in der FAQ erwarten, es ist mir unklar warum nicht direkt auf der Seite in der Navigation ein Link zum Kontaktformular existiert). Ich habe stattdessen die 0900er Hotline angerufen. Das erste mal nach ca 2 Minuten – einfach Gespräch weg, das zweite mal nach ähnlicher Zeit, wieder Gespräch weg – das dritte mal habe ich dann auf einer 0180er Nummer angerufen. Das Voice System dort hat mir wieder eine 0900er Nummer genannt – diesmal aber eine andere. Ich habe auch dort angerufen, die Ansage sagte 0,14 EUR / Minute (wahrscheinlich ein Fehler, mir scheint dass deren Asterisk genauso kaputt ist wie deren Spamassassin), nach ca. 10 Minuten Warteschleife (ich dachte diese muss seit neuestem in .de kostenfrei sein?) habe ich dann endlich jemanden am Telefon.
Ich erkläre dass ich keine Endkunde bin, sondern ein anderer ISP, dessen User einfach nur an die User des Freemail Anbieters E-Mails zustellen wollen. Nach Rückfrage mit dem Teamleiter erklärte man mir, ich müsse in das FAQ auf der Webseite unter “Anwender FAQ” ein Kontaktformular finden – Glückwunsch, das Alles hat insgesamt nur knapp eine halbe Stunde gedauert!
Was ich dennoch überhaupt nicht nachvollziehen kann – warum gibt es nicht einfach eine ganz normale E-Mail Adresse support@? Das sollte doch für einen Freemailanbieter eine Kleinigkeit sein, den Kunden wenigstens halbwegs unkompliziert Support zu bieten. Echt erbärmlich, ein Armutszeugnis, oder aber Beweis für die Servicewüste Deutschland.
Da ich gerade Zugriff auf mehere Virtuelle Server (KVM virtualisiert) habe, habe ich mal fix ein paar Tests gemacht um die Performance der Systeme zu vergleichen.
Die technischen Daten:
profitbricks: 1 Core, 1GB RAM, 25GB HDD 33,40 € / Monat
xirra: 1 Core, 512MB RAM, 40GB HDD 4,90 € / Monat
Smart Weblications: 1/4 Core, 256MB RAM, 10GB HDD – 4,90 € / Monat
Betriebssystem jeweils Debian 6.0 64bit.
Ich habe einfach den aktuellsten Linux Kernel (3.5.1) geholt, und gemessen wie lange jede KVM zum Entpacken sowie zum Compilen braucht, hier die Ergebnisse:
Bei Profitbricks sind die Systeme zweifach redundant aufgebaut. Ich habe in meiner Testphase dennoch einen Ausfall von ca einer Stunde gehabt. Die KVMs liefen zwar, aber Disk-IO war nicht möglich, das Disk-Subsystem war wohl abgestürzt. Smart Weblications setzt ceph als Storage Backend ein welches mehrfach redundant aufgebaut ist. Bei Smart Weblications können die KVMs im Fehlerfall live auf einen alternativen Host migrieren – der User merkt hiervon nichts. Sollte doch ein kompletter Host ausfallen, z.B. durch Hardwaredefekt, dann werden die KVMs bei Smart Weblications sofort auf einem anderen Host neu gestartet. Da die Systeme sehr schnell booten (default Install 120Sek, Reboot/Boot ca. 15 Sek) ist die Downtime sehr gering. Xirra bietet kein HA an.
Auf der Webseite von Profitbricks steht zwar, dass man sich anmelden und kostenlos testen kann, in Echtzeit wie bei Smart Weblications geht dies jedoch nicht. Xirra bietet keine Testlaufzeit an. Von den Preisen her sind xirra.net sowie smart-weblications relativ ähnlich, xirra.nets günstigster VServer hat etwas mehr RAM und Plattenplatz, ist aber von der CPU her etwas langsamer als Smart Weblications. Profitbricks ist mit über 30 € / Monat und der langsamen CPU sehr teuer.
Ergebnisse:
xirra time tar -xvjf linux-3.5.1.tar.bz2 real 0m50.216s user 0m15.369s sys 0m2.196s root@130-185-104-xx:/usr/src# time apt-get -y install build-essential real 0m30.203s user 0m0.992s sys 0m0.772s root@130-185-104-xx:/usr/src/linux-3.5.1# time make real 56m45.931s user 47m27.670s sys 4m42.290s root@130-185-104-xx:/usr/src/linux-3.5.1# time make modules_install real 2m10.658s user 0m3.052s sys 0m2.148s root@130-185-104-xx:/usr/src/linux-3.5.1#
profitbricks time tar -xvjf linux-3.5.1.tar.bz2 real 0m39.253s user 0m30.580s sys 0m4.120s root@profitbricks:/usr/src# time apt-get -y install build-essential real 0m29.856s user 0m4.760s sys 0m3.260s root@profitbricks:/usr/src/linux-3.5.1# time make real 106m13.465s user 88m54.050s sys 8m45.620s root@profitbricks:/usr/src/linux-3.5.1# smartweb time tar -xvjf linux-3.5.1.tar.bz2 real 0m29.412s user 0m13.813s sys 0m1.744s root@kvm00000000542:/usr/src# time apt-get -y install build-essential real 0m27.875s user 0m3.184s sys 0m1.232s root@kvm00000000542:/usr/src/linux-3.5.1# time make real 53m16.430s user 44m26.715s sys 4m5.187s root@kvm00000000542:/usr/src/linux-3.5.1# time make modules_install real 2m38.441s user 0m5.756s sys 0m2.932s root@kvm00000000542:/usr/src/linux-3.5.1#
Wieder mal ein neues Update, diesmal:
– Multilanguage via Smarty
– neue KVM VServer – Linux und Windows möglich, kostenlose Testphase – neue Kunden können diese VServer 12 Stunden lang absolut kostenlos testen!
Jede Menge Bugfixes und Erweiterungen unter der Haube 😉
seit einiger Zeit biete ich auch direkt Mietcluster auf GlusterFS Basis inklusive Loadbalancer und Failover an. Dazu gehört auch 24/7 Monitoring sowie das durchführen von komplexen Setups wie z.B. Master-Master Mysql Cluster etc.
Da ich in letzter Zeit mit Mails diesbezüglich geflutet werde, hier mal der Link zur Firma 🙂 => www.smart-cluster.com
Als ich heute versucht habe, eine Mail an einen unserer Kunden zu schicken, staunte ich nicht schlecht als die Mail gebounced wurde. Unsere Mailserver seien angeblich SPAM-Schleudern und wurden mittel Barracuda Reputation geblockt. Folgt man dem angegebenen Link, kann man dann eine Anfrage stellen, den Mailserver aus der RBL entfernen zu lassen – das dauert dann (angeblich) bis zu 12 Stunden. Alternativ kann man sich bei emailreg.org einen Account anlegen um dort die IPs des Mailservers auf eine Whitelist setzen zu lassen – dass das Ganze dann 20 US $ Kosten soll, erfährt man erst wenn man sich einen Account angelegt hat – eine Unverschämtheit wie ich finde.
Dazu kommt noch dass der Aufwand die Mailserver dort aus deren RBL zu delisten bei einem Cluster mit vielen Mailservern enorm steigen kann. Man muss sich ja immer durch irgendwelche Forms mit Captchas durchhangeln – auf ein Feedback seitens Baracuda Central wartet man wohl vergeblich.
Ich kann nicht nachvollziehen, warum einige Mailserver-Admins der Meinung sind, dieses perverse System unterstützen zu müssen. Der Ärger mit Kunden die keine Mails zustellen können und der Aufwand whitelists zu Pflegen stehen doch in diesem Falle in keinem Verhältnis mehr. Dazu kommt noch, dass sich SPAM auch sehr effizient mit den üblichen Opensource-Lösungen wie dspam, spamassassin, diversen Filterlisten wie SpamCop und Spamhaus, amavisd, Greylisting etc filtern lässt.
Aber eine gute Geschäftsidee wäre es schon, einfach mal eine Blacklist aufzubauen, alles erst mal zu Blacklisten, für das Whitelisting Geld zu verlangen und dann irgendwelche Marketingmenschen in größeren Unternehmen dieses System als innovativ zu verkaufen und nochmals die Hand aufzuhalten. Dieser Gedanke könnte einem zumindest in den Sinn kommen, liest man sich diverse Foren im Netz durch.
Einfach nur frustrierend…
UPDATE:
http://packetstormsecurity.org/papers/evaluation/Barracuda_Evil.txt bestätigt meinen Verdacht, dass das Barracuda Zeug einfach nur Müll ist…
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
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!
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