Unsupported content

 

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Manually installing BMC Small RDS

This section describes how to install and configure BMC Small RDS.

Before you begin

This section provides the details that you must collect before you deploy BMC Cloud LifeCycle Management 4.0 Small RDS.

How long does it take to deploy BMC Small RDS?

Deployment time varies by environment. Deploying over a LAN is much quicker than installing over a WAN. LAN deployments per template in the BMC lab typically range from 30-60 minutes. Deploying through a firewall or over a WAN definitely slows deployment.

Manually deploying BMC Small RDS

 To manually deploy the Small RDS, use the steps in the following sections.

Note

If you want to Deploy OVF and DB Dumps using automation, see Auto-deploying BMC Small RDS.

Copying RDS images to the target vCenter or ESX host

Copy the VM OVF images from the USB drive to the datastore used by the target ESX host that will run the VMs. Depending on your network speed, copying the OVF images can consume an entire day, especially over SCP. Make sure you allocate sufficient copy time.

Use one of the following copy methods:

  • Use the Datastore Browser within the VMware vSphere Client:
  1. Connect the vSphere client to the vCenter instance managing the target ESX host.
  2. Using the vSphere client navigation bar, select Home Inventory Datastores.
     
  3. Right-click the datastore on which to place the VM images, and then click Browse Datastore.

    Note

    The VM images can be spread across multiple datastores.
  4. Click Upload files to this datastore to upload the folder for each VM image to the datastore.
     
  • Use WinSCP:
  1. Install WinSCP on your laptop
  2. Connect as root to the target ESX4 (vsphere) host
  3. Copy each set of VM files from the USB drive to the /vmfs/cloud folder of target ESX host
  • Use a Veeam client, which can speed the upload, but is more complicated than the previous two methods. Review the Veeam documentation for more details.

Note

To conserve disk space, the ESX VMs contain thin-provisioned virtual disks. NFS supports thin-provisioning only on newer NAS devices and you should avoid this for this implementation. If only NFS is provided and the ESX VMs enter the recovery shell # immediately after the vsd-mount service fails, then use one of the following workarounds:

  • Convert the thin disk to a larger thick disk:  
    vmkfstools –i <SourceThinDisk><TargetDisk>
  • Obtain another DataStore formatted with VMFS3—locally or SAN-based.

Deploying the images to the vCenter

In this section, you are deploying the following VM templates:

  • CLM-AR
  • CLM-BAO
  • CLM-BSA
  • CLM-BNA
  • CLM-MT
  • CLM-AWS
  • CLM-BCO
  • CLM-PM
  • CLM-PXE
  • CLM-PLANNER
  • CLM-AUTODEPLOY

Note

Use the use same hostnames as the OVF template names.  For example, if the template name is CLM-MT, then the deployed VM name/hostname should also be CLM-MT.

  1. Click Resource Pool to deploy the OVF template to the vSphere client.
     
  2. Select File > Deploy OVF Template.
  3. From the Source panel, browse to the OVF file to deploy and click Deploy.
    For example: 
     
  4. Click Next and continue to the Name and Location panel. 
  5. From the Name and Location dialog panel, make sure that the name is the name of the host that you are deploying.
    For example: CLM-MidTier
     
  6. Click Next
  7. From the Storage panel, select the destination storage on which you will place the VM.  
    The customer should provide this information. In some environments, you select a datastore instead. 

     
  8. Click Next
  9. Select Thin Provision and then click Next
  10. Review the network mapping and then click Next.
  11. From the Ready to Complete dialog box, make sure the settings listed below are correct and then click Finish button.
     
  12. Verify the following values with the customer before deploying any template to their environment.

    Deployment settingDescription
    OVF filePoints to correct OVF file location.
    NameEasily identifiable name which appears in vSphere client for the VM Host/Cluster.
    Host/ClusterObtain this information from the customer.
    Resource PoolObtain resource pool placement with the customer
    DatastoreVerify this information is correct.
  13. After deploying VMs, make sure that the CPU and RAM meet the required recommendations.

(optional) Registering the RDS Images with the target ESX Host

If the VM images are not registered to the target host, follow these instructions to register them with the target host.

  1. Use the Datastore Browser to view each VM image folder on the target datastore.
  2. Right-click the *.vmx file in each of these folders and select Add to Inventory.

Optionally, you can create a resource pool in the target ESX host and use it to manage the computing resources reserved for these VMs.

Verifying data and time on multiple ESX hosts

Verify the date and time in the ESX hosts when you use more than one ESX host in the implementation.  Mismatches in date and time can cause issues with BMC Cloud Lifecycle Management processes, such as AO workflow or AO service operations.

Adding OS and database licensing requirements

For information about licensing, see Licensing BMC Compact RDS.

BMC Small RDS operating system and application log on accounts

For detailed information on BMC Small RDS OS and application log on accounts, see BMC RDS operating system and application log on accounts.

Migrating the virtual appliance database to a customer’s physical computers

You can migrate the Oracle database either to a single Oracle server or to Oracle RAC

Migrating the database to a single Oracle server

Note

  • You can create the database on a standalone server or Oracle RAC with required instances. Accordingly you must modify the DB migration scripts. You can convert the DB migration script to Oracle SQL script and run to create table spaces and users.
  • To migrate the database using logical backup, create three database Instances before you start the migration process. This procedure assumes that the Oracle database has three Instances: <Inst1>, <Inst2>, and <Inst3> 

Start by migrating the ARADMIN schemas to <Inst1>.

  1. Log on to the Oracle server.
  2. Create a /home/oracle/pump_dir directory on Oracle server as the oracle user.
    This directory will be used by Oracle Data Pump for importing CLM schemas.

  3. Copy the database scripts to /home/oracle/pump_dir on the Oracle server.
  4. Edit the ARADMIN.txt script and replace +DATA1 with the oradata directory path of the target database
    For example, replace +DATA1 with /data1/oracle/app/oracle/oradata.

  5. Connect to the Oracle instance <Inst1> as the system user.
  6. (optional) At the SQL prompt, copy each SQL statement and create tablespaces and users.
  7. Exit SQL prompt.
  8. Import the Dumps into instance <Inst1> on the Oracle server by executing following impdp commands:
    impdp system/<password> SCHEMAS=ARADMIN directory=PUMP_DIR dumpfile=ARADMIN.dmp logfile=ARADMIN.log
    You finished the migration of ARAdmin.

  9. Exit the SQL prompt.
  10. Follow the same steps for the BCAN and BLADELOGIC DB import. Change the username and DB dumps names accordingly.

After the database schemas are migrated, modify the applications to point them to the new database.

Note

Before you begin

  1. Power on the VMs that run the BMC products.
  2. Add the VMs to the customer network.
  1. Point the Enterprise-AR VM (clm-ar) to the Oracle database.
    1. Stop the AR System service.
    2. Update the <Oracle_installed_dir>/network/admin/tnsnames.ora file with new details.
      For example:

      ARDB =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCP)(HOST = <Oracle Server host>)(PORT = <DB Port>))
          (CONNECT_DATA =
            (SERVER = DEDICATED)
            (SERVICE_NAME = <Inst1 Service name>)
          )
        )
    3. Start the AR System service.
    4. Log on to Enterprise-AR to make sure that the AR System service started properly.
  2. Point the BNA VM (clm-bna) to the Oracle database.
    1. Stop the BNA service
    2. Update database details in the /gfs/bmc/BCA-Networks-Data/database.properties file. 

    3. Locate the javax.jdo.option.ConnectionURL property name.

    4. Update the database details in the /opt/bmc/BCA-Networks/tomcat/conf/server.xml file.

    5. Locate the connectionURL property name.

    6. Update the database details in the /opt/bmc/BCA-Networks/BcanInstalledConfiguration.xml file.

    7. Locate the DATABASE_PORT_NUMBER and DATABASE_URL property names.

    8. Start the BNA service.

    9. Log on to the BNA BNA web console to make sure that the BNA service started properly. 

  3. Point the BSA VM to the Oracle database.
    1.  

      Stop the BSA application server.

    2. Update the database details with new database settings in the global.Properties file located in the /opt/bmc/bladelogic/NSH/br/deployments folder.

    3. Restart the BSA service. 

    4. Log on to the BMC Server Automation client to make sure that the BSA service started properly.

Migrating your database to Oracle RAC

Note

  • You can create the database on a standalone server or Oracle RAC with required instances. Accordingly you must modify the DB migration scripts. You can convert the DB migration script to Oracle SQL script and run to create table spaces and users.
  • To migrate the database using logical backup, create three database Instances on the Oracle RAC before you start the migration process. This procedure assumes that the Oracle RAC is hosted on two nodes – rac01 and rac02. The instances are <Inst1>, <Inst2>, and <Inst3>. The RAC uses ASM for storage of all data files.
  1. Log on to rac01 as the Oracle user.
  2. Create a /home/oracle/pump_dir directory on rac01 as the oracle user.
    This directory will be used by Oracle Data Pump for importing CLM schemas.

  3. Copy the ARADMIN.dmp file to the pump_dir directory. 
  4. Copy the database scripts to /home/oracle/pump_dir on the Oracle server.
  5. If necessary, edit the ARADMIN.txt script and replace +DATA1 with with the ASM name or that data path that is used for storage in the customer Oracle RAC.

  6. Connect to the Oracle instance <Inst1> as the system user.
  7. At the SQL prompt, run the SQL commands from ARADMIN.txt on <Inst1> instance.
    This script creates the table spaces and users required for CLM schema imports.
  8. Exit SQL prompt.
  9. Import the dumps as the oracle user into instance <Inst1> on node rac01 by executing following impdp commands:
    impdp system/<password> SCHEMAS=ARADMIN directory=PUMP_DIR dumpfile=ARADMIN.dmp logfile=ARADMIN.log
    You finished the migration of ARAdmin.

  10. Exit the SQL prompt.
  11. Follow the same steps for the BCAN and BLADELOGIC DB import. Change the username and DB dumps names accordingly.

After the database schemas are migrated, modify the applications to point them to the new database.

Note

Before you begin

  1. Power on the VMs that run the BMC products.
  2. Add the VMs to the customer network.
  1. Point the Enterprise-AR VM (clm-ar) to the Oracle database.
    1. Stop the AR System service.
    2. Update the <Oracle_installed_dir>/network/admin/tnsnames.ora file with new details.
      For example:

      ARDB =
      (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = <Oracle RAC Hostname>)(PORT = 1521))
      (CONNECT_DATA =
      	(SERVER = DEDICATED)
      	(SERVICE_NAME = <RAC service name>)
      	)
      )
    3. Start the AR System service.
    4. Log on to Enterprise-AR to make sure that the AR System service started properly.
  2. Point the BNA VM (clm-bna) to the Oracle database.
    1. Stop the BNA service
    2. Update database details in the /gfs/bmc/BCA-Networks-Data/database.properties file. 

    3. Locate the javax.jdo.option.ConnectionURL property name.

    4. Update the database details in the /opt/bmc/BCA-Networks/tomcat/conf/server.xml file.

    5. Locate the connectionURL property name.

    6. Update the database details in the /opt/bmc/BCA-Networks/BcanInstalledConfiguration.xml file.

    7. Locate the DATABASE_PORT_NUMBER and DATABASE_URL property names.

    8. Start the BNA service.

    9. Log on to the BNA BNA web console to make sure that the BNA service started properly. 

  3. Point the BSA VM to the Oracle database.
    1. Stop the BSA application server.

    2. Update the database details with new database settings in the global.Properties file located in the /opt/bmc/bladelogic/NSH/br/deployments folder.

    3. Restart the BSA service. 

    4. Log on to the BMC Server Automation client to make sure that the BSA service started properly.

Powering on the VMs

You must power on the virtual machines in the following order. Some of these pre-configured VMs require started applications before they can be powered on.  Following the sequence as shown starts the required applications in the required order. 

  1. BMC Atrium Orchestrator (clm-bao)
  2. BMC Server Automation (clm-bsa)
  3. BMC Network Automation (clm-bna)
  4. Cloud-AR 
  5. Platform Manager (OSGi)
  6. Enterprise-AR 
  7. Atrium Web Registry
  8. Mid Tier

Adding the VMs to a customer network 

The following steps might be necessary if you are placing the BMC Cloud Lifecycle Management version 4.0 virtual appliance into a customer network.  However, in some cases, the environment might be isolated and able to run as delivered.

Before you begin

Obtain IP and DNS information from the customer for assignment to the BMC Cloud Lifecycle Management 4.0 VMs.  This information will most likely be a pool of static IP addresses for use with the appliance.  Gather the following required information:

  • Pool of static IP addresses for the virtual appliance 4.0 images
  • Subnet mask address
  • Default Gateway address
  • Primary DNS Server
  • Secondary DNS Server
  • Tertiary DNS Server
  • Domain name (DNS Search Path), for example, bmc.com

To add the VMs to a customer network

Complete the following tasks to assign this information:

  1. Log on to the vSphere client with administrator privileges.
  2. Select the VM, select Edit virtual machine settings, and then select the Network Adapter device.
  3. Uncheck the device statuses of Connected and Connect at power on
    This action saves time when starting the VM, because the configured Network Adapter will likely not start as it is assigned to a BMC network when delivered.
  4. Right-click the  VM and select Power On.
  5. After the machine is powered on, right-click and select Open Console, and then log on as the root user
  6. From the console, select System > Administration > Network.
  7. From the Devices tab of the network dialog box, select the eth0 device and then select Edit from the toolbar.  Select the option for Static IP assignment, and then add the IP, Subnet Mask, and Default Gateway obtained from the customer.  Click OK to close the dialog box.
  8. Select the DNS tab and enter the DNS information that you obtained from the customer.
  9. Click File > Save to save the configuration changes.
  10. After completing the configuration changes, reset the Network Adapter device status to Connected and Connect at power on.  
  11. To complete the changes, restart the VM or open a terminal and restart the network service by issuing service network restart from the prompt.  Issue ifconfig to verify that eth0 configuration changes have taken place and that the IP information is correct.

Complete these steps above for all of the delivered images.

Related topic

BMC Small RDS deployment and configuration flow diagrams

Where to go from here

Configuring BMC RDS after deployment

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments