...
Federated architecture best fits customers that execute high load (thousands of transactions per second or more) in their gateways, where the vast majority of the transactions is executed on-premise.
...
- Cell Manager - a DPOD server (virtual or physical) that manages all Federated Cell Members (FCMs) as well as providing central DPOD services such as Web Console, reports, alerts, etc.
- Federated Cell Member (FCM) - a DPOD server (usually physical with very fast local high speed storage) that includes Store data nodes and agents (Syslog and WS-M) for collecting, parsing and storing data. There could be one or more federated cell members per cell.
...
- DPOD cell manager and federated cell members must be with the same version (minimum version is v11.0.8.5).
- DPOD cell manager can be installed in both Appliance Mode or Non-Appliance Mode with Medium Load architecture type, as detailed in the Hardware and Software Requirements. The manager server can be both virtual or physical.
- Physical DPOD federated cell member (FCM) must be installed in Non-appliance Mode with High_20dv architecture type, as detailed in the Hardware and Software Requirements.
- Virtual DPOD federated cell member (FCM) must be installed in Non-appliance Mode with Medium architecture type or higher, as detailed in the Hardware and Software Requirements and in Virtual Cell Environment Installation.
- All DPOD federated cell member (FCM) must have the exactly the same resources such as CPUs, RAM, disk type and storage capacity.
- Each cell component (manager / FCM) should have two network interfaces:
- External interface - for DPOD users to access the Web Console (on the cell manager) and for communication between DPOD and Monitored Gateways (on both the cell manager and the members).
- Internal interface - for internal DPOD components inter-communication (should be a 10Gb Ethernet interface).
- Network ports should be opened in the network firewall as detailed below:
...
Install DPOD as described in one of the following installation procedures:
- For Appliance Mode:
- Follow the procedure: Appliance Installation
- In this mode, during the During installation the user is prompted to choose the data disk type (SSD / non SSD). Choose the cell members disk type (should be SSD) instead of the cell manager disk type.
- For Non-appliance Mode:
- Follow the procedure: Non-Appliance Installation
- As described in the prerequisites section, During installation, since the cell manager should have has two network interfaces .
In this mode(see prerequisites section), the user is prompted to choose the IP address for the Web Console. Choose the IP address of the external network interface.
...
After DPOD installation is complete, the user should execute the following operating system performance optimization script and reboot the server:
| Code Block | ||||
|---|---|---|---|---|
| ||||
/app/scripts/tune-os-parameters.sh
reboot |
Federated Cell Member Installation
The following section describes the installation process of a single Federated Cell Member (FCM). User should Please repeat the procedure for every FCM installation.
...
DPOD Installation
- Use Non-appliance Mode and follow the procedure: Non-Appliance Installation
This installation (before the federation process is executed later) is similar to a standard All-In-One standalone DPOD installation.
In order for this installation to complete successfully, all prerequisites for DPOD installation should be met as described in the installation procedure, including the 3 disk drives requirement. - As described in the prerequisites section, the cell member should have two network interfaces.
During the installation During installation, since the cell manager has two network interfaces (see prerequisites section), the user is prompted to choose the IP address for the Web Console. Choose the IP address of the external network interface (although the FCM does not run the Web Console service).. - The four-letter Installation Environment Name should be identical to the one that was chosen during the Cell Manager installation.
...
After DPOD installation is complete, the user should execute the following operating system performance optimization script and reboot the server:
| Code Block | ||||
|---|---|---|---|---|
| ||||
/app/scripts/tune-os-parameters.sh |
| Note |
|---|
Reboot the server for the new performance optimization to take effect. |
Preparing the Cell Member for Federation
...
reboot |
Configuring Mount Points of Cell Member before Federation
The cell member is usually a " bare metal " server with NVMe disks for maximizing server I/O throughput.
Each of the Store's logical node nodes (service) will be bound to a specific physical processor, disks and memory using NUMA (Non-Uniform Memory Access) technology.
The default cell member configuration assumes 6 NVMe disks which will serve 3 Store logical nodes (2 disks per node).
The following
Required information
The following table contains the list of OS mount points that should be configured by the user along with additional information that must be gathered before federating the DPOD cell member to the cell environment.
| Note |
|---|
We highly recommend the use of LVM (Logical Volume Manager) to allow flexible storage for future storage needs. |
Empty cells in the following table should be completed by the user, based on their specific hardwarePlease copy this table, use it during the procedure, and complete the information in the empty cells as you follow the procedure:
| Store Node | Mount Point Path | Disk Bay |
|---|
| Disk Serial | Disk OS Path | PCI Slot Number | NUMA |
|---|
| Node (CPU #) | ||||||
|---|---|---|---|---|---|---|
| 2 | /data2 | |||||
| 2 | /data22 | |||||
| 2 * | /data222 | |||||
| 3 | /data3 | |||||
| 3 | /data33 | |||||
| 3 * | /data333 | |||||
| 4 | /data4 | |||||
| 4 | /data44 |
How to Identify Disk OS Path and Disk Serial
...
| 4 * | /data444 |
* Lines marked with asterisk (*) are relevant only in case DPOD sizing team recommends 9 disks instead of 6 disks per cell member. You may remove these lines in case you have only 6 disks per cell member.
Identifying disk bays and disk serial numbers
To identify which of the server's NVMe disk bays is bound to which of the CPUs, use the hardware manufacture documentation.
...
Write down the disk bay as well as the disk's serial number by visually observing the disk.
...
Identifying disk OS paths
To list the OS path of each disk, execute the following command and write down the disk OS path (e.g.: /dev/
...
Identify all NVMe Disks installed on the server
...
nvme0n1) according to the disk's serial number (e.g.: PHLE8XXXXXXC3P2EGN):
| Code Block | ||||
|---|---|---|---|---|
|
...
nvme - |
...
list |
...
Expected |
...
output: |
...
Node |
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
SN |
...
|
...
|
...
|
...
Locate disk's NUMA node
Use the disk PCI slot listed in previous command to identify the NUMA node (the first disk PCI slot is : 5d:00.0 )
...
| theme | RDark |
|---|---|
| linenumbers | true |
...
Model Namespace Usage Format FW Rev ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- -------- /dev/nvme0n1 PHLE8XXXXXXC3P2EGN SSDPE2KE032T7L |
...
|
...
|
...
|
...
|
...
1 |
...
|
...
|
...
...
|
...
|
...
|
...
|
...
3.20 |
...
TB |
...
/ 3.20 TB |
...
|
...
|
...
|
...
512 B + 0 B QDV1LV46 |
...
/dev/nvme1n1 |
...
|
...
|
...
|
...
PHLE8XXXXXXM3P2EGN SSDPE2KE032T7L |
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
1 |
...
3.20 TB / 3.20 TB |
...
|
...
512 B + 0 B QDV1LV46 /dev/nvme2n1 |
...
|
...
|
...
PHLE8XXXXXX83P2EGN |
...
|
...
SSDPE2KE032T7L |
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
1 |
...
|
...
|
...
3.20 TB / 3.20 TB |
...
|
...
|
...
|
...
512 |
...
B + 0 B |
...
QDV1LV46 /dev/nvme3n1 PHLE8XXXXXXN3P2EGN SSDPE2KE032T7L |
...
|
...
|
...
|
...
|
...
|
...
|
...
1 3.20 TB |
...
/ |
...
3.20 |
...
TB |
...
|
...
512 |
...
B |
...
Identify NVMe Disks path
Use the disk PCI slot listed in previous command to identify the disk's block device path
| Code Block | ||
|---|---|---|
| ||
ls -la /sys/dev/block |grep 5d:00.0
expected output :
lrwxrwxrwx. 1 root root 0 Nov 5 08:06 259:4 -> ../../devices/pci0000:58/0000:58:00.0/0000:59:00.0/0000:5a:02.0/0000:5d:00.0/nvme/nvme0/nvme0n1 |
...
| theme | RDark |
|---|
...
+ 0 B QDV1LV46 /dev/nvme4n1 PHLE8XXXXXX63P2EGN SSDPE2KE032T7L 1 3.20 TB / 3.20 TB 512 B + 0 B QDV1LV46 /dev/nvme5n1 PHLE8XXXXXXJ3P2EGN SSDPE2KE032T7L 1 |
...
3.20 |
...
TB / |
...
3.20 TB |
...
...
512 B + |
...
0 B |
...
- Use the disk bay number and the disk serial number (visually identified) and correlate them with the output of the disk tool to identify the disk OS path.
Example for Mount Points and Disk Configurations
...
Example for LVM Configuration
| Code Block | ||
|---|---|---|
| ||
pvcreate -ff /dev/nvme0n1
vgcreate vg_data2 /dev/nvme0n1
lvcreate -l 100%FREE -n lv_data vg_data2
mkfs.xfs -f /dev/vg_data2/lv_data
pvcreate -ff /dev/nvme1n1
vgcreate vg_data22 /dev/nvme1n1
lvcreate -l 100%FREE -n lv_data vg_data22
mkfs.xfs /dev/vg_data22/lv_data |
/etc/fstab file:
| Code Block | ||
|---|---|---|
| ||
/dev/vg_data2/lv_data /data2 xfs defaults 0 0
/dev/vg_data22/lv_data /data22 xfs defaults 0 0
/dev/vg_data3/lv_data /data3 xfs defaults 0 0
/dev/vg_data33/lv_data /data33 xfs defaults 0 0
/dev/vg_data4/lv_data /data4 xfs defaults 0 0
/dev/vg_data44/lv_data /data44 xfs defaults 0 0 |
Create directories for the new data mount points
| Code Block | ||
|---|---|---|
| ||
mkdir -p /data2 /data22 /data3 /data33 /data4 /data44 |
Example for the Final Configuration for 3 Store's nodes
| Note |
|---|
This example does not include other mount points needed, as describe in Hardware and Software Requirements. |
| Code Block | ||
|---|---|---|
| ||
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 2.9T 0 disk
└─vg_data2-lv_data 253:6 0 2.9T 0 lvm /data2
nvme1n1 259:5 0 2.9T 0 disk
└─vg_data22-lv_data 253:3 0 2.9T 0 lvm /data22
nvme2n1 259:1 0 2.9T 0 disk
└─vg_data3-lv_data 253:2 0 2.9T 0 lvm /data3
nvme3n1 259:2 0 2.9T 0 disk
└─vg_data33-lv_data 253:5 0 2.9T 0 lvm /data33
nvme4n1 259:4 0 2.9T 0 disk
└─vg_data44-lv_data 253:7 0 2.9T 0 lvm /data44
nvme5n1 259:3 0 2.9T 0 disk
└─vg_data4-lv_data 253:8 0 2.9T 0 lvm /data4 |
Install NUMA Software
| Code Block | ||
|---|---|---|
| ||
yum install numactl |
Preparing Local OS Based Firewall
Most Linux-based OS uses a local firewall service (e.g.: iptables / firewalld).
Since the OS of the Non-Appliance Mode DPOD installation is provided by the user, it is under the user's responsibility to allow needed connectivity to and from the server.
User should make sure needed connectivity detailed in Network Ports Table is allowed on the OS local firewall service.
| Note |
|---|
When using DPOD Appliance mode installation for the cell manager, local OS based firewall service is handled by the cell member federation script. |
Cell Member Federation
In order to federate and configure the cell member, run the following script in the cell manager once per cell member.
For instance, to federate two cell members, the script should be run twice (in the cell manager) - first time with the IP address of the first cell member, and second time with the IP address of the second cell member.
Important: The script should be executed using the OS root user.
| Code Block | ||
|---|---|---|
| ||
/app/scripts/configure_cell_manager.sh -a <internal IP address of the cell member> -g <external IP address of the cell member>
For example: /app/scripts/configure_cell_manager.sh -a 172.18.100.34 -g 172.17.100.33 |
Example for a Successful Execution
| Code Block | ||
|---|---|---|
| ||
/app/scripts/configure_cell_manager.sh -a 172.18.100.36 -g 172.17.100.35
2018-10-22_16-13-16 INFO Cell Configuration
2018-10-22_16-13-16 INFO ===============================
2018-10-22_16-13-18 INFO
2018-10-22_16-13-18 INFO Log file is : /installs/logs/cell_manager_configuration-2018-10-22_16-13-16.log
2018-10-22_16-13-18 INFO
2018-10-22_16-13-18 INFO Adding new cell member with the following configuration :
2018-10-22_16-13-18 INFO Cell member internal address 172.18.100.36
2018-10-22_16-13-18 INFO Cell member external address 172.17.100.35
2018-10-22_16-13-18 INFO Syslog agents using TCP ports starting with 60000
2018-10-22_16-13-18 INFO Wsm agents using TCP ports starting with 60020
2018-10-22_16-13-18 INFO
2018-10-22_16-13-18 INFO During the configuration process the system will be shut down, which means that new data will not be collected and the Web Console will be unavailable for users.
2018-10-22_16-13-18 INFO Please make sure the required network connectivity (e.g. firewall rules) is available between all cell components (manager and members) according to the documentation.
2018-10-22_16-13-18 INFO
2018-10-22_16-13-20 INFO Please choose the IP address for the cell manager server internal address followed by [ENTER]:
2018-10-22_16-13-20 INFO 1.) 172.18.100.32
2018-10-22_16-13-20 INFO 2.) 172.17.100.31
1
2018-10-22_16-14-30 INFO Stopping application ...
2018-10-22_16-15-16 INFO Application stopped successfully.
root@172.18.100.36's password:
2018-10-22_16-21-41 INFO Cell member configuration ended successfully.
2018-10-22_16-21-45 INFO Stopping application ...
2018-10-22_16-22-31 INFO Application stopped successfully.
2018-10-22_16-22-31 INFO Starting application ...
|
Note that the script writes two log file, one in the cell manager and one in the cell member. The log file names are mentioned in the script's output.
Example for a Failed Execution
| Code Block | ||
|---|---|---|
| ||
/app/scripts/configure_cell_manager.sh -a 172.18.100.36 -g 172.17.100.35
2018-10-22_16-05-03 INFO Cell Configuration
2018-10-22_16-05-03 INFO ===============================
2018-10-22_16-05-05 INFO
2018-10-22_16-05-05 INFO Log file is : /installs/logs/cell_manager_configuration-2018-10-22_16-05-03.log
2018-10-22_16-05-05 INFO
2018-10-22_16-05-05 INFO Adding new cell member with the following configuration :
2018-10-22_16-05-05 INFO Cell member internal address 172.18.100.36
2018-10-22_16-05-05 INFO Cell member external address 172.17.100.35
2018-10-22_16-05-05 INFO Syslog agents using TCP ports starting with 60000
2018-10-22_16-05-05 INFO Wsm agents using TCP ports starting with 60020
2018-10-22_16-05-05 INFO
2018-10-22_16-05-05 INFO During the configuration process the system will be shut down, which means that new data will not be collected and the Web Console will be unavailable for users.
2018-10-22_16-05-05 INFO Please make sure the required network connectivity (e.g. firewall rules) is available between all cell components (manager and members) according to the documentation.
2018-10-22_16-05-05 INFO
2018-10-22_16-05-06 INFO Please choose the IP address for the cell manager server internal address followed by [ENTER]:
2018-10-22_16-05-06 INFO 1.) 172.18.100.32
2018-10-22_16-05-06 INFO 2.) 172.17.100.31
1
2018-10-22_16-05-09 INFO Stopping application ...
2018-10-22_16-05-58 INFO Application stopped successfully.
root@172.18.100.36's password:
2018-10-22_16-06-46 ERROR Starting rollback
2018-10-22_16-06-49 WARN Issues found that may need attention !!
2018-10-22_16-06-49 INFO Stopping application ...
2018-10-22_16-07-36 INFO Application stopped successfully.
2018-10-22_16-07-36 INFO Starting application ... |
In case of a failure, the script will try to rollback the configuration changes it made, so the problem can be fixed before rerunning it again.
Cell Member Federation Post Steps
NUMA configuration
DPOD cell member is using NUMA (Non-Uniform Memory Access) technology. The default cell member configuration binds DPOD's agent to CPU 0 and the Store's nodes to CPU 1.
If the server has 4 CPUs, the user should edit the service files of nodes 2 and 3 and change the bind CPU to 2 and 3 respectively.
Identifying NUMA Configuration
To identify the amount of CPUs installed on the server, use the NUMA utility:
| Code Block | ||
|---|---|---|
| ||
numactl -s Example output for 4 CPU server : policy: default preferred node: current physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12QDV1LV46 |
Identifying PCI slot numbers
To list the the PCI slot for each disk OS path, execute the following command and write down the PCI slot (e.g.: 0c:00.0) according to the last part of the disk OS path (e.g.: nvme0n1):
| Code Block | ||||
|---|---|---|---|---|
| ||||
lspci -nn | grep NVM | awk '{print $1}' | xargs -Innn bash -c "printf 'PCI Slot: nnn '; ls -la /sys/dev/block | grep nnn"
Expected output:
PCI Slot: 0c:00.0 lrwxrwxrwx. 1 root root 0 May 16 10:26 259:2 -> ../../devices/pci0000:07/0000:07:00.0/0000:08:00.0/0000:09:02.0/0000:0c:00.0/nvme/nvme0/nvme0n1
PCI Slot: 0d:00.0 lrwxrwxrwx. 1 root root 0 May 16 10:26 259:5 -> ../../devices/pci0000:07/0000:07:00.0/0000:08:00.0/0000:09:03.0/0000:0d:00.0/nvme/nvme1/nvme1n1
PCI Slot: ad:00.0 lrwxrwxrwx. 1 root root 0 May 16 10:26 259:1 -> ../../devices/pci0000:ac/0000:ac:02.0/0000:ad:00.0/nvme/nvme2/nvme2n1
PCI Slot: ae:00.0 lrwxrwxrwx. 1 root root 0 May 16 10:26 259:0 -> ../../devices/pci0000:ac/0000:ac:03.0/0000:ae:00.0/nvme/nvme3/nvme3n1
PCI Slot: c5:00.0 lrwxrwxrwx. 1 root root 0 May 16 10:26 259:3 -> ../../devices/pci0000:c4/0000:c4:02.0/0000:c5:00.0/nvme/nvme4/nvme4n1
PCI Slot: c6:00.0 lrwxrwxrwx. 1 root root 0 May 16 10:26 259:4 -> ../../devices/pci0000:c4/0000:c4:03.0/0000:c6:00.0/nvme/nvme5/nvme5n1
Tip: you may execute the following command to list the details of all PCI slots with NVMe disks installed in the server:
lspci -nn | grep -i nvme | awk '{print $1}' | xargs -Innn lspci -v -s nnn
Tip: you may execute the following command to list all disk OS paths in the server:
ls -la /sys/dev/block |
Identifying NUMA nodes
To list the NUMA node of each PCI slot, execute the following command and write down the NUMA node (e.g.: 1) according to the PCI slot (e.g.: 0c:00.0):
| Code Block | ||||
|---|---|---|---|---|
| ||||
lspci -nn | grep -i nvme | awk '{print $1}' | xargs -Innn bash -c "printf 'PCI Slot: nnn'; lspci -v -s nnn | grep NUMA"
Expected output:
PCI Slot: 0c:00.0 Flags: bus master, fast devsel, latency 0, IRQ 45, NUMA node 1
PCI Slot: 0d:00.0 Flags: bus master, fast devsel, latency 0, IRQ 52, NUMA node 1
PCI Slot: ad:00.0 Flags: bus master, fast devsel, latency 0, IRQ 47, NUMA node 2
PCI Slot: ae:00.0 Flags: bus master, fast devsel, latency 0, IRQ 49, NUMA node 2
PCI Slot: c5:00.0 Flags: bus master, fast devsel, latency 0, IRQ 51, NUMA node 3
PCI Slot: c6:00.0 Flags: bus master, fast devsel, latency 0, IRQ 55, NUMA node 3 |
Example of required information
This is an example of how a row of the table should look like:
| Store Node | Mount Point Path | Disk Bay | Disk Serial | Disk OS Path | PCI Slot Number | NUMA node (CPU #) |
|---|---|---|---|---|---|---|
| 2 | /data2 | Bay 1 | PHLE8XXXXXXC3P2EGN | /dev/nvme0n1 | 0c:00.0 | 1 |
Verifying NVMe disks speed
Execute the following command and verify all NVMe disks have the same speed (e.g.: 8GT/s):
| Code Block | ||||
|---|---|---|---|---|
| ||||
lspci -nn | grep -i nvme | awk '{print $1}' | xargs -Innn bash -c "printf 'PCI Slot: nnn'; lspci -vvv -s nnn | grep LnkSta:"
Expected output:
PCI Slot: 0c:00.0 LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
PCI Slot: 0d:00.0 LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
PCI Slot: ad:00.0 LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
PCI Slot: ae:00.0 LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
PCI Slot: c5:00.0 LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
PCI Slot: c6:00.0 LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- |
Configuring mount points
Configure the mount points according to the table with all gathered information.
It is highly recommended to use LVM (Logical Volume Manager) to allow flexibility for future storage needs.
The following example uses LVM. You may use it for each mount point (replace vg_data2 with vg_data22/vg_data222/vg_data3 etc.):
| Code Block | ||||
|---|---|---|---|---|
| ||||
pvcreate -ff /dev/nvme0n1
vgcreate vg_data2 /dev/nvme0n1
lvcreate -l 100%FREE -n lv_data vg_data2
mkfs.xfs -f /dev/vg_data2/lv_data |
The following example is the line that should be added to /etc/fstab for each mount point (replace vg_data2 and /data2 with the appropriate values from the table):
| Code Block | ||||
|---|---|---|---|---|
| ||||
/dev/vg_data2/lv_data /data2 xfs defaults 0 0
|
Create a directory for each mount point (replace /data2 with the appropriate values from the table):
| Code Block | ||||
|---|---|---|---|---|
| ||||
mkdir -p /data2 |
Inspecting final configuration
| Note |
|---|
This example is for 6 disks per cell member and does not include other mount points that should exist, as describe in Hardware and Software Requirements. |
Execute the following command and verify mount points:
| Code Block | ||||
|---|---|---|---|---|
| ||||
lsblk
Expected output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:2 0 2.9T 0 disk
└─vg_data2-lv_data 253:0 0 2.9T 0 lvm /data2
nvme1n1 259:5 0 2.9T 0 disk
└─vg_data22-lv_data 253:11 0 2.9T 0 lvm /data22
nvme2n1 259:1 0 2.9T 0 disk
└─vg_data3-lv_data 253:9 0 2.9T 0 lvm /data3
nvme3n1 259:0 0 2.9T 0 disk
└─vg_data33-lv_data 253:10 0 2.9T 0 lvm /data33
nvme4n1 259:3 0 2.9T 0 disk
└─vg_data44-lv_data 253:8 0 2.9T 0 lvm /data44
nvme5n1 259:4 0 2.9T 0 disk
└─vg_data4-lv_data 253:7 0 2.9T 0 lvm /data4 |
OS Configuration of Cell Member before Federation
Installing NUMA software
Execute the following command:
| Code Block | ||||
|---|---|---|---|---|
| ||||
yum install numactl |
Configuring local OS based firewall
Most Linux-based OS use a local firewall service (e.g.: iptables / firewalld). Since the OS of the Non-Appliance Mode DPOD installation is provided by the user, it is under the user's responsibility to allow needed connectivity to and from the server.
Configure the local firewall service to allow connectivity as described in the prerequisites section at the top of this page.
| Note |
|---|
When using DPOD Appliance mode installation for the cell manager, local OS based firewall service configuration is handled by the cell member federation script. When using DPOD Non-Appliance mode installation for the cell manager, local OS based firewall service configuration should be done by the user in addition to configuring the local OS based firewall service configuration of the cell memeber. |
Cell Member Federation
In order to federate and configure the cell member, run the following script in the cell manager once per cell member.
For instance, to federate two cell members, the script should be run twice (in the cell manager) - first time with the IP address of the first cell member, and second time with the IP address of the second cell member.
Important: The script should be executed using the OS root user.
| Code Block | ||||
|---|---|---|---|---|
| ||||
/app/scripts/configure_cell_manager.sh -a <internal IP address of the cell member> -g <external IP address of the cell member>
For example: /app/scripts/configure_cell_manager.sh -a 172.18.100.34 -g 172.17.100.33 |
Note that the script writes two log files, one in the cell manager and one in the cell member. The log file names are mentioned in the script's output.
In case of a failure, the script will try to rollback the configuration changes it made, so the problem can be fixed before rerunning it again.
Cell Member Federation Post Steps
DPOD cell member is using NUMA (Non-Uniform Memory Access) technology.
The default cell member configuration binds DPOD's agent to NUMA node 0 and the Store's nodes to NUMA node 1.
If the server has 4 CPUs, the user should update the service files of nodes 2 and 3 and change the bound NUMA nodes to 2 and 3 respectively.
Identifying CPU amount
To identify the amount of CPUs installed on the server, use the NUMA utility:
| Code Block | ||||
|---|---|---|---|---|
| ||||
numactl -s Expected output: policy: default preferred node: current physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 cpubind: 0 1 2 3 nodebind: 0 1 2 3 membind: 0 1 2 3 |
Alter Store's Node 2 and 3 (OPTIONAL - only if the server has 4 CPUs)
The services files are located on the directory /etc/init.d/ with the name MonTier-es-raw-trans-Node-2 and MonTier-es-raw-trans-Node-3.
|
Updating service files for 4-CPU cell members
Note: In case the cell member has only 2 CPUs - skip this step.
To update the service files, execute the following command:
| Code Block | ||||
|---|---|---|---|---|
| ||||
For node MonTier-es-raw-trans-Node-2 OLD VALUE : numa="sed 's#/usr/bin/numactl --membind=1 --cpunodebind=1" NEW VALUE : numa="1#/usr/bin/numactl --membind=2 --cpunodebind=2" For node 2#g' /etc/init.d/MonTier-es-raw-trans-Node-32 OLD VALUE : numa="sed 's#/usr/bin/numactl --membind=1 --cpunodebind=1" NEW VALUE : numa="1#/usr/bin/numactl --membind=3 --cpunodebind=3#g' /etc/init.d/MonTier-es-raw-trans-Node-cpunodebind=3" |
Cell Member Federation Verification
After a successful executionfederation, you will be able to see the new federated cell member in the Manage → System → Nodes page.
For example, after federating cell member the page should look as follows:
Also, the new agents will be shown in the agents list in the Manage → Internal Health → Agents page.
For example, if the cell manager has two agents and there is a federated cell member with additional four agents, the page will show six agents:
Configure the Monitored
...
Gateways to Use the Federated Cell Member Agents
It is possible to configure entire monitored device or just a specific domain to the federated cell member's agents.
To configure monitored device / specific domain please Configure the monitored gateways to use the federated cells agents. Please follow instructions on Adding Monitored Devices.
...