EMC Isilon 15PB Storage system

EMC has announced a new storage system called Isilon 108NL. The Isilon storage system consists of 36 disk 4U nodes which can be joined together to create a 144 node storage system with a capacity of 15 PB.

It’s a scale-out storage system where each node contains its own 1 Gbps and 10 Gbps interfaces so you can add capacity while maintaining throughput.

According to EMC, the Isilon 108NL can achieve a throughput of 85 GBps and a maximum of  1.4 M IOPS. The Isilon can be equipped with 1, 2 or 3 TB Hitachi SATA disks giving it 36, 72 or 108 TB per storage node. The Isilon is by powered by the OneFS operating system which supports NFS, SMB, iSCSI, http and FTP and delivers N+4 data protection on cluster, directory or file level.

VMware is still the best

  
Now, you can nit-pick on the measurements he made or the criteria he has chosen, but in general I think it’s a solid test of up-to-date versions.

The best conclusions I can draw from his report are these:

VMware might not always be the cheapest, VMware might not always be the one with the highest speeds.. but VMware is still the one with the most diverse OS support (any x86 OS can be virtualized), the best management toolkit and the most reliable architecture.


The article also shows some interesting trends. If you go back in time a bit, you can certainly remember that Citrix was aiming at the server virtualization market when they bought Xen. They even re-branded their entire portfolio with it after the purchase. When you look at the results they present in the test Paul did, the conclusion I draw is that Citrix has run out of fuel in this part of town and is concentrating on the desktop again.
Also, another remarkable trend is to be seen at Microsoft and Red Hat. A few years back, Red Hat didn’t really compete in this part of town and Microsoft was more or less the laughing stock of the bunch. Nobody really considered running Hyper-V in their data center as it was not even ready for proper single server deployment, let alone in a complete data center cluster.

Well, Microsoft did what was to be expected of them; they improved and improved again. One thing can be said of their current version, it can be deployed in a data center scenario. But as the shoot out shows, there is still a lot of room for improvements. And we all know that statements made with previous versions of Hyper-V like ‘who needs live migration’ quickly changed into ‘look, we can do live migration too!’. Reliability and scalability hugely improved, management still is a pain in the butt for Redmond. One thing that strikes me most when I am in selection of a virtualization platform. Many clients tend to think Hyper-V is for free. You get it with any server license you buy. Indeed you do. But keep in mind that you burn that specific license for your virtual platform AND you still need to buy a collection of management software to properly manage the lot. But I guess we haven’t seen the last of this yet.

Red Hat is one of the most remarkable companies in this list. They have been on the virtualization train for quite some time but as this test shows, they really can compete with the big three in this field.. and come out as second. It seems that open source is closing the gap quickly with the enterprise environments and really showing off what they can do, although implementation is a bit limited with Windows and Red Hat Linux as only supported client VM’s.

How to convert VHD to VMDK partition types (Convert format to VMDK)

Download Winimage 8.10

First thing you will need is Win Image 8.10 witch is shareware. You may evaluate it for a period of 30 days, after you need to register if you intend to continue using it. Make sure to download WinImage version 8.10. You can get it from:

This is the Winimage download page.

http://www.winimage.com/download.htm

Install Winimage 8.10 and start it

After installing WinImage, you will get to this screen:

Click menu "Disk" and "Convert Virtual Hard Disk Image".

Select file type "Virtual Hard Disk (*.vhd)" under file type field.
Choose the folder where the source virtual disk is, select the virtual disk and click "Open".

Select either "Create Fixed Size Virtual Hard Disk" or "Create Dynamically Expanding Virtual Hard Disk".

Select file type "VMware VMDK (*.vmdk)" under file type field.
Choose the folder where the destination virtual disk will be, type the virtual disk name and then click "Save".

Give it time to finish the conversion. It may take a while depanding on the size of the virtual hard disk.

Once it is done you will go back to the opening window. The conversion is done.

This is "Virtual to Virtual" (V2V) conversion.

vSphere 4.1 Memory Enhancements - Compression

Finally, with Transparent Memory Compression, 4.1 will compress memory on the fly to increase the amount of memory that appears to be available to a given VM. The new Transparent Memory Compression is of interest in the workload cases where memory -- rather than CPU cycles -- has limitations. ESX/ESXi provides a Memory Compression cache to improve virtual machine performance when using memory over-commitment. Memory Compression is enabled by default when a host's memory becomes overcommitted; ESX/ESXi compresses virtual pages and stores them in memory

Since accessing compressed memory is faster than accessing memory swapped to disk, Memory Compression in ESX/ESXi allows memory over-commits without significantly hindering performance. When a virtual page needs to be swapped, ESX/ESXi first attempts to compress the page. Pages that can be compressed to 2 KB or smaller are stored in the virtual machine's compression cache, increasing the capacity of the host. The maximum size can be set for the Compression Cache and disable Memory Compression using the Advanced Settings dialog box in the vSphere Client.

vSphere 4.1 Network Traffic Management - Emergence of 10 GigE

The diagram at left should be familiar to most. When using 1GigE NICs, ESX hosts are typically deployed with NICs dedicated to particular traffic types. For example you may dedicate 4x 1GigE NICs for VM traffic; one NIC to iSCSI, another NIC to vMotion, and another to the service console. Each traffic type gets a dedicated bandwidth by virtue of the physical NIC allocation. 

Moving to the diagram at right … ESX hosts deployed with 10GigE NICs are likely to be deployed (for the time being) with only two 10GigE interfaces. Multiple traffic types will be converged over the two interfaces. So long as the load offered to the 10GE interfaces is less than 10GE, everything is ok—the NIC can service the offered load. But what happens when the offered load from the various traffic types exceeds the capacity of the interface? What happens when you offer say 11Gbps to a 10GigE interface? Something has to suffer. This is where Network IO Control steps in. It addresses the issue of oversubscription by allowing you to set the relative importance of predetermined traffic types.  

NetIOC is controlled with two parameters—Limits and Shares.

Limits, as the name suggests, sets a limit for that traffic type (e.g VM traffic) across the NIC team. The value is specified in absolute terms in Mbps. When set, that traffic type will not exceed that limit *outbound* (or egress) of the host.

Shares specify the relative importance of that traffic type when those traffic types compete for a particular vmnic (phyiscal NIC). Shares are specified in abstract units numbered between 1 and 100 and indicate the relative importance of that traffic type. For example, if iSCSI has a shares value of 50, and FT logging has a shares value of 100, then FT traffic will get 2x the bandwidth of iSCSI when they compete. If they were both set at 50, or both set at 100, then they would both get the same level of service (bandwidth).

There are a number of preset values for shares ranging from low to high. You can also set custom values. Note that the limits and shares apply to output or egress from the ESX host, not input.Remember that shares apply to the vmnics; limits apply across a team.

vSphere 4.1 offers improved vMotion speeds

The vSphere 4.1 vMotion enhancements significantly reduce the overall time for host evacuations, with support for more simultaneous virtual machine migrations and faster individual virtual machine migrations. The result is a performance improvement of up to 5x for an individual virtual machine migration and support for four to eight simultaneous vMotion migrations per host, depending on the vMotion network adapter (1GbE or 10GbE respectively).

 

Fault Tolerance Checklist

I delivered my first “vSphere 4 what’s new” training this week. During the last lab, the students managed to configure VMware Fault Tolerance. After powering down one of the ESX servers the protected virtual machine switched over to the second ESX server. FT works fabulous, you can use the following checklist to make sure you configure FT the right way. 

Fault Tolerance Checklist 

• Required  ESX/ESXi Hardware: Ensure that the processors are supported: AMD Barcelona+, Intel Penryn+ (run the CPU compatibility tool to determine compatibility).
• Required  ESX/ESXi Hardware: Ensure that HV (Hardware Virtualization) is enabled in the BIOS.
• Optional  ESX/ESXi Hardware: Ensure that power management (also known as power-capping) is turned OFF in the BIOS (performance implications).
•  Optional  ESX/ESXi Hardware: Ensure that hyper-threading is turned OFF in the BIOS (performance implications).
•  Required  Storage: Ensure that FT protected virtual machines are on shared storage (FC, iSCSI or NFS). When using NFS, increase timeouts and have a dedicated NIC for NFS traffic.
•  Required  Storage: Ensure that the datastore is not using physical RDM (Raw Disk Mapping). Virtual RDM is supported.
•  Required  Storage: Ensure that there is no requirement to use Storage VMotion for VMware FT VMs since Storage VMotion is not supported for VMware FT VMs.
•  Required  Storage: Ensure that NPIV (N-Port ID Virtualization) is not used since NPIV is not supported with VMware FT.
•  Optional  Storage: Ensure that virtual disks on VMFS3 are thick-eager zeroed (thin or sparsely allocated will be converted to thick-eager zeroed when VMware FT is enabled requiring additional storage space).
•  Optional  Storage: Ensure that ISOs used by the VMware FT protected VMs are on shared storage accessible to both primary and secondary VMs (else errors reported on secondary as if there is no media, which might be acceptable).
•  Optional  Network: Ensure that at least two NICs are used (NIC teaming) for ESX  management/VMotion and VMware FT logging. VMware recommends four VMkernel NICs: two dedicated for VMware VMotion and two dedicated for VMware FT.
•  Required  Network: Ensure that at least gigabit NICs are used (10 Gbit NICs can be used as well as jumbo frames enabled for better performance).
•  Optional  Redundancy: Ensure that the environment does not have a single point of failure (i.e. use NIC teaming, multiple network switches, and storage multipathing).
•  Required  vCenter Server: Ensure that the primary and secondary ESX hosts and virtual machines are in an HA-enabled cluster.
•  Required  vCenter Server: Ensure that there is no requirement to use DRS for VMware FT protected virtual machines; in this release VMware FT cannot be used with VMware DRS (although manual VMotion is allowed).
• Required  vCenter Server: Ensure that host certificate checking is enabled (enabled by default) before you add the ESX/ESXi host to vCenter Server.
•  Required  ESX/ESXi: Ensure that the primary and secondary ESX/ESXi hosts are running the same build of VMware ESX/ESXi.
•  Required  Virtual Machines: Ensure that the virtual machines are NOT using more than 1 vCPU (SMP is not supported).
•  Required  Virtual Machines: Ensure that there is no user requirement to use NPT/EPT (Nested Page Tables/Extended Page Tables) since VMware FT disables NPT/EPT on the ESX host.
•  Required  Virtual Machines: Ensure that there is no user requirement to hot add or remove devices since hot plugging devices cannot be done with VMware FT.
•  Required  Virtual Machines: Ensure that there is no user requirement to use USB (USB must be disabled) and sound devices (must not be configured) since these are not supported for  ecord/Replay (and VMware FT).
•  Required  Virtual Machines: Ensure that there is no user requirement to have virtual machine snapshots since these are not supported for VMware FT. Delete snapshots from existing virtual machines before protecting with VMware FT.
•  Required  Virtual Machines: Ensure that virtual machine hardware is upgraded to v7.
•  Optional  Virtual Machines: Ensure that there are will be no more than four (to eight) VMware FT enabled virtual machine primaries or secondaries on any single ESX/ESXi host (suggested general guideline based on ESX/ESXi host and VM size and workloads which can vary).
•  Required  Guest OS: Ensure that the virtual machines do not use a paravirtualized guest OS.
•  Required  3rd Party: Ensure MSCS clustered virtual machines will have MSCS clustering removed prior to protecting with VMware FT (and make sure that the virtual machines are not SMP).