|
When Tech OnTap contacted me about writing an Oracle on NetApp article, they asked me to talk specifically about our experiences running Oracle on SAN and NAS. I told them, “Shame on you for still thinking in terms of SAN or NAS. You should be talking about unified storage and using whatever protocol best meets each client’s needs or the needs of the application.” The terms SAN and NAS are dead along with “totally tubular” and “awesome.” (Those are dead, aren’t they?) At Catholic Healthcare West (CHW) we have more than 117 Oracle Database instances running approximately 150 applications supported by 55 NetApp storage systems with NFS, Fibre Channel, and iSCSI protocols. In total, we have over 750TB of storage. Since the reality is that many IT organizations, application vendors, and DBAs still think in terms of protocol, this article highlights:
- How we choose which storage protocol to use for a given application
- The advantages of unified storage for Oracle
- The relative merits of the various protocols
Frankly, it’s the second section that we think is the most interesting. The combination of unified storage and unique NetApp data management tools gives us tremendous power to manage our Oracle environment.
Choosing a Storage Protocol
Our first experience with Oracle on NetApp was with NFS a number of years ago. When NetApp said we could run Oracle over NFS, our first reaction was to laugh because at that time it was a very unconventional way to do things (some think it still is); back then our DBAs still wanted raw disk. When we converted from SAP to Lawson Financials we switched from traditional storage to NFS.
Lawson sent a team of engineers out to certify the configuration. They planned to stay for five days. After one day they were completely satisfied; they certified the solution and left.
Since that time, we’ve added many additional Oracle applications, some on NFS, some on Fibre Channel, and some on iSCSI.v At this point you’re probably wondering why we use more than one storage protocol with Oracle and how we choose which protocol to use.
Today, our standard for Oracle is Linux® with NetApp storage, and we don’t differentiate between Fibre Channel, iSCSI, or NFS. We’re running it all with confidence. When we deploy a new application, the decision really comes down to which protocol the vendor supplying the application can support the best. We always try to find out what protocol the vendor is most comfortable with or has the most deployments on.
Some vendors are Fibre Channel only, while others are willing, or even prefer, to support other options. For example, our Emageon Picture Archiving and Communication System (PACS) specifies the use of NFS.
In the past, our preferred option was either iSCSI or NFS due to their protocol resiliency and the high per–port cost and management costs of Fibre Channel, but today the per–port cost on a director– class switch is really no longer an issue (it’s no longer significantly different between FC and IP), so vendor support has become our overriding criterion.
Other Factors to Consider
Along with vendor support, there are a few other factors you may want to consider if you’re trying to decide which protocol to choose for your Oracle environment:
- Relationship with networking team: I’ve talked with people who don’t want to do anything but Fibre Channel because they don’t have control over IP networking or a good relationship with their networking team. If that applies to you, you might find it beneficial in the long run to use FC SAN. On the flip side, there’s obviously an issue of management complexity with FC SAN. If your organization doesn’t have the skill set to deal with that, the protocols that leverage standard Ethernet gear may be preferable.
- What does your DBA want? Let’s face it, good Oracle DBAs are hard to find, and many of them come with strong opinions about what’s good and what isn’t. Some will be more comfortable with NFS and iSCSI than others. I don’t force a good DBA to use a protocol he or she isn’t comfortable with if I don’t have to.
|
