Welche Hard- und Software ist für einen prof. Firebirdserver notwendig?

[Chemiker]

Hallo,

der FB-Server soll in eine virtuelle Maschine laufen, es soll täglich ein Backup erstellt werden.
Er soll mit ca. 20 Usern verbunden werden.

Bis bald Chemiker

[haentschman]

Hallo... 8-)

meiner bescheidenen Meinung nach ist die Hardwareanforderung nicht besonders hoch. Da bleibt wohl das Netzwerk der Flaschenhals. Anders sieht es aus wenn die Datenbank einen Großteil der Programmlogik erledigt bzw. wie komplex die Abfragen sind.

Persönlich bin ich eher der Freund von "das was er am besten kann soll er machen". Datenbank speichert Daten, Report druckt, Programm ist das Gehirn.

[p80286]

Ich denke, Du weißt selbst, daß Deine Beschreibung ein wenig unspezifisch ist.
Wir haben z.b. einen stinknormalen Lenovo (2Kerne,2GB,XP-prof) Arbeitsplatzrechner für 30 Nutzer im Betrieb.
Allerdings sind durchn. nur 2-3 Benutzer gleichzeitig aktiv.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von Chemiker (Beitrag 1178760)

Er soll mit ca. 20 Usern verbunden werden.

Arbeiten die immer gleichzeitig?
Wieviel Inserts pro Tag/Stunde/Minute werden anstehen?
Wiviele Abfragen pro Tag/Stunde/Minute?
Wie groß wird die Datenbank werden? MB/GB/TB-Bereich?

[Bummi]

@haentschman
Eine "intelligente" Datenbank, bzw. auch ein Middeltier sind IMHO bezüglich der Datenintegrität und der durchgängigen Durchsetzung von Anforderungen, auch beim Zugriff durch gegf. später hinzukommende fremde Clientanwendungen bei größeren Projekten unabdingbar. Hier halte ich Trigger/Rechte und Prozeduren/Function(s)/Tables für die am einfachsten zu implementierenden Regelwerke. (Normale Anforderungen wie Normalisierung/ForeinKeys etc. betrachte ich hierbei als selbstverständlich).

[Furtbichler]

Eine VM ist imho keine gute Idee, denn die Netzwerklast wird hier ein Problem werden.

Für eine genaue Abschätzung benötigt man jedoch die von Bernhard angefragten Informationen.

[Bummi]

@Furtbichler

ich war auch erst (entsetzt) skeptisch als einige unserer Großkunden auf virtuelle Datenbankserver umgestellte haben. Musste meine Meinung aber mittlerweile revidieren, bei entsprechender Konfiguration sind die Teile doch recht leistungsfähig (und schnell an neue Anforderungen angepasst).

[haentschman]

Zitat:

Hier halte ich Trigger/Rechte und Prozeduren/Function(s)/Tables für die am einfachsten zu implementierenden Regelwerke. (Normale Anforderungen wie Normalisierung/ForeinKeys etc. betrachte ich hierbei als selbstverständlich).

... da sind wir uns einig, daß das normale Härte ist. (Datenintegrität) :wink: Ich meinte, daß die Datenbank nicht unbedingt für das Aufarbeiten von riesigen Datenmengen (Berechnungen etc.) herangezogen wird. Wenn das dann 20 Clients gleichzeitig machen ist schnell Schluß. Die 20 Berechnungen auf den jeweiligen Clienten fallen da nicht so ins Gewicht.

[Bummi]

hängt von der betroffenen Datenmenge ab, vor ich hier GB's über Netz ziehe wird in Prozeduren berechnet und die (kleine) Ergebnismenge geliefert. (rein persönliche Äußerung)
(hinzufügen muss ich dass ich mit Firebird so gut wie keine Erfahrung habe)

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1178776)

Ich meinte, daß die Datenbank nicht unbedingt für das Aufarbeiten von riesigen Datenmengen (Berechnungen etc.) herangezogen wird.
...
Die 20 Berechnungen auf den jeweiligen Clienten fallen da nicht so ins Gewicht.

"Riesig"? Wenn Du ein normales Count oder ein paar Sum's auf dem Client ausführen willst, mußt Du erst die Daten über die Leitung quälen, da ist dann ganz schnell Schluß mit lustig.

Meiner Meinung nach ist der DB-Server genau dafür zuständig.

Gruß
K-H

[haentschman]

ok... :wink: Ich meine nicht normale Aggregatfunktionen. Das wäre ja auch nicht Sinn der Sache.

mal ganz bescheuert:

Man kann eine SP anlegen mit einer Milionenschleife die Daten aus Tabellen holt, berechnet und das Ergebnis wieder zwischen den Tabellen hin und her schaufelt...was auch immer. Ich lasse mich gern belehren, aber imho ist das eher kontraproduktiv und nimmt Leistung für andere weg. Erst recht wenn das mehrere tun.

[Bummi]

wenn Du mit relativ geringen Datenmengen komplexe Berechnungen anstellst gebe ich Dir Recht, die nach meinen Erfahrungen üblichen Anforderungen beinhalten aber Berechnungen mit sehr großen Datenmengen un relativ kleinen Ergebnismengen.

[haentschman]

Zitat:

wenn Du mit relativ geringen Datenmengen komplexe Berechnungen anstellst

...genau das meinte ich. Letztens bleibt es eine von Fall zu Fall Entscheidung.

[Chemiker]

Hallo,

@haentschman: Das Netz sollte kein Problem sein ist erst vor 2 Jahren erneuert worden.

@p80286: XP-Prof. läuft zurzeit, aber es können nicht mehr als 10 Usern gleichzeitig arbeiten.

@Bernhard Geyer:

Zitat:

Arbeiten die immer gleichzeitig?

Über 10 wollen immer gleichzeitig arbeiten.

Zitat:

Wieviel Inserts pro Tag/Stunde/Minute werden anstehen?

100 Inserts pro Minute; können mit der Zeit noch mehr werden.

Zitat:

Wiviele Abfragen pro Tag/Stunde/Minute?

Alle 3 Minuten 1 Abfrage möglich, dass ist der max. Wert wird eher weniger sein.

Zitat:

Wie groß wird die Datenbank werden? MB/GB/TB-Bereich?

Zurzeit ist sie ca. 12 GB groß.
Das ist das was schon vorhanden ist, es soll aber noch 2 weitere Anwendungen (die noch in der Entwicklung sind) auch das Grundlage den FB-Server haben.
@Furtbichler: Die VM ist von unseren Admin vorgeschlagen worden.
@Bummi:

Zitat:

ich war auch erst (entsetzt) skeptisch als einige unserer Großkunden auf virtuelle Datenbankserver umgestellte haben. Musste meine Meinung aber mittlerweile revidieren, bei entsprechender Konfiguration sind die Teile doch recht leistungsfähig (und schnell an neue Anforderungen angepasst).

Welche Software habt ihr dafür verwendet?

Bis bald Chemiker

[Furtbichler]

Also eine VM (um das Thema nochmals aufzugreifen) hat bei einem Kunden zum kompletten Zusammenbruch der DB geführt, einfach weil tierisch viele Daten übers Netz in die DB geblasen werden und die VM-Umsetzung des Netzwerks nun einmal Overhead kostet.

Bei der prognostizierten Performance von knapp 2 Operationen pro Sekunde wird dieses Limit jedoch aller Vorausicht nach nicht erreicht werden.

Ich würde grundsätzlich einem DB-Server so viel CPU-Power und RAM wie irgend möglich spendieren, natürlich in Abwägung der zu erwartenden Arbeiten. So eine DB ist ein Numbercruncher, nur eben nicht mit FP, sondern mit Integerwerten (Das Aggregieren von FP-Feldern mal ausgenommen, aber das fällt nicht ins Gewicht).

Mit handelsüblicher Mittelklasseserverhardware fährt man i.A. sehr gut. Wir merken bei Neukunden sehr schnell, das es mit einer DB-Anwendung nicht getan ist, und dann ist es praktisch, beim DB-Server nicht gespart zu haben.

[Sir Rufo]

Also für eine VM spricht auf jeden Fall schon mal die Möglichkeit der einfachen Skalierung, 24/7 Betrieb bei einer sehr hohen Verfügbarkeit, nahezu hardware-unabhängig (Portierung auf neue Hardware), etc.

ABER, das gilt natürlich nur, wenn man darunter auch die richtige Hardware laufen hat, die dafür auch gedacht ist. Gerade beim Thema Festplattenzugriffe oder Netzwerk (wie ja schon angesprochen wurde) wird es schnell sehr teuer, wenn dort die Performance für mehr als eine VM hoch sein muss/soll und/oder Redundanz gefordert ist.

Somit kann es wesentlich kostengünstiger sein, dafür einen eigenständigen Rechner zu nehmen.
Im Falle eines Hardwaredefekts ist man allerdings mit der Wiederherstellung idR langsamer als mit einer (vernünftigen) VM Umgebung.

Es kommt wie immer auf den Geldbeutel und den Einsatzzweck an.

[Bummi]

Microsofts Hyper-V auf fetten HP - Servern....

[Furtbichler]

Interessant, wie sehr die Erfahrungen mit VM und DB-Umfeld divergieren.

[rwachtel]

Zitat:

Zitat von Bummi (Beitrag 1178792)

Microsofts Hyper-V auf fetten HP - Servern....

...oder eines der entsprechenden Pendants der anderen Virtualisierungs-Experten auf entsprechend ausgerüsteten Systemen (und damit meine ich garantiert keine Einsteiger-Server).

Die von Furtbichler geschilderten Probleme sind meiner Erfahrung nach mit ziemlicher Sicherheit auf ungeeignet konfigurierte Virtualisierungen auf ungeeigneter Hardware durch unerfahrene Systemadministratoren zurückzuführen (ja, es gibt absolute Spezialisten für die Einrichtung und den Betrieb von virtuellen Servern) respektive die beliebige Kombination der genannten Aspekte.

[gsh]

Wir haben einige Datenbanken virtuell und ein paar auf Hardware.
Mit Firebird hab ich zwar keine Erfahrungen aber zumindest bei MSSQL ist mir aufgefallen das diese Datenbank komplexere Abfragen wesentlich schneller (viel mehr als doppelt so schnell) beantwortet wenn diese zwei Kerne zugewissen bekommt (auch wenn sie einen nicht vollständig ausnutzt). Dies kann aber einfach eine eigenheit von MSSQL sein. In jeden Fall sollte man trotzdem bei virtuellen Servern immer zuerst mit einen Single Core anfangen und nur wenn es nötig ist mehr Kerne zuweisen (wegen den Zeitschlitzen des Hosts).

Ram ist eigentlich eher ein kritischer Faktor bei Datenbanken. Ich finde die Angabe von dir (100 Inserts aber nur 0,3 Abfragen pro Minute) nur etwas kommisch für eine Datenbank. Normal sind eher 50-95% Read, wenn nicht sogar 99% (z.b. Webserver DB) aber das hängt natürlich stark von der Anwendung ab. Wenn du wirklich nur 0,3% Read hast bringt dir viel RAM nur begrenzt etwas und somit behaupte ich einfach mal das du mit 2 bis 4GB RAM genug haben solltest.

Bei einem 0,3% Read Faktor ist Platten Performance bzw. IOs viel wichtiger. SSDs wären perfekt für dich, leider sind diese im Enterprise Sektor noch sehr kostspielig. Ansonsten sollte zumindest ein Server mit einem vernüftigen RAID-Controller+Write Cache dahinter stehen, damit du zumindest Write-Back zur Verfügung hast.

Bemerkung am Rande: XP ist kein Server Betriebssytem ... dafür gibts Windows Server 2003 bzw. 2008

[Furtbichler]

Zitat:

Zitat von rwachtel (Beitrag 1178816)

Die von Furtbichler geschilderten Probleme sind meiner Erfahrung nach mit ziemlicher Sicherheit auf ungeeignet konfigurierte Virtualisierungen auf ungeeigneter Hardware durch unerfahrene Systemadministratoren zurückzuführen.

Dazu tendiere ich mittlerweile auch.

[exilant]

Meine Konfiguration:

2 X Corei5, 8GB, 2 X 500GB RAID 1, je 2 X GBit Ethernet,
Ubuntu 12.04 LTS,
Firebird 2.5

Die Server sind via eth0 im Firmensubnetz und bilden mit eth1 ein eigenes Subnetz.

Datenbank > 30GB, Mindestens 25 User, Peak > 50 User


Keine Performance Probleme.

Per Cron wird von morgens 06:00 bis abends 23:00 alle drei Stunden eine Sicherung per gbak angestoßen, die gbk Sicherung auf wird auf Server zwei kopiert, jede zweite wird dort mittels gbak restored.
Das ist nicht wirklich hochverfügbar, aber läuft hier nach ähnlichem Schema seit vielen Jahren. Die Server tausche ich alle drei Jahre aus.
Den Datenverlust von max. drei Stunden sind wir bereit hinzunehmen, ist aber noch nicht passiert. Dafür haben wir ein ausgezeichnetes Preis/Leistungsverhältnis.

[vagtler]

Zitat:

Zitat von exilant (Beitrag 1178845)

[...] läuft hier nach ähnlichem Schema seit vielen Jahren. Die Server tausche ich alle drei Jahre aus. [...]

Ja, so hört sich das auch an: antiquarischer Serverbetrieb wie im letzten Jahrtausend. Wir leben in Zeiten von Virtualisierung und Cloud-Systemen.

[mkinzler]

Zitat:

Zitat von vagtler (Beitrag 1178849)

Zitat:

Zitat von exilant (Beitrag 1178845)

[...] läuft hier nach ähnlichem Schema seit vielen Jahren. Die Server tausche ich alle drei Jahre aus. [...]

Ja, so hört sich das auch an: antiquarischer Serverbetrieb wie im letzten Jahrtausend. Wir leben in Zeiten von Virtualisierung und Cloud-Systemen.

Und auf diese setzt man als "moderner" It-ler dann ohne jegliche Reflektion?

[vagtler]

Zitat:

Zitat von mkinzler (Beitrag 1178850)

Und auf diese setzt man als "moderner" It-ler dann ohne jegliche Reflektion?

Habe ich das geschrieben?

Allerdings lässt der dargelegte konservative Betriebsprozess gerade die von Dir geforderte Reflektion (ganz besonders im Hinblick auf einen kontinuierlichen Verbesserungsprozess) gänzlich vermissen.

[Sir Rufo]

Zitat:

Zitat von vagtler (Beitrag 1178853)

Zitat:

Zitat von mkinzler (Beitrag 1178850)

Und auf diese setzt man als "moderner" It-ler dann ohne jegliche Reflektion?

Habe ich das geschrieben?

Allerdings lässt der dargelegte konservative Betriebsprozess gerade die von Dir geforderte Reflektion (ganz besonders im Hinblick auf einen kontinuierlichen Verbesserungsprozess) gänzlich vermissen.

Wieso liest du aus der Aussage exilant, dass darüber nicht nachgedacht wurde, es aber aus Kostengründen nicht in Betracht kam?
Vor allem, wo er doch schreibt, dass er ein sehr gutes Preis-/Leistungsverhältnis hat.

[exilant]

Zitat:

Zitat von vagtler (Beitrag 1178849)

Ja, so hört sich das auch an: antiquarischer Serverbetrieb wie im letzten Jahrtausend. Wir leben in Zeiten von Virtualisierung und Cloud-Systemen.

Vermutlich meintest du "antiquiert". Was soll's. Es läuft, und läuft, und läuft, und läuft...
Viel Spass in der Cloud.

[Bummi]

wer traut der Cloud:?:

[Bernhard Geyer]

Zitat:

Zitat von Bummi (Beitrag 1178860)

wer traut der Cloud:?:

Solang es eine Private Cloud ist :-)

[exilant]

Zitat:

Zitat von Sir Rufo (Beitrag 1178856)

Wieso liest du aus der Aussage exilant, dass darüber nicht nachgedacht wurde, es aber aus Kostengründen nicht in Betracht kam?
Vor allem, wo er doch schreibt, dass er ein sehr gutes Preis-/Leistungsverhältnis hat.

Betriebssystem Lizenzkosten 0, Datenbank Lizenzkosten 0, eine Handvoll Shell Scripte < 1 Tag für die Erstellung, Server Hardware ca. 1.100 pro Server.
Administrationsaufwand < 5 Min. am Tag (nur Emails checken)
Macht weniger als 80 Teuros Betriebskosten im Monat.
Dazu kommen nur noch Stromkosten sowie anteilig die Kosten der USV und der Klimatisierung. Ein gewichtiges Argument für einen kleinen Mittelstädler in der sehr schwierigen Textilbranche.

[vagtler]

Zitat:

Zitat von Sir Rufo (Beitrag 1178856)

Wieso liest du aus der Aussage exilant, dass darüber nicht nachgedacht wurde, es aber aus Kostengründen nicht in Betracht kam? [...]

Alleine die erforderliche "Handarbeit" bei dem regelmäßigen Austausch der Hardware würde eine virtualisierte Lösung wahrscheinlich schon in der ersten Wirkperiode amotisieren. exilant hat meinen Eindruck durch seine Kostenaufstellung nur untermauert - da ist im größten Kostenfaktor Einsparungspotential sicherlich im zweistelligen Prozentbereich vorhanden.

Tatsächlich konnten *alle* unsere Kunden, die auf virtuelle (Datenbank-)Server umgestellt haben (und das sind mittlerweile weit über 500), ihre Kosten reduzieren. Dazu gehört natürlich eine betriebswirtschaftlich umfassende Betrachtungsweise.

Wobei wir als reines Softwarehaus diese Umstellungen weder vorgeben noch betreuen.

Zitat:

Zitat von exilant (Beitrag 1178858)

Vermutlich meintest du "antiquiert". [...]

Stimmt. Richtig gedacht aber falsch geschrieben...

Zitat:

[...] Viel Spass in der Cloud.

Ich schrieb nur, dass wir in Zeiten von Virtualisierung und Cloud-Systemen leben. Ich sagte weder, dass die Cloud der Heilsbringer ist noch dass ich den Einsatz empfehlen würde.

[Furtbichler]

Den Riesenvorteil einer VM habe ich noch nicht begriffen. Ich erkenne nur einen Vorteil:
[vorteil]
Ein VM-System kann schnell auf einen neuen Rechner kopieren werden.
[/vortei]

Das man gefälligst im 21.Jahrhundert virtualisieren sollte, ist kein Argument.

Welche Vorteile habe ich denn noch? Schneller wirds auf keinen Fall, nur langsamer.

Und billiger kanns auch nicht sein, denn Hardware und Lizenzen benötige ich sowieso.

[Sir Rufo]

Da wären noch die bessere Ausfallsicherheit, dynamische Leistungsverteilung, Ressourcenteilung zu nennen (das fällt mir spontan dazu ein)

EDIT: Ach ja, ich spreche hier von einem VM-Center und keinem Kinderspielzeug ;)

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1178897)

Das man gefälligst im 21.Jahrhundert virtualisieren sollte, ist kein Argument.

Naja, soo neu ist diese Technik schließlich auch nicht IBM-Mainframes beherschten diese Technik schon im letzten Jahrhundert.

Ein weiterer Vorteil die Skalierung.

Zitat:

Zitat von Sir Rufo (Beitrag 1178907)

Ach ja, ich spreche hier von einem VM-Center und keinem Kinderspielzeug ;)

Es ist halt die Frage ob es gewünscht ist, daß mehrere DB's sich einen Phys. Server teilen dürfen.
Alleine aus Gründen der Vertraulichkeit denken da viele Entscheidungsträger "antiquiert".

Gruß
K-H

[Furtbichler]

Zitat:

Zitat von Sir Rufo (Beitrag 1178907)

Da wären noch die bessere Ausfallsicherheit, dynamische Leistungsverteilung, Ressourcenteilung zu nennen (das fällt mir spontan dazu ein)

EDIT: Ach ja, ich spreche hier von einem VM-Center und keinem Kinderspielzeug ;)

Ach so: Sozusagen eine "virtuelle Clusterlösung"? Aber billiger isses nicht, sondern nur flexibler. Und es lohnt sich nur, wenn ich mehrere DBs hosten muss.

Zitat:

Zitat von p80286 (Beitrag 1178915)

Ein weiterer Vorteil die Skalierung.

Verstehe ich nicht. Was will man da skalieren? Wenn die Hardware zu lahm ist, muss ich sowieso einen neuen PC kaufen und da greift nur Vorteil #1: Schneller neu aufsetzen.

Seid mir nicht böse, wenn ich eure Erfahrung hinterfrage, aber ich wills verstehen.

[vagtler]

Zitat:

Zitat von Furtbichler (Beitrag 1178917)

[...] Verstehe ich nicht. Was will man da skalieren? Wenn die Hardware zu lahm ist, muss ich sowieso einen neuen PC kaufen und da greift nur Vorteil #1: Schneller neu aufsetzen. [...]

Naja, nicht ganz: die virtuelle Maschine braucht einen weiteren Prozessor(kern)? Kein Probleme - dann konfiguriere ich der Maschine noch einen Prozessor(kern) hinzu.

Ich habe keinen Prozessor (resp. -kern) mehr zur Verfügung? Kein Problem, dann kaufe ich halt einen neuen Prozessor oder ein neues Blade.

Das gilt ebenso für RAM.

Ein Downscaling ist dadurch natürlich auch kinderleicht - so kann ich die Ressourcen z.B. für besondere Anforderungen zeitlich beschränkt erhöhen.

Durch das mögliche Teilen von Ressourcen mit anderen virtuellen Maschinen können dann ganz schnell Szenarien aufgesetzt werden, die zu einer erheblichen Kosteneinsparung des Serverbetriebs führen können.

[shmia]

Zitat:

Zitat von Furtbichler (Beitrag 1178917)

Zitat:

Zitat von p80286 (Beitrag 1178915)

Ein weiterer Vorteil die Skalierung.

Verstehe ich nicht. Was will man da skalieren?

Stell Dir vor, du hast einen schnellen Server mit 16 CPUs und 128GB RAM. 8-)
Dann kommt eine Abteilung zur IT und braucht einen SQL-Server und/oder Web-Server fürs Intranet.
Kein Problem, innerhalb 15 Min. gibt's einen neuen virtuellen Server (Windows 2008, 2GB RAM, 1 CPU).
Ein Woche später gibt's ein Gejammer: "der Server ist zu langsam".
Server kurz runterfahren, 4GB RAM sowie 2 CPUs zuteilen und neu starten - fertig in 3 Minuten.

Das Gastbetriebssystem bekommt nicht immer 4GB sonder nur maximal 4GB zugeteilt.
Bei vielen virtuellen Maschinen ergibt sich dann der Vorteil, dass statistisch nicht jedes Gastsystem seinen Speicher sowie CPU-Leistung voll ausschöpft.
Damit kann der teuere, aber leistungsfahige Hostrechner besser ausgelastet werden wie viele schwächere, aber billigere physische Rechner.

[mjustin]

Zitat:

Zitat von Furtbichler (Beitrag 1178917)

Zitat:

Zitat von p80286 (Beitrag 1178915)

Ein weiterer Vorteil die Skalierung.

Verstehe ich nicht. Was will man da skalieren? Wenn die Hardware zu lahm ist, muss ich sowieso einen neuen PC kaufen und da greift nur Vorteil #1: Schneller neu aufsetzen.

Beispiel aus der Praxis: beim Betrieb von Datenbank und einem oder mehreren Web- und Anwendungsservern, alle auf einem gemeinsamen Host-System, kann man die verfügbare Performance auf die Systeme verteilen, solange die Hardware mitspielt.

Wenn man zum Beispiel anfangs 50 Prozent der CPU Geschwindigkeit (oder der RAM Zuteilung) für die Datenbank-VM und 50 Prozent den anderen VMs zugeteilt hat, und sich später herausstellt dass die Datenbank mehr oder weniger Leistung benötigt, kann man, wenn die Gesamtleistung ausreicht durch Umverteilung den Kauf neuer Hardware vermeiden.

Die Gesamt-Leistungsgrenze ist natürlich immer eine Grenze. Skalierbar in diesem Fall heisst: man kann - wenn die Anforderungen sich ändern - durch Hinzufügen virtueller Kerne, höhere Anteile an Gesamt-CPU Leistung und Geamt-RAM Ausstattung eine VM leichter skalieren als wenn man es physikalisch tun müsste.

... ups, roten Kasten ignoriert :oops:

[Furtbichler]

Ergo: Nutzen = 0, wenn eh nur eine DB/Anwendung vorhanden ist. Bei größeren Netzwerken macht sich dann die Flexibilität bemerkbar.

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1178934)

Ergo: Nutzen = 0, wenn eh nur eine DB/Anwendung vorhanden ist. Bei größeren Netzwerken macht sich dann die Flexibilität bemerkbar.

Mit dem Netzwerk hat dies erst einmal nichts zu tun.
Aber Du hast natürlich Recht, wenn es nur um eine Db/Anwendung geht brauchst Du keine VM.

Gruß
K-H