Dukel

Welche Grenzen sind das denn?

Scaling Out SQL Server 2005 Scaling Out SQL Server with Data Dependent Routing

Diese Öffentlichen IPs gehen zum Webserver. Der Webserver greift aber nicht über diese IP auf den SQL Server sondern auf die SQL IP. Du wirst aber nur einen Active/Passiv Cluster bekommen oder die Daten per Partitionierung Active/Active Clustern.

Du darfst nicht den Fehler machen und den SQL und den Webserver zusammen anschauen. Beide haben eigenen, unterschiedliche Möglichkeiten zur Hochverfügbarkeit. Das heißt aber auch, dass du unter Umständen 4 Server brauchst. Die Webserver sicherst du per Loadbalancing (DNS RR) ab und die SQL Server per Mirror oder Cluster.

Man kann z.B. eine Active/Multi-Passiv Installation aufbauen. Einen Master, welcher die Daten zu mehreren Passiven Knoten repliziert, die dann die Webserver bedienen. So viel ich weiß kennt MS-Sql (genauso wie MySql) einen Activ/Activ Cluster nur durch Partitionierung.

Ja. Aber ich glaube ein Forum ist für so ein recht komplexes Thema der Falsche Ort. SQL Mirror benötigt keine Shared Storage, aber wie geschrieben ist das trotzdem eine Aktiv/Passiv Lösung. Was man machen kann im Webandundungsdeployment das ganze immer auf beide Webserver verteilen, dann muss man nichts replizieren. Aber das kommt auf die Webanwendung an.

Du brauchst eben 4 Server. 2x IIS per Loadbalancing und 2x SQL mit SQL Hochverfügbarkeit (Cluster, Mirror, Log Shipping,...). Die Partitionierung ist auch für Performance da. Da bekommst du aber "nur" einen Ausfall abgesichert. Der 2. IIS wird immer noch auf den SQL im anderen RZ zugreifen.

Genau. Man hat z.B. eine Tabelle x mit Namen. Alle Datensätze mit dem Namen von A-M sind auf SQL Server 1 und alle Namen von N-Z sind auf SQL Server 2. Ob man dass dann so macht kommt auch immer auf die Umgebung und Ziele /Anforderungen an. Was hast du denn vor?

Du musst zwischen SQL und IIS trennen. Den IIS kann man per Loadbalancing clustern. Dies ist dann ein Shared Nothing Cluster. Welcher Replikationmechanismus dann zum tragen kommt ist fast beliebig. Die Webapplikation ändert sich auch nicht dauernd. Den SQL dahiner kann man per Partitionierung Clustern sonst hat man immer eine Akitv / Passiv Lösung.

Was hast du denn schon gefunden? Schau mal @ MSXFAQ.DE - PersonalArchiv

Ähm...? Für 2 Einstellungen bei Users & Computers eine komplette Umgebung mit Exchange aufsetzen? Da würde ein Test DC reichen um das zu testen.

Dann SSD's nehmen wenn SAS zu teuer ist? Wird auch, je nachdem was drauf läuft und wieviele User arbeiten, auch mit Sata Platten laufen. Lieber die SSD als zusätzliche Disk einbauen und darauf z.B. die Mail DB's legen.

Oder man benutzt eine richtige Backupsoftware, die beides unterstützt. Mit Commvault z.B. macht man eine komplette VM Sicherung (ESX oder Hyper-V) und kann diese komplett, einzelne Volumes oder einzelne Files zurückspielen.

Wenn nicht mehr als 5 Leute an den Rechnern arbeiten, dann ja.

Es ist egal wer wo angemeldet ist und an wie vielen Rechnern. Die Anzahl der Nutzer zählt.

Kann der Softwarehersteller kein Debugging aktivieren oder in der DB Tracen? Hast du die wichtigsten Performance Counters (Ram, Cpu, Disk, LAN) angeschaut? Läuft die Anwendung mit einer anderen DB?

Ja so ist es.

Ich würde statt der SSD lieber ne schnelle SAS Disk nehmen.

Das Problem bei Backup aus einer VM heraus ist folgender: Bei einem Restore musst du eine VM erstellen, das OS installieren, Backup Agent installieren und dann das Backup zurückspielen. In manchen Umgebungen sind das verschiedene Teams und das dauert ewig. Wenn man VM's komplett sichert kann man diese auch komplett zurückspielen.

Es ist eine natürliche Person gemeint.

Und worauf zeigt die ext. ip (reverse)?

Ich habe zwar keine konkrete antwort, aber ich hatte vor einiger Zeit was über CA Monitoring gelesen: MSXFAQ.DE - CA Monitoring

Stimmt das Reverse DNS?

Wenn es unbedingt(!) sein muss würde ich das per App-V virtualisieren.

Sind Serverseite Profile aktiviert oder Lokale Profile im Einsatz? Für die Fileshares wirst du um ein Wartungsfenster (nur ein kurzes, wenn man es richtig macht) nicht herum kommen, wenn du keinen potentiellen Datenverlust haben wirst.