Andres Rodriguez - Fotolia
Customers moving from a proof-of-concept HANA application to a production-ready installation must consider a variety of elements as they ready their landscape for the in-memory database platform, ranging from choosing between hardware vendors and backup and recovery plans, to managing security concerns.
But where do you start?
First, you need to understand HANA is not a black box; it's the Linux operating system on a piece of hardware with lots of memory, and it's more than a SQL92-compliant in-memory database. In terms of Linux support, HANA was initially deployed with SUSE Enterprise 11 and now Red Hat Enterprise Linux 6.5 is supported with HANA revision 80. (Always refer to SAP's Product Availability Matrix for the latest details.)
For the hardware, we have the option to purchase hardware from a range of approved vendors. Earlier this year, SAP began allowing customers to bring their own hardware for use with HANA licenses. Customers still need to have the proper blend of hardware specifications (memory, solid-state drives for log files, fast drives for data, proper ratio of memory and CPU cores, etc.), but it looks as though SAP is loosening its strict rules on HANA devices. We also know SAP will allow customers to perform their own HANA installations. As of this past May, VMware is now certified for up to a 1 TB HANA instance. Adding virtualization partners to the mix with hardware will provide customers with even more backup and recovery options.
When planning a HANA landscape, we can use the traditional three-system landscape where each instance is isolated from the activities on the other. For example, you can use one piece of hardware for each software development lifecycle component -- one for development, one for quality assurance (QA), and one for production. HANA does have the capability to support more than one HANA database per server. For example, we might be able to leverage a single piece of hardware for sandbox and development while using another for QA and training. HANA also enables us to perform distributed installations where we have master and worker nodes, thereby allowing us to easily setup an environment in QA to match your production scenario where you might have multiple nodes in production. For example, two nodes could support a single development HANA instance and a distributed instance of QA.
When planning hardware for a production environment, we also need to take into account our backup strategy and disaster recovery requirements. In my opinion, an "active-active" environment is one where both hosts are accepting requests. And if one host fails, client connections can immediately be re-established. Within a HANA environment, SAP doesn't provide this "active-active" cluster configuration. SAP does provide an automatic host failover, which also requires some DNS changes that can be automated as well. Is it immediate? No. But can it be fast? Yes.
We can use a replicated standby system that will enable a failover within minutes, but it's not true high availability like we understand with NetWeaver. In the replicated standby database scenario, we need to remember two key points. One, we will need to repoint client database requests via DNS changes in the event of a failover; and two, we can use the standby database as a non-productive database for another instance, say, for QA and testing. We at NIMBL have been impressed with the flexibility SAP provides with its standby database scenario. SAP has put considerable thought into enabling customers to make the best use of hardware so we don't have idle machines in our data center.
Working with backups in HANA should be familiar to any data center manager or mid-level IT executive. We must backup the database and log files on a recurring basis to provide a point-in-time recovery. Out of the box, we can perform backups via SAP HANA Studio or the command line at the operating system level. We see several customers exploring HANA-certified backup partners like Symantec, IBM, HP, etc. The specific certification that partners are able to achieve for backing up HANA is called HANA-BRINT 1.1. You can find multiple backup products from the SAP Store when searching "HANA-BRINT 1.1".
Now that we understand what makes up HANA, the next question is, "How we will structure our landscape and how we will back up our landscape?" Also, implementing HANA impacts internal resource skill set demands. From an administration perspective, SAP Basis Administrators should easily transition to being HANA administrators if they have experience supporting UNIX platforms. The installation mechanism for HANA looks and feels like SAP. We still need to connect HANA to SAP Solution Manager for Enterprise Support Services (more to follow on this topic), which is a common Basis task we perform with any SAP NetWeaver installation. Basis administrators will ideally welcome the new technology and be excited to support it. Having an in-memory database does add another dimension of system monitoring, and SAP does a good job of providing the tools we need for both real-time and historical performance analysis.
Managing security in HANA is one of the greatest areas of change, in my opinion, for customers who currently have security teams managing application security in the SAP Business Suite or other NetWeaver-based applications. If you are running NetWeaver BW or the SAP Business Suite on HANA, the security team will continue to work tomorrow as it does today. However, if you choose to deploy HANA as a standalone data warehouse or application server, the security team will require significant ramp-up time. Answering the question, "Who should perform security in HANA?" is still debatable for me. In the traditional database management system world, a database administrator (DBA) might perform security administration in addition to DBA activities. In SAP NetWeaver environments, very rarely does security work at the database layer occur, since SAP manages security at the application layer. In the standalone data warehouse scenario, we might require authorizations by company code or sales organization. Basis administrators rarely make good security administrators. If I'm a customer faced with a production deployment of HANA, then I would need to look at internal experience and the requirements to determine who will take on HANA security administration.
One final takeaway some customers may forget or misunderstand is the use of Solution Manager with your HANA deployment. Solution Manager is still the only mechanism for HANA Early Watch Reports, and is the vehicle for SAP Continuous Quality Checks, which are included as part of every customer's standard or enterprise SAP maintenance agreement. Customers who are investing significant spend in a HANA deployment must absolutely take advantage of SAP's Going Live verification services before a HANA go-live. Solution Manager is still the gateway to SAP Support. Coupled with its proactive monitoring capabilities -- included as part of Solution Manager Technical Operations -- Solution Manager should be a part of every customers HANA deployment plan.
Implementing HANA is indeed exciting, and challenges obviously exist, but with collaboration and knowledge sharing, your new deployment has a tremendous opportunity to complement your own SAP world. This is just the beginning; I can't wait for what comes out next.
Does HANA replace SAP BW?
SAP HANA and the real-time enterprise are changing how companies manage data quality
Dig Deeper on Business Objects and SAP business intelligence