Port Opening for Learning Platforms

[ctbjs]

This is just a general enquiry to schools that have bought learning platforms. I am keen to find out whether any of you have had an resistance from your LA with regard to opening ports for your VLE. I ask because ours has told one of our schools who ae using the frog vle that they will not open the ports for them because they will be provided with a vle by the LA.

Now Tony mentions in a post I made some time back that we should work with our LAs and while I agree the working with should, in my opinion work both ways. I realise that LAs have been given funding under 121a to invest in a solution for the Authority but it would appear that not all schools want to use the same solution for one reason or another and this denial of port opening to this school in particular seems pretty obstructive to me. We have purchased the MLG and will be doing the same shortly and worry that the same will apply when I make my request. Accordng to their network manager once he had requested the port openings the LA were on the phone to their head insisting that they do not pay money for the vle and that the ports would not be made available.

I know the MLG is not listed on the becta top ten but in my view and recent activity with platforms such as rm and frog jumping into bed with sharepoint makes me believe that this is the way forward. Indeed the Dfes brochure on the subject shows schools that use MLG as their exemplars!!

Just to add to this further, we had a meeting a short while back at which all 10 of the becta approved providers demonstrated their platforms and none were anything special. Finally, we are looking to move forward and start things moving so that we have something in place for 2008, the LA have not yet decided which platform they are going to force upon us!!

[Geoff]

We have to go through our LEA network for everything. There is no direct internet access possible and our contract with them prevents us from installing another line from another ISP to provide this.

For web services (like your VLE example) our LEA provides a reverse proxy. This functions adequately. However, it's yet another performance bottleneck and single point of failure.

Other systems are affected in a similar way. For example the LEA email systems are currently struggling to meet demands. Resulting in a 10 - 30min delay in email delivery during busy periods. Because I have to route my SMTP traffic via the LEA's primary MX our mail is equally effected. If they just allowed the school primary MX to talk directly on the internet we'd avoid the delays and reduce the load on the central mail system.

[NewOrder]

You are right about the exemplar schools. They developed their gateways with out LEA interference and BECTA. Shireland has been running its Gateway for 3 years. It host about 60 schools in a data centre. A lot of servers. It even has Sims webparts working for some of its hosted schools.

Shirelands LEA decided not to develop its own but to recommend to Sandwell schools that they use it..

In addition Shirelands hosts for schools around the country and worldwide.

It creates content and trains staff. It does everything an LEA should do but its team is dedicated to supporting students and staff. It takes the teckie bits away for schools.

Its done some excellent work with flash using sharepoint, which it shares with its schools. It shows them how best to use sites for the learning process. Its not particularly prescriptive it advises schools on how best to use it.

I would say it sells its content and training but the moderator will moan.

It also advises other gateways and gives free advice and demos.

Does Becta listen to the team. No. Shireland is not about the technical box ticking but what works for students and teachers

The other school in the booklet is also excellent in what it is doing.

Computers for pupils scheme was the direct result of a Shireland Testbed project. It distributed over 2400 computers to families, gave out 800 broadband connections and linked them to a portal.

Like usual this was done quitely with no meeting for meeting sake. Lets hope LEAs can do the same wiith some of the £60 m given to them

[Sypher]

For web services (like your VLE example) our LEA provides a reverse proxy. This functions adequately. However, it's yet another performance bottleneck and single point of failure.

Drifting gently off-topic here, but how do you know the reverse proxy is a single point of failure? In actual fact there are two CLEO reverse proxies (they are provided by your RBC, not your LEA), and they will fail over.

In the event of hardware failure of one proxy, the other will take over. Since this is a data-less service, further proxies can be installed onto fresh hardware, (providing we have hardware, of course) in about 20 minute from bare metal to fully-functioning proxy. This situation will be improved still further when the load balancers go live on this service.

Now, how many Moodle web / database / file servers to do you have? How many 'net feeds? How many routers at the border into CLEO? Etc...

[SimpleSi]

Before Geoff comes back (and I'm sure he will) but ...

but how do you know the reverse proxy is a single point of failure?

We don't because we are treated like mushrooms

In the event of hardware failure of one proxy, the other will take over.

Us mushrooms don't know that - do we have any SLA thats says this will happen - who gets fired if it doesn't?

further proxies can be installed onto fresh hardware, (providing we have hardware, of course) in about 20 minute from bare metal to fully-functioning proxy.

I can do some neat reconfiguration tricks with an AP in 10 mins if my DHCP server goes down - but only on a good day, with a following wind so don't try and blow us off with our support skills are better than yours routine.

This situation will be improved still further when the load balancers go live on this service.

Jam tomorrow

Now, how many Moodle web / database / file servers to do you have? How many 'net feeds? How many routers at the border into CLEO? Etc...

Translate - stay in your kiddies playground and leave it to the grownups to sort things out

Come and visit our world and see how things aren't quite as rosy and how we battle against the gods themselves into providing actual practical working IT to our pupils.
[/RANT]

Simon

PS Welcome to the forum

[Ric_]

Now now Simon, play nicely.

Hearing the reports from those unfortunate enough not to be in CLEO we do have it pretty good. I must agree though that a lack of written SLA or any documentation outlining any of the points raised is very frustrating.

I think that the problem with Lancashire is the additional layer that Westfield adds so we do sometimes find it difficult to get a straight answer. If we were allowed to talk to CLEO direct, a lot of the misconceptions could be cleared up IMHO.

[Sypher]

Before Geoff comes back (and I'm sure he will) but ...

but how do you know the reverse proxy is a single point of failure?

We don't because we are treated like mushrooms

In the event of hardware failure of one proxy, the other will take over.

Us mushrooms don't know that - do we have any SLA thats says this will happen - who gets fired if it doesn't?

I think it's fairly widely recognised that neither LEA nor RBC is the best at
communicating stuff to schools (having just had a poke around the CLEO site, I
couldn't find any published info along those lines. Maybe I'm missing
something, but I doubt it.) Sadly, all that is done at a different level --
we just implement.

But if you don't *know* then why say that it is?

As for firing, there aren't enough of us to fire any

further proxies can be installed onto fresh hardware, (providing we have hardware, of course) in about 20 minute from bare metal to fully-functioning proxy.

I can do some neat reconfiguration tricks with an AP in 10 mins if my DHCP
server goes down - but only on a good day, with a following wind so don't try
and blow us off with your support skills are better than yours routine.

It's not about support skills. We *know* how much the schools rely on a lot of
the services we provide (like Moodle, the reverse proxy, etc) being available,
and we know how much disruption is caused when they're not. In the case of
data-less servers like the reverse proxies, dns servers, etc, it's actually
quicker for us to rebuild a server from scratch than to find the appropriate
backup tapes -- we've put an *awful* lot of time and effort into building a
system for doing exactly this, which we're hoping to be able to release as Free
Software when we've done a bit more polishing.

Now, how many Moodle web / database / file servers to do you have? How many 'net feeds? How many routers at the border into CLEO? Etc...

Translate - stay in your kiddies playground and leave it to the grownups to sort things out

Again, nope. My point isn't the quatity relative to what we look after (sorry
if it came across like that) but rather that the reverse proxy really isn't the
major single point of failure there; even if Geoff has multiple Moodle
servers backing each other up, there are plenty of other SPOFs between him
and the world, whereas the proxy is actually resilient.

Come and visit our world and see how things aren't quite as rosy and how we battle against the gods themselves into providing actual practical working IT to our pupils.
[/RANT]

Welcome to our club

What I object to though, is the automatic assumption that the proxies are crap,
and the fact that something that simply isn't true is presented as gospel
without knowledge and without checking. Now, I don't mind constructive comments, either here or via your LEA support. We are more than open to suggestions and questions; is it too much to ask for people to check their facts?

PS Welcome to the forum

Thanks

[Geoff]

Drifting gently off-topic here, but how do you know the reverse proxy is a single point of failure?

I meant to use the term 'reverse proxy' to refer to the system as a whole rather than the equipment and software performing said process.

In actual fact there are two CLEO reverse proxies.

I am aware of this.

In the event of hardware failure of one proxy, the other will take over. Since this is a data-less service, further proxies can be installed onto fresh hardware, (providing we have hardware, of course) in about 20 minute from bare metal to fully-functioning proxy.

Well, as I said, I did know there was two boxes doing the job (it's obvious enough from the IPs in the webserver access logs and the DNS info). However, no matter how well engineered and fault tolerant the boxes themselves I have misgivings about the surrounding networking infrastructure. I have seen several cases of jitter, packet loss and poor latency within the network. I don't know if it's CLEO, LGfL or something else, but either way some thing's not right somewhere.

This situation will be improved still further when the load balancers go live on this service.

Are these the same type of load balancers that occasionally decide to fail to load balance the HTTP proxy servers correctly at LGfL?

Now, how many web servers

Two (although admittedly only one is configured for external access).

database

Two

file servers to do you have?

Two. I'm hoping to go the SAN route though soon.

How many 'net feeds?

AFAIK one upstream, several downstream to various primary schools.

How many routers at the border into CLEO?

One visible router.

Now I don't doubt I have a slightly blinkered view of the network infrastructure beyond my local CLEO router (Something I could resolve by sufficient poking around I suppose). However it is my understanding that there is a lack of redundancy in the links between the various schools and the upstream links to CLEO/LGfL/Lancs Uni/JANet/whatever. Therefore, no matter how great the 'reverse proxy' might be, the rest of the system lets it down.

[Sypher]

Drifting gently off-topic here, but how do you know the reverse proxy is a single point of failure?

I meant to use the term 'reverse proxy' to refer to the system as a whole rather than the equipment and software performing said process.

There isn't really much more to the system than that...

This situation will be improved still further when the load balancers go live on this service.

Are these the same type of load balancers that occasionally decide to fail to load balance the HTTP proxy servers correctly at LGfL?

I have no idea what LGfL use.

How many routers at the border into CLEO?

One visible router.

Now I don't doubt I have a slightly blinkered view of the network infrastructure beyond my local CLEO router (Something I could resolve by sufficient poking around I suppose). However it is my understanding that there is a lack of redundancy in the links between the various schools and the upstream links to CLEO/LGfL/Lancs Uni/JANet/whatever. Therefore, no matter how great the 'reverse proxy' might be, the rest of the system lets it down.

Your main SPOF is the link between you and the rest of Preston. However, that is equally valid whether you're presenting your VLE to the world through the reverse proxy or whether you're using a global IP on the server itself. So why single the reverse proxy (as the specific boxen or as the wider service) out for introducing a SPOF (which it doesn't) when your main SPOF is actually your single uplink?

[Geoff]

There isn't really much more to the system than that...

There is, there's the logical IP routing and the physical cable/fibre wiring it all up. Oh, and various DNS records on the primary/secondary NS for the zone of course.

So why single the reverse proxy (as the specific boxen or as the wider service) out for introducing a SPOF (which it doesn't) when your main SPOF is actually your single uplink?

Because from my position on the network I don't get to see that. All I can see is end user services. I don't get to see how it glues together or interacts. All I can come back to my boss with when external services go down is 'It's broke and it's not us' which kinda sucks.

Thanks for confirming my suspicions about the network connectivity though. I'll have to inquire about improvements to that situation next time I get chance.

[GrumbleDook]

You lot up north have it good ... you just speak to us lot on EMBC and *then* you will understand what is meant by Mushrooms ... and then you get to the point in Northants where the local support company (contracted to do first line for EMBC) will fob you off with no information and then blame EMBC and Fujitsu because *they* can't be bothered to do the work to give you the information.

And guess who I am just about to call about it.

[zag]

We just run our own web server and open up port 80, no need to involve the lea in what ports we use.

[webman]

ittech: Some RBCs don't let schools have any ports open.

[GrumbleDook]

Actually ... when you go throught the full documentation that you should get, or should have access to, with the EMBC there are some good examples and methods of hosting servers and getting ports opened easily.

The idea that within your range you have certain IPs that are, by default, viewable to other sites within the RBC, but just need external addresses (and subsequent NATing) to be visible to the outside world.

Yes ... a sort of DMZ really (but not actually ... ) and can make life easier for schools.

The other issue is that some schools want *all* ports open on a certain IP ... even when they only want to server web pages ...

I am more than willing to say that we only have one IP like this ... all our others are restricted to certain ports (and actually come under one-to-one NAT at our internal firewall) ... and this box that is completely open *is* our internal firewall. I would not do it for any other device ...

[webman]

DurhamNET give us one external static IP, visible to the outside world and we request ports to be opened via email.

The 'Magicbox' NAT device at our end is a shuttle PC running Debian and a few of their own custom scripts with Gatekeeper for Videoconf. We run a DMZ on the other side of this which we manage ourselves.