It's Friday, and the promise of a weekend has made my heart even lighter and more positive!
Today I want to discuss SAP, and describe some of the basics about it. These are my opinions and are from the perspective of someone who has experienced it only on SuSE SLES 11 SP1 (required in the specs by SAP; I'd have preferred Ubuntu Server or Debian, but that's just me), using Oracle 11.2 64-bit (again, required by the SAP specs). Your mileage may vary, and let's face it; I may be dead wrong on some things, as SAP is not my forte. Supporting the servers that host it is my forte.
SAP is an enormous application that covers an organization's finance, payroll, work orders, material inventory, etc. There are modules available for just about everything, and most will cost you even more money. The purpose it serves is worthwhile, and without it, many companies would have a very difficult time tracking everything and linking things together for report generation, paying employees, etc. So kudos for creating a product that is very powerful and very useful.
When I was hired on at this organization, it was with the understanding that I'd be focused entirely on Linux and AIX systems administration. As with most jobs in the SysAdmin world, you should make sure you have a written contract that specifies your specific responsibilities. Otherwise, you will find yourself tasked with more and more disciplines, until you no longer have the time you need to properly maintain the Linux environment that you were hired to oversee.
Such is the case with SAP. SAP (pronounced as the individual letters, not sap) is a German company, and as such, support is in a very different time zone from the East Coast of Florida where I do my work. Fortunately, there are vendors and contractors in the United States who make their living supporting SAP installations, so you are not entirely dependent on help that includes an overseas time delay when you are having issues. Even so, no issue with SAP is small, and each takes serious thought before deciding upon a resolution. Each module may affect dozen of other modules, so each change must be carefully examined and tested. I bring up the German ownership for another reason. While they support a few different databases - in our case we're using Oracle - they create many of the tables and fields using German names, which makes it very difficult for the SysAdmin or the Oracle DBA to have a quick look at the database layout and determine what does what.
Supporting SAP is something that actually requires many people. There is BASIS, which is basically the user interface, and the admin portion where you create, delete, and assign access roles to users. That is one of the areas I've been asked to learn, and it is huge. The BASIS book on my shelf is about one and a half inches thick, and it barely scrapes the surface. And that is only one of many aspects of SAP that must be supported. Their classes are very expensive, and in the ones my coworkers and I have taken, each class warns you that to truly understand what they are teaching you, you should attend these 7 other expensive classes. Not good for an organization with a limited budget.
So far, my primary responsibility has been at the Linux server level, creating and maintaining them, but the BASIS is creeping in and I'm learning more each week, and then being tasked with using what I've learned for user support. Oh, well. One day I'll get that written contract, and be able to focus entirely on Linux, but for now, so far, only about 5% of my time is being used for BASIS support.
On the SysAdmin side, I was responsible for creating the new Linux servers, each of which are virtualized on VMWare. The reason for my creation of new servers is that we were upgrading from a much older version of SAP, and were converting from AIX to Linux. To give you an idea of the enormity of this upgrade, it took them over 6 months to complete the process!
I've had to create 5 separate SAP servers for our organization, and if you work for a larger organization with multiple geographic locations, there would be even more servers required. Most of the servers are configured pretty identically, but some can be made lighter in disk space, RAM and CPUs. At a minimum, when you buy SAP - and be prepared to shell out hundreds of thousands of American dollars, or in same cases, multiple millions - you will need to create the following servers:
SSM - SAP Solution Manager: This server is not as resource intensive as the others. This server is the one that communicates with the SAP headquarters most frequently, looking for updates, etc., and in part, proving that you are not exceeding your licensing. In the past, installing updates in SAP was a much more manual process, involving reading what are called "SAP Notes" which often, in order to understand this SAP Note, contain pointers to other SAP Notes, which contain still more links to other SAP Notes, ad infinitum, ad nauseum. There is still a lot of manual work in installing updates, but at least this server can - in theory - reach out and grab them. I truly don't know. The consulting team we hired to do our upgrade to the latest version and move us from AIX to Linux never properly configured the SSM server, and we're in discussion to get them to do it post mortem.
SD1 - The sandbox server where you can try things without breaking the production server. The resources it requires are greater than the SSM server, but lighter than the production machine.
DV1 - The development server. This one needs to be fairly beefy on resources, but not as beefy as QA1 or production. This is where users try out minor changes, things like new payroll rules based on tax laws changing, etc. It has two separate login environments; client 200 and client 400. All initial testing of changes takes place in client 200, and if passed, sometimes also get tested in client 400, but that is rare in our case.
QA1 - The quality analysis server. This environment is very much like the production server, and is the final place to test your changes before moving them to production. It needs to be fairly beefy on resources, but not as beefy as production.
PRD - The production server. This is the environment where real time work is done, and where real time changes such as adding users, etc., are done. It is the most resource intensive, and the server which keeps you up at night as a SysAdmin. If this goes down, there is no work being done, and more importantly in the minds of all our employees, payroll is unable to process and we don't get paid. My goal here is to create a backup PRD server which we'll initially be able to bring up if PRD dies. In time, I'll want it to also be a live failover server, and the final phase will be to make it a load balancing server. We shall see.
In my next blog entry, I'll discuss a bit about how the changes that require traversing 3 servers are done, using what is called the "transport".
Incidentally, here's a fun thing you can do when you need a bit of humor in your day. As the customer, if you ever want to make an SAP rep or consultant twitch, you can pronounce it "sap", as in the liquid that flows from pine trees. They'll correct you immediately, and it adds just a little bit of joy to your life. :-D
Benny Helms
No comments:
Post a Comment