Stillstand, offline, nicht erreichbar, Fehler, Absturz, Ausfall, Unterbrechung, Störung: Eine Menge negativer Begriffe werden mit dem Begriff "Ausfallzeit" assoziiert und stellen eine Bedrohung der Verfügbarkeit von Server-Anwendungen dar. Ein Imageschaden und finanzielle Einbußen können mögliche Folgen sein - auch weil Kunden solche Ausfälle nicht hinnehmen und sich entscheiden, zur Konkurrenz zu wechseln. Dieser Risiken sind sich viele Unternehmen, besonders Mittelständler, kaum, gar nicht oder nicht genügend bewusst - und das obwohl jeder erwartet, dass betriebliche Prozesse stets reibungslos ablaufen.
Risiken von Ausfallzeiten ernst nehmen und handeln
Maßnahmen, um diesen Ausfallzeiten vorzubeugen, werden noch immer vernachlässigt, "es läuft doch im Großen und Ganzen" wird oft gesagt. Eins aber ist klar: Im Zeitalter von Big Data, Industrie 4.0 und Always-On reicht Verfügbarkeit "im Großen und Ganzen" einfach nicht mehr aus.
- Die 10 größten Security-Risiken in der Cloud
Lesen Sie, welche Security-Risiken der Einsatz einer Public oder Hybrid Cloud birgt und was Sie dagegen tun können. - Verletzung der Vertraulichkeit und Integrität der Daten:
Eine Lokalisierung der Daten ist in einer Public oder Hybrid Cloud für den Dateneigentümer nicht mehr einfach möglich. Daher ist der Schutz der Daten auf der Infrastruktur-, Plattform und Applikationsebene häufig nicht mehr mit üblichen Mitteln zu gewährleisten. - Löschung von Daten:
Daten müssen in vielen Fällen (etwa aufgrund gesetzlicher Bestimmungen) gelöscht werden. Auch hier besteht das Risiko einer nur unzureichenden oder unvollständigen Löschung auf allen Plattformen und Datenbanken der Cloud, da die Lokalisierung der Daten nur schwer möglich ist. - Ungenügende Mandantentrennung:
Bei nicht ausreichend abgesicherter Mandantentrennung besteht die Gefahr, dass Dritte unautorisiert Daten einsehen oder manipulieren können. - Verletzung der Compliance:
Da Daten in einer Public Cloud prinzipiell in allen Ländern der Welt in deren spezifischen Rechtsordnungen verarbeitet werden können, ist die Erfüllung aller gesetzlicher Anforderungen eine wesentliche Aufgabe bei der Nutzung von Public Cloud Leistungen. - Verletzung von Datenschutzgesetzen:
Es ist nicht von vornherein klar, in welchen Ländern, Rechenzentren, auf welchen Servern und mit welcher Software die Daten gespeichert und verarbeitet werden. - Insolvenz des Providers:
Die Insolvenz eines Providers bedeutet meist nicht die Insolvenz aller Rechenzentren, die der Provider verwendet hat. Rechenzentren werden zudem bei Insolvenz mit großer Wahrscheinlichkeit an andere Provider verkauft werden. - Problematik der Subunternehmer:
Ein weiteres Problem stellt die Auftragsweitergabe an Subunternehmer dar. Der Provider wird häufig Subunternehmer für gewisse Leistungen verpflichten. In einer Public Cloud bleibt auch diese Komplexität dem Benutzer häufig verborgen (und soll ja nach der Philosophie des Cloud Computing verborgen bleiben). - Beschlagnahmung von Hardware:
Eine Beschlagnahme von Hardware kann in allen Ländern erfolgen, in denen der Provider Computing-Ressourcen nutzt. Meist werden sich Daten des Auftraggebers auf beschlagnahmten Servern befinden. - Handel mit Ressourcen wird denkbar:
Denkbar ist auch, dass Provider einen Handel mit ihren Ressourcen untereinander aufbauen und damit eine "Ressourcenbörse" realisieren wie sie in obiger Abbildung angedeutet ist. Auf dieser Börse werden Ressourcen zu einem bestimmten Preis angeboten. - Erpressungsversuche:
Die Gefahr von Erpressungsversuchen steigt, da der Personenkreis mit Administrationsaufgaben für Ressourcen der Public Cloud unüberschaubar groß ist. Das eingesetzte Personal verfügt im Allgemeinen über unterschiedliches Ausbildungsniveau und Sicherheitsbewusstsein.
Verfügbarkeitsoptionen kennen und unterscheiden
Wie wichtig Verfügbarkeit ist, lässt sich an den folgenden Zahlen demonstrieren: Eine HP-Studie von 2013 belegt, dass in mittelständischen Unternehmen in Deutschland durch Ausfälle jährlich 380.000 Euro Kosten pro Jahr entstanden. Laut EMC ist der finanzielle Schaden für 2014 sogar noch größer: 2014 haben Unternehmen in Deutschland wegen "Downtime" Verluste von zusammengerechnet 11,6 Milliarden Euro hinnehmen müssen. Ausfallkosten sind natürlich auch von der Branche abhängig, weshalb Unternehmen bei der Auswahl von Verfügbarkeitslösungen genau hinschauen müssen.
Bei den Verfügbarkeitsoptionen wird zwischen "gut", "besser" und "optimal" unterschieden: Als gut gilt die Standardverfügbarkeit (99% Verfügbarkeit, durchschnittlich 87,5 Stunden Ausfall pro Jahr). Hier kommen in der Regel zuverlässige x86-Einzelserver mit redundanten Lüftern, redundanter Stromversorgung und gespiegeltem Speicher zum Einsatz. Sie bieten aber keinerlei Sicherheit bei der Datenübertragung. Besser ist da schon eine Datenreplikationssoftware: Damit werden Daten synchron oder asynchron von einem oder mehreren Ausgangsservern auf einen Zielserver repliziert. Der Nachteil ist, dass es bei einem Ausfall keine Garantie dafür gibt, dass der Betrieb sofort wieder aufgenommen wird. Noch besser einzuschätzen ist die Hochverfügbarkeit (99,9%, 8,75 Stunden Ausfall pro Jahr), optimal die ständige Verfügbarkeit bzw. eine Always-On-Lösung (99,99%, 52 Minuten Ausfall pro Jahr und bis zu 99,9999%, 1-5 Minuten Ausfall pro Jahr).
Foto: Adacor
Die Ständige Verfügbarkeit ist das höchste Level der Verfügbarkeit und bietet den größten Schutz vor Ausfällen. Zu dieser Lösung gehören zwei vollständig redundante Server sowie Software zur permanenten Überwachung der Systemkomponenten.
Grundsätzlich ist zwischen Hochverfügbarkeitssoftware und einer Cluster-Lösung zu unterscheiden. Bei der Software-Lösung beträgt die Ausfallzeit weniger als eine Stunde pro Jahr, bei Hochverfügbarkeits-Clustern hingegen fast neun Stunden. Auch ist deren Grund-Ansatz verschieden: Das Cluster zielt auf eine möglichst schnelle Wiederherstellung nach einem Systemausfall ab, die Software hingegen kann Ausfallzeiten und Datenverluste automatisch erkennen und Fehler melden, bevor sie das gesamte System betreffen. Bei einer Clusterlösung bedarf es für die Entwicklung des dafür nötigen Failover-Scripts zudem ausreichender Fachkenntnisse, die bei einer Software nicht notwendig sind.