Im Vergleich: Standardpaket vs. Maßanfertigung

Serverservices und Hostingangebote als Standardpakete mit festen Features können Sie überall finden. Doch erfüllen diese tatsächlich alle Ihre Anforderung an die notwendigen Serverservices? Diese Frage ist berechtigt, denn die Praxis zeigt, dass sich die Kundenwünsche an hochwertige Online-Angebote oft sehr deutlich von typischen Standard-Anforderungen der 08/15 Websites unterscheiden. Sie brauchen meistens eine Maßanfertigung. Doch leider ist dieser Umstand nur den wenigsten Anwendern bewusst.

Was das genau bedeutet, wollen wir in einem Praxisbericht über ein erfolgreich abgeschlossenes Kundenprojekt der BB-ONE.net zeigen.

Der Fall

Der Betreiber eines speziellen Medizin-Portals, welches sich an Ärzte und Krankenhäuser richtet, war mit der bisherigen technischen Performance unzufrieden. Da man ohnehin einen Relaunch plante, um das Portal an mobile Endgeräte anzupassen, war der Zeitpunkt für eine technische Generalüberholung günstig. Daher beauftragte der Bereiber eine Potsdamer Online-Agentur, die in den letzten Jahren bei ähnlich gelagerten Anfragen erfolgreich gearbeitet hatte. Diese wandte sich wegen der guten Erfahrungen in Sachen performanter Server-Infrastruktur wiederum an die BB-ONE.net.

Wichtige Anforderungen

Eine kurze Funktions-Beschreibung des Portales verdeutlicht den Anspruch, der weit über eine normale WebSite hinausgeht und deshalb auch nicht mit Standardpaketen auskommen konnte:

  • In diese Medizin-Anwendung sind mehr als 2500 verschiedene Analysen (Labortests) integriert. Diese wiederum müssen verschiedenen Bereichen dynamisch zugeordnet werden können. Der Benutzer kann mittels dieses Auswahlwerkzeuges die speziell für seine Fragestellung in Frage kommenden Analysen auswählen, Details anzeigen lassen und dann beauftragen.
  • Diese Auswahl ist alternativ auch über eine integrierte Suchmaschine erreichbar.
  • Das jeweilige Ergebnis lässt sich zusätzlich als Druckausgabe verwerten.
  • Über Nacht wird ein tagesaktuelles Verzeichnis über alle möglichen Analysen für eine zusätzlich bereitgestellte App exportiert.

Der eigentliche Relaunch war schon einigermaßen anspruchsvoll, da allein aus juristischen Gründen erhebliche Anforderungen an das technische Design vorlagen. Aber auch die Kundenvorgaben zur Performance waren einerseits ganz klar:

„Das muss deutlich schneller werden!“

Und:

„Beim Neu-Indizieren der Dokumentendatenbank darf der Server nicht in die Knie gehen!“

Andererseits konnte bis dato niemand sagen, wo genau der Performance-Schwachpunkt lag. Immerhin hostete man das Portal bei einem der bekanntesten Anbieter für Agentur-Hosting mit dem grössten Server Standardpaket. Man dachte, das würde schon ausreichen. Ein gefährlicher Trugschluss, wie sich später herausstellte.

Eine neue Erfahrung

Dennoch lies sich der Kunde darauf ein, die Welt der Standardpakete zu verlassen und eine überraschende neue Erfahrung zu machen. Er erteilte den Auftrag. Daraufhin sammelte die BB-ONE.net alle verfügbaren Informationen sowohl beim beauftragenden Kunden als auch bei dessen bisheriger Online-Agentur ein. Diese kooperierte im Sinne des Kunden dankenswerter Weise sehr gut. Die neue, übernehmende Potsdamer Agentur führte alle Daten und Fakten zusammen und definierte ein Anforderungsprofil mit dem erklärten Ziel „schneller & stabiler“.

Festlegung der Anforderungen

Zunächst legte man gemeinsam die wichtigsten Kriterien fest:

  • wenigstens während der Entwicklungszeit und während der Startphase:
    • überdimensionierter Arbeitsspeicher (RAM) und CPU-Ressourcen
    • überdimensionierter Speicherplatz in einem SSD-Raid-System
  •  bereits während der Entwicklungszeit, aber auch während des normalen Betriebes:
    • eine getrennte Entwicklungsumgebung
    • eine ActiveBackup-Instanz (das ist ein spezieller Service bei uns, der quasi einen Spiegelserver darstellt)
    • aktuelles PHP 7.3, Geschwindigkeits-optimierter Datenbank-Server
    • HTTP/2 und ebenfalls auf Geschwindigkeit getrimmte SSL-Konfiguration
    • als Webserver NGINX statt Apache (skaliert deutlich besser)

Erste Erfolge werden sichtbar

Die Agentur entwickelte das Portal mit dem aktuellen TYPO3 komplett neu. Schon zu diesem Zeitpunkt stellte sich ein erster Erfolg ein: Das neue Backend war deutlich flotter als das alte. Und die Indizierung der Suchmaschinen-Inhalte führte nicht mehr zum „Einfrieren“. Der Kunde bemerkte beide Verbesserungen von ganz allein und betätigte diesen ersten Erfolg.

Kleine Stolpersteine

Am Rande sei ein Vorkommnis erwähnt, welches sicherlich nicht zur Normalität gehört. Aber bei Projekten dieser Größenordnung können derartige Überraschungen schon mal vorkommen. Der Kunde verfügte nämlich löblicher Weise bereits über ein Server-Zertifikat, das er gerne weiterverwenden wollte. Also wurde die „Alt-„Agentur gebeten, vom bisherigen Server sowohl den Server-Key als auch das Zertifikat und das von der Certificate Authority verwendete Chain-Certifikate zu kopieren und bereitzustellen. Das erfolgte dann auch, mit einem großen „Aber“.

Man lieferte das Zertifikat im eher ungewöhnlichen GFX-Format. Zusätzlich war der Server-Key dann auch noch mit einem Passwort versehen. Diese gut gemeinte Absicht bedeutete im Klartext, dass jedesmal beim Neustart des Servers oder des Webserver Apache eben dieses Passwort auf der Kommando-Zeile eingegeben werden musste. Das ist im Bereich Web-Hosting ein extrem ungewöhnliches Verfahren, besonders in der Entwicklungsphase auch noch extrem lästig. Denn Neustarts kommen hier – im Gegensatz zum Regelbetrieb – häufiger vor. Also musste man das Passwort aus dem Serverkey entfernen, was dann mit etwas Aufwand schließlich auch gelang.

Ziel erreicht

Der eigentliche Relaunch ging glatt über die Bühne. Um die erwartete tatsächliche Geschwindkeits-Steigerung auch belegen zu können, richtete die BB-ONE.net im Monitoring System eine Messung jeweils für http, https und ICMP/Ping ein. Da diese bereits im Vorfeld schon lief, konnte die deutliche Performance-Verbesserung zwischen „alt“ und „neu“ bewiesen werden. Die nachfolgende Graph zeigt, dass ein Ziel, nämlich mehr Schnelligkeit, erreicht wurde. Und man erkennt, wann der Relaunch stattfand.

Die Auslieferungsgeschwindigkeit steigt am Tag des Relaunches deutlich. Man sieht, wie viel schneller die WebSite geworden ist. Daran beteiligt waren mehrere Aspekte:

Dieser Graph lässt gut erkennen, wann der Relaunch durchgeführt wurde.
  1. die verwendete Servertechnik
  2. schnelleres PHP
  3. NGINX statt Apache
  4. weitere Verbesserungen wie HTTP/2, SSL-Implementierung etc.

Fazit: Standardpakete haben ihre Grenzen

Maßarbeit erwies sich hier tatsächlich effektiver als das Angebot „Von der Stange“. Zugegeben, im beschriebenen Fall handelte es sich um eine besonders anspruchsvolle Anwendung. Aber sie zeigt die Grenzen und Schwächen der Standardpakete von Massenhostern am deutlichsten. Agenturen bedienen sich dieser Paketangebote sehr gerne, weil sie zunächst einfach zu händeln und billig einzukaufen sind. Das ist durchaus verständlich. Aber als reine Wiederverkäufer haben sie dann meistens keine Möglichkeiten und selten die technische Qualifikation, auf die Performance der Systeme aktiv Einfluss zu nehmen. Ihnen fehlt der echte Einblick in die Überwachung von Lastproblemen und damit fehlen ihnen auch Optimierungsmöglichkeiten.

Hier sind diese Agenturen in bester Gesellschaft, denn auch der Massenhoster bekommt einzelne Lastprobleme oft nicht mit. Schließlich besteht seine Aufgabe darin, das Große und Ganze im Blick zu behalten. Doch selbst wenn solche kritischen Anwendungen wie jene aus der Medizintechnik zur Zeit noch die Ausnahme sind, werden die Ansprüche von Online-Geschäftsanwendungen an die Server-Performance zunehmen. Die großen Hosting-Anbieter werden daraufhin sicherlich ihre Standardpakete zu vermeintlich maximal großen Kanonen aufpumpen, die allerdings bei genauem Hinsehen dann doch nicht mehr wirklich preiswert sind. Denn die meisten Agenturen können mit vielen extra Paket-Features gar nichts anfangen. Und das Problem der fehlenden Flexibilität in Sachen Skalierbarkeit bleibt weiterhin ungelöst.

Eine Maßanfertigung bleibt flexibel.

So erstaunlich das klingt, aber Speziallösungen sichern bei richtiger Planung und Umsetzung den Spielraum für Wachstum und Beschleunigung, ohne wirklich teurer zu sein. Und wenn die durchführende Agentur ihre technischen Grenzen richtig einschätzt und einen Managed Hosting Spezialisten wie die BB-ONE.net hinzuzieht, dann kann man unterm Strich sogar Geld und Zeit sparen und kommt zu befriedigenderen Ergebnissen.

Best Practice: Update Warenwirtschaftssystem

Update Warenwirtschaftssystem bzw. Fakturierung

Hier handelt es sich um ein Projekt im eigenen Haus, bei dem keine längere Unterbrechung des Betriebs erwünscht bzw. möglich war.

Die Debitoren-Buchhaltung der BB-ONE.net wird seit vielen Jahren mit einer Software erledigt, deren Hersteller quasi Markführer ist. Dem entsprechend sind Funktionalität und Support. Im Laufe der Jahre haben sich u.a. durch Software-Fehler einige Macken eingeschlichen, die dazu führten, dass wir die für uns lebenswichtige Software nicht mehr korrekt updaten konnten. Um hier einen sauberen Stand und eine sichere Funktion zu gewährleisten, wurde ein kompletter Neuaufsatz beschlossen, der parallel zum Tagesbetrieb durchgeführt werden sollte. Dabei ergaben sich einige Herausforderungen, die hier beschrieben werden sollen.

So war der Plan

Unter normalen Umständen wäre die Vorgehensweise beim Update des Warenwirtschaftssystems wie folgt gewesen:

  1. Datensicherung des „alten“ Servers
  2. Sicherung/Export der kompletten Datenbank
  3. Einrichten des neuen Servers mit der aktuellen Fakturierungs-Software
  4. Einspielen/Import der Datenbank in das neue System
  5. notwendige weitere Einrichtungen auf dem neuen System

Die Datenbank des alten Systems liess sich jedoch nicht in das neue System importieren. Also musste die alte Software temporär neu installiert werden. Als Zielserver wurde eine virtuelle Maschine (VM) in der gleichen Grössenordnung des alten Servers genommen: Systemplatte 300 GB/250 GB frei, Platte für de Software 500 GB/450 GB frei). Die exportierte Datenbank mit ca. 75 GB Grösse als ZIP-Archiv  sollte von einem gemappten Netzwerklaufwerk importiert werden. Plan war, mit diesem System dann die Software auf aktuellen Stand zu bringen.
Ärgerlich war allerdings, dass der Import der Datenbank nicht von einem Netzwerklaufwerk, sondern lediglich von einem lokalen Laufwerk möglich war. Die entsprechende Fehlermeldung kam allerdings erst nach ca. zwei Stunden. Die Software-Dokumentation und andere Quellen des Herstellers sagte darüber nichts.

Da es sich um eine VM handelte, konnte eine weitere virtuelle Festplatte (200 GB) eingerichtet und eingebunden werden. Die Fehlermeldung kam nun später, nämlich nach ca. drei Stunden: nicht genügend Plattenspeicher. Aber welches Laufwerk war nun zu klein? Rein rechnerisch waren alle drei Laufwerke gross genug. Um weitere Versuchsreihen abzukürzen, wurden alle drei Laufwerke auf jeweils 1000 GB erweitert. Dies war möglich, da erstens mit Virtualisierung gearbeitet wurde und zweitens die genutzte Hardware, also der Host so überdimensioniert ist, dass wir „mal eben“ aus dem vollen schöpfen konnte.

Damit konnte dann über Nacht der Datenbankimport fehlerfrei durchgeführt werden.
Die Datenbank konnte durch eine spezielle Software vom Hersteller deutlich verkleinert werden, sie benötigte nun nur noch knapp 15 GB.

Nachdem allerlei Tests bestätigten, dass die Datenbank und die Software einwandfrei waren, wurden die drei Arbeitsplatz-Clients als VM eingerichtet. Um Arbeitszeit zu sparen, wurde der erste Client zweimal kopiert, was gegenüber dem kompletten Neuaufsatz wesentlich schneller ging: die Einrichtung der ersten VM dauerte insgesamt 1,5 Arbeitstage, das Kopieren ging dann in knapp drei Stunden vor sich.

Damit hatten wir ein funktionierendes System mit vier Rechnern: einer VM mit Windows 2012 als Server, drei VM mit Windows 10 als Arbeitsplatz-Clients.

Die beiden Originale ( 1 Server, 1 Client) wurden zunächst wiederum kopiert und auf einem getrennten Host gesichert.

Nun kam der Wunsch auf, die Speicherkapazität des Servers von den zwischenzeitlich 3 TB wieder auf eine vernünftige Grösse zu bringen. Die drei Laufwerke C,D,E liessen sich zwar aus Windowssicht verkleinern jedoch war es nicht möglich, die drei nicht zusammenhängenden Speicherbereiche wieder frei zu geben. Die verschiedenen empfohlenen Ansätz führten sogar dazu, dass Windows nicht mehr stabil lief. Ob dies auf einen Fehler oder auf Unmöglichkeit zurückzuführen war, liess sich unter Zeitdruck nicht mehr feststellen.

Abhilfe war dann das Hochfahren der vorher erzeugten Backup-Kopie der VM. Da trotzdem noch der Wunsch nach Verringerung der Speicherkapazität bestand, musste also noch einmal eine Schleife eingelegt werden.

Der Server wurde also noch einmal aufgesetzt, die Software eingerichtet und die Datenbank importiert. Es stellte sich heraus, dass für Windows 300 GB, die Software 500 GB, für die Datenbank beim Importieren 500 GB ausreichen waren. Damit hatten wir für den Server 1,5 TB statt 3 TB in Gebrauch.

Dies Resultat wurde nun wiederum kopiert und als Backup für Notfälle vorgehalten.

Das Resultat

Insgesamt wurde für den gesamten Prozess vier Arbeitstage benötigt. Obwohl es, speziell beim Importieren der Datenbank zu deutlichen Verzögerungen kam, kann man abschliessend sagen:

  • Projekt gelungen
  • Erfahrungen gemacht
  • Werkzeugauswahl war richtig

Projekt gelungen?

Die Fakturierungssoftware konnte aktualisiert, neue gewünschte Funktionen hinzugefügt werden, ohne Datenverlust zu riskieren. Damit ist das Projekt zunächst einmal gelungen.

Erfahrungen gemacht?

Das Verhalten der Fakturierung war an einigen Stellen nicht entsprechend der Dokumentation und Angaben des Herstellers. Dies betraf sowohl den eigentlichen Installationsprozess (z.B. Speicherbedarf beim Datenbankimport, Unmöglichkeit des Imports von einem Netzlaufwerk, einige Ungereimtheiten beim Zusammenspiel mit dem Betriebssystem und zusätzlichen Treibern) als auch versteckte Funktionsänderungen (z.B. Mailversand der Rechnungen angeblich nur noch über Outlook).

Die Vorgehensweise, viele Systeme zu virtualisieren, hat sich auch hierbei wieder bestätigt.

Der gesamte Prozess inclusive aller Probleme und deren Lösungen wurde im internen Wiki dokumentiert.

Werkzeugauswahl?

Wie bereits mehrfach angedeutet, laufen sowohl der Server als auch die Arbeitsplatz-Clients als virtuelle Windows Maschinen mit dem Hypervisor VMware vCenter. Es ist ein stabiles, flexibles und auch betriebswirtschaftlich akzeptables System. Auf die drei Client-VMs wird per RDP mit Netzwerk-Authentifizierung zugegriffen. Dadurch ergaben und ergeben sich sowohl für den Update-Prozess als auch für den laufenden Betrieb mehrere Möglichkeiten:

  1. Durch das Anlegen von Komplett-Kopien sowohl der Clients als auch des Servers konnte unnötiger Stress vermieden bzw. Zeit eingespart werden. Die Alternative wäre das Anlegen von Snapshots gewesen. Diese Vorgehensweise ist jedoch weder vergleichbar sicher noch vergleichbar flexibel. Das von uns verwendete Werkzeug ist der „VMware vCenter Converter Standalone Client“. Er ist ursprünglich dazu gedacht, einen physischen Rechner in eine VM zu konvertieren. Es ist jedoch auch möglich, eine vollständige Kopie einer Windows-VM im laufenden Betrieb anzulegen, dies sogar auf einem anderen Host in einem anderen Netzwerk. Diese Kopie hat üblicherweise identische Eigenschaften wie das Original. Allerdings kann man verschiedene Eigenschaften wie Speicher oder RAM während des Konvertierens beeinflussen.
  2. Da bei der BB-ONE.net der Grossteil der Rechnungen am Monatswechsel erzeugt wird, erscheint für die Datensicherungsprozedur folgende Vorgehensweise sinnvoll:
    1. Vor dem Rechnungslauf, also kurz vor Monatsende werden die drei Clients und der Server mit dem oben beschriebenen Tool „VMware vCenter Converter Standalone Client“ auf einen zweiten Hypervisor-Host kopiert.Damit ist gewährleistet, dass regelmässig eine funktionsfähige Kopie der vier VMs vorhanden ist, die in sehr kurzer Zeit (ca. 5 Minuten einsatzbereit ist).
    2. Die Fakturierung verfügt über eine automatische Datenbank-Sicherungsroutine, die regelmässig (täglich, sieben Generationen) die Datenbank auf ein Netzlaufwerk sichert.
      Die Sicherung erfolgt auf einer getrennten VM, in der ein Linux-System mit einem SAMBA-Server läuft. Diese VM wird täglich auf getrennte Hardware gesichert (3 Generationen: Mo/Mi/Fr bzw. Di/Do/Sa, sowie So. Täglich wird dieser Datenbestand per Rsync mit einem identischen virtuellen Server in unserem Datacenter abgeglichen.
      Zusätzlich wird am Monatswechsel eine Vollkopie auf eine dritte Hardware an einem dritten Ort gezogen, die nur dann am Netz ist.
      Als Hypervisor für die Linux-bezogenen Virtuellen Maschinen dient bei BB-ONE.net OpenVZ.
  3. Dimensionierung ist stets ein wichtiges Kriterium für den sicheren Betrieb von beliebiger IT. Sowohl verhält sich jede Hardware unnormal, wenn sie über eine bestimmte Grenze hinaus belastet wird. Router und Switche beispielsweise erzeugen dann  Paketverluste.
    Für Speicherplatz eine optimale Dimensionierung zu definieren, ist deutlich schwieriger, hier kommen neben persönlichen Erfahrungswerten auch unterschiedliche Vorgehensweisen zum Tragen. Bei der BB-ONE.net wird stets mit dem dreifachen Speicherbedarf gegenüber der ersten Planung gearbeitet.
    So war es uns möglich, schnell und flexibel auf temporäre Speicherbedürfnisse zu reagieren.

Abschliessend kann gesagt werden, dass zwar der Prozess „Update des Warenwirtschaftssystems bzw. der Fakturierung“ positiv abgeschlossen werden konnte. Allerdings gab es doch einige Verärgerungen über schlechte und Praxis-fremde Dokumentationen. Auch die Tatsache, dass der Hersteller mehrfach und an verschiedenen Stellen quasi als Wiederverkäufer von Microsoft tätig war, kam bei uns nicht positiv an. Dass die Software nur für Windows verfügbar ist, kann noch hingenommen werden. Dass aber auch immer wieder auf die Verwendung von Microsoft-Softwares gedrängt wurde, ist inakzeptabel.

Best Practice: DNSSEC für mehr Sicherheit im Domain-Betrieb

DNSSEC ist eine DNS-Erweiterung, die inzwischen eigentlich Standard sein sollte. Denn das Domain Name System ist ein beliebtes Angriffsziel für Hacker, welche allzu gerne Anfragen über „www….“ auf kriminelle Seiten umleiten, damit sie zum Beispiel Ihre Bank- oder Kreditkartendaten abgreifen können. Das kann natürlich auch mit Ihrer Geschäftsdomain passieren. Daher sollten Sie diese mit DNSSEC von Ihrem Anbieter schützen lassen.

Wir empfehlen Ihnen, auch den hierzu passenden  Beitrag des BB-ONE.net Magazins zu diesem Thema zu lesen. Aber um sich erst einmal zu informieren, wie das Sicherheitssystem für Domains arbeitet, sehen Sie sich am besten diesen kurzen anschaulichen Video-Beitrag an.

Starten Sie das Webinar „Best Practice – DNSSEC“:


Haben Sie Fragen?

Wenn Sie Fragen haben oder noch einmal nachhaken wollen, dann nutzen Sie einfach das Formular:





Bitte beweisen Sie ein Mensch zu sein und wählen Sie den Schlüssel aus.

Best Practice: Der eigene lokale DNS-Resolver

Ein eigener lokaler DNS-Resolver ist sinnvoll, wenn Sie in Ihrem Unternehmen viel Wert auf Internet-Sicherheit legen. Das sollten Sie vor allem immer dann tun, wenn Sie bzw. Ihre Mitarbeiter „von Berufs wegen“ viel im Internet unterwegs sind, sei es weil ein Großteil Arbeit in der Cloud erledigt oder weil alle Bankgeschäfte, An- und Verkaufsaktivitäten mit Zahlungsverkehr online getätigt werden. Denn hier müssen Sie sicherstellen, dass der Aufruf „www…“ immer bei der richtigen Adresse landet und die dabei übertragenen Daten nicht in die falschen Hände (z. B. von Hackern) geraten.

Wir empfehlen Ihnen, auch den Beitrag „Der eigene Resolver? Kein Hexenwerk.“des BB-ONE.net Magazins zu diesem Thema zu lesen. Aber um sich erst einmal zu informieren, wie DNS-Resolver funktionieren und wo Ihr lokales System anzusiedeln wäre, sehen Sie sich am besten diesen kurzen anschaulichen Video-Beitrag an.

Starten Sie das Webinar „Best Practice – Der lokale DNS-Resolver“:


Haben Sie Fragen?

Wenn Sie Fragen haben oder noch einmal nachhaken wollen, dann nutzen Sie einfach das Formular:





Bitte beweisen Sie ein Mensch zu sein und wählen Sie die Flagge aus.

Best Practice: Datencloud geht auch ohne „Box“

Es gibt eine attraktive Alternative zur Datencloud mit der „Box“. In unserem „Best Practice“ Webinar zur Datencloud DropIn zeigen wir Ihnen, wie Sie mit dieser skalierbaren Cloudlösung Dokumente ganz einfach hochladen, verwalten und teilen können. Und das alles DSGVO-konform.

Starten Sie das Webinar „Best Practice Datencloud Dropin“:


Haben Sie Fragen?

Wenn Sie Fragen haben oder noch einmal nachhaken wollen, dann nutzen Sie einfach das Formular:





Bitte beweisen Sie ein Mensch zu sein und wählen Sie die Flagge aus.