Hallo! Ich habe jetzt erst von UCS erfahren und bin begeistert.
Ich würde mich über Tips für folgendes Szenario freuen:
5 Benutzer arbeiten mit einem Anwaltsprogramm (Advoware, Basis wohl SQL-Datenbank; Server-Client), das nur auf Windows läuf. Die Client starten das Programm über eine Verknüpfung zum Server (exe-Datei). Die Daten (hauptsächlich Dokumente) werden über eine Laufwerksfreigabe vom Server zur Verfügung gestellt und im Programm eingebunden. Alles läuft momentan als Workgroup.
Nun möchte ich gerne UCS verwenden und eine Domäne aufbauen. Irgendwo muss eine Windows-Instanz für das Programm laufen (Win Server oder Win10). Es soll 2 Server geben, davon einer als Backup bzw. Failover. Außerdem habe ich einen VPS, der zusätzlich eingebunden werden kann und soll.
Ich stelle mir eine Virtualisierung vor. Entweder mit Proxmox als Basis und UCS virtualisiert oder UCS als Host und darin virtualisieren? Allerdings sollen Virt.-Host wohl nur diese eine Aufgabe erledigen?
Wie würde man am besten vorgehen?
Wichtig: Backups und kurze Ausfallzeiten.
Vielen Dank!!
Einfach Standardsetup. Schon zigmal gemacht. Virtualisierung mit Proxmox, da du ein Vollbackup dort schon integriert hast. Als Dateibackuplösung kann ich die BackupPC (sehr einfach) oder Bareos empfehlen.
Mind. 3 UCS virtuelle Maschinen. Master/Slave/Backup. Auf diesen laufen Services wie DHCP/DNS/Printserver… keine Apps. Für Freigaben und Apps kannst du weitere Slaves oder Memberserver dazu installieren. Windows dann einfach dazu hängen. Wir installieren immer zum Management ein Windows10, dort konfigurieren wir die ganzen GPO’s. Damit das auch gut funktioniert müssen die Clients auch Windows10 mit aktuellem Patchlevel sein. Oder KDE-Neon was wir hier verwenden.
Have Fun 
Hallo @boospy,
findest du 3 UCS Infrastruktur-Instanzen (ohne Anwendungen) -gerade für kleine Umgebungen- nicht stark übertrieben? Vor allem, wozu soll die 1. Slave-Instanz hier gut sein? Nur Printserver? Meiner Meinung steht hier der Management-Overhead dieser ja jeweils eigens zu pflegenden Instanzen hier in keinem vernünftigen Verhältnis. Und zumindest der 1. Slave, wenn nicht schon auch die Backup-Instanz könnte Standard-Anwendungen wie File-Shares/Freigaben übernehmen. Und mit genügend RAM/CPU-Zuteilung braucht man nicht für jede App/Anwendung eine eigene UCS Instanz. Klar könnte man die UCS Pflege mehrerer Instanzen mit Ansible etc. zentral orchestrieren, aber sowas macht man eben gerade bei kleinen Umgebungen auch nicht bzw. kein Budget dafür.
Gegenargumente, was sagen andere?
Just my 2 cents,
Robert
Wir haben hier beides schon gemacht, je nach Anforderungen, Kunden-Umgebungs-Größe & Budget hat beides Vor & Nachteile.
Hast du 2 oder mehr physikalische Server & etwas mehr als nur “small budget” zur Verfügung? Dann empfehle ich Proxmox (wie hier schon empfohlen wurde) und mache einen Proxmox Cluster, wobei du für HA ohne ein externes hochverfügbares shared Storage schon 3 phys. Server benötigst um damit sinnvoll Ceph & HA betreiben zu können. Mit 2 Servern kann man sonst nur simpler replizieren (bei ZFS Einsatz bietet Proxmox einfache Replikations Funktion)
Alternativ gibt es von Univention seit kurzem dazu auch einen Ceph-Ansatz / Cool Solution:
HTH, Robert
Natürlich kommt es drauf an was man möchte. Ich gehe immer von eine optimalen Umgebung aus. Runderschrauben kann man ja immer 
Ja wir verwenden auch Foreman (Puppet). Wobei UCS hier selbst schon supertolle Werkzeuge mit bringt. Unsere Server laufen hier vollautomatisch. Mit einem eigenen zentralen Reposerver für alle und und automatische Updates mit Reboots, genau getimed. Bei UCS heist das ganze dann “Paketpflege” Steht sehr gut beschrieben in der Dokumentation.
Und ich ja hier auch ne Umgebung mit Intel NUC, nativ, auch das geht
Ja, klar gibt es diese Möglichkeiten, aber der OP oben spricht von 5 Benutzern & Small Office, weswegen mir dein Vorschlag eher oversized auffiel und ich mich v.a. auch fragte, wozu du eine 3te Slave-Instanz hier verwendest, obwohl da noch gar keine Apps/Anwendungen zum Einsatz kommen
Nichts für ungut,
VG Robert
Ganz einfach, weil aus unserer Sicht Management immer extra sein sollte. Abgekoppelt von den anderen Dingen wie Nextcloud, Git, usw.
Auf Master und den anderen zweien sind Dinge wie DNS, DHCP, Radius, CUPS, Selfservice und diese Dinge. Sollte mal ein Server mit einer App was haben und nicht mehr richtig tun, sind Managementsachen davon überhaupt nicht betroffen. Möglicherweise ist man hier noch ein wenig von Windowsbugs geprägt. Aber auch im Linuxbereich (noch Gentoo und Ubuntu) trennten wir die Dinge schon immer. Auch das sich Server die öffentlich erreichbar sind immer in einem anderen VLAN befanden und gewissen Ports nur zu einer gewissen Zeit geöffnet werden.
Hab neulich erst wieder ne Umgebung mit Nextcloud, Rocketchat, Wekan, Odoo… aufgebaut. UCSbasis. Nur das die DMZ Server in nen eingenen VLAN sind und getrennt von dem Mangement agieren, nur Ports die unbedingt durchgeschaltet sein müssen, sind da über nen Layer3router und ACL’s geschaltet. Im Falle eines erfolgreichen Angriffs kann da nicht viel passieren. Und zwischen 5000 und 20.000 gibt es pro Tag immer. Und die blockt zu gut 95% die Firewall ab. Aus diesem Grund ist die “UCS Paketpflege” ne Feine. Sache.
Immer Ansichts, Sicherheit und Geldfrage. Ich fahre das System auch privat so abgeschottet. Würde es für mich niemals anders gestalten. Und wer die paar Euro’s nicht in die Hand nehmen möchte, der hat halt nicht die volle Bandbreite an möglichen Gegenmaßnahmen.
Fazit: auch alles klein aufgebaut ist technisch funktional, aber nicht optimal. Und UCS kann mit seinen Policies auch alles automatisieren. Da braucht man keinen Puppet. Ausser für große Umgebungen.
Have Fun 
Das wuerde ich folgendermassen realisieren:
Klienten - e.g Ubuntu/Zorin - verbinden sich via RDP zum Windows Server und melden sich dort an der Domaene an und/oder Klienten werden in die Domaene integriert
Server 1
Basis Installation UCS, KVM VMs
(Samba Domain Controler, File , Print server - In Domaene integriert, Windows Terminal server mit allen installierten Anwendungen - In Domaene integriert (Anwender arbeiten dann “lokal” auf dem Server, nur 1 Konfiguration/setup noetig))
Server 2, groessere Festplatten, so das mehrere Backups gehalten werden koennen
Basis installation UCS , KVM VMs
Backups nach Bedarf (e.g nachts) per rsync oder andere Backup Software zum Server 2
Im Falle des Falles, die Kopien der VMs koennen auf dem Server 2 SOFORT gestartet werden oder Backups der VMs zum Server 1 hergestellt werden, kann auch noch Backups der Klienten aufnehmen. Ohne AD Integrierung koennen diese in weniger als 10 Minuten wieder hergetellt werden