Category Archives: Jedox Infrastructure

Jedox Migration – Moving from one Server to another

You will find Jedox migration a lot easier than these wilderbeasts' annual journey across the Serengeti

Let’s imagine that we want to do a server upgrade to our current Jedox installation; that is, going from Server A (which is our current Jedox environment) to Server B.

Let’s start with Server B

1. Install everything necessary for Jedox to run (i.e. Java,).

2. Install Jedox (guide).

The beauty of this, is that the installation is a completely new one; so you can even upgrade to the latest version.
Remember to enable the same features that your current Jedox environment has (i.e. Drill Through).
Also, at these point, there’s no need to worry about the Licence yet.

3. Check that Jedox is running, and all of the services are up.

4. Stop Jedox, so we can change some of the configuration files later.

Let’s go to Server A

1. Grab a copy of the following folders:

  • Data folder (including all of the folders inside, specially the System folder).
  • ETL folder
  • Web folder

If you don’t have a backup folder, you will need to stop the services in order to make a copy of these folders.

2. Copy the following lines from palo_config.xml and config.php

<Jedox Installation>\httpd\app\etc\config.php:

<?xml version="1.0" encoding="utf-8"?>
<palo_configuration xmlns="http://www.jedox.com/wss" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <server>
<host>127.0.0.1</host>
<port>7777</port>
  </server>
<secret>sometext</secret>
  <subset_cache size="500" treshold="50" timecheck="1000" disabled="no"/>
</palo_configuration>

<Jedox Installation>\core\palo_config.xml:

// shared secret - needs to be 16 chars long
define('CFG_SECRET', 'sometext');

// palo
define('CFG_PALO_HOST', '127.0.0.1');
define('CFG_PALO_PORT', '7777');
define('CFG_PALO_USER', '_internal_suite');
define('CFG_PALO_PASS', 'some_password');

3. Copy the Data, Web and ETL folders from Server A to Server B (replace what’s necessary) to Server B.

Let’s go back to Server B

1. Change the CFG_SECRET and CFG_PALO_PASS in both palo_config.xml and config.php files to match Server A details.

2. Remember to copy any other files with custom configurations, for examples: sep.inc.php, httpd.conf or any other manually modified (just remember the ones originally changed).

3. Start Jedox.

After that, the Server B will have the same Databases (including all of the cubes), ETL projects and Web Reports. Also, it will carry on the users, groups and roles already setup in Server A, implying that all of the security rules are already in place.

Note: It might be an issue with the Web Reports, which have an internal connection that are unique to every Jedox Installation. In that case, it might be better to export them from Server A and import them to Server B.

Jedox Load Balancing – The Master and the Slave

I had the pleasure the other week of visiting and working closely with the Jedox Team at Dawin Consulting in Seoul, Korea. They are a fantastic group of professionals working hard on their first major Jedox project for a very large Korean company. It is a big project and a team of four consultants are on it full time. 

Their client had the requirement of setting up Load Balancing as well as full Failover for their Jedox Servers. Load Balancing allows the incoming traffic to the Jedox Server to be spread over multiple web servers, which is helpful only when you have a big volume of web users.

The Load Balancing requirement architecture was as follows:

Load_Balancing_Inverted

As per the diagram above, the requirement was that users will be accessing the Jedox system via multiple Web Servers, but actually connecting to the same OLAP Server.

Setting up Jedox to Handle Load Balancing
To do this, you require 2 or more servers in which Jedox you can install Jedox. The Server that will have the active MOLAP server will be referred to as the “Master”. The additional servers that will just have the Web Service running will be called the “Slaves”. In this example, we will assume that we have 2 servers only – a Master and 1 Slave. Also, ensure that either all relevant ports are accessible through the firewalls of each server or just turn the firewall off completely for the purpose of this exercise.

Install Jedox on both Master and Slave Server. Ensure you do a full install on each server. However, as you will probably only have one licence key, install this on the Master server. You will not need a licence key for the Slave server, as the slave servers will not be running the MOLAP server.

Once you have done a full install, you need to tweak some settings on both servers. As the Slave server will only be using its HTTPD Service (ie the web service), you can stop all the other services (ie Core, MOLAP, MDX Interpreter, etc).

NOTE: Before changing any of these files on any servers, ensure you have a backup up all of the original files so you have a roll-back position in case of something going wrong.

Settings to Change on the Slave Server(s)

STEP 1:
in file C:\Program Files\Jedox\Jedox Suite\httpd\conf\httpd.conf , confirm this setting:
ServerName 127.0.0.1:80 (or other port number set during installation)
Should be
ServerName 0.0.0.0:80
STEP 2:
in file C:\Program Files\Jedox\Jedox Suite\httpd\conf\httpd.conf, we will be replacing the 127.0.0.1 to the address of the Master server. Change the following block of code: 


#ProxyPass /ub/ ajp://127.0.0.1:8194/ min=2
ProxyPass /ub/ ajp://127.0.0.1:8194/ retry=0
ProxyPassReverse /ub/ ajp://127.0.0.1:8194/
ProxyPassReverseCookiePath / /ub/

### ETL
Alias /tc/web-etl ../tomcat/webapps/web-etl
ProxyPassMatch /tc/web-etl/app/service/(.*)$ ajp://127.0.0.1:8010/web-etl/app/service/$1
ProxyPass /tc/web-etl !
ProxyPass /tc ajp://127.0.0.1:8010/
ProxyPassReverse /tc ajp://127.0.0.1:8010/
ProxyPassReverseCookiePath / /tc/

### Palo Pivot
ProxyPass /web-palo-ng ajp://127.0.0.1:8010/web-palo-ng
ProxyPassReverse /web-palo-ng ajp://127.0.0.1:8010/web-palo-ng

to


#ProxyPass /ub/ ajp://<address of master molap server>/ min=2
ProxyPass /ub/ ajp://<address of master molap server>:8194/ retry=0
ProxyPassReverse /ub/ ajp://<address of master molap server>:8194/
ProxyPassReverseCookiePath / /ub/

### ETL
Alias /tc/web-etl ../tomcat/webapps/web-etl
ProxyPassMatch /tc/web-etl/app/service/(.*)$ ajp://<address of master molap server>:8010/web-etl/app/service/$1
ProxyPass /tc/web-etl !
ProxyPass /tc ajp://<address of master molap server>:8010/
ProxyPassReverse /tc ajp://<address of master molap server>:8010/
ProxyPassReverseCookiePath / /tc/

### Palo Pivot
ProxyPass /web-palo-ng ajp://<address of master molap server>:8010/web-palo-ng
ProxyPassReverse /web-palo-ng ajp://<address of master molap server>:8010/web-palo-ng

STEP 3:
Open C:\Program Files\Jedox\Jedox Suite\httpd\app\etc\config.php. Change


define('CFG_PALO_HOST', '127.0.0.1');

to


define('CFG_PALO_HOST', <ip of master molap server>);

Settings to Change on the Master Server
OK. So at this point all of your slave servers are now pointing to the Master server for their various components. Now we need to make some changes on the Master server to allow incoming connections from the Slave Servers.

STEP 1:
Open …\core2\ui_backend_config.xml Change


 <tcp address="127.0.0.1" port="8194" />

to


 <tcp address="0.0.0.0" port="8194" />

This allows connections to the core server from outside the master server.

STEP 2:
Go to C:\Program Files\Jedox\Jedox Suite\tomcat\conf\server.xml. To Allow connections to the ETL from outside the master server, change the line


 <Connector port="7775" address="127.0.0.1" connectionTimeout="20000" protocol="HTTP/1.1" redirectPort="7743" />

to


 <Connector port="7775" address="0.0.0.0" connectionTimeout="20000" protocol="HTTP/1.1" redirectPort="7743" />

In the same file, change this line for AJP (for Report Manager, File Manger)


<Connector port="8010" protocol="AJP/1.3" address="127.0.0.1" redirectPort="7743" />

to


<Connector port="8010" protocol="AJP/1.3" address="0.0.0.0" redirectPort="7743" />

Connection Manager
Once this is all in place, you will need to change the Jedox Connections in Connection Manager. Assuming you have the same connection names as per the default install, change the localhost and localhost_static to the Master IP address. You can also use the IP address for the Load Balancer here, which is useful, particularly if you are also implementing a Fail Over regime on top of the Load Balancing. Once all your changes are in place, restart all services on the Master Server, and restart the JedoxSuiteHttpdService on the Slave server(s).

Now go to the IP address of the Slave server in a browser. You will now be using the web service of the Slave server but connecting to the MOLAP server of the Master. Type in the IP of the Master, and you should now be connecting to the Master web server.
Follow the above again for each slave server that you have.

The Load Balancing bit..
Once we completed the configuration, we handed the IP addresses over to the clients IT Department for configuration inside the Load Balancer. There are many load balancing software products out there, but in this case the Windows Server 2012 Network Load Balancing (NLB) was used. The NLB has an IP address of its own, and the IP addresses of the Master and Slave are routed to this address, so the server access is seamless as far as the users are concerned.

Please note that the above changes to the Jedox filesystem comes without warranty and does not guarantee that future changes to the binaries could potentially impact this approach to load balancing.

How Jedox helps IT: An infrastructure overview

This paper answers questions common to IT managers to help understand and support Jedox deployments.

Jedox IT White Paper
How Jedox helps IT: A technical overview

When working with new organisations, I often find business users really champion Jedox because they can see immediately on how it can improve their business process efficiency and save them precious hours in a day.

As part of the procurement process, I sometimes find these business users must articulate technical fundamentals to their IT team. IT may prefer for a single vendor (perhaps a ‘mega’-vendor) and will want to ensure that Jedox, does not require major IT support.

To help this, I recently put together a brief white paper. By and large, I simply combined information from other Jedox  documents into a single overview.

It’s not an official Jedox document, but it may make it easier if you are in IT to help you understand how Jedox fits within your standard operating environment.

Jedox IT White Paper
Download here: How Jedox helps IT: A technical overview

Jedox Server Room