Dukel

Eine CAL ist Nötig wenn auf einen Server zugegriffen wird (Informationen lt. aktuellem MS PUR Dokument): Du meinst sicher mit den Administrativen Verwaltungsvorgängen die beiden Nutzer für die Administration eines Servers. Da es bei dem Backupserver aber nicht um die Administration des Server OS geht sondern um die Backupsoftware zählt dieser Passus vermutlich nicht.

Wenn du einen anderen Domänen Namen nutzen willst kannst du den SBS nicht migrieren.D.H. du musst alle Daten / User / Clients selbst migrieren und ggf. anfassen.

Es geht aber um die Administration. Das die Verbindung für das Backup keine CAL benötigt ist schon geklärt. Der Admin greift aber (per RDP oder Backup GUI) auf den Server zu um das Backup zu konfigurieren und verwalten.

Ich kenne bei den Windows Bordmitteln um Daten zu spiegeln / replizieren nur Raid (SW Raid; Storage Spaces) oder DFS. Es kann sein, dass es noch etwas anderes gibt was ich nicht kenne. Ich würde nicht "reine Vermutung" sagen sondern Erfahrung.

Wie sieht die Storage Konfiguration des Servers aus?

Ich würde den SBS einfach migrieren. Dabei wird der Domänename behalten.

Du kannst certreg.exe nutzen oder die MMC.

Wo steht das der Admin von einem Server OS kommt? Er wird sicher von seinem Client die Backup Konsole benutzen oder sich per RDP anmelden. Ich glaube nicht, dass der Admin einen Server als Desktop hat.

Sagt mir gar nichts.

Bei SQL 2008 gibt es 2 Möglichkeiten für HA. Failover Cluster oder SQL Mirror. Für einen Cluster brauchst du eine Shared Storage für SQL Mirror nicht. Wenn du den SQL Ausfallsicher machen willst musst du jedes Teil Ausfallsicher machen (Server; Storage; Leitungen). Wenn du einen Cluster erstellst muss die Storage gespiegelt sein. Wenn du SQL Mirror einsetzt braucht jeder Server seine eigene Storage. Hier kannst du einfach einen 2. Storage kaufen und an den 2. Server verbinden. Die vorhandene Storage muss dabei nicht mal Shared sein.

Soll der Exchange vom SBS deinstalliert werden und auf einer anderen Maschine installiert werden oder soll es einen zusätzlichen Exchange geben?

Wieso schließt du den neuen Rechner nicht auch per IB an? Sind die Nodes nur per IB angeschlossen oder auch per LAN? Hast du einen 10GB Switch? Ich würde keinen Server Systeme per Crossoverkabel verbinden, alle nur per Switch.

Dann stelle das ganze doch in der Testumgebung nach.

Bei dem SQL Cluster oder bei SQL Mirror? Wo liegen deine Datenbanken? Auf der Storage! Was passiert wenn die weg ist? Da hilft dir einfach nur eine neue SQL Instanz nichts.

Wieso migrierst du die Daten nicht einfach? Gerade bei einem SQL Server sollte das kein Problem sein. 2. SQL Server installieren, SQL Mirror (keine Downtime) oder Logshipping (kurze Downtime) einrichten, Datenbanken schwenken, Spiegel trennen und alten SQL Server abschalten.

Sind die Credentials irgendwo hinterlegt worden und dann das Kennwort geändert? Evtl. nen geplanter Task oder ein Service?

Ein SQL Cluster hilft auch nicht wenn die Storage dahinter wegbricht. Eine Möglichkeit ist SQL Mirror (oder in späteren Versionen SQL Always on). Dabei wird auch keine Shared Storage benötigt. Bei SQL Mirror muss dieses aber die Applikation unterstützen.

Ich sage ja nicht, dass es nicht geht, es gibt nur diverse Einschränkungen und Stolperfallen. Dann lasset uns weiter nach einer Replizierungslösung für StefanWe suchen ;)

Außerdem ist das ganze Thema Storage Spaces in dem Thema wohl obsolet, da nur Lokale Disks angeschlossen werden können. D.h. der Storage Pool auf Server 1 hat mit dem anderen Server gar nichts zu tun.

Enclosure Awareness ist etwas anderes. Angenommen du hast ein JBOD mit 4 Disks und entsprechenden Controller. Dann kann der Controller dem OS sagen, dass eine Disk ausgefallen ist. Hilft aber dem TO nicht, da er zwischen 2 Standorten Daten replizieren / spiegeln will.

Die Shared Storage brauchst du für deinen Hyper-V Cluster. Der Vorteil bei Hyper-V 3.0 und Smb 3.0 ist, dass deine Shares Storage ein SMB Share sein kann. Du stellst eine NAS Storage mit SMB 3.0 oder ein Windows 2012 Fileserver hin und legst dort deine VHD(X) Dateien ab. Die Storage Spaces sind schon Syncron, solange man 2 Disks hat. Da es eben ein Pool ist und kein Raid 1 ist das verhalten bei mehreren Disks anders.

Dann geht das mit Bordmitteln nicht. Entweder die Targets können sich replizieren oder du brauchst eine Extra Komponente (evtl. kann das DataCore).

Angenommen du hast 4 Disks in einem Storage Pool. Die Daten werden in kleine Teile aufgeteilt und dann auf Disks in einem Pool verteilt bzw. gespielt. Bei 2-Way Mirror auf 2 Disks, bei 3-Way Mirror auf 3 Disks. Da kann es sein, dass ein Block auf Disk 1 und 2 liegt oder aber auf Disk 1 und 3 oder auf 3 und 4,... Da das nicht beeinflussbar ist kann es sein, dass Daten auf 2 Disks von einer Storage liegen und keine Kopie auf der anderen Storage.

Die Fritz Box ist ein NAT Gateway fürs Internet. Diese und andere "Router" können nicht "normal Routen". Du hast ja durch die VLans unterschiedliche Subnetze. Diese musst du per Router wieder verbinden (routen setzen).

Geht das dann aber nicht nur, wenn man nur 2 Disks (je eine Disk pro Storage) in einen Pool legt? Dann fehlt einem aber der Vorteil des dynamischen Wachsen mit einfachem hinzufügen von Disks. Außer man erweitert die Storage und diese gibt nur eine Disk an den Server weiter.