Login
Newsletter
Werbung

Thema: DragonFly BSD 5.6 freigegeben

41 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Verfluchtnochmal_5987109 am Mi, 19. Juni 2019 um 20:00 #

4-15 Sekunden Reboot wegen kernel oder dist-upgrades fallen nicht unter Downtime! Downtime sind ungeplante Probleme

  • 0
    Von klopskind am Mi, 19. Juni 2019 um 23:58 #

    Doch, ob geplant oder nicht, das tut es, siehe Duden, Oxford dictionary, Wiktionary.

    0
    Von Urmel am Do, 20. Juni 2019 um 06:48 #

    Gröhl.... noch eine Pappnase mehr die du dir gerade aufgesetzt hast. Du arbeitest niemals in der IT.

    • 0
      Von Verfluchtnochmal_5987109 am Fr, 21. Juni 2019 um 01:09 #

      Na wenn du das sagst :-)

      Eine VM mit einem uefi-stub setup rebooted BTW deutlich unter 2 Sekunden

      • 0
        Von blablabla233 am Fr, 21. Juni 2019 um 10:52 #

        Das ist egal, 2 sekunden koennen verdammt lange sein, downtime ist downtime basta. Ist sie vertretbar? Das kommt auf den einsatz an (bei einer Website ja...bei Ebay..nein...bei Marslandungen...lieber nicht, bei Aktienmarkt..Weltuntergang :-) )

        0
        Von klopskind am Fr, 21. Juni 2019 um 11:12 #

        1. Sie ändern hier die Prämisse des Diskussionsausgangs. Oben waren es noch 4-15s Neustartdauer. Was denn nun?

        2. Ihr Spezialfall bedeutet eine hypothetische Downtime von "deutlich unter 2 Sekunden" - was auch immer das genau heißen mag; lass es ca. 1s sein.
        Hinzu kommt aber in jedem Fall noch die Dauer des sauberen Beendens & Starts der jeweilig eingesetzten Anwendungen. Das kann bei Datenbanken etc. so seine Zeit dauern, sodass die 1s (oder auch die vorher erwähnten 15s) in Allgemeinen nur ein Bruchteil der effektiven Dauer eines Neustarts entspräche(n).

        3. Mit einem herausgegriffenen Spezialfall, lässt sich nicht auf den Regelfall schließen. Genau das versuchen Sie hier aber indirekt, um Ihre These, reguläre Neustarts zögen keine Downtime nach sich (s.o.), zu stützen.

        4. Somit stimmt Ihre suggerierte Behauptung, Neustarts wären im Allgemeinen kürzer als 2s (bzw. zuvor 4-15s), und demnach quasi vernachlässigbar, nicht. Insbesondere ist auch Ihre Aussage, ein "regulärer" Neustart ziehe keine Downtime nach sich (s.o.), widerlegt - erneut.

        5. Damit sind Ihre Argumente zur Stützung Ihrer anfänglich implizierten und aus der Frage "Was genau soll mir fehlen?" resultierenden These, Ihr weiter oben geschildertes Szenario wäre gewissermaßen optimal, gegenstandslos und ungültig.

        6. Folglich sind die entkräftenden Argumente meiner Entgegnung Ihrer These (siehe Punkt 5) weiterhin gültig; die selbstentkräftenden Argumente meiner Entgegnung allerdings auch.

        7. Es ist anzunehmen, dass sich der Beitrag Urmels auf Ihren gesamten Kommentar bezog, nicht nur auf die Dauer eines Neustarts in einem hypothetischen Spezialfall; insbesondere also auf Ihre Behauptung, reguläre Neustarts zögen keine Downtime nach sich.

        8. Sie erhalten Beiträge à la Urmel, weil Sie Behauptungen aufstellen, deren Widerlegung trivial sind, und somit provokativ interpretiert werden können.
        Daher sollten Sie sich nicht über Reaktionen jener Art wundern; denn wer in der IT arbeitet, sollte solche Dinge wissen oder wenigstens grob abschätzen können, um nicht zu solchen Aussagen zu gelangen. Andernfalls wäre derjenigen/demjenigen Inkompetenz zu unterstellen. Urmels Kommentar ist lediglich der leidliche Ausdruck Letzterer.

        Das gilt in gewisser Weise auch für Ihren Eingangskommentar, der nicht erstrebenswerte Reaktionen provoziert (hat). Darauf aufbauend eine gescheite Diskussion zu beabsichtigen, gleicht daher einem Glücksspiel und ist äußerst fahrlässig. Sie können es besser!

        • 0
          Von Urmel am Fr, 21. Juni 2019 um 13:57 #

          Ich auch, aber ich will nicht.

          0
          Von Verfluchtnochmal-05995bd7b am Fr, 21. Juni 2019 um 13:57 #

          Nur weil ihr Vögel alle nicht sinnerfassend lesen könnt?

          "laufen seit fast 10 Jahren 365/24 durch, tun genau was sie sollen ganz genau wie die Produktivserver die seit nun mehr 11 Jahren durchlaufen und dabei mehrfach ohne Downtime durch die Gegend geschoben wurden"

          Das "ohne downtime" bezieht sich explizit auf Live-Migration, nirgenda aber wirklich nirgends steht da ansatzweise was davon das keine kernel-updtes gemacht werden

          • 0
            Von blablabla233 am Fr, 21. Juni 2019 um 15:02 #

            "laufen seit fast 10 Jahren 365/24 durch, tun genau was sie sollen ganz genau wie die Produktivserver die seit nun mehr 11 Jahren durchlaufen und dabei mehrfach ohne Downtime durch die Gegend geschoben wurden"

            Bis auf die 2 sekunden Downtime :D ...love it!!!

            0
            Von klopskind am Fr, 21. Juni 2019 um 15:06 #

            Es wäre hilfreich gewesen, Sie hätten die in diesem Zusammenhang relevanteste Stelle zitiert:

            Meine Hauptmaschine [...] und die darauf laufende Backup-VM [...] laufen seit fast 10 Jahren 365/24 durch, [...]
            Das kann nur eins bedeuten: ohne Downtime.

            Das "ohne downtime" bezieht sich explizit auf Live-Migration, nirgenda aber wirklich nirgends steht da ansatzweise was davon das keine kernel-updtes gemacht werden
            Das stimmt. Aber wie migrieren Sie denn nun Ihre "Hauptmaschine", d.h. live bzw. ohne Downtime?

            Der Zusatz

            [...], [und] tun genau was sie sollen ganz genau wie die Produktivserver die seit nun mehr 11 Jahren durchlaufen und dabei mehrfach ohne Downtime durch die Gegend geschoben wurden
            macht es auch nicht besser.

            Und warum präsentieren Sie dieses hanebüchenen "Argument" eigentlich erst jetzt, nachdem dem all' Ihre anderen Argumentationslinien erschöpft sind?

            Nur weil ihr Vögel alle nicht sinnerfassend lesen könnt?
            Was lese ich da? Das muss wohl eines dieser argumentum ad hominem oder sogar ad personam in majestätisch prächtigster Reinstform sein!
            Klasse, nur weiter so! So macht man sich einen Namen!

            • 0
              Von Verfluchtnochmal-05995bd7b am Fr, 21. Juni 2019 um 15:35 #

              "laufen seit fast 10 Jahren 365/24 durch" bedeutet genau das was es aussagt, kein Shutdown weil irgendwas den Bach runter gegangen ist

              Wie ich die Hauptmaschine ohne downtime migriere? Das steht im Zwiefel gar nicht zur Debatte, aber ja auch die lässt sich minimieren, die Hälfte der RAID10 Disks in die neue Hardware, rsync der Daten, IP übernehmen, die andere Hälfte der Platten nachstecken, echte Downtime ein paar Sekunden, die ist aber wurscht weil sich Migration ohne Downtime auf Produktivserver bezog

              • 0
                Von klopskind am Fr, 21. Juni 2019 um 17:33 #

                "laufen seit fast 10 Jahren 365/24 durch" bedeutet genau das was es aussagt, kein Shutdown weil irgendwas den Bach runter gegangen ist
                Schon wieder so eine nachträglich relativierte Prämisse. Wie schleichen die sich nur immer ein?

                Aber halten wir fest: Wir sind uns darin einig, dass "laufen seit fast 10 Jahren 365/24 durch" kein Shutdown bedeutet.

                Wie ich die Hauptmaschine ohne downtime migriere? Das steht im Zwiefel gar nicht zur Debatte, [...]
                Na klar tut es das! Denn Sie haben diese Debatte mit der Frage "Was genau soll mir fehlen?" doch eigenständig provoziert (Antwort: möglicherweise Sicherheitsaktualisierungen). Damit war und bleibt es fragwürdig, wie Sie diese zustande bringen. Verfolgen Sie einfach den Diskussionsstrang bis hierher.

                [...] , aber ja auch die lässt sich minimieren, [...]
                Soll das heißen, dass Sie genau das nicht tun?

                [...] , die Hälfte der RAID10 Disks in die neue Hardware, rsync der Daten, IP übernehmen, die andere Hälfte der Platten nachstecken, [...]
                1. die Hälfte der RAID10 Disks in die neue Hardware:
                Ab dem Zeitpunkt des Abnabelns und mindestens bis zur Übernahme der IP ist der Dienst unverfügbar oder funktioniert nicht korrekt, denn Sie müssen auf die Konsistenz der Daten achten bzw. diese ggf. wiederherstellen, was ebenfalls eine Downtime nach sich zöge, wenn dies online, d.h. mit eingehangenem Dateisystem, nicht möglich wäre.

                2. rsync der Daten:
                Wozu? Die (richtigen) Datenträger im RAID10 sind doch bereits gespiegelt. Wäre es nicht viel sinnvoller, zunächst einfach die richtigen zwei Datenträger zu wechseln, da schneller? Damit würde dieser Schritt entfallen.

                3. die IP übernehmen:
                Dabei kommt es zu einer kurzen Downtime des Dienstes, außer Sie verwenden CARP o.Ä.

                4. die andere Hälfte der Platten nachstecken:
                Hier fallen ggf. Konsistenzprüfungen an, da während des Wechsels weitere Daten gelöscht oder geschrieben worden sein könnten. Kann dies online, d.h. mit eingehangenem Dateisystem stattfinden?
                Andernfalls bräuchte es eine Downtime...

                5. Das ist einfach gesagt und klingt sehr aufwändig. Hoffentlich geht bei dieser Prozedur nichts schief, sonst sind die Daten futsch!
                Machen Sie das bei jeder Sicherheitsaktualisierung? Wie häufig aktualisieren Sie?

                Von einem Profi hätte ich besseres erwartet. Aber halt, vielleicht kann man dieses Problem ja gar nicht lösen...

                [...], echte Downtime ein paar Sekunden, [...]
                Aha, also doch eine Downtime! Aber genau das wollten Sie doch mit Ihrem Verfahren verhindern. D.h. Sie haben mit Ihrem Verfahren genau nichts gewonnen! Ein Satz zuvor haben Sie noch von "ohne Downtime" gesprochen. Bravo!

                Übrigens: Nettes Eingeständnis!

                [...], die ist aber wurscht weil sich Migration ohne Downtime auf Produktivserver bezog
                Wieso ist eine Downtime der "Hauptmaschine" plötzlich "wurscht"? Es ging doch gerade nur um die Migration Ihrer "Hauptmaschine", um Sicherheitsaktualisierungen, ohne Downtime wohlbemerkt, irgendwie sicherstellen zu können!

    0
    Von blablabla233 am Do, 20. Juni 2019 um 12:34 #

    Hahaha....klar.
    Downtime ist, wenn ein/dein Dienst nicht online ist...der Grund hat damit absolut nix zutun.

    • 0
      Von Verfluchtnochmal_5987109 am Fr, 21. Juni 2019 um 01:16 #

      Bla, schreib halt das Wort nennenswert davor wenn es dir dann besser geht, die Migration selbst ist zu 100% ohne Downtime und die regulären reboots wegen kernel updates haben weder mit der migration noch mit einem Filesystem zu tun und gehören zum ganz normalen operativen Tagesgeschäft

      Und auch dafür ist je nach setup keine Downtime der Dienste zwingend notwendig! Schon mal was von clustering und load balancern gehört?

      Shared session store, node rebooted, load balancer verteilt eingehende requests in der Zwischenzeit auf die verbleibenden nodes, node wieder da, reboot des nächsten

      • 0
        Von blablabla233 am Fr, 21. Juni 2019 um 10:57 #

        Jo Clustering wird eben gemacht weil es einer einzigen maschine eben nicht moeglich ist ohne Downtime auszukommen (mainframes teilweise ausgeschlossen)
        Du vermischt die Uptime eines Dienstes mit der eines Servers, und versuchst dich damit herauszureden (je nachdem was dir gerade herausgerutscht ist, was nicht passt). Du hast geschrieben dass man einen Server (nicht virtualisiert) ohne Downtime migrieren kann und das stimmt einfach nicht.

        Wie geschrieben, im Aktienmarkt ist eine zehntelsekunde sehr wohl nennenswert, das kommt auf deine anforderungen drauf an.

        • 0
          Von Verfluchtnochmal-05995bd7b am Fr, 21. Juni 2019 um 14:26 #

          "Du hast geschrieben dass man einen Server (nicht virtualisiert) ohne Downtime migrieren kann und das stimmt einfach nicht" ist Bullshit denn wenn im selben Post schon von Backup-VM die Rede ist kannst du mit etwas Verstand davon ausgehen dass produktive Server erst recht virtualisiert sind

          Ich gehe einfach seit mindestens 2008 davon aus dass man auf barem-emntal ausser einem hypervisor nichts installiert wenn es um Server geht

          • 0
            Von blablabla233 am Fr, 21. Juni 2019 um 15:05 #

            Es gibt tausend gruende keine Virt einzusetzen. Der overpowerte kellerserver sollte jedoch virtualisiert werden (also wie bei Dir)

            • 0
              Von Verfluchtnochmal-05995bd7b am Fr, 21. Juni 2019 um 15:36 #

              Nenne mal welche, müssen nicht alle 1000 sein, Performance ist keiner und was Backups und Failover angeht macht bare-metal genau keinen Spass

              • 0
                Von blablabla233 am Sa, 22. Juni 2019 um 11:40 #

                Bumm....und gerade performance IST einer, stichwort ActianVector, Oracle, DB2
                Zugriff auf spezielle netwerkarten-funktionen die virtio nicht unterstützt werden.
                HSM's DU willst nicht dass irgendein anderer ausser deinem OS zugriff darauf hat.
                Appliance...da braucht es schlicht keine
                Cluster.....absolut sinnlos (Zones/Jails/Container machen jedoch teilweise Sinn)
                GrossesHPC....neinneinnein da ist jedes 1% performanceverlust wegeworfenes geld
                Realtime-Systeme (logisch oder?)

                und als schmankerl.....der GamingPC


                PS: Failover innerhalb der gleichen hardware macht aber auch nur begrenzt Sinn (und hat wenig mir virtualisierung zutun)

                • 0
                  Von Verfluchtnochmal-05995bd7b am Sa, 22. Juni 2019 um 16:10 #

                  Cluster absolut sinnlos?
                  GamingPC? In dem Kontext?

                  PS:
                  Wie kommst du Vollhonk auf failoer innerhalb der gleichen Hardware?
                  Da kommt der für dich sinnlose Cluster ins Spiel

                  • 0
                    Von blablabla233 am Mo, 1. Juli 2019 um 12:26 #

                    Failover wegen Update z.b nicht wegen Hardware-Ausfall.
                    Irgendwie sagt jeder deiner Saetze (Ich glaube habe ahnung hab es jedoch nicht)

        0
        Von klopskind am Fr, 21. Juni 2019 um 12:16 #

        [...], die Migration selbst ist zu 100% ohne Downtime und [...]
        Wenn man VMs oder mehrere Maschinen verwendet schon. Befindet sich das in Ihren beiden anfänglich erwähnten Szenarien im Einsatz?

        Sie hatten im Ihrem vorangehenden Kommentar behauptet, reguläres Neustarten zöge keine Downtime nach sich (s.o.). In diesem Kontext handelt es sich um ein Scheinargument, da irrelevant, weil es um den reguläres Neustarten ging, nicht um Migration.

        [...] und die regulären reboots wegen kernel updates haben weder mit der migration noch mit einem Filesystem zu tun und gehören zum ganz normalen operativen Tagesgeschäft

        Und auch dafür ist je nach setup keine Downtime der Dienste zwingend notwendig! Schon mal was von clustering und load balancern gehört?

        Verwenden Sie in beiden anfänglich beschriebenen Szenarien denn ein Setup, das ohne Downtime auskommt, d.h. Clustering oder Load-Balancing? Also auch für Ihre "Hauptmaschine"?

        Bla, schreib halt das Wort nennenswert davor wenn es dir dann besser geht, [...]
        Das ändert die Prämisse des Diskussionsausgangs entscheident. Sie behaupteten, reguläres Neustarten (4-15s in Ihrem Spezialfall; im Allgemeinen deutlich länger) zöge keine Downtime nach sich. Ganz unabhängig davon, dass der Begriff "nennenswert" sehr stark vom Kontext und dessen Anforderungen abhängt, bewerten Sie es indirekt nun auf einmal doch als eine Downtime, nur keine "nennenswerte".
        Damit haben Sie sich übrigens indirekt selbst widerlegt.

        Im Nachhinein die Prämissen zu ändern oder Aussagen zu relativieren, kann jeder. Aber die bewusst provozierten Reaktionen auch noch gereizt erwidern zu müssen, zeugt von einer Unverschämtheit sondergleichen. Sie sind unausstehlich.

        • 0
          Von Verfluchtnochmal-05995bd7b am Fr, 21. Juni 2019 um 14:00 #

          Dag mal bist du besoffen? Mein inital-Posting "laufen seit fast 10 Jahren 365/24 durch, tun genau was sie sollen ganz genau wie die Produktivserver die seit nun mehr 11 Jahren durchlaufen und dabei mehrfach ohne Downtime durch die Gegend geschoben wurden" beziht sich bei "ohne downtime" ganz klar auf Live-Migration auf neue Hardware und natürlich verwendet man virtuelle maschinen und Redundanz, davon gehe ich 2019 implizit aus, immer

          • 0
            Von blablabla233 am Fr, 21. Juni 2019 um 15:08 #

            Korrektur 365/23.98

            0
            Von klopskind am Fr, 21. Juni 2019 um 15:29 #

            Sie zitieren nicht die relevante Stelle. Sie schrieben:

            Meine Hauptmaschine [...] und die darauf laufende Backup-VM [...] laufen seit fast 10 Jahren 365/24 durch, [...]
            Das kann nur eins bedeuten: ohne Downtime.

            Außerdem sind sie meiner ernstgemeinten, nicht rhetorischen Frage ausgewichen:

            Verwenden Sie in beiden anfänglich beschriebenen Szenarien denn ein Setup, das ohne Downtime auskommt, d.h. Clustering oder Load-Balancing? Also auch für Ihre "Hauptmaschine"?
            Also wie bewerkstelligen Sie denn nun die Sicherheitsaktualisierungen für Ihre "Hauptmaschine"? Live-Patching, Clustering, Load-Balancing oder sonstige Redundanzen? Oder ist Ihre "Hauptmaschine" auch virtualisiert, d.h. für Live-Migration geeignet?

            [...] und natürlich verwendet man virtuelle maschinen und Redundanz, davon gehe ich 2019 implizit aus, immer
            Schön für Sie! Vielleicht wäre es ratsam, Sie würden in Zukunft weniger Annahmen treffen, oder aber diese wenigstens vorab kommunizieren, wenn Sie mit unbekannten Personen in Disput treten; und insbesondere keine falschen, wie z.B. geplante Unverfügbarkeit ist keine Downtime.

            Dag mal bist du besoffen?
            Alles kein Grund so ausfallend zu werden...

            • 0
              Von Verfluchtnochmal-05995bd7b am Fr, 21. Juni 2019 um 15:40 #

              Wo impliziert für dich 365/24 durchlaufen keinen Reboot wegen Kernel-Updates? Färhst du deine Systeme nach einem Kernel-Update runter, zählst bis 5 und schaltest sie dann wieder ein und wenn ja warum?

              Es ging lediglich darum dass ext4 auf RAID10 wohl sauber und stabil genug ist um über Jahre ohne Probleme zu laufen und dass man Platten einfach im Betrieb tauschen kann weswegen ich die Frage stellte was mir denn genau fehlen soll nur weil ich kein one-man-show Fileystem oder ZFS habe?

              • 0
                Von Cascavel am Fr, 21. Juni 2019 um 17:29 #

                Ein in die Enge getriebener ertappter Lügner stammelt vor sich hin.....?

                0
                Von klopskind am Fr, 21. Juni 2019 um 18:13 #

                Wo impliziert für dich 365/24 durchlaufen keinen Reboot wegen Kernel-Updates?
                Das haben wir bereits zu genüge diskutiert. Und ein Neustart bleibt Neustart, weswegen ist in diesem Disput nicht primär relevant.

                Außerdem haben Sie nach langem Ringen doch schon zugegeben, dass dieser Ausdruck kein Neustarten impliziert.
                Ihr ambivalente Verhalten führt mich zu dem gut gemeinten Ratschlag, den Facharzt zu konsultieren.

                Färhst du deine Systeme nach einem Kernel-Update runter, zählst bis 5 und schaltest sie dann wieder ein und wenn ja warum?
                Netter rhetorischer Trick, aber das steht nicht zur Debatte.

                Ohne Live-Patching sind Aktualisierungen des Kernels wirkungslos, da dieser nicht geladen wurde, insbesondere also nicht die enthaltenen Fehlerkorrekturen.

                Es ging lediglich darum dass ext4 auf RAID10 wohl sauber und stabil genug ist um über Jahre ohne Probleme zu laufen [...]
                Sie ändern wieder die Prämisse und relativeren. Mit der Frage "Was genau soll mir fehlen?" haben Sie der Leserschaft freigestellt, worum es hier gehen soll. Es ist nicht verwunderlich, dass davon Gebrauch gemacht wurde/wird.
                Jetzt versuchen Sie sich mit allen billigen Tricks und Mitteln irgendwie wieder da herauszuwinden - bisher mit kläglichem Erfolg.

                [...] und dass man Platten einfach im Betrieb tauschen kann [...]
                Davon steht nichts in Ihrem Eingangskommentar.

                [...] weswegen ich die Frage stellte was mir denn genau fehlen soll nur weil ich kein one-man-show Fileystem oder ZFS habe?
                Die Einwände kritisieren in großen Teilen nicht Ihre Wahl des Dateisystems. Sie sind vielfältiger Natur, da Sie es mit Ihrer Frage nicht nur zugelassen, sondern sogar provoziert haben. Deswegen haben Sie kein Recht, sich im Nachhinein über die Art der Einwände zu echauffieren.

                Sie stellten diese Frage und öffneten _jedem_ Einwand Tür und Tor. Dann müssen Sie sich nicht wundern, dass hier Dinge zur Debatte gestellt werden, die Sie nicht debattieren wollten. Und falls Sie tatsächlich Letzteres gewollt hättem, so hätten Sie die Frage entweder gar nicht erst stellen dürfen, oder aber einfach nicht weiter auf die Einwände reagiert. Stattdessen haben Sie die Wahl des Disputs gewählt. Now deal with it like an adult!

                • 0
                  Von Verfluchtnochmal_5987109 am Fr, 21. Juni 2019 um 19:30 #

                  Die lächerlichern Einwände gehen alle samt an der Grundaussage vorbei und geilen sich alle am zweiten Halbsatz auf der eine völlig andere Umgebung als der erste Teil anspricht

                  • 0
                    Von klopskind am Sa, 22. Juni 2019 um 00:14 #

                    Das sehen scheinbar nur Sie selbst so.

                    Lächerlich würde ich die Einwände jedenfalls nicht bezeichnen. Und es gibt einen erheblichen Teil, der nicht an "der Grundaussage"® vorbei geht.

                    Mit Verlaub, die einzige Person, die sich hier an irgendetwas aufgeilt, sind Sie. Geben Sie Bescheid, falls Sie Hilfe beanspruchen möchten!

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung