Naturkatastrophen und Business Continuity: Sind Sie vorbereitet?

Posted by Sabrina Sturm Wed, 31 Aug 2011 10:52:00 GMT

Naturkatastrophen, ein Ausfall des Rechenzentrums oder Pandemien – all diese negativen Worte haben in letzter Zeit allzu häufig Schlagzeilen gemacht. Klingt übertrieben, mögen Sie denken. Aber, gerade vergangenes Wochenende traf Hurrikan „Irene“ auf die Ostküste der USA. Entlang der gesamten Küste herrschte Ausnahmezustand, viele Teile wurden weitläufig evakuiert. Für Stunden pausierte in Washington das öffentliche Leben, in New York ist kein Bus und keine Bahn mehr unterwegs; der Flugverkehr wird zeitweise eingestellt. Auch in Deutschland sind heftige Überschwemmung oder Unwetter mittlerweile keine Seltenheit mehr. In einem solchen Fall stellt sich die Frage: „Wie den Geschäftsbetrieb aufrecht erhalten, wenn man nicht in die Firma kommt oder das eigene Büro überschwemmt oder evakuiert ist?“

Viele äußerliche Einflüsse können sich negativ auf Geschäftsprozesse auswirken und somit die Geschäftsaktivitäten gefährden. Dies kann ernstzunehmende Konsequenzen haben, die nur schwer wieder zu beheben sind. Unglücklicherweise ist es für den Menschen jedoch unmöglich, externe Einflüsse wie zum Beispiel Naturkatastrophen zu kontrollieren oder gar vorauszusehen. Um sicherzugehen und für den Ernstfall gerüstet zu sein ist die beste Lösung, sich frühzeitig für jegliche Katastrophen und Ausfälle von Rechenzentren entsprechend zu wappnen.

Hat ein Unternehmen einen Krisenplan für einen solchen Fall, so kann ein Fortführen des laufenden Geschäftsbetriebs auch in Notfallsituationen gewährleistet werden. Die Fähigkeit, remote auf Rechenzentren und abhängige Einrichtungen zugreifen zu können, erlaubt es Unternehmen ihre Technologie-Ressourcen abzusichern und über mehrere Standorte zu verteilen. Darüber hinaus kann auf alle firmeninternen Daten und Programme auch während der Katastrophe von jedem Ort der Welt über einen Internetbrowser zugegriffen werden. Wichtige Emails können so beispielsweise trotzdem bearbeitet, Deadlines eingehalten werden. Dies garantiert Business Kontinuität und mindert das Risiko eines Gesamtausfalls. Zusätzlich sind Unternehmen, die auf remote Zugänge setzen, besser ausgerüstet, wenn es um die Wiederherstellung der vollständigen Unternehmenstätigkeit nach Katastrophen und Notfällen geht.

 

 Fazit:

Der einzige Weg sicherzustellen, dass die Unternehmensdaten geschützt sind, ist der Einsatz einer Remote Access Lösung schon bevor die Katastrophe eintritt. Nur dann können alle Vorteile einer sicheren, reibungslosen, und störungsfreien Geschäftsfortführung erwartet werden.

keine Kommentare |

HOB Lasttest für Windows Remote Desktop Services

Posted by augustke Tue, 02 Aug 2011 07:53:00 GMT

Aufgabenstellung

Als Hersteller von Remote Desktop Lösungen wird HOB immer wieder gefragt, wie viele Anwender denn gleichzeitig auf einem Windows Server arbeiten können. Leider gibt es für diese Fragestellung keine pauschalen Aussagen. Deshalb hat HOB einen Lasttest mit definierter Hardware durchgeführt.

Folgende Fragestellung sollte beantwortet werden:

„Wie viele Anwender können die Remote Desktop Services auf einer definierten Hardwareplattform gleichzeitig verwenden und diese auch noch sinnvoll einsetzen?“

In diesem Test wurde der Schwerpunkt auf das vom Anwender gefühlte Lastverhalten gelegt und weniger auf die Erfassung von Performance-Werten des Betriebssystems. Dies wurde durch paralleles Arbeiten in einer Sitzung und gleichzeitig simulierter Hintergrundlast - mittels einer ansteigenden Anzahl von Testsessions - durchgeführt.

Beschreibung der Testumgebung

Dieser Test sollte gut nachvollziehbar sein und es wurde deshalb auf gängige Hardware und Standardanwendungen wert gelegt.

Remote Desktop Session Host:

Hardware:
HP ProLiant DL 380 G6, 2 x W5590 Prozessoren (3,33 GHz) mit 8 Cores (und Hyperthreading / sind 16 Threads), 96 GB RAM, 2 x 300 GB SAS HD (Mirror) an HP Smart Array P410i (512 MB Cache), 1 GBit/s-Netzwerkkarte

Betriebssystem- und Softwareumgebung:
Windows Server 2008 R2 Enterprise, Microsoft Office 2010 (Word, Excel und PowerPoint werden für diesen Test verwendet), Updates und Hotfixes vom Stand 21.01.2011, kein Virenscanner, keine weiteren Anpassungen (nur default-Werte), kein Pagefile

400 lokale Benutzerkonten, kein Active Directory

Remote Desktop Services Client Simulation:

Hardware:
HP ProLiant DL 380 G6, 2 x W5590 Prozessoren (3,33 GHz) mit 8 Cores (kein Hyperthreading), 96 GB RAM, 8 x 300 GB SAS HD (Raid 1+0), 1 GBit/s-Netzwerkkarte

Verwendete Client-Software:
 HOBLink JWT 3.3.0579:

Szenario 1:
Displaysize 1024 x 768, Farbtiefe 15 bit, Kompression ein, Audio aus

Szenario 2:
Displaysize 1280 x 1024, Farbtiefe 32 bit, Kompression ein, Audio aus

 

Durchführung der Testsessions

Durch ein Batchfile wurden jeweils 25 User-Sitzungen im 5 Sekunden-Abstand angemeldet. Die User wurden neu angemeldet und es wurde kein Reconnect zu bestehenden Sitzungen durchgeführt. Die Benutzerprofile waren alle bereits vorhanden, d. h. es gab keine Auswirkungen durch das erstmalige Anlegen des Benutzerprofiles aus dem Default-Profil.

Für die Lasterzeugung auf dem Server wurde ein Makro generiert. Folgende Software wurde dafür verwendet:

MacroMaker 3.0.0.6 (http://members.ij.net/anthonymathews/MacroMaker.htm)

Diese Software wurde ausgewählt, weil sie im Ablauf eine sehr kleine CPU- und RAM-Last auf dem Host-Rechner verursacht. Da der Prozess in jeder User-Sitzung ausgeführt wird, kann sich schon eine spürbare zusätzliche Belastung ergeben und dadurch das Ergebnis beeinflussen.

Alle Makro-Aktivitäten wurden ausschließlich über die Tastatur ausgeführt. Auf die Steuerung durch die Maus wurde verzichtet, weil es zu viele Abhängigkeiten von der korrekten Position der verschiedenen Menüs, Schaltflächen usw. gibt. Außerdem wäre es mit einer Maussteuerung nicht möglich auf eine wechselnde Bildschirmauflösung der Clients zu reagieren.

Das Makro ruft als erstes Word auf und gibt Text ein. Dieser wird über einen HP PCL-Druckertreiber auf Gerät „:nul“ gedruckt. Danach wird Excel gestartet und einfache Berechnungen ausgeführt – eine mehrfache Multiplikation von Zufallszahlen. Die Ergebnisse werden in zwei Diagramme übergeben und gedruckt (wie oben). Anschließend wird eine PowerPoint-Datei als Präsentation abgespielt, ein Notepad noch kurz  geöffnet, Text eingegeben und geschlossen.

Dieses Makro wurde in einer Schleife mit kurzen Pausen 100-mal ausgeführt. Weil es keine langen Pausen im Makroablauf gibt und z. B. auch Druckausgaben simuliert werden, kann man durchaus von einem Heavy Load Profil sprechen, das wird in einschlägigen Berichten/Reports auch gerne als Power-User benannt.

 

Testergebnisse


Ergebnisse für das Szenario 1: Displaysize 1024 x 768, Farbtiefe 15 bit

Anzahl User

Commited Memory in GB

Ø CPU-Last in %

Gefühltes Lastverhalten

1 (Admin) Idle

4

~ 0

 

25

9

~ 5

 

50

14

~ 10

 

75

19

~ 15

 

100

24

~ 20

 

125

30

~ 30

 

150

35

~ 35

 

175

41

~ 40

 

200

47

~ 45

 

225

53

~ 50

 

250

60

~ 65

Gelegentliche kleine Ruckler

275

66

~ 75

 

300

74

~ 90

Erkennbare Verzögerungen

325

81

~ 95

Programmstart dauert deutlich länger, schreiben (Word) geht noch gut

350

88

~ 100

 

375

95

~ 100

Keine weitere Verbindungen möglich

 

Szenario 2: Displaysize 1280 x 1024, Farbtiefe 32 bit, Kompression ein, Audio aus

Anzahl User

Commited Memory in GB

Ø CPU-Last in %

Gefühltes Lastverhalten

1 (Admin) Idle

4

~ 0

 

25

9

~ 10

 

50

14

~ 15

 

75

21

~ 20

 

100

27

~ 25

 

125

33

~ 35

 

150

40

~ 45

 

175

46

~ 50

 

200

51

~ 55

Erkennbare Verzögerungen

225

59

~ 70

 

250

66

~ 80

 

275

72

~ 90

Programmstart dauert deutlich länger, schreiben (Word) geht noch gut

300

79

~ 100

Explorer starten dauert 5 sec

325

89

~ 100

Träge Reaktion

350

95

~ 100

Keine weiteren Sessions möglich

 

Fazit

Im ersten Szenario konnten bis zu 250 Sitzungen gleichzeitig ohne Beeinträchtigungen aufgebaut werden. Ab 250 Sitzungen waren erste Verzögerungen und Ruckler zu beobachten. Das Arbeiten in einer bestehenden Sitzung ging trotzdem ohne störende Begleiterscheinungen. Ab 300 Sitzungen gab es störende Verzögerungen und mit 325 Sitzungen dauerte der Programmstart schon merklich länger, ein Arbeiten war aber noch möglich.

Mit der höheren Auflösung für die Clients im zweiten Szenario konnten bis zu 200 Sitzungen ohne Probleme betrieben werden. Danach gab es am Anfang leichtere und dann ansteigend immer mehr Beeinträchtigungen des subjektiven Arbeitsablaufs. Ab 275 Sitzungen wird dann das Arbeiten schon deutlich merkbar beeinträchtigt und ab 300 Sitzungen waren Verzögerungen für den Anwender sehr deutlich spürbar.

Dieser Test zeigt auch auf, dass mit der 64bit-Technologie wesentlich mehr User auf einem Windows Server arbeiten können, als mit den bisherigen 32bit Betriebssystemen, wenn auch hier die Vergleichswerte fehlen. Vor allem durch die Möglichkeit wesentlich mehr Arbeitsspeicher zu verwenden. Pauschale Aussagen die lauten, dass nur ca. 30-50 gleichzeitige Nutzer auf einem Windows Remote Desktop Sessionhost arbeiten können, kommen wohl aus der Zeit der 32bit-Windows-Betriebssysteme und gehören der Vergangenheit an.

Hans Herrgott / Kai-Uwe Augustin

keine Kommentare |


emplates.arcsin.se/'), link_to("Frédéric de Villamil", 'http://fredericdevillamil.com')) %>
Powered by typo