Mit VLANs und Zugang zu SAN-Systemen will Strato seinen Kunden die Möglichkeit geben, hochverfügbare und lastverteilte Web- und Cloudanwendungen anzubieten. ZDNet zeigt, welche Szenarien sich mit den neuen Produkten realisieren lassen.
Der im November von der Deutschen Telekom übernommene[1] Webhoster Strato[2] hat seine Produktpalette deutlich erweitert. Kunden von dedizierten Servern können ab sofort VLANs, Speicherplatz auf SAN-Storagesystemen und IPv6 buchen.
Damit bietet der Berliner Webhoster erstmals ein Portfolio an, das für den Aufbau missionskritischer Web- und Cloudangebote geeignet ist, die Hochverfügbarkeit garantieren können. Das ist für einen Anbieter von fertig konfektionierten und damit preisgünstigen Serverlösungen durchaus ein Novum.
Bei dem Angebot "Strato ProNet VLAN" handelt es sich technisch gesehen nicht um ein VLAN auf der OSI-Schicht 2[3], sondern um ein privates IP-Teilnetz aus dem Bereich 10.x.y.0/24, in das der Kunde bis zu 254 Server einbuchen kann. Dazu nutzt Strato die zweite Netzwerkkarte, über die jeder dedizierte Strato-Server verfügt.
Die Preise richten sich nach der bestellten Bandbreite. 10 MBit/s kosten 5 Euro pro Monat, 100 MBit/s liegen bei 15 Euro. Für 1 GBit/s verlangt Strato stolze 145 Euro. Hinzu kommt eine Pauschale von 7,50 Euro pro Netz. Da die zweite Netzwerkkarte physisch neu verkabelt wird, muss eine einmalige Setup-Gebühr von 49 Euro bezahlt werden, die in der Einführungsphase jedoch erlassen wird, siehe Bild 1[4].
Über das private VLAN können die Server des Kunden miteinander kommunizieren, ohne im Internet sichtbar zu sein. Wer beispielsweise die MySQL-Datenbank seiner Webanwendung auf einem zweiten Server betreibt, kann mysqld an das VLAN-Interface binden und braucht sich über direkte Datenbankzugriffe aus dem Internet keine Sorgen mehr zu machen.
Ein solches Szenario lässt sich auch über eine Software-VPN-Lösung, etwa per tinc[5] oder OpenVPN[6], realisieren. Dabei entstehen jedoch Protokoll-Overhead, CPU-Last und Wartungsaufwand. Diese Faktoren lassen sich für ein paar Euro mehr im Monat eliminieren.
Bildergalerie
Neue Funktionen für Dedicated Server bei Strato[7]
» zur Bildergalerie ...[7]Durch die Verwendung von iSCSI kann Strato die bestehende Netzwerkinfrastruktur in seinem Rechenzentrum nutzen und muss keine Fibre-Channel-Verkabelung aufbauen. So lassen sich die Kosten gering halten. Strato erlaubt die Nutzung des SAN bereits ab 1 GByte Speicherplatz. Wer bis zu 10 GByte bucht, zahlt 2,90 Euro pro GByte. Ab 100 GByte liegt der Preis bei 0,99 Euro pro Gigabyte, siehe Bild 3[11].
Mit einem SAN im Hintergrund lassen sich leicht Failover-Szenarien aufsetzen. Da heutzutage die Nutzung von Dateisystem-Clustering mittels iSCSI sowohl unter Linux als auch unter Windows kein Problem mehr ist, lassen sich auch Backend-Aktiv/Aktiv-Lastverteilungslösungen einrichten, beispielsweise mit Microsofts Cluster Shared Volumes[12] oder dem Global File System[13] unter Linux.
Bild 4[14] zeigt eine Beispielkonfiguration für ein Failover-System mit Loadbalancing. Für das Frontend-Loadbalancing bietet sich als einfache, aber effektive Lösung DNS-Round-Robin[15] an. Die von Strato angebotene Cluster-IP-Adresse lässt sich nur auf genau einen Server routen und ist damit als alleiniges Instrument zum Loadbalancing nicht einsetzbar.
Wichtig ist die Überwachung aller Frontend-Server auf Applikationsebene, beispielsweise mittels Nagios[16]. Wenn ein Frontend-Server funktionell oder von der Hardware her ausfällt, muss man sofort reagieren, da Clients, die durch DNS-Caching nach wie vor auf die IP-Adresse des betroffenen Servers geleitet werden, erst nach einem Time-out auf einen anderen Server verbinden.
Hier hilft die Strato-Cluster-IP, die man für jeden Frontend-Server benötigt. Ein solche Adresse lässt sich vorübergehend auf einen anderen Server umleiten. Rechnet man mit einem längeren Ausfall, kann man die IP-Adresse aus dem Round-Robin nehmen. Nach Ablauf der DNS-Cache-TTL[17] ist die Last unter den verbleibenden Servern wieder gleich verteilt.
Wer Erfahrung mit Dateisystem-Clustering und Loadbalancing hat, kann mit den neuen Strato-Produkten sehr schnell und vor allem preisgünstig skalierbare, fehlertolerante und hochverfügbare Lösungen aufbauen, ohne dazu eigene Hardware bei einem Co-Location-Anbieter unterstellen zu müssen.
In vielen Szenarien kann eine solche Lösung durchaus mit Microsofts Windows-Azure-Konzept mithalten. Als Azure-Kunde bekommt man zwar keine eigenen Server, sondern eine Art administrierbare virtuelle Hosting-Umgebung, die unter anderem auch PHP und MySQL unterstützt. Diese Umgebung wird von Microsoft automatisch hochverfügbar gehalten und skaliert beliebig nach oben - jedenfalls, wenn man den Aussagen aus Redmond Glauben schenkt.
Das Strato-Konzept erlaubt im Gegensatz dazu, auch kleinen und mittelständischen Unternehmen hochverfügbare Umgebungen aufzubauen. So lassen sich als Frontend-Server bereits die Einstiegsserver ab 29,99 Euro pro Monat einsetzen.
Sogar virtuelle Server lassen sich als Frontends einsetzen, wenn man nicht darauf angewiesen ist, mit dem Datenbankserver im eigenen VLAN zu kommunizieren. Kleinere Datenbanken mit 5 bis 10 GByte lassen sich ohne große Kosten auf einem iSCSI-SAN ablegen. Nach oben sind kaum Grenzen gesetzt.
Hinzu kommt, dass man Testumgebungen schnell im eigenen Unternehmen aufbauen kann. Ein iSCSI-Server unter Linux, mit dem man das Strato-SAN simulieren kann, ist schnell und einfach realisiert. Eine Windows-Azure-Umgebung hingegen wird man kaum zu Testzwecken nachstellen können.
Eine weitere Neuerung, die Strato ab sofort anbietet, ist die native Unterstützung von IPv6. Kunden von dedizierten Servern erhalten auf Wunsch ohne Aufpreis eine öffentliche IPv6-Adresse und ein /56-Netz mit weiteren 4,7 Trilliarden IPv6-Adressen, siehe Bild 5[18].
Für einen Produktivserver mag IPv6 auf den ersten Blick derzeit bedeutungslos erscheinen, da es kaum Internetnutzer mit IPv6-Anbindung gibt. Dennoch ist es für Serverbetreiber an der Zeit, sich mit dieser Technologie zu beschäftigen. So lassen sich beispielsweise schnell Serveranwendungen finden, die nicht IPv6-fähig sind, etwa MySQL und Asterisk.
Daneben kann man Erfahrung im Umgang von IPv6-Netzen sammeln. Beispielsweise sollte man tunlichst ungenutzte Adressen in die Routing-Table aufnehmen. Bindet man aus einem IPv6-Netz eine oder mehrere Adressen an ein Interface und routet den öffentlichen IPv6-Adressraum 2000::/3 an den Default-Router (bei Strato fe80::1), wie man es von IPv4 gewohnt ist, so hat man den Effekt, dass alle ungenutzten IPv6-Adressen aus dem eigenen Netz an den Router zurückgeschickt werden, was den Traffic unnötig belastet.
Die sinnvollste Lösung ist, alle eigenen Netze an das Loopback-Interface zu binden. Besitzt man beispielsweise das Netz 2001:db8:4711:1200::/56, so kann man unter Linux mit dem Befehl ip -6 route add 2001:db8:4711:1200::/56 dev lo erreichen, dass zunächst alle Adressen den Fehler "Network unreachable" melden. Diese Einstellung gilt nur bis zum nächsten Reboot. Strato hält für die unterstützten Distributionen eine Anleitung[19] bereit, wie man diese Route dauerhaft festlegt.
Unter Windows reicht es aus, den Kommandozeilenbefehl netsh interface ipv6 add route 2001:db8:4711:1200::/56 interface=1 store=persistent zu verwenden, um diese notwendige Route dauerhaft einzurichten.
Sobald man eine IP-Adresse an ein Interface bindet oder ein Teilnetz an einen anderen Rechner routet, hat die neue Route Vorrang vor der "unreachable route", da kleinere Subnetze (/57 bis /127) und Hosts (/128) Vorrang vor größeren haben. Daher braucht man sich später um die Route an das Loopback-Interface nicht mehr kümmern.
Einige paranoide Experten vertreten allerdings die Meinung, dass es besser sei, ungenutzte Adressen an die Netzwerkkarte (eth0 beziehungsweise unter Windows LAN-Verbindung oder Local Area Connection) zu routen, da statt dem Fehler "Network unreachable" nur ein Time-out zu erwarten sei. Das erschwere das Scannen von IPv6-Netzen. In der Praxis dürfte es jedoch grundsätzlich unmöglich sein, 4,7 Trilliarden IP-Adressen zu scannen. Selbst bei einer Pingzeit von einer Millisekunde dauert das 149 Milliarden Jahre.
Im ZDNet-Dauertest über zwei Wochen zeigen sich mit der IPv6-Anbindung bei Strato überhaupt keine Probleme. Die Verbindung funktioniert zu jeder Tages- und Nachtzeit, siehe Bild 6[20].
In einem weiteren Test bindet ZDNet einige virtuelle Server bei Strato und anderen Hostern mit einem Tinc-Tunnel über das /56-Netz in das öffentliche IPv6-Netz ein, siehe Bild 7[21]. Auch das macht keine Probleme. An den unterschiedlichen Pingzeiten lässt sich ablesen, dass diese Server teilweise bei anderen Hostern stehen.
Was den Aufbau hochverfügbarer, lastverteilter Serversysteme angeht, dringt Strato mit seinen Produkten in neue Bereiche vor. Voraussetzung ist jedoch, dass solche Systeme von Linux-Administratoren mit ausreichender Erfahrung aufgebaut werden.
Wer erwartet, in seinem Plesk-Controlpanel eine Schaltfläche "Mache mein System automatisch hochverfügbar und beliebig skalierbar" zu finden, wird enttäuscht. Sehr gute Kenntnisse verteilter Dateisysteme und Datenbanken sowie Webfarmen sind unerlässlich.
Wenn man davor nicht zurückschreckt, lassen sich allerdings mit günstigen konfektionierten Produkten Lösungen aufbauen, für die man bisher Co-Location oder einen Hoster mit individuellen Lösungen in Anspruch nehmen musste.
Mit der nativen Unterstützung von IPv6 bietet Strato seinen Kunden die Möglichkeit, sich mit der neuen Technologie vertraut zu machen. Ein IPv6-Netz erlaubt beispielsweise den Betrieb von nahezu beliebig vielen virtuellen HTTPS-Servern. Da pro IP-Adresse nur ein virtueller HTTPS-Server möglich ist, kommt es mit IPv4 schnell zu Engpässen.
Derzeit ist der Betrieb eines Produktivservers unter IPv6 nicht sinnvoll - zumindest nicht, wenn bestimmte Dienste ausschließlich unter IPv6 verfügbar sind. Nur ein verschwindend geringer Teil der Internetnutzer verfügt über das Internet-Protokoll der Zukunft.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = https:/
[20] = http:/
[21] = http:/