Wechsel auf SQL und SAN

Hallo

wir planen im Moment den Wechsel von unserer C/Side Datenbank zu SQL und von einem Festplatten Shelf per SCSI in ein SAN.
Hat jemand so etwas schon mal gemacht oder geplant.
Unsere jetzigen Eckdaten sind HP Proliant DL380 G5 mit Windows 2003 R2, 4 GB Ram, Xeon Quadcore mit 2,8Ghz dazu 12
mal 15K Platten (24HD im Raid1). Das System läuft stabil und die Sperrungen halten sich in Grenzen. Die Datenbank ist 12 * 9,5GB
groß und wird von ca 120 Usern bedient.

Geplant ist umzuziehen auf einen HP BL460c Blade Cluster mit 2* Windows 2008 Enterprise und SQL2005, Quad Core 2,33 Ghz,
16GB Ram mit FC-Verbindung zum HP EVA 8100 San.
Kann man Grundsätzlich sagen was für Probleme wir haben könnten bei der Umstellung auf SQl und ob sich die Performance
verbessert durch das SAN. Für Erfahrungen und Hinweise jeder Art wäre ich sehr dankbar.

Gruß

welche technische NAV- Umgebung benutzt ihr?

Hallo

technisch haben Dynamics NAV 5.00 ( Build 24199 )im Einsatz. Die Objekte sind aus der Version
3.7. Laut Systemhaus inhaltlich 3.7 und technisch 5.0.

Also ob Windows 2008 durch Navision schon unterstützt wird weiß ich nicht, aber für den SQl Server und das Betriebssystem würde ich jeweils einen 64 Bit Version empfehlen. Ich würde Dir auch für den Arbeitsspeicher empfehlen, diesen auf 32GB herauf zusetzen. Bei 120 Usern hat der Server dann schon einiges zu tun und der SQl Server begint hungrig zu werden. Aus Erfahrungen mit einem SAN kann ich Dir nur sagen, dass der SQL Server sich die FC Controler des SAN nicht mit anderen Servern unbedingt teilen sollte, da es sonst zu Engpässen in der Bandbreite der FC Controler kommen könnte. Wenn ich es richtig noch in Erinnerung habe, ist die Bandbreiter der FC Controler bei der EVA 4 GBit/s und kommt einem SCSI controler eigentlich sehr Nahe, aber auch nur dann, wenn der SQL Server alleine diesen Controler nutzen kann.

Ansonsten würde ich Empfehlen im SAN selber RAID 10 Level aufzubauen. Über die Geschwindigkeit von den RAID leveln brauchen wir ja hier nicht weiter zu diskutieren. Darüber ist schon mehr als genügend diskutiert worden.

Zusammengefasst, Ein SAN kann ein Segen sein, aber wenn es nicht "dick" genug ausgerüstet ist, dann wird es Geschwindigkeitsmäßig schnell zum Fluch, genauso wie der SQL Server. Wie schon gesagt, nutzt die 64 Bit Versionen, dann hast Du in der Speicherverwaltung bessere Karten und der Server ist schneller in der Bearbeitung der Transaktionen. Eine Empfehlung aber noch. Ihr solltet vielleicht darüber nachdenken, ob ihr die Netzwerkverbindung des Server nicht sogar zu einer verbindet und damit bis zu 2 GBit/s Bandbreite erzeugt. Aber 1 GBit langt auch.

Also dann viel Spass beim Wechsel. Nicht vergessen, Datenbank für den SQl Server tauglich machen.

MFG

Sven

Dem ist (fast) nix mehr hinzu zu fügen; außer:

NAV 4.0SP3, NAV 5.0, NAV 5.0SP1 und NAV 2009 - jeweils in den aktuellsten/gepatchten Versionen - sind freigegeben für Windows Server 2008 und SQL Server 2008.
Zum SAN: jawohl, SAN kann viele Vorteile bringen, muss aber korrekt konfiguriert werden.

Bei 120 Usern kann man sich auch schon überlegen, ob man besser 2 physikalische CPU verwendet - also z.B. 2 QuadCore - da es Empfehlungen (von MS Menschen) gibt, die besagen, dass man pro 100 CCU eine physikalische CPU haben sollte.
Aber letztlich hängt das vom Transaktionsvolumen ab, ist also nicht unbedingt "Pflicht" ...

Und wie mein "Vorredner" schon angesprochen hat: die richtige Konfiguration und Wartung des NAV/SQL System sind ebenso entscheidend. Dazu findest du im Forum sicher viele nützliche Hinweise!

Gruß,
Jörg

also wir haben hier eine 200GB-Datenbank auf Win2003-64bit , SQL2005 64 bit und einem Fujitsu-Fibrecat-80 SAN am Laufen, auf 30 Harddisks m 2x Raid 10-Verbund.
kann nur sagen: die Kiste rennt.

Meine Erfahrungen noch beim SAN:
früher hab ich immer ein wenig gespart, und die Harddsik-Shelfs nicht ganz voll gemacht, um Platz für erweiterungen zu lassen. Später war dann immer die technik so viel weiter dass es sich nicht lohnte, weitere Harddisks einzusetzen.

seitdem bestücke ich die shelfs immer komplett mit allen Festplatten, die reinpassen.

So soll es sein

Probleme mit SAN treten meist dann auf, wenn man z.B. alle Disks in einen einzigen großen - physikalischen - Array packt und dann die einzelnen - logischen - LUN dann verschiednen "Schwerlastverursachern" zuordnet, also SQL Server & Exchange & Sharepoint & File Server ...

Die Daten werden dann "physikalisch" gemischt auf den Spindels abgelegt; durch die hohe Lastverteilung wird das Schreiben zwar rasend schnelle, aber beim Lesen der Daten muss ggf. über große Bereiche gelesen werden. Schlage da mehrere "schwere Jungs" gleichzeitig zu, dann kann es zu Latenzen kommen, wenn die "Spindeln" quasi überlastet werden ...

Bei SAN die dediziert für den SQL Server verwendet werden kommt sowas kaum vor.

So haben wir das eigentlich auch, trotzdem ist Nav seit dem Unstieg auf SQL tageweise reichlich langsam. Selbst einfaches Scrollen durch die Objektliste im Designer ruckelt vor sich hin. An machen Tagen geht es jedoch wunderbar schnell. An Traffic im Netzwerk ist nie etwas Besonderes feststellbar (sagt unser Admin).

Wo könnte ich die Fehlersuche zuerst beginnen? Bin für alle Ideen offen :)

hmm.
so ins blaue hinein:
ihr habt euren SQL-Server doch hoffentlich nicht in einer VM laufen?

ihr habt euren SQL-Server doch hoffentlich nicht in einer VM laufen?

Nein. Die Hardware entspricht in etwa dem, was oben beschrieben wurde. 2 Quadcores Xeon, 16GB, Windows Server 2003, SQL2008 (je 64bit), 20 Platten, alles fein aufgeteilt. Nav ist 5.0SP1, Build 28342.

Achso, Anzahl User ist nie größer als 40.

Hallo,

ich möchte mal diesen Thread wieder "hoch holen".

Wir betreiben unseren SQL-Server auf einem DL380 G5 mit FC-Anbindung an ein EVA4400.
Alle 24 Platten sind zu einer Diskgroup zusammen gefasst und dort liegen drei LUN's für den SQL-Server (vRAID1).
Ich habe schon weiter oben gelesen, dass es nicht wirklich optimal ist. Da aber die anderen Systeme auf dem SAN nicht so Leistungshungrig sind, sollte das nicht so schwer ins Gewicht fallen.

Wir haben jetzt von unserem Dienstleister erfahren, dass der Betrieb eines SQL-Servers über ein SAN nachteilig ist, weil die SQL-Anfragen über FC nicht so schnelle verarbeitet werden können und es deswegen besser ist lokale Festplatten zu verwenden.
Kann jemand bestätigen, dass FC die Datenbank ausbremst ?
Ich würde lieber das SAN erweitern, als wieder zurück zu lokalen Festplatten zu gehen (SAN vs. DAS).

Danke,
Gruß

Cheesy

das mit dem FC kann ich weder bestätigen noch dementieren, aber einiges geht wohl schon verloren, weil alle platten zu einer LUN zusammengefasst sind, so hast du keine dediziert getrennten platten für datenbank und Log. du hast nur eine logische Trennung, das SAN macht das dann wie es ihm passt.

Im prinzip schreibt dein SAN also alles auf EINE große Platte.

nun wird man fragen: wenn man das so aufdröseln muss und die platten nun doch einteilen muss, und die ganze automatische verwaltung des SAN übergangen wird, wozu dann ein SAN?
Antwort: genau. da wäre ein DAS besser(sprich performanter)
das SAN ist da halt ein Kompromiss zwischen Verwaltung von Plattenplatz und performance.