Yeah, the whole 34/68GB is all on a single beefy server. There are systems that let you access remote node's memory in a NUMA type system over fast interconnects, but they're _very_ expensive and have horrible latency.
Yes, and it works fine as long as you accept that data will need to be migrated at some point when you run out of memory and/or instances.
To put this off as long as possible, you can max out the memory in your boxes and use a large number of servers - 100s in some cases - running on those servers, hopefully with less than 1 per CPU core to maximize performance.
Then if you begin maxing out memory, you can easily split those servers onto their own hardware. My calculations showed that would allow scaling to trillions of keys without problems.
Could be done with a moderate-spec single server. Replace the JBOD enclosures with on-server 8xSamsung EVOs in hardware RAID6, and gain a bit in speed because we don't have drives that slow anymore. Xeon E5v4 could replace the computational power. Network multihoming would be done the same, except with 10000baseT instead of multiple cables. Run nginx on it and you're good.
Or, one could host the entire thing on S3 with CloudFront at a fraction of the cost.
Isn't the problem then that each host would be underutilized on average by a lot? It has X cpus and the service can never use more than X cpus. If a service has any spiky loads then it'd been overprovisioned cpu to handle them at good latency.
I'd be interested in seeing how difficult it would be to modify this to use multiple communication servers (redis, cassandra, etc) so that it can be scaled across multiple instances.
Would also be interested in seeing how many connections it could handle doing say 5-10 messages per second.
It doesn't seem like a particularly elegant solution, but with that much memory, you could almost certainly carve out 4 VMs, each running a separate guac instance, right? Getting to them might be trickier, though...
Flexibility in my case. I can go from one server with 8GB of RAM to 8 copies of that server with 32GB of RAM each and back again at the press of a button as and when the need arises.
Yes but the storage used by that instance is shared among 1000 users, rather than all devoted to just one user. Theoretically there would be a fair amount of duplication and therefore less net resource use.
Question: Do all my 8 VSs have to reside on the same host? If the host goes down, it will take all my VSs with it. Any way of getting the same number of VSs but distributed across hosts?
Just going off the deep end, what if you ran an entire server farm as a single OS instance? It's certainly an interesting model for a distributed system, but I don't know how practical it is.
Even then, I don't see anyone getting 3.16 * 10^29 gigs of ram, so maybe it's just more marketing?
They might have, for all I know. It's doable in a product that isn't trying to do much else at the same time, if you own all the servers in question and can make sure they are connected by a low latency network. The bad news will come when you try to keep the property of seamlessness between servers while scaling up to do other things as well.
We have 3 servers each of 4 slots, below is the state of each server (the state of a server is a set of VMs it's running)
[3], [2, 1] and [2].
Say we need to place a new 3-slot VM to our system.
We'll pick the third server as less-loaded and try to accomodate the second server. Together they have enough space, but we can't provision the VM withour using all 3 servers. The solution here is
hey, so I'd be happy to donate 16GB worth of Xen instances to the project,just to say I did, if you need mirrors. my boxes are 32GB ram/8 core, and the CPU is proportional, so if you want 4x4GB instances over separate servers, I can do that. (well, you will have to wait a bit for me to put up the 4th server.)
FWIW, If you use one of the largest instance types (4x large or whatever), the VM will probably be on it's own host which would mean you're unlikely to have neighbors ;)
Except you don't have 3 hosts but 3 thousands, and during the time you're stopping the 9 VMs somebody else is starting 5 or 15 new ones!
Yes it is similar to memory fragmentation in some way, but your argument is like saying an integer stored on the heap costs a full memory page! You realize that it's nonsense. Sure in extreme edge cases it can, but that's not a good metric to know the memory footprint of an integer!
Being able to move VMs is nice as it allows more host use, but it's doesn't mean hosts end up with single idle VMs often!
I don't think that would be that efficient of a use of computing resources. Each instance explores the same instruction space. It keeps track of where it's explored, and uses various techniques to explore different parts of space.
It's very likely that multiple instances, if run in parallel and with no data sharing, will explore a lot of the same space.
Also, making a public cluster would be a security challenge. It runs arbitrary C/C++ code, and can trigger code paths that the developers didn't even realize. How would your box stand up to multiple grabs of 4GB of memory?
Even if servers are I/O bound, this setup is almost like crunching 50 machines into one; applications will have lower latency access to data stored on larger memory.
If you had all of the instance data stored on a fast SAN, so that it was available to all of the hosts simultaneously (possible.)
And you had an ultra-high speed interconnect (40Gbit Infiniband would do) between hosts, for sharing the memory state when you migrate..
4GB of memory, at 40Gbit/s would be transferred in 0.8s. (assuming perfect throughput, all cows are spherical, etc..)
reply