Although Windows Server 2008, with its many storage feature updates, was released last year, the updated version of Windows Storage Server was still under construction until last month. But Windows Storage Server 2008 is available to manufacturers today! Expect to see some new Intel-based storage array announcements in the coming weeks!

For my personal experiences with Windows Storage Server 2008, see my blog post, I Can Finally Talk About Windows Storage Server 2008!

What’s new in Storage Server 2008? Plenty! Most of the features are inherited from Windows Server 2008:

1. Server Message Block (SMB) 2.0 is a re-working of the traditional Windows NAS protocol. Also present in Vista and Server 2008, SMB 2.0 reduces the notorious chattiness of SMB, combining multiple commands into a single packet, as well as allowing more simultaneous open connections and larger buffers as well as durable file handles.  Performance gains using both SMB 2.0 clients and servers has been phenominal with Tom’s Hardware showing a 5x gain in throughput over the Internet!
2. The NFS server (also present in Windows Server 2008) has been updated.
3. A new MMC snap-in called Storage Explorer lets you manage WMI-compliant SAN devices.
4. File Server Resource Manager (FSRM) is a full-featured storage resource management (SRM) application and has been improved greatly for both the Server and Storage Server versions of 2008 with quotas, file screening, and advanced reporting.
5. DFS-R and DFS-N are tweaked – Jose Barreto gets into this on his blog.
6. Smaller or branch offices (and low-end storage array vendors) will be interested in using BitLocker full-volume drive encryption to protect their data.
7. Storage Manager for SANs (SMfS) allows you to perform basic storage array administration tasks within Windows.
8. The Volume Shadow Copy Service (VSS) and DFS interfaces are improved and are now scriptable with PowerShell (through WMI).
9. The new but not yet complete Windows Server Backup system replaces the outdated and limited NTBackup system. Although it includes bare-metal recovery, Server Backup isn’t ready for prime time in my opinion. I’m looking for major improvements in R2!
10. Search 4.0 and 2008 SP2 adds full-text search for files stored on a Storage Server.
11. Server 2008 now automatically aligns filesystem boundaries with storage, which was one of those dark and secret skills us storage guys used to share amongst ourselves.  This can increase performance in high-I/O environments.
12. NTFS (in both Server 2008 and Vista) now has symbolic link support, just like UNIX and Mac OS X, and SMB 2.0 supports symlinks as well.
13. NTFS was also tuned and tweaked a bit for better stability and crash recovery.
14. The updated virtual disk service (VDS) supports LUN shrinking, online/offline and read-only/read-write settings, and SAN policies so new LUNs can be treated as either online, offline, or shared.
15. Failover clustering is simplified, requiring just a few clicks to set up.

Although all of these are also present in the basic Windows Server 2008 install, Windows Storage Server 2008 includes some unique features:

1. The included iSCSI target software is unique
   1. It’s been updated to support failover clustering
   2. It now includes VDS and VSS providers
   3. It’s been ported to StorPort
   4. Installation is now done in the standard Windows manner, with an MSI not an EXE
   5. You can now set up an IPv6-only iSCSI SAN and specify initiators directly using their IPv6 addresses
   6. CHAP secret security is enhanced
2. Single-Instance Storage (SIS) is the second major Storage Server differentiator, providing file-level deduplication
   1. SIS used to be limited to 6 volumes per node, but now scales to 128
   2. SIS now supports clustering, though SIS doesn’t span nodes
   3. A new command allows one to undo single-instancing instead of copying all of a volume’s content to another drive
   4. Enabling SIS is simpler – it’s now just a checkbox per volume in the Share and Storage Management UI
3. Many performance tuning tweaks are standard out of the box, though readers of the Windows Server 2008 Performance Tuning White Paper might be able to perform these on their own. One major standard tweak was removing 8.3 naming and disabling aliasing on filesystem – this led to an an 8% performance gain right out of the box.
4. Remote administration through HTTP is very cool, and ought to be standard on every version of Windows Server! Just point a web browser to the server and you will have an ActiveX or Java-based RDP client without installing any software.
5. Licensing is one more unique aspect. Storage Server does not require client-access licenses (CALs) so any number of clients can access the system without worrying about license management.

All in all, Storage Server 2008 is a solid move forward. I expect that the ability to do single-instance storage at full native speed will be very useful for corporate file servers and similar applications, and the enhancements overall are welcome as well. But this will be the last release of Windows Storage Server as a separate product. From now on, Microsoft simply release OEM storage server software on top of their standard Windows Server versions for OEM’s to use. There will not even be a special Service Pack 2 version of Storage Server 2008. Instead, expect OEMs to provide the regular Server 2008 SP2 as a suggested or required update to Storage Server users.

Microsoft is detailing the new version of Windows Storage Server 2008 in a webcast Thursday at 8 AM Pacific. You should also check out the official Microsoft site, and the Microsoft Storage Server blog, especially their post, A Brief History of Windows Storage Server Releases.

© Stephen Foskett for Gestalt IT, 2009. | Windows Storage Server-Based Systems Step Into 2008
Read more posts categorized as All, Exclusive, Featured, Storage, Top Story

It does not cover SAN in any detail and the FC coverage is limited to this is how you present a LUN as a fibre channel device but this led on to some interesting conversations around the complexity of FC vs iSCSI.

I, for sometime, have been saying that the complexity of FC is over-stated and actually it is not really any harder than iSCSI. This often leads to looks of disbelief and complete disagreement, it is almost as if I am spouting heresy. The iSCSI camp think I am mad and the FC camp seem to think that I’m diminishing them.

But, if you take OnTap; there is really very little difference in how you present a iSCSI LUN compared to how you present an FC LUN. It is certainly no harder to do FC from an array management point of view.

And then we go to the host; lets take Windows for example. Now this is where I think a lot of the perception of the simplicity of iSCSI comes in; Microsoft have implemented a very nice software initiator, it’s there and it’s standard. A bit of pointing and clicking and you are there.

Unfortunately, traditional FC cannot be implemented completely in software and needs FC HBAs, hence we need to install additional drivers and software to make it work; these are not part of the standard Windows build and suddenly it all becomes ‘complex’.

If we go to Unix, we end up mucking about configuration files in general for both iSCSI and FC; so really it’s not any harder to do FC than iSCSI.

So if it’s not hard to do at the host level and if it’s not hard to do at the array; where is it hard? And this is where I think it becomes more interesting; it’s the network! Is a large Data Centre IP network harder to set-up than a large Data Centre FC network?

Arguably, the FC network is easier but it is different. In the FC network you have a lot less to worry about; you run less protocols, services, it’s non routeable, the security model is simpler, there is less potential for different workloads to clash, you do not have address space management to worry, you do not have name services to worry about and if I were a Network Admin, I would argue that it’s them who are being diminished by this constant claim that iSCSI is easier.

To do either iSCSI or FC properly is probably equally hard. If you just want to bung a block-level array in and do not care about segregation of traffic, quality of service, don’t care whether your IP back-up traffic and IP storage traffic contend and make your back-ups over-run. If you know you’ve got enough headroom on your existing IP network to carry your block traffic, go ahead with iSCSI; it’s easier because you’ve already got the infrastructure in place.

But if you want put in place a dedicated storage network; the choice is not as clear-cut as people would like to make out. Even when you start looking at cost; yes GbE is cheaper than FC but FC is generally running at 4 gig now and is faster. FC ports are in my experience are significantly cheaper than 10GbE ports. So if you need the throughput, then FC might well be cheaper than iSCSI.

There might be a small saving in the number of FTEs you require as you could have a single Network team but I believe that FC is actually so simple that if you get over the politics, you could have a single Network team which manages both FC and IP. This is purely politics and a turf-war!

If you are a small shop and you have just a few administrators who do everything, iSCSI might also make sense but don’t believe FC is hard; administering a small SAN with a couple of switches might not add a huge amount of additional overhead.

Neither iSCSI or FC are wrong answers but make sure that when you have got to the answer, you show your working. And when a vendor tells you what the answer is, ask them to show your their working and challenge it.

Of course, if I was building a green-field data-centre and could simply start again, I’d probably look at putting in Data Centre Ethernet which would give me the option of FCoE. I would have a single Network team from the get go.

It’ll be interesting to see if Microsoft bundle a software initiator for FCoE into Windows at some point; then I think we’ll see perceptions of complexity change again.

Yes, I’ve completely ignored NAS but actually many of the same arguments apply.

I’d welcome some thoughts; that’s if anyone is still reading and not exploded in apoplectic rage at the heretic!

© Martin for Gestalt IT, 2009. | Protocols, Religions and Heresy!
Read more posts categorized as All, Featured, Storage

As usual, expected from EMC, the Big Bang!!!!!

So after a lot of speculation, finally the Next Generation Celerra is released now. Again this time around, EMC is pushing the technology towards unified storage, deduplication and virtual provisioning giving away some bells and whistles at no cost.

Here are the highlights of the product.

Celerra Next Generation Ultra Scale Architecture, Unified Storage with Deduplication, Virtual Provisioning, File Level Retention, Support for Flash Drives – 30X IOPS, LP SATA Drives 5.4K, 32% Energy Savings, 22% lower TCO, 960 drives, 960TB of RAW Storage.

Release date: 24th Feb 2009

Product availability: Feb 2009, the NS-8G and NS-960 might be available early March 2009.

Models: NS-120, NS-480, NS-960, NS-G8 (Gateway Version).

Introduction of LP Sata Drives: Low Power SATA Drives 5.4K RPMs.

Introduction of Flash Drives in Celerra: 30X IOPS, introduction of Tier 0.

Cost: Low CapEx, OpEx. Customer installation available with Low and Medium profile celerra’s. High End Celerra’s available to install through ASN Partners or by EMC.

Protocols Supported: NAS, MPFS, FC, iSCSI

Software: Deduplication (no cost), Virtual Provisioning (no cost), Startup Assistant (no cost), Celerra Manager (no cost), Volume Manager (no cost), Celerra Snapsure (no cost) –

Energy Efficiency: 32% less energy consumption

Lower TCO: 22%

Build on: Intel Xeon Chips

Choice of Delivery: File Based or Block Based, NAS to MPFS for throughput, iSCSI to FC for throughput

NS-120
Supports 120 Drives
Supports Flash Drives
1 or 2 Blades
64TB
120TB RAW

NS-480
Support 480 Drives
Support Flash Drives
2 or 4 Blades
192TB
480TB RAW

NS-960
Support 960 Drives
Support Flash Drives
2 to 8 Blades
760TB
960TB RAW

NS-G8
Supports 4 Arrays behind NS-G8
2 to 8 Blades
896TB RAW

Applications usable on Celerra: VMware, Oracle, MS Exchange, MS SQL Server, Windows, Linux File Server

Celerra Integration Available: With VMware, Oracle, MS Exchange, MS SQL

Classifications:
High End: NS-G8, NS-960
Mid-Tier: NS-40G, NS-480, NS-120
Low End: NX-4

Compliance: Meets file level compliance related to SEC Rule 17a-4(f). Also available for the Celerra is 3rd Party Compliance.

Celerra File Level Retention: Celerra is being pushed to allow Filesystem archiving. For Application and Filesystem archiving you will still need a Centera.

ROI Models: Better ROI on Celerra models than any comparative NetApp models.

Haven’t had a chance to play with it yet, but hopefully soon and looking forward to it.

© Devang for Gestalt IT, 2009. | Next Generation Celerra – Unified Storage with Deduplication
Read more posts categorized as All, Storage

I recently lead a session at CloudCampIndy on “App Scalability in the Cloud”.  Many of those who participated were app developers as well as general business people.  We talked about understanding your application regardless of who developed it and the impact that cloud computing would have. For now, application scaling will be similar in both.  The difference will be how you add and pay for capacity.

Here are some points made:

• Pick or develop apps with scaling in mind from the start
• Virtualization is changing how you deploy your apps
• Horizontal scaling apps do better in the cloud
• Vertical scaling works but is more limited
• Developers benefit from knowing their app’s impact on the underlying infrastructure (Is my app read or write intensive? Does it cache well?)
• Caching is a cheap way to improve database performance
• Database replication (master/slave) or sharding is another way to scale
• Have at least two providers if you need disaster recovery capabilities (1 could be yourself)
• Products like VMware’s vCenter AppSpeed will make scaling out an easy automated process

Whether you’re running SAP or some web application that needs to scale, you need to understand bottlenecks in a system and ways of resolve them.  Disk is usually the slowest component in an architecture.  However, before you go spend $150k on an expensive SAN, make sure you’ve optimized your application and added caching where useful to speed things up.  If you’re in the cloud (Amazon EC2, Bluelock, Slicehost, Joyent etc.) you will pay for the resources you use so it is wise to optimize your architecture in the beginning.

© edsai for Gestalt IT, 2009. | Scalability in the cloud
Read more posts categorized as All, Cloud Computing, Featured, Server Virtualization, Storage

  

Frankenweenie saves young Victor in Tim Burton’s macabre short film

When is a solution integrated and when is it a Frankenstein-like mashup of tangled tech? Apparently, that line is crossed when it’s your competitor’s offering…

In my time in the storage industry, I’ve seen enough franken-storage come and go to make me skeptical whenever a new “integrated” solution is announced. But a lot of this stuff works just fine, so I also know that integrated solutions aren’t always bad!

The latest industry blog flame war centers around NetApp’s recently-announced solid state storage solution, which pairs a V-Series NAS head and a Texas Memory Systems RamSan-500 flash storage system. Perhaps NetApp’s Val Bercovici did get a bit over-excited in his post on the topic, but he wasn’t just talking about the RamSan: He was laying out how NetApp’s WAFL technology can work in an SSD world, and using some recent performance test numbers on that solution as well as their PAM cache cards as an illustration of this.

The next thing you know, we have EMC’s Storagezilla and IBM’s Barry Whyte calling the company out for what they (and others. like Storagebod) see as an underwhelming product offering. That’s all well and good, and I’ll let the reader decide if NetApp’s moves warranted a press release, but now things have gotten uglier…

EMC’s Chuck Hollis called the whole RamSan idea to account, saying it was “Frankenstorage“, causing NetApp’s Alex MacDonald to engage in a little “I know you are but what am I” in reference to EMC’s CLARiiON/Celerra “unified storage” solutions.

It’s time to bring some sanity to this whole integrated solution concept. Every product in the storage world is an amalgamation of OEM parts to one extent or another, and there are always integration issues. Certainly many of EMC’s offerings could be the subject of name-calling: They use STEC SSD drives in the DMX, they use Quantum deduplication engines in their CDLs, and their Celerra NS platform does include a complete Fibre Channel SAN behind the curtain. But they’re not alone, and not even wrong in doing this: Every vendor relies on OEMs, and as a wise man said, “working with an OEM gives you the flexibility to pick best of breed technologies” and that’s exactly what customers want. Any objective person would welcome qualification and integration of TMS’ RamSan with a solid platform like the NetApp V-Series – it’s a certifiable win for the customer. Just like they would be happy to see EMC leveraging great technology from Quantum and STEC.

Chuck goes on to point out some downsides to these OEM combinations, and they’re certainly fair criticisms:

• When you’re buying this from this guy and that from that guy, it’s bound to cost more because everyone needs their cut.
• Since all attempts at unified heterogeneous device management have failed, a combo is certainly harder to manage than a single device.
• With multiple vendors in the mix, fingerpointing is common once support is needed.

But these criticisms can be mitigated by the vendors themselves. They can give up some margin in order to gain market share. They can create unified management interfaces for the combinations they sell and support. And they can really support what they sell, refusing to give in to the temptation to say “not my problem” when the going gets rough. And companies deal with these problems all the time! Frankenstorage doesn’t have to be so scary…

© Stephen Foskett for Gestalt IT, 2009. | The Difference Between “Integration” and “Frankenstein”
Read more posts categorized as Featured, Storage

When you decide to maintain a server’s existing iSCSI partitions as a VM, there are several configuration considerations to plan for.

Multipathing Support for iSCSI is no longer needed in the VM

When you were configuring the iSCSI initiator chances are you used two physical network interface cards (NICs) for a redundant connection in the server operating system to the storage. You then used the NIC manufacturer’s drivers/management software to create a team and a virtual ip address. Your SAN was configured to allow an iSCSI initiator to connect via that NIC team virtual ip address.

As a VM that same team ip address will probably still be maintained as the initiator, but the need for two NICs and the former manufacturer’s drvers and software will be removed. The VM only needs a single vNIC to the iSCSI storage. The virtual host should be configured with a vSwitch mapped to two pNICs. Therefore the virtual host provides the redundant connection to the storage.

Be sure to remove the team configuration and the old NIC drivers and software.

Dedicate a vSwitch with it’s own pNICs for the VM iSCSI traffic

Separate the VM’s iSCSI traffic from the virtualization host’s iSCSI traffic. You could add an extra portgroup to your iSCSI vSwitch in VMware ESX for example, but ideally, you want 2 NICs dedicated to the host, and 2 other NICs dedicated to the VM(s). This requires separate vSwitches. This will maximize performance and provide redundancy.  

Consider the cables needed to the SAN switches

Before P2V each server needed 2 cables to the storage switches for redundancy. After P2V, each virtualization host will need 4 cables. Two of the cables will be replaced by the connection to the host’s dedicated LUNs where the VM’s operating systems and and other partitions are encapsulated. The second set of two cables will be for the VM’s initiator to access it’s own iSCSI partitions. 

Disconnect the iSCSI initiator before P2V

This is not a must do, but rather a safety net for the P2V migration process. Disconnecting the server’s iSCSI initiator ensures the LUNs you need to maintain will not be selectable as disks to be converted during the migration.

Be prepared to recreate any file shares and permissions

If you disconnect the iSCSI initiator as previously mentioned then be prepared to recreate any file permissions and shares that were configured. To be honest, I am not sure of the best way to prepare for this or if it’s even necessary, but in my experience I have had to recreate shares. Thank goodness it was never a complex user or department hierarchy as you can imagine the impact and administrator time needed that overlooking this would cause.

Check out this VMTN Communities thread on this topic too: VMware Communities: P2V when server has a LUN through iSCSI? …

© Rich for Gestalt IT, 2009. | P2V strategy for a Physical Server with an iSCSI Partition
Read more posts categorized as Server Virtualization