Developing the SAP Data Center : Introducing the SAP Data Center

11/21/2011 9:21:05 AM

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!

The SAP Solution Stack or the OSI Model?

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.

  •  Inventory of Broadband Phone Services
  •  Parallel Programming : Task Relationships (part 2) - Parent and Child Tasks
  •  Parallel Programming : Task Relationships (part 1) - Continuation Tasks
  •  BizTalk 2006 : Handling Ordered Delivery
  •  BizTalk 2006 : Implementing Dynamic Parallel Orchestrations
  •  Windows System Programming : The Registry
  •  Windows System Programming : File Locking
  •  SharePoint 2010 : Security - Secure Store Service & Using SSS with BCS
  •  SharePoint 2010 : Security - Claims Based Authentication
  •  SharePoint 2010 : PerformancePoint Services (part 2) - Using PerformancePoint
  •  SharePoint 2010 : PerformancePoint Services (part 1) - PerformancePoint Central Administration Settings
  •  Windows System Programming : Example: Listing File Attributes & Setting File Times
  •  Windows System Programming : File Attributes and Directory Processing
  •  Windows System Programming : File Pointers & Getting the File Size
  •  SharePoint 2010 : Business Intelligence - Excel Services (part 2) - Accessing Excel Services Over SOAP
  •  SharePoint 2010 : Business Intelligence - Excel Services (part 1) - Accessing Excel Services Over REST
  •  SharePoint 2010 : Business Intelligence - Visio Services
  •  Exchange Server 2010 : Perform Essential Database Management (part 3) - Manage Database Settings
  •  Exchange Server 2010 : Perform Essential Database Management (part 2) - Manage the Transaction Log Files
  •  Exchange Server 2010 : Perform Essential Database Management (part 1) - Manage the Database Files
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)