Monday, July 10, 2006
Oracle for Windows Hardware Guide
I’d like to stray a little bit from the pure software aspects of Oracle on Windows to focus on the hardware and OS perspective in this blog. The Oracle software is very important, and the version of Windows 2003 is also very important, but if you do not have the proper hardware running this software, you might be headed for trouble. In this installment I will be describing the hardware components necessary to run Oracle and Oracle RAC on Windows as well as discussing some of the new technologies that are available today.
When putting together a system to run Oracle, you must consider not only the amount and type of hardware, but the brand of hardware. In addition, it is important to properly size the system. All of these tasks lead you to putting together an optimal system for your environment.
I’m not going to recommend that you purchase a particular brand of hardware, but I would recommend that you purchase your hardware from a company that you recognize. Not only is the quality of the hardware important, but the quality of the support as well. Many vendors go the extra step and test their products with Oracle on Windows in order to provide an optimal solution. It is especially important when implementing Oracle RAC that you choose a vendor that can provide a tested solution. These vendors will often supply you with white papers or other docs on how to optimally configure their system for Oracle RAC on Windows.
With Oracle RAC, the storage selection is as important as the selection of the actual servers. The storage system must provide the ability to be shared, be robust and be able to support a sufficient number of disk drives to achieve the performance that you need. In addition, the storage should be configured in order to avoid a single point of failure. In this installment of my blog I will discuss the servers, the storage and the infrastructure.
Servers
When choosing a Windows server to run Oracle there are several features that you should look for. The CPU is the brains of the computer and should be selected for the type of processor, the cache size and its speed. Because of the memory requirements of the dedicated and shared server processes, the larger the better is usually the case with the cache on the CPUs. The more CPUs there are in the system, the more important the CPU cache is. If you have a choice between a faster CPU and more cache, with Oracle it is usually better to go with more cache.
The type of CPU offers quite a selection now. AMD has an excellent processor with the Opteron line, and Intel has done a great job with the EM64T processor. They are both available with single or dual cores and both are x64 processors. I only recommend the Itanium 2 processors for specific applications where a large system with many processors is required due to the cost differential between the x64 systems and the Itanium systems. In more cases, the x64 (Opteron or EM64T) processors will work great for you.
Storage
Storage is one of the most crucial components of your Oracle system. The storage subsystem must be robust, high performing and expandable. Today there are many options to choose from. In the past I would have only recommended SAN storage for an Oracle RAC system, but recently I have had very good experience with both NAS and iSCSI solutions. This in conjunction with Microsoft’s release of its iSCSI support for Microsoft Storage Server 2003 R2, iSCSI is not much more interesting.
When selecting a storage subsystem make sure to minimize the single points of failure. This is done by creating as many redundant components as possible. In addition, not only the size of the disk drive is important, but the number of disk drives is crucial. A state of the art disk drive should be configured to do no more than 125 IOs Per Second (IOPS). Running disk drives hotter than this will cause latencies to increase, thus causing system performance problems.
Infrastructure
The network infrastructure is an important piece of your entire system, especially with network storage. If you are using Network Attached Storage (NAS) or iSCSI you should dedicate a network specifically for storage. By sharing the storage network with other network functions such as the RAC interconnect or general network connectivity you could create higher latencies and thus reduced performance. Since the speed of the network is critical to your storage performance (in a NAS or iSCSI environment) you should not use anything less than Gigabit speed networks.
Network storage should always be available locally, that is, there should not be any active components between the database server and its storage; such as routers, firewalls, etc. The only components that should reside between the database server and its storage is one or more network switches. Active components such as routers and firewalls can add too much latency.
Summary
In summary, it is important to think about the hardware that you will be deploying in terms of both stability (supportability) and performance. Many of the performance engagements that I am brought in on are caused by an undersized system. If you are using network attached storage, make sure that you have a sufficient network infrastructure to handle it.
This is interesting advice for implementation of Oracle RAC in production but in my case I'm looking to set up a 2 node cluster for testing purposes and I'm looking for simple and cheap. Would you have any advice regarding the Shared Storage? Does a SCSI disk on a shared bus would be enough? You mention also the usage of a NAS: I though this was not supported...actually I have one sitting in the office and I would be happy to use it...to have it acting as a shared storage you need to map it to an identiocal drive letter on earch node right?
Thanks for your response
Pascal
NAS is supported with RAC. In fact, I've implemented several RAC clusters using Network Appliance storage. We've also done some preliminary work with iSCSI which is very promising. This is especially significant on Windows since Microsoft Storage Server supports iSCSI initiators.
: 7:29 AM : 7:41 AM << Home
