3 ms·
When your user data / logs / spools / db files are on a filer or confined to one local place that’s easily backed up and can be deployed — I tend to use /data —
by gorgoiler 6y ago
When your user data / logs / spools / db files are on a filer or confined to one local place that’s easily backed up and can be deployed — I tend to use /data — there’s no reason to have ‘pets’ any more.
What’s the non-cattle use case you are referring to? Systems that can’t be wiped because of important persistent user processes? That’s the only volatile state I can think of that would be lost by reimaging.
- bayindirh 6y agoIn normal enterprise operations, it's easily attainable. I presume your servers are not extremely under load and they mount a remote storage system. In our system, there's tens of storage servers under heavy load (while they are redundant they are generally actively load-balancing) and more than 700 nodes which are cattle but under max load 24/7/365. The whole thing doesn't have any time or space to breath basically. While losing nodes doesn't do any harm, we lose some processes hence lose time and, we don't want that. Even if we can restore something under 15 minutes, avoiding this allows us to complete a lot of jobs. We don't want to rewind and re-execute a multi-day, multi-node job just because something decided to go south randomly. Our servers are rarely rebooted and most reboots mean we have a hardware problem.