HP Sizing Tool für Exchange Server 2016

von

Hewlett Packard Enterprise (HPE) hat sein Exchange Server Sizing Tool aktualisiert, sodass jetzt auch Exchange 2016 Server geplant werden können.

Mit dem HPE Sizer ist es sehr einfach geeignete Hardware für eine Exchange 2016 Organisation zu finden. Ähnlich wie bei dem Mailbox Calculator können auch im HPE Tool die Parameter ziemlich genau definiert werden. Der Sizer empfiehlt dann, welche HP Hardware geeignet ist. Hier kann der HP Sizer für Exchange 2013 runtergeladen werden:

HPE Sizer for Microsoft Exchange Server

Sizing

Am Ende kommt ein wirklich guter Bericht raus, es fehlt eigentlich nur noch der „Gib mir 50% Rabatt und Bestell“-Knopf :-)

image

Ich habe gerade nur ein bisschen rumgespielt, mir gefällt es.

Noch ein kleiner Tipp, der HPE Sizer benötigt .NET Framework 3.5, unter Windows 10, kann .NET Framework 3.5 über die Systemsteuerung nachinstalliert werden:

image

Ohne .NET 3.5 startet der Sizer nicht.

10 Gedanken zu „HP Sizing Tool für Exchange Server 2016“

  1. Hi Frank,

    wir müssen aktuell eine Ex2016 zu Ex2016 Migration durchführen und haben für das Sizing damals das Tool verwendet. Leider hat HP das Tool eingestellt und wir haben auch keine Kopie mehr davon.
    Hättest Du die Möglichkeit mir das noch einmal zur Verfügung zu stellen?
    Das wäre super.

    Antworten

    • Hallo Frank,

      ja wir stehen auch vor einer Migration und bräuchten das Tool. Man kann es leider nicht mehr downloaden. Kannst du es vielleicht nochmal auf deiner Website direkt zum Download bereit stellen?

      ;fg

      Antworten

  2. den Sizer gibt es ja schon viele Jahre und die für 2013, 2010, 2007 habe ich auch. Was mich dran stört, abgesehen von der Trägheit, sind ein paar nervige Fehler, die ich grade wieder ermittelt habe
    1. Er scheint immer auf RAID zu gehen (5 oder 10), obwohl JBOD auch möglich wäre. HP will wohl HW verkaufen, da ein RAID5 viel mehr Disks für die IOPS braucht als ein RAID10 oder JBOD
    2. er hat mit nicht nur einmal „Disks“ angeboten, die in der Preisliste nicht drin sind aber in der BOM-Liste werden die dann einfach nicht mit eingerechnet. Der Preis ist dann falsch.

    eine gewisse „Vorsicht“ ist also auch hier angebracht

    Antworten

    • Hi Frank,

      die Probleme sind mir noch nicht aufgefallen, allerdings muss ich zugeben, dass ich auch nur wenig mit dem HP Sizer gearbeitet hab. Es wäre ganz hilfreich wenn HP die IO Leistung der HDDs / Controller angeben würde, dann wäre es um ein vielfaches einfacher den geeigneten Speicher auszuwählen, leider muss man sich die IO Werte der HDDs umständlich raussuchen. Vielen Dank aber für die Hinweise. Leider habe ich keine Server mit lokalem Storage mehr, sonst würde ich eine entsprechende Tabelle mit den verschiedenen HDD-Typen und RAID-Leveln hier veröffentlichen.

      Gruß,
      Frank

      Antworten

      • Nach einigen Versuchen habe ich es nun doch geschafft auch JBOD (non-Raid) zu machen. Ich hatte einen DL360G9 als „Vorgabe“, da der Kunde den halt im Warenkorb hat. Warum auch immer wollte der Sizer dafür kein JBOD anbieten.
        Als ich bei einem weiteren Versuch dann keinen Server vorgeschrieben habe, konnte ich im Storage Bereich dann „non-Raid“ auswählen.- Aber nur wenn ich einen DL560G9 nehmen-. Der ist bautechnisch zum 360 eigentlich gleich, nur dass mehr CPU-Sockets drauf sind. Ich bin mal gespannt, was der HP-Vertrieb dazu sagt :-) auch wieder „upselling“.
        Die IOPS sind eigentlich „einfach“. die Platten geben sich da nicht viel http://www.msxfaq.de/konzepte/iops.htm
        Kritischer sind die RAID-Levels. Bei RAID5 kannst du die Summer der IOPS glatt durch 4 Teilen, bei Raid6 sogar durch 6. Bei DAGs mit „genug“ Kopien (mind3, besser 4) ist JBOD echt ein Gewinn und macht viele Server erst möglich. Mein Sizing kommt mit 272 Disks in 8 Servern aus, mit RAID5 müsste ich allein gegen der IOPS über 600 Disks einplanen. (mit entsprechenden enclosures). Das sind schon beeindruckende Zahlen.

        Antworten

        • Hi Frank,
          das ist interessant. Der DL360G9 ist meines Wissens ein 1HE Server, der dürfte nicht nativ in der Lage sein 34 HDDs aufzunehmen, ich habe die Quickspecs jetzt nicht gelesen, man wird ja wahrscheinlich ein Disk Shelf an den DL360 anschließen können, aber berücksichtigt das auch der Sizer? Dein Artikel zu den IOPS der Platten ist super, ich hab mich etwas blöd ausgedrückt, ich meinte eine Tabelle in der Art 5 x 10K SAS im RAID5 liefert ca. „X“ IOPS. Wobei man da natürlich nicht alle Konfigurationen berücksichtigen kann.
          Ich kenne ja die Anforderungen nicht, aber 272 Disks finde ich schon beachtlich. Darf ich fragen warum es 8 Server und JBOD sind? Ist es aus preislicher Sicht tatsächlich soviel günstiger 8 Server mit 272 HDDs und Shelfs auszustatten, als 8 Server an ein SAN welches ggf. Dedup unterstützt anzuschließen (sofern die Server nicht über zig RZs verteilt sind)?

        • Sorry mein Fehler. DL380 (2HE) aber es kommen eh externe Enclosures (D3600) zum Einsatz. Der Unterschied vom 3xx/5x ist ja nur 2 vs 4 Sockets. Ich wart mal auf das HP Feedback :-).
          Das Sizing ist für 20.000+ ausgelegt und mit recht großen Mailumschlag in zwei DataCenter. Ich hatte erst mit 4 Server in einer DAG (2 je RZ) geplant aber dann wäre ich über die 96 GB RAM gekommen und für die IOPS müssten mehr Disks pro Server dran. Da ist es nicht viel teurer, weitere Server (statt Enclosure) zu kaufen und flexibler im Fehlerfall zu sein.
          SAN oder DAS ist einfach zu rechnen SAN ist zu teuer und ein Single Point of Failure. (Alle großen Probleme der letzten drei Jahre waren irgendwie mit dem SAN verbunden) Die „Redundant“ im SAN brauche ich nicht, da die DAG das macht. und die SAS/SATA Disks sind um zehntausende billiger als SAN. Die Rechnung gilt halt nur, solange man keine anderen SAN-Funktionen (Snapshot, SAN-Backup, Replication etc) braucht.
          Habe am ADMIN-C grade gesehen, dass wir wohl in Fahrradentfernung voneinander wohnen. Wir mal seit sich nen Biergarten zu suchen. (Le Coq ?)

        • Ah OK, das HP Feedback würde mich interessieren. Du hast natürlich recht, wenn ich nur für Exchange ein SAN und entsprechendes Storage kaufen muss, dann ist es sicherlich viel teurer als Server mit DAS. Allerdings gibt es ja wahrscheinlich bereits ein SAN und entsprechendes Storage bei dem Kunden dieser Größenordnung. Hier wäre Exchange dann ggf. nur ein weiterer Konsument und Kosten müssten nur anteilig berechnet werden. Gerade bei 4 Kopien je DB könnte hier je nach Storage eine menge Platz gespart werden, wenn das Storage dedupliziert, sofern es dann auch die IOs liefern kann. Wenn ein SAN bereits vorhanden ist, welches natürlich entsprechend redundant ausgelegt sein sollte, könnte es zumindest ähnlich teuer sein. Günstiger sicherlich nicht, da stimme ich zu.

          Die Welt ist aber auch klein, Le Coq hört sich gut an, bei dem Herbstwetter kann man ja auch drinnen sitzen, erste Runde geht auf mich.

  3. Nettes Tool. Allerdings funktioniert die Übernahme der Daten aus dem Exchange Calculator nicht sauber. Ich habe im Exchange Calculator eine Kalkulation für 50.000 Mailboxen mit 3 DAGs im Vollausbau gemacht, die der Exchange Calculator hinsichtlich RAM und CPU Cores per Server akzeptiert, nicht aber der HPE Sizer, wenn ich die Kalkulation aus dem Exchange Calculator lade.
    Ein Tool explizit für Virtuelle Server gibt es nicht. Man kann aber im Exchange Calculator und im HPE Sizer angeben ob Virtualisierung oder Eisen.

    Antworten

  4. Hi Frank,
    sieht nach nem tollen Tool aus. In wiefern ist das umzurechnen/ zu gebrauchen für Virtuelle Server oder gibts evtl. sogar hierfür schon ein Tool?!

    Gruß
    Christian

    Antworten

Schreibe einen Kommentar