Lehrstuhl für Datenverarbeitung Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber

Transkript

1 Lehrstuhl für Datenverarbeitung Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber Diplomarbeit 355 Entwurf und Realisierung eines Verfahrens zur optimierten Verteilung von Analyseprozessen in einem dezentralen Sicherheitskonzept Die Verfügbarkeit der eigenen Netzinfrastruktur ist ein wichtiger Faktor bei der Bewertung der Qualität eines LAN. Folglich erlangen Aspekte der Sicherheit einen immer höheren Stellenwert. Durch dezentrale Sicherheitskomponenten, wie z.b. ID- und IR- Systeme, kann die Sicherheit eines Netzes erhöht werden. Zu einem dezentralen Sicherheitskonzept gehören jedoch weitere intelligente Lösungen, die alle Rechner und verteilten Ressourcen eines Netzwerks in die Sicherheitsinfrastruktur einbinden. Ziel der Arbeit ist es, Analyseprozesse unter dem Gesichtspunkt einer optimierten Ausnutzung der zu Verfügung stehenden Ressourcen auf die verschiedenen Rechner zu verteilen. Es ist ein Verfahren zu entwickeln, welches mit Hilfe gegebener Systemparameter und stochastischen Ansätzen den vorhandenen Rechnerverbund bewertet. Das Verfahren soll geeignet als Software implementiert werden, wobei die Kommunikation und der Datenaustausch über die Protokollfamilie TCP/IP abgewickelt werden soll. Das Verfahren soll autark die notwendigen Komponenten auf das Zielsystem, welches für den Analyseprozess vorgesehen ist, transferieren. Dazu ist ein Mechanismus zu integrieren, der über eine Datenbasis die vorhandenen Komponenten verwaltet und dafür Sorge trägt, dass diese im Bedarfsfall auf den einzelnen Rechnern zur Verfügung stehen. Um der Zielsetzung einer optimierten Verteilung gerecht zu werden sind zudem Schnittstellen für die einzelnen Analyseprozesse sowie ein auf das TCP/IP aufgesetztes Protokoll zur Interaktion zwischen den Rechnern zu definieren. Der Status eines Verteilungsvorgangs ist geeignet auf demjenigen Rechner, welcher als Initiator eines Verteilungsvorgangs agiert, lokal zu sichern. Die resultierende Software ist unter MS Windows NT mittels MS Visual C++ zu realisieren. Alle Entwicklungsschritte sind zudem projektbegleitend zu dokumentieren. (Prof. Dr.-Ing. Wolfgang Weber) Bearbeiter: cand.-ing. Johannes Jußen Matrikel-Nummer: Betreuer: Dipl.-Ing. Thomas Droste Ausgabetag: Abgabetag:

2 Inhalt Inhalt 1 Einleitung Bestehende Umgebung Microsoft Windows NT Service Verwendete Softwarekomponenten Erweiterung des bestehenden Dienstes NetworkPool Serverfunktionalität Planungsphase (Lastenheft) Zielsetzung Adressaten Musskriterien Wunschkriterien Abgrenzungskriterien Produkteinsatz Anwendungsbereiche Zielgruppen Betriebsbedingungen Produktumgebung Software Hardware Umgebung Produktschnittstellen Alternative Lösungsmöglichkeiten Lösungswerkzeuge Zeitplanung Planungsphase (Pflichtenheft) Produktfunktionen Kommunikationsschnittstelle (Socket) Kommunikationsschnittstelle (Skeleton Stub) Softwarekomponenten Verfügbarkeit von Softwarekomponenten Aufgabenstellungen Optimierte Verteilung von Aufgabenstellungen Produktdaten Produkt-Leistungen Benutzungsschnittstelle Qualitäts-Bestimmung

3 Inhalt 4.6 Globale Testfälle Softwarekomponenten im Sicherheitsmanagement CONSOLE-Anwendungen als Softwarekomponenten Umgebung der CONSOLE-Anwendung Definition einer Softwarekomponente Beispiel für eine Datei Setup.ini Verfügbarkeit von Softwarekomponenten Theoretische Grundlagen Konsistenz Auswahl eines Verfahrens Konkretisierung des ausgewählten Verfahrens Erreichbarkeit und Verfügbarkeit Gruppenkommunikation Ermittlung der Erreichbarkeit über den Dienst Systemdetector Abgleich der Softwarekomponenten Verwaltung von Softwarekomponenten Ermittlung von Nachfolgern und Partnern im Ring Bestimmung eines Nachfolgers im Ring Suche nach Partnern Datenquelle Systemdetector Verteilungsprozesse im Rechnerverbund Installation Deinstallation Resultierender Algorithmus Fallbeispiele Installation Deinstallation Abgleich von Softwarekomponenten Aufgabenstellung Begriffsdefinitionen Beschreibung einer Aufgabenstellungen Aufgabenstellung Erzeugung einer Aufgabenstellung aus einer Spezifikationsdatei Erzeugung einer Aufgabenstellung durch Methodenaufrufe Bearbeitung von Aufgabenstellungen Festlegung der Vorgehensweise Entgegennahme von Aufgabenstellungen Bearbeitung von Aufgabenstellungen

4 Inhalt 8.4 Entgegennahme von bearbeiteten Aufgabenstellungen Optimierte Verteilung von Prozessen Auslastung eines Rechners Verteilung einer Aufgabenstellung Bestimmung der Auslastung eines Rechners Einführendes Beispiel Zuteilung von Rechenleistung unter MS Windows NT Prozessmodell Größen aus der Aufgabenstellung Größen aus der Umgebung Exakt bestimmbare Messgrößen Resultierendes vereinfachtes Modell Zeitpunkt einer bearbeiteten Aufgabenstellung Auswahl einer Schätzfunktion Komplexitätsanalyse Charakteristische Beispiele für Komplexitätsklassen Methode der kleinsten Quadrate im Einzelschrittverfahren Algorithmus Verknüpfung zwischen Algorithmus und Softwarekomponente Kommunikation zwischen den Rechnern Überblick Interface: CLogMessage Klasse CBlockingSocket Protokoll Beispiel Fazit Kurzbeschreibung der Dienstprogramme DatabaseViewer Arbeitsweise Grafische Oberfläche PDInstaller Arbeitsweise Grafische Oberfläche PDTaskScheduler Arbeitsweise...80 Grafische Oberfläche Test Test gemäß Kriterium /T10/

5 Inhalt 12.2 Test gemäß Kriterium /T20/ Test gemäß Kriterium /T30/ Test gemäß Kriterium /T40/ Test gemäß Kriterium /T50/ Test gemäß Kriterium /T60/ Test gemäß Kriterium /T70/ Test gemäß zusätzlichem Kriterium /T70a/ Test gemäß zusätzlichen Kriterium /T70b/ Test gemäß Kriterium /T80/ Test gemäß Kriterium /T90/ Test gemäß Kriterium /T100/ Test gemäß Kriterium /T110/ Zusammenfassung Literatur...95 Anhang

6 Kapitel 1 Einleitung 1 Einleitung In einem verteilten Sicherheitsmanagement [DRO00] sind auf jedem partizipierenden Rechner Softwarekomponenten installiert und in Betrieb, die Sicherheit gewährleisten sollen. Dieser Ansatz unterscheidet sich von einem zentralen Sicherheitsmanagement. Bei einem zentralen Sicherheitsmanagement sind spezielle Rechner zum Zweck der Gewährleistung von Sicherheit vorgesehen (z.b. Firewall). Andere Rechner stehen dadurch weiterhin uneingeschränkt für die Benutzung zur Verfügung. Ein Nachteil des verteilten Sicherheitsmanagements ist es, dass die Performance der Rechner für den lokalen Benutzer beeinträchtigt wird, weil die Sicherheit gewährleistende Softwarekomponenten viel Rechenleistung beanspruchen. Im Rahmen dieser Arbeit wird ein Lastausgleich (load balancing) zwischen den am Verbund partizipierenden Rechnern realisiert. Aufgabenstellungen, wie z.b. die Analyse von aufgezeichneten Daten im Netzverkehr, sollen auf demjenigen Rechner bearbeitet werden, der zum aktuellen Zeitpunkt am wenigsten ausgelastet ist. Dazu müssen die als relevant eingestuften Eigenschaften der Umgebung von Microsoft Windows NT beschrieben werden. Kernpunkt ist dabei den Begriff der Auslastung zu quantifizieren, da nur auf einer quantifizierbaren Grundlage von Informationen eine solide Entscheidung über die Verteilung von Aufgabenstellungen gefällt werden kann. Es werden Softwarekomponenten des verteilten Sicherheitsmanagements vorgestellt, die bereits implementiert sind und deren Dienste zur Umsetzung obiger Zielsetzung in Anspruch genommen werden. Basierend auf diesen Vorkenntnissen wird ein Modell zur Verteilung von Analyseprozessen auf verschiedene Rechner entworfen. Ein besonderes Augenmerk wird dabei auch auf die Verfügbarkeit von aktuellen Softwarekomponenten auf den lokalen Rechnern gelegt. Das Modell soll implementiert und nach einem Test bewertet werden. Dabei interessiert insbesondere, ob die Voraussetzungen hinreichend genau spezifiziert sind, um einen sinnvollen Betrieb der erstellten Softwarekomponente im Rahmen des verteilten Sicherheitsmanagements zu gewährleisten. 5

7 Kapitel 2 Bestehende Umgebung 2 Bestehende Umgebung 2.1 Microsoft Windows NT Service Das verteilte Sicherheitsmanagement basiert auf Prozessen, die im Hintergrund des normalen Betriebs ablaufen. Microsoft Windows NT bietet hierzu die Möglichkeit, Softwarekomponenten als Microsoft Windows NT Service (kurz: Dienst) zu implementieren [MIL98]. Diese Dienste sind vergleichbar mit Dämonen unter UNIX. Service Control Manager (SCM) Dienst A Dienst B Dienst C Abbildung 2-1: Dienste unter MS Windows NT Dienste können auch aktiv sein, wenn kein Benutzer auf einem Rechner eingeloggt ist. Sie haben in der Regel keine eigene grafische Benutzeroberfläche (GUI) und werden durch den Service Control Manager (SCM) verwaltet, der über eine Datenbank aller lokal registrierten Dienste verfügt (vgl. Abbildung 2-1). Über die Systemsteuerungsoption Dienste können diese manuell gestartet, gestoppt oder auf automatisch gestellt werden. Im letzteren Fall startet der SCM den speziellen Dienst beim Hochfahren des Rechners und beendet ihn beim Herunterfahren. Der Dienst ist somit bei eingeschaltetem Rechner immer aktiv im Hintergrund. Microsoft Windows NT erlaubt es, den Dienst über den SCM mit benutzerdefinierten Mitteilungen zu steuern. Dazu ist die Implementierung einer eigenen Systemsteuerungsoption erforderlich. Diese Vorgehensweise ist allerdings sehr langsam, da die Kommunikation mit dem Dienst immer den Umweg über den SCM nimmt. Es ist also 6

8 Kapitel 2 Bestehende Umgebung sinnvoll, mit einem Dienst über andere Schnittstellen zu kommunizieren. Der Aufgabenbereich einer Systemsteuerungsoption wird auf das Starten und Stoppen des Dienstes beschränkt. Diese Funktionalität ist durch die Systemsteuerungsoption Dienste hinreichend abgedeckt. 2.2 Verwendete Softwarekomponenten Es stehen bereits drei Dienste zur Verfügung, die im Rahmen dieser Arbeit verwendet werden sollen. Ein Report-Dienst [DRO01] erlaubt es, Kurzmitteilungen im verteilten Sicherheitsmanagement zu versenden, zu empfangen und im Serverbetrieb lokal zu sichern. Dieser hat die Bezeichnung NetworkPool. Der Dienst Systemdetector [SCH99] erlaubt es zu erkennen, welche Rechner am verteilten Sicherheitsmanagement partizipieren und ob diese aktuell erreichbar sind. Sind sie erreichbar, so sollen sie auch am Lastausgleichsverfahren teilnehmen. Der Dienst liefert eine Datei, aus der die benötigten Informationen ermittelt werden können. Der Dienst Windows Time Service [MIC00] trägt dafür Sorge, dass die Uhren auf allen Rechnern, die am verteilten Sicherheitsmanagement partizipieren, synchronisiert sind. Dies ist notwendig, da die korrekte Verteilung von Analyseprozessen von einer gemeinsamen physikalischen Zeitbasis abhängig ist. 2.3 Erweiterung des bestehenden Dienstes NetworkPool Die neu zu implementierende Komponente soll in den bereits bestehenden Dienst NetworkPool integriert werden. Dieser beinhaltet bisher den Report-Dienst [DRO01]. Um die Anzahl an Diensten mit einer Serverfunktionalität im verteilten Sicherheitsmanagement nicht übermäßig ansteigen zu lassen, wird die Schnittstelle zum TCP/IP- Netzwerk des Report-Dienstes zur Entgegennahme von Kurzmitteilungen so erweitert, dass im Rahmen dieses Dienstes auch die Verteilung und Verwaltung von Aufgabenstellungen und Anwendungen erlaubt wird. Die neu zu erstellende Softwarekomponente ProcessDistributor wird somit in die Komponente NetworkPool integriert, die bereits den Report-Dienst beinhaltet (vgl. Abbildung 2-2). Über den SCM läßt sich das Dienst-Paket NetworkPool starten und stoppen. Ist NetworkPool aktiviert, so kann über das TCP-IP Netzwerk auf alle Komponenten von NetworkPool zugegriffen werden. Speziell CLogServer muss in der Funktionalität erweitert werden, um mehrere Dienste innerhalb des Dienst-Paketes ansprechen zu können. 7

9 Kapitel 2 Bestehende Umgebung SCM Netzwerk TCP/IP NetworkPool CLogServer Report-Dienst ProcessDistributor Abbildung 2-2: Integration von ProcessDistributor in die bestehende Umgebung 2.4 Serverfunktionalität Über den Server (CLogServer) können Instanzen über das TCP/IP-Netzwerk empfangen werden, deren Klassen bei einem Interface CLogMessage registriert sind (vgl. Kapitel 10). Dabei wird in zwei Fälle unterschieden: 1. Die empfangene Instanz kann den Klassen CLogEntry bzw. CLogMultipleMessage zugeordnet werden: Die Instanzen werden wie bisher an den Report-Dienst [DRO01] weitergeleitet. 2. Die empfangene Instanz kann der Klasse CPDCommand zugewiesen werden: eine solche Instanz leitet einen Funktionsaufruf an ProcessDistributor ein. Es folgen weitere Instanzen, welche die Attribute des Funktionsaufrufs repräsentieren (vgl. Abbildung 2-3). Attribut N Attribut 2 Attribut 1 CPDCommand Rückgabewert Clientseite Serverseite Abbildung 2-3:Definition eines Funktionsaufrufes ProcessDistributor ist als globale Instanz innerhalb des Projektes NetworkPool definiert. Mit einer switch-case Fallunterscheidung werden Instanzen der Klasse CPDCommand Funktionsaufrufen an der globalen Instanz ProcessDistributor zugeordnet. Dabei werden zunächst die erforderliche Anzahl von Attributen 8

10 Kapitel 2 Bestehende Umgebung empfangen, anschließend mit den empfangenen Attributen der Funktionsaufruf durchgeführt und der Rückgabewert über die Netzwerkverbindung wieder an den Client versendet. CLogServer kann also als ein Skeleton aufgefasst werden. Funktionsaufruf Netzwerk resultierender Funktionsaufruf Stub Socket Socket Skeleton ProcessDistributor Clientseite Serverseite Abbildung 2-4: Entfernter Aufruf von Funktionen Ein Benutzer kann einen Stub ProcessDistributorStub auf einem Remote-Rechner in derselben Art und Weise verwenden, wie die Instanz ProcessDistributor lokal (vgl. Abbildung 2-4). Die Stub-Klasse wandelt die Funktionsaufrufe in eine Folge von Instanzen um, wie in Abbildung 2-3 beschrieben ist. Derjenige Rechner, der mit Hilfe des Stubs kontaktiert werden soll, muss auf dem Stub über die Angabe der IP-Adresse spezifiziert werden. 9

11 Kapitel 3 Planungsphase (Lastenheft) 3 Planungsphase (Lastenheft) 3.1 Zielsetzung Es soll die Möglichkeit geschaffen werden, den Mehraufwand an Systemressourcen zur Umsetzung eines Sicherheitsmanagements auf alle partizipierenden Rechner zu verteilen. Rechner schließen sich zu einem Rechnerverbund zusammen, wenn sie zu einem gemeinsamen Sicherheitsmanagement gehören und teilen sich Systemressourcen. Einerseits sollen die bestehenden Systemressourcen in einer Weise ausgenutzt werden, dass für die Benutzer bei der Anwendung von Rechensystemen, die in das Sicherheitsmanagement eingebunden sind, nur geringe Nachteile in der Performance des Rechners durch die hinzugefügten Sicherheitskomponenten entstehen. Andererseits soll durch eine Verteilung eine hohe Verfügbarkeit der Sicherheitskomponenten erreicht werden. Es sind in einem solchen Sicherheitsmanagement diejenigen Softwarekomponenten zu verteilen, die nicht lokal an einen einzelnen Rechner gebunden sind. Dies sind also vorrangig Komponenten zur Datenanalyse, die aus im Netzwerk aufgezeichneten Informationen wichtige Kennparameter berechnen bzw. Informationen entsprechend definierter Richtlinien modifizieren. Eine einfache Anwendung ist z.b. das Ordnen von Einträgen in einer Protokolldatei nach bestimmten Kriterien. Die Kommunikation zwischen den einzelnen Rechnern soll dezentral nach dem Peermodell 1 organisiert sein, da bei einer zentralen Organisation der Ausfall des zentralen Rechners das gesamte Sicherheitsmanagement gefährdet ist. 3.2 Adressaten Zielgruppe des Produktes sind Systemadministratoren, die mit Hilfe des Komplettpakets ein verteiltes Sicherheitsmanagement in einem LAN 2 realisieren. 3.3 Musskriterien Schnittstelle zur Kommunikation zwischen verschiedenen Rechnern, die es erlaubt, fest spezifizierte Funktionsaufrufe auf dem jeweils anderen Rechner auszuführen. 1 Peermodell Im Peermodell sind Client und Server in einem Programm vereinigt. Diese dann untereinander gleichberechtigten Komponenten werden im Verbund als Peers bezeichnet [WEB98] 2 LAN Local Area Network 10

12 Kapitel 3 Planungsphase (Lastenheft) Sicherstellung der Verfügbarkeit von Softwarekomponenten auf den verschiedenen Rechnern, die am Rechnerverbund partizipieren. Dazu Abgleich von Softwarekomponenten bei Einbindung eines neu gestarteten Rechners in den Rechnerverbund. Spezifikation des Begriffs Aufgabenstellung und die Möglichkeit, einem Rechner über obige Kommunikationsschnittstelle eine solche Aufgabenstellung asynchron zuzuweisen. Messung des Rechenaufwands von Aufgabenstellungen jeweils lokal auf den verschiedenen Rechnern in Abhängigkeit von der Datenmenge, die der Aufgabenstellung zugehörigen Anwendung als Eingabedatei(-en) übergeben wird. Entwicklung eines geeigneten Modells für eine Schätzfunktion Ξ, um aus der einer Anwendung übergebenen Aufgabenstellung heraus einen voraussichtlichen Rechenaufwand zu bestimmen. Bestimmung von lokal den installierten Anwendungen zugeordneten Schätzfunktionen Ξ i. i ist die Identifikation der zum Schätzer zugehörigen Softwarekomponente. Dabei sollen gemessene Rechenaufwände aus bereits bearbeiteten Aufgabenstellungen verwendet werden. Beurteilung, in welchen speziellen Fällen eine Abschätzung durch eine solche Schätzfunktion Ξ i hinreichend genau möglich ist. Mechanismus zur Ermittlung eines optimalen Partners (Rechner) zur Bearbeitung einer Aufgabenstellung aufgrund der Kenntnis der geschätzten Rechenaufwände. Implementierung der Anwendung ProcessDistributor als Microsoft Windows NT Service durch Integration in den Report-Dienst NetworkPool, der bereits verfügbar ist. 3.4 Wunschkriterien Ein lokaler Anwender soll durch die Existenz von ProcessDistributor nicht in seinem Arbeitsablauf eingeschränkt werden. Lokale Anwendungen sollen erhöhte Priorität gegenüber Anwendungen haben, die Aufgabenstellungen von Process- Distributor bearbeiten. Die Kommunikationsschnittstelle soll möglichst schnell sein. Möglichkeiten zur Optimierung, die nicht implementiert werden, sollen aufgezeigt werden. Hohe Stabilität bei langer Laufzeit Abgrenzungskriterien Die Software setzt ausschließlich auf das TCP/IP-Protokoll auf und ist mit anderen Netzwerkprotokollen nicht lauffähig. Der Betrieb beschränkt sich auf das Betriebssystem Microsoft Windows NT

13 Kapitel 3 Planungsphase (Lastenheft) 3.5 Produkteinsatz Das Produkt dient zur Verteilung von Aufgabenstellungen an verschiedene Anwendungen in einem Rechnerverbund. Die Aufgabenstellungen beinhalten in der Regel die Analyse von im Netzwerk aufgezeichneten Daten (auditing). Andere Anwendungen sind möglich und zugelassen. Die gemeinsamen Ressourcen sollen im Rahmen eines Lastausgleichsverfahrens (load balancing) möglichst gleichmäßig ausgelastet werden Anwendungsbereiche Systemmanagement Zielgruppen Keine besondere Spezifikation einer Zielgruppe Betriebsbedingungen LAN-Umgebung. 3.6 Produktumgebung Software Betriebssystem: Microsoft Windows NT Hardware Die Hardwareanforderungen entsprechen denen des Betriebssystems Umgebung Der Microsoft Windows NT Dienst muss gemeinsam mit dem Dienst Systemdetector auf jedem Rechner installiert werden, der am Lastausgleich partizipieren soll. Eine Netzwerkanbindung mit mindestens 10 MBit/s, besser 100MBit/s, ist erforderlich Produktschnittstellen Über den Service Control Manager (SCM) des Betriebssystems Microsoft Windows NT ist es möglich, den Dienst ProcessDistributor zu starten und zu stoppen. Die Aktivität von ProcessDistributor ist dabei an die Aktivität des Servers CLogServer des Report-Diensts NetworkPool gekoppelt, da dieser Server sowohl Mitteilungen für den Report-Dienst als auch entfernte Funktionsaufrufe im 12

14 Kapitel 3 Planungsphase (Lastenheft) Rahmen von ProcessDistributor entgegennimmt. Speziell CLogServer wird über eine Systemsteuerungsoption gestartet und gestoppt (nicht Bestandteil der Arbeit). ProcessDistributor wird gemeinsam mit CLogServer gestartet und gestoppt, da ein sinnvoller Betrieb von ProcessDistributor ohne CLogServer nicht möglich ist. Ist CLogServer über den SCM aktiviert worden, kann mit Hilfe der aktiven Kommunikationsschnittstelle CLogMessage über entfernte Funktionsaufrufe auf ProcessDistributor zugegriffen werden. Kleine Dienstprogramme (vgl. Kapitel 11) setzen auf dieser Schnittstelle auf, um den Zugriff auf ProcessDistributor zu gewährleisten. ProcessDistributor kann im Rahmen von Aufgabenstellungen Ein- und Ausgabedateien lokal lesen und schreiben. 3.7 Alternative Lösungsmöglichkeiten Zur Verteilung von Anwendungen existieren am Markt Verfahren, um verteilte Programmierung zu realisieren. Insbesondere sind hier CORBA 3 und DCOM 4 zu nennen. Zur Spezifikation CORBA [OMG00] sind bereits implementierte ORBs 5 verfügbar. Eine Einarbeitung in CORBA, um eine Bewertung vorzunehmen ob CORBA und welcher dabei frei verfügbare ORB geeignet ist, steht in keinem Verhältnis zur Realisierung eines einfachen Kommunikationsmechanismus, der innerhalb dieser Anwendung benötigt wird. Das Konzept DCOM hat neben den vielen Vorteilen auch einige Nachteile, insbesondere, wenn die Möglichkeit der Einbindung in eine grafische Oberfläche nicht erforderlich ist: Die Schnittstelle DCOM über das Netzwerk ist relativ langsam [KOC99]. Jede Softwarekomponente muss in eine (D-)COM-Anwendung umgewandelt werden. Jede Softwarekomponente muss beim Betriebssystem registriert werden. Der Rechenaufwand einer (D-)COM-Komponente läßt sich schlecht abschätzen. 3.8 Lösungswerkzeuge Die Softwarekomponente wird in der Programmiersprache C++ erstellt. Es dürfen alle Bibliotheken verwendet werden, die unter Microsoft Windows NT 4.0 verfügbar sind. 3 CORBA Common Object Request Broker Architecture 4 DCOM Distributed Component Object Model 5 ORB Object Request Broker 13

15 Kapitel 3 Planungsphase (Lastenheft) Als Entwicklungsumgebung wird das Visual Studio 5.0 bzw. 6.0 der Microsoft Corp. verwendet. 3.9 Zeitplanung Für die Realisierung der Diplomarbeit inkl. Dokumentation und Test wird eine Dauer von 6 Monaten angesetzt. 14

16 Kapitel 4 Planungsphase (Pflichtenheft) 4 Planungsphase (Pflichtenheft) 4.1 Produktfunktionen Kommunikationsschnittstelle (Socket) /F10/ /F20/ /F30/ /F40/ /F50/ /F60/ /F70/ Registrierung von Klassen. Kontaktierung eines Rechners (Client). Entgegennahme von Anfragen (Server). Versenden von Instanzen. Empfang von Instanzen registrierter Klassen. Beendigung einer Netzwerkverbindung. Spezifikation eines Funktionsaufrufs mit n Attributen Kommunikationsschnittstelle (Skeleton Stub) 6 /F110/ Installation einer Softwarekomponente (lokal). /F120/ Überprüfung der lokalen Aktualität einer Softwarekomponente (Version/vorhanden). /F130/ Überprüfung der lokalen Aktualität von Softwarekomponenten einer kompletten Datenbank von Softwarekomponenten (Version/vorhanden). /F140/ Erfragen einer Softwarekomponente, die auf dem Rechner installiert ist. /F150/ Deinstallation einer Softwarekomponente (lokal). /F160/ Hinzufügen einer Aufgabenstellung (lokal). /F170/ Zurücksenden einer bearbeiteten Aufgabenstellung. /F180/ Ermittlung des voraussichtlichen Zeitaufwands zur Bearbeitung einer Aufgabenstellung aus der Spezifikation der Datenmenge und der zugehörigen Anwendung. /F190/ Zuweisung einer Aufgabenstellung an den Dienst ProcessDistributor auf dem lokalen Rechner mit anschließender Verteilung Softwarekomponenten /F210/ /F220/ /F230/ Spezifikation einer Umgebung, in der ProcessDistributor Softwarekomponenten installieren und auffinden kann. Spezifikation einer Softwarekomponente. Lokale (De-)Installation von Softwarekomponenten. 6 Die Kommunikationsschnittstelle verwendet den in beschriebenen Mechanismus. 15

17 Kapitel 4 Planungsphase (Pflichtenheft) /F240/ Versenden und Empfang einer Softwarekomponente Verfügbarkeit von Softwarekomponenten /F310/ /F320/ /F330/ /F340/ /F350/ /F360/ /F370/ Spezifikation eines Ordnungsprinzips der Rechner untereinander im Verbund. Ermittlung eines Partners im Rechnerverbund aufgrund /F310/ zur Ermittlung der aktuellen Softwarekomponenten. Versendung einer aktuellen Datenbank lokal installierter Softwarekomponenten. Empfang einer Beschreibung einer Softwarekomponente mit anschließender Überprüfung, ob die Softwarekomponente auf dem lokalen Rechner in angemessener Versionsnummer zur Verfügung steht. Lokale (De-) Installation einer Softwarekomponente. Persistenz der lokalen Datenbank aktuell installierter Softwarekomponenten. Dienstprogramm zur Initiierung eines verteilten (De-) Installationsvorganges Aufgabenstellungen /F410/ /F420/ /F430/ /F440/ Spezifikation einer Umgebung, in der ProcessDistributor Aufgabenstellungen bearbeitet. Anfügen einer Aufgabenstellung an eine Warteschlange lokal zu bearbeitender Aufgabenstellungen. Es soll immer nur eine Aufgabenstellung aktuell bearbeitet werden. Rückversenden einer bearbeiteten Aufgabenstellung an den Auftraggeber (Rechner). Algorithmus zur Bearbeitung von an die Warteschlange angefügten Aufgabenstellungen (separater kontrollierender Thread) Optimierte Verteilung von Aufgabenstellungen /F510/ /F520/ /F530/ /F540/ /F550/ /F560/ /F570/ Ermittlung des Rechenaufwands zu bereits bearbeiteten Aufgabenstellungen. Spezifikation einer Schätzfunktion zur Abschätzung des Rechenaufwands einer Aufgabenstellung. Berechnung der Schätzfunktion aus bereits aufgenommenen Messwerten des Rechenaufwands. Ermittlung eines Schätzwertes zur Bestimmung des voraussichtlichen Rechenaufwands einer durch die Menge der Eingabedaten und die verknüpfte Anwendung gekennzeichneten Aufgabenstellung. Ermittlung einer Anzahl von Partnern der aktuell verfügbaren Rechner im Verbund bei der Verteilung von Aufgabenstellungen. Ermittlung des optimalen Partners zur Bearbeitung einer Aufgabenstellung. Schreiben einer Datei im Format MATLAB mit aufgezeichneten Messdaten 16

18 Kapitel 4 Planungsphase (Pflichtenheft) und der berechneten Schätzfunktion selbst, um die Qualität der Abschätzung für verschiedenen Anwendungen zu überprüfen. 4.2 Produktdaten /D10/ /D20/ /D30/ /D40/ /D50/ Softwarekomponente: Eindeutiger Bezeichner, Versionsnummer, Anzahl der DLLs, Anzahl anderer Dateien, Vektor der Bezeichner der zugeordneten DLLs, Vektor der Bezeichner der zugeordneten anderen Dateien, Statistikmodul zur Behandlung der Abschätzung des Rechenaufwands. Die Softwarekomponente wird in einer INI-Datei spezifiziert, die im selben Verzeichnis steht wie die Softwarekomponente selbst. Softwarekomponentendatenbank: Vektor der installierten Softwarekomponenten. Zur Sicherung der Persistenz wird eine Datei mit der serialisierten Form der Softwarekomponenten-Datenbank auf der lokalen Festplatte angelegt. Aufgabenstellung: Eindeutiger Bezeichner der zugeordneten Softwarekomponente, benötigte Versionsnummer, Vektor der Bezeichner der Eingabedateien, Vektor der Bezeichner der Ausgabedateien, Pfadangabe der Eingabedateien auf dem Rechner des Auftraggebers, Pfadangabe der Ausgabedateien des Rechners des Auftraggebers, Parameterzeile. Eine Aufgabenstellung kann entweder in einer INI-Datei beschrieben oder durch Methodenaufrufe dynamisch erstellt werden. Statistikmodul zur Abschätzung des Rechenaufwands einer Aufgabenstellung: Vektor mit Zuordnungen von Datenmenge und benötigter Rechenaufwand, Matrizen und Vektoren zur Bestimmung der Schätzfunktion. MATLAB-Datei mit Vorschrift zur Anzeige eines X-Y-Diagramms aufgenommener Messwerte und der generierten Schätzfunktion. 4.3 Produkt-Leistungen /L10/ /L20/ /L30/ Es soll in einem variabel einstellbaren Zeitintervall jeweils überprüft werden, ob sich ein neuer Partner gemäß /F310/ und /F550/ ergibt. Die Bearbeitung einer Aufgabenstellung soll mit niedriger Priorität auf dem lokalen System erfolgen (vgl. /F420/). Die maximale Anzahl an Partnern, die bei der Verteilung von Aufgabenstellung berücksichtigt werden, soll variabel einstellbar sein (vgl. /F550/). 17

19 Kapitel 4 Planungsphase (Pflichtenheft) 4.4 Benutzungsschnittstelle /B10/ Dialogfeldbasierendes Dienstprogramm zur (De-)Installation von Softwarekomponenten. /B20/ Dialogfeldbasierendes Dienstprogramm zur Demonstration der Verteilung einer Aufgabenstellung mit Hilfe des die Diplomarbeit umfassenden Klassenpakets. /B30/ Dialogfeldbasierendes Dienstprogramm zur Anzeige der Softwarekomponenten-Datenbank. 4.5 Qualitäts-Bestimmung Produktqualität sehr gut gut Normal Funktionalität X Zuverlässigkeit X Benutzbarkeit X Geschwindigkeit X Änderbarkeit X Stabilität X Verträglichkeit X Übertragbarkeit X nicht relevant Tabelle 4-1: Qualitätsbestimmung 4.6 Globale Testfälle /T10/ /T20/ /T30/ /T40/ /T50/ /T60/ Einzelner Rechner wird gestartet. Alle Ausführungen lokal (IP-Monitor). Lokale (De-)Installation einer Softwarekomponente. Ein weiterer Rechner wird gestartet und blendet sich in den Rechnerverbund ein. Abgleich der Softwarekomponenten. (De-)Installation einer Softwarekomponente bei mehreren verfügbaren Rechnern im Rechnerverbund. Versenden einer Aufgabenstellung an einen Partner ohne vorherige Auswertung der Statistik. Überprüfung der Statistikdaten mittels MATLAB nach häufiger Ausführung einer Aufgabenstellung. 18

20 Kapitel 4 Planungsphase (Pflichtenheft) /T70/ /T80/ /T90/ /T100/ /T110/ Bestimmung des optimalen Partners bei Kontaktieren mehrerer Rechner und Auswahl. Ordentliches Beenden des Programms. Programmabsturz simulieren. Es interessiert die Fragestellung, ob der Partner bei Abbruch einer Netzwerkverbindung korrekt weiterarbeiten kann. Netzwerkstörung simulieren. Spezialfall: In einem durch eine Netzwerkstörung in zwei Bereiche geteilten Rechnerverbund werden in beiden Bereichen zwei unterschiedliche Softwarekomponenten installiert. Stabilität der Applikation prüfen. 19