cancel
Showing results for 
Search instead for 
Did you mean: 

Site consolidation, any tips?

Pioneer
Pioneer

Hei,

 

We have 4 sites (2 US, 1 NL, 1 TW)

NL is the main site.

Main reason to consolidate to 1 site is Global Change management. We do however have many NX users round the globe too.

We are looking into best practices here. So use VDI/Remote desktop or Rich Client (AWC) using Cache and store and forward.

 

All sites have the same configuration and TC version, that should not be a problem.

Formal data is synchronized accross the sites. Design data is not :-)

 

Any experienecs and tips are welcome to join the discussion here!

 

Regards,

Maarten Romers

11 REPLIES

Re: Site consolidation, any tips?

Esteemed Contributor
Esteemed Contributor

The easiest to maintain is VDI, since updating Tc is really cumbersome if you need to migrate multiple sites at once.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community

Re: Site consolidation, any tips?

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

The site consolidation tools are your best friend here, anything that employs low-level tcxml, which includes cvs2tcxml. Jamie Griffis is the current reigning champion with csv2tcxml and provides terrific advice and support to the community. The site consolidation tools require authorization\certification which can only be obtained by attending the Siemens week-long class.

Consolidating to NL is a great choice and having remote FSC's configured for store and forward to support NX is also perfect.

  • You probably want to have a distributed "NX Custom" folder structure, main in NL - synced to remotes (scheduled task or cron) - allowing unique remote content, to maintain corporate standards and files. Benefit is the administration is simpler and nothing special needs to be installed on clients.
  • You can use a similar concept for distributing TC/NX help and other static content via the remote FSC's.
  • You want location specific rich client flavors (differing parent FSC) which point to the remote FSC's (delineated by IP range is best).
  • You may want to add more rich client flavors for Minimum, NX, NX+MSO, MSO and SuperSet[Admin] feature sets.

The client flavors should either be scripted w/TEM as a silent install, configured in OTW (distributed across local and remote FSC's running RMI/Distro services as appropriate), or entirely within Active Workspace (pushes the envelop here).

Avoiding Dispatcher for store and forward volume syncing is less hassle. Use move_volume_files as a scheduled task or cron to maintain better quality control and dependability.

Of course these are not the only strategies you need to consider but do answer the major questions you'll have during the site consolidation. There are a lot more once you step into the weeds.


Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: Site consolidation, any tips?

Siemens Phenom Siemens Phenom
Siemens Phenom

I agree with Randy and have already done all of what he's proposing for the company I work for.

 

I doubly agree with the recommendation to not use the Dispatcher Store and Forward and use a scripted move_volume_files utility instead.  I've tried the S&F, and it was a PITA.  Now I use move_volume_files on a scheduled task, and there have been no problems.


Larry Carpenter, P.E.
CAxPLM Architect @ Siemens Molecular Imaging
Past Board Member @ PLM World, Inc,

Re: Site consolidation, any tips?

Pioneer
Pioneer

Thanks Randy, appreciate your feedback and suggestions, sure will take this!

But what about a first step, how to come to a consolidated database.

 

We maintain our 4 sites (configuration wise) in a well structured way. Configuration is maintained using SVN and all sites are equal with respect to this configuration.

Even users are defined on all sites (still using the "manual" tolling like create_user). Groups also are available on all sites. The only thing we do not maintain is membership in groups.

 

Official parts (with BOM, drawings, etc) are unique globally. because we have a number generator outside TC (in SAP) which makes sure the parts created at each site are unique.

And our NL site is the hub, containing all these offical parts, since scripting at night takes care on replicating and synchronzing this data.

Simple thought could be, just get rid of the export records and you have consolidated most data :-)

 

There is however quite some local design data not being replicated. So this at least must be looked into too.

 

And most important, end user experience. You can cache and store forward the volume data, but working with meta data goes direct to the central database.

We wonder how people experience this, working with structures like MPP or Change Objects.

 

Our US sites are in San Diego and Wilton (CT). latency ~160ms and ~100ms from NL Veldhoven.

 

Would be nice to hear about this.

 

Regards,

Maarten

Re: Site consolidation, any tips?

Siemens Phenom Siemens Phenom
Siemens Phenom

User experience will certainly be impacted if they are currently using better latencies and you make them go to higher latencies. 

 

For example, we have users that have two Teamcenter environments to connect to: one hosted in the US and one hosted in Germany.  The US latency is <1ms for LAN users and ~30-40ms for remote WAN users.  The Germany latency is over 100ms.  The performance difference is VERY noticable to the users.  What might have taken a minute or two in one system takes upwards of 20 minutes in the other.  Yes, it works but the users groan when they have to use the slower one.


Larry Carpenter, P.E.
CAxPLM Architect @ Siemens Molecular Imaging
Past Board Member @ PLM World, Inc,

Re: Site consolidation, any tips?

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom
Our experience paints quite a different picture. Latencies as high as 160ms have barely noticeable performance degradation. Upwards of 340ms do feel pain but at least they work. All of it can be mitigated with either Cisco WAS or Riverbed technologies. The ROI for just Teamcenter is small so use it for the whole network to make the investment worthwhile.

Take the Site Consolidation class and get the token required to use the low-level tcxml tools. You can push all the content to the main site in waves then flip ownership over a weekend. Truly spectacular method for switching over.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: Site consolidation, any tips?

Pioneer
Pioneer

Randy,

 

Can you explain or give examples in what you mean with :

  • You want location specific rich client flavors (differing parent FSC) which point to the remote FSC's (delineated by IP range is best).
  • You may want to add more rich client flavors for Minimum, NX, NX+MSO, MSO and SuperSet[Admin] feature sets.

 

Thanks!

Re: Site consolidation, any tips?

Pioneer
Pioneer

Hei Larry,

 

I assume your reply is related to working with Rich Client and Cache/Store&Forward?

Or is your answer related to VDI/Remote Desktop?

Re: Site consolidation, any tips?

Siemens Phenom Siemens Phenom
Siemens Phenom

Rich Client only.  S&F wasn't part of my point about performance issue regarding latency and user experience since the FCCs are populated in the users computers for best read performance and have local volumes to save their data (for best save performance) that are then forwarded/moved to the final volume later. 

I was mainly referring to the point that users will notice a performance degradation when if they go from a low latency environment to a higher one.  It's a relative issue.  Although 100+ms latencies are considered acceptable by IT folks and any end user that has only ever known 100+ ms latencies, those users that are accustomed to lower latencies will indeed notice the difference when made to use a higher latency.


Larry Carpenter, P.E.
CAxPLM Architect @ Siemens Molecular Imaging
Past Board Member @ PLM World, Inc,