Windows Server oder NAS?

t-6 schrieb:
RalphS meint wohl eher, dass der Aufwand für diese kleine Geschichte hier etwas übertrieben wäre.
Seh ich nicht so. DB und Fileserver könnten Linux VMs werden und Anwendungs und DC Windows. Damit halten sich die benötigten Windows Lizenzen im Rahmen und als unterbau könnte man einen ESXi nehmen oder vergleichbar + NAS für Backup.
 
Hm? Ich bin nicht sicher, ob das, was Ralph meinte auch so durchgekommen ist, egal wie "richtig" oder "falsch" es gewesen sein mag. :confused_alt:

  • Ich hab hier selber eine Weile einen einzelnen Server betrieben in einer ähnlichen Konfiguration wie vorgeschlagen.
  • Host, Fbsd.
  • HW, Xeon E3 1271 (4c8t) + 32GB RAM.
  • VMs, 1x DC, 1x DBMS, 1x Application + 1x Debian-Maschine zum Testen.
  • Anwender, einer. Ich. ^_^

Ergebnis, Datenbank am Krebsen, DC okay, Application mehr tot als nicht, Debian-Maschine "normal", aber lief ja auch nicht wirklich was da.

DBMS will IO. Also zwei SSDs gekauft, Mirror drauf, DBMS auf den Mirror. Besser, aber nicht viel besser.

Habe das DBMS dann rausgeworfen auf ein dediziertes Blech. Nun geht es.

Für acht Anwender? Und dann produktiv? Nie im Leben.
 
Die Anzahl der CPU-Kerne ist die unkritischste Grenze die man haben kann. Auch vCPUs langweilen sich die meiste Zeit, daher kann man die echten Kerne massiv überbuchen. Das traut sich nur kaum jemand. In aller Regel gehen einem erst der RAM oder die IOPS aus.
 
Ich habe jetzt eine DS218 als Fileserver installiert + plus nächtlichem Backup auf USB-Platte + plus wöchentlichen Backup auf zweite USB-Platte (die zweite ist nur während des Backups angeschlossen und befindet sich sonst außerhalb des Büros). Bin mit der Lösung soweit zufrieden. Danke für die Anregungen!
 
Ich hoffe du hast BTRFS als Dateisystem gewählt, dann kannst du dich nämlich mal mit Snapshot & Replication beschäftigen. Auch kannst du dir zB eine zweite DS218 (oder anderes Modell mit BTRFS) kaufen und die Schnappschüsse parallel auf dieses NAS erstellen lassen. Dann hast du die Daten schonmal "heiß" dupliziert verfügbar. Wenn dein Backup ausgebaut werden soll kannst du dir RDX ansehen, je nach Datenmenge ist das finanziell sehr ansprechend.

PS: USV ist dran? Ein kleines Modell wäre APC Back-UPS 700VA Schuko. Erstmal besser als gar nichts. Das NAS kann auch als USV-Server für andere Synology NAS dienen.
 
Zuletzt bearbeitet:
RalphS schrieb:
Hm? Ich bin nicht sicher, ob das, was Ralph meinte auch so durchgekommen ist, egal wie "richtig" oder "falsch" es gewesen sein mag. :confused_alt:

  • Ich hab hier selber eine Weile einen einzelnen Server betrieben in einer ähnlichen Konfiguration wie vorgeschlagen.
  • Host, Fbsd.
  • HW, Xeon E3 1271 (4c8t) + 32GB RAM.
  • VMs, 1x DC, 1x DBMS, 1x Application + 1x Debian-Maschine zum Testen.
  • Anwender, einer. Ich. ^_^

Ergebnis, Datenbank am Krebsen, DC okay, Application mehr tot als nicht, Debian-Maschine "normal", aber lief ja auch nicht wirklich was da.

DBMS will IO. Also zwei SSDs gekauft, Mirror drauf, DBMS auf den Mirror. Besser, aber nicht viel besser.

Habe das DBMS dann rausgeworfen auf ein dediziertes Blech. Nun geht es.

Für acht Anwender? Und dann produktiv? Nie im Leben.

Was für 1 DBMS war denn am Krebsen?
 
Ein virtueller MSSQL 2017 mit einer SUSDB für 5 bis 10 Clients. Die VM hatte dazu 4 Threads und 16GB.

Der läuft jetzt auf seinem eigenem Blech, ein R9 3900X mit 64GB ECC und einer PCIe SSD für die Datenbankdateien. (Kein gutes Layout, aber ist ja auch bisher nur die SUSDB.)

Seither keine Probleme mehr, weder auf dem ursprünglichen Host noch mit dem neuen System.
 
Die SUSDB (von WSUS) läuft bei uns auf ESXI und ist auch am Krebsen. Kann es sein, dass man MSSQL, wenn überhaupt, nur auf HyperV oder Blech laufen lassen darf? Und machen die das mit Absicht?
 
Der SQL des WSUS benötigt bei meinen 70 oder 15 Systemen weniger als 1 GB und 2 Kerne reichen im Hyper V durchaus aus. So richtig performant ist die SUSDB nie, auch nicht nach Optimierungsskripten. Ich sehe da bisher keine Notwendigkeit für solch einen großen Unterbau.
 
  • Gefällt mir
Reaktionen: chris2014
Interne DB? Oder ein Express?

Na wie auch immer, ich mach ja noch ein bissel mehr mit dem MSSQL, vor allem da er nun den Bums unterm Arsch hat. Einfach so Threads, IO und RAM dagegenwerfen für ne Testinstanz SUSDB wäre tatsächlich albern, da stimme ich zu. Virtuelles DBMS bin ich sowieso dagegen, von daher war es nur recht und billig, daß ich meinen eigenen Ansprüchen gerecht werde :daumen:

Muß mir noch bissel was überlegen re: Migration bestehender weiterer Datenbanken - die laufen momentan auf Postgres, würd ich evtl auf Oracle umziehen, keine Ahnung. Postgres auf Windows widerstrebt mir allerdings... einfach so ein Bauchgefühl.

Was ich halt damit sagen wollte - und dazu steh ich auch -- ist, daß DBMS ein ganz Ticken ressourcenhungrig sind. Einfach irgendwo dazuklatschen kann man... wenn man nichts damit macht.
Wenn natürlich die Express Edition reicht und man keine Einschränkungen damit spürt, dann kann man DAMIT natürlich machen was man will. Der geht sogar noch auf nem Celeron.
 
  • Gefällt mir
Reaktionen: chris2014
Zurück
Oben