2004-001-tgd
Windows Futures (DRAFT)

Document revision: 0.1 - 09/13/2004 (wcw)
http://asg.web.cmu.edu/arch/ao/2004-001-tgd

1.0 Question Summary

DNS Naming of Windows Domain
1. ANDREW.AD.CMU.EDU vs. ANDREW.WIN.CMU.EDU
2. Upgrade the domain vs. re-install
Server storage architecture
File service for the DSP Windows Environment
Roaming profiles for Windows and file service for Clusters

2.0 Opinion Summary

2.1 DNS Naming of Windows Domain

2.1(a) `ANDREW.AD.CMU.EDU` vs. `ANDREW.WIN.CMU.EDU`

The primary concern with ANDREW.AD.CMU.EDU was the precedent it may set with other departments. We've already had instances where departments would attempt to create a Windows domain in their third level zone and so we did not want to be using this namespace when we tell everyone else they should be using WIN.CMU.EDU.

The architecture group's opinion is continuing to use ANDREW.AD.CMU.EDU is reasonable as long as the following conditions are met:

No additional domains are to be added under AD.CMU.EDU
The Windows group will stop running DNS servers and the DNS service for AD.CMU.EDU will be transitioned to DDNS servers run by the Network Group.
AD.CMU.EDU is considered a legacy namespace/domain. In particular, if the ANDREW domain needs to be reinstalled then the domain will then be moved under WIN.CMU.EDU
Do the phase-out and transition (or revisit this issue) within the next 5 years.

The architecture group also recommends the following:

Update and publish the document on how to create your own windows domain.
Ensure that the topic on how to create a windows domain is brought up periodically during the Departmental Computing Forum so that departmental administrators are aware that they can't just go do this themselves like they could under Windows NT 4.

2.1(b) Upgrade the domain vs. re-install

The Windows Group asserts that re-installation would be a time-consuming process that provides little benefit. As such, the group would prefer to use the (already) upgraded domain as the basis for future growth.

The architecture group's opinion is that this is primarily an operational issue and the consequences of either approach are mostly localized to the Windows group.

However, the architecture group would like to raise the following points for consideration:

The architecture group does not believe that a full and complete audit of every object can be effectively done. As such there will be "cruft" left over from the upgrade.
The usage of the current domain is fairly low, especially if you remove machines that are in our direct administrative control (i.e. clusters). As such, it would seem better to be reinstalling now, before you push for a growth phase, rather than delaying it and having a larger re-install project.
ANDREW.AD.CMU.EDU has support for "legacy" systems, e.g. those that did not support Kerberos authentication. ANDREW.WIN.CMU.EDU was supposed to be a "fresh start" without having to worry about legacy clients.
While the Architecture Group does not currently have a statement on the creation of special passwords for special services (i.e. domain passwords), it is considered to be bad and not something that should occur.

2.2 Server storage architecture

Computing Services has been using a direct attached storage model. With Windows filesharing and other projects are coming up where weaknesses in the direct attached storage model are becoming more problematic.

The Architecture Group's opinion is that not enough investigation has been done on the various storage architecture directions keep with the status quo. Specifically,

If everything is equal, then stick with direct attached storage.
If there are compelling reasons to do something different, then that option should be fully investigated.

The Architecture Group recommends:

Investigating the current state of storage technology and a storage strategy for Computing Services servers/services be developed within the next year.
A study be done to see if there are general campus storage needs that can be also be addressed at the same time.

2.3 File service for the DSP Windows Environment

The Architecture Group does not understand the requirements for this project. Specifically, what are the assumptions and models for the service.

The Architecture Group recommends:

A study be done to understand the user requirements for this service. [done already?]
A study to be done to understand who the users of this service and would they use the service?

2.4 Roaming profiles for Windows and file service for Clusters

There are similar concerns with this service and the previous question posed.

However, the Architecture Group understands work is currently underway to deploy something as early as Spring of 2005.

The Architecture Group recommends the following:

The current work underway should clearly document what services are to be provided and what the assumptions and limitations of the services would be.
There should be a clear understanding of the dependencies, especially the resources required outside of ISAM. See section 3.4 for more details.
A study be done to validate that the service as proposed by ISAM will meet user expectations.

3.0 Detailed Discussion

3.1 DNS Naming of Windows Domain

3.1(a) `ANDREW.AD.CMU.EDU` vs. `ANDREW.WIN.CMU.EDU`

The major points that were considered include:

There will only be one domain and that domain is to be ANDREW.AD.CMU.EDU.
Because AD.CMU.EDU is an "empty root" domain, it creates a dependency with the child domain. As such, one can not rename ANDREW.AD to ANDREW.WIN
ISAM and NG assert that NG should manage DDNS ANDREW.AD and remove the reliance on Windows DNS services.
NG routinely enforces cleanliness in third-level domains - for example, CS doesn't have cs.cmu.edu *and* scs.cmu.edu, though an argument had been made.. Maintaining all the legacy domains does add some to the administrative load for DNS support.
A Google search for 'create windows domain' in cmu.edu does not result in any documentation coming up for people who want to create a windows domain on campus.
Before Windows 2000, one could create a domain without any central support. After Windows 2000, in order to have a fully functional and connected domain, you must work with Computing Services. This may not be well understood by everyone yet given the previous history.

3.1(b) Upgrade the domain vs. re-install

The major points that were considered include:

Scheduling and operational concerns led ISAM to recommend against re-installing and re-creating an ANDREW.WIN domain.
Previous experience leads us to believe that an upgrade of the underlying OS may not upgrade all the objects. In fact, we've seen the case where a GPO object that was created early on did not have all the attributes that a later object had.

3.2 Server storage architecture

The rough framework that we decided on were as follows:

Direct Attached Storage [provides block level storage]
1. SCSI
2. Fibre
SAN [provides block level storage]
1. iSCSI
2. Fibre
NAS [provides file level storage; may be backed by a SAN]

The current storage architecture has RAID units and disks directly attached to a single computer. Part of the reason Computing Services has been able to continue to do this is that the server software understands the data virtualization and so there is no need to put it in the disk subsystem (e.g. Cyrus Murder, AFS).

Going with native Windows filesharing makes this more difficult. While there is some degree of virtualization obtained by Dfs, it is fairly primitive. Also, ISAM has a project underway that is looking at database clustering (GridApp). The recommended storage system for this is NAS (NFS).

There are many interesting developments in the storage area:

iSCSI appears to be gaining widespread adoption. The main attraction of iSCSI has been TCO. In the data center, instead of having to run a different (fibre) network, you can leverage your existing TCP/IP network. This leverage includes common network management.
iSCSI also provides an interesting opportunity to provide raw block storage to people outside of the datacenter.
Panasas (http://panasas.com) and Spinnaker (http://www.spinnaker.com) provide NAS solutions which are similar to our current storage management strategies with AFS. Other companies such as Bluearc (http://www.bluearc.com are also worth investigating.

3.3 File service for the DSP Windows Environment

The architects noted the following:

There was a general belief that all Windows DSP clients would be (or at least should be) in the domain. This was not validated.
A profile of the DSP clients, including their current usage of the Windows space, was not available. Similarly, a projected usage or desired usage of current or future clients was not available.
It was unclear how much sharing was required/necessary between Windows and other platforms (i.e. Mac, Unix, web, etc.).

An overview of the Windows technology that to be used can be found in [3].

3.4 Roaming profiles for Windows and file service for Clusters

The architects noted the following:

Most of issues in 3.3 exist here.
Roaming profile service brings up the same problems with IMSP. For example, what is the role of the Help Center with regards to resetting corrupt profiles?
There is no current discussion on quota management. How do users increase/monitoring/get hit by over quota situations?
There is no current discussion on the impact of the network. Is a 100Mbit connection sufficient? Any checks of the network topology to clusters to ensure that it is gig to the switch?
Backups and restorals - what can be expected and who needs to do this work?
ISAM staff are already working on a deployment plan which should answer a number of the technology questions and/or provide enough detail so that other stakeholders (e.g. Help Center) can provide resource estimates of their own. The hope/expectation is that there is "low hanging fruit" and a deployment of some form (perhaps a pilot) can proceed in the Spring 2005 timeframe.

An overview of the Windows technology that to be used can be found in [3].

4.0 Additional Architect's Commentary

[none]

References

[1] Poepping, Mark. Original Opinion Request. September 2, 2004. [txt]

[2] Redmond, Brian and Goth, Jenn. Active Directory Restructing Recommendations, V2.0-FINAL. September 7, 2004. [pdf]

[3] Redmond, Brian. DFS and IntelliMirror Information, v1.2-FINAL. September 7, 2004. [pdf]

[4] Wong, Walter. Comments on Dfs and IntelliMirror v1.1. September 1, 2004. [txt]

ChangeLog

0.1  - 09/13/2004 - Initial draft

2004-001-tgd Windows Futures (DRAFT)