What better way to learn binary than to have to read it in order to tell the time!

4-Bit Binary Watch One of the little joys of geekhood is wearing something that is totally geeky but only noticed by other geeks. “Normal” people just don’t get it. It’s like a secret handshake. Are you in the club? Or are you some outsider wannabe? Of course, it’s been argued that we geeks are just turning the tables on the folks that excluded us when we were scribbling code in our notebooks during recess. But whatever, that’s too serious a discussion for today. OMG, CHECK OUT THIS WATCH! Instead of Arabic or Latin numerals, the numbers on this dial are 4-bit binary. To the outsider, it looks like nifty black and white boxes, but to the geek, it’s an awesome conversation starter. If you can’t wear your Binary People shirt to work, at least you can express your love of 1s and 0s through this classy watch, suitable for any occasion. Product Specifications Quietly geeky watch lets you say: “Pssst, I like binary.” Case made from jewelry grade (316L) stainless steel Saddle stitched two part leather strap with stainless steel buckle Miyota quartz movement Case size: 40mm diameter, 9mm thickness Water resistant to 3ATM Sapphire coated quartz glass

This one is great news for those of us that have migrated to vSphere 5 or have held of on migrating. vSphere 5 introduced the idea of memory based licensing and it sent their customer base into a spin.

In vSphere 4.1 if you had all the RAM on 128GB server with two sockets, you still only needed two licenses. In vSphere 5 you now need three licenses to cover the RAM in use. Not only does it get confusing, but also expensive; especially in the small to mid business space.

VMware may be dropping the vRAM (#Vtax) licensing to help stave off competition from competitors, like Microsoft. Hyper-V has not been a serious competitor in the enterprise space, but once it hits maturity and adds features, you can’t imagine it will be long before there is some serious competition in the virtualisation space.

On top of the additional cost, the vRAM licensing was confusing, requiring customers to have excess licenses for memory dense servers. Based on the premise of what you would try to achieve with virtualisation (server consolidation, mostly), this cost structure hit in the one area that had to be massively provisioned.

By changing the license model, VMware can adopt a packaged license model and not build in things like vCenter Operations, vShield and vCloud Director to the base vSphere licence.

So bring on vSphere 5.1 (sooner than later!) and simplified vSphere licensing!!

In Part 1 and Part 2 we looked at deploying the start of an Active Directory using Vmware Player for testing purposes. In Part 3 we’ll look at deploying additional virtual machines and promoting them to domain members.

At the completion of Part 2, we should have one “template” virtual machine that will be copied each time we need a new VM and one deployed domain controller for the domain of our choice (invurted.local).

Building on this we want an additional member server for the domain. This server will use the Active Directory to authenticate users.

As in Part 2, there are two options for deploying a virtual machine
a) Build it from scratch, or;
b) Copy an existing virtual machine and copy it.

For ease of deployment, we are going to copy the _TMPL-inv-dc01 virtual machine.

Right click and select Copy on the directory of _TMPL-inv-dc01. In the same directory, right click and select Paste or use the Edit menu in Windows Explorer to paste. This may take a couple of minutes to copy. The virtual machine that we built takes up 6.50 GB (6,983,880,704 bytes) on my hard drive.

Once the copy is complete, we can rename the new copy to something more meaningful than _TMPL-inv-dc01 – Copy. Right click on the folder that has been created, select rename and call it inv-srv01.

Now the virtual machine is ready to start up. At this point, be aware that there are some Windows 2008 configuration changes needed before we can make the server a domain member. The IP address and machine name, at the least, will need to be changed.

Because the files for the machine are a direct copy of the “template”, the following should happen.

As you can see, the directory is called inv-srv01 and the Vmware virtual machine configuration (.vmx extension) still has the inv-dc01 name. This is not a major problem and can be fixed by right clicking the file, selecting Rename and changing the name to inv-srv01. DO NOT change the contents of the file as it contains configuration information that points to other files in the directory. Improperly edits can result in non-bootable virtual machines.

Once the file is renamed, open it using Vmware Player and the wait for the virtual machine to boot. Hopefully you get the following dialogue box.

Select the “I copied it” option and press OK.

We are immediately prompted to install Vmware Tools in the new virtual machine. The template that we made was post-operating system installation, but pre-install of Vmware Tools. Choose to either install now or be reminded later.

When we run an ipconfig in the virtual machine, the IP address is allocated from a DHCP pool that is managed by Vmware Player. This IP address won’t be able to communicate with the domain that we created and, therefore, won’t be able to join the domain.

Setting the IP address can be done any number of ways, the previous tutorial used the netsh command:
The interface that we are interested in is Local Area Connection.

netsh interface ip set address name="Local Area Connection" static 192.168.0.20 255.255.255.0 192.168.0.1 1

and, most importantly, set the DNS IP address. This is required to join the domain successfully. Again, at the command prompt:

netsh interface ip set dns "Local Area Connection" static 192.168.0.10

Now we can join the domain. There are multiple ways to joing the domain, but we’re doing so much at the command line, we may as well keep going.

From a DOS prompt, type hostname and press enter.

The hostname is the randomly generated when we created the virtual machine and installed the Windows 2008 operating system. Renaming the computer will be done using the command line and the command NETDOM. We are still not part of the domain. so the command syntax is pretty straight forward:

netsh renamecomputer win-agimt9cb3rv /newname inv-srv01

The renamecomputer win-agimt9cb3rv will change to whatever your hostname is.

This command will require a reboot to apply the new name. Once rebooted, login and open a command prompt again.

Test connectivity to the network, ping invurted.local. Any response from the network is considered successful. Again, from the command line:

netdom join inv-srv01 /domain:invurted.local /userd:administrator /passwordd:P@ssw0rd

This command requires a reboot when successful. If it fails, check your IP address and, especially, DNS address to make sure they are right.

Once rebooted, login as username invurted\administrator with the password word P@ssw0rd and now we have one domain joined Windows 2008 server!

That’s Part 3 complete. Any suggestions where to go from here? Please email me (contactme [at] invurted dot com).

In Part 1 we installed Vmware Player and installed Windows 2008 R2 Enterprise into a virtual machine. In this second part, we’ll look at setting up another virtual machine and deploying our first domain controller for the testing environment.

We could definitely go back and setup another virtual machine using the the same process as before. However, this takes too long; the least of which we have to wait for Windows 2008 R2 to re-install.

An easier option is to copy the existing virtual machine files to a new directory and paste it as a new virtual machine.

1. Right click on our perviously built virtual machine (inv-dc01), select Copy and then right click and Paste into the same directory. This will create two copies of the virtual machine, inv-dc01 (the original) and inv-dc01 – Copy. This process can be repeated as many times as we like until the local drive is full.

   

   For the moment, all that is required is the two copies of the virtual machine.

2. Rename inv-dc01 – Copy to _TMPL-inv-dc01. Now we have a TEMPLATE version of a virtual machine with Windows 2008 R2 installed and can continue to take copies of it as needed.

Onto setting up our domain controller.

1. Open the Vmware virtual machine configuration file by double clicking or right click and open the Vmware virtual machine configuration file with Vmware Player.
   
2. Once the operating system has started, use CTRL+ALT+INSERT to get to the login screen.
   
   At this point login as the user we created or login as Administrator. If you login as Administrator, Windows will prompt you to change the password. The Administrator password will also have to meet complexity requirements ie. uppercase, lowercase, letter, number and special characters.
3. Next up is the all important Vmware Tools. VMware Tools package adds drivers and utilities to improve the graphical performance for different guest operating systems, including mouse tracking. The package also enables some integration between the guest and host systems, including shared folders, plug-and-play devices, clock synchronisation, and cutting-and-pasting across environments.
   
   Click “Install Tools” in the bottom bar of the window to start the install process.
4. You may want to close this window for the moment to allow the Vmware Tools installer to run.
5. If this dialog fails to appear, open Windows Explorer, browse to the CD drive of the virtual machine and run setup.exe manually.
   
   Install Vmware Tools using the default settings; there is no real benefit to be gained from changing the default options in our scenario.
   
   Once the installer has completed, reboot the virtual machine and then log back in when it has restarted.

Once the desktop is initialised, there are a couple of configurations required before we can create the domain controller. Primarily, the IP address and the Windows machine name.

1. The domain controller ABSOLUTLEY has to have a statically assigned IP address, and the easiest (and most fun!) way to do this is set it via the command line:

   netsh interface ip show config

   
   This will show all the adapters currently available to the virtual machine. The interface that we are interested in is Local Area Connection. Once we have establised that it is available and has an IP address allocated from DHCP, it needs to be changed to a static IP address.

   netsh interface ip set address name="Local Area Connection" static 192.168.0.10 255.255.255.0 192.168.0.1 1

   This set the static IP of 192.168.0.10, subnet mask of 255.255.255.0 and default gateway (which we don’t need for the moment) of 192.168.0.1. For the purposes of completeness, it’s best to put the gateway in.
   DNS is still required, but configuring the domain controller will automatically install this service on the domain controller.
   Running ipconfig from the command line should verify the configuration has been applied.

2. Finally we’re at the point of installing the domain controller! From the command prompt, run dcpromo to start the install.
   
3. From here it is a simple matter of following the prompts.
   • At the Active Directory Domain Services Installation Wizard make sure Use advanced mode installation is NOT selected and press Next.
   • The next window is a warning about incompatibilites with Windows NT 4.0. Just press Next.
   • Choose a Deployment Configuration – Check the Create a new domain in a new forest and press Next.
   • Name the Forest Root Domain – In the FQDN of the forest root domain enter the name of your network. For our purposes, any name will do. invurted.local is acceptable. Press Next.
   • Set forest functional level – Select Windows 2008 R2 from the drop down list. This will mean that all domain controllers have to have at least Windows 2008 R2 as their operating systems. Press Next.
   • Additional Domain Controllers – Make sure the DNS Server option is ticked and press Next. Select Yes for any dialog boxes that appear.
   • Location for Database, Log Files and SYSLOG – Accept the default locations and press Next.
   • Directory Services Restore Mode Password – Enter the password of P@ssw0rd in both fields and press Next.
   • Summary – Verify your settings and press Next.
   • Active Directory Domain Services Installation WizardActive Directory will now start installing. At the completion, reboot the virtual machine. If everything is successful, upon reboot, your domain controller setup is complete.

Upon successful restart and login using the Administrator username and password, we want to look at our new domain. From the start menu, select Administrative Tools and launch the Active Directory Users and Computer program. This will allow us to create any users, groups and Organisation Units that are required.

I almost forgot! We need to rename our domain controller. In previous versions of Windows this was painful, especially as the virtual machine is a domain controller. In Windows 2008 there is more tolerance to name changes. It’s not the sort of thing that I would want to do regularly, but is possible.
In the start menu, right click on Computer and select Properties.

Chose Change settings and accept any warnings that appear on screen.

In the Sytem Properties, select Change and, again, accept any warning that appear.

In the computer name field enter the new name for the computer. For our purposes, inv-dc01 will do fine. Press OK twice and then close the system properties. At this point, it is a good idea to restart the machine again.

That’s Part 2 complete. In Part 3 we’ll look at configuring the virtual machine as a domain member server.

As ever, if you have any questions, please email me (contactme [at] invurted dot com).

Following a number of requests, I have written a tutorial on setting up a Windows 2008 testing environment. Part 1 looks at installing Vmware Player and setting up the first virtual machine
ASSUMPTIONS:

• A supported operating system is used. Vmware Player supports most Microsoft operating systems as well as a number of Linux distributions. For the purposes of this tutorial, Windows 7 is the operating system used as the base.
• The account on the Windows 7 base operating system is either a member of the Local Administrators group or can elevate priveledges as required.
• At least 50 – 100 GB of storage space is available for all the virtual machines. It’s better to err on the side of caution.
• Vmware Player is the chosen hypervisor. Vmware Workstation could as easily be used if available. We use Vmware Player as the hypervisor due to it’s cross platform compatibility and its free licensing.
• We are only doing the setup of the first virtual machine. Further configuration will be done in subsequent tutorials.

On to the fun bits! As with most hypervisor technologies, the result of what we are doing here is allowing me to run two (or more) instances of operating systems on the one hardware platform. Vmware Player is our chosen hypervisor because it removes a lot of the guess work from deploying virtual machines. Vmware Workstation definitely gives us more granular control over the final conifguration. For our purposes, the default RAM, CPU and storage configurations are more than acceptable.

1. Install Vmware player following all the default configuration options. There is little need to change the installation path etc. unless absolutley necessary.
2. Once installed, run the program and select “Create new Virtual Machines”.
   
   This will start the wizard driven configuration of the new virtual machine that we will use as the basis for the testing environment.
3. One of the first configuration options is the installation media. We’re focussing on the first two options; providing either a CDROM or an ISO file to install from. It’s possible to network boot a virtual machine, but that’s something for later.
   If we load a CDROM into the drive, Vmware Player should recognise the operating system. Similarly with an ISO file.
   
4. Next up, the all important licence key. Windows 2008 R2, Enterprise will install without a key being provided. It will install in Evaluation Mode giving us sixty days to activate with a valid licence. Again, for purely testing purposes, we can ignore the licence key and come back to it later if we need to. The only configuration to be aware of is the version of Windows 2008 to install. The CDROM (or ISO file, in this case) has a number of different versions available. Make sure Windows 2008 R2 Enterprise is the selected option.
   
   The only other piece of information needed is the first user who is installed. The username can be Administrator, but Vmware Player will throw back a warning. Windows 2008 doesn’t treat the Administrator account the same as previous operating systems. To perform most administrative functions, we still have to elevate the credentials. The user name is invurted and a password of P@ssw0rd to meet complexity requirements.
5. Now we apply the name and location of the virtual machine. This is where the space requirement comes in. By default, Vmware Player saves the virtual machine files to the current user’s directory. Both the name and the save location can be changed at this point. A recommendation would be make sure the volume that you are saving the virtual machines to has enough space for all the hard disks that will be created.
   
6. The next step is to configure the virtual hard disk. In the physical world this would be the hard disk used as an installation target for Windows. It’s exactly the same in the virtual machine. The main difference is that the size represents the maximum size that the “physical” hard drive will be reported as to the Windows operating system.
   
   As this server will only provide domain controller and networking services for the lab environment, it’s been configured as a 20GB hard drive. In the real world, we would attach a second virtual hard drive of larger size that would store all of the application data, leaving the operating system with a volume all to itself.
7. Almost there!
   
   We have our final configuration ready to go. Before powering on the virtual machine for the first time, we need to customise the virtual machine.
   
   The networking configuration is the one major limitation of Vmware Player. Vmware Workstation has a lot more configuration options available.
   The three options are:
   • Bridged – the virtual machine will use an available physical adapter for the virtual machine. This will appear on the network as a separate device from the host operating system. As out virtual machine will be a domain controller, we don’t want to expose it to the real, potentially production, nework.
     DO NOT use a bridged adapter unless you are absolutley certain it is required.
   • NAT – the virtual machine will use the same IP address assigned to a physical adapter. Both the virtual machine and the host OS will appear on the network as the “same” device.
     DO NOT use a bridged adapter unless you are absolutley certain it is required.
   • Host only – This will create a software based virtual switch that virtual machines will be plugged into. The virtual machine will have no network connectivity unless a virutal routing device is created. This is the safest option as it removes the ability for our test lab to interfere with the real, production network.
8. As the machine powers up for the first time, we should see the familiar Windows starting screen. If at this point you don’t see it, check that the CDROM or ISO file is properly mounted.
   
   We need to mount the CDROM or ISO file through this interface.
   
   Once this is done, press CTRL+ALT+INSERT to force a reset of the virtual machine. If you hit CTRL+ALT+DELETE, this will open up the option to get to the task manager of the host operating system.
9. Go and get a cup of tea, sit back and relax because Windows 2008 is installing and there’s very little required at this point.
   
   Once Windows has finished installing, we should be presented with this screen. From this point on, there is no difference between the virual machine and a real version of Windows 2008.
   Power off the virtual machine and move onto Part 2!

That’s Part 1 complete. In Part 2 we’ll look at configuring the virtual machine as a domain controller and deploying additional servers for the rest of the lab.

As ever, if you have any questions, please email me (contactme [at] invurted dot com).

Vmware View is the virtual desktop infrastructure offering from Vmware. The current version is 4.5.

The object of virtualising my desktop include

• Replace outdated unreliable hardware
• Increase overall system performance
• Increase overall system performance
• Reduce ongoing Power consumption and Cooling requirements
• Built a “Green IT” focused IT environment
• Reduce time & costs associated with purchase / management and support Desktop PC’s

Effectively, I am able to achieve many, if not all, of these goals by turning my user workstations into virtual machines! By replacing my client workstation with thin clients, I can extend the life of the hardware or even re-purpose the old hardware I have.

VMware View is well suited to large environments where traditional Desktop imaging such as Ghost, are no longer viable due to numerous restraints. It simplifies management of desktops and enables quick and easy deployment of new applications.

A VMware view “Thin provisioned” virtual machine performance is higher than a standard virtual machine as the snapshot of the master image will remain in the SAN’s cache due to its high utilization. This speed’s up performance as all requests are returned by cache and don’t need to access the physical disk which generates I/O load on the SAN.

The ability to utilize existing desktops and/or thin clients means a migration to VMware View is quick and easy. Once the older desktops are replaced with Thin Clients the lifespan of the equipment dramatically increases as there are no moving parts. The cost saving of a VMware View environment also extends to power savings as a typical Thin Clients uses far less power than a desktop PC.

A VMware capacity planner audit of the existing desktop pc’s will be required to get an accurate number of required ESX hosts for the VMware view environment. As a guide typically you’ll see ~50 medium use virtual desktops per HP DL380 (or equivalent) ESX Host. Depending on the number of concurrent users and applications used this number can vary.

Although additional ESX hosts will be required if VMware View was utilized across the organisation the SAN disks and configuration is designed to support a full VMware View environment.

As I mentioned elsewhere, the technology underlying View is remarkably simple. At its core there is my existing virtual infrastructure running Vmware ESX, some shared storage and a few minor network tweaks. After that, all I need are:

• VMware View manager “Connection Server”
  The server used to connect the VMware View Client to the virtual desktops entitled to the user/s
• VMware View manager “Security Server”
  A server to be placed in the DMZ, for remote users to connect to for secure access to the VMware view environment
• Virtual Desktops
  A Virtual machine running a Desktop operating system with VMware View Agent installed to enable all VMware View features.

As you can see below:

It shows the “Fat Client”, “Thin client” and “Diskless PC’s” connected directly to the View manager server while within the Local area network or Private -Area network.

The example also shows a “Mobile / Remote user” connecting securely via a View Manager Security server in the DMZ and through the Connection server to the centralized virtual desktops.

And that’s about it! The security server acts as a front end for my clients from external sources, thereby avoiding potentially dangerous access directly to the Connection Server (or Broker) that controls the connection to the virtual machines.

There is, of course, more to it than this. However, for the moment, the basic structure is a good starting point.

And of course, all the machines required for VDI virtualise brilliantly!

Well, I’m back after an extended hiatus! Didja miss me? In my new job, back onto relevant topics, I am mucking around with deploying Vmware View to various organisations.

Of all the suite of Vmware products, View has me most interested. It’s the network nazi in me that really finds granular control of the destop environment so fascinating.

Generally this means implementing group policies to lock down the Windows operating system, redirect user data and so forth. Now I can leverage ideas like snapshots and templates to deploy my standard operating environment (SOE) to clients both locally and remotely. Bare metal deploys are still a bit of a problem, but now both Wyse and HP thin clients are integrating the Vmware View client into them, when it comes time to do a hardware refresh I can throw away my old desktop machines and replace them with thin clients.

The transition from Windows XP to Windows 7 is now possible without a (potentially) expensive hardware refresh too. All I need to do it deploy the View Client to my existing fleet and I can have a shiny new operating system ready to go.

The infrastructure behind the technology is, like much of Vmware’s technology, remarkably simple once you get your head around a few key concepts. I’m looking forward to implementing this technology and fully maxing out it’s potential, especially, in my opinion, to my SME customers!

Wow! Hasn’t it been a while?!

Isn’t it always the way? You get a new job, a new wife and family and important things like blogging go out the window.

I have been extremely busy with all the above, but will spare you the boring details and get onto the good stuff.

Recently I have been doing a fairly large scale migration from Autonomous Wireless Access points to Light Weight Access points. This means implementing a Cisco Wireless Lan Controller and installing a “light weight” IOS so the Wireless Access points can be managed by the controller. No more dispersed SSIDs or inconsistent security.

The environment, most interestingly, consists of 1200 series, 1250 series and two 1310 outdoor controllers.

From Cisco;

A Cisco Aironet 1300 Series device operating autonomously is an intelligent access point or bridge, capable of functioning as a standalone device. As an LWAPP access point, the Cisco Aironet 1300 Series works along with the Cisco wireless LAN controller to enable centralized configuration and management, application of security policies, and seamless mobility. When operating with wireless LAN controllers, Cisco Aironet 1300 Series Outdoor Access Points/Bridges function only as access points and are not capable of bridging.
The integrated antenna versions feature a radio and high-gain patch antenna for user installations of either point-to-point links or non-root nodes of point-to-multipoint networks. The connectorized versions provide professional installers with RP-TNC type connectors that allow the deployment of nodes with omnidirectional, sector, or high-gain dish antennas for longer links. In all cases, the mounting kit must be ordered separately.
All parts, along with accessories such as the Roof Mount Kit, Wall Mount Kit, cable, antennas, and power supplies, are available on the Cisco Systems® global and wholesale price lists.

So it’s designed for outdoors, which is great! However, at the remote end, it keeps getting screwed up by the upgrade process and I have to nuke both sides to reconfigure them to be autonomous. I’m serious, delete /force /recursive flash:!

That scares the SHIT out of me and I’ve been forced to do it two or three times! The first time we transferred the IOS back onto both ends via console ie. 9600 bps. This was not any fun at all. Logically, there has to be a better way.

After nuking the device back to the stone age, issue the following commands:
set IP_ADDR A.B.C.D
set DEFAULT_ROUTER W.X.Y.Z
set NETMASK XXX.XXX.XXX.XXX
tftp_init
tar -xtract tftp://IPADDR_OF_TFTP_SERVER/ios.tar flash:
set BOOT flash:/c1310-k9w7-mx.124-21a.JA1/c1310-k9w7-mx.124-21a.JA1

The only thing to look out for is make sure the TFTP server is reachable by the access point. And make sure you set the BOOT option to boot to the correct directory and file in flash. As you can see above, I am booting from the flash directory c1310-k9w7-mx.124-21a.JA1 and a file called c1310-k9w7-mx.124-21a.JA1. A simple dir flash: will start to get you on the right track.

It seems that in the local industry (Melbourne, Australia) that businesses just don’t get virtualisation.

At the cessation of another job, I am beginning to wonder if this virtualisation thing will ever catch on. Or maybe I’m too far ahead of the curve and waiting for it to catch up.

Let’s start with the benefits;

• no reliance on physical infrastructure
• Rapid provisioning of both servers and desktops (VDI)
• Fault tolerance and, if I want it, automated load balancing
• Cost savings in the datacentre because I’m not taking up as much space with hardware that needs to be maintained and replaced as often

The disadvantages are far outweighed by the benefits. It does cost to put in a virtual infrastructure; primarily the storage. Fibre channel is still “king” in the storage stakes, however, advances in ethernet technologies and a bit of planning in the implementation phase mean that iSCSI is a viable competitor (http://invurted.com/iscsi-vs-fibre-channel-storage-performance/). Of course, there are training considerations. Thankfully, the virtualisation platform is largely “fire and forget” technology. So apart from some familiarity with my chosen platform, there is little reason to touch it post-implementation.

Maybe I’m missing the point somewhere …

]]> http://invurted.com/virtualisation-i-dont-get-it/feed/ 0 http://invurted.com/iscsi-vs-fibre-channel-storage-performance/ http://invurted.com/iscsi-vs-fibre-channel-storage-performance/#comments Sun, 21 Feb 2010 23:14:28 +0000 Adam http://invurted.com/?p=306

It’s something that I have been discussing a lot with one of my customers.

At the moment, they are hesitant to invest in a potentially very expensive SAN solution involving fibre channel connections. Currently, there are eight vSphere servers configured with no centralised storage. Hence, all virtual machines are running on the local disk arrays. Therefore, there is no DRS, no HA and no Vmotion! We are protecting the virtual machines only with the local server’s ability to recover from physical disk failure, in this case, on board RAID 5 controllers.

My temporary solution was an open source iSCSI storage solution until a more permenant solution can be found.

However, the big question that I keep coming up against is, “What’s the performance hit I will take?”

It’s undeniable that the fibre channel should be faster, as the article below describes, this may not be that much of an issue.

If we look at the way a virtual machine (and a physical machine, indirectly) runs, the most important resources are RAM and CPU. Disk storage is (sort of) secondary. The exception to this is streaming media or backup servers. Typically, performance difference is minimal.

As long as you have a properly implemented iSCSI solution. I have look at the security considerations previously (http://invurted.com/tutorial-iscsi-security/) and performance will always be optimal if iSCSI is isolated to its own infrastructure. This can be achieved by physical infrastructure or VLANs to isolate the traffic.

In short, there should be very little to stop small to medium enterprises from adopting iSCSI solutions for shared storage. Its performance is comparable to fibre channel in most circumstances and the relative cost is less than most fibre channel solutions for a minimal performance hit.

What weighs more: one pound of bricks or one pound of feathers? Which is faster: 2 Gb FC or 1 Gb Ethernet? Hint: Both questions have the same answer.

The area of iSCSI performance and how it compares to Fibre Channel is often misunderstood. Both of these SAN interconnects are typically measured by bandwidth with “2 Gb” FC SANs dominating the market today and “1 Gb” Ethernet used for the majority of iSCSI SANs.

Which would you say is faster: a 2 Gb FC connection or a 1 Gb Ethernet connection? It’s a trick question — they are equally fast. They both transfer data at the speed of light. Bandwidth is not an issue of speed but size. Tthink about a four-lane highway versus a two-lane highway. If there are just a few automobiles traveling on either highway, drivers will be able to go the maximum speed. As more drivers travel on each road, the two-lane highway will experience a bottleneck before the four-lane highway does.

This is the same with FC and Ethernet. A 2 Gb FC interconnect has twice the bandwidth (double the number of lanes) of 1 Gb Ethernet. Bandwidth has an impact on performance when large requests are being processed. In this case, most of the work is spent transferring the data over the network making bandwidth the critical path. However, for smaller read and write requests, the storage system spends more time accessing data making the CPU, cache memory, bus speeds and hard drives more important to overall application performance.

Unless you have a bandwidth-intensive application (e.g., streaming media or backup data), the difference in performance will be minimal. Enterprise Strategy Group (ESG) Lab has tested storage systems that support iSCSI and FC and the performance difference is minimal — ranging between 5% and 15%.

In fact, an iSCSI storage system can actually outperform a FC-based product depending on more important factors than bandwidth, including the number of processors, host ports, cache memory and disk drives and how wide they can be striped.

The slowest component of the storage performance chain is the hard disk drive. It takes a hard disk drive much longer — sometimes several thousands-percent longer — to access data in a storage system than the electronic components like processors, bus and memory. The timeline for an I/O starts with a read/write command being sent to the hard drive from the application. This is followed by long, mechanical access times waiting for the drive to move the actuator, referred to as the seek process.

The seek process is by far the slowest part of storage performance. The actuator then has to spin to the data that’s been requested, which is another long mechanical process that creates latency. Next, the data is transferred from the drive to the CPU and a status handshake is performed to terminate the request. Access time associated with all disk drives, which includes seek plus latency, is responsible for the majority of the “wait time.”

Striping data
Traditional storage systems are typically limited in the number of drives across which they can stripe data. Many traditional storage systems can only stripe up to 16 drives, while more advanced products can stripe across hundreds of drives. Striping data across a large number of drives allows a system to leverage all the actuators, which work in parallel to make read/write functions a much more efficient process. Striping data across many drives increases performance and essentially eliminates the need for tuning performance and determining hot spots. Naturally, there is a cost associated with acquiring more hard drives, so a balance and consideration of price/performance is important.

In ESG Lab head-to-head testing, we configured a storage system using traditional striping methods and another one using wide striping. ESG Lab used the same workloads to compare the performance of the traditionally configured system and that of a system using a wide stripe group of 48 drives. The stripe group of 48 drives significantly outperformed the traditional method.

A comparison of Iometer results revealed a 44% improvement in the number of disk I/Os per second when switching from traditional volumes to a 48-drive wide stripe group. That is an amazing performance difference, much more than the five to 15% difference that we found between iSCSI and FC.

Some iSCSI storage systems may not have well-tuned performance optimized iSCSI target drivers. This is the fault of the storage vendor and they need to go back to their R&D group and do a better job. Additionally, ESG Lab has found that using a TCP/IP offload engine (TOE) on the iSCSI target port within the storage system can have a measurable positive impact on performance. Some iSCSI storage systems do not have integrated TOE support.

The architecture of the storage system, the speed and number of processors, the amount of memory and the intelligence of its caching algorithms, the speed the disk drives and number of drives in a stripe group, the number of host ports and the backend interconnect all play a major role in performance. I recommend that you evaluate the storage system based on all of the above criteria. It is the storage system itself that will make a bigger difference. The speed of iSCSI is not the issue.

]]> http://invurted.com/iscsi-vs-fibre-channel-storage-performance/feed/ 0