From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Tue Jan 20 2004 - 16:29:43 GMT-3
At 2:01 PM -0500 1/20/04, rdanu wrote:
>I am trying to put together the pieces of a migration puzzle. The
>company I work for is thinking about a possible migration of their
>data center. I thought about several options but Id like to see
>what some of you seasoned professionals might advise. A brief
>scenario is described below, if you have any questions feel free to
>ask. I appreciate any feedback!
>
>Current setup:
>Location A contains 6 production VLANS, and customers access
>everything via a high speed (OC-3) Internet connection.
>
>Migration scenario:
>
>The goal is to transition all the servers from Location A to
>location B. The distance amongst locations is approximately 100
>miles. No down time is allowed.
You know, this "no down time" requirement seems to come up a lot. At
least here, it always seems to refer to the network. What about
server downtime? Are there server failover mechanisms now in place?
If there are, one quite rational strategy may be to implement the
cutover exploiting both the network and the servers. Keep customers
using the local server, move its backup, and then flip the
primary/secondary relationship. You might get suboptimal server load
balancing during the transition, but you aren't likely to have flat
downtime.
>
>Servers at Location A have subnet/VLAN information 10.1.1.0,
>10.1.2.0, 10.1.3.0. 10.1.6.0.
Again in the interest of reliability and flexibility, I'd make a very
strong case to have the servers accessed by DNS name, not IP address.
Client addresses should come from DHCP. Yes, I know there are
managements that don't want to change anything on the host side, but
they are spiting themselves in maintenance cost and availability of
failover.
I don't immediately see why, if you have DHCP-DNS, you can't have
different VLANs and host addressing. Things like VRRP very nicely
make things transparent on the host side. If you are using
third-party load balancers, they may be able to do much of the work.
>
>A private OC-3 will connect Location A to Location B.
>
>Servers will be moved to Location B in batches of 10. There are
>approximately 150 servers in total.
>
>The objective is, to keep all servers working together and allow
>them to co-exist on the same VLANS, at both locations.
Why is having the same VLAN so important, as long as you have exactly
the functional connectivity you need? If the servers are equivalent
and are simply load shared, a VRRP virtual address should give you
the same result. If the servers are on a separate subnet from the
client, routing can be very flexible in getting you to the right
place. If the servers have multiple NICs, VLAN capable NICs, or the
ability to support multiple IP addresses, you have lots more options.
Are you getting the idea that this shouldn't be looked at as a pure
network problem? Modestly, I will mention my own _WAN Survival
Guide_ (Wiley), with special reference to the parts on server
failover in distributed environments. You'll find I have an
extensive system for categorizing server and server cluster behavior
-- you really need to do this sort of definition before you can
design the proper network solution.
>
>Internet access will continue to be provided through Location A,
>until all servers have been migrated to Location B.
>
>In essence, how could the same exact VLANS (same subnets) co-exist
>and communicate with each other at both locations via a routed IP
>network? Is there a method to tunnel VLANS through an IP network?
Several ways, including MPLS and L2TPv3. Whether or not it is a good
idea is quite another matter.
>
>Location A contains CAT5500 Equipment. Location B will have CAT3750
>Cisco equipment, possibly 4500.
>
>Example:
>Out of a pool of 20 Web servers (Load Balanced at Location A from
>its Internet connection), about 10 will be moved to Location B in
>the 1st trip. We have to make sure that these moved servers will
>preserve the same IP address. The requirement is to have the 10
>Servers at Location A, and the 10 Servers at Location B work
>together, as if they were next to each other.
This archive was generated by hypermail 2.1.4 : Mon Feb 02 2004 - 09:07:48 GMT-3