none
Hardware-Konzeption eines SQL-Servers für ein Dynamics NAV ERP-System RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen!

    Wir planen gerade einen Wechsel des ERP-Systems. Aktuell setzen wir eine Lösung auf AS400-Basis (IBM iSeries) ein. Künftig soll ein Dynamic NAV basierendes ERP-System mit MS SQL-Server genutzt werden.

    Umgebungsdaten:
    50 User
    zu erwartende DB-Größe: Nach Installation ca. 30GB, mit 10 Jahren Produktivdaten ca. 600GB

    Folgende Hardware-Konfiguration wurde von dem Softwarehaus vorgeschlagen:

    2x XEON 5645 (Hexacore. 2,4 GHz)
    48GB DDR3 RAM
    18 SAS 6Gb 146GB 15K HDDs, folgende Config:
    2x Betriebssystem, RAID1
    4x LogSpace, RAID10
    4x TempSpace. RAID10
    8x DataSpace, RAID10

    Da wir aus der AS400-Welt kommen, haben wir bisher keine große Erfahrung im MS SQL-Server-Umfeld. Ich möchte diese Config daher einfach mal zu allgemeinen Diskussion stellen. Über ein paar Erfahrungswerte diesbezüglich würde ich mich sehr freuen.

    Viele Grüße,

    Thies


    Donnerstag, 28. April 2011 08:01

Alle Antworten

  • Hallo Thies,
    für mich sieht das nach einer sehr ordentlichen Maschine aus. Vielleicht etwas überdimensioniert für Eure Ansprüche, aber sonst ok. Kommt aber extrem auf die Anwendung an, die ich nicht kenne.
    Wenn ihr etwas einsparen wollt, könntet ihr vielleicht auf das Laufwerk für die tempdb verzichten und die Datenbank mit den anderen zusammen ablegen. Weiterhin solltet ihr Euch Gedanken darüber machen, wo die LogSicherungen hinkommen. Dies könnte ein anderer Server sein, oder ein separates Laufwerk (statt TempSpace) auf dem lokalen System.
    Die Datenbank-Sicherungen legt ihr dann bestimmt woanders ab?!?

    Laufwerk für die tempdb und Memory könnte man auch noch nachrüsten, wenn man mit der Anfangskonstellation nicht klar kommt.

    Auch der Arbeitsspeicher ist ziemlich großzügig dimensioniert.
    Beachtet bitte, dass Euer Betriebssystem auch mehr als 32 GB unterstützen muss und ihr die 64-Bit Variante von SQL Server installiert.

    Einen schönen Tag noch,
    Christoph


    Microsoft SQL Server MVP
    http://www.insidesql.org/blogs/cmu

    Freitag, 29. April 2011 08:04
    Beantworter
  • Hallo Thies,

    ich sehe dies genauso wie Christoph. Im Grunde ist dies eine grundsolide Maschine. Für den Anfang wohl etwas überdimensioniert, jedoch liegt dies an dem zu erwartenden  Datenzuwachs. Wichtig wäre jedoch noch zu wissen, was auf der Maschine noch laufen soll. Wird die Maschine als dezidierter SQL-Server betrieben, wovon ich ausgehe oder sollen darauf noch andere Anwendungen laufen?

    Auf alle Fälle sollte dies eine 64-bit Maschine sein, was laut der Konfigurationsangaben wohl auch so geplant ist. Was den Arbeitsspeicher angeht so ist dieser für den Anfang wie Christoph bereits erwähnte ziehmlich großzügig bemessen. Jedoch gehe ich davon aus das in ca. 5-6 Jahren da vermutlich noch etwas nachgerüstet werden müsste. Dies sollte jedoch kein Problem sein und richtet sich nach der tatsächlichen Entwicklung des Datenzuwachses was aus heutiger Sicht sicherlich nur schwer einschätzbar ist.

    Falk

    Freitag, 29. April 2011 09:30
  • Hallo,

    für die Logs und die Temp DB würde ich mehr zu einem RAID 1 tendieren. Den so bekommt ihr in dem Bereich mehr Performance, natürlich auf Kosten der Datensicherheit. Jedoch reden wir bei einer Temp DB über ausgelagerte Daten bei einer Abfrage etc, die Logs sollten jedoch die meiste Schreib und Lese Performance bekommen.

     

    Beim RAM kommt es natürlich auf die Datenbewegungen an, bzw. wie die Anwendung mit dem Server umgeht. Von daher würde ich an dieser Größenordnung eher festhalten.

     

    Viele Grüße.

    Philipp Lenz


    Viele Grüße, Philipp Lenz www.flip-it.de - SQL Server Blog
    Samstag, 30. April 2011 20:47
  • Hallo zusammen!

    Zunächst vielen Dank für Eure Antworten.

     

    @ Christoph

    Die Datenbanksicherung soll in der Nacht als Dump auf einem Netzlaufwerk landen. Es soll einen Stand-By-Server geben, der über Logshipping mit den aktuellen Daten gespeist wird.

    @ Falk

    Es handelt sich um eine 64-bit Maschine (Windows Srv 2008 R2 Ent)

    @ Philipp

    Du meinst RAID 0 für Logs und TempDB, oder?! Wenn dann aber eine Platte aus diesem/n RAID-Set(s) Probleme hat, wäre der SQL-Server nicht mehr funktionstüchtig, nicht wahr?!

     

    Spricht grundsätzlich etwas dagegen, über alle Platten ein RAID10 zu erstellen, anstatt die Bereiche einzeln zu konfigurieren? Es würden dann schließlich bei jedem Zugriff alle Platten aktiv werden (respektive die hälfte wg. der Spiegelung) und somit den Flaschenhals der HDD-Mechnik verringern. Oder würden Zugriffe auf Temp- und Logfiles bzw. Zugriffe des BS die Performance in dieser Config drosseln?

     

    Viele Grüße,

    Thies

    Montag, 2. Mai 2011 09:34
  • Hallo Thies,

    zu Philipps Aussage:
    RAID 10 ist RAID 1 + 0, und kombiniert die Fähigkeiten beider Technologien, d. h. spiegelt und verteilt,
    und ist in allen Belangen vorzuziehen (dafür aber teurer), siehe dazu http://de.wikipedia.org/wiki/RAID

    Das Zusammenfassen zu einem RAID 1+0 Verbund ist nicht besser.

    Grundsätzlich sollten Daten und Protokoll nie auf einem Platten-Verbund liegen -
    und bei der angepeilten Größe wären mehrere Controller zu empfehlen,
    sonst habt ihr dort einen Single Point of Failure.

    Wenn mehrere Controller verwendet werden (bzw. es werden mehrere Kanäle unterstützt)
    bringt das Verteilen auf mehrere Verbünde zusätzlich Geschwindigkeitsvorteile.

    Selbst wenn das nicht der Fall ist (in eurem Falle nicht zu empfehlen):
    Aus konzeptioneller Sicht teilt man Daten / Protokoll / Tempdb auf, um eine spätere
    Änderung zu erleichtern, z. B. wenn die Hardware doch zu klein sein sollte oder aus
    anderen Gründen einiges getauscht werden muss/soll.
    Einige Grundregeln: Storage Top 10 Best Practices

    Aus dem NAV Blog als Lektüre:
    http://blogs.msdn.com/b/nav/archive/2010/09/28/microsoft-dynamics-nav-sql-server-configuration-recommendations.aspx
    und die Kommentare dort (woraus man einige Kennlinien ableiten kann) .

    Wenn ich davon ausgehe, das es das Angebot einer Komplettlösung ist,
    solltet ihr euch von dem Anbieter vergleichbare Referenzen geben lassen.
    Darüber könnt ihr mehr erfahren, ob die Hardware angemessen ist und auch
    wie viel Erfahrung der Anbieter in der Größenordnung hat.

    Gruß Elmar

    Montag, 2. Mai 2011 10:18
  • Hallo,

     

    @countryhiller: Nein, ich meine schon ein RAID1, d.h. 2 Platten die sich gegenseitig spiegeln. Bei einem Stripeset (RAID 0) wäre die Gefahr da die Du beschrieben hast.

     

    @Elmar: Ein RAID 10 geht aber im Gegensatz zu einem RAID 1 auf Kosten der Performance, da zusätzlich das Stripeset geschrieben werden muss. Für eine Plattensystem wo "lediglich" eine tempdb liegt, habe ich bisher immer zu einem RAID 1 gegriffen. Gleiches gilt auch für das Transaktionslog - hier könnte man sich aber schon wegen der Sicherheit über ein RAID 10 streiten ...

     

    >> Grundsätzlich sollten Daten und Protokoll nie auf einem Platten-Verbund liegen

    Da gebe ich Dir recht, das meinte ich auch gar nicht. Ich meinte eher das anstatt den beiden RAID 10 für tempdb und log jeweils ein RAID 1 gewählt werden solllte.


    Viele Grüße, Philipp Lenz www.flip-it.de - SQL Server Blog
    Montag, 2. Mai 2011 10:42
  • Hallo Philipp,

    > Ein RAID 10 geht aber im Gegensatz zu einem RAID 1 auf Kosten der Performance,
    > da zusätzlich das Stripeset geschrieben werden muss.

    Die Aussage ist nicht richtig.
    Die Geschwindigkeit wird erhöht, da die Daten-Zugriffe auf mehrere Platten verteilt wird (RADI 0)
    und zudem redundant gespeichert wird (RAID 1).
    Grundsätzlich gilt: Begrenzender Faktor sind i. a. die Platten (Zahl der Spindeln).

    Für mehr informiere Dich bitte in der Wikipedia, die englische spricht auch den Datenbank-Aspekt an.

    Da die tempdb beim Neustart eines SQL Servers neu erstellt wird, ist ein RAID-0 möglich
    (wenn die Downtime beim Ausfall akzeptiert werden kann), siehe u.a.

    SQL Server 2005 Configuration Blog #2.doc  und das Prinzip gilt auch für neuere (ältere) Versionen.

    Gruß Elmar


    Montag, 2. Mai 2011 12:29
  • Hallo zusammen,

    vielen Dank nochmal für die konstruktiven Hinweise. Es hat etwas gedauert, weil das Thema erst jetzt wieder aktuell wird.

    Zur Storage-Config:

    Wir haben nun einen Server mit 16 146GB 15K 6GbSAS-Platten geordert. Zu der vom Softwarehaus vorgeschlagenen Config fehlen also 2 Platten (Der Server ist so voll ausgebaut). Ich habe mir die Strorage Best Practices zu Gemüte geführt. Danach sehe ich drei mögliche Configs. Welche davon ist eurer Meinung nach am geeignesten?

    Config 1:

    In den Best Practices steht leider nicht, wo das Betriebssystem angesiedelt sein sollte. Ist es sinnvoll, es auf Log-, Temp- oder Data-Space mit unterzubrigen:

    4x RAID 10 - Log

    4x RAID 10 - Temp und Betriebssystem

    8x RAID 10 - Data

     

    Config 2:

    Ist es sinnvoll Temp und Log auf einem Raid zu kombinieren?

    4x RAID 10 - Temp / Log

    8x RAID 10 - Data

    2x RAID 1 - Betriebssystem

    2x Spare

     

    Config 3:

    Ist es sinnvoll Temp auf einem RAID1 unterzubringen?

    4x RAID 10 - Log

    8x RAID 10 - Data

    2x RAID 1 - Betriebssystem

    2x RAID 1 - Temp

    ...oder müssen wir doch zusehen, dass wir die Config vom Softwarehaus umsetzen? Oder würdet Ihr zu einem ganz anderen Ansatz raten?

     

    Viele Grüße,


    Thies

    Freitag, 27. Mai 2011 10:21
  • Hallo countryhiller,

    meiner Meinung nach war die vom Systemhaus vorgeschlagene Lösung schon die beste. Da Ihr euch jedoch für eine andere Lösung entschieden habt, wurde ich zu Config 1 tendieren.

    Config 2 kommt nicht in Frage da Temp und Log nicht auf ein Laufwerk gehören  da beide sequentiell geschrieben werden und somit der Performencvorteil somit nicht mehr vorhanden ist.

    Config 3 kommt ebenfalls nicht in Frage, da ich das Temp immer auf ein RAID 10 legen würde.


    Gruß Falk
    Dienstag, 31. Mai 2011 06:59
  • Hallo Falk,

    vielen Dank. Deine Ansichten sind nachvollziehbar. Leider bietet der Server nur Platz für 16 Platten.

     

    Eine Config habe ich noch unterschlagen:

    2x RAID 1 - Betriebsystem

    4x RAID 10 - Log

    4x RAID 10 - Temp

    6x RAID 10 - Data

     

    Sollte das BS denn grundsätzlich separat angesiedelt werden oder ist Config 1 (s.oben) ein probater Ansatz?

     

    Viele Grüße,

    Thies

    Dienstag, 31. Mai 2011 17:48
  • Hallo Thies,

    wenn die Möglichkeit besteht, würde ich das Betriebssystem grundsätzlich seperat ansiedeln. Deine neu vorgeschlagene Config ist so nicht möglich, da Du ja mit einem Anwachs der Datenbank auf bis zu 600 GB rechnest. Diese Konfiguration wäre somit für die Datenbank nur auf 3x146 Gb = 438 GB beschränkt. Ansonsten wäre diese Konfiguration mein klarer Favorit.

     


    Gruß Falk
    XING


    Mittwoch, 1. Juni 2011 08:04
  • Hallo Falk,

    ganz klar, Du hast Recht: Ich widerspreche meinen Zielvorgaben. Allerdings werden wir keine historischen daten aus dem Altsystem übernehmen und werden insofern lediglich etwas ressourcenschonender mit diesen im neuen Produktivsystem umgehen müssen (...an dieser Stell war ich gedanklich weiter als im Text... ;-)). Eine Belegrecherche kann immernoch im separaten Archivsystem erfolgen.

    Ich stelle mir allerdings noch die Frage, ob die Performance unter der fehlenden logischen Platte im Stripe-Set für den Data-Bereich leiden wird. Dies wir wahrscheinlich aber nur die Praxis offenbaren...

    Viele Grüße,

    Thies

    Mittwoch, 1. Juni 2011 16:40
  • Hallo Thies,

    unter diesen Umständen würde ich natürlich zu der letzgenannten Config greifen.

    Ein Performance-Problem durch die fehlende logische Platte für den Data-Bereich, würde ich so nicht sehen. Aber Du hast Recht, dies wird erst die Praxis offenbaren.

     


    Gruß Falk
    XING
    Freitag, 3. Juni 2011 09:24