Introducing the SAP Data Center
I
will discuss in detail the process inherent in building a new data
center facility, or transforming your current data center into a
foundation capable of supporting a mission-critical enterprise SAP
application and its requisite solution stack. The goal is clear—to
create a stable and highly available facility for hosting your SAP
implementation. I take this process from building out the power,
network, and rack infrastructure through installing servers, configuring
disk subsystems, and installing server operating systems.
Although you may have
already decided on many of the factors that will drive the design and
deployment of this facility, including location, hardware and software
vendors, and SAP products and components, “availability” should
typically represent the single most important consideration driving the
data center build-out. Remember, this application and its resident data
will ultimately prove critical to your company’s well-being. Should this
application and data become unavailable, even for a short period of
time, costly and otherwise huge ramifications could result:
Thousands of users may sit idly by, waiting for the system to come “back.” Trucks may stack up in the loading docks, waiting for bills of lading and shipping orders. Customers
may call in or “click in” looking for status updates on their orders,
only to be told to “try again sometime later, the system is down.” Manual
processes may need to be invoked to keep new orders coming in. And to
make it worse, eventually these manual orders will need to be keyed into
the system when it again becomes available, further impacting the
users’ time to place new orders. Reports will be unavailable, impacting decision making from the boardroom down to the assembly line, and everywhere in between.
So, keeping “availability”
uppermost in our minds, let’s move on, noting that the data center in
some way affects all layers of the SAP Solution Stack. For example:
At the lowest layer
of the stack we find power requirements. I have worked on a number of
mySAP.com implementations where as many as 80 new servers and related
disk resources are deployed over the course of a year, for example. Such
a formidable collection of hardware pulls a considerable amount of amps
and volts, not to mention the raw power infrastructure requirements
needed to simply keep all of this gear running. An incorrectly
architected power infrastructure will bring down an otherwise highly
available clustered SAP solution in a heartbeat—all of the
high-availability offerings at other layers in the solution are
“powerless” without a well-architected Uninterruptible Power Supply
(UPS) solution or power distribution system. Similarly,
cooling requirements must be addressed at one of the lowest layers of
the stack. Those same 80 servers I mentioned not only pull a tremendous
amount of power, they also generate a considerable quantity of BTUs
(British Thermal Units, or units of heat). An inadequate cooling and air
handling system can wreak havoc with availability statistics. Servers,
disk subsystems, network infrastructure, and other SAP-related
infrastructure needs to all be neatly racked and cabled. Lack of
attention to detail, poor planning, and more can quickly become
contributing downtime factors. In more than one case, I have seen racks
of servers cabled neatly and in an organized manner, only to have all of
this work ripped out after someone finally thought to pull out a server
for servicing. Why? Because the cabling did not allow enough “slack”
for the servers to be actually pulled out more than a few inches! In
other cases, I have seen high availability compromised simply because
otherwise redundant pairs of cables were routed through the same cable
conduits, and the conduit itself failed or was damaged. SAP’s
tiered architecture requires forethought in regard to network planning. Neglecting the impact that a
three-tiered architecture can have on public and private network
segments can impact not only availability, but also overall performance.
In addition, we cannot forget about network firewall security and other
network infrastructure considerations that will impact availability
when it comes to Internet-facing SAP Web servers, eCommerce/procurement
systems, and so on. Server
infrastructure and design directly impact availability, both “in the
box” via single points of failure, and “out of the box” when it comes to
higher-layer solution stack matters like failover clustering. Your
disk subsystem, whether direct-attached SCSI, fibre channel arbitrated
loop, switched fabric, or network attached, tends to be the single most
important performance factor in my experience, outside of really bad
coding. But it is also one of the most easily misunderstood solution
components when it comes to high availability. Operating
system installation, configuration practices, and more can easily
impact availability. I will note how and why this seems to be so often
overlooked, and help you to conform to best practices in this regard.
As you have just seen,
the design and implementation of a company’s specific SAP Solution Stack
through a well-planned data center deployment affects availability at
all levels of the stack. Single points of failure (SPOFs) abound
everywhere. A lone power source, single power distribution unit,
nonredundant power supplies, single network segment to a server, single
server hosting a database, and more all represent opportunities for
downtime. And I have not even begun to discuss the database and SAP
application layers!
|
If you prefer to look at
things from an OSI model perspective, you’ll be happy to note that many
of the key layers of the SAP Solution Stack map nicely to a layer in the
OSI model. Therefore, every aspect of planning for a highly available
SAP Data Center also tends to “snap into” one of those seven OSI layers,
from the physical layer—power, through the data, network, and transport
layers, up to the session, presentation, and application layers—where
your end users are provided with the SAPGUI interface.
|
I will take a closer look at each of the availability factors
in the bulleted list provided earlier, as well as operational and other
processes that will ultimately impact the net availability of your SAP
solution to your end-user population.The SAP Data Center “Big Picture”
From
a “big picture” perspective, you need to ensure that no detail is
overlooked when planning for your SAP Data Center facility or
facilities. Availability, after all, is all about details. Each layer in
the SAP Solution Stack presents you with single-point-of-failure
challenges; each layer must therefore be thoughtfully considered with an
eye toward eliminating these SPOFs, or at least noting and mitigating
risk to the point where such risk becomes financially acceptable.
First Things First—Standardization
Before we dive
into identifying and addressing single points of failure common to SAP
Data Center designs and implementation, it first makes sense to discuss
the role of standards and standardization in your data center. Standards
impact everything. Fortunately, taking a close look at standards early
in the SAP Data Center planning process forces you to think ahead, and
ultimately avoid many pitfalls potentially lurking in the future.
Consider the following:
Server naming
conventions must be descriptive enough to promote manageability, but
short enough to be technically supported by the particular SAP component
version (and any other applications that might need to reference this
name, including systems management applications like HP Openview or BMC
Patrol). IP
naming conventions should help identify what type of server network
connection is being made. For example, standards that help to identify
public, private, clustered, and internal/other network connections are
quite prevalent in the world of SAP infrastructure. Disk
naming (and drive letter, for Windows 2000/NT) conventions should be
published and leveraged for consistency. Such consistency by its very
nature impacts availability as well, as the chance of someone
“accidentally” bringing a disk resource offline is less likely to occur
when the disk name or disk drive letter for the database (for example)
tends to be the same throughout the SAP landscape. Even
something as simple as color-coding network cables and power cables can
improve system availability. Similar to IP naming conventions, a good
color-coding scheme helps avoid unplanned downtime due to inadvertently
uncabling or miscabling a vital network or power connection. I have
witnessed companies leveraging factors other than simply color, too; the
number and thickness of bands in a cable, and even the cable thickness
itself can also be used to differentiate otherwise similar cables. Standard
“high-availability server configurations” are normal in most SAP shops.
This usually equates to servers configured with redundant power supplies,
fans, power distribution units, processors, RAID-protected disk drives,
RAID or ECC-protected RAM, network cards, and so on, in a server
cluster configuration with dual-host bus adapters in each server. As
with standard highly available server configurations, most SAP shops
also promote an equivalent “high-availability disk subsystem.” This
usually involves a standard frame or disk chassis, standard drive size
(in example, 36GB 15,000 RPM 1” drives), standard redundant disk drive
controllers, and redundant disk interconnects back to the server
infrastructure. Next,
a standard operating system built for high-availability deployments is
typically developed. This would include specific OS release levels,
patch or service pack levels, any patches or bug-fixes required, other
software drivers and their versions, and so on. Nowadays, standard
methodologies for deploying customary server images are often employed,
leveraging OS-build approaches ranging from traditional disk imaging to
custom scripting, deployment of imaging servers, hardware
vendor-specific approaches, and so on. Finally,
standardized processes regarding managing all of the aforementioned
resources help to minimize downtime across the board.
Other standards exist, of
course, but the preceding list should prove useful in identifying the
key areas within each layer of the SAP Solutions Stack that must be
addressed before a single data center floor-tile is ever pulled up, or
server mounted, or operating system installed.
|
