Abo
  1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Fusion-io: Ioscale soll…

Für Virtualisierung leider ungeeignet.

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Für Virtualisierung leider ungeeignet.

    Autor: 1st1 16.01.13 - 17:46

    Weder von VMWare zertifiziert, noch macht es Sinn die Dinger direkt in den VMWare-Hoste einzubauen, da damit keine Live-Migration von VMs zwischen den VMWare-Hosts möglich ist. Also lokaler Speicher im VMWare-Host wären das die sprichwörtlichen Perlen vor die Säue.

    Einzige Möglichkeit wäre eine separate Storage-Appliance damit zu bauen, und die per FC an die Hosts dran zu hängen, evtl. mit VMWare VSA, aber wer zertifiziert einem so ein System, dass wenn Support nötig ist, dass VMWare das auch supportet? Und außerdem wäre da dann das FC-Interface der Bottleneck, selbst wenn man mehrere Kanäle bündelt.

    Das selbe gillt auch für Citrix und HyperV-Umgebungen.

    Daher für Virtualisierung leider ungeeignet. Aber gerade hier wäre es im High-Perofmance-Bereich interessant.

  2. Re: Für Virtualisierung leider ungeeignet.

    Autor: Neuro-Chef 16.01.13 - 18:28

    1st1 schrieb:
    > Weder von VMWare zertifiziert, noch macht es Sinn die Dinger direkt in den
    > VMWare-Hoste einzubauen, da damit keine Live-Migration von VMs zwischen den
    > VMWare-Hosts möglich ist. Also lokaler Speicher im VMWare-Host wären das
    > die sprichwörtlichen Perlen vor die Säue.
    Ich würde meinen das hängt von der Anwendung ab. Wenn man flinken Zugriff braucht und mit enormen Datenmengen hantiert, könnte sich das gegenüber HDDs eventuell lohnen. Oder meinst du im Vergleich mit konventionell angeschlossen SSDs?
    Zur Live-Migration: Sollte die Art des Speichers der Software nicht relativ egal sein, inwiefern sollte das nicht funktionieren?

    » Niemand ist vollkommen, aber irre sind ganz sicher viele. «

    ಠ_ಠ

  3. Re: Für Virtualisierung leider ungeeignet.

    Autor: DeaD_EyE 16.01.13 - 19:45

    1st1 schrieb:
    --------------------------------------------------------------------------------
    >
    > Einzige Möglichkeit wäre eine separate Storage-Appliance damit zu bauen,
    > und die per FC an die Hosts dran zu hängen, evtl. mit VMWare VSA, aber wer
    > zertifiziert einem so ein System, dass wenn Support nötig ist, dass VMWare
    > das auch supportet?

    Ich kenne mich mit VM recht wenig aus. Ist es notwendig alles Zertifizieren zu lassen? Was spricht gegen ein System, dass einfach als Storage arbeitet und in VMWare eingebunden wird? Aber ich kann es mir schon denken: Es geht dabei wahrscheinlich um Haftung, Support und KnowHow.

  4. Re: Für Virtualisierung leider ungeeignet.

    Autor: Boeby 16.01.13 - 20:06

    Neuro-Chef schrieb:
    --------------------------------------------------------------------------------
    > 1st1 schrieb:
    > > Weder von VMWare zertifiziert, noch macht es Sinn die Dinger direkt in
    > den
    > > VMWare-Hoste einzubauen, da damit keine Live-Migration von VMs zwischen
    > den
    > > VMWare-Hosts möglich ist. Also lokaler Speicher im VMWare-Host wären das
    > > die sprichwörtlichen Perlen vor die Säue.
    > Ich würde meinen das hängt von der Anwendung ab. Wenn man flinken Zugriff
    > braucht und mit enormen Datenmengen hantiert, könnte sich das gegenüber
    > HDDs eventuell lohnen. Oder meinst du im Vergleich mit konventionell
    > angeschlossen SSDs?
    > Zur Live-Migration: Sollte die Art des Speichers der Software nicht
    > relativ egal sein, inwiefern sollte das nicht funktionieren?

    Live-Migration ist wenn eine VM von einem shared-Storage von einem Host auf einen anderen Host migriert wird, im laufenden Betrieb. Da diese Festplatte nicht shared ist, ist eine einfache LiveMigration auch nicht so einfach möglich. Ausser du verschiebst zeitgleich noch den Storage, was aber sehr performance kosten wird (falls das bereits im Zuge einer Vmotion möglich ist)

  5. Re: Für Virtualisierung leider ungeeignet.

    Autor: Neuro-Chef 16.01.13 - 20:18

    Boeby schrieb:
    > Live-Migration ist wenn eine VM von einem shared-Storage von einem Host auf
    > einen anderen Host migriert wird, im laufenden Betrieb.
    So dachte ich mir das schon, natürlich müsste man die Teile dann im Storage einbauen - was bei gängigen Storage-Systemen nicht gehen mag, ok. Sich dafür selbst einen Server zu bauen würden wohl nicht viele wollen.
    Dennoch leigt das Problem hier ja beim Storage, nicht bei SSDs oder VMs. SSDs mit SATA/SAS-Anschlüssen sollten dann ja gehen, bei ebenfalls deutlichem Performance-Gewinn.
    Es fehlen also wenn ich das jetzt richtig verstehe nur Shared-Storage-Systeme, die sowas hier unterstützen. Kommt schon noch.

    » Niemand ist vollkommen, aber irre sind ganz sicher viele. «

    ಠ_ಠ

  6. Re: Für Virtualisierung leider ungeeignet.

    Autor: malo 17.01.13 - 06:55

    ...schade wenn man keine Ahnung hat und trotzdem sich im Forum ausbreiten muss. Wäre schön wenn Du vorher mal ein paar Fachartikel wenigstens zu dem Thema lesen würdest.
    (bezogen auf den Eintrag von Autor Neuro-Chef 16.01.13 - 20:18)



    1 mal bearbeitet, zuletzt am 17.01.13 06:56 durch malo.

  7. Re: Für Virtualisierung leider ungeeignet.

    Autor: Neuro-Chef 17.01.13 - 10:49

    malo schrieb:
    > ...schade wenn man keine Ahnung hat und trotzdem sich im Forum ausbreiten
    > muss.
    Du hast Recht, damit kenne ich mich nicht aus. Allerdings finde ich es interessant, deshalb verwende ich Formulierungen wie "dachte ich" und "wenn ich das jetzt richtig verstehe" - subtile Ausdrucksweise für "bitte um Erklärung".

    >Wäre schön wenn Du vorher mal ein paar Fachartikel wenigstens zu dem
    > Thema lesen würdest.
    Wäre schön, wenn du mir einen empfehlen könntest :-)
    Ich bin ja auch manchmal genervt, wenn Leute Unsinn posten weil sie keine Ahnung haben. Entweder korrigiere ich sie dann (sie könnten ja etwas dazulernen wollen) oder antworte erst garnicht. Einzig und Allein auf die Ahnungslosigkeit hinzuweisen ist mit Sicherheit fruchtlos, wenn auch ggf. berechtigt.

    Schöne Grüße.

    » Niemand ist vollkommen, aber irre sind ganz sicher viele. «

    ಠ_ಠ

  8. Re: Für Virtualisierung leider ungeeignet.

    Autor: lokidiabel 17.01.13 - 12:53

    Stimmt, von VMware Zertifiziert ist die Technik "noch" nicht. Aber HA geht damit dennoch. Man braucht halt nur das auf DRBD basierende Addon von VMware.

    Einfach ausgedrückt macht man damit ein Raid über alle ESX Server und nutzt den localen storage als ziel für ein Cluster FS.

    Hoffe das hilft dir weiter.

    Gruß

    Neuro-Chef schrieb:
    --------------------------------------------------------------------------------
    > malo schrieb:
    > > ...schade wenn man keine Ahnung hat und trotzdem sich im Forum
    > ausbreiten
    > > muss.
    > Du hast Recht, damit kenne ich mich nicht aus. Allerdings finde ich es
    > interessant, deshalb verwende ich Formulierungen wie "dachte ich" und "wenn
    > ich das jetzt richtig verstehe" - subtile Ausdrucksweise für "bitte um
    > Erklärung".
    >
    > >Wäre schön wenn Du vorher mal ein paar Fachartikel wenigstens zu dem
    > > Thema lesen würdest.
    > Wäre schön, wenn du mir einen empfehlen könntest :-)
    > Ich bin ja auch manchmal genervt, wenn Leute Unsinn posten weil sie keine
    > Ahnung haben. Entweder korrigiere ich sie dann (sie könnten ja etwas
    > dazulernen wollen) oder antworte erst garnicht. Einzig und Allein auf die
    > Ahnungslosigkeit hinzuweisen ist mit Sicherheit fruchtlos, wenn auch ggf.
    > berechtigt.
    >
    > Schöne Grüße.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Ratbacher GmbH, Großraum Melsungen
  2. Deutsche Telekom AG, Bonn, Trier, Saarbrücken, Münster
  3. Deutsche Bundesstiftung Umwelt, Osnabrück
  4. T-Systems International GmbH, Leinfelden-Echterdingen, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kryptowährungen: Bitcoin steht vor grundlegenden Änderungen
Kryptowährungen
Bitcoin steht vor grundlegenden Änderungen
  1. Drogenhandel Weltweit größter Darknet-Marktplatz Alphabay ausgehoben
  2. Kryptowährungen Massiver Diebstahl von Ether
  3. Kryptowährung Bitcoin notiert auf neuem Rekordhoch

Indiegames Rundschau: Meisterdiebe, Anti- und Arcadehelden
Indiegames Rundschau
Meisterdiebe, Anti- und Arcadehelden
  1. Jump So was wie Netflix für Indiegames
  2. Indiegames-Rundschau Weltraumabenteuer und Strandurlaub
  3. Indiegames-Rundschau Familienflüche, Albträume und Nostalgie

IETF Webpackage: Wie das Offline-Internet auf SD-Karte kommen könnte
IETF Webpackage
Wie das Offline-Internet auf SD-Karte kommen könnte
  1. IETF DNS wird sicher, aber erst später
  2. IETF Wie TLS abgehört werden könnte
  3. IETF 5G braucht das Internet - auch ohne Internet

  1. Counter-Strike Go: Bei Abschuss Ransomware
    Counter-Strike Go
    Bei Abschuss Ransomware

    Wie gut ist es eigentlich um die Security von Spielen bestellt? Der Sicherheitsforscher Justin Taft wollte es herausfinden und wurde in der Source-Engine fündig. Nach einem Abschuss droht bei seiner modifizierten Karte die Infektion mit Ransomware oder anderer Schadsoftware.

  2. Hacking: Microsoft beschlagnahmt Fancy-Bear-Infrastruktur
    Hacking
    Microsoft beschlagnahmt Fancy-Bear-Infrastruktur

    Um gegen die Hackergruppe Fancy Bear vorzugehen, nutzt Microsoft das Markenrecht und beschlagnahmt Domains. Die kriminellen Aktivitäten der Gruppe würden "die Marke und den Ruf" des Unternehmens schädigen. Komplett stoppen lassen sich die Aktivitäten aber auch auf diesem Wege nicht.

  3. Die Woche im Video: Strittige Standards, entzweite Bitcoins, eine Riesenkonsole
    Die Woche im Video
    Strittige Standards, entzweite Bitcoins, eine Riesenkonsole

    Golem.de-Wochenrückblick Beim IETF-Meeting in Prag wird hitzig über Internet-Standards diskutiert, bei Bitcoin stehen umstrittene Änderungen an und wir programmieren eine Spielkonsole. Sieben Tage und viele Meldungen im Überblick.


  1. 12:43

  2. 11:54

  3. 09:02

  4. 16:55

  5. 16:33

  6. 16:10

  7. 15:56

  8. 15:21