Upgrade Guide
Virtual Multimedia Resource Function
Contents
This document describes the manual vMRF
upgrade and rollback
process on a cloud service. During the manual upgrade process, the user must
perform the upgrade-related tasks manually, using application scripts and the
deployment-related functions in the cloud environment. The manual upgrade process must be used
until the Ericsson Network Manager (ENM) becomes available. In the ENM, the upgrade process,
which involves deployment of a new VNF and migrating the configuration, will be offered as a
fully automated solution.
This document is written for
vMRF
operator personnel who are responsible for upgrading
vMRF.
The
vMRF
operator is assumed to be a cloud service consumer, that is, an end user on a cloud service.
The end user is also referred to as a tenant.
The
network-redundant
upgrade process can be performed when two VNFs are available in parallel during normal
operation, as described in Network-Redundant Upgrade.
Alternatively,
manual in-service upgrade process, as described in vMRF In-Service Upgrade,
requires that temporarily two VNFs are running in parallel, and there is no traffic
impact during the upgrade
process.
This procedure describes how to upgrade
vMRF with network redundancy available. This procedure can be performed when two
VNFs are
available in parallel during normal operation.
Figure 1 shows the
network-redundant upgrade process.
-
Export data
Configuration data is exported from the vMRF.
-
The vMRF is locked. After lock, the vMRF does not handle sessions, so it stops processing
traffic.
-
The vMRF is
scaled-in and removed.
-
A new version of vMRF is deployed.
The configuration data exported previously is imported into the new version.
After that, the new version of vMRF already starts processing traffic.
Figure 1 vMRF
Network-Redundant Upgrade
Steps
-
Open an SSH connection to the O&M IP address of the old version of the vMRF VNF
instance using the following command:
ssh <user ID>@<O&M IP
address>
-
Run the following command:
/opt/mrf_director/mrf_export_conf.py /home/<user
ID>/<output file without extension>
The configuration data is exported into a specified
.tar.gz
archive file (the default and recommended format).
-
Copy the exported configuration file out of the file system of the VNF using, for
example,
scp:
scp <user
ID>@<O&M IP address>:/home/<user
ID>/mrf_conf.tar.gz .
The configuration file mrf_conf.tar.gz is
copied from the /home/<user ID>/ folder in the file system of
the vMRF VNF to the current
directory.
Steps
-
Lock all
the deployed VMs in the old version of the vMRF VNF
instance. Consider graceful locking through MTAS configuration by
gracefully locking the MRFP nodes in MTAS. For more information, refer to
section Deactivate Gracefully in MTAS Media Control Management Guide,
Reference [1]. Otherwise continue with the following
steps:
| Note: |
In the procedure below, after modifying the
administrativeState attribute, the VMs are
immediately locked and all ongoing traffic on the VMs stops.
|
-
Open an SSH connection to the O&M IP address of the vMRF VNF
using the following command:
ssh <user ID>@<O&M
IP address>
-
Start a session by issuing the cliss command.
-
Navigate to the MrfInstance MO that
represents the VM and enter configure mode:
>ManagedElement=1,MediaResourceFunction=1,MrfResource=1,MrfInstance=<mrfInstanceId>
(MrfInstance=<mrfInstanceId>)>configure
-
Modify the value of the administrativeState
attribute:
(config-MrfInstance=<mrfInstanceId>)>administrativeState=<LOCKED>
-
Commit the changes:
(config-MrfInstance=<mrfInstanceId>)>commit
-
Repeat steps from Step 1.b to
Step 1.e for all
VMs.
The VM is locked immediately.
-
Scale in all the deployed VMs of the instance, as described in vMRF Configuration Management.
-
Using the proper deployment instructions, deploy the new version of
vMRF with one or two VMs, and check that it is running
properly. Ensure that the new version connects to the same external networks as
the old version. It is recommended to import the configuration data during
deployment.
-
If you have imported configuration data during deployment, continue with Step 6. Otherwise,
continue with the next step.
-
Open an SSH connection to the O&M IP address of the new version of the vMRF VNF instance
using the following command:
ssh <user ID>@<O&M IP
address>
-
Copy the configuration data file exported from the old version to the file system of the new
version using, for example, scp:
scp
mrf_conf.tar.gz <user ID>@<O&M IP
address>:/home/<user
ID>
The configuration file mrf_conf.tar.gz is copied from the current directory to the
/home/<user ID>/
folder in the file system of the vMRF VNF.
-
Run the following command:
/opt/mrf_director/mrf_import_conf.py /home/<user
ID>/mrf_conf.tar.gz
-
Check that traffic processing in the new version of the vMRF VNF instance
is working properly.
The new version starts processing traffic. If there are problems with the new version
that cannot be solved and that are considered unacceptable, continue with Rollback Procedure.
The vMRF
in-service
manual upgrade process involves deployment of a new VNF and migrating the
configuration. This method requires that temporarily two VNFs are running in parallel.
Figure 2 vMRF
In-Service
Upgrade
-
Export data
Configuration data is exported from the old version of vMRF.
-
Deploy the new version of vMRF
The new version is deployed with only a few VMs to minimize the potential impact on
traffic of a software fault in the new version. The configuration data exported from the
old version is imported into the new version. After that, the new version of vMRF already
starts processing traffic.
It is recommended to monitor the new version of vMRF. If the new version has any severe
problems, the upgrade must be rolled back.
-
Commit to using the new version of vMRF
The new version is scaled out to the actual number of VMs and the old version is locked. After the lock, the old version of vMRF
does not handle
sessions, so it
stops processing traffic.
It is recommended to monitor the new version of vMRF until it has fully taken over the
traffic. If any severe problems are found, the upgrade must be rolled back.
-
Remove the old version of vMRF
If the new version is considered to be operating on a sufficient
level, the old version can be removed. It is also possible to keep
the old version and run the old and new versions in parallel if, for
example, there is a requirement to have a longer testing period for
the new version.
Steps
-
Open an SSH connection to the O&M IP address of the old version of the vMRF VNF
instance using the following command:
ssh <user ID>@<O&M IP
address>
-
Run the following command:
/opt/mrf_director/mrf_export_conf.py /home/<user
ID>/<output file without extension>
The configuration data is exported into a specified
.tar.gz
archive file (the default and recommended format).
-
Copy the exported configuration file out of the file system of the VNF using, for
example,
scp:
scp <user
ID>@<O&M IP address>:/home/<user
ID>/mrf_conf.tar.gz .
The configuration file mrf_conf.tar.gz is
copied from the /home/<user ID>/ folder in the file system of
the vMRF VNF to the current
directory.
Prerequisites
Before starting this procedure, ensure that the following conditions are met:
-
The vMRF VMs to be scaled-out are configured as MRFP (Media Resource
Function Processor) nodes in the MTAS.
A vMRF VM identifies itself to the MTAS with a Message Id (MId) that
contains the vMRF VM signaling IP address and SCTP port. Typically, the
whole range of signaling IP addresses, that is, the signaling subnet,
that has been configured in the OpenStack for the vMRF VNF, is
configured as MRFP nodes in the MTAS.
For more information on adding an MRFP node in MTAS, refer to section Add
MRFP in MTAS Media Control Management Guide, Reference
[1].
Steps
-
Using the proper deployment instructions, deploy the new version of vMRF with one or two VMs, and check that it is running properly. Ensure
that the new version connects to the same external networks as the old version. It is
recommended to import the configuration data during deployment.
| Note: |
In OSS-RC, make sure to create a new VNF as well, due to the different O&M IP
addresses used for the old and the new VNFs.
|
-
If you have imported configuration data during deployment, continue with Step 6. Otherwise, continue with
the next step.
-
Open an SSH connection to the O&M IP address of the new version of the vMRF VNF instance using the
following command:
ssh <user ID>@<O&M IP
address>
-
Copy the configuration data file exported from the old
version to the file system of the new version using, for
example, scp:
scp mrf_conf.tar.gz
<user ID>@<O&M IP
address>:/home/<user ID>
The configuration file mrf_conf.tar.gz is
copied from the current directory to the /home/<user
ID>/ folder in the file system of the vMRF VNF.
-
Run the following command:
/opt/mrf_director/mrf_import_conf.py /home/<user
ID>/mrf_conf.tar.gz
-
Check that traffic processing in the new version of the vMRF VNF instance is working
properly.
-
If the operation of the new version is considered acceptable, continue with Commit to Using the New Version.
If there are problems with the new version that cannot be solved and that are
considered unacceptable, do not proceed with the upgrade, continue with Rollback Procedure.
Steps
-
Scale out the new version of the VNF by increasing the number of VMs to the full
capacity of the VNF.
| Note: |
If there are not enough resources to scale out the new instance while the old
instance still exists, scale in the old instance, as described in vMRF Configuration Management. Always keep one VM in
the old VNF.
|
If there are problems with the new version during or after scaling out that cannot be
solved and that are considered unacceptable, do not proceed with the upgrade, continue
with Rollback Procedure to roll back the upgrade.
-
Lock all the
deployed VMs in the old version of the vMRF
VNF
instance. Consider graceful locking through MTAS configuration by gracefully
locking the MRFP nodes in MTAS. For more information, refer to section Deactivate
Gracefully in MTAS Media Control Management Guide, Reference [1]. Otherwise continue
with the following steps:
| Note: |
In the procedure below, after modifying the administrativeState
attribute, the VMs are immediately locked and all ongoing traffic on the VMs
stops.
|
-
Open an SSH connection to the O&M IP address of the vMRF VNF using the
following command:
ssh <user ID>@<O&M IP
address>
-
Start a session by issuing the cliss command.
-
Navigate to the MrfInstance MO that represents the VM and
enter configure mode:
>ManagedElement=1,MediaResourceFunction=1,MrfResource=1,MrfInstance=<mrfInstanceId>
(MrfInstance=<mrfInstanceId>)>configure
-
Modify the value of the administrativeState attribute:
(config-MrfInstance=<mrfInstanceId>)>administrativeState=<LOCKED>
-
Commit the changes:
(config-MrfInstance=<mrfInstanceId>)>commit
-
Repeat steps from Step 2.c to Step 2.e for all VMs.
The VM is locked immediately.
It is possible to keep the old version and run the old and new
version in parallel if, for example, there is a requirement to have
a longer testing period for the new version. If the old version is
no longer needed, remove it.
If there are problems with the new version that cannot be solved and that are
considered unacceptable, the latest upgrade must be rolled back.
Steps
-
If any severe problems are found in the new vMRF VNF instance
while the old VNF still exists, lock the
new version by locking all the deployed
VMs. Consider graceful locking through MTAS configuration by
gracefully locking the MRFP nodes in MTAS. For more information, refer to
section Deactivate Gracefully in MTAS Media Control Management Guide,
Reference [1]. Otherwise continue with the following
steps:
| Note: |
In the procedure below, after modifying the
administrativeState attribute, the VMs are
immediately locked and all ongoing traffic on the VMs stops.
|
-
Open an SSH connection to the O&M IP address of the vMRF VNF
using the following command:
ssh <user ID>@<O&M
IP address>
-
Start a session by issuing the cliss command.
-
Navigate to the MrfInstance MO that
represents the VM and enter configure mode:
>ManagedElement=1,MediaResourceFunction=1,MrfResource=1,MrfInstance=<mrfInstanceId>
(MrfInstance=<mrfInstanceId>)>configure
-
Modify the value of the administrativeState
attribute:
(config-MrfInstance=<mrfInstanceId>)>administrativeState=<LOCKED>
-
Commit the changes:
(config-MrfInstance=<mrfInstanceId>)>commit
-
Create a report, and attach troubleshooting data according to the Data Collection Guideline for
vMRF. Send the report to the Ericsson support organization.
-
If required by the Ericsson support organization, keep the new version of vMRF for debugging
purposes. Otherwise, remove the new version.
The upgrade is rolled back, you can exit this procedure.
|
[1]
|
MTAS Media Control Management Guide, 19/1553-AVA 901
29/9
|
Figure 1 vMRF
Network-Redundant Upgrade
Figure 2 vMRF
In-Service
Upgrade