SAP Adaptive Computing Controller 7.2
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:
- Start and Stop instances,
- Relocation of instances,
- Task Planner / Scheduler,
- Monitoring, Reporting & Dashboards, and
- 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:
- Download software for NW 7.01 SR1, CE 7.2, ACC 7.2
- Install JRE 1.4.2 (SR13) on the Linux servers
- Install NW (SID = LNW) using the virtual hostnames lnwap01 (inst nr=00), lnwdb01 and lnwdi01 (inst nr=10)
- Install CE (SID = LAC) using virtual hostname lacap01 (inst nr=00, SCS nr=01)
- Perform SAP NW (LNW) Post installation steps
- Perform SAP CE (LAC) Post-installation steps. Look at the next section to perform the CE specific post installation steps.
- 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.
- Install SAPHostctrl on lnwap01, lnwdb01 and lnwdi01.
- 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.
- 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.
- 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:
- URL: http://lacap01.cardinalhealth.net:50000/NWA
- Follow : Configuration Management -> Scenarios -> Configuration Wizard
- Click the link “Functional Unit Configuration UI”
- Select “Java Foundation” and notice that the “System Landscape Directory” gets selected automatically.
- Click Enable automatically button
- Follow the wizard
- Select setup new SLD option
- Check the option: “This SLD will be used as name server for development”
- Follow the progress bar
- This takes some time since SLD is setup during the process
- Click “Return to the task list” and then select show: All configurations to perform the ACC configuration.
Setup ACC:
- URL: http://lacap01.cardinalhealth.net:50000/NWA
- Follow : Configuration Management à Scenarios -> Configuration Wizard
- Select: “Initial setup for Adaptive Computing Controller”
- Click Start button
- Select Custom Mode
- 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.
- Look for the progress bar on the screen
- Click “Return to the task list” and Log Off.
- 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 |
|
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.
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.
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.
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
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