Noch schlauere Leute als du haben mittlerweile auch herausgefunden, dass rein zentralistische Storage Architekturen nicht immer die geilste Lösung sind.
- Single Point of Failure - Vendor Lockin - Auch bei redundanten Lösungen kann ein Amok laufender Patch alles still legen (schon bei uns im RZ gehabt, wo die Webseite gehostet wird).
Aus meiner Sicht geht der Trend eher in die andere Richtung als Mischform. Halt Objekt-based Storage verteilt über viele Knoten mit Commodity Hardware.
Von Urs Pfister2 am So, 4. Dezember 2016 um 00:37 #
Ich sehe jetzt kein Vendor Lock bei Open Source, ich sehe bei DRBD auch kein Single Point of Failure.
Die 'grossen' Daten liegen bei mir, also möchte ich die Rechner ganz bestimmt nicht in der Cloud haben. An der Leitung mit öffentlicher IP kanns nicht liegen, das kostet heute sehr sehr wenig, die Open Source Firewall hilft wohl besser abzuschotten, als eine jede Cloud, wo ich noch nicht mal weiss, was die Anbieter da mixen (dies alleine ist doch Single Point of Failure, ich kann es grad gar nicht beeinflussen). Ich möchte auch nicht mit 99 Prozent Verfügbarkeit extern leben müssen, sondern entscheide gerne selber, wann wo und wie es läuft, und übernehme dafür auch gerne die Verantwortung.
Und sag mir mal bitte, wie ich Betriebssysteme, die wir bauen, als Objekt-based Storage führen soll? Ich bau die Betriebssystem nun sehr schlank (ArchivistaMini braucht keine 80 MByte), aber die anderen Produkte mit all den gewünschten Applikationen (LibreOffice alleine 'frisst' 500 MByte), das geht unter ein paar GByte leider nicht. Und da ist es doch praktisch zu wissen, dass ich die Daten mit nfs/drbd im Nu auf andere Rechner kiege.
Ich spiele auch keine Patches ein, sondern die neu gebauten ISO wandern in die Testumgebung, und erst wenn es dort ok ist, geht es auf die Produktivmaschinen. Dabei könnte es vor und zurückgehen (letzteres war bisher nicht wirklich notwendig). Ich könnte es aber, da meine Debian-Linuxe im RAM laufen. Booten ab alter ISO, und ich bin wieder zurück. Mit all diesen Features habe ich in der Cloud keine Chancen.
Commodity-Hardware verwenden wir noch so gerne, alle Messungen erfolgten genau mit solcher Hardware. Die Messungen sind/waren Bestandteil meines Vortrages:
Du aber meinst noch immer, ich würde rein zentralistische Storage-Architekturen aufbauen, dabei mach ich gerade das nicht. Allerdings, ein Image einer Distro ist und bleibt ein Image. Und die Kundeninstallation z.B. in der Form eines ERP-Systems liegt auch in einem Image, da ist es doch verdammt praktisch, wenn ich solche Gäste in ein paar Sekunden zügle, anstatt mit rsync viele Minuten bis Stunden zu warten.
Und ja, offen gestanden interessieren mich Trends nicht mehr wahnsinnig. Da ist in den letzten 20 Jahren schon so viel gekommen und gegangen. Die Wolke wird weiterziehen, da bleib ich gerne auf dem Boden -- und messe dann auch immer mal wieder.
Noch schlauere Leute als du haben mittlerweile auch herausgefunden, dass rein zentralistische Storage Architekturen nicht immer die geilste Lösung sind.
- Single Point of Failure
- Vendor Lockin
- Auch bei redundanten Lösungen kann ein Amok laufender Patch alles still legen (schon bei uns im RZ gehabt, wo die Webseite gehostet wird).
Aus meiner Sicht geht der Trend eher in die andere Richtung als Mischform. Halt Objekt-based Storage verteilt über viele Knoten mit Commodity Hardware.
Ich sehe jetzt kein Vendor Lock bei Open Source, ich sehe bei DRBD auch kein Single Point of Failure.
Die 'grossen' Daten liegen bei mir, also möchte ich die Rechner ganz bestimmt nicht in der Cloud haben. An der Leitung mit öffentlicher IP kanns nicht liegen, das kostet heute sehr sehr wenig, die Open Source Firewall hilft wohl besser abzuschotten, als eine jede Cloud, wo ich noch nicht mal weiss, was die Anbieter da mixen (dies alleine ist doch Single Point of Failure, ich kann es grad gar nicht beeinflussen). Ich möchte auch nicht mit 99 Prozent Verfügbarkeit extern leben müssen, sondern entscheide gerne selber, wann wo und wie es läuft, und übernehme dafür auch gerne die Verantwortung.
Und sag mir mal bitte, wie ich Betriebssysteme, die wir bauen, als Objekt-based Storage führen soll? Ich bau die Betriebssystem nun sehr schlank (ArchivistaMini braucht keine 80 MByte), aber die anderen Produkte mit all den gewünschten Applikationen (LibreOffice alleine 'frisst' 500 MByte), das geht unter ein paar GByte leider nicht. Und da ist es doch praktisch zu wissen, dass ich die Daten mit nfs/drbd im Nu auf andere Rechner kiege.
Ich spiele auch keine Patches ein, sondern die neu gebauten ISO wandern in die Testumgebung, und erst wenn es dort ok ist, geht es auf die Produktivmaschinen. Dabei könnte es vor und zurückgehen (letzteres war bisher nicht wirklich notwendig). Ich könnte es aber, da meine Debian-Linuxe im RAM laufen. Booten ab alter ISO, und ich bin wieder zurück. Mit all diesen Features habe ich in der Cloud keine Chancen.
Commodity-Hardware verwenden wir noch so gerne, alle Messungen erfolgten genau mit solcher Hardware. Die Messungen sind/waren Bestandteil meines Vortrages:
https://fileshare.lugv.at/public/LinuxDay_2016/raum_104/archivistavm-cloud.pdf
Du aber meinst noch immer, ich würde rein zentralistische Storage-Architekturen aufbauen, dabei mach ich gerade das nicht. Allerdings, ein Image einer Distro ist und bleibt ein Image. Und die Kundeninstallation z.B. in der Form eines ERP-Systems liegt auch in einem Image, da ist es doch verdammt praktisch, wenn ich solche Gäste in ein paar Sekunden zügle, anstatt mit rsync viele Minuten bis Stunden zu warten.
Und ja, offen gestanden interessieren mich Trends nicht mehr wahnsinnig. Da ist in den letzten 20 Jahren schon so viel gekommen und gegangen. Die Wolke wird weiterziehen, da bleib ich gerne auf dem Boden -- und messe dann auch immer mal wieder.