14
Konzeption Terminalserver
Guten Morgen,
ich arbeite in einer kleinen "Abteilung" eines großen Unternehmens. Grundsätzlich gibt es ein Firmennetz, in dem alles sauber gepflegt, gewartet und administriert wird.
Meine Abteilung hat, auf Grund ihrer Aufgaben, ein eigenes Schmuddelnetz. Die Grundkonzeption war, dass eben die (damals) vier Leute, ihre Daten nicht mehrfach vorhalten und per HD austauschen müssen, dass diese die Erlaubnis haben, ihre Geräte zu vernetzen. Hardware für den Netzaufbau (Switche, Kabel, Dosen) wurde geliefert; aber ansonsten geht das Netz die eigentliche IT-Abteilung nichts an. Wir bekommen (meist) was wir brauchen; sofern wir es begründen können, aber ansonsten ist das Netz uns überlassen.
Aus der Abteilung mit vier Leuten wurden sieben Leute. Aus vier Workstations wurden acht Workstations, eine Fileserver, ein AD-Server plus Backup-Server, ein HyperV-Serverchen für WDS und WSUS.
Und da die Abteilung Vorarbeiten für 50 andere Personen leistet, kamen noch 50 Desktop-PCs dazu, die jetzt in unserem "Nicht-mehr-ganz-so-schmuddelig-Netz" hängen.
Unser Hauptarbeitsprogramm gibt es in einer Version für Aufbereiter und für Endanwender.
Bisher bereiten wir die Arbeit auf den Workstations auf, und kopieren das ganze dann über Netz auf die Desktop der Endanwender.
Problem gibt es, wenn wieder etwas aufbereitet werden muss, denn damit der gleiche Bearbeitungsstand erhalten bleibt, heißt es zurückkopieren, aufbereiten und wieder ausbringen.
Bei unseren Außendienstterminen trafen wir immer mehr auf Terminalserverlösungen bei der Kundschaft und überlegten wie wir dies nutzen können.
Erste Tests haben ergeben, dass unsere Programm Multi-User-fähig sind, und sowohl Aufbereiter als auch Endanwender gleichzeitig arbeiten können.
Das Installieren der Terminalserverrolle war kein Problem, ebenso RDP-CALs, etc. haben wir bekommen. Nur ist unser Testgerät zu klein.
RAM und Festplattenspeicher gibt uns die Software bzw. der Arbeitsumfang vor. Jetzt kamen Fragen auf wie:
Wie ermittle ich, wie viele Kerne mein Blech eigentlich braucht?
Wie lege ich bei der Remotedesktopbereitstellungen einen Standarddesktop für alle Nutzer an?
Wie verhindere ich, dass ein Standardnutzer "aus Versehen" den Server herunterfährt?
ich arbeite in einer kleinen "Abteilung" eines großen Unternehmens. Grundsätzlich gibt es ein Firmennetz, in dem alles sauber gepflegt, gewartet und administriert wird.
Meine Abteilung hat, auf Grund ihrer Aufgaben, ein eigenes Schmuddelnetz. Die Grundkonzeption war, dass eben die (damals) vier Leute, ihre Daten nicht mehrfach vorhalten und per HD austauschen müssen, dass diese die Erlaubnis haben, ihre Geräte zu vernetzen. Hardware für den Netzaufbau (Switche, Kabel, Dosen) wurde geliefert; aber ansonsten geht das Netz die eigentliche IT-Abteilung nichts an. Wir bekommen (meist) was wir brauchen; sofern wir es begründen können, aber ansonsten ist das Netz uns überlassen.
Aus der Abteilung mit vier Leuten wurden sieben Leute. Aus vier Workstations wurden acht Workstations, eine Fileserver, ein AD-Server plus Backup-Server, ein HyperV-Serverchen für WDS und WSUS.
Und da die Abteilung Vorarbeiten für 50 andere Personen leistet, kamen noch 50 Desktop-PCs dazu, die jetzt in unserem "Nicht-mehr-ganz-so-schmuddelig-Netz" hängen.
Unser Hauptarbeitsprogramm gibt es in einer Version für Aufbereiter und für Endanwender.
Bisher bereiten wir die Arbeit auf den Workstations auf, und kopieren das ganze dann über Netz auf die Desktop der Endanwender.
Problem gibt es, wenn wieder etwas aufbereitet werden muss, denn damit der gleiche Bearbeitungsstand erhalten bleibt, heißt es zurückkopieren, aufbereiten und wieder ausbringen.
Bei unseren Außendienstterminen trafen wir immer mehr auf Terminalserverlösungen bei der Kundschaft und überlegten wie wir dies nutzen können.
Erste Tests haben ergeben, dass unsere Programm Multi-User-fähig sind, und sowohl Aufbereiter als auch Endanwender gleichzeitig arbeiten können.
Das Installieren der Terminalserverrolle war kein Problem, ebenso RDP-CALs, etc. haben wir bekommen. Nur ist unser Testgerät zu klein.
RAM und Festplattenspeicher gibt uns die Software bzw. der Arbeitsumfang vor. Jetzt kamen Fragen auf wie:
Wie ermittle ich, wie viele Kerne mein Blech eigentlich braucht?
Wie lege ich bei der Remotedesktopbereitstellungen einen Standarddesktop für alle Nutzer an?
Wie verhindere ich, dass ein Standardnutzer "aus Versehen" den Server herunterfährt?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 511148
Url: https://administrator.de/contentid/511148
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
14 Kommentare
Neuester Kommentar
die benötigte Hardware kann dir nur der Hersteller sagen da du ja nicht mal das Programm verrätst. Und 50x Notepad hat sicher ne andere Anforderung als 50x SAP-Server die parallel laufen ;)
Standard-Benutzer haben keine Berechtigung (normalerweise) um den Server runterzufahren. Lokale Admins sollten das natürlich eh nicht sein da du auch nich willst das die auf nem TS was installieren.
Ich würde jedoch mal mit eurer Internen IT sprechen - die kennen das bei euch ja besser als nen forum und können dir vermutlich auch besser + direkter helfen.
Standard-Benutzer haben keine Berechtigung (normalerweise) um den Server runterzufahren. Lokale Admins sollten das natürlich eh nicht sein da du auch nich willst das die auf nem TS was installieren.
Ich würde jedoch mal mit eurer Internen IT sprechen - die kennen das bei euch ja besser als nen forum und können dir vermutlich auch besser + direkter helfen.
Hi,
zunächst:
Mach Dir Gedanken über die Sicherung und was passiert, wenn der RDS so kaputt oder kaputt konfiguriert ist, dass alle nicht mehr arbeiten können. Wie viel Personen müssen dann wie lange warten, um wieder arbeiten zu können.
Um im Fehlerfall schnell zurück sichern zu können oder einen Ersatzserver aufziehen zu können, schlage ich vor, dass Ihr Euch ein Blech mit doppelt so viel RAM holt (+8GB für den Hyper-V Host) und ihn als reinen Hyper-V Server laufen lässt und den RDS Server als virtuelle Maschine laufen lässt. Das bleibt nur günstig, wenn die Software keine extremen 3D Anforderungen an die Grafik hat. Steck noch ein bisschen mehr RAM rein, dann kannst Du auch einen zweiten AD installieren, zwecks Redundanz. Die Sicherungen der VMs kann dann das kostenlose Veeam Community Edition übernehmen und Du kannst auch am Hyper-V Snapshots anlegen, bevor Du Änderungen machst oder ein Update kommt. Wenn Du dem bereits existierenden Hyper-V Serverchen mehr RAM spendierst, kannst Du die VMs auch auf den anderen Server übertragen, falls ein Server Macken macht, und umgekehrt auch.
zunächst:
Mach Dir Gedanken über die Sicherung und was passiert, wenn der RDS so kaputt oder kaputt konfiguriert ist, dass alle nicht mehr arbeiten können. Wie viel Personen müssen dann wie lange warten, um wieder arbeiten zu können.
RAM und Festplattenspeicher gibt uns die Software bzw. der Arbeitsumfang vor
Pro Benutzer zählst Du nochmal 4GB RAM und 50GB Festplattenspeicher dazu.Um im Fehlerfall schnell zurück sichern zu können oder einen Ersatzserver aufziehen zu können, schlage ich vor, dass Ihr Euch ein Blech mit doppelt so viel RAM holt (+8GB für den Hyper-V Host) und ihn als reinen Hyper-V Server laufen lässt und den RDS Server als virtuelle Maschine laufen lässt. Das bleibt nur günstig, wenn die Software keine extremen 3D Anforderungen an die Grafik hat. Steck noch ein bisschen mehr RAM rein, dann kannst Du auch einen zweiten AD installieren, zwecks Redundanz. Die Sicherungen der VMs kann dann das kostenlose Veeam Community Edition übernehmen und Du kannst auch am Hyper-V Snapshots anlegen, bevor Du Änderungen machst oder ein Update kommt. Wenn Du dem bereits existierenden Hyper-V Serverchen mehr RAM spendierst, kannst Du die VMs auch auf den anderen Server übertragen, falls ein Server Macken macht, und umgekehrt auch.
Wie ermittle ich, wie viele Kerne mein Blech eigentlich braucht?
Da ist immer eine Schätzung. Als Beispiel bei uns: Wenn es reine Office Arbeiten sind, reicht ein 16-Kern Xeon für 20 Benutzer und es besteht die Gefahr, dass er dabei einschläft, weil er überhaupt nicht ausgelastet ist. Wenn mit langen Prozessen gearbeitet wird, bei dem der Rechner über einen gewissen Zeitraum die gesamte CPU Last beansprucht, würde ich auf einen Dual-Xeon gehen, damit die anderen Benutzer auf dem Server nicht gestört werden.Wie lege ich bei der Remotedesktopbereitstellungen einen Standarddesktop für alle Nutzer an?
Die Desktops sind für jeden Benutzer getrennt. Jeder Benutzer hat ein eigenes Profil, wie bei getrennten PCs. Leg also keine Daten oder Programme auf den Desktop, sondern Links zu einem gemeinsamen Dateibereich / Ordneroder ausführbarem Programm. Änderungen an denen sehen dann alle. Links, die Du als Administrator anlegst, sehen alle Benutzer. Links, die ein Benutzer anlegt, sieht nur er selbst.
Moin,
Wenn ihr tarsächlich Teil eines großen Unternehmens seid, solltet Ihr Euch Hilfe bei der internen IT holen. Fie werden sich mit sowas auskennen.
lks
Wenn ihr tarsächlich Teil eines großen Unternehmens seid, solltet Ihr Euch Hilfe bei der internen IT holen. Fie werden sich mit sowas auskennen.
lks
Moin,
Denke daran, dass pro User auch RAM für die virtuelle Umgebung verbraucht wird. RAM kann man nie genug haben.
Guck Dir an, was an CPU-Last bei wievielen Kernen auf den bestehenden Clients verursacht wird (Langzeitbeobachtung z. B. mit der Leistungsüberwachung) und multipliziere das Ergebnis mit 50. Dann hast Du eine grobe Schätzung. Dabei musst Du die Anzeige genau beachten, ob die Last pro Kern oder die Gesamtlast aller Kerne ausgewertet wird.
Willst Du ein verbindliches Profil? Dann lautet das Stichwort zum Googeln "mandatory profile". Willst Du ein voreingestelltes Profil, dann "default profile". Beides kannst Du per GPO für den TS separat definieren. Hier lautet das Stichwort "remote desktop profile".
Das musst Du nicht. Kein Standarduser kann das weder "aus Versehen" noch mit Absicht. Selbst Admins müssen sich da ein wenig Mühe geben, um den Server wirklich herunterzufahren. Das hat MS ganz ordentlich gemacht, um ein versehentliches Herunterfahren zu vermeiden. Da das Ganze nach neuer Hardware klingt, würde ich Dir empfehlen, eine Serverhardware zu kaufen, die sowas wie die ILO (HP-Server) bietet, damit Du nicht, wenn das Ding mal abschmiert oder doch statt eines Neustarts das Herunterfahren gewählt wurde, immer in den Keller rennen musst.
hth
Erik
Zitat von @Meandor:
RAM und Festplattenspeicher gibt uns die Software bzw. der Arbeitsumfang vor. Jetzt kamen Fragen auf wie:
RAM und Festplattenspeicher gibt uns die Software bzw. der Arbeitsumfang vor. Jetzt kamen Fragen auf wie:
Denke daran, dass pro User auch RAM für die virtuelle Umgebung verbraucht wird. RAM kann man nie genug haben.
Wie ermittle ich, wie viele Kerne mein Blech eigentlich braucht?
Guck Dir an, was an CPU-Last bei wievielen Kernen auf den bestehenden Clients verursacht wird (Langzeitbeobachtung z. B. mit der Leistungsüberwachung) und multipliziere das Ergebnis mit 50. Dann hast Du eine grobe Schätzung. Dabei musst Du die Anzeige genau beachten, ob die Last pro Kern oder die Gesamtlast aller Kerne ausgewertet wird.
Wie lege ich bei der Remotedesktopbereitstellungen einen Standarddesktop für alle Nutzer an?
Willst Du ein verbindliches Profil? Dann lautet das Stichwort zum Googeln "mandatory profile". Willst Du ein voreingestelltes Profil, dann "default profile". Beides kannst Du per GPO für den TS separat definieren. Hier lautet das Stichwort "remote desktop profile".
Wie verhindere ich, dass ein Standardnutzer "aus Versehen" den Server herunterfährt?
Das musst Du nicht. Kein Standarduser kann das weder "aus Versehen" noch mit Absicht. Selbst Admins müssen sich da ein wenig Mühe geben, um den Server wirklich herunterzufahren. Das hat MS ganz ordentlich gemacht, um ein versehentliches Herunterfahren zu vermeiden. Da das Ganze nach neuer Hardware klingt, würde ich Dir empfehlen, eine Serverhardware zu kaufen, die sowas wie die ILO (HP-Server) bietet, damit Du nicht, wenn das Ding mal abschmiert oder doch statt eines Neustarts das Herunterfahren gewählt wurde, immer in den Keller rennen musst.
hth
Erik
Moin,
Die Beschreibung klingt so, als wollten sie die IT aus der Abteilung weiterhin raushalten.
Liebe Grüße
Erik
Zitat von @Lochkartenstanzer:
Wenn ihr tarsächlich Teil eines großen Unternehmens seid, solltet Ihr Euch Hilfe bei der internen IT holen. Fie werden sich mit sowas auskennen.
Wenn ihr tarsächlich Teil eines großen Unternehmens seid, solltet Ihr Euch Hilfe bei der internen IT holen. Fie werden sich mit sowas auskennen.
Die Beschreibung klingt so, als wollten sie die IT aus der Abteilung weiterhin raushalten.
Liebe Grüße
Erik
Zitat von @erikro:
Moin,
Die Beschreibung klingt so, als wollten sie die IT aus der Abteilung weiterhin raushalten.
Moin,
Zitat von @Lochkartenstanzer:
Wenn ihr tarsächlich Teil eines großen Unternehmens seid, solltet Ihr Euch Hilfe bei der internen IT holen. Fie werden sich mit sowas auskennen.
Wenn ihr tarsächlich Teil eines großen Unternehmens seid, solltet Ihr Euch Hilfe bei der internen IT holen. Fie werden sich mit sowas auskennen.
Die Beschreibung klingt so, als wollten sie die IT aus der Abteilung weiterhin raushalten.
Die kann ja ja immer noch außen vor bleiben. Aber normalerweise sollten doch die Kollegen zumindest Tipps geben können, wie man den Server dimensioniert.
In meiner Zeit als Angestellter bei einem Carrier/ISP hatte unsere Abteilung auch Ihre eigene autonome Infrastruktur, konnten uns aber mit der "IT" durchaus austauschen.
lks
Ein bisschen was von beidem.
Wir wollen nicht, dass unser Netz voll den Konventionen der Gesamt-IT unterliegt, da wir dann unsere Arbeit nur unter erschwerten Bedingungen erledigen können.
Die IT würde eine weitere Betreuung unseres Netzes übernehmen, aber nur, wenn es den Konventionen angepasst wird.
Der Status Quo ist; sie versorgen uns, mit alles was wir begründet brauchen, aber wir müssen es selbst hinbekommen.
Wir wollen nicht, dass unser Netz voll den Konventionen der Gesamt-IT unterliegt, da wir dann unsere Arbeit nur unter erschwerten Bedingungen erledigen können.
Die IT würde eine weitere Betreuung unseres Netzes übernehmen, aber nur, wenn es den Konventionen angepasst wird.
Der Status Quo ist; sie versorgen uns, mit alles was wir begründet brauchen, aber wir müssen es selbst hinbekommen.
Zitat von @Meandor:
Der Status Quo ist; sie versorgen uns, mit alles was wir begründet brauchen, aber wir müssen es selbst hinbekommen.
Der Status Quo ist; sie versorgen uns, mit alles was wir begründet brauchen, aber wir müssen es selbst hinbekommen.
Dann sagt Doch ihr braucht einen TS für 50 User für Eure Anwendung. Dann sollten sie Euch doch eine passende Büchse geben können.
lks
Okay, war alles sehr kryptisch.
"Wir" sind die IT-Forensik einer Strafverfolgungsbehörde.
Lauffähig auf dem Terminalserver sollten sieben Instanzen von X-Ways Forensics und im Schnitt 20 Instanzen von X-Ways Investigator sein.
Die Forensic Variante läuft bisher auf Workstations mit 32GB bis 64GB RAM; die Investigator Variante auf Desktops mit 16GB bis 32GB RAM. Speicher wird auf den Workstations im Schnitt 10TB vorgehalten, aber selten ausgenutzt; die Desktops kommen mit 2 TB aus.
Mit der IT unserer Verwaltung wurde abgestimmt, dass wir keine komischen Sachen von Ihnen wollen, und sie dafür unser komisches Netz nicht regulieren. Nicht alle sind mit diesem Konzept glücklich, aber wir müssen damit arbeiten.
Jetzt basteln wir aber gerade an einem Antrag um die "Büchse" zu beschaffen; aber eigentlich wissen wir nicht wirklich was wir genau brauchen.
"Wir" sind die IT-Forensik einer Strafverfolgungsbehörde.
Lauffähig auf dem Terminalserver sollten sieben Instanzen von X-Ways Forensics und im Schnitt 20 Instanzen von X-Ways Investigator sein.
Die Forensic Variante läuft bisher auf Workstations mit 32GB bis 64GB RAM; die Investigator Variante auf Desktops mit 16GB bis 32GB RAM. Speicher wird auf den Workstations im Schnitt 10TB vorgehalten, aber selten ausgenutzt; die Desktops kommen mit 2 TB aus.
Mit der IT unserer Verwaltung wurde abgestimmt, dass wir keine komischen Sachen von Ihnen wollen, und sie dafür unser komisches Netz nicht regulieren. Nicht alle sind mit diesem Konzept glücklich, aber wir müssen damit arbeiten.
Jetzt basteln wir aber gerade an einem Antrag um die "Büchse" zu beschaffen; aber eigentlich wissen wir nicht wirklich was wir genau brauchen.
Moin,
Na dann muss es ja kryptisch sein.
Lauffähig auf dem Terminalserver sollten sieben Instanzen von X-Ways Forensics und im Schnitt 20 Instanzen von X-Ways Investigator sein.
Na der X-Ways Forensics ist ja ein recht schlankes Programm und da der Investigator nur eine Teilmenge von Forensics ist, dürfte der noch schlanker sein. Das läuft doch auch vom Stick auf jeder alten XP-Büchse. Oder irre ich mich da?
So viel RAM? Habt Ihr mal geguckt, ob Ihr das überhaupt braucht? Wie schon gesagt: Ich würde mal ein Tool auf den bestehenden PCs laufen lassen und gucken, wie da die Auslastung ist. Dann noch was draufschlagen für die Verwaltung des TS und dann sollte das passen.
Liebe Grüße
Erik
Zitat von @Meandor:
Okay, war alles sehr kryptisch.
"Wir" sind die IT-Forensik einer Strafverfolgungsbehörde.
Okay, war alles sehr kryptisch.
"Wir" sind die IT-Forensik einer Strafverfolgungsbehörde.
Na dann muss es ja kryptisch sein.
Lauffähig auf dem Terminalserver sollten sieben Instanzen von X-Ways Forensics und im Schnitt 20 Instanzen von X-Ways Investigator sein.
Na der X-Ways Forensics ist ja ein recht schlankes Programm und da der Investigator nur eine Teilmenge von Forensics ist, dürfte der noch schlanker sein. Das läuft doch auch vom Stick auf jeder alten XP-Büchse. Oder irre ich mich da?
Die Forensic Variante läuft bisher auf Workstations mit 32GB bis 64GB RAM; die Investigator Variante auf Desktops mit 16GB bis 32GB RAM. Speicher wird auf den Workstations im Schnitt 10TB vorgehalten, aber selten ausgenutzt; die Desktops kommen mit 2 TB aus.
So viel RAM? Habt Ihr mal geguckt, ob Ihr das überhaupt braucht? Wie schon gesagt: Ich würde mal ein Tool auf den bestehenden PCs laufen lassen und gucken, wie da die Auslastung ist. Dann noch was draufschlagen für die Verwaltung des TS und dann sollte das passen.
Liebe Grüße
Erik
Irgendwie klappt das mit dem zitieren nicht...
XWF ist sehr genügsam, bei Aufbereitung nimmt es aber auch mal die vollen 64 GB.
Auch die XWI Variante ist genügsam. Will der Bearbeiter aber einen Suchlauf starten, sind wir beim Vollausschlag.
Beim RAM würde die Hälfte des unteren Wertes mal 50 bzw. mal 7 reichen.
Ich steig nur bei den Prozessorkernen nicht durch. XWF unterstützt bis 16 Threads und das würde ich auch gerne nutzen können, solange es noch sinnvoll ist.
XWF ist sehr genügsam, bei Aufbereitung nimmt es aber auch mal die vollen 64 GB.
Auch die XWI Variante ist genügsam. Will der Bearbeiter aber einen Suchlauf starten, sind wir beim Vollausschlag.
Beim RAM würde die Hälfte des unteren Wertes mal 50 bzw. mal 7 reichen.
Ich steig nur bei den Prozessorkernen nicht durch. XWF unterstützt bis 16 Threads und das würde ich auch gerne nutzen können, solange es noch sinnvoll ist.
Kann ich mir das so vorstellen das ihr (derzeit) einen Datensatz (X GB) auf einen Client schmeißt, dann das XWF darüber rödeln lasst und das auf bis zu 20 PCs parallel (also 20 Fälle)?
Da bietet sich natürlich viel RAM an und auch viele Kerne. Viele Kerne können aber Lizenztechnisch ein Nachteil werden, daher sollte man vielleicht nicht nur viele Kerne sondern möglichst viele potente Kerne haben (auch kann die Software hier unterschiedlich gut mit umgehen).
Vielleicht ist die Anwendung aber gar nicht so sehr auf parallele Prozesse angewiesen denn ein Server kann die Aufgaben mitunter schneller und dann nach einander statt parallel abarbeiten. Also statt 20 papallele Vorgänge nur 2-4 die dann aber deutlich schneller abgefrühstückt sind. Du wirst nicht drum herum kommen die Vorgänge genau zu beobachten und zu testen wann dein Server am efizientesten arbeitet.
Wenn meine Annahme richtig ist wurde auch noch kein Wort zum Storage verloren, das wäre aber bei größeren Datenmengen enorm relevant.
Da bietet sich natürlich viel RAM an und auch viele Kerne. Viele Kerne können aber Lizenztechnisch ein Nachteil werden, daher sollte man vielleicht nicht nur viele Kerne sondern möglichst viele potente Kerne haben (auch kann die Software hier unterschiedlich gut mit umgehen).
Vielleicht ist die Anwendung aber gar nicht so sehr auf parallele Prozesse angewiesen denn ein Server kann die Aufgaben mitunter schneller und dann nach einander statt parallel abarbeiten. Also statt 20 papallele Vorgänge nur 2-4 die dann aber deutlich schneller abgefrühstückt sind. Du wirst nicht drum herum kommen die Vorgänge genau zu beobachten und zu testen wann dein Server am efizientesten arbeitet.
Wenn meine Annahme richtig ist wurde auch noch kein Wort zum Storage verloren, das wäre aber bei größeren Datenmengen enorm relevant.
Derzeit wird ein Datensatz auf der Workstation des Forensikers aufbereitet. Der Standard-Datensatz hat ca. 1,5 TB; mit Ausreißern nach oben. Wenn die Aufbereitung mit XWF durch ist; wird der aufbereitete Fall auf einen PC kopiert und dieser dem Ermittler zur Verfügung gestellt.
Insgesamt sind derzeit 14 Workstations vorhanden und auch Lizenzen für 14 XWF. Ich kann XWF mit einer Lizenz auf einer Workstation unter dem selben Benutzer mehrfach starten, aber die Leistung nimmt logischerweise ab. Übers Wochenende wird sowas gerne gemacht.
Laut XWF Handbuch kann XWF diverse Aufbereitungsarbeiten auf bis zu 16 Threads (in Abhängigkeit der Prozessorkerne) verteilen; aus der praktischen Erfahrung gebe ich XWF aber im Regelfall nur die Hälfte bis 2/3 der Kerne, sonst hängt es sich auf.
Ein Storage mit ca. 200 TB ist vorhanden, auf welchem die Asservate gesammelt und gesichtet werden. Von dort aus, werden sie dann "gepackt" und im Landesrechenzentrum archiviert.
Insgesamt sind derzeit 14 Workstations vorhanden und auch Lizenzen für 14 XWF. Ich kann XWF mit einer Lizenz auf einer Workstation unter dem selben Benutzer mehrfach starten, aber die Leistung nimmt logischerweise ab. Übers Wochenende wird sowas gerne gemacht.
Laut XWF Handbuch kann XWF diverse Aufbereitungsarbeiten auf bis zu 16 Threads (in Abhängigkeit der Prozessorkerne) verteilen; aus der praktischen Erfahrung gebe ich XWF aber im Regelfall nur die Hälfte bis 2/3 der Kerne, sonst hängt es sich auf.
Ein Storage mit ca. 200 TB ist vorhanden, auf welchem die Asservate gesammelt und gesichtet werden. Von dort aus, werden sie dann "gepackt" und im Landesrechenzentrum archiviert.
Der Trick dabei ist nach dem > ein Leerzeichen zu lassen
