Intouch 10.0 - Galaxy Repository and Application Servers

[BobLfoot 302]

Just sat thru the first of several classes by our Intouch/Wonderware EE Expert. We are in process of moving our version 9.5 Wonderware Applications and HMI's to a Galaxy Repository and Several Application Servers. When all is said and done we'll have the following network topography. 1. A single galaxy repository Server PC 2. Four Application Server Pairs with Automatic Failover - App Servers will gather tag information from PLC's and pass it to HMI Clients - Four pairs coinciding with the four major sections of our facility 3. Several {number to be determined} Terminal Servers for publishing HMI Client apps to thin client terminals 4. Several {number to be determined} HMI Client PCs 5. An INSQL Server logging data from the Application Servers for display by Incuity Trend I'm making this post to see if anyone else is using the Galaxy Repository and Intouch 10.0 on an enterprise scale and facilitate the exchange of first impressions and "gotchas".

[paulengr 44]

Just starting to look into it myself. I'm still trying to decide whether it is better to do all the redundancy stuff with Wonderware or via High Availability Xen virtual servers. Of course the ultimate on the server virtualization approach is Marathon EverRun VM which includes fault tolerance but I'm still debating on whether that level of availability is truly necessary. I'm not impressed with the $12K per IDE development station license. But at least you can thin client that one up too and use RDP to transfer control around the plant as needed. Have you considered a single redundant server station in a hardened location? I'm trying to decide that right now. I can put it in the plant area but the atmosphere is atrocious for PC's (very dusty), which pushes me into a NEMA 4 server rack with all the attendant fans, filters, air conditioners, etc. Of course I could go with a thermoelectric cooling unit (www.melcor.com for instance) which elminates the filter. But still, it is very attractive to put the server stack in an office and instead concentrate my resources on redundant network cabling and switches. I'm definitely thinking about server virtualization for the InSQL server. That gives me plenty of up time on the SQL server. If you go this route, you'll need a pair of SAN's. The ones from cybernetics (MiSAN) are very reasonably priced, very high performance, and don't cost you an arm and a leg. After having already ran a pair of both servers and SAN's, I can definitely say they live up to their name. With 2 gigabit links onto TOE NIC cards (iSCSI TOE) from each SAN, the performance was nothing short of amazing. It absolutely blew away the on-board SATA RAID drives in terms of performance. This was quite a surprise. The point of the test was to measure loss in performance but that's not what happened in practice. And Xen virtualized servers vs. bare hardware installs of Windows performed identical.

[Camel 1]

My company uses it on a large scale. I am still learning about it, and will post more when I do. About the server virtualization thing: When a server dies that has GR node running on it, it tends to start back up with everything undeployed and generally "out of whack". If you use MS virtual server 05, it comes up deployed and running. For us, thats the difference between a normal restart and and hour or more worth of "OMG were down" time. The one hard lesson I have had to learn: Make good and sure you have a sound and stable network infrastructure. If you spend a ton on anything, make sure this is it..... A little side note: Look at the little box that pops up when you deploy something. It has a cancel box, but it greys out when you would normally need to cancel the deploy. Later on down the road, when you deploy a big app and realize you forgot something, you will find it funny (as you wait an hour for the deploy to fail).