- SAP Systems (Managed SAP Systems) – Each of these systems consist of software running on one or more machines (bare metal, or in the case of VLA environments, virtual machines [VMs] hosted on VMware vSphere™ products [ESXi systems managed by vCenter Server™]) that perform some business function, such as order processing, accounts payable, general ledger, inventory management, etc. Each SAP System consists of one or more components like a database service, SAP instance or SAP Host Agent service. When all of the components are up and running, the SAP System is running. When all of the components are stopped, the SAP system is stopped. If some systems are running and some are not, the SAP system is in an intermediate state.
-
The SAP Landscape Management (LaMa) VM – The SAP Landscape Management (LaMa) application runs on ABAP or Java stack in a Linux based guest OS. It provides a web-based user interface for SAP BASIS administrators to create / destroy / configure / and otherwise operate on and provision SAP Systems and their underlying machinery (bare metal or virtualized).
The SAP Landscape Management (LaMa) has an extensible architecture that allows SAP and third-party vendors, for example VMware, to create plugins to extend certain features.
- The VMware Adapter for SAP Landscape Management — This is a plugin to LaMa that extends how LaMa integrates with the underlying systems virtualized with VMware vSphere (see next bullet), optimizing and extending the functionality for certain operations, such as activating (powering on) and deactivating (powering off), copying and cloning systems, and automation of these copying and cloning operations.
-
ESXi and vCenter Server (collectively called vSphere) – ESXi is VMware’s premier hypervisor product. VI administrators typically install it on bare-metal server-class computers, with VMs running guest operating systems (OSes) with SAP Systems as applications within the guests. vCenter Server is VMware’s premier product for managing environments virtualized with ESXi. Collectively called vSphere, these products provide an enterprise-class environment with features for creating clusters, load balancing VMs between host systems (ESXi instances), fault tolerance, virtual networking, virtual storage, and more. In VLA environments, the VLA appliance (next bullet) runs in a VM on this infrastructure.
Note: It is possible to run ESXi in a nested environment. In this case, VI administrators install ESXi in a VM running in a vSphere environment. For more information on vSphere Templates, see http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.hostclient.doc%2FGUID-F40130B0-0194-4A41-91FA-1A967721924B.html. For more information about vApps, see http://pubs.vmware.com/vsphere-6-5/index.jsp?topic=%2Fcom.vmware.powercli.ug.doc%2FGUID-CFCCBEAC-74DD-4259-9D9D-1FCCCB185218.html - VMware vRealize Orchestrator™ – This VMware product helps VI administrators automate their environments by creating work flows (essentially scripts) that perform VI administrative actions, including complex actions that may take multiple steps, involve loops, conditions, etc. VMware vRealize Orchestrator workflows can handle exceptions automatically or can pause waiting for a VI administrator to mitigate an issue. See the next bullet for how VLA uses VMware vRealize Orchestrator.
- VMware Landscape Management Appliance (VLA) – This part of the VLA product is a virtual appliance. It maintains connection with one or more vCenters, contains a repository of inventory data and user credentials and executes operations at VMs, ESX hosts, datastores or networks by utilizing VMware vRealize Orchestrator (vRO). Collectively, it consists of one or more web services that accepts commands from (previously discussed) LaMa VLA Adapter and take appropriate actions to implement the commands, typically with the help of the (previously discussed) VMware vRealize Orchestrator. For example:
- When a SAP BASIS administrator activates (powers on) a SAP System via LaMa, the VLA Adapter sends commands to the vla-service (discussed later in this topic) to power on the underlying VMs. The vla-service in turn invokes a VLA-specific workflow on the VMware vRealize Orchestrator to turn on the VMs in the underlying vSphere infrastructure. An analogous action occurs when a SAP BASIS administrator deactivates (powers off) a SAP System.
-
When a SAP BASIS administrator copies a SAP System, the VLA Adapter sends commands to the vla-service which in turn invokes a VLA-specific VMware vRealize Orchestrator workflow to create vSphere copies of the VMs on which the SAP Systems reside, configuring the VMs according to the parameters provided by the SAP BASIS administrator in the LaMa web user interface.
The VLA Appliance contains several components, including:- A purpose-configured and hardened operating system (OS)
- A minimalist set of OS utilities and VLA-specific programs and configuration files required to provide the functionality described here. These include:
- The vla-service — A web service running in tomcat that receives and processes commands from the VLA Adapter. It also serves out the VLA dashboard web UI. By default, this server listens on port 8443.
- Tomcat user database — Database with usernames / passwords used to authenticate access to that instance’s services. VI Administrators create an entry in the database for the VLA instance during deployment of the VLA environment using the vla_user command as detailed later in this document.
- A
credentials store(separate from the username / password database for tomcat access) that contains information needed for the various components of the VLA environment to communicate with one another. Each entry in the credentials store includes a component type (vRealize Orchestrator, LaMa, vCenter Server etc), the hostname and port (if configurable) for the component’s API, and a username / password used to authenticate to the component’s API. You create entries in this database using the vla_credentials command as detailed later in this document.
