Static-Web-Pakete: Unterschied zwischen den Versionen

Aus Hostsharing Wiki
Zur Navigation springen Zur Suche springen
(Austattungsunterschiede rein, allgemeies .htacces auth raus)
(Ergänzung zu cron+php.., allgemeines auf Pakete Seite verschoben)
Zeile 5: Zeile 5:
Der SW-Webspace unterscheidet sich kaum vom DW-Webspace  - außer:
Der SW-Webspace unterscheidet sich kaum vom DW-Webspace  - außer:
* keine Datenbanken
* keine Datenbanken
* keine Cronjobs
* keine Cronjobs*
* kein CGI, PHP, Python, Perl...
* kein Skripte* (CGI, PHP*, Python, Perl...)
* keine App-Server
* keine App-Server


Zeile 13: Zeile 13:
Backups und Hot-Standby sind völlig identisch.
Backups und Hot-Standby sind völlig identisch.


Was heißt das konkret?
*Außer Skripte für den Paket-Admin zu administrativen Zwecken, d.h.
man darf seinen Logfile-Auswertungsprogramm per Cronjob oder
event-handler starten und sogar CGI/PHP als Paket-Admin verwenden, um
die "bunten" Bildchen anzeigen zu lassen. Ebenso darf man ein eigenes
Webfrontend zur Konfiguration des Pakets betreiben.


Unsere Systeme sind z.Zt. (Mai 2009) hochwertige HDD mit RAID 5, demnächst RAID 10.
Das ist ein Entgegenkommen Hostsharings, um SW Pakete auf gleich hohem Niveau
D.h. wir brauchen jetzt 1,5-fachen, dann doppelten Speicherplatz. Aber
handhabbar zu halten wie DW Pakete. Wir gehen davon aus, dass diese Funktionen
wir haben auch ein Hot-Standysystem, was jederzeit sofort mit aktuellen
keine nenneswerte Belastung der SW-Server darstellen, weil "administrative Funktionen" nur
Daten (nicht Daten von gestern) starten kann. Also nochmal Faktor 2.
sporadisch genutzt werden.
Zusätzlich haben wir noch jede Nacht inkrementelle Backups.


Insgesamt braucht damit 1 GB Webspace:


2 GB (auf dem Produktiv-System, RAID 10, 15k RPM SAS-Platten)
2 GB (auf dem Standby-System, RAID 10, 15k RPM SAS-Platten)
4 GB (auf dem Backup-System, RAID 5, SATA-Platten)
Also 1 GB Webspace wird durch die Redundanz auf extrem teuren
Festplatten vervierfacht und auf vergleichswiese preiswerten Festplatten
nochmal vervierfacht.
Nun können wir aber nicht alle System "vollhauen", sondern müssen
Reserve behalten, damit die Benutzer auch nachbestellen können. Außerdem
sind neue Server nicht gleich "optimal ausgelastet". Wir kalkulieren mit
rund 50% Auslastung der Festplatten.
Damit entfällt preislich also noch mal etwa das Doppelte auf das eine 1
GB Webspace - und HS hat noch nichts daran verdient: da sind die Server
nicht drin, die Anbindung nicht, der Rackspace nicht, der Strom nicht,
die Hostmaster nicht und auch der Vorstand nicht - und auch nicht die
Last, die das Backup nächtlich erzeugt.
Aber warum ist DW dann teurer als SW? DW erzeugt mehr komplizierte
Schreib- und Lesezugriffe auf die HDDs als SW, vor allem durch
Datenbanken. Auch ändern sich viel schneller größere Datenvolumina, so
dass das Backup anspruchsvoller ist. (Ein Kunststück ist bereits, das
Backup nachts "fertig" zu bekommen, damit es tagsüber nicht bremst.)
(Anmerkung: Schaut mal, was bei DELL so ein 2x QuadCore, 48 GB RAM, 4x
SAS Server kostet...)
Man könnte natürlich abspecken: kein Backup oder nächtlich nur ein paar
Pakete/jedes Paket einmal die Woche, kein RAID 10, sondern nur 5 oder
gar nicht, kein SAS, sondern nur SATA...
Aber wollen wir das? Oder wollen wir Qualitätshosting.





Version vom 27. Mai 2009, 08:30 Uhr

Das Static-Web-Paket besitzt einige Besonderheiten, auf die hier konkret eingegangen werden soll.

Ausstattung

Der SW-Webspace unterscheidet sich kaum vom DW-Webspace - außer:

  • keine Datenbanken
  • keine Cronjobs*
  • kein Skripte* (CGI, PHP*, Python, Perl...)
  • keine App-Server

Die grundlegende Technik und Handhabung von Mail, Webspace, Accounts, Logfiles etc, aber auch des nächtlichen, vollständigen Backups und Hot-Standby sind völlig identisch.

  • Außer Skripte für den Paket-Admin zu administrativen Zwecken, d.h.

man darf seinen Logfile-Auswertungsprogramm per Cronjob oder event-handler starten und sogar CGI/PHP als Paket-Admin verwenden, um die "bunten" Bildchen anzeigen zu lassen. Ebenso darf man ein eigenes Webfrontend zur Konfiguration des Pakets betreiben.

Das ist ein Entgegenkommen Hostsharings, um SW Pakete auf gleich hohem Niveau handhabbar zu halten wie DW Pakete. Wir gehen davon aus, dass diese Funktionen keine nenneswerte Belastung der SW-Server darstellen, weil "administrative Funktionen" nur sporadisch genutzt werden.



Aufschalten von Subdomains

Auch Subdomains können ganz normal per Dom-Order Formular aufgeschaltet werden.

Für Domains, die nicht bei Hostsharing liegen, wird eine Subdomain direkt mit action=setup per Dom-Order Formular aufgeschaltet.

Domains die bei Hostsharing liegen sind hingegen zunächst vom Domainadmin freizuschalten, damit sie von einem anderen Paket zur vollständigen Verwaltung der Zone aufgeschaltet werden können.

Im Beispiel soll die Subdomain pic.example.org der Domain example.org eines Dynamik-Web Pakets auf ein Static-Web Paket aufgeschaltet werden.

Zunächst wird die Subdomain nochmals explizit auf die HS Nameserver delegiert. Hierdurch wird die Freigabe der Subdomain zur vollständigen Aufschaltung (mit eigem Zonefile) auf ein anderes Paket signalisiert.

(Die Domain ist hier dem User xyz00-abc zugeordnet.)

xyz00-abc@h01 cp /etc/bind/pri.example.org ~/doms/example.org/etc

Editieren des Zonenfiles:

xyz00-abc@h01 vim ~/doms/example.org/etc/pri.example.org

Ersetzen der Seriennummer durch {SIO} und weitere Platzhalter einsetzen (siehe Verwalten der Zonendaten).

Am Ende der pri.example.org sind folgende Zeilen einzufügen:

pic.example.org. IN NS dns1.hostsharing.net.
pic.example.org. IN NS dns2.hostsharing.net.
pic.example.org. IN NS dns3.hostsharing.net.

Bitte auf die Punkte achten!

Dann folgt ein

xyz00-abc@h01 touch ~/doms/example.org/etc/pri.* \ ~/doms/example.org/etc/zonefile.upd

um das Update in Gang zu setzen.

Bei der Aufschaltung der Subdomain pic.example.org wird entsprechend geprüft ob diese dafür freigegeben ist (und auch nicht zwischenzeitlich von einem anderen Paketadmin aufgeschaltet wurde).


Nun kann das Dom-Order Formular ins ~/etc Verzeichnis des Static-Web Paketes kopiert und ausgefüllt werden.

Aber erst wenn die Änderung des Zonenfiles erfolgreich erfasst wurden, kann der Setup-Auftrag erfolgreich durchlaufen. Prüfen ob die Änderung bereits erfolgreich erfasst wurde: (kann ca. 5 Minuten dauern)

xyz00-abc@h01 dig @dns1.hostsharing.net "pic.example.org" NS | grep '^sw.example.org'


Erst jetzt kann der dom-order mit

xyz00-abc@h01 touch ~/etc/dom-order.upd

erfolgreich angestoßen werden.

Ist ein Fehler aufgetreten, muss das Dom-Order Formular und das File dom-order.upd "getoucht" werden!