Virtualisierung ist ja eine super Sache und ich bin inzwischen richtig Fan von KVM/libvirt. Um aber eine wirklich Leistungsfaehige Umgebung zu bauen (ca. 10 Server) hat man aber fast keine Chance als Kleininvestor. Klar hat man schnell viel RAM und Multi-Core-CPUs zur Hand und diese kosten auch sehr wenig. Was aber immer das Hauptargument gegen Virtualisierung ist/war, ist Storage. Ohne SAN macht der Disk-I/O einfach keinen Spass. Dieses kostet dann aber wieder ein mehrfaches der ganzen Server-Infrastruktur. Koennte man mit GlusterFS und ein paar anstaendigen Hosts (gebraucht PCs mit mehr oder weniger aktuelle CPU, SATA-Platten, Gigabit Ethernet) sowas kostenguenstig bauen und wenn noetig dann auch ausbauen?
Oder ist das ganze eher auf Ausfallsicherheit und weniger auf Geschwindigkeit optimiert? Gibt es denn irgendwo so ein aehnliches Szenario nachzulesen? Ich finde immer nur beispiele wo a) Storage lokal ist oder b) Sauteure Disk-Infrastruktur verwendet wird.
Von Virtualisierungsprofi am Mi, 5. Oktober 2011 um 13:13 #
Sämtliche Cluster- oder Cloud Storagelösungen sind allerdings auch kein Allheilmittel, wenn die Hardware im Backend nicht stimmt (schnelles Speichernetzwerk wie 10GB Ethernet/Fiberchannel/Infiniband und entsprechend schnelle Speichermedien wie SAS/SSD). Oder anderst herum: Ein Storagepool aus 20 billigen Desktoprechnern mit 2x1TB SATA HDD in RAID0 ersetzen noch lange nicht den Netapp-Server
Von Virtualisierungsprofi am Mi, 5. Oktober 2011 um 12:57 #
Moin,
irgendwie wirfst du aus meiner Sicht mehrere Dinge durcheinander.
>Um aber eine wirklich Leistungsfaehige Umgebung zu bauen (ca. 10 Server) >hat man aber fast keine Chance als Kleininvestor. Öhm... 1) Nicht jede Anwendung taugt zur Virtualisierung bzw. nicht bei jeder Anwendung mit profitiert von den Vorzügen von Virtualisierungslösungen. Dies trifft nach meiner unwesentlichen Erfahrung häufig auf Anwendungen mit viel I/O (Disk- und/oder Netzwerk) zu. Mit paravirtualisierten Treibern (Virtio) kann man Einiges rausholen, aber ein gewisser Schwund bleibt immer. Dies trifft z.B. auf Datenbankserver zu. Eventuell (je nach Lastszenario) kann dieser Verlust tw. durch schnelle(re) HDDs ausgeglichen werden oder fällt nicht groß ins Gewicht. Was davon zutrifft kann nur eine entsprechend realitätsnahe Evaluierung zeigen.
2) Wenn ich z.B. 10 Server mit unterschiedlichen Anwendungen konsolidiere, dann braucht meine Virtualisierungsplatform mindestens die Ressourcen (RAM, CPU, I/O) wie alle 10 Server in der Summe unter Maximallast. Das Ganze eventuell mal Faktor 1.X wegen der Verluste durch Virtualisierung.
Wenn ich also 10 Server konsolidieren möchte (im Sinne weniger Blech), dann muss das neue Blech eben entsprechend Leistung haben. Das neue Blech kostet eben bis zu einem gewissen Faktor ähnlich viel wie die 10 physikalischen Server eben auch. Von daher verstehe ich deinen Kommentar mit dem Kleininvestor nicht.
>Was aber immer das Hauptargument gegen Virtualisierung ist/war, ist Storage. Siehe Punkt 2) -> I/O-Performance des VM-Hosts = mindestens Summe aller I/O der Einzelserver bei Volllast.
>Ohne SAN macht der Disk-I/O einfach keinen Spass. Sagt wer ? Im mittleren Performancebereich kann man selbst mit schnellen SATA-Platten an einem entsprechenden Raidcontroller (oder mit Software RAID) ordentlichen Durchsatz erzielen. SAS oder gar SSD wären die anderen Alternativen mit entsprechender Performance pro Mehrpreis.
Bei lokalem versus zentralem Storage (SAN / NAS) ist aus meiner Sicht bei Virtualisierungssicht keinen Gewinner. Beide Szenarien haben Vor- und Nachteile. Ein RAID-Array aus schnellen Sataplatten kann bei zwei bis drei Virtualisierungsservern deutlich billiger sein als ein redundantes SAN mit gleicher Nettokapazität.
Redundanz kann man auch bei lokalem Storage über Clusterfilesysteme oder verteilte Blockdevices schaffen.
Für KVM sind noch ganz andere Lösungen wie Sheepdog interessant.
>Oder ist das ganze eher auf Ausfallsicherheit und weniger auf Geschwindigkeit optimiert? Hm, das "ganze" ist für das Szenario "optimiert" für das du es auslegst.
>Gibt es denn irgendwo so ein aehnliches Szenario nachzulesen? >Ich finde immer nur beispiele wo a) Storage lokal ist oder >b) Sauteure Disk-Infrastruktur verwendet wird. Ein Kompromiss aus lokalem Storage, "normalen" Festplatten und normaler Hardware könnte für zwei Knoten so aussehen: Repliziertes lokales Storage mit 8 SATA Festplatten im RAID pro Host (per DRBD) bei Nutzung eines dedizierten Storage Netzwerkes mit 10GBit Das Ganze mit zwei schnellen 8-12 Kern-Servern aufgebaut dürfte im KMU Bereich einen Großteil der Anwendungsszenarien abdecken YMMV
Virtualisierung ist ja eine super Sache und ich bin inzwischen richtig Fan von KVM/libvirt. Um aber eine wirklich Leistungsfaehige Umgebung zu bauen (ca. 10 Server) hat man aber fast keine Chance als Kleininvestor.
Klar hat man schnell viel RAM und Multi-Core-CPUs zur Hand und diese kosten auch sehr wenig. Was aber immer das Hauptargument gegen Virtualisierung ist/war, ist Storage.
Ohne SAN macht der Disk-I/O einfach keinen Spass. Dieses kostet dann aber wieder ein mehrfaches der ganzen Server-Infrastruktur.
Koennte man mit GlusterFS und ein paar anstaendigen Hosts (gebraucht PCs mit mehr oder weniger aktuelle CPU, SATA-Platten, Gigabit Ethernet) sowas kostenguenstig bauen und wenn noetig dann auch ausbauen?
Oder ist das ganze eher auf Ausfallsicherheit und weniger auf Geschwindigkeit optimiert? Gibt es denn irgendwo so ein aehnliches Szenario nachzulesen?
Ich finde immer nur beispiele wo a) Storage lokal ist oder b) Sauteure Disk-Infrastruktur verwendet wird.
am besten etwas warten anfang november kommt ovirt ( http://www.ovirt.org/ ) vielleicht ist der connector von gluster schon drin :-).
Sämtliche Cluster- oder Cloud Storagelösungen sind allerdings auch kein Allheilmittel, wenn die Hardware im Backend nicht stimmt (schnelles Speichernetzwerk wie 10GB Ethernet/Fiberchannel/Infiniband und entsprechend schnelle Speichermedien wie SAS/SSD).
Oder anderst herum: Ein Storagepool aus 20 billigen Desktoprechnern mit 2x1TB SATA HDD in RAID0 ersetzen noch lange nicht den Netapp-Server
Moin,
irgendwie wirfst du aus meiner Sicht mehrere Dinge durcheinander.
>Um aber eine wirklich Leistungsfaehige Umgebung zu bauen (ca. 10 Server)
>hat man aber fast keine Chance als Kleininvestor.
Öhm...
1) Nicht jede Anwendung taugt zur Virtualisierung bzw. nicht bei jeder Anwendung mit profitiert von
den Vorzügen von Virtualisierungslösungen. Dies trifft nach meiner unwesentlichen Erfahrung häufig
auf Anwendungen mit viel I/O (Disk- und/oder Netzwerk) zu. Mit paravirtualisierten Treibern (Virtio)
kann man Einiges rausholen, aber ein gewisser Schwund bleibt immer. Dies trifft z.B. auf Datenbankserver
zu. Eventuell (je nach Lastszenario) kann dieser Verlust tw. durch schnelle(re) HDDs ausgeglichen werden
oder fällt nicht groß ins Gewicht. Was davon zutrifft kann nur eine entsprechend realitätsnahe Evaluierung
zeigen.
2) Wenn ich z.B. 10 Server mit unterschiedlichen Anwendungen konsolidiere, dann braucht meine Virtualisierungsplatform
mindestens die Ressourcen (RAM, CPU, I/O) wie alle 10 Server in der Summe unter Maximallast. Das Ganze eventuell mal
Faktor 1.X wegen der Verluste durch Virtualisierung.
Wenn ich also 10 Server konsolidieren möchte (im Sinne weniger Blech), dann muss das neue Blech eben entsprechend
Leistung haben. Das neue Blech kostet eben bis zu einem gewissen Faktor ähnlich viel wie die 10 physikalischen
Server eben auch. Von daher verstehe ich deinen Kommentar mit dem Kleininvestor nicht.
>Was aber immer das Hauptargument gegen Virtualisierung ist/war, ist Storage.
Siehe Punkt 2) -> I/O-Performance des VM-Hosts = mindestens Summe aller I/O der Einzelserver bei Volllast.
>Ohne SAN macht der Disk-I/O einfach keinen Spass.
Sagt wer ? Im mittleren Performancebereich kann man selbst mit schnellen SATA-Platten an einem entsprechenden Raidcontroller (oder mit Software RAID) ordentlichen Durchsatz erzielen.
SAS oder gar SSD wären die anderen Alternativen mit entsprechender Performance pro Mehrpreis.
Bei lokalem versus zentralem Storage (SAN / NAS) ist aus meiner Sicht bei Virtualisierungssicht keinen Gewinner. Beide Szenarien haben Vor- und Nachteile.
Ein RAID-Array aus schnellen Sataplatten kann bei zwei bis drei Virtualisierungsservern deutlich billiger sein als ein redundantes SAN mit gleicher Nettokapazität.
Redundanz kann man auch bei lokalem Storage über Clusterfilesysteme oder verteilte Blockdevices schaffen.
Für KVM sind noch ganz andere Lösungen wie Sheepdog interessant.
>Oder ist das ganze eher auf Ausfallsicherheit und weniger auf Geschwindigkeit optimiert?
Hm, das "ganze" ist für das Szenario "optimiert" für das du es auslegst.
>Gibt es denn irgendwo so ein aehnliches Szenario nachzulesen?
>Ich finde immer nur beispiele wo a) Storage lokal ist oder
>b) Sauteure Disk-Infrastruktur verwendet wird.
Ein Kompromiss aus lokalem Storage, "normalen" Festplatten und normaler Hardware könnte für zwei Knoten so aussehen:
Repliziertes lokales Storage mit 8 SATA Festplatten im RAID pro Host (per DRBD) bei Nutzung eines dedizierten Storage Netzwerkes mit 10GBit
Das Ganze mit zwei schnellen 8-12 Kern-Servern aufgebaut dürfte im KMU Bereich einen Großteil der Anwendungsszenarien abdecken
YMMV