Virtualisierungstechniken -- Erfahrungen und Fragen

[#1]

Guten Abend zusammen !

"Inspiriert" von einem Beitrag von @LS4B mit folgendem Zitat:

Gucken ob das Dongle richtig durchgereicht wird (bei Proxmox gehts total easy - bei VMWare musste man glaub ich etwas manuell nachfummeln => Vergessen, benutze kein VMWare).

... bringt mich das zu einem leidigen Thema:  Wirrtualisierung.

Allgemein:

Ist das überhaupt sinnvoll im DATEV - Umfeld ?

a) 'Fileserver' und WTS

Hört sich für mich recht problematisch an, weil der 'Fileserver' ja in Wirklichkeit Datenbankserver ist.  Fast jede Interaktion auf dem WTS löst, zeitlich quasi-koinzident, eine Serie von Datenbankabfrage aus.  Verteilte Spitzenbelastungen (man kann keine CPU zu "40%" auslasten, sondern entweder gar nicht oder zu 100%) tun nicht weh, aber immer, wenn viele Threads quasi gleichzeitig aktiv sind, sinkt die Performance.

Für einen Datenbanker ist es schon der Horror, wenn Tabellen innerhalb eines "normalen" Dateisystems gespeichert werden.  Erwachsene Datenbanken tun das direkt auf dem Massenspeichermedium, und die Erklärung ist naheliegend und banal:  Wenn die Datenbank auf den Satz #47114711 zugreifen will, dann multipliziert sie die Satznummer mit der Tabellenlänge und hat adhoc den Offset.   Innerhalb eines Dateisystems liegen aber die Daten "gesprenkelt" auf der Platte, also muß man (rechen-)zeitaufwendig traversieren.  Nun ist das so bei MS, die speichern ja auch das 'pagefile.sys' im Dateisystem und pagen auch den Netzwerk-Bufferpool.  Soll schön sein.

Wenn ich aber jetzt den Fileserver auch noch "wirrtualisiere", dann baue ich mir eine "Russiche Puppe" (Uiuiuiuiui, wenn das 'mal durch die Zensur geht ...), sprich, der komplette "Fileserver" liegt als einzelne Datei auf dem Virtualisierungs-Host.  Innerhalb dieser Datei befindet sich ein weiteres Dateisystem, innerhalb dieses Dateisystems befindet sich eine Datei mit den Tabellen.

Also, für mich ist das der Performance - Super-GAU.

b) Mehrere WTS virtualisiert

Viele Anwender hier hosten zwei oder sogar mehrere WTSsen auf einem Server.

Da frage ich mich doch:  Warum?  Denn jedes Bertiebssystem ist doch per se eine Virtualisierungsinstanz!  Warum soll ich beispielsweise 40 Benutzer mit zwei WTS zu je 20 bedienen ?   Warum kann ich nicht eine Instanz nehmen mit der dann doppelten Anzahl Prozessoren und der doppelten Menge an Speicher ?

Hinzu kommt ein simpler Effekt:  Bei nicht-kontinuierlicher, interaktiver Nutzung benötigen wir für Programme auf Großrechnern in etwa die 1,4-fache Leistung, um die Anzahl der aktiven Benutzer verdoppeln zu können.   Kommt hinzu:   Die Unmengen an "DLL"s liegen nur einmal im Hauptspeicher.

Hier würden mich ja die Erkenntnisse des @metalposaunist brennend interessieren.

Es gibt einen denkbaren Erklärungsansatz:  In einem konkreten Fall hatte ein Kunde etwa 200 Benutzer, die allerdings nur sehr sporadisch auf ihr ERP-System zugriffen, auf einem "Terminalserver".  Auch noch mit "VMWare".

Die "VMWare" zeigte kaum CPU-Last an, kaum Netzwerklast, kaum Disk-I/O -- aber es bewegte sich nichts.   Feigerweise aber zeigt "VMWare" nicht an, welche Leistung es selbst vernichtet.   Und da sind wir wieder bei der "Russischen Puppe":   Der "Systemmonitor" des "Terminalservers" zeigte 420.000 geöffnete Filehandles auf einer einzigen virtuellen Platte, die auf dem Host durch eine einzige ranzige "VMhd" (oder so) realisiert war.  Es geht nicht anders:  Bei jedem Zugriff auf eine Datei benötigt man eine Reihe von sog. "Lock"s, damit konkurrierende Prozesse sich nicht gegenseitig die Kontrolltabellen kaputtschreiben.  Unter Linux gab es bis vor noch nicht allzulanger Zeit auch noch einen "BKL", einen "Big Kernel Lock" quasi gratis dazu.   Und das bei 420.000 Handles !  Verschachtelt !

Eigentlich geht das gar nicht.

Problematisch kann auch der "virtuelle Switch" und die "virtuelle Netzwerkkarte" sein, die massig CPU-Leistung auffressen.   Seriöse Virtualisierungsumgebungen zeigen den "Eigenverbrauch" an.

c) Mögliche Wege aus dem Dilemma:

Hier kommt jetzt @LS4B ins Spiel:

benutze kein VMWare

Stattdessen setzt er "Proxmox" ein.  Würde ich ja eher nicht tun, weil ich den Namen sehr albern finde.  Aber ich habe gehört, daß "Proxmox" auf KVM/Qemu basiert, und das ist an und für sich recht ausgereift.  Es bietet gegenüber den "Global Playern" zwei massive Vorteile:

1)

Es kommt mit "Block I/O" klar, d.h., man kann den Gastbetriebssystemen eine "echte" Platte anbieten.   1)a, für Fachleute:  Wenn ein SAN vorhanden, könnte es auch NPIV.

Damit entfallen die durch die "Russische Puppe" sich ergebenen Flaschenhälse und CPU-Zyklusvernichtungen.

2)

Man kann Partitionen "echte" Netzwerkkarten direkt zuordnen, sodaß man weder "virtuelle Switches" noch "virtuelle Netzwerkkarten" benötigt.  Die Prozessoren auf den Karten bewältigen dann den Löwenanteil des IP-Datenverkehrs.

Es kommt noch ein subtiler Aspekt dazu, der des 'Cache Trashings' infolge des Verlustes referentieller Lokalität und infolge von unnötig vielen Taskwechseln.

Das ist aber jetzt schon arg kompliziert, entscheidend ist:  Die Netzwerkkarten können endlich wieder das machen, was sie können und wofür sie gebaut wurden.

Echte Netzwerkkarten kann man auch ordentlich aggregieren (was nützt die schönste 10-Gigabit-Autobahn, wenn sie nur einspurig ist und man hinter einem rumänischen LKW hängt), unter "VMWare" geht das bis heute nicht ordentlich.

3)

Wie ich vor gut einem Jahr mit großer Freude gehört habe, explodieren die Lizenzgebühren für "VMWare" und "Hyper-V" mit der Anzahl der Prozessoren pro Sockel.

Schlimmer als die Inflationsrate !

KVM/QEMU ist kostenfrei.  Kann man bspw. mit DEBIAN sofort herunterladen.

4)

Sowohl mit "VMWare" als auch mit "Hyper-V" habe ich bei Kunden Situationen erlebt, die die jeweiligen Unternehmen massive Schäden größer 35.000,-- verursacht haben.

Beispiel "Hyper-V":  Ein Gast steht mit einmemmal im Status "gespeichert" und läßt sich nicht mehr zum Leben erwecken.  War lustig, da hing ein Trumpf-Bearbeitungszentrum dran, welches sich an der Spitze der Fertigungspyramide befand.  Alle Mitarbeiter wurden dann erstmal nach Hause geschickt ...

Das wäre auch nicht erquicklich für eine Steuerberatungskanzlei.

Zusammenfassend:

"Aus dem Bauch heraus" würde ich zwei Server OHNE Wirrtualisierung betreiben, eine Combo aus "Fileserver", LiMa, Kommunikationsserver und, wenn überhaupt, "DC".

Und dann einen einzigen "WTS".   Als Datenträger NVMe.   Beide Server mit einem aggregierten 10 GBit/s - Link verbunden.  Extra-Netz für die Arbeitsplätze.

Altmodisch, aber einfach.

Meine Frage jedoch:

Würde KVM/QEMU die beschriebenen Probleme lösen können ?

Wirtschaftlich lösen können ?

Vor allen Dingen aber:

Sind meine Schlußfolgerungen richtig oder übersehe ich etwas ?

Einen schönen Abend wünscht

[#2]

... Einfach nur ein paar platte Gedanken dazu...

a) Einfacher ist an sich wirklich Blech-Gegen-Blech ohne Virtualisierung. Wenn gar nichts mehr funktioniert, kann ich jemanden per Telefon in der Kanzlei auch sagen: Drück solange auf den Knopf bis er aus ist und schalt ihn wieder an (den Server). Verstehen alle. Auch von der Bemessung der Hardware. Die DATEV macht nen "Vorschlag" für den Fileserver und den Terminalserver => kann ich direkt so umsetzen. Jemand fremdes kann sich vor den Monitor setzen und "sieht" was reales, nicht nur ne Konsole. Auch nen Vorteil.

b) Performance: Blech-Gegen-Blech wird bestimmt besser sein. Wieviel es heute ausmacht, keine Ahnung. In der Vor-SSD-Zeit hat man es schon gemerkt - heute "fühl" ich keinen Unterschied.

c) Hyper-V mach ich nicht wegen keinen Hyper-V Host auf einem DC => Macht man nicht=> Dann hab ich ja quasi noch eine relativ dicke  Windows-Maschine mehr im Haus als VM-Host, die ich aber nicht will.

d) VMWare => Kosten, sehe keinen Vorteil zu Proxmox den ich für "lau" haben kann. Updates am Proxmox: Ganz ehrlich, schenk ich mir inzwischen. Lass das Teil die 5 Jahre durchlaufen. Ich mach ja auch nicht ständig nen BIOS-Update am Blech... sozusagen.

e) Aber: Vorteile Virtualisierung: Ganz simpel, die Reboots der Server. So schön schnell und zuverlässig. Wenn mal was total klemmt, kann ich die Maschine aus der Ferne abwürgen ohne auf einen physikalischen Knopf drücken zu müssen. Kommt nicht oft vor aber dann ists halt so einfach

f) Datensicherung: Die interne Proxmox-Sicherung funktioniert "tadellos". Das Rücksichern einer Maschine ist recht simpel. (Bedenken: Ich sicher trotzdem auch innerhalbt der VM, wenn ich mal nur eine Datei wiederholen muss - einfacher).

g) Kosten: Ein etwas dickeres "Blech" als VM-Host, ist halt günster als zwei nicht so performante "Bleche". Vorteil für die VMs.

Für meine Größenordnungen, vielleicht 15-20 Leute max. in der Kanzlei hat sich bei mir Virtualisierung durchgesetzt. Einen DC, FileServer-Kombination so wie es @Koppelfeld schreibt und fertig , einen WTS, einen vielleicht einen Mail-Server, Cloud-Server halt alles auf einem Blech, nen Hardware-Raid unten drunter - die HDDs teile ich den Machinen sinnig zu, heute natürlich mit SSDs und ich empfinde das Ganze als durchaus performant. Die letzen zwei Systeme waren dann auch AMDs...

Wenns wesentlich mehr Mitarbeiter sind hab ich aber  tatsächlich auch bisher, "Alte-Schule" Intel-Blech-Gegen-Blech gestellt.

---

Was sich mir auch nicht so ganz erschließt, ist die Aufteilung auf mehrere WTS. Die DATEV sagt ja "ca. 15 Personen / Instanz". Daran hab ich mich bisher nicht exakt gehalten. 20 gehen natürlich in der Praxis auch - ich merk da keinen Unterschied - gefühlt. Was ist denn mit sagen wir mal 30-40 Usern? Das wäre so meine maximale Kunden-Größe. 2x WTS oder einmal richtig "dick" geht auch noch?

Das "Drei-Server-Modell" ist aus der Sicht höhere Ausfallsicherheit durch 2x WTS an sich für mich nicht richtig haltbar... Wenn der FileServer defekt ist, hab ich damit auch nichts gewonnen...

[#3]

Moin,

---

@Koppelfeld schrieb: a) 'Fileserver' und WTS

...

Also, für mich ist das der Performance - Super-GAU.

---

Hmm... bei den Kanzleien wo ich ein Blech mit 3-4 VM's laufen habe, kein Problem. Und wenn ich den "Leistungsindex" (Rewe-App) mal als Referenz zu anderen "klassischen" Kanzleien ziehe, dann liegen die in der Performance gleich auf oder schneller... 

ABER: Diese Vergleiche hinken... in meinen Hosts stecken SSD's, bei anderen ggf. noch HDD's... und was nicht noch alles.

---

b) Mehrere WTS virtualisiert 

...

Warum soll ich beispielsweise 40 Benutzer mit zwei WTS zu je 20 bedienen ? 

---

Aus der Erfahrung heraus. Bei meinem vorherigen Arbeitgeber hatten wir 8 WTS im Einsatz. Je nach Benutzeranzahl waren dann pro WTS durchaus mal 15 User am Start. Soweit kein Problem. Wenn nun eine Maschine mal in die Knie gegangen ist (BlueScreen), wurden die betreffenden Benutzer nach Neuanmeldung auf die restlich verbliebenen WTS verteilt. Je nachdem wie der Loadbalancer (seinerzeit 2X) gearbeitet hat, kamen dann schon durchaus mehr als 20 User auf einen WTS. Und der ging dann auch deutlich in der Performance runter. 

Auch wenn noch RAM / Festplatte / CPU ausreichend Luft hatten. Aber auf der Maschine ging dann einfach alles langsamer.

Netzwerk? Möglich, aber das eine GBit-Karte (später 10GBit) an ihre Grenzen kam, hab ich seit Jahrzehnten nicht mehr erlebt. 

Werter @Koppelfeld : Das sind meine persönlichen Erfahrungen. Nicht mehr und nicht weniger.

---

@LS4B schrieb: a) Einfacher ist an sich wirklich Blech-Gegen-Blech ohne Virtualisierung. Wenn gar nichts mehr funktioniert, kann ich jemanden per Telefon in der Kanzlei auch sagen: Drück solange auf den Knopf bis er aus ist und schalt ihn wieder an 

---

Die Server-Hosts von mir sind alle mit Management ausgestattet. Da schick ich keinen mehr zum Server und bitte ihn diesen auszuschalten....

---

b) Performance: Blech-Gegen-Blech wird bestimmt besser sein. Wieviel es heute ausmacht, keine Ahnung. In der Vor-SSD-Zeit hat man es schon gemerkt - heute "fühl" ich keinen Unterschied.

---

Ack. Zumal es dann noch auf viele weitere Gegebenheiten ankommt. Letztendlich vergleichen wir ggf. nicht nur Äpfel mit Birnen, sondern auch noch mit Melonen...

---

c) Hyper-V mach ich nicht wegen keinen Hyper-V Host auf einem DC => Macht man nicht

---

Darf man auch nicht... Hyper-V bleibt als einzige Rolle für sich allein. Aber einen DC darfst Du in einer VM betreiben.

---

e) Aber: Vorteile Virtualisierung: Ganz simpel, die Reboots der Server. So schön schnell und zuverlässig. 

---

Ack. Und alle Konsolen an einer Stelle ohne irgendwelchen Kram dazwischen im Zugriff. Wir haben mal mit KVM-Switches over Ethernet gearbeitet. So richtig geil war anders... 

---

Für meine Größenordnungen, vielleicht 15-20 Leute max. in der Kanzlei hat sich bei mir Virtualisierung durchgesetzt.

---

In grösseren Umgebungen ist das auch im Einsatz. Nur ändern sich hier deutlich die Rahmen. Und die verantwortlichen Admins/Entscheider sollten wissen, was sie tun.

Spannend wird eh die Zukunft. Denn hier stellt sich die Frage ob wir in den einzelnen Kanzleien oder auch Mandantenbetrieben noch über lokale Systeme reden werden. Aber dies ist dann hier definitiv offtop.

Beste Grüße
Christian Ockenfels

[#4]

Guten Morgen !

Danke für die Erfahrungen, @LS4B  und @chrisocki .   Vielleicht hat noch der eine oder andere einen Hinweis, daher warte ich mit der Antwort.

Ein Hinweis vorab an@chrisocki in Sachen "Saturierung eines Netzwerks":

Der Sprung von seinerzeit 10 MBit/s auf 100 MBit/s war gigantisch, insbesondere dann, wenn gleichzeitig von Halbduplex auf Vollduplex gewechselt wurde.  Beim Sprung von 100 MBit/s auf 1 GBit/s (bei ziemlich identischer "Bandbreite" auf dem Medium übrigens) war es schon kritischer.  Irgendwie mußte ja auch die Datenschwemme von etwa 10 MB pro Sekunde verarbeitet werden.  In der Praxis wurden lange Zeit nur 50% des Durchsatzes genutzt.

Mit 10 GB/s wird es dann "herausfordernd".  Ich hänge Ihnen 'mal ein ganz aktuelles Problembild an:   Zwei unterschiedliche Virtualisierungsumgebungen, die Pakete passieren zwei Bridges und einen "echten" Switch.   Die eine Richtung prima, die andere humpelt mit 4 GBit/s durch die Gegend.  Muß ich am Wochenende lösen.

Während der Übertragung ist übrigens eine der Hypervisor-CPU zu etwa 30 % ihrer Zeit aktiv.  Für eine einzige TCP-Verbindung.

Wenn Sie viele kleine Pakete haben, bekommen Sie auch einen 10 GBE - Link nie saturiert, die Pakete müssen ja, wie eine LKW-Kolonne, einen gewissen "Mindestabstand" haben.  Denn die Netzwerkkarte muß ja davon ausgehen, daß sich neben dem Empfänger noch jemand anders in der gleichen "collision domain" befindet.  Damit das "Kollisionserkennungssystem" CSMA/CD funktioniert, ist die Pause erforderlich.

Beruflich habe ich viel mit VoIP-Datenströmen zu tun, da werden i.d.R. nur 20 ms in einem Paket transportiert und wenn man da hundert gleichzeitige Gespräche hat, bidrektional, dann ist der Netzwerklink "versaut" für eine effiziente TCP-Übertragung, auch wenn der Switch sagt, "Auslastung nur 4%".

Deswegen meine Erfahrung:

a) "Jumbo Frames" sind keine gute Idee, aus verschiedenen Gründen. So müssen ALLE beteiligten Komponenten mit diesen Frames klarkommen, ansonsten sie nämlich "Hardwarefehler" detektieren.

b) Immer wieder verblüffend:

Ein aggregierter Link mit zwei mal 1 GBit/s zwischen zwei Switches ist DEUTLICH effektiver als ein Mal 10 GBit/s.  Natürlich NICHT, wenn im wesentlichen eine große Datei übertragen wird.   Es müssen schon mehrere Nutzer die Leitung nutzen, denn das Maximum pro Übertragung ist 1 GBit/s.

Ganz konkret:  Nachdem wir einmal zwei Switches mit aggregierten Links verbunden hatten, gab es am nächsten Tag "Aha-Effekte" bei den Anwendern, und wie wir alle wissen, bemerken die eigentlich NIE Verbesserungen, geschweige denn, daß sie uns dies mitteilen.

Das "Zusammenbinden" zweier Netzwerkports ist nicht ganz trivial, aber in der Regel beherrschen moderne Switches das, Stichwort 802.3ad.   Wenn das von Interesse ist für jemanden hier, schreibe ich gerne einmal ein "howto".

Erstmal "DANKE" für die Erfahrungen, zwar versuche ich DATEV und PC/WIN zu vermeiden, aber ein Kunde will gerade eine "Terminalserver" - Umgebung für gut 180 User erneuern.  Bislang hat er vier davon, ich wollte auf zwei reduzieren.

Jetzt habe ich Bauchschmerzen.  Mal sehen, was ich tun kann.

Gruß und Dank!

[#5]

@Koppelfeld 

Wie üblich übersehen Sie etwas: DATEV!

DATEV zwingt seit jahrzehnten zu Workarounds, das beginnt mit den tiefen Eingriffen in das Betriebssystem (egal ob damals DOS, OS/2 oder jetzt Windows NT) und endet in der etwas merkwürdigen nutzung von MS-SQL.

Damit verhindert DATEV auch effizientere Methoden der, ich nenne es einmal so, gemeinsamen Nutzung der leistungsfähigen Hardware. DATEV kann und will die Nutzung der Software in einer Containerumgebung nicht zulassen, Grund siehe oben. Und dabei ist es zimlich egal ob jetzt BSD Jails oder Docker oder Kubernates eingesetzt werden, am Ende will DATEV ein Windows als Basis.

Über den Aufbau eines funktionsfähigen AD sollten Sie eigentlich genug Wissen haben, also kann ich die Eingangsfrage nur als rhetorisch qualifizieren.

Ansonsten empfehle ich das Abonnement der iX wo viele Ihrer gestellten Fragen umfassend beantwortet werden, nur leider kann DATEV den modernen Techniken nichts abgewinnen. Es ist die Virtualisierung zu nehmen die mit DATEV am besten funktioniert. Wie die Umgebung dann aufzubauen ist sollten Sie dann wissen.

Kleiner Hinweis: auf Großrechnern läuft DATEV auch nut virtualisiert. Die RZ Anwendungen kommen aber. Dann gibt es aber neue Herausforderungen.

Läuft SAP /HANA eigentlich nativ auf einem Blockdevice?

[#6]

Als jemand, der nicht studierter Fachmann in der Rechnerarchitektur oder den hardware- und softwareseitigen Detailabläufen ist, möchte ich einbringen, dass man hier sicher Peak-Performance, Kapazität und Kosten gegeneinander abwägen muss.

Ich behaupte bei kleineren Kanzleien (so bis 5...15) stellt eine virtualisierte Lösung sicher einen guten Kompromiss dar.

Man möchte zunächst die Empfehlungen der Datev einhalten (WTS soll's sein wegen einfacherer Wartung):

• 3 Server die 24/7 laufen
• teure Prozessoren (hohe Taktrate) und SSDs natürlich
• USV
• Backup
• ...

PS: die Anforderungen der Datev scheinen mir allerdings etwas zu hoch, was vielleicht die Motivation der Programmierer effizient und ressourcenschonend zu arbeiten abmildert - ist ja eigentlich keine Hochleistungsanwendung wie Rendering, Video, Simulation ...

Dann die Kosten:

• Hardware
• Energie
• Lizenzen
• Wartung

Hier wird schnell klar, dass ein all in one System eigentlich kostenseitig top wäre (Austausch aber komplex), was aber Datev nicht offiziell als Empfehlung anbietet (ich weiß, @Koppelfeld hatte da schon mal einen umfangreicheren Aufsatz hier hinterlassen). Man möchte aber im Supportfall nicht wegen solcherlei alleine dastehen.

Die alles erfüllende Alternative ist die Virtualisierung, bei der auch beim irgendwann anstehenden Tausch des Hosts die VMs einfach migriert werden können....

Es ist wohl so, dass die Virtualisierung einige Hardware-Ressourcen "ungenutzt" liegen lässt und durch den Verwaltungsaufwand auch die Peak-Performance verringert, aber das Gesamtpaket, welches auf einem Server läuft, ist meiner Meinung nach diesen Kompromiss wert, besonders wenn man eine solche Anwendung wie Datev nutzt. Die Kapazität des Host wird dadurch jedenfalls gut genutzt.

Die Vorteile der Virtualisierung liegen meiner Meinung also primär in den Kosten (ein Host, eine MS Server-Lizenz, geringer Stromverbrauch...), der Flexibilität (VMs können einfach gesichert und auf andere Hardware verschoben werden) und der Tatsache, dass jede VM standardisierte virtuelle Hardware hat. Zusätzlich sind nicht unbedingt High-Speed Netzwerkkomponenten notwendig, weil die VMs intern ja quasi direkt kommunizieren können.

Letztlich muss man bei Virtualisierung eine gegenüber Blech geringere Peak-Performance und höhere Latenz in Kauf nehmen (was aber praktisch zumeist keine Rolle spielt). Weitere Nachteile kann ich nicht sehen.

Abhängig von der Größe der Nutzerschaft, mag dies hier natürlich auch anders ausschlagen können.

[#7]

---

@Koppelfeld schrieb: Der Sprung von seinerzeit 10 MBit/s auf 100 MBit/s war gigantisch, insbesondere dann, wenn gleichzeitig von Halbduplex auf Vollduplex gewechselt wurde.

---

Wohl wahr. 10Mbit (Koax) auf 10Mbit (noch mit HUB) waren echt der Knaller... Im DATEV-Bereich hat sich dann der Sprung auf GBit (zumindest gefühlt) nur gering ausgewirkt.

---

Wenn Sie viele kleine Pakete haben, bekommen Sie auch einen 10 GBE - Link nie saturiert, 

---

Und genau dass wird wohl auch in vielen Umgebungen das Problem sein. Terminalserver, VoIP und SQL-Abfragen produzieren nur kleine aber viele Datenpakete. 

Aus dem Gefühl und der Erfahrung heraus klemmt es dann an den Netzwerkkomponenten, wenn hier "Billig-Produkte" genutzt werden. Wobei sich dies auch mittlerweile relativiert, da wohl Broadcom seine Finger überall drin hat... 

zu a) Hab ich noch nie eingesetzt, da es bei kleinen Datenpaketen einfach keinen Sinn ergibt...

zu b) Ack, konnten wir bei der genannten grösseren Umgebung nachvollziehen

Da kommt es aber auch wieder auf die verwendeten Komponenten (Netzwerkkarten, Switche) an. Billigkram bremst hier oder funktioniert gar nicht... 

180 User im Vollbetrieb (immer angemeldet) oder 180 User als angelegte User im AD? 

Allein auf DATEV würde ich die Anzahl der WTS nicht abstellen. DATEV mag wohl Ressourcen auslasten, aber die anderen Applikationen stehen denen meist nichts nach. Und wenn dann noch grottige Prozessaufrufe (Word, Excel, etc.) es schaffen eine CPU mit 100% zu belasten, wird es auf einem WTS schnell einsam... 

Und das geht/ging in Excel mitunter mit der einfachen "Speichern"-Frage... Excel steht bei einem User auf 100% und bleibt dort, bis der Mitarbeiter das Fenster quittiert hat... 

---

@einmalnoch schrieb: Damit verhindert DATEV auch effizientere Methoden der, ich nenne es einmal so, gemeinsamen Nutzung der leistungsfähigen Hardware. DATEV kann und will die Nutzung der Software in einer Containerumgebung nicht zulassen, Grund siehe oben. Und dabei ist es zimlich egal ob jetzt BSD Jails oder Docker oder Kubernates eingesetzt werden, am Ende will DATEV ein Windows als Basis.

---

Betrachten Sie doch mal den Einsatz aus Sicht der DATEV. Allein der Supportaufwand für die Umgebungen, die einen eigens lizenzierten MS-SQL nutzen wollen... Und dann skalieren Sie das mal hoch auf Kanzleien die einfach nicht wissen was sie tun oder gar wollen... 

Dann gehen im DATEV-Support schnell die Lichter aus. Also bleibt letztendlich nur ein Korsett, welches alle DATEV-Nutzer anziehen müssen. Egal ob sie wollen oder nicht. 

Oder haben Sie eine bessere Idee, wie die schiere Anzahl von DATEV-Umgebungen supportet werden kann?

---

Kleiner Hinweis: auf Großrechnern läuft DATEV auch nut virtualisiert. Die RZ Anwendungen kommen aber. Dann gibt es aber neue Herausforderungen.

---

Da bin ich voll bei Ihnen... Und die Systemhäuser, die meinen in 10 Jahren noch mit DVD-Installationen o.ä. durch zukommen, können eigentlich heute schon das Buch zu machen... 

Und dann stellen sich m.E. gar nicht mehr die Fragen Virtualisierung oder nicht... 

---

@Nutzer_8888 schrieb: Ich behaupte bei kleineren Kanzleien (so bis 5...15) stellt eine virtualisierte Lösung sicher einen guten Kompromiss dar.

---

Gern auch für mehr Benutzer, bei entsprechender Skalierung. Aber ansonsten bin ich da bei Ihnen.

Beste Grüße
Christian Ockenfels

[#8]

---

@einmalnoch  schrieb:

@Koppelfeld 

Wie üblich übersehen Sie etwas: DATEV!

DATEV zwingt seit jahrzehnten zu Workarounds, das beginnt mit den tiefen Eingriffen in das Betriebssystem (egal ob damals DOS, OS/2 oder jetzt Windows NT) und endet in der etwas merkwürdigen nutzung von MS-SQL.

Mir wurde erzählt, sinngemäß:  "Mit der deutlich überarbeiteten DATEV Framework Library ("DFL") können wir die spezifischen Vorzüge (welche auch immer das sein mögen) des unterliegenden Betriebssystems nutzen und uns optimal an Neuentwicklungen anpassen".

So etwas hat man ja Ende der Achtziger bei IBM mit dem AS/400 gemacht, wie auch immer es jetzt tagesaktuell heißt.  Da gibt es nicht nur den 'single level store', an dem sich HP seit einigen Jahren versucht, sondern vor allem den "TIMI", "Technology Independant Machine Interface".  Prozessorcode kann vom Anwendungsprogramm nicht ausgeführt werden, und die Pointer unter OS/400 waren schon seit Indienststellung 128 Bit breit.

NACHTEIL:  Die AS/400 war grottenlahm.  Einer unserer Azubis zeichnete damals einen Cartoon mit einem "serverartig" aussehenden Käfig, in dem sich Schnecken bewegten, die kleine Tafeln mit "0" oder "1" hochhielten:  "Blick ins Innere der AS/400".

NUR:  Die "Zwischenschicht" bei IBM ist in den letzten 30 Jahren nicht komplexer geworden, sie wurde nur angepaßt von 24-Bit CISC über 32-Bit RISC zu 64-Bit "RISC".

Performance und Ressourcen allerdings steigerten sich um den Faktor 1.000 bis 10.000.

Diese Leistungssteigerungen kamen zu etwa 50% beim Benutzer an.

Da scheint in der Tat bei DATEV etwas schiefgelaufen zu sein, das wäre ein interssantes Forschungsprojekt ...

Damit verhindert DATEV auch effizientere Methoden der, ich nenne es einmal so, gemeinsamen Nutzung der leistungsfähigen Hardware. DATEV kann und will die Nutzung der Software in einer Containerumgebung nicht zulassen, Grund siehe oben. Und dabei ist es zimlich egal ob jetzt BSD Jails oder Docker oder Kubernates eingesetzt werden, am Ende will DATEV ein Windows als Basis.

Je nun, eine Prozessorvirtualisierung und "Container" sind aber schon zwei paar Schuhe.

Und ich kann DATEV verstehen, wenn sie sich noch mehr "Diversität" ans Bein binden will.

Über den Aufbau eines funktionsfähigen AD sollten Sie eigentlich genug Wissen haben, also kann ich die Eingangsfrage nur als rhetorisch qualifizieren.

Ohne Flachs:   Bei WEITEM habe ich nicht das notwendige Wissen über "AD", unter "Windows 2000" war es gruselig, da habe ich mir gesagt, "NIEMALS".   Zumal unser Rechtsanwalt uns mitteilte:  "Wenn SIE beim Kunden AD oder Outlook oder Exchange installieren, dann übernehmen Sie eine Art Garantenstellung und sind haftbar".

Nein, Nein, NEIN.

Ich habe NIXDORF überlebt, die 8870/U war ein Horror.   Mit IBMs AIX war es auch nicht immer Zuckerlecken.  Ich habe Dassault Systèmes (CAD / CATIA) überlebt.   MVS / TSO / CICS / OS/400 sind auch recht eigensinnig.

Ich muß keine PC-Technik in diesem Leben mehr haben und auch kein "Windows".

Unsere DATEV-Anwender sind "ererbt" und ein Freund erzählte mir ein Sprichwort aus seiner türkischen Heimat, "Man tritt nicht an die Tür, hinter der man gewohnt hat".

Allerdings haben wir neuerdings einen richtig guten Mitarbeiter, der den Produkten aus Redmond aufgeschlossener gegenübersteht als ich und dem "AD" ein Begriff ist.

Keine der von mir verwalteten DATEV-Umgebungen verwendet eine "DC" oder ein "AD".

Die Benutzersynchronisation machen wir mit dem (mittlerweile vollständig in "Win2016" integrierten) SFU, damit löst man auch das Problem eines plattformübergreifenden Dateiservers, auf den unsere Kunden in Industrie und Handel sehr viel Wert legen.

Läuft SAP /HANA eigentlich nativ auf einem Blockdevice?

---

Da kann ich nur für IBM POWER sprechen.   Unter POWER VM sind Block Devices eher Regel aus Ausnahme.   Typischerweise heute via SAN und NPIV, das geht auch recht gut und ist kinderleicht einzurichten.  Sofern man nicht 20 LUNs auf einem Plattenpool wieder zusammenführt. was neuerdings "Goldstandard" ist.

Generell meine ich aber, daß SAP auf richtige Großrechner gehört.  S4/HANA ist die Folge einer massiven Verstimmung zwischen IBM und SAP.

Wenn ich mir ansehe, wie grottenlahm SAP in manchen Kliniken ist ...

Danke für Ihre Hinweise, aber wir bekommen in 1/2 Stunde Besuch und ich sitze hier noch im T-Shirt.

Schönen Tag!

[#9]

---

@LS4B  schrieb:

b) Performance: Blech-Gegen-Blech wird bestimmt besser sein. Wieviel es heute ausmacht, keine Ahnung. In der Vor-SSD-Zeit hat man es schon gemerkt - heute "fühl" ich keinen Unterschied.

Mit der x86 - Welt bin ich nicht so befreundet.  Daher die nur vorsichtige Frage:

Ist eine "SSD" nicht wieder ein Weg in die Sackgasse ?

Die meinsten, die ich sehe, sind "SATA".   Ich würde ja eher zu SAS tendieren.

Das Schlimmste bei SSDs ist aber das "D" drin:  Die simulieren tatsächlich eine drehende Platte.   Der drehenden Platte hat man über die Jahre alle möglichen Tricks beigebracht, ihre I/Os zu serialisieren und umzusortieren, bspw. "Elevator Algorithm" und "Tagged Command Queue".  Eine wichtige Metrik für eine drehende Platte ist tatsächlich die Anzahl der Aufträge in der Warteschlange.

Dumm nur:   Moderner Flash-Speicher hat gar keine Probleme damit, gleich mehrere Aufträge gleichzeitig zu bearbeiten - und dank PCI Express kann er diese Aufträge auch über verschiedene Lanes abwickeln.

Viele RAID-Controller behandeln die SSDs ebenfalls wie drehende Platten, kennen kein TRIM-Kommando und verringern so die Lebensdauer der SSD.

Wäre es da nicht zielführender in einer DATEV-Umgebung, man würde gleich NVMe in die Maschinen stecken?  Bei IBM gibt es das seit geraumer Zeit, es gibt auch NVMe für die Mezzanine-Slots von Bladesystemen und die 'random' - Schreibperformance ist schon gigantisch.

c) Hyper-V mach ich nicht wegen keinen Hyper-V Host auf einem DC => Macht man nicht=> Dann hab ich ja quasi noch eine relativ dicke  Windows-Maschine mehr im Haus als VM-Host, die ich aber nicht will.

SCHON WIEDER ein Grund, auf "DC" und "AD" zu verzichten.

d) VMWare => Kosten, sehe keinen Vorteil zu Proxmox den ich für "lau" haben kann. Updates am Proxmox: Ganz ehrlich, schenk ich mir inzwischen. Lass das Teil die 5 Jahre durchlaufen. Ich mach ja auch nicht ständig nen BIOS-Update am Blech... sozusagen.

Naja, wenn ich die Release Notes so durchlese ...   Unseren industriellen Kunden gegenüber fühlen wir uns schon verpflichtet, regelmäßig Updates durchzuführen, zumal die über verlustfrei umschaltbare Backup - Systeme verfügen.  Da fangen wir meistens beim "BIOS" an, welches in unserer Welt etwas anders heißt.

Der neue Hit:  Die Kundschaft liebt es, "Cyber-Versicherungen" abzuschließen, und da tut man gut, wenn die Maschinen einigermaßen aktuell sind.

Aber ich finde Ihren pragmatischen Ansatz gut, wir haben jetzt zum erstenmal ein "schieres" KVM für Microsoft-Virtualisierung eingesetzt und das läuft unverschämt gut.

"Proxmox" ist ja wohl nur eine "repackaged" - Version von KVM.

Bieten Sie doch einmal einen "Workshop" an, "Alternativen zu VMWare und Hyper-V".

e) Aber: Vorteile Virtualisierung: Ganz simpel, die Reboots der Server. So schön schnell und zuverlässig. Wenn mal was total klemmt, kann ich die Maschine aus der Ferne abwürgen ohne auf einen physikalischen Knopf drücken zu müssen. Kommt nicht oft vor aber dann ists halt so einfach

Die x86 - Systeme haben aber doch alle ein Fernmanagement ?

Für eine Kanzlei habe ich einmal aus der Ferne eine komplette Installation gemacht, den "Windows" - Datenträger über die Internetverbindung angehängt.  Unglaublich, was heute so alles geht.  Da sollte man dann aber auf einem separaten Management-Netzwerk bestehen.  Und das bringt uns zu dem Punkt:

Steuerberater sind EXTREM sparsam und meinen stets, man wollte sie übers Ohr hauen.

Selbst nehmen sie auch viel zu geringe Stundensätze (wenn ich da nur an die Haftung denke -- und die Berufshaftpflicht zahlt nur sehr selten).  Mandanten "vergessen" ja auch gern die Vorbereitungszeit.   Manchmal bekomme ich ja "hautnah" mit, wie umfassend ein Kundentermin vorbereitet wird - und dann wird nur die Besprechungszeit abgerechnet mit 75,-- / Stunde.   Entsprechend meinen Steuerberater, auch nicht mehr für einen EDV-Dienstleister ausgeben zu wollen.   Und für Hardware schon gar nichts.

Manche "Serverräume" verursachen bei mir einen Herzstillstand.

f) Datensicherung: Die interne Proxmox-Sicherung funktioniert "tadellos". Das Rücksichern einer Maschine ist recht simpel. (Bedenken: Ich sicher trotzdem auch innerhalbt der VM, wenn ich mal nur eine Datei wiederholen muss - einfacher).

Sehe ich auch so.  Zumal die aktuellen "Windows-Server" ja keine Bandmaschinen mehr unterstützen.  Man faßt es nicht.

Mit KVM (oder Proxmox) kann man bequem und in einem Rutsch alle Images nachts auf ein Band kopieren.

g) Kosten: Ein etwas dickeres "Blech" als VM-Host, ist halt günster als zwei nicht so performante "Bleche". Vorteil für die VMs.

Erziehungsache.  Es ist ja auch immer Geld für neue Autos da.  Hardware macht typischerweise 10% des EDV-Budgets aus.  Da optimiere ich lieber die restlichen 90%.

Wenn eine Kanzlei keinen ordentlichen Raum für die EDV hat, dann muß mindestens so ein klimatisierter Serverschrank "drin" sein.  Der kostet dann mit Montage des Außengerätes gut 7.500,--.   Dafür aber spart man Strom (die Serverlüfter drehen wesentlich langsamer, das macht bei zwei Servern 150 W aus), die Lebensdauer der Geräte steigt deutlich, die Zuverlässigkeit dito, weil nicht alles mit Papierflusen eingedreckelt wird.   Anständige Verkabelung, ordentliche Switche, klimatisierter Serverschrank - da kommen dann ganz schnell 10.000,-- zusammen.

USV habe ich noch gar nicht drin.

Die Herren Steuerberater sagen dann aber ganz gern, "das lasse ich durch meinen Neffen machen, das ist ein Computergenie".  Da frage ich dann immer, ob sie sich vom Neffen auch das Auto reparieren lassen.

Vor nicht allzu langer Zeit haben wir eine Steuerberater-EDV nach obigen Kriterien ausgetauscht, die ist tatsächlich 12 Jahre ohne Mucken durchgelaufen.

Wenns wesentlich mehr Mitarbeiter sind hab ich aber  tatsächlich auch bisher, "Alte-Schule" Intel-Blech-Gegen-Blech gestellt.

Kompromiß:  So ein "Kombigerät", vier "echte" Server zentral verwaltet in einem Gehäuse, das macht auch Spaß.

Was sich mir auch nicht so ganz erschließt, ist die Aufteilung auf mehrere WTS. Die DATEV sagt ja "ca. 15 Personen / Instanz". Daran hab ich mich bisher nicht exakt gehalten. 20 gehen natürlich in der Praxis auch - ich merk da keinen Unterschied - gefühlt. Was ist denn mit sagen wir mal 30-40 Usern? Das wäre so meine maximale Kunden-Größe. 2x WTS oder einmal richtig "dick" geht auch noch?

Was mich zu diesem Thread veranlaßt hat.   Nehmen wir an, man verwendet NVMe und eliminiert noch ein paar andere Bremsen, etabliert einen dicken Link zum "Fileserver" ohne Umweg über einen Switch, nimmt diese "Gold-CPUs" ...

... dann müßte man doch auch 80 User hinbekommen, bei 50 gleichzeitig arbeitenden Mitarbeitern.  24 CPUs für 50 Mitarbeiter, das muß doch ausreichen ...

Das "Drei-Server-Modell" ist aus der Sicht höhere Ausfallsicherheit durch 2x WTS an sich für mich nicht richtig haltbar... Wenn der FileServer defekt ist, hab ich damit auch nichts gewonnen...

Eben, eben, eben.  Zumal:  Das größte Risiko speziell bei DATEV-Installationen sind Updates und Outlook-Trojaner.   Die legen dann gleich drei Server lahm, so hat man dann mehr Arbeit bei der Wiederherstellung.

Updates "zur Probe erstmal auf einem WTS" sind nicht drin, weil doch meistens korrespondierende Updates auf dem Fileserver notwendig sind.  DATEV selbst rät von "Schnappschuß" - Funktionen der Betriebssysteme ab, aus verständlichen Gründen.

---

Ich hätte ja wirklich Lust, einmal eine Referenzinstallation zu versuchen, aber ich war ein gutes Jahr schwer krank und habe einfach zuviel Zeit verloren.

Alle Gespräche mit DATEV-Beratern (und auch DATEV-Mitarbeitern, welche ich aus deren "früherem Leben" kenne) lassen den Schluß zu, daß sich die Berater noch locker 5 Jahre mit "lokalen" Installationen herumschlagen müssen.   Bei kleinen Kanzleien lohnt sich "ASP" ganz sicher, aber eine Kanzleigemeinschaft mit 40 Leuten zahlt sich dumm und dusselig.

"Gammelige" DATEV - Umgebungen aber behindern die Mitarbeiter und sind NOCH teurer.

[#10]

---

@Nutzer_8888  schrieb:

Als jemand, der nicht studierter Fachmann in der Rechnerarchitektur oder den hardware- und softwareseitigen Detailabläufen ist, möchte ich einbringen, dass man hier sicher Peak-Performance, Kapazität und Kosten gegeneinander abwägen muss.

Ich behaupte bei kleineren Kanzleien (so bis 5...15) stellt eine virtualisierte Lösung sicher einen guten Kompromiss dar.

Wenn nicht mehr als 10 GLEICHZEITIG aktiv sind, dann reicht wirklich das "All-in-One" - Modell.   Haben wir bei mehrfach bei Unternehmen im Einsatz, die selbst buchen, aber eine eigene EDV-Abteilung haben.

Aber ganz ehrlich -- warum nicht "ASP" ?   Es gibt da durchaus seriöse und erfahrene Partner.  Ohne da jetzt großartig Werbung machen zu wollen:  Die Firma SPECTRUM in Erkrath bietet da sehr individuelle Lösungen und der Uli Giesen ist mal mindestens 30 Jahre im Geschäft.  Andere können das bestimmt auch.

Man möchte zunächst die Empfehlungen der Datev einhalten (WTS soll's sein wegen einfacherer Wartung):

• 3 Server die 24/7 laufen
• teure Prozessoren (hohe Taktrate) und SSDs natürlich
• USV
• Backup
• ...

PS: die Anforderungen der Datev scheinen mir allerdings etwas zu hoch, was vielleicht die Motivation der Programmierer effizient und ressourcenschonend zu arbeiten abmildert - ist ja eigentlich keine Hochleistungsanwendung wie Rendering, Video, Simulation ...

Mir kommt es aber fast so vor.  Siehe dazu die Ausführungen von @einmalnoch .

Die alles erfüllende Alternative ist die Virtualisierung, bei der auch beim irgendwann anstehenden Tausch des Hosts die VMs einfach migriert werden können....

Ganz aktuell haben wir einige "Windows" - Instanzen streßfrei auf eine Virtualisierungsumgebung "umgezogen", indem wir einfach die Platten 1:1 kopiert haben, ohne "Tools" irgendwelcher Art.  Sie müssen dann nur die Netzwerkkarten- und Massenspeicher-"Treiber" austauschen.   Würde mich vor Probleme stellen, aber unser "Windows-Freak" hatte das in wenigen Minuten.

Es ist wohl so, dass die Virtualisierung einige Hardware-Ressourcen "ungenutzt" liegen lässt und durch den Verwaltungsaufwand auch die Peak-Performance verringert, aber das Gesamtpaket, welches auf einem Server läuft, ist meiner Meinung nach diesen Kompromiss wert, besonders wenn man eine solche Anwendung wie Datev nutzt. Die Kapazität des Host wird dadurch jedenfalls gut genutzt.

Es kommt halt doch sehr auf die Art der Virtualisierung an.

Die KVM / Proxmox - Lösung scheint mir momentan diejenige zu sein mit den wenigsten Fallen.  Das Kostenthema haben Sie ja schon angesprochen.

Wünsche ienen schönen Tag !

[#11]

Moin @Koppelfeld :

des Pudels Kern ist eigentlich zu Beginn diese Aussage:

---

Steuerberater sind EXTREM sparsam und meinen stets, man wollte sie übers Ohr hauen.

---

Natürlich sind nicht alle Kanzleientscheider so aufgestellt, aber einige schon. Und dann wird es statt eines vernünftigen Serverkonzepts (Schrank, USV, Klima, etc.), schnell eine "Spardose" unter dem Schreibtisch des Sekretariats... 

---

Ist eine "SSD" nicht wieder ein Weg in die Sackgasse ?

---

Nicht unbedingt. In jedem Fall bringen die SSD's ordentlich Schub in jedes System. Für entsprechende Anwendungen/Daten lasse ich auch gern SATA-SSD's zu. Für die DATEV-Daten und WTS bevorzuge ich allerdings SAS-SSD's oder besser NVMe.

Die RAID-Controller aus den aktuellen Chargen können auch problemlos mit den Themen TRIM, etc. umgehen. 

---

Naja, wenn ich die Release Notes so durchlese ... Unseren industriellen Kunden gegenüber fühlen wir uns schon verpflichtet, regelmäßig Updates durchzuführen, zumal die über verlustfrei umschaltbare Backup - Systeme verfügen. Da fangen wir meistens beim "BIOS" an, welches in unserer Welt etwas anders heißt.

---

Warum sollten Systemhäuser überhaupt zwischen "Industrie" und "Freiberuflern" unterscheiden? 

---

Die x86 - Systeme haben aber doch alle ein Fernmanagement ?

---

Noepp.... ist wieder eine Kostenfrage und kann entsprechend als Option auch abgewählt werden. Wenn aber ein Systemhaus sich auf sowas noch einlässt 

---

Manche "Serverräume" verursachen bei mir einen Herzstillstand.

---

🤣Kann ich verstehen... 

---

Sehe ich auch so. Zumal die aktuellen "Windows-Server" ja keine Bandmaschinen mehr unterstützen.

---

Ist das so? Ich kann mich dunkel daran erinnern, dass die Backupsoftware entsprechende Treiberunterstützungen mitbringt. 

---

Die Herren Steuerberater sagen dann aber ganz gern, "das lasse ich durch meinen Neffen machen, das ist ein Computergenie".

---

Machen lassen... da gibt es nur ein lernen durch Schmerzen. 

---

Was mich zu diesem Thread veranlaßt hat. Nehmen wir an, man verwendet NVMe und eliminiert noch ein paar andere Bremsen, etabliert einen dicken Link zum "Fileserver" ohne Umweg über einen Switch, nimmt diese "Gold-CPUs" ...

... dann müßte man doch auch 80 User hinbekommen, bei 50 gleichzeitig arbeitenden Mitarbeitern. 24 CPUs für 50 Mitarbeiter, das muß doch ausreichen ...

---

Sie haben doch selber das Thema mit den IO's angesprochen gehabt... Irgendwann ist da Schluß mit lustig. Und DATEV ist da nur ein Mitspieler. Office, Adobe und was nicht noch alles machen da auch den Ressourcenfresser... Mal von nervtötenden Druckertreibern abgesehen... (hatten Sie auch mal was geschrieben... ).

---

Das größte Risiko speziell bei DATEV-Installationen sind Updates und Outlook-Trojaner. Die legen dann gleich drei Server lahm, so hat man dann mehr Arbeit bei der Wiederherstellung.

---

Updates sind nur dann eine Lücke, wenn Sie nicht eingespielt werden. Und eine Wiederherstellung sollte je nach Backup gerade in VM-Bereich ziemlich fix gehen. 

Bei mehreren Kanzleien sichere ich via SnapShot stündlich. Bekommt keiner mit und im Worst-Case verliert die Kanzlei max. eine Stunde... 

---

daß sich die Berater noch locker 5 Jahre mit "lokalen" Installationen herumschlagen müssen.

Bei der aktuellen Entwicklungsgeschwindigkeit der DATEV-Cloudsysteme bin ich da bei Ihnen... 

---

Bei kleinen Kanzleien lohnt sich "ASP" ganz sicher, aber eine Kanzleigemeinschaft mit 40 Leuten zahlt sich dumm und dusselig.

---

Bleiben ja noch PartnerASP o.ä. wenn DATEVasp zu teuer ist. Und wenn die Kanzlei sich keinen Serverraum und Server mit entsprechender Ausstattung und Pflege leisten möchte, ist das Paket DATEVasp durchaus gerechtfertigt. Einen Serverraum mit der Ausstattung finden Sie wohl in (fast) keiner Kanzlei.

Beste Grüße
Christian Ockenfels

[#12]

---

@chrisocki  schrieb:

Moin @Koppelfeld :

des Pudels Kern ist eigentlich zu Beginn diese Aussage:

---

Steuerberater sind EXTREM sparsam und meinen stets, man wollte sie übers Ohr hauen.

---

Natürlich sind nicht alle Kanzleientscheider so aufgestellt, aber einige schon. Und dann wird es statt eines vernünftigen Serverkonzepts (Schrank, USV, Klima, etc.), schnell eine "Spardose" unter dem Schreibtisch des Sekretariats... 

Also DAS ist uns bislang erspart geblieben.  "USV" finden viele ja chic. aber wenn ich dann sage, "Netzfilter, zwei Einspeisungen pro Server, eine hinter dem Netzfilter, eine hinter der USV und die USV bitte mit Netzwerkanschluß, ordentlichem Akku und nicht von "APC", überhaupt bitte wg. Phasenlast dreiphasig anschließen", dann gibt es schon Streß.

---

Die RAID-Controller aus den aktuellen Chargen können auch problemlos mit den Themen TRIM, etc. umgehen.

Danke für den Hinweis, dann gucke ich mir 'mal die DL380 G10 an, die ein Kollege hier herumstehen hat.

Der Effekt von SSDs ist schon gigantisch.   Wir haben welche in unserem eigenen System, in einem kleinwagenteuren (Doppel-) Controller mit Failover, Batteriecache, EassyTiering usw. usf..  Mußten wir damals kaufen, man kann seine Erfahrungen ja nicht auf Produktivsystemen der Kunden sammeln.  Wenn ich mich recht entsinne, war der Listenpreis vor sechs Jahren 35.000,--.  Faktisch zahlt man die Hälfte.  Durch die SSD-Backplane vorn baut die Kiste dann auch gleich mit vier Höheneinheiten.

Das bekommen Sie heute WESENTLICH günstiger hin mit NVMe.

Da kann ich nur jedem empfehlen, "Wenn ihr modernisieren wollt, gleich neuen Server mit NVMe".

---

Warum sollten Systemhäuser überhaupt zwischen "Industrie" und "Freiberuflern" unterscheiden?

Wir sind zwar kein "Systemhaus", aber die Gründe kann ich trotzdem liefern:

a) Der Freiberufler stellt den Scheck persönlich aus, das ist ihm stets zuwider.

b) Der Steuerberater haßt es, wenn er bei uns den doppelten Stundensatz

    zahlen muß, den er selbst berechnet.  Kann ich nachvollziehen, die Ausbildung

    ist nicht ohne, die Verantwortung ist hoch und der Fortbildungsaufwand auch.

c) Industrie und Handel sind "schmerzfrei", die haben Hochregallager, Elektronen-

    rastermikroskope, CNC-Bearbeitungszentren und jede Menge anderes teures

    Spielzeug.

d) Oft haben die eine fach- und sachkundige EDV-Abteilung, da muß man sich nicht

    den Mund fusselig reden.

e)  Die HABEN meistens schon eine ordentliche Infrastruktur.

f)  Der Teufel sch... immer auf den dicksten Haufen, die kaufen sehr günstig ein.

     Der HP DL 380, der gerade bei uns liegt, würde uns im EK 8.000,-- kosten, der

     Kunde, der ihn bestellt hat, zahlt nicht einmal die Hälfte.

g)  Industrieunternehmen müssen teilweise üble Verträge mit ihren Kunden abschließen,

     die mit irrsinnigen Konventionalstrafen versehen sind.   Die können sich keinen Ausfall

     leisten.   Und wenn der EDV-Leiter Mist baut, bekommt er massiv Ärger.

     Schon von daher tut er alles, damit sein Laden läuft.

     Einem "Partner" kann man so leicht nix anhaben.

(Fernmanagement)

---

Noepp.... ist wieder eine Kostenfrage und kann entsprechend als Option auch abgewählt werden. Wenn aber ein Systemhaus sich auf sowas noch einlässt 

Das allerbeste gibt es bei HP, mit dem durchaus brauchbaren "ILO":

Da bootet man einen Rechner, und kurz nach dem Start sagt das ILO, "ich mache jetzt Schluß, für das Angucken nach dem Boot brauchst Du eine Extra-Lizenz".

Also, das würde ich nicht mehr mit einem Steuerberater diskutieren, und SO vernünftig sind sie auch, um zu erkennen, daß sie selbst die Nutznießer sind, weil man ihnen aus der Ferne sofort helfen kann.   Wir sind dann auch noch so doof und berechnen für die "Fernwartungen" nichts.

(Bandstation)

---

---

Ist das so? Ich kann mich dunkel daran erinnern, dass die Backupsoftware entsprechende Treiberunterstützungen mitbringt. 

Wir haben es versucht mit HP LTOFS.  Ein Reinfall.

Die "Windows Serversicherung" ist gar nicht schlecht, vor allen Dingen kann man damit sogar eine Wiederherstellung betreiben.  Ist auch automatisierbar.

Warum soll ich irgendetwas von "Veem" kaufen, bloß weil MS es versäumt hat, eine ganz normale Bandmaschine zu unterstützen ?!?!   Zumal:  Die Lizenz wäre mir ja wurscht, aber die muß man jährlich erneuern, und wieder haben wir einen Parasiten im System.

Was allein die Rechnungsprüfung kostet ...

---

Sie haben doch selber das Thema mit den IO's angesprochen gehabt... Irgendwann ist da Schluß mit lustig. Und DATEV ist da nur ein Mitspieler. Office, Adobe und was nicht noch alles machen da auch den Ressourcenfresser...

200 User mit "Office" und den üblichen Spielereien wie "Chrome" sind eher kein Problem nach unserer Erfahrung.   DATEV dagegen ist ein echter Showstopper.

Mal von nervtötenden Druckertreibern abgesehen... (hatten Sie auch mal was geschrieben... ).

Jetzt gerade wieder.

Ich weiß nicht, was ich dem Steuerberater noch erzählen soll.

Der druckt aus "Unternehmen online" und bemängelt, daß pro Minute nur eine Seite herauskomme.  "Und der Drucker heult", ich nehme einmal an, er meint den Standby-Modus, der nach einer gewissen Leerlaufzeit angelaufen wird.  WAS MACHEN DIE DA ?

Es ist eine ganz banale Liste, ohne Graphik.   Und der Drucker ist ein fettes "Abteilungsgerät" von HP mit starkem RISC-Prozessor.

Immer wieder "lustig", den Aufwand wird uns keiner bezahlen, denn wenn wir ein Gerät empfehlen, dann sorgen wir auch dafür, daß es läuft.  Sehr unschön.

Bei mehreren Kanzleien sichere ich via SnapShot stündlich. Bekommt keiner mit und im Worst-Case verliert die Kanzlei max. eine Stunde... 

... sagt DATEV:  "Das dürft Ihr nicht", ist mir auch plausibel wegen der offnen Tabellen.

Einen Serverraum mit der Ausstattung finden Sie wohl in (fast) keiner Kanzlei.

Und ob.   Wenn es sein muß, im Keller.   Wenn kein Gewässer in der Nähe ist.

Mit so einem Klimaschrank kann der Raum ja auch noch als Archiv oder Lager genutzt werden.

[#13]

@Koppelfeld 

Vielleicht mal die Kirche im Dorf lassen.

Zunächst muss der geneigte Berater feststellen das es ohne Virtualisierung heute nicht mehr geht. Schon 2 Windows Server auf Blech auf neue Hardware ist schon eine Herausforderung.

Über Windows brauchen wir nicht sprechen, das ist von DATEV mit allen Vor- und Nachteilen vorgegeben. Bleibt nur eine sinnvolle Verteilung der Last. Das ist ein schwieriges Unterfangen da DATEV den MS-SQL Server nur als Tontäfelchenlagerplatz nutzt. Die Auswertungsoperationen finden am Client statt.

Die Virtualisierungsumgebung wird in der Regel durch die Anforderungen bestimmt. Wer eine CentOS Maschine auf VMWare virtualisiert hat kann nicht einfach mal damit auf Proxmox umziehen. Irgendwie mögen die sich nicht beim Umzug, die HowTos sind Legende.

Virtualisierung und Bandsicherung ist auch so eine unendliche Veranstaltung - viel Spaß dabei. LTFS auf LTO Geräten ist auch eher eine Zweitsicherung für eine längerfristige Aufbewahrung. LTFS stammt im Übrigen von IBM, der Download des Originals ist in der Regel stabiler als die Herstellerderivate.

Ob ich jetzt Proxmox Backup oder Veeam zahle ist relativ egal, ohne Datensicherung bin ich nackt, da hilft manchmal auch ASP mit 30 Tagen nichts. Weitere Backuplösungen? Da sind **bleep** wenige noch unterwegs, für kleine und mittlere Unternehmen noch weniger.

Wie immer zählt das Gesamtpaket in Kosten - Nutzen Analyse. Da bleibt am Ende nur eins, Know How kaufen oder sich in die Sache einarbeiten.

Im Übrigen ist die Cloud kein Mainframe, der Mainframe ist das Rechenzentrum von gestern. Es gibt ihn noch weil ihn noch viele alte Anwendungen benötigen (Aussage eine Fujitsu Managers im Interview mit der iX).

[#14]

@einmalnoch  schrieb:
@Koppelfeld 

Vielleicht mal die Kirche im Dorf lassen.

Zunächst muss der geneigte Berater feststellen das es ohne Virtualisierung heute nicht mehr geht. Schon 2 Windows Server auf Blech auf neue Hardware ist schon eine Herausforderung.

Erstmal Danke für Ihre Antwort.

Hier schreiben gute und interessante Leute.

Den Schuh des "Beraters" ziehe ich mir nicht an, auch heute noch mache ich mir gern die Hände schmutzig.  Am liebsten würde ich nur programmieren, das kann ich nämlich ganz gut, aber leider werde ich oft zu Infrastrukturproblemen in Anspruch genommen.

Virtualisierung gibt es schon lange, richtig lange.   Sie wissen, daß Sie alt sind, wenn Sie im "Deutschen Museum" die Maschine stehen sehen, auf der Sie gelernt haben.

In meinem Falle war es eine KIENZLE 6100/8, und, guess what:

Ja, schon diese Kiste, mit Magnetkernspeicher und festgefädeltem ROM, konnte eine Partition hosten.

Produktiv gab es das bei IBM seit ich denken kann, ein bekanntes Großrechner-OS nennt sich VM.  Heute z/VM.

Daß heute "kein Weg an Vrtualisierung vorbeigeht", weiß ich nicht.

Sehr gut laufen kleinere Einzelmaschinen 'bare metal' auf Blades.   Da gibt es Kisten, da steckt ein fettes SAN drin, komplett mit FC-Fabric, redundant, mit 10 GB/s - Ethernet Switches.  Da stecken Sie dann noch Blades hinein und managen alles über das zentrale Management-Modul.  Da merken Sie gar nicht, daß Sie auf unterschiedlichen Maschinen sind.  Zugriff zur Datensicherung haben Sie dann z.B. via SVC.

Natürlich sehe ich auch Vorteile bei der Wirrtualisierung, aber

a) die Umsetzung ist z.T. doch sehr dilettantisch.  Namentlich der "Virtual Storage".

b) das "Virtual Networking" frißt jede Menge Performance.  Jeder 40-Euro-Zockerswitch für die LAN-Party ist dank ASICs und/oder FPGAs leistungsfähiger als der "virtuelle Switch" in einer Virtualisierungsumgebung.

c) die Zuverlässigkeit läßt doch sehr zu wünschen übrig.

d) ein Server ist ein Server, ob nun virtuell oder auf Blech.   Das Blech ist das billigste daran.

e) ein Server ist schon per se eine Virtualisierungsinstanz.

Mir geht es darum, einfache, aber zuverlässige Umgebungen zu schaffen.

Eine Sondermülldeponie muß sicher sein.

Über Windows brauchen wir nicht sprechen, das ist von DATEV mit allen Vor- und Nachteilen vorgegeben. Bleibt nur eine sinnvolle Verteilung der Last. Das ist ein schwieriges Unterfangen da DATEV den MS-SQL Server nur als Tontäfelchenlagerplatz nutzt. Die Auswertungsoperationen finden am Client statt.

Das ist jetzt nicht Ihr Ernst, oder?

Mir schwant da etwas ganz Schlimmes.

Das ist wirklich grotesk.

Ich wage das ja gar nicht zu fragen:

Wollen Sie damit insinuieren, daß die DATEV eigentlich immer noch auf dem "BTRIEVE" - Niveau programmiert ?   Ich glaube, so hieß die ISAM-Bibliothek unter "MS-DOS".  Die "Windows-Versionen" waren im Anfang ja auch nur DOS-Anwendungen in einer Terminal-Box.  Das Crashen der "ZMSD" gehörte in DATEV-Umgebungen ja schon zum guten Ton.

Die "Umstellung" auf "SQL Server" ist also so erfolgt, daß ein ISAM-API "drübergestülpt" wurde ?  Sodaß die derartig kastrierte "DB" nur Record Locking machen durfte ?

Würde bedeuten, daß bspw. ein 'JOIN' zweier Tabellen im Client realisiert wird ?

Das ist so gruselig, das es schon wieder wahrscheinlich wird.

Das würde allerdings EINIGES erklären.

Die Virtualisierungsumgebung wird in der Regel durch die Anforderungen bestimmt. Wer eine CentOS Maschine auf VMWare virtualisiert hat kann nicht einfach mal damit auf Proxmox umziehen. Irgendwie mögen die sich nicht beim Umzug, die HowTos sind Legende.

Gut, daß ich keine lese.  Das ist aber auch ein Verhau:  Der eine nimmt "CentOS", der nächste "Fedora", der nächste "RHEL", wieder andere wollen "SLES", gerne wird auch "UBUNTU" genommen.  Andere machen daraus einen fröhlichen Mix und gießen es zum 29. Mal als "Proxmox" auf.

Ich kann da nur die eigene Erfahrung heranziehen, und die sagt, daß ein "schieres" KVM einfacher und komplikationsloser ist als "VMWare" oder "Hyper-V".

Insbesondere, und das hat mich selbst überrascht, hat ein (microsoftkundiger) Mitarbeiter gerade vor einer Woche einen bunten Strauß an "Servern" von "Windows 2012" bis "2016" sowie eine Reihe "Windows 10" von "Hyper-V" oder auch direkt von Platten-Images 1:1 übertragen -- und die liefen dann, natürlich nach Installation der DASD- bzw. NIC-Driver.  Ich glaube, das hat er VOR der Übernahme gemacht.

Alles erstmal Block I/O, zugegebenermaßen von einem SAN, "durchgereicht" mit VSCSI.

Ich habe das Gefühl, die "Featuritis" und die "Cockpits" machen die Systeme anfällig.

SR-IOV mag gut und schön sein, aber es muß dann auch funktionieren.

Virtualisierung und Bandsicherung ist auch so eine unendliche Veranstaltung - viel Spaß dabei.

Hatten wir.

LTFS auf LTO Geräten ist auch eher eine Zweitsicherung für eine längerfristige Aufbewahrung. LTFS stammt im Übrigen von IBM, der Download des Originals ist in der Regel stabiler als die Herstellerderivate.

Wir haben mit IBM, Exabyte-OEM und HP-OEM getestet.

Unbefriedigend.

Im Übrigen ist die Cloud kein Mainframe, der Mainframe ist das Rechenzentrum von gestern.

Ja, aber mit dem "Rechenzentrum von gestern" war DATEV 1976 da, wo sie heute hinwill.   Schon damals konnte man über die DATEV-eigenen Konzentratoren in die "DATEV-Cloud", um im echten Dialog Umbuchungen zu machen und dann Bilanz, GuV und Anlagespiegel unmittelbar lokal drucken.  Die Umbuchungen konnte man auch adhoc in die laufende FiBu übernehmen.

Auch die "Steuerrechtsdatenbank" war brauchbar.

Und alles mit nur einer "App", dem Terminalprogramm.

Es gibt ihn noch weil ihn noch viele alte Anwendungen benötigen (Aussage eine Fujitsu Managers im Interview mit der iX).

Und für die "alten Anwendungen" gibt es vielfach keinen Ersatz, der horizontal und vertikal skaliert.  Wir haben viele "Migrationen" gesehen, die erbärmlich gescheitert sind, Firma Liqui Moly hat das einmal öffentlich gemacht.  Katastrophale "Migrationsprojekte" Richtung "JAVA" bspw. von Intentia gingen ebenfalls durch die Tagespresse.

Wenn die "alten Anwendungen" von gestern sind, ist der abgestandene, kalte JAVA-Kaffee von vorgestern.

An die Performance der DATEV-Programme "von gestern" werden, so fürchte ich, deren Lösungen von übermorgen nicht herankommen.

Bezüglich der aktuellen Situation sagen DATEV-Anwender, daß die Performance unterirdisch sei und sie regelmäßig ausgebremst würden.  Ganz speziell die Leistungsträger.

Der administrative Aufwand ist erheblich.

Das Gefährdungspotential ist hoch.

Der Tanker schwoit.

Und was sehen wir am Horizont ?

Vor-vor-vorgestern sagten die Mönche,

"nunc videmus per speculum in enigmate" ...

[#15]

Bezüglich der aktuellen Situation sagen DATEV-Anwender, daß die Performance unterirdisch sei und sie regelmäßig ausgebremst würden.  Ganz speziell die Leistungsträger.

Der administrative Aufwand ist erheblich.

Das Gefährdungspotential ist hoch.

ein paar Jahre noch.. dann ist alles in der Cloud.. so lange noch: Augen zu und durch ;-).

Bei uns läuft Datev sehr schnell. Aber auch keine Virtualisierung...

Wir haben noch eine virtualisierte Maschine für SVnet.. ja, da ist langsam. 

Aber keine Ahnung warum... ist auch egal, da sie sehr selten genutzt wird.

[#16]

@Koppelfeld 

Das ist jetzt nicht Ihr Ernst, oder?

Mir schwant da etwas ganz Schlimmes.

Das ist wirklich grotesk.

Ich wage das ja gar nicht zu fragen:

Wollen Sie damit insinuieren, daß die DATEV eigentlich immer noch auf dem "BTRIEVE" - Niveau programmiert ?   Ich glaube, so hieß die ISAM-Bibliothek unter "MS-DOS".  Die "Windows-Versionen" waren im Anfang ja auch nur DOS-Anwendungen in einer Terminal-Box.  Das Crashen der "ZMSD" gehörte in DATEV-Umgebungen ja schon zum guten Ton.

Die "Umstellung" auf "SQL Server" ist also so erfolgt, daß ein ISAM-API "drübergestülpt" wurde ?  Sodaß die derartig kastrierte "DB" nur Record Locking machen durfte ?

Würde bedeuten, daß bspw. ein 'JOIN' zweier Tabellen im Client realisiert wird ?

Das ist so gruselig, das es schon wieder wahrscheinlich wird.

Das würde allerdings EINIGES erklären.

Wer hier und in der alten Newsgroup interessiert mitliest weiß das es so ist. @zippo hatte mal eine Auswertung über die Ladezeiten im Arbeitsplatz gepostet. Ich selbst habe mal bei Rumspielen mit dem NCP Client die frühe Bindung und dem entsprechenden Login probiert, eine halbe Stunde später war der AP über über eine damals flotte DSL Leitung im Client Server Betrieb geladen. Noch Fragen?

Also nix mit Views oder StoredProcs und was moderne Datenbanken noch so anbieten. DATEV liebt die Mainframesteinzeit.

DATEV und Sicherheit? Ja, was den Zugriffschutz angeht, Betriebssicherheit ist bei DATEV ein sehr stiefmütterlich behandeltes Thema.

Und ja, die Nutzung des SQL Servers durch DATEV ist tatsächlich auf BTrieve Niveau, etwas Access kommt aber auch vor (EO classic). Schauen Sie sich mal die SQL Paketstatistiken an.

DATEV - das Softwaremuseum.

[#17]

... auf jeden Fall ist hier im Thread 'ordentlich Musik drin' 😅

Eigentlich bräuchte man einen digitalen "grünen" Markierstift, um alle Aussagen grün zu markieren, mit denen man d'accord geht und einen "roten" Stift für die Aussagen, die einem wie eine Fischgräte quer im Hals stecken bleiben.

... aber laaaange Beiträge mit Kudos zu bewerfen ... ähm ... zu bewerten, fällt nicht ganz leicht, weil ein Kudo ja "Begeisterung" und "völligen Gleichklang" suggeriert

... aber meinungsstarke Beitragsschreiber sind ja sowieso nicht auf Lob oder Kritik angewiesen 😉

... aber nochmal:

wäre das nicht auch ein schönes Feature, beliebige Textstellen für sich selbst markieren zu können, @Dirk_Jendritzki  ?

[#18]

---

@vogtsburger  schrieb:

... auf jeden Fall ist hier im Thread 'ordentlich Musik drin' 😅

Ich vermisse den "#AUFSCHREI"

Allerdings befürchte ich, wir haben den "Zündstoff" unter einem Kokon von "TLA"s (three-letter-acronyms) begraben.

Einfache, konzise und dennoch nicht simplifizierende Darstellungen fallen mir sehr schwer.

Eigentlich bräuchte man einen digitalen "grünen" Markierstift, um alle Aussagen grün zu markieren, mit denen man d'accord geht und einen "roten" Stift für die Aussagen, die einem wie eine Fischgräte quer im Hals stecken bleiben.

Es ging hier ja darum, Ursachenforschung zu betreiben.

Durchaus mit dem Ziel, "wie kann ich eine Plattform im DATEV-Umfeld einfach, effizient und sicher betreiben ?".

Wirklich fundierte Aussagen sind für "Außenstehende" nicht möglich.

Allerdings:  Die grüne DATEV-Landschaft gleicht ja einem gepflegten englischen Rasen, jedes Hälmchen ist gestutzt und alles ist "gestylt".    Überall befinden sich Steinplatten für die Anwender, sodaß diese darauf wandeln können, ohne dem Rasen ein Leides zu tun.

Wenn man jetzt aber, einer plötzlichen Eingebung folgend, eine der Platten anhebt, dann tut sich eine ganz andere Welt auf:  Ein Gewimmel von Würmern und Käfern, und man spürt so einen modrigen Leichengeruch.  Jetzt hat @einmalnoch an einer Stelle einmal etwas tiefer gegraben, und heraus kommt:  Der Datev-Park ist auf einer Leichengrube gebaut, in der die Kadaver liegen, die von der PC/DOS - Pest dahingerafft wurden.

Mir scheint das alles sehr plausibel, und um ganz ehrlich zu sein:   Selber habe ich auch etliche Leichen im Keller, die loszuwerden es ganz schwierig ist, "politisch" wie technisch.

Hinweise auf Fehler, die den Autoren hier unterlaufen, sind garantiert willkommen.

Also her mit dem Rotstift.

... aber laaaange Beiträge mit Kudos zu bewerfen ... ähm ... zu bewerten, fällt nicht ganz leicht, weil ein Kudo ja "Begeisterung" und "völligen Gleichklang" suggeriert

Viel schöner wäre doch ein "Ablehnung" - Knopf.

... aber meinungsstarke Beitragsschreiber sind ja sowieso nicht auf Lob oder Kritik angewiesen 😉

Jeder, der sich die Mühe macht, sich mit der etwas staubigen Materie auseinanderzusetzen, freut sich über Anerkennung.   Nein, fühlen Sie sich nicht verpflichtet, auf irgendeinen Knopf zu drücken.

So ein Forum ist ja dazu da, Erfahrungen auszutauschen und Erkenntnisse zu gewinnen.

Stattdessen kann ich Sie nur ermutigen, die "Fischgräten" auszuspucken und zu benennen.

Gruß,

[#19]

---

@einmalnoch  schrieb:

Also nix mit Views oder StoredProcs und was moderne Datenbanken noch so anbieten. DATEV liebt die Mainframesteinzeit.

DATEV und Sicherheit? Ja, was den Zugriffschutz angeht, Betriebssicherheit ist bei DATEV ein sehr stiefmütterlich behandeltes Thema.

Da haben es die Amis besser, die unterscheiden strikt zwischen "Security" und "Safety".

Und ja, die Nutzung des SQL Servers durch DATEV ist tatsächlich auf BTrieve Niveau, etwas Access kommt aber auch vor (EO classic). Schauen Sie sich mal die SQL Paketstatistiken an.

DATEV - das Softwaremuseum.

---

Das dicke Ende kommt ja noch:   Die Uralt-Legacy-DOS - Programmierung wird mit jedem neuen Modul komplexer.   Wenn Sie sich in der Anwendung selbst um referenzielle Integrität kümmern müssen, dann haben Sie verloren.   Das kann man auch prima mit einem Mainframe machen.

Die "Sackgasse", in der DATEV steckt, ist also nicht nur eine Frage der Infrastruktur, sondern eine Folge einer ungeeigneten, veralteten Softwarearchitektur.   Zumindest legen das Ihre Inferenzen sehr nahe.

Macht DATEV eigentlich keine interne Supervisionen ?

Wissen die Genossen eigentlich, welche Architektur hinter den "neuen" Anwendungen steckt ?  Hier geht es ja nicht nur um Sicherheit und Stabilität, sondern um Flexibilität und Offenheit für spätere Erweiterungen !

Die aktuelle "Suite" hat Datev ja aufgegeben, dafür hat jeder Verständnis.

Aber traut man einem Unternehmen, daß eine "Landschaft" wie die aktuelle nach Art eines "Great Barrier Reef"s agglomeriert hat, wirklich zu, eine saubere Architektur abzuliefern ?

Oder wird nach Art des Hauses wieder wild und überall zugekauft, in der Hoffnung, ein paar Zeilen "Glue Code" würden es schon richten ?

[#20]

Wieso #AUFSCHREI?

Hatten wir schon häufiger hier. Siehe #Sendepause.

DATEV kann und will nicht.

[#21]

Sie viel zum Thema wir verwenden keine Views und StoredProcedures

[#22]

Moin @einmalnoch ,

wo kommen denn diese Aussagen her? Haben Sich mal mit der EO-Datenbank genauer beschäftigt?

---

Also nix mit Views oder StoredProcs und was moderne Datenbanken noch so anbieten. DATEV liebt die Mainframesteinzeit.

Für EO comfort kann ich sagen: Falsch.

In der Datenbank sind beide Techniken in der Verwendung. Korrekt ist, dass DATEV auf der Clientseite noch mit einer Runtime Auswertungen "aufhübscht". Im wesentlichen sind es aber nur noch die Reports.

---

DATEV und Sicherheit? Ja, was den Zugriffschutz angeht, Betriebssicherheit ist bei DATEV ein sehr stiefmütterlich behandeltes Thema.

---

Das mit der "Betriebssicherheit" hätte ich gern mal genauer erläutert. Denn die liegt nun bei den Anwendern (Kanzlei/Mandantenbetrieb) und dessen beauftragte Techniker.

---

Und ja, die Nutzung des SQL Servers durch DATEV ist tatsächlich auf BTrieve Niveau, etwas Access kommt aber auch vor (EO classic). Schauen Sie sich mal die SQL Paketstatistiken an.

---

Leider auch nicht richtig. Oder zumindest überholt. s.a. auch die Aussage von @Martin_Lederer 

Beste Grüße
Christian Ockenfels

[#23]

Die Aussage bezieht sich wohl eher auf dei "dokument"-basierten Programme, wie die Steuerprogramme, AP, ...

[#24]

---

@chrisocki  schrieb:

Moin @einmalnoch ,

wo kommen denn diese Aussagen her? Haben Sich mal mit der EO-Datenbank genauer beschäftigt?

---

Also nix mit Views oder StoredProcs und was moderne Datenbanken noch so anbieten. DATEV liebt die Mainframesteinzeit.

Für EO comfort kann ich sagen: Falsch.

Jetzt müßte man SEHR genau schauen, wie die "Brot-und-Butter" - Anwendungen realisiert sind.

Nebenher:  Die "Mainframesteinzeit" beherrscht seit Ur-Ur-Zeiten Äquivatente zu "Views", natürlich gibt es auch Trigger uns 'Stored Procedures'.  Nutzt man aber ungern, weil Mainframe-Kunden typischerweise keine Downtimes mögen und Releasewechsel unter laufendem Betrieb "atomar" haben möchten.  Da machen diese beiden Features Höllenprobleme.   Das aber nur am Rande.

---

DATEV und Sicherheit? Ja, was den Zugriffschutz angeht, Betriebssicherheit ist bei DATEV ein sehr stiefmütterlich behandeltes Thema.

---

Das mit der "Betriebssicherheit" hätte ich gern mal genauer erläutert. Denn die liegt nun bei den Anwendern (Kanzlei/Mandantenbetrieb) und dessen beauftragte Techniker.

Die Auswahl der Plattform war eine Idee der DATEV.

Die "Windows-Plattform" an sich ist weit davon entfernt, betriebssicher zu sein.

Mit "AD", "Outlook" und "Exchange" ist m.E. die Grenze von der einfachen zur groben Fahrlässigkeit überschritten.

Man verläßt sich auf Filter und "Virenschutz".  Gleichzeitig ist bekannt, daß u.a. unsere Bundesregierung gefährliche "Zero Day Exploits" aufkauft und für grundgesetzwidrige Zwecke verwendet, anstatt sie publik zu machen.  Man kann sich am A**** abfingern, wann da das eine oder andere "Tierchen" entfleucht.

Insbesondere bei der grünen "Hackback" - Strategie:  Da greife ich dann einen "Server" an und warte in aller Ruhe ab, daß mir die Behörden ihre neuesten "Errungenschaften" zurückschicken.

Jeder preiswerte Kompressor, zur Not einer aus dem Baumarkt, hat minsestens ZWEI dissimilar redundante Sicherungen, zum einen ist es der elektrische Druckschalter, zum anderen ist es ein mechanisches Sicherheitsventil.

Das, was in der Technik "Stand der Technik" ist, das wird in der PC-Technik (und etwas anderes ist der Mist nicht) durch aufgepfropfte Camouflage ersetzt.

Die Auswirkungen können Sie regelmäßig in der Tagespresse lesen.

Das kann man jetzt nicht alles den Kanzleien oder dem Installationspersonal anlasten.

In mittlerweile vierzig Berufsjahren habe ich nie etwas gesehen, das komplexer und komplizierter ist als ein "modernes" Windows.   Sage ich ganz offen:  Die Administration solcher "Farmen" traue ich mir persönlich nicht zu.

Aber ausgerechnet die billigsten Hobbyadmins werden, weil sie so schön preiswert sind, von vielen Dienstleistern rekrutiert und auf die Menschheit losgeschickt.

Aber auch die ehrgeizige Zielsetzung der DATEV, "wir machen es schön benutzerfreundlich", sorgt immer wieder für unschöne Überraschungen.  Wobei ich persönlich meine, daß es in den letzten zwei Jahren sehr viel besser geworden ist.

Aber der wirkliche Kritikpunkt, vor allen Dingen von den engagierten Damen, die in den Kanzleien die "Volumendaten" buchen, ist und bleibt:

"Die Antwortszeiten der Anwendungen sind unterirdich, ich kann schneller buchen als die Maschine meine Daten verarbeiten kann".

Und das trotz "Gold-CPUs", modernsten Flashspeicher, 10-Gigabit-Ethernet, abgeschalteter "Spectre" - Bremse usw., usf..

Wie heißt es so schön:

"Finde den Fehler" ...

Gruß,

[#25]

Moin @Koppelfeld,

---

Die "Windows-Plattform" an sich ist weit davon entfernt, betriebssicher zu sein.

---

Und wer ist schuld? DATEV? Mitnichten. Der Markt bzw. die Nutzer haben/hatten es in der Hand. Und die Entwickler ebenso. 

DATEV war während der DOS-Ära mal auf "Ausflug" zu OS/2. Und? Wurde aus bekannten Gründen nicht angenommen. Und wäre es besser gewesen? Kann wohl keiner sicher behaupten. Zum einem mit MS am Anfang gemeinsam entwickelt und wenn es in die breite Masse gegangen wäre, hätten sich die Spitzbuben genauso dafür interessiert und auch Lücke gefunden. 

---

Mit "AD", "Outlook" und "Exchange" ist m.E. die Grenze von der einfachen zur groben Fahrlässigkeit überschritten.

---

Ist mir auch zu platt. Und eine grobe Fahrlässigkeit zu unterstellen halte ich für ebenso grob fahrlässig. Andere OS haben auch Lücken. Dass diese nicht so massiv ausgenutzt werden, liegt auch wieder in der Marktdurchdringung. Sicher wird in aller Konsequenz KEIN System sein. 

Die Systeme werden von Menschen erfunden, eingerichtet, genutzt und gewartet. Und der Mensch ist als Komponente fehleranfällig. 

---

Man verläßt sich auf Filter und "Virenschutz". 

---

Das kommt auf den entsprechenden Systemberater an. Letztendlich kommt es auf das Gesamtkonzept an und dessen Handhabung. Wenn ich das Konzept in die Schublade lege und dann doch meinen eigenen Stiefel mach, dann muss ich mich über die Konsequenzen nicht wundern.

---

Gleichzeitig ist bekannt, daß u.a. unsere Bundesregierung gefährliche "Zero Day Exploits" aufkauft und für grundgesetzwidrige Zwecke verwendet, anstatt sie publik zu machen.  Man kann sich am A**** abfingern, wann da das eine oder andere "Tierchen" entfleucht.

---

Ich denke mal, dass die bösen Buben nicht auf die Hacks der Bundesregierung warten, denn dann sind sie schon verarmt.... Die haben andere, schnellere und bessere Quellen... 

---

Die Auswirkungen können Sie regelmäßig in der Tagespresse lesen.

---

Ja, und immer wieder menschliches Versagen. Bei Konzept, Umsetzung und Anwendung.

---

Aber ausgerechnet die billigsten Hobbyadmins werden, weil sie so schön preiswert sind, von vielen Dienstleistern rekrutiert und auf die Menschheit losgeschickt.

---

Fehler im Konzept. Fail.

---

Aber der wirkliche Kritikpunkt, vor allen Dingen von den engagierten Damen, die in den Kanzleien die "Volumendaten" buchen, ist und bleibt:

"Die Antwortszeiten der Anwendungen sind unterirdich, ich kann schneller buchen als die Maschine meine Daten verarbeiten kann".

---

Noepp. Kann ich nicht bestätigen. Weder im DATEVasp-Umfeld noch im WTS-Umfeld (inkl. Virtualisierung) noch bei "klassischem" Client-Server-Betrieb.

Finde ich aber zugegeben bei den Umgebungen, die ich dann erbe, weil der "gute Bekannte" wieder versagt...

Und ich buche tatsächlich auch noch selber. Insofern kann ich dazu auch noch eine Aussage machen.

Beste Grüße
Christian Ockenfels

P.S. Ich glaube wir sind mittlerweile meilenweit vom Thema entfernt.

[#26]

Hallo,

---

@chrisocki  schrieb:

Moin @Koppelfeld,

---

Die "Windows-Plattform" an sich ist weit davon entfernt, betriebssicher zu sein.

---

Und wer ist schuld? DATEV? Mitnichten. Der Markt bzw. die Nutzer haben/hatten es in der Hand. Und die Entwickler ebenso. 

DATEV war während der DOS-Ära mal auf "Ausflug" zu OS/2. Und? Wurde aus bekannten Gründen nicht angenommen. Und wäre es besser gewesen? Kann wohl keiner sicher behaupten.

Ganz sicher nicht.  Wir müssen es auch heute ab und zu benutzen, lustigerweise nutzt es IBM als Konsole für seine Server.

DATEV hat seine Anwender aber noch in anderen Schlammlöchern baden lassen, z.B. Novell.

Und schon da hätte klar sein müssen:  Niemals, niemals, NIEMALS eine Anwendung mit einem ganz bestimmten System "verbandeln".   Gab es doch früher auch nicht !

Früher, als wirklich noch einiges besser war, konnte ich auf einer KIENZLE 1200, einer Olivetti A5 oder einer TA 1000, um nur drei Beispiele zu nennen, an ein- und der gleichen Buchhaltung arbeiten.   Dialogverarbeitung?  Auch kein Problem.   Anwendungsprogramm?  Lieferte der Hersteller, DATEV zertifizierte die Schnittstellen.

Die DATEV - SBI ("System zur Bestandsführung und Inventur") - Schnittstelle von KIENZLE stammt von mir, und ja, sie funktionierte mit etwa 10 Buchungen pro Sekunde auf einem Rechner mit 16 KB Hauptspeicher und einem INTEL 8080 mit 2 GHz getaktet.

DATEV war früher der Garant für eine einfache, automatisierbare FiBu, die weithin akzeptiert wurde.

Andere, bspw. SAP, haben ebenfalls frühzeitig mit einem "allgemeinen" Client-Programm begonnen, bspw. dem JAVA-verseuchten "Platin GUI".   Mit "Fiori" ist allerdings etwas sehr Brauchbares entstanden.

Das läuft dann auf jeder Kaffeemühle.   Nur noch EIN Programm, der SAP Client, muß auf einer beliebigen Plattform laufen können.

---

---

Mit "AD", "Outlook" und "Exchange" ist m.E. die Grenze von der einfachen zur groben Fahrlässigkeit überschritten.

---

Ist mir auch zu platt. Und eine grobe Fahrlässigkeit zu unterstellen halte ich für ebenso grob fahrlässig. Andere OS haben auch Lücken. Dass diese nicht so massiv ausgenutzt werden, liegt auch wieder in der Marktdurchdringung.

Es ist doch wumpe, WARUM Schwachstllen massiv ausgenutzt werden.  Entscheidend ist, daß sie ausgenutzt werden und entscheidend ist, daß jeder das weiß.   Da kann man sich auch nicht herausreden, "Ich bin von meinen Beratern falsch informiert worden".  Fragen Sie "Boris", der hat ja jetzt viel Zeit.

Sicher wird in aller Konsequenz KEIN System sein. 

Die Systeme werden von Menschen erfunden, eingerichtet, genutzt und gewartet. Und der Mensch ist als Komponente fehleranfällig.

Ja, aber der Mensch kann merken, wenn er "über seine Verhältnisse lebt".  Zeit meines Lebens bin ich mit schnellen Autos nie klargekommen und habe viele Unfälle verursacht.  Seitdem ich weiß, daß mir die Befähigung zum Fahren im Grenzbereich fehlt, meide ich Risiken und nichts passiert mehr.

Das kann man als "Computeranwender" auch machen, indem man strikt sagt, "HTML" und ähnlicher Quatsch, womöglich noch "ausführbar" oder in zartrosa Fonts mit changierenden Serifen, werden schlicht und einfach genau so abgelehnt wie irgendwelche Bildchen.   Und eine "Vorschau" braucht es auch nicht.

Eine solche Mail, und nur genau so ist sie standardkonform, kann man ganz beliebig oft auf jeder Plattform öffnen, ohne daß etwas "passieren" könnte.

Also:  Man nimmt sich etwas zurück und schon hat man keinen Ärger.

Und wer das nicht tut und "sich auf seine Berater/Experten verläßt", landet in Wandsworth.  Zu recht.

Gleichzeitig ist bekannt, daß u.a. unsere Bundesregierung gefährliche "Zero Day Exploits" aufkauft und für grundgesetzwidrige Zwecke verwendet, anstatt sie publik zu machen.  Man kann sich am A**** abfingern, wann da das eine oder andere "Tierchen" entfleucht.

---

Ich denke mal, dass die bösen Buben nicht auf die Hacks der Bundesregierung warten, denn dann sind sie schon verarmt.... Die haben andere, schnellere und bessere Quellen...

Sie glauben gar nicht, wie schusselig sich gerade Behörden oder gar die Bundeswehr anstellt.  So aus dem CCC - Umfeld bekomme ich da manchmal etwas mit, da liegt man auf dem Boden vor Lachen.   Es tut schon fast weh.   Also, einen haue ich 'raus:   Bundeswehr muß unbedingt nach Somalia.   Die Somalesen, nicht faul, klauen ein paar Mobilfunk-BTS aus dem Westerwald (!) und bauen die im Busch auf.   Der Deutsche Landser, "im Felde unbesiegt", muhahahahahahahahahaha, war natürlich froh, daß er auf einmal "Netz" hatte und plauderte fürderhin alles aus, denn der Somali war selbstredend so schlau, nur als "man in the middle" zu agieren und die gehenden Telephonate nach D weiterzuleiten.   Der Laden hat echt seine "Helikopter-Mutti" verdient.

Wie gesagt, gibt auch Ausnahmen, die "Deutsche Bundesbank" in München konnte ich als kompetent erleben, vor allen Dingen sind da auch richtig kluge junge Frauen im Team.   Das war bislang für mich die leuchtende Ausnahme.

---

@chrisocki  schrieb:

Die Auswirkungen können Sie regelmäßig in der Tagespresse lesen.

---

Ja, und immer wieder menschliches Versagen. Bei Konzept, Umsetzung und Anwendung.

Und deswegen müssen wir die Ansprüche herunterfahren.   Auch die an unsere eigene Leistungsfähigkeit.   Heute VIER Stunden wegen "technischen Fortschritts" sinnlos vertrödelt:   Meine Frau läßt den PIN-Brief zum Onlinebanking zu lange liegen, der Zugang wird invalidiert.   Wir melden uns heute an:  "Sie haben den PIN 3 x falsch eingegeben".  O-keeeh, ich habe den Brief aber gerade erst aufgerissen.   Aaaaaaaber:

Das proaktive "Webinterface" bietet nun die Möglichkeit, mit "Photo-TAN" den Zugang freizuschalten, mit einem chicen farbigen Multikulti - QR-Code.   Gemacht, getan:

"Leider ist Ihr TAN-Gerät noch nicht aktiviert.   Sie können das bequem vom Online-Banking aus erledigen ..." -- Hauptmann von Köpenick Version 4.0.

Also Hotline, wir landen im Ostblock, unterlegter "Comfort Noise Generator".  Nur schade, daß das von modernen Informatikern gestylte "Interactive Voice Response" keine DTMF-Töne erkennt.  Wir senden die nämlich nicht "analog", sondern als "SIP INFO", und so gehört das.  Aber offenbar nicht im Ostblock.   Vielleicht haben die auch "MS Teams".

Naja, gottseidank sind wir ja Hersteller unserer Telephonanlage, kurz eben umkonfiguriert.   Nun können wir uns mit Konto und "Telephon-PIN" anmelden, statt der Verbindung mit dem "Berater" gekt der Kontakt zu Verlust und es folgt ein Sermon an Fragen, wieder gestellt vom Blechtrottel.  Nach Frage 6 habe ich dann aufgelegt, unglaublich, welche Kräfte ein Polycom - Telephonhörer aushält.

Wir sind dann schlußendlich hingefahren.

Der Sachbearbeiter ging auf sein Webinterface und schubste die Maus eine Viertelstunde lang herum, und dann wurde es ihm zu bunt:  Er öffnete ein 3270-Terminal, aktivierte den Zugang und schwupps, konnte meine Frau wieder über ihr Konto verfügen ...

DAS ist das Motto der "Deutschen Bank":  Leistung, die Leiden schafft.

Das muß aufhören.

Aber der wirkliche Kritikpunkt, vor allen Dingen von den engagierten Damen, die in den Kanzleien die "Volumendaten" buchen, ist und bleibt:

"Die Antwortszeiten der Anwendungen sind unterirdich, ich kann schneller buchen als die Maschine meine Daten verarbeiten kann".

---

Noepp. Kann ich nicht bestätigen. Weder im DATEVasp-Umfeld noch im WTS-Umfeld (inkl. Virtualisierung) noch bei "klassischem" Client-Server-Betrieb.

Finde ich aber zugegeben bei den Umgebungen, die ich dann erbe, weil der "gute Bekannte" wieder versagt...

Und ich buche tatsächlich auch noch selber. Insofern kann ich dazu auch noch eine Aussage machen.

Glaube ich Ihnen sofort, ich merke, wenn jemand weiß, wovon er spricht.

Die "Damen", deren Aussagen ich für voll nehme, sind zwar nicht unbedingt Schönheiten, aber geistig flexibel, lernfähig und auch experimentierfreudig.  Macht echt Spaß, und sie bringen richtig Leistung.   Heute nochmal bei einer angerufen:  "Buchen geht ja einigermaßen, aber WEHE, wir nutzen das im Zusammenhang mit 'Belege online'.

Außerdem:  Wir haben es 'im Gefühl', wenn 'die DATEV' 'mal wieder 'hakt'.   Dann geht es wieder für ein paar Stunden".

Die Partnerkanzlei wird von einem "Systemhaus" betreut, und manchmal müssen diese Damen, via RDP und VPN, dort buchen:   "Da ist es noch viel schlimmer".   Und an der WAN-Strecke liegt es 'mal nicht.

In einem anderen Fall (Industriebetrieb, bucht selbst) habe ich auf Anregung des sehr kompetenten Steuerberaters die DATEV-Umgebung von dessen Mitarbeiter (es ist eine Großkanzlei mit gigantisch großer eigener EDV) komplett neu aufsetzen lassen, in der Hoffnung, "den Sch... bist Du erstmal los".   Aus meinem bare metal "1-Server-Modell" machte er ein "Drei-Server-Modell" mit Hyper-V, File, WTS und einem virtualisierten "Windows 10" - Client.  Eigentlich waren es ja vier Server.   Um es ganz klar zu sagen:

Der Mitarbeiter war absolut kompetent und traumwandlerisch sicher im Umgang mit den Anwendungen.  Seriöses Auftreten, hielt seine Zusagen ein.

Es hatte auch alles funktioniert.   Und was sehr teuer, etwa 10.000,--.

Schade nur:   Es war NOCH LANGSAMER.

Haben wir dann irgendwann wieder "geschleift".

Ja, wir sind "off topic", aber ich versuche die Kurve zu bekommen:

Was kann man tun, um DATEV einigermaßen betriebssicher und einigermaßen effizient einzusetzen ?

[#27]

---

@Koppelfeld schrieb: Rechner mit 16 KB Hauptspeicher und einem INTEL 8080 mit 2 GHz getaktet

---

 Haben Sie den 8080 leicht übertaktet?

[#28]

---

@Nutzer_8888  schrieb:

---

@Koppelfeld schrieb: Rechner mit 16 KB Hauptspeicher und einem INTEL 8080 mit 2 GHz getaktet

---

 Haben Sie den 8080 leicht übertaktet?

---

Hallo, Ihre Antwort ist mir durchgegangen.

Du liebe Güte, 2 GHz.   Wo doch früher alles um den Faktor 10³ bis 10⁶ kleiner resp. langsamer war ...

Natürlich waren 2 MHz gemeint und das war schnell genug für den seinerzeit eingesetzten Magnetkernspeicher.   Der lahme Hauptspeicher war ja überhaupt DER Grund für die Einführung der genialen CISC - Architektur, die heute so verschmäht wird.

Danke für den Hinweis!

[#29]

a) "Dateien" sind auch nur Blöcke auf einem Device mit ein paar Metadaten außenrum.. Meistens sogar zusammenhängende Bereiche.. Datenbanken schauen nicht jedes mal nach der file u.s.w. sondern "mappen" die Datei einmal beim starten per memmory mapped i/o typischerweise. Memory Mapped I/O mapped eine Datei z.B. in den virtuellen Adressraum des Prozesses der die Datei mapped.
Der Zugriff ist dann ein Speicherzugriff, erst das Betriebsystem kann dann relativ effizient (je nachdem was der Treiber / Blocklayer unterstützt) auf das physikalische Gerät schreiben.

b) Ja die "Umwege" sind da, am Ende sind das aber alles nur lookups die auf Metadaten im RAM passieren und es wird nur der Block auf dem tatsächlichen Speichergerät angefasst der auch betroffen ist. Das kann gut sein, dass bei den ersten paar Dateizugriffen diese Metadaten erst ins RAM geladen werden müssen, aber wenn Sie mal da sind geht das unglaublich schnell, da ein Schreibzugriff auf ein I/O Geräte (jedenfalls mit klassischen Adaptern wie SATA) Magnituden langsamer ist wie die CPU.. Bei NVMe über PCIe liegen immernoch welten zwischen Memoryzugriff und NVMe über PCIe.

Async I/O

Moderne Speichergeräte sind zudem Multi-Queue fähig, sprich das Betriebsystem kann teilweise bis zu 128 lese und Schreibzugriffe gleichzeitig "in der Schwebe" haben.. Das ist besonders interessant, da man hierüber bessere parallelisierung über CPU Kerne hinweg erreicht.. Moderne Hypervisor verwenden zudem recht effiziente APIs um diese Zugriffe asynchron abzusetzen.. Proxmox mit KVM verwendet in den neueren Versionen io_uring, was komplett asynchron ist.

Physikalisches Gerät direkt in die VM "mappen"

Würde ich nicht machen, da man damit die Vorteile der Virtualisierung verliert, da Resourcen hart einzelnen VMs zugeordnet werden und weder einfach zu skalieren sind noch backups durchzuführen.

Man möchte ja so etwas haben wie Snapshots der Laufwerke um z.B. online-backup durchzuführen. Das selbe mit dem RAM der VM. Ein moderner Hypervisor hält die VM nur wenige uS an um einen Snapshot der Blockdevices zu erzeugen und auf alle memory pages ein "trap" zu setzen, wenn die VM darauf schreibt. Danach wird erst eine Kopie dieser konsistenten Snapshots erzeugt und als Backup weggespeichert. Das würde so nicht funktionieren, wenn da nicht nochmal eine Ebene dazwischen ist.

Zudem wird da auch sowas wie eine "dirty bitmap" gepflegt in der sich gemerkt wird welche Blöcke von der VM überhaupt seit dem letzten Backup geschrieben wurden, dadurch sind inkrementelle Backups um welten schneller, da nur Blöcke kopiert werden müssen die auch zugegriffen wurden.

Thin-Provisioning ist ja auch ein Thema, wenn man es "hart" mapped, wäre immer direkt alles belegt was der VM zugewiesen ist an Speicherplatz.

Das die Festplatten in der Hardware stecken auf der der Hypervisor läuft ist zwar verbreitet aber auch nicht zwingend erforderlich / nicht optimal. Storage Virtualisierung ist ja auch ein Thema, warum nicht einen großen redundanten Blockstorage der zwei "Controller" hat und somit ausfallsicher ist? Dieser wird dann per 10/100GBit Ethernet redudant über Kreuz an die Hypervisor angebunden (im "Enterprise" Umfeld benutzt man da auch gerne FibreChannel).

Vorteil: Ausfallsicherheit.. Alle Hypervisor Server können jede VM starten, Live Migration erfordert kein migrieren des Storage, da ja beide Server Zugriff auf den gemeinsamen Storage haben.
Die einzelnen Storage Arrays kann man per "NVMe over Fabrics" an die Storage Controller anbinden (falls man NVME verwendet).

Möchte man keine komplette eigene Storage Infrastruktur kann man auch mit bestehenden Hypervisorn mit eingebauten Platten Hochverfügbarkeit erreichen und zwar über DRBD, da werden praktisch die Schreibzugriffe auf Blockdevice Ebene über Netzwerk zwischen den beiden Kisten hin und her synchronisiert. Fällt einer der Knoten aus, kann der andere Knoten die VMs einfach automatisiert bei sich starten und nach ein paar Sekunden ist man wieder "online".

Würde ich eine größere Virtualisierungsinfrastruktur aufbauen, würde ich vermutlich aber zu einem CEPH Cluster greifen. -> Das ist auch was die Hyperscaler tun, mit ihrer eigenen Implementierung so eines Clusters.

Bei unserer Installation verwende ich ZFS im raidz2, für VM Blockdevices werden hier zvols verwenden, sprich keine Dateien. ZFS ist sehr flexibel und hat eine relativ ausgefeilte Caching infrastruktur lesend wie schreibend. Man kann z.B. eine SSD oder ein Optane Drive als Lesecache verwenden (L2ARC) und ein ein pärchen von zwei schnellen Optane Laufwerken als Schreibcache (ZIL).. Lesezugriffe der VMs gehen dann erst an den RAMcache, dann den SSD-Cache und erst wenn es in beiden nicht gefunden wird auf die evtl. langsamen Platten. Schreibzugriffe sind wie auf SSD schreiben, da sobald Sie im ZIL stehen (SSD Schreibcache) kriegt die VM das "ok" zurück.
Ich habe mal einen Hypervisor mit 5400 rpm SMR Festplatten und Optane Caches gebaut.. Es fühlt sich so an, als würde man auf einer SSD schaffen, da einfach 99% der Blöcke die die VM zugreift im Cache liegen. Das "workingset" an Daten ist meist relativ klein.. 80-90% der Sachen die da rumliegen werden nahezu nie gelesen bei typischen Windows VMs.

ZFS schützt zudem gegen "Bitrot" durch Checksumen.. Bei normalen Festplatten und SSDs können Bits "kippen" bei den heutigen Größen der Laufwerke liegt das durchaus im Bereich des möglichen, bei einem klassischen RAID1 weiß man im Zweifel nicht welche der beiden Kopien die richtige ist, wenn ein Bit kippt.

Heute macht man eh nur noch "Flash-only".. So eine 1,92TB PCIE4 Enterprise SSD kostet gerade mal noch 350€, (Samsung PM9A3), die kann irgendwie 7Gbyte/sec lesen und 5 schreiben oder sowas synchron und schafft knapp eine Million IOPS.

Festplatten sind doch eh nur noch für Backup und Archivierungssysteme interessant..

Kurzum: Möchte man nicht die Virtualisierung verlieren vom Storage, sollte man sowas wie ZFS verwenden oder einen dedizierten Storage cluster wie Ceph. Für Hochverfügbarkeit entweder Ceph oder DRBD ansonsten natürlich ein RAID (zfs hat das integriert).

Proxmox

Benutze ich selber kann ich sehr empfehlen, denn man kriegt direkt so Sachen wie:

- Snapshoting

- Live Migration

- Inkrementelle Backups

- Storage Virtualisierung

- Hochverfügbarer Cluster einfach damit zu realisieren und kostenlos dabei

- (Debian) Linux basiert

- Gute Performance, da breiter Hardware Support und KVM ziemlich schlank / optimiert ist. Die großen Cloudprovider verwenden auch alle KVM (Amazon, Microsoft / Azure, Google, Tencent, Alibaba u.s.w.) Amazon hat er kürzlich dazu gewechselt.

Netzwerk Virtualisierung

Das ist heutzutage nicht mehr das Problem, da über IOMMU und Hardwarefähigkeiten in der Netzwerkkarte.
Die Netzwerkkarte wird vom Hypervisor so konfiguriert, dass Sie Pakete an bestimmte MAC-Adressen direkt per DMA in einen Speicherbereich ohne Beteiligung des Hauptprozessor schreibt. Die VM kriegt diesen Speicherbereich einfach in ihren reingemapped und kann direkt daraus lesen. Sprich der "Hypervisor" hat die Daten nie in der Hand.. Der liest nur irgendwelche Counter aus der Netzwerkkarte aus um zu sehen wie viele Pakete wer transportiert hat für die Statistik.

Es gibt sogar Anwendungen bei denen RAM-Zugriffe auf entferne Maschinen ohne Betriebsystembeteiligung stattfinden können.. RoCE (RDMA over Converged Ethernet).

Der Overhead für die Netzwerkvirtualisierung ist minimal, vor allem im Vergleich zu den Laufzeiten die man auf dem physikalischen Medium hat. Gerade "bessere" Netzwerkkarten können viel davon auch in Hardware abbilden, deswegen kostet halt so ne Karte auch 200-300€ stattt halt nur 5 wie die Realtek bei Aliexpress, deren Chip nichtmal TCP Offloading kann (berechnen der TCP Checksummen in Hardware).

Open Source

Dank OpenSource Software und der Beteiligung der großen Hyperscaler, kann man heutzutage für um die 10-15k€ Hardware kaufen und kostenlose Software verwenden um einen Hoch verfügbaren Virtualisierungscluster zu bauen. Ich finde man kann sich nicht beklagen.
Würde man das mit Enterprise Hardware / Software machen, also z.B. mit VMWare und den ganzen modulen die man für die Hochverfügbarkeit braucht + einem Storage Array, ist man eher bei 100k€+ denke ich..

[#30]

Magnetspeicher? Viel zu modern!

Delay-line Memory ist das Ding welches man braucht.

- Kein random access (modernes Zeug was Niemand braucht)

- Entschleunigung, da man auf seine Daten warten muss

- Daten sind weg, oder man erzeugt schöne neue, wenn man mal ordentlich gegen das Gehäuse schlägt.

- Man kann die Daten fühlen, wenn man an den Draht greift (oder die Glasröhre mit dem Quecksilber)

Danach wurde es doch nicht besser, mit diesen 1-Bit Flipflops aus Vakuum-Röhren die so groß wie ein Ziegelstein waren.