|
|
|
|
|
|
by fundabulousrIII
3249 days ago
|
|
|
Every network access to disk based storage that can't be
cached|copied to the your ram filesystem for the lifetime of your container is a performance hit and you can't scale with RAM backed storage without more phys memory. As a matter of fact when you run out of RAM in your (maybe incomplete) scenario you no longer have a working node. Zero sum. DRBD is fine (used it for years) but it's not something that is one size fits all. |
|
|
Rare for most services. Stuff like logs can be shuffled off elsewhere for a write, requiring no commit validation. Only DB/fileservers really require permanent storage with commit validation, writes are typically rare, and 100Gbps+ LAN on a PXE-based diskless cluster is not going to be introducing massive latency, especially if you prioritize the VLAN or link multiple ports. Reads are typically cheap and cacheable.
that can't be cached|copied to the your ram filesystem for the lifetime of your container
IMHO most services and their dependencies will come in well under 512MB, so that's a non-issue.
you can't scale with RAM backed storage without more phys memory
By definition, one could say the same about anything... although to be fair you could still scale via compression, sharding, or another established strategy.
when you run out of RAM...
In a managed scenario a service container or VM would terminate or a significant degradation in response time would be detected, it would be taken out of the service pool and stop having traffic routed to it, be restarted, then be re-introduced to the pool. Ditto extra CPU load, broken network policies, anomalous block IO, etc. Leaving modern service-level architecture aside, basic heartbeat-style IP monitoring with reliable node-level failover has existed in open source since the 90s. There's really no excuse to wing this stuff on production systems today.
it's not something that is one size fits all
Nothing fits all!