D5.3 Aktualisierte Ergebnisse der Evaluierung

Größe: px
Ab Seite anzeigen:

Download "D5.3 Aktualisierte Ergebnisse der Evaluierung"

Transkript

1 D5.3 Aktualisierte Ergebnisse der Evaluierung Arbeitspaket/Task: AP 5 Task 5.3 Fälligkeit: M36 Abgabetermin: Verantwortlich: NEC Versionsnummer/Status: 288 Final Autoren: Jeutter, Andreas Focht, Erich Volk, Eugen Schwitalla, Jürgen Lohrer, Marc Koudela, Daniela Belonozhka, Polina Mickler, Holger Schmidt, Matthias Schwarzkopf, Roland NEC NEC HLRS S&C S&C ZIH ZIH ZIH UMA UMA Interne Gutachter: Volk, Eugen Schwarzkopf, RolandMickler, Holger HLRS UMA ZIH Vertraulichkeitsstatus Öffentlich Projektintern Sonstiges: X Version Datum Änderungen Autor Erstellung Andreas Jeutter (NEC) 1/25

2 Erste Messungen am BWGrid Eugen Volk (HLRS) Erste Messungen am DEIMOS Holger Mickler (ZIH) Daniela Koudela (ZIH) Polina Belonozhka ('ZIH) Aktualisierte Messungen am BWGrid und DEIMOS Cluster Eugen Volk (HLRS) Holger Mickler (ZIH) Daniela Koudela (ZIH) Messungen und Evaluation am UMA Roland Schwarzkopf (UMA) Matthias Schmidt (UMA) Evaluation der Messergebnisse Alle Autoren 0.7 Review und Akutalisierung des Dokuments Holger Mickler (ZIH) Eugen Volk (HLRS) 2/25

3 Inhaltsverzeichnis 1 Einleitung Komponenten des Systems Abschließender Test des Gesamtsystems Test des TIMaCS-Frameworks Konfiguration der Testsysteme... 7 BWGrid... 7 Deimos Testszenarien Test-Szenario für den BWGrid Cluster Test-Szenario für den Deimos Cluster Durchführung der Tests Eingesetzte Testwerkzeuge zur Performancemessung Start / Stop des Testssystems Test und Evaluierung auf dem BWGrid Cluster Test und Evaluierung auf dem Deimos Cluster Test und Evaluierung der Virtualisierungslösung Konfiguration des Marburger Rechencluster (MaRC) Test-Szenario für den Marburger Rechencluster (MaRC) Testergebnisse auf dem Marburger Rechencluster (MaRC) Szenario 1: Übertragung von virtuellen Maschinen Szenario 2: Reduktion der Datenmenge von virtuellen Maschinen Szenario 3: Ausführungszeit Szenario 4: Migration von virtuellen Maschinen Zusammenfassung der Evaluation Zusammenfassung Referenzen /25

4 1 Einleitung In diesem Dokument werden die aktualisierten Ergebnisse der Evaluierung der finalen TIMaCS Softwarekomponenten dargestellt. Nachdem die Funktionalität sowie das Zusammenwirken und Integration der einzelnen Komponenten anhand des evaluierten Prototypen sichergestellt und in D5.2 [D5.2] dokumentiert wurde, soll nun in diesem Dokument die Leistungsfähigkeit mit besonderem Fokus auf Skalierbarkeit anhand der finalen Version der Software evaluiert werden. Die TIMaCS-Software wird hierzu nicht mehr auf dem zur Verfügung stehenden Entwicklungssystem (TIMaCS Cluster bestehend aus sechs Knoten) getestet sondern auf mehreren realen Cluster installiert und geprüft. Die hierzu verwendeten Systeme sind a) BWGrid [BWG] mit etwa 500 Knoten am HLRS, b) der Deimos Cluster [DMC] mit mehr als 700 Knoten des ZIH, und c) MaRC Cluster der Uni-Marburg. 4/25

5 2 Komponenten des Systems In der folgenden Abbildung 1 ist die Gesamtarchitektur des TIMaCS Systems und die Interaktion der einzelnen TIMaCS Knoten dargestellt, entsprechend der Beschreibung und Darstellung in [D1.2] und [D1.3].,,...,,, 1 1 Die logische Struktur eines TIMaCS Knotens, dargestellt in Abbildung 2, wird durch einen Monitoring- und einen Management-Block gebildet. Die Funktion und die Schnittstellen der Komponenten des TIMaCS-Frameworks (Monitoring- und Management-Block) wurden in [D1.2] und [D1.3] beschrieben. 5/25

6 ,, / 1 3 Abschließender Test des Gesamtsystems Der abschließende Performance-Test der TIMaCS-Komponenten gliedert sich in zwei Test-Typen: Test des TIMaCS-Frameworks auf dem BWGrid Cluster am HLRS auf dem Deimos Cluster am ZIH Test der Virtualisierungslösung auf dem MaRC Cluster der Uni-Marburg Dabei wurden unterschiedliche Konfigurationen getestet, die sich in der Anzahl und im Typ der Knoten, installierten Betriebssysteme, und TIMaCS-Hierarchien unterscheiden. 3.1 Test des TIMaCS-Frameworks Der Test des TIMaCS-Frameworks ist darauf ausgerichtet, die Performance der TIMaCSKomponenten zu erfassen, um eine Aussage über die Skalierbarkeit des TIMaCS-Frameworks treffen zu können. Die Tests wurden auf dem BWGrid Cluster am HLRS und auf dem Deimos Cluster am ZIH durchführt. 6/25

7 3.1.1 Konfiguration der Testsysteme Im Folgenden wird die Konfiguration der einzelnen Systeme gezeigt, auf denen die Komponenten getestet wurden. Im Allgemeinen sind die Compute-Knonten eines Clusters mit mehreren Netzwerkschnittstellen ausgestattet. Wobei es sich hier normalerweise um ein gewöhnliches Ethernet Netzwerk und ein zusätzliches High Performance Netzwerk wie z. B. InfiniBand handelt. Das letztere sollte den rechenintensiven Anwendungen vorbehalten sein, so dass TIMaCS derart konfiguriert wird, dass es das verbleibende Ethernet benutzt. BWGrid Der BWGrid Cluster am HLRS besteht aus 39 IBM Bladecenter HS21XM mit jeweils 14 Knoten, und hat insgesamt 545 Knoten [BWG]. Jeder Knoten beinhaltet 2 Intel Xeon E5440 Harpertown Prozessoren mit je 12 MB Cache, 16 GB Hauptspeicher, keinen lokalen Platten, ein InfiniBandNetzwerk für die Berechnung und GBit Ethernet als Managementnetzwerk. Des Weiteren gibt es einen Infrastrukturserver, der das Batchsystem mit Torque/Moab beinhaltet und mehrere Frontends (IBM x3650 mit der gleichen CPU/SpeicheraAusstattung) für den Zugang per SSH und Grid Middleware (Globus, GSI-SSH, Unicore). Die Knoten werden mit Scientific Linux 5 betrieben. Für den Cluster stehen zusätzlich 100 TB an Plattenkapazität zur Verfügung. Dieser Cluster wird im Rahmen von D-Grid von vielen VOs genutzt. Zur Erfassung des Zustands der Knoten des BWGrid Clusters wird Cluster Node Checker [CNM] verwendet. Hierzu werden in regelmäßigen Abständen auf jedem Knoten mehrere Test-Skripts aufgerufen, die den Zustand der Services (Job-Status, SSH-Status,..) und der Komponenten (Memory, CPU,...) ermitteln und das Ergebnis der Checks in eine zentrale Datenbank (MySQL) eintragen, die auf einem dedizierten Infrastruktur-Knoten läuft. Das TIMaCS-Framework fragt diese Datenbank in regelmäßigen Abständen ab und verarbeitet die Daten. Alle Komponenten des TIMaCS-Frameworks werden innerhalb einer VM-Instanz (KVM, mit Linux-Debian) auf einem dedizierten Knoten ausgeführt. Deimos Deimos ist ein x86-cluster, der am ZIH vorwiegend für sogenanntes Capacity-Compting verwendet wird, das heißt, viele voneinander unabhängige Jobs werden parallel ausgeführt, bspw. um Parameterstudien durchzuführen. Ende November 2011 wurde ein Teil des Clusters abgebaut, die daraus resultierenden Zahlen sind nachfolgend in Klammern aufgeführt. Alle Knoten von Deimos sind mit AMD Opteron Dual-Core Prozessoren ausgestattet. Die Konfiguration der einzelnen Knoten kann in 4 Klassen unterteilt werden: Singles, Duals, Quads und FatQuads. Diese unterscheiden sich hinsichtlich Anzahl verfügbarer CPUs und Menge des Hauptspeichers. Insgesamt stehen 724 (564) Knoten mit 2576 (2256) Prozessor-Cores für NutzerJobs zur Verfügung, wovon 384 (224) mit einem Prozessor ( Singles ), 228 mit zwei Prozessoren ( Duals ) und 112 mit vier Prozessoren ( Quads und FatQuads ) ausgestattet sind. Die 7/25

8 Heimatverzeichnisse der Nutzer sowie ein Pfad für temporäre Dateien befinden sich in globalen Dateisystemen, die mittels Lustre an die Knoten angebunden sind. Tabelle 1 enthält eine Übersicht zu den Austattungsmerkmalen der verschiedenen Knoten. Singles Duals Quads FatQuads Anzahl Cores Hauptspeicher 4 GB 8 GB 16 GB 32 GB Kommunikations netzwerk SDR InfiniBand 4x (1 GB/s) I/O-Netzwerk (Lustre) SDR InfiniBand 4x (1 GB/s) Service-Netzwerk Lokales Dateisystem /tmp (Ext3) Fast Ethernet (100 MBit/s) 80 GB 160 GB 320 GB Globales Dateisystem /home (Lustre) 68 TB Globales Dateisystem /fastfs (Lustre) 68 TB 320 GB Betriebssystem SuSE Linux Enterprise Server 10 SP4 (Kernel Lustre ) Batch-System Platform LSF Version 6.2 Tabelle 1: Ausstattung der verschiedenen Knotenklassen des Deimos Clusters Zum Test von TIMaCS wurde zuerst eine dreistufige Hierarchie erstellt (Konfiguration A), für deren Master-Knoten Single -Rechenknoten von Deimos exklusiv abgestellt wurden. Diese Hierarchie ist in Abbildung 3 dargestellt und die zugehörige Konfigurationsdatei in Tabelle 2 auszugsweise gelistet. Die TIMaCS Master-Knoten der oberen zwei Ebenen haben jeweils drei TIMaCS-Master unter sich, so dass sich auf der untersten Ebene neun TIMaCS Master-Knoten befinden. Auf jedem TIMaCS Master-Knoten laufen ein AMQP-Broker, ein htimacsd-daemon sowie die TIMaCS Rule-Engine. An den Master-Knoten der untersten Ebene werden Importer von htimacsd zum Sammeln von Ganglia-Metriken der Service- und Compute-Knoten des Clusters gestartet. Weiterhin werden Statusmeldungen von Nagios auf einem Master-Knoten der zweiten Ebene (p2s080) importiert. Die htimacsd-daemons jeder Ebene aggregieren die in dieser Ebene gesammelten Metriken und bilden Minimum-, Durchschnitts- und Maximalwerte. Diese Werte werden an die übergeordnete Ebene weitergeleitet, wo sie eine ressourcenschonende Sicht auf die darunterliegenden Systeme ermöglichen. 8/25

9 Abbildung 3: Dreistufige Hierarchie der TIMaCS Master-Knoten unter Verwendung von Rechnenknoten von Deimos Eine andere Hierarchie (Konfiguration B) mit insgesamt drei Knoten kommt für den Produktivbetrieb von TIMaCS zum Einsatz (siehe Abbildung 4). Diese besteht aus nur drei Rechnern, von denen einer als AMQP-Broker fungiert (timacs3), während die anderen beiden in einer simplen zweistufigen Hierarchie angeordnet sind. Der Wurzelknoten (timacs1) hat dabei htimacsd und die Policy-Engine laufen, während der Kindknoten (timacs2) mittels htimacsd Metriken von Ganglia, Nagios und weiteren Quellen importiert, sowie die Rule-Engine ausführt. Abbildung 4: Einfache Hierarchie mit separatem AMQP-Broker Die Hardware der drei TIMaCS-Knoten aus Konfiguration B besteht aus Komponenten wie in Tabelle 3 aufgeführt ist. Der AMQP-Server hat weniger Rechenleistung als die TIMaCS-Master, dafür aber mehr Arbeitsspeicher, um bei eventuellen Engpässe bei der Abholung von Nachrichten diese nicht langsam auf Festplatte zwischenspeichern zu müssen. Weiterhin ist die reine Verteilung der Nachrichten nicht so rechenintensiv, dass dies mittelfristig leistungsbeschränkend würde. 9/25

10 /p2s111 m:/ /l1g1/p1s100 m:/l1g1 /l1g2/p2s080 m:/l1g2 /l1g3/p2s250 m:/l1g3 /l1g1/l2g1/p1s010 m:/l1g1/l2g1 /l1g1/l2g2/p1s040 m:/l1g1/l2g2 /l1g1/l2g3/p1s080 m:/l1g1/l2g3 /l1g2/l2g4/p1s120 m:/l1g2/l2g4 /l1g2/l2g5/p2s040 m:/l1g2/l2g5 /l1g2/l2g6/p2s120 m:/l1g2/l2g6 /l1g3/l2g7/p2s160 m:/l1g3/l2g7 /l1g3/l2g8/p2s200 m:/l1g3/l2g8 /l1g3/l2g9/p2s240 m:/l1g3/l2g9 /l1g1/l2g1/p1q001 /l1g1/l2g1/p1q002 [...] /l1g1/l2g2/p1q017 /l1g1/l2g2/p1q018 [...] /l1g1/l2g3/p1s041 /l1g1/l2g3/p1s042 [...] Tabelle 2: Auszug aus der Konfigurationsdatei der dreistufigen Hierarchie timacs1, timacs2 timacs3 Prozessor 2x AMD Opteron 2220 (2,8 GHz) 1x AMD Opteron 256 (3 GHz) Anzahl Cores 4 2 Hauptspeicher 8 GB 16 GB Netzwerk Gigabit Ethernet Lokales Dateisystem 120 GB Betriebssystem SuSE Linux Enterprise Server 11 SP1 (Kernel ) 60 GB Tabelle 3: Hardware des TIMaCS Produktionssystems am ZIH Testszenarien In diesem Kapitel werden die Testszenarien beschrieben, die auf den unterschiedlichen Clustern durchgeführt wurden. 10/25

11 Test-Szenario für den BWGrid Cluster Auf jedem der 545 Knoten des BWGrid Clusters werden 24 Tests (vgl. Tabelle 4) von dem Cluster Node Checker [CNM] durchführt. Das Ergebnis der Tests wird in eine Datenbank geschrieben, unter Angabe der Knoten-ID, der Check-ID und des Datums. Zur Test-Zeit befanden sich ca Einträge in der Datenbank. Der Testablauf ist wie folgt: Der Importer der TIMaCS Monitoring-Komponente ist so konfiguriert, dass er die Daten aus der MySQL Datenbank in regelmäßigen Abständen abfragt und diese auf dem Metrik-Kanal publiziert. Dabei werden die Daten von der TIMaCS Storage-Komponente konsumiert und gespeichert. Der Filter&Event Generator analysiert empfangene Metrik-Daten und vergleicht sie mit vordefinierten Schwellwerten. Bei einer Abweichung werden Events erzeugt und anschließend auf dem Message-Bus (AMQP-Server) publiziert. Die Policy-Engine abonniert die Event-Nachrichten, die von dem Filter&Event Generator auf dem Message-Bus publiziert werden. Die empfangenen Event-Nachrichten werden nun von der Policy-Engine weiterverarbeitet. In Abhängigkeit von dem Zustand, der in der Event-Nachricht spezifiziert ist, wird eine entsprechende Aktion bzw. Befehl umgewandelt und an den betroffenen Delegate übermittelt. Der Delegate, der für das Empfangen der Kommando-Nachrichten für den Host zuständig ist, empfängt nun die entsprechende Kommando-Nachricht von der Policy-Engine und führt das Kommando aus. 11/25

12 Id Name des Checks/Tests 1./plugins/remote/check_ping 2./plugins/local/check_ramdisk.sh 3./plugins/local/check_swap.sh 4./plugins/local/check_ib.sh 5./plugins/local/check_init_procs.sh 6./plugins/local/check_mcelog.sh 7./plugins/local/check_uptime.sh 8./plugins/local/check_filesystems.sh 9./plugins/local/check_dmesg.sh 10./plugins/local/check_user_procs.sh 11./plugins/remote/check_local_plugins 12./plugins/local/.check_ramdisk.sh.swp 13./plugins/local/check_lustre.sh 14./plugins/local/.check_lustre.sh.swp 15./plugins/local/compute_node_HW_inventory.sh 16./plugins/local/check_reboot.sh 17./plugins/local/.check_reboot.sh.swp 18./plugins/remote/check_failure_led 19./plugins/local/check_node_image_version.sh 20./plugins/local/check_nobatchprocs.sh 21./plugins/local/.check_nobatchprocs.sh.swp 22./plugins/remote/.check_failure_led.swp 23./plugins/local/.check_node_image_version.sh.swp 24./plugins/local/.compute_node_HW_inventory.sh.swp Tabelle 4: Checks auf jedem Knoten des BWGrid Clusters In jedem der Schritte wird die Geschwindigkeit gemessen, mit der die Daten/Events verarbeitet und publiziert werden. 12/25

13 Test-Szenario für den Deimos Cluster Das Szenario für den Test des TIMaCS-Frameworks auf dem Deimos Cluster entspricht der Beschreibung in D5.2 [D5.2] und besteht aus den folgenden Schritten: 1. Nagios und Ganglia erfassen auf jedem Knoten den Zustand der Services und der Komponenten. Dabei werden die in Tabelle 5 aufgeführten Metriken verwendet. 2. Der Importer liest alle Monitoring-Daten aus dem Nagios-Log und GangliaXMLMetric aus und publiziert diese auf dem Metrik-Kanal. 3. Der Filter&Event Generator liest und verarbeitet die Metriken auf dem Metrik-Kanal und wandelt diese in entsprechende Event-Nachrichten um. Die Event-Nachrichten werden anschließend auf dem Message-Bus (AMQP-Server) publiziert. 4. Die Policy-Engine abonniert die Event-Nachrichten, die von dem Filter&Event Generator auf dem Message-Bus publiziert werden. Die empfangene Event-Nachrichten werden nun von der Policy-Engine weiterverarbeitet. In Abhängigkeit von dem Zustand, der in der Event-Nachricht spezifiziert ist, wird eine entsprechende Aktion bzw. Befehl umgewandelt und an den betroffenen Delegate übermittelt. 5. Der Delegate, der für das Empfangen der Kommando-Nachrichten für den Host zuständig ist, empfängt nun die entsprechende Kommando-Nachricht von der Policy-Engine und führt das Kommando aus. In jedem der Schritte wird die Geschwindigkeit gemessen, mit der die Daten/Events verarbeitet und publiziert werden. Die in Tabelle 5 aufgelisteten Metriken werden in vorgegebenen <min> Abständen erfasst. Wenn die Änderung zum letzten Wert größer ist als ein definierter Wert, werden alle Daten der Gruppe gesendet. Spätestens jedoch nach <max> werden in jedem Fall alle Daten der Gruppe gesendet. D. h. das minimale Invervall ist durch <min> bestimmt, das maximale Intervall ist entsprechend durch <max> bestimmt. Ausgehend von den beiden Intervallen lässt sich wie in Tabelle 6 berechnet, die minimale (0.25 Metriken/Sekunde und Host) und die maximale (0.9 Metriken/Sekunde und Host) Häufigkeit bzw. Geschwindigkeit ermitteln, mit der die Metriken pro Host erfasst werden. 13/25

14 Metrik-Name Abfrageintervall [min/max] heartbeat 20 s cpu_num, cpu_speed, mem_total, swap_total, boottime, machine_type, os_name, os_release 1200 s cpu_user, cpu_system, cpu_idle, cpu_nice, cpu_aidle, cpu_wio, cpu_intr, cpu_sintr, load_one, load_five, load_fifteen 20 / 90 s proc_run, proc_total 80 / 950 s mem_free, mem_shared, mem_buffers, mem_cached, swap_free, disk_free, part_max_used 40 / 180 s bytes_out, bytes_in, pkts_out, pkts_in 40 / 300 s disk_total 1800 / 3600 s Tabelle 5: Erfasste Metriken mit Abfrage-Intervall pro Metrik und Host Abfrage-Intervall [in Sekunden] Anzahl der Metriken Abfrage-Häufigkeit gesamt [pro Sekunde] min max max min ,05 0, , , ,55 0, ,025 0, ,175 0, ,1 0, , , , ,25 Tabelle 6: Berechnung der maximalen und minimalen Abfrage-Häufigkeit der Metriken pro Host 14/25

15 3.1.3 Durchführung der Tests Die Performance Tests sind darauf ausgerichtet, die Geschwindigkeit zu messen, mit der die Daten von den TIMaCS-Komponenten verarbeitet werden. Die nachfolgenden Teilkapitel beschreiben eingesetzte Testwerkzeuge und start/stop des Testsystems. Eingesetzte Testwerkzeuge zur Performancemessung Die Performance-Messung erfolgt mit Hilfe des RabbitMQ-Management-Plugins. Das Plugin erlaubt eine Messung der Geschwindigkeit (Messages per second) mit der die Nachrichten auf jedem Exchange publiziert werden. Da jede TIMaCS-Komponente einen dedizierten Exchange für das Publizieren von Nachrichten verwendet (vgl. Tabelle 7), kann mit Hilfe des RabbitMQManagement-Plugins die Geschwindigkeit gemessen werden, mit der jede TIMaCS-Komponente die Nachrichten erzeugt. Da der Verarbeitungsprozess im TIMaCS Framework deterministisch ist, erlaubt die Messung der Geschwindigkeit mit der die Nachrichten erzeugt werden einen Rückschluss auf die Verarbeitungsgeschwindigkeit der eingehenden Nachrichten in jeder Komponente. Komponente ExchangeName Data-Collector metrics von dem Data-Collector erzeugte Metriken Rule-Engine events von der Rule-Engine erzeugte Events Policy-Engine policyengine Policy-Engine commands Beschreibung von der Policy-Engine erzeugte Event und Reports von der Policy-Engine erzeugte Befehle Tabelle 7:TIMaCS-Komponenten und ihre Exchanges Start / Stop des Testssystems Das Testsystem wird durch das vorinstallierte Skript timacs gestartet und auch wieder gestoppt. bin/timacs start Dieses Kommando startet den htimacsd Daemon auf allen TIMaCS-Knoten. Zum Stoppen des Daemons wird das obige Kommando mit der Option --stop verwendet. 15/25

16 3.1.4 Test und Evaluierung auf dem BWGrid Cluster Abbildung 5 veranschaulicht die Ergebnisse der Tests auf dem BWGrid Cluster und listet die Geschwindigkeiten für jede Exchange auf, mit der die Nachrichten publizieren bzw. verarbeitet werden. Tabelle 8 veranschaulicht die maximal gemessene Werte. Das Abfrage-Intervall zur Abfrage der Datenbank wurde mit Absicht klein gehalten, um die Performance-Grenzen der TIMaCS-Komponenten zu erfassen. Die tatsächliche Häufigkeit mit der die Tests durchgeführt werden ist abhängig von der Job-Dauer, da die Tests meistens zwischen den Jobs durchgeführt werden. Im Worst-Case, unter der Annahme dass die Tests alle 5 min ausgeführt werden, ergibt sich eine Geschwindigkeit von etwa (24 Metriken / (5 * 60 s)) 0,08 Metriken pro Sekunde und Host. Unter Berücksichtigung der in Tabelle 8 aufgeführten Maximalwerte ergibt sich damit eine maximal unterstütze Kapazität (Anzahl von Knoten) wie in Tabelle 9 dargestellt. 16/25

17 Komponente ExchnageName max Speed [msg/sec] Data-Collector metrics 558 Rule-Engine events 250 Policy-Engine policyengine 100 Tabelle 8: Maximale Geschwindigkeit auf dem BWGrid Cluster Komponente max Speed Abfrage-Häufigkeit [pro Sekunde und [msg/sec] Knoten] Max Kapazität [Anzahl der Knoten] Data-Collector 558 0, Rule-Engine 250 0, Policy-Engine 100 0, Tabelle 9: Berechnung der maximalen Monitoring-Kapazität Test und Evaluierung auf dem Deimos Cluster Anhand des Deimos Clusters wurde zunächst die Funktionsfähigkeit eines hierarchischen Aufbaus der TIMaCS-Komponenten getestet. Die dazu eingerichtete Konfiguration A (vgl. Kap ) stellt eine Variante dar, die in naher Zukunft für das Monitoring wahrscheinlich noch nicht notwendig sein wird. Trotzdem konnte nach Fehlerbereinigung des Codes die Funktionsfähigkeit von TIMaCS in dieser Konstellation sichergestellt werden. Konfiguration B (vgl. Kap ) wurde dahingegen auf ihre Performanz untersucht. Im ersten Schritt wurde aufgezeichnet, mit welcher Geschwindigkeit die Monitoring-Daten vom Deimos Cluster eintreffen. In Abbildung 6 ist zu sehen, dass die Daten in Schüben am AMQP-Server eintreffen (publish) und zur gleichen Zeit auch an die Abonnenten weitergeleitet werden (deliver). Die Zahl der ausgelieferten Nachrichten ist dabei höher als die der eintreffenden, weil mehrere Clients dieselben Kanäle abonnieren und an dieser Stelle Nachrichten dupliziert werden. Das schubweise Auftreten der Nachrichten ist durch die Arbeitsweise der Daten-Importer bedingt: sowohl der Ganglia- als auch der Nagios-Importer fragen in einem bestimmten Intervall die Quellen ab und speisen die Daten ins TIMaCS-System ein. Dieses Intervall ist für die Evaluierung auf 30 Sekunden eingestellt. 17/25

18 AMQP Nachrichtenaufkommen Ganglia und Nagios Nachrichtenrate publish_rate deliver_rate Zeit (s) Abbildung 6: Datenaufkommen des Monitorings vom Deimos-Cluster Eine längere Messung am AMQP-Server (ohne Abbildung) hat gezeigt, dass in dieser Konfiguration im Mittel 100 Monitoring-Nachrichten pro Sekunde publiziert und ungefähr 125 Nachrichten pro Sekunde ausgeliefert werden. Sowohl der htimacsd-daemon auf timacs2 als auch der AMQPServer haben keinerlei Probleme, diesen Nachrichtenfluss zu verarbeiten. Im zweiten Schritt wurden mittels eines speziellen Datengenerators (BurnInImporter) Metriken auf timacs2 generiert und in das TIMaCS-Framework eingespeist. Dieser Test sollte zum Einen zeigen, welches Datenaufkommen die Hardware in dieser Konfiguration noch verarbeiten kann und zum Anderen, ob die gesamte TIMaCS-Architektur unter diesen extremen Bedingungen stabil arbeitet. 18/25

19 AMQP Nachrichtendurchsatz 10s Burst Intervall, 20 Metriken je Host, 500 Hosts 2500 Nachrichtenrate publish_rate deliver_rate Zeit (s) Abbildung 7: Stresstest der TIMaCS-Installation zum Ermimtteln der maximalen Verarbeitungsgeschwindigkeit Abbildung 7 zeigt den Nachrichtendurchsatz am AMQP-Server in der genannten Konfiguration. Bei diesem Nachrichtenaufkommen hat der AMQP-Server immernoch Reserven, die begrenzende Komponente ist die Metrikverarbeitung im htimacsd-daemon. Mit einem schnelleren Prozessor oder Parallelisierung dieses Ablaufs könnte die Verarbeitungsgeschwindigkeit erhöht werden. In der aktuellen Version und mit der beschriebenen Hardware kann TIMaCS ca. 650 Metrik-Nachrichten pro Sekunde verarbeiten. Setzt man dies ins Verhältnis zu den 100 Nachrichten pro Sekunde, die durch das Monitoring der 564 Compute-Knoten + 20 Service-Knoten mittels Ganglia und Nagios im TIMaCS-System eintreffen, so bedeutet dies, dass ein TIMaCS-Server das Monitoring von (650/ [100/584]) ca Knoten leisten kann. 3.2 Test und Evaluierung der Virtualisierungslösung Die Evaluierung der Virtualisierungslösung wurde auf dem Marburger Rechencluster (MaRC) vorgenommen Konfiguration des Marburger Rechencluster (MaRC) Die Evaluierung der Virtualisierungslösung wurde auf dem Marburger Rechencluster (MaRC) vorgenommen. Clustermerkmale Compute-Knoten mit 2x AMD Opteron 2216HE (dual-core) Prozessoren 19/25

20 8 GB Hauptspeicher 2x Gigabit Ethernet Netzwerk lokale 250 GB Festplatte pro Knoten Betriebssystem Debian GNU Linux, Kernel mit Xen Version Test-Szenario für den Marburger Rechencluster (MaRC) Auf dem Marburger Rechencluster wurden verschiedene Tests zur Leistungsfähigkeit von Virtualisierungslösungen im HPC Umfeld durchgeführt. Diese Tests decken verschiedene Phasen des Einsatzes von virtuellen Maschinen (VMs) ab. Zunächst wurden in Szenario 1 verschiedene Algorithmen zum effizienten Ausrollen von Festplatten-Images von VMs getestet. Das Ausrollen der VMs auf die Compute-Knoten ist ein zeitkritischer Prozess. Bevor die VMs nicht auf den Compute-Knoten zur Verfügung stehen, können keine Jobs berechnet werden. Somit muss die zur Vervielfältigung und zur Übertragung benötigte Zeitspanne möglichst minimal sein. Zudem belastet die Verteilung die Netzwerk-Infrastruktur, d. h. die Verteilung einer großen VM könnte beispielsweise zu Überlastsituationen im Netzwerk führen. Würde eine 5 GB große VM 100 mal sequentiell kopiert, wäre die Verbindung zwischen dem QuellRechner und dem entsprechenden Switch-Port für längere Zeit überlastet und neue Transfers würden nur langsam oder gar nicht stattfinden. Als mögliche Kandidaten wurden ein Binärbaumbasierter Algorithmus, ein Peer-to-Peer basiertes Verfahren und eine Übertragung über Multicast untersucht. Um verwertbare Mittelwerte zu erzielen, wurden die Messungen jeweils 100 mal durchgeführt und zudem wurde die Größe der VM linear erhöht. Diese Messungen sind für die Installation in Marburg relevant, da vor Ort kein ausreichend schneller, geteilter Speicher (z. B. in Form eines NFS-/iSCSI-SAN) existiert. Bei den anderen Partnern ist dies gesichert. Am HLRS in Stuttgart steht auf dem BWGrid Cluster ein schneller, gemeinsamer Speicher zur Verfügung, so dass ein Ausrollen der VMs nicht nötig ist. Zur Optimierung der Übertragung von VMs wurde ein System zum Aufbau von VMs aus mehreren Schichten entwickelt. Diese VMs werden im folgenden Layered VMs genannt. Im Unterschied zu normalen VMs, die ein monolithisches Festplatten-Image verwenden, werden bei Layered VMs mehrere kleinere Festplatten-Images (Layer) eingesetzt. Diese Layer werden mit Hilfe eines Copyon-Write (COW) Dateisystems zu einem kompletten Dateisystem zusammengesetzt. Ein Vorteil dieses Konzepts ist die Wiederverwendbarkeit der Layer, die somit auf den physikalischen Knoten vorgehalten und bei ihrer Verwendung nicht erneut übertragen werden müssen. In Szenario 2 wurden zwei verschiedene Messungen mit Layered VMs durchgeführt, um die Geschwindigkeit des Zugriffs auf virtuelle Platten in normalen VMs und Layered VMs vergleichen zu können. Die ersten Messungen wurden mit bonnie++ in einer normalen VM und in LayeredVMs mit 2 und 3 Schichten durchgeführt. Die Messungen in Layered VMs wurden zudem einmal 20/25

21 normal und einmal mit der real read-only Option von aufs durchgeführt, die aufs für einige interne Optimierungen beim Umgang mit Schichten erlauben, die sich nicht verändern können. In jeder Konfiguration wurden 3 Tests mit bonnie++ durchgeführt. Bonnie++ führt alle Messungen mit einer einzigen oder wenigen großen Dateien durch. Neben diesen Zugriffen ist aber auch die Geschwindigkeit im Umgang mit vielen kleinen Dateien von Interesse. Ein hervorragender Indikator dafür ist die Dauer einer Übersetzung des Linux Kernels, im Zuge derer tausende kleine Dateien geöffnet und mindestens ebenso viele neu angelegt und geschrieben werden. Bei der zweiten Messung von Szenario 2 wurde der Kernel in jeder der oben beschriebenen Konfigurationen je 10 mal übersetzt und ein Mittelwert der Übersetzungszeit gebildet. Durch die Nutzung von Virtualisierungstechnologien wird die Laufzeit von Anwendungen erhöht. Dies hängt unter anderem mit dem erhöhten Verwaltungsaufwand für Speicher, Geräte, usw. zusammen. Um den Mehraufwand in Zahlen auszudrücken, wurde in Szenario 3 die Ausführungszeit einer typischen HPC-Anwendung einmal nativ und einmal virtuell gemessen. In Szenario 4 wurde die Zeit, die zur Migration einer VM benötigt wird, gemessen. Während der Migration wurde in der VM der Linux-Kernel übersetzt. Um einen robusten Mittelwert zu erhalten, wurde die Messung insgesamt 50 mal wiederholt Testergebnisse auf dem Marburger Rechencluster (MaRC) Szenario 1: Übertragung von virtuellen Maschinen In der folgenden Abbildung 8 sowie in Tabelle 10 sind die Ergebnisse der Messungen dargestellt. Es wurde jeweils ein VM Image mit 1024 MB, 2048 MB und 8192 MB übertragen. Auf der xachse sind die Versuche aufgetragen, während die benötigte Zeit in Sekunden auf der y-achse aufgetragen ist. Als Referenz gilt eine sequentielle Unicast-Übertragung von einem Knoten zu allen Zielknoten. Die Grafiken spiegeln die Erwartung wider. Während die Binärbaum-basierte Übertragung schneller als die Referenz ist, kann sie mit BitTorrent sowie Multicast nicht mithalten. Multicast steht eindeutig als schnellste Methode fest. Zudem ist die Verwendung von Multicast wesentlich einfacher als die Verwendung von BitTorrent, da der administrative Aufwand (u. a. durch die Erstellung von torrent-dateien, die vom Tracker benötigt werden) geringer ist. 21/25

22 Image Größe Unicast Binärbaum BitTorrent Multicast 1024 MB 191,1 s 95,7 s 62,3 s 45,5 s 2048 MB 401,0 s 183,8 s 120,9 s 90,6 s 4096 MB 815,2 s 367,4 s 214,3 s 121,8 s 8192 MB 1634,1 s 727,6 s 465,0 s 383,5 s Tabelle 10: Ergebnisse der Messungen Abbildung 8: Ergebnisse der Übertragungsmessungen Szenario 2: Reduktion der Datenmenge von virtuellen Maschinen Die Ergebnisse der Messungen mit bonnie++ sind in Abbildung 9 dargestellt. Die Messungen mit der real read-only Option von aufs sind in der Abbildung mit (rr) gekennzeichnet. Dabei misst write den Datendurchsatz beim Schreiben, read den Durchsatz beim Lesen und rewrite den Durchsatz bei einer Kombination von Lesen, Positionieren (seek) und Schreiben. Man kann sehen, dass die Verwendung von Layered VMs keine nennenswerten Einbrüche beim Datendurchsatz zur Folge hat. Die Schwankungen in beide Richtungen bewegen sich im Bereich < 3%. Abbildung 10 zeigt die Ergebnisse der Messungen der Übersetzungszeit des Linux Kernels. Bei der Verwendung einer Layered VM mit 2 Schichten verlängert sich die Übersetzungszeit um ca. 80 Sekunden bzw. 3 %, mit 3 Schichten um ca. 100 Sekunden bzw. 3,5%. Insgesamt ist die Geschwindigkeit des Festplatten-Zugriffs in Layered VMs vergleichbar mit der in normalen VMs. Die gemessenen Verschlechterungen sind alle im niedrigen einstelligen Prozentbereich. Entgegen der Erwartung führt der real read-only Modus von aufs nicht zu spürbaren Verbesserungen gegenüber dem normalen Modus. 22/25

D5.2 Ergebnisse der Evaluierung

D5.2 Ergebnisse der Evaluierung D5.2 Ergebnisse der Evaluierung Arbeitspaket/Task: AP 5 Task 5.2 Fälligkeit: M30 Abgabetermin: 30.06.11 Verantwortlich: Versionsnummer/Status: Autoren: Interne Gutachter: NEC Jeutter, Andreas (AJ) Focht,

Mehr

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25 XEN Performance Projektpraktikum Informatik Arne Klein 2008-02-26 Arne Klein () XEN Performance 2008-02-26 1 / 25 1 Virtualisierung mit XEN 2 Performance von XEN Allgemeines Netzwerk-Performance IO-Performance

Mehr

Voraussetzungen für jeden verwalteten Rechner

Voraussetzungen für jeden verwalteten Rechner Kaseya 2 (v6.1) Systemvoraussetzungen Voraussetzungen für jeden verwalteten Rechner Kaseya Agent 333 MHz CPU oder höher 128 MB RAM 30 MB freier Festplattenspeicher Netzwerkkarte oder Modem Microsoft Windows

Mehr

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa Berner Fachhochschule Hochschule für Technik und Informatik HTI Performance und Bandbreitenmanagement Tests Version 10.01.2005 Diplomarbeit I00 (2004) MuSeGa Mobile User Secure Gateway Experte: Andreas

Mehr

Leistungsanalyse von Rechnersystemen

Leistungsanalyse von Rechnersystemen Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) Leistungsanalyse von Rechnersystemen Auf Ein-/Ausgabe spezialisierte Benchmarks Zellescher Weg 12 Willers-Bau A109 Tel. +49 351-463 - 32424

Mehr

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

Mehr

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 Inhaltsverzeichnis Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 1. Terminal-Server-Betrieb (SQL)... 3 1.1. Server 3 1.1.1. Terminalserver... 3 1.1.2. Datenbankserver (bei einer Datenbankgröße

Mehr

Hochleistungsrechnen mit Windows Interaktive Benutzung und das Batchsystem Christian Terboven Rechen- und Kommunikationszentrum RWTH Aachen

Hochleistungsrechnen mit Windows Interaktive Benutzung und das Batchsystem Christian Terboven Rechen- und Kommunikationszentrum RWTH Aachen Hochleistungsrechnen mit Windows Interaktive Benutzung und das Batchsystem hristian Terboven Rechen- und Kommunikationszentrum RWTH Aachen 1 Hochleistungsrechnen mit Windows enter omputing and ommunication

Mehr

D1.3 TIMaCS Gesamtarchitektur V2

D1.3 TIMaCS Gesamtarchitektur V2 D1.3 TIMaCS Gesamtarchitektur V2 Arbeitspaket/Task: Fälligkeit: AP1/T1.2 M25 Abgabetermin: 31.01.11 Verantwortlich: Versionsnummer/Status: Autoren: Interne Gutachter: HLRS Volk, Eugen Koudela, Daniela

Mehr

bw-grid Cluster in Mannheim

bw-grid Cluster in Mannheim bw-grid Cluster in Mannheim Dr. Heinz Kredel mit Helmut Fränznick, Rudi Müller, Steffen Hau, Andreas Baust Inhalt Grid und D-Grid BMBF Projekt bw-grid Cluster Stand: Aufbau und Inbetriebnahme Benutzung

Mehr

UBELIX University of Bern Linux Cluster

UBELIX University of Bern Linux Cluster University of Bern Linux Cluster Informatikdienste Universität Bern ID BEKO Grid Forum 7. Mai 2007 Inhalt Einführung Ausbau 06/07 Hardware Software Benutzung Dokumentation Gut zu wissen Kontakt Apple/Mac:

Mehr

Systemanforderungen ab Version 5.31

Systemanforderungen ab Version 5.31 Systemanforderungen ab Version 5.31 Auszug aus BüroWARE Erste Schritte Version 5.4 Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive Das Programm kann sowohl auf 32 Bit- als auch auf 64 Bit-en

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum CORVUS by init.at... 3 3 Ihre Vorteile durch CORVUS... 3 4 CORVUS Features... 4

Mehr

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Martin Däumler Matthias Werner Lehrstuhl Betriebssysteme Fakultät für Informatik

Mehr

Linux Cluster in Theorie und Praxis

Linux Cluster in Theorie und Praxis Foliensatz Center for Information Services and High Performance Computing (ZIH) Linux Cluster in Theorie und Praxis Monitoring 30. November 2009 Verfügbarkeit der Folien Vorlesungswebseite: http://tu-dresden.de/die_tu_dresden/zentrale_einrichtungen/

Mehr

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16 2. Braunschweiger Linux-Tage Vortrag über RAID von Thomas King http://www.t-king.de/linux/raid1.html 2. Braunschweiger Linux-Tage Seite 1/16 Übersicht: 1. Was ist RAID? 1.1. Wo wurde RAID entwickelt? 1.2.

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003

Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003 Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003 In diesem Whitepaper werden zwei wichtige NAS Betriebssysteme gegenübergestellt und auf ihre

Mehr

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen?

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Umgebung Getestet wurde auf einem Linux-System mit voller invis-server Installation, auf dem eine virtuelle Maschine

Mehr

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Dieses Dokument dient zur Information über die Organisation der Projektphasen und der technischen Vorbereitung eines Refile

Mehr

Systemvoraussetzungen. Hardware und Software MKS AG

Systemvoraussetzungen. Hardware und Software MKS AG Goliath.NET Systemvoraussetzungen Hardware und Software MKS AG Version: 1.4 Freigegeben von: Stefan Marschall Änderungsdatum: 20.10.2013 Datum: 29.10.2013 Goliath.NET-Systemvoraussetzungen Hardware-Software.docx

Mehr

Virtualisierung. Zinching Dang. 12. August 2015

Virtualisierung. Zinching Dang. 12. August 2015 Virtualisierung Zinching Dang 12. August 2015 1 Einführung Virtualisierung: Aufteilung physikalischer Ressourcen in mehrere virtuelle Beispiel: CPUs, Festplatten, RAM, Netzwerkkarten effizientere Nutzung

Mehr

Virtuelle Infrastrukturen mit Linux...

Virtuelle Infrastrukturen mit Linux... Virtuelle Infrastrukturen mit Linux...... und deren Integration in OSL SC Christian Schmidt Systemingenieur Virtualisierung "Aufteilung oder Zusammenfassung von Ressourcen" Unterschiedliche Bereiche für

Mehr

Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung

Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung Fritz Günther 17.03.2014 Folie 1 Agenda Was ist Virtualisierung Server- / Clientvirtualisierung

Mehr

ALL NEW GROUNDWORK 7.0.2

ALL NEW GROUNDWORK 7.0.2 ALL NEW GROUNDWORK 7.0.2 11 gute Gründe für den Umstieg / Upgrade 1. Benutzerfreundlichkeit 2. Performance 3. Sicherheit 4. CloudHub 1.3 5. Kostenloser Upgrade 6. Business Service Management 7. Authentifikation

Mehr

Lasttestbericht BL Bankrechner

Lasttestbericht BL Bankrechner Lasttestbericht BL Bankrechner Business-Logics GmbH Inhaltsverzeichnis 1 Testumgebung 2 1.1 Hardwareversionen........................ 2 1.2 Softwareversionen........................ 3 1.3 Datenbestand..........................

Mehr

PVFS (Parallel Virtual File System)

PVFS (Parallel Virtual File System) Management grosser Datenmengen PVFS (Parallel Virtual File System) Thorsten Schütt thorsten.schuett@zib.de Management grosser Datenmengen p.1/?? Inhalt Einführung in verteilte Dateisysteme Architektur

Mehr

4. Optional: zusätzliche externe Speicherung der Daten in unserem Rechenzentrum

4. Optional: zusätzliche externe Speicherung der Daten in unserem Rechenzentrum KMU Backup Ausgangslage Eine KMU taugliche Backup-Lösung sollte kostengünstig sein und so automatisiert wie möglich ablaufen. Dennoch muss es alle Anforderungen die an ein modernes Backup-System gestellt

Mehr

Systemvoraussetzungen

Systemvoraussetzungen ID Information und Dokumentation im Gesundheitswesen GmbH & Co. KGaA Platz vor dem Neuen Tor 2 10115 Berlin Systemvoraussetzungen ID DIACOS ID EFIX ID QS Bögen ID DIACOS PHARMA August 2015 Inhaltsverzeichnis

Mehr

Noon2Noon Protecting Big Data

Noon2Noon Protecting Big Data Noon2Noon Protecting Big Data Dr. Jürgen Arnold Empalis Consulting GmbH Nürnberg, 25.11.2014 Protecting Big Data using Node Replication 2 Agenda Einführung Aufgabenstellung Herangehensweise Stand Zusammenfassung

Mehr

XEN-basiertes Cluster mit iscsi-san

XEN-basiertes Cluster mit iscsi-san XEN-basiertes Cluster mit iscsi-san UNIX Stammtisch Sachsen 28.10.2008 thomas.gross@teegee.de Cluster? hier: kein Cluster für paralleles Rechnen! mindestens 2 Clusterserver ein gemeinsamer Speicher (SAN)

Mehr

ISA Server 2004 - Best Practice Analyzer

ISA Server 2004 - Best Practice Analyzer ISA Server 2004 - Best Practice Analyzer Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Seit dem 08.12.2005 steht der Microsoft ISA Server 2004 Best Practice Analyzer

Mehr

Erweiterung einer D-Grid Ressource um eine Compute Cloud Schnittstelle

Erweiterung einer D-Grid Ressource um eine Compute Cloud Schnittstelle am am Erweiterung einer D-Grid Ressource um eine Compute Schnittstelle 3. DFN-Forum 2010 Kommunikationstechnologien Verteilte Systeme im Wissenschaftsbereich Stefan Freitag Institut für Roboterforschung

Mehr

Systemvoraussetzungen Windows Server 2008 Windows Server 2008 R2

Systemvoraussetzungen Windows Server 2008 Windows Server 2008 R2 Systemvoraussetzungen Windows Server 2008 Windows Server 2008 R2 Basis: HiScout 2.5 Datum: 17.06.2015 14:05 Autor(en): HiScout GmbH Version: 1.1 Status: Freigegeben Dieses Dokument beinhaltet 13 Seiten.

Mehr

Calogero Fontana Fachseminar WS09/10. calogero.b.fontana@student.hs-rm.de. Virtualisierung

Calogero Fontana Fachseminar WS09/10. calogero.b.fontana@student.hs-rm.de. Virtualisierung Calogero Fontana Fachseminar WS09/10 calogero.b.fontana@student.hs-rm.de Virtualisierung Was ist Virtualisierung? Definition Virtualisierung ist das zur Verfügung stellen von Hardware-Ressourcen für ein

Mehr

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen Learning Suite Talent Suite Compliance Suite Systemvoraussetzungen Vorwort Dieses Dokument beschreibt, welche Anforderungen an die Installationsumgebung zu stellen sind, um die Plattform unter optimalen

Mehr

Systemvoraussetzungen. Titel

Systemvoraussetzungen. Titel voraussetzungen Titel Installation & Administration Finanzbuchführung Anlagenbuchhaltung Kostenrechnung Personalwirtschaft 1 IMPRESSUM Varial World Edition Beschreibung der voraussetzungen März 2011 Varial

Mehr

Das bwgrid High Performance Compute Cluster als flexible, verteilte Wissenschaftsinfrastruktur

Das bwgrid High Performance Compute Cluster als flexible, verteilte Wissenschaftsinfrastruktur Das bwgrid High Performance Compute Cluster als flexible, verteilte Wissenschaftsinfrastruktur Marek Dynowski (Universität Freiburg) Michael Janczyk (Universität Freiburg) Janne Schulz (Universität Freiburg)

Mehr

Preis- und Leistungsverzeichnis der Host Europe GmbH. Virtual Backup V 1.0. Stand: 01.01.2013

Preis- und Leistungsverzeichnis der Host Europe GmbH. Virtual Backup V 1.0. Stand: 01.01.2013 Preis- und Leistungsverzeichnis der Host Europe GmbH Virtual Backup V 1.0 Stand: 01.01.2013 INHALTSVERZEICHNIS PREIS- UND LEISTUNGSVERZEICHNIS VIRTUAL BACKUP... 3 Produktbeschreibung Virtual Backup...

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 9.5, Asura Pro 9.5, Garda 5.0...2 PlugBALANCEin 6.5, PlugCROPin 6.5, PlugFITin 6.5, PlugRECOMPOSEin 6.5, PlugSPOTin 6.5,...2 PlugTEXTin 6.5, PlugINKSAVEin 6.5, PlugWEBin

Mehr

Systemanforderungen. Finanzbuchführung. Anlagenbuchführung. Kostenrechnung. Personalwirtschaft

Systemanforderungen. Finanzbuchführung. Anlagenbuchführung. Kostenrechnung. Personalwirtschaft anforderungen Finanzbuchführung Anlagenbuchführung Kostenrechnung Personalwirtschaft IMPRESSUM Varial World Edition Beschreibung der voraussetzungen Februar 2008 by Varial Software AG Hauptstraße 18 57074

Mehr

Servervirtualisierung mit VMware

Servervirtualisierung mit VMware Servervirtualisierung mit VMware Die Ziele Serverkonsolidierung durch Virtualisierung Reduzierung der Komplexität Verfügbarkeit verbessern Den Serveradmins das Leben leichter machen Server- und Infrastruktur-

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 10.2, Asura Pro 10.2,Garda 10.2...2 PlugBALANCEin 10.2, PlugCROPin 10.2, PlugFITin 10.2, PlugRECOMPOSEin 10.2, PlugSPOTin 10.2,...2 PlugTEXTin 10.2, PlugINKSAVEin 10.2,

Mehr

VMware. Rainer Sennwitz.

VMware. Rainer Sennwitz. <Rainer.Sennwitz@andariel.informatik.uni-erlangen.de> VMware Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer Sennwitz VMware Inhalt Inhalt

Mehr

Virtuelle Tape Libraries, Überblick und Merkmale. Martin Mrugalla martin.mrugalla@empalis.com

Virtuelle Tape Libraries, Überblick und Merkmale. Martin Mrugalla martin.mrugalla@empalis.com Virtuelle Tape Libraries, Überblick und Merkmale Martin Mrugalla martin.mrugalla@empalis.com Inhalt Was ist eine Virtuelle Tape Library (VTL)? Mögliche Gründe für eine VTL im TSM Umfeld Klärung der Begriffe

Mehr

Einblick in die VMware Infrastruktur

Einblick in die VMware Infrastruktur Einblick in die VMware Infrastruktur Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer

Mehr

OpenStack bei der SAP SE

OpenStack bei der SAP SE OpenStack bei der SAP SE Integration bestehender Dienste in OpenStack dank Workflow Engine und angepasstem Webinterface 23. Juni 2015 Christian Wolter Linux Consultant B1 Systems GmbH wolter@b1-systems.de

Mehr

SPARC LDom Performance optimieren

SPARC LDom Performance optimieren SPARC LDom Performance optimieren Marcel Hofstetter hofstetter@jomasoft.ch http://www.jomasoftmarcel.blogspot.ch Mitgründer, Geschäftsführer, Enterprise Consultant JomaSoft GmbH 1 Inhalt Wer ist JomaSoft?

Mehr

Installation Guide. Installation Guide. Installationsanleitung für die anaptecs JEAF Plattform. Version 1.2 Letzte Änderung 05.

Installation Guide. Installation Guide. Installationsanleitung für die anaptecs JEAF Plattform. Version 1.2 Letzte Änderung 05. Installation Guide Thema Version 1.2 Letzte Änderung 05. Dezember 2011 Status Installationsanleitung für die anaptecs JEAF Plattform Freigegeben Inhaltsverzeichnis 1 Motivation... 4 1.1 Abgrenzungen...

Mehr

PERFORMANCE TESTS AVALON ODS-SERVER 28.11.12 DR. REINHARD HALLERMAYER, BMW GROUP

PERFORMANCE TESTS AVALON ODS-SERVER 28.11.12 DR. REINHARD HALLERMAYER, BMW GROUP PERFORMANCE TESTS AVALON ODS-SERVER 28.11.12 DR. REINHARD HALLERMAYER, BMW GROUP Freude am Fahren Inhalt. Ziele Testumgebung und Testwerkzeug Tests und Testergebnisse Ausblick Beteiligte: Fa. Science +

Mehr

PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD

PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD Inhaltsverzeichnis 1. ZUSAMMENSTELLUNG VON SERVERN...3 1.1. ANFORDERUNGSPROFIL...3 1.2. 1.3. SERVER MODELLE...3 TECHNISCHE

Mehr

Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de

Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften Agenda Einleitung Vor- und Nachteile der Virtualisierung Virtualisierungssoftware

Mehr

Hyper-V Grundlagen der Virtualisierung

Hyper-V Grundlagen der Virtualisierung Grundlagen der Virtualisierung Was ist Virtualisierung? Eine Software-Technik, die mehrere Betriebssysteme gleichzeitig auf dem Rechner unabhängig voneinander betreibt. Eine Software-Technik, die Software

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 9.6, Asura Pro 9.6, Garda 5.6...2 PlugBALANCEin 6.6, PlugCROPin 6.6, PlugFITin 6.6, PlugRECOMPOSEin 6.6, PlugSPOTin 6.6,...2 PlugTEXTin 6.6, PlugINKSAVEin 6.6, PlugWEBin

Mehr

Installationsvoraussetzungen

Installationsvoraussetzungen Installationsvoraussetzungen Betriebssysteme Der Cordaware bestinformed Infoserver kann auf folgenden Microsoft Betriebssystemen installiert werden: Windows 2000 Windows XP Windows Vista Windows 7 Windows

Mehr

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG Oracle Database 11g Standard Edition One Die passende Datenbank-Lösung

Mehr

XEN- The Debian way of life

XEN- The Debian way of life XEN- The Debian way of life Gruppe 5 Mayer und Pikart Inhaltsverzeichnis 1 Was ist XEN?...2 2 Paketinstalltion...3 3 Runlevel anpassen...4 4 Xen Installation anpassen...4 4.1 /etc/xen/xend-config.sxp...4

Mehr

VirtualBox und OSL Storage Cluster

VirtualBox und OSL Storage Cluster VirtualBox und OSL Storage Cluster A Cluster in a Box A Box in a Cluster Christian Schmidt Systemingenieur VirtualBox und OSL Storage Cluster VirtualBox x86 und AMD/Intel64 Virtualisierung Frei verfügbar

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Peter Stalder DOAG November 2009 Basel Baden Bern Lausanne Zurich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg Munich Stuttgart Vienna

Mehr

Mindestanforderungen an Systemumgebung Für die Nutzung von excellenttango

Mindestanforderungen an Systemumgebung Für die Nutzung von excellenttango Die Hardware- und Softwareanforderungen sind als allgemeine Anforderungen zu betrachten. Zahlreiche Faktoren können sich auf diese Anforderungen auswirken und müssen daher beachtet werden: Die Anzahl und

Mehr

herzlich vsankameleon Anwendungsbeispiel Titelmasterformat durch Klicken bearbeiten willkommen Titelmasterformat durch Klicken bearbeiten

herzlich vsankameleon Anwendungsbeispiel Titelmasterformat durch Klicken bearbeiten willkommen Titelmasterformat durch Klicken bearbeiten herzlich willkommen vsankameleon Anwendungsbeispiel Powered by DataCore & Steffen Informatik vsan? Kameleon? vsan(virtuelles Storage Area Network) Knoten Konzept Titelmasterformat Alle HDD s über alle

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Betrieb eines heterogenen Clusters

Betrieb eines heterogenen Clusters Betrieb eines heterogenen Clusters Georg Hager Regionales Rechenzentrum Erlangen (RRZE) ZKI AK Supercomputing Karlsruhe, 22./23.09.2005 Transtec GBit/IB-Cluster am RRZE IA32-Cluster 04/2003 86+2 Knoten

Mehr

lobodms.com lobo-dms Systemvoraussetzungen

lobodms.com lobo-dms Systemvoraussetzungen lobodms.com lobo-dms Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Betriebssystem... 3 1.2 Windows Domäne... 3 1.3 Dateisystem... 3 2 Server... 3 2.1 Hardware... 4 2.2 Betriebssystem... 4 2.3 Software... 4

Mehr

Hochleistungs-Disk-I/O

Hochleistungs-Disk-I/O Hochleistungs-Disk-I/O mit Lustre, dcache und AFS eine vergleichende Betrachtung Stephan Wiesand DESY DV 33. Treffen des ZKI AK Supercomputing Hamburg, 2010-03-04 Computing am DESY Standort Zeuthen Batch

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Einführung in Bacula - Teil 2 und Aufbau eines Testsystems

Einführung in Bacula - Teil 2 und Aufbau eines Testsystems Einführung in Bacula - Teil 2 und Aufbau eines Testsystems vorgestellt am 10.09.2010 in Pforzheim Daniel Bäurer inovex GmbH Systems Engineer Linux Was ich mit Ihnen besprechen möchte Einführung in Bacula

Mehr

Parallels Transporter Read Me ---------------------------------------------------------------------------------------------------------------------

Parallels Transporter Read Me --------------------------------------------------------------------------------------------------------------------- Parallels Transporter Read Me INHALTSVERZEICHNIS: 1. Über Parallels Transporter 2. Systemanforderungen 3. Parallels Transporter installieren 4. Parallels Transporter entfernen 5. Copyright-Vermerk 6. Kontakt

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

VCM Solution Software

VCM Solution Software VCM Solution Software Die BORUFA VCM Solution ist ein umfangreiches Werkzeug für virtuelles Content Management basierend auf hochauflösenden vollsphärischen Bildern, 360 Videos und Punktwolken. In der

Mehr

Systemvoraussetzungen für Autodesk Revit 2015 - Produkte (gemäß Angaben von Autodesk)

Systemvoraussetzungen für Autodesk Revit 2015 - Produkte (gemäß Angaben von Autodesk) Systemvoraussetzungen für Autodesk Revit 2015 - Produkte (gemäß Angaben von Autodesk) Mindestanforderung: Einstiegskonfiguration Betriebssystem ¹ Windows 8.1 Enterprise, Pro oder Windows 8.1 CPU-Typ Single-

Mehr

Freiberuflicher IT-Berater Schwerpunkte: Unix, Oracle, Netzwerk. www.jj-it.de. www.jj-it.de. Dipl.-Inform. Joachim Jäckel

Freiberuflicher IT-Berater Schwerpunkte: Unix, Oracle, Netzwerk. www.jj-it.de. www.jj-it.de. Dipl.-Inform. Joachim Jäckel Freiberuflicher Schwerpunkte: Unix, Oracle, Netzwerk 2005 1 Testaufbauten von Oracle 10g RAC auf preiswerter Hardware 2 3 Typisches Cluster System Clients Public Network Node A Node B Cluster Interconnect

Mehr

ORACLE Database Appliance X4-2. Bernd Löschner 20.06.2014

ORACLE Database Appliance X4-2. Bernd Löschner 20.06.2014 ORACLE Database Appliance X4-2 Bernd Löschner 20.06.2014 Einfach Zuverlässig Bezahlbar Technische Übersicht Oracle Database Appliance 2 Hardware To Kill... Costs! Einfach. 3 Hardware To Kill... Costs!

Mehr

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel Aufgabe 1 (5 Punkte) (Multiple Choice) Beantworten Sie folgende Fragen durch Ankreuzen der richtigen Antwort. Für jede falsche Antwort wird ein Punkt abgezogen (es werden minimal 0 Punkte vergeben). Welche

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge

D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge Arbeitspaket/Task: AP 2 Task 2.2 Fälligkeit: M12 Abgabetermin: 30.04.10 Verantwortlich: Versionsnummer/Status: Autoren: ZIH Koudela,

Mehr

Exklusive Preisliste für Nur für Sie!! Ihr exone Systemhauspartner Friedrich Ritschel GmbH & Co. KG Herr Jacobsen 05221-93760 edv@ritschelkg.

Exklusive Preisliste für Nur für Sie!! Ihr exone Systemhauspartner Friedrich Ritschel GmbH & Co. KG Herr Jacobsen 05221-93760 edv@ritschelkg. Exklusive liste für Nur für Sie!! Herr Jacobsen 0522193760 edv@ritschelkg.com exone Challenge 1111 Atom 330 exone Challenge 1211 X3430 RAID exone Challenge 1911 W3520 exone Challenge 1911 X3430 exone Challenge

Mehr

UEBERSICHT ABACUS DIENSTE

UEBERSICHT ABACUS DIENSTE UEBERSICHT ABACUS DIENSTE Maerz 2006 / EMO v.2006 Diese Unterlagen sind urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdrucks und der Vervielfältigung der Unterlagen, oder Teilen

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Virtualisierung Linux-Kurs der Unix-AG

Virtualisierung Linux-Kurs der Unix-AG Virtualisierung Linux-Kurs der Unix-AG Zinching Dang 12. August 2015 Einführung Virtualisierung: Aufteilung physikalischer Ressourcen in mehrere virtuelle Beispiel: CPUs, Festplatten, RAM, Netzwerkkarten

Mehr

CHiC Chemnitzer Hochleistungs-Linux Cluster. Stand HPC Cluster CHiC. Frank Mietke, Torsten Mehlan, Torsten Höfler und Wolfgang Rehm

CHiC Chemnitzer Hochleistungs-Linux Cluster. Stand HPC Cluster CHiC. Frank Mietke, Torsten Mehlan, Torsten Höfler und Wolfgang Rehm CHiC er Hochleistungs-Linux Cluster Stand HPC Cluster CHiC, Torsten Mehlan, Torsten Höfler und Wolfgang Rehm Fakultätsrechen- und Informationszentrum (FRIZ) / Professur Rechnerarchitektur Technische Universität

Mehr

Diskless Cluster und Lustre Erfahrungsbericht zum CHiC

Diskless Cluster und Lustre Erfahrungsbericht zum CHiC Diskless Cluster und Lustre Erfahrungsbericht zum CHiC, Torsten Hoefler, Torsten Mehlan und Wolfgang Rehm Fakultätsrechen- und Informationszentrum (FRIZ) / Professur Rechnerarchitektur Technische Universität

Mehr

Installation SQL- Server 2012 Single Node

Installation SQL- Server 2012 Single Node Installation SQL- Server 2012 Single Node Dies ist eine Installationsanleitung für den neuen SQL Server 2012. Es beschreibt eine Single Node Installation auf einem virtuellen Windows Server 2008 R2 mit

Mehr

onboard, optimale Darstellung bei: 1.024 x 768, 32 Bit, bei 75 Hz Veröffentlichte Anwendung / Veröffentlichter Desktop ausgestattet mit min.

onboard, optimale Darstellung bei: 1.024 x 768, 32 Bit, bei 75 Hz Veröffentlichte Anwendung / Veröffentlichter Desktop ausgestattet mit min. Terminal Server Anforderungen Betriebssystem: Windows Server 2003 / 2008 / 2008 R2 / 2012 Grafik/ Videospeicher: Netzwerkkarte: Technologien Veröffentlichungs- Methoden: 2-fach Dual Core Prozessoren min.

Mehr

Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen

Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen DATA WAREHOUSE Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen Alfred Schlaucher, Detlef Schroeder DATA WAREHOUSE Themen Big Data Buzz Word oder eine neue Dimension

Mehr

science + computing ag

science + computing ag science + computing ag Evaluation der Integration von Windows HPC in eine bestehende Berechnungsumgebung Harry Schlagenhauf science + computing ag IT-Dienstleistungen und Software für anspruchsvolle Rechnernetze

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

Xenologie oder wie man einen Plastikmainframe baut

Xenologie oder wie man einen Plastikmainframe baut Xenologie oder wie man einen Plastikmainframe baut Alexander Schreiber http://www.thangorodrim.de/ Chemnitzer Linux-Tage 2006 I think there is a world market for maybe five computers.

Mehr

MAXDATA b.drive. Externe Festplatte mit integrierter Backup Software

MAXDATA b.drive. Externe Festplatte mit integrierter Backup Software MAXDATA Computer Produktinformation Highlights USB 3.0 mit bis zu 5GB/s Übertragungsrate Bootfähigkeit Integrierte Backup Software Robustes Aluminium Gehäuse MAXDATA b.drive Einsatzbereiche Systembackup

Mehr

Systemvoraussetzungen sou.matrixx-produkte

Systemvoraussetzungen sou.matrixx-produkte Systemvoraussetzungen sou.matrixx-produkte Vorwort Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und stellen keine Verpflichtung seitens des Verkäufers dar.

Mehr

Systemvoraussetzungen sou.matrixx-produkte

Systemvoraussetzungen sou.matrixx-produkte Systemvoraussetzungen sou.matrixx-produkte Vorwort Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und stellen keine Verpflichtung seitens des Verkäufers dar.

Mehr

Quick Cluster Overview

Quick Cluster Overview Physikalische Fakultät der Universtät Heidelberg Projektpraktikum Informatik, SS 06 Aufgabenstellung Problem: von Clusterdaten Vermeidung der schwächen von Ganglia und Lemon Nutzung von Ganglia bzw. Lemon

Mehr

Befindet sich das Rechenzentrum in einem gefährdeten Gebiet (Überflutung, Erdbeben)? >> Nein

Befindet sich das Rechenzentrum in einem gefährdeten Gebiet (Überflutung, Erdbeben)? >> Nein Gültig ab dem 01.03.2015 FACTSHEET HCM CLOUD Sicherheit, technische Daten, SLA, Optionen 1. Sicherheit und Datenschutz Wo befinden sich meine Daten? Zugegeben - der Begriff Cloud kann Unbehagen auslösen;

Mehr

Isilon Solutions + OneFS

Isilon Solutions + OneFS Isilon Solutions + OneFS Anne-Victoria Meyer Universität Hamburg Proseminar»Ein-/Ausgabe Stand der Wissenschaft«, 2013 Anne-Victoria Meyer Isilon Solutions + OneFS 1 / 25 Inhalt 1. Einleitung 2. Hardware

Mehr

Systemanforderungen und unterstützte Software

Systemanforderungen und unterstützte Software Systemanforderungen und unterstützte Software 1. Systemanforderungen für Server und Client Diese Anforderungen gelten für den Betrieb von Sage 200 ERP Extra Version 2013 Die Übersicht beschreibt die für

Mehr