Webhosting-Panel - Gebuehren

[d4f]

Ohne jetzt auf die Details zu einem solchen, theoretischen, Webhosting-Panel einzugehen (wer es sich unbedingt vorstellen will nehme beispielsweise Plesk), was waert ihr bereit als Mietlizenz (monatlich) zu bezahlen?

- je Webspace
- maximal je Rootserver (einzeln oder im Cluster)


(Bitte kein Hinweis zu kostenfreier Software a la froxlor, IspCP, ...)

Wie bereits gesagt - rein theoretisch und (fast) ausschliesslich aus persoenlichem Interesse
Interne/private Server-Betreiber (oder angehende Root's) ausdruecklich erwuenscht

 

[CentY]

Also bei mir hängt der Preis den ich zahlen würde sehr von den Features (Clustersupport, wie individuell anpassbar usw.) und dem gebotenem Support des Herstellers ab.

Auch die Zahlungsmethode, also ob pro Server oder Kunden, hängt sehr von den gebotenen Features ab. Wenn ich einen Clusterverbund mit vielen Kunden habe dann natürlich lieber pro Server mit unbegrenzter Kundenanzahl. Wenn ich aber erstmal klein anfangen möchte sind die Kosten evtl. pro Kunde überschaubarer und ich kann das noch besser in die Angebote für Kunden einkalkulieren.

Auch Updates usw. würden bei mir bei der Preisgestaltung ne Rolle spielen, wenn diese regelmäßig kommen zahle ich gerne mehr. Wenn Updates allerdings bloß alle Jahr einmal releasen bin ich nicht bereit viel für so ein Produkt zu zahlen.

Also wie du siehst ist es nicht ganz so einfach für mich zu sagen was ich bereit bin zu zahlen, weil einfach mehrere Faktoren eine Rolle spielen.

 

[d4f]

Danke fuer dein Feedback =)
Die Entwicklung eines Webpanels spuckt mir seid einiger Zeit im Kopf rum da schlichtwegs kein (zumindest kein bezahlbares) auf dem Markt ist was alle der genannten Funktionen bietet

-einfaches Deployment (Initdatei generien und mit dem Installer auf alle Server raufladen)
-kein Einklammern des Systems (was kann ein einfaches apt-get nicht alles zerschiessen...)
-Echte Clusterfaehigkeit (mit oder ohne Hardware-Loadbalancer)
-dezentralisiert (Abschmiren der Masterserver soll nicht eine ganze Plattform lahmlegen)
- Meldung bei Ausfall eines Dienstes per SMS
- automatische Korrektur ('repair' eines Dienstes, Reboot eines Servers)
- CPU-/Ram-/Bandbreiten-Begrenzung je Kunde
- SRS,SPF
- Absichern aller Dienste (chroot, ...)
- vollstaendig offene API's (und offengelegtes Beispielfrontend)
- ...

Das war jetzt mal aus dem Kopf, ich hab ein Heft mit seitenweise Brainstorming rumliegen - ob es allerdings je (in diesem Umfang) fertig entwickelt und released wird steht natuerlich auf einem anderen Blatt



Die Zahlungsmethode habe ich glaube ich schlecht beschrieben Die Idee ist dass (bsp) jeder angelegte Webspace monatlich 0.10$ kostet bis zu einer festen Obergrenze wie zB 20$ ab welcher es dann als Flatrate gilt.

 

[Pijay]

In deiner Auswahl fehlt noch der Menüpunkt "Eigenentwicklung".

 

[d4f]

Hmm stimmt :S
Ich kann sie jetzt nicht mehr aendern (oder bin ich nur blind?)

 

[Armadillo]

-dezentralisiert (Abschmiren der Masterserver soll nicht eine ganze Plattform lahmlegen)

Bei welchem clusterfähigen Tool ist das denn der Fall?

- Meldung bei Ausfall eines Dienstes per SMS
- automatische Korrektur ('repair' eines Dienstes, Reboot eines Servers)

fällt in die Zuständigkeit eines Monitoringsystems

- CPU-/Ram-/Bandbreiten-Begrenzung je Kunde

Wie genau stellst du dir das vor? CPU-Zeit und Ram in PHP beschränken geht ja problemlos. Quotas gehen auch, deckt das deine Anforderungen ab?

Die Zahlungsmethode habe ich glaube ich schlecht beschrieben Die Idee ist dass (bsp) jeder angelegte Webspace monatlich 0.10$ kostet bis zu einer festen Obergrenze wie zB 20$ ab welcher es dann als Flatrate gilt.

D.h. die ganze Angebotsverwaltung soll auf festen Preisen basieren oder wie habe ich mir das vorzustellen?

Ich kann sie jetzt nicht mehr aendern (oder bin ich nur blind?)

Oben über dem ersten Post bei den Themen-Optionen müsste man es bearbeiten können.

 

[d4f]

ben über dem ersten Post bei den Themen-Optionen müsste man es bearbeiten können.

Zur Auswahl stehen 'druckbare Version' ,'per Email', 'Abo loeschen', 'Thema loeschen'
Zumindest fuer uns einfaches Fussvolk scheint es nicht zu gehen (oder ich bin wirklich blind)

Bei welchem clusterfähigen Tool ist das denn der Fall?

Eben bei keinem das mir bekannt ist... Das ist einer der Hauptgruende fuer eine Eigenentwicklung.
Cluster-FS wie Mogile oder Ceph sind 'by design' SPOF-frei und bei vielen Anbietern ist es moeglich eine IP per Failover-API auf einen anderen Server zu routen oder mehrere Server in einem VLAN zusammen zu fassen, somit stuende technisch nichts im Weg.
In diesem Fall muss allerdings die Kommunikation zwischen den einzelnen Servern ueber ein P2P-Protokoll mit Peer-Exchange und Public-Private Keys zum Update der Listen und Propagation neuer Kommandos erfolgen.
(Die professionelle Methode mit SAN und Hardware-Loadbalancer lasse ich mal im Beispiel aussen vor Erstere ist -leider- selten gesaet und letztere bieten nur eine Handvoll Anbieter an sofern man nicht housing benutzt)

fällt in die Zuständigkeit eines Monitoringsystems

Waere es nicht ideal wenn das System selbst -und eventuell viel schneller- auf Aussetzer oder Angriffe reagieren kann statt auf die Meldung eines Monitoringsystems zu warten? Ein zusaetzliches System ist natuerlich niemals verkehrt... (aber mal ehrlich: wieviele der 'kleineren' Admins setzen ein solches Monitoring-System auch ein )
Wer ueberwacht die Waechter...

Wie genau stellst du dir das vor? CPU-Zeit und Ram in PHP beschränken geht ja problemlos.

Ich dachte eher an CPU%-Begrenzung. PHP und ulimit bieten beide nur Funktionen zur Begrenzung der CPU-Zeit, allerdings kann, darf und muss ein Prozess oefter gerne mal laenger laufen, nur halt nicht die Machine ausbremsen...). Stichwort: Bildergallerie-Thumbnails
Das 'cpulimit'-Tool ist dahingehend interessant, ich muss mich aber noch weiter damit beschaeftigen um Overhead und etwaige negative Folgen
abschaetzen zu koennen. Funktioniert soweit aber nur bei Einbindung von PHP als cgi oder fastcgi

die ganze Angebotsverwaltung soll auf festen Preisen basieren oder wie habe ich mir das vorzustellen?

Ich will einerseits unausgelastete Server nicht mit dem vollen Preis belasten, andererseits die Lizenzkosten bei einem Hochleistungsserver nicht in den Himmel schiessen lassen. Eine logarithmische Kurve als Kostenmodell waere ebenfalls interessant, allerdings in der Berechnung der aufkommenden Kosten fuer Kunden defintiv etwas kompliziert
'Paketweise' Upgrades (30 Domains, 50 Domains, ...) sind hingegen nach meinem Geschmack zu unflexibel.
(Ich gebs zu, ich mich beim Lizenzmodell 'ganz leicht' an Tritoncia (Teamspeak) inspiriert )

 

[Firewire2002]

Waere es nicht ideal wenn das System selbst -und eventuell viel schneller- auf Aussetzer oder Angriffe reagieren kann statt auf die Meldung eines Monitoringsystems zu warten?

Und wie soll das System selbst feststellen, dass der Dienst nicht läuft? Richtig, es muss im Intervall prüfen. Der Dienst wird dir auch in der eigenen Lösung kein Trap senden, wenn er wegen OOM, Softwarefehler oder was auch immer gekillt wird.
Die Verzögerung durch das Monitoring hast du immer. Wie große diese ist, lässt sich überall konfigurieren.

aber mal ehrlich: wieviele der 'kleineren' Admins setzen ein solches Monitoring-System auch ein )

Du redest hier von einer ziemlich mächtigen Clusterlösung. Wenn man bedenkt, dass da noch weitere Systeme für das Management, der eigenen Webinterfaces, Crons, APIs, usw dazu kommt, ist ein Monitoring pflicht.

Wer ueberwacht die Waechter...

2 Möglichkeiten:

• Das Monitoring System besteht aus 2 Servern, die sich gegenseitig überwachen.
• Man nutzt selbst nur ein Monitoring Server, der sich selbst zusätzlich mit überwacht (Ram, CPU, Raid, usw.) + ein externes Monitoring, dass prüft ob dein eigener Monitoring Server erreichbar ist und seinen Dienst vollbringt.

Ich will einerseits unausgelastete Server nicht mit dem vollen Preis belasten

Hä? D.h. wenn ich als einziger Kunde auf einem Server liege, und mir theoretisch die volle Leistung des Systems zur Verfügung steht, soll ich mehr bezahlen, als wenn später noch mehr Kunden drauf liegen?
Interessantes Preismodell.

 

[d4f]

Hä? D.h. wenn ich als einziger Kunde auf einem Server liege, und mir theoretisch die volle Leistung des Systems zur Verfügung steht, soll ich mehr bezahlen, als wenn später noch mehr Kunden drauf liegen?

Das Preismodell bezieht sich auf das Webinterface fuer den Anbieter, nicht auf dessen Kunde. Als Kunde bezahlst du ja auch nicht dem Anbieter die Plesk-Lizenz (Ok, indirekt schon )
Der Anbieter bezahlt, so die Ueberlegung, nicht bereits beim 1. Kunde eine XXL-Lizenz oder muss staendig die Lizenz oder das LIzenzpaket wechseln sondern letztere passt sich seinem Erfolg an

Du redest hier von einer ziemlich mächtigen Clusterlösung

Ein Cluster kann man theoretisch mit 2 Pentium3 aufbauen. Maechtig? Naja (Mein Testcluster [aka Spielwiese] ab Sommer wird zirka 8-10 Pentium3 enthalten )

ist ein Monitoring pflicht.

Gute Serverabsicherung ist auch Pflicht. Dass die Wirklichkeit anders aussieht bewies mir heute morgen wieder ein Moechtegern-DDoS auf einen meiner Server. (Warum moegen Pishing-Seiten es nicht wenn man deren vor Schreibfehlern strotzende "Konto-Verlaengerung"-Seite vom Kunden-FTP loescht?! )

Und wie soll das System selbst feststellen, dass der Dienst nicht Und wie soll das System selbst feststellen, dass der Dienst nicht läuft? Richtig, es muss im Intervall prüfenUnd wie soll das System selbst feststellen, dass der Dienst nicht läuft? Richtig, es muss im Intervall prüfenläuft? Richtig, es muss im Intervall prüfen

Wenn ein Prozess abstuerzt kann der spawnende Supervisor dies direkt erkennen. Im Fall eines eingefrorenen oder ueberlasteten Prozesses natuerlich nicht, dies muss durch aktives polling bewerkstelligt werden.
Allerdings hat ein 'Einfrieren' meist eine andere Ursache, zb Fehler in der Konfiguration, Hardwarelimit oder Angriffe, was somit das System zur weiteren Analyse des Ausfalls anregen soll. Bekannte Produktivsoftware stuerzt meistens nicht 'einfach so' ab.
Im Beispiel eines Clusters sollten die Server sich natuerlich idealerweise abwechselnd gegenseitig kontrollieren.
Einen Ausfall der Rechenzentrum-Uplinks oder Peering-Ueberlastung kann natuerlich ein interner Wachhund nicht erkennen, da muss dann ein externer Dienstleister her.

 

[Firewire2002]

Das Preismodell bezieht sich auf das Webinterface fuer den Anbieter, nicht auf dessen Kunde.

Ok, kleiner Denkfehler von mir. Dann passt das schon eher.

Ein Cluster kann man theoretisch mit 2 Pentium3 aufbauen.

Für eine derartige Testumgebung würde ich auch keine 2 Monitoring Systeme aufbauen. Meine Aussage bezog sich auf den produktiven Betrieb und ich bezweifel dass sich da nur jemand 2 Pentium 3 Maschinen hinstellt.

Wenn ein Prozess abstuerzt kann der spawnende Supervisor dies direkt erkennen. Im Fall eines eingefrorenen oder ueberlasteten Prozesses natuerlich nicht, dies muss durch aktives polling bewerkstelligt werden.

Das zusätzliche Monitoring brauchst du also sowieso.

Im Beispiel eines Clusters sollten die Server sich natuerlich idealerweise abwechselnd gegenseitig kontrollieren.

Am zuverlässigen Distributed Monitoring arbeiten einige größere Monitoring Lösungen schon seit einer ganzen Weile. Das willst du mal eben nebenbei in einer Webhosting Clustering Software mit implementieren?
Sag Bescheid, wenns funktioniert.

Einen Ausfall der Rechenzentrum-Uplinks oder Peering-Ueberlastung kann natuerlich ein interner Wachhund nicht erkennen, da muss dann ein externer Dienstleister her.

Das oben angesprochene Monitoring System mit 2 Servern kann eben so gut in 2 verschiedenen Rechenzentren untergebracht werden. Dann kannst du es wieder selbst überwachen und du hast vorallem, für das eigene Management, überall die gleiche API.

 

[Dennisda]

Moin,

habe mir die anderen Antworten nicht durchgelesen.

Ich mache mittlerweile alles selber bzw. per Hand. Mir hat die Vergangeheit gezeigt. das es so besser und sicherer ist.
Besonders was die Sicherheit betrifft. Es ist zwar einfacher ein Panal zu Installieren und zu "betreiben" aber wenn mal ein Loch offen ist, muss man warten bis ein Fix raus ist.

usw usw

Anbei ist es geschmacks und erwahrungssache. Wie beim Sex.....

 

[Armadillo]

habe mir die anderen Antworten nicht durchgelesen.

Hättest du mal machen sollen...

Ich mache mittlerweile alles selber bzw. per Hand. Mir hat die Vergangeheit gezeigt. das es so besser und sicherer ist.
Besonders was die Sicherheit betrifft. Es ist zwar einfacher ein Panal zu Installieren und zu "betreiben" aber wenn mal ein Loch offen ist, muss man warten bis ein Fix raus ist.

... dann hättest du gemerkt, dass es hier um größere Sachen als nen einzelnen Server eines Anfängers geht.

 

[d4f]

Am zuverlässigen Distributed Monitoring arbeiten einige größere Monitoring Lösungen schon seit einer ganzen Weile.

Ich bin mir bewusst dass es, wie die meisten beschriebenen Features, ein komplexes Unterfangen ist. Allerdings habe ich, zumindest gegenueber SaaS-Anbieter, einen Vorteil: der Monitoring muss keineswegs extrem kompakt sein sondern kann einige Zeit beanspruchen (sofern CPU, Traffic und RAM nicht darunter leiden). Eine gemaechtliche Loesung ist bei Anbietern die tausende Kunden mit dutzenden Servern ueberwachen natuerlich nicht moeglich.

Dass eine Out-of-the-box Loesung nicht mit Anbietern entsprechender Software und Hardware konkurrieren kann ist klar. Ich versuche jedoch moeglichst viele der nuetzlichen oder ueberlebenswichtigen Funktionen zu vereinen und ein System zu bauen was auf sich selbst basierend lauffaehig und produktiv einsetzbar ist. Da die API's vollkommen offenliegen waere eine Einbindung externer Anbieter oder Programme denkbar, ich ueberleg mir grade 'von haus aus' eine Reihe verschiedener Loesungen zu unterstuetzen.

dann hättest du gemerkt, dass es hier um größere Sachen als nen einzelnen Server eines Anfängers geht.

Du sein pöse
Auch wenn der Kommentar von Dennisda nicht zur urspruenglichen Frage oder Diskussion passt; halb Recht hat er allerdings:

[a]
Ein System sollte folgende Struktur aufweisen
FRONTEND ---> oeffentliche API ---> interne API ---> Supervisor ---> Kommando
Die 4 ersten Teile sollten voneinander komplett abgekapselt unter verschiedenen Benutzer und chroot-Umgebungen laufen und ohne shared-code auskommen; dass ein Fehler in allen 4 Teilen enthalten ist und nicht vom ueberwachenden Hypervisor entdeckt wird ist gering. Selbst wenn ein Fehler bekannt wird kann mittels Push-Update die Filterregel in allen folgenden Teilen dahingehend verschaerft werden dass der entsprechende Exploit nicht mehr lauffaehig ist.


Bei manuellem Anlegen von Konten, Emailadressen, ... kann man schnell was vergessen und ein offenes Tor schaffen; etwas was man durch den Verzicht auf eine Oberflaeche eigentlich zu vermeiden versucht. Allerdings werden, zumindest im kommerziellen Hosting-Bereich, Kunden nicht in Scharen gerannt kommen wenn du keine weiteren Email-Adressen erlaubst oder eine solche an eine Kontaktaufname an den Support knuepfst.
Um konsequent zu sein muesstest du dir den Linux-Kernel und die GNU-Tools ziehen und daraus eine neue Distribution backen. Debian hat ja mit dem SSH-Key Debakel gezeigt wie unsicher ein fertiges System ist...

kann eben so gut in 2 verschiedenen Rechenzentren untergebracht werden.

Dann hast du wieder nicht alle (oder die meisten) Peering ueberwacht... Anbieter wie host-test.net bieten die Kontrolle mit zig weltweit verteilten Server an, ein (regionaler) Ausfall liesse sich somit schneller feststellen.