SAP Adaptive Computing Controller 7.2

[former_member197442]

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	Automatically detects # of CPUs, RAM Shows utilization of h/w resources 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.