2 Project Of Building The Data Centre For University Campus
Contents
Contents................................................................................................................................................2
Introduction to Data Centre..................................................................................................................6
1.Data Center Network Design:.............................................................................................................6
2.Data Center Network Application Architecture Models: ...................................................................9
2.1The Client/Server Model and Its Evolution:..................................................................................9
2.2The n-Tier Model........................................................................................................................10
2.3Multitier Architecture Application Environment:.......................................................................12
2.4Types of Server Farms:................................................................................................................13
2.4.1Internet Server Farms:.........................................................................................................13
2.4.2Intranet Server Farms:.........................................................................................................16
2.4.3Extranet Server Farm ..........................................................................................................17
3.Data Center Architecture:.................................................................................................................19
3.1Aggregation Layer:......................................................................................................................20
3.2Access Layer:...............................................................................................................................22
3.2.1Front-End Segment..............................................................................................................22
3.2.2Application Segment:...........................................................................................................23
3.2.3Back-End Segments:.............................................................................................................26
3.3Storage Layer:.............................................................................................................................26
3.4Data Center Transport Layer:......................................................................................................29
4.Data Center Topologies:...................................................................................................................31
4.1Generic Layer 3/Layer 2 Designs:................................................................................................31
4.1.1The Need for Layer 2 at the Access Layer:...........................................................................35
4.2Alternate Layer 3/Layer 2 Designs:.............................................................................................37
4.3Multiple-Tier Designs..................................................................................................................38
4.4Expanded Multitier Design:........................................................................................................41
System And Network Administration

4.5Collapsed Multitier Design:.........................................................................................................43
4.6Fully Redundant Layer 2 and Layer 3 Designs:............................................................................45
4.6.1The Need for Redundancy:..................................................................................................45
5.Data Center Services.........................................................................................................................53
5.1IP Infrastructure Services:...........................................................................................................55
5.2Application Services:...................................................................................................................57
5.2.1Service Deployment Options:..............................................................................................57
5.2.2Design Considerations with Service Devices:.......................................................................59
5.3Security Services:........................................................................................................................61
5.4Storage Services..........................................................................................................................62

Table of Figures
Figure 1 Data Centre..............................................................................................................................8
Figure 2 Client/Server n-Tier Applications.............................................................................................9
Figure 3 n-tier Model...........................................................................................................................11
Figure 4 Multitier Architecture Application Environment....................................................................12
Figure 5 Internet Server Farm..............................................................................................................15
Figure 6 DMZ Server Farm...................................................................................................................15
Figure 7 Intranet Server Farm..............................................................................................................17
Figure 8 Extranet Server Farm.............................................................................................................17
Figure 9 Data center architecture........................................................................................................19
Figure 10 Aggregation and Access layer..............................................................................................21
Figure 11 Access layer segments.........................................................................................................25
Figure 12 Storage and Transport layers...............................................................................................28
Figure 13 Generic Layer 3/Layer 2 Designs..........................................................................................32
Figure 14..............................................................................................................................................34
Figure 15 The Need for Layer 2 at the Access Layer............................................................................37
Figure 16 Multiple-Tier Designs...........................................................................................................40
Figure 17 Expanded Multitier Design...................................................................................................42
Figure 18 Collapsed Multitier Design...................................................................................................43
Figure 19 The Need for Redundancy....................................................................................................46
Figure 20 Layer 2 and Layer 3 in Access Layer.....................................................................................47
Figure 21 Layer 2, Loops, and Spanning Tree.......................................................................................49
Figure 22 Layer 2, Loops, and Spanning Tree.......................................................................................50
Figure 23..............................................................................................................................................51
Figure 24..............................................................................................................................................52
Figure 25 Data Center Services............................................................................................................53

Figure 26 Service Deployment Options................................................................................................58
Figure 27 Design Considerations with Service Devices........................................................................60

Introduction to Data Centre
A data center is a centralized repository, either physical or virtual, for the storage,
management, and dissemination of data and information organized around a particular body
of knowledge or pertaining to a particular business/education.
Data center can be classified as either:
Enterprise (Private):
Privately owned and operated by private corporate, institutional or government entitles.
Co-Location/Hosting (Public):
Owned and operated by Telco’s or service providers.
In this document we will propose enterprise data center model.
Data Centers house critical computing resources in controlled environments and under
centralized management, which enable enterprises to operate around the clock or according to
their business/educational needs. These computing resources include mainframes, web and
application servers, file and print servers, messaging servers, application software and the
operating systems that run them, storage subsystems, and the network infrastructure, whether
IP or storage-area network (SAN). Applications range from internal financial and human
resources to external e-commerce and business-to-business applications. Additionally, a
number of servers support network operations and network-based applications. Network
operation applications include Network Time Protocol (NTP), TN3270, FTP, Domain Name
System (DNS), Dynamic Host Configuration Protocol (DHCP), Simple Network
Management Protocol (SNMP), TFTP, Network File System (NFS), and network-based
applications, including IP telephony, video streaming over IP, IP video conferencing.
1. Data Center Network Design:

The following section summarizes some of the technical considerations for designing a
modern day data center network.
• Infrastructure Services: Routing, switching, and server-farm architecture.
• Application Services: Load balancing, Secure Socket Layer (SSL) offloading, and caching.
• Security Services: Packet filtering and inspection, intrusion detection, and intrusion
prevention.
• Storage Services: SAN architecture, Fiber Channel switching, backup, and archival.
• Campus Continuance: SAN extension, site selection, and Data Center interconnectivity.
Data Center Roles:
Figure 1 presents the different building blocks used in the enterprise network and illustrates
the location of the Data Center within that architecture.
The building blocks of this typical enterprise network include:
• Campus Network:
• Private WAN:
• Remote Access:
• Internet Server Farm:
• Extranet Server Farm:
• Intranet Server Farm:
Data Centers typically house many components that support the infrastructure building
blocks, such as the core switches of the campus network or the edge routers of the private
WAN. Data Center designs can include any or all of the building blocks in Figure 1-1,
including any or all server farm types. Each type of server farm can be a separate physical
entity, depending on the business requirements of the enterprise. For example, a company
might build a single Data Center and share all resources, such as servers, firewalls, routers,
switches, and so on. Another company might require that the three server farms be physically

separated with no shared equipment.
Figure 1 Data Centre
Data Centers in service provider (SP) environments, known as Internet Data Centers (IDCs),
unlike in enterprise environments, are the source of revenue that supports collocated server
farms for enterprise customers. The SP Data Center is a service-oriented environment built
to house, or host, an enterprise customer’s application environment under tightly controlled
SLAs for uptime and availability. Enterprises also build IDCs when the sole reason for the
Data Center is to support Internet-facing applications.

2. Data Center Network Application Architecture Models:
Architectures are constantly evolving, adapting to new requirements, and using
new technologies. The most pervasive models are the client/server and n-tier models that
refer to how applications use the functional elements of communication exchange. The
client/server model, in fact, has evolved to the n-tier model, which most enterprise software
application vendors currently use in application architectures. This section introduces both
models and the evolutionary steps from client/server to the n-tier models.
2.1 The Client/Server Model and Its Evolution:
The classic client/server model describes the communication between an application and a
user through the use of a server and a client. The classic client/server model consists of the
following:
• A thick client that provides a graphical user interface (GUI) on top of an application
or business logic where some processing occurs
• A server where the remaining business logic resides
Thick client is an expression referring to the complexity of the business logic (software)
required on the client side and the necessary hardware to support it. A thick client is then a
portion of the application code running at the client’s computer that has the responsibility of
retrieving data from the server and presenting it to the client. The thick client code requires a
fair amount of processing capacity and resources to run in addition to the management
overhead caused by loading and maintaining it on the client base. The server side is a single
server running the presentation, application, and database code that uses multiple internal
processes to communicate information across these distinct functions. The exchange of
information between client and server is mostly data because the thick client performs local
presentation functions so that the end user can interact with the application using a local user
interface.
Client/server applications are still widely used, yet the client and server use proprietary
interfaces and message formats that different applications cannot easily share. Part a of
Figure 2 shows the client/server model.
Figure 2 Client/Server n-Tier Applications

The most fundamental changes to the thick client and single-server model started when
web-based applications first appeared. Web-based applications rely on more standard
interfaces and message formats where applications are easier to share. HTML and HTTP
provide a standard framework that allows generic clients such as web browsers to
communicate with generic applications as long as they use web servers for the presentation
function. HTML describes how the client should render the data; HTTP is the transport
protocol used to carry HTML data. Netscape Communicator and Microsoft Internet Explorer
are examples of clients (web browsers); Apache, Netscape Enterprise Server, and Microsoft
Internet Information Server (IIS) are examples of web servers. The migration from the classic
client/server to a web-based architecture implies the use of thin clients (web browsers), web
servers, application servers, and database servers. The web browser interacts with web
servers and application servers, and the web servers interact with application servers and
database servers. These distinct functions supported by the servers are referred to as tiers,
which, in addition to the client tier, refer to the n-tier model.
2.2 The n-Tier Model

Part b of Figure 2 shows the n-tier model. Figure 2 presents the evolution from the
classic client/server model to the n-tier model. The client/server model uses the thick client
with its own business logic and GUI to interact with a server that provides the counterpart
business logic and database functions on the same physical device. The n-tier model uses a
thin client and a web browser to access the data in many different ways. The server side of
the n-tier model is divided into distinct functional areas that include the web, application,
and database servers.
The n-tier model relies on a standard web architecture where the web browser formats and
presents the information received from the web server. The server side in the web
architecture consists of multiple and distinct servers that are functionally separate. The n-tier
model can be the client and a web server; or the client, the web server, and an application
server. This model is more scalable and manageable, and even though it is more complex
than the classic client/server model, it enables application environments to evolve toward
distributed computing environments.
The n-tier model marks a significant step in the evolution of distributed computing from
the classic client/server model. The n-tier model provides a mechanism to increase
performance and maintainability of client/server applications while the control and
management of application code is simplified.
Figure 3 introduces the n-tier model and maps each tier to a partial list of currently
available technologies at each tier.
Figure 3 n-tier Model

2.3 Multitier Architecture Application Environment:
Multitier architectures refer to the Data Center server farms supporting applications that
provide a logical and physical separation between various application functions, such as
web, application, and database (n-tier model). The network architecture is then dictated by
the requirements of applications in use and their specific availability, scalability, and security
and management goals. For each server-side tier, there is a one-to-one mapping to a network
segment that supports the specific application function and its requirements. Because
the resulting network segments are closely aligned with the tiered applications, they are
described in reference to the different application tiers.
Figure 4 presents the mapping from the n-tier model to the supporting network segments
used in a multitier design.
Figure 4 Multitier Architecture Application Environment

The web server tier is mapped to the front-end segment, the business logic to the application
segment, and the database tier to the back-end segment. Notice that all the segments
supporting the server farm connect to access layer switches, which in a multitier architecture
are different access switches supporting the various server functions.
2.4 Types of Server Farms:
As depicted in Figure 1, three distinct types of server farms exist:
• Internet
• Extranet
• Intranet
All three types reside in a Data Center and often in the same Data Center facility, which
generally is referred to as the corporate Data Center or enterprise Data Center. If the sole
purpose of the Data Center is to support Internet-facing applications and server farms, the
Data Center is referred to as an Internet Data Center.
Server farms are at the heart of the Data Center. In fact, Data Centers are built to support at
least one type of server farm. Although different types of server farms share many
architectural requirements, their objectives differ. Thus, the particular set of Data Center
requirements depends on which type of server farm must be supported. Each type of server
farm has a distinct set of infrastructure, security, and management requirements that must be
addressed in the design of the server farm. Although each server farm design and its specific
topology might be different, the design guidelines apply equally to them all. The following
sections introduce server farms.
2.4.1 Internet Server Farms:

As their name indicates, Internet server farms face the Internet. This implies that users
accessing the server farms primarily are located somewhere on the Internet and use the
Internet to reach the server farm. Internet server farms are then available to the Internet
community at large and support consumer services. Typically, internal users
also have access to the Internet server farms. The server farm services and their users rely
on the use of web interfaces and web browsers, which makes them pervasive on Internet
environments.
Two distinct types of Internet server farms exist. The dedicated Internet server farm, shown
in Figure 5, is built to support large-scale Internet-facing applications that support the
core business function. Typically, the core business function is based on an Internet
presence or Internet commerce.
Security and scalability are a major concern in this type of server farm. On one hand, most
users accessing the server farm are located on the Internet, thereby introducing higher
security risks; on the other hand, the number of likely users is very high, which could easily
cause scalability problems.
The Data Center that supports this type of server farm is often referred to as an Internet Data
Center (IDC). IDCs are built both by enterprises to support their own e-business
infrastructure and by service providers selling hosting services, thus allowing enterprises to
collocate the e-business infrastructure in the provider’s network.
The next type of Internet server farm, shown in Figure 6, is built to support Internet-based
applications in addition to Internet access from the enterprise. This means that the
infrastructure supporting the server farms also is used to support Internet access from
enterprise users. These server farms typically are located in the demilitarized zone (DMZ)
because they are part of the enterprise network yet are accessible from the Internet. These
server farms are referred to as DMZ server farms, to differentiate them from the dedicated
Internet server farms.
These server farms support services such as e-commerce and are the access door to portals
for more generic applications used by both Internet and intranet users. The scalability
considerations depend on how large the expected user base is. Security requirements are
also very stringent because the security policies are aimed at protecting the server farms
from external users while keeping the enterprise’s network safe. Note that, under this
model, the enterprise network supports the campus, the private WAN, and the intranet
server farm.

Figure 5 Internet Server Farm
Figure 6 DMZ Server Farm

2.4.2 Intranet Server Farms:
The evolution of the client/server model and the wide adoption of web-based applications
on the Internet was the foundation for building intranets. Intranet server farms resemble the
Internet server farms in their ease of access, yet they are available only to the enterprise’s
internal users.
Notice that the intranet server farm module is connected to the core switches that form a
portion of the enterprise backbone and provide connectivity between the private WAN and
Internet Edge modules. The users accessing the intranet server farm are located in the campus
and private WAN. Internet users typically are not permitted access to the intranet; however,
internal users using the Internet as transport have access to the intranet using virtual
private network (VPN) technology.
The Internet Edge module supports several functions that include the following:
• Securing the enterprise network
• Controlling Internet access from the intranet
• Controlling access to the Internet server farms
The Data Center provides additional security to further protect the data in the intranet server
farm. This is accomplished by applying the security policies to the edge of the Data Center
as well as to the applicable application tiers when attempting to harden communication
between servers on different tiers. The security design applied to each tier depends on the
architecture of the applications and the desired security level.

Figure 7 Intranet Server Farm
2.4.3 Extranet Server Farm
From a functional perspective, extranet server farms sit between Internet and intranet
server farms. Extranet server farms continue the trend of using web-based applications, but,
unlike Internet- or intranet-based server farms, they are accessed only by a selected group of
users that are neither Internet- nor intranet-based. The main purpose for extranets is to
improve business-to-business communication by allowing faster exchange of
information in a user-friendly and secure environment. The purpose of the extranet is to
provide server farm services to trusted external end users, there are special security
considerations. Many factors must be considered in the design of the extranet topology,
including scalability, availability, and security. Dedicated firewalls and routers in the extranet
are the result of a highly secure and scalable network infrastructure for partner connectivity.
Notice that the extranet server farm is accessible to internal users, yet access from the
extranet to the intranet is prevented or highly secured. Typically, access from the extranet to
the intranet is restricted through the use of firewalls.
Figure 8 Extranet Server Farm

3. Data Center Architecture:
The focus of this section is the architecture of a generic enterprise data center connected to
the Internet and supporting an intranet server farm.
Architecture of an IP network that supports server farms, we include explanations pertaining
to how the server farms are connected to the rest of the enterprise network for the sake of
clarity and thoroughness. The core connectivity functions supported by Data Centers are
Internet Edge connectivity, campus connectivity, and server-farm connectivity.
The Internet Edge provides the connectivity from the enterprise to the Internet and its
associated redundancy and security functions, such as the following:
• Redundant connections to different service providers
• External and internal routing through exterior border gateway protocol (EBGP) and
interior border gateway protocol (IBGP)
• Edge security to control access from the Internet
• Control for access to the Internet from the enterprise clients
Figure 9 Data center architecture

The campus core switches provide connectivity between the Internet Edge, the intranet
server farms, the campus network, and the private WAN. The core switches physically
connect to the devices that provide access to other major network areas, such as the private
WAN edge routers, the server-farm aggregation switches, and campus distribution
switches.
The following are the network layers of the server farm:
• Aggregation layer
• Access layer
Front-end segment
Application segment
Back-end segment
• Storage layer
• Data Center transport layer
Some of these layers depend on the specific implementation of the n-tier model or the
requirements for Data Center-to-Data-Center connectivity, which implies that they might
not exist in every Data Center implementation. Although some of these layers might be
optional in the Data Center architecture, they represent the trend in continuing to build
highly available and scalable enterprise Data Centers. This trend specifically applies to the
storage and Data Center transport layers supporting storage consolidation, backup and
archival consolidation, high-speed mirroring or clustering between remote server farms,
and so on.
3.1 Aggregation Layer:

The aggregation layer is the aggregation point for devices that provide services to all server
farms. These devices are multilayer switches, firewalls, load balancers, and other devices
that typically support services across all servers. The multilayer switches are referred to as
aggregation switches because of the aggregation function they perform. Service devices are
shared by all server farms. Specific server farms are likely to span multiple access switches
for redundancy, thus making the aggregation switches the logical connection point for
service devices, instead of the access switches.
If connected to the front-end Layer 2 switches, these service devices might not offer
optimal services by creating less than optimal traffic paths between them and servers
connected to different front-end switches. Additionally, if the service devices are off of the
aggregation switches, the traffic paths are deterministic and predictable and simpler to
manage and maintain.
Figure 10 Aggregation and Access layer

As depicted in Figure 9, the aggregation switches provide basic infrastructure services
and connectivity for other service devices. The aggregation layer is analogous to the
traditional distribution layer in the campus network in its Layer 3 and Layer 2 functionality.
The aggregation switches support the traditional switching of packets at Layer 3 and Layer 2
in addition to the protocols and features to support Layer 3 and Layer 2 connectivity. A
more in-depth explanation on the specific services provided by the aggregation layer
appears in the section, “Data Center Services.”
3.2 Access Layer:
The access layer provides Layer 2 connectivity and Layer 2 features to the server farm.
Because in a multitier server farm, each server function could be located on different access
switches on different segments, the following section explains the details of each segment.
3.2.1 Front-End Segment

The front-end segment consists of Layer 2 switches, security devices or features, and the
front-end server farms. The front-end segment is analogous to the traditional access layer of
the hierarchical campus network design and provides the same functionality.
The access switches are connected to the aggregation switches in the
manner depicted in Figure 9. The front-end server farms typically include FTP, Telnet,
TN3270 (mainframe terminals), Simple Mail Transfer Protocol (SMTP), web servers, DNS
servers, and other business application servers, in addition to network-based application
servers such as IP television (IPTV) broadcast servers and IP telephony call managers that
are not placed at the aggregation layer because of port density or other design requirements.
The specific network features required in the front-end segment depend on the servers and
their functions. For example, if a network supports video streaming over IP, it might require
multicast, or if it supports Voice over IP (VoIP), quality of service (QoS) must be enabled.
Layer 2 connectivity through VLANs is required between servers and load balancers or
firewalls that segregate server farms.
The need for Layer 2 adjacency is the result of Network Address Translation (NAT) and
other header rewrite functions performed by load balancers or firewalls on traffic destined
to the server farm. The return traffic must be processed by the same device that performed
the header rewrite operations.
Layer 2 connectivity is also required between servers that use clustering for high availability
or require communicating on the same subnet. This requirement implies that multiple
access switches supporting front-end servers can support the same set of VLANs to provide
layer adjacency between them.
Security features include Address Resolution Protocol (ARP) inspection, broadcast
suppression, private VLANs, and others that are enabled to counteract Layer 2 attacks.
Security devices include network-based intrusion detection systems (IDSs) and host-based
IDSs to monitor and detect intruders and prevent vulnerabilities from being exploited. In
general, the infrastructure components such as the Layer 2 switches provide intelligent
network services that enable front-end servers to provide their functions.
Note that the front-end servers are typically taxed in their I/O and CPU capabilities. For I/O,
this strain is a direct result of serving content to the end users; for CPU, it is the connection
rate and the number of concurrent connections needed to be processed.
Scaling mechanisms for front-end servers typically include adding more servers with
identical content and then equally distributing the load they receive using load balancers.
Load balancers distribute the load (or load balance) based on Layer 4 or Layer 5 information.
Layer 4 is widely used for front-end servers to sustain a high connection rate without
necessarily overwhelming the servers. Scaling mechanisms for web servers also include the
use of SSL off loaders and Reverse Proxy Caching (RPC).
3.2.2 Application Segment:

The application segment has the same network infrastructure components as the front-end
segment and the application servers. The features required by the application segment are
almost identical to those needed in the front-end segment, albeit with additional security.
This segment relies strictly on Layer 2 connectivity, yet the additional security is a direct
requirement of how much protection the application servers need because they have direct
access to the database systems. Depending on the security policies, this segment uses
firewalls between web and application servers, IDSs, and host IDSs. Like the front-end
segment, the application segment infrastructure must support intelligent network services
as a direct result of the functions provided by the application services.
Application servers run a portion of the software used by business applications and provide
the communication logic between the front end and the back end, which is typically
referred to as the middleware or business logic. Application servers translate user requests
to commands that the back-end database systems understand. Increasing the security at this
segment focuses on controlling the protocols used between the front-end servers and the
application servers to avoid trust exploitation and attacks that exploit known application
vulnerabilities. Figure 10 introduces the front-end, application, and back-end segments in
a logical topology.
Note that the application servers are typically CPU-stressed because they need to support
the business logic. Scaling mechanisms for application servers also include load balancers.
Load balancers can select the right application server based on Layer 5 information.
Deep packet inspection on load balancers allows the partitioning of application server
farms by content. Some server farms could be dedicated to selecting a server farm based on
the scripting language (.cgi, .jsp, and so on). This arrangement allows application

administrators to control and manage the server behavior more efficiently.
Figure 11 Access layer segments

3.2.3 Back-End Segments:
The back-end segment is the same as the previous two segments except that it supports the
connectivity to database servers. The back-end segment features are almost identical to
those at the application segment, yet the security considerations are more stringent and aim
at protecting the data, critical or not.
The hardware supporting the database systems ranges from medium-sized servers to highend
servers, some with direct locally attached storage and others using disk arrays attached
to a SAN. When the storage is separated, the database server is connected to both the
Ethernet switch and the SAN. The connection to the SAN is through a Fibre Channel
interface. Figure 11 presents the back-end segment in reference to the storage layer. Notice
the connections from the database server to the back-end segment and storage layer.
Note that in other connectivity alternatives, the security requirements do not call for
physical separation between the different server tiers.
3.3 Storage Layer:

The storage layer consists of the storage infrastructure such as Fiber Channel switches and
routers that support small computer system interface (SCSI) over IP (iSCSI) or Fiber
Channel over IP (FCIP). Storage network devices provide the connectivity to servers,
storage devices such as disk subsystems, and tape subsystems.
The network used by these storage devices is referred to as a SAN. The Data Center is the
location where the consolidation of applications, servers, and storage occurs and where the
highest concentration of servers is likely, thus where SANs are located. The current trends
in server and storage consolidation are the result of the need for increased efficiency in the
application environments and for lower costs of operation.
Data Center environments are expected to support high-speed communication between
servers and storage and between storage devices. These high-speed environments require
block-level access to the information supported by SAN technology. There are also
requirements to support file-level access specifically for applications that use Network
Attached Storage (NAS) technology. Figure 11 introduces the storage layer and the typical
elements of single and distributed Data Center environments.
Figure 11 shows a number of database servers as well as tape and disk arrays connected to
the fiber channel switches. Servers connected to the fiber channel switches are typically
critical servers and always dual-homed. Other common alternatives to increase availability
include mirroring, replication, and clustering between database systems or storage devices.
These alternatives typically require the data to be housed in multiple facilities, thus
lowering the likelihood of a site failure preventing normal systems operation. Site failures
are recovered by replicas of the data at different sites, thus creating the need for distributed
Data Centers and distributed server farms and the obvious transport technologies to enable
communication between them. The following section discusses Data Center transport

alternatives.
Figure 12 Storage and Transport layers

3.4 Data Center Transport Layer:

The Data Center transport layer includes the transport technologies required for the
following purposes:
• Communication between distributed Data Centers for rerouting client-to-server traffic
• Communication between distributed server farms located in distributed Data Centers
for the purposes of remote mirroring, replication, or clustering
Transport technologies must support a wide range of requirements for bandwidth and
latency depending on the traffic profiles, which imply a number of media types ranging
from Ethernet to Fibre Channel.
For user-to-server communication, the possible technologies include Frame Relay, ATM,
DS channels in the form of T1/E1 circuits, Metro Ethernet, and SONET.
For server-to-server and storage-to-storage communication, the technologies required are
dictated by server media types and the transport technology that supports them transparently.
Systems Connectivity (ESCON), which should be supported by the metro optical transport
infrastructure between the distributed server farms.
If ATM and Gigabit Ethernet (GE) are used between distributed server farms, the metro
optical transport could consolidate the use of fiber more efficiently. For example, instead of
having dedicated fiber for ESCON, GE, and ATM, the metro optical technology could
transport them concurrently.
The likely transport technologies are dark fiber, coarse wavelength division multiplexing
(CWDM), and dense wavelength division multiplexing (DWDM), which offer transparent
connectivity (Layer 1 transport) between distributed Data Centers for media types such as
GE, Fibre Channel, ESCON, and fiber connectivity (FICON).
Note that distributed Data Centers often exist to increase availability and redundancy in
application environments. The most common driving factors are disaster recovery and
business continuance, which rely on the specific application environments and the
capabilities offered by the transport technologies.
• Blade servers
• Grid computing
• Web services
• Service-oriented Data Centers
All these trends influence the Data Center in one way or another. Some short-term trends
force design changes, while some long-term trends force a more strategic view of the
architecture.
For example, the need to lower operational costs and achieve better computing capacity at
a relatively low price leads to the use of blade servers. Blade servers require a different
topology when using Ethernet switches inside the blade chassis, which requires planning
on port density, slot density, oversubscription, redundancy, connectivity, rack space, power
consumption, heat dissipation, weight, and cabling. Blade servers can also support compute
grids. Compute grids might be geographically distributed, which requires a clear
understanding of the protocols used by the grid middleware for provisioning and load
distribution, as well as the potential interaction between a compute grid and a data grid.
Blade servers can also be used to replace 1RU servers on web-based applications because
of scalability reasons or the deployment or tiered applications. This physical separation of

tiers and the ever-increased need for security leads to application layer firewalls.
An example of this is the explicit definition for application layer security is (included in the
Web Services Architecture). Security on Web Services is in reference to
a secure environment for online processes from a security and privacy perspective. The
development of the WSA focuses on the identification of threats to security and privacy and
the architect features that are needed to respond to those threats. The infrastructure to support
such security is expected to be consistently supported by applications that are expected
to be distributed on the network. Past experiences suggest that some computationally
repeatable tasks would, over time, be offloaded to network devices, and that the additional
network intelligence provides a more robust infrastructure to complement Web Services
security (consistency- and performance-wise).
Finally, a services-oriented Data Center implies a radical change on how Data Centers are
viewed by their users, which invariably requires a radical change in the integration of the
likely services. In this case, interoperability and manageability of the service devices become
a priority for the Data Center designers. Current trends speak to the Utility Data Center from
HP and On Demand (computing) form IBM, in which both closer integration of available
services and the manner in which they are managed and provisioned is adaptable to the
organization. This adaptability comes from the use of standard interfaces between the
integrated services, but go beyond to support virtualization and self-healing capabilities.
Whatever these terms end up bringing to the Data Center, the conclusion is obvious: The
Data Center is the location where users, applications, data, and the network infrastructure
converge.
The result of current trends will change the ways in which the Data Center is architected
and managed.
4. Data Center Topologies:
This section discusses Data Center topologies and, in particular, the server farm topology.
Initially, the discussion focuses on the traffic flow through the network infrastructure (on a
generic topology) from a logical viewpoint and then from a physical viewpoint.
4.1 Generic Layer 3/Layer 2 Designs:

The generic Layer 3/Layer 2 designs are based on the most common ways of deploying
server farms. Figure 12 depicts a generic server farm topology that supports a number of
servers.
Figure 13 Generic Layer 3/Layer 2 Designs

The highlights of the topology are the aggregation-layer switches that perform key Layer 3
and Layer 2 functions, the access-layer switches that provide connectivity to the servers in
the server farm, and the connectivity between the aggregation and access layer switches.
The key Layer 3 functions performed by the aggregation switches are as follows:
• Forwarding packets based on Layer 3 information between the server farm and the
rest of the network
• Maintaining a “view” of the routed network that is expected to change dynamically as
network changes take place
• Supporting default gateways for the server farms.
The key Layer 2 functions performed by the aggregation switches are as follows:
• Spanning Tree Protocol (STP) 802.1d between aggregation and access switches to
build a loop-free forwarding topology.
• STP enhancements beyond 802.1d that improve the default spanning-tree behavior,
such as 802.1s, 802.1w, Uplinkfast, Backbonefast, and Loopguard.
• VLANs for logical separation of server farms.
• Other services, such as multicast and ACLs for services such as QoS, security, rate
limiting, broadcast suppression, and so on.
The access-layer switches provide direct connectivity to the server farm. The types of
servers in the server farm include generic servers such as DNS, DHCP, FTP, and Telnet;
mainframes using SNA over IP or IP; and database servers. Notice that some servers have
both internal disks (storage) and tape units, and others have the storage externally
connected (typically SCSI).
The connectivity between the two aggregation switches and between aggregation and
access switches is as follows:
• EtherChannel between aggregation switches. The channel is in trunk mode, which
allows the physical links to support as many VLANs as needed (limited to 4096
VLANs resulting from the 12-bit VLAN ID).
• Single or multiple links (EtherChannel, depending on how much oversubscription is
expected in the links) from each access switch to each aggregation switch (uplinks).
These links are also trunks, thus allowing multiple VLANs through a single physical
path.
• Servers dual-homed to different access switches for redundancy. The NIC used by the
server is presumed to have two ports in an active-standby configuration. When the
primary port fails, the standby takes over, utilizing the same MAC and IP addresses
that the active port was using.
The typical configuration for the server farm environment just described is presented in
Figure 13.
Figure 13 shows the location for the critical services required by the server farm. These
services are explicitly configured as follows:
• agg1 is explicitly configured as the STP root.
• agg2 is explicitly configured as the secondary root.
• agg1 is explicitly configured as the primary default gateway.

• agg2 is explicitly configured as the standby or secondary default gateway.
Figure 14

Other STP services or protocols, such as UplinkFast, are also explicitly defined between the
aggregation and access layers. These services/protocols are used to lower convergence time
during failover conditions from the 802.d standard of roughly 50 seconds to 1 to 3 seconds.
In this topology, the servers are configured to use the agg1 switch as the primary default
gateway, which means that outbound traffic from the servers follows the direct path to the
agg1 switch. Inbound traffic can arrive at either aggregation switch, yet the traffic can reach
the server farm only through agg1 because the links from agg2 to the access switches are
not forwarding (blocking). The inbound paths are represented by the dotted arrows, and the
outbound path is represented by the solid arrow.
The next step is to have predictable failover and fallback behavior, which is much simpler
when you have deterministic primary and alternate paths. This is achieved by failing every
component in the primary path and recording and tuning the failover time to the backup
component until the requirements are satisfied. The same process must be done for falling
back to the original primary device. This is because the failover and fallback processes are
not the same. In certain instances, the fallback can be done manually instead of automatically,
to prevent certain undesirable conditions.
The use of STP is the result of a Layer 2 topology, which might have loops that require an
automatic mechanism to be detected and avoided. An important question is whether there
is a need for Layer 2 in a server farm environment.
4.1.1 The Need for Layer 2 at the Access Layer:

Access switches traditionally have been Layer 2 switches. This holds true also for the
campus network wiring closet. This discussion is focused strictly on the Data Center
because it has distinct and specific requirements, some similar to and some different than
those for the wiring closets.
The reason access switches in the Data Center traditionally have been Layer 2 is the result
of the following requirements:
• When they share specific properties, servers typically are grouped on the same VLAN.
These properties could be as simple as ownership by the same department or performance of
the same function (file and print services, FTP, and so on). Some servers that
perform the same function might need to communicate with one another, whether as
a result of a clustering protocol or simply as part of the application function. This
communication exchange should be on the same subnet and sometimes is possible
only on the same subnet if the clustering protocol heartbeats or the server-to-server
application packets are not routable.
• Servers are typically dual-homed so that each leg connects to a different access switch
for redundancy. If the adapter in use has a standby interface that uses the same MAC
and IP addresses after a failure, the active and standby interfaces must be on the same
VLAN (same default gateway).
• Server farm growth occurs horizontally, which means that new servers are added to
the same VLANs or IP subnets where other servers that perform the same functions
are located. If the Layer 2 switches hosting the servers run out of ports, the same
VLANs or subnets must be supported on a new set of Layer 2 switches. This allows
flexibility in growth and prevents having to connect two access switches.
• When using stateful devices that provide services to the server farms, such as load
balancers and firewalls, these stateful devices expect to see both the inbound and
outbound traffic use the same path. They also need to constantly exchange connection
and session state information, which requires Layer 2 adjacency. More details on
these requirements are discussed in the section, “Access Layer,” which is under the
section, “Multiple Tier Designs.”
Using just Layer 3 at the access layer would prevent dual-homing, Layer 2 adjacency
between servers on different access switches, and Layer 2 adjacency between service
devices. Yet if these requirements are not common on your server farm, you could consider
a Layer 3 environment in the access layer. Before you decide what is best, it is important
that you read the section titled “Fully Redundant Layer 2 and Layer 3 Designs with
Services,” later in the chapter. New service trends impose a new set of requirements in the
architecture that must be considered before deciding which strategy works best for your
Data Center.
The reasons for migrating away from a Layer 2 access switch design are motivated by the
need to drift away from spanning tree because of the slow convergence time and the
operation challenges of running a controlled loopless topology and troubleshooting loops
when
they occur. Although this is true when using 802.1d, environments that take advantage of
802.1w combined with Loop guard have the following characteristics: They do not suffer

from the same problems, they are as stable as Layer 3 environments, and they support low
convergence times.
4.2 Alternate Layer 3/Layer 2 Designs:
Figure 15 The Need for Layer 2 at the Access Layer

Figure presents a topology in which the network purposely is designed not to have
loops. Although STP is running, its limitations do not present a problem. This loopless
topology is accomplished by removing or not allowing the VLAN(s), used at the accesslayer
switches, through the trunk between the two aggregation switches. This basically
prevents a loop in the topology while it supports the requirements behind the need for Layer
2.
In this topology, the servers are configured to use the agg1 switch as the primary default
gateway. This means that outbound traffic from the servers connected to acc2 traverses the
link between the two access switches. Inbound traffic can use either aggregation switch
because both have active (nonblocking) paths to the access switches. The inbound paths are
represented by the dotted arrows, and the outbound path is represented by the solid arrows.
This topology is not without its own challenges.
4.3 Multiple-Tier Designs

Most applications conform to either the client/server model or the n-tier model, which
implies most networks, and server farms support these application environments. The tiers
supported by the Data Center infrastructure are driven by the specific applications and
could be any combination in the spectrum of applications from the client/server to the
client/web server/application server/database server. When you identify the communication
requirements between tiers, you can determine the needed specific network services. The
communication requirements between tiers are typically higher scalability, performance,
and security. These could translate to load balancing between tiers for scalability and
performance, or SSL between tiers for encrypted transactions, or simply firewalling and
intrusion detection between the web and application tier for more security.
Figure 15 introduces a topology that helps illustrate the previous discussion.
Notice that Figure 15 is a logical diagram that depicts layer-to-layer connectivity through
the network infrastructure. This implies that the actual physical topology might be different.
The separation between layers simply shows that the different server functions could
be physically separated. The physical separation could be a design preference or the result
of specific requirements that address communication between tiers.
For example, when dealing with web servers, the most common problem is scaling the web
tier to serve many concurrent users. This translates into deploying more web servers that
have similar characteristics and the same content so that user requests can be equally
fulfilled by any of them. This, in turn, requires the use of a load balancer in front of the
server farm that hides the number of servers and virtualizes their services. To the users, the
specific service is still supported on a single server, yet the load balancer dynamically picks

a server to fulfill the request.
Figure 16 Multiple-Tier Designs

Suppose that you have multiple types of web servers supporting different applications, and
some of these applications follow the n-tier model. The server farm could be partitioned
along the lines of applications or functions. All web servers, regardless of the application(s)
they support, could be part of the same server farm on the same subnet, and the application
servers could be part of a separate server farm on a different subnet and different VLAN.
Following the same logic used to scale the web tier, a load balancer logically could be
placed between the web tier and the application tier to scale the application tier from the
web tier perspective. A single web server now has multiple application servers to access.
The same set of arguments holds true for the need for security at the web tier and a separate
set of security considerations at the application tier. This implies that firewall and intrusion
detection capabilities are distinct at each layer and, therefore, are customized for the
requirements of the application and the database tiers. SSL offloading is another example of a
function that the server farm infrastructure might support and can be deployed at the web tier,
the application tier, and the database tier. However, its use depends upon the application
environment using SSL to encrypt client-to-server and server-to-server traffic.
4.4 Expanded Multitier Design:
The previous discussion leads to the concept of deploying multiple network-based services
in the architecture. These services are introduced in Figure 4-10 through the use of icons
that depict the function or service performed by the network device.
The different icons are placed in front of the servers for which they perform the functions.
At the aggregation layer, you find the load balancer, firewall, SSL off loader, intrusion
detection system, and cache. These services are available through service modules (line cards
that could be inserted into the aggregation switch) or appliances. An important point to
consider when dealing with service devices is that they provide scalability and high
availability beyond the capacity of the server farm, and that to maintain the basic premise
of “no single point of failure,” at least two must be deployed. If you have more than one
(and considering you are dealing with redundancy of application environments), the
failover and fallback processes require special mechanisms to recover the connection
context, in addition to the Layer 2 and Layer 3 paths. This simple concept of redundancy at
the application layer has profound implications in the network design.

Figure 17 Expanded Multitier Design
A number of these network service devices are replicated in front of the application layer
to provide services to the application servers. Notice in Figure 16 that there is physical
separation between the tiers of servers. This separation is one alternative to the server farm
design. Physical separation is used to achieve greater control over the deployment and
scalability of services. The expanded design is more costly because it uses more devices,
yet it allows for more control and better scalability because the devices in the path handle
only a portion of the traffic. For example, placing a firewall between tiers is regarded as a
more secure approach because of the physical separation between the Layer 2 switches.

4.5 Collapsed Multitier Design:
A collapsed multitier design is one in which all the server farms are directly connected at
the access layer to the aggregation switches, and there is no physical separation between
the Layer 2 switches that support the different tiers. Figure 17 presents the collapsed
design.
Figure 18 Collapsed Multitier Design

Notice that in this design, the services again are concentrated at the aggregation layer, and
the service devices now are used by the front-end tier and between tiers. Using a collapsed
model, there is no need to have a set of load balancers or SSL off loaders dedicated to a
particular tier. This reduces cost, yet the management of devices is more challenging and
the performance demands are higher. The service devices, such as the firewalls, protect all
server tiers from outside the Data Center, but also from each other. The load balancer also
can be used concurrently to load-balance traffic from client to web servers, and traffic from
web servers to application servers.
Notice that the design in Figure 17 shows each type of server farm on a different set of
switches. Other collapsed designs might combine the same physical Layer 2 switches to
house web applications and database servers concurrently. This implies merely that the
servers logically are located on different IP subnets and VLANs, yet the service devices still
are used concurrently for the front end and between tiers. Notice that the service devices
are always in pairs. Pairing avoids the single point of failure throughout the architecture.
However, both service devices in the pair communicate with each other, which falls into the
discussion of whether you need Layer 2 or Layer 3 at the access layer.
The Need for Layer 2 at the Access Layer:

Each pair of service devices must maintain state information about the connections the pair
is handling. This requires a mechanism to determine the active device (master) and another
mechanism to exchange connection state information on a regular basis. The goal of the
dual–service device configuration is to ensure that, upon failure, the redundant device not
only can continue service without interruption, but also seamlessly can failover without
disrupting the current established connections.
In addition to the requirements brought up earlier about the need for Layer 2, this section
discusses in depth the set of requirements related to the service devices:
• Service devices and the server farms that they serve are typically Layer 2–adjacent.
This means that the service device has a leg sitting on the same subnet and VLAN
used by the servers, which is used to communicate directly with them. Often, in fact,
the service devices themselves provide default gateway support for the server farm.
• Service devices must exchange heartbeats as part of their redundancy protocol. The
heartbeat packets might or might not be routable; if they are routable, you might not
want the exchange to go through unnecessary Layer 3 hops.
• Service devices operating in stateful failover need to exchange connection and session
state information. For the most part, this exchange is done over a VLAN common to
the two devices. Much like the heartbeat packets, they might or might not be routable.
• If the service devices provide default gateway support for the server farm, they must
be adjacent to the servers.
After considering all the requirements for Layer 2 at the access layer, it is important to note
that although it is possible to have topologies such as the one presented in Figure 4-8, which
supports Layer 2 in the access layer, the topology depicted in Figure 4-7 is preferred.
Topologies with loops are also supportable if they take advantages of protocols such as
802.1w and features such as Loop guard.
The following section discusses topics related to the topology of the server farms.
4.6 Fully Redundant Layer 2 and Layer 3 Designs:
Up to this point, all the topologies that have been presented are fully redundant. This section
explains the various aspects of a redundant and scalable Data Center design by presenting
multiple possible design alternatives, highlighting sound practices, and pointing out
practices to be avoided.
4.6.1 The Need for Redundancy:

Figure 18 explains the steps in building a redundant topology.
Figure 18 depicts the logical steps in designing the server farm infrastructure. The
process starts with a Layer 3 switch that provides ports for direct server connectivity and
routing to the core. A Layer 2 switch could be used, but the Layer 3 switch limits the
broadcasts and flooding to and from the server farms. This is option a in Figure 4-12. The
main problem with the design labeled a is that there are multiple single point of failure
problems: There is a single NIC and a single switch, and if the NIC or switch fails, the
server and applications become unavailable.
The solution is twofold
• Make the components of the single switch redundant, such as dual power supplies and
dual supervisors.
• Add a second switch.
Redundant components make the single switch more tolerant, yet if the switch fails, the
server farm is unavailable. Option b shows the next step, in which a redundant Layer 3
switch is added.
Figure 19 The Need for Redundancy
By having two Layer 3 switches and spreading servers on both of them, you achieve a
higher level of redundancy in which the failure of one Layer 3 switch does not completely
compromise the application environment. The environment is not completely compromised
when the servers are dual-homed, so if one of the Layer 3 switches fails, the servers still
can recover by using the connection to the second switch.
In options a and b, the port density is limited to the capacity of the two switches. As the
demands for more ports increase for the server and other service devices, and when the

maximum capacity has been reached, adding new ports becomes cumbersome, particularly
when trying to maintain Layer 2 adjacency between servers.
The mechanism used to grow the server farm is presented in option c. You add Layer 2
access switches to the topology to provide direct server connectivity. Figure 18 depicts
the Layer 2 switches connected to both Layer 3 aggregation switches. The two uplinks, one
to each aggregation switch, provide redundancy from the access to the aggregation
switches, giving the server farm an alternate path to reach the Layer 3 switches.
The design described in option c still has a problem. If the Layer 2 switch fails, the servers
lose their only means of communication. The solution is to dual-home servers to two
different Layer 2 switches, as depicted in option d of Figure 18.
Layer 2 and Layer 3 in Access Layer:
Option d in Figure18 is detailed in option a of Figure 19.
Figure 20 Layer 2 and Layer 3 in Access Layer

Figure 19 presents the scope of the Layer 2 domain(s) from the servers to the aggregation
switches. Redundancy in the Layer 2 domain is achieved mainly by using spanning tree,
whereas in Layer 3, redundancy is achieved through the use of routing protocols.
Historically, routing protocols have proven more stable than spanning tree, which makes
one question the wisdom of using Layer 2 instead of Layer 3 at the access layer. This topic
was discussed previously in the “Need for Layer 2 at the Access Layer” section. As shown
in option b in Figure 19, using Layer 2 at the access layer does not prevent the building
of pure Layer 3 designs because of the routing between the access and distribution layer or
the supporting Layer 2 between access switches.
The design depicted in option a of Figure 19 is the most generic design that provides
redundancy, scalability, and flexibility. Flexibility relates to the fact that the design makes
it easy to add service appliances at the aggregation layer with minimal changes to the rest
of the design. A simpler design such as that depicted in option b of Figure 19 might better
suit the requirements of a small server farm.
Layer 2, Loops, and Spanning Tree:

The Layer 2 domains should make you think immediately of loops. Every network designer
has experienced Layer 2 loops in the network. When Layer 2 loops occur, packets are
replicated an infinite number of times, bringing down the network. Under normal conditions,
the Spanning Tree Protocol keeps the logical topology free of loops. Unfortunately, physical
failures such as unidirectional links, incorrect wiring, rogue bridging devices, or bugs
can cause loops to occur.
Fortunately, the introduction of 802.1w has addressed many of the limitations of the original
spanning tree algorithm, and features such as Loopguard fix the issue of malfunctioning
transceivers or bugs.
Still, the experience of deploying legacy spanning tree drives network designers to try to
design the Layer 2 topology free of loops. In the Data Center, this is sometimes possible.
An example of this type of design is depicted in Figure 20. As you can see, the Layer 2
domain (VLAN) that hosts the subnet 10.0.0.x is not trunked between the two aggregation
switches, and neither is 10.0.1.x. Notice that GigE3/1 and GigE3/2 are not bridged together.
Figure 21 Layer 2, Loops, and Spanning Tree

If the number of ports must increase for any reason (dual-attached servers, more servers,
and so forth), you could follow the approach of daisy-chaining Layer 2 switches, as shown in
.
Figure 22 Layer 2, Loops, and Spanning Tree

To help you visualize a Layer 2 loop-free topology, Figure 21 shows each aggregation
switch broken up as a router and a Layer 2 switch.
The problem with topology a is that breaking the links between the two access switches
would create a discontinuous subnet—this problem can be fixed with an Ether Channel
between the access switches.
The other problem occurs when there are not enough ports for servers. If a number of
servers need to be inserted into the same subnet 10.0.0.x, you cannot add a switch between
the two existing servers, as presented in option b of Figure 21. This is because there is no
workaround to the failure of the middle switch, which would create a split subnet. This
design is not intrinsically wrong, but it is not optimal.
Both the topologies depicted in Figures 20 and 21 should migrate to a looped topology
as soon as you have any of the following requirements:
• An increase in the number of servers on a given subnet
• Dual-attached NIC cards
• The spread of existing servers for a given subnet on a number of different access
switches
• The insertion of stateful network service devices (such as load balancers) that operate
in active/standby mode
Options a and b in Figure 22 show how introducing additional access switches on the
existing subnet creates “looped topologies.” In both a and b, GigE3/1 and GigE3/2 are
bridged together.
Figure 23

If the requirement is to implement a topology that brings Layer 3 to the access layer, the
topology that addresses the requirements of dual-attached servers is pictured in Figure 23
Figure 24

Notice in option a of Figure 23, almost all the links are Layer 3 links, whereas the access
switches have a trunk (on a channel) to provide the same subnet on two different switches.
This trunk also carries a Layer 3 VLAN, which basically is used merely to make the two
switches neighbors from a routing point of view. The dashed line in Figure 23 shows the
scope of the Layer 2 domain.
Option b in Figure 23 shows how to grow the size of the server farm with this type of
design. Notice that when deploying pairs of access switches, each pair has a set of subnets
disjointed from the subnets of any other pair. For example, one pair of access switches hosts
subnets 10.0.1.x and 10.0.2.x; the other pair cannot host the same subnets simply because
it connects to the aggregation layer with Layer 3 links.
So far, the discussions have centered on redundant Layer 2 and Layer 3 designs. The Layer 3
switch provides the default gateway for the server farms in all the topologies introduced
thus far. Default gateway support, however, could also be provided by other service devices,
such as load balancers and firewalls.
5. Data Center Services
This section presents an overview of the services supported by the Data Center architecture.
Related technology and features make up each service. Each service enhances the manner
in which the network operates in each of the functional service areas defined earlier in the
chapter. The following sections introduce each service area and its associated features.
Figure 24 introduces the Data Center services.
Figure 25 Data Center Services
As depicted in Figure24, services in the Data Center are not only related to one another
but are also, in certain cases, dependent on each other. The IP and storage infrastructure
services are the pillars of all other services because they provide the fundamental building
blocks of any network and thus of any service. After the infrastructure is in place, you can
build server farms to support the application environments. These environments could be
optimized utilizing network technology, hence the name application services. Security is a
service expected to leverage security features on the networking devices that support all

other services in addition to using specific security technology. Finally, the business
continuance infrastructure, as a service aimed at achieving the highest possible redundancy
level.
The highest redundancy level is possible by using both the services of the primary Data
Center and their best practices on building a distributed Data Center environment.

5.1 IP Infrastructure Services:

Infrastructure services include all core features needed for the Data Center IP infrastructure
to function and serve as the foundation, along with the storage infrastructure, of all other
Data Center services. The IP infrastructure features are organized as follows:
• Layer 2
• Layer 3
• Intelligent Network Services
Layer 2 features support the Layer 2 adjacency between the server farms and the service
devices (VLANs); enable media access; and support a fast convergence, loop-free,
predictable, and scalable Layer 2 domain. Layer 2 domain features ensure the Spanning Tree
Protocol (STP) convergence time for deterministic topologies is in single-digit seconds and
that the failover and failback scenarios are predictable.
STP is available on Cisco network devices in three versions: Per VLAN Spanning Tree Plus
(PVST+), Rapid PVST+ (which combines PVST+ and IEEE 802.1w), and Multiple
Spanning Tree (IEEE 801.1s combined with IEEE 802.1w). VLANs and trunking (IEEE
802.1Q) are features that make it possible to virtualize the physical infrastructure and, as a
consequence, consolidate server-farm segments. Additional features and protocols increase
the availability of the Layer 2 network, such as Loopguard, Unidirectional Link Detection
(UDLD), PortFast, and the Link Aggregation Control Protocol (LACP or IEEE 802.3ad).
Layer 3 features enable a fast-convergence routed network, including redundancy for basic
Layer 3 services such as default gateway support. The purpose is to maintain a highly
available Layer 3 environment in the Data Center where the network operation is predictable
under normal and failure conditions. The list of available features includes the support for
static routing, Border Gateway Protocol (BGP) and Interior Gateway Protocols (IGPs) such
as Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP),
Intermediate System-to-Intermediate System (IS-IS), gateway redundancy protocols such
as the Hot Standby Routing Protocol (HSRP), Multigroup HSRP (MHSRP), and Virtual
Router Redundancy Protocol (VRRP) for default gateway support.
Intelligent network services encompass a number of features that enable application services
network-wide. The most common features are QoS and multicast. Yet there are other
important intelligent network services such as private VLANs (PVLANs) and policy-based
routing (PBR). These features enable applications, such as live or on-demand video streaming
and IP telephony, in addition to the classic set of enterprise applications.
QoS in the Data Center is important for two reasons—marking at the source of application
traffic and the port-based rate-limiting capabilities that enforce proper QoS service class as
traffic leaves the server farms. For marked packets, it is expected that the rest of the
enterprise network enforces the same QoS policies for an end-to-end QoS service over the
entire network.
Multicast in the Data Center enables the capabilities needed to reach multiple users
concurrently. Because the Data Center is the source of the application traffic, such as live
video streaming over IP, multicast must be supported at the server-farm level (VLANs,
where the source of the multicast stream is generated). As with QoS, the rest of the
enterprise network must either be multicast-enabled or use tunnels to get the multicast
stream to the intended destinations.

5.2 Application Services:
Application services include a number of features that enhance the network awareness of
applications and use network intelligence to optimize application environments. These
features are equally available to scale server-farm performance, to perform packet inspection
at Layer 4 or Layer 5, and to improve server response time. The server-farm features are
organized by the devices that support them. The following is a list of those features:
• Load balancing
• Caching
• SSL termination
Load balancers perform two core functions:
• Scale and distribute the load to server farms
• Track server health to ensure high availability
To perform these functions, load balancers virtualize the services offered by the server
farms by front-ending and controlling the incoming requests to those services. The load
balancers distribute requests across multiple servers based on Layer 4 or Layer 5 information.
The mechanisms for tracking server health include both in-band monitoring and out-ofband
probing with the intent of not forwarding traffic to servers that are not operational. You
also can add new servers, thus scaling the capacity of a server farm, without any disruption
to existing services.
Layer 5 capabilities on a load balancer allow you to segment server farms by the content
they serve. For example, you can separate a group of servers dedicated to serve streaming
video (running multiple video servers) from other groups of servers running scripts and
application code. The load balancer can determine that a request for an .mpg file (a video
file using MPEG) goes to the first group and that a request for a .cgi file (a script file) goes
to the second group.
Server farms benefit from caching features, specifically working in RPC mode. Caches
operating in RPC mode are placed near the server farm to intercept requests sent to the
server farm, thus offloading the serving of static content from the servers. The cache keeps
a copy of the content, which is available to any subsequent request for the same content, so
that the server farm does not have to process the requests. The process of offloading occurs
transparently for both the user and the server farm.
SSL offloading features use an SSL device to offload the processing of SSL sessions from
server farms. The key advantage to this approach is that the SSL termination device offloads
SSL key negotiation and the encryption/decryption process away from the server farm.
An additional advantage is the capability to process packets based on information in the
payload that would otherwise be encrypted. Being able to see the payload allows the load
balancer to distribute the load based on Layer 4 or Layer 5 information before re-encrypting
the packets and sending them off to the proper server.
5.2.1 Service Deployment Options:

Two options exist when deploying Data Center services: using service modules integrated
into the aggregation switch and using appliances connected to the aggregation switch.
Figure 25 shows the two options.
Figure 26 Service Deployment Options

Option a shows the integrated design. The aggregation switch is represented by a router
(Layer 3) and a switch (Layer 2) as the key components of the foundation (shown to the
left) and by a firewall, load balancer, SSL module, and IDS module (shown to the right as
add-on services). The service modules communicate with the routing and switching
components in the chassis through the backplane.
Option b shows the appliance-based design. The aggregation switch provides the routing
and switching functions. Other services are provided by appliances that are connected
directly to the aggregation switches.
A thoughtful approach to the design issues in selecting the traffic flow across different
devices is required whether you are considering option a, option b, or any combination of
the options in Figure 4-18. This means that you should explicitly select the default gateway
and the order in which the packets from the client to the server are processed. The designs
that use appliances require more care because you must be concerned with physical
connectivity issues, interoperability, and the compatibility of protocols.
5.2.2 Design Considerations with Service Devices:

Up to this point, several issues related to integrating service devices in the Data Center
design have been mentioned. They are related to whether you run Layer 2 or Layer 3 at the
access layer, whether you use appliance or modules, whether they are stateful or stateless,
and whether they require you to change the default gateway location away from the router.
Changing the default gateway location forces you to determine the order in which the
packet needs to be processed through the aggregation switch and service devices.
Figure 26 presents the possible alternatives for default gateway support using service
modules. The design implications of each alternative are discussed next.
Figure 26 shows the aggregation switch, a Catalyst 6500 using a firewall service module,
and a content-switching module, in addition to the routing and switching functions
provided by the Multilayer Switch Feature Card (MSFC) and the Supervisor Module.
The one constant factor in the design is the location of the switch providing server
connectivity; it is adjacent to the server farm.
Figure 27 Design Considerations with Service Devices
Option a presents the router facing the core IP network, the content-switching module
facing the server farm, and the firewall module between them firewalling all server farms.
If the content switch operates as a router (route mode), it becomes the default gateway for
the server farm. However, if it operates as a bridge (bridge mode), the default gateway

would be the firewall. This configuration facilitates the creation of multiple instances of the
firewall and content switch combination for the segregation and load balancing of each
server farm independently.
Option b has the firewall facing the server farm and the content switch between the router
and the firewall. Whether operating in router mode or bridge mode, the firewall configuration
must enable server health-management (health probes) traffic from the content-switching
module to the server farm; this adds management and configuration tasks to the design.
Note that, in this design, the firewall provides the default gateway support for the server
farm.
Option c shows the firewall facing the core IP network, the content switch facing the server
farm, and the firewall module between the router and the content-switching module. Placing
a firewall at the edge of the intranet server farms requires the firewall to have “router-like”
routing capabilities, to ease the integration with the routed network while segregating all
the server farms concurrently. This makes the capability to secure each server farm
independently more difficult because the content switch and the router could route packets
between the server farm without going through the firewall. Depending on whether the
content-switching module operates in router or bridge mode, the default gateway could be
the content switch or the router, respectively.
Option d displays the firewall module facing the core IP network, the router facing the
server farm, and the content-switching module in between. This option presents some of
the same challenges as option c in terms of the firewall supporting IGPs and the inability to
segregate each server farm independently. The design, however, has one key advantage: The
router is the default gateway for the server farm. Using the router as the default gateway
allows the server farms to take advantage of some key protocols, such as HSRP, and
features, such as HSRP tracking, QoS, the DHCP relay function, and so on, that are
only available on routers.
All the previous design options are possible—some are more flexible, some are more
secure, and some are more complex. The choice should be based on knowing the
requirements as well as the advantages and restrictions of each.
“Integrating Security into the Infrastructure,” addresses the network design in the context
of firewalls.
5.3 Security Services:
Security services include the features and technologies used to secure the Data Center
infrastructure and application environments. Given the variety of likely targets in the Data
Center, it is important to use a systems approach to securing the Data Center. This
comprehensive approach considers the use of all possible security tools in addition to
hardening
every network device and using a secure management infrastructure. The security tools and
features are as follows:
• Access control lists (ACLs)
• Firewalls

• IDSs and host IDSs
• Secure management
• Layer 2 and Layer 3 security features
ACLs filter packets. Packet filtering through ACLs can prevent unwanted access to network
infrastructure devices and, to a lesser extent, protect server-farm application services. ACLs
are applied on routers (RACLs) to filter routed packets and to VLANs (VACLs) to filter
intra-VLAN traffic. Other features that use ACLs are QoS and security, which are enabled
for specific ACLs.
An important feature of ACLs is the capability to perform packet inspection and
classification without causing performance bottlenecks. You can perform this lookup process
in
hardware, in which case the ACLs operate at the speed of the media (wire speed).
The placement of firewalls marks a clear delineation between highly secured and loosely
secured network perimeters. Although the typical location for firewalls remains the Internet
Edge and the edge of the Data Center, they are also used in multitier server-farm
environments to increase security between the different tiers.
IDSs proactively address security issues. Intruder detection and the subsequent notification
are fundamental steps for highly secure Data Centers where the goal is to protect the data.
Host IDSs enable real-time analysis and reaction to hacking attempts on database,
application, and Web servers. The host IDS can identify the attack and prevent access to
server
resources before any unauthorized transactions occur.
Secure management include the use of SNMP version 3; Secure Shell (SSH); authentication,
authorization, and accounting (AAA) services; and an isolated LAN housing the management
systems. SNMPv3 and SSH support secure monitoring and access to manage network
devices. AAA provides one more layer of security by preventing users access unless they
are authorized and by ensuring controlled user access to the network and network devices
with a predefined profile. The transactions of all authorized and authenticated users are
logged for accounting purposes, for billing, or for postmortem analysis.
5.4 Storage Services
Storage services include the capability of consolidating direct attached disks by using disk
arrays that are connected to the network. This setup provides a more effective disk utilization
mechanism and allows the centralization of storage management. Two additional services are
the capability of consolidating multiple isolated SANs on to the same larger SAN
and the virtualization of storage so that multiple servers concurrently use the same set of
disk arrays.
Consolidating isolated SANs on to one SAN requires the use of virtual SAN (VSAN)
technology available on the SAN switches. VSANs are equivalent to VLANs yet are
supported by SAN switches instead of Ethernet switches. The concurrent use of disk arrays
by multiple servers is possible through various network-based mechanisms supported by
the SAN switch to build logical paths from servers to storage arrays.

Other storage services include the support for FCIP and iSCSI on the same storage network
infrastructure. FCIP connects SANs that are geographically distributed, and iSCSI is a
lower-cost alternative to Fibre Channel. These services are used both in local SANs and
SANs that might be extended beyond a single Data Center. The SAN extension subject is
discussed in the next section.

Data Center Proposal (System Network Administration)

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Data Center Proposal (System Network Administration) (20)

More from Muhammad Ahad (20)

Recently uploaded (20)

Data Center Proposal (System Network Administration)