Höhere Verfügbarkeit mit einem 2. SQL-Server 2008 R2?

[bla!zilla 10]

Stimmt, du hast Recht. Für zwei Knoten reicht die R2 Standard. Mangels Shared Storage und Cluster Knowhow fällt das aber IMHO raus.

[martins 11]

HA und Quickie-Lösungen sind keine sinnvolle Kombination. Mangels zentralem Storage und SQL Enterprise Version fällt ein Cluster eh bei dir raus. Database Mirroring würde gehen, sofern deine Anwendungen mitspielen. Nutzen diese den SQL Native Client, sehe ich eigentlich kein Problem (außer evtl. das Knowhow)

 

Da das auch Inhouse betreut werden soll, möchte ich mir hier nicht noch eine Baustelle aufmachen.

 

 

 

Nee, die Infos reichen nicht für ein Sizing. Wie viele IOPS brauchst du? Welches Verfügbarkeitslevel strebst du an? Kapazitätsangaben alleine sind nicht brauchbar.

 

Habe ich noch nicht ermittelt. Viele sind es nicht... ich tippe auf ~ 500 IOPS.

 

 

 

Ach wenn es nur immer so einfach wäre... Leider kenne ich genug Installationen, an die so herangegangen wurde. Etwas mehr Planung darf es schon sein...

 

Beginn des Threads war ja auch die Frage, ob ich die Verfügbarkeit meines SQL-Servers "etwas" erhöhen könnte. Eventuell durch die Nutzung der zweiten SQL-Standard Lizenz. Wir haben da offenbar etwas übersprungen :suspect: :D

 

Nach der Empfehlung fragte ich, damit ich so ungefähr eine Hausnummer habe, ob ich mich mit dem Thema weiter beschäftige.

[Dukel 454]

Ich würde trotzdem eher (auch wenn es weiteren Aufwand und kosten bedarf) auf ein Hyper-V Cluster gehen. Da hat man dann HA für den SQL Server und alle anderen Server mit.

[bla!zilla 10]

Habe ich noch nicht ermittelt. Viele sind es nicht... ich tippe auf ~ 500 IOPS.

 

500 IOPS bei 60 Usern, zwei Terminalservern, einem SQL, einem Exchangeu nd sechs anderen VMs? Ich halte das zwar für untertrieben, aber wenn ich mal von einem Read/ Write Verhältnis von 70/30 ausgehe, dann sollte ein RAID 1+0 aus 6 10k SAS Platten deinen Performanceanforderungen genügen (ausgehend von 32K IOs komme ich auf ca. 600 random IOPS).

bearbeitet 21. Juli 2012 von bla!zilla

[martins 11]

Ich hatte es mal vor einiger Zeit überschlagen, allerdings für 2 HyperV-Hosts (je Host ~ 500 IOPS) und für ~ 45 User. Daher denke ich, dass für ein SAN mind. 1500 IOPS benötigt würden, großzügig vielleicht 2000 IOPS.

 

Da jetzt am WE kein Mensch arbeitet, kann ich schlecht was ermitteln. Gibt es da keine Eckwerte? Für Exchange 2010 las ich mal einen Wert von 0,03 IOPS pro Mailbox. Das wären bei 60 Usern nur ein Bedarf von gerade mal 2 IOPS!? :confused:

 

Bei einem SAN mit 20x 10.000 RPM (SAS 2,5"), je 300 GB müsste ich dann doch nicht so verkehrt liegen!?

 

Edit: Ich würde ein SAN von HP bevorzugen, da ich aus meinen jetzigen HP-Hosts die HDDs (SAS 10.000 RPM, 2,5") weiterhin nutzen könnte. Für den Ausfall würde ich dann aber wohl noch ein zweites, nicht ganz so performantes SAN benötigen? Tipps hierzu?

bearbeitet 21. Juli 2012 von martins
Ergänzung

[bla!zilla 10]

Da jetzt am WE kein Mensch arbeitet, kann ich schlecht was ermitteln.

 

Dann hol das mal schleunigst nach.

 

Bei einem SAN mit 20x 10.000 RPM (SAS 2,5"), je 300 GB müsste ich dann doch nicht so verkehrt liegen!?

 

Das sollten bei 70/30 (Read/ Write), im Schnitt 32K IOs, RAID 1+0 und konservativ mit 0% Cache Hit Ratio überschlagsweise so 1500 random IOPS sein.

 

Edit: Ich würde ein SAN von HP bevorzugen, da ich aus meinen jetzigen HP-Hosts die HDDs (SAS 10.000 RPM, 2,5") weiterhin nutzen könnte. Für den Ausfall würde ich dann aber wohl noch ein zweites, nicht ganz so performantes SAN benötigen? Tipps hierzu?

 

Vergiss es. Die P2000 nutzt nicht mehr die gleichen Platten wie die ProLiants. Bei der P4000 ist es nicht vorgesehen Platten zu erweitern, nur Boxen (Basis sind DL180 G6), die P6000, P9000 und P10000 haben ebenfalls keine ProLiant SAS Disks. Das mit dem Umbauen von Platten ist noch aus seligen MSA1x00/ MSA30 Zeiten. Theoretisch kannst du eine P2000 nutzen und eine MSA70 hinterhängen. Dort könntest du dann die 10k 2,5" ProLiant SAS Disks verwenden. Eine Alternative wäre der Umbau der Platten in MSA70 Enclosures und der Einsatz von HP ProLiant Servern mit DataCore. Die Frage ist: Ist es betriebswirtschaftlich sinnvoll Platten umzubauen? Wohl kaum...

 

Ein zweites Storage für den Disaster-Recovery Fall ist nice, aber eigentlich nur dann, wenn du dazwischen einen synchronen oder asyncronen Spiegel hast. Damit hast du dann ein sehr niedriges RPO. Das RTO hängt davon ab, wie einfach der Failover und der Wiederanlauf ist. Ein zweites Storage, auf dem du Images oder Kopien der VMs ablegst ist eher witzlos. Die meisten DR Pläne, die eine derartiges Szenario vorsehen, haben oft ein relativ hohes RTO und RPO (abhängig von der Aktualität der Images).

 

Achte lieber darauf, dass an dem Storage alles redundant ist, dass die HBA/ Netzwerkkarten redundant sind, die Anbindung redundant ist und du ein ordentliches SLA auf die Komponenten hast (4h vor Ort, besser Call-to-Repair). Um es der Geschäftsführung schmackhaft zu machen solltest du wissen, was es das Unternehmen kostet, wenn die IT eine Stunde steht.

[martins 11]

Das hört sich nach deutlich mehr als 10.000 € an. Ist es überhaupt möglich, so ein Projekt mit nur Kenntnissen mit Standard-Servern umzusetzen, ggf. mit Hilfe hier im Forum?

 

Vielen Dank nochmal für deinen/euren Einsatz!

 

 

Gruß

Martin

[lefg 276]

Hallo

 

....Ist es überhaupt möglich, so ein Projekt mit nur Kenntnissen mit Standard-Servern umzusetzen, ggf. mit Hilfe hier im Forum?.....

 

Ich traute mir sowas nicht zu, fasste es so nicht an. Auf eine wirksame Forenhilfe könnte ich im Ernstfall doch nicht setzen; wie sollte ich das auch meinem Direktor erklären. Die Firma hat auch vorzusorgen; was geschähe bei Urlaub/Krankheit/ sonstige Abwesenheit eines Admins.

 

Benötigt wird die qualifizierte Beratung und Umsetzung, weiter die Versicherung für die Zukunft, den Ernstfall.

bearbeitet 22. Juli 2012 von lefg

[bla!zilla 10]

Das hört sich nach deutlich mehr als 10.000 € an. Ist es überhaupt möglich, so ein Projekt mit nur Kenntnissen mit Standard-Servern umzusetzen, ggf. mit Hilfe hier im Forum?

 

Ganz schlechte Idee. Kein Forum, auch dieses hier, kann professionelle Beratung ersetzen. Wenn wir über Virtualisierung reden, dann ist Knohow aus dem Kompetenzfeldern Storage, Netzwerk und Serverinfrastruktur gefragt. Meiner Erfahrung krankt es an den ersten beiden Punkten, insbesondere beim Storage-Knowhow.

[martins 11]

Ich sehe das wie ihr. Daher werde ich eure Anregungen aufnehmen, aufbereiten, der GL vortragen und abwarten wie sich entschieden wird.

 

Zurück dann noch einmal zu meiner ursprünglichen Frage: Kann ich mit den jetzigen Gegebenheiten die Wiederherstellungszeit meines SQL-Servers noch optimieren?

 

Gruß

Martin

[bla!zilla 10]

Meines Erachtens nach nicht. Höchstens in der Form, dass du bestimmte Tätigkeiten bei der Recovery automatisiert. Alles was du per Hand machen musst ist fehleranfällig.

[martins 11]

In dem Fall meinst du das Recovery der Datenbanken, der VM oder des Hosts? Aber eigentlich egal bei welchem Szenario - ich wüsste nicht, warum ich mit einer Checkliste nicht ebenso weit kommen würde, wie mit einem Skript. Ich sehe hier eher den automatisierten Prozess als potentielle Fehlerquelle. Aber präzisiere doch bitte...!

 

Noch eine Frage bzgl. eines SANs. Da wir wahrscheinlich nicht um das Thema "Höhere Verfügbarkeit" drumherum kommen, würde ich mir gerne eine Testumgebung bauen. Gibt es hier SOHO-Hardware die ihr empfehlen könnt?

 

Gruß

Martin

[bla!zilla 10]

In dem Fall meinst du das Recovery der Datenbanken, der VM oder des Hosts? Aber eigentlich egal bei welchem Szenario - ich wüsste nicht, warum ich mit einer Checkliste nicht ebenso weit kommen würde, wie mit einem Skript. Ich sehe hier eher den automatisierten Prozess als potentielle Fehlerquelle. Aber präzisiere doch bitte...!

 

Alles eine Frage des Skripting-Knowhows. Alles was man mehr als ein Mal macht, sollte man automatisieren. Per se ist alles, wo Menschen hand anlegen müssen, fehleranfällig. Automatisierte Prozesse erzeugen immer den gleichen Output.

 

Aber hey: Dein Arbeitegeber, die Umgebung wird von dir administriert, eine Regeln.

 

Noch eine Frage bzgl. eines SANs. Da wir wahrscheinlich nicht um das Thema "Höhere Verfügbarkeit" drumherum kommen, würde ich mir gerne eine Testumgebung bauen. Gibt es hier SOHO-Hardware die ihr empfehlen könnt?

 

Ein SAN ist erst einmal nur ein Netzwerk, ein Netzwerk von Speichergeräten. Was du suchst, sind offenbar Speichersysteme im Entry-Level Bereich. Ich kenne deine Umgebung, deinen Arbeitgeber und dein Budget nicht, aber um rudimentäre Erfahrungen zu sammeln, sollte es ein beliebiges Entry-Level NAS tun, dass Speicher auch per iSCSI exportieren kann. Diese Systeme liegen preislich i.d.R. noch deutlich unter dem, was ein Single- oder Dual-Controller iSCSI Speichersystem kostet. Des Weiteren solltest du dir geeignete Literatur besorgen, um dich in die Thematik einzulesen.

[martins 11]

Ich würde für ein NAS ~ 2000,- € ausgeben. Wenn es teurer wird, muss man gucken. Nutzen möchte ich es nur als Spielwiese.

 

Da ich aber noch einen recht jungen HP-Server mit Windows Server 2008 R2 Std. in der Ecke habe, macht es vielleicht Sinn diesen mit dem "iSCSI Software Target" zu erweitern und als SAN zu verwenden? Was spricht aus eurer Sicht dafür / dagegen?

 

Gruß und Danke.

Martin

[bla!zilla 10]

Da ich aber noch einen recht jungen HP-Server mit Windows Server 2008 R2 Std. in der Ecke habe, macht es vielleicht Sinn diesen mit dem "iSCSI Software Target" zu erweitern und als SAN zu verwenden? Was spricht aus eurer Sicht dafür / dagegen?

 

Dafür: Nichts.

Dagegen: Vieles...

 

Das taugt maximal als Spielwiese um ein grundlegendes Verständnis von iSCSI zu erhalten. Aber von einem Produktionseinsatz würde ich eher absehen. Kommt aber auch auf die Umgebung an.