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 Nettoprofi wächst um 117 Prozent. Auch beim Umsatz erzielt die Facebook-Mutter ein deutliches Plus.…
Vom Standpunkt eines Verbrauchers aus betrachtet, stellt sich die Frage: Wie relevant und persönlich sind…
Scamio analysiert und bewertet die Gefahren und gibt Anwendern Ratschläge für den Umgang mit einer…
Seine Trainingsdaten umfassen 3,8 Milliarden Parameter. Laut Microsoft bietet es eine ähnliche Leistung wie OpenAIs…
Sie erlaubt eine Remotecodeausführung außerhalb der Sandbox. Betroffen sind Chrome für Windows, macOS und Linux.
Probleme treten vor allem bei Nutzern von Outlook Web Access auf. Das optionale Hotfix-Update für…