Understand Application Tier Properties

Overview

The Topology tab contains three main sections (or panes in the Workload Manager UI):

  • Topology Modeler Graphical Workflow: The graphical workflow for each application. When you click on a specific tier in the graphical workflow for each application, you see the configurable parameters and fields for that tier.

  • Topology Modeler Services: Type and group of the defined or selected service. Service properties differ based on the selected service.

    Depending on the service that you select in this section, the corresponding parameters and settings may differ for each service in the Properties section.

  • Topology Modeler Properties: Application properties defined using service parameters to further qualify application actions. This section explains the Properties that you can configure for an application tier.

    These properties include a list of property groups that are used in one or more Out-of-box (OOB) services offered by Workload Manager.

    Each property group explained below will differ based on the service that you model or deploy.

    This section provides a list of all the parameters in each property group. If the properties differ, they are explained in the respective OOB Application Services.

Terminology

TermDefinition
Service

A reusable component that operates on the supported OOB Base OS Images.

You can define a new service to capture framework dependencies (called when you onboard or migrate one or more applications).

Service library
Custom service

A user-defined service that resides in the service library.

External serviceAny service that resides in another location. See External Service for additional context.
Application stackA composite topology that includes a variety of formats of services, images, and containers.
Topology ModelerA Workload Manager UI tool used to model an application profile using various profile templates and out of box services, images, and containers. See Define Application Topology for additional context.
Service Lifecycle Actions

The actions to per-determine granular steps of the service deployment process for each application. See Service Lifecycle Actions for additional context.

General Settings

This section is unique based on how the service was defined. 

The following table lists the configurable properties to ensure that the application is functioning.

Properties

Description

Name

A descriptive name for this service.

Base Image

The OOB Base OS Images in which you are installing this service.

Minimum number of nodes

The minimum number of nodes (VMs) in this cluster.

If the number of active VMs (nodes) is lower than the number specified in this field, then the application may not function as designed.

Maximum number of nodes

The maximum number of nodes in this cluster.

Once the number specified in this field is reached, then the application cannot be scaled.

Number of Volumes

Number of persistent data storage volumes for Web Server. 

See Multiple Volumes for additional context.

Default Volume Size

Persistent data storage for Web Server. Persistent Storage is defined by default for database tiers, but can be assigned manually to any tier

See Multiple Volumes for additional context.

Allowed Scaling Polices

A list of available policies for this application with each policy having an info icon that displays additional details on time duration, CPU utilization, and other details. See Policy Management for additional details on each type of policy.

  • If you do not select an allowed scaling policy for a tier, the scaling policy field for that tier is hidden in the deploy form and no scaling policies can be selected by users at deploy time.
  • If only one allowed scaling policy is selected, the corresponding visibility toggle is enabled and set to on by default.  If one policy is selected and the visible toggle is turned off, the scaling policy cannot be disabled at deploy time, but is still applied to the deployment behind the scenes.

  • If at least one policy is selected, a mandatory toggle is displayed to the right of the visibility toggle and a deploy time preview link appears under the allowed scaling  policies field.
Visible: Identifies if the selected policy should be visible (ON) to users in your tenant and makes it visible in the deploy flow.
Mandatory: This setting is only available if you switch on visibility and allows you to determine if this application should require this policy (ON) or it is an optional setting (OFF)

Deploy Time Preview: Identifies the required time-based option for the selected policies. Refer to the info icon for the required policy in the previous step to select the corresponding option.

Click the Deploy Time Preview link for a popup window to display the tier scaling policy dropdown field's appearance for that tier in the per-tier section on Page 1 of the Deploy form.

Associate Tags

A label that consists of a name and an optional description for metadata association and for tracking purposes. See System Tags for additional details.

App Config files

This field is specific to the web server. Application config files that contain system Parameters and Macros that may need to be modified at deployment time. The config file uses a relative path from the web app root folder, for example, webinfo.conf. If you are configuring multiple files, separate each file in the list using a semicolon.

See Configuration Files and Parameter Substitution for additional context.

Deploy Folder

This field is specific to the web server. When you deploy an web server application, use this field to specify the /service/var/www/html root path where the folder must be created. For example, if your folder is called Doc, then this folder is created as /apache/var/www/html/Doc.

The app binaries are unzipped in this folder before deployment.

Associate Tags

You can associate system tags with application profiles and application deployments, either at the tier level or globally.

See System Tag for additional context.

External Initialization

Defines the scripts to be run before (pre) and after (post) the start of the Service or pre/post stopping of the service when the application is rebooted, suspended, or terminated.

External Initialization scripts are run at the same time as their equivalent service initialization scripts, but are run from an isolated container on Docker (see Dedicated Docker Registry).

See External Service for additional details on this section.

You must configure the information explained in this section:

  • If your deployment uses external services, to ensure that the application is functioning.

  • To ensure that the node is functioning.

The following table lists the configurable properties that define each script execution.

Properties

Description

VM Pre-Prevision ScriptScript executed before the application VM is provisioned.
VM Pre-Initialization ScriptScript executed before the application VM service is initialized.
VM Post-Start ScriptScript executed after the application VM service is started.
VM Pre-Terminate ScriptScript executed before the application VM is terminated.
VM Post-Terminate ScriptScript executed after the application VM is terminated.

Node Initialization & Clean Up

You must configure the information explained in this section to ensure that the application is functioning.

See Deployment Lifecycle Scripts for additional details on this section.

Each node initialization and clean up script is run once for each VM function.

The following table lists the configurable properties for node initialization.

Properties

Description

Initialization script

Cleanup script

Downloaded and executed at the time of deployment termination. See Deployment Lifecycle Scripts > Lifecycle Action Script Definition 

Resume Script

Downloaded and executed when the VM is suspended and restarted. See Deployment Lifecycle Scripts > Lifecycle Action Script Definition

Deploy Packages

External packages required for each VM are bundled and referenced as an application content package in the application profile. For example, php5 sendmail. See the following pages for additional details:    

Sudo command list (Linux VMs only)

Specify a list of semicolon separated commands that may be executed with superuser privileges. Use ALL to allow any command to be executed with superuser privileges.

Service Initialization

This section defines the scripts to be run before (pre) and after (post) the start of the Service or pre/post stopping of the service when the application is rebooted, suspended, or terminated.

Once the node initialization is complete, CloudCenter downloads the Bundle Store to the VM and unzips the file in the specified location. See Deployment Lifecycle Scripts for additional details.

You must configure the information explained in this section to ensure that the application is functioning.

Service initialization actions at the application tier level are not called automatically. You must call them explicitly from within the service scripts.

This behavior is different from other initialization actions (like external initialization and node initialization actions) that are called automatically.

The following table lists the configurable properties after node initialization is complete.

Properties

Description

Pre-Start ScriptScript executed before the service is started.
Post-Start ScriptScript executed after the service is started.
Pre-Stop Script Script executed before the service is stopped.
Post-Stop ScriptScript executed after the service is stopped.

Firewall Rules

The firewall rules that are specified as part of the application profile are used to configure the cloud provider firewall. These firewall rules can be applied to Cloud based Security Groups or features like ACI contracts.

Although it is not possible to explicitly specify security policies for each tier in the application profile, any allowed security policy specified in the deployment environment form can be selectively applied to each tier at deploy time. If you want to define per tier security policies that are unique to each tier, consider defining firewall rules for each tier in the application profile instead.

If microsegmentation is enabled:

If you disable microsegmentation, after enabling it and configuring any change, all firewall rules revert to the initial state – any changes associated with the microsegmentation configuration are lost.

  • The default firewall rule for a service are automatically displayed in this section if it is the top tier for the app or at any tier level if .

  • If service-level microsegmentation is enabled, you can restrict any firewall rule to any tier by specifying the tier name or IP for the source.

  • See Security and Firewall Rules for additional context.

As soon as you connect the service in the Topology Modeler, the IP column in the Firewall Rules section automatically updates to display the Apache service tier name. You can choose to keep the preconfigured firewall definition or add additional Firewall rules as required. 

The following table lists the configurable properties for service-level firewall rules.

PropertiesDescription
IP Protocol

Defines the protocol to be used by VMs running this service.

  • TCP: Transmission Control Protocol
  • UDP: User Datagram Protocol
From Port

The initial port number of the port range to use for the inbound firewall rule (or security rule).

To PortThe final port number of the port range to use for the inbound firewall rule (or security rule).
IP/CIDR/TIERThe default CIDR for the application tier defaults to 0.0.0.0/0.

Deployment Parameters

Once the Node initialization is complete, the application is capable of functioning as configured. Once the node is up, the utility files can be sourced in the script. See Deployment Parameters for additional context.

To add additional parameters that are specific to each step or tier, provide the parameter information listed in the following table. 

Properties

Description

Parameter NameIdentifies the name for this custom parameter.
Display NameIdentifies the display details for this custom parameter.
Help TextIdentifies the help text required when using this custom parameter.
TypeSee Using Parameters > Parameter Type.
Default ValueIdentifies a default value, if provided, for this custom parameter.
User Option Checks

See Using Parameters > Granular Control for User-Defined Parameters.

Hardware Specification

Identifies the hardware specification for each application tier. The following table lists the properties used to filter the instance type based on your minimum hardware provisioned for your deployment.

Properties

Description

CPUs Needed

See Manage Instance Types.

MemorySee Manage Instance Types.
Network InterfacesSee IP address allocation. 

Scratch Disk Storage (Local Storage )

See Manage Instance Types.


Environment Variables

Environment variables help servers find the directory to install files, the location to store temporary files, and the settings to find the user profile(s).

This section is similar to Custom Parameters for N-Tier applications. The only difference is that you can define the type for Custom Parameters (type is not configurable for Environment Variables).

The following table lists the configurable properties for environment variables.

Properties

Description

NameIdentifies the name for this environment variable.
ValueIdentifies a value for this environment variable.

User Options

  • Visible
  • Editable
  • Optional

See the following pages for additional context:

Migration

You can set migration parameters that your application may need here. The migration for the Database tier will be done automatically, if the scripts are not specified. See Deployment Lifecycle Scripts for additional context.

The following table lists the configurable properties for migration scripts.

Properties

Description

Pre Migrate ScriptScript is executed before the backup.
Backup ScriptBackup Script writes the backup files to a Backup Folder.
Backup Location

Location (path) where the application files are backed up/restored.

This is a required field for any application requiring data backup.

Restore ScriptRead from the backup files in the Backup folder. The Restore Script runs after the service is started and the Post-Start Script has run, except in case of the Database tier, where the Post-Start Script runs after the Restore Script.
Post Migrate ScriptScript executed after the restore is run.

Upgrade

You can upgrade an existing deployment by specifying the upgrade scripts for each tier. Specify the upgrade parameters in the sequence to be executed. See Deployment Lifecycle Scripts for additional context.

The following table lists the configurable properties for deployment upgrades.

Properties

Description

Upgrade Type

Define upgrade scripts for the node:

  • Auto: Upgrade the tier with latest package and any backup/restore content (if specified).
  • Advance: Allow additional scripts and steps during the upgrade process. You can specify scripts for each step separately.
  • None: Exclude the Node/Tier from upgrading.
Pre Upgrade ScriptScript is executed before the upgrade.
Post Upgrade ScriptScript is executed after the upgrade.

Other References

The following table lists additional references related to application tier configuration.

TaskReference Link
Model a new application profileSee New Application Profile.
Model an applicationSee New Application.
Understand the Topology ModelerSee Topology Modeler.
Understand application modelingSee Application Lifecycle Management.
Understand script lifecycle flowSee Deployment Lifecycle Scripts.
List of supported servicesSee OOB Services.
Add a New ServiceSee Custom Service Definition.
Manage Services and ScriptsSee Service Administration.
ParametersSee Using Parameters.


Back to: OOB Application Services

  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved