The purpose of this article is to provide a sample Application Profile for Microsoft SQL, leveraging the Amazon AWS RDS service included with CloudCenter. CloudCenter's RDS service is designed in a way that allows you to customize the parameters and values that RDS accepts, so you can adjust what you need from AWS dynamically from CloudCenter, including the Database Engine and version. Attached is a sample Application profile that takes advantage of this, and presents you with some of the available options you can choose for the Microsoft SQL Engine when deploying. For more information on the available variables you can choose, please see the following article, published by Amazon: CreateDBInstance - Amazon Relational Database Service Below are the Custom Parameters defined in the attached profile, along with their mapping to RDS: Script Parameter Maps To Sample Variables cliqrRdsEngine Engine sqlserver-se, sqlserver-ee cliqrRdsEngineVersion EngineVersion 12.00.5000.0.v1, 13.00.2164.0.v1 cliqrRDSLicenseModel LicenseModel license-included dbSubnetGroup DBSubnetGroupName default cliqrDBDataStorageSize AllocatedStorage 300 cliqrIsPublicAccessible PubliclyAccessible true, false cliqrStorageType StorageType standard, gp2 Instructions for importing: Download the attached file MSSQL-RDS.zip From the CloudCenter Manager, go to Applications (App Profiles in 4.8.x). Select Import/Profile Package in the upper right of the Application Profiles page. Click Upload Profile Package and locate where you saved the MSSQL-RDS.zip file. Select the MSSQL-RDS.zip file and click Open. Your profile should be loaded and ready to use! **Important note** - In CloudCenter versions 4.8.0 and below, the RDS service script has an issue where the cliqrDBDataStorageSize parameter is not honored, and defaults to '100'. This causes an issue when deploying SQL Enterprise and Standard, which has a requirement of 200GB or more for the DB storage size. To correct this, the RDS service will need to refer to an updated version of the script in your own repository during the Start sequence, located in our c3-communities GitHub repo.
... View more
Summary: In most cases, the default logging levels set in CloudCenter should be sufficient to understand what is happening during the startup and transaction processing of the CCO and CCM appliances. There are some scenarios where additional information is desired or required in order to successfully troubleshoot an issue. Depending on what is being troubleshot, you may need to look at the output from the Orchestrator (CCO) or the Manager (CCM), or both. This article includes the areas and instruction where enhanced logging can be enabled for the osmosix.log file, as well as examples of which appliance you will want to look at for the most relevant log detail. CloudCenter version 4.7 brings additional ways to more easily view the log files, without having to enter the command line of any given appliance. Additionally version 4.8 enhances this by giving you logging detail from the worker itself, which greatly improves the ability to troubleshoot. Information about how to set up an ELK server that 4.7 and above leverages is not covered in this article. Please reference the following URL for more information about ELK server logging: Download Log File - Version 4.6 and 4.7 - CloudCenter Docs Things to be aware of: Increasing the level of logging can negatively impact the performance of the machine where this has been enabled. The impact usually isn't significant enough to warrant an after hours change window, but still is not recommended to maintain as set in production for long periods of time. As with any best practice, ensure you have a back up of any files you will be editing, in case a revert to original is required. How To: To enable enhanced logging of the osmosix.log file do the following: Log into the console of the desired appliance (CCM, CCO) either through SSH or direct. Switch to root: "sudo -i" <-- without quotes Edit the log4j.xml file with this command: "vi /usr/local/tomcat/webapps/ROOT/WEB-INF/classes/log4j.xml" <-- without quotes Press the "i" key to enter edit (insert) mode. Scroll down to locate the section called <!-- Application Loggers --> Under here are a number of different areas that can be adjusted. Each logger type has a 'logger name' and 'level value'. Change the "info" field to "debug" for the logger you wish to enhance. In most scenarios, the loggers 'com.osmosix' and 'com.cliqr' are of most interest. The other loggers can be increased as well, but they could introduce too much information, confusing the debugging process. Which Appliance and Which Logger for Which Scenario? Not all logging will need to be enabled in all appliances to fit your needs. When determining if you need enhanced logging, you first need to look at the problem you are trying to troubleshoot. Some scenarios and the choice are more obvious than others. Below are a few examples of where you want to look for the log information: Are you trying to troubleshoot an issue where.... ...you see a problem while inside of the UI of the CCM? - Look at the CCM logs ...you have an API that is sending calls to CloudCenter, such as from an external source like Jenkins or Service Now? - Look at the CCM logs ...you submit a job that contains an External Service that you are having troubles with? - Look at the CCO logs of the Cloud where you submit the job ...the application isn't deploying on the destination cloud, or errs out? - Look at the CCO logs in most cases ...your Orchestrator isn't registering with the Manager? - You may need to look at both the CCM and related CCO. (assuming the CCO is already registered and connected to the AMQP server) Loggers <logger name="com.osmosix"> Enable debug in most scenarios that require enhanced logging. <logger name="com.cliqr"> Enable debug in most scenarios that require enhanced logging. <logger name="com.osmosix.commons.communication"> Enable usually when troubleshooting communications related issues. This produces a lot of extra logging, so be aware.
... View more
Summary: The purpose of this document is to provide instruction for cases where the administrator of a CloudCenter environment may want to extend the amount of time it takes before the Manager login will timeout and return to the login screen. This is useful for demonstration scenarios in particular, where there may be periods of discussion in between actions. While best practice is to save your work as you go, this could also be useful for admins who are modeling applications, who require research time in between fields. Please use caution and understand the risks before implementing this, as the extended timeout could increase the chances for an unwanted individual to gain access to an unattended desktop. Steps: Connect to the CCM console via SSH or directly. Edit the web.xml file by using the following command: "vi /usr/local/tomcat/webapps/ROOT/WEB-INF/web.xml" <-- without the quotes Find the line for <session-timeout>15</session-timeout> Press "i" to enter edit (insert) mode Change the value of 15 to your preferred value, in minutes Press escape to exit edit mode Save and exit the file by typing ":wq!" <-- without the quotes Restart the Tomcat server (/etc/init.d/tomcat restart) Once the Tomcat service is up and running, your new timeout should be in place! Please note, there are other things that can affect the prompt for login, such as additional logins from other browsers using the same credentials. This is especially noticeable in a demo scenario, where you may have many people showing the same environment at the same time.
... View more
Credit goes to demehta for writing this article! Overview At various stages in the deployment lifecycle of VMs, Cisco CloudCenter supports the ability to control the behavior of the provisioning process. The different lifecycle points where the behavior can be controlled are called topics. The behavior is controlled by scripts via callouts that are assigned to topics. Some common use cases for callouts are as follows Query an IPAM tool during the IP Address Allocation (IPAM) topic to get an IP address and during the IP shutdown topic (IPAM2) to de-allocate the IP address. Assign static IP address to the nodes during deployment time and release the IP address back to the pool upon tear down of the deployment. Configure the name of the VM that is going to be deployed Initiate some clean up action before terminating a deployment The callout scripts are configured on a per-CCO (Cloud Center Orchestrator) basis and thus allowing users to control the deployment behavior based on the target cloud. Each callout consists of two key parts: a configuration file (callout.conf) and the script to be executed. These files are placed in the /usr/local/osmosix/callout/<name> path on the CCO. The name of the sub-folder that you use is arbitrary, but a best-practice is to use the name of the topic that the callout is for. Ex: /usr/local/osmosix/callout/ipam/<files> Each callout script, when executed from CloudCenter, has access to a wide variety of environment variables that can be used, including cloud type, deployment environment, etc. A full list is available in the callout script log at /usr/local/osmosix/callout/<name>/logs/<logs> The callout scripts use the same parameters and incoming variables. However, each callout script exposes a different variable and they are mutually exclusive. Please refer to the following URL for more information about Callouts in CloudCenter http://docs.cloudcenter.cisco.com/display/CCD46/Callout+Scripts Use Case: Using callout to assign static IP address during deployment time Sometimes there is a requirement to assign static IP addresses to the VM’s during application deployment. This may be due to the application requirement or the cloud environment requirement. For this use case, we will use the IPAM callout topic to assign static IP addresses to the VM’s during deployment time. We need to configure the callout on the CCO before we begin to deploy applications by providing static IP address at deployment time. Following are the steps to configure the callout on the CCO 1. First, we need to create a folder on the CCO under the callout directory on the CCO. To keep things simple, we will create a directory called ipam-static /usr/local/osmosix/callout/ipam-static/ 2. Create the following file in the ipam-static directory /usr/local/osmosix/callout/ipam-static/callout.conf The key value pairs for the callout.conf are as follows callout.conf
The name must match the dir name that we have configured in Step 1. 3. Create the script run.sh in the ipam-static dir This script is that one that is going to fetch the IP address that we need to assign to the deployed node. The IP address can be read from a file or any other source. Also, all of the parameters specified during deployment time and the cloud environment variables are available to this script. A sample run.sh that will fetch the IP Addr depending on the env is as follows: run.sh
# Get the Env Details. In this case as part of the App Profile we will define a custom variable "DEP_ENV" to indicate which list to pick the IP from
# CloudCenter CCO will be passed the variable by prefix it with eNV as shown below.
# File to fetch the IP from. These files will be stored on the CCO and will maintain the IP Addr list.
# Fetch the first available IP Address from the list and mark the status as used
ipAddr=`grep -m 1 "available" $fname | cut -d' ' -f1`
# Change the status of the IP Address from available to used
sed -i -e /$ipAddr/s/available/used/ $fname
# Configure the key value pairs that are needed to be passed to the VM for static IP Address configuration
# These value pairs will be used by the CCO to configure the static IP Address for the deployed VM
echo "nicDnsServerList_0=22.214.171.124"; # DNS Server List can also be dynamically fetched from the file.
echo "nicGateway_0=10.0.0.1" ; # Gateway can also be dynamically fetched from the file.
echo "nicNetmask_0=255.255.255.0"; # Netmask can also be dynamically fetched from the file.
4. Ensure that run.sh has executable permissions chmod +x run.sh 5. In this case, the 2 files (dep_ip_list and prod_ip_list) that maintain the ip list will also be in the same location as run.sh i.e /usr/local/osmosix/callout/ipam-static/ The sample entries in these files look like as follows dev_ip_list
At this point we have configured all of the steps that we need as part of the callout. The next step is to configure the App profile so that we can specify a static IP address during deployment. As part of the App profile, we are going to create a custom parameter as shown below During deployment time, depending on the Environment that the user selects, the callout script will automatically fetch the IP address to be assigned to the VM's. Please note that the run.sh script is a sample script to showcase how callout's can be configured in CloudCenter to manage static IP addresses. The script can be customized to meet the user's requirement. Some examples are as follows User can specify the IP Address to be assigned as part of the App profile In this can we can define a custom parameter to take the IP Address as input during deployment. The logic for the callout script will read this IP and can check against a list to see if it is available or assigned and take actions accordingly. Pick IP address depending on the Environment where the VM is deployed and configure a domain name for the deployed VM In this case, we can also specify domain name as an additional parameter and the script will configure the IP Address and then configure the domain name as well.
... View more