ODX Server installed on Dev\TST server

Hi ​@Timmm 

I would usually suggest having the ODX on the prod server. We did a internal BI setup and that is what I suggested then as well.

You run more transfers on production than on development, so it makes sense to have it be on the one closes to the traffic.

To do the switch.

1. Uninstall the ODX on DEV
2. Install the ODX on Prod and run the config
3. Point at the ODX on prod from DEV
4. Point at the ODX on Prod from Prod

You don’t need to change the name of the VM, unless it is called something like DEV and runs Prod.

Hi ​@Thomas Lind ,

Thank you for your response! Below are a few follow-up questions:

1. Wouldn’t it be more practical to install the ODX on the Dev Server environment after the ODX Prod server has been installed?
2. Can I already proceed with this even though an ODX is currently running on the Dev server? I think I could temporarily disable the TimeXtender ODX service on the Production server.

When installing the ODX on the production server, can I simply transfer all data sources manually? Or is there also a way to migrate data sources from ODX Dev to ODX Prod?

Thanks in advance for your answer.

Kind regards,

Tim

​​​​​​

Hi ​@Timmm 

I don’t know if it is more practical, but you can choose to install it wherever you want as long as the environments can connect to it.

The server that hosts the ODX will use memory and processing when running tasks. When it is done from an external server, you will see that this server uses more memory whereas the ODX server is using CPU to run them.

The environments can only connect to one ODX, it is not possible to have one for each environment, they will need to share one.

Regarding moving from one ODX to another, I think it should be mentioned that we do not have ODX in TimeXtender Data Integration (TDI), it is called Ingest Instances. The ODX exists in our legacy program aka v20. You can use the above sections as answers to how it would be done in v20.

So if you meant TDI, then sure, you can set up a Ingest instance for each environment. Then you would use it similar to other environments and move the data source setups from one ingest to another. It is important that the same data sources exists in both instances when you do the migrations.

​@Timmm does Thomas’ comment above help answer your questions? Please let us know if you have any follow up questions

​@Christian Hauggaard  and ​@Thomas Lind , thank you guys for your anwsers!

These anwser were helpfull. 

​@Christian Hauggaard  and ​@Thomas Lind , actually i do have an follow up question:

When i try to configure the ODX on the production server. I get the following message:
 

Does this mean configuring the ODX server on Production is going to copy the project to production?

Am i able to setup datasources when i take over the lock?

And what happens to the other ODX configuration on my dev/test enviroment? 

Hi,

an ODX Server project can only be run by one instance of the ODX Server software. A running and configured ODX Server will therefore lock the project, to prevent other deployments from accidentally taking it over. The config tool will sometimes give you this warning even when on the same machine, so it is good to check the IP to be sure.

If you take over the lock, that instance of the software will take over the running of that project and give you all the functionality.

In 20.10.x you cannot have two different ODX Server instances linked to the same project. There is only one, meaning you need to be careful with changes you apply to avoid disrupting production. I would typically run the ODX Server on production as there should not be developers poking around on the production machine.

If you need separate ingestion setups per environment (dev/test/prod) you would need to use TDI as this allows for multiple Ingests.

​@rory.smith , thank you for your anwser. To summarize it:

• I am not able to configure another ODX on the PROD server in my current TX Version 20.10.45.64?
• If i take over the lock. My ODX server on the dev/test server stops working and the ODX Prod wil take over its function. If so, do all my datasources get copied? Or do i have to configure them again?

Hi ​@Timmm ,

you can configure another wherever you want, but only one can be the active one. So you need to decide which place is best for running the service. This usually depends on resources available and access to systems.

If you take over the lock from your dev/test server and activate it on prod, you keep all the metadata: the ODX Server uses a cloud repository hosted by TimeXtender. Note that your version of TX is rather old and this has repercussions for the ODX. The main thing to focus on is that pre 20.10.53 ODX Server still uses the local backlog system. Before taking over the lock from your dev/test ODX, it is important to be sure the backlog has been synched to the cloud repository (see: https://legacysupport.timextender.com/hc/en-us/articles/360051186931-Release-Notes-for-TimeXtender-20-10-x notes for ‘Fixed in ODX 20.10.53’). I would then shut down the ODX on dev/test using the TX UI and only then finish the configure steps on the prod machine. Your datasource specifications will be there on the new server, no configuration needed. But you need to ensure that any files or folders referred to in data source specifications are available. This means that any CData .rsd files need to be copied to the new server or made available centrally on shares and folder for writing logs exist. Similarly any files you are loading locally from the dev/test machine need to be available to the prod machine.