MII Implementation Architecture

Question

Hi,
Due to service maintenance costs for each server deployed, I've been asked to try limit the number of servers used for a multi-site MII roll out.  The MII system requirements are for Operator/Management Production Reports with a view for system integration at a later stage.  The current architecture options on the table are:
1. Local - one instance per production site (Typical and my usual approach)
2. Regional - one instance serving four or five Production Sites within close proximity (50 kms)
3. Central - one instance serving all Production Sites Globally.
While I've successfully been able to convince the necessary parties that option 3 is not an option, I'm finding it difficult to build up a convincing case for option 1 over option 2 (other than this is the official/preferred way - money talks I'm afraid ).
My immediate reluctance for the regional approach is because:
1. Increased communication overhead will impact on performance (esp. if interactive screen)
2. Increased risk of communication failure to source production systems (located on each site).
Point 1 is easy to test and measure, but Point 2 is what I'm having difficulty quanitifying for this evaluation.  This will be a 12.x installation, so the Query Data Buffering will be available (Tag and SQL), but I haven't used it within a production environment extensively so I'm not too sure if it's a recommended route to rely on.  I'm also of the thought that it's better to avoid the problem than "fix" it.  Also, while the buffering is great for an integration/transactional environment, it doesn't help much with regards to an operator screen/report - from the perspective of the operator waiting for data.
Does anyone have any experience/views on the Regional Approach, in particular my concerns on the communication failure, or am I being over paranoid?
Thanks.

Answer 1

Hi, Lawrence.  Here's my view, for what it's worth...
Since you're paying a license for each site anyway, it isn't a "license-based" cost decision - it's largely a question of the cost of administering multiple MII instances/servers and related hardware.  In the 11.X era, this cost was reasonably low.  With 12.X, it has increased a bit with the more frequent need for NW patches and management (or so I've been told by a few customers who I trust greatly).
A few key considerations are performance/responsiveness, availability, and overall application manageability.  As I recall, the networking infrastructure in S.A. can be a challenge in some remote locations, with limited bandwidth ISDN or DSL connections.  If there will be a lot of "trending" views by the users, mostly against data local to their site, you'll be wasting an enormous amount of network bandwidth (and response time) shipping data up to the regional or central server and then all the way back to the user.  Also, there is always the question of availability, and the likelihood of a local server on a local network being down versus a central/regional server with intermittent outages is important to consider.
One of the "hidden features" of MII that offers a good compromise solution is the "Virtual Server" (a special type of connector, not something like VMware).  This approach allows you to have MII systems at each site handling communications to historians/databases, but also regional or central servers that can utilize these data connections remotely.  Customers have benchmarked performance and generally found that accessing a historian from a regional server, for example, is far more efficient and faster if you use a Virtual Server connection to the historian than versus connecting to it directly from the regional server.  The reason is often due to the binary protocol that MII uses being more efficient/lean than the vendors underlying protocols.  Of course, you may find different results, but it is something to consider.
Similarly, you might want to consider application segmentation/partitioning, whereby you could create very ad-hoc "engineering" applications on the local MII server at each site, and do the more "corporate oriented" dashboards, reports, and ERP integration activities on the regional or central servers.  This way you can get the best of both worlds.