HANA in a pocket, a skull and some dirty hands on Linux
DISCLAIMER: this blog describes unsupported and unlicensed use of the SAP HANA software. I describe my personal try-out of a hardware/software combination. It’s not in any way meant to be used productively or recommended to use the software in the way I describe.
If you loose data, waste life-time, money, your good mood or damage anything while trying to do what I describe: that’s all on you and there’s no guarantee, warranty or liability whatsoever from SAP or myself.
The frustrating reality of ‘big machine computing’
Just like everyone else in the SAP HANA community, I really like having a private instance available for me.
Trying things out, practicing, researching solutions, working with sample data, checking system behaviour etc. are just so much easier than e.g. on a HCP instance or some “playground” instance on the company’s SAP HANA hardware.
Yes, there are always ways to work around this but e.g. for me this means I have to live with average round trip times of ca. 320ms. That’s certainly not too bad and definitively works for most use cases. Unfortunately the server is not “mine”.
So, if I e.g. wanted to reboot the server for any reason, well, folks probably wouldn’t be too happy …
Also, this server really is only available when I can logon into our corporate network in one way or another. And this turns out to be a limitation that is easily hit.
Customer visit with no immediate WIFI logon?
Nope, no way to access the SAP HANA system then.
Cable provider outage in the home office?
Yep, that SAP HANA server is running fine, far away – without any chance to be used by me.
In short a somewhat local SAP HANA installation would be a really nice thing. Especially since I am not permanently working with tons of data, but rather look into the development/admin aspect of things.
Is there a way or what?
A few weeks ago, I was on a customer visit in San Francisco and the development team there came up with a valid and interesting question: how to provision developers with private SAP HANA instances?
With a private instance, each developer could mess around with his system without impacting anyone else. This is pretty much a standard approach for development nowadays, so the request is rather reasonable.
SAP internally there exist multiple approaches to this problem.
From “small” SAP HANA hardware under the developer’s desk (actually quite expensive machines, that we would have called “workstations” back in the day) to spawn-on-demand-systems on virtual servers: there’s a flavor for everyone.
Unfortunately all that sort of screams: high initial investment.
Not great for smaller teams or individuals who would want to get deeper into SAP HANA development/administration without access to “allowed” hardware.
Even though I am not a gamer and the last time I assembled a PC myself was somewhat around 2000 this looked really interesting to me.
The system runs on an Intel i7 quad-core processor and allows up to 32GB of RAM.
That’s certainly enough to run and operate a small SAP HANA instance.
Here’s a picture of this nice piece of technology:
Cutting the story short
I ordered that thing online together with two 16 GB DDR4 strips and an old/slow but relatively cheap IBM SSD with 480GB capacity.
All in all the bill for this was around 1400 Australian Dollars – not too bad for a system way more powerful than my MacBook Pro.
Of course: this doesn’t come with any display or input device (well, in fact the online shop I ordered from had a special and chipped in a Logitech K400 plus for free 😉 . You have to have a monitor to use this thing.
A few days later the whole pack arrived and I was really surprised by the weight of it: easily below one kilogram.
I’ll skip the whole un-boxing and assembly part, but will tell you: it’s easy.
The RAM modules just need to be clicked into place and the SSD installation requires to loosen and tighten a single screw. Definitively doable for a hardware n00b like myself.
The more complicated part – again: for me, others might just do this without blinking – was to put an operating system onto the new machine.
I didn’t buy a Windows license, since the whole purpose of this buy was to eventually run SAP HANA on it, so I went for OpenSuse Linux (Leap Distribution). Creating a boot-able USB thumb drive is relatively easy.
The only changes to this tutorial I did was
- using ‘pv‘ to get an idea on the progress of the data transfer (installed via ‘brew‘) – yes, I used a Mac for this.
- using a blocksize of 1M instead of the 4k mentioned in the tutorial.
The whole command set then looked like this:
pv /path/to/downloaded.iso | dd of=/dev/rdisk2 bs=1M
Armed with this USB thumb drive stuck into one of the 4 USB ports, I simply started my “skullbox” and the OpenSuse installation screen appeared.
Again, I’m not the Linux expert on the installation side of things, so I basically when with most of the default settings and clicked through.
One reboot after that, I had OpenSuse running on the new machine.
Meanwhile in the kitchen
As TV chefs would say “… meanwhile I prepared something else …” which translates here into the download of the SAP HANA installation files from SAP Service Marketplace (Yes, you do need to have paid access to this).
The installation files come in a big multi-part RAR archive with Windows Auto-Extraction, which means, that the first part is an .EXE file.Unpacking on Linux however is not a problem; all you need is the UNRAR tool (if all fails ‘zypper install http://download.opensuse.org/repositories/openSUSE:/Leap:/42.1:/NonFree/standard/x86_64/unrar-5.3.3-1.3.x86_64.rpm‘ should fetch this).
The rest of the installation is fairly well documented, and only small additional changes were required to make the installation work on this NOT SUPPORTED operating system:
a) PNG Library couldn’t be loaded, and the hdblcmgui woudln’t start.
Fixed by installing an older version via ‘zypper install –oldpackage libpng12-0′
b) nameserver couldn’t be started due to missing SSL libs.The trace file listed
“Can’t load ‘/playfield/hana_inst/51050838/DATA_UNITS/HDB_SERVER_LINUX_X86_64/instruntime/SSLeay.so’ for module Net::SSLeay: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory at DynaLoader.pm line 193.”
Fixed by ‘zypper install libssl*’ and
ln -s /lib64/libcrypto.so.1.0.0 /usr/libcrypto.so.0.9.8
ln -s /lib64/libssl.so.1.0.0 /usr/lib64/libssl.so.0.9.8
(as seen here)After that the installation went through without further troubles.
The looooong fork
I have enabled the option for remote administration in OpenSuse, which means that the system now can be accessed via VNC.
For my Windows 10 based work laptop I find that MobaXTerm makes it really simple to access the Linux box – it even has a plugin that contains a VNC client.
For the Mac, there is actually a VNC client build in (I’m using El Capitan): just start “Screen Sharing” or put vnc://hostname:port into the Safari address bar and off you go…
After all of this (and some more wrestling with the Linux network setup – I still barely have a clue on that, but it seems to work now…)
I can now access my “HANA skullbox” via:
- WIFI connection at homeoffice
- drect CAT5 cable connection between my work laptop and the NUC
which are exactly the scenarios I wanted to support.
Starting a HANA Studio via X-Server works too:
But that’s neither fast nor pretty.
For working with the system I prefer using the local HANA Studio or the Web UI.
Of course I used ‘memory allocation limit’, but to have some fun, I cranked it up to the total 32 GB of installed RAM; so far no functional problems with this 😉
All of this setup happened after hours over maybe three evenings. Someone with more Linux know-how would probably be done in way less time.
So far I’m quite happy with this setup and I’m eager to try out what things work and where the hard limit of usability for this micro-HANA lies.
OK, that’s it for now.
AGAIN: this is a completely unsupported setup. No support, warranty, maintenance or endorsement is provided by SAP or myself for this.
There you go – now you know!