Mittwoch, 16. Juni 2010, 10:47
Leistungsbeschreibung für Root-Server aktualisiert
Auf diverse Anregungen hin haben wir unsere Leistungsbeschreibung für Root-Server, u.a. weil sie härter klang als in der Praxis umgesetzt, aktualisiert. Die wichtigsten Änderungen sind:
An dieser Stelle möchte ich noch zu einigen Punkten Stellung nehmen, die ggf. erklärungsbedürftig sind, u.a. aus unserer Perspektive:
- die Unterscheidung zwischen (nach AGB und Leistungsbeschreibung) "legalem" und "nicht legalem" Datentransfer von oder zum Server ist entfallen, der gesamte Datentransfer ist nun vom Freikontingent abgedeckt
- die Aufführung von TCP, UDP und ICMP als IP-Protokolle ist entfallen und wurde allgemein durch (alle) IP-basierten Protokolle ersetzt
- das "Limit" von großen UDP- und ICMP-Mengen ist entfallen, es wurde allgemein durch einen Passus bzgl. extrem großer Mengen an Daten, die zum Schädigen des Netzwerks gedacht sind, ersetzt
- alle weiteren Einsatzwecke, die bislang nicht zulässig waren (ausgenommen Anonymisierungsdiensten, dazu weiter unten mehr) sind entfallen, sprich ab sofort sind Chat, File-Sharing, Peer-2-Peer-Netzwerke, Download-Server etc. zulässig
An dieser Stelle möchte ich noch zu einigen Punkten Stellung nehmen, die ggf. erklärungsbedürftig sind, u.a. aus unserer Perspektive:
- ad Anonymisierungsdiensten: Wir lassen diese weiterhin nicht zu - aus diversen Gründen. Einer davon ist der Umstand, dass es (dies deckt sich mit empirischen Erfahrungen aus unserer Vergangenheit sowie der von Marktbegleitern) einen erheblichen personellen Aufwand bei der Bearbeitung von Nachfragen von Rechteinhabern und Strafverfolgern erzeugt. Diesen Aufwand auf alle Produkt-Kunden umzulegen, wäre unfair, einzelne Kunden für jeden Einzelfall mit Kosten im Rahmen von ca. 100 Euro zur Kasse zu bitten, ist weder praktisch noch inkassotechnisch durchsetzbar.
- ad Priorisierungen von Datenströmen: Im Prinzip haben die meisten großen Router, so wie wir sie einsetzen, nur einen minimalen Spielraum, was das Priorisieren von Datenströmen in Echtzeit angeht. Und es ist auch gar nicht unsere Absicht, denn wir leiten Datentransfer rein und raus - nicht mehr, und nicht weniger. Allerdings kann es bei (d)DoS-Angriffen durchaus nötig sein, die nicht gewollten Datenströme anders zu priorisieren, und wir müssen uns diese Option im Interesse aller Kunden offenhalten, sonst handeln wir uns indirekt einen Mangel ein. Das ist im Prinzip auch schon der einzige Grund für diese Option.
- ad private IP-Adressen: Was unsere Kunden intern auf virtuellen Netzwerk-Interfaces an privaten IP-Adressen nutzen, ist uns - salopp gesagt - schnuppe, nur eben nicht auf dem externen Interface in Richtung "Rechenzentrum" (ausgenommen sind natürlich Server mit zusätzlich gebuchten, privaten internen Netzwerken). Hier ist es eben klar geregelt.
- ad (Verfügbarkeits-)Garantien: Unsere Jahresmittel-Werte der letzten Jahre liegen weit über den in der Leistungsbeschreibung angegebenen Werten. Wir könnten hier selbstverstänlich eine untere Grenze festlegen und diese garantieren. Wer hier aber kaufmännisch fair handelt, muss das Risiko nach unten absichern. Schaue ich mir einige unserer Marktbegleiter an, reicht bei kaum einem die Stammeinlage, um einen nennenwerten Teile der betroffenen Kunden zu entschädigen. Wer hier ehrlich garantiert, sichert das über einen Rückversicherer ab - und das kostet eben Geld. Nur warum soll ich 99% der Kunden "zwingen", indirekt eine Versicherung für einen Fall abzuschließen, der erfahrungsgemäß in den letzten Jahren nie vorgekommen ist? Zudem ist dies nur eine finanzielle Absicherung, das technische Risiko bleibt.
- ad Festplatten-Verfügbarkeit: Wir geben hier bewusst 98% an, weil eine (klassische, non-SSD-)Festplatte eben bewegliche Teile enthält und somit einen gewissen Verschleiß unterliegt. Und ja, rechnerisch gesehen sind das 7 Tage im Jahr, an denen die Festplatten ausfallen könnten, und weiterhin und wiederum ist das eine untere Grenze des Erfahrungswerts der Vergangenheit, so gesehen also der schlechteste Fall über alle Kunden in den letzten Jahren. Schaue ich mir die aktuelle Verfügbarkeit in 2010 über alle Server an, haben wir eine durchschnittliche Verfügbarkeit im Bereich Festplatten von über 99,95%!
- ad Löschen von Daten bei Rückgabe: Selbstverständlich löschen wir die Daten von allen Servern (mehr als ausreichend), die gekündigt werden. Geben wir das aber in den AGB oder der Leistungsbeschreibung an, wird uns irgendwann jemand darauf festnageln wollen. Im Prinzip ist das wie mit einer Mietwohnung: Wer auszieht, räumt seinen Kram raus und wirft alles andere weg. Und der Vermieter geht eben nochmal durch und macht sauber, ohne es aber dem vorherigen Mieter schriftlich zu garantieren.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
EDK
Florian
Wenn so ein Linux auf nem internen IF ne private IP hat und auf dem externen IF nen arp-request dafür reinkommt, antwortet der in der Regel.... Kann zu unschönen Ergebnissen führen. Für die Kunden wäre da evtl. eine Info welche Subnetze ihr eventuell im selben Segment einsetzt interessant
Manuel Schmitt (manitu)
Alphager
Py
Avarion
Jan
Du garantierst laut Leistungsbeschreibung, definitiv nichts was auf Produktabbildungen zu sehen ist ("entspricht auf keinen Fall") einzusetzen, und die Kundendaten nach der Kündigung zu behalten. Wäre es nicht sinnvoller "muss nicht ... entsprechen" zu schreiben und "wird ... nicht löschen" durch "ist nicht verpflichtet ... zu löschen" zu ersetzen? Sowas ähnliches ist auch nochmal beim Linux-Kernel und bei der Firewall zu finden, d.h. du garantierst eigentlich, keine Firewall zu benutzen...
Die 128 MB für die GraKas überraschen mich, gerade bei Serverhardware. Kann man das nicht runterstellen? Oder ist das auch eine Maximalangabe?
Zu den Verfügbarkeits-Zahlen: In die Leistungsbeschreibung steht derzeit ausdrücklich, dass es die mittlere Verfügbarkeit ist, obwohl du die niedrigste angibst. Damit redest du den Dienst doch nur unnötig schlecht, zumal du die Werte ausdrücklich nicht garantierst.
Ansonsten muss ich aber sagen, dass es die sauberste und transparenteste Beschreibung ist, die ich je gesehen hab.
Urs
Richtige Server Hardware ist teurer, dafür würde man sich aber den bastel mit reset u.s.w. sparen da die Boards dann meistens AMT oder sogar IPMI drinn haben.
Man kann ja mit dmidecode nachschauen was so in der kiste drinn steckt.
Woo
Was mich ein wenig erstaunt ist, dass Traffic zwischen einzelnen Kunden mit abgerechnet wird, obwohl der ja fuer Manitu eigentlich kostenneutral ist..
Urs
Wenn du die traffic stats über SNMP von der switch oder dem router holst, ist da im normalfall alles dabei was über den Port geht, es wird kein Unterschied gemacht wo hin der Traffic geht. Man kann das sicher anders lösen, z.B. mit netflow. Aber das ist dann aufwändiger.
Bjoern
Ist das neu? Bis vor einem Jahr (oder so) hatte ein Kollege auch einen Server bei Manitu und die gegenseitigen nächtlichen Backups wurden nicht berechnet...
Manuel Schmitt (manitu)
Im Prinzip sieht es derzeit wie folgt aus: Alles, was über den Router geht, und für nach außen bestimmt ist, oder was über den Router geht, und für nach innen bestimmt ist, wird gezählt. Alles andere NICHT. Rein geswitchter Traffic ist für uns nicht mal berechenbar, wenn wir es wollten, denn wir accounten pro IP-Adresse, nicht pro Server-/Switch-Port.
Manuel Schmitt (manitu)
Danke übrigens für das Lob - es ist IMHO das erste hier im Blog, und es freut mich persönlich sehr, weil wir mit der LB nur etwas Gutes tun wollten und wollen, anstatt das Gegenteil (was offenbar einigen Lesern übel aufgestoßen ist).
Peter
debe
Aus dem Blickwinkel eines Kunden ist doch ein Sturm an Reaktionen auf Deinen ersten Entwurf zu erwarten - man ist mittlerweile gewöhnt, von Anbietern bei jedem AGB-Wechsel eins "reingewürgt" zu bekommen, mal echte Verschlechterungen, mal verlängerte Kündigungsfristen. Wenn sich etwas verbessert, wird auch immer explizit darauf hingewiesen. Man ist also vorgewarnt und mißtrauisch. Dazu dann ein paar gut gemeinte, aber nicht ganz so gut gemachte Klauseln bezüglich IP-Traffic und so weiter, und schon kommen Zweifel an den Vorteilen der Neuregelung.
Ich bin froh, dass Du so deutlich Stellung genommen hast und auf die Bedenken eingegangen bist. Etwas Anderes hätte auch nicht zur Firmenphilosophie gepasst, gell?
Micha
Dann sollt man an den 7 Tagen die Festplatten lieber auslassen und nur an den restlichen Tagen betreiben scnr
john suchankova
gratuliere!
Emil
Das die Festplatten irgendwann mal nicht mehr können ist doch normal. Es sind günstige Desktop-Festplatten, die nicht für den Dauerbetrieb gebaut sind und zudem stark belastet werden! Bisher verlief es immer so, dass die defekte Festplatte am nächsten morgen, zu einem abgesprochen Termin, innerhalb weniger Minuten gewechselt wurde. Beim letzten mal verlief es so, dass die Festplatte um 10Uhr gewechselt werden soll und wir das System um 10Uhr heruntergefahren haben sollten. So wurde das System um 9.59 heruntergefahren und um 10.03Uhr war alles wieder mit der neuen Festplatte aktiv.
also: WAS WILL MAN MEHR BEI DEM PREIS!!!
Manuel Schmitt (manitu)
Jamma
Was empfehlt ihr Euren Kunden bezüglich des Backups? Mein Server bei einem Mitbewerber produziert ca. 2 GB Backupdaten pro Tag, die ich dann auf einem FTP parke. So habe ich zumindest eine Restsicherheit gegen hässliche Hardwareschäden oder Dummheit. Was gibt es für Alternativen?
Danke & Viele Grüße,
Jamma.
jan
Daniel
Manuel Schmitt (manitu)