Your SlideShare is downloading. ×
0
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Exchange 2010 storage improvements
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Exchange 2010 storage improvements

4,124

Published on

A deck covering Exchange 2010 Storage improvements built and extended from some of the Microsoft ignite decks

A deck covering Exchange 2010 Storage improvements built and extended from some of the Microsoft ignite decks

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,124
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
158
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Currently 2TBMoving to 8TBRandom IO not getting quicker 15K RPM, 10K RPM, 7.2K RPMDensity is getting better so can read more data in the same timeFlash – SSD – Didn’t take that betOptimised for spinning media for E14Expensive – so use as Cache in SAN
  • JBOD – i.e. 1 disk per database and log setRAID less – disks will fail3 + copies
  • 2007 roughly the same at Exchange 4.0One database and then a couple of really large tablesMessage table and attachments – all messages per databaseMessage folder table per mailbox which does all the viewsThis gives the benefit of single instance storage – one copy in the message table with pointers from the message folder tableRandom IO!2010 schema is changed massivelyOnly one table per database Now data specific to mailbox so data can be kept sequential for quick retrieval from the same area of diskNow message view table instead of secondary indexes
  • Really important in reduction of IOUpdate the view when user views!
  • Page size is smallest section of IOBigger page means less small IO for a single message read2007 random layout of data on disk means 3 Ios201020K message – pull the same message – get the message header and body on one pageThis makes a huge difference to IOPage size will be fine for handling large messages – 12-15K is mean size of message currently
  • As you add larger page sizes, and lay things out for sequential IO DB grows by 20%.Same as OST grew in SP2 for office 2007Now compress message headers and text/hmtl bodies – limited to this for speedCan bring database back to same size as 2007 or even less if bulk of HMTL messagesNow have many more tables and fewer bigger pagesThere is also Cache compressionSo when you pull a 32KB page – the smallest element of Exchange data but that page only holds 16KB of data the free space will be compresses so that only 16KB of cache is used.
  • Can do coalescing when pages are not next to each other2007 needs 3 ios to get pages off disk – random IO2010 bring all five up – a stream of IOThen evict the middle pages
  • Cleanup was done using online maintenance and defragThis has changes and cleanup is done when tombstone or dumpster cleanup happens – Page 0 happens automatically as because it occurs when the write is being done anyway, there is no additional IO2003 and 2007 are great for compaction2007 SP1 changed this slightly to reduce IO during the maintenance window.2010 this has changed a lot – it is done at run time as space is seenContiguity has never been a concern until now - compaction has always not worried about continuity to make it small2010 makes trade offs on size as we’ve mentioned to ensure contiguity – analysis happens continuouslyDB check summing
  • Utility MSFT built to track contiguity of the new DBThis is showing a Message folder table of the inbox on 2007This is massively Random2010 is contiguous as pages are laid out sequentially so that reading a huge folder full of 10000 items is quick and easy!
  • Transcript

    • 1. Exchange 2010 Storage Improvements<br />Nathan Winters – Exchange MVP<br />
    • 2. Agenda<br />A Brief History of Exchange Storage<br />The new ethos<br />Feature Deep Dive<br />Summary<br />
    • 3. History<br />
    • 4. History<br />ESE/JET Blue<br />IOPS – Random IO application<br />Why? – Small Expensive drives<br />1.6GB disk $400 in 1996<br />SCSI 2GB and 4GB 100 IOPS<br />Single Instance Storage<br />Clustering with Shared Storage<br />Backup an issue<br />Single Point of Failure<br />32 bit <br />Not enough RAM<br />Ram limited number of users per server<br />
    • 5. History - Exchange 2007<br />Big improvements in Exchange Server 2007<br />Reduce storage input/output (I/O) (70%)<br />Use large amounts of memory (64 bit)<br />Increased page size (4 kilobyte (KB) -> 8 KB)<br />Lower storage costs<br />Support large mailboxes (> 1 gigabyte (GB))<br />Provide fast search (CI)<br />Continuous replication (log shipping)<br />High Availability (HA) + fast recovery<br />Eliminate single points of failure<br />5<br />
    • 6. New Ethos<br />
    • 7. Email Usage<br />Radicati seeing 165 mails per day growing to 230 over next couple of years<br />Users used to large free storage<br />25GB<br />5GB 3 years of mail<br />Triage once per year to archive<br />Not once per day!<br />Mail available through all clients<br />Cached Mode/Performance issues<br />High Item counts – 5000, 20000, 100000<br />
    • 8. Disk Technology<br />Currently 2TB<br />Moving to 8TB<br />Random IO not getting quicker <br />15K RPM, 10K RPM, 7.2K RPM<br />Density is getting better so can read more data in the same time<br />Flash – SSD – Didn’t take that bet<br />Optimised for spinning media for E14<br />Expensive – so use as Cache in SAN<br />
    • 9. Exchange Server 2010 Storage Vision<br />IO Reduction<br />Sequential IO<br />SATA/Tier 2 Disk Optimization<br />Large, Fast, Low-cost Mailboxes<br />Storage Design Flexibility<br />RAID-less Storage (JBOD)<br />9<br />
    • 10. Exchange Server 2010 HA Storage Design Flexibility<br />10<br />DAS (SAS) <br />DAS (SATA) <br />HA = Shared Storage Clustering<br />+1.0 IOPS/Mailbox<br />3.5” 15K 146GB FC Disks<br />RAID10 for DB & Logs<br />Dedicated Spindles<br />Multi-path (HBA’s, FC Switches, SAN array controllers)<br />Backup = Streaming off active <br />Fast Recovery = Hardware VSS (Snapshots/Clones)<br />HA = CCR<br />.33 IOPS/Mailbox<br />2.5” 146GB 10K SAS Disks<br />RAID5 for DB<br />RAID10 for Logs<br />SAS Array Controller (/w BBU)<br />Backup = VSS Snapshot<br />Fast Recovery = CCR<br />HA = DAG (2 DB copies)<br />.11 IOPS/Mailbox<br />3.5” 2TB 7.2K SATA/SAS Disks<br />RAID10 for DB & Logs<br />SAS Array Controller (/w BBU)<br />Backup = Optional/VSS<br />Fast Recovery = Database Failover<br />HA = DAG (3+ DB copies)<br />.11 IOPS/Mailbox<br />3.5” 2TB 7.2K SATA/SAS Disks<br />1 DB = 1 Disk<br />Backup = Optional/VSS<br />Fast Recovery = Database Failover<br />SAN<br />JBOD (SATA)<br />More options to reduce storage cost<br />
    • 11. JBOD/RAID-less Storage: Now An Option<br />JBOD : 1 disk = 1 database (with logs)<br />Requires Exchange Server 2010 High Availability (3+ DB Copies)<br />Annual Disk Failure Rate (AFR) = 5% <br />11<br />
    • 12. Exchange Server 2010 HA<br />Simplified mailbox High Availability and disaster recovery with new unified platform<br />New York<br />San Jose<br />Mailbox Server<br />Mailbox Server<br />Mailbox Server<br />Replicate databases to remote datacenter<br />DB1<br />DB1<br />DB1<br />Recover quickly from disk and database failures<br />DB2<br />DB2<br />DB2<br />DB3<br />DB3<br />DB3<br />DB4<br />DB4<br />DB4<br />DB5<br />DB5<br />DB5<br />Evolution of continuous replication technology (database mobility)<br />Easier than traditional clustering to deploy and manage<br />Allows each database to have 16 replicated copies<br />Provides full redundancy of Exchange roles on as few as two servers<br />12<br />
    • 13. Deep Dive<br />
    • 14. Exchange 2010 Features<br />Move to Sequential IO<br />Change Table structure<br />Lazy View<br />Page size 32KB<br />Database Compression (LVC)<br />Read/Write Coalescing<br />Database Contiguity<br />Cache Compression<br />Storage Groups Gone<br />Single Point of Failure Gone<br />Optimised for huge mailboxes<br />
    • 15. Random vs. Sequential Disk IO<br />Random IO<br />Disk head has to move to process subsequent IO<br />Head movement = High IO latency<br />Seek Latency limits IO (IOPS)<br />Sequential IO<br />Disk head does not move to process subsequent IO<br />Stationary head = low IO latency<br />Disk RPM speed limits I/O per second (IOPS)<br />Disk Head<br />7.2K SATA Disk (20ms Latency)<br />Random = 50 IOPS<br />Sequential = +300 IOPS<br />15<br />
    • 16. IO Reduction: Store Table Architecture<br />Per Database<br />Per Folder<br />Exchange Server 2007<br />Secondary Indexes used for Views<br />Per Database<br />Per Mailbox<br />Per View<br />Exchange Server 2010<br />New store schema = no more single instance storage within a database<br />16<br />
    • 17. Exchange 2007<br />M1<br />M2<br />M1<br />M3<br />M2<br />Nickel & Dime Approach<br />Many, random, IOs (1 per update)<br />Time<br />DB I/O<br />M1 arrives<br />M2 arrives<br />M1 flagged<br />M3 arrives<br />M2 deleted<br />User uses OWA/Outlook Online and <br />switches to this view<br />Exchange 2010<br />M1<br />M2<br />M1<br />M3<br />M2<br />Pay to Play Approach<br />Fewer, sequential, IOs (1 per view)<br />Store Schema Changes: Lazy View Updates<br />
    • 18. IO Reduction: Database Page Size Increased to 32 KB<br />Exchange Server 2007 DB Read 20 KB Message<br />DB<br />Cache<br />Disk<br />3 Read IO’s<br />8 KB Pages<br />Exchange Server 2010 DB Read 20 KB Message<br />DB<br />Cache<br />Disk<br />1 Read IO<br />32 KB Pages<br />18<br />
    • 19. Mitigate DB Space Growth: Database Compression<br />Problem:Store Schema change, space hints, B+Tree Defrag and 32 KB page size combine to increase DB file size by 20%<br />Solution: Growth is 100% mitigated by Database Compression<br />Targeted compression for message headers and text/html bodies (7bit/Express)<br />DB Space Analysis<br />DB File Size Comparison<br />Msg Views<br />32KB Pages<br />1 Database, 750 x 250MB mailboxes<br />RTF = RTF Compressed, Mix = 77% HTML, 15% RTF, 8% Text<br />Avg. Message size = ~50KB<br />19<br />
    • 20. IO Reduction: Read IO Gap Coalescing<br />Exchange Server 2007 DB Read Behavior<br />DB<br />Cache<br />Disk<br />3 Read IO’s<br />Exchange Server 2010 DB Read Behavior<br />DB<br />Cache<br />Disk<br />1 Read IO<br />20<br />
    • 21. IO Reduction: Maintain Contiguity Over Time<br />New Database Maintenance Architecture:<br />Database B+Tree Defragmentation (aka OLD2):<br />Background/throttled process that maintains space and contiguity of database tables<br />21<br />
    • 22. IO Reduction: Database Contiguity Results<br />Exchange Server 2007 Message Header Table (aka MFT)<br />DB Page Numbers<br />FRAGMENTED<br />Random deletes at the tail<br />Exchange Server 2010 Message Header Table (aka MsgHeader)<br />CONTIGUOUS<br />*Production/Dogfood database analysis<br />Blue = contiguous (good)<br />Red = fragmented (bad)<br />22<br />
    • 23. Summary<br />
    • 24. Exchange IO Trend<br />+90% Reduction!<br />24<br />
    • 25. Putting It All Together: Mailboxes/Disk<br />Exchange Server 2010 storage improvements cannot be quantified in IOPS reductions alone<br />+4X Mailboxes/Disk!<br />+500<br />125<br />250 MB Mailbox Size, 3MB DB Cache/user, 12 x 7.2k SATA disks (DB/Logs on same spindles), Loadgen Outlook 2007 Online Very Heavy Profile, measured at <20ms RPC Average latency<br />25<br />
    • 26. Summary<br />Exchange Server 2010 store has…<br />Reduced DB IOPS by +70%...again!<br />Optimized for large mailboxes (+10 GB) and 100K item counts<br />Optimized for large/slow/low-cost disks (SATA/Tier2)<br />Made JBOD/RAID-less storage a viable option<br />Enables unmatched storage flexibility to push storage Capex costs down<br />Provides many more backup/DR options<br />26<br />

    ×