Glowing for Techies newsletter - November 2007
Welcome to this, the first issue of Glowing for Techies. The Glow team has decided to introduce this more technically focused version of Glowing which will appeal to people who are involved in deployment of ICT services in Scottish local authorities and other national organisations. It is intended that the newsletter will consist of a number of informative articles to provide more detailed guidance and in-depth information when appropriate. We hope that readers will find the content both helpful and interesting.
Glow
The Glow project has reached a very important stage in its evolution. After two years of development work we have now reached the stage when it is being made available to users across Scotland. The product will first be used in four early adopter local authorities and then the solution will be rolled out to the other 28 local authorities, seven university education faculties, and national bodies including Learning and Teaching Scotland and the Scottish Qualifications Authority during 2008. We do not expect that the user base will go straight to the maximum possible but we do anticipate a gradual and steady increase in numbers.
Firewall final configuration guidance
As Glow is introduced to local authorities and other organisations, it will be necessary to ensure that access to the Glow Datacentre is possible via any firewalls which lie in the data path between it and the end user. Work has been done to provide a guidance document which provides all the port and access list details necessary to facilitate the configurations. Throughout the development period and during each pilot phase a firewall configuration documentation was issued to those participating but these configurations were always based on the principle that all necessary ports should be opened to the entire datacentre IP range. This was done to give RM the flexibility to move some services around in the datacentre IP space. However, now that the development work is complete, it is now possible to specify a service IP range for each application/service and therefore allow firewalls to be configured in the most restricted manner whilst providing full access to the full range of Glow services. The recently published Glow Firewall Configuration document is now available for download at the following address:
PDF file: Glow Firewall Requirements v 2.2 (65 KB)
If any difficulties are encountered in implementing the necessary firewall rules please feel free to contact the Glow Helpdesk for advice.
User Acceptance Test work – summary of progress
In order to confirm that Glow is ready for acceptance and delivery to end users it has been necessary to conduct a wide range of user acceptance tests (UATs) which cover all aspects of the product and its component services.
During the pilot phases, the Glow team devised a number of user activities designed with the UAT process in mind. This ensured that critical functionality was being trialled and tested through the entire development process.
Approximately 350 UATs have been conducted by members of LTS across 14 core services. This work inevitably highlighted one or two failures which had then to be addressed by RM and a retest took place. The UAT team also observed some application behavior which was highlighted and then referred back to RM for remedial action.
We have now arrived at a position where all the UAT work is complete and all UATs have been awarded a pass status. There remain a few non-critical issues that are still being worked on by RM. These will be addressed by the time end users are exposed to the system. This work confirms our confidence that the solution has been delivered according to the contract which was agreed some two years ago. However, we recognise that the only real test of user acceptance will be when the real users access the system and use it all the time.
Glow Meet and existing H.323/H.320 end points
During the early stages of the Glow development it was agreed that any desktop collaboration system that would be implemented should support the capability to interact with existing room-based videoconferencing equipment. Careful consideration was given to this requirement and it was agreed that any communication between Glow Meet and room-based H.323 or H.320 end points would only be possible by connecting via the JANET Video Conferencing Service (JVCS) booking system. This would ensure that the Glow Meet servers would only need to communicate with the JVCS Multi-point Conference Units (MCUs) as opposed to potentially connecting to any and every existing H.323/H.320 end point in existence. This was considered to be most likely to succeed and provide a solution which would be easy to configure and operate.
All of this has been made possible due to an agreement between RM and the owners of the Marratech system (which is known as Glow Meet) to implement an H.323 gateway on the Marratech servers. Although this work was initiated to meet the requirements of Glow, it has also been incorporated into the core Marratech product range.
There are thought to be approximately 350 H.323/H.320 videoconference end points throughout Scotland’s local authorities at present. It is now necessary to have these end points registered and quality assured with the JVCS as by doing this it will be possible to include this existing system into Glow Meet conferences. It is recognised that any communication from an H.323 end point will not be able to make use of the Glow Meet collaborative tools including Shared Whiteboard, cross-platform application sharing etc. It will also be possible to interact with H.323/H320 systems which are used by content providers such as museums and other cultural locations in this way.
Contact Stuart Oliphant to get your H.323/H.320 end points registered with JCVS booking system.
Password distribution policies
As end user accounts are provisioned it will be necessary to inform each user about their Glow user name and initial password. Each user is required to change their password on first access to the Glow single sign-on system. It is recognised that the process of distributing this information will represent a significant task for account security and will be a major task for management staff. The Glow team has given this process careful consideration and has published a document providing some advice which highlights some issues that need to be considered when implementing a user name and password distribution process. This document is available for download at:
PDF file: Glow Password Policy v 2.1 (67 KB)
This is offered as general advice as it is recognised that organisations using Glow may already gave their own procedure for handling this process.
SSDN Interconnect V2
After a procurement exercise which took place in 2003, the original SSDN Interconnect was implemented and commenced service in August 2003. The interconnect was the subject of a contract between the Scottish Executive and UKERNA (now called the Scottish Government and JANET(UK) respectively) and provided a managed high bandwidth connection for each of Scotland’s local authorities and other national bodies. In the original interconnect, there were 37 connections in total which ranged in bandwidth from 45Mbps to 1Gbps. The bandwidth requirements were estimated by building a data model of all the connecting organisations and taking into account differing needs. In local authorities, for example, the fact that each school had at the time a projected bandwidth need of 4 or 8 Mbps (for primary and secondary schools respectively) allowed some assessment to be made about the likely overall bandwidth needs. This allowed a range of target bandwidths to be set down for each connected site, which allowed the procurement of network components to proceed. It is now interesting to review the actual usage of bandwidth during the period since the Interconnect was first started and this is shown in the graphs below.
This graph shows the aggregate traffic levels which left the connected sites between 1 January 2004 and the end of July 2007.
The second graph shows the aggregate traffic levels which entered the connected sites for the same period. The units are M Bytes on the vertical axis and calendar months on the horizontal axis.
It is interesting to note that the trend profiles are consistently upward; we might realistically expect that this trend will continue at the current rate of increase shown or perhaps even accelerate as Glow comes on stream and users start to use its services.
Work to replace the current interconnect has now started and Learning and Teaching Scotland is working with the Scottish Government to take this forward. Although it is still too early to be specific about the likely outcome of a procurement exercise it is possible to confirm the results of a survey that was conducted earlier this year. This work will set down the basic requirements for the technical specification of the new interconnect. The main findings were:
- Additional bandwidth will be needed to meet needs during the next three to five years
- Increased resilience is necessary in view of increasing dependence on the Interconnect service
- Increased flexibility is needed to make increased bandwidth additional circuits easier to provide
- The current JANET planned maintenance time, which is 7–9 am on a Tuesday morning, needs to be reviewed so that it is moved away from core business hours.
It is intended to keep the SSDN Interconnect community fully engaged with the reprocurement process as it progresses and to seek its active involvement at each critical stage.
Content Delivery Network – August 2006 - 10% August 2007 - 39%
The last year has seen a significant upturn in the use of Content Delivery Infrastructure (CDI) in Scottish schools. A recent poll of the CDI Management System showed that 39% of the devices which were procured are now in use and registered with the Content Delivery Manager (CDM).
As well as providing an inline dynamic web caching service the Content Engines (CE) can also be used for pre-positioning content on devices at the edge of the network.
Last year the CDI support team was approached and asked for assistance to overcome some critical performance problems that were being experienced with the Virtual Work Experience project which features the delivery of video content to end users in schools. The project had developed three virtual worlds which could be explored by pupils wanting to know more about the featured professions. The worlds are about NHS Trauma, Hairdressing and Beauty Therapy and a Contact Centre. The worlds are web-based and use a 3D browser plug-in called TurnKey to render the virtual world. The application is hosted and serviced from a web server and LTS hosts the supporting video content on its Video Streaming service, located at its Glasgow office. When the product was trialled in schools if was noted that in some circumstances, particularly when a full class attempted to access the service, the performance was very poor and unworkable.
Using CDI, a content channel was configured to contain all of the VWE videos on the Root content engine which is at the core of the CDI network. CEs in the pilot local authorities and schools were then ‘subscribed’ to the content channel. This had the effect of positioning the video media files on the participating school CEs. This data transfer was done overnight when the school network was not being used for other purposes. As a direct result of this work the Virtual Work Experience application has now been shown to work in schools where previously it failed.
The success of the pilot means that it is very likely that more virtual worlds will be developed in the future. So it has been demonstrated that CDI can help overcome network infrastructure limitations.
Also in some local authorities there were restrictions in place which prevented all access to streamed media. This has been done for good reason, namely to protect the available network bandwidth for other purposes. Using the CDI content pre-positioning feature also overcame these restrictions as the content was being loaded directly from the local CE to the workstation via the school LAN with no firewalls to traverse.