Skip to Content

SAP Adaptive Computing Controller, a.k.a ACC version 7.2 is a promising tool from SAP in the virtualization and cloud computing space. It decouples the tradition Central Instance (or now called Central Services), Dialog Instance and Database instance from being tied to a server (may it be physical or virtual). We are supposed to visualize them as “Services” and these services can be provided from any server we need. There are some limited number of use cases of actually making use of ACC for all that it promises, however, hey! this is a step closer towards virtualization and ACC 7.3 has a lot more to offer.

The below text describes a testing of ACC 7.2 (when these tests were being conducted, ACC 7.3 was in the Ramp-up) in a lab environment conducted to not only test the functionalities, but also to be able to make a cautious choice of where and in what situations do we use a particular feature provided by ACC.

Focused Functionalities:

  1. Start and Stop instances,
  2. Relocation of instances,
  3. Task Planner / Scheduler,
  4. Monitoring, Reporting & Dashboards, and
  5. VMWare Integration

The Lab Setup:

SAP Instances:

The SAP ACC is installed on one of the 4 virtual servers in the form of a single system installation with no dialog servers. (SID = LAC)

The Netweaver 7.0 EHP1 instance is the system to be used for testing (SID = LNW). The NW system is comprised of a Central Instance running on one of the Virtual servers, a Dialog instance running on another Virtual server and the Database instance that is installed on the physical server (no real reasoning behind this).

Servers:

The lab setup comprised of six servers – 2 physical servers and 4 virtual servers. All of these servers run SUSE Linux 9 Enterprise Edition.

Storage:

For the purpose of this lab testing, all our file systems are mounted on one of the server above. We selected the database server of the Netweaver instance to be central point for al file systems. They are then NFS mounted from the Netweaver database server to the servers that will host the NW Central and the NW Dialog instance. Each of the servers has permissions to mount the file systems that are NFS mounted on the NW DI and CI.

Virtual Hostname and IP addresses:

Each SAP instance is installed with a separate virtual host name and a virtual IP address. The Virtual names are as below:

NW Database Instance

NW Central Instance

NW Dialog Instance

ACC Instance (Single System)

Virtual : lnwdb01

Virtual : lnwap01

Virtual : lnwdi01

Virtual : lacap01

(not mandatory)

Installation Process:

  1. Download software for NW 7.01 SR1, CE 7.2, ACC 7.2
  2. Install JRE 1.4.2 (SR13) on the Linux servers
  3. Install NW (SID = LNW) using the virtual hostnames lnwap01 (inst nr=00), lnwdb01 and lnwdi01 (inst nr=10)
  4. Install CE (SID = LAC) using virtual hostname lacap01 (inst nr=00, SCS nr=01)
  5. Perform SAP NW (LNW) Post installation steps
  6. Perform SAP CE (LAC) Post-installation steps. Look at the next section to perform the CE specific post installation steps.
  7. Install ACC package using JSPM on LAC. Use the LMACC01 (SP1). Since all java packages are cumulative, you can directly apply LMACC01. Note that when you download the patch it might be downloaded as a .zip file. When you copy over the patch to the server (…/EPS/in) rename it to .sca extension.
  8. Install SAPHostctrl on lnwap01, lnwdb01 and lnwdi01.
  9. Install SAPHostctrl also on LAIL0210LAB02 and LAIL0219GEN01 which do not have any instances on them at this point of time, but will be the target servers during relocation.
  10. Run the Prepare Hosts step using SAPINST on LAIL0210LAB02 and LAIL0219GEN01 servers to create users and groups. This is required since we do not have our SAP IDs accessible over LDAP. See http://help.sap.com/saphelp_nwacc72/helpdata/en/49/61053690ab2009e10000000a42189c/frameset.htm point # 2.
  11. Make sure the OS Group ID for sapsys is same across all servers. Preferably all UIDs and GIDs should be same, but group sapsys plays a critical role here.

CE specific Post Installation:

  1. URL: http://lacap01.cardinalhealth.net:50000/NWA
  2. Follow : Configuration Management -> Scenarios -> Configuration Wizard
  3. Click the link “Functional Unit Configuration UI”
  4. Select “Java Foundation” and notice that the “System Landscape Directory” gets selected automatically.
  5. Click Enable automatically button
  6. Follow the wizard
  7. Select setup new SLD option
  8. Check the option: “This SLD will be used as name server for development”
  9. Follow the progress bar
  10. This takes some time since SLD is setup during the process
  11. Click “Return to the task list” and then select show: All configurations to perform the ACC configuration. 

Setup ACC:

  1. URL: http://lacap01.cardinalhealth.net:50000/NWA
  2. Follow : Configuration Management à Scenarios -> Configuration Wizard
  3. Select: “Initial setup for Adaptive Computing Controller”
  4. Click Start button
  5. Select Custom Mode
  6. Follow the instructions. You may keep defaults for now. For this test, we decided not to use the Landscape scanner to unchecked the “Run Landscape Scanner” checkbox.
  7. Look for the progress bar on the screen
  8. Click “Return to the task list” and Log Off.
  9. Now Launch ACC Console. You can now launch the ACC UI from the URL: http://lacap01.cardinalhealth.net:50000/acc 

Test Cases:

Case #

ACC Functionality

Test Case description

Expected Results

Observation

Pass/Fail

1.1

Monitoring, Reporting & Dashboards

Monitoring Capability

Monitor various components of physical & Virtual servers

  1. Automatically detects # of CPUs, RAM
  2. Shows utilization of h/w resources
  3. Shows number of active instances / services

Pass

1.2

Monitoring, Reporting & Dashboards

Reporting & Dashboard Capability

Improve visibility of SAP landscapes / systems

Provides a single view of SAP Instances (services) and Servers (Resources) in Overview tab

Pass

1.2

Monitoring, Reporting & Dashboards

Dashboard shows current status as well as active tasks running

Shows all actively running tasks

Shows all actively running tasks

Pass

2.1

Mass Operations

Stop Single DI instance

Stops single DI instance

Pass

2.2

Mass Operations

Stop Only the CI instance

Does not stop CI without stopping DI instances

Gave a warning and automatically selected dependent services (i.e. DI)

Pass

2.3

Mass Operations

Stop Only the DB instance

Does not stop DB without stopping CI & DI instances

Gave a warning and automatically selected dependent services (i.e. CI & DI)

Pass

2.4

Mass Operations

Stop the service from ACC console and start from the OS level (eg. By using startsap)

ACC should detect the instance status

ACC detected the services status

Pass

2.5

Mass Operations

Stop & Start DI & CI together

Able to stop and start CI & DI together

Pass

2.6

Mass Operations

Stop & Start DB, CI & DI together

Able to stop and start DB, CI & DI together

Pass

3.1

Relocation

Try relocating DI instance from its original resource (virtual) to another virtual guest server

 

DI relocates and starts on the target server

DI relocation was successful. Verified using Linux process viewer (ps -ef)

Pass

3.3

Relocation

Try relocating DI instance from its original resource (virtual) to a physical server

DI relocates and starts on the target server

All steps completed successfully.

Pass

3.4

Relocation

Try relocating DI instance from physical server back to its virtual guest server

DI relocates and starts on the target server

All steps completed successfully.

Pass

3.5

Relocation

Try relocating CI instance from its original resource (virtual) to a physical server

CI relocates and starts on the target server

When relocating CI only, ACC automatically detects that the DI is dependent upon CI and so pops up a warning “Some services required to complete the operation are missing; these have been added to the list” making it mandatory to select DI. The DI instance will just restart on the server in the appropriate order.

 

NOTE: We are relocating CI from LAIL0219VCI01 to LAIL0210LAB02 while DI was already running on LAIL0219VDI01

Pass

3.6

Relocation

Try relocating CI instance from physical server back to its virtual guest server

CI relocates and starts on the target server

Same as above as far as managing dependents go.

Pass

3.7

Relocation

Mass relocate CI and DI to two different servers

Both relocate to different servers

All steps completed successfully.

 

In general, relocating just DI instance takes around 5 to 7 minutes while moving CI with one DI takes around 7 to 10 minutes. The more the app servers, the more time it will take.

Pass

3.8

Relocation

During all above relocations connections are not lost

It is expected that the relocation of instances / SAP services is seamless and does not cause user connection terminations

ACC shuts down the instance before Un Prepare and Prepare, so connections are lost

Fail

4.1

Hypervisor Integration

All virtual guest servers visible under the Virtualization tab

Lists all guest servers and their status

Action buttons de-activated because Read-only access is provided to connect to ESX host

Pass

4.2

Hypervisor Integration

Deactivate, Activate and Suspend guest servers

Able to deactivate, activate and suspend VMWare guest servers from ACC console

Does deactivate, activate and suspends the guest servers. Checked via ping and ACC Overview page.

Pass

4.3

Hypervisor Integration

Start instance on another server if the guest server is deactivated or suspended

Able to prepare and start instance on any other server

When the guest server where DI was running was deactivated, the instance got shutdown as well (verified through lost connection and SM51). However when attempted to start the instance on other server, it did prepare itself and start up successfully.

Pass

5.1

Task Planner

Schedule startup and shutdown

Shutdown and startup goes as per schedule

Actions kicked off accurately at the specified time. Shutdown and Startup steps completed successfully.

Pass

5.2

Task Planner

Schedule relocation of one SAP service

Relocation goes as per schedule

 

Pass

5.3

Task Planner

Schedule relocation of multiple SAP service at once

Relocation goes as per schedule

 

Pass

 

 

 

 

 

 

List of Issues & Resolutions as a part of the test:

Issue #

Issue Description & Details

Resolution Description & Details

Comments

Status

1

NFS /sapmnt file system wasn’t able to be mounted on GEN01

NFS export requires permissions to which servers it can be mounted on

Permissions provided to allow the export to be mounted on GEN01 and LAB02.

Check using the command (do not use this as a normal SOP):

./sapacosprep -a @command -f 161.244.39.54:/sapmnt -m /sapmnt

Where @ = mount and then umount

CLOSED

2

[Ref: Test case # 3.2] Relocation failing with no specific error during un-mounting NFS file systems from source

Upgrade host agents from level 24 to 32

None

CLOSED

3

[Ref: Test case # 3.2] Relocation failing with no specific error during startup on the target server

Need entries in the /etc/services file

Make sure the services file is distributed to all servers that will host an SAP instance

CLOSED

4

[Ref: Test case # 3.2] Relocation failing with error “no permission to create sapstart.sem” during startup on the target server

File system permissions need to be verified. Best recommendation is to create users and groups with same UID’s and GID’s. e.g. GID for sapsys should be same across all servers.

Run the option to create OS users and groups using SAPINST

CLOSED

Conclusion:

We found Adaptive Computing Controller (ACC) to be very useful, especially in mass operations such as mass start and stop of multiple SAP instances. We plan on utilizing the relocation functionality to relocate an instance in situations such as a Hardware failure (eg. CPU failure). We do find the task scheduler functionality useful for scheduled maintenance and the dashboard is pretty sleek in reporting the results or show a status of an active task. We however did not feel comfortable with the VMWare integration feature and will look forward to more features in the later releases.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Michelle Crapo
    OK – I’m not system literate.  I don’t understand all the tests, done etc.

    In regular terms could you explain why VMWARE was not a good option at this time?  It looked like a lot of the test passed, and the issues were addressed.

    Thank you!

    Michelle

    Timely blog – we just had a Basis engineer come back from a conference and talk about VMWARE.

    (0) 
    1. Pise Mangesh Post author
      This was more of an operational confidence issue with managing VM guest hosts from within ACC. Basis engineers are experts in SAP Basis Technology and majority of them do not have enough operational knowledge about VMWare or other supported virtualization technology. Also, in order to be able to provision a VMWare guest server from ACC, a template needs to be created and there are no enough guidelines around what that template should look like so that ACC can provision a guest server.
      Bottomline, VMWare integration as a feature is great, but sometimes it makes sense to keep the core technologies where they belongs and in this case, server management seems more appropriate with the server teams.
      Note: The above comments are based on a certain operational structure and team structure.
      (0) 
      1. Michelle Crapo
        Thank you!

        Now I understand our engineer came back from the conference and said close to the same thing.  That many companies didn’t have the expertise in VMWARE.

        Very interesting indeed,

        Michelle

        (0) 
  2. Martin English
    Thanks for the tabulation of the results; very nicely done and easily readable.

    I noticed that when you relocated SAP instances, that you lost connection with them (because they were restarted on the new server).  I can understand why this is so.

    However, I don’t see what happened when (or if) you tried relocating the Virtual image that was running a given SAP instance.  Given what I’ve read about ACC, any application (be it SAP, FTP, IIS etc) should remain running.  Was this tested, and if so what results did you get ?

    thanks

    (0) 
    1. Pise Mangesh Post author
      As far as I know ACC cannot relocate the VM guest image, per say. One would have to use native vmware features like vMotion to relocate a VM guest image. However I believe (haven’t tested that myself) that the vMotion is seamless and no connections are lost. With ACC, however, one can provision a new VM guest image and then relocate other already running instances onto the new guest (use-case: harware failure or scale-up situations) ofcourse with a limited unavailability during the unprepare and prepare steps of relocation. With 7.3, it should also be able to install a new Dialog instance on the new VM image that is provisioned through ACC. Refer in the below discussion that provisioning VMWare guest images require VM templates.
      (0) 

Leave a Reply