Ross Smith IV Senior Technology Architect Microsoft Session Code: UNC316 Agenda Discuss the topology changes introduced in Exchange Server 2010 Client Access Transport Mailbox Understand our guidance on server.

Download Report

Transcript Ross Smith IV Senior Technology Architect Microsoft Session Code: UNC316 Agenda Discuss the topology changes introduced in Exchange Server 2010 Client Access Transport Mailbox Understand our guidance on server.

Ross Smith IV
Senior Technology Architect
Microsoft
Session Code: UNC316
Agenda
Discuss the topology changes introduced in
Exchange Server 2010
Client Access
Transport
Mailbox
Understand our guidance on server sizing
Exchange 2010 Enterprise Topology
Enterprise Network
Edge Transport
Routing & AV/AS
Phone system
(PBX or VOIP)
Hub Transport
Routing & Policy
External
SMTP
servers
Mobile phone
Web browser
Mailbox
Storage of mailbox
items
Unified Messaging
Voice mail &
voice access
Client Access
Client connectivity
Web services
Outlook
(remote user)
Line of business application
Outlook (local user)
Consolidation of Store Access Paths
Entourage
Exchange Components
Exchange Components
Outlook /
MAPI clients
Outlook /
MAPI clients
Exchange
Biz Logic
Entourage
Mailbox
Middle
Tier
Sync
UM
MAPI RPC
Store
Mailbox
Agents
DAV
Mailbox
OWA
Mailbox
Agents
Middle
Tier
WS
WS
Transport
Agents
OWA
Sync
MAPI,
Exchange
RFR &
Biz Logic
NSPI RPC
Exchange Core Biz Logic
MAPI RPC
Store
Transport
Agents
UM
RPC Client Access Service
The What
Outlook Clients
A new service in Exchange Server 2010
that resides on CAS
What it handles:
Outlook data connections go to CAS instead
of connecting directly to mailbox servers
Replaces the DSProxy interface by
providing an Address Book service on CAS
Public folder connections connect directly
to the mailbox server, but through RPC
Client Access
Exchange CAS Array
MBX
GC
RPC Client Access Service
The Why
Provides a better client experience during switchovers/failovers
When a MBX server fails over, Outlook client will only see ~30 sec
disconnection, as compared to 1-TTL min before
Uses the same business logic for Outlook and other CAS clients
Calendar logging + fix up
Content/body conversion
Greatly simplifies AD topology requirements for Outlook
Supports more concurrent connections/mailboxes per Mailbox
server
Reduces code and client logic in Exchange Store process for
increased reliability
Client Access
Client RPC Connection Changes
Exchange Server 2007
Exchange Server 2010
Outlook / MAPI
clients
RpcProxy
MAPI RPC
DSProxy
NSPI
RPC Data Flow
Mailbox
AD
HTTP Data Flow
RPCProxy
NSPI,
RFR RPC
Exchange Biz Logic
MAPI RPC
Store
Store
ESE
MAPI RPC
ESE
Mailbox
CAS Array
CAS
Outlook / MAPI
clients
Common Data Flow
LDAP
AD
RPC Client Access Service
How Directory Referral Connections Work
a.
b.
c.
3.
4.
Mailbox location (AD site)
Mailbox version
RpcClientAccessServer property of
mailbox database
CAS tells Outlook which CAS server
or array should be used for
directory requests
Outlook connects to the
appropriate CAS
1
4
3
CAS 2010
MBX 2010
2
GC
AD Site 2
2.
Outlook calls get Address Book
server API
CAS queries Active Directory
AD Site 1
1.
CAS 2010
MBX 2010
GC
If mailbox is moved back to 2003/2007, CAS will redirect the client to the
mailbox server so that it can provide a referral to a global catalog server
Otherwise, all legacy mailboxes will get directory referrals from mailbox server
RPC Client Access Service
Outlook connecting
with Outlook
Anywhere
Outlook Anywhere Improvements
Outlook Anywhere clients utilize
the Address Book service on
CAS for directory related
requests
This architecture resolves issues
surrounding DSProxy and split
HTTP connections that are due
to using SSL-ID load balancing
solutions
HTTPS
RPC_IN_DATA
HTTPS
RPC_OUT_DATA
Windows 2008+
RPC/HTTP Proxy
RPC_IN_DATA
RPC_OUT_DATA
CAS
RPC Client Access
Services + Address Book
LDAP
AD
RPC
Mailbox
RPC Client Access Service
Writing to the Directory
Question: Does this new behavior ensure that Outlook can write
changes to Active Directory for the following scenarios?
Distribution group membership
Delegate management
Certificate management
Answer: When the Address Book service detects modifications
for one of those scenarios, it will utilize the appropriate cmdlet
to commit the change to Active Directory based on the property
tag (assuming user is scoped and authorized to make those
changes):
Add/Remove-DistributionGroupMember
Set-Mailbox –PublicDelegates
Set-Mailbox –UserCertificate –UserSMIMECertificate
Client Access
Scaling Mailbox Connections
Outlook Anywhere Clients
60K outbound
connections /
CAS IP (W2K8)
CAS
MBX
Exchange Server 2007
60K connections / MBX server
MBX
Outlook Clients
Exchange Server 2007
60K outbound
connections /
MBX server
GC
Client Access
Scaling Mailbox Connections
# of CAS servers
x 100 connections / CAS RPCCA
service/process
Outlook Clients
GC
Exchange Server 2010
MBX
Exchange CAS NLB
LDAP
Client Access
Firewall/Proxy Guidelines
Internet Security and Acceleration (ISA) Server 2006
Kernel memory limitations imposed by the 32-bit architecture
ISA:CAS ratio 3:1 (worst case – heavy Outlook Anywhere usage)
Important when you have a large percentage of your users connected via
Outlook Anywhere, as the ratio of Transmission Control Protocol (TCP)
connections to users is much higher than you would see for Outlook Web
Access (OWA), ActiveSync, POP, or IMAP traffic
Beyond ISA 2006 … pre-release product information
Forefront Unified Access Gateway (UAG)
Next-generation secure remote access product and the future version of
Microsoft Intelligent Application Gateway—native 64-bit architecture
Will be tested with Exchange Server 2010
Forefront Threat Management Gateway (TMG)
Next-generation network security product and the future version of
Microsoft ISA Server—native 64-bit architecture
Will be tested with Exchange Server 2010
Client Access
Architectural Considerations
Exchange 2010 is version specific
Exchange 2010 CAS required in every AD site where
Exchange 2010 MBX is deployed
Exchange 2007 MBX requires Exchange 2007 CAS
Load balancing
If planning on deploying more than 8 CAS servers in a load
balanced array, consider deploying hardware load balancing
solution
Attend the UNC318 Transition/Deployment session to
understand the intricacies involved in co-existence!
Transport Roles
Resiliency Issues in Exchange 2007
Transport database is stateful
Loss of service results in loss of mail
Transport dumpster impacts the environment
In extreme cases, up to 200% increase in
IOPS/message due to many SGs and inefficient
cache usage when compared to similar scenarios
without dumpster
Redelivery submission results in entire quota being
redelivered and store removing duplicates
Transport Roles
Exchange 2010 Resiliency Improvements
Shadow redundancy is a new feature of transport
Provides redundancy for messages for the entire time they
are in transit
Transport becomes stateless
Eliminates need for RAID, which reduces 50% write I/O
Dumpster Changes
Database replication feedback is now used to control which
messages remain in dumpster
When message has been replicated to all database copies,
message is truncated from dumpster
Dumpster size is now based on log replication latency and
frequency of feedback
Transport Roles
How does Shadow Redundancy Work?
1. Hub (shadow) delivers message to Edge1
(primary)
Detects that Edge1 supports Transport
redundancy through XSHADOW verb
Hub moves message to shadow queue and
stamps Edge1 as current, primary owner
Hub
1
Edge1
Edge2
2
Foreign
MTA
2. Edge1 (primary) receives message
(becomes “primary owner”)
Edge1 delivers message to next hop
Edge1 updates discard status of the
message indicating delivery complete
to foreign MTA
Transport Roles
How does Shadow Redundancy Work?
3. Success: Hub (shadow) queries Edge1 (primary) for
expiry status
Hub issues XQDISCARD command (next SMTP
Session),Edge1 checks local discard status and
responds with list of messages considered delivered
 Hub deletes messages from its shadow queue
Hub
1
4
3
4.
Edge1
Edge2
2
Foreign
MTA
Failure: Hub (shadow) queries Edge1 (primary)
discard status and resubmits
Hub opens SMTP session, issued XQDISCARD
command (heartbeat)—if Hub can’t contact Edge1
within timeout, resubmits messages in shadow
queue—resubmitted messages are delivered to Edge2
(go to #1)
Transport Roles
Shadow Redundancy Other Scenarios
For systems that do not support shadow redundancy, Exchange
2010 utilizes a delayed acknowledgement process
SMTP submission from Exchange 2003/2007, 3rd party Message
Transfer Agent( MTA ) and Mail User Agent (MUA - UM, POP and IMAP
clients)
250 response delayed up to 30 sec (default)
If transport server fails before ack, client resubmits
Mailbox Submission redundancy relies on copy of message in
sender’s “Sent Items” folder
Mail Submission Service resubmits copy when hub doesn’t acknowledge
successful delivery of message
System generated (Journal Report, NDR) are considered “side
effects” of original message submission, tracked as part of
original delivery status
Transport Roles
Exchange 2010 Performance Enhancements
ESE changes:
ESE page size is 32KB
ESE database page compression
Intrinsic long value record storage
ESE version store maintenance
DB cache size increased to 1GB
Checkpoint depth increased to 512MB
Results:
With transport dumpster changes and ESE improvements, transport
IOPS requirements are targeted to be reduced by more than 50%
Larger message sizes are supported without causing backpressure
Transport Roles
Edge Transport Improvements
Better Performance for EdgeSync via Deltasync Mode
Under this mode, each time EdgeSync service only reads the
delta change since last sync and updates the target
accordingly
Support for safe senders and blocked senders
Configurable Safe List quotas
Administrator defined blocked senders
Automatic update of Safe Sender list propagation into Active
Directory
Transport Roles
Other Improvements
Information Leakage Protection and Control
(IPC) features
Attend UNC314 – Information Protection and
Control in Microsoft Exchange Server 2010 on 5/12
at 10:15am
Instrumentation and reporting improvements
Measuring end-to-end message delivery latency
Server component latency
Historical reporting and trends
End user message tracking
Transport Roles
Architectural Considerations
Shadow redundancy enables RAID-less solutions for mail.que database
Routing version boundary change:
Exchange 2010 Mailbox servers can only submit to Exchange 2010 Hub
Transport servers
Exchange 2010 Hub Transport servers can only deliver to Exchange 2010
Mailbox servers
Exchange 2007 Mailbox servers can only submit to Exchange 2007 Hub
Transport servers
Exchange 2007 Hub Transport servers can only deliver to Exchange 2007
Mailbox servers
Exchange 2010 Hub Transport servers can communicate with Exchange 2007
Hub Transport servers via SMTP (and vice versa)
For Edge:
Exchange 2010 Hub Transport will become authoritative for Edgesync in the
coexistence scenario
Mailbox
Store/ESE Changes
Exchange 2007 Issues
Exchange does many small, random input/outputs (I/Os) which
inhibit the types of disks that can be used
Exchange Server 2010
Exchange store schema and ESE optimized for fewer large,
smoother, sequential I/Os
•Store schema changes
•DB I/O size improvements
•Database cache effectiveness improvements
•ESE optimized for new store schema
Result: Exchange 2010 reduces I/O by an additional 70%
when compared to Exchange Server 2007 and is optimized for
SATA class disks
Large item count per folder is an issue due to restricted views
(affects large mailbox deployments)
Schema changes of the table structure and deferred index
updates greatly improves restricted view performance
Result: Supports 100,000 items per folder
Outlook Personal Folder Files (PSTs) are a litigation, security, and
management nightmare
New Messaging Records Management features
•Item level policy settings
•Archive mailbox feature for importing and storing PST
data
•Compliance Officer search capabilities
Result: PSTs can be removed by placing data into Exchange
repository and can be searched easily
Mailbox
High Availability Changes
Single-Copy
Single-copy Cluster
cluster
Cluster Continuous
Replication
Exchange Server 2010 High
Availability
*Over granularity
Server-level
Server-level
Database-level
Copies of data
1
2
2 to 16
*Over time
~2 min
~2 min
~30 sec (POR)
*Over management
Windows Cluster
Windows Cluster
Exchange Server
Data replication
Partner replication or SCR
Continuous replication
Continuous replication
Management tools
Separate
Separate
Unified
Host other roles?
No
No
Yes
Other advantages
Step up to automatic failover without rebuilding the mailbox server
Incrementally add replicated copies to meet business needs
No subnet or special DNS requirements
High Availability Design Example
Double Resiliency
Upgrade
Single
Siteserver 1
Server
4
Nodes2 fails
Server
1 upgrade is done
3
HA Copies
2 active
die Copies
JBOD
-> copies
3 physical
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
X
Database Availability Group (DAG)
Mailbox
Server 4
Mailbox
Exchange 2010 High Availability Sizing
Leverage the incremental deployment capabilities of Exchange
Server 2010
You do not need to deploy site resilience out of the box!
Deploy larger database availability groups (DAGs) over smaller
DAGs
Distribute database copies across nodes in a matrix
Improved database seed/log shipping performance across the
wide area network (WAN)
DAG network compression/encryption (optional)
Log shipping is now Transport Control Protocol (TCP) socket based
Use multiple 1 Gb networks or 10 Gb network to improve local
area network (LAN) re-seed/log replication queue drain
performance
Mailbox
Architectural Considerations
Streaming backup support has been removed
Utilize direct-attached storage (DAS) solutions to reduce costs
with large mailboxes and continuous replication
Leverage the Storage Cost Calculator
Deploy Database Availability Groups (DAGs) and use replication
to achieve high availability
If deploying 3 or more database copies, consider RAID-less storage
design and combining logs and database on same spindles
Ensure unique database names across the organization
Attend UNC321 - Storage in Microsoft Exchange Server 2010 on
5/13 at 2:45pm
Attend UNC313 - High Availability in Microsoft Exchange Server
2010 on 5/13 at 1pm
Mailbox
Architectural Considerations
Large mailbox support (10 GB+) enables different scenarios
Deploy Office 2007 Service Pack 2 (SP2) or later
Leverage records management functionality
Scenario 1:
Deploy a single mailbox to contain all data
Scenario 2:
Deploy primary mailbox to support 1-2 years worth of data
Deploy archive mailboxes to allow end users to retain long-term needed
data
Attend UNC312 - Archiving and Retention in Microsoft Exchange
Server 2010 on 5/12 at 2:45pm
Public Folders
Co-existence support between Mailbox server 2010 and Mailbox
server 2003/2007
Outlook can access public folder data from Exchange 2010,
2007, or 2003
OWA 2010 only gives access to public folders with replicas
located on Exchange 2010
This is different from OWA 2007, which had a redirection behavior,
opening up OWA 2000/2003 for public folders on older mailbox servers
in separate browser windows
Get-PublicFolderStatistics now captures last user access
Unlike Exchange 2007, public folder stores can no longer be
enabled for continuous replication, but you can create a public
folder store on a mailbox server that resides in a DAG
Public Folder replication is your data resiliency solution
Agenda
Discuss the topology changes introduced in
Exchange Server 2010
Understand our guidance on server sizing
Scale Out vs. Scale Up
Scale out is a strategic choice made by
Microsoft
Focus is on supporting large mailboxes at low
cost, goal to further decrease input/output (I/O)
to reduce Total Cost of Ownership (TCO)
Scaling up increases risk that an outage or
failure affects more users
Scaling out provides an opportunity for high
availability at low cost
Processor Core Scalability
Single role servers
Beta: 12 cores maximum
No benefit moving to 16 cores from a performance
perspective
High scale all-in-one server—currently under
investigation
Beta: 16 cores max
Client Access
Beta Sizing Guidance
Since CAS role is now a true middle-tier
solution, CAS servers will require beefier
hardware
CAS to Mailbox processor core ratio changes
drastically as a result of RPCCA (Beta1: 3:4)
Processor/Memory requirements:
8 cores recommended
2 GB RAM/core recommended (8 GB min)
Transport
Beta Sizing Guidance
Memory and processor requirements are
staying inline with Exchange 2007 requirements
Processor/Memory requirements:
4 cores recommended
1 GB RAM/core recommended
Transport rule attachment scanning and content
encryption technologies may impact these
guidelines
Mailbox
Beta Sizing Guidance
Use 4 – 8 total cores for mailbox
16 cores shows decline in throughput on single role
machines
RAM
4GB base RAM for content indexing and mailbox assistants
2-8MB per mailbox recommended for database cache and
will be based on message profile and mailbox size
Example: Light Message Profile with 10+GB mailbox – 8MB memory
Size and prepare disks correctly
Use storage calculator
Unified Messaging
Beta Sizing Guidance
Use 4 cores
4-8 GB of RAM recommended
More than 8 GB is not shown to improve TCO or
scale
Not recommended combining with other roles
Audio quality can be affected
Place close to the mailbox servers that host UMenabled mailboxes
Voice mail preview may impact these guidelines
All-In-One Server Example
Branch Office or Smaller Deployment
8 processor cores
recommended
with a maximum
of 64GB RAM
UM role not
recommended for
co-location
CAS/HUB/
MAILBOX 1
CAS/HUB/
MAILBOX 2
Member servers of DAG
can host other server
roles
DB2
2 server DAGs, with
server roles combined
or not, should use RAID
Exchange 2010 Beta Ratio
Guidelines
Processor core ratios
Client Access Server (CAS) : Mailbox = 3 : 4
Hub Transport server : Mailbox
= 1 : 7 (no A/V on Hub)
= 1 : 5 (with A/V Hub)
Edge guidance expected to be very similar to
Exchange Server 2007
GC: Mailbox
= 1 : 4 (32–bit GC)
= 1 : 8 (64-bit GC)
Capacity Planning Tools
Profiling
Exchange Profile Analyzer (EPA)
Performance Monitor (Perfmon)
Sizing
Exchange Server 2010 Mailbox Storage
Requirements Calculator
Validation
Jetstress 2010
Exchange Load Generator “Loadgen”
Key Takeaways
Exchange Server 2010 introduces several paradigm shifts
Client connections are performed through Client Access Server role
Shadow redundancy introduces message resiliency within transport
pipeline
High Availability, store, and new compliance scenarios improve data
retention, resiliency, and availability
There are changes to server sizing and scalability, most notably
with CAS
Attend the deep-dive breakout sessions for more in-depth
information!
Resources
www.microsoft.com/teched
www.microsoft.com/learning
Sessions On-Demand & Community
Microsoft Certification & Training Resources
http://microsoft.com/technet
http://microsoft.com/msdn
Resources for IT Professionals
Resources for Developers
www.microsoft.com/learning
Microsoft Certification and Training Resources
Related Content
UNC314 – Information Protection and Control in Microsoft Exchange Server
2010
UNC315 – Federation in Microsoft Exchange Server 2010
UNC312 – Archiving and Retention in Microsoft Exchange Server 2010
UNC320 – Microsoft Exchange Server Outlook Web Access 2010: The Future
of Web-Based E-mail
UNC317 – Microsoft Exchange Server 2010 Management Tools
UNC318 – Microsoft Exchange Server 2010 Transition and Deployment
UNC313 – High Availability in Microsoft Exchange Server 2010
UNC321 – Storage in Microsoft Exchange server 2010
UNC324 – What's New in Exchange Web Services in Microsoft Exchange
Server 2010
UNC319 – Unified Messaging in Microsoft Exchange Server 2010
UNC308 – Microsoft Exchange Server 2007 SP1 and Microsoft Hyper-V: Dos
and Don'ts
Complete an
evaluation on
CommNet and
enter to win!
© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS,
IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.