|
Grex > Coop > #248: Running Grex as a VPS | |
|
| Author |
Message |
| 25 new of 56 responses total. |
tsty
|
|
response 21 of 56:
| 
Dec 18 05:44 UTC 2008 |
ummmmmmm, can we users login with newuser? url pse?
|
mickeyd
|
|
response 22 of 56:
|
Dec 18 20:48 UTC 2008 |
re #20 - thanks.
What if we virtualized grex and m-net on the same hardware? like a two in
one type system? just kinda merge them together, but keeping them seperate?
Ok, i'll shut up now.
|
cross
|
|
response 23 of 56:
|
Dec 18 21:47 UTC 2008 |
I'm not opposed to doing that.
|
tsty
|
|
response 24 of 56:
|
Dec 19 09:56 UTC 2008 |
oh, wow ... the word 'merge' is anathema in extremis.
not even teh det freepress & det newds is as bad a thought.
but a thought nonetherlwess..
and it;s not an hostility thing .. it's a2 cultural.
|
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.
|