Frage Warum wird DNS-Failover nicht empfohlen?


Beim Lesen scheint DNS-Failover nicht zu empfehlen, nur weil DNS dafür nicht entwickelt wurde. Aber wenn Sie zwei Webserver in verschiedenen Subnetzen haben, die redundante Inhalte hosten, welche anderen Methoden gibt es, um sicherzustellen, dass der gesamte Verkehr an den Live-Server weitergeleitet wird, wenn ein Server ausfällt?

Für mich scheint DNS-Failover die einzige Failover-Option zu sein, aber der Konsens ist, dass es keine gute Option ist. Doch Services wie DNSmadeeasy.com bieten es, also muss es einen Verdienst geben. Irgendwelche Kommentare?


166
2017-08-30 17:57


Ursprung


Aussehen Hier für eine aktualisierte Diskussion zu diesem Thema. Das Failover wird jetzt automatisch von modernen Browsern durchgeführt. - GetFree


Antworten:


Mit 'DNS-Failover' meine ich, dass DNS Round Robin mit einer gewissen Überwachung kombiniert wird, d. H. Die Veröffentlichung mehrerer IP-Adressen für einen DNS-Hostnamen und das Entfernen einer toten Adresse, wenn die Überwachung feststellt, dass ein Server ausgefallen ist. Dies kann für kleine, weniger frequentierte Websites praktikabel sein.

Wenn Sie eine DNS-Anfrage beantworten, geben Sie bei Bedarf eine Time To Live (TTL) für die von Ihnen ausgegebene Antwort an. Mit anderen Worten, Sie sagen anderen DNS-Servern und Caches "Sie können diese Antwort speichern und für x Minuten verwenden, bevor Sie sich mit mir zurückmelden". Die Nachteile ergeben sich daraus:

  • Bei einem DNS-Failover werden Ihre DNS-Daten bei einem unbekannten Prozentsatz Ihrer Benutzer mit unterschiedlichen TTL-Mengen zwischengespeichert. Bis die TTL abläuft, können sie sich mit dem Dead-Server verbinden. Es gibt schnellere Möglichkeiten, Failover abzuschließen.
  • Aus diesem Grund neigen Sie dazu, den TTL ziemlich niedrig zu setzen, sagen Sie 5-10 Minuten. Eine höhere Einstellung bietet jedoch einen (sehr geringen) Leistungsvorteil und kann dazu beitragen, dass Ihre DNS-Verbreitung zuverlässig funktioniert, auch wenn der Netzwerkverkehr nur kurz unterbrochen wird. Die Verwendung von DNS-basiertem Failover geht also gegen hohe TTLs, aber hohe TTLs sind ein Teil von DNS und können nützlich sein.

Die üblicheren Methoden, um eine gute Verfügbarkeit zu erreichen, beinhalten:

  • Platzieren von Servern im selben LAN
  • Platzieren Sie das LAN in einem Datencenter mit hoch verfügbaren Strom- und Netzwerkebenen.
  • Verwenden Sie einen HTTP-Load Balancer, um das Laden und Failover bei einzelnen Serverfehlern zu verteilen.
  • Ermitteln Sie die für Ihre Firewalls, Load Balancer und Switches erforderliche Redundanz / erwartete Betriebszeit.
  • Es muss eine Kommunikationsstrategie für Fehler im gesamten Datencenter und für den gelegentlichen Ausfall eines Switch- / Datenbankservers / anderer Ressourcen eingerichtet werden, die nicht einfach gespiegelt werden können.

Eine sehr kleine Minderheit von Websites verwendet Multi-Datacenter-Setups mit "Geo-Balancing" zwischen Datencentern.


93
2017-08-30 18:39



Ich denke, er versucht speziell, Failover zwischen zwei verschiedenen Rechenzentren zu verwalten (beachten Sie die Kommentare zu verschiedenen Subnetzen), also wird es nicht helfen, die Server zusammen zu stellen / Load Balancer / Redundanz zu verwenden (abgesehen von redundanten Rechenzentren) muss dem Internet immer noch sagen, dass es zu demjenigen gehen soll, der immer noch aufsteht). - Cian
Fügen Sie Anycast zu dem Multi-Datacenter-Setup hinzu und es wird Datencenter-Ausfallsicher. - petrus
Wikipedia Eintrag auf Anycast (en.wikipedia.org/wiki/Anycast) diskutiert dies in Bezug auf die Widerstandsfähigkeit des DNS-Root-Servers. - dunxd
DDoS-Angriffe sind so weit verbreitet, dass ganze Rechenzentren offline gehen können (passiert mit Linode London und ihren anderen Rechenzentren im Dezember 2015). Es wird nicht empfohlen, denselben Anbieter im selben Rechenzentrum zu verwenden. Daher wären mehrere Rechenzentren mit unterschiedlichen Providern eine gute Strategie, die uns zurück zum DNS-Failover bringt, sofern keine bessere Alternative existiert. - Laurence Cope
Gibt es keinen Grund für einen Failover, weil Sie Ihre Site live halten müssen, wenn ein Gerät ausgefallen ist? Wie gut wird Ihr Failover sein, wenn es sich im selben Netzwerk befindet, das dieselben Geräte wie z. Router? - user2128576


DNS-Failover funktioniert definitiv großartig. Ich nutze es seit vielen Jahren, um den Datenverkehr manuell zwischen Datencentern zu verlagern, oder automatisch, wenn das System Ausfälle, Verbindungsprobleme oder überlastete Server erkennt. Wenn Sie die Geschwindigkeit sehen, mit der es funktioniert, und die Menge des realen Verkehrs, die mit Leichtigkeit verschoben werden kann - werden Sie nie zurückblicken. Ich benutze Zabbix für die Überwachung all meiner Systeme und die visuellen Diagramme, die zeigen, was während einer DNS-Failover-Situation passiert, setzen alle meine Zweifel auf und enden damit. Es gibt vielleicht ein paar ISPs, die TTLs ignorieren, und es gibt immer noch Nutzer mit alten Browsern - aber wenn Sie Traffic von Millionen von Seitenaufrufen pro Tag über zwei Rechenzentrumsstandorte hinweg betrachten und eine DNS-Verkehrsverlagerung vornehmen - der Restverkehr, der TTLs ignoriert, ist lachhaft. DNS-Failover ist eine solide Technik.

DNS wurde nicht für Failover entwickelt - aber es wurde mit TTLs entwickelt, die in Kombination mit einem soliden Überwachungssystem erstaunlich für Failover-Anforderungen geeignet sind. TTLs können sehr kurz eingestellt werden. Ich habe effektiv TTLs von 5 Sekunden in der Produktion für blitzschnelle DNS-Failover-basierte Lösungen verwendet. Sie müssen DNS-Server haben, die in der Lage sind, die zusätzliche Last zu verarbeiten - und named wird es nicht schneiden. Allerdings passt powerdns, wenn es mit einer MySQL-replizierten Datenbank auf redundanten Nameservern gesichert wird. Sie benötigen außerdem ein solides verteiltes Überwachungssystem, auf das Sie bei der automatisierten Failover-Integration vertrauen können. Zabbix funktioniert für mich - ich kann Ausfälle von mehreren verteilten Zabbix-Systemen fast augenblicklich überprüfen - mysql-Datensätze, die von powerdns im laufenden Betrieb verwendet werden, aktualisieren - und bei Ausfällen und Traffic-Spikes fast sofortiges Failover bereitstellen.

Aber hey - ich habe ein Unternehmen gegründet, das DNS-Failover-Dienste anbietet, nachdem es jahrelang für große Unternehmen funktioniert hat. Also nimm meine Meinung mit einem Körnchen Salz. Wenn Sie während eines Ausfalls einige Zabbix-Traffic-Grafiken von Websites mit hohem Volumen sehen möchten - um sich selbst davon zu überzeugen, wie gut DNS-Failover funktioniert - schreiben Sie mir eine E-Mail, die ich gerne weitergebe.


44
2017-10-20 17:17



Cian's Antwort serverfault.com/a/60562/87017 widerspricht dir direkt ... also wer hat Recht? - Pacerier
Es ist meine Erfahrung, dass kurze TTLs nicht über das Internet funktionieren. Möglicherweise führen Sie DNS-Server aus, die die RFCs berücksichtigen - aber es gibt viele Server, die das nicht tun. Bitte gehen Sie nicht davon aus, dass dies ein Argument gegen Round Robin DNS ist - siehe auch die unten stehende Antwort von vmiazzo - Ich habe mit RR DNS ausgelastete Sites ausgeführt und getestet - es funktioniert. Die einzigen Probleme, auf die ich stieß, waren einige Java-basierte Clients (nicht Browser), die nicht einmal versuchten, sich bei einem Fehler neu zu verbinden, geschweige denn die Liste der Hosts auf einer RST zyklisch zu ändern - symcbean
Ich wette, die Leute, die sagen, dass DNS Failover überwacht wird, sind großartig und die Leute, die sagen, dass es scheiße ist, haben ähnliche Erfahrungen, aber mit anderen Erwartungen. 100 sch sch sch 100 100 100 100 100 100 100 100 sch sch sch sch zwischen sch 100 sch sch sch sch 100 100 sch sch sch sch sch sch 100 100 sch sch sch sch sch sch dieser 100 sch sch sch sch sch 100 100 sch sch sch sch sch 100 100 sch sch sch sch sch sch 100 100 100 sch 100 sch dieser Wenn Sie einen vollständig nahtlosen Zugriff benötigen (niemals eine einzelne Anfrage verlieren, selbst während eines Serverausfalls), benötigen Sie wahrscheinlich eine viel anspruchsvollere - und teure - Architektur. Das ist keine Voraussetzung für viele Anwendungen. - Tom Wilson


Das Problem mit dem DNS-Failover ist, dass es in vielen Fällen unzuverlässig ist. Einige ISPs werden Ihre TTLs ignorieren, es passiert nicht sofort, selbst wenn sie Ihre TTLs respektieren, und wenn Ihre Site wieder hochfährt, kann es bei Sessions zu seltsamen Situationen kommen, wenn der DNS-Cache eines Benutzers ausfällt und am Ende geht zu dem anderen Server.

Leider ist es so ziemlich die einzige Option, es sei denn, Sie sind groß genug, um Ihr (externes) Routing selbst durchzuführen.


31
2017-08-30 18:27



+1 Langsam und unzuverlässig - Chris S
Siehe auch serverfault.com/q/315199/87017 - Pacerier


Die vorherrschende Meinung ist, dass mit DNS RR, wenn eine IP ausfällt, einige Clients die kaputte IP für Minuten weiter verwenden werden. Dies wurde in einigen der vorherigen Antworten auf die Frage angegeben und es ist auch auf Wikipedia geschrieben.

Sowieso,

http://crypto.stanford.edu/dns/dns-rebinding.pdf erklärt, dass dies für die meisten aktuellen HTML-Browser nicht zutrifft. Sie werden die nächste IP in Sekunden versuchen.

http://www.tenereillo.com/GSLBPageOfShame.htm scheint noch stärker zu sein:

Die Verwendung von mehreren A-Datensätzen ist kein Trick des Handels oder ein Merkmal, das von Herstellern von Lastausgleichsgeräten entwickelt wurde. Das DNS-Protokoll wurde aus diesem Grund mit Unterstützung für mehrere A-Datensätze entwickelt. Anwendungen wie Browser, Proxies und Mail-Server nutzen diesen Teil des DNS-Protokolls.

Vielleicht kann ein Experte einen Kommentar abgeben und erklären, warum DNS RR nicht gut für Hochverfügbarkeit ist.

Vielen Dank,

Valentino

PS: Entschuldigung für den fehlerhaften Link, aber als neuer Benutzer kann ich nicht mehr als 1 posten


19
2017-09-29 10:06



Mehrere A-Datensätze sind für das Load Balancing vorgesehen und nicht für Failover. Clients werden die Ergebnisse zwischenspeichern und den gesamten Pool (einschließlich der beschädigten IP-Adresse) einige Minuten lang verwenden, nachdem Sie den Datensatz geändert haben. - Cian
Also, ist was geschrieben ist crypto.stanford.edu/dns/dns-rebinding.pdf Kapitel 3.1 falsch? << Internet Explorer 7 pinnt DNS-Bindungen für 30 Minuten.1 Wenn die Domäne des Angreifers mehrere A-Einträge aufweist und der aktuelle Server nicht verfügbar ist, versucht der Browser innerhalb einer Sekunde leider eine andere IP-Adresse. >> - Valentino Miazzo
Habe meine Teilfrage hier verschoben serverfault.com/questions/69870/... - Valentino Miazzo


Ich führte DNS-RR-Failover auf einer Produktion moderat-trafficked aber geschäftskritische Website (über zwei Länder) für viele Jahre.

Es funktioniert gut, aber es gibt mindestens drei Feinheiten, die ich auf die harte Tour gelernt habe.

1) Browser führen nach 30 Sekunden (das letzte Mal, wenn ich überprüft habe) einen Failover von einer nicht funktionierenden IP zu einer funktionierenden IP durch, wenn beide in dem Cache, der zwischengespeichert wird, als aktiv betrachtet werden. Das ist grundsätzlich eine gute Sache.

Aber "halb" Ihre Benutzer warten 30 Sekunden ist inakzeptabel, so dass Sie wahrscheinlich Ihre TTL-Datensätze aktualisieren möchten, um ein paar Minuten, nicht ein paar Tage oder Wochen, so dass im Falle eines Ausfalls können Sie schnell entfernen Sie den Server herunter von Ihrem DNS. Andere haben in ihren Antworten darauf hingewiesen.

2) Wenn einer Ihrer Nameserver (oder einer Ihrer beiden Länder) ausfällt, der Ihrer Round-Robin-Domain dient, und wenn der primäre von ihnen ausfällt, erinnere ich mich vage daran, dass Sie auf andere Probleme stoßen, die versuchen, diese zu entfernen den Nameserver von DNS abstürzen lassen, wenn Sie Ihre SOA TTL / Expiration für den Nameserver nicht auf einen ausreichend niedrigen Wert gesetzt haben. Ich könnte die technischen Details hier falsch haben, aber es gibt mehr als nur eine TTL-Einstellung, die Sie richtig machen müssen, um wirklich gegen einzelne Fehlerpunkte zu verteidigen.

3) Wenn Sie Web-APIs, REST-Dienste usw. veröffentlichen, werden diese in der Regel nicht von Browsern aufgerufen, und daher scheint DNS-Failover meiner Meinung nach echte Schwachstellen aufzuweisen. Dies könnte der Grund sein, warum einige sagen, wie du es ausdrückst: "Es ist nicht empfehlenswert". Hier ist, warum ich das sage. Erstens sind die Apps, die diese URLs verwenden, normalerweise keine Browser, daher fehlt ihnen die 30-Sekunden-Failover-Eigenschaften / Logik gängiger Browser. Zweitens hängt die Frage, ob der zweite DNS-Eintrag aufgerufen wird oder nicht, sogar von DNS-Abfragen ab, sehr von den Programmierdetails der Netzwerkbibliotheken in den von diesen API / REST-Clients verwendeten Programmiersprachen sowie davon, wie sie aufgerufen werden die API / REST-Client-App. (Unter ihnen deckt, ruft die Bibliothek get_addr, und wann? Wenn Sockets hängen oder schließen, öffnet die App neue Sockets wieder? Gibt es eine Art von Timeout-Logik? Etc etc)

Es ist billig, gut getestet und "funktioniert meistens". Wie bei den meisten Dingen kann Ihre Laufleistung variieren.


11
2018-04-12 01:21



Eine Bibliothek, die die anderen Ressourceneinträge für eine Adresse nicht erneut versucht, ist defekt. Richten Sie die Entwickler auf die Manpages für getaddrinfo () usw. - Jasen


Es gibt eine Reihe von Leuten, die uns (Dyn) für Failover benutzen. Aus demselben Grund können Websites auch eine Statusseite erstellen, wenn sie Ausfallzeiten haben (denken Sie an Dinge wie Twitter's Fail Whale) ... oder leiten Sie einfach den Datenverkehr basierend auf den TTLs um. Manche Leute denken vielleicht, dass DNS-Failover ein Ghetto ist ... aber wir haben unser Netzwerk von Anfang an mit Failover entworfen, so dass es genauso gut funktioniert wie Hardware. Ich bin mir nicht sicher, wie DME es tut, aber wir haben 3 von 17 unserer nächstgelegenen anycasted PoPs überwachen Ihren Server von der nächsten Stelle. Wenn es von zwei der drei erkennt, dass es unten ist, leiten wir einfach den Verkehr zur anderen IP um. Die einzige Ausfallzeit ist für diejenigen, die für den Rest dieses TTL-Intervalls angefordert wurden.

Manche Leute benutzen beide Server gleichzeitig ... und können in diesem Fall so etwas wie einen Round Robin Load Balancing ... oder einen geo-basierten Load Balancing durchführen. Für diejenigen, die sich wirklich um die Performance kümmern ... unser Echtzeit-Traffic-Manager wird jeden Server überwachen ... und wenn einer langsamer ist ... den Traffic auf den schnellsten umleiten, basierend darauf, welche IPs Sie in Ihren Hostnamen verlinken. Auch dies funktioniert auf der Grundlage der Werte, die Sie in unserer UI / API / Portal festgelegt haben.

Ich denke, mein Punkt ist ... wir haben dns Failover mit Absicht entwickelt. Obwohl DNS nicht für das Failover erstellt wurde, als es ursprünglich erstellt wurde ... unser DNS-Netzwerk wurde entwickelt, um es von Anfang an zu implementieren. Es kann normalerweise genauso effektiv sein wie Hardware ... ohne Abschreibungen oder Hardware-Kosten. Hoffentlich macht mich das nicht lahm, wenn ich Dyn packe ... es gibt viele andere Firmen, die das tun ... Ich spreche nur aus der Perspektive unseres Teams. Hoffe das hilft...


9
2018-05-25 19:38



Was meinen Sie mit "kann genauso effektiv sein wie Hardware?" Welche Art von Hardware macht DNS-Routing? - mpen
@ Ryan, was meinst du wenn du "Ghetto" sagst? - Pacerier
Für dieses Wort gibt das städtische Wörterbuch keine Definitionen mit positiver Konnotation, ich könnte annehmen, dass "eine Bettlerlösung" eine geeignete Übersetzung sein könnte. - Jasen


Eine andere Option wäre, den Nameserver 1 auf dem Standort A und den Nameserver 2 auf dem Standort B einzurichten, aber alle aufzustellen, sodass alle A-Einträge auf NS1 den Verkehr auf die IPs für Standort A richten und auf NS2 alle A-Einträge auf IPs verweisen Standort B. Setzen Sie dann Ihre TTLs auf eine sehr niedrige Anzahl und stellen Sie sicher, dass Ihr Domain-Eintrag beim Registrar für NS1 und NS2 eingerichtet wurde. Auf diese Weise wird automatisch die Balance geladen und ein Failover wird ausgeführt, wenn ein Server oder eine Verbindung zu einem Standort ausfällt.

Ich habe diesen Ansatz auf eine etwas andere Art und Weise verwendet. Ich habe einen Standort mit zwei ISPs und verwende diese Methode, um den Verkehr über jeden Link zu leiten. Nun, es könnte etwas wartungsintensiver sein, als Sie es tun möchten ... aber ich war in der Lage, eine einfache Software zu erstellen, die automatisch NS1-Datensätze abruft, A-IP-Adressen für ausgewählte Zonen aufzeichnet und diese Zonen an verschiebt NS2.


5
2017-08-07 05:13



Neigen die Nameserver nicht zu viel, um sich zu verbreiten? Wenn Sie einen DNS-Eintrag mit niedriger TTL ändern, wird es sofort funktionieren, aber wenn Sie Nameserver ändern, werden 24 Horus oder mehr zur Verbreitung benötigt, daher sehe ich nicht, wie dies eine Failover-Lösung sein könnte. - Marco Demaio


Die Alternative ist ein BGP-basiertes Failover-System. Es ist nicht einfach einzurichten, aber es sollte kugelsicher sein. Richten Sie Site A an einem Ort ein, Site B an einer zweiten Stelle, alle mit lokalen IP-Adressen, dann erhalten Sie eine Klasse C oder einen anderen Block von IPs, die portierbar sind, und richten Sie die Umleitung von den tragbaren IPs zu den lokalen IPs ein.

Es gibt Fallstricke, aber es ist besser als DNS-basierte Lösungen, wenn Sie diese Kontrollebene benötigen.


4
2017-08-30 21:40



BGP-basierte Lösungen sind jedoch nicht für jeden verfügbar. Und es ist viel einfacher, besonders schreckliche Wege einzuschlagen als DNS. Schaukeln und Kreisverkehre, nehme ich an. - Cian


Eine Option für das Multi-Data-Center-Failover ist die Schulung Ihrer Benutzer. Wir werben für unsere Kunden, dass wir mehrere Server in mehreren Städten und in unseren Anmelde-E-Mails anbieten und Links direkt zu jedem "Server" enthalten, so dass Benutzer wissen, wenn ein Server außer Betrieb ist, können sie den Link zu dem anderen Server verwenden.

Dadurch wird das Problem des DNS-Failovers umgangen, indem nur mehrere Domänennamen verwaltet werden. Benutzer, die auf www.company.com oder company.com gehen und sich einloggen, werden an server1.company.com oder server2.company.com weitergeleitet und haben die Wahl, eines der beiden zu bookmarken, wenn sie feststellen, dass sie mit dem einen oder dem anderen eine bessere Leistung erzielen . Wenn einer ausfällt, werden die Benutzer darauf trainiert, zum anderen Server zu gehen.


3
2017-10-11 22:11



Trainiere deine Benutzer auf diese Weise ... Erhöht das nicht die Wahrscheinlichkeit, dass sie angegriffen werden? - Pacerier


Ich habe in den letzten zehn Jahren DNS-basierte Site-Balancing und Failover verwendet, und es gibt einige Probleme, die jedoch gemildert werden können. BGP, obwohl in mancher Hinsicht überlegen, ist keine 100% ige Lösung, weder mit erhöhter Komplexität, wahrscheinlich zusätzlichen Hardwarekosten, Konvergenzzeiten, etc ...

Ich habe festgestellt, dass das Kombinieren von lokalem (LAN-basiertem) Lastenausgleich, GSLB und Cloud-basiertem Zonenhosting recht gut funktioniert, um einige der Probleme zu schließen, die normalerweise mit dem DNS-Lastausgleich verbunden sind.


2
2017-08-23 01:50





All diese Antworten haben eine gewisse Gültigkeit für sie, aber ich denke, es hängt wirklich davon ab, was Sie tun und was Ihr Budget ist. Hier bei CloudfloorDNS ist ein großer Prozentsatz unseres Geschäfts DNS und bietet nicht nur schnelles DNS, sondern auch niedrige TTL-Optionen und DNS-Failover. Wir wären nicht im Geschäft, wenn das nicht funktioniert und gut funktioniert.

Wenn Sie ein multinationales Unternehmen mit unbegrenztem Budget sind, dann sind die GSLB-Load Balancer und Tier 1-Rechenzentren der Hardware zwar großartig, aber Ihr DNS muss immer noch schnell und stabil sein. Wie viele von Ihnen wissen, ist DNS ein kritischer Aspekt jeder Infrastruktur, abgesehen vom Domain-Namen selbst. Es ist der Service auf niedrigster Ebene, auf dem jeder andere Teil Ihrer Online-Präsenz läuft. Beginnend mit einem soliden Domain-Registrar ist DNS genauso wichtig, wie Ihre Domain nicht ablaufen zu lassen. DNS geht unter, es bedeutet, dass der gesamte Online-Aspekt Ihrer Organisation ebenfalls nicht verfügbar ist!

Bei der Verwendung von DNS-Failover sind die weiteren kritischen Aspekte die Serverüberwachung (immer mehrere geo-Standorte, von denen geprüft werden soll und immer mehrere (mindestens 3) sollten überprüft werden, um falsch positive Ergebnisse zu vermeiden) und die DNS-Einträge ordnungsgemäß zu verwalten. Niedrige TTLs und einige Optionen mit dem Failover können dies zu einem nahtlosen Prozess machen, und sie werden mitten in der Nacht, wenn Sie ein sys-Administrator sind, zu einem Pager aufwachen.

Insgesamt funktioniert DNS Failover wirklich und kann sehr erschwinglich sein. In den meisten Fällen von uns oder den meisten der verwalteten DNS-Anbieter erhalten Sie Anycast DNS zusammen mit Server-Überwachung und Failover für einen Bruchteil der Kosten von Hardware-Optionen.

Die wirkliche Antwort ist ja, es funktioniert, aber ist es für jeden und jedes Budget? Vielleicht nicht, aber bis Sie es ausprobieren und die Tests für sich selbst durchführen, ist es schwer zu ignorieren, wenn Sie ein kleines bis mittleres Unternehmen mit einem begrenzten IT-Budget sind, das die bestmögliche Verfügbarkeit anstrebt.


2
2018-04-24 17:37