Once you start testing your
environment, you may find that in some situations physical servers are
the best route. In this section we will look at several scenarios that
could lead to a positive virtualization experience. These scenarios are
not guarantees for success, but examples of what may
work. We will not be looking at the physical specifications for the
virtual hosts and storage. There will be discussions about the possible
hardware for both the virtual host and virtual guest, but this is just
an estimation of hardware that may be needed. These scenarios have not
been tested in a lab for performance. They are merely examples of what
could be virtualized.
1. Small Office/Remote or Branch Office
In this scenario, our office
has a relatively small number of users and we need to provide email
services to them. We have determined that users would be better off by
using local Exchange servers instead of pulling email across the WAN. We
want to provide redundancy and high availability where possible.
As we start to build this
solution, we must determine which virtual guest roles will have to be
placed on which virtual hosts. We see that there will be a need for the
following:
Because the users are in a remote
office, we will be supplying directory services as well. It has been
determined, through research, interviews with staff members, and data
collection, that our users are light email users. The CAS and Hub
Transport roles will be combined, and we will be providing high
availability via DAG. We have also found a requirement for site
resilience. We will be fulfilling the requirement by adding a server at
the main datacenter into the DAG.
We can put this solution
together with only three physical servers and storage. Again, the exact
specifications on the servers and storage are not being discussed. When
we create the DAG, it will automatically place the file share witness,
but in our solution we will have to specify the correct location for the
file share witness. We need to ensure that we do not create an issue
where the file share witness ends up being on the same virtual host as a
Mailbox server in the DAG. If this were to happen and we created the
file share witness on virtual host 2, then we'd have two voting members
of the DAG on the same physical hardware. This is not a recommended
solution. We can move the file share witness from the Exchange
Management Console (EMC) or the Exchange Management Shell (EMS).
Virtual Host 1 will have the following virtual guests:
Domain Controller 1
CAS and Hub Transport 1
Virtual Host 2 will have the following virtual guests:
Domain Controller 2
Mailbox Server 1
Virtual Host 3 will have the following virtual guests:
CAS and Hub Transport 2
Mailbox Server 2
As you can see, the
physical servers would probably not be overutilized with the current
workloads that we have placed on them. If you add a file server cluster
into the mix, make sure that the virtual host has enough resources to
perform the additional work. So instead of having six servers in use,
you will have three servers, or a 50 percent reduction in servers for
this location.
2. Site Resilience
In this scenario, we are going
to be setting up a second location for site resilience. We are assuming
that the primary datacenter is fully functional with Exchange 2010
physical servers. We have been handed a new requirement that states we
will be providing site resilience for all users in our organization. We
have also been told that we will need to provide the same level of
performance and reliability as the primary datacenter. Our primary
datacenter information is listed here:
Four Mailbox servers in a DAG (four processors and 16 GB of RAM each)
Three CAS servers (four processors and 8 GB of RAM each)
Two Hub Transport servers (four processors and 8 GB of RAM each)
So to meet the
requirements we will be deploying four physical servers to host 11
virtual guests. These 11 guests include four domain controllers. We are
using four domain controllers to keep the number of virtual processors
and RAM down on each domain controller.
We will need five physical
servers for the solution. For ease of ordering, we will order all
servers with the same hardware specifications. They will have four
quad-core processors and 32 GB of RAM for each virtual host. A breakdown
of virtual guests and the virtual host to which they belong follows.
Since we have to provide the same level of performance as the primary
datacenter, we will leave the CAS and Hub Transport servers separated.
If we didn't have the requirement to meet performance for the primary
datacenter, we could have combined the CAS and Hub Transport roles and
possibly met the performance needs on four physical servers.
Virtual Host 1 will have the following virtual guests:
Domain Controller 1 (four processors and 4 GB of RAM)
Mailbox Server 1 (four processors and 16 GB of RAM)
CAS Server 1 (four processors and 8 GB of RAM)
Virtual Host 2 will have the following virtual guests:
Virtual Host 3 will have the following virtual guests:
Virtual Host 4 will have the following virtual guests:
Virtual Host 5 will have the following virtual guests:
You are probably wondering
where we are going to put the file share witness since there is a
Mailbox server on each of the virtual hosts. In this scenario, it is
fine to let Exchange place the file share witness. You may recall that
the file share witness is only used when there is an even number of
servers in the DAG. We do have that here, but there are enough servers
to separate the witness without putting the DAG in jeopardy.
By separating the virtual
guests across four virtual hosts, we have accomplished the task at
hand. If we had chosen to mirror the production environment and use
physical servers, we would have needed nine servers plus the domain
controllers. At a minimum, we cut our servers by 50 percent if not more
with the inclusion of the domain controllers. The flip side of this is
that we probably increased the number of processors and RAM in the
virtual hosts. By doing this, we also increased the cost of the virtual
hosts. It may have not been much, but that is something you would
calculate before implementing this solution.
3. Mobile Scenario
For the mobile solution, we are
going to look at a customer that has a requirement to react to an
emergency quickly. They need to have their entire infrastructure
physically with them. They do not need to tie back into a corporate
environment, but they will be connecting to the Internet and must be
able to send and receive email and surf the Internet. They also require a
database server, file/print capabilities, and collaboration. There will
be an external appliance to provide firewall protection. This is also
considered a short-term solution. Once the disaster is over or a
permanent datacenter has been established, the mobile solution will be
decommissioned. This solution brings in several different technologies
in addition to Exchange.
The customer has only 50 users,
but they will be sending and receiving a large amount of email. With
this number of users, there will not be a huge draw on any of the
servers. Knowing this, we are able to pull back on some of the server
requirements. We can keep the file share witness separated from the
Mailbox servers and stay within the recommendations of Microsoft. We
will place a node of the database cluster on the same virtual host as
one of the Mailbox servers. This is not a recommended solution, but
since we are looking at a temporary solution with limited users, we
should be fine with the layout.
Virtual Host 1 will have the following virtual guests:
Domain Controller 1 (two processors and 4 GB of RAM)
Mailbox Server 1 (four processors and 8 GB of RAM)
CAS and Hub Transport 1 (four processors and 8 GB of RAM)
Database Server Node 1 (four processors and 8 GB of RAM)
Virtual Host 2 will have the following virtual guests:
Domain Controller 2 (two processors and 4 GB of RAM)
Mailbox Server 2 (four processors and 8 GB of RAM)
Collaboration Server 2 (four processors and 8 GB of RAM)
File and Print Node 1(two processors and 8 GB of RAM)
Virtual Host 3 will have the following virtual guests:
File and Print Node 2 (two processors and 8 GB of RAM)
CAS and Hub Transport 2 (four processors and 8 GB of RAM)
Database server node 2 (four processors and 8 GB of RAM)
Collaboration server 2 (four processors and 8 GB of RAM)
We are able to meet the
requirements for the customer with only three physical servers. Each
server will have four dual-core processors and 32 GB of RAM. If during
testing we decide that we would need an additional server, we can add
another server. Looking at the numbers, you can see that we have
decreased the number of servers from twelve to three, which is a 75
percent reduction.
You will find that there are
plenty of times for you to virtualize Exchange. One of the times to
virtualize is in the lab. When you virtualize your lab, you can either
do an equal virtualization to what is going to be in production, or you
can have a different layout. There are benefits to both.
If you are able to duplicate
the lab and production, you can include performance testing. Duplicating
the lab to production does not only mean matching the number of servers
and role designations, but also determining whether or not they will be
physical servers. If you are going to virtualize in production, this
test will give you accurate results and a baseline for the production
environment. You will also increase the hardware requirement for the
virtual hosts and the storage that you will be using.
If you are not able to
duplicate the lab, you must prepare yourself and management that the lab
is for functional testing only. If you were to do any performance
testing, the results would not be accurate. By using this method, you
will save on hardware for the virtual hosts and storage.
Both
scenarios will give you a good base for testing your virtualized
Exchange environment. One gives you the ability to test performance and
functionality with an added hardware cost, while the other gives you the
ability to do a functionality test with minimal hardware costs.
