Amazon Web Services hat einen ungewöhnlichen Lösungsansatz vorgestellt, wie es dem demnächst wieder anstehenden Problem der Schaltsekunde begegnen will. Es wird dazu 24 Stunden lang praktisch eine eigene Zeitrechnung schaffen.
In den vergangenen Jahren führte das Schaltsekundenproblem regelmäßig zu Fehlfunktionen bei einigen Computersysteme. Beim letzten Auftreten im Juni 2012 war dies beispielsweise bei Reddit, Quantas und Mozilla der Fall. Die nächste Schaltsekunde ist für Mitternacht am 30. Juni vorgesehen. Viele Systeme lösen das Problem, indem sie ihrer Uhr einfach eine Extrasekunde hinzufügen, die dann als „23:59:60“ angezeigt wird.
Doch wie Jeff Barr, Chief Evangelist von Amazon Web Services (AWS), in einem Blogbeitrag erklärt, sind nicht alle Systeme in der Lage, die „:60“-Schreibweise korrekt zu verarbeiten. Dazu zählen auch einige Backend-Systeme und die Verwaltungskonsole von AWS.
„Die AWS Management Console und Backend-Systeme werden die Schaltsekunde NICHT implementieren. Stattdessen teilen wir die eine Extrasekunde auf einen 24 stündigen Zeitraum um die Schaltsekunde auf, indem wir jede Sekunde minimal verlängern“, so Barr weiter. Statt also am 30. Juni um Mitternacht eine Sekunde zu addieren, werde man für je 12 Stunden vor und nach der Schaltsekunde jede einzelne Sekunde in den AWS-Uhren auf „1 plus 1/86400 Sekunden der ‚echten‘ Zeit“ ausdehnen.
Das bedeutet, das Amazon in diesen 24 Stunden eine eigene Zeitrechnung vornimmt, die von der koordinierten Weltzeit um bis zu eine halbe Sekunde abweicht. Gegen 12 Uhr am 1. Juli sollen die AWS-Uhren dann wieder mit der koordinierten Weltzeit synchron sein.
Nutzer von Amazons EC2-Instanzen werden die Anpassungen selbst durchführen müssen, indem sie Public Time Services auf Basis des Network Time Protocol (NTP) oder Microsofts Dienst time.windows.com verwenden. Andere AWS-Ressourcen, die sich mit Zeitservern von ntp.org synchronisieren, werden die eine Standardsekunde automatisch implementieren. Dazu zählen CloudSearch-Cluster sowie EC2-Container-Service-, RDS- und Redshift-Instanzen.
Google hatte schon 2011 einen ähnlichen Lösungsansatz für das Schaltsekundenproblem mit einer geringen Zeitausdehnung entwickelt. Es nannte ihn „Leap Smear„, also etwa „Sprungverwischung“. Dabei modifizierte es die NTP-Server für seine Dienste so, dass sukzessive wenige Millisekunden hinzugefügt wurden, sodass zum Zeitpunkt der Schaltsekunde der Zeitunterschied bereits ausgeglichen war.
[mit Material von Liam Tung, ZDNet.com]
Tipp: Sind Sie ein Fachmann in Sachen Cloud Computing? Testen Sie Ihr Wissen – mit dem Quiz auf silicon.de.
Der Cybersecurity Report von Hornetsecurity stuft 2,3 Prozent der Inhalte gar als bösartig ein. Die…
Die Hintermänner haben es auf Zugangsdaten zu Microsoft Azure abgesehen. Die Kampagne ist bis mindestens…
Cloud-Plattform für elektronische Beschaffungsprozesse mit automatisierter Abwicklung elektronischer Rechnungen.
Mindestens eine Schwachstelle erlaubt eine Remotecodeausführung. Dem Entdecker zahlt Google eine besonders hohe Belohnung von…
Nur rund die Hälfte schaltet während der Feiertage komplett vom Job ab. Die anderen sind…
Security-Experten von Check Point sind einer neuen Angriffsart auf die Spur gekommen, die E-Mail-Schutzmaßnahmen umgehen…