Seite 3: Einblicke in Microsofts Linux- Open-Source- Software-Lab

Inhaltsverzeichnis

4 Eine Open-Source-Blase in einem Microsoft-Meer

Interessant und unerwartet ist die Dynamik, die sich daraus ergibt, dass das Labor mit seiner umfassenden Linux- und Unix-Umgebung eingebettet ist in die weltweit größte, komplett aus Microsoft-Produkten bestehende Umgebung, mit der alle Microsoft-Mitarbeiter unterstützt werden. Dazu gehören Windows-basierte Security-Services, Internet-Proxies, Mail-Services, Human-Resource-Services und alle anderen Systeme, die im Unternehmen verwendet werden.

Wir mussten also Wege finden, um die Interoperabilität dieser unheimlich komplexen Umgebung nicht nur im Labor zu sichern, und uns dabei nicht auf die Microsoft-Umgebung wie Exchange oder Active Directory beschränken, sondern auch die Interoperabilität zwischen dem Labor und Microsoft gewährleisten.

Viele Kunden, die ihre Systeme in gemischten Umgebungen einsetzen, haben uns gefragt, wie wir Linux, Unices und andere OSS in einer Microsoft-zentrischen IT-Umgebung verwenden: "Wie schaffen wir es, dass diese Systeme zusammenarbeiten? Wie sollte der Einsatz der Software erfolgen? Welche Tools verwendet Microsoft?"

Die vielen unterschiedlichen Management-Tools, die wir verwenden, entsprechen der Anzahl an Servern, Betriebssystemen und anderen Anwendungen, die in unserem Labor eingesetzt werden. Für das Software-Management und die Verteilung verwenden wir Tools wie Microsoft Systems Management Server mit Vintela Management Extensions (VMX), Kickstart, Red Carpet, Portage und Red Hat Network. Um die Infrastruktur des Labors fernzuverwalten, nutzen wir SSH, VNC, X-Windows Tunneling und Windows Terminal Services. Auch hier ist sehr unwahrscheinlich, dass ein Kunde alle Tools verwendet. Wir versuchen aber, so viele verschiedene Szenarien wie möglich zu reproduzieren, die die unterschiedlichsten Kunden verwenden könnten. Auf diese Weise erhalten wir tief greifende Erkenntnisse zur Lösung von Problemen.

Durch diese unterschiedlichen Linux-orientierten Workloads, Server, Desktops, Laptops, Software- und Gerätekongurationen innerhalb einer komplexen Microsoft Umgebung können wir täglich mit der Interoperabilität experimentieren und sie testen. Im Verlauf dieses Prozesses ergeben sich interessante Erkenntnisse: simple Problemlösungen, zum Beispiel, wie man mit Linux in einer Windows-Umgebung ins Internet gelangt, aber auch komplexere Fragestellungen, beispielsweise, wie man die Authentizierung gegen Active Directory von Linux-Clients durchführt oder wie man OSS-Mail-Clients mit Microsoft Exchange Server verwendet.

5 Aufbau und Testen der Interoperabilität im Labor

Äußerst interessant beim Testen der Interoperabiliät der von uns verwendeten Management-Tools war ein Szenario, in dem der Microsoft Systems Management Server erweitert wurde. Ziel war die Verwaltung von Unix-, Linux- und sogar Apple-Systemen durch den SMS, der so aufgebaut wurde, dass ein offenes Protokoll mit der Bezeichnung OpenWBEM genutzt werden konnte, um mit anderen Software-Elementen zu kommunizieren, zum Beispiel mit VMX, die auf Nicht-Microsoft-Systemen laufen. Durch die Erweiterung des SMS unter Verwendung von VMX waren wir im Labor in der Lage, das SMS-Framework für die Verwaltung sämtlicher Server und Clients einzusetzen. Dieses Setup stellt denjenigen im Labor, die daran gewöhnt sind mit Windows zu arbeiten, ein bekanntes Tool zur Verwaltung von Nicht-Windows-Systemen zur Verfügung. Gleichzeitig stehen unseren Linux- und Unix-Forschern die Management-Tools zur Verfügung, mit denen sie vertraut sind: SSH-Clients, X-Windows und Red Hat Config Tools. Abbildung 1 zeigt das SMS-Interface zur Verwaltung unserer Linux-Server im Labor.

Darüber hinaus haben wir wichtige Informationen über den Einsatz von kommerzieller Software von Drittanbietern zur Erweiterung von Microsoft-Produkten erhalten, vor allem bei der Verwendung einer Centrify-DirectControl-Lösung zur Integration unserer Unix- und Linux-Plattformen mit den Identitäts-, Zugangs- und Policy-Management-Services von Microsoft Active Directory.

Vor dem Einsatz von DirectControl musste sich jeder Mitarbeiter mittels Benutzernamen und Passwort auf jedem Server anmelden, um sich auf einem unserer Server einzuloggen - lästig, wenn mehr als 300 Server und viele unterschiedliche Betriebssysteme installiert sind. Durch das Einrichten einer Active-Directory-Domäne wurden für jeden Mitarbeiter ein Domänen-Benutzername und ein Passwort erstellt, mit denen wir auf alle Server zugreifen können, nachdem wir uns durch einmaliges Anmelden in die Domäne eingeloggt haben. Damit steht uns eine leistungsstarke Authentizierungslösung zur Verfügung. Vielen ist nicht bewusst, dass ein Active-Directory-Server die Authentizierung von Linux-Rechnern durchführen kann - ich habe vor CIOs, die diese Lösungsmöglichkeit nicht kannten, entsprechende Vorträge gehalten.

Das Linux-/Open-Source-Labor spielte auch eine Rolle bei der Unterstützung des Test-Supports von Microsoft für Linux in Microsoft Virtual Server 2005 SP1, der die Betriebssysteme Linux und Sun Solaris auf Windows-Servern virtualisieren kann. Wir haben diesen Support intensiv unter Einsatz von Virtual Server 2005 auf einem Single-Machine-Modell getestet und alle 48 Linux-Distributionen als Gastbetriebssystem verwendet. Mit diesem Setup konnten wir unterschiedliche Linux-Distributionen und alle Server, die auf einem Microsoft-Betriebssystem laufen, testen, ohne separate Server für jede Linux-Maschine einzusetzen.

6 Unix- und Linux-Experten sprechen mit Windows eine bekannte Sprache

Die Interoperabilität von Produkten ist ein wichtiger Aspekt. Eine größere Problematik entsteht allerdings dadurch, dass viele Unix- und Linux-Experten mit Windows nicht vertraut sind.

Als langjähriger Unix-Experte besteht für mich eine der größten Schwierigkeiten in einem Windows Data Center darin, dass keine Verbindung zwischen meiner Sprache, also meinen Kenntnissen und meinem Wissen über Unix, und der Sprache der Windows-Plattform vorhanden ist. Diese Inkongruenz lässt sich auf unterschiedliche Weise beheben, zum Beispiel durch Verwendung des Subsystems für Unix-Applikationen in R2, durch Einsatz eines Fremdproduktes wie CygWin oder sogar mit einem Virtualisierungsprodukt. Aber viele dieser Migrations-Tools dienen lediglich dazu, eine Anwendung von einer Plattform auf eine andere zu übertragen. Was ich eigentlich benötigte, war eine integrierte Technologie, die Teil von Windows war und die mir, dem langjährigen Unix-Experten, dabei helfen würde, auf einem Windows-Server eine vertraute Sprache zu sprechen.

Mit der Entwicklung einer solchen Technologie beschäftigt sich derzeit unser Windows- Server-Management-Produktteam. Unter der Bezeichnung Monad wird eine Befehlszeilen- und Shell-Umgebung der nächsten Generation für Windows erarbeitet, die unter .NET läuft. Im Rahmen des Projektes besteht Microsofts Vision darin, die einfache Automatisierung für die lokale und ferne Administration zu ermöglichen, indem wir eine konsistente, schnelle, umfassende und zusammensetzbare Befehlszeilen- und Skripting-Umgebung zur Verfügung stellen, die die gesamte Windows-Plattform umfasst. Für einen Unix-Experten ist die Möglichkeit wichtig, eigene Befehlszeilen und eine eigene Skripting-Umgebung zu erstellen, die denen aus der Unix- und Linux-Welt ähneln, um die Windows-Umgebung besser kontrollieren und die Barriere zwischen Unix und Windows deutlich reduzieren zu können.