Re: Standard systems...
> "The official name is Prince 2"
Umm, PRINCE2
http://prince2.wiki/PRINCE2
15 publicly visible posts • joined 1 Apr 2015
> I wonder if Go can cope with a thread blocking on network I/O?
All I/O requests are handled in a special thread which multiplexes all the file-descriptors (with a select/epoll) called the netpoller.
It can become a bottleneck if the program is handling a lot (>100Mbps) of network traffic.
This is the problem I'm having at the moment with some code I've written. I've mitigated it by dedicating an OS thread to each TCP port with runtime.LockOSThread() and using some inline C (or /x/sys/unix) to read the data with direct syscalls.
It's not perfect, but if I was trying to write the app in C I'd still be bashing rocks together.
Hey man, I'm just using your terminology:
" Hey, I've got an object storage system, and didn't know it! The "globally unique identifier" starts with "/home/peter/Media..." or some such, and each object has some metadata that can be seen using examination tools like "ls -l", "istat" and "file""
My point was that an object can be instantiated in one location with certainty that it will not clash with an object in another location. That is all.
Once it is instantiated it can be replicated to the other locations. If it needs to be accessed from another location BEFORE it has been replicated then it can be requested from the originating location (and now it has been replicated).
Quoth you:
"How global is global? If it's really global, what is the arbitration system to make sure that there are no collisions with other systems and organizations? And are objects immutable so that you have to version them as part of their globally unique identifier?. I cannot really believe that there are people who believe that a non-hierarchical unique identifier is really possible at any scale."
I am just answering your questions. A local originator being part of the key prevents collision between locations (and a local arbitrator prevents local collisions). If they are immutable then replication is very easy.
I'm not detailing the working of any actual system. Just suggestions as to how they *could* work.
I'm not suggesting that you should use then for any particular workload, just that their properties may be useful some workloads.
Take it or leave it. Meh.
Peter.
Once you drop the POSIX requirements of a traditional filesystem many things become a lot easier.
Globally unique identifiers can be randomly generate with a (very) high probability that they will not clash. Sure there may be some arbitration involved but simply making part of the key unique to the generating geo-datacentre would be a big help.
If an object is write-once rather than updatable then replication is a breeze (have the object stored locally? yes - serve it, no - contact the datacentre identified in the geo part of the key to fetch it on the fly and cache it). A worldwide replicated POSIX filesystem would be a weeee bit trickier to achieve with the possibility of multiple writers.
You don't have to "mount" an object store - it's just "there" via an API.
Unshackle yourself!
If you're predicating a "cloud" application on the ability for a VM to be transparently migrated from one physical server to another then you are Doing It Wrong.
If you even *considered* EC2 for this kind of application (never mind had a meeting with their top brass) then you are In The Wrong Job.
XenServer (http://blogs.citrix.com/2013/06/25/xenserver-6-2-is-now-fully-open-source/) is fully Open Source now too as well as having commercial support. So don't discount it thinking you'll have to pay big bucks.
The live migrations between machines without the need for shared storage is fricking fantastic!
Genuine question - does one really need VHDL to setup a whitebox switch, rather than just configuring switching parameters (VLANs, MPLS, routing, QoS, trunks, VTP-domain-type-stuff)?
If so, why is that the case - do you really need to reprogram the ASICs on interfaces?
If you've got any reasonably competent IPMI baseboard management controller then you'll be able to remotely power down/up and likely a decent Serial Over LAN interface to access the BIOS should you need to.
The Dell iDRAC6 onwards is real nice for the built in KVM and remote media though ...