Chapter 1. Quickly Install MRG Messaging
1.1. The Messaging Server
1.1.1. The Messaging Server
1.1.2. Messaging Broker
1.1.3. Install MRG-M 3 Messaging Server on Red Hat Enterprise Linux 6
- If you are using RHN classic management for your system, subscribe your system to the base channel for Red Hat Enterprise Linux 6.
- Additionally, subscribe to the available MRG Messaging software channels relevant to your installation and requirements:
MRG Messaging Software Channels
- Base Channel
- Subscribe to the
Additional Services Channels for Red Hat Enterprise Linux 6
/MRG Messaging v.3 (for RHEL-6 Server)
channel to enable full MRG Messaging Platform installations. - High Availability Channel
- Subscribe to the
Additional Services Channels for Red Hat Enterprise Linux 6 / RHEL Server High Availability
channel to enable High Availability installations.
- Install the MRG Messaging server and client using the following commands:
Note
If only Messaging Client support is required go directly to Step 4.- MRG Messaging Server and Client
- Install the "MRG Messaging" group using the following
yum
command (as root):yum groupinstall "MRG Messaging"
- High Availability Support
- If High Availability support is required, install the package using the following yum command (as root):
yum install qpid-cpp-server-ha
Alternative: Install Messaging Client Support Only
If only messaging client support is required, install the "Messaging Client Support" group using the followingyum
command (as root):yum groupinstall "Messaging Client Support"
You do not need to install this group if you have already installed the "MRG Messaging" group. It is included by default.Note
Both Qpid JMS AMQP 0.10 and 1.0 clients require Java 1.7 to run. Ensure the Java version installed on your system is 1.7 or higher.
1.1.4. Upgrade a MRG Messaging 2 Server to MRG Messaging 3
- If you are using RHN classic management for your system, subscribe your system to the base channel for Red Hat Enterprise Linux 6.
- Remove incompatible components. Run the following command as root:
yum erase qpid-cpp-server-cluster sesame cumin cumin-messaging python-wallaby
- Unsubscribe the system from the MRG v2 channels.
- Additionally, subscribe to the available MRG Messaging software channels relevant to your installation and requirements:
MRG Messaging Software Channels
- Base Channel
- Subscribe to the
Additional Services Channels for Red Hat Enterprise Linux 6
/MRG Messaging v.3 (for RHEL-6 Server)
channel to enable full MRG Messaging Platform installations. - High Availability Channel
- Subscribe to the
Additional Services Channels for Red Hat Enterprise Linux 6 / RHEL Server High Availability
channel to enable High Availability installations.
- Update the MRG Messaging server and client using the following commands:
Note
If only Messaging Client support is required go directly to Step Six.- MRG Messaging Server and Client
- Update the "MRG Messaging" group using the following
yum
command (as root):yum groupinstall "MRG Messaging"
- High Availability Support
- If High Availability support is required, update the package using the following yum command (as root):
yum install qpid-cpp-server-ha
- If only messaging client support is required, update the "Messaging Client Support" group using the following
yum
command (as root):yum groupinstall "Messaging Client Support"
You do not need to update this group if you have already updated the "MRG Messaging" group. It is included by default.Note
Both Qpid JMS AMQP 0.10 and 1.0 clients require Java 1.7 to run. Ensure the Java version installed on your system is 1.7 or higher.
1.1.5. Linearstore Custom Broker EFP Partitions
See Also:
1.1.6. Upgrade a MRG Messaging 3.1 Server to MRG Messaging 3.2
Procedure 1.1. How to Upgrade MRG Messaging 3.1 to 3.2
- Verify that all required software channels are still correctly subscribed to in Section 1.1.3, “Install MRG-M 3 Messaging Server on Red Hat Enterprise Linux 6”
- Stop the server by doing one of the following:
- Press Ctrl+C to shutdown the server correctly if started from the command line.
- Run
service qpidd stop
to stop the service correctly.
- Run
sudo yum update qpid-cpp-server-ha
to upgrade to the latest packages. Important
If you intend to set up custom EFP partitions, complete the steps in Procedure 1.2, “How To Manually Upgrade Linearstore EFP to the New Partitioning Structure” before completing this step.Restart the server by runningqpidd
orservice qpidd start
depending on requirements.
Directory Changes
- qls/dat
- This directory is now
qls/dat2
. There is no other change other than the directory name. - qls/tpl
- This directory is now
qls/tpl2
.The journal files previously stored in this directory are now links to journal files. The actual files now reside inqls/pNNN/efp/[size]k/in_use
directory in the EFP. This allows the files to be contained within the partition in which the EFP exists. - qls/jrnl
- This directory is now
qls/jrnl2
, and contains the [queue-name] directories.The [queue-name] directories previously stored inqls/jrnl
are now links to journal directories. The actual directories now reside inqls/pNNN/efp/[size]k/in_use
directory in the EFP. This allows the directories to be contained within the partition in which the EFP exists. - qls/pNNN/efp/[size]k
- Directories of this type now contain an
/in_use
and/returned
subdirectory, along with the empty files.pNNN
relates to the broker partition ID, which is set on the command line using the--efp-partition
parameter.[size]k
is the size in MiB of the broker partition, which is set on the command line using the--efp-file-size
parameter.
Note
- You have queues that cannot be recreated.
- There is message data that cannot be expunged before the upgrade.
Example 1.1. Old directory structure
qls
├── dat (contains Berkeley DB database files)
├── p001
│ └── efp
│ └── 2028k (contains empty/returned journal files)
├── jrnl
│ ├── queue_1 (contains in-use journal files belonging to queue_1)
│ ├── queue_2 (contains in-use journal files belonging to queue_2)
│ ├── queue_3 (contains in-use journal files belonging to queue_3)
│ ...
└── tpl (contains in-use journal files belonging to the TPL)
Possible variations
- It is possible to use any number of different EFP file sizes, and there may be a number of other directories besides the default of 2048k.
- It is possible to have a number of different partition directories, but in the old Linearstore, these don't perform any useful function other than providing a separate directory for EFP files. These directories must be named
pNNN
, where NNN is a 3-digit number. The partition numbers need not be sequential.
Example 1.2. New directory structure
qls
├── dat2 (contains Berkeley DB database files)
├── p001
│ └── efp
│ └── 2028k (contains empty/returned journal files)
│ ├── in_use (contains in-use journal files)
│ └── returned (contains files recently returned from being in-use, but not yet processed before being returned to the 2048k directory)
│
├── jrnl2
│ ├── queue_1 (contains in-use journal files belonging to queue_1)
│ ├── queue_2 (contains in-use journal files belonging to queue_2)
│ ├── queue_3 (contains in-use journal files belonging to queue_3)
│ ...
└── tpl2 (contains in-use journal files belonging to the TPL)
Note
Procedure 1.2. How To Manually Upgrade Linearstore EFP to the New Partitioning Structure
- Create new directories
qls/dat2
.# mkdir dat2
- Copy the contents of the Berkeley DB database from
qls/dat
to the newqls/dat2
directory.# cp dat/* dat2/
- For each EFP directory in
qls/
, add 2 additional subdirectories;pNNN
/efp/[size]k- in_use
# mkdir p001/efp/2048k/in_use
- returned
# mkdir p001/efp/2048k/returned
By default, there is only one partition;qls/p001
, and only one EFP size;2048k
. - Create a
jrnl2
directory.# mkdir jrnl2
For each directory in the oldjrnl
directory (each of which is named for an existing queue), create an identically named directory in the newjrnl2
directory.# mkdir jrnl2/[queue-name-1] # mkdir jrnl2/[queue-name-2] ...
You can list the directories present in thejrnl2
directory with the following command:# dir jrnl
- Each journal file must be first copied to the
in_use
directory of the correct partition directory with correct efp size directory. Then a link must be created to this journal file in the newjrnl2/[queue-name]
directory.Two pieces of information are needed for every journal file:- Which partition it originated from.
- Which size within that partition it is.
The default setting is a single partition number (in directoryqls/p001
), and a single EFP size of2048k
(which is the approximate size of each journal file). If the old directory structure has only these defaults, then proceed as follows:- For each queue in
qls/jrnl
, note the journal files present. Once they are moved, it will be difficult to distinguish which journal files are from which queue as other journal files from other queues will also be present.# ls -la jrnl/queue-name/*
- Copy all the journal files from the old queue directory into the partition's
2048k
in_use
directory.# cp jrnl/queue-name/* p001/efp/2048k/in_use/
- Finally, create a symbolic link to these files in the new queue directory created in step 3 above. This step requires the names of the files copied in step b. above.
# ln -s /abs_path_to/qls/p001/efp/2048k/in_use/journal_1_file_name.jrnl jrnl2/queue-name/ # ln -s /abs_path_to/qls/p001/efp/2048k/in_use/journal_2_file_name.jrnl jrnl2/queue-name/ ...
Note
When creating a symlink, use an absolute path to the source file. - Repeat the previous step for each journal file in queue.If more than one partition exists, it is important to know which journal files belong to which partition.You can inspect a hexdump of the file header for each journal file to obtain this information. Note the 2-byte value at offset 26 (0x1a):
# hexdump -Cn 4096 path/to/uuid.jrnl 00000000 51 4c 53 66 02 00 00 00 1c 62 0c f1 e2 4c 42 0d |QLSf.....b...LB.| 00000010 5a 6b 00 00 00 00 00 00 01 00 01 00 00 00 00 00 |Zk..............| 00000020 00 02 00 00 00 00 00 00 00 10 00 00 00 00 00 00 |................| 00000030 34 63 b9 54 00 00 00 00 8e 61 ef 2c 00 00 00 00 |4c.T.....a.,....| 00000040 2f 00 00 00 00 00 00 00 08 00 54 70 6c 53 74 6f |/.........TplSto| 00000050 72 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |re..............| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
In the event that there are several size directories inpNNN/efp/
directory, it is necessary to consider the size of the files being copied in step b. above, and ensure that they are copied to thein_use
directory of correct efp size.Example 1.3. More than one size in use in a partition
qls └── jrnl ├── queue-1 │ └──jrnl1_file.jrnl (size 2101248) └── queue-2 └──jrnl2_file.jrnl (size 4198400)
Assuming that both these files belong to partitionpNNN
, thenjrnl1_file.jrnl
will be copied to the newpNNN/efp/2048k/
directory, andjrnl2_file.jrnl
will be copied to the new pNNN/efp/4096k/ directory.
- The Transaction Prepared List (TPL) is a special queue which records transaction prepare and commit/abort boundaries for a transaction. In the new store, it is located in a new directory called
tpl2
.- Create the
tpl2
directory:# mkdir tpl2
- Repeat the process described in step 4 above, except that the journal files are located in the
tpl
directory, and the symlinks must be created in the newtpl2
directory:- List current journal files:
# ls -la tpl
- Copy journal files to from the
tpl
directory to the correctpNNN/efp/[size]k/in_use
alongside other files copied as part of step 4 above.# cp tpl/* p001/efp/2048k/in_use/
- Create symbolic links in the new
tpl2
directory to these files:# ln -s abs_path_to/qls/p001/efp/2048k/in_use/efp_journal_1_file_name.jrnl tpl2/
- Repeat the above step for each file copied in
tpl
.
See thenote
in step 4 above if more than one partition and/or more than one EFP size is in use, and make the appropriate adjustments as described there if necessary. - Restore the correct ownership of the
qls
directory:# chown -R qpidd:qpidd /absolute_path_to/qls
- Restore SELinux contexts for qls directory
# restorecon -FvvR /abs_path_to/qls
--log-enable info+
for the first restart, otherwise change the broker configuration file to use this log level prior to starting the broker as a service.
See Also:
1.1.7. Configure the Firewall for Message Broker Traffic
5672
.
root
user.
Procedure 1.3. Configuring the firewall for message broker traffic
- Open the
/etc/sysconfig/iptables
file in a text editor. - Add an
INPUT
rule allowing incoming connections on port5672
to the file. The new rule must appear before anyINPUT
rules thatREJECT
traffic.-A INPUT -p tcp -m tcp --dport 5672 -j ACCEPT
- Save the changes to the
/etc/sysconfig/iptables
file. - Restart the
iptables
service for the firewall changes to take effect.#
service iptables restart
5672
.