vSphere 6.0 bejelentés

http://www.yellow-bricks.com/2015/02/03/vsphere-6-0-finally-announced/

http://blogs.vmware.com/vsphere/

vSphere 6
Virtual Volumes
Want “Virtual SAN” alike policy based management for your traditional storage systems? That is what Virtual Volumes will bring in vSphere 6.0. If you ask me this is the flagship feature in this release.
Long Distance vMotion
Cross vSwitch and vCenter vMotion
vMotion of MSCS VMs using pRDMs
vMotion L2 adjacency restrictions are lifted!
vSMP Fault Tolerance
Content Library
NFS 4.1 support
Instant Clone aka VMFork
vSphere HA Component Protection
Storage DRS and SRM support
Storage DRS deep integration with VASA to understand thin provisioned, deduplicated, replicated or compressed datastores!
Network IO Control per VM reservations
Storage IOPS reservations
Introduction of Platform Services Controller architecture for vCenter
SSO, licensing, certificate authority services are grouped and can be centralized for multiple vCenter Server instances
Linked Mode support for vCenter Server Appliance
Web Client performance and usability improvements
Max Config:
64 hosts per cluster
8000 VMs per cluster
480 CPUs per host
12TB of memory
2048 VMs per host
128 vCPUs per VM
4TB RAM per VM

vSphere Replication
Compression of replication traffic configurable per VM
Isolation of vSphere Replication host traffic
vSphere Data Protection now includes all vSphere Data Protection Advanced functionality
Up to 8TB of deduped data per VDP Appliance
Up to 800 VMs per VDP Appliance
Application level backup and restore of SQL Server, Exchange, SharePoint
Replication to other VDP Appliances and EMC Avamar
Data Domain support

Virtual SAN 6
All flash configurations
Blade enablement through certified JBOD configurations
Fault Domain aka “Rack Awareness”
Capacity planning / “What if scenarios”
Support for hardware-based checksumming / encryption
Disk serviceability (Light LED on Failure, Turn LED on/off manually etc)
Disk / Diskgroup maintenance mode aka evacuation
Virtual SAN Health Services plugin
Greater scale
64 hosts per cluster
200 VMs per host
62TB max VMDK size
New on-disk format enables fast cloning and snapshotting
32 VM snapshots
From 20K IOPS to 40K IOPS in hybrid configuration per host (2x)
90K IOPS with All-Flash per host

( hassan | 2015. 02. 03., k – 07:57 )

Akkor nem csatlakozok be az eventre. :)
Köszi!

( Zahy v | 2015. 02. 03., k – 20:05 )

Nem néztem meg a linkeket, a "vSMP Fault Tolerance" azt jelenti amit a név sugall? Immár lehet Fault Tolerance VM-ben több virtuális proci? (Ha igen, mennyi?)

Volt egy előadás erről VMworld-ön és emlékeim szerint technikai akadályai voltak az SMP-s FT-nek, i.e. túl nagy volt a sávszélesség és erőforrás igénye.

Nem néztem végig megint de szerintem megtalálod benne:
http://vmware.mediasite.com/mediasite/Play/5c0d5fe1b0644742bf55cf764bac…

Meg fogom nézni. Bár kétlem, hogy a piszkos részletekbe elég mélyen bele fog menni.
EDIT: nem is ment bele... egy UI demo volt mindössze.

Az a nehéz benne, hogy 1 CPU-nál a program futása interruptok és I/O műveletek közötti időszakokban teljesen determinisztikus. Illetve ez a könnyű benne. :) Az interruptok és IO műveletek trappelhetőek a hypervisorban, a CPU állapota ezeken a pontokon menthető és pontosan visszajátszható a második node-on. Utasításonkénti lockstep nélküli szinkronizációt lehet csinálni kis költséggel. Ráadásul az első node-on a hálózati forgalom visszatartásával egy kicsit lehet késni hagyni a második node-ot, így nem lesz annyira latency érzékeny, hogy infiniband és hasonló egzotikus hálózati megoldások kelljenek a szinkronizációhoz.

Több CPU-nál kezdődnek a bajok, mert ha nem órajelciklusra pontosan egyforma az első és második node-on a CPU-k végrehajtási sebessége (eltérő cache tartalom miatt általában nem az), akkor a konkurensen futó szálak közötti adatátadásoknál egyáltalán nem biztos, hogy ugyanaz történik a két node-on. Persze megvannak az elvi módszerek erre is, de a költségük lényegesen több, mint amennyit a több CPU-val nyernél. A pontos O()-ra nem emlékszem már, de lineáris feletti költségről beszéltek -> a magok számának növelésével az összteljesítmény csak romlani tud.

Xen-esek írtak erről elég részletekbemenő publikációkat, de nyilván az alapprobléma a VMware-t is ugyanúgy érinti. Na ezért volnék nagyon kíváncsi, hogyan tudták ezt praktikusan használható módon megoldani, illetve milyen rejtett buktatói vannak a megoldásuknak.
---
Régóta vágyok én, az androidok mezonkincsére már!