Static-Web-Pakete

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 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.

Was heißt das konkret?

Unsere Systeme sind z.Zt. (Mai 2009) hochwertige HDD mit RAID 5, demnächst RAID 10. D.h. wir brauchen jetzt 1,5-fachen, dann doppelten Speicherplatz. Aber wir haben auch ein Hot-Standysystem, was jederzeit sofort mit aktuellen Daten (nicht Daten von gestern) starten kann. Also nochmal Faktor 2. 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.

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!

---