MII Implementation Architecture

[lawrence_prinsloo]

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.

[Former Member]

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.

[Former Member]

Hello Lawrence,

Please also note the licensing conditions. To my knowledge, the license fee is per

Site. In this case, you would only save the hardware costs. Please contact your SAP

Sales Account Manager to clarify this topic. My doubts are the same as Christian mention.

The network in this scenario is usually the bottleneck and also consider that MII is not alone

using this network... Please take also in mind that the performance on the MII server will extremly

degress, if for all sites will have the same application (also schedule jobs).

Take also a look into the new [Best Practice|https://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/f08d7ae2-6f56-2c10-50b4-8a3bb1d43502&overridelayout=true]

Hope Christian and my suggestion will help you on your decision.

Regards

Pedro Iglesias

Edited by: Pedro Iglesias on Aug 2, 2009 11:28 PM

[lawrence_prinsloo]

Hi Pedro, Christian,

thanks very much for your feedback. It's good to note that my "gut" feelings are shared by others. I'll follow up with Jeremy and Sam - maybe SAP have dealt with the before and I can use their official response.

One other thing though, I know you can get off the shelf software which monitor's network performance (the way we'd probably measure the difference in performance between a local and regional installation instance), but is it possible to use NetWeaver to do this? My experience with NetWeaver outside of the context of MII is limited, so advice from someone with a better understanding of NetWeaver would be appreciated.

Thanks again.

[Former Member]

Hi Lawrence,

One more peice of information I would say that application Performance matters most to end-users(specially Operators).

So perception of performance begins and ends with response time of the application/server.

Architecture option 2 may create critical performance situations and there will be couple of performance parameters to investigate (network throughput, Disk throughput and CPU utilization, application bug..etc)

Architecture option 1 will give better concurrency, response time & uptime for operator and you can have one Central instance serving all Production Sites Globally for Management Production Reports.

Please do let forum know once you to get the right architecture

Best Regards

Ram Upadhayay

[Former Member]

Regarding the regional strategy and assuming the network is decent ( and that is a big assumption, I have seen sites where their connection to the world is a 54kbps DSL ) I haven't seen any UI/Data performance issues that weren't acceptable. The risk there however is any server and/or network issues bringing down multiple sites and also making your 24/7 scenarios useless in incase of just network failure. If you are just reporting its not a big deal. If your sites are transactionally dependent on your MII implementations for production there could be greater risk.

Regards,

Christian