- Preface
- Overview
- Before Installing Broadband Access Center
- Installing Broadband Access Center
- Post-Installation Activities
- Upgrading Broadband Access Center
- Setting Up a Device Provisioning Engine
- Uninstalling Broadband Access Center
- Network Registrar Configuration File Example
- Installation Worksheet
- Index
Upgrading Broadband Access Center
This chapter describes how to upgrade a Cisco Broadband Access Center for Cable (BACC) 2.6.2.7 installation to Cisco Broadband Access Center (BAC) 4.0. If you have a BAC release preceding BACC 2.6.2.7, you must first upgrade your system to BACC 2.6.2.7 and then complete this upgrade procedure.
This BAC release supports online migration, using which you can migrate one server at a time without disrupting the entire BAC deployment.
Before upgrading to 4.0, ensure that you obtain the license file that this release supports. Once the upgrade is complete, the installation program deletes all existing license keys. You must then install the license file that 4.0 supports using the administrator user interface. For details on obtaining and installing the license file, see the
Release Notes for the Cisco Broadband Access Center 4.0.
Table 5-1 summarizes the upgrade tasks required for the different BAC components.
When upgrading to 4.0 from 2.6.2.7, you must enter a new target location for these directories:
–Home (BPR_HOME)
–Data (BPR_DATA)
–Database logs (BPR_DBLOG)
Note Once the upgrade is complete, BAC does not restart the process watchdog (bprAgent) automatically. You must migrate your existing database first.
The BAC online upgrade procedure requires that you upgrade the components in the order specified below. Performing the upgrade in any other order results in errors during provisioning.
4. Upgrading Network Registrar Extensions
Before You Begin
Before upgrading BAC components, ensure that you back up the RDU database files.
To back up the RDU database, run the backupDb.sh script in the BPR_HOME/rdu/bin directory.
For example:
# backupDb.sh /var/backup
where /var/backup identifies the database backup directory.
In this example, all backup database files are stored in a directory called /var/backup/rdu-backup-20071116-031028. The last subdirectory (rdu-backup-20070316-111028) is automatically created with a current time stamp.
Note The time-stamped subdirectory format is rdu-backup-yyyyMMdd-HHmmss. In this example, the subdirectory would be rdu-backup-20071116-031028, meaning that the directory contains a backup that was started at 3:10:28 a.m. on November 16, 2007.
For additional information on using the backupDb.sh tool, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
Upgrading the RDU
Before upgrading the RDU, we recommend that you archive your files in the BPR_HOME/rdu/conf directory.
To upgrade the RDU:
Step 1 Disable access to the RDU from the operations support system.
Step 2 Back up the existing RDU database, using the backupDb.sh tool. For details, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
For example:
# /opt/CSCObpr/rdu/bin/backupDb.sh -nosubdir /disk1/backup
•-nosubdir—Disables the automatic creation of a subdirectory. If you do not use this option, a subdirectory is created and reported to the console.
•/disk1/backup—Identifies the location for the database backup files.
Step 3 Verify if the database has been backed up by checking the history.log file, which resides in the BPR_DATA directory.
Step 4 Restore the database that you have backed up to a consistent state, using the recoverDb.sh tool. For details, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
For example:
# /opt/CSCObpr/rdu/bin/recoverDb.sh /disk1/backup
where /disk1/backup identifies the location of the database backup files.
Step 5 Copy the backed-up database to a safe location.
Step 6 If the operating system (OS) on which the existing BAC version runs does not meet the requirements for the 4.0 release, upgrade the OS.
Step 7 Install the 4.0 version.
For example:
# pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac
The installation program prompts you to enter locations for the:
•Home directory (BPR_HOME)
•Database directory (BPR_DATA)
•Database logs directory (BPR_DBLOG)
It then upgrades the necessary libraries and property files but leaves your RDU database intact. After installation is complete, it prompts you to migrate your RDU database.
Step 8 After the installation is complete, upgrade the RDU database by following the steps described in Migrating the RDU Database.
Upgrading the DPE
Before upgrading your DPE, we recommend that you archive your files in the BPR_HOME/dpe/conf directory.
To upgrade the installed DPE from BACC 2.6.2.7 to BAC 4.0:
Step 1 Run the pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac command.
Output similar to the following appears. The output has been trimmed for brevity.
Processing package instance <CSCObac> from </var/CSCObac.pkg>
Cisco BAC product
(sparc) 4.0
CSCObpr
Welcome to the Cisco Broadband Access Center for (BAC) installation program. This installation program installs BAC on your system.
Press Enter to Continue or q to Quit:
Upgrading BAC from 2.6.2.7 to 4.0. Are you sure? [n]: y
Stopping BAC Process Watchdog...
...
File installation completed.
...
Installation of <CSCObac> was successful.
Step 2 To verify if the version information indicates BAC release 4.0, enter:
# pkgparam CSCObac VERSION
Step 3 You must manually restart the DPE process to finish the upgrade process.
For example, from the command line, run:
# /etc/init.d/bprAgent start dpe
Upgrading Network Registrar Extensions
Before upgrading Cisco Network Registrar extensions, we recommend that you archive your files in the BPR_HOME/cnr_ep/conf directory.
To upgrade the Network Registrar extensions from BACC 2.6.2.7 to BAC 4.0:
Step 1 Run the pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac command.
Step 2 Stop the Network Registrar Server Agent when prompted.
The upgrade script automatically copies the upgraded extension point files to the required directories. When complete, it prompts you to restart the Network Registrar Server Agent.
Step 3 To verify if the output information indicates BAC release 4.0, enter:
# pkgparam CSCObac VERSION
Step 4 Go to the BPR_HOME/lib directory. If the upgrade was successful, the directory content appears similar to the list of installed files for the DPE upgrade with the addition of the libbprextensions-2x.so file.
Step 5 If a second check is required to verify upgrade success, go to the CNR_HOME/extensions/dhcp/dex directory and verify that these files appear:
-rwxr-xr-x 1 root bin 60904 Oct 29 2003 libdexextension.so
-rwxr-xr-x 1 root other 1530628 Jul 22 12:43 libbprextensions-2x.so
-rwxr-xr-x 1 root other 1560748 Aug 11 12:49 libbprextensions.so
Depending on the components installed, the directory content shown in this procedure may differ from the output featured above.
Upgrading the KDC
Note The BAC 4.0 KDC requires a new license. Before you start the BAC process watchdog, ensure that the correct license and certificates are installed.
To upgrade the KDC from BACC 2.6.2 to BAC 4.0:
Step 1 Run the pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac command.
Step 2 Manually start the BAC process watchdog to complete the upgrade process.
Step 3 To verify if the output information indicates BAC release 4.0, enter:
# pkgparam CSCObac VERSION
Migrating the RDU Database
The RDU database migration script lets you migrate your RDU database from BACC 2.6.2.7 to BAC 4.0.
Migrating involves two distinct phases:
1. Phase 1—This phase is performed after BAC in installed and is executed via the migrateDb.sh tool.
2. Phase 2—This phase is executed when the RDU is first started up after the first phase of migration is complete.
The migration script (migrateDb.sh) is automatically installed when you run the BAC 4.0 installation program (pkgadd). Migration is accomplished by reading from the original database and writing it into a new database. For this purpose, you must allocate additional disk space for accommodating the newly created database.
The status of the first phase of migration is recorded in a migration log file, which is stored in the migrated database directory. The migration.log file identifies the version of the database that is being migrated and provides status messages for the migration process.
Note Migration deletes any outstanding jobs stored in the database, such as reliable batches that did not finish execution or pending Configuration Regeneration Service (CRS) jobs.
Backwards Compatibility
You can use the 4.0 RDU with a migrated database to operate with earlier versions of Solaris DPEs and Network Registrar servers for gradual online migration.
Migration preserves the device record revision numbers used in DPE synchronization. As a result, DPE repopulation is not triggered after the RDU database upgrade, ensuring the least disruption until you upgrade the specific DPE.
Note This BAC release provides multivendor support via Option 43 and its suboptions. When using this option, ensure that you modify templates used in earlier releases to be compatible with the template grammar that BAC 4.0 uses.
Migration Performance
A large BAC RDU database can be several gigabytes in size, and may take an extended length of time to migrate. The length of time that database migration takes depends largely on your hardware. Using faster disks improves the time significantly.
Migration automatically compacts your database that may be fragmented. However, this BAC release stores additional data for every device. You can expect the size of the database to increase after migration by as much as 10 percent.
The migration process is optimized for speed and database compactness. As a result, migration requires a large amount of process heap size (memory). For example, migrating a 7-million device database requires approximately 1,024 MB of process heap size. Because the migration process is limited to 4 GB of heap space, migration is effectively limited to a database size of approximately 25-30 million devices.
The -Xmx parameter in the migrateDb.sh script determines the maximum process heap size for migration. The default setting of 3,072 MB for this parameter is sufficient for migrating a 20-million device database. You may need to fine-tune this setting to suit your environment. For example, to migrate smaller databases running on low-end systems with less memory, you can reduce the value of the maximum heap size setting. For databases that exceed the maximum supported scale, you may need to increase this setting.
To change the heap size parameter, in the migrateDb.sh script edit the value for the -Xmx parameter.
Licensing After Migration
The licensing scheme changes significantly in this release. You cannot use the license keys from earlier versions of BAC to provision your network using BAC 4.0. Any existing license keys are automatically deleted during database migration. To configure BAC licensing, you must obtain the license files via a license claim process and install them using the administrator user interface. For details, see the Release Notes for Broadband Access Center 4.0.
During migration, device counters are recalculated based on the number of devices in each provisioning group found in the database. New counters are recorded in the new database and used for licensing.
RDU Extension Migration
During database migration, custom extensions are reset to 4.0 defaults. Custom extensions must be updated to operate in the 4.0 environment. If you require custom extensions after migration, you must add them using the administrator user interface. For details, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
Migration of Duplicate Class of Service and Node Name
This BAC release does not support duplicate names across technologies for Class of Service and nodes. If BAC detects duplicate names during database migration, the duplicate entries are automatically renamed in the following format:
•Class of Service—{Technology_Name}_{Original_ClassOfService_Name}
•Nodes—{Node_Type}_{Node_Name}
For example, if BAC encounters a gold Class of Service for a computer and a DOCSIS modem, either the computer Class of Service is renamed Computer_gold or the DOCSIS modem Class of Service is renamed DOCSISModem_gold. The appropriate warnings are issued to the console and migration log, and all properties containing the specific Class of Service value are automatically updated.
Verifying Database Integrity
We recommend that you perform a dry run of the migration process on a staging (nonproduction) system, instead of on a live system during RDU downtime. These steps may not be practical during live migration, because in the case of a large database, verification can take an extended length of time.
To verify the database:
•Before migration, run the verifyDb.sh tool on a backup snapshot.
Note To verify the database before migration, use the verifyDb.sh tool from the BAC installation corresponding to the version of the database. You cannot verify a nonmigrated database with the BAC 4.0 version of verifyDb.sh.
For example, enter:
# /opt/CSCObpr/rdu/internal/db/bin/verifyDb.sh -dbdir /disk1/backup
This pathname is specific to the BAC installation version before migration.
•After migration, run the verifyDb.sh tool on the migrated database.
For example, enter:
# /opt/CSCObac/rdu/internal/db/bin/verifyDb.sh -dbdir /disk2/target
For details on the verifyDb.sh tool, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
RDU Migration Workflow
Migrating the RDU database consists of two phases:
1. Phase 1—This phase is executed after installation via the migrateDb.sh tool.
2. Phase 2—This phase is executed when the RDU is first started up after the first phase of migration is complete.
Table 5-2 describes the process of migration using examples that assume that:
•BAC is installed in the default home directory (/opt/CSCObac).
•The backup of the previous version of the RDU database is located in the /disk1/backup directory.
|
|
|
|
|---|---|---|
Step 1 |
Select two disk partitions: one for the migrated database, and another as a temporary storage directory for the database transaction logs. Note The partitions that are used in the examples in this procedure are: • The available disk space for the migrated database should be at least 120 percent of the size of the original database (which is the bpr.db file in the backup directory). • The available space on the temporary storage disk must be at least 2 GB. For performance reasons, however, we recommend that you locate this directory on a different disk from the backup database and the target database location. |
Solaris documentation |
Step 2 |
Run the migrateDb.sh tool on the backed-up database. The migrateDb.sh script resides in the BPR_HOME/migration directory. For a description of all arguments that this tools supports, see Using the migrateDb.sh Tool. For example: # /opt/CSCObac/migration/migrateDb.sh -dbdir /disk1/backup
-targetdbdir /disk2/target -targetdblogdir /disk3/target &>
/var/run/migration-console.log &
• • • Note |
Cisco Broadband Access Center Administrator Guide 4.0 |
Step 3 |
Observe the migration progress using the migration.log file. For example: # tail -f /disk2/target/migration.log
|
Solaris documentation |
Step 4 |
Verify if the migration is complete using the migration.log file. If you find any warnings or notices, use the grep command-line tool. For example: # tail /disk2/target/migration.log
... Tue Oct 16 15:36:20 EDT 2007: Phase 1 of RDU database migration to BAC 4.0 completed with 1 warning(s) and 2 notice(s). # cat migration.log | grep "WARNING"
Tue Oct 16 15:57:23 EDT 2007: WARNING: Duplicate Class of Service name [cg814wg_chn_n05] detected for [CableHomeWanMan] technology. Class of Service object was renamed to [CableHomeWanMan_cg814wg_chn_n05]. # cat migration.log | grep "NOTICE" Tue Oct 16 19:06:23 EDT 2007: NOTICE: A deprecated property [/dhcp/client-policy/response/boot-file] was found on object with oid [2882304375712137210]. Property will be declared as custom property. 
Tip |
Solaris documentation |
Step 5 |
Restore the migrated database into the target directories for the 4.0 RDU. This process copies the migrated database to the RDU BPR_DATA and BPR_DBLOG directories. For example: # /opt/CSCObac/rdu/bin/restoreDb.sh /disk2/target
Note |
Cisco Broadband Access Center Administrator Guide 4.0 |
Step 6 |
Start the RDU process from the BAC watchdog process command line, and look for messages on successful initialization in the rdu.log file. For example: # /etc/init.d/bprAgent start rdu
|
Cisco Broadband Access Center Administrator Guide 4.0 |
Step 7 |
Verify if the second phase of migration has started. For example, rdu.log should include similar messages: bac-test.example.com: 2007 10 17 02:36:28 EDT: %BAC-RDU-6-0695: [Starting Phase 2 of RDU db migration]. |
Solaris documentation |
Step 8 |
Observe the progress of the migration. For example, rdu.log should include similar messages: bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Progress report for selection process...]. bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Selection process stats: Read a total of 400000 DOCSISModem device records]. bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Selection process stats: Read a total of 400000 device records]. bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Selection process stats: Ran selection on 398228 eligible devices]. |
Solaris documentation |
Step 9 |
Verify if the second phase of migration is complete. For example, rdu.log should include a similar message: bac-test.example.com: 2007 10 17 03:28:58 EDT: %BAC-RDU-6-0695: [Completed Phase 2 of RDU db migration]. bac-test.example.com: 2007 10 17 03:28:58 EDT: %BAC-RDU-6-0695: [RDU db migration has been finalized]. Also, you can check if the BPR_DATA/rdu/DB_VERSION file indicates the database version as 4.0. |
Cisco Broadband Access Center Administrator Guide 4.0 |
Note |
||
Step 10 |
Verify the RDU operations by logging in to the administrator user interface. From Servers > RDU, you can check the RDU version and device count statistics. |
Cisco Broadband Access Center Administrator Guide 4.0 |
Using the migrateDb.sh Tool
Table 5-3 describes the arguments that you can use with the migrateDb.sh tool.
Migrating Using a RAM Disk
The RAM disk is a Solaris feature that allows you to mount a portion of the RAM as a disk volume. Disk I/O operations on such volumes are considerably faster and can be useful when you have large databases on systems with sufficient memory.
The procedures described in this section are optional and describe how to create and use different RAM disks to migrate your database instead of a regular disk volume, such as a fast RAID array with battery-backed write cache:
•Creating RAM Disk Volumes for Migration
•Using the RAM Disk Volumes for Migration
Creating RAM Disk Volumes for Migration
The following procedure creates three volumes for migration and assumes that the size of the original database is 9 GB. Adjust the volume sizes as required for your database and according to what the available memory permits.
Using the following procedure, you can create three RAM disks that you could use for migration:
•/ram-disk1—To contain the source database
•/ram-disk2—To contain the migrated database directory
•/ram-disk3—To contain the temporary migration transaction logs
Step 1 Ensure that enough memory is allocated to the RAM disk in the /etc/system file. This figure is a percentage of the total RAM on the system. Assuming a 64-GB RAM, this setting dedicates 32 GB to the RAM disk.
For example:
# less /etc/system
...
set ramdisk:rd_percent_physmem=50
Note If you also set the segmap_percent parameter, which determines the quantity of memory allocated to the OS I/O buffer cache, make sure that there is sufficient memory for both settings and some space is left for the OS operation.
Step 2 Reboot the system.
For example:
# shutdown -i6 -g0 -y
Step 3 Create three RAM volumes.
For example:
# ramdiskadm -a volume1 10g
# ramdiskadm -a volume2 12g
# ramdiskadm -a volume3 2g
Step 4 Create new file systems on each volume.
For example:
# newfs /dev/ramdisk/volume1
# newfs /dev/ramdisk/volume2
# newfs /dev/ramdisk/volume3
Step 5 Mount the volumes.
For example:
# rmdir /ram-disk1
# rmdir /ram-disk2
# rmdir /ram-disk3
# mkdir /ram-disk1
# mkdir /ram-disk2
# mkdir /ram-disk3
# mount /dev/ramdisk/volume1 /ram-disk1
# mount /dev/ramdisk/volume2 /ram-disk2
# mount /dev/ramdisk/volume3 /ram-disk3
Step 6 Verify the mount points and their size.
For example:
# df -kh
Using the RAM Disk Volumes for Migration
To use the RAM-disk volumes that you have created for migration:
Step 1 Copy the backup of your database to /ram-disk1.
For example:
# mkdir /ram-disk1/backup
# cp /disk1/backup/* /ram-disk1/backup/.
Step 2 Perform the first phase of migration according to the procedure that Table 5-2 describes. Remember to use a command similar to the one described here instead of the one mentioned in Step 2 of the table.
For example:
# /opt/CSCObac/migration/migrateDb.sh -dbdir /ram-disk1/backup
-targetdbdir /ram-disk2/target -targetdblogdir /ram-disk3/target
&> /var/run/migration-console.log &
Step 3 To ensure that the second phase of migration is executed with the database of the RAM disk:
a. Install the 4.0 RDU such that the database directory and the database logs directory (defined by the BPR_DATA and BPR_DBLOG variables, respectively) point to the volumes on the RAM disk.
b. After the second phase of migration is complete, stop the BAC process watchdog, using the /etc/init.d/bprAgent stop command from the BAC process watchdog command line.
c. Back up the database using:
BPR_HOME/rdu/bin/backupDb.sh -nosubdir /ram-diskX/migrated-db/
–BPR_HOME—Specifies the home directory, which is by default /opt/CSCObac.
–X—Specifies the RAM disk to which the RDU database is migrated.
d. Edit the bpr_definitions.sh file that is found in the home directory (by default /opt/CSCObac) and change the BPR_DATA and BPR_DBLOG locations to new directories located on permanent storage drives.
e. Recover and restore the database to the new RDU locations. Run the recoverDb.sh and the restoreDb.sh scripts, respectively, using:
BPR_HOME/rdu/bin/recoverDb.sh
where BPR_HOME specifies the home directory, which is by default /opt/CSCObac.
BPR_HOME/rdu/bin/restoreDb.sh /ram-diskX/migrated-db/
–BPR_HOME—Specifies the home directory, which is by default /opt/CSCObac.
–X—Specifies the RAM disk to which the RDU database is migrated.
For details on using these scripts, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
f. Start the process watchdog, by running the /etc/init.d/bprAgent start command.
Feedback