|
Grex > Coop > #248: Running Grex as a VPS | |
|
| Author |
Message |
| 25 new of 56 responses total. |
jep
|
|
response 25 of 56:
| 
Dec 19 15:00 UTC 2008 |
A JOA between M-Net and Grex?
There would be little reason at that point not to simply merge the two
systems. Both have Boards which do little and need to do little; a
shortage of staff members; and nearly identical conferencing systems
with mostly the same users. There is one staff member in common with
the two, who is cross. In a lot of ways it is already hard to tell
which system you're on. There could be a general and an agora
conference, with a few specialty conferences shared by both.
The difference between running the two organizations on one computer,
and running one organization, is minimal.
I do think we are heading in that direction. I've thought so for
several years. I think there are a few who would be vehemently opposed,
a few who would quit using whichever system they use now and go away
entirely, and the rest (a pretty small number) would go along with it.
|
cross
|
|
response 26 of 56:
|
Dec 19 18:44 UTC 2008 |
Eh, diversity is good. But virtualizing the hardware and running both systems
on the same physical box might not be a bad idea.
|
jep
|
|
response 27 of 56:
|
Dec 19 20:56 UTC 2008 |
I dunno, when it's the same group of users, I don't see that there's
much more diversity from two systems than from one. The world has a lot
of diversity in discussion forums, anyway. Grex and M-Net have very
little influence on that, whether each or both continue to exist.
|
remmers
|
|
response 28 of 56:
|
Dec 21 17:03 UTC 2008 |
Re resp:25 - "The difference between running the two organizations on
one computer, and running one organization, is minimal."
Wrong, if each runs in its own VPS.
But the question of a Grex/Arbornet merger is material for a different
item. For now I'll just say that I agree with the first sentence of
Dan's resp:26.
Re an earlier question: No, not interested in returning to staff at
this point, at least not the day-to-day-keeping-things-running variety
of staff work. Did it for 15 years; that's enough for the forseeable
future, for me. I'd consider lending a hand for projects of limited
duration where I feel I could be of help, such as migrating Grex to
FreeBSD, if folks should decide they want to go in that direction.
|
cross
|
|
response 29 of 56:
|
Dec 21 17:59 UTC 2008 |
Fair enough.
|
lar
|
|
response 30 of 56:
|
Dec 21 18:51 UTC 2008 |
you can forget about any grex/arbornet merger
|
jep
|
|
response 31 of 56:
|
Dec 21 21:40 UTC 2008 |
I wasn't proposing one. I was forecasting that that could happen someday.
|
tsty
|
|
response 32 of 56:
|
Dec 26 14:42 UTC 2008 |
having the wequivant of 'off site backup' grex<==>m-b0x creates a
more reliable 'place to go' - not too likely tat both b0xes, in different
placers, would be broken at the same time.
|
jared
|
|
response 33 of 56:
|
Jan 1 07:40 UTC 2009 |
are the modems really needed anymore?
|
mary
|
|
response 34 of 56:
|
Jan 3 22:13 UTC 2009 |
Too cool. Jared stopped by.
Welcome to Grex!
|
cross
|
|
response 35 of 56:
|
Jan 5 00:05 UTC 2009 |
resp:33 Needed or wanted....
|
tsty
|
|
response 36 of 56:
|
Jan 5 10:49 UTC 2009 |
|
tsty
|
|
response 37 of 56:
|
Jan 5 10:56 UTC 2009 |
|
remmers
|
|
response 38 of 56:
|
Jan 5 12:53 UTC 2009 |
Getting back to the idea of running Grex as a VPS... It could have
avoided the recent multi-day outage.
|
cross
|
|
response 39 of 56:
|
Jan 5 15:07 UTC 2009 |
Could it have? What was the recent multi-day outage all about?
|
unicorn
|
|
response 40 of 56:
|
Jan 6 00:52 UTC 2009 |
I'm not sure what caused it, or even how it happened to get rebooted.
All I know is that over the new year, I didn't have a chance to log in
for several days, and when I tried to log in at about 3:00 pm on the
3rd, grex was down, and not even responding to pings or traceroute.
I was just about to call provide.net to have it rebooted, but after
looking up the information I needed to give them, I tried one last
ping, and when I got a response, I tried logging in, and was successful.
It appeared to have been down since sometime early on the 1st, but I
don't know how it just happened to have been rebooted at the exact same
time I was trying to log in. I was the first to log in after the reboot,
and no one else that I would have guessed might have called logged in
right after the reboot, so it's a mystery to me. It seems that the only
reason it was down for two days is because none of the people authorized
to call provide.net tried to log in during that time.
|
unicorn
|
|
response 41 of 56:
|
Jan 6 00:55 UTC 2009 |
I hadn't yet read agora when I posted that. I see Joe (gelinas) was the
one who called. Thanks, Joe.
|
cross
|
|
response 42 of 56:
|
Jan 6 03:52 UTC 2009 |
Is there really any difference between logging into the virtual server
console or calling provide.net and asking them to power-cycle the machine?
I really don't see how using the VPS solution would have "prevented" the
recent outage. Perhaps made it marginally easier to fix, but that's about
it.
|
mary
|
|
response 43 of 56:
|
Jan 6 11:41 UTC 2009 |
Nights, weekends and holidays would be the difference.
|
remmers
|
|
response 44 of 56:
|
Jan 6 12:39 UTC 2009 |
Yes. On-site ProvideNet support isn't available 24/7, but a virtual
console would be. Wouldn't have prevented the problem from occurring,
but it certainly would have been quicker to fix.
|
cross
|
|
response 45 of 56:
|
Jan 6 16:33 UTC 2009 |
I'm not so sure about that.
The fundamental problem isn't access, but getting someone to notice
and use whatever access is available. It's still not clear to me
that anyone who could have done anything about it noticed right
away. At that point, whether the vector to bring the system back
online is a phone call or a virtual console is irrelevant, because
there isn't anyone to do the job.
Besides, if we ran some sort of virtualization solution on our own
hardware, we could have reaped the benefit of virtual consoles and
etc. It doesn't require that a third party runs it for us.
I'll restate my specific objections to the idea of hosting Grex on
a virtualization hosting provider at this point in time:
1. Modems. No one has even bothered to address this one yet.
2. Maturity. These solutions are relatively new, and they're just
not mature enough for our use. There's a strong possibility
that they will be in a year or two, but we're not there yet.
3. Privacy. If we host our data on someone else's server, how do
we know who looks at it? I'm not sure this matters, but it has
in the past.
4. Solving the wrong problem. This isn't about hardware reliability,
it's about staff availability. A virtual solution with
net-accessable virtual consoles isn't going to solve that, and
as I stated above, we could realize the same benefits on our own
hardware.
5. Quality of service (in the performance sense). With a virtualized
solution, we lose some of this, as we no longer control what
happens on our hardware. Another user of the virtualization
service that happens to be using the same *physical* computer
as our virtualized server could send our performance spiraling
by running some job that sucks up some resource, thus starving
us. Disk and network capacity come immediately to mind, and
even if other services are rate-limited going out, nothing can
stop the network interface from being overwhelmed with incoming
traffic.
I'm not in principle opposed to a virtualized solution, but I'd
rather us do another round of Grex on our own hardware to let the
commercial virtualization offerings mature and address the above
issues than jump ship before the infrastructure is really ready.
For example, it's highly probable that in four years or so, modems
just won't be an issue or that we can force them not to be even if
they still are.
|
mary
|
|
response 46 of 56:
|
Jan 6 17:58 UTC 2009 |
1. Are the modems being used much? I'd bet not but some data would be
nice.
2. Our way of doing it is old and no longer matches our needs which is a
thin and disperse staff. Change can be good. We should be looking
forward. Commercial equipment and service providers seems to be working
for most of the internet.
3. Privacy? I'd go out of my way to warm people that nothing here is
backed up or private. Use at your own risk and that's regardless of who
controls the hardware.
4. It is about staff availability. Would it be easier to recruit more
staff if the hardware was on reliable equipment, supplied and maintained
by for-profit entities with a stake in keeping us up and running? Don't
know. But I do wonder where this new machine you refer to will be
delivered. Ann Arbor? Is anyone here going to set it up? Ask Mark
about last time around and how long new equipment sat in a box because
staff wasn't available. And that was when we had local staff.
5. Quality of service? See 4. The company has a stake in making sure
we are happy with the service. Nobody is doing that presently and it
shows.
If we could get staff interested in setting it up I'd like to see
something like this tried if only in a limited way. Maybe setup Grex II
on it and keep both systems up for 3 months - comparing service, reliability,
comfort, etc.
But with our lack of staff I think it would be a big mistake to put a
chunk of change into new hardware at this point.
|
cross
|
|
response 47 of 56:
|
Jan 7 01:57 UTC 2009 |
resp:46
1. I'm not sure that's the point. I've suggested in lesser or more
subtle ways that we need to start thinking about getting rid of
modem access over the last few months, but met with resistance.
There are a few very well established users who use the modems.
It's part of Grex's philanthropic charter. It may even be related
to our status as a non-profit organization. Can all of these things
been fixed? Yeah, given time, but Grex just isn't ready for that
change yet.
2. Not really. There's a big difference between what most of the
rest of the Internet does and what John is describing.
3. In principle I'd agree with you. But not everyone would. Have
you discussed your thoughts on this with Steve Andre? He believes
one of the benefits of Grex is that it allows people to do things
"under the radar" of certain repressive regimes around the world;
that's one of his arguments for fixing mail as a viable service to
draw new users. He has a compelling vision there. My own perspective
is that we shouldn't guarantee privacy, but we shouldn't give access
to our data to outside organizations either. That's exactly what
we'd be doing with a virtualized solution.
4. Who says it's the current hardware that's not reliable? I see
no indications of that. If you have data to the contrary, I'd love
to see it. What I'm seeing is that it's the software (particularly
OpenBSD) that isn't reliable. Virtualization won't solve that if
we stick with OpenBSD. If we switch to FreeBSD, we'd get the benefit
of (possibly) greater reliability on our own hardware, too. Cause
and effect aren't correlated here.
As for new hardware, ship it to me in New York; I'll set it up and
ship it to Ann Arbor for physical placement at Provide.net.
You assume too much in assuming that, at present, those commercial
entities (a) want a stake in keeping us up and running (think about
what we do and what most companies do and how they differ), (b) the
virtualization technology is mature enough to support us yet, (c)
that it would be any more relabile than what we currently run, (d)
we couldn't reap most of the benefits of virtualization on our own
hardware, without the drawbacks.
5. Note that I said QoS with respect to performance, not availability
of the service. If we run a virtualized service on physical hardware
that supports multiple services, some of which are presumably beyond
our control, how do we prevent their workloads from interfering
with our own? The sad truth is that we cannot. If you disagree
post data to back yourself up.
I did a financial analysis earlier in this thread showing that we'd
about break even over a four year anticipated lifespan of new
equipment (that's assuming there aren't hidden costs associated
with a virtualized solution that we haven't considered yet). By
then, the virtual provider offerings will have matured enough to
make this viable. Right now, I'm just not seeing a compelling
argument for it. Hope isn't a strategy, and right now, the argument
*for* VPS is predicated on the hope that it would solve lots of our
problems, but no data to back that up. I'd be willing to do some
experiments to get some of that data (which is what you elluded to)
but I am unwilling to jump to a radically different, virtualized
server unless I see data strongly indicating a net positive benefit.
The bottom line is this: without some hard data, I'm just not seeing
the benefit here. Next step: get the data. Taking off my staff
hat and putting on my board hat for a moment, I'm 100% behind you
and John getting some of the data and presenting it to the board.
|
mary
|
|
response 48 of 56:
|
Jan 7 12:47 UTC 2009 |
I'm glad we're having this discussion now because hardware has a
lifespan and even if our equipment is reliable now, it won't always be
so. A big part of my perspective on this is assuming we have to make a
choice between our own hardware or virtual hardware.
These systems that are running on for-profit hardware wouldn't be there
long if service was lousy. I consider that soft data. How are we doing
in terms of use? How does fairly frequent downtown, like over the last
holiday weekend when Provide wasn't there to reboot, affect our
community? Again, soft data, but I'd think it hurts us in terms of
users.
And I'd really like to hammer home my point about privacy on Grex. I
can't speak for STeve but over the years the terrain has changed. First
off, we don't have physical control of the machine. He who has the
machine has root. Two, if one of our users, foreign or US citizen, had a
presence here and he or she was under investigation, we'd give it up.
Period. In many instances it would be illegal not to. Too, we couldn't
afford to legally fight to protect that information. At least not for
long, like past a token retainer. So we must not, in any way, pretend
we're about privacy. The best thing we could do, all around, is warn
people to be very careful what they do here with sensitive information.
Regarding hard data, you're not going to get it until you can compare
Grex on virtual to Grex at Provide. Hence, my suggestion we give it a
try. But first we need a miracle. Staff.
|
naftee
|
|
response 49 of 56:
|
Jan 12 00:19 UTC 2009 |
COGNRANTUG:LATIONS< TS> FOR WINNING THE BOARD SEAT>
ARE YOU GOING TO BE TYP:ING UP THE MINUTES ? I THINK THEY REALLY SHOULD MAKE
YOU SEDCRETARY
MJAYBE THE IRS WILL TAKE A QUCICK LOOK AT THOSE FUNKY MINUTES<> REEZEF> AND
THEN SEND SOE P{OELICE OFFICIERS TO BREAK UP THE NEXT BOARD MEETING NBECAUSE
WHO KNOWS< YUOU GUYS MIGHT BE ON ACID< JUDGING BY THAT TYPING AND THE USE OF
PSYCHEDELIC WORDS SUCH AS "EPISTOLICALLY EPISTEMOLOGICALLY SOUND< DUDE"
JUST FOOD FOR THOUGHT< YOU KNOW
|