- Zenoss 4.2.3
After Zenoss Resource Manager has been running in your environment and you become familiar with various operating requirements, it might become useful to move the ZenDS Data Store application and database(s) to a dedicated server. The data store and databases can be moved (migrated) to a remote server to conserve resources on the master Zenoss Resource Manager server. These resources include processing (CPU) and data storage resources.
If you have distributed hubs and collectors, log on to each and stop Zenoss:
# service zenoss stop (as root)
$ zenoss stop (as the zenoss user)
On The Master Resource Manager server:
- Stop zenoss:
# service zenoss stop
- Create a mysqldump of databases as the zenoss user. For example, to create a mysqldump of specific databases and save them into the /tmp directory:
# su zenoss $ /opt/zends/bin/mysqldump -u root / --flush-logs --flush-privileges --databases / mysql zenoss_zep zodb zodb_session > /tmp/mysql_dump_file.sql
- Copy the dumpfile to the remote machine, as root.
For example, the following command copies the file to the /tmp directory of the machine with the IP address 10.177.215.212:
# scp mysql_dump_file.sql firstname.lastname@example.org:/tmp
- Stop the data store on the master Resource Manager server and configure it so it does not run at system boot:
# service zends stop # chkconfig --level 2345 zends off
- Become the zenoss user and edit the $ZENHOME/etc/global.conf file:
#su zenoss $ nano $ZENHOME/etc/global.conf
- Change the following values in the file:
- zodb-host - Change the value from "localhost" to the remote server name or IP address
- zodb-port - Verify the value is 13306
- zep-host - Change the value from "localhost" to the remote server name or IP address
- zep-port - Verify the value is 13306
- Save and exit the file.
- Synchronize the global and ZODB configuration files:
$ /opt/zenoss/bin/zenglobalconf -s
On the new ZenDS server:
- Download the Zenoss DataStore RPM file from the https://support.zenoss.com site.
Contact your Zenoss representative for login credentials.
- Install the zends package , for example:
# yum --nogpgcheck localinstall / zends-5.5.31-1.r73360.el5.x86_64.rpm
- Start the zends service and set it to run at system boot:
# service zends start # chkconfig --level 2345 zends on
- Configure the firewall on the new ZenDS server to allow communication with the Zenoss master and with any distributed hubs. Consult the article titled Firewall and Port Requirements for Zenoss 4.2 Deployments for specific port requirements.
For short term testing and configuration purposes, you may wish to stop the firewall services:
# service iptables stop # service ip6tables stop
- Change to the zenoss user:
# su - zenoss
- Restore the database dump as the zenoss user. For example:
$ cd /tmp $ /opt/zends/bin/mysql -u root <mysql_dump_file.sql
Note: This automatically recreates the required databases for zends.
- Invoke the ZenDS client:
$ zends -u root
- Enable remote access to the Zenoss DataStore:
zends> flush privileges;
- Verify the created databases:
zends> SHOW DATABASES;
Your results should be similar to the following:
+--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | | zenoss_zep | | zodb | | zodb_session | +--------------------+ 7 rows in set (0.00 sec)
- Optionally, improve the security of your ZenDS instance by issuing the following command to identify users with no username:
zends> select user, host from mysql.user where user =' ';
The following shows example, partial output from the command:
| user + host |
| zenoss | % |
^^^^^^^^^^^^^^^^^^^^ | zenoss | localhost |
| | MyZenoss.bigco.loc |
| root | MyZenoss.bigco.loc |
- Consult the output to determine any hosts, other than localhost, that show users for whom no username is defined. These users can be identified by a blank value in the user column. In this case there is a user without a username that is authorized for the host MyZenoss.bigco.loc.
Substitute your information in the following command to drop any such users identified. For example to drop the user without a username (blank) authorized for the host MyZenoss.bigco.loc:
zends> drop user ''@'MyZenoss.bigco.loc';
- Flush privileges:
zends> FLUSH PRIVILEGES;
- Exit ZenDS:
On master Resource Manager server:
- Become the zenoss user:
# su zenoss
- Verify you can log in (authenticate) as the zenoss user to the new ZenDS server. For example, where the new ZenDS server resides at the IP 10.177.215.212:
$ mysql -u zenoss -p --host 10.177.215.212 -P 13306
Successful authentication yields the zends> prompt.
- If the authentication test is successful, start zenoss:
$ zenoss start
- After Zenoss starts, update any distributed hubs you are running, using one of the following methods:
- Method 1:
Use the Zenoss Resource Manager GUI to update the hub(s):
- Select Advanced → Collectors
- Click the hubname to display the Overview pane
- Click the Gear icon in the Hub Configuration pane
- Click Update Hub from the drop down list
- Method 2:
Use the command line to update the hub(s) - as the zenoss user, enter the following command:
$ dc-admin --collector-pattern NONE update
Note: This command updates only your hub(s).
- Method 1:
- Start any remote collectors.