NT Embedded Is OS-Agnostic.

It's an article of faith for Microsoft

In the late 80s and early 90s, storage hardware vendors complained, loud and long that there was no operating system support for storage. OS was a processor-centric technology. But modernly, it is no longer the case. Software giant Microsoft Corporation has a clear investment in the storage space now. In the November 2000 issue of CTR, readers learned about StorLogic's involvement with embedded NT. Following up on this connection, Dave Ursino and Zane Adam from Microsoft's Embedded and Appliance Platforms Group found time to share some thoughts about embedded NT in the mass storage space.

MF: Let's start by having you give me a short technical description of embedded NT.

Dave Ursino: Basically, embedded NT takes our base operating system, NT Workstation 4.0, and embedize that. We component-ize that. And we do that because there's all these different various vertical markets and devices that people are making that have different requirements that obviously require more flexibility than the standard base operating system will allow them to do. So what we've done is taken the NT Workstation operating system and broken up the individual feature components into piece component-features that you can actually fit and choose and put back together in any way you see fit for your target device. It gives you a great level of granularity and flexibility. Therefore if I have a single purpose device, I don't need everything that's in the base operating system, I just want bits and pieces of it for my single function device. And by just taking the pieces I want, I have smaller footprints because I leave behind the features I don't need. I can even get better response time in performance in some cases. So what we've done is taken that core operating system, broken it up into components, and then provide the tools to easily use those components. NT embedded is based on NT Workstation 4.0 with service pack 5. So those are the binaries we use. They're unchanged binaries from the base product, and there's a lot of advantage to that because that platform has a lot of momentum in the industry. There are many developers out there that are familiar with that code base, there are numerous devices that are supported by that code base, off the shelf hardware and software supported by that code base, so we use that unchanged binary and allow you, through our tools, which are a target designer and a component designer, to extract the pieces of code you want to build your single function or target device. And then those tools allow you to build that unique image configuration and replicate it across those devices.

MF: Does this particular version of NT have some of the same characteristics as the base program? I'm thinking specifically of its tendency to map all mass storage devices to itself.

Zane Adam: When NT boots up or Windows boots up, it does have a tendency to, since it is a general purpose server software by definition, take all the local storage and map to it, saying that all the storage is mine. In NAS, that's alright because the storage is basically attached to the NAS box. The only time that the issue with mapping comes about is if the storage is SAN-based. When NT boots up, it scans to look for which drive the mount is and to look at all these drives as mine. In that case we use LUN masking. So if that NT server was sitting in front of a SAN deployment, and if this was an issue, then LUN masking, which can be part of either NT itself or on a host bus adapter or even on the switch level, takes care of that so NT will not mount to every single storage device that it can see.

MF: How is embedded NT going to be operating within the mass storage space? Are you looking at embedded NT as NAS specific in the short term?

DU: NT Workstation 4.0, which the product is based on, is a very leverage-able, a very adaptable code base, so I wouldn't say that we're focusing on NAS in the short term or focusing anywhere. We're actually enabling a whole host of partners to go do all kinds of unique things in the industry. Our web site features case studies and content. You'd be surprised to see a lot of the unique adaptations that people have been able to come up. The reason for that again is because there are so many people out there familiar with that code base. The code base provides a really fast time to market across all kinds of deployments because of the familiarity with it. So that being said, NAS is one of many areas that we don't particularly focus, but we enable partners to go out and do great things with these cool devices across all kinds of vertical markets. Zane can drill in on the particular NAS scenario.

ZA: To reinforce what David said, yes, Windows NT embedded scales to all products. We're focusing on mass storage right now. First, before we even address that, by mass storage are you saying just NAS or are you talking about SAN also?

MF: I thought we'd start with NAS since I think that's the immediate application. As you know, SAN is a little further out because there are issues of interoperability and security and a mature software suite to make sure SAN actually happens properly.

ZA: I'll address the SAN part, because that's the easy one. We do support Fibre Channel protocol, as well as SCSI over Fibre Channel and all. If that's supported, it can be used with a SAN without any issues. In fact, as Dave mentioned, since the binaries are the same as Windows NT 4, you can see NT 4 today deployed in SAN environments. Therefore NT embedded, by definition, also supports that environment.

MF: Let's explore that for just a second. As you know, the enterprise is still very heavily Unix influenced. How is NT making its way into that space with a focus on the mass storage?

ZA: You've brought up two different points. When you said the enterprise is Unix heavy, are you talking in the data center perspective or the storage perspective?

MF: Actually on both sides. Unix and storage don't always get along very smoothly.

ZA: Right, that's what I was going to say. Storage is mostly, if you look at SAN implementations, not really OS-based, meaning whether it's Unix, Windows, it doesn't really matter. It's based on the proprietary Fibre Channel switching capabilities that the storage vendors in SAN specially provide. EMC has its own proprietary storage protocol, same as Compaq, same as IBM. So in that case it's OS agnostic. Therefore it doesn't matter who's doing it as long as their protocol interoperates with NT. So most vendors--since Windows has a huge chunk of the middle and mid-sized enterprise and large-sized enterprise market--do support, or do interoperate, with NT. So in that sense when an enterprise, let's assume, for an example, we had a company, let's say is named Adam.com, and I'm using Windows NT today and I have a SAN environment; it doesn't matter who the SAN company is...all of them will work with NT today. It's in their interest to support the protocol. It has nothing to do with Windows as an operating system, it has to do with file level protocol or SAN protocol, in this case, which would be Fibre Channel and SCSI.

MF: How do some of the new file systems that are coming up impact your efforts with embedded NT? We've got things like iSCSI popping out of the woodwork; we've got new file systems like DAFS.

ZA: iSCSI hasn't taken a foothold yet, so we're looking at that market. We're looking to see if it becomes something real and if customer demand exists there. If it does, then we look into supporting it fully. As far as DAFS goes, basically that is built on the VI technology. In this case, there are issues with that today, like security issues. It has not been extremely well received so far in real implementation. So there is a lot of theory about it, there is a lot of noise, but we haven't seen actual implementation. So NetApp is pushing that heavily. But we haven't seen actual implementation to say that customers are really looking at it. Our methodology is that if customer requirement exists, and if it does help the system, (meaning it's still secure, does not compromise security, does not compromise performance) we will look into supporting that in the future. But currently, we're just looking at all these technologies. But it goes beyond that. There's DAFS and VI technology, there's iSCSI, SOIP is coming , all these technologies are coming, but we don't know which one is going to be the one that's going to win so we can support that. But that's all protocol. Our vision is that whatever the customer wants, when it does not compromise security and performance, we will look into supporting that.

MF: We've answered the question of storage mapping and how it impacts in NAS, I'm wondering about other efforts that Microsoft is looking at in the mass storage space. Even for Microsoft, the involvement with mass storage has been comparatively recent.

ZA: We didn't address the NAS portion of mapping, so let me just give a thirty second review on that. In a NAS, since the storage is attached locally to the network attached storage, there is no mapping issue because the NAS box owns all the storage itself. So there is no mapping issue there. The only time mapping becomes an issue is in a SAN. In a NAS box you can just take the box, put it on your network, and in 15, 16 minutes it'll just start serving files to your workstation.

MF: Yes, they're having contests about how fast they can get their NAS up and operating.

ZA: Exactly. So in that case there's no issue with mapping, right?

MF: Well there couldn't be. It would take cripplingly long times.

ZA: Yes. Not only that but since the storage is local, all of it is owned by the operating system, by the NAS operating system, in this case NT embedded. So there is no need to go out scanning for remote disks, and since there are no remote disks to worry about there is no need to worry about mapping to them.

MF: That's true, right now NAS seems to be a departmental creature, but I wonder if that will change a little bit as the data center becomes the home and the department has to interoperate.

ZA: That's a really good point and a good question. When I go visit customers, I'm seeing NAS step out of the department and going into centralized storage in the enterprise and data center, because I'm seeing implementations of like 5, 6, 10 terabyte boxes. So what they're doing is the departmental NAS' are backing up to these centralized, big data center NAS boxes. And the way I look at NAS is more like a SAN in a box. If you don't want to spend hundreds of thousands of dollars and pay a big company to charge you hundreds and hundreds of dollars an hour to maintain your SAN environment, you buy these big, big NAS boxes that can scale up to tens and tens of terabytes and be basically a SAN in a box.

MF: And you see that as an alternative to some of the outsourcing options that are popping up?

ZA: I personally do at a certain level. There will be one tier at the upper echelon that will require a SAN. But I think as NAS creeps up it's going to take over portions of the SAN market. It's kind of a disruptive technology, in my opinion, because people are not always going to have unlimited IT budgets.

MF: I don't know anybody that has an unlimited IT budget.

ZA: It's become like that. They're throwing 55% of their revenue of the IT budget on storage right now, roughly. So eventually I think they'll make a better choice where price, performance, and cost per megabyte will become more important than anything else, as long as reliability is there. As long as NAS provides the reliability, or close enough, acceptable reliability, I think it's going to scale very, very well into the data center market.

MF: Where else is Microsoft going in the mass storage space?

ZA: Breaking it down from NAS and SAN or combined?

MF: Combined. Let's call it storage networking because that seems to be where it is. At this point, you remember some wonderful phrase: the computer is the network. It seems to me now that the network is the storage.

ZA: Fair enough. So as far as storage goes, Windows has a very robust file systems and DFS. What we've done is we've scaled it to mass storage. As long as the low level protocols are supported by any vendor, NT will basically go into any storage environment and fit in. If you take, for example the StorLogic box, you can throw it into Windows, non-Windows environments and it just works, it doesn't care. Basically we're OS agnostic in storage space.

MF: And that's the key direction. OS agnosticism is beginning to be a significant factor when you've got these very large installations that have just a plethora of equipment, they used to be islands in storage. Do you see those islands coming together?

ZA: Yes I do, but I'll address it in two different ways. First, OS-agnostic is a key word, but there is a fine distinction. The OS agnostic that I'm talking about is the client operating system being agnostic. But network attached storage itself can and does benefit from the features that Windows provides versus the other OSes. Think about interoperability: you can put embedded applications on NAS, mass driver support, all those things do not exist for proprietary OSes. So when I have a NAS box, it's important to me that I should be built on a platform that scales and can be flexible, like Windows. And because I have a scalable and flexible platform, I do not care about the clients that attach to it. So the customers themselves, when they choose a NAS box, whether they be Linux customers, Unix customers, or Windows, it's very important that the NAS box is flexible and interoperable. In that case, one of the key decision making criteria would be that it should be Windows-based or, as we say, Windows powered, r ather than going with a no-name or proprietary OS. In. that case it is not agnostic, but the box itself is agnostic to who connects to it. So that's the fine distinction. As far as the storage islands coming together, in that case I do see that and the way I see that is storage over IP. If IP, instead of Fibre Channel just by itself, starts becoming the underlying protocol support storage, then I do see WAN support for storage, and less of a need for these islands to pop.