Umgebung:
12 vSphere 5.1 Knoten
Ein IBM SVC Cluster mit zwei Plattenpools (20TB mit 10k Platten + 30TB mit 7,2k Platten)
Wir haben die Pools in je ca. 4TB LUNs geteilt und in VM-Ware in zwei Storage Cluster mit eingeschaltetem Storage DRS eingebunden.
Wir haben einige VMs mit mehr als 2TB Platzbedarf, was uns die Verwaltung des freien Platzes immer wieder erschwert. Ich hätte am liebsten pro Plattentype im VM einen Pool, den sich alle VMs teilen. Durch Thin Provisionierung in VM-Ware und im SVC verliert man dadurch schnell den Überblick, wie viel Platz wo wirklich noch frei ist.
Man kann hier immer wieder was lesen von zu wenig LUNs und damit Queues und Locks usw. Gibt es mit ESX 5.1 oder 5.5 eine Möglichkeit dieses Problem zu umgehen?
kann ich nicht einfach beide Pools vom SVC in zwei VM Datenspeicher verbinden und nur in VM-Ware Thin Provisionierung nutzen? Wie machen das die großen Rechenzentren?
MfG Bals
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Verwaltung der Datastores in VM-Ware
SDRS bietet dir die Möglichkeit VMDKs von VMs über Datastores zu verteilen. Per Default versucht SDRS die VMDKs einer VM zusammenzuhalten. Du hast also die Möglichkeit hier einzugreifen. Des Weiteren solltest du dir Thin-Provisioning aus zwei Gründen sehr gut überlegen:
- Management
- Performance
Wie du selber festgestellt hast, kann es durchaus ein Problem sein TP auf VM Ebene zu nutzen, da man damit wunderbar Datastores überbuchen kann. Den Performanceverlust wirst du bei I/O armen VMs kaum merken, bei I/O intensiven VMs zumindest dann, wenn diese dauerhaft Speicher allokieren, vor allem in kleinen Schritten (bei TP sind zwei Schritte notwendig: Block allokieren, Block nullen). Zudem liegen die Daten damit verteilt über mehrere Stripes etc.
Jede LUN hat ihre eigene LUN Queue Depth. Locking ist heute weniger ein Problem. Aber deswegen auf die Idee zu kommen einen oder zwei große Datastores zu bauen, ist nicht gut. An dieser Stelle verweise ich gerne auf den exzellenten Artikel von Jason Boche.
Tja, wie machen das andere Firmen... mal so, mal so. Ich sehe immer wieder Kunden, die eine von zwei Extremformen nutzen: Wenige, extrem große Datastores (es wurde ja immer wieder gebettelt, dass man DS mit mehr als 2 TB bauen möchte) und dem anderen Extrem ein DS pro VM. Beides ist Murks. Die Wahrheit liegt in der Mitte und definiert sich nach den Anforderungen der Firmen. SDRS kann hier ein Segen sein, aber auch diese Technik will verstanden werden (vollautomatisiertes SDRS vs. array-based TP vs. array-based Tiering).
- Management
- Performance
Wie du selber festgestellt hast, kann es durchaus ein Problem sein TP auf VM Ebene zu nutzen, da man damit wunderbar Datastores überbuchen kann. Den Performanceverlust wirst du bei I/O armen VMs kaum merken, bei I/O intensiven VMs zumindest dann, wenn diese dauerhaft Speicher allokieren, vor allem in kleinen Schritten (bei TP sind zwei Schritte notwendig: Block allokieren, Block nullen). Zudem liegen die Daten damit verteilt über mehrere Stripes etc.
Jede LUN hat ihre eigene LUN Queue Depth. Locking ist heute weniger ein Problem. Aber deswegen auf die Idee zu kommen einen oder zwei große Datastores zu bauen, ist nicht gut. An dieser Stelle verweise ich gerne auf den exzellenten Artikel von Jason Boche.
Tja, wie machen das andere Firmen... mal so, mal so. Ich sehe immer wieder Kunden, die eine von zwei Extremformen nutzen: Wenige, extrem große Datastores (es wurde ja immer wieder gebettelt, dass man DS mit mehr als 2 TB bauen möchte) und dem anderen Extrem ein DS pro VM. Beides ist Murks. Die Wahrheit liegt in der Mitte und definiert sich nach den Anforderungen der Firmen. SDRS kann hier ein Segen sein, aber auch diese Technik will verstanden werden (vollautomatisiertes SDRS vs. array-based TP vs. array-based Tiering).
-
irix
- King of the Hill
- Beiträge: 13058
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Aus meiner Sicht hoert sich deine aktuelle Umsetzung doch gut an. Auch hier sind es aktuell in der einen Installation:
- 34 Datastores a' 2TB
- 3 Datastore Cluster
- Thinprovisioning *wenn ueberhaupt* nur auf VM Basis
Wir haben die StorageProfiles noch im Einsatz damit ich gucke ob es noch so ausschaut wie mal bei der VM Erstellung.
An beiden Stellen Thinprovisioning zumachen halte ich fuer nicht gut. Die Frage nach wieviel freien Speicherplatz haben wir denn wird da irgendwie immer schwerer zu beantworten. Aber ich frage die Leute immer ob sie denn ein 24/7 Operating haben bzw. wie sie es finden wenn ein Volume offline geht wenn es doch mal am Ende der Kapazitaet angekommen ist. Gerade wer viel mit VM Sicherungen und deren Snapshots arbeiten muss sollte ueberlegen was er tut.
Gruss
Joerg
- 34 Datastores a' 2TB
- 3 Datastore Cluster
- Thinprovisioning *wenn ueberhaupt* nur auf VM Basis
Wir haben die StorageProfiles noch im Einsatz damit ich gucke ob es noch so ausschaut wie mal bei der VM Erstellung.
An beiden Stellen Thinprovisioning zumachen halte ich fuer nicht gut. Die Frage nach wieviel freien Speicherplatz haben wir denn wird da irgendwie immer schwerer zu beantworten. Aber ich frage die Leute immer ob sie denn ein 24/7 Operating haben bzw. wie sie es finden wenn ein Volume offline geht wenn es doch mal am Ende der Kapazitaet angekommen ist. Gerade wer viel mit VM Sicherungen und deren Snapshots arbeiten muss sollte ueberlegen was er tut.
Gruss
Joerg
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 16 Gäste