So, to make it clear, NO IT DOES NOT!
What SAP HANA requires is a shared file system in the same way the old SAP Netweaver system had a shared file system that was SAPMNT.
The same happens with HANA and his is called /hana/shared and must be accessible by all HANA nodes, in the same way it happened with SAPMNT in the Netweaver world
So, using a NAS storage / gateway is a way to achieve this goal, but is not the only one.
For example, in the same way it was done for the Netweaver's SAPMNT, you can use a Linux server with PaceMaker to export an NFS share out of a block device in an high available way.
The consideration you need to take here is the size of your cluster. So, if you are going for scale-out clusters with a large number of nodes, you don't want this NFS share to become a bottleneck and a problem, so ensuring proper network connectivity (latency, throughput and availability) requires more careful planning than just throwing it to any existing Linux machine.
I've written a lot on why you should use block devices for HANA.
As a short reference you can read about:
- the SAP HANA Storage Connector for Fibre Channel at: http://sapinfrastructureintegration.blogspot.com/2014/07/sap-hana-fiber-channel-storage.html
- my long discussion on why some HANA "architecture" myths are outdated, being one of the topics exactly why Block is a better option for HANA persistency over NFS.
All this said, using a unified storage that provides both block and file connectivity may also serve your needs, by using the block connectivity for all the data and log devices, and the NAS functionality for the HANA SHARED.
Again, this is a possibility, not a need.
Finally, considering that most HANA projects I'm seeing these days are for Suite on HANA, which implies single server implementations, doing this in a TDI setup, by connecting two servers to external storage for high availability, and while installing Linux add as well the clustering software package just with the goal of protecting and exporting the "HANA shared" NFS share might be the simplest more integrated option. (you can read more about running SAP Business Suite on HANA in a TDI setup on my blog post here: http://sapinfrastructureintegration.blogspot.com/2014/09/running-sap-business-suite-on-hana-in.html).
Again, these are all possibilities, and fortunately, as HANA has matured a lot over the last year, now you have these well known options also available for HANA, further providing you choice in a way that you can standardize your datacenter practices.
As a conclusion, HANA is a lot more open today than it was just 1 year ago, so don't go for proprietary solutions that having been the first, are not the easiest neither the best for most customer cases. Take your time to evaluate current architectural options and make a decision to have the most standard possible application architecture and building blocks, across your datacenter, including HANA of course!
Having this uniform architecture across the datacenter will drive down your risk, enable more agile changes, and in the end a more streamline and cost effective operation.
Hope this helps, and feel free to shoot me any deeper technical questions you may have in this regards.
No comments:
Post a Comment