Testfeld

Viele neue Programme oder eigene Entwicklungen sollten nicht ohne einen Test auf die Produktion losgelassen werden. Nur wo sollten Sie so etwas testen? Ganz klar in einer TestUmgebung, die hierfür bereit steht. Damit stellt sich dann aber die Frage, was ist eine ausreichend geeignete TestUmgebung. Reicht ein frisch installierter Windows und Exchange Server auf einem eigens bereit gestellten PC ohne Verbindung zum produktiven Netzwerk ausreichend ? Reicht die gleiche Installation in einer virtuellen Umgebung (siehe auch Virtuelle Server) aus ? Es gibt quasi drei Optionen:

• 1:1 Kopie
  Sie versuchen eine komplette Kopie der Produktion im Testfeld aufzubauen. Ihre Tests sind zwar dann sehr aussagekräftig, aber lohnt sich der Aufwand ?. Lasttests sind natürlich möglich aber nur dann aussagekräftig, wenn wirklich auch alles identisch ist. Meist scheitert diese Lösung an den Kosten oder dass ein entsprechendes Testfeld sehr schnell kannibalisiert wird, d.h. bei Engpässen und Problemen in der Produktion als Ersatzteillager dient. Zudem ist es meist sehr viel weniger aktuell als die Produktion und parallele Tests mehrerer Produkte sollten zugunsten der Aussagekraft vermieden werden.
• Reduzierte Kopie
  Wenn eine komplette Kopie nicht möglich ist, dann versuchen viele Firmen eine Kopie der relevanten Komponenten der Produktion zu übernehmen, z.B.: nur einen Domänencontroller einer Domäne statt alle oder nur eine Teilmenge der Produktionsdaten. Das schwächt natürlich die Aussagekraft der Ergebnisse, vor allem da diese Kopie erst mal wieder "Funktionstüchtig" werden muss. Als Administrator müssen Sie genau genommen nicht nicht mit übernommenen Dienste auch sauber umkonfigurieren und entfernen. Was hilft ihnen ein Testfeld zu Exchange, wenn der Exchange Server, welcher den RUS oder den ADC betreibt, nicht übernommen wurde ?
• Optimiertes Testfeld
  Bei dieser Option überlegen Sie was sie testen wollen und welche Voraussetzungen Sie benötigen. Dann wird ein Testfeld für diesen Zweck aufgebaut bzw. eine Vorlage angepasst und darin getestet. Dies ist zwar sehr fern von der ProduktionsUmgebung aber bezogen auf den Test meist sehr aussagekräftig. Einige Dinge müssen aber dann transformiert werden, z.B. Aussagen zur Belastung und Skalierbarkeit. Durch die geringen Anforderungen ist es einfacher möglich, mehrere Testfelder parallel zu betreiben.

Eine einfache Antwort gibt es darauf nicht, aber mit den richtigen Fragen kommen Sie eine Antwort näher.

Die 1:1 Kopie

Der erste Ansatz ist natürlich "Eine Kopie der Produktion" anzulegen. Damit entspricht das Testfeld genau der Produktion. Im Hinblick auf die Konfiguration und Testdaten sind auch gleich enthalten. Entsprechenden sollten die Ergebnisse aussagekräftig sein. Aber da gibt es einige Probleme.

• Wie vollständig ist die Kopie
  Nur kleine Umgebungen können es sich leisten eine 1:1 Kopie herzustellen. Je größer ihre Umgebung ist desto unmöglicher wird eine 1:1 Kopie als Testfeld
• Hardware und Virtualisierung
  Meist ist es aber schon schwer, eine 1:1 Kopie der Hardware bereit zuhalten. Eine Kopie auf andere Server oder in virtuelle Maschinen mit anderen Umgebungen, Treibern etc. ist aber nicht nur aufgrund der unterschiedlichen HAL dann keine Kopie mehr, sondern scheitert eben oft auch daran. (Stichwort Windows Aktivierung, Treiber, HAL)
• Umfang
  Wenn Sie für den Test zwar Testdaten aber z.B.: keine 1:1 Kopie ihrer kompletten Exchange Datenbank benötigen oder aufgrund von Hardwarebeschränkungen nicht haben wollen, dann ist eine Kopie nicht der richtige Weg. Wenn ihre Umgebung größer ist, dann müssen Sie genau genommen jeden Server mit in das Testfeld übernehmen. Das sind zumindest alle Domain Controller. Wenn Sie Server nicht übernehmen, die sie für den Test nicht brauchen, dann kann es trotzdem sein, dass das Testfeld nicht korrekt funktioniert oder den Test erschwert, Wenn Sie z.B. immer nur einen Domaincontroller jeder Domäne übernehmen, dann fehlen ihnen sicherlich einige Replikationspartnern und DNS/WINS-Server mit den entsprechenden Problemen bei der Namensauflösung
• Netztrennung
  Bei einer Kopie hat das Testfeld die gleichen SID's etc, eine komplette Netztrennung muss daher erforderlich sein, um die Produktion nicht zu stören. Nur wird es dann natürlich schwer, größere Daten zu bewegen, Hier bleiben dann nur Wechselfestplatten, USB-Speicher, andere Medium oder ein Gateway als Vermittler zum Datenaustausch. Wenn ihre Produktion aus mehreren Netzwerken mit Firewalls besteht, dann müssen Sie auch dies nachstellen. In Verbindung mit virtuellen Maschinen auf einem physikalischen Rechner wird die Netzwerkstruktur damit dann schon etwas komplexer. Und die Anbindung aus Außenstellen könnten Sie durch serielle Nullmodem-Kabel oder extra Router nachbilden.
• Aktualität
  Ein weiteres großes Problem ist die Aktualität der TestUmgebung. Wenn Sie zu einem bestimmten Zeitpunkt einen Schnappschuss ihrer Produktion in ein Testfeld übertragen ist die erste Sekunde danach schon das Testfeld nicht mehr identisch mit der Produktion. Insofern relativiert auch das schon wieder die Ergebnisse ihrer TestUmgebungen. da sie sich immer nur auf den Stand der Produktion von damals beziehen.
• RollBack
  Eine TestUmgebung dient zum Testen und Lernen. So ist es völlig normal, dass auch mal etwas schief geht oder Sie in einer Sackgasse gelandet sind und noch mal von vorne anfangen wollen. Spätestens dann kommt die Leistung von virtuellen Maschinen zum tragen, bei denen Sie sehr einfach wieder einen Rollback auf einen früheren Stand durchführen können. Bei der Nutzung von physikalischen Systemen müssten Sie dann wieder das System von einem Backup oder Image zurück holen.

Zusammengefasst erkennen Sie, dass eine echte 1:1 Kopie einer Produktion nur in sehr kleinen Umgebungen funktioniert und selbst dann diese Kopie trotzdem noch eingeschr��������nkt ist. Es müssen also Kompromisse bei der Einrichtung eines Testfelds getroffen werden.

Neuaufbau

Als Alternative können Sie natürlich dann ein virtuelles Testfeld frisch aufbauen, in dem Sie möglich viele Konstellationen ihrer ProduktionsUmgebung einbauen. Hierbei kann man natürlich dann "einsparen".

• Weniger DCs
  Wenn Sie in der Produktion zwei oder mehr DCs pro Domäne haben, dann reicht im Testfeld vielleicht ein DC
• Weniger Domains
  Wenn Sie in der Produktion einen Forest mit 20 Domains haben, dann reicht im Restfeld vielleicht ein Forest mit 2-3 Domänen
• Vereinfachtes Exchange
  Für eine TestUmgebung kann es ausreichend sein, ihre Exchange Umgebung zu vereinfachen. Aus einer Organisation mit 100 Servers in 50 administrativen Gruppen kann für viele Tests auch eine kleine Umgebung mit zwei oder drei administrativen Gruppen reichen.

Beschränkungen solch einer Umgebung sind natürlich auch zu beachten:

• Frage der Übernahme von Daten und Einstellungen
  Ein neues AD und eine neue Exchange Organisation entspricht natürlich nicht der Produktion. Also müssen Sie überlegen, ob Sie einfach Testbenutzer anlegen oder einen Teil der Produktionsdaten einfach mit ADMT oder LDIFDE in die TestUmgebung importieren.
• keine Altlasten
  Das bedeutet aber auch, dass vielleicht die ein oder andere unstimmigkeit in der ProduktionsUmgebung nicht in der TestUmgebung vorhanden ist. Das kann schlecht sein, wenn ihre Testanwendung in der TestUmgebung funktioniert und in der Produktion nicht. Auf der anderen Seite haben Sie dann aber auch die Möglichkeit zu vergleichen, d.h. TestUmgebung ist "Default" und Produktion ist abweichend.
• keine Produktionsdaten
  Ihnen fehlen aber vor allem die Inhalte in Postfächern und Ordnern, Dateiserver, SQL-Servern etc. Das spart zwar Festplattenplatz aber gerade bei Migrationen etc. ist es nicht aussagekräftig genug, wenn Sie 100 leere Postfächer in 5 Minuten migriert haben, wenn dann in der Produktion korrupte Mails und fehlende Berechtigungen auf öffentlichen Ordnern die produktive Migration stoppen.
• Keine Aussage über Last, Laufzeiten und Stabilität
  Keine Daten und virtuelle Systeme nehmen ihnen natürlich auch viele Möglichkeit, den späteren Dauerbetrieb zu testen.
• manueller Abgleich mit Produktion
  Wenn Sie in der Produktion eine Änderungen durchführen (z.B.: neue Gruppenrichtlinie etc.), dann sollten Sie diese auch in der TestUmgebung nach halten. Das ist zwar doppelte Arbeit aber sonst wird ihre TestUmgebung immer schlechter. Besser ist es natürlich, wenn Sie ihre Einstellung eben in der TestUmgebung zu erst umsetzen und dann in die Produktion übertragen.

Testfeldplanung

Generell stellt sich die Frage, wie "nahe" ein Testfeld an der Produktion dran sein muss. Wenn ihre Produktion z.B. aus einem Forest mit 5 Domänen besteht, dann ist zu überlegen, um für die verschiedenen Tests nicht auch ein Testfeld mit 2-3 Domänen ausreicht. In den meisten Fällen lassen sich damit auch Themen rund um die Namensauflösung, Replikation, Trusts und Berechtigungen klären. Auch wenn ihre Produktion viele verteilte Standorte hat, kann es für das Testfeld ausreichend sein, einen entfernten Standort mit einer simulierten WAN-Verbindung aufzubauen. Ein Testfeld kann nicht eine Produktschulung ersetzen. Es darf also nicht zu einer SchulungsUmgebung verkommen, in der bestimmte Dinge "probiert" werden, nur weil Sie die Lösung nicht wissen. Hier ist es günstiger und besser, externen Rat für Design und Planung bestimmter Projekte einzukaufen. Ein Testfeld sollte es ihnen erlauben, eine Planung und Konzeption zu überprüfen bzw. ein bestimmtes Problem nachzustellen aber nicht als Probierfeld für Wissenslücken dienen. Das kostet zu viel Zeit und letztlich auch Geld.

Daher ist die Planung eines Testfelds der erste Schritt. Bei größeren Firmen ist es dazu erforderlich, sich mit allen Abteilungen abzustimmen, die später im Testfeld Dinge austesten müssen.

• Was muss das Testfeld abdecken ?
  Ehe Sie in die Details über Server und Installation gehen, sollten Sie sich einfach mal mit einem leeren Blatt an einen Tisch setzen und überlegen, welche Tests und Umgebungen Sie zukünftig benötigen.
• Größe und Partitionierung des Testfelds
  Zudem sollten Sie sich fragen, ob sie "genau ein" Testfeld benötigen oder ob Sie bestimmte Dinge voneinander unabhängig testen können. Das macht später auch die Wiederherstellung einfacher. Reine Softwarefunktionstests können problemlos auch in virtuellen Maschinen durchgefhrt werden, während Tests von Treibern, Festplatten, Netzwerkkarten, Switches, Routern, SAN-Anbindungen etc. sehr hardwarenahe erfolgen und kaum zu virtualisieren sind.
• Rollback und Versionierung
  Wenn Sie im Testfeld etwas verändern und ihr Test abgeschlossen ist, dann sollten Sie das Testfeld wieder in den ursprungszustand bringen. Wie lösen Sie diese Aufgabe? Denkbar ist z.B. das Sichern einer Festplatte als IMAGE auf eine zweite Festplatte im PC oder die Nutzung von virtuellen Maschinen. Interessant wird es, wenn Sie in einem Testlauf auch einen Zwischenstand nach einem Teilschritt gesondert einmal fixieren möchten.
  Was passiert, wenn mehrere Abteilungen konkurrierend einen Test durchführen wollen. Auch hier sind virtuelle Maschinen fast unschlagbar, da damit jede TestUmgebung auch mehrfach vorgehalten werden kann.
• Was muss getestet werden
  Abhängig von der Anwendung müssen Sie definieren, welche Schnittstellen genutzt werden und Änderungen eine Software durchführt. Eventuell müssen Sie für eine bestimmte Software ihr Testfeld temporär erweitern.

Mustertestfelder

Ich kann ihnen für ihre Umgebung keine Testfelder vorschlagen, Aber ich kann ihnen meine verschiedenen TestUmgebungen beschreiben, mit denen ich für die MSXFAQ und meinen Beruf die verschiedenen Tests, Bilder, Scripte, Migrationen, Schulungen mache. Alle TestUmgebungen sind als virtuelle Systeme unter VirtualPC bzw. VMware ausgeführt.

Testfeld 1: Exchange 2003

Diese Testfeld ist eine einige Maschine und dient mir als Referenz für Exchange 2003 Standard Installationen.

• SRV1
  Windows 2003 DC
  DNS und WINS
  Exchange 2003 SP1
  Zertifizierungsstelle
  Support Tools

Hier kann ich wunderbar die "Default Rechte "anzeigen, Funktionen testen und auch meine VBScripte dagegen fahren

Testfeld 2: MSXLAB1

Diese Testfeld dient für Tests in einer gemischten Umgebung und besteht aus drei Serversn

• E3KA (Site A)
  Windows2003 DC mit DNS/WINS
  Exchange 2003 SP1
  ADC
• EX55A (Site A)
  NT4 Server SP6a
  Exchange 5.5 SP4
  X.400 Connector zu EX55B mit DirSync
• EX55B (Site b)
  NT4 Server SP6a
  Exchange 5.5 SP4
  X.400 Connector zu EX55A mit DirSync

Hier kann ich so ziemlich alle Konstellationen mit dem ADC und der Replikation nachstellen. Zudem ist diese Umgebung auch Ausgangspunkt für weitere Tests, da hier die weiteren Migrationsschritte durchgeführt werden können, z.B.:

• E3KC (Site C)
  Ein neuer Exchange in einer Native Site
• E3KB (Site B)
  Ein neuer Exchange mach aus einer Native EX55 Site eine Mixed Site
• InterSite Migration
  Tests, um Postfächer von EX55A nach E3KA zu migrieren (Über Sitegrenze hinweg mit EXPROFRE etc.)
• NativeMode umschaltung
  Wenn ich die Verbindung zu EX55B lösche, habe ich sehr schnell eine einzige Admingroup im Mixed Mode, und kann da den EX55A dann "deinstallieren".
• DC2 - MultiDomain
  Durch die Installation eines weiteren DCs als neue Domäne in den Forest kann auch die Situation mit Benutzern in einer Domäne ohne Exchange nachgestellt werden.

Sie sehen also, wie flexibel eine geschickte Testfeld Basisinstallation ist. Der Einsatz von NT4 Servern hat den Vorteil, dass diese weniger Hauptspeicher benötigen.

Bausteine

Da ich für weitere Installation immer mal wieder "fertige" Maschinen brauche und diese nicht immer neu installieren will, gibt es natürlich noch eine Menger von virtuellen Systemen, die fertig installiert in einer Arbeitsgruppe sind und deren SID und Namen ich schnell mit NEWSID (Sysinternals) ändern kann, um diese in die TestUmgebungen einzubinden. So haben ich:

• Win98SE
  Eine Windows 98 Second Edition Workstation.
• W2KPro
  Windows 2000 Professional SP4
• WinXP
  Windows XP
• NT4S
  Windows NT4 Server
• DOS622
  Auch eine einfache DOS-Maschine mit einem Microsoft Client mit NDIS2-Treiber kann ich in kurzer Zeit einbinden. Wobei ich diese Maschine eher nutze, um Bootdisketten und PXE-Tests durchzuführen und weniger für die Exchange Testfelder benötige
• Linux/Unix/Knoppix/Solaris/Debian
  Klar, dass ich auch die ein oder andere Unix-VM bei bedarf starten kann, um z.B.: die Interaktion mit DNS, Outlook Web Access etc. zu testen. Wobei hier auch coLinux und Knoppix von einer CD das Leben einfacher machen.

Ich hoffe Sie sind nun etwas neugierig auf den Einsatz von virtuellen Maschinen als Testfeld. Und ohne Planung geht nichts. Versuchen Sie nicht, die Testmaschinen all zu stark zu spezifieren.