Migrating Exchange 2010 to Dell
Advanced Infrastructure Manager
Environment
A Dell Technical White Paper
Global Solutions Engineering Team
Feedback:
solutionfeedback@dell.com
Migrating Exchange 2010 To Dell Advanced Infrastructure Manager Environment
THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL
ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR
IMPLIED WARRANTIES OF ANY KIND.
Dell, the DELL logo, PowerEdge, PowerConnect, PowerVault, and EqualLogic are trademarks of Dell
Inc. Symantec and the SYMANTEC logo are trademarks or registered trademarks of Symantec
Corporation or its affiliates in the USand other countries. Microsoft, Windows, Windows Server, and
Active Directory are either trademarks or registered trademarks of Microsoft Corporation in the United
States and/or other countries. Other trademarks and trade names may be used in this document to
refer to either the entities claiming the marks and names or their products. Dell Inc. disclaims any
proprietary interest in trademarks and trade names other than its own.
November 2011
Page ii
Migrating Exchange 2010 To Dell Advanced Infrastructure Manager Environment
Migrating Exchange 2010 To Dell Advanced Infrastructure Manager Environment
Introduction
Dell Advanced Infrastructure Manager (AIM) is datacenter software that manages an environment so
that workloads can be isolated from the underlying hardware. AIM changes the traditional way in which
elements of the datacenter are managed: it controls the logical networks and the server boot
environment. Using AIM, you can create a pool of backup servers that are ready to step in and do the
work of any failed server. The pool allows adding or reducing the number of servers fulfilling the
service availability needs provided by the datacenter based, for example, on computational load.
This paper describes a method to integrate an existing Microsoft™ Exchange 2010 SP1 (henceforth
referred to as Exchange 2010) ecosystem with AIM environment by taking advantage of Exchange 2010‘s
native high availability – a Brownfield scenario. It also provides guidelines to freshly deploy Exchange
2010 into AIM environment – a Greenfield scenario. The environment that provides flexibility in
managing a datacenter should also be validated for ease of integrating workloads to it. It should be
ensured the environment does not hamper the performance of the workloads it supports.
The paper summarizes the results of lab exercises for Exchange 2010 running in a standalone (without
being managed by AIM) environment and in an AIM-managed environment. The performance comparison
over these scenarios indicates that IT departments can take advantage of AIM while seeing minimal
impact on the performance of their Exchange 2010 infrastructure. The primary measures for
performance were: Exchange Database Read Latencies, Exchange Database Write Latencies, and
Exchange Log Write Latencies.
Audience and Scope
This whitepaper is intended for sales engineers, IT administrators, and field engineers interested in
quickly getting a grip on Dell AIM and Exchange 2010 co-existence. The paper covers Exchange 2010
migration to an AIM environment as a series of summarized steps both in Brownfield and Greenfield
scenarios.
In order to ensure that the AIM environment would not affect Exchange 2010 performance, lab results
for running Loadgen (an Exchange sizing tool from Microsoft) in a standalone Exchange environment
and in an AIM managed environment have been shown as proof points. The paper helps answer the
following concerns:
- Is there a performance impact for Outlook users connecting to Exchange on AIM versus an
identical deployment without AIM?
- How can the boot- and application-specific networks be provisioned effectively in an AIM
environment?
- How do field engineers and administrators migrate their Exchange deployments to AIM with
minimal impact to the organization‘s users?
Page 4
Migrating Exchange 2010 To Dell Advanced Infrastructure Manager Environment
2x PowerConnectTM 6248s - used as top of rack switches
6x PowerConnect M6220s:
Modular switch fabric A: modular switches A1 and A2 (2x PowerConnect M6220s)
Modular switch fabric B: modular switches B1 and B2 (2x PowerConnect M6220s)
Modular switch fabric C: modular switches C1 and C2 (2x PowerConnect M6220s)
Hardware Summary
This section provides an overview of the hardware used to study Exchange 2010 with AIM.
Table 1. Hardware used in this study
Dell AIM and Its Components
Dell AIM is enterprise class software that allows you to detach your workload and its execution
environment (the Operating System (OS)) from your server hardware. AIM achieves this by supporting
Preboot Execution Environment (PXE) boot of an OS from a Storage Area Network (SAN). The operating
system and application no longer reside on the server‘s local hard drive, but are instead LUNs carved
out of a SAN. Along with central booting, AIM manages the switches and networking for the net booted
operating systems. Dell AIM and its environment primarily consist of following components:
AIM Controller
The Dell AIM controller is software that can manage both physical and virtual servers in a datacenter
environment. It runs on a dedicated server, and communicates with the environment via the existing
network infrastructure. The Controller also hosts the Dell AIM Console, a web-based user interface that
can be used to monitor and work with the elements in the Dell AIM environment. Apart from the webbased interface, it provides both a Command-line Interface (CLI) and Application Programming
Interfaces (APIs).
Personas
AIM uses the concept of personas to isolate the application and its operating system from underlying
hardware. Personas are server environments captured on disk—the operating system, optional Dell AIM
agent software, application software, and networking components. The Dell AIM agent is a software
utility you can install when you create the persona; the agent reports detailed persona status to the
Controller and configures networking and other settings on the persona at the direction of the
Controller. Personas can reside on a server‘s local disk or on any of a number of types of Ethernet or
Fibre Channel network storage resources, including NAS, iSCSI, and SAN-based storage servers. When a
persona resides on network storage, the Controller can assign it to any appropriate network-bootable
server, or retarget it to a backup server in case the first server fails. In this paper we consider iSCSI
booted personas.
Management Consoles
There are two primary interfaces for managing and configuring an AIM 3.4 environment. The first is the
management web console accessed through an IP address entered during the start of controller setup.
The second is the CLI provided with the Software Development Kit (SDK), through which administrators
can enter commands in auto-complete mode. The CLI is used to configure switch parameters, add and
remove resources from the AIM environment, and etc. Once configured, the switches are managed by
AIM, and the management console can be used for most tasks.
Page 5
Migrating Exchange 2010 To Dell Advanced Infrastructure Manager Environment
1
Using AIM, CLI commands are applied to the database immediately upon submitting the configuration
changes. The Controller maintains a database of the resources identified in the Dell AIM environment.
When users connect to the Controller by using the Console or the CLI, the Controller projects to the
Console or CLI a copy of the most current database to monitor and change. When you make changes to
the database using the Console or CLI (adding a resource, changing a network, starting a persona, and
so on), the changes are committed to the database using the ‗save‘ command. The commands used to
interact with the controller are listed in later sections.
Networking with AIM
Analogous to physical networks, AIM networks are logical constructs with IPv4 network address and
network masks. These logical constructs behave the same way in a Dell AIM managed environment as
do conventional networks, except that they‘re built out of Virtual Local Area Networks (VLANs) over
physical Network Interface Cards (NICs), switches, and cables. AIM networks are easy to create and
manage compared to physical networks as they do not require any re-wiring of your network
infrastructure. Many networks can be added to the AIM environment even if there is only a single
physical NIC available. The number of AIM networks is limited by the number of VLANs supported by
physical switches.
AIM organizes physical network resources into channels, and a channel ID is assigned to each managed
switch. An AIM managed switch has default channel 1 for all its ports, which should be changed based
on your network configuration. For example, you can have your AIM bootable NIC‘s on channel 1, MAPI
network on channel 3, and Replication Network on channel 4.
The Controller uses the System Control Network (SCN), which is an AIM-defined logical network used to
discover new servers and their capabilities, to communicate status and configuration changes between
itself and personas, to connect servers with the network storage devices that contain the images that
personas boot from, and to manage many other aspects of how personas are configured, including how
they are connected to networks. AIM personas connect to AIM networks through Network Connections.
Personas have hidden network connections to the SCN. A persona can be configured to have its
networking in trunk, access or auto mode by configuring the ‗Mode‘ parameter of the persona.
When the network mode is set to trunk, each physical network interface on the persona is configured
so it can access multiple VLANs. This means that the Dell AIM software agent will create tagged
network interfaces on top of the physical interfaces in the operating system, and then configure all the
networking settings required by the persona‘s network connections using those interfaces. Additional
network interfaces are observed at the operating system level. The persona in trunk mode performs
efficiently provided the operating system has the Dell AIM agent software installed. AIM agent software
communicates with the controller and helps configure networks dynamically on the operating system.
AIM agent software also helps the controller to monitor the health of the server on which the persona is
booted. Every switch port to which the persona is connected will be configured in trunk mode with the
user VLANs added to the list of allowed VLANs as required by the persona‘s network connections. AIM
persona networks in trunk mode1 can combine traffic from multiple VLANs and hence provide ways to
configure failover channels for network interfaces.
In access mode, the network interfaces on the operating system are managed by AIM. However, the
access mode of the persona configures each network interface on the on the operating system to
access a single VLAN. This means that no additional network interfaces are created at the operating
AIM personas in trunk mode do not support jumbo frames at present.
Page 6
Migrating Exchange 2010 To Dell Advanced Infrastructure Manager Environment
system and the agent will configure all the networking settings required by the persona‘s network
connections directly on the existing network interfaces. The concept of NIC failover does not apply to
access mode since usually a single channel is assigned to each NIC.
In certain scenarios, a persona may be migrated from a physical server to a virtual server (virtual
machine) or vice versa. In such scenarios, Dell recommends that you set the persona mode to auto. In
auto mode, the AIM controller automatically picks either the access or trunk mode depending on
whether the persona is booted on a physical server or a virtual machine. If the persona is booted on a
physical server the mode will be set to trunk, and if the persona is booted on a virtual machine the
mode will be set to access.
AIM relies on centralized booting mechanisms in order to decouple an application/workload and its
execution environment (OS) from the underlying hardware. In this paper we consider iSCSI/PXE boot
from SAN as one of the methods of central booting. Centralized booting involves boot through Network
Interface Cards (NICs), and AIM prefers two NICs for SAN-booted operating systems. Two NICs help
provide redundancy and protect against boot NIC failures. We allocate two NICs associated with
modular switch fabrics C1 and C2 (fabric C) listed in Table-1 for boot NICs. Fabric C is assumed to be
unused in the Exchange-only environment. Fabric B (Table-1) is used for the Exchange iSCSI database
network, and Fabric A (Table -1) is used for both Exchange MAPI and replication networks.
Overview of Exchange
Microsoft Exchange Server is one of the leading enterprise messaging systems. Exchange 2010 is
comprised of multiple sub-systems, which are also known as server roles. A server role is an application
layer entity and multiple roles can be collocated on a single machine. Here is a quick overview of the
Exchange 2010 server roles:
1.Mailbox Server (MBX): A back-end server capable of hosting mailboxes and public folders.
Multiple MBX roles can be clustered using a Database Availability Group or DAG.
2.Client Access Sever (CAS): A server role that supports all messaging clients such as Outlook,
etc. and Exchange Web Services.
3.Hub Transport Server (Hub): A routing server that routes a message within the Exchange
organization.
4.Edge-Transport Server (Edge): A server role residing on the edge of the topology that routes
messages in and out of the Exchange organization.
5.Unified Messaging Server (UM): A server role that connects a PBX system to the Exchange
topology and helps combine voice and email messages into a single messaging infrastructure.
Note that this role is presently not supported on a Virtual Machine.
All server roles except the Edge Transport role can be collocated as a multi-role Exchange server. A
Domain Controller (Active Directory role) is required for Exchange 2010, and primarily provides user
authentication and domain name services to Exchange users. For the purposes of this paper, the
Mailbox, Client Access and Hub Transport roles are most relevant. A solution summary for 1800 users is
shown below in Table 2.
Exchange Database Availability Group
A Database Availability Group (DAG) forms the basis of native High Availability (HA) provided by
Exchange 2010. Essentially, a DAG is a cluster of mailbox servers responsible for hosting databases. In
case of failures affecting servers or storage, this cluster ensures availability at the database level. In
order to ensure high availability, databases have one active copy and one or more passive copies. In
Page 7
Migrating Exchange 2010 To Dell Advanced Infrastructure Manager Environment
Number of mailboxes
1800
Average user I/O profile (messages/day)
.15 IOPS (~160 messages/day)
Average mailbox size limit
512MB
Total active/passive copies per database
2
Not included in this solution
Backup and recovery infrastructure
Disaster recovery or site resiliency
UM and Edge roles
Server Configurations
Detail
Multi-role (Mailbox/Hub/CAS) server
2x PowerEdge M610 servers
2x quad-core processors and 48GB of RAM
Active Directory servers
2x PowerEdge M610 server
2x quad-core processors and 48GB of RAM
Number of DAGs
1
Servers per DAG
2
Number of Active and Passive Mailboxes per
Server
900 active + 900 passive
Storage Configuration
Details
Storage hardware
2x EqualLogic PS6000E
16 drives each; 32 total drives
Data volumes per mailbox server
2
Databases per volume
1
Mailboxes per database
900
Disk type
3.5‖ 7.2k rpm SATA – 500GB
RAID type
RAID 10
Additional details
Databases and logs combined;
1 volume = 1 DB + 1 Log
38% estimated capacity for growth
NTFS allocation unit size = 64KB
case of failure to access an active copy of a database, one of the passive copies of the database is
activated to provide availability.
AIM‘s high availability complements Exchange DAG. As an example scenario, consider an infrastructure
which already has two Exchange 2010 mailbox servers that are in a Database Availability Group (DAG).
If one of these servers fails, the other active server can mount those database copies. The AIM
controller will then detect that there has been a failure in the managed pool and will re-target the
failed operating system image along with the application on to the stand-by server. The original
distribution of databases can then be restored on the running servers. A pool of servers can be assigned
to these personas or images on SAN. AIM can automatically restore normalcy or provide availability to
IT environments.
Exchange Sample Solution Summary
Table 2. Exchange 2010 test solution summary
For the above deployment, 48 GB of RAM was used across the board for non-AIM and AIM environment
test results. As explored in the results section, 20 GB per server should be sufficient.
Exchange has its own application-specific networks, namely the public/MAPI (Messaging API) network,
primarily used by Active Directory/Domain controller to communicate to the mailbox servers and a
private/replication network used for log-based synchronization of databases in the Database
Page 8
Loading...
+ 23 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.