TechEd2006 Exchange Server 2007: Storage Changes and Design Considerations

  • Article

UCM309
Scott Schnoll
scott.schnoll@microsoft.com
Senior Technical Writer, Exchange Server

Achtung: Das ist eine TECHNIKER Session, nicht für Sales ;-)

MS Exchange 2007 Design Goals

  • grosse, billige Mailboxen (> 1 GB)
    Eins der Wege, das zu erreichen, ist die massive Reduzierung von Disk I/O (70 % reduktion !)
    das wurde durch den Move auf 64 Bit erreicht
    Heute verwendet Exchange max. 3 GB Speicher !
    Exchange 2007 kann 32 GB und mehr Speicher verwenden

    Features, die so grosse Mailboxen erlauben:
    Contend Indexing
             automatisch enabled und läuft im Background - overhead in Prozessor und Speicher ist gering,
             der Gewinn bei Suche ist aber enorm !
    Backup vom Replikat
    Managed Folder
    Fast recovery
              VSS Volume Shadow Copy support
              Continuos Replication
    14 Tage dumpster (der Ort, wo gelöschte Objekte hingehen, bevor sie endgültig gelöscht werden)

  • mehr Storage Options, billigere Storage Kosten und Komplexibilität
    Storagekosten sind bei größeren Kunden bis zu 80 % der Gesamtkosten von Exchange !
    Soll nicht heissen, daß SANs schlecht sind oder abgelöst werden sollen - aber es soll alternativen zu SAN geben !

  • gesteigerte Verfügbarkeit

Exchange 2007 and Storage

  • Database Fundamentals
    • Architektur nahezu unverändert
    • Checkpoint depth - die Menge von Seiten, die im Speicher gehalten werden können, bevor sie auf die Platte geschrieben werden - bleiben bei 20 MB pro Storagegroups
  • Lost Log Resiliency
    • Wenn das Log erfolgreich auf die Disk geschrieben wurde, dann bekommt Exchange das Signal, die Datenbank upzudaten - ist Standard...
    • Problem ist, wenn beim Recovery 1 - 2 Logfiles fehlen, ist die ganze Datenbank unvollständig
    • bei 2007 ist die Datenbank immer 1 - 2 Logfiles "hinten nach", damit ist im Falle eines Crashes die Wahrscheinlichkeit geringer, daß Logfiles fehlen oder defekt sind
  • die 2 größten 64 Bit storage features:
    • DB Cache size unlimitet:
      • RAM Rule of Thumb: 2 GB + 5 MB per User (bis empfohlenerweise max. 32 GB Speicher) - über 32 GB nicht mehr viel Performanceverbesserung feststellbar
      • Light User 2 MB, Middle Users 3 MB, high users 5 MB Speicher (für die Berechnung des Speicherbedarfs)
      • increasing cache size reduces DB Reads
    • 50 databases in 50 storage groups (Standardedition max. 5 Storagegroups)
      50 mal 50 geht nicht ! Maximum ist 50 Databases, d.h. wenn ich 50 Storagegroups habe, kann jede nur 1 Datenbank haben !
      Best practice ist 1 Datenbank pro Storagegroup
      • 1 GB & 2 GB mailboxes
      • Databases are mounted in parallel
  • Increased Page Size to 8 KB (von 4 KB)
  • I/O Coalescing (die Menge an Daten, bevor sie geschrieben werden - ist jetzt 1 MB an Daten - weniger Writes, aber grössere
  • No more STM Files
    Grund: Der Frontendserver ist komplett verändert worden - Inhaltsumwandlung ist am Storeserver passiert - passiert heute am Frontendserver
  • keine Virtual Memory fragmentation mehr
  • Log Files generation up to billions - quasi keine Grenze mehr bei der Logfilegenerierung
    8 hex Stellen....
  • Log File Size hat sich geändert - Log File nun 1 MB - gemacht wegen continous replications und um die Menge an daten zu reduzieren, die bei LogFile verlust entstehen können
  • Checksum recovers from single bit errors
  • aber auch bei gleicher Hardware/Memory wie Exchange 2003 sind bis zu 50 % IO Verbesserung feststellbar
  • Verhältnis Read/Write hat sich auf 1:1 verändert...

Cluster Continous Replications

  • Log Shippping zu einem zweiten Server
  • ich habe 2 Kopien meiner Datenbank
  • ich habe high avaliability - ist ein Cluster mit Failover
  • Nachteil: Ich brauche doppelt so viel Plattenspeicher

Local Continous Replication

  • Replication ist am selben Server, aber hoffentlich auf einer zweiten Diskeinheit und idealerweise an einem anderen Storagecontroller !
  • Overhead auf der gleichen Maschine um die 20 %...
  • 2 Disk könnte auch iScsi sein - damit muß der Storage nicht im gleichen Ort stehen, sondern kann an einem anderen Ort stehen...

aus diesen Änderungen ergbit sich, ich brauche nicht mehr unbedingt Fibre Channel Storage, sondern kann problemlos mit iScsi arbeiten...

Wie stelle ich meinen Platzbedarf fest ?

Database

  • 14 tag dumster ca. 15 % overhead [MSIT profile]
  • 5 % CI overhead
  • ca. 10 % overhead for whitespace in the database

Log

  • Recommended log LUN size
  • Move Mailbox - bei MIgration auf 2007 muß ich die Benutzer moven (vom alten Server auf den neuen)
    Produziert viele Logfiles am Zielserver ! - Bei Größendefinition beachten !

Beispiel:

  • 1000 User, 250 MB mailbox = 250 GB
    CI 12,5 GB, Dumpster 37,5 GB, Whitespace 25 GB
  • Total 325 GB

MAx. Database Size

  • hier gibt es empfehlungen - wegen Backup und vor Allem Recovery Size !
  • Offline Defrag/repair
  • Online maintenance
  • Reseed time (1 database=25 MB/Sec) (wenn etwas mit meiner replizierten Datenbank nicht in Ordnung ist, muß ich die andere DB reseeden - dauert in etwa 25 MB/Sec)
  • 100 GB max empfohlene Datenbankgröße ohne Continous Replication
  • 200 GB max. empfohlene Datenbankgröße mit Continous Replication
  • max. Size ist 16 TB (!) - d.h. die oben genannten Größen sind empfohlene Größen, keine Maximalgrössen !

Storage Design

  • Ich muß die Benutzung meiens Systems relativ genau wissen, um ein neues System gut designen können - dazu gibt es die IOPS/per user - Whitepaper, das mit hilft, das zu berechnen bzw. auf Exchange 2003 festzustellen
  • Exchange 2007 IOPS/per user verändert sich bezogen auf memory und anzahl der Benutzer
    • 2000 1.0 IOPS != 4000 0,5 IOPS

Managed Folders (MF)

  • For delete/move(Aging Policies), MF processed 100 KB messages in 5 min (2x2.8 Ghz DualCore, 4 Gb RAM)
  • MF ist sehr rechenintensiv, nicht gleichzeitig mit Backup oder anderen Tasks machen

Empfehlung: Nicht mehr als 5000 Items in einem Folder - insbesonders in den kritischen Foldern (Inbox, ...)

Weitere Anforderungen an den Server:

  • Outlook Chached Mode:
    • Sorts und searches passieren am Client
  • Outlook online Mode
    • Sorts & Searches erfolgen direkt am Server !

Continous replication

  • braucht doppelte Storage Kosten
  • CCR erlaubt clustering mit non-shared Storage - damit wird das ganze wesentlich billiger !
  • Pflicht bei CR - pro Storage Group 1 Datenbank
    sonst nur Empfehlung
  • 4 LUNs pro storage group,2 LOG and 2 Database
  • Logs und Datenbank auf unterschiedlichen Platten
  • Active und passive auf unterschiedlichen Storage systemen !
  • unterschiedliche Storage Controllers und PCI Bus in LCR !
  • Active und passive Node sollten die gleichen Performancewerte haben - damit beim Switch die Performance nicht leidet
  • man sollte Storage für Exchange nicht mit anderen teilen (zumindest nicht auf der gleichen Spindel !)
  • supporteter Storage in Exchnage 2007
    • DAS
    • SAN
      • iSCSI
      • Fiber Channel
  • NAS ist NICHT Supportet für Exchange 2007 !
  • RAID Types:
    RAID 10 beste Verfügbarkeit - empfohlen !
    RAID 5 beste Speichernutzung
      schlechte Performance, wenn eine Disk ausfällt und noch schlechter beim Rebuild
    RAID 6 bessere Dataprotection als RAID 5 - geringer performance
  • Diskpar(t) Blog:
    https://msexchangeteam.com/archive/2005/08/10/408950.aspx

 

Backup Options:

  • LCR/CCR ist erst Verteidigungslinie, erste Recovery Ebene - kein Backup !
  • Primary Datenbank:
    • Legacy streaming to disk, to tape
  • Backup Änderung:
    • tägliches Incremental, weekly full
      nachdem ich von CR zurücksichern kann, ist das akzeptabel

Solution Guidance:

www.microsoft.com/technet/prodtechnol/exchange/2003/esrp.mspx - hier kommen die Speicherhersteller zu MS ins Lab, dort wird getestet und im Dokument vermerkt - bei Release von Exchange 2007 wird es upgedatet - EMpfehlung nur Storage zu nehmen, das dort getestet wurde...

Christian