- Avid Technology

Transcription

- Avid Technology

Avid MediaCentral Platform Services
®
Version 2.2 Upgrading Guide
Document Version: 1.0.1
This document is a guide to upgrading to MediaCentral Platform Services (MCS) 2.2 from a
previous version of MCS or Interplay Central Services (ICS). It also includes instructions on
migrating the UMS database from a production system to a test system.
Note: For a list products qualified for use with MCS 2.2, and the supported RHEL operating
system, see the Avid MediaCentral Platform V2.2 ReadMe.
Note: The Gluster version changed and additional Gluster packages are required as of MCS 2.0.
See “Obtaining Gluster” in the MediaCentral Platform V2.2 ReadMe.
Important Information
Avid® recommends that you read all the information in this upgrade guide thoroughly
before installing or using the corresponding software release.
Important: Search the Avid Knowledge Base at http://www.avid.com/support for the most
up-to-date ReadMe, which contains the latest information that might have become
available after the documentation was published. The MCS 2.2 documentation can be found
here: http://avid.force.com/pkb/articles/en_US/readme/Avid-MediaCentral-Version-2-2-xDocumentation
Revision History
Date Revised
Version
Changes Made
March 26, 2015
1.0
First publication
April 17, 2015
1.0.1
Fixed incorrect references to MCS 2.1.
About MCS 2.2
Please see the MediaCentral Platform 2.2 ReadMe and any ReadMe documents pertaining
to the solution(s) by which MCS is used.
MediaCentral Services 2.2 Upgrading Guide
Contents
Important Information ....................................................................................................................... 1
Revision History .................................................................................................................................. 1
Contents ..................................................................................................................................................... 2
Overview .................................................................................................................................................... 4
How to Use this Guide ............................................................................................................................... 4
Operating System....................................................................................................................................... 4
Update Installation versus Full Installation................................................................................................ 5
Obtaining the MCS Installation Package .................................................................................................... 5
Obtaining Gluster ....................................................................................................................................... 5
Security Updates ........................................................................................................................................ 5
An Important Note on SSL Certificate Passwords ...................................................................................... 5
Upgrading Media | Index and Multi-Zone Deployments ........................................................................... 6
Resetting Layouts After Upgrading from V2.0 to V2.2 .............................................................................. 7
Resetting Layouts After Upgrading from ICS V1.6 or Earlier ..................................................................... 7
Setting Gluster Volume Ownership Permanently ...................................................................................... 7
Upgrading Paths ......................................................................................................................................... 9
Upgrading from 1.2.x or 1.3.x to MCS 2.2 .............................................................................................. 9
Upgrading to MCS 2.2 for Interplay Central ........................................................................................... 9
Upgrading to MCS 2.2 for Media Composer | Cloud ........................................................................... 10
Upgrading to MCS 2.2 for Interplay | MAM......................................................................................... 10
Special Note: Upgrading from MCS 2.0 ................................................................................................ 10
Upgrading a Single Server RHEL 6.5 System to MCS 2.2 .......................................................................... 11
Installing MCS 2.2 Using the Update Installation ................................................................................. 11
Upgrading a Cluster RHEL 6.5 System to MCS 2.2 ................................................................................... 12
Identifying the Master, Slave and Load-Balancing Nodes .................................................................... 13
Bringing the Cluster Off-line ................................................................................................................. 13
Updating the Cluster ............................................................................................................................ 14
Upgrading a Single Server RHEL 6.3 System to MCS 2.2 .......................................................................... 16
Backing Up System Settings and Installing RHEL 6.5 & MCS 2.2 .......................................................... 17
Restoring System Settings and Migrating User Settings ...................................................................... 18
Verifying and Configuring Date and Time Synchronization Settings.................................................... 19
Logging in and Backing Up the New System Settings........................................................................... 20
Upgrading a Cluster RHEL 6.3 System to MCS 2.2 ................................................................................... 21
2
Identifying the Master, Slave and Load-Balancing Nodes .................................................................... 21
Backing Up Master Node System Settings and Bringing Down the Cluster ......................................... 22
Upgrading the Master Node................................................................................................................. 23
Restoring System Settings and Migrating User Settings on the Master Node..................................... 24
Verifying and Configuring Date and Time Synchronization Settings.................................................... 25
Upgrading the Slave Node and Load-Balancing Nodes ........................................................................ 26
Setting up the Cluster and Cache Replication ...................................................................................... 27
Validating the Cluster and Backing Up the New System Settings ........................................................ 27
Reconfiguring ICS for Interplay | MAM or Media Composer | Cloud in an Upgrade from ICS 1.7 or Earlier
................................................................................................................................................................. 28
Reconfiguring MCS for Use with Interplay | MAM .............................................................................. 28
Reconfiguring MCS for Use with Media Composer | Cloud ................................................................. 29
Backing Up and Restoring SSL Private Keys ............................................................................................. 29
Appendix A: Frequently Asked Questions................................................................................................ 31
Appendix B: Migrating the UMS Database to a Test Node ...................................................................... 32
Migrating the 1.6.x (or later) UMS Database ....................................................................................... 32
Migrating the 1.4.x/1.5.x UMS Database ............................................................................................. 33
Appendix C: Mounting and Unmounting the USB Key ............................................................................ 34
Appendix D: Deleting the RAID 5 ............................................................................................................. 35
Appendix E: Backing Up and Restoring System Settings and the ICS/MCS Database ............................. 38
Appendix F: Glossary ................................................................................................................................ 43
MediaCentral ........................................................................................................................................ 43
Media Composer | Cloud ..................................................................................................................... 43
Interplay | MAM................................................................................................................................... 43
MediaCentral Platform Services (MCS) ................................................................................................ 43
Interplay Central Playback Service (ICPS) ............................................................................................. 43
MCS System Settings ............................................................................................................................ 44
MCS Platform Settings.......................................................................................................................... 44
MCS Database ...................................................................................................................................... 44
MediaCentral User Management Database......................................................................................... 44
Corosync ............................................................................................................................................... 44
Distributed Replicated Block Device (DRBD) ........................................................................................ 44
Copyright and Disclaimer ......................................................................................................................... 45
3
Overview
Upgrading to MediaCentral Platform Services (MCS) 2.2 for MediaCentral, Media
Composer | Cloud, and Interplay | MAM, involves the migration of settings and data along
with the software upgrade. Depending on the upgrade path you are faced with, the
migration of settings and data is manual or automated. When upgrading from the earliest
versions of Interplay Common Services (ICS) the upgrade involves significant changes to the
hardware topology of the system.
Note: Beginning with version 2.0, the term “MediaCentral Platform Services” replaces
“Interplay Central Services.” In addition, the term “MediaCentral Playback Service” replaces
“Interplay Central Playback Service.”
There are two main upgrade paths to MCS 2.2, depending on the currently installed
operating system:
·
RHEL 6.5 – If this is the currently installed OS, the upgrade is non-destructive and
largely automated. Manually backing up system settings and MCS Database is not
required, but recommended.
·
RHEL 6.3 and earlier – The upgrade involves a clean installation of RHEL 6.5 and
MCS. Manually backing up system settings and MCS database before the upgrade
and restoring them after is mandatory.
When the upgrade path involves a RHEL version change, you must also manually
back up any private keys associated with SSL certificates received from a Certificate
Authority, if CA-signed certificates are in use. In the case of a cluster, you must
manually re-create the cluster and reconfigure cache replication (if used).
How to Use this Guide
This guide documents the overall upgrade process for the supported upgrade scenarios. It
must be used in conjunction with the MCS 2.2 Installation and Configuration Guide. For
clustering, you might find it helpful to refer to the most recent edition of the MCS Clustering
Guide too – for validation of the cluster post-installation, for example.
For each step in the overall upgrade process, this document offers the following guidance:
·
Includes the step-by-step instructions for the step
- or -
·
Cross-references a section in the MCS 2.2 Installation and Configuration Guide
In the second case, the heading of the relevant section in the MCS 2.2 Installation and
Configuration Guide is provided. Since direct page references are unreliable, you must scan
the table of contents in that guide to find the heading and page.
Operating System
MCS 2.2 requires RHEL 6.5. In addition, whether performing an upgrade or a full installation,
the MCS installer requires the RHEL 6.5 ISO to be mounted, so you must obtain the RHEL 6.5
4
ISO. This is true, even when performing an upgrade where the operating system does not
change.
Note: Red Hat has issued a security advisory for RHEL 6.5. See “Security Updates” on page 5.
For convenience, the following table lists the ICS/MCS releases and corresponding RHEL
versions.
ICS/MCS Version
RHEL Version
ICS 1.2.3 – 1.5
RHEL 6.2
ICS 1.6 – 1.8
RHEL 6.3
ICS 1.8.1 – MCS 2.2 RHEL 6.5
Update Installation versus Full Installation
The MCS 2.2 release can be installed as a full installation that performs a clean installation of
RHEL, overwriting the system disk. In this case, you prepare a USB key, insert and reboot
from it. For an existing MCS installation with a supported RHEL version, it can be installed as
an upgrade. In this case, you prepare the USB key and trigger the installation script
manually. You do not reboot from it. The installation package and USB key preparation is the
same in both cases.
Obtaining the MCS Installation Package
The MCS 2.2 release is available directly on the Avid Download Center.
Obtaining Gluster
If are installing Gluster, note that since MCS 2.0 a new version of Gluster is required, and
additional Gluster packages.
For package names and download instructions, please consult the MediaCentral Platform
2.2 ReadMe.
Security Updates
Important: Red Hat has issued security advisories for RHEL 6.5. Once you have installed the
operating system, please take a moment to resolve the security vulnerabilities. For
instructions, see the “Security Updates” section in the MediaCentral Platform 2.2 ReadMe.
An Important Note on SSL Certificate Passwords
Interplay Central uses the Secure Sockets Layer (SSL) for its server to browser connections.
Default passwords are used by the system to automatically generate and use self-signed
5
certificates. Customized certificates can also be used, including those that have been issued
by a Certificate Authority (CA).
When customized or CA-signed certificates are used, the MCS 2.2 Installation and
Configuration Guide explains that the SSL passwords must be written to the user-available
Application Properties file in the following directory:
/opt/avid/etc/avid/avid-interplay-central/config/application.properties
This should not be confused with the system-reserved Application Properties file, in the
following location:
/opt/avid/avid-interplay-central/config/application.properties
Caution: The user-available Application Properties file is backed up and restored by the systembackup script. The system-reserved Application Properties file is not backed up. If the SSL
passwords are in the wrong file, SSL configuration will be broken by the upgrade.
To avoid mishaps, double-check the contents of the system-reserved Application Properties
file before proceeding with the upgrade.
To double-check the system-reserved Application Properties file:
1. List the contents of the Application Properties file reserved for use by the system:
less /opt/avid/avid-interplaycentral/config/application.properties
2. Look for the following two lines (they might not be next to each other):
system.org.ops4j.pax.web.ssl.password=OBF\:1lfc1n7n1l1618qm18qo1kxw1n3v1lc6
system.org.ops4j.pax.web.ssl.keypassword=OBF\:1lfc1n7n1l1618qm18qo1kxw1n3v1l
c6
The obfuscated passwords shown above (in bold) are the default system passwords.
3. If the passwords you see match the above, this is correct, and nothing more needs to be
done.
4. If the passwords you see are different, it indicates the file has been edited. This is
incorrect, and you must copy the two modified lines into the following file (you might
need to create the file):
/opt/avid/etc/avid/avid-interplay-central/config/application.properties
Copying the modified lines to the user-available Application Properties file ensures they
are preserved during the upgrade.
Upgrading Media | Index and Multi-Zone Deployments
If your deployment is configured for Media | Index and multi-zone, note the following:
6
·
Upgrade Slave Zones First: If you cannot bring all zones off-line at once, upgrade
the slave zone(s) before the master zone.
Note that an upgraded slave zone system no longer has access to the centralized
user management service (UMS), which is owned by the master zone. Users in the
upgraded slave zone can continue to log in —the local, read-only copy of the UMS
database is used — but you cannot create new users.
·
Delete the Media| Index System Data Index: The system data index contains
information on registered systems and localization strings for display fields. In
initialized systems it also contains production data. If Media Index is configured, you
must delete the system data index in the master zone before the upgrade. Note that
deleting the system data index restores a clean index state. For instructions, see the
Avid Media | Index Configuration Guide.
Resetting Layouts After Upgrading from V2.0 to V2.2
Three panes used in MediaCentral UX v2.0 were dropped as of MediaCentral UX v2.1:
·
Markers pane: redesigned as Logging pane.
·
Layouts pane in Users Layout: replaced by drag-and-drop functionality.
·
Search pane in Users Layout: replaced by Filter field.
After Media Central UX is upgraded to v2.2, users who had signed out of V2.0 with these
panes open will see them when they sign in again, with the message: “No View
implementation found for type undefined” in the pane. Users need to reset the panes.
To reset the outdated panes, do one of the following:
·
Close the outdated panes.
·
Reset the layout by selecting Reset Layout from the Layout selector.
Resetting Layouts After Upgrading from ICS V1.6 or Earlier
After upgrading from Interplay Central Services V1.6 or earlier, users who had previously
signed in will see the Assets pane and Search panes from their most recent session.
However, the Assets tabs and Search panes are not usable.
This problem does not occur when upgrading from ICS V1.7 to MediaCentral Platform V2.2.
To reset the Assets pane and Search panes, do one of the following:
·
Close all open Assets tabs and Search panes and reopen them.
·
Reset the layout by selecting Reset Layout from the Layout selector.
Setting Gluster Volume Ownership Permanently
Recall that the following two directories must be owned by user maxmin and have group id
set to maxmin:
cache/gluster/gluster_data_download
7
cache/gluster/gluster_data_fl_cache
The directories above are associated with RHEL directories (/cache/fl_cache and
/cache/download) used to store files for http-based streaming, such as media converted to
FLV for file-based playback. They are also used to store media converted to Mpeg2TS for
playback on iOS devices. The download directory contains links to simplify iOS playback.
With Gluster 3.4.0.8, restarting the Gluster daemon (glusterd) results in user ID and group
ownership of the Gluster volumes being changed from maxmim to root, which breaks
playback on iOS devices. Thus if a cluster node is rebooted, playback issues can arise.
To prevent issues for an existing cluster, you must configure the two Gluster cache volumes
to use the same UID and GID as the maxmin user, as described in the following procedure.
Note: This procedure should be done after the upgrade. It is only necessary for cluster
deployments using Gluster.
To set Gluster volume ownership so it does not change:
On each node in the cluster perform the following steps (slave first, master second, load
balancing at any time):
1. Stop Pacemaker:
service pacemaker stop
2. Stop Corosync:
service corosync stop
3. Obtain the user ID of the user maxmin (this might be different on each machine):
id -u maxmin
4. Change the user ownership of the gluster volume to maxmin using the user ID:
gluster volume set gl-cache-dl storage.owner-uid <uid>
gluster volume set gl-cache-fl storage.owner-uid <uid>
In the above commands, do not type the angle brackets. Enter the number obtained in
the previous step.
Note: Do not alter the gl-cache-mcam (multicam) volume. It uses the default root ownership.
5. Obtain the group ID of the user maxmin (this might be different on each machine):
id -g maxmin
6. Change the group ownership of the gluster volume to maxmin using the group ID:
gluster volume set gl-cache-dl storage.owner-gid <gid>
gluster volume set gl-cache-fl storage.owner-gid <gid>
Note: Do not alter the gl-cache-mcam (multicam) volume. It uses the default root ownership.
8
7. Verify the success of the ownership changes:
ls –la /cache/gluster
Should return:
drwxrwsrwx 3 maxmin maxmin 4096 Jan 12 09:51 gluster_data_download
drwxrwsrwx 5 maxmin maxmin 4096 Jan 12 09:51 gluster_data_fl_cache
drwxr-xr-x 3 root
root
4096 Feb 5 08:33 gluster_data_multicam
8. Restart the GlusterFS service:
service glusterd restart
9. Verify the ownership changes are sticky:
ls –la /cache/gluster
Should return same as before:
drwxrwsrwx 3 maxmin maxmin 4096 Jan 12 09:51 gluster_data_download
drwxrwsrwx 5 maxmin maxmin 4096 Jan 12 09:51 gluster_data_fl_cache
drwxr-xr-x 3 root
root
4096 Feb 5 08:33 gluster_data_multicam
10. Change ownership of any files residing in gluster_data_download and
gluster_data_fl_cache:
chown –R maxmin:maxmin /cache/gluster/gluster_data_download
chown –R maxmin:maxmin /cache/gluster/gluster_data_fl_cache
This is only absolutely necessary on systems that have already been running, where the
Gluster daemon reset ownership to root.
11. Start Corosync:
service corosync start
12. Start Pacemaker:
service pacemaker start
Upgrading Paths
This section presents the upgrade paths for specific deployment options.
Upgrading from 1.2.x or 1.3.x to MCS 2.2
For Interplay Central and/or ICPS 1.2.x and 1.3.x upgrade options, please consult your Avid
representative.
Upgrading to MCS 2.2 for Interplay Central
Since ICS 1.3 — which introduced the hardware consolidation and software service
colocation on Linux servers — in many respects MediaCentral Platform Services and
9
MediaCentral are the same thing. MediaCentral uses all MediaCentral Platform Services,
and its version number increases in lock step with MediaCentral Platform Services.
For upgrading instructions:
·
“Upgrading a Single Server RHEL 6.5 System to MCS 2.2” on page 10.
·
“Upgrading a Cluster RHEL 6.5 System to MCS 2.2” on page 12.
·
“Upgrading a Single Server RHEL 6.3 System to MCS 2.2”on page 16.
·
Upgrading to MCS 2.2 for Media Composer | Cloud
The latest version of the Media Composer | Cloud plugin requires at least ICS 1.3. Upgrading
to MCS 2.2 for Media Composer | Cloud does not add any new functionality, but you do get
the benefit of the latest bug fixes.
·
·
·
·
Upgrading to MCS 2.2 for Interplay | MAM
For Interplay MAM compatibility with MCS please refer to the MediaCentral Platform 2.2
ReadMe.
·
·
·
·
Special Note: Upgrading from MCS 2.0
If you are upgrading from MCS 2.0, note the following. As part of some cluster deployments,
the MediaCentral Platform Services 2.0 Installation and Configuration Guide provided
instructions for replicating the cluster file caches using Gluster, an open source software
solution. The instructions include creating a metadata cache directory for Interplay | MAM
deployments with MPEG-1 browse proxies.
The use of Gluster to replicate metadata has been deprecated due to its negative impact on
performance. Please delete the GlusterFS metadata volume from all your server nodes in all
affected deployments. Once complete, metadata information is loaded into RAM and is no
longer replicated across other nodes.
10
For instructions, consult the Avid KB article “Removing the GlusterFS Metadata Cache
Replication Volume” at the following link:
http://avid.force.com/pkb/articles/en_US/how_to/Removing-the-gluster-metadata-cachereplication-volume
Upgrading a Single Server RHEL 6.5 System to MCS 2.2
For systems already running RHEL 6.5, the upgrade to MCS 2. 1 is an update installation
involving the following procedure:
¨ Installing MCS 2.2 Using the Update Installation
Expected downtime: 30 min.
Installing MCS 2.2 Using the Update Installation
To install MCS 2.2 using the update installation:
1. Prepare and insert the MCS 2.2 installation USB key.
In the MCS 2.2 Installation and Configuration Guide, see “Preparing the MCS Installation
USB Key”.
Note: If the RHEL image cannot be put not on the USB key — that is, if it is not local to the
installation package — mount the RHEL as a loop device image to/sysinstall before
proceeding:
mount -o loop <Path_to_Image>/<RHEL_Image>.iso /sysinstall/
2. Mount the USB key and change to the USB mount point.
In this document, see “Appendix C: Mounting and Unmounting the USB Key” on page
34.
3. Log in as root and dump the current database:
avid-db dumpall
Although the upgrade is non-destructive, it is a good idea to backup the MCS database.
4. Unzip the installation package.
unzip MediaCentral_Services_2.2_Build_XX_Linux.zip
5. Start the installation script.
./install.sh
Note: Be sure to use the dot-slash (“./”) notation, which tells Linux to look for the installation
script in the current directory. Otherwise you will receive the following error message:
-bash: install.sh: command not found
11
For security, Linux does not include the “current” directory (“.”) in its PATH variable. You
must specify the path, even when you are in the directory where the script or command is
located.
During the installation process, progress is displayed (details have been omitted, for
clarity):
Cleaning repos:
Cleaning up Everything
Those familiar with the Linux yum update process will recognize the pattern of the
update.
The update completes with an indication of success:
INSTALLATION FINISHED
6. Check the installation was successful using the ics_version script:
ics_version
Service version numbers are returned as follows:
UMS
Version: 2.2.x.x
ICPS
Version: 2.2.x.x
ICPS manager Version: 2.2.x.x
ACS
Version: 2.2.x.x
System ID: "xxxxxxxxxxx"
ICS installer: 2.2 (Build xx)
Created on <installer creation date>
Note: The System ID is an 11-digit number used in support calls. You enter it via the
MediaCentral UX user interface. See the MCS 2.2 Installation and Configuration Guide.
Note: For precise version numbers for this release, see the MediaCentral Platform 2.2
ReadMe.
7. Unmount the USB key.
34.
Upgrading a Cluster RHEL 6.5 System to MCS 2.2
Installing MCS 2.2 on a cluster already running MCS compatible with RHEL 6.5 is a simple
automated update of the affected packages. All MCS system settings are preserved. There is
no need to manually backup and/or restore any MCS system settings. All nodes must be
brought off-line to perform the update.
The cluster update involves the following steps:
¨ Identifying the Master, Slave and Load-Balancing Nodes
¨ Bringing the Cluster Off-line
12
¨ Updating the Cluster
Expected downtime: 1 hr. for 2 servers, + 30 min. for each additional server.
Identifying the Master, Slave and Load-Balancing Nodes
To identify the master, slave, and load-balancing nodes:
Recall that there are three types of nodes in a cluster: master, slave, and load-balancing.
The master “owns” the cluster IP address. The slave assumes the role of master in the event
of a failover. Any extra nodes play a load-balancing role, but can never take on the role of
master.
1. Identify the master node of the cluster. Log into any machine in the cluster as root and
type:
crm_mon
2. In the output of that command, look for the line containing “AvidClusterIP”—this service
runs on the master server.
For example, if the crm_mon command output contains the line:
AvidClusterIP (ocf::heartbeat:IPaddr2):
Started ics-1
…the master server is ics-1.
3. To identify the slave, look for the line containing “Master/Slave Set”.
For example, if the crm_mon command output contains the lines:
Master/Slave Set: ms_drbd_postgres [drbd_postgres]
Masters: [ ics-1 ]
Slaves: [ ics-2 ]
…the slave server is ics-2.
4. To identify the load-balancing nodes, look for the line containing “Clone Set”.
Clone Set: AvidAllEverywhere [AvidAll]
Started: [ ics-1 ics-2 ics-3]
…the extra server in this case is ics-3.
Bringing the Cluster Off-line
To bring the cluster off-line:
Note: The master node should not be in standby when you back up the database.
1. Log in to the master node as root and dump the current database:
avid-db dumpall
13
Although the update is non-destructive, it is a good idea to backup the MCS database.
2. Begin bringing the cluster off-line by putting the load-balancing nodes into standby
mode:
crm node standby <node name>
3. Next, put the slave node into standby mode:
4. Finally, put the master node into standby mode:
Updating the Cluster
You can upgrade the nodes in any order you like. However, be sure to bring them back
online in the correct order, as indicated in the instructions.
To update the cluster:
USB Key”.
Note: If the RHEL image is not on the USB key — that is, if it is not local to the installation
package — mount the RHEL image as a loop device to/sysinstall before proceeding:
mount -o loop <Path_to_Image>/<RHEL_Image>.iso /sysinstall/
2. Mount the USB key and change to the mount point.
34.
3. Unzip the installation package.
unzip MediaCentral_Services_2.2_Build_XX_Linux.zip
4. Start the installation script.
./install.sh
Note: Be sure to use the dot-slash (“./”) notation, which tells Linux to look for the installation
script in the current directory. Otherwise you will receive the following error message:
-bash: install.sh: command not found
For security, Linux does not include the “current” directory (“.”) in its PATH variable. You
must specify the path, even when you are in the directory where the script or command is
located.
During the installation process, progress is displayed (details have been omitted, for
clarity):
Cleaning repos:
14
Cleaning up Everything
Those familiar with the Linux yum update process will recognize the pattern of the
update.
The update completes with an indication of success:
INSTALLATION FINISHED
ics_version
UMS
Version: 2.2.x.x
ICPS
Version: 2.2.x.x
ACS
Version: 2.2.x.x
ReadMe.
6. Unmount the USB key, proceed to the next node, and follow the same pattern:
a. Mount the USB key (and the RHEL image, if it is not on the USB key)
b. Run the update script
c. Unmount the USB key
7. When all the nodes have been updated, you must restart the RabbitMQ server on each
node.
service rabbitmq-server restart
The system should respond with the following output:
Stopping rabbitmq-server:
Starting rabbitmq-server:
[FAILED]
[ OK ]
8. Once you have restarted the RabbitMQ server on each updated node in the cluster,
reactivate the cluster by running the following command on the master node:
sh /opt/avid/cluster/bin/reactivate-cluster
Note: If after running the reactivate-cluster script you observe that a node is the state of
“Offline - Unclean Node”, restart Pacemaker on that node.
9. If the reactivate-cluster command does not bring all nodes back online, you can do it
manually. For example, to bring the master node back online:
15
crm node online <node name>
Bringing the master node back online starts the Avid Interplay Central service (which
was stopped when you put the node into standby).
Similarly, you can bring the slave node back online:
If applicable, bring the load-balancing nodes back online:
10. Verify the cluster status and cluster failover status
crm_mon -f
·
Verify the master, slave, and load-balancing nodes have rejoined the cluster, as
expected.
·
Verify the fail counts for the following resources (at a minimum): AvidIPC, AvidUMS,
AvidACS, pgsqlDB.
·
Verify the cluster status.
11. If there are fail counts listed, run the cluster resource manager cleanup command to
reset them:
crm resource cleanup <rsc> [<node>]
<rsc> is the resource name of interest: AvidIPC, AvidUMS, AvidACS, pgsqlDB (or another)
<node> (optional) is the node of interest.
Note: If you receive an “object/attribute does not exist” error message, it indicates the
resource is active on more than one node. Repeat the command using the group name for
the resource (the “everywhere” form). For example, for the AvidAll resource, use
AvidAllEverywhere. For AvidConnectivityMon, use AvidConnectivityMonEverywhere.
Note: You can address the services contained in the postgres resource group (postgres_fs,
AvidClusterIP and pgsqlDB) individually, or as a group.
For example, to reset the fail count for AvidALL resource, issue the following command:
crm resource cleanup AvidAllEverywhere
Upgrading a Single Server RHEL 6.3 System to MCS 2.2
The upgrade to MCS 2.2 is a fresh OS and MCS software installation involving the following
procedures:
¨ Backing Up System Settings and Installing RHEL 6.5 & MCS 2.2
¨ Restoring System Settings and Migrating User Settings
¨ Verifying and Configuring Date and Time Synchronization Settings
¨ Logging in and Backing Up the New System Settings
16
Note: Before proceeding, back up any private key used to generate a Certificate Signing
Request. In this document, see “Backing Up and Restoring SSL Private Keys” on page 29.
Expected downtime: 30 min.
Backing Up System Settings and Installing RHEL 6.5 & MCS
2.2
To back up system settings and install MCS 2.2:
USB Key”.
34.
3. Back up the current system settings and ICS/MCS database using the backup script.
In this document, see “Appendix E: Backing Up and Restoring System Settings and the
ICS/MCS Database” on page 38.
4. Unmount and remove the USB key.
34.
5. Boot into the HP BIOS, enter the “Option ROM Configuration for Arrays” utility and
destroy the RAID 5.
In this document, see “Appendix D: Deleting the RAID 5” on page 35.
6. While still in the utility, re-create the RAID 5.
In the MCS 2.2 Installation and Configuration Guide, see “Setting Up the RAID Level 5
Cache Drives”.
Destroying and re-creating the RAID 5 eliminates (in advance) problems with cache
permissions that can arise as a result of the RHEL update.
7. Insert the USB key and boot from it to install RHEL and MCS.
8. Once installed, remove the USB key and reboot as prompted.
Rebooting after the OS upgrade causes the RHEL Text Mode Setup Utility (“Choose a
Tool”) screen to appear, providing access to set-up menus.
9. Quit the RHEL Text Mode Setup Utility and log in to RHEL.
ics_version
UMS
Version: 2.2.x.x
ICPS
Version: 2.2.x.x
17
ACS
Version: 2.2.x.x
ReadMe.
11. Install the RHEL security update.
In this document, see “Security Updates” on page 5.
Restoring System Settings and Migrating User Settings
To restore system settings and migrate user settings:
1. Re-insert and re-mount the USB key.
34.
2. Restore the system settings and MCS database using the restore script.
Note: It is possible that error messages similar to the following will be output to the shell:
/usr/maxt/maxedit/cluster/resources/_common.sh errors
Ignore the messages and type the following and press Enter to complete the command:
service avid-all stop
You do not need to stop the error messages to type the above command. You can type it
even as the error messages are output to the terminal.
34.
4. Open the restored filesystem table (/root/fstab) to examine it for reference purposes.
·
The restored filesystem table (/root/fstab).
·
The current filesystem table (/etc/fstab).
Note: The filesystem table cannot be automatically restored to the original location, since
some entries are assigned UUIDs dynamically by Linux. These can change from one RHEL
18
installation to the next, even if they underlying hardware remains the same. Nevertheless, it
is convenient to examine the restored filesystem table, for reference.
For example, in an MCS system with a RAID 5 cache volume, the restored filesystem
table contains an entry similar to the following:
/dev/mapper/vg_ics_cache-lv_ics_cache /cache ext4 rw 0 0
Note: For Interplay | MAM system the filesystem table contains an entry to
automatically mount the Interplay | MAM filesystem.
5. Reboot and note the restored host name at the login prompt (e.g. ics-dl360-1).
6. Log in as root and migrate the user settings from the UMS database to the USS database
(new in 2.0):
/opt/avid/bin/avid-uss-import –p Avid123
The above command needs to be invoked once only. In the case of a cluster, it is
invoked on the master node only.
The system returns the following:
Loading properties..
Fetching zone UUID..
Importing settings for zone UUID: 00000000-0000-0000-0000000000000000
Importing setting_domain_class..
Importing setting_class..
Importing setting_instance..
SUCCESS
Verifying and Configuring Date and Time Synchronization
Settings
To verify and configure the date and time synchronization settings:
1. Log in and check the date and time are correct, and adjust if needed:
date
In the MCS 2.2 Installation and Configuration Guide, see “Verifying the Date and Time”.
2. Though time zone information was restored, you must re-create the symbolic link RHEL
needs to make use of it:
ln –sf /usr/share/zoneinfo/<yourzone> /etc/localtime
If you need to verify the zone in use prior to re-creating the symbolic link:
cat /etc/sysconfig/clock
For more information, in the MCS 2.2 Installation and Configuration Guide, see “Setting
the Time Zone”.
3. Verify the availability of the in-house NTP server, synchronize the System Clock, and set
up a cron job to keep the clock synchronized.
19
In the MCS 2.2 Installation and Configuration Guide, see “Synching the System Clock”.
Logging in and Backing Up the New System Settings
To perform final configurations and back up the new system settings and MCS database:
1. Log in to Media Central UX, accept the license agreement, and verify user migration and
role assignments.
2. If you are deploying ICS for Interplay | MAM or Media Composer | Cloud, you must
update Interplay Central configuration settings.
In this document, see “Reconfiguring ICS for Interplay | MAM or Media Composer |
Cloud in an Upgrade from ICS 1.7 or Earlier” on page 28.
3. Finally, back up the system settings and MCS database.
20
Upgrading a Cluster RHEL 6.3 System to MCS 2.2
The cluster upgrade to MCS 2.2 is a fresh OS and MCS software installation involving the
following procedures:
¨ Identifying the Master, Slave and Load-Balancing Nodes
¨ Backing Up Master Node System Settings and Bringing Down the Cluster
¨ Upgrading the Master Node
¨ Restoring System Settings and Migrating User Settings on the Master Node
¨ Verifying and Configuring Date and Time Synchronization Settings
¨ Upgrading the Slave Node and Load-Balancing Nodes
¨ Setting up the Cluster and Cache Replication
¨ Validating the Cluster and Backing Up the New System Settings
Note: Before proceeding, back up any private key used to generate a Certificate Signing
Request. In this document, see “Backing Up and Restoring SSL Private Keys” on page 29.
Expected downtime: 1 hr. for 2 servers, + 30 min. for each additional server.
Identifying the Master, Slave and Load-Balancing Nodes
To identify the master, slave, and load-balancing nodes:
Recall that there are three types of nodes in a cluster: master, slave, and load-balancing.
The master “owns” the cluster IP address. The slave assumes the role of master in the event
of a failover. Any extra nodes play a load-balancing role, but can never take on the role of
master.
1. Identify the master node of the cluster. Log into any machine in the cluster as root and
type:
crm_mon
2. In the output of that command, look for the line containing “AvidClusterIP”—this service
runs on the master server.
For example, if the crm_mon command output contains the line:
AvidClusterIP (ocf::heartbeat:IPaddr2):
Started ics-1
…the master server is ics-1.
3. To identify the slave, look for the line containing “Master/Slave Set”.
Master/Slave Set: ms_drbd_postgres [drbd_postgres]
Masters: [ ics-1 ]
Slaves: [ ics-2 ]
…the slave server is ics-2.
21
4. To identify the load-balancing nodes, look for the line containing “Clone Set”.
Clone Set: AvidAllEverywhere [AvidAll]
Started: [ ics-1 ics-2 ics-3]
…the extra server in this case is ics-3.
Backing Up Master Node System Settings and Bringing Down
the Cluster
To back up the master node and bring down the cluster:
Note: The master node should not be in standby when you back up the system settings and
database using the system-backup script. If it is in standby, only the system settings will be
backed up – not the database. Other nodes can be in standby. On the slave node the
database is present, but not mounted. Load balancing nodes do not have a database.
1. Prepare and insert the MCS 2.2 installation USB key into the master node.
USB Key”.
34.
3. Back up the current system settings and ICS/MCS database using the backup script.
Be sure to create a copy of the master node backup directory using the Linux cp
command. For example:
cp -r sys-backup sys-backup-<nodename>
Note: It is important to copy the master node backup directory and rename it. Only the
master node backup contains a complete set of backup information (i.e. both system settings
and database). If you do create a copy of the master node backup file, it will be overwritten
by the backup from a non-master node and you will lose the user database, amongst other
information.
4. Begin bringing the cluster off-line by putting the load-balancing nodes into standby
mode:
5. Next, put the slave node into standby mode:
6. Finally, put the master node into standby mode:
22
7. Unmount the USB key.
34.
Upgrading the Master Node
To upgrade the master node:
1. Unmount the USB key (if you have not already done so).
34.
2. Boot into the HP BIOS, enter the “Option ROM Configuration for Arrays” utility and
destroy the RAID 5.
In this document, see “Appendix D: Deleting the RAID 5” on page 35.
3. While still in the utility, re-create the RAID 5.
Cache Drives”.
Destroying and re-creating the RAID 5 eliminates (in advance) problems with cache
permissions that can arise as a result of the RHEL update.
4. Insert the USB key and boot from it to install RHEL and MCS.
5. Once installed, remove the USB key and reboot as prompted.
Rebooting after the OS upgrade causes the RHEL Text Mode Setup Utility (“Choose a
Tool”) screen to appear, providing access to set-up menus.
6. Quit the RHEL Text Mode Setup Utility and log in to RHEL.
ics_version
UMS
Version: 2.2.x.x
ICPS
Version: 2.2.x.x
ACS
Version: 2.2.x.x
ReadMe.
23
8. Install the RHEL security update.
In this document, see “Security Updates” on page 5.
Restoring System Settings and Migrating User Settings on the
Master Node
To restore system settings and migrate user settings on the master node:
1. Insert and Mount the USB key.
34.
Note: It is possible that error messages similar to the following will be output to the shell:
/usr/maxt/maxedit/cluster/resources/_common.sh errors
Ignore the messages and type the following and press Enter to complete the command:
service avid-all stop
You do not need to stop the error messages to type the above command. You can type it
even as the error messages are output to the terminal.
34.
4. Open the restored filesystem table (/etc/fstab) to examine it for reference purposes.
·
·
For example, in an MCS system with a RAID 5 cache volume, the restored filesystem table
contains an entry similar to the following:
Note: For Interplay | MAM system the filesystem table contains an entry to automatically
mount the Interplay | MAM filesystem.
5. Verify if DRBD is set to run at system startup:
24
chkconfig –-list drbd
There are two dashes (“--“) with no space between them , in the above command.
6. If set to run, disable DRBD (since it will interfere with setting up the cluster):
chkconfig drbd off
8. Log in as root and migrate the user settings from the UMS database to the USS database
(new in 2.0):
/opt/avid/bin/avid-uss-import –p Avid123
The above command needs to be invoked on the master node only.
The system returns the following:
Loading properties..
Fetching zone UUID..
Importing settings for zone UUID: 00000000-0000-0000-0000000000000000
Importing setting_domain_class..
Importing setting_class..
Importing setting_instance..
SUCCESS
Verifying and Configuring Date and Time Synchronization
Settings
To verify and configure the date and time synchronization settings:
1. Log in (if you have not already done so) and check the date and time are correct, and
adjust if needed:
date
In the MCS 2.2 Installation and Configuration Guide, see “Verifying the Date and Time”.
2. Though time zone information was restored, you must re-create the symbolic link RHEL
needs to make use of it:
ln –sf /usr/share/zoneinfo/<yourzone> /etc/localtime
If you need to verify the zone in use prior to re-creating the symbolic link:
cat /etc/sysconfig/clock
For more information, in the MCS 2.2 Installation and Configuration Guide, see “Setting
the Time Zone”.
3. Verify the availability of the in-house NTP server, synchronize the System Clock, and set
up a cron job to keep the clock synchronized.
In the MCS 2.2 Installation and Configuration Guide, see “Synching the System Clock”.
25
Upgrading the Slave Node and Load-Balancing Nodes
To upgrade the slave node (and load-balancing nodes):
1. Insert and mount the MCS 2.2 installation USB key.
34.
2. Back up the system settings using the backup script.
38.
Be sure to make a copy of the backup file using the Linux cp command. For example:
cp -r sys-backup sys-backup-<nodename>
3. Upgrade the node.
In this document, see “Upgrading the Master Node” on page 23.
Be sure to delete, then re-create the RAID 5.
Be sure to install the RHEL security update.
Be sure to examine the contents of the restored filesystem table (/root/fstab) and copy
any needed entries into the current filesystem table (/etc/fstab) as indicated in the
instructions.
Be sure to unmount and remove the USB key when complete.
5. Verify if DRBD is set to run at system startup:
chkconfig –-list drbd
There are two dashes (“--“) with no space between them , in the above command.
6. If set to run, disable DRBD:
chkconfig drbd off
8. Verify the time, date and time synchronization settings.
In this document, see “To verify and configure the date and time synchronization
settings” on page 25.
9. Repeat the process for any load-balancing nodes.
26
Setting up the Cluster and Cache Replication
To set up the cluster and cache replication:
1. On the master and slave node, establish database replication between the master node
and slave node using the drbd_setup script.
In the MCS 2.2 Installation and Configuration Guide, see “Setting Up DRBD”.
2. On the master node, configure the cluster and start the cluster services using the setupcorosync and setup-cluster scripts.
In the MCS 2.2 Installation and Configuration Guide, see “Starting the Cluster Services”.
Don’t forget to restart the following services (as indicated in the instructions):
service acs-messenger restart
service avid-aaf-gen restart
service avid-mpd restart
Note: Restarting the Interplay Pulse (avid-mpd) service is only needed if Interplay Pulse
(separate installer) is installed on the system.
3. Join each non-master — the slave and load-balancing nodes — to the cluster using the
setup-corosync script.
In the MCS 2.2 Installation and Configuration Guide, see “Joining the Cluster”.
Once again, restart the acs-messenger, avid-aff-gen and avid-mpd services.
4. If you are deploying a RAID 5, set up cache replication using Gluster.
In the MCS 2.2 Installation and Configuration Guide, see “Replicating the Cluster File
Caches using Gluster”.
Validating the Cluster and Backing Up the New System
Settings
To log in and validate the cluster:
1. Log in to Media Central UX, accept the license agreement, and verify user migration and
role assignments.
2. If you are deploying ICS for Interplay | MAM or Media Composer | Cloud, you must
update Interplay Central configuration settings.
In this document, see “Reconfiguring ICS for Interplay | MAM or Media Composer |
Cloud in an Upgrade from ICS 1.7 or Earlier” on page 28.
3. Validate the cluster.
In the MCS 2.2 Installation and Configuration Guide, see “Part V: Post Installation”.
In particular:
27
·
Verify ACS bus functionality (acs_query)
·
Verify cache directory permissions (ls -la /cache)
·
Secure the system (change root and Administrator passwords)
·
Monitor cluster status (crm_mon)
·
Test the cluster email service (service postfix status & mail -v <address>)
4. Once the cluster is running to your satisfaction, back up the system settings and MCS
database on each node.
5. The cluster is ready for use.
Reconfiguring ICS for Interplay | MAM or Media Composer |
Cloud in an Upgrade from ICS 1.7 or Earlier
In previous releases, the MCPS Player embedded in the MediaCentral | UX UI required its
own user name and password for communicating with the MCS server (from which it
receives video). In MCS 2.2 this is no longer the case. As of ICS 1.8 the MCPS Player uses the
credentials of the logged-in user.
As a result, if you have deployed MCS in support of Interplay | MAM or Media Composer |
Sphere, and are upgrading from ICS 1.7 (or earlier) you will need to reconfigure MCS to
support these applications.
Reconfiguring MCS for Use with Interplay | MAM
To reconfigure MCS for use with Interplay | MAM:
1. With the server (or cluster) up and running, log in to MediaCentral | UX as an
administrator level-user, using the host name or IP address of the server or cluster.
2. Select Users from the Layout selector.
3. Create a special role for the Interplay | MAM user by clicking on the Create Role button
in the Roles pane.
4. Click the Create Role button.
5. In the Details pane, type the properties for the new role:
·
Role name (e.g. MAM)
·
·
Advance License
Do not assign the MAM role any layouts
6. Click Apply to save your changes.
The new MAM role is added to the Roles pane.
28
7. Create a MAM user by clicking the Create User button.
8. In the Details pane, type the properties for the new user:
·
User name (e.g. MAM)
·
Password
·
Uncheck “User must change password at next sign-in”
·
Check “User cannot change password
9. Drag the MAM role from Roles pane to the Role section of the Details pane for the new
user.
10. Click Save to save your changes.
The new MAM user is added to the User Tree, as a top-level user.
For more information on creating users and roles, see the “Interplay Central Administration
Guide”.
Reconfiguring MCS for Use with Media Composer | Cloud
To reconfigure MCS for use with Media Composer | Cloud
1. With the server (or cluster) up and running, log in to MediaCentral | UX using the host
name or IP address of the server or cluster.
2. Select System Settings from the Layout selector.
3. In the Settings pane, click Player.
4. Enter the user name and password reserved for Sphere (e.g. sphere).
5. Click Apply to save your changes.
Backing Up and Restoring SSL Private Keys
Upgrading can be a “true” (non-destructive) upgrade, or can involve a fresh install of RHEL.
For fresh installs, the system-backup script has been provided to back up and restore system
settings related to ICS, including SSL data (the Jetty keystore and certificates it contains).
However, if you stored the private key (jettyPrivateKey.key) file in in the root user home
directory (/root) be sure to back it up manually before the upgrade. Backing up private key
files is good practice, whatever the type of upgrade being performed.
Note: If the private key was not backed up elsewhere, it is doubly important to back up the
keystore before performing the upgrade. The private key is used to generate Certificate Signing
Requests (CSRs).
For instructions on installing SSL certificates see the following article:
29
http://avid.force.com/pkb/articles/en_US/how_to/SSL-Certificates-for-server-to-browserconnections
To back up and restore the Jetty keystore:
1. Locate the separate private key file used to generate the Certificate Signing Request
(if any).
The default name is jettyPrivateKey.key. During its creation, it was suggested you
store it in the following directory:
/root
2. Copy the private key to a safe location (off the ICS server), restoring it at an
appropriate step in the upgrade.
30
Appendix A: Frequently Asked Questions
What is the difference between the system-backup script and the avid-db utility?
The system-backup script is used to back up and restore important ICS system settings and is
found on the USB installation key. The avid-db utility is used to back up and restore the ICS
database (including user information), and is found in the /opt/avid/bin directory.
What About MediaCentral Distribution Service (MCDS)?
If you are upgrading from Interplay Central 1.4 or later, MCDS is already separately installed
and configured, and the settings configured for it are backed up and restored as part of the
upgrade process.
Note: For installation instructions see “Installing the MediaCentral Distribution Service” in the
MCS 2.2 Installation & Configuration Guide. For versions compatibility, see the MCS 2.2 ReadMe.
What Do I Do With the Unused Hardware After an Upgrade from 1.2.x?
(Interplay Central only) If you are upgrading from Interplay Central 1.2.x to MediaCentral
2.2, some hardware used in 1.2.x is no longer required in 2.2. You can decommission this
hardware entirely, though you may want to repurpose it for other uses. Here are some
suggestions:
·
Repurpose the former Interplay Central middleware servers to run ICDS (required by
Interplay Central). In this case, uninstall Interplay Central. If necessary, update Avid
Service Framework (ASF), the Windows ISIS client, and then the ICDS package that came
with your ICS installation package.
·
If the former Interplay Central middleware servers are AS3000s, you may want to
repurpose them as Interplay Transcode engines, or some other Interplay service engine.
Consult an Avid representative for options.
31
Appendix B: Migrating the UMS Database to a Test Node
ICS maintains a database containing information for the following subsystems:
·
ACS - Avid Common Services
·
ICPS - Interplay Central Playback Services
·
UMS - User Management Services
In some situations you might need to extract just the UMS data. For example, you may want
to update the ICS database of a test system with user names and passwords, roles, and so
on, from a ICS system in a production setting. This appendix provides the procedures for
doing so.
Migrating the 1.6.x (or later) UMS Database
To extract the UMS database from an ICS 1.6.x (or later) system, use the avid-ums-backup
and avid-ums-restore utilities:
avid-ums-backup <backup-filename> [-pp <postgres password>] [ -pu <postgres user>]
avid-ums-restore <backup-filename> [-pp <postgres password>] [-pu <postgres user>]
The tools for working with the UMS database are located in the following directory:
/opt/avid/bin
To extract the UMS database from an ICS 1.6.x (or later) system:
1. Log in to the master node as root and dump the UMS database:
avid-ums-backup <backup-filename>
[-pu <postgres user>]
[-pp <postgres password>]
For example:
avid-ums-backup backup.sql
-pu postgres
The system responds with an indication of success:
UMS database was backed up successfully.
2. Move the file to the server of interest in preparation for restoring it to the MCS 2.2
system.
To restore the UMS database to an MCS 2.2 system:
1. Log in to the master node as root
2. Stop the UMS service:
service avid-ums stop
32
In the case of a cluster, issue the following command instead:
crm resource stop AvidUMS
3. Restore the UMS database:
avid-ums-restore <backup-filename>
[-pu <postgres user>]
[-pp <postgres password>]
For example:
avid-ums-restore backup.sql -pu postgres
Once you confirm the restore operation, the operation begins. It can take a minute or
two.
The system responds with an indication of success:
UMS database was restore successfully.
4. Confirm the UMS service was restarted by the avid-ums-restore utility:
service avid-ums status
crm resource status AvidUMS
Migrating the 1.4.x/1.5.x UMS Database
To extract the UMS database from an ICS 1.4.x/1.5.x system and load it into an MCS 2.2
system, you must use PostgreSQL tools directly, at both ends.
To extract the UMS database from an ICS 1.4.x/1.5.x System:
1. Log in to the master node as root and dump the UMS database:
pg_dump –U postgres uls > uls_backup.sql
2. Move the file to a safe location (off the server) in preparation for restoring it to the MCS
2.2 system.
To restore the ICS 1.4.x/1.5.x UMS database to the MCS 2.2 system:
5. Log in to the master node as root
6. Stop the UMS service:
service avid-ums stop
crm resource stop AvidUMS
7. Drop the current UMS database from the ICS database:
33
psql –U postgres –c "drop database uls;"
8. Create a new UMS database:
psql –U ulsuser postgres –c "create database uls;"
9. Import the ICS 1.5 UMS database:
psql –U ulsuser uls < uls_backup.sql
10. Start the UMS service:
service avid-ums start
crm resource start AvidUMS
Appendix C: Mounting and Unmounting the USB Key
Refer to the instructions below to mount the USB key.
Note: If you decide not to mount the USB key — for example, —
To mount and unmount the USB key:
1. Insert the USB key into the MCS server.
2. Verify the name of the device using the dmesg command:
dmesg
Linux information relating to hardware appears on the screen.
Information for the USB key will appear near the end of the output, near the list of SCSI
devices. The name of the USB key is found inside square brackets (e.g. sdc). This is the
name you use to mount the key.
3. If needed, create a mount point for the USB key:
mkdir
/media/usb
4. Mount the USB key at the mount point you just created:
mount
/dev/sdc1
/media/usb
Note the name of the USB key, sdc (in this case), takes a 1 (one) in the mount command.
This simply indicates a partition exists on the USB key. When the USB key was
formatted, the partition was created.
The USB key is now mounted and available for use.
5. Verify the USB key has been mounted:
df -h
34
Information is displayed about all mounted filesystems and devices, and should include
information about the USB key, similar to the following (other output has been omitted,
for clarity):
Filesystem
/dev/sdc1
Size
7.5G
Used Avail Use% Mounted on
5.3G 2.2G 71% /media/usb
6. To change to the mount point:
cd media/usb
7. To unmount the USB key when finished, ensure you are not currently on it by changing
directories:
cd
Note: In Linux the cd command without any arguments takes you directly to the user’s home
directory. If you are logged in as root, it takes you to the /root directory. You must be off the
USB key to unmount it.
8. Unmount the USB key:
umount
/media/usb
The USB key is now available for use in another server.
If you receive an error message that the USB device is busy, it typically indicates the
Linux ISO on the USB key was automounted. Verify what is mounted using the df -h
command and/or the mount command. Then, dismount the Linux ISO first, followed by
the USB device:
umount /sysinstall
umount /media/usb
9. Remove the USB key from the server.
Removing the USB key prevents accidental rebooting and re-imaging of the system disk.
Appendix D: Deleting the RAID 5
When upgrading from one version of RHEL to another, it is recommended that you delete
the RAID 5 prior to installing the new OS and MCS software. Deleting and re-creating the
RAID 5 eliminates (in advance) problems with cache permissions that can arise as a result of
the RHEL update.
This section provides instructions for deleting the RAID 5. For information on re-creating the
RAID 5, in the MCS 2.2 Installation and Configuration Guide, see “Setting Up the RAID Level 5
Cache Drives”.
To delete the RAID 5 prior to an upgrade in which the OS changes:
1. Umount and remove the USB key (if you have not already done so) then reboot the
server.
35
2. Press any key when prompted (spacebar recommended) to display the HP ProLiant
“Option ROM” messages.
3. As soon as you see the prompt to enter the Option ROM Configuration for Arrays utility,
press F8.
Note: The prompt to press F8 can flash by very quickly. If you miss it, reboot and try
again.
36
4. From the Main Menu, select Delete Logical Drive and press Enter.
5. Select the RAID 5 and press F8 to delete.
6. A warning appears asking you to confirm your choice. Press F3 to delete the RAID.
37
7. The RAID 5 is removed, and can now be re-created.
Cache Drives”.
Note: As indicated in the MCS 2.2 Installation and Configuration Guide, once you have recreated the RAID 5 and have returned to the Main Menu, do not press <Esc> to exit since this
reboots the server. Wait until you have inserted the USB key and are ready to perform the
upgrade.
Appendix E: Backing Up and Restoring System Settings and
the ICS/MCS Database
Before performing an upgrade it is recommended — and sometimes required — that you
back up the ICS/MCS server system settings using the system-backup script. Depending on
the upgrade path, you may also be required to restore the backed up system settings after.
The system-backup script provided for this task backs up important files and directories,
including NIC card settings, DNS settings, and so on. In addition, the script calls the avid-db
command, which dumps and backs up the contents of the ICS/MCS database. The ICS/MCS
database contains ACS (Avid Common Services, “the bus”), UMS (User Management Service)
and ICPS (Interplay Central Playback Services) data. It collects all this information and backs
it up to the USB key itself.
Note: In a cluster, the IC/MCSS database is replicated across the master and slave node, but
it is only mounted on the master. Thus, the ICS/MCS database is only available for dumping
and backup on the master node.
If you are backing up multiple nodes in a cluster, rename the backup file for each node before
proceeding to the next node. If you do not rename the backup file obtained from the master
38
node, it will be overwritten by the backup from a non-master node and the contents of the
ICS/MCS database will be lost (including user information).
The following table lists the files and directories backed up and restored by the systembackup script.
Note: RHEL user names and passwords (such as the root user) are not backed up or restored
by the system-backup script. After the upgrade, logging in as “root” requires the default
password. For the default root user password, contact your Avid representative.
Directory/File
Description
/etc/sysconfig/*
Network settings
/etc/fstab (restored in /root)
Filesystem settings
/etc/resolv.conf
DNS config file
/etc/ntp.conf
Network Time Protocol config file
/etc/cron.d/ntpd
The cron job that automates
synchronization of the system clock.
/etc/snmp/snmpd.conf
Simple Network Management Protocol
(network monitor)
/usr/maxt/maxedit/etc/*
Maxedit settings (used by ICPS)
/etc/udev/rules.d/70-persistent-net.rules
NIC card settings
/usr/maxt/maxedit/share/MPEGPresets/MPEG2TS.
mpegpreset
Defines encoding for iOS playback
/etc/localtime
Time zone info
/etc/sudoers
List of users with sudo privileges
/opt/avid/etc/avid/avid-interplaycentral/ssl/jetty.keystore
Jetty keystore and SSL certificates and
usage passwords.
/opt/avid/etc/avid/avid-interplaycentral/config/application.properties
Pacemaker configuration
(restored as /root/pcmk.conf)
Pacemaker configuration
/etc/corosync/corosync.conf
Corosync config file
/etc/drbd.d/r0.res
DRDB config file
ICS/MCS database
ICS/MCS database (ACS, UMS and ICPS
data). This includes user information.
RHEL user names and passwords
*** Not backed up. ***
To back up the system settings and ICS/MCS database:
39
Note: When backing up the master node in a cluster, it must not be in standby mode.
When backing up other nodes, they can be in standby.
1. Mount the USB key containing the system-backup script.
34.
2. Change to the mount point. For example:
cd /media/usb
3. Back up the ICS/MCS settings and database using the backup script.
./system-backup.sh –b
Note: The following message indicates the system-backup script has already been run on
the current machine:
File /root/pcmk.conf exists. Do you want to overwrite it?
Type “yes” or “y” to overwrite the file and continue with the backup.
A backup file is written to the USB key:
/media/usb/sys-backup/ics_setup_files.tar.gz
Since the system-backup script also calls the avid-db command, a backup of the ICS/MCS
database is also written to the following directory (on the ICS/MCS server):
/var/lib/avid/db/dumps
The backup file on the server has a name has the following form:
ALL-YYYYMMDD_HHMMSSZ.sql.gz.cr
Note: Note the time stamp appended to the file name uses the Universal Time Code
(UTC), not the local time.
The following message indicates success:
Backup setup successful!
4. Make a copy of the backup file using the Linux cp command. For example:
cp –r sys-backup sys-backup-<nodename>
The above command copies the directory containing the backup file just created. The
backup file itself (ics_setup_files.tar.gz) remains unchanged inside the directory.
Note: Making a copy of the backup file is good practice, and is particularly important if you
are backing up multiple nodes in a cluster. Only the master node backup contains a complete
set of backup information (including end-user data). If you do not make a copy of the master
node backup file, it will be overwritten by the backup from a non-master node.
5. Once the settings are backed up, it is good practice to unmount and remove the USB key
to avoid accidentally rebooting, resulting in a re-image of the system disk.
40
34.
To restore the system settings and ICS/MCS database:
1. Mount the USB key containing the system-backup script.
34.
2. Change to the mount point. For example:
cd /media/usb
3. If you made a copy of the backup file, copy it back to its original location.
cp -r sys-backup-<nodename> sys-backup
4. Restore the ICS/MCS settings and database using the backup script.
./system-backup.sh –r
You are asked to confirm the restoration of the ICS/MCS database:
Would you like to restore the database now? (y/n)
5. Type “y” (without the quotes) to confirm the action.
You are asked to confirm the shutting down of the Avid services:
All Avid services will be shut down before performing a database
restore operation.
Would you like to continue? [yes/no]
6. Type “yes” (spelled out in full, without the quotes) to confirm the action.
Note: Be careful when typing your response to this question. Typing anything other than
“yes” results in the script exiting without restoring the ICS/MCS database. Other items
are restored, but not the ICS/MCS database.
Services are shut down, the ICS/MCS database is restored, and services are restarted.
The ICS/MCS database service is stopped, and you are prompted to restore the
database.
The following message indicates success:
Restoration done!
Your old fstab settings were saved in /root/fstab
Please remove the USB key and reboot the server.
Note: The filesystem table (fstab) file contains information to automate mounting
volumes at boot time. It is not restored automatically.
7. Open the restored filesystem table (/root/fstab) to examine it for reference purposes.
41
·
·
For example, in an MCS system with a RAID 5 cache volume, the restored filesystem table
contains an entry similar to the following:
Note: For Interplay | MAM system the filesystem table contains an entry to automatically
mount the Interplay | MAM filesystem.
8. Once the settings are restored, unmount and remove the USB key.
34.
42
Appendix F: Glossary
This section defines some terms used in this document.
MediaCentral
MediaCentral is the set of web-based and mobile applications that are powered by
MediaCentral Platform Services. MediaCentral can be configured to work with Interplay,
ISIS, and iNEWS to provide video editing, story editing, and logging solutions for
broadcasters and newsrooms.
Prior to Interplay Central 1.3, the middleware and user management services ran separately
on Windows servers.
Media Composer | Cloud
Media Composer | Cloud is a Media Composer and NewsCutter plug-in that enables remote
editing workflows. From any remote connection, you can log into a remote Interplay/ISIS
and upload media from the field, as well as playback media residing on the remote ISIS.
MCPS/MCS are used to provide the remote playback capability.
Interplay | MAM
Interplay | MAM is a media archive solution, extensible to serve several media lifecycle
workflows from ingest to distribution. MCPS/MCS are used to provide web-based playback
of media proxies registered in the MAM database.
MediaCentral Platform Services (MCS)
MediaCentral Platform Services (MCS) is the set of software services that work together to
power MediaCentral. Additionally, MCS provides video playback for Media Composer |
Cloud and Interplay | MAM.
With the release of Interplay Central Services (ICS 1.3) in December 2012, all ICS (now MCS)
services run on the same Linux server. This includes MediaCentral middleware,
MediaCentral user management, and the MediaCentral Playback Service (MCPS).
Interplay Central Playback Service (ICPS)
MediaCentral Playback Service (MCPS) is one of the MCS services. It provides video playback
of video assets for MediaCentral | UX, Media Composer | Cloude, and Interplay | MAM
clients. MCPS can decode Avid MXF data on ISIS and many other standard file formats on
standard and proprietary storage systems.
Prior to ICS 1.3 (and with it Interplay Central 1.3) the ICPS service ran on its own Linux
server.
43
MCS System Settings
In this document, the upgrade procedures refer to backing up and restoring MCS system
settings. These settings include server network configuration, OS user settings (e.g. the root
user password), SSL certificate configuration, load balancing configuration, and the video
player configuration.
MCS Platform Settings
MCS platform settings are the settings you configure in the MediaCentral | UX
administration UI (e.g. the connections to Interplay, ISIS, and iNEWS).
MCS Database
In this document, the upgrade procedures refer to backing up and restoring the MCS
database. This database stores the MCS platform settings.
MediaCentral User Management Database
Since ICS 1.3, the Interplay Central (now MediaCentral) User Management database has
been part of the ICS/MCS database. Prior to ICS 1.3, the Interplay Central user management
database was a separate database on the Interplay Central middleware servers
This explains why when upgrading from Interplay Central 1.2.x to 2.2, migrating the
Interplay Central user management database is required. The migration of the database
merges the user management data into the ICS (now MCS) database.
Corosync
Corosync is a software service used by MCS to manage MCS software services across a
multi-node server cluster. Corosync orchestrates the stopping and starting of software
services on nodes in the cluster to obtain a highly available system.
Distributed Replicated Block Device (DRBD)
DRBD refers to block devices designed as a building block to form high availability (HA)
clusters. DRBD can be understood as network based RAID (level 1). In MCS, DRBD is used to
replicate the MCS database, allowing for a more reliable failover in more severe software
and service failures.
DRBD was introduced in ICS 1.4—configuring DRBD is a required step for cluster setups only.
44
Copyright and Disclaimer
Product specifications are subject to change without notice and do not represent a commitment on the part of Avid
Technology, Inc.
The software described in this document is furnished under a license agreement. You can obtain a copy of that license by
visiting Avid's Web site at www.avid.com. The terms of that license are also available in the product in the same directory as
the software. The software may not be reverse assembled and may be used or copied only in accordance with the terms of the
license agreement. It is against the law to copy the software on any medium except as specifically allowed in the license
agreement.
No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including
photocopying and recording, for any purpose without the express written permission of Avid Technology, Inc.
Copyright © 2013 Avid Technology, Inc. and its licensors. All rights reserved.
Attn. Government User(s). Restricted Rights Legend
U.S. GOVERNMENT RESTRICTED RIGHTS. This Software and its documentation are “commercial computer software” or
“commercial computer software documentation.” In the event that such Software or documentation is acquired by or on behalf
of a unit or agency of the U.S. Government, all rights with respect to this Software and documentation are subject to the terms
of the License Agreement, pursuant to FAR §12.212(a) and/or DFARS §227.7202-1(a), as applicable.
This product may be protected by one or more U.S. and non-U.S patents. Details are available at www.avid.com/patents.
Trademarks
Adrenaline, AirSpeed, ALEX, Alienbrain, Archive, Archive II, Assistant Avid, Avid Unity, Avid Unity ISIS, Avid VideoRAID,
CaptureManager, CountDown, Deko, DekoCast, FastBreak, Flexevent, FXDeko, iNEWS, iNEWS Assign, iNEWS ControlAir,
Instinct, IntelliRender, Intelli-Sat, Intelli-sat Broadcasting Recording Manager, Interplay, ISIS, IsoSync, LaunchPad, LeaderPlus,
ListSync, MachineControl, make manage move | media, Media Composer, NewsCutter, NewsView, OMF, OMF Interchange,
Open Media Framework, Open Media Management, SIDON, SimulPlay, SimulRecord, SPACE, SPACEShift, Sundance Digital,
Sundance, Symphony, Thunder, Titansync, Titan, UnityRAID, Video the Web Way, VideoRAID, VideoSPACE, VideoSpin, and
Xdeck are either registered trademarks or trademarks of Avid Technology, Inc. in the United States and/or other countries.
All other trademarks contained herein are the property of their respective owners.
MediaCentral Services v2.2 Upgrading Guide• 17 April 2015
• This document is distributed by Avid in online (electronic) form only, and is not available for purchase in printed form.
45

- Avid Technology

Transcription

Similar documents

newsletter 10 Jahre mcs

file - OpenHeadend

Mission, Vision, and Values A ministry of Maranatha Chapel

HOW TO UPGRADE YOUR HARDLOCK KEY

The Growing Edge O E L

Mission, Vision, Values II A ministry of Maranatha Chapel

Industry Leading Solutions for the Flexographic Industry - Add-Jet

MCS 2011 Newsletter Issue 2

abstract

Eagle Express 08/28/15