Meeting Notes 2013-12-17

Update from Andy and Dougie on 18-Dec-13

• Appleton Tower, where the second application server will be passive unless required
• Project to be costed with 3 servers
• DR will be done on the LIVE environment right before the upgrade is LIVE (so pseudo LIVE)

Meeting 17-Dec-13

Attendees Andy, Mark D and Anne (cc David Mc)

• After discussion with Dougie Williams, Andy clarified by confirming that EST076 is not a mission critical project.
• To complete failover it would require manual intervention. This project will have an overall priority of 3, which means that the 'Veam' process is not an option for us to consider and is out of scope. As in a disaster we would be lower down the priorities for getting the system back up and running..
• Load Balancing will be considered to ease failover to secondary site if required.  It should be noted that the project is not considering load balacing the application across multiple application servers.
• Encryption - requirement to confirm with Brian that Internet Information Services (IIS) can be configured to encrypt passwords
• Co-Sign will not be considered as Brian would have to change Meterology to make this work, so it is out of scope

Conclusions and Recommendation to clarify with Dougie.

1. No automatic failover to 2nd site, as this will require manual intervention
2. Best option is to have 2 servers in LIVE where any changes will be required to be manually mirrored at both sites. Where we are running it  on more than 1 server, there will be licensing product costs involved. (Currently licensed for use on one desktop and the sensors).
3. It is thought that METERology can do encryption via IIS (Internet Information Sevices)  to make logins encrypted.
4. Initially our thoughts indicate that the design would be as above, however when the Technical Architecture Document (TAD) is complete - the final decision will be concluded in there.
5. Initial costs indicate 3 servers being required..

Options

1. Run on a single site. In the event of Disaster Recovery (DR) there could be considerable down time of loss of service, as there would be the need to commission a server and restore from back up.
2. Run with two application servers (one active, one passive). This should allow for quicker fallback.

Email on Andy and Dougie's discussion 16-Dec-13

Just had a conversation with Dougie Williams  this morning regarding the feedback from Brian Hunter and have attached the notes below. 

1) We were thinking about the resilience of the system in the event that we lose our primary data centre. Is it possible to run the application / web end on more than one server in a live environment? As I understand the system, the application / web server has a windows service installed to get the data from the meter devices and to push that data to the database. If the windows service wouldn't cope well with running on multiple servers would it be possible to run just the web side of it on multiple machines which we could then load balance to provide resilience in the event of a site loss?

 *** There is certainly no need for the system to be load balanced *** With regards failover requirements it would be helpful to establish the following            (i) If there is a second application server sitting in a passive state at AT, would failover be automatic, and if not what would the process / procedures be involved and roughly how long would it take           (ii) If there is no second application server sitting at AT, is there any other option, e.g. Requirement to commission a virtual server, restore a backup of the KB application server, and again thoughts on the feasibility of this option and how long it might take.

 The answers to the above questions will clarify Dougie's requirements going forward

 2) I didn't get a chance to ask about the permissions / logins for the system at the time. Is it possible to give different users different levels of permissions? *** As I understand, the admin user has access to all system maintenance activity and that there is not the option to limit functionality to specific users

3) We use some software called Cosign to protect web pages within the university from unauthorised access as a single sign-on system. Would it be possible to fit this into the Meterology software? For example, Cosign would prevent / allow access to given web pages within the Meterology website provided we could make Meterology trust the information it has been given by Cosign. *** further information regarding this is required from Dev Tech to understand the impact

Co-Sign is out of scope for this project as it would require software changes to be applied to Meterology. This will require individual admin users to log into the system each time  

 4) I appreciate that you said that you can run the software on a limited resource system (such as an average laptop) but could you give a minimum / recommended specification for a server? RAM / Number of cores / disk space. I know it was mentioned in the meeting about the current system using about 500 megs for the DB, 500 megs for the logs and about 100 megs for config / web files. *** Assume that this is ok

Yes this is ok

 5) We would want to run the web site with SSL if users are required to enter data and particularly passwords. Would that cause any problems for the application? *** again, I think we need further details from Dev Tech

This should be fine - agree with Dev Tech and Brian

 I wonder if it might be pertinent to get some more feedback from Dev Tech, prepare a quick summary to the above points and arrange a quick conference call between yourself, Dougie, Mark and Brian.

In addition, Dougie has confirmed that he is the senior business user for this project